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? ### 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: 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 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. to requests for the parent via RPC.
4. Therefore, optimistic nodes must send optimistic blocks via RPC. 4. Therefore, optimistic nodes must send optimistic blocks via RPC.
So, to prevent network segregation from optimistic nodes accidentally sending So, to prevent network segregation from optimistic nodes inadvertently sending
invalid payloads, nodes should never downscore/disconnect nodes due to invalid 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. 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, 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 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` - `SYNCING` -> `INVALID`
When a block transitions from `SYNCING` -> `VALID`, all *ancestors* of the 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". considered "optimistically imported".
When a block transitions from `SYNCING` -> `INVALID`, all *descendants* of the When a block transitions from `SYNCING` -> `INVALID`, all *descendants* of the
block MUST also transition from `SYNCING` -> `INVALID`. 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`. `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 `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`][] MUST be run against the merge block. If the block
fails [`validate_merge_block`][], the merge block MUST be treated the same as fails [`validate_merge_block`][], the merge block MUST be treated the same as