-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update EIP-7594: include cell proofs in network wrapper of blob txs #9378
base: master
Are you sure you want to change the base?
Conversation
File
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
|
||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The transaction RLP is the same. Does your TX definition include what verification function to use?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what I understand the only change will be in proofs - there will be n * m
instead of m
(m - number of blobs, n - number of cells in blob
), so structure will be the same. Right now we are validating if number of blobs is equal to number of proofs, we will need to change it and accept txs in two forms - old and new. So validate number of proofs == n*m || m
What I think is the most reasonable here:
- In all ELs p2p start accepting new form of blob txs without dropping support for old format - just accept both. Keep responding to
GetPooledTransactions
with old format at this point - just be able to handle a new format. Check readiness in test environment. - Prepare internally for changes required by new format, like blob pool adjustments and "translating" rpc txs with old format to the new one. Probably we need to keep both forms of proofs in blob pools at this point.
- After the fork start sending txs by p2p in a new format - all peers will be ready as hard fork requires clients version update and all clients were already ready to accept it. In p2p only change will be in
PooledTransactions
messages, so should be easy to switch at fork - Some time after the fork drop p2p support for old format and remove all stale stuff from blob pools etc.
I haven't started implementing it yet, so all above is just a theory at this point. Planning to start it next week.
Another ideas:
- new tx type
- new eth protocol version with override of
PooledTransactions
|
||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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