Part 3: Annotated Specification

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 type ExecutionState
• a notification function self.notify_new_payload which may apply changes to the self.execution_state

Note: notify_new_payload is a function accessed through the EXECUTION_ENGINE module which instantiates the ExecutionEngine 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.