Conversation
djrtwo
left a comment
djrtwo
left a comment
There was a problem hiding this comment.
nice! a bit confused about Bytes32() in the helpers for randao reveal but otherwise, looking good
|
suggested polishing:
|
|
I'm okay with the suggested cleanups. Although it is an important design goal for execution layer to be parallelizable, I don't think the added param moves the needle too much on making that clear to the reader. I would suggest noting the parallelizability in the header comment (or pre-function text) of |
|
Thanks everyone for your inputs! I've accepted suggested polishing with related comment about |
4 participants
Adds the most recent
randao_mixinto execution payload.This PR is a follow up to the corresponding discussion that took place in Merge Implementers' Call 5.
The value of new
randaofield inExecutionPayloadmust be assigned todifficultyfield of derivedExecutionBlock. And furtherrandaovalue is exposed by theDIFFICULTYopcode in the EVM. This way allows to preserve randomness property of the value returned by this opcode. Potentially,DIFFICULTYopcode will be renamed toRANDAOand is one of the post-Merge cleanups.There two reasons whyrandaoshould be an explicit part of the payload:-ExecutionPayloadis the only input required to build correspondingExecutionBlock- further compatibility with stateless executionUPD
The main idea of this particular solution is to exclude EVM changes from the Merge scope. An implementation where
randaovalue is passed alongside with the payload and utilized by EVM context directly without requirement of being a part ofExecutionBlockcould be done after the Merge within other EVM changes.Should be rebased after #2472 gets merged