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

Tidy

This commit is contained in:
Paul Hauner 2021-12-20 10:32:45 +11:00
parent 26e934b1e1
commit da6cad8767
No known key found for this signature in database
GPG Key ID: 5E2CFF9B75FA63DF
1 changed files with 12 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
sync/optimistic.md
View File

@ -14,7 +14,7 @@ blocks without verifying the execution payloads. This partial sync is called an
|`SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY`| `96` | slots
*Note: the `SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY` must be user-configurable. See
[Failure Recovery](#failure-recovery).
[Fork Choice Poisoning](#fork-choice-poisoning).*
## Helpers
@ -64,6 +64,9 @@ conditions are met:
1. The current slot (as per the system clock) is at least `SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY` ahead of
the slot of the block being imported. I.e., `should_optimistically_import_block(current_slot) == True`.
*See [Fork Choice Poisoning](#fork-choice-poisoning) for the motivations behind
these conditions.*
## How to optimistically import blocks
To optimistically import a block:
@ -126,7 +129,14 @@ If the justified checkpoint transitions from `SYNCING` -> `INVALID`, a
consensus engine MAY choose to alert the user and force the application to
exit.
## Failure Recovery
## Fork Choice
Consensus engines MUST support removing from fork choice blocks that transition
from `SYNCING` to `INVALID`. Specifically, a block deemed `INVALID` 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.
### Fork Choice Poisoning
During the merge transition it is possible for an attacker to craft a
`BeaconBlock` with an execution payload that references an
@ -158,13 +168,6 @@ disaster recovery:
- `--safe_slots_to_import_optimistically`: modifies the
`SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY`.
## Fork Choice
Consensus engines MUST support removing from fork choice blocks that transition
from `SYNCING` to `INVALID`. Specifically, a block deemed `INVALID` 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.
## Checkpoint Sync (Weak Subjectivity Sync)
A consensus engine MAY assume that the `ExecutionPayload` of a block used for