KZG Commitments, Layer 1 R&D - Day 1

[Music] all right morning everybody uh there we go we're online so i'm uh ben edgington um i self-identify as a writer and podcaster um right we're talking about uh kcg commitments i was deeply conflicted in preparing this talk whether to go with kzg commitments which is obviously correct or the more popular kzg we're going with kcg because it's slightly easier to say um so what problem are we trying to solve it sounds very mysterious right kcg commitment what prob and my job here is to convince you that it is actually straightforward and not scary at all so we'll start with a problem statement given a large amount of data these are the blobs that proto was talking about the the blob transactions so this is about 128 kilobytes um we want to do two things we want to be able to commit to that data succinctly so we want to short digest which is linked to that data represents that we know what it is and can't change it and we want later to be able to prove values um in that data set so we can prove that the value at position 10 in that data set was 27 or whatever it might be so we can do this with merkle trees we know how to do this it's tried and tested so committing succinctly to a data in a merkle tree is easy that's 32 byte root of the tree um and we can also construct proofs uh that we know what a leaf of the tree is which is a miracle proof but they tend to be a bit larger so um log the the width of the tree so 384 bytes if in this scenario with the ktg commitments um we can also do both so we can commit succinctly so 48 bytes is a um is a commitment to the tree that's an elliptic curve point uh but you don't need to know that and within the protocol we can further hash that down to 32 bytes so it's equivalent but where the real value comes from is making these proofs so uh we can prove any element in the in the data set using just 48 bytes and we can also use 48 bytes just the same succinct size to prove any number of elements so you can aggregate these proofs so that's why we uh want to do this what is a ktg commitment then well um vitalik's head on danny ryan's body says um you don't need to worry about it just treat it like some kind of specialized hash function that's got some some nice properties um nonetheless what's happening under the hood is that uh we have this data set um and we convert it to a polynomial it's a polynomial commitment and we do that using fast fourier transforms in protocol we don't need to worry about that that's the l2 people's problem um and then this polynomial we commit to it by evaluating it at a a random point and we don't know what that point is it's a secret and that represents our entire polynomial of course it represents any number of polynomials but the chance of anyone stumbling across the same one as us is infinitesimal and we generate this random point that nobody knows via a trusted uh set up ceremony there are two functions that we we need to be aware of there's the commitments which is taking the blob of data and making um a kcg commitment out of it um so we have the blob and its kind of blob shapes that's our 128 kilobytes of data we have the trusted setup which is just a set of elliptic curve points uh and we we zip the the two of them together so that's um making the kcg commitment the commitments in the middle is in an ellipse that's how you know it's an elliptic curve point uh it's 48 bytes when serialized um and then we take um for convenience a hash of that too because the evm is not very good at dealing with 48 byte objects so we hash it down to 32 bytes and this is what hashes look like in my brain so um that's the end and the point is the point for this audience is this is really easy this is three lines of code or it might be one line of code if you've got a live a crypto library that supports this the blast library uh implements a pippinger multiscale and multiplication and it just does this it's it's very very simple the other thing we need to do is is what's called an opening which is a bit pretentious it's verifying a proof it's like a merkle proof so we have our polynomial but it's represented by our commitment um we have two values we have an x value which is the location we want to prove the value at we have the y which is the value we believe ought to be in that position and we have our proof which is like a merkle proof but in this case it's an elliptic curve point um that's constructed by the person who makes a proof and then we have this verify function and this is a little bit of elliptic curve arithmetic and a call to the pairing function where the the magic happens and it's very complicated and we don't need to worry about it at all because it's just a black box so in eip484 again the code is in there and it's three lines long so both execution side and consensus side will need to make some changes to take advantage of this um kzg commitment uh technology uh on the execution side um there are two precompiles and these are for the use of roll-ups so there's a blob verification pre-compile and that's just blob to kzg so it's making this commitment um and this is useful primarily for optimistic roll-ups and then we've got this point evaluation precompiles this is verifying that we know the value the data we have is the correct data for that uh that point so that's a wrap around verify kcg proof so two precompiles uh there's an extra op code which is trivial it's just looking up um one of the commitments that we have in um in a block and um when verifying a transaction that a user has submitted that contains a blob we need to check that the k the kcg commitment is correct which again is the same as a blob verification pre-compile so under the hood it's the same code on consensus side and this is a lot more familiar because we're all already using bls 12381 elliptic curve libraries because we have this bls signature scheme uh i'm pretty sure all the consensus clients are using blast library though i'm not 100 certain but yep i'm getting nods uh on that um we need to add wrappers primitives um to them because the blast library itself doesn't provide these off-the-shelf functions but we need to add our kind of three lines of code blob to kcg um kcg to version hashes has taken a hash of 48 bytes which is trivial we don't need the verification of proofs we don't need to do the openings um on the consensus side we just need to check that the blobs match their commitment and also when we gossip blocks and so on we need to check that um so how do we just to summarize kind of where things happen and how we build this we have a library elliptic curve library bls 12381 curve at the bottom that's off the shelf and black boxed we have code to implement commitments on top of that we have code to implement the verification on top of that and then the on the roll-up side and outer protocol creating blobs you do with phosphoria transforms proof generation it's just some elliptic curve uh arithmetic and actually kind of in better proportion it looks like this we're just you know kcg commitments are just a very thin layer on top of this big library that already exists what is the current state of the art there are a bunch of stuff around i'm not aware of everything i put in bold the stuff which is either production ready or there or thereabouts so on the bls library level blast is has become kind of standard in the consensus world there's also harumi there's noble which is a typescript implementation stuff that already implements the code to do kcg commitments uh narc is consensus that some some of our colleagues at consensus that's basically production ready client um constantine i think is is mommy's thing hey mammy uh production ready yeah cool um there's go kzg which proto wrote uh based on sort of democrats kind of initial code uh ckg which is my port of that they do this extra um little bit to do kcg commitments they also do some mores add some data availability sampling things which is what most of the code in there is all about um so what's the gap between where we are where we want to be um we need we need these functions available in an audited um way we can either add them add the lines of code to our clients on the execution side and on the consensus side or we can put get them put into the standard cryptographic library i'm a kind of one crypto library maximalist really i mean i think there's not advantage to having multiple crypto libraries necessarily um so potentially getting blast to put these uh extra higher level functions in would be a good idea and we need to do a trusted setup and we've got sessions this afternoon on or later this morning on both of these things um looking at the maturity of the available libraries and on how we might run a trusted setup um for them and the last couple of slides are just reference so i'll share the link with everybody and you can you can check what's out there and that's probably enough for me [Applause] [Music]