Closed tarassh closed 4 months ago
Hi and sorry, I accidentally made a pr to original repo instead of the fork. So you can close it if you want but if you are interested in the use case and why do I need it feel free to consider:
I want to build DAS protocol similar to what Avail does with their light client approach. In nutshell light client need to pick few cells from data blob (a grid of kzg.Blobs) in order to verify if data is available. Each cell is a tuple (value, proof). So published data block has to have a proof to every value. Light client can query these tuples and verify them agains KZG commitment.
Existing implementation allows to generate a proof agains a random value but not within the polynomial domain. Also high level API calls have a bit of redundancy: results are serialised, and when they are passed into a next function they are deserialised. Not sure what are the benefits of serialising points and scalars all the time.
Here is a trivial snippet of what I want:
func main() {
var ctx, _ = gokzg4844.NewContext4096Secure()
// blob := GetRandBlob(123)
// file is packed into blob grid
blobs, _ := LoadBlobFromFile()
for _, blob := range blobs {
polynomial, err := gokzg4844.DeserializeBlob(blob)
if err != nil {
log.Fatalf("Failed to deserialize blob: %v", err)
}
commitment, err := ctx.Commit(polynomial, NumGoRoutines)
if err != nil {
log.Fatalf("Failed to create KZG commitment: %v", err)
}
for i := 0; i < 4096; i++ {
chunk := polynomial[i]
println("Poly ", chunk.String())
proof, err := ctx.Open(polynomial, polynomial[i], NumGoRoutines)
if err != nil {
log.Fatalf("Failed to create KZG proof: %v", err)
}
// Proof verification should happen in a light client.
err = ctx.Verify(commitment, proof)
if err != nil {
log.Fatalf("Failed to verify KZG proof: %v", err)
}
}
}
// Select a random proof to verify
log.Println("Successfully verified KZG proof")
}
Hey no worries :)
What you want makes complete sense. I'll be working on a new implementation that exposes this behaviour in the coming weeks. The (slight) issue with the current implementation is that it produces one proof per point being opened, whereas a "Cell", atleast how it is defined in the ethereum specs, can contain 64 opening points. For this, we can use a more efficient kzg proving scheme that allows one proof per 64 points without sacrificing much in terms of performance.
@kevaundray can you point me to this documentation, that actually might be my case as well.
@kevaundray can you point me to this documentation, that actually might be my case as well.
Yep sure, it should all be in this document: https://github.com/ethereum/consensus-specs/blob/master/specs/_features/eip7594/polynomial-commitments-sampling.md#compute_cells_and_kzg_proofs
Going to close this as we have started to add the above functionality into the library
can you say why you want to expose the low level API?