Rationale
Why should this feature exist?
The eth_simulateV1 API is the most advanced Geth simulation API but is missing core state transitions through BeaconRoot and Withdrawals support. If there is other ways to calculate the StateRoot and ReceiptsRoot without modifying Geth state, let me know!
What are the use-cases?
My usecase demands that I build execution blocks outside of the Geth block builder as I'm trying to hand craft blocks for testing the Engine API responses. For example, I want to hand craft an execution block with an invalid state transition to see how my Consensus Layer deals with the "INVALID_BLOCK" response from NewPayload.
The main blocker for this form of testing is calculating the StateRoot and ReceiptsRoot which requires access to EVM state to generate.
However, every CL will generally have at least a ParentBeaconRoot and often Withdrawals, both of which mutate the state resulting in a change of the StateRoot which is not captured in the eth_simulateV1 API.
Implementation
Do you have ideas regarding the implementation of this feature?
The ParentBeaconRoot handling is trivial to implement, as I've PoC'd this. Not sure about withdrawals but shouldn't be too bad - as long as the default consensus engine is Beacon, we don't need the Headerchain as that's unused.
This can be completely backwards compatible as its just new fields.
Are you willing to implement this feature?
Yea I can have a crack.
Rationale
Why should this feature exist?
The
eth_simulateV1API is the most advanced Geth simulation API but is missing core state transitions through BeaconRoot and Withdrawals support. If there is other ways to calculate the StateRoot and ReceiptsRoot without modifying Geth state, let me know!What are the use-cases?
My usecase demands that I build execution blocks outside of the Geth block builder as I'm trying to hand craft blocks for testing the Engine API responses. For example, I want to hand craft an execution block with an invalid state transition to see how my Consensus Layer deals with the "INVALID_BLOCK" response from
NewPayload.The main blocker for this form of testing is calculating the StateRoot and ReceiptsRoot which requires access to EVM state to generate.
However, every CL will generally have at least a ParentBeaconRoot and often Withdrawals, both of which mutate the state resulting in a change of the StateRoot which is not captured in the
eth_simulateV1API.Implementation
Do you have ideas regarding the implementation of this feature?
The ParentBeaconRoot handling is trivial to implement, as I've PoC'd this. Not sure about withdrawals but shouldn't be too bad - as long as the default consensus engine is Beacon, we don't need the Headerchain as that's unused.
This can be completely backwards compatible as its just new fields.
Are you willing to implement this feature?
Yea I can have a crack.