Conversation
|
The max blobs per block is 4. This is equal to or less than the number of cores of most of the target CPUs. I would suggest to start adding a comparison with simple parallel alternatives (in this particular case it would do a simple single blob verification per thread) together with such more sophisticated proposals. In many cases, simple parallel algos are simpler (likely more secure) and faster. Like blob proof generation here. |
The max number of blobs per block is not 4. This was a temporary conservative restriction when (a) we were trying to shoot for Shanghai and (b) we did not have any networking tests. This is still likely to be increased. The spec should not try to specify any parallel algorithms. It just needs to specify what's correct and not provide optimizations. |
|
Marked as ready for review because I think the consensus is to (a) free the blobs and (b) make this change to the cryptography. |
Co-authored-by: George Kadianakis <[email protected]>
Co-authored-by: George Kadianakis <[email protected]>
Co-authored-by: George Kadianakis <[email protected]>
8 participants
This is an addition to the cryptography API to allow for efficient verification in the case where every blob comes with its own commitment proof.
The new function
verify_blob_kzg_proof_batchcan be called for any number of blobs and verifies their commitments using the individual blobs, commitments, and proofs. It is marginally less efficient than creating an aggregate proof for all blobs together, but not by much (ca. 300 us per blob).Update: Now changed so that the blob verification protocol only takes single blobs and commitments in order to simplify the protocol. This makes sense because the only application of aggregate verification would now have been transactions, and it makes sense to just change them to one proof per blob since then the proofs can just be copied by block producers (makes local block production cheaper).