status-im
/
eth2.0-specs
mirror of https://github.com/status-im/eth2.0-specs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Polish the description of execution engine functions

This commit is contained in:
Mikhail Kalinin 2021-09-22 18:10:57 +06:00
parent 8cecf405cb
commit 06107ce7d8
3 changed files with 16 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
specs/merge/beacon-chain.md
View File

@ -242,9 +242,14 @@ The implementation-dependent `ExecutionEngine` protocol encapsulates the executi
* a state object `self.execution_state` of type `ExecutionState` * a state object `self.execution_state` of type `ExecutionState`
* a state transition function `self.execute_payload` which applies changes to the `self.execution_state` * a state transition function `self.execute_payload` which applies changes to the `self.execution_state`
* a method `self.consensus_validated` which signals that the beacon block containing the execution payload * a function `self.consensus_validated` which signals that the beacon block containing the execution payload
is valid with respect to the consensus rule set is valid with respect to the consensus rule set
*Note*: `execute_payload` and `consensus_validated` are functions accessed through the `EXECUTION_ENGINE` module which instantiates the `ExecutionEngine` protocol.
The body of each of these functions is implementation dependent.
The Engine API may be used to implement them with an external execution engine.
#### `execute_payload` #### `execute_payload`
```python ```python
@ -262,11 +267,6 @@ def consensus_validated(self: ExecutionEngine, execution_payload: ExecutionPaylo
... ...
``` ```
The above functions are accessed through the `EXECUTION_ENGINE` module which instantiates the `ExecutionEngine` protocol.
The body of each of these functions is implementation dependent.
The Engine API may be used to implement them with an external execution engine.
### Block processing ### Block processing
*Note*: The call to the `process_execution_payload` must happen before the call to the `process_randao` as the former depends on the `randao_mix` computed with the reveal of the previous block. *Note*: The call to the `process_execution_payload` must happen before the call to the `process_randao` as the former depends on the `randao_mix` computed with the reveal of the previous block.

10
specs/merge/fork-choice.md
View File

@ -31,11 +31,14 @@ This is the modification of the fork choice according to the executable beacon c
### `ExecutionEngine` ### `ExecutionEngine`
The following methods are added to the `ExecutionEngine` protocol for use in the fork choice: *Note*: The `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.
#### `forkchoice_updated` #### `forkchoice_updated`
This method performs two actions *atomically*: This function performs two actions *atomically*:
* Re-organizes the execution payload chain and corresponding state to make `head_block_hash` the head. * Re-organizes the execution payload chain and corresponding state to make `head_block_hash` the head.
* Applies finality to the execution state: it irreversibly persists the chain of all execution payloads * 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`. and corresponding state, up to and including `finalized_block_hash`.
@ -45,9 +48,6 @@ def forkchoice_updated(self: ExecutionEngine, head_block_hash: Hash32, finalized
... ...
``` ```
The body of this function is implementation dependent.
The Engine API may be used to implement this with an external execution engine.
## Helpers ## Helpers
### `PowBlock` ### `PowBlock`

10
specs/merge/validator.md
View File

@ -38,7 +38,10 @@ Please see related Beacon Chain doc before continuing and use them as a referenc
### `ExecutionEngine` ### `ExecutionEngine`
The following methods are added to the `ExecutionEngine` protocol for use as a validator: *Note*: `prepare_payload` and `get_payload` functions are added to the `ExecutionEngine` protocol for use as a validator.
The body of each of these functions is implementation dependent.
The Engine API may be used to implement them with an external execution engine.
#### `prepare_payload` #### `prepare_payload`
@ -70,9 +73,6 @@ def get_payload(self: ExecutionEngine, payload_id: uint64) -> ExecutionPayload:
... ...
``` ```
The body of each of these functions is implementation dependent.
The Engine API may be used to implement them with an external execution engine.
## Beacon chain responsibilities ## Beacon chain responsibilities
All validator responsibilities remain unchanged other than those noted below. Namely, the transition block handling and the addition of `ExecutionPayload`. All validator responsibilities remain unchanged other than those noted below. Namely, the transition block handling and the addition of `ExecutionPayload`.
@ -134,4 +134,4 @@ def get_execution_payload(payload_id: Optional[uint64], execution_engine: Execut
``` ```
*Note*: It is recommended for a validator to call `prepare_execution_payload` as soon as input parameters become known, *Note*: It is recommended for a validator to call `prepare_execution_payload` as soon as input parameters become known,
and make subsequent calls to this function if any of these parameters has been updated. and make subsequent calls to this function when any of these parameters gets updated.