You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adopt EIP-7688: Forward compatible consensus data structures
EIP-4788 exposes the beacon root to smart contracts, but smart contracts
using it need to be redeployed / upgraded whenever the indexing changes
during a fork, even if that fork does not touch any used functionality.
This problem expands further to bridges on other blockchains, or even
into wallet apps on a phone that verify data from the beacon chain
instead of trusting the server. It is quite unrealistic to expect such
projects to all align their release cadence with Ethereum's forks.
EIP-7688 fixes this by defining forward compatibility for beacon chain
data structures. Electra `Profile` retain their Merkleization even when
rebased to `StableContainer` definitions from future forks, enabling
decentralized protocols to drop the requirement for trusted parties to
periodically upgrade beacon state proof verifiers.
@@ -175,12 +178,34 @@ class SignedExecutionPayloadEnvelope(Container):
175
178
176
179
### Modified containers
177
180
178
-
#### `BeaconBlockBody`
181
+
#### `StableBeaconBlockBody`
179
182
180
183
**Note:** The Beacon Block body is modified to contain a `Signed ExecutionPayloadHeader`. The containers `BeaconBlock` and `SignedBeaconBlock` are modified indirectly. The field `execution_requests` is removed from the beacon block body and moved into the signed execution payload envelope.
**Note:** The `ExecutionPayloadHeader` is modified to only contain the block hash of the committed `ExecutionPayload` in addition to the builder's payment information, gas limit and KZG commitments root to verify the inclusion proofs.
latest_block_hash: Optional[Hash32] # [New in EIP-7732]
316
+
latest_full_slot: Optional[Slot] # [New in EIP-7732]
317
+
latest_withdrawals_root: Optional[Root] # [New in EIP-7732]
318
+
```
319
+
220
320
#### `BeaconState`
221
321
222
322
*Note*: The `BeaconState` is modified to track the last withdrawals honored in the CL. The `latest_execution_payload_header` is modified semantically to refer not to a past committed `ExecutionPayload` but instead it corresponds to the state's slot builder's bid. Another addition is to track the last committed block hash and the last slot that was full, that is in which there were both consensus and execution blocks included.
0 commit comments