*Chuck Norris doesn't need to sample data availability; data just becomes available when he decides it's time.*

# The novel PeerDAS approach (Fulu)

## Introduction

Rather than requiring all beacon nodes to fetch and store every blob from all blocks over `4096` epochs, we propose a system that allows nodes to shard the responsibility for blob custody. This approach aims to enable an increase in the number of blobs per block without linearly increasing the required bandwidth and storage capacity.

However, it is essential to ensure that all blobs remain effectively available throughout the entire `4096` epochs. A straightforward but resource-intensive way to verify blob availability is to download each blob, which is the current approach used in EIP-4844 (Proto-Danksharding). Unfortunately, even downloading blobs without storing them consumes network bandwidth.

The PeerDAS concept addresses this challenge by ensuring blob availability **without requiring all blobs to be downloaded**.

## Protocol
The first step is to apply erasure coding to each blob. If you're unfamiliar with erasure coding, please refer to the section on [polynomials](https://hackmd.io/XyUFRKB1RGSiMEWlypw9hw#Polynomials) at the end of this book. For our purposes, we will use an erasure coding ratio of `2`. This means that an erasure-coded blob will require twice the storage space of a non-erasure-coded blob.

Before applying erasure coding, blobs can be represented as follows:

With erasure code, blobs can be represented as follows:

Now, let's divide all rows (the blobs) into 128 columns, referred to as **data columns**.

- With `128` data colums, each cell represents `256 kB / 128 = 2 kB`.
- With `6` blobs, each column represents `2 kB * 6 = 12 kB`.

## Peer custody
Peers no longer need to download and store complete blobs (i.e., entire rows). Instead, they only need to handle a subset of data columns.


In this example:
- There is 128 columns `NUM_COLUMNS = 128`.
- The peer custodies `4` data columns

## Modified topics structure

With the introduction of peerDAS, the previous `blob_sidecar_<n> topics` (where `n=0..5`) have been replaced by `data_column_sidecar_<n>` topics (where `n=0..127`).

Example of Prysm logs:

...
INFO sync: Subscribed to topic=/eth2/153249ea/data_column_sidecar_36/ssz_snappy
INFO sync: Subscribed to topic=/eth2/153249ea/data_column_sidecar_105/ssz_snappy
INFO sync: Subscribed to topic=/eth2/153249ea/data_column_sidecar_124/ssz_snappy
INFO sync: Subscribed to topic=/eth2/153249ea/data_column_sidecar_23/ssz_snappy
...

:::info
**NOTE**

In an earlier version of the specification, a single topic could contain multiple data columns. However, in the current version, each topic is limited to exactly one data column, resulting in a total of `128` topics.
:::

## Custody requirement

### Without attached validators
**Without** attached validators, a full node is required to download, store **and serve** a minimum of `4` data columns but has the option to download, store **and serve** more if desired.

