status-im/eth2.0-specs
2
0
Fork 0
mirror of https://github.com/status-im/eth2.0-specs.git synced 2025-01-31 21:05:24 +00:00
Code Issues Projects Releases Wiki Activity

split out general phase1 networking from DAS

Browse Source
This commit is contained in:
protolambda 2021-01-04 22:47:42 +01:00
parent 02e3144283
commit b7d965b543
No known key found for this signature in database
GPG Key ID: EC89FDBB2B4C7623
2 changed files with 65 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -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}`

63
specs/phase1/p2p-phase1.md Normal file
View File

@ -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
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
- [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)
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
## 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.