refactor/polish style of DAS docs, move DAS validator work to new doc

specs/phase1/das-internals.md

@@ -1,4 +1,4 @@
-# Ethereum 2.0 Phase 1 -- Data Availability Sampling
+# Ethereum 2.0 Phase 1 -- Data Availability Sampling - Internals
 
 **Notice**: This document is a work-in-progress for researchers and implementers.
 

specs/phase1/das-p2p.md

@@ -1,6 +1,11 @@
+# Ethereum 2.0 Phase 1 -- Data Availability Sampling - 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 -->
-**Table of Contents**
 
 - [Ethereum 2.0 Phase 1 -- Network specification for Data Availability Sampling](#ethereum-20-phase-1----network-specification-for-data-availability-sampling)
   - [Table of contents](#table-of-contents)
@@ -23,19 +28,10 @@
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
 
-# Ethereum 2.0 Phase 1 -- Network specification for Data Availability Sampling 
-
-**Notice**: This document is a work-in-progress for researchers and implementers.
-
-## Table of contents
-
-<!-- TOC -->
-
-<!-- /TOC -->
 
 ## Introduction
 
-For an introduction about DAS itself, see [the DAS section in the Phase 1 validator spec](./validator.md#data-availability-sampling).
+For an introduction about DAS itself, see [the DAS participation spec](./das-participation.md#data-availability-sampling).
 This is not a pre-requisite for the network layer, but will give you valuable context. 
 
 For sampling, all nodes need to query for `k` random samples each slot.
@@ -133,11 +129,11 @@ These subscriptions rotate slowly, and with different offsets per node identity
 # TODO hash function: (node, time)->subnets
 ```
 
-Backbone subscription work is outlined in the [DAS validator spec](./validator.md#data-availability-sampling)
+Backbone subscription work is outlined in the [DAS participation spec](./das-participation.md#slow-rotation-backbone)
 
 #### 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).
+A node MUST maintain `k` random subscriptions to topics, and rotate these according to the [DAS participation spec](./das-participation.md#quick-rotation-sampling).
 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
@@ -164,7 +160,7 @@ Take `blob = signed_blob.blob`:
 2. Create samples with proofs: `samples = sample_data(blob.slot, blob.shard, extended_data)`
 3. Fanout-publish the samples to the vertical subnets of its peers (not all vertical subnets may be reached).
 
-The [DAS validator spec](./validator.md#data-availability-sampling) outlines when and where to participate in DAS on horizontal subnets.
+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)

specs/phase1/das-participation.md

@@ -0,0 +1,74 @@
+# Ethereum 2.0 Phase 1 -- Data Availability Sampling - Participation
+
+**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 -->
+
+TODO
+
+<!-- END doctoc generated TOC please keep comment here to allow auto update -->
+
+
+## Data Availability Sampling
+
+TODO: Summary of Data Availability problem
+
+TODO: Summary of solution, why 2x extension, and randomized samples
+
+## GossipSub
+
+### Horizontal subnets
+
+TODO
+
+### Vertical subnets
+
+#### Slow rotation: Backbone
+
+TODO
+
+#### Quick rotation: Sampling
+
+TODO
+
+
+### DAS during network instability
+
+The GossipSub based retrieval of samples may not always work.
+In such event, a node can move through below stages until it recovers data availability.
+
+#### Stage 0: Waiting on missing samples
+
+Wait for the sample to re-broadcast. Someone may be slow with publishing, or someone else is able to do the work.
+
+Any node can do the following work to keep the network healthy:
+- Common: Listen on a horizontal subnet, chunkify the block data in samples, and propagate the samples to vertical subnets.
+- Extreme: Listen on enough vertical subnets, reconstruct the missing samples by recovery, and propagate the recovered samples.
+
+This is not a requirement, but should improve the network stability with little resources, and without any central party.
+
+#### Stage 1: Pulling missing samples from known peers
+
+The more realistic option, to execute when a sample is missing, is to query any node that is known to hold it.
+Since *consensus identity is disconnected from network identity*, there is no direct way to contact custody holders
+without explicitly asking for the data.
+
+However, *network identities* are still used to build a backbone for each vertical subnet.
+These nodes should have received the samples, and can serve a buffer of them on demand.
+Although serving these is not directly incentivised, it is little work:
+1. Buffer any message you see on the backbone vertical subnets, for a buffer of up to two weeks.
+2. Serve the samples on request. An individual sample is just expected to be `~ 0.5 KB`, and does not require any pre-processing to serve.
+
+A validator SHOULD make a `DASQuery` request to random peers, until failing more than the configured failure-rate.
+
+TODO: detailed failure-mode spec. Stop after trying e.g. 3 peers for any sample in a configured time window (after the gossip period).
+
+#### Stage 2: Pulling missing data from validators with custody.
+
+Pulling samples directly from nodes with validators that have a custody responsibility,
+without revealing their identity to the network, is an open problem.
+

specs/phase1/validator.md

@@ -536,53 +536,6 @@ class SignedLightAggregateAndProof(Container):
     signature: BLSSignature
 ```
 
-## Data Availability Sampling
-
-### Gossip subscriptions to maintain
-
-#### Slow rotation: Backbone
-
-TODO
-
-#### Quick rotation: Sampling
-
-TODO
-
-
-### DAS during network instability
-
-The GossipSub based retrieval of samples may not always work
-
-#### Waiting on missing samples
-
-Wait for the sample to re-broadcast. Someone may be slow with publishing, or someone else is able to do the work.
-
-Any node can do the following work to keep the network healthy:
-- Common: Listen on a horizontal subnet, chunkify the block data in samples, and propagate the samples to vertical subnets.
-- Extreme: Listen on enough vertical subnets, reconstruct the missing samples by recovery, and propagate the recovered samples.
-
-This is not a requirement, but should improve the network stability with little resources, and without any central party.
-
-#### Pulling missing samples
-
-The more realistic option, to execute when a sample is missing, is to query any node that is known to hold it.
-Since *consensus identity is disconnected from network identity*, there is no direct way to contact custody holders
-without explicitly asking for the data.
-
-However, *network identities* are still used to build a backbone for each vertical subnet.
-These nodes should have received the samples, and can serve a buffer of them on demand.
-Although serving these is not directly incentivised, it is little work:
-1. Buffer any message you see on the backbone vertical subnets, for a buffer of up to two weeks.
-2. Serve the samples on request. An individual sample is just expected to be `~ 0.5 KB`, and does not require any pre-processing to serve.
-
-A validator SHOULD make a `DASQuery` request to random peers, until failing more than the configured failure-rate.
-
-TODO: detailed failure-mode spec. Stop after trying e.g. 3 peers for any sample in a configured time window (after the gossip period).
-
-Pulling samples directly from nodes with a custody responsibility, without revealing their identity to the network, is an open problem.
-
-
-
 ## How to avoid slashing
 
 Proposer and Attester slashings described in Phase 0 remain in place with the