Add pi to BlobCommitment to enable optimized kzg commitment verification

[litt3]

Problem

• 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
• Looking at this formula e(pi, s-z) = e(C-y, H):
  • z is the blob hash
  • C is the kzg commitment to the blob polynomial p
  • pi is the evaluation of C at z
  • s is the first public SRS point
  • y is the evaluation of p at z
  • H is the g2 generator
• 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

[bxue-l2]

Related material. 4844 spec has a function definition for this purpose, see link here

But because 4844 treat the data as evaluation, the way to compute y is a bit different.