diff --git a/EIPS/eip-9999.md b/EIPS/eip-9999.md index dbbaaffd3035b..0e3b632bb5bb1 100644 --- a/EIPS/eip-9999.md +++ b/EIPS/eip-9999.md @@ -18,11 +18,11 @@ This EIP fundamentally changes the way an Ethereum block is validated by decoupl This EIP solves a different set of unrelated important problems. -- An overwhelming majority of beacon block proposers outsource the construction of the execution payload within their blocks to a third party (henceforth called a *builder*). In order to do so, they request the hash tree root (HTR) of a promised execution payload and submit a `SignedBlindedBeaconBlock` to a trusted party that is tasked with replacing the HTR with the full execution payload (received from the builder) before broadcasting. This EIP allows for a trust-free direct communication between the beacon block proposer and the builder, guaranteeing that an honest beacon block proposer will receive payment from the builder regardless of the latter actions and that the honest builder's payload will be the canonical head of the chain regardless of the proposer's action. -- Currently, validators have the time between receiving the full beacon block (including an execution payload) and the attesting deadline (4 seconds in Ethereum mainnet) to perform both consensus and execution state transition functions, check blob data availability and evaluate the new head of the blockchain. The remainder of the slot time is spent during less CPU-intense and critical task. By separating the validation of the execution and consensus part of the block, validators are only tasked to perform the consensus state transition function in this critical time before attesting, while execution and data availability validation is deferred for most of the remainder of the slot (between the builder's reveal time and the next attestation deadline). +- An overwhelming majority of beacon block proposers outsource the construction of the execution payload within their blocks to a third party (henceforth called a *builder*). In order to do so, they request the hash tree root (HTR) of a promised execution payload and submit a `SignedBlindedBeaconBlock` to a trusted party that is tasked with replacing the HTR with the full execution payload (received from the builder) before broadcasting. This EIP allows for a trust-free fair exchange between the beacon block proposer and the builder, guaranteeing that an honest beacon block proposer will receive payment from the builder regardless of the latter's actions and that the honest builder's payload will be the canonical head of the chain regardless of the proposer's action. +- Currently, validators have the time between receiving the full beacon block (including an execution payload) and the attesting deadline (4 seconds in Ethereum mainnet) to perform both consensus and execution state transition functions, check blob data availability and evaluate the new head of the blockchain. The remainder of the slot time is spent doing less CPU-intense and critical task. By separating the validation of the execution and consensus part of the block, validators are only tasked to perform the consensus state transition function in this critical time before attesting, while execution and data availability validation is deferred for most of the remainder of the slot (between the builder's reveal time and the next attestation deadline). - By removing the full execution payload size from the consensus block, it allows for faster network propagation on the critical path. -- It removes the increased reorg likeliness of including blob transactions in blocks. -- It prevents validators from missing attestations and strengthens the LMD weight properties of forkchoice in the event that builders produce invalid payloads. +- It removes the increased reorg likeliness of including blob transactions in blocks given the natural increase in timelines for DA availability checks and the fact that the builder may broadcast the blob sidecars even before attestations for the beacon block have been released. +- It prevents validators from missing attestations and strengthens the LMD weight properties of fork choice in the event that builders produce invalid payloads. - It removes the need of using middleware, not maintained by core developers, used by the vast majority of validators and it removes the need from client teams to continue supporting such middleware, improving thus coordination efforts for testing and deploying future hard forks. ## Specification @@ -35,7 +35,7 @@ No changes are required. The full consensus changes can be found the consensus-specs Github repository. They are separated in - [Beacon Chain](https://github.com/ethereum/consensus-specs/blob/345e95504275d6c44b2bc251c50cb230fefb71b5/specs/_features/epbs/beacon-chain.md) changes -- [Forkchoice](https://github.com/ethereum/consensus-specs/blob/345e95504275d6c44b2bc251c50cb230fefb71b5/specs/_features/epbs/fork-choice.md) changes +- [Fork choice](https://github.com/ethereum/consensus-specs/blob/345e95504275d6c44b2bc251c50cb230fefb71b5/specs/_features/epbs/fork-choice.md) changes - [P2P](https://github.com/ethereum/consensus-specs/blob/345e95504275d6c44b2bc251c50cb230fefb71b5/specs/_features/epbs/fork-choice.md) changes - [Honest validator guide](https://github.com/ethereum/consensus-specs/blob/345e95504275d6c44b2bc251c50cb230fefb71b5/specs/_features/epbs/fork-choice.md) changes - A new [honest builder](https://github.com/ethereum/consensus-specs/blob/345e95504275d6c44b2bc251c50cb230fefb71b5/specs/_features/epbs/builder.md) guide. @@ -130,7 +130,7 @@ State transition logic is modified by: - A new `process_payload_attestation` is added to `process_operations`, this function validates the payload timeliness attestations broadcast by the PTC members. - `process_execution_payload` is now called as a separate helper when receiving a `SignedExecutionPayloadEnvelope` on the P2P layer. This function in particular checks that the HTR of the resulting beacon state coincides with the committed one in the payload envelope. -Forkchoice changes include: +Fork choice changes include: #### Constants @@ -187,22 +187,22 @@ Being a builder is a new attribution of validators. As such builders are staked The Payload Timeliness Committee members do not need to validate the execution payload before attesting to it. They perform basic checks like verifying the builder's signature and the correct blockhash is included. This takes away the full execution payload validation from the hot path of validation of an Ethereum block, giving the next proposer 6 seconds (`SECONDS_PER_SLOT * 2 // INTERVALS_PER_SLOT`) to validate the payload and every other validator 9 seconds (`SECONDS_PER_SLOT * 3 // INTERVALS_PER_SLOT`). A tradeoff from the user experience point of view is that transactions have a longer delay into being confirmed on-chain as validly included. -### (Block, Slot, Payload) - Forkchoice +### (Block, Slot, Payload) - Fork choice -The following features of forkchoice are guaranteed under specified margins of security: +The following features of fork choice are guaranteed under specified margins of security: -- Proposer unconditional payment -- Builder reveal safety -- Builder withhold safety. +- Proposer unconditional payment. +- Builder reveal safety. +- Builder withhold safety. -Proposer unconditional payment refers to the following. An Ethereum slot can be either +Proposer unconditional payment refers to the following. An Ethereum slot can be either: - *Full*: both the beacon block and the execution payload have been revealed and included on-chain - *Skipped*: No beacon block (and therefore no execution payload) has been included on-chain for this slot. - *Empty*: The beacon block has been included on-chain, but the committed execution payload has not. Proposer unconditional payment refers to the fact that in the third scenario the beacon block proposer received payment from the corresponding builder. -Builder reveal safety refers to the fact that if the builder acted honestly and revealed a payload in a timely fashion (as attested by the PTC) then the revealed payload will be included on-chain. This is enforced by the addition of a new `BUILDER_REVEAL_BOOST` to the LMD weight of the forkchoice node that contains the payload. +Builder reveal safety refers to the fact that if the builder acted honestly and revealed a payload in a timely fashion (as attested by the PTC) then the revealed payload will be included on-chain. This is enforced by the addition of a new `BUILDER_REVEAL_BOOST` to the LMD weight of the fork choice node that contains the payload. Builder withhold safety refers to the fact that if some beacon block containing a builder's commitment is withheld and revealed late, then that beacon block root **will not** be the canonical head of the blockchain in the view of honest validators. @@ -229,11 +229,11 @@ This EIP is fully compatible with forward inclusion lists as specified in [EIP-7 #### Slot auctions -A simple change to this EIP is to remove the blockhash commitment from the `SignedExecutionPayloadHeader`. This allows the builder to commit any payload to the slot. A preliminary security analysis shows that payload equivocation does not weaken forkchoice's FFG. Some advantages of Slot auctions include: +A simple change to this EIP is to remove the blockhash commitment from the `SignedExecutionPayloadHeader`. This allows the builder to commit any payload to the slot. A preliminary security analysis shows that payload equivocation does not weaken fork choice's FFG. Some advantages of Slot auctions include: - Better user experience as any submitted transaction can be included in the next block (with block auctions a transaction sent in the first half of the slot can only be included in the following block). - Longer continuous time to build blocks. -- Better compatibility designs with forkchoice enforced inclusion list proposals. +- Better compatibility designs with fork choice enforced inclusion list proposals. ## Backwards Compatibility @@ -244,12 +244,12 @@ This EIP introduces backward incompatible changes to the block validation rule s ### Reorg resistance -`PROPOSER_SCORE_BOOST` is reduced from 40 to 20. This does not allow however a en-anti reorg by a proposer with 20% of the total stake as the attacker's payload will also be not included. Proposers are protected against *1-slot sandwich* reorgs by a colluding set of validators and builders controlling more than 20% of the total stake +`PROPOSER_SCORE_BOOST` is reduced from 40 to 20. This does not allow however a ex-ante reorg by a proposer with 20% of the total stake as the attacker's payload will also not be included. Proposers are protected against *1-slot sandwich* reorgs by a colluding set of validators and builders controlling more than 20% of the total stake ### Builder safety - A colluding set of proposers and attesters controlling consecutive blocks and more than 20% of the total stake can reorg a builder's payload and force it to pay the bid's value. -- There is no possible *unbundling* of the builder's payload, that is, if the builder reveals a payload for the head of the chain, no other payload is possible for the current slot. +- There is no possible *unbundling* of the builder's payload in the same slot, that is, if the builder reveals a payload for the head of the chain, no other payload is possible for the current slot. ### Malicious PTC