From b7d965b5431cd5e9b8548ea7a92297ec91e18637 Mon Sep 17 00:00:00 2001 From: protolambda Date: Mon, 4 Jan 2021 22:47:42 +0100 Subject: [PATCH] split out general phase1 networking from DAS --- specs/phase1/das-p2p.md | 18 ++--------- specs/phase1/p2p-phase1.md | 63 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 65 insertions(+), 16 deletions(-) create mode 100644 specs/phase1/p2p-phase1.md diff --git a/specs/phase1/das-p2p.md b/specs/phase1/das-p2p.md index 15a7dc66f..f227872ba 100644 --- a/specs/phase1/das-p2p.md +++ b/specs/phase1/das-p2p.md @@ -142,15 +142,13 @@ If the node does not already have connected peers on the topic it needs to sampl Following the same scheme as the [Phase0 gossip topics](../phase0/p2p-interface.md#topics-and-messages), names and payload types are: | Name | Message Type | |----------------------------------|---------------------------| -| `shard_blob_{shard}` | `SignedShardBlob` | -| `shard_header_{shard}` | `SignedShardHeader` | | `das_sample_{subnet_index}` | `DASSample` | -TODO: separate phase 1 network spec. +Also see the [Phase1 general networking spec](./p2p-phase1.md) for important topics such as that of the shard-blobs and shard-headers. #### Horizontal subnets: `shard_blob_{shard}` -Shard block data, in the form of a `SignedShardBlob` is published to the `shard_blob_{shard}` subnets. +Extending the regular `shard_blob_{shard}` as [defined in the Phase1 networking specification](./p2p-phase1.md#shard-blobs-shard_blob_shard) If participating in DAS, upon receiving a `signed_blob` for the first time, with a `slot` not older than `MAX_RESAMPLE_TIME`, a subscriber of a `shard_blob_{shard}` SHOULD reconstruct the samples and publish them to vertical subnets. @@ -161,18 +159,6 @@ Take `blob = signed_blob.blob`: The [DAS participation spec](./das-participation.md#horizontal-subnets) outlines when and where to participate in DAS on horizontal subnets. -The following validations MUST pass before forwarding the `signed_blob` (with inner `blob`) on the horizontal subnet or creating samples for it. -- _[REJECT]_ `blob.shard` MUST match the topic `{shard}` parameter. (And thus within valid shard index range) -- _[IGNORE]_ The `blob` is not from a future slot (with a `MAXIMUM_GOSSIP_CLOCK_DISPARITY` allowance) -- - i.e. validate that `blob.slot <= current_slot` - (a client MAY queue future blobs for processing at the appropriate slot). -- _[IGNORE]_ The blob is the first blob with valid signature received for the proposer for the `(slot, shard)` combination. -- _[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. - -TODO: make double blob proposals slashable? #### Vertical subnets: `das_sample_{subnet_index}` diff --git a/specs/phase1/p2p-phase1.md b/specs/phase1/p2p-phase1.md new file mode 100644 index 000000000..633814a35 --- /dev/null +++ b/specs/phase1/p2p-phase1.md @@ -0,0 +1,63 @@ +# Ethereum 2.0 Phase 1 -- Network specification + +**Notice**: This document is a work-in-progress for researchers and implementers. + +## Table of contents + + + + + +- [Introduction](#introduction) +- [DAS in the Gossip domain: Push](#das-in-the-gossip-domain-push) + - [Topics and messages](#topics-and-messages) + - [Shard blobs: `shard_blob_{shard}`](#shard-blobs-shard_blob_shard) + - [Shard header: `shard_header`](#shard-header-shard_header) + + + +## Introduction + +With Phase 1, shard data is introduced, which requires various new additions and adjustments to the groundwork that Phase 0 implements. +The specification of these changes continues in the same format, and assumes Phase0 as pre-requisite. +The Phase 0 adjustments and additions for Shards are outlined in this document. +See the [Data Availability Sampling network specification](./das-p2p.md) for Phase 1 networking specifc to Data availability. + + +## DAS in the Gossip domain: Push + +### Topics and messages + +Following the same scheme as the [Phase0 gossip topics](../phase0/p2p-interface.md#topics-and-messages), names and payload types are: +| Name | Message Type | +|----------------------------------|---------------------------| +| `shard_blob_{shard}` | `SignedShardBlob` | +| `shard_header` | `SignedShardHeader` | + +The [DAS network specification](./das-p2p.md) defines additional topics. + +#### Shard blobs: `shard_blob_{shard}` + +Shard block data, in the form of a `SignedShardBlob` is published to the `shard_blob_{shard}` subnets. + +The [DAS networking specification](./das-p2p.md#horizontal-subnets) outlines an extension of the regular behavior on this topic. + +The following validations MUST pass before forwarding the `signed_blob` (with inner `blob`) on the horizontal subnet or creating samples for it. +- _[REJECT]_ `blob.shard` MUST match the topic `{shard}` parameter. (And thus within valid shard index range) +- _[IGNORE]_ The `blob` is not from a future slot (with a `MAXIMUM_GOSSIP_CLOCK_DISPARITY` allowance) -- + i.e. validate that `blob.slot <= current_slot` + (a client MAY queue future blobs for processing at the appropriate slot). +- _[IGNORE]_ The blob is the first blob with valid signature received for the proposer for the `(slot, shard)` combination. +- _[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. + +TODO: make double blob proposals slashable? + +#### Shard header: `shard_header` + +Shard header data, in the form of a `SignedShardHeader` is published to the global `shard_header` subnet. + +TODO: validation conditions. +