[Source](https://github.com/ethereum/consensus-specs/blob/dev/specs/fulu/das-core.md#custody-requirement).

By default, a Prysm beacon node will download, store **and serve** `4` data columns. However, running a Prysm beacon node with the `--subscribe-all-subnets` option enables it to download, store **and serve** all `128` data columns. In this configuration, the node is considered a **super node**.

### With managed validators (validator custody)
**With** at least one attached validators, a full node is required to download, store **and serve** a minimum of `8` data columns.
For each new `32 ETH` attached, the full node is required to download, store **and serve** one extra data column.

- If `4096 ETH` or more are attached (`128` validators with `32 ETH` each), then the node is required to download, store **and serve** a minimum all the `128` data columns.
- If `2048 ETH` or more are attached (`64` validators with `32 ETH` each), then the node is required to download, store **and serve** a minimum all the `64` data columns, and is now able to reconstruct the `64` missing data columns


[Source](https://github.com/ethereum/consensus-specs/pull/3871/files).

## Determining custody data columns
A beacon node operates using a private key, and the custody of data columns is determined through the following steps:

1. A unique public key is deterministically derived from the private key.
2. A unique node ID is deterministically derived from the public key.
3. A unique sequence of `128` data column indices is deterministically derived from the node ID.
4. If the node is required to custody `n` data columns, these must correspond to the first `n` indices of the sequence computed in step 3.

**Example:**
If, in step `3`, the following unique sequence of 128 indices is derived from the node ID: `[14, 86, 45, 54, 66, 78, 127, 103, 2, ...]`, and the node is assigned custody of `4` columns, the corresponding indices must be `[14, 86, 45, 54]`.

If, at a later time, the same node (using the same private key) is assigned custody of `6` columns, the corresponding indices must be `[14, 86, 45, 54, 66, 78]`.

[Source](https://github.com/ethereum/consensus-specs/blob/dev/specs/_features/eip7594/das-core.md#get_data_column_sidecars).

## Advertising Custody Columns
The number of custody groups (which corresponds to the number of custody data columns in the current specification) is advertised through both the node's ENR record and the Metadata P2P message.

In the ENR record, a new field, `cgc` (short for custody group count), has been introduced to indicate this information.

**Example with:**

enr:-Me4QGw9qjlhPjQ9Q-yoi_ju4-6aXLtvjeS2V2U0BveqIkeVGNObDR8pTRZCUVQW48yd81ch6SndZTzd6w6Ha1tqtDaGAZNDJl6sh2F0dG5ldHOIAAAAAAAAGACDY3NjBIRldGgykBUySepgAAA4AOH1BQAAAACCaWSCdjSCaXCErBAAFYlzZWNwMjU2azGhAnhJ7EpX-jrAq3cBimdLfhcXmUwMiZyxylTUjCrr00Y1iHN5bmNuZXRzAIN0Y3CCMsiDdWRwgjLI


New Metadata structure:

  seq_number: uint64
  attnets: Bitvector[ATTESTATION_SUBNET_COUNT]
  syncnets: Bitvector[SYNC_COMMITTEE_SUBNET_COUNT]
  custody_subnet_count: uint64 # csc

Both the node ID and the custody subnet count are publicly accessible, allowing anyone to determine the custody data columns for any node on the network.

## Newsly introduced Req/Resp
PeerDAS comes with two new Req/Resp messages: `DataColumnSidecarsByRoot` and `DataColumnSidecarsByRange`.

([Source](https://github.com/ethereum/consensus-specs/blob/dev/specs/_features/eip7594/p2p-interface.md#the-reqresp-domain))

`DataColumnSidecarsByRoot` allows to retrieve from peers a list of data column sidecars by specifying:
- a block root, and
- a data column index.

In Prysm, `DataColumnSidecarsByRoot` is used:
- during peer sampling, and
- when retrieving data columns after a reorg (if the reorg is small enough not to switch back to initial sync).

`DataColumnSidecarsByRange` allows to retrieve from peers a range of data columns sidecars by specifying:
- a start slot,
- a count, and
- a list of data columns indices.

In Prysm, `DataColumnSidecarsByRange` is used during the initial sync.

## Custody sampling

In addition to managing custody columns, a full node without any attached active validator must perform custody sampling to verify the availability of additional data columns

[Source](https://github.com/ethereum/consensus-specs/blob/dev/specs/fulu/das-core.md#custody-sampling).

With custody sampling, a node is required to download via gossip and verify the validity of at least `8` data columns per block.

If the node already holds custody of at least `8` data columns, subnet sampling does nothing (a no-op).

**Example 1:**
If a node custodies `4` data columns, then for each block containing blobs, it must fetch and verify via gossip an additional `4` data columns, for a total of `4 + 4 = 8` data columns.

- **Note 1:** The node continues to advertise custody of only `4` data columns (its `cgc` value in the ENR remains `4`).
- **Note 2:** The node is not required to store or serve the `4` extra data columns fetched during custody sampling.

In this scenario, the node subscribes to a total of `8` `data_column_sidecar_<n>` topics: the `4` topics corresponding to its costody data columns and the `4` additional topics required for subnet sampling.

To mark a block as available, all custody and custody-sampled columns must be successfully retrieved and verified.


**Example 2:**
If a node custodies `12` data columns, then for each block containing blobs, it does not need to fetch or verify any additional data columns. The total remains `12 + 0 = 12` data columns, and subnet sampling is a no-op.


The following chart shows that custody sampling has an effect only for full nodes not managin any validator.


## How are data columns stored?
In Prysm, data columns are stored directly in the filesystem using the pattern `data-columns/<epoch/4096>/<epoch>/<blockRoot>.ssz`.

Example for a node custodying columns `3`, `5`, `13` and `120`:

[  96]  data-columns
└── [ 29K]  0
    ├── [ 896]  1000
    │   ├── [254K]  0x050d7815bc638f28568120e45a17353d448658a50b111683ffbcd4871b6b9aa8.sszs
    │   ├── [ 87K]  0x08f32d8c2f45cd5c586508af47d6d027af32b478b9aba0b8b78cd9ae29b6501d.sszs
    │   ├── [254K]  0x08f613d7175f2dd19c62ee6f4e73cf2554869f097a0920e55f3f1e335087782c.sszs
    │   ├── [254K]  0x1647817d154bd7698a749beee5e73aac47b2441aa5257e73a351bade9e60dad4.sszs
    │   ├── [ 87K]  0x1dd40a37a1b56bb92319d6539c0acac66f8c5a1900c7573a434d78b41f52dead.sszs
    │   ├── [254K]  0x30008981a1063277128f51841666799cca4b51e83c6282583501fb419ddac21f.sszs
    │   ├── [ 87K]  0x4664027b80541d83ff927567c48d2357cb5ce5112a6e7ee4e47d4ab55f461fde.sszs
    │   ├── [254K]  0x4d2ebad1cf66c4d6e8bb810ff2311d520f7375b74fce22dab9b724466a0c0db5.sszs
    │   ├── [254K]  0x511287927a19ed03d37ee1d909b19d9a9271ae7357b6cf221f03b07612c0d4df.sszs
    │   ├── [254K]  0x5e98fc4bb65850f897d80fbc528d3077cb1257bcc6759d78eddb64c0f1a1b4fe.sszs
    │   ├── [ 70K]  0x727ee49f1fd84d021becbbcb4920f34013b68dc15e7e8f858b3f9b9694a5d44c.sszs
    │   ├── [221K]  0x7815d08582372ae4885d714f64c51d5c5abf63b2402196adf439bd0b87127c26.sszs
    │   ├── [254K]  0x7dc777574f07a86d4115ba1e2fb6cb98b869825e2447c24bb894e306d6394184.sszs
    │   ├── [254K]  0x80857b847202876bfb6165da3b0144828068fd0e64b73f6e2198deb18ab0e745.sszs
    │   ├── [221K]  0x84b6e007efd17e5c252c3ca29bbbb0ffb89c5b76ce365633146ad7c0ddb0ee72.sszs
    │   ├── [254K]  0x8f5202004434690b718e14fb85572d4cda8a9aed9b0f2cda7af15756fe5547f2.sszs
    │   ├── [254K]  0xa02114bf09a683da42aba024a309d4ff57293eccefba011b4942bdd6be0fca62.sszs
    │   ├── [254K]  0xab7e7b08653d4f56f14b3a7e879e43ddcb65de729a773859f21ddae7070031b6.sszs
    │   ├── [237K]  0xafc09b204b22cfd70f55967e34e36288eba33ab62db79a876be3b9fbe050264e.sszs
    │   ├── [ 87K]  0xc712d4f0679834b3156b3130ce0e2e997ae34f42ec5570a1461d33670eae2662.sszs
    │   ├── [ 87K]  0xc947bde40f76ae4ce3cf36b8769a66bc055f23ce0310c4131dbffbef01464399.sszs
    │   ├── [237K]  0xcc1f3bb8bd17616136e595cb9b86cf064cfa6f5b5040cb38c467720dd197af4f.sszs
    │   ├── [254K]  0xd46b617a424c0e64adbdf2580c79cfb08a3aab4065860d265ae6e8ef164df5c5.sszs
    │   ├── [254K]  0xeaecb6386b36f96632be75b1230ba387ff89945872cbfe7b8d0c3e10f50d13bc.sszs
    │   ├── [254K]  0xefec1373eac0b713f125a73db9ca11ea93db8674e4d67354e04edd565318a1d6.sszs
    │   └── [221K]  0xfa41faf21cf261b8acbad57b1cd5d3eeefb3ad4642acab704b9347a1be734696.sszs
    ├── [ 992]  1001
    │   ├── [ 87K]  0x0bc7a32a5dbe813ae18c0896a5624ff46fe3525fd24a57b2c67572b172573a5d.sszs
    │   ├── [187K]  0x100b0c287323c8b685aded79fb5c993d504bf25a763c6b014f8fbbe544f146f9.sszs
    │   ├── [254K]  0x1477459cf4efeb1e648f4dc749b1c860bfdfbc4f40d115d80a2e89cde2ad191e.sszs
    │   ├── [254K]  0x181e360facb3693fe333c57280bc897735409d73acdf84f353aecc5f0781e3be.sszs
    │   ├── [ 70K]  0x276b2378c8637650de63efd5b4b5d407066d1905cb0f80feb7d97e4e1868f10c.sszs
    │   ├── [154K]  0x28accdfd9f7a301ada318c13461798d1309c6df9061c39f1e3b6bf0daae0d969.sszs
    │   ├── [254K]  0x2af7d0e8a84332d5f9afd294acdeb3c262ad83baed65b2577b359f27b5e12278.sszs
    │   ├── [254K]  0x38f5384917c1e4bca49d8fae8212c1063d8cddac011a2453b63996aaa13ca423.sszs
    │   ├── [237K]  0x40ae217b8d37f8c0696038172d62948a05fbf663ac5372211f8fb9b71d76f155.sszs
    │   ├── [254K]  0x53f5de76325475634bac2aa6f6f7e9dfc24839539d12e3fbe0602e7fe8f8bf25.sszs
    │   ├── [254K]  0x606dc6464fa4044cd517588d44ccdbdb6319a876f79a36a1bb5caef1f1f892f6.sszs
    │   ├── [ 87K]  0x71d0f7fd76762f8284f61d52de81481798eef14ea29dd9c99344b20dd51f2a42.sszs
    │   ├── [254K]  0x732ba8aa98845d6d3a72cf3e2ddb11346469f295a8689fd8087b22b307e9412a.sszs
    │   ├── [ 20K]  0x7cbac5eec244c4d6245d9fe16f386f7efd6c08530d325112abf7cda1fc6c249a.sszs
    │   ├── [187K]  0x7d55bea5bb3dd5aa02b4f3dc9cfbada8f1737d5d40253d3d063198fdfd086710.sszs
    │   ├── [254K]  0x8204a1cf435da1c12cbb893593830fe953ded460b3f421db66641ad685f5ddf7.sszs
    │   ├── [254K]  0x8f8beb9cfdb0f9d45fa8ebb3f7d1afc59fad6385a467c8d37476b4958d862053.sszs
    │   ├── [254K]  0xab923354876442400a33f7bf35bb986b1aa9760a7fe537c15e079260e83d612d.sszs
    │   ├── [154K]  0xb6972b3244ae32f889c1b3db46d9e093e7a334c49c0d5f1be81a3df544843865.sszs
    │   ├── [254K]  0xc32c3edc5c48b369d5a6b6f4a16ac3f21d4969ce9acd228055d7ff0090b3ada4.sszs
    │   ├── [254K]  0xc6c0c4681ee1257f7b8fb132eb9bd8cafc90bb7574fb331c170c8a409e89073e.sszs
    │   ├── [ 87K]  0xcfc99000a3ea95b357636d72ec62ce4069da2fa56bf9477701895eb244ec7227.sszs
    │   ├── [ 70K]  0xd2ff9128335409f194341384d14a2d96901414be01573971bf1b6e9069c89feb.sszs
    │   ├── [254K]  0xd321bd41a3953f9eab69e2876e1b26956425a03feb38243f1686a87c8d2e8fec.sszs
    │   ├── [204K]  0xec70ca5ccd299c8605392f12abb773c5d009dd381b852292228accc63645672b.sszs
    │   ├── [120K]  0xeeee1b27cb39ceaeba0f8045c89bc48a92ecf46e82baa05883333bab5069dde7.sszs
    │   ├── [254K]  0xf000272f0031891b35bfb7cab4a0278f09c665595d5ced3a97541f84c53d3d55.sszs
    │   ├── [ 87K]  0xf20efb206e43ba76aaa8c2551a1a866f4c246478f1e778e64c1a518627c26947.sszs
...

## Reconstruction
If a Prysm beacon node receives `50%` or more of the data columns (i.e., `64` or more data columns), it immediately begins reconstructing the missing `50%`.

After a random waiting time into the slot, the node compares the data columns it should have theoretically received (based on its subscriptions to the corresponding topics) with the data columns it actually received. The beacon node then sends the difference.

## Do we really need all this complexity?
Wouldn't it be sufficient to keep EIP-4844 with row subnets and require each node to custody only a subset of blobs?

Consider this scenario: there are a maximum of 6 blobs per block. Unlike the current EIP-4844 design, where all nodes take custody of all blobs, in this proposed (and flawed) system, each peer would only need to custody 2 subnets.

Now, imagine an attacker launching a DDoS attack targeting all nodes responsible for custodying a given subset of blobs. In such a case, those nodes would be completely unable to serve the corresponding blobs.

As a result, some blobs—despite being committed to a block—would no longer be available.


:::warning

**This is exactly the situation we aim to prevent.**
:::

Now with columns subnets **and** erasure code:

**Example:**


Extracting one (extended) blob:

Since the extended blob is [erasure coded](https://hackmd.io/uImjdfxFT2-xA793rvaNIw), as long as no more than 50% of the extended blob is missing, it remains possible to reconstruct the extended `256 kB` blob.


And, finally, to retrieve the original, non-extended, `128 kB` blob.


## Raw Comparison: Without vs. With PeerDAS

### Without PeerDAS (Proto-Danksharding only)
When considering only the blob data payload (excluding additional data in the [Blob Sidecar](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#blobsidecar), such as `kzg_commitment` or `kzg_proof`):
- Each blob consists of **64 cells**.
- A maximum of **6 blobs** can be included per block.
- Each cell holds **2 kB** of data.

This means a node is responsible for storing up to:
**64 × 6 × 2 kB = 768 kB** of blob data per block.


### WithPeerDAS
Using PeerDAS, with 4 custody data columns and 4 additional data columns fetched via subnet sampling, and considering only the blob data payload (excluding other data in the [Data Column Sidecar](https://github.com/ethereum/consensus-specs/blob/dev/specs/fulu/das-core.md#datacolumnsidecar), such as `kzg_commitments` or `kzg_proofs`), while maintaining a total of **768 kB** of blob data, we can define the following:
- Each node custodizes and samples **8 data columns** per block.
- A maximum of **48 blobs** can be included per block.
- Each cell holds **2 kB** of data.

This results in each node custodizing and sampling up to:
**8 × 48 × 2 kB = 768 kB** of blob data per block.


Focusing solely on blob data and **disregarding all other constraints and potential challenges**, PeerDAS enables the Ethereum network to achieve an **8x** increase in the number of blobs.

However:
> ... increasing blob throughput by 8x with PeerDAS could be “a little harder than we think” and will require more research and testing before developers can know for certain how best to roll out the sampling-related code changes.
Source: [Galaxy.com (Terence Tsao)](https://www.galaxy.com/insights/research/ethereum-all-core-developers-consensus-call-149/)