Bellatrix -- Fork Choice¶
- Introduction
- Types
- Protocols
ExecutionEngine- Helpers
PayloadAttributesPowBlockget_pow_blockis_valid_terminal_pow_blockvalidate_merge_block- Handlers
on_block
Introduction¶
This is the modification of the fork choice according to the executable beacon chain proposal.
Unless stated explicitly, all prior functionality from Altair is inherited.
Note: It introduces the process of transition from the last PoW block to the first PoS block.
Types¶
| Name | SSZ equivalent | Description |
|---|---|---|
PayloadId |
Bytes8 |
Identifier of a payload building process |
Protocols¶
ExecutionEngine¶
Note: The notify_forkchoice_updated function is added to the
ExecutionEngine protocol to signal the fork choice updates.
The body of this function is implementation dependent. The Engine API may be used to implement it with an external execution engine.
notify_forkchoice_updated¶
This function performs three actions atomically:
- Re-organizes the execution payload chain and corresponding state to make
head_block_hashthe head. - Updates safe block hash with the value provided by
safe_block_hashparameter. - Applies finality to the execution state: it irreversibly persists the chain of
all execution payloads and corresponding state, up to and including
finalized_block_hash.
Additionally, if payload_attributes is provided, this function sets in motion
a payload build process on top of head_block_hash and returns an identifier of
initiated process.
Note: The (head_block_hash, finalized_block_hash) values of the
notify_forkchoice_updated function call maps on the POS_FORKCHOICE_UPDATED
event defined in the
EIP-3675. As per
EIP-3675, before a post-transition block is finalized,
notify_forkchoice_updated MUST be called with
finalized_block_hash = Hash32().
Note: Client software MUST NOT call this function until the transition
conditions are met on the PoW network, i.e. there exists a block for which
is_valid_terminal_pow_block function returns True.
Note: Client software MUST call this function to initiate the payload build
process to produce the merge transition block; the head_block_hash parameter
MUST be set to the hash of a terminal PoW block in this case.
safe_block_hash¶
The safe_block_hash parameter MUST be set to return value of
get_safe_execution_block_hash(store: Store)
function.
should_override_forkchoice_update¶
If proposer boost re-orgs are implemented and enabled (see get_proposer_head)
then additional care must be taken to ensure that the proposer is able to build
an execution payload.
If a beacon node knows it will propose the next block then it SHOULD NOT call
notify_forkchoice_updated if it detects the current head to be weak and
potentially capable of being re-orged. Complete information for evaluating
get_proposer_head will not be available immediately after the receipt of a
new block, so an approximation of those conditions should be used when deciding
whether to send or suppress a fork choice notification. The exact conditions
used may be implementation-specific, a suggested implementation is below.
Let validator_is_connected(validator_index: ValidatorIndex) -> bool be a
function that indicates whether the validator with validator_index is
connected to the node (e.g. has sent an unexpired proposer preparation message).
Note: The ordering of conditions is a suggestion only. Implementations are
free to optimize by re-ordering the conditions from least to most expensive and
by returning early if any of the early conditions are False.
In case should_override_forkchoice_update returns True, a node SHOULD
instead call notify_forkchoice_updated with parameters appropriate for
building upon the parent block. Care must be taken to compute the correct
payload_attributes, as they may change depending on the slot of the block to
be proposed (due to withdrawals).
If should_override_forkchoice_update returns True but get_proposer_head
later chooses the canonical head rather than its parent, then this is a
misprediction that will cause the node to construct a payload with less notice.
The result of get_proposer_head MUST be preferred over the result of
should_override_forkchoice_update (when proposer reorgs are enabled).
Helpers¶
PayloadAttributes¶
Used to signal to initiate the payload build process via
notify_forkchoice_updated.
PowBlock¶
get_pow_block¶
Let get_pow_block(block_hash: Hash32) -> Optional[PowBlock] be the function
that given the hash of the PoW block returns its data. It may result in None
if the requested block is not yet available.
Note: The eth_getBlockByHash JSON-RPC method may be used to pull this
information from an execution client.
is_valid_terminal_pow_block¶
Used by fork-choice handler, on_block.
validate_merge_block¶
Handlers¶
on_block¶
Note: The only modification is the addition of the verification of transition block conditions.