Conversation
| block_hash: Hash32 # Hash of execution block | ||
| transactions: List[Transaction, MAX_TRANSACTIONS_PER_PAYLOAD] | ||
| withdrawals: List[Withdrawal, MAX_WITHDRAWALS_PER_PAYLOAD] | ||
| parent_beacon_block_root: Root # [New in EIP-4788] |
There was a problem hiding this comment.
I am curious if we can avoid extension of ExecutionPayload with parent_beacon_block_root on CL side and simply put its value into ExecutionPayloadV3 structure in the Engine API directly from a beacon block?
There was a problem hiding this comment.
This would imply a synchronous CL<>EL processing which given the way EL sync works, we have to assume some modes EL is syncing on it's own with head-info from CL
There was a problem hiding this comment.
This field should be a part of EL header, what we can try to do is to avoid this information to be duplicated on CL side, i.e. CL can read it from beacon_block.parent_root and pass to EL in Engine API calls
djrtwo
left a comment
djrtwo
left a comment
There was a problem hiding this comment.
Looks good!
nice and simple. testing should be simple as well
| block_hash: Hash32 # Hash of execution block | ||
| transactions: List[Transaction, MAX_TRANSACTIONS_PER_PAYLOAD] | ||
| withdrawals: List[Withdrawal, MAX_WITHDRAWALS_PER_PAYLOAD] | ||
| parent_beacon_block_root: Root # [New in EIP-4788] |
There was a problem hiding this comment.
This would imply a synchronous CL<>EL processing which given the way EL sync works, we have to assume some modes EL is syncing on it's own with head-info from CL
djrtwo
left a comment
djrtwo
left a comment
There was a problem hiding this comment.
will add tests in a separate pr
4 participants
Beacon block root in the EVM
also relevant: ethereum/EIPs#6859