You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the process for a client to verify the kzg commitment contained in the BlobCommitment involves recomputing the commitment, and checking whether the computed commitment matches the received commitment
This is not always ideal, since computing the commitment requires the blob to have SRS data for the whole length of a blob (currently 32MiB, could be increased in the future)
Optimization
The proposed optimization involves computing an opening pi of the kzg commitment, and including pi in the BlobCommitment
With access to pi from the BlobCommitment, a client will be able to check the equality of these pairings, thus verifying the commitment without any SRS data
Implementation Details
pi must be added to the BlobCommitment
any party creating the BlobCommitment will be responsible for also computing pi
this is either the client doing the dispersal, or the disperser
Problem
BlobCommitmentinvolves recomputing the commitment, and checking whether the computed commitment matches the received commitmentOptimization
piof the kzg commitment, and includingpiin theBlobCommitmente(pi, s-z) = e(C-y, H):zis the blob hashCis the kzg commitment to the blob polynomialppiis the evaluation ofCatzsis the first public SRS pointyis the evaluation ofpatzHis the g2 generatorpifrom theBlobCommitment, a client will be able to check the equality of these pairings, thus verifying the commitment without any SRS dataImplementation Details
pimust be added to theBlobCommitmentBlobCommitmentwill be responsible for also computingpi