From 0ad6025b488ff690e87c270a061cd3d736de76e6 Mon Sep 17 00:00:00 2001 From: Paul Hauner Date: Tue, 14 Dec 2021 15:51:02 +1100 Subject: [PATCH] Remove valid roots set --- sync/optimistic.md | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/sync/optimistic.md b/sync/optimistic.md index 63c060009..7092a69ee 100644 --- a/sync/optimistic.md +++ b/sync/optimistic.md @@ -13,23 +13,16 @@ To perform an optimistic sync: - The `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 - `pow_block` and `pow_parent` are unknown to the execution engine. +- The `validate_merge_block` function MUST NOT raise an assertion if both the `pow_block` and `pow_parent` are unknown to the execution engine. In addition to these changes to validation, the consensus engine MUST be able to ascertain, after import, which blocks returned `SYNCING` and which returned `VALID`. This document will assume that consensus engines store the following -sets: +set: -- `valid_roots: Set[Root]`: `hash_tree_root(block)` where - `block.body.execution_payload` is known to be `VALID`. - `optimistic_roots: Set[Root]`: `hash_tree_root(block)` where `block.body.execution_payload` is known to be `SYNCING`. -Notably, `optimistic_roots` only includes blocks which have execution enabled. -On the other hand, `valid_roots` contains blocks *with or without* execution -enabled (i.e., all blocks). - A consensus engine MUST be able to retrospectively (i.e., after import) modify the status of `SYNCING` blocks to be either `VALID` or `INVALID` based upon responses from an execution engine. I.e., perform the following transitions: