EIP-4788: Beacon state root in EVM

[ralexstokes]

Expose the beacon state root in the EVM by including it in each execution block and introduce an opcode to facilitate reading the roots.

[eth-bot]

All tests passed; auto-merging...

(pass) eip-4788.md

classification
updateEIP

• passed!

[vbuterin]

I would still favor using the slot number and not the block number, and copying the most recent block hash into multiple slots if there are skips the same way as the consensus chain history accumulator does it (see the process_slot function).

Reasons:

1. Block numbers are an execution-layer concept; they have no meaning in the consensus layer. Using the block number for this would introduce the concept of "the beacon block at execution block # N", which doesn't exist today. So using execution block numbers as an index of the beacon block would hurt layer separation.
2. Using the block number would also mean that we would have two accumulators of historical beacon blocks that work differently, whereas using slot number means that the accumulators work the same way, increasing cleanness (and potentially opening the door to eventually getting rid of one of those accumulators at some point in the future).
3. Slot numbers are more useful than block numbers, because they correspond directly to time. If you want something like "tell me the state at 00:00 GMT on Jan 1, 2023", then slot numbers are the only thing you could use (unless you incur the logarithmic overhead and complexity of a binary search).

I don't think the extra complexity of having an SSTORE loop is that large; it's a simple loop, and the beacon chain already does it.

[mcdee]

If I'm reading it correctly, it appears that ommersHash will be a 32-byte hash of the RLP encoding of a single-element list of the 32-byte beacon state root. I get the idea that you can continue to calculate ommersHash from ommers, but does this feature need to be retained? Is altering the block structure and/or validation logic that much of an issue that it needs to be avoided at all costs?

[lightclient]

gm

[MicahZoltu]

Recommend referring to these fields by their position, since the names are meaningless (especially post-merge since it is just a fixed value). You could say something like "in position x, which formerly held the ommersHash".

[MicahZoltu]

There is no discussions-to URL yet so posting this comment here:
I strongly advocate for block root rather than state root. There is value in being able to prove block data such as historic RANDAOs.

[ralexstokes]

@mcdee

If I'm reading it correctly, it appears that ommersHash will be a 32-byte hash of the RLP encoding of a single-element list of the 32-byte beacon state root. I get the idea that you can continue to calculate ommersHash from ommers, but does this feature need to be retained? Is altering the block structure and/or validation logic that much of an issue that it needs to be avoided at all costs?

The primary goal here is to get the beacon accumulator into the execution block header (or at least committed to there). Execution clients already have this functionality to include ommer headers (and commit to them via the ommersHash).

This EIP suggests to reuse this machinery as it can simply be used as is, without having to introduce further development and testing requirements for client developers going into Shanghai (that already has a number of EIPS already competing for scarce developer attention).

There are a couple of alternatives if we don't want to go this route:

1. Retain the EIP-3675 behavior that the ommers part of the execution block is empty. Repurpose the ommersHash as the beaconStateRoot field. The state root is available now via the header. The downside is that if we need to include further data into the execution block we will no longer have a variable length portion of the block to take advantage of. The route this EIP suggests leaves open the possibility that we can place further info into the deprecated ommers field if needed.

2. Leave the ommers alone entirely per the EIP-3675 functionality and add an entirely new field to the block header. As per my understanding, there is some desire to not disturb the block header for reasons of backwards compatibility (although we already added the EIP-1559 base fee during the London upgrade so this point is weakened some).

I want to get client developer input on this point to see what the appetite is for the various options.

[ralexstokes]

@vbuterin

I don't think the extra complexity of having an SSTORE loop is that large; it's a simple loop, and the beacon chain already does it.

I agree with all of your reasoning -- the concern is efficient reads and writes in the case where we have many skipped slots. Unlikely to happen on mainnet, but we should still consider worst case behavior. Will think this over some more...

[ralexstokes]

@MicahZoltu

There is no discussions-to URL yet so posting this comment here:

updated! https://ethereum-magicians.org/t/eip-4788-beacon-state-root-in-evm/8281

feel free to migrate this there if you want :)

I strongly advocate for block root rather than state root. There is value in being able to prove block data such as historic RANDAOs.

we could go either way here -- the important context is that all of the block roots are committed to in the beacon state (so only a few extra hashes in a merkle proof to go from state root to any block root) and so it is fairly easy to e.g. prove some RANDAO value in a block via the state root.

the opposite also holds: each block has its state root, so we could just as easily use the block root and then (with a few extra hashes) reach the state root and then prove anything in the state we wanted...

my personal feeling is that there is more in the state that a user would want to make proofs against (e.g. finalized or justified blocks for light client-esque bridges) and so we should favor that use case more (by requiring fewer hashes to process in a proof) -- knowing this do you still see a case for block roots?

[MicahZoltu]

we could go either way here -- the important context is that all of the block roots are committed to in the beacon state (so only a few extra hashes in a merkle proof to go from state root to any block root) and so it is fairly easy to e.g. prove some RANDAO value in a block via the state root.

the opposite also holds: each block has its state root, so we could just as easily use the block root and then (with a few extra hashes) reach the state root and then prove anything in the state we wanted...

my personal feeling is that there is more in the state that a user would want to make proofs against (e.g. finalized or justified blocks for light client-esque bridges) and so we should favor that use case more (by requiring fewer hashes to process in a proof) -- knowing this do you still see a case for block roots?

This would be a good bit of text to put in the Rationale. Nevermind, looks like this is already present and I just missed it.

[MicahZoltu]

CI blocked on:

./EIPS/eip-4788.md:55: committment ==> commitment

[MicahZoltu]

No blockers, but recommend applying or commenting on the remaining feedback.

[MicahZoltu]

These should link to specific commit hashes rather than files in a dev branch. Also, are these not available in the primary consensus spec yet (hence why you are linking to dev rather than main/master)?

[MicahZoltu]

Suggested change

	## Test Cases
	TODO
	## Reference Implementation
	TODO

These sections are optional, recommend just removing them until you have something useful to include.

Feedback addressed.

[jambestwick]

There is no discussions-to URL yet so posting this comment here: I strongly advocate for block root rather than state root. There is value in being able to prove block data such as historic RANDAOs.

agreeed