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

Merge pull request #2 from ethereum/build-opt-sync 

build opimistic sync file
This commit is contained in:
Paul Hauner 2022-01-21 09:50:02 +11:00 committed by GitHub
parent 50b236e5eb a5b3c91f25
commit b50bea86a0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 17 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
setup.py
View File

@ -868,6 +868,7 @@ class PySpecCommand(Command):
specs/bellatrix/fork.md
specs/bellatrix/fork-choice.md
specs/bellatrix/validator.md
sync/optimistic.md
"""
if len(self.md_doc_paths) == 0:
raise Exception('no markdown files specified, and spec fork "%s" is unknown', self.spec_fork)

23
sync/optimistic.md
View File

@ -1,7 +1,8 @@
# Optimistic Sync
[`validate_merge_block`]: ../specs/bellatrix/fork-choice.md#validate_merge_block
../specs/bellatrix/fork-choice.md#validate_merge_block
## Introduction
In order to provide a syncing execution engine with a partial view of the head
@ -66,7 +67,7 @@ def latest_verified_ancestor(opt_store: OptimisticStore, block: BeaconBlock) ->
```
```python
def is_execution_block(block: BeaconBlock) -> BeaconBlock:
def is_execution_block(block: BeaconBlock) -> bool:
return block.body.execution_payload != ExecutionPayload()
```
@ -107,9 +108,11 @@ To optimistically import a block:
- The [`execute_payload`](../specs/bellatrix/beacon-chain.md#execute_payload) function MUST return `True` if the execution
engine returns `SYNCING` or `VALID`. An `INVALID` response MUST return `False`.
- The [`validate_merge_block`][] function MUST NOT raise an assertion if both the
- 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`][] (e.g., `TERMINAL_BLOCK_HASH`) MUST prevent an optimistic import.
- 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.
In addition to this change in validation, the consensus engine MUST track which
@ -137,8 +140,10 @@ When a block transitions from the `SYNCING` state, it is removed from the set of
When a "merge block" (i.e. the first block which enables execution in a chain) is declared to be
`VALID` by an execution engine (either directly or indirectly), the full
[`validate_merge_block`][] MUST be run against the merge block. If the block
fails [`validate_merge_block`][], the merge block MUST be treated the same as
[`validate_merge_block`](../specs/bellatrix/fork-choice.md#validate_merge_block)
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
removed from the block tree).
@ -353,9 +358,11 @@ optimistic sync all together.
## What if `TERMINAL_BLOCK_HASH` is used?
If the terminal block hash override is used (i.e., `TERMINAL_BLOCK_HASH !=
Hash32()`), the [`validate_merge_block`][] function will deterministically
Hash32()`), the [`validate_merge_block`](../specs/bellatrix/fork-choice.md#validate_merge_block)
function will deterministically
return `True` or `False`. Whilst it's not *technically* required
retrospectively call [`validate_merge_block`][] on a transition block that
retrospectively call [`validate_merge_block`](../specs/bellatrix/fork-choice.md#validate_merge_block)
on a transition block that
matches `TERMINAL_BLOCK_HASH` after an optimistic sync, doing so will have no
effect. For simplicity, the optimistic sync specification does not define
edge-case behaviour for when `TERMINAL_BLOCK_HASH` is used.