Discussion thread for EIP-4788: Beacon state root in EVM.
By including the
ommersHashvalidation, clients can use existing code with only minimal changes (supplying the actual state root) during block production and verification.
Having the beacon state root value in the
ommersfield means that it is fairly straightforward to provide the value from the block data to the EVM execution context for client implementations as they stand today.
I would like to get validation from execution client teams that this is actually of meaningful value. It may be just as easy to completely remove the uncle validation code entirely as it would be to pseudo-replace it with this. If so, then I would strongly advocate for changing this into a single 32-byte hash rather than an array of 1 item.
Should the storage address be added to warm addresses by default (EIP 2929?)
Correct me if I am wrong but this should also have a rule that if you
CALL the storage address, this should not get removed from the state. I am pretty sure that accounts which have non-empty storage, but no code, nonce 0 and balance 0 are
DEAD and should therefore get removed from the MPT (thus clearing the storage). The alternative could be to just send 1 wei to this address, but it should be noted in the EIP anyways.
A couple of things:
Epoch/slot/timestamp as a fork trigger requires support of two EL blocks at the same height with different consensus rules and/or structures. AFAIK, this is not currently supported by client implementations and might result in additional complexity.
I am echoing Vitalik’s comment on slot vs block number. Imagine an application that securely (with a proof) reads validator record from a beacon state, an interface of this app will have to do slot to block height translation to specify the right beacon block root for the proof verification process. Using slot number allows to avoid this complexity, reads will look like
slot.validator(i).effective_balance. Though, this approach requires slots to be passed to EL block, perhaps slot numbers are suitable replacement for
For the reading of the value it would be possible to include code at the address, and require a
CALL to be made to the address as opposed to a dedicated opcode. This would be similar to EIP-210.
This does raise the question why not also do the same for
RANDAO(n) in EIP-4399: Supplant DIFFICULTY opcode with RANDOM.
IIUC, the two arguments are:
- Changing the shape of the block makes it easier to differentiate between blocks of different eras as you can just look at the block’s shape to know “when” the block was from.
- Changing the shape of the block can break existing code that depends on block shape to decode.
I think the question we need to answer is which of these is likely to have a larger negative impact on the Ethereum ecosystem long term. If (1), then adding a new field to the end and (optionally, if we want to save 32 bytes per block) deleting OmmersHash from the middle is the ideal strategy. If (2), then changing the interpretation of OmmersHash to be BeaconRoot is the optimal strategy.
This EIP is useful for liquid staking protocols that want to prove new balance updates for their validators and account fault with the highest security. Most LSDs rely on a small oracle committee to supply them this sort of information. In addition, there are tons of new applications that will be built given the trustless access to more detailed protocol parameters. Seems like a win. What are implementation barriers for this sort of thing?
there are many many many applications unlocked by this EIP
the implementation barriers are not really the blocking ones, the bigger issue is simply prioritizing this feature amongst all other things we want to do to make ethereum better
Agreed! What’s the process of getting this prioritized?
im happy to help you argue for it on ACD sooner or later
i can say that it will be hard to prioritize against validator withdrawals and work around 4844
and currently ACD is very focused on a successful merge so we haven’t really done any serious Shanghai planning and I’m not sure now is the right time.
perhaps we revisit after the merge has occurred?
Totally. Appreciate it. Thanks for the responses, excited for this
My understanding is that to be able to prove some value in the beacon state, we also need to know the generalised index of the property we wish to prove (or more generally the depth of the merkle tree representations of the objects in the path with which we can compute the generalised indices of properties).
It seems likely (and is already the case in Capella) that the consensus spec containers will be appended to in future forks and so the depth of their tree representation may increment and therefore all the generalised indices of the existing properties will change too.
The consequence of this is that any smart contract that verifies proofs will need some sort of upgradability to be forwards compatible with future changes to the beacon state object.
This seems to break some of the fundamental usefulness of having the state root available on the EVM because proof verification logic cannot be made immutable. Previously, we had to trust an oracle to submit the correct state about the beacon chain. Now, we have to trust the contract owner to upgrade the proof verification logic as required by future consensus spec changes.
Unless the proof verification logic was also made part of the EVM via a precompile or something.
Am I missing something?
This EIP requires changes to the consensus layer and engine API. Where should those be spec’ed? I recall EIP4844 having similar issues.