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

Add aliases

This commit is contained in:
Paul Hauner 2022-01-28 09:45:08 +11:00
parent 020d72c756
commit cbbe6e744a
No known key found for this signature in database
GPG Key ID: 5E2CFF9B75FA63DF
1 changed files with 34 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

57
sync/optimistic.md
View File

@ -25,6 +25,17 @@ statelessness).
## Helpers
For brevity, we define two aliases for values of the `status` field on
`PayloadStatusV1`:
- Alias `NOT_VALIDATED` to:
- `SYNCING`
- `ACCEPTED`
- Alias `INVALIDATED` to:
- `INVALID`
- `INVALID_BLOCK_HASH`
- `INVALID_TERMINAL_BLOCK`
Let `head: BeaconBlock` be the result of calling of the fork choice
algorithm at the time of block production. Let `head_block_root: Root` be the
root of that block.
@ -34,8 +45,8 @@ BeaconState]` be the blocks (and accompanying states) that have been verified
either completely or optimistically.
Let `optimistic_roots: Set[Root]` be the set of `hash_tree_root(block)` for all
optimistically imported blocks which have only received a `SYNCING` designation
from an execution engine (i.e., they are not known to be `INVALID` or `VALID`).
optimistically imported blocks which have only received a `NOT_VALIDATED` designation
from an execution engine (i.e., they are not known to be `INVALIDATED` or `VALID`).
Let `current_slot: Slot` be `(time - genesis_time) // SECONDS_PER_SLOT` where
`time` is the UNIX time according to the local system clock.
@ -56,7 +67,7 @@ def is_optimistic(opt_store: OptimisticStore, block: BeaconBlock) -> bool:
```python
def latest_verified_ancestor(opt_store: OptimisticStore, block: BeaconBlock) -> BeaconBlock:
# It is assumed that the `block` parameter is never an INVALID block.
# It is assumed that the `block` parameter is never an INVALIDATED block.
while True:
if not is_optimistic(opt_store, block) or block.parent_root == Root():
return block
@ -104,35 +115,35 @@ these conditions.*
To optimistically import a block:
- The [`notify_new_payload`](../specs/bellatrix/beacon-chain.md#notify_new_payload) function MUST return `True` if the execution
engine returns `SYNCING`, `VALID`, or `ACCEPTED`. An `INVALID` or `INVALID_BLOCK_HASH` response MUST return `False`.
engine returns `NOT_VALIDATED` or `VALID`. An `INVALIDATED` response MUST return `False`.
- The [`validate_merge_block`](../specs/bellatrix/fork-choice.md#validate_merge_block)
function MUST NOT raise an assertion if both the
`pow_block` and `pow_parent` are unknown to the execution engine.
- All other assertions in [`validate_merge_block`](../specs/bellatrix/fork-choice.md#validate_merge_block)
(e.g., `TERMINAL_BLOCK_HASH`) MUST prevent an optimistic import.
- The parent of the block MUST NOT have an INVALID execution payload.
- The parent of the block MUST NOT have an `INVALIDATED` execution payload.
In addition to this change in validation, the consensus engine MUST track which
blocks returned `SYNCING` and which returned `VALID` for subsequent processing.
blocks returned `NOT_VALIDATED` and which returned `VALID` for subsequent processing.
Optimistically imported blocks MUST pass all verifications included in
`process_block` (withstanding the modifications to `notify_new_payload`).
A consensus engine MUST be able to retrospectively (i.e., after import) modify
the status of `SYNCING` blocks to be either `VALID` or `INVALID` based upon responses
the status of `NOT_VALIDATED` blocks to be either `VALID` or `INVALIDATED` based upon responses
from an execution engine. I.e., perform the following transitions:
- `SYNCING` -> `VALID`
- `SYNCING` -> `INVALID`
- `NOT_VALIDATED` -> `VALID`
- `NOT_VALIDATED` -> `INVALIDATED`
When a block transitions from `SYNCING` -> `VALID`, all *ancestors* of the
block MUST also transition from `SYNCING` -> `VALID`. Such a block and any previously `SYNCING` ancestors are no longer
When a block transitions from `NOT_VALIDATED` -> `VALID`, all *ancestors* of the
block MUST also transition from `NOT_VALIDATED` -> `VALID`. Such a block and any previously `NOT_VALIDATED` ancestors are no longer
considered "optimistically imported".
When a block transitions from `SYNCING` -> `INVALID`, all *descendants* of the
block MUST also transition from `SYNCING` -> `INVALID`.
When a block transitions from `NOT_VALIDATED` -> `INVALIDATED`, all *descendants* of the
block MUST also transition from `NOT_VALIDATED` -> `INVALIDATED`.
When a block transitions from the `SYNCING` state, it is removed from the set of
When a block transitions from the `NOT_VALIDATED` state, it is removed from the set of
`opt_store.optimistic_roots`.
When a "merge block" (i.e. the first block which enables execution in a chain) is declared to be
@ -141,7 +152,7 @@ When a "merge block" (i.e. the first block which enables execution in a chain) i
MUST be run against the merge block. If the block
fails [`validate_merge_block`](../specs/bellatrix/fork-choice.md#validate_merge_block),
the merge block MUST be treated the same as
an `INVALID` block (i.e., it and all its descendants are invalidated and
an `INVALIDATED` block (i.e., it and all its descendants are invalidated and
removed from the block tree).
### Execution Engine Errors
@ -155,11 +166,11 @@ validity request for some block, a consensus engine:
### Assumptions about Execution Engine Behaviour
This specification assumes execution engines will only return `SYNCING` when
there is insufficient information available to make a `VALID` or `INVALID`
This specification assumes execution engines will only return `NOT_VALIDATED` when
there is insufficient information available to make a `VALID` or `INVALIDATED`
determination on the given `ExecutionPayload` (e.g., the parent payload is
unknown). Specifically, `SYNCING` responses should be fork-specific, in that
the search for a block on one chain MUST NOT trigger a `SYNCING` response for
unknown). Specifically, `NOT_VALIDATED` responses should be fork-specific, in that
the search for a block on one chain MUST NOT trigger a `NOT_VALIDATED` response for
another chain.
### Re-Orgs
@ -167,16 +178,16 @@ another chain.
The consensus engine MUST support any chain reorganisation which does *not*
affect the justified checkpoint.
If the justified checkpoint transitions from `SYNCING` -> `INVALID`, a
If the justified checkpoint transitions from `NOT_VALIDATED` -> `INVALIDATED`, a
consensus engine MAY choose to alert the user and force the application to
exit.
## Fork Choice
Consensus engines MUST support removing blocks from fork choice that transition
from `SYNCING` to `INVALID`. Specifically, a block deemed `INVALID` at any
from `NOT_VALIDATED` to `INVALIDATED`. Specifically, a block deemed `INVALIDATED` at any
point MUST NOT be included in the canonical chain and the weights from those
`INVALID` blocks MUST NOT be applied to any `VALID` or `SYNCING` ancestors.
`INVALIDATED` blocks MUST NOT be applied to any `VALID` or `NOT_VALIDATED` ancestors.
### Fork Choice Poisoning
@ -333,7 +344,7 @@ unlikely attack increases or decreases our total risk. Presently, it appears
that `SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY` sits in a sweet spot for this
trade-off.
### Transitioning from VALID -> INVALID or INVALID -> VALID
### Transitioning from VALID -> INVALIDATED or INVALIDATED -> VALID
These operations are purposefully omitted. It is outside of the scope of the
specification since it's only possible with a faulty EE.