Proposal: Indexed cell masks for heterogeneous GetCells requests

[vbhattaccmu]

Summary

I would like feedback on an extension to EIP-8070's eth/72 cell retrieval protocol for batches where different blob transactions require different cell masks.

The current GetCells message applies one 128-bit mask to every transaction hash. Clients must therefore split a scheduling batch by exact mask equality. This is efficient for normal custody-aligned sampling, but partial delivery and recovery can produce transaction-specific missing-cell sets and fragment one logical batch into several requests.

Proposed wire format

A future eth version would retain the existing shared forms and add indexed forms:

GetCells shared:
[request_id, hashes, cell_mask]

GetCells indexed:
[request_id, hashes, masks, mask_ids]

Cells shared:
[request_id, hashes, cells, cell_mask]

Cells indexed:
[request_id, hashes, cells, masks, mask_ids]

masks is a deduplicated table of 128-bit masks. mask_ids contains one byte per transaction hash and selects the corresponding table entry.

The indexed Cells form is necessary because the existing response has one shared mask and cannot describe transaction-specific partial responses.

The shared form remains mandatory when every transaction uses the same mask. Indexed encoding is used only when it reduces the request count or encoded size.

Canonical validation and limits

The draft requires:

• equal hash and mask-ID counts;
• at most 64 hashes and 64 unique masks;
• unique hashes and masks;
• in-range mask IDs;
• no unused mask-table entries;
• mask-table ordering by first reference;
• response masks that are subsets of the corresponding request masks;
• validation before allocating cell-response storage; and
• identical request, response, and peer quotas for shared and indexed forms.

Evidence so far

Controlled request traces show a conditional benefit when missing-cell masks are highly fragmented. For example, synthetic 64-transaction workloads collapsed 8-64 shared-mask requests into 1-4 indexed requests, with request-side wire-byte reductions of roughly 15-63% in those cases.

However, a corrected sparse-node observation recorded 92 scheduling batches and zero fragmented batches. That is negative evidence for deploying a new wire version today. The response-side indexed format also needs to be added to the simulator before claiming an end-to-end byte reduction.

I am opening this issue to determine whether execution-client teams expect heterogeneous recovery masks to become common enough to justify standardization.

Draft specification

https://github.com/vbhattaccmu/EIPs/blob/eth73-indexed-cell-requests/EIPS/eip-draft_indexed_cell_requests.md

Questions

1. Are transaction-specific missing-cell masks expected under realistic sparse blobpool recovery workloads?
2. Can client-local scheduling avoid the fragmentation without a protocol change?
3. Is a canonical indexed table preferable to parallel per-transaction masks?
4. Which measurements or devnet conditions should gate an eth successor proposal?