Add EIP: Delayed Execution Layer State Root #9241
Conversation
github-actions
bot
added
c-new
File
|
eth-bot
added
e-consensus
eth-bot
changed the title
EIPS/eip-xxxx.md
Outdated
|
|
||
| The EL `state_root` must be computed by block builders (and verified by relays, validators, and light clients) in near-real-time. This computation accounts for a large fraction of block production and verification time, especially in an MEV-Boost environment. This overhead is also a challenge for efforts to enable real-time ZK proving of the chain. | ||
|
|
||
| By delaying the EL `state_root` reference by one block, we can remove EL `state_root` calculation overhead from the critical path of block production. Instead, clients can pipeline calculation of block `n-1`'s EL `state_root` during the idle slot time of block `n`. |
There was a problem hiding this comment.
idle slot time of block
n.
I think this is n-1. At n-1, the block arrives around the 4th second of the slot, you verify everything except the state root, and then you have 8 more seconds in n-1 to verify the state root
There was a problem hiding this comment.
I think in this design the EL clients are calculating the state root of block n-1 while building block n at the same time, and this process occurs during the last 8 seconds of block n-1. Is this correct?
There was a problem hiding this comment.
yea either change it to n-1 or it should read:
Instead, clients can pipeline calculation of block n's EL state_root during the idle slot time of block n.
EIPS/eip-xxxx.md
Outdated
| - The actual new state root resulting from block `n` will only appear in block `n+1`. | ||
| 3. **Proactive Computation of Post-state Root**: | ||
| - To fully realize latency benefits, clients should compute the post-state root of block `n-1` during the idle time of slot `n`. |
There was a problem hiding this comment.
during the idle time of slot
n.
Same. I think this would be n-1, not n
EIPS/eip-xxxx.md
Outdated
|
|
||
| By delaying the EL `state_root` reference by one block, we can remove EL `state_root` calculation overhead from the critical path of block production. Instead, clients can pipeline calculation of block `n-1`'s EL `state_root` during the idle slot time of block `n`. | ||
|
|
||
| This change will lower latency at the tip, allowing us to increase throughput and simplify the block production pipeline. It can also significantly accelerate the timeline real-time ZK proving Ethereum. |
There was a problem hiding this comment.
| This change will lower latency at the tip, allowing us to increase throughput and simplify the block production pipeline. It can also significantly accelerate the timeline real-time ZK proving Ethereum. | |
| This change will lower latency at the tip, allowing us to increase throughput and simplify the block production pipeline. It can also significantly accelerate the timeline of real-time ZK proving Ethereum. |
EIPS/eip-xxxx.md
Outdated
| bytes32 parentHash; | ||
| address feeRecipient; | ||
| ... | ||
| bytes32 stateRoot; // now references the post-state root of block (n-1) |
There was a problem hiding this comment.
| bytes32 stateRoot; // now references the post-state root of block (n-1) | |
| bytes32 stateRoot; // now references *this* block's pre-state i.e. the post-state root of block (n-1) |
just a suggestion for more clarity
EIPS/eip-xxxx.md
Outdated
|
|
||
| 1. **Reduce Latency at the Tip** | ||
| - Proposers and builders no longer must compute and finalize the new state root within the same slot. | ||
| - This speeds up block propagation, as peers can quickly validate the rest of the block without waiting on the state root calculation. |
There was a problem hiding this comment.
It doesn't actually speed up block propagation, because forwarding a block doesn't require fully verifying it, the main check is just the proposer's signature
EIPS/eip-xxxx.md
Outdated
| bytes32 parentHash; | ||
| address feeRecipient; | ||
| ... | ||
| bytes32 stateRoot; // now references the post-state root of block (n-1) |
There was a problem hiding this comment.
i have another Q:
since the block builders will have the stateroot because they can't include a tx before executing a previous one because of previous txs affecting any prestate of the tx, so why should we not include the stateroot in it
since the logs/requests etc are all dependent on the correct execution. Ofcourse the attesters can still do delayed verification.
may we we just add a block pre-stateroot field and use that for running verifications because proofs of correct execution results against this block might require this block's post stateroot and will be easy and fast check for whenever the block gets executed before next block arrives
There was a problem hiding this comment.
since the block builders will have the stateroot because they can't include a tx before executing a previous one because of previous txs affecting any prestate of the tx, so why should we not include the stateroot in it
They only need the state, not the state root.
Currently they'd need to compute the state root before completing the block building process. Now they don't need to compute it eagerly (they can do it async).
EIPS/eip-xxxx.md
Outdated
| # assert compute_state_root(transactions_of_block_n) == payload_n.stateRoot | ||
| # | ||
| # Now: | ||
| assert payload_n.stateRoot == post_state_of_block_n_minus_1 |
There was a problem hiding this comment.
Does this mean that if a future protocol upgrade changes EVM behavior, then nodes that did not upgrade would fork off the network with 1 block delay? (Though I don't think this is an issue.)
There was a problem hiding this comment.
I guess that is true only if the protocol change results in a mismatched state but doesn't change the execution flow of the transactions.
There was a problem hiding this comment.
Right, so for instance adding a new tx type could result in a fork exactly at the upgrade block.
But adding a new opcode or precompile, or changing the gas schedule, could result in a fork one block later.
|
The commit 8c717f3 (as a parent of a1fee73) contains errors. |
This EIP implements a delayed state root. It is ready for draft status and discussion.