Part 3: Annotated Specification
Beacon Chain State Transition Function
Execution engine
Ethereum's "Merge" to proof of stake occurred on the 15th of September 2022. As far as the beacon chain was concerned, the most significant change was that an extra block validity condition now applies. Post-Merge Beacon blocks contain a new ExecutionPayload
object which is basically an Eth1 block. For the beacon block to be valid, the contents of its execution payload must be valid according to Ethereum's longstanding block and transaction execution rules (minus any proof of work conditions).
The beacon chain does not know how to validate Ethereum transactions. The entire point of the Merge was to enable beacon chain clients to hand off the validation of the execution payload to a locally connected execution client (formerly an Eth1 client). The beacon chain consensus client does this hand-off via the notify_new_payload()
function described below.
Architecturally, the notify_new_payload()
function is accessed via a new interface called the Engine API which the Bellatrix specification characterises as follows.
The implementation-dependent
ExecutionEngine
protocol encapsulates the execution sub-system logic via:
- a state object
self.execution_state
of typeExecutionState
- a notification function
self.notify_new_payload
which may apply changes to theself.execution_state
Note:
notify_new_payload
is a function accessed through theEXECUTION_ENGINE
module which instantiates theExecutionEngine
protocol.The body of this function is implementation dependent. The Engine API may be used to implement this and similarly defined functions via an external execution engine.
notify_new_payload
def notify_new_payload(self: ExecutionEngine, execution_payload: ExecutionPayload) -> bool:
"""
Return ``True`` if and only if ``execution_payload`` is valid with respect to ``self.execution_state``.
"""
...
This function is called during block processing to verify the validity of a beacon block's execution payload. The contents of the execution payload are largely opaque to the consensus layer (hence the ...
in the function definition) and validation of the execution payload relies almost entirely on the execution client. You can think of it as just an external black-box library call if that helps.
Used by | process_execution_payload() |