mass/mechanical update of 1.1.3 phase0 spec URLs to 1.1.4 in markdown (#3059)

This commit is contained in:
tersec 2021-11-08 09:26:18 +00:00 committed by GitHub
parent eb3ad25859
commit 2c8600e746
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 17 additions and 17 deletions

View File

@ -5,11 +5,11 @@ This folder holds the various consensus object pools needed for a blockchain cli
Object in those pools have passed the "gossip validation" filter according
to specs:
- blocks: https://github.com/ethereum/consensus-specs/blob/v1.0.1/specs/phase0/p2p-interface.md#beacon_block
- aggregate attestations: https://github.com/ethereum/consensus-specs/blob/v1.1.3/specs/phase0/p2p-interface.md#beacon_aggregate_and_proof
- unaggregated attestation: https://github.com/ethereum/consensus-specs/blob/v1.1.3/specs/phase0/p2p-interface.md#beacon_attestation_subnet_id
- aggregate attestations: https://github.com/ethereum/consensus-specs/blob/v1.1.4/specs/phase0/p2p-interface.md#beacon_aggregate_and_proof
- unaggregated attestation: https://github.com/ethereum/consensus-specs/blob/v1.1.4/specs/phase0/p2p-interface.md#beacon_attestation_subnet_id
- voluntary exits: https://github.com/ethereum/consensus-specs/blob/v1.0.1/specs/phase0/p2p-interface.md#voluntary_exit
- Attester slashings: https://github.com/ethereum/consensus-specs/blob/v1.1.3/specs/phase0/p2p-interface.md#attester_slashing
- Proposer slashings: https://github.com/ethereum/consensus-specs/blob/v1.1.3/specs/phase0/p2p-interface.md#proposer_slashing
- Attester slashings: https://github.com/ethereum/consensus-specs/blob/v1.1.4/specs/phase0/p2p-interface.md#attester_slashing
- Proposer slashings: https://github.com/ethereum/consensus-specs/blob/v1.1.4/specs/phase0/p2p-interface.md#proposer_slashing
After "gossip validation" the consensus objects can be rebroadcasted as they are optimistically good, however for internal processing further verification is needed.
For blocks, this means verifying state transition and all contained cryptographic signatures (instead of just the proposer signature).

View File

@ -9,12 +9,12 @@ This folder holds a collection of modules to:
Gossip validation is different from consensus verification in particular for blocks.
- Blocks: https://github.com/ethereum/consensus-specs/blob/v1.1.3/specs/phase0/p2p-interface.md#beacon_block
- Blocks: https://github.com/ethereum/consensus-specs/blob/v1.1.4/specs/phase0/p2p-interface.md#beacon_block
- Attestations (aggregated): https://github.com/ethereum/consensus-specs/blob/v1.0.1/specs/phase0/p2p-interface.md#beacon_aggregate_and_proof
- Attestations (unaggregated): https://github.com/ethereum/consensus-specs/blob/v1.1.3/specs/phase0/p2p-interface.md#attestation-subnets
- Voluntary exits: https://github.com/ethereum/consensus-specs/blob/v1.1.3/specs/phase0/p2p-interface.md#voluntary_exit
- Proposer slashings: https://github.com/ethereum/consensus-specs/blob/v1.1.3/specs/phase0/p2p-interface.md#proposer_slashing
- Attester slashing: https://github.com/ethereum/consensus-specs/blob/v1.1.3/specs/phase0/p2p-interface.md#attester_slashing
- Attestations (unaggregated): https://github.com/ethereum/consensus-specs/blob/v1.1.4/specs/phase0/p2p-interface.md#attestation-subnets
- Voluntary exits: https://github.com/ethereum/consensus-specs/blob/v1.1.4/specs/phase0/p2p-interface.md#voluntary_exit
- Proposer slashings: https://github.com/ethereum/consensus-specs/blob/v1.1.4/specs/phase0/p2p-interface.md#proposer_slashing
- Attester slashing: https://github.com/ethereum/consensus-specs/blob/v1.1.4/specs/phase0/p2p-interface.md#attester_slashing
There are multiple consumers of validated consensus objects:
- a `ValidationResult.Accept` output triggers rebroadcasting in libp2p

View File

@ -6,10 +6,10 @@ This is a WIP document to explain the attestation flows.
It is important to distinguish attestation `validation` from attestation `verification`.
- Attestation `validation` is defined in the P2P specs. Validated attestations can be forwarded on GossipSub.
- Aggregated: https://github.com/ethereum/consensus-specs/blob/v1.1.3/specs/phase0/p2p-interface.md#beacon_aggregate_and_proof
- Unaggregated: https://github.com/ethereum/consensus-specs/blob/v1.1.3/specs/phase0/p2p-interface.md#beacon_attestation_subnet_id
- Aggregated: https://github.com/ethereum/consensus-specs/blob/v1.1.4/specs/phase0/p2p-interface.md#beacon_aggregate_and_proof
- Unaggregated: https://github.com/ethereum/consensus-specs/blob/v1.1.4/specs/phase0/p2p-interface.md#beacon_attestation_subnet_id
- Attestation `verification` is defined in the consensus specs. Verified attestations can affect fork choice and may be included in a block.
- https://github.com/ethereum/consensus-specs/blob/v1.1.3/specs/phase0/beacon-chain.md#attestations
- https://github.com/ethereum/consensus-specs/blob/v1.1.4/specs/phase0/beacon-chain.md#attestations
From the specs it seems like gossip attestation `validation` is a superset of consensus attestation `verification`.
@ -52,7 +52,7 @@ These GossipSub topics are used to listen for attestations:
The attestations are then validated by `validateAttestation()` or `validateAggregate()` in either `attestationValidator()` or `aggregateValidator()` according to the P2P specs.
- https://github.com/ethereum/consensus-specs/blob/v1.1.0/specs/phase0/p2p-interface.md#beacon_aggregate_and_proof
- https://github.com/ethereum/consensus-specs/blob/v1.1.3/specs/phase0/p2p-interface.md#attestation-subnets
- https://github.com/ethereum/consensus-specs/blob/v1.1.4/specs/phase0/p2p-interface.md#attestation-subnets
Finally, valid attestations are added to the local `attestationPool`.
Attestations are dropped in case of an error.

View File

@ -6,10 +6,10 @@ This is a WIP document to explain the beacon block flows.
Important distinction:
- We distinguish block `validation` which is defined in the P2P specs:
https://github.com/ethereum/consensus-specs/blob/v1.1.3/specs/phase0/p2p-interface.md#beacon_block.
https://github.com/ethereum/consensus-specs/blob/v1.1.4/specs/phase0/p2p-interface.md#beacon_block.
A validated block can be forwarded on gossipsub.
- and we distinguish `verification` which is defined in consensus specs:
https://github.com/ethereum/consensus-specs/blob/v1.1.3/specs/phase0/beacon-chain.md#block-processing
https://github.com/ethereum/consensus-specs/blob/v1.1.4/specs/phase0/beacon-chain.md#block-processing
A block needs to be verified to enter fork choice, the DAG and the BeaconChainDB
In particular in terms of costly checks validating a block only requires checking:
@ -103,7 +103,7 @@ It is important to note that 3 data structures are sharing the same `AsyncQueue[
Blocks are listened to via the gossipsub topic `/eth2/{$forkDigest}/beacon_block/ssz_snappy` (`topicBeaconBlocks` variable)
They are then:
- validated by `blockValidator()` in the Eth2Processor by `validateBeaconBlock()` according to spec https://github.com/ethereum/consensus-specs/blob/v1.1.3/specs/phase0/p2p-interface.md#beacon_block
- validated by `blockValidator()` in the Eth2Processor by `validateBeaconBlock()` according to spec https://github.com/ethereum/consensus-specs/blob/v1.1.4/specs/phase0/p2p-interface.md#beacon_block
- Important: P2P validation is not full verification (state transition and internal cryptographic signatures were not checked)
- enqueued in the shared block queue `AsyncQueue[BlockEntry]` in case of success
- dropped in case of error
@ -115,7 +115,7 @@ Logs:
### Gossip flow out
- After validation in `blockValidator()` in the Eth2Processor by `validateBeaconBlock()` according to spec https://github.com/ethereum/consensus-specs/blob/v1.1.3/specs/phase0/p2p-interface.md#beacon_block
- After validation in `blockValidator()` in the Eth2Processor by `validateBeaconBlock()` according to spec https://github.com/ethereum/consensus-specs/blob/v1.1.4/specs/phase0/p2p-interface.md#beacon_block
- Important: P2P validation is not full verification (state transition and internal cryptographic signatures were not checked)
- We jump into libp2p/protocols/pubsub/pubsub.nim in the method `validate(PubSub, message)`
- which was called by `rpcHandler(GossipSub, PubSubPeer, RPCMsg)`