ZK11: 1 Circuit, 5 Rollups: Building a Re-Usable DA Integration for ZK Rollups - Connor O'Hara

Transcript

[Music] uh my name is Connor and I'm an engineer and uh I work for Celestia Celestia is a layer one blockchain which is minimal and modular and it can be used in a variety of different ways uh some of the ways you might see Celestia used are for Sovereign rollups which are kind of like app chains uh or uh regular rollups which settle on some settlement layer or the most popular use case celestium which are when you use Celestia data availability

for a L2 that settles on ethereum this is currently the number one user of the celestial block space and it's also what this talk is going to be mostly focused on the title The talk is building a reusable ZK powered data availability integration for ZK rollups well I guess just for any kind of rollup but this talk most mainly about ZK rollups and while everybody here probably is already familiar with the concepts of rollups and data availability for the sake of completeness I think it makes sense to

quickly go over what these things are and how they work so rollups were originally conceived as a way to scale a lower throughput blockchain they were originally conceived as scaling solutions for ethereum and the general gist of how it works is you have a high throughput blockchain which produces Big Blocks with many many transactions from users and it will post its headers and a ZK proof to a lower throughput blockchain ethereum is the main example of this and that's a way to scale it it gives you a trust minimized Bridge from a low throughput chain to a high throughput chain as a scaling solution to go more into detail about

how a ZK rollup works you have your circuit which proves the correctness of a state transition the ZK rollup basically a big old State machine and what goes into the private inputs are transactions from users and then what other whatever other intermediate witness data that you need to prove the correctness of the state transition and then the public inputs shared between the prover and the verifier are commitments to the Old State and the new state or something like that I'm being very uh vague and general because they vary quite a bit in what exactly it uses for the private inputs and the public inputs so you have your rollup block

producer and your rollup block producer produces a big block for the rollup then it generates a validity proof for the correctness of that and hands the new header and the validity proof over to the verifier which in the case of an L2 runs on the evm in a settlement smart contract and once the verifier has the header and the ZK proof he knows it's valid right wrong uh if all the verifier does is look at the header and the ZK proof there's a way that he can still be trict which is if the role of block producer gives him a header and a proof

for a block that doesn't exist for a block that he deleted right after he created it and didn't share with anyone in other words if the data is unavailable so the verifier would be left wondering whether or not a block exists that corresponds to the header and proof that he's looking at so so we call this data availability the verifier needs some way to validate the availability of the data for the rollup block that he's looking at now what exactly is the data that needs to be available so remember the circuit for the ZK rollup and remember its private

inputs some subset of the private of the private inputs are necessary to reconstruct the state and produce the next state transition or for users to be able to withdraw their balances Etc we call this the pub data the subset of the private inputs which needs to be available or rather that the verifier for which the verifier needs to validate availability we call pub data this term I borrowed from ZK sync I believe they're the first people to have come up with the term Pub data thank you ZK sync for coining that useful term and there's three ways which we see data

availability being validated in practice first is the old ethereum way using call data the second is the new ethereum way using the blob space which was given to us in EIP 4844 as part of the denune upgrade and then the Third Way is with celestium the rollups which opt to use Celestia da instead of L1 da for one reason or another possibly increased throughput or decrease cost or something of something or other so let's get into it we're going to go through how each of these Ways work quickly in practice so for the ethereum way um prior to EIP 4844 back when all the ZK rollups were

using call data what you would do is you would have the circuit compute a commitment to the pob data and then add that commitment as a public input so what this the way that this is done is it usually just takes a linear kak hash of the pub data so um the state the state Deltas for example is usually what the ZK rollups require in the da and so the circuit will actually just hash them using kak because that is a evm friendly hash function and then when the rollup block producer goes to settle the rollup block on

ethereum of course he posts the L2 block header and the L2 State transition proof and the evm will verify that but also it takes the whole Pub data dumps it into the evm then the evm hashes the pub data and then verifies that the hash of the pub data that it computed in the evm matches the one that it got from the Block producers um proof with public inputs uh this is uh pretty well documented in ZK syncs docs as well as in a blog post by scroll if anyone is curious about how data availability is is done in ZK

rollups I'll let you scan that for another second all right but everything changed with the Denon upgrade and now ethereum has given us a bunch of extra blob space to use for da to massively increase increase the capacity of these rollups um but yeah so the the way it does this is it exposes this new API where you can send a uh so-called blob carrying transaction and that lets you that lets you get a 131 kilobyte blob and that goes into the block it goes into a special part of the block

called The Blob space um but you can't access the contents of the blob from inside the evm rather you can only access the kzg commitment to the blob in the evm but as it turns out that is sufficient to verify proofs about the blob which is all we really need when zare rups go to integrate 4844 they have to do it quite a bit differently than the old call data way that I explained in the previous slide with the kak hash now what they do is they add the kcg commitment as a public input but unlike with the previous way where we recompute the kak hash in

circuit you cannot recompute the kzg commitment for the blob in circuit because that would be a whole bunch of non-native multiscalar multiplications and it's basically completely infeasible luckily we can do it non-deterministically so this technique I first saw mentioned by vitalic on the eth Forum post in about 2020 and the general idea is you'll put the kcg commitment in as a public input and then you'll verify it uh with this clever this clever non-deterministic fimir trick where you compute a challenge Point by hashing The Blob with its kcg commitment and then

you evaluate the well you take the blob and you interpret it as a polinomial in evaluation form and then you use the Barry Centric formula to evaluate the blob's corresponding polinomial at this challenge point and then you take the challenge point and you also add that as a public input and then you have the prover compute a opening proof from The Challenge point to the kcg commitment and then the verifier then has to check that as a little bit of extra work but it's very very light verifying a kcg opening is is very very lightweight and it's generally a much better trade-off than doing anything crazy on the prover

side especially when all this nonnative arithmetic is used um so yeah that's that's how the ZK rollups are starting to integrate 4844 and a bunch of them have already done this EK sync and scroll uh as far as I know they both have code for this but what if 4844 is still not enough throughput for you or it costs too much or something or other and you want to use Celestia da on your L2 which is a um like I said before the the most popular way that Celestia is currently being used so to understand how we adapt the ZK rollups to use Celestia da we first need to go into how Celestia Works a

little bit under the hood so Celestia has giant blocks and it takes blob transactions from users and then for each block of IA it breaks each blob up into 512 by shares and then it lays the shares out in a 2d Square eraser codes them into a bigger 2D square and then it takes Merkel roots of each individual row and column and basically kind of unrolls the whole square and creates this giant Merkel tree um which the root we call the data route and the data root get signed by the validators as part of the

header and we relay this onto different chains notably ethereum so ethereum has all the Celestia blocks sign data Roots um as part of its state and we call this The Blob stream Bridge so now that we have now that you're given the data roots in the ethereum State you can just add the Celestia data route as a public input to your circuit and then you don't even need to prove a commitment you can just go straight to inclusion and prove that your Pub data is included it is a bunch of shatu 56 hashes so it's a little bit not ZK

friendly but they're getting pretty good at that at at those these days but wait this talk is building a reusable ZK powered d integration not rip up the rip up the pro side code and rewrite the contract for a bunch of different languages and proof systems so we want to build this integration in a way that modifies the rollup as little as possible we don't want to have to rip apart polygon stet Aztec scroll ZK sync right we would like to integrate them without needing to do too much modifications especially to the Prov side

contracts um and what modifications we do need to make try to keep them on the verifier side where it's generally a lot easier to change them to do Integrations so we keep the ZK rollup circuit the way it is and we build a new circuit for the integration and this circuit is pretty simple all it does is it takes the pub data from the rollup and it adds the Celestia data route as a public input and it proves that that blob is included in the data route and that it has the same

commitment that the ZK rollup was already working with before a nice thing about 4844 is that 4844 gives the rollups a standard commitment to use that we can very easily hook into back when they were doing call databased Da Integrations they did it differently some of them were doing linear K cash some of them might have been doing sha some of them may have been doing Merkel trees or various other ways to commit to it um with 4844 they're all going to do kzg and so it's one thing that we can reuse all right and uh a quick detour on uh circuit development step one before building a circuit try it into zkm and see if it's

fast enough which we did and it's certainly fast enough uh so our uh blob inclusion proofs run really really fast in sp1 and risk zero and now there's jolt which came out yesterday so I'm going to I'm looking forward to try to run it in that as well um and yeah there was already rust code for all the types and Merkel trees that are blob inclusion proofs use and both sp1 and risk zero provide Forks of the rust shatu crate which are patched to have cryptographic accelerator for the hash function and so getting this to work was extremely easy

and we were really impressed with the performance and it's faster than the L2 block proving time so the whole system will not be bottlenecked by the da integration and the da integration can run can start proving in parallel while the L2 block is improved so uh we feel no need to go in hand optimize a table for a stark to do this when the ZK EVMS work so nicely um and that is about it so uh happy to start taking questions yeah thanks can make sure yeah

you ask for the mic can you come in the front to ask you question so that it's recorded hi thank you very much for the very good presentation uh I have a question about the pub data what is the size of Pub data and is it all stored in the evm contract um what was the part about the evm contract the settlement contract on the rollup not on the rollup on the on the ethereum the B dat are ending in the ethereum right as input uh so it varies in size and with EIP 4844 all the blobs are a fixed size of 131 kilobytes so um I think what we're seeing in practice

right now correct me if I'm wrong is that they're not full rollups are um getting blobs and then not filling them all the way up but theoretically if there's more transactions from the users they might need multiple blobs and then there's right now there's a limit per block on how many blobs there can be per each ethereum block and then before with the call data I'm not sure I'm not sure what the limit was or what the like if you if you're allowed to take up a whole block so ethereum block with call data or not that's a good question okay and yeah what happens actually if the the block actually surpasses The Blob size and it cannot be posted on chain what will happen I mean it's committed on the layer two and eventually it has to go to

layer one so what am I missing here well um you know the rollup needs to be aware of what the max blob size is and it shouldn't produce a block that can't fit yes but all the rollups are racing for blob space right that's true yeah so so it's not something that they can calculate on goinging or is it uh well I mean like what a rollup can do is a rollup can say we're going to use one we're going to use one blob of 131 kilobytes and once they create a full block they just keep trying to get it into the L1 and if the L1 is congested then it has to wait or

start fighting with the other ones and then you're just out of throughput then the L1 is just needs to scale more okay I see thank you very much hey Conor um when we were talking about the the circuits you you telling us you could have a different circuit that will only verify the blob and would not like integrate in the other circuit I noticed there was an arrow there that actually had the commitment being committed by the original circuit I was wondering if the challenge Point has to be included in the original rollup circuit or if there's a way around it oh

that's a good question well I mean I tried to draw the arrows so that the challenge point and the kcg commitment go into both um but uh I it was a little bit frustrating to use the drawing tool um I think that both circuits need to have the challenge point and the kg commitment maybe there's some way around it I'm not I'm not quite sure so if I wanted to integrate this right now I would have to change the Z rollup circuit to commit to that that's the uh well so we don't actually have the we we only have The Blob inclusion proof this BL blob inclusion part side of the circuit

done at the moment and uh the this is first going to ship not with kg this is going to ship first with like a call databased one we're going to we're going to try this first with um polygon polygon Hermes which still does the K cash and the kcg side of it is kind of a more of a long-term road map to make it Universal and reusable cool hey yeah so just a quick

clarification here so the ZK rollup circuit is from the rollup itself and then the other two circuits uh are Celestia circuits correct oh uh yeah I should have said more about that so the da integration circuit is um is for the Celestia integration and this one here the outer verifier this is kind of like very abstract and vague so you could have the integration circuit and the ZK rollup circuit get verified directly by the evm um and then you would have the evm verifying two ZK proofs in practice though the ZK rollups all have some sort of outermost proof that wraps some sort of inner proof like for polygon Hermes

they take a Stark and they wrap it with Groth 16 and what would be more gas efficient is to actually just verify the integration and compare the public inputs in that circuit rather than doing two in the evm okay thanks uh and so I guess the point though is that uh the ZK rollup circuit you know you've modified that as little as possible so basically you've just added this challenge point and a little bit of stuff into there and everything else is out like outside the circuit or overlaid over this rollup ciruit yeah I mean if the rollup is already integrating 4844 then they already have the challenge point and the kcg commitment and we just will'll hook into that with our circuit I wanted to ask have you tried

benchmarking the price difference in US Dollars of using Celestia against using D sharding since it came out about 2 weeks ago uh I don't have the figure I don't know the figure off the top of my head unfortunately oh yeah like what is fundamentally changes

if if if the L2 is not ZK role another type of role yeah that's a good question so we have done um Celesta Integrations with two different optimistic rollups and for both of them we had to rip apart the code and deeply deeply surgically insert Celestia stuff into op stack and arbitrum orbit but theoretically if the optimistic rollup uses 4844 we could generalize this into a generalized 4844 compatibility layer which is sort of like long-term road map where we would have a bunch of kcg

commitments in the ethereum state and then proofs that those are included in the corresponding Celestia data route and and then the optimistic rollup could just modify their verifier a little bit to just look into that API rather than us needing to rip them apart as well so it is it is possible to generalize this tech for optimistic roll offs as well thank you initially you said you're using a matrix to put the data in a matrix what's the reason for that and is and why not use a cube or like higher Dimension storing

it um why don't we use a cube that's a good question I sometimes I wonder why don't we use a line but uh um it's the uh it's the it's the Eraser coding it has it has to do with the um like the the the way that Celestia allows light nodes to verify data availability using the sampling mechanism which I didn't want to bore you all with because it's been discussed on zero knowledge podcast in about four different episodes I highly recommend you listen to them to them though if you're interested because uh it is very cool sometime I come sometime I come and

then they ask question uh we have time for one last question if you were shy up until now you can still speak up okay we have one here maybe one last question that okay so what is the problem with The Blob scriptions I heard something that the blob space became like u a racing condition like an open market an auction based because of some project if you want just to comment on that I have no idea I've just read some articles to be honest sure um no yeah that is true so um the first few days of the Denon upgrade blobs were really really affordable and so the transaction fees on all the l2s were super low but if

some resource is free then people are going to start you know using it and bidding it up and uh there was an inscriptions project which is just inscriptions is just basically just wasting block space for fun and uh just paying money for fun to like put random stuff on the chain and very quickly those people got a hold of the blobs and they pumped up the price a lot it was going to happen anyway right cuz we we think these things will be used and we think there will be demand for Block space so like the blobs were going to go up in price eventually there was going to be some uh contention uh this is just accelerating the inevitable and yeah I mean thankfully there's lots of capacity they're going to add more blobs there's

going to be full dank sharting and there's also celest yet thank you okay thank you