github/consensus-specs
1
1
Fork 0
mirror of https://github.com/ethereum/consensus-specs.git synced 2026-02-02 06:15:15 -05:00
Code Issues Packages Projects Releases Wiki Activity

Code review - apply suggestions to DAS doc

Browse Source 
Co-authored-by: Danny Ryan <dannyjryan@gmail.com>
This commit is contained in:
Diederik Loerakker
2021-01-04 21:55:11 +01:00
committed by protolambda
parent a8c9cfbe84
commit c6af2ec687
1 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
specs/phase1/p2p-das.md
View File

@@ -46,13 +46,13 @@ This is a lot of work, and ideally happens at a low latency.
To achieve quick querying, the query model is changed to *push* the samples to listeners instead, using GossipSub.
The listeners then randomly rotate their subscriptions to keep queries unpredictable.
Except for a small subset of subscriptions, which will function as a backbone to keep topics more stable.
Except for a small subset of subscriptions, which will function as a backbone to keep topics more stable and allow for efficient peer discovery.
Publishing can utilize the fan-out functionality in GossipSub, and is easier to split between nodes:
nodes on the horizontal networks can help by producing the same samples and fan-out publishing to their own peers.
This push model also helps to obfuscate the original source of a message:
the listeners will not have to make individual queries to some identified source.
the listeners do not have to make individual queries to some identified source.
The push model does not aim to serve "historical" queries (anything older than the most recent).
Historical queries are still required for the unhappy case, where messages are not pushed quick enough,
@@ -80,7 +80,7 @@ a regular proposer cannot reach every vertical subnet.
#### Publishing
To publish their work, proposers already put the shard block as a whole on a shard-block subnet.
To publish their work, proposers propagate the shard block as a whole on a shard-block subnet.
The proposer can fan-out their work more aggressively, by using the fan-out functionality of GossipSub:
it may publish to all its peers on the subnet, instead of just those in its mesh.
@@ -138,7 +138,7 @@ Backbone subscription work is outlined in the [DAS validator spec](./validator.m
#### Quick Rotation: Sampling
A node MUST maintain `k` random subscriptions to topics, and rotate these according to the [DAS validator spec](./validator.md#data-availability-sampling).
If the node does not already have connected peers on the topic it needs to sample, it can search its peerstore for peers in the topic backbone.
If the node does not already have connected peers on the topic it needs to sample, it can search its peerstore, and if necessary in the DHT, for peers in the topic backbone.
## DAS in the Gossip domain: Push
@@ -175,7 +175,7 @@ The following validations MUST pass before forwarding the `signed_blob` (with in
- _[REJECT]_ As already limited by the SSZ list-limit, it is important the blob is well-formatted and not too large.
- _[REJECT]_ The `blob.data` MUST NOT contain any point `p >= MODULUS`. Although it is a `uint256`, not the full 256 bit range is valid.
- _[REJECT]_ The proposer signature, `signed_blob.signature`, is valid with respect to the `proposer_index` pubkey, signed over the SSZ output of `commit_to_data(blob.data)`.
- _[REJECT]_ The blob is proposed by the expected `proposer_index` for the blob's slot
- _[REJECT]_ The blob is proposed by the expected `proposer_index` for the blob's slot.
TODO: make double blob proposals slashable?