status-im
/
eth2.0-specs
mirror of https://github.com/status-im/eth2.0-specs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Apply suggestions from @djrtwo review 

Co-authored-by: Danny Ryan <dannyjryan@gmail.com>
This commit is contained in:
Paul Hauner 2022-01-18 09:30:01 +11:00 committed by GitHub
parent 856eea4986
commit 15ef2f30d2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
specs/bellatrix/p2p-interface.md
View File

@ -202,7 +202,7 @@ always by simultaneously respected.
### Why allow invalid payloads on the P2P network?
The specification allows blocks with invalid payloads to propagate across
The specification allows blocks with invalid execution payloads to propagate across
gossip and via RPC calls. The reasoning for this is as follows:
1. Optimistic nodes must listen to block gossip to obtain a view of the head of
@ -213,8 +213,8 @@ gossip and via RPC calls. The reasoning for this is as follows:
to requests for the parent via RPC.
4. Therefore, optimistic nodes must send optimistic blocks via RPC.
So, to prevent network segregation from optimistic nodes accidentally sending
invalid payloads, nodes should never downscore/disconnect nodes due to invalid
So, to prevent network segregation from optimistic nodes inadvertently sending
invalid execution payloads, nodes should never downscore/disconnect nodes due to such invalid
payloads. This does open the network to some DoS attacks from invalid execution
payloads, but the scope of actors is limited to validators who can put those
payloads in valid (and slashable) beacon blocks. Therefore, it is argued that

6
sync/optimistic.md
View File

@ -116,16 +116,16 @@ from an execution engine. I.e., perform the following transitions:
- `SYNCING` -> `INVALID`
When a block transitions from `SYNCING` -> `VALID`, all *ancestors* of the
block MUST also transition from `SYNCING` -> `VALID`. Such a block is no longer
block MUST also transition from `SYNCING` -> `VALID`. Such a block and any previously `SYNCING` ancestors are no longer
considered "optimistically imported".
When a block transitions from `SYNCING` -> `INVALID`, all *descendants* of the
block MUST also transition from `SYNCING` -> `INVALID`.
When a block transitions from the `SYNCING` state it is removed from the set of
When a block transitions from the `SYNCING` state, it is removed from the set of
`store.optimistic_roots`.
When a "merge block" (i.e. a block which enables execution) 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
[`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