[WIP] caps/eth.md: cell exchange

caps/eth.md

@@ -123,6 +123,55 @@ of it (either because it was previously sent or because it was informed from thi
 originally). This is usually achieved by remembering a set of transaction hashes recently
 relayed by the peer.
 
+### Blob Transaction and Cell Exchange
+
+This section describes additional constraints and node behaviours that apply only to blob 
+transactions, in addition to the ordinary transaction exchange.
+
+Blob transactions contain one or more 128 KiB fixed-size objects called blobs. Blobs can be 
+split into cells using the erasure code defined in [EIP-7594]. The size of a cell is 
+currently defined as 2 KiB and each blob consists of 128 cells encoded with a 1/2 
+code rate. A cell is identified within the erasure-coded blob by its index.
+
+Blob transactions also include metadata such as proofs and commitments required to verify 
+whether a cell belongs to the blob data.
+
+- Commitment: A cryptographic value bound to a blob, used in inclusion verification to 
+ensure that any given cell is part of the original blob.
+
+- Proof: A cell-specific data used during inclusion verification of the corresponding cell.
+
+Blob transaction exchange must be initiated only through the 
+[NewPooledTransactionHashes] message. The peer must also announce the availability of its 
+cells using the `cells` field in the message. If a bit in the field is set, it indicates that 
+the peer holds the corresponding cell for all blobs included in the announced transactions.
+
+Responses to [GetPooledTransactions] for blob transactions include the traditional transaction 
+payload and blob metadata. However, the blob data itself can only be obtained 
+as cells via [GetCells]. Since a transaction can carry multiple blobs, cell exchange is 
+handled at the transaction level, meaning that all cells within the same transaction must 
+be delivered together.
+
+Upon receiving the [NewPooledTransactionHashes] message with new blob transaction hashes, 
+the node begins fetching cells in parallel with transaction fetching. The node first makes 
+a probabilistic decision. If it decides to fetch full blobs with probability $p$, it 
+requests them using the [GetCells] message, setting more than 50% of the total cell indices 
+to 1 in the cells field. The recommended probability $p$ is 0.15.
+
+If it decides not to fetch full blobs, it must instead request its custody cells from peers 
+that announced overlapping availability, using the [GetCells] message, but only after 
+observing N (TBD) distinct full-availability announcements. Custody cells are the cells 
+whose indices belong to the custody index set of the associated consensus node ID. In practice, 
+this information can be delievered using engine API from consensus layer. The node 
+must also request an excess of N random indices in addition to its custody set to mitigate 
+targeted and selective data attacks. A node must announce availability only after obtaining 
+all of its custody cells.
+
+A client that wants to store every blobs should distribute its requests as evenly as possible. 
+To avoid being banned by its peer, it must also respect a probability parameter $p$. 
+With probability $p$, it can request 50% of the data from a single peer, but with probability 
+$1 – p$, it should request those cells collectively from multiple peers.
+
 ### Transaction Encoding and Validity
 
 Transaction objects exchanged by peers have one of two encodings. In definitions across
@@ -418,11 +467,11 @@ block.
 
 ### NewPooledTransactionHashes (0x08)
 
-`[txtypes: B, [txsize₁: P, txsize₂: P, ...], [txhash₁: B_32, txhash₂: B_32, ...]]`
+`[txtypes: B, [txsize₁: P, txsize₂: P, ...], [txhash₁: B_32, txhash₂: B_32, ...], cells: B_16]`
 
 This message announces one or more transactions that have appeared in the network and
 which have not yet been included in a block. The message payload describes a list of of
-transactions, but note that it is encoded as three separate elements.
+transactions, but note that it is encoded as four separate elements.
 
 The `txtypes` element is a byte array containing the announced [transaction types]. The
 other two payload elements refer to the sizes and hashes of the announced transactions.
@@ -432,6 +481,13 @@ All three payload elements must contain an equal number of items.
 the byte size of `tx-type || tx-data` for typed transactions, and the size of the
 RLP-encoded `legacy-tx` for non-typed legacy transactions.
 
+The `cells` element is a bitmap marking which cell indices can be fetched from the sending 
+peer. For each bit set to one, the peer stores the cell at that index in all blobs of the 
+transaction. A bit must be set only if the peer has the cell at that index in all blobs of 
+the transaction. This field is only relevant for those entries that refer to blob 
+transactions. Blob transactions with the same `cells` field may be announced together in a 
+batch within this message.
+
 The recommended soft limit for this message is 4096 items (~150 KiB).
 
 To be maximally helpful, nodes should inform peers of all transactions that they may not
@@ -509,8 +565,50 @@ received updates.
   At the same time, client implementations must take care to not disconnect all syncing
   peers purely on the basis of their BlockRangeUpdate.
 
+### GetCells (0x12)
+
+`[request-id: P, [txhash₁: B_32, txhash₂: B_32, ...], cells : B_16]`
+
+This message requests the peer to return cell data of the given transaction hashes.
+The cells element is a bitmap specifying which cell indices are requested. For each bit 
+set, the requester asks for the cell at that index from all blobs of the corresponding 
+transaction.
+
+A node should either set 4 bits (with probability $1–p$) or 64 bits (with probability $p$) 
+in the cells field. This mechanism prevents a greedy peer from abusing bandwidth and 
+encourages collective fetch.
+
+
+### Cells (0x13)
+
+`[request-id: P, [[txhash₁: B_32, [index₁: P, cell₁: B_2048, cell₂: B_2048, ...], [index₂: P, cell₁: B_2048, cell₂: B_2048, ...]], [txhash₂: B_32, [index₁: P, cell₁: B_2048, cell₂: B_2048, ...], [index₂: P, cell₁: B_2048, cell₂: B_2048, ...]], ...]]` 
+
+This is the response to [GetCells].
+
+Each transaction hash is followed by one or more pairs consisting of an index and the 
+corresponding cells. The index specifies the position of a cell within a blob. 
+Blob transaction can contain multiple blobs, and the same index is applied to all of 
+them. If an index is included in the response, one cell must be returned from each 
+blob of the transaction at that index. The cells are listed in the order in which the 
+blobs appear in the transaction.
+
+A peer may omit entire transactions or entire indices if they are unavailable or 
+constrained. However, if an index is included for a transaction, cells for all blobs 
+of that transaction at that index must be returned.
+
+A peer may respond with an empty list if none of the requested cells are available.
+
+To manage uplink bandwidth usage, a node may disconnect peers that send excessive requests. 
+This can be enforced by monitoring metrics such as the number of requested cells over a given 
+period. 
 ## Change Log
 
+### eth/ ()
+
+Version 70 changed the [NewPooledTransactionHashes] message to include custody information 
+which represents cell indicies sending peer has stored. New message types,
+[GetCells] and [Cells] were introduced to support cell-level messaging.
+
 ### eth/69 ([EIP-7642], April 2025)
 
 Version 69 changed the [Status] message to include information about the available block
@@ -624,6 +722,8 @@ Version numbers below 60 were used during the Ethereum PoC development phase.
 [GetReceipts]: #getreceipts-0x0f
 [Receipts]: #receipts-0x10
 [BlockRangeUpdate]: #blockrangeupdate-0x11
+[GetCells]: #getcells-0x12
+[Cells]: #cells-0x13
 [RLPx]: ../rlpx.md
 [EIP-155]: https://eips.ethereum.org/EIPS/eip-155
 [EIP-1559]: https://eips.ethereum.org/EIPS/eip-1559
@@ -639,6 +739,7 @@ Version numbers below 60 were used during the Ethereum PoC development phase.
 [EIP-4844]: https://eips.ethereum.org/EIPS/eip-4844
 [EIP-4938]: https://eips.ethereum.org/EIPS/eip-4938
 [EIP-5793]: https://eips.ethereum.org/EIPS/eip-5793
+[EIP-7594]: https://eips.ethereum.org/EIPS/eip-7594
 [EIP-7642]: https://eips.ethereum.org/EIPS/eip-7642
 [EIP-7685]: https://eips.ethereum.org/EIPS/eip-7685
 [The Merge]: https://eips.ethereum.org/EIPS/eip-3675