Skip to main content
netspecsEthereum networking

4.3.3.PeerDAS custody

Stage
Current
Validity
In force since Fusaka.
Sources
5 pinned sources

PeerDAS divides the extended blob matrix into custody groups. A node stores, serves, and subscribes to every column in each group that it advertises.

A peer does not advertise a bitmap of its columns. It advertises one group count. Any node combines that count with the peer's discovery node ID to derive the exact group set.

Mainnet profile

Parameter Value
NUMBER_OF_COLUMNS 128
NUMBER_OF_CUSTODY_GROUPS 128
DATA_COLUMN_SIDECAR_SUBNET_COUNT 128
CUSTODY_REQUIREMENT 4
VALIDATOR_CUSTODY_REQUIREMENT 8
BALANCE_PER_ADDITIONAL_CUSTODY_GROUP 32 ETH
SAMPLES_PER_SLOT 8
MIN_EPOCHS_FOR_DATA_COLUMN_SIDECARS_REQUESTS 4,096

Mainnet has one column per custody group and one group per gossip subnet. The group, column, and subnet indices are equal. The formulas do not assume that equality for another preset.

Deterministic group assignment

get_custody_groups(node_id, custody_group_count) returns an ordered set of distinct group indices.

  1. Treat the 256-bit node ID as an integer.
  2. Hash its byte encoding.
  3. Convert the first eight hash bytes to a Uint64 and reduce it modulo NUMBER_OF_CUSTODY_GROUPS.
  4. Add a candidate that is not already in the result.
  5. Increment the integer, wrapping from UINT256_MAX to zero, and repeat until the result has the requested count.
  6. Sort the result.

A count equal to NUMBER_OF_CUSTODY_GROUPS returns every group without the loop. A higher count is invalid.

The function has a prefix property. Increasing the count extends the prior group set. It does not replace the peer's old assignment. This property lets a node add capacity without making its earlier discovery claim false.

compute_columns_for_custody_group(group) returns:

NUMBER_OF_CUSTODY_GROUPS * i + group

for each column position i in the group. With the mainnet values, each result has one column.

ENR advertisement

The discovery ENR key is cgc. A node must add it once FULU_FORK_EPOCH has a real configured value instead of FAR_FUTURE_EPOCH.

The value is an unsigned 64-bit integer in minimal big-endian form. It has no leading zero bytes. Zero is the empty byte string. A syntactically valid value can still be below the protocol's custody minimum and therefore unusable for PeerDAS service.

Changing cgc changes the ENR content. The node increments the ENR sequence number and signs the new record.

Metadata confirmation

Metadata version 3 contains:

seq_number: Uint64
attnets: Bitvector[ATTESTATION_SUBNET_COUNT]
syncnets: Bitvector[SYNC_COMMITTEE_SUBNET_COUNT]
custody_group_count: Uint64

The metadata value and ENR cgc describe the same local service contract. A client can reject or disconnect a peer whose count is below CUSTODY_REQUIREMENT. It should treat a mismatch as stale or false advertising, not choose one value without further checks.

Required count

An ordinary node custodies at least four groups. It can choose any higher count through 128.

A node with attached validators uses the latest finalized state and the sum of their effective balances:

required =
  min(
    max(
      total_effective_balance // BALANCE_PER_ADDITIONAL_CUSTODY_GROUP,
      VALIDATOR_CUSTODY_REQUIREMENT
    ),
    128
  )

Effective balances and BALANCE_PER_ADDITIONAL_CUSTODY_GROUP use Gwei, and the division is integer floor division. On mainnet the divisor is 32 ETH and VALIDATOR_CUSTODY_REQUIREMENT is 8.

The node can advertise more than this minimum. A node with at least 4,096 ETH of attached effective balance reaches all 128 groups and is a supernode under the mainnet profile.

Count changes and backfill

When the required count increases, the node should publish the higher count at once. It serves the new groups from that change onward and may backfill their older columns. Status/2.earliest_available_slot should initially be the slot at which the node updated custody_group_count. If the node backfills, the value may move progressively backward as work completes.

When the required count decreases, the node should keep its previous highest count. It continues to custody, advertise, and serve that larger prefix. It should persist the high-water count across restarts. This rule keeps old discovery claims true and prevents a quick loss of network coverage.

A node that is syncing must backfill every column in all of its custody groups to the required serving boundary. This sync requirement is separate from the optional backfill caused only by a later count increase.

A node must cope with more than one count change during the 4,096-epoch retention window.

Peer selection

To find a peer for a missing column:

  1. Read the candidate's node ID and cgc from its signed ENR.
  2. Reject a count below the required minimum or above 128.
  3. Derive the candidate's groups.
  4. Keep the candidate only if one derived group owns the needed column.
  5. Dial the candidate and compare metadata version 3 with the ENR claim.
  6. Request the sidecar and verify it before counting the sample.

The deterministic mapping supports pre-dial filtering. It does not prove that the peer actually retained the data.

Sampling and serving

Each slot, a node samples:

sampling_size = max(8, custody_group_count)

groups derived with the same function. Its custody set is therefore a subset of its sample set. Sampling succeeds only when every selected column is retrieved and verified.

The node stores custody columns acquired under its advertised set for the 4,096-epoch retention window and serves them by range and root. Its normal lower bound is the later of the Fusaka boundary and current_epoch - 4096. After a count increase, its advertised earliest_available_slot can be later until optional backfill moves that boundary backward.

A node that elects to custody all 128 groups subscribes to all column subnets, stores all columns, and performs reconstruction and cross-seeding. This costs more bandwidth, storage, and computation than the minimum profile.

Peer scoring and failure handling

  • A wrong-size or below-minimum count fails before the node uses the advertisement for routing.
  • A request timeout does not by itself prove false advertising. The requester accounts for rate limits, serving windows, and ordinary network failure.
  • Repeated failure to serve retained data from derived custody groups can lower peer score or cause disconnect.
  • Invalid returned sidecars use the normal gossip or Req/Resp validation path. The advertised count never makes bad data valid.
  • Do not penalize a peer for an old column outside the peer's required and advertised range.