eth2.0-specs/specs/merge/validator.md

110 lines
4.5 KiB
Markdown
Raw Normal View History

# Ethereum 2.0 The Merge
2021-03-11 12:33:36 +00:00
**Warning:** This document is currently based on [Phase 0](../phase0/validator.md) but will be rebased to [Altair](../altair/validator.md) once the latter is shipped.
2021-03-17 16:39:35 +00:00
2021-03-11 12:33:36 +00:00
**Notice**: This document is a work-in-progress for researchers and implementers.
## Table of contents
<!-- TOC -->
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
- [Introduction](#introduction)
- [Prerequisites](#prerequisites)
2021-05-10 13:48:37 +00:00
- [Protocols](#protocols)
- [`ExecutionEngine`](#executionengine)
- [`assemble_block`](#assemble_block)
2021-03-11 12:33:36 +00:00
- [Beacon chain responsibilities](#beacon-chain-responsibilities)
- [Block proposal](#block-proposal)
- [Constructing the `BeaconBlockBody`](#constructing-the-beaconblockbody)
- [Execution Payload](#execution-payload)
2021-03-11 12:33:36 +00:00
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
<!-- /TOC -->
## Introduction
This document represents the changes to be made in the code of an "honest validator" to implement executable beacon chain proposal.
## Prerequisites
This document is an extension of the [Phase 0 -- Validator](../phase0/validator.md). All behaviors and definitions defined in the Phase 0 doc carry over unless explicitly noted or overridden.
All terminology, constants, functions, and protocol mechanics defined in the updated Beacon Chain doc of [The Merge](./beacon-chain.md) are requisite for this document and used throughout. Please see related Beacon Chain doc before continuing and use them as a reference throughout.
2021-05-10 13:48:37 +00:00
## Protocols
### `ExecutionEngine`
The following methods are added to the `ExecutionEngine` protocol for use as a validator:
#### `assemble_block`
Produces a new instance of an execution payload, with the specified `timestamp`,
on top of the execution payload chain tip identified by `block_hash`.
2021-05-10 13:48:37 +00:00
The body of this function is implementation dependent.
The Consensus API may be used to implement this with an external execution engine.
```python
def assemble_block(self: ExecutionEngine, block_hash: Hash32, timestamp: uint64, random: Bytes32) -> ExecutionPayload:
2021-05-10 13:48:37 +00:00
...
```
2021-03-11 12:33:36 +00:00
## Beacon chain responsibilities
All validator responsibilities remain unchanged other than those noted below. Namely, the transition block handling and the addition of `ExecutionPayload`.
2021-03-11 12:33:36 +00:00
### Block proposal
#### Constructing the `BeaconBlockBody`
##### Execution Payload
2021-03-11 12:33:36 +00:00
* Set `block.body.execution_payload = get_execution_payload(state, transition_store, execution_engine, pow_chain)` where:
2021-03-11 12:33:36 +00:00
```python
2021-07-20 11:37:52 +00:00
def get_pow_block_at_total_difficulty(total_difficulty: uint256, pow_chain: Sequence[PowBlock]) -> Optional[PowBlock]:
# `pow_chain` abstractly represents all blocks in the PoW chain
for block in pow_chain:
parent = get_pow_block(block.parent_hash)
if block.total_difficulty >= total_difficulty and parent.total_difficulty < total_difficulty:
return block
return None
2021-03-11 12:33:36 +00:00
2021-06-11 10:05:19 +00:00
def compute_randao_mix(state: BeaconState, randao_reveal: BLSSignature) -> Bytes32:
epoch = get_current_epoch(state)
return xor(get_randao_mix(state, epoch), hash(randao_reveal))
def produce_execution_payload(state: BeaconState,
parent_hash: Hash32,
randao_reveal: BLSSignature,
execution_engine: ExecutionEngine) -> ExecutionPayload:
timestamp = compute_timestamp_at_slot(state, state.slot)
randao_mix = compute_randao_mix(state, randao_reveal)
return execution_engine.assemble_block(parent_hash, timestamp, randao_mix)
2021-06-11 10:05:19 +00:00
2021-06-01 11:44:58 +00:00
def get_execution_payload(state: BeaconState,
transition_store: TransitionStore,
2021-06-11 10:05:19 +00:00
randao_reveal: BLSSignature,
execution_engine: ExecutionEngine,
pow_chain: Sequence[PowBlock]) -> ExecutionPayload:
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
if not is_merge_complete(state):
terminal_pow_block = get_pow_block_at_total_difficulty(transition_store.transition_total_difficulty, pow_chain)
if terminal_pow_block is None:
# Pre-merge, empty payload
return ExecutionPayload()
else:
# Signify merge via producing on top of the last PoW block
return produce_execution_payload(state, terminal_pow_block.block_hash, randao_reveal, execution_engine)
# Post-merge, normal payload
2021-06-11 10:05:19 +00:00
parent_hash = state.latest_execution_payload_header.block_hash
2021-06-15 08:55:06 +00:00
return produce_execution_payload(state, parent_hash, randao_reveal, execution_engine)
2021-03-11 12:33:36 +00:00
```