[WIP] caps/eth.md: cell exchange

[healthykim]

This is a draft PR to support cell level messaging on the EL

[raulk]

• Can the schema proposed there deal with (a) max 6 blobs per tx and (b) multiple type 3 txs being announced in the same message? Or does "Note that blob transactions with same cells field is being batched together." imply that if cell availability differs across txs, we'd announce them separately?
• I think it's safe to assume that nodes will want to sample the same cell indices for all blobs in a single type 3 tx, which makes the cells naming a bit confusing IMO, but also not a dealbreaker (technically they're columns, but also technically columns don't exist until the blobs are packed in a block).

[healthykim]

Yes, I think we can assume that nodes will try to fetch the same indices for all transactions in most cases. That is why I designed this in a batched form. So, regarding the first question, yes, we would announce them separately, but we can easily assume that most transactions would be batched together and there would not be much fragmentation. I also agree on the naming. cell-indices, custody-indices, and mask could be candidates, but we could also just leave it as it is

[raulk]

Gotcha. We might want nodes to sample a few random cells from peers holding the full payload in addition to their custody set. This mechanism is a sentinel against selective data serving attacks. Otherwise an attacker could repeatedly advertise full availability while holding only the exact subset of cells they know we'll request every time.

[cskiraly]

Since a type 3 tx can have several blobs, we should clarify whether the bitmap is at the tx or at the blob granularity.
For our current purposes, tx granularity looks fine, and then the meaning of a bit is that that the node has the corresponding cell of all blobs in the tx.

[healthykim]

Since a type 3 tx can have several blobs, we should clarify whether the bitmap is at the tx or at the blob granularity. For our current purposes, tx granularity looks fine, and then the meaning of a bit is that that the node has the corresponding cell of all blobs in the tx.

Thank you, I added a more detailed explanation about this in the introduction.

[healthykim]

Gotcha. We might want nodes to sample a few random cells from peers holding the full payload in addition to their custody set. This mechanism is a sentinel against selective data serving attacks. Otherwise an attacker could repeatedly advertise full availability while holding only the exact subset of cells they know we'll request every time.

I’m not sure how much random sampling would be needed given that we have the full payload node count check too, but I think it can be supported under this design. A node can select random columns and perform sampling over the transaction batch, and if an attacker skips the cell indices of the transaction they want to hide, the node would request that column from another peer and ultimately be able to drop the malicious transaction.

[cskiraly]

There are already eth/70 proposals in progress, so the number will be different
We can update at the end in the doc, but maybe remove from title to avoid confusion

[healthykim]

I removed all eth/70 numbering in this PR and on doc so that we can add it back at the end.