Update EIP-7594: include cell proofs in network wrapper of blob txs #9378
Conversation
github-actions
bot
added
c-update
File
|
eth-bot
changed the title
|
|
||
| This EIP introduces cell KZG proofs, which are used to prove that a KZG commitment opens to a cell at the given index. This allows downloading only specific cells from a blob, while still ensuring data integrity with respect to the corresponding KZG commitment, and is therefore a key component of data availability sampling. However, computing the cell proofs for a blob is an expensive operation, which a block producer would have to repeat for many blobs. Since proof verification is much cheaper than proof computation, and the proof size is negligible compared to cell size, we instead require blob transaction senders to compute the proofs themselves and include them in the network wrapper for blob transactions. | ||
|
|
||
| To this end, during transaction gossip responses (`PooledTransactions`), the EIP-4844 wrapper of the EIP-2718 `TransactionPayload` of the blob transaction is modified to: |
There was a problem hiding this comment.
Reviewing Besu's code we currently have no way of changing the definition of a transaction type at a hardfork block. It would be much easier to introduce a new transaction type and make the current 4844 transactions invalid. That change would be straightforward in our case, it would be way less error prone and faster to be implemented.
There was a problem hiding this comment.
The transaction RLP is the same. Does your TX definition include what verification function to use?
There was a problem hiding this comment.
Yes, but it is not protocol-schedule aware. We don't currently have a means of changing that rule during and upgrade.
There was a problem hiding this comment.
Just to add that L2 teams that's given input so far are happy with making changes on their side.
I think @marcindsobczak also had some input on this on the last breakout call, any thoughts on the above comment?
|
|
||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. | ||
|
|
||
| ### Networking | ||
|
|
||
| This EIP introduces cell KZG proofs, which are used to prove that a KZG commitment opens to a cell at the given index. This allows downloading only specific cells from a blob, while still ensuring data integrity with respect to the corresponding KZG commitment, and is therefore a key component of data availability sampling. However, computing the cell proofs for a blob is an expensive operation, which a block producer would have to repeat for many blobs. Since proof verification is much cheaper than proof computation, and the proof size is negligible compared to cell size, we instead require blob transaction senders to compute the proofs themselves and include them in the network wrapper for blob transactions. |
There was a problem hiding this comment.
There was a suggestion from Lion and also brought up by Nethermind during the PeerDAS breakout to have the broadcasting EL node translate the eip4844 blob transaction into the new network form (with cell proofs), i.e. compute cell proofs after receiving blob transaction via RPC, and propagate the updated transaction to p2p network - it seems reasonable to me and would have no impact to end users, even if we change the cell size in the future.
There was a problem hiding this comment.
There was a suggestion from Lion and also brought up by Nethermind during the PeerDAS breakout to have the broadcasting EL node translate the eip4844 blob transaction into the new network form (with cell proofs), i.e. compute cell proofs after receiving blob transaction via RPC, and propagate the updated transaction to p2p network - it seems reasonable to me and would have no impact to end users, even if we change the cell size in the future.
See this doc for context