build opimistic sync file and fix a minor lint/typing issue

This commit is contained in:
Danny Ryan 2022-01-20 09:25:02 -07:00
parent 50b236e5eb
commit a5b3c91f25
No known key found for this signature in database
GPG Key ID: 2765A792E42CE07A
2 changed files with 17 additions and 9 deletions

View File

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

View File

@ -1,7 +1,8 @@
# Optimistic Sync # Optimistic Sync
[`validate_merge_block`]: ../specs/bellatrix/fork-choice.md#validate_merge_block
../specs/bellatrix/fork-choice.md#validate_merge_block
## Introduction ## Introduction
In order to provide a syncing execution engine with a partial view of the head 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 ```python
def is_execution_block(block: BeaconBlock) -> BeaconBlock: def is_execution_block(block: BeaconBlock) -> bool:
return block.body.execution_payload != ExecutionPayload() return block.body.execution_payload != ExecutionPayload()
``` ```
@ -106,10 +107,12 @@ these conditions.*
To optimistically import a block: To optimistically import a block:
- The [`execute_payload`](../specs/bellatrix/beacon-chain.md#execute_payload) function MUST return `True` if the execution - 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`. 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. `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. - 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 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 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 `VALID` by an execution engine (either directly or indirectly), the full
[`validate_merge_block`][] MUST be run against the merge block. If the block [`validate_merge_block`](../specs/bellatrix/fork-choice.md#validate_merge_block)
fails [`validate_merge_block`][], the merge block MUST be treated the same as 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 `INVALID` block (i.e., it and all its descendants are invalidated and
removed from the block tree). removed from the block tree).
@ -353,9 +358,11 @@ optimistic sync all together.
## What if `TERMINAL_BLOCK_HASH` is used? ## What if `TERMINAL_BLOCK_HASH` is used?
If the terminal block hash override is used (i.e., `TERMINAL_BLOCK_HASH != 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 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 matches `TERMINAL_BLOCK_HASH` after an optimistic sync, doing so will have no
effect. For simplicity, the optimistic sync specification does not define effect. For simplicity, the optimistic sync specification does not define
edge-case behaviour for when `TERMINAL_BLOCK_HASH` is used. edge-case behaviour for when `TERMINAL_BLOCK_HASH` is used.