From a5b3c91f250a8d6a057c3f4021c41199d41e4c21 Mon Sep 17 00:00:00 2001 From: Danny Ryan Date: Thu, 20 Jan 2022 09:25:02 -0700 Subject: [PATCH] build opimistic sync file and fix a minor lint/typing issue --- setup.py | 1 + sync/optimistic.md | 25 ++++++++++++++++--------- 2 files changed, 17 insertions(+), 9 deletions(-) diff --git a/setup.py b/setup.py index aa4157b292..888c16142e 100644 --- a/setup.py +++ b/setup.py @@ -868,6 +868,7 @@ def finalize_options(self): 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) diff --git a/sync/optimistic.md b/sync/optimistic.md index 01765112cd..80e9de3e90 100644 --- a/sync/optimistic.md +++ b/sync/optimistic.md @@ -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() ``` @@ -106,10 +107,12 @@ these conditions.* 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 + engine returns `SYNCING` or `VALID`. An `INVALID` 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`][] (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.