Currently ethereum BeaconState tracks
HistoricalStateRoots for last
SLOTS_PER_HISTORICAL_ROOT period and accumulate them in
HistoricalSummaries upon completion of every period.
This proposal extends the similar tracking and accumulation to the execution payload’s
- With this one would be able to easily prove if a particular execution state/block was part of canonical chain represented by the BeaconBlock/BeaconState.
- Additionally this could help stateless (or rather chainless) EL execution by providing last 256 roots in
newPayload block executions for resolving
There could be additional benefits from (2.) for the Verkle fork where having stateful pre-compiles (which require free “system” update on each block to the state) could pose risks from some DoS vectors
the proof would be a bit longer but you can get to both
stateRoot in the execution payload header from any
HistoricalSummary so I don’t see the need to lift these into the state as explicit data
right thats possible, but it also allows to seed these values to the EL client via newPayloads without requiring them written into the EL state which is quite relevant for VKT (so 4788 is also a problem see this: EIP-4788: Beacon root in EVM - #42 by ihagopian)
Tangential thought that in the context of Verkle, if we end up going with the “get blockhash from CL” to implement the
BLOCKHASH opcode, we probably would need to revisit the gas cost associated with
BLOCKHASH (currently at
20). Intuitively, getting the data from a data structure living on the CL sounds more like an “SLOAD-like” operation. The historically cheap cost of
BLOCKHASH seems to assume that clients are continually storing the last 256 blockhashes in a stateful and easy-to-access cache, which won’t hold in the context of verkle stateless clients.
the right way to implement would be for new payload to carry last 256 hashes, so EL doesn’t need to fetch anything from CL, and these hashes should be readily available (similarly for beacon block root corresponding to 4788)
It’s worth considering the case of syncing a fresh archive execution node here. The consensus node can still start from recent finalized state but the execution node would do a full sync instead of a snap sync to catch up. In this situation the execution node would be executing transactions from block arbitrarily older than the earliest state the consensus node has. If the EL needs to retrieve the root for
BLOCKROOT from the consensus node then the consensus state must include them all without the usual accumulator pattern.
but EL doing archive sync from genesis will have all the roots no?