status-im/eth2.0-specs
2
0
Fork 0
mirror of https://github.com/status-im/eth2.0-specs.git synced 2025-01-13 12:14:19 +00:00
Code Issues Projects Releases Wiki Activity

Remove valid roots set

Browse Source
This commit is contained in:
Paul Hauner 2021-12-14 15:51:02 +11:00
parent 497b5f8cbb
commit 0ad6025b48
No known key found for this signature in database
GPG Key ID: 5E2CFF9B75FA63DF
1 changed files with 2 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
sync/optimistic.md
View File

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