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

setup.py

@@ -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)

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()
 ```
 
@@ -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
+[`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
 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.