From ce04a9f0fb562c0dd78e2d5c5b30100c982672a1 Mon Sep 17 00:00:00 2001 From: Mikhail Kalinin Date: Thu, 22 Jul 2021 20:59:10 +0600 Subject: [PATCH 01/15] Create eip-3675.md --- EIPS/eip-3675.md | 244 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 244 insertions(+) create mode 100644 EIPS/eip-3675.md diff --git a/EIPS/eip-3675.md b/EIPS/eip-3675.md new file mode 100644 index 0000000000000..0c5933ffa7782 --- /dev/null +++ b/EIPS/eip-3675.md @@ -0,0 +1,244 @@ +--- +eip: 3675 +title: Upgrade consensus to Proof-of-Stake +author: Mikhail Kalinin (@mkalinin), Danny Ryan (@djrtwo), Vitalik Buterin (@vbuterin) +discussions-to: +status: Draft +type: Standards Track +category: Core +created: 2021-07-22 +requires: 2982 +--- + + +## Simple Summary + +Specification of the consensus mechanism upgrade on Ethereum Mainnet that introduces Proof-of-Stake. + + +## Abstract + +This EIP deprecates Proof-of-Work (PoW) and supersedes it with the new Proof-of-Stake consensus mechanism (PoS) driven by the beacon chain. Information on the bootstrapping of the new consensus mechanism is documented in [EIP-2982](/EIPS/eip-2982). Full specification of the beacon chain can be found in [eth2.0-specs](https://github.com/ethereum/eth2.0-specs/) repository. + +This document specifies the set of changes to the block structure, block processing, the fork choice rule and the network interface introduced by the consensus upgrade. + + +## Motivation + +The beacon chain network has been up and running since December 2020. Neither safety nor liveness failures were detected during this period of time. The long period of running without failures demonstrates sustainability of the beacon chain system and witnesses its readiness to start driving and become a security provider for the Ethereum Mainnet. + +To understand the motivation of introducing the Proof-of-Stake consensus see Motivation section of [EIP-2982](/EIPS/eip-2982#motivation). + + +## Specification + +### Definitions + +* **PoW block**: Block that is built and verified by the existing proof-of-work mechanism. In other words, a block of the Ethereum network before the consensus upgrade. +* **PoS block**: Block that is built and verified by the new proof-of-stake mechanism. +* **Terminal PoW block**: A PoW block that satisfies the following conditions -- +`pow_block.total_difficulty >= TERMINAL_TOTAL_DIFFICULTY` *and* `pow_block.parent_block.total_difficulty < TERMINAL_TOTAL_DIFFICULTY`. +There can be more than one terminal PoW block in the network, e.g. multiple children of the same pre-terminal block. +* **`TERMINAL_TOTAL_DIFFICULTY`** The amount of total difficulty reached by the network that triggers the consensus upgrade. +* **`TRANSITION_BLOCK`** The earliest PoS block of the canonical chain, i.e. the PoS block with the lowest block height. +`TRANSITION_BLOCK` **MUST** be a child of a terminal PoW block. +* **`POS_CONSENSUS_VALIDATED`** An event occurring when the PoS block is validated with respect to the proof-of-stake consensus rules. +* **`POS_CHAINHEAD_SET`** An event occurring when the PoS block is designated as the head of the canonical chain. +* **`POS_BLOCK_FINALIZED`** An event occurring when the PoS block is considered as finalized. + +#### PoS events + +Events having the `POS_` prefix in the name (PoS events) are emitted by the new proof-of-stake consensus mechanism. They signify the corresponding assertion that has been made regarding a block specified by the event. The underlying logic of PoS events can be found in the beacon chain specification. On the occurence of each PoS event the corresponding action that is specified by this EIP **MUST** be taken. + +Each `POS_BLOCK_FINALIZED` event has a reference to the head of the canonical chain in addition to the finalized block and incorporates the semantics of the `POS_CHAINHEAD_SET` event. Thus, every action and effect that is specified on the occurrence of `POS_CHAINHEAD_SET` event according to this EIP **MUST** also be taken on every occurrence of `POS_BLOCK_FINALIZED` event. + + +### PoW block processing + +PoW blocks that are descendants of any terminal PoW block **MUST NOT** be imported. This implies that a terminal PoW block will be the last PoW block in the canonical chain. + + +### Block structure + +Beginning with `TRANSITION_BLOCK`, a number of previously dynamic block fields are deprecated by enforcing these values to instead be constants. Each block field listed in the table below **MUST** be replaced with the corresponding constant value. + +| Field | Constant value | +|-|-| +| **`ommersHash`** | `Keccak256(RLP(EMPTY_LIST))` | +| **`difficulty`** | `0` | +| **`extraData`** | `EMPTY_LIST` | +| **`mixHash`** | `0x0000000000000000000000000000000000000000000000000000000000000000` | +| **`nonce`** | `0x0000000000000000` | +| **`ommers`** | `EMPTY_LIST` | + +*Note*: `EMPTY_LIST` denotes `[]` respecting the semantics of the corresponding field. + +*Note*: Logic and validity conditions of block fields that are *not* specified here **MUST** remain unchanged. Additionally, the overall block format **MUST** remain unchanged. + + +### Block validity + +Beginning with `TRANSITION_BLOCK`, the block validity conditions **MUST** be altered by the following: +* Remove verification of the block's **`difficulty`** value with respect to the difficulty formula. +* Remove verification of the block's **`nonce`** and **`mixHash`** values with respect to the Ethash function. +* Remove all validation rules that are evaluated over the list of ommers and each member of this list, except for enforcing this list to be empty. +* Add verification of the fields noted in [block structure](#Block-structure) as their specified constant value, including the enforcement of empty ommers list. +* Add verification of block validity with respect to the PoS consensus rules, i.e. assert that there **MUST** be a corresponding event for the block to consider it valid. Such events are limited to the following: + * A `POS_CONSENSUS_VALIDATED` event considering the block or any of its descendants as valid. + * A `POS_CHAINHEAD_SET` event, including the `POS_BLOCK_FINALIZED` form of this event, designating the block or any of its descendants as the head of the canonical chain. + +*Note*: If one of the new rules fails then the block **MUST** be invalidated. + +*Note*: Validity rules that are not specified in the list above **MUST** remain unchanged. + + +### Block and ommer rewards + +Beginning with `TRANSITION_BLOCK`, block and ommer rewards are deprecated. Specifically, the following actions **MUST** be taken: +* Remove increasing the balance of the block's **`beneficiary`** account by the basic block reward. +* Remove increasing the balance of the block's **`beneficiary`** account by the ommer inclusion reward per each ommer. +* Remove increasing the balance of the ommer's **`beneficiary`** account by the ommer block reward per each ommer. + +*Note*: Transaction fee mechanics affecting the block's `beneficiary` account **MUST** remain unchanged. + + +### Fork choice rule + +As of the first `POS_CHAINHEAD_SET` event, the fork choice rule **MUST** be altered in the following way: +* Remove the existing PoW heaviest chain rule. +* Adhere to the new PoS LMD-GHOST rule. + +The new PoS LMD-GHOST fork choice rule is specified as follows. On each occurrence of a `POS_CHAINHEAD_SET` event including the first one, the following actions **MUST** be taken: +* Consider the chain starting at genesis and ending with the block nominated by the event as the canonical blockchain. +* Set the head of the canonical blockchain to the block nominated by the event. + + +### Network + +The networking stack **SHOULD NOT** send the following messages if they advertise the descendant of any terminal PoW block: +* [`NewBlockHashes (0x01)`](https://github.com/ethereum/devp2p/blob/master/caps/eth.md#newblockhashes-0x01) +* [`NewBlock (0x07)`](https://github.com/ethereum/devp2p/blob/master/caps/eth.md#newblock-0x07) + +Beginning with the first `POS_BLOCK_FINALIZED` event, the networking stack **MUST** remove the handlers corresponding to the following ETH protocol messages: +* [`NewBlockHashes (0x01)`](https://github.com/ethereum/devp2p/blob/master/caps/eth.md#newblockhashes-0x01) +* [`NewBlock (0x07)`](https://github.com/ethereum/devp2p/blob/master/caps/eth.md#newblock-0x07) + + +## Rationale + +The changes specified in this EIP target a minimal requisite set of consensus and client software modifications to safely replace the existing proof-of-work consensus algorithm with the new proof-of-stake consensus represented by the already in-production beacon chain. + +Minimalism in this changeset was chosen to reduce the complexity of the unprecedented task of hot-swapping the live consensus of the Ethereum network in order both to increase the safety of the operation and to reduce the time to production. Additionally, a minimal changeset helps ensure that *most* smart contracts and services will continue to function as intended during and after the transition with little to no required intervention. + +### Total difficulty triggering the upgrade + +See [Security considerations](#Terminal-total-difficulty-vs-block-number). + +### Halting the import of PoW blocks + +See [Security considerations](#Halt-the-importing-of-PoW-blocks). + +### Replacing block fields with constants + +Deprecated block fields are replaced with constant values to ensure the block format remains backwards compatible. Preserving the block format aids existing smart contracts and services in providing uninterrupted service during and after this transition. + +This change introduces an additional validity rule that enforces the replacement of deprecated block fields. + +### Replacing `difficulty` with `0` + +After deprecating the proof-of-work the notion of difficulty no longer exists and replacing the block header **`difficulty`** field with `0` constant is semantically sound. + +### Deprecating `extraData` + +The **`extraData`** field is deprecated in favour of the corresponding **`graffiti`** field of the beacon block. + +### Changing block validity rules + +The rule set enforcing the PoW seal validity is replaced with the corresponding PoS rules along with the consensus upgrade as the rationale behind this change. + +An additional rule validating a set of deprecated block fields is required by the block format changes introduced by this specification. + +### Removing block rewards + +Existing rewards for producing and sealing blocks are deprecated along with the PoW mechanism. The new PoS consensus becomes both responsible for sealing blocks and for issuing block rewards once this specification enters into effect. + +### Supplanting fork choice rule + +The fork choice rule of the PoW mechanism becomes completely irrelevant after the upgrade and is replaced with the corresponding rule of the new PoS consensus mechanism. + +### Removing block gossip + +After the upgrade of the consensus mechanism only the beacon chain network will have enough information to validate a block. Thus, block gossip provided by the `eth` network protocol will become unsafe and is deprecated in favour of the block gossip existing in the beacon chain network. + +It is recommended for the client software to not propagate descendants of any terminal PoW block to reduce the load on processing the P2P component and stop operating in the environment with unknown security properties. + +## Test Cases +*TBD* + +## Reference Implementation +*TBD* + + +## Backwards Compatibility + +This EIP introduces backward incompatibilities in block validity, block rewards and fork choice rule. + +The design of the consensus upgrade specified by this document does not introduce backward incompatibilities for existing applications and services built on top of Ethereum except for those that are described in the [EVM](#EVM) section below or heavily depends on the PoW consensus in any other way. + + +### EVM + +Although this EIP does not introduce any explicit changes to the EVM there are a couple of places where it may affect the logic of existing smart contracts. + +#### DIFFICULTY + +`DIFFICULTY` operation will always return `0` after this EIP takes effect and deprecates the **`difficulty`** field by replacing it with `0` constant. + +*Note:* Altering the `DIFFICULTY` semantics to return randomness accumulated by the beacon chain is under consideration but will be introduced in a separate EIP. + +#### BLOCKHASH + +Pseudo-random numbers obtained as the output of `BLOCKHASH` operation become more insecure after this EIP takes effect and the PoW mechanism (which decreases the malleability of block hashes) gets supplanted by PoS. + + +## Security Considerations + +### Beacon chain + +See Security Considerations section of [EIP-2982](/EIPS/eip-2982#security-considerations). + + +### Transition process + +The transition process used to take this specification into effect is a more sophisticated version of a hardfork -- the regular procedure of applying backwards incompatible changes in the Ethereum network. This process has multiple successive steps instead of the normal block-height point condition of simpler hardforks. + +The complexity of this upgrade process stems from this fork targeting the underlying consensus mechanism rather than the application layer within the consensus mechanism. Although the design seeks simplicity where possible, safety and liveness considerations during this transition have been prioritized. + +#### Terminal total difficulty vs block number + +Using a pre-defined block number for the hardfork is unsafe in this context due to the PoS fork choice taking priority during the transition. + +An attacker may use a minority of hash power to build a malicious chain fork that would satisfy the block height requirement. Then the first PoS block may be maliciously proposed on top of the PoW block from this adversarial fork, becoming the head and subverting the security of the transition. + +To protect the network from this attack scenario, difficulty accumulated by the chain (total difficulty) is used to trigger the upgrade. + +#### Ability to jump between terminal PoW blocks + +There could be the case when a terminal PoW block is not observed by the majority of network participants due to (temporal) network partitioning. In such a case, this minority would switch their fork choice to the new rule provided by the PoS rooted on the minority terminal PoW block that they observed. + +The transition process allows the network to re-org between forks with different terminal PoW blocks as long as (a) these blocks satisfy the terminal PoW block conditions and (b) a `POS_BLOCK_FINALIZED` has not yet been received. This provides resilience against adverse network conditions during the transition process and prevents irreparable forks/partitions. + +#### Halt the importing of PoW blocks + +Suppose the part of the client software that is connected to the beacon chain network goes offline before the Ethereum network reaches the `TERMINAL_TOTAL_DIFFICULTY` and stays offline while the network meets this threshold. Such an event makes the client software unable to switch to PoS and allows it to keep following the PoW chain if this chain is being built beyond the terminal PoW block. Depending on how long the beacon chain part was offline, it could result in different adverse effects such as: +* The client has no post-state for the terminal PoW block (the state has been pruned) which prevents it from doing the re-org to the PoS chain and leaving syncing from scratch as the only option to recover. +* An application, a user or a service uses the data from the wrong fork (PoW chain that is kept being built) which can cause security issues on their side. + +Not importing PoW blocks that are beyond the terminal PoW block prevents these adverse effects on safety/re-orgs in the event of software or configuration failures *in favor* of a liveness failure. + +### Further threat analysis +_TBD_ + + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From e6f0de5cda52d9acfdf6f86416c4205495b7a30a Mon Sep 17 00:00:00 2001 From: Mikhail Kalinin Date: Thu, 22 Jul 2021 21:14:57 +0600 Subject: [PATCH 02/15] Add discussions-to URL --- EIPS/eip-3675.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-3675.md b/EIPS/eip-3675.md index 0c5933ffa7782..0125758f437e1 100644 --- a/EIPS/eip-3675.md +++ b/EIPS/eip-3675.md @@ -2,7 +2,7 @@ eip: 3675 title: Upgrade consensus to Proof-of-Stake author: Mikhail Kalinin (@mkalinin), Danny Ryan (@djrtwo), Vitalik Buterin (@vbuterin) -discussions-to: +discussions-to: https://ethereum-magicians.org/t/eip-3675-upgrade-consensus-to-proof-of-stake/6706 status: Draft type: Standards Track category: Core From bf7e6616ffd4a5f36f66c15e824753560bdc9964 Mon Sep 17 00:00:00 2001 From: Mikhail Kalinin Date: Fri, 23 Jul 2021 18:58:34 +0600 Subject: [PATCH 03/15] Add a note on other message handlers --- EIPS/eip-3675.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/EIPS/eip-3675.md b/EIPS/eip-3675.md index 0125758f437e1..25f242cd2b5b9 100644 --- a/EIPS/eip-3675.md +++ b/EIPS/eip-3675.md @@ -123,6 +123,8 @@ Beginning with the first `POS_BLOCK_FINALIZED` event, the networking stack **MUS * [`NewBlockHashes (0x01)`](https://github.com/ethereum/devp2p/blob/master/caps/eth.md#newblockhashes-0x01) * [`NewBlock (0x07)`](https://github.com/ethereum/devp2p/blob/master/caps/eth.md#newblock-0x07) +*Note:* The logic of message handlers that are not affected by this section **MUST** remain unchanged. + ## Rationale From a428ab463b69f4adf708f2c488bc4bfea4c5ee95 Mon Sep 17 00:00:00 2001 From: Mikhail Kalinin Date: Fri, 23 Jul 2021 19:00:49 +0600 Subject: [PATCH 04/15] Fix grammar and spelling Co-authored-by: Jorge Olivero Co-authored-by: terence tsao --- EIPS/eip-3675.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-3675.md b/EIPS/eip-3675.md index 25f242cd2b5b9..cba3135461247 100644 --- a/EIPS/eip-3675.md +++ b/EIPS/eip-3675.md @@ -27,7 +27,7 @@ This document specifies the set of changes to the block structure, block process The beacon chain network has been up and running since December 2020. Neither safety nor liveness failures were detected during this period of time. The long period of running without failures demonstrates sustainability of the beacon chain system and witnesses its readiness to start driving and become a security provider for the Ethereum Mainnet. -To understand the motivation of introducing the Proof-of-Stake consensus see Motivation section of [EIP-2982](/EIPS/eip-2982#motivation). +To understand the motivation of introducing the Proof-of-Stake consensus see the Motivation section of [EIP-2982](/EIPS/eip-2982#motivation). ## Specification @@ -48,7 +48,7 @@ There can be more than one terminal PoW block in the network, e.g. multiple chil #### PoS events -Events having the `POS_` prefix in the name (PoS events) are emitted by the new proof-of-stake consensus mechanism. They signify the corresponding assertion that has been made regarding a block specified by the event. The underlying logic of PoS events can be found in the beacon chain specification. On the occurence of each PoS event the corresponding action that is specified by this EIP **MUST** be taken. +Events having the `POS_` prefix in the name (PoS events) are emitted by the new proof-of-stake consensus mechanism. They signify the corresponding assertion that has been made regarding a block specified by the event. The underlying logic of PoS events can be found in the beacon chain specification. On the occurrence of each PoS event the corresponding action that is specified by this EIP **MUST** be taken. Each `POS_BLOCK_FINALIZED` event has a reference to the head of the canonical chain in addition to the finalized block and incorporates the semantics of the `POS_CHAINHEAD_SET` event. Thus, every action and effect that is specified on the occurrence of `POS_CHAINHEAD_SET` event according to this EIP **MUST** also be taken on every occurrence of `POS_BLOCK_FINALIZED` event. From 41cba2d328bf778136eaa3aaf0f27abee1613ee6 Mon Sep 17 00:00:00 2001 From: Mikhail Kalinin Date: Mon, 26 Jul 2021 15:21:04 +0600 Subject: [PATCH 05/15] Apply more grammar fixes after the review Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com> --- EIPS/eip-3675.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-3675.md b/EIPS/eip-3675.md index cba3135461247..9dce41ab0888e 100644 --- a/EIPS/eip-3675.md +++ b/EIPS/eip-3675.md @@ -20,12 +20,12 @@ Specification of the consensus mechanism upgrade on Ethereum Mainnet that introd This EIP deprecates Proof-of-Work (PoW) and supersedes it with the new Proof-of-Stake consensus mechanism (PoS) driven by the beacon chain. Information on the bootstrapping of the new consensus mechanism is documented in [EIP-2982](/EIPS/eip-2982). Full specification of the beacon chain can be found in [eth2.0-specs](https://github.com/ethereum/eth2.0-specs/) repository. -This document specifies the set of changes to the block structure, block processing, the fork choice rule and the network interface introduced by the consensus upgrade. +This document specifies the set of changes to the block structure, block processing, fork choice rule and network interface introduced by the consensus upgrade. ## Motivation -The beacon chain network has been up and running since December 2020. Neither safety nor liveness failures were detected during this period of time. The long period of running without failures demonstrates sustainability of the beacon chain system and witnesses its readiness to start driving and become a security provider for the Ethereum Mainnet. +The beacon chain network has been up and running since December 2020. Neither safety nor liveness failures were detected during this period of time. This long period of running without failure demonstrates the sustainability of the beacon chain system and its readiness to become a security provider for the Ethereum Mainnet. To understand the motivation of introducing the Proof-of-Stake consensus see the Motivation section of [EIP-2982](/EIPS/eip-2982#motivation). @@ -130,7 +130,7 @@ Beginning with the first `POS_BLOCK_FINALIZED` event, the networking stack **MUS The changes specified in this EIP target a minimal requisite set of consensus and client software modifications to safely replace the existing proof-of-work consensus algorithm with the new proof-of-stake consensus represented by the already in-production beacon chain. -Minimalism in this changeset was chosen to reduce the complexity of the unprecedented task of hot-swapping the live consensus of the Ethereum network in order both to increase the safety of the operation and to reduce the time to production. Additionally, a minimal changeset helps ensure that *most* smart contracts and services will continue to function as intended during and after the transition with little to no required intervention. +This EIP was designed to minimize the complexity of hot-swapping the live consensus of the Ethereum network. Both the safety of the operation and time to production were taken into consideration. Additionally, a minimal changeset helps ensure that *most* smart contracts and services will continue to function as intended during and after the transition with little to no required intervention. ### Total difficulty triggering the upgrade From de9fcf2a334d0aba79e4c1748906b31aa030156d Mon Sep 17 00:00:00 2001 From: Mikhail Kalinin Date: Mon, 26 Jul 2021 15:07:33 +0600 Subject: [PATCH 06/15] Remove 'requires: 2982' from header --- EIPS/eip-3675.md | 1 - 1 file changed, 1 deletion(-) diff --git a/EIPS/eip-3675.md b/EIPS/eip-3675.md index 9dce41ab0888e..90f1156845b9f 100644 --- a/EIPS/eip-3675.md +++ b/EIPS/eip-3675.md @@ -7,7 +7,6 @@ status: Draft type: Standards Track category: Core created: 2021-07-22 -requires: 2982 --- From 4fdc2ddd42473d225814134bc94ad48115a81bdb Mon Sep 17 00:00:00 2001 From: Mikhail Kalinin Date: Mon, 26 Jul 2021 15:11:31 +0600 Subject: [PATCH 07/15] Fix links to the external EIP --- EIPS/eip-3675.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-3675.md b/EIPS/eip-3675.md index 90f1156845b9f..c388d541a1bba 100644 --- a/EIPS/eip-3675.md +++ b/EIPS/eip-3675.md @@ -17,7 +17,7 @@ Specification of the consensus mechanism upgrade on Ethereum Mainnet that introd ## Abstract -This EIP deprecates Proof-of-Work (PoW) and supersedes it with the new Proof-of-Stake consensus mechanism (PoS) driven by the beacon chain. Information on the bootstrapping of the new consensus mechanism is documented in [EIP-2982](/EIPS/eip-2982). Full specification of the beacon chain can be found in [eth2.0-specs](https://github.com/ethereum/eth2.0-specs/) repository. +This EIP deprecates Proof-of-Work (PoW) and supersedes it with the new Proof-of-Stake consensus mechanism (PoS) driven by the beacon chain. Information on the bootstrapping of the new consensus mechanism is documented in [EIP-2982](./eip-2982.md). Full specification of the beacon chain can be found in [eth2.0-specs](https://github.com/ethereum/eth2.0-specs/) repository. This document specifies the set of changes to the block structure, block processing, fork choice rule and network interface introduced by the consensus upgrade. @@ -26,7 +26,7 @@ This document specifies the set of changes to the block structure, block process The beacon chain network has been up and running since December 2020. Neither safety nor liveness failures were detected during this period of time. This long period of running without failure demonstrates the sustainability of the beacon chain system and its readiness to become a security provider for the Ethereum Mainnet. -To understand the motivation of introducing the Proof-of-Stake consensus see the Motivation section of [EIP-2982](/EIPS/eip-2982#motivation). +To understand the motivation of introducing the Proof-of-Stake consensus see the Motivation section of [EIP-2982](./eip-2982.md#motivation). ## Specification @@ -206,7 +206,7 @@ Pseudo-random numbers obtained as the output of `BLOCKHASH` operation become mor ### Beacon chain -See Security Considerations section of [EIP-2982](/EIPS/eip-2982#security-considerations). +See Security Considerations section of [EIP-2982](./eip-2982.md#security-considerations). ### Transition process From eca306f29b27eeb551f44ec89c6b11fd7ef2bf0c Mon Sep 17 00:00:00 2001 From: Mikhail Kalinin Date: Mon, 26 Jul 2021 15:13:10 +0600 Subject: [PATCH 08/15] Set extraData value to 0x80 --- EIPS/eip-3675.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-3675.md b/EIPS/eip-3675.md index c388d541a1bba..305ece4853758 100644 --- a/EIPS/eip-3675.md +++ b/EIPS/eip-3675.md @@ -65,7 +65,7 @@ Beginning with `TRANSITION_BLOCK`, a number of previously dynamic block fields a |-|-| | **`ommersHash`** | `Keccak256(RLP(EMPTY_LIST))` | | **`difficulty`** | `0` | -| **`extraData`** | `EMPTY_LIST` | +| **`extraData`** | `0x80` | | **`mixHash`** | `0x0000000000000000000000000000000000000000000000000000000000000000` | | **`nonce`** | `0x0000000000000000` | | **`ommers`** | `EMPTY_LIST` | From 3caf6949b7dfc4b7262261a777bf18bc171ed98a Mon Sep 17 00:00:00 2001 From: Mikhail Kalinin Date: Mon, 26 Jul 2021 15:22:25 +0600 Subject: [PATCH 09/15] Apply a tiny grammar fix --- EIPS/eip-3675.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-3675.md b/EIPS/eip-3675.md index 305ece4853758..77d0d0af5dc0b 100644 --- a/EIPS/eip-3675.md +++ b/EIPS/eip-3675.md @@ -17,7 +17,7 @@ Specification of the consensus mechanism upgrade on Ethereum Mainnet that introd ## Abstract -This EIP deprecates Proof-of-Work (PoW) and supersedes it with the new Proof-of-Stake consensus mechanism (PoS) driven by the beacon chain. Information on the bootstrapping of the new consensus mechanism is documented in [EIP-2982](./eip-2982.md). Full specification of the beacon chain can be found in [eth2.0-specs](https://github.com/ethereum/eth2.0-specs/) repository. +This EIP deprecates Proof-of-Work (PoW) and supersedes it with the new Proof-of-Stake consensus mechanism (PoS) driven by the beacon chain. Information on the bootstrapping of the new consensus mechanism is documented in [EIP-2982](./eip-2982.md). Full specification of the beacon chain can be found in the [eth2.0-specs](https://github.com/ethereum/eth2.0-specs/) repository. This document specifies the set of changes to the block structure, block processing, fork choice rule and network interface introduced by the consensus upgrade. From a8dd00eeff5de6765084872ad30f45dcafcbcad9 Mon Sep 17 00:00:00 2001 From: Mikhail Kalinin Date: Mon, 26 Jul 2021 15:27:58 +0600 Subject: [PATCH 10/15] Add SHOULD disconnect peers requirement --- EIPS/eip-3675.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/EIPS/eip-3675.md b/EIPS/eip-3675.md index 77d0d0af5dc0b..ebd69c8c629c9 100644 --- a/EIPS/eip-3675.md +++ b/EIPS/eip-3675.md @@ -122,6 +122,8 @@ Beginning with the first `POS_BLOCK_FINALIZED` event, the networking stack **MUS * [`NewBlockHashes (0x01)`](https://github.com/ethereum/devp2p/blob/master/caps/eth.md#newblockhashes-0x01) * [`NewBlock (0x07)`](https://github.com/ethereum/devp2p/blob/master/caps/eth.md#newblock-0x07) +Beginning with the first `POS_BLOCK_FINALIZED` event, the networking stack **SHOULD** disconnect peers sending [`NewBlockHashes (0x01)`](https://github.com/ethereum/devp2p/blob/master/caps/eth.md#newblockhashes-0x01) and [`NewBlock (0x07)`](https://github.com/ethereum/devp2p/blob/master/caps/eth.md#newblock-0x07) messages. + *Note:* The logic of message handlers that are not affected by this section **MUST** remain unchanged. From 208d979db0a71fc6142083a66affd4df92faf93f Mon Sep 17 00:00:00 2001 From: Mikhail Kalinin Date: Wed, 28 Jul 2021 15:15:52 +0600 Subject: [PATCH 11/15] Simplify disconnect peers statement --- EIPS/eip-3675.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-3675.md b/EIPS/eip-3675.md index ebd69c8c629c9..f13a1a5a562c8 100644 --- a/EIPS/eip-3675.md +++ b/EIPS/eip-3675.md @@ -122,7 +122,7 @@ Beginning with the first `POS_BLOCK_FINALIZED` event, the networking stack **MUS * [`NewBlockHashes (0x01)`](https://github.com/ethereum/devp2p/blob/master/caps/eth.md#newblockhashes-0x01) * [`NewBlock (0x07)`](https://github.com/ethereum/devp2p/blob/master/caps/eth.md#newblock-0x07) -Beginning with the first `POS_BLOCK_FINALIZED` event, the networking stack **SHOULD** disconnect peers sending [`NewBlockHashes (0x01)`](https://github.com/ethereum/devp2p/blob/master/caps/eth.md#newblockhashes-0x01) and [`NewBlock (0x07)`](https://github.com/ethereum/devp2p/blob/master/caps/eth.md#newblock-0x07) messages. +Beginning with the first `POS_BLOCK_FINALIZED` event, peers that keep sending these messages **SHOULD** be disconnected. *Note:* The logic of message handlers that are not affected by this section **MUST** remain unchanged. From 55cba8bf2a1c34130f3d4e247726c14953d5104d Mon Sep 17 00:00:00 2001 From: Mikhail Kalinin Date: Wed, 28 Jul 2021 15:50:01 +0600 Subject: [PATCH 12/15] Give a note on why block format matters --- EIPS/eip-3675.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/EIPS/eip-3675.md b/EIPS/eip-3675.md index f13a1a5a562c8..1a047b80ba1d0 100644 --- a/EIPS/eip-3675.md +++ b/EIPS/eip-3675.md @@ -145,6 +145,8 @@ See [Security considerations](#Halt-the-importing-of-PoW-blocks). Deprecated block fields are replaced with constant values to ensure the block format remains backwards compatible. Preserving the block format aids existing smart contracts and services in providing uninterrupted service during and after this transition. +Particularly, this is important for those smart contracts that verify Merkle proofs of transaction/receipt inclusion and state by validating the hash of externally provided block header string against the corresponding value returned by the `BLOCKHASH` operation. + This change introduces an additional validity rule that enforces the replacement of deprecated block fields. ### Replacing `difficulty` with `0` From d439f37416cd018a2bc547badcb24d4822d87139 Mon Sep 17 00:00:00 2001 From: Mikhail Kalinin Date: Wed, 28 Jul 2021 16:29:43 +0600 Subject: [PATCH 13/15] Add verbosity to the deprecated fields table --- EIPS/eip-3675.md | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/EIPS/eip-3675.md b/EIPS/eip-3675.md index 1a047b80ba1d0..ebeb61b8edca7 100644 --- a/EIPS/eip-3675.md +++ b/EIPS/eip-3675.md @@ -61,16 +61,14 @@ PoW blocks that are descendants of any terminal PoW block **MUST NOT** be import Beginning with `TRANSITION_BLOCK`, a number of previously dynamic block fields are deprecated by enforcing these values to instead be constants. Each block field listed in the table below **MUST** be replaced with the corresponding constant value. -| Field | Constant value | -|-|-| -| **`ommersHash`** | `Keccak256(RLP(EMPTY_LIST))` | -| **`difficulty`** | `0` | -| **`extraData`** | `0x80` | -| **`mixHash`** | `0x0000000000000000000000000000000000000000000000000000000000000000` | -| **`nonce`** | `0x0000000000000000` | -| **`ommers`** | `EMPTY_LIST` | - -*Note*: `EMPTY_LIST` denotes `[]` respecting the semantics of the corresponding field. +| Field | Constant value | Comment | +|-|-|-| +| **`ommersHash`** | `0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347` | `= Keccak256(RLP([]))` | +| **`difficulty`** | `0` | | +| **`extraData`** | `b''` | `RLP(b'') = 0x80` | +| **`mixHash`** | `0x0000000000000000000000000000000000000000000000000000000000000000` | | +| **`nonce`** | `0x0000000000000000` | | +| **`ommers`** | `[]` | `RLP([]) = 0xc0` | *Note*: Logic and validity conditions of block fields that are *not* specified here **MUST** remain unchanged. Additionally, the overall block format **MUST** remain unchanged. From 32e056c97b4bee62e9e4ea9b1e9c3f8d2454370a Mon Sep 17 00:00:00 2001 From: Mikhail Kalinin Date: Wed, 28 Jul 2021 19:22:56 +0600 Subject: [PATCH 14/15] Decapitalize anchors --- EIPS/eip-3675.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-3675.md b/EIPS/eip-3675.md index ebeb61b8edca7..d496433751b6d 100644 --- a/EIPS/eip-3675.md +++ b/EIPS/eip-3675.md @@ -79,7 +79,7 @@ Beginning with `TRANSITION_BLOCK`, the block validity conditions **MUST** be alt * Remove verification of the block's **`difficulty`** value with respect to the difficulty formula. * Remove verification of the block's **`nonce`** and **`mixHash`** values with respect to the Ethash function. * Remove all validation rules that are evaluated over the list of ommers and each member of this list, except for enforcing this list to be empty. -* Add verification of the fields noted in [block structure](#Block-structure) as their specified constant value, including the enforcement of empty ommers list. +* Add verification of the fields noted in [block structure](#block-structure) as their specified constant value, including the enforcement of empty ommers list. * Add verification of block validity with respect to the PoS consensus rules, i.e. assert that there **MUST** be a corresponding event for the block to consider it valid. Such events are limited to the following: * A `POS_CONSENSUS_VALIDATED` event considering the block or any of its descendants as valid. * A `POS_CHAINHEAD_SET` event, including the `POS_BLOCK_FINALIZED` form of this event, designating the block or any of its descendants as the head of the canonical chain. @@ -133,11 +133,11 @@ This EIP was designed to minimize the complexity of hot-swapping the live consen ### Total difficulty triggering the upgrade -See [Security considerations](#Terminal-total-difficulty-vs-block-number). +See [Security considerations](#terminal-total-difficulty-vs-block-number). ### Halting the import of PoW blocks -See [Security considerations](#Halt-the-importing-of-PoW-blocks). +See [Security considerations](#halt-the-importing-of-PoW-blocks). ### Replacing block fields with constants @@ -186,7 +186,7 @@ It is recommended for the client software to not propagate descendants of any te This EIP introduces backward incompatibilities in block validity, block rewards and fork choice rule. -The design of the consensus upgrade specified by this document does not introduce backward incompatibilities for existing applications and services built on top of Ethereum except for those that are described in the [EVM](#EVM) section below or heavily depends on the PoW consensus in any other way. +The design of the consensus upgrade specified by this document does not introduce backward incompatibilities for existing applications and services built on top of Ethereum except for those that are described in the [EVM](#evm) section below or heavily depends on the PoW consensus in any other way. ### EVM From 7bf827255510b95ffc0b2c8f02ce53e51d6cec2f Mon Sep 17 00:00:00 2001 From: Mikhail Kalinin Date: Thu, 29 Jul 2021 12:57:59 +0600 Subject: [PATCH 15/15] Fix one more buggy anchor --- EIPS/eip-3675.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-3675.md b/EIPS/eip-3675.md index d496433751b6d..fe38317326d5d 100644 --- a/EIPS/eip-3675.md +++ b/EIPS/eip-3675.md @@ -137,7 +137,7 @@ See [Security considerations](#terminal-total-difficulty-vs-block-number). ### Halting the import of PoW blocks -See [Security considerations](#halt-the-importing-of-PoW-blocks). +See [Security considerations](#halt-the-importing-of-pow-blocks). ### Replacing block fields with constants