Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EIP-4788: Beacon state root in EVM #4788

Merged
merged 2 commits into from Feb 17, 2022

Conversation

ralexstokes
Copy link
Member

@ralexstokes ralexstokes commented Feb 11, 2022

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
Copy link
Collaborator

eth-bot commented Feb 11, 2022

All tests passed; auto-merging...

(pass) eip-4788.md

classification
updateEIP
  • passed!

@vbuterin
Copy link
Contributor

vbuterin commented Feb 11, 2022

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
Copy link
Contributor

mcdee commented Feb 11, 2022

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
lightclient previously requested changes Feb 11, 2022
Copy link
Member

@lightclient lightclient left a comment

gm

EIPS/eip-beacon_state_root_in_evm.md Outdated Show resolved Hide resolved
EIPS/eip-beacon_state_root_in_evm.md Outdated Show resolved Hide resolved
EIPS/eip-beacon_state_root_in_evm.md Outdated Show resolved Hide resolved
EIPS/eip-beacon_state_root_in_evm.md Outdated Show resolved Hide resolved

## Abstract

Commit to the state root of the beacon chain in the `ommers` field in the post-merge execution block. Reflect the changes in the `ommersHash` field of the execution block header.
Copy link
Contributor

@MicahZoltu MicahZoltu Feb 12, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

MicahZoltu commented Feb 12, 2022

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
Copy link
Member Author

ralexstokes commented Feb 13, 2022

@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
Copy link
Member Author

ralexstokes commented Feb 13, 2022

@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
Copy link
Member Author

ralexstokes commented Feb 13, 2022

@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?

@ralexstokes ralexstokes force-pushed the beacon-state-root-in-evm branch 2 times, most recently from c65626b to 459342e Compare Feb 13, 2022
@ralexstokes ralexstokes force-pushed the beacon-state-root-in-evm branch from 459342e to 8809ca0 Compare Feb 13, 2022
@ralexstokes ralexstokes changed the title Beacon state root in EVM EIP-4788: Beacon state root in EVM Feb 13, 2022
@MicahZoltu
Copy link
Contributor

MicahZoltu commented Feb 14, 2022

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
Copy link
Contributor

MicahZoltu commented Feb 14, 2022

CI blocked on:

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

Copy link
Contributor

@MicahZoltu MicahZoltu left a comment

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


Beginning at the execution timestamp `FORK_TIMESTAMP`, execution clients **MUST**:

1. set the value of the `ommers` field in the block to an RLP list with one element: the 32 byte [hash tree root](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md#merkleization) of the [beacon state](https://github.com/ethereum/consensus-specs/blob/dev/specs/bellatrix/beacon-chain.md#beaconstate) from the previous slot to this block.
Copy link
Contributor

@MicahZoltu MicahZoltu Feb 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)?

## Test Cases

TODO

## Reference Implementation

TODO

Copy link
Contributor

@MicahZoltu MicahZoltu Feb 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
## Test Cases
TODO
## Reference Implementation
TODO

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

@MicahZoltu MicahZoltu dismissed lightclient’s stale review Feb 14, 2022

Feedback addressed.

@eth-bot eth-bot enabled auto-merge (squash) Feb 14, 2022
EIPS/eip-4788.md Outdated Show resolved Hide resolved
@eth-bot eth-bot merged commit 844f115 into ethereum:master Feb 17, 2022
5 checks passed
@jambestwick
Copy link

jambestwick commented Feb 18, 2022

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

PowerStream3604 pushed a commit to PowerStream3604/EIPs that referenced this pull request May 19, 2022
* Add EIP for beacon state root in EVM

* fix typo

Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com>
@ralexstokes ralexstokes deleted the beacon-state-root-in-evm branch Aug 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants