Real-Time Proving and Synchronous Composability Between Rollups

Transcript

Welcome. [applause] >> Well, hello everybody. Um, well, today um let's know if it works. Yeah, today um and I I will divide my presentation in first a few um a small update of the status of ZISK and then I'm going to go a little bit deeper in how to build the easy proof especially for the proving systems how to use ZIS to build the easy proof and see all the advantages that CIS have to build that proof and what are the challenges that are there. If we talk about Zisk, as many of you know, ZISK is an open source ZKVM is based in RI 5 64 bits. It's fully open source.

It's fully quantum persistent. It's 128 bit security. And uh today we um know if this works. Yeah, today we are announcing what's this 1.0 alpha. So 1.0 what it means is uh I mean we just freeze the just freeze the code. We say it's alpha. So everything is there. Everything is in place. Everything can be used, UX is used. Uh we don't want to call it uh like a final I mean we don't want to remove the word alpha because the security I mean I think we believe I mean we strongly believe in security and uh we are not uh still 100% confident. I mean we are still we just changing some

lines of code a few uh uh weeks ago. So we are not 100% confident that there is no soundness errors and and so and in today's days uh AI is taking an important place for auditing by formally refying all these smart contracts and this is very much the current work that we are doing right now but uh especially for projects that they are building their own proofs system is there is available you can start using and uh yeah we we believe that's quite deliverable u except for this auditing that's going to be the the the main work for for the next for the next uh for the next month. Okay. We're also introducing what's uh kind of a toy but is a a zcat one. This is a full Ethereum client is a

is a uh it's a it's a stateless client uh and it's optimized uh for this actually this is with this client proofs can be uh so we get an between 10 and 50% uh earnings in proof uh cost and is full client design from scratch using AI and it's interesting to mention here that right now writing a full Ethereum client in two in two weeks is a crazy is a crazy thing but something that you can do it today.

Okay. Okay. Let's go to the to the easy proof. Okay. So well Martin already explained what's easy about synchronous composibility uh you know this this this challenge here. So what happened? So when doing when we're talking about the synchronous composibility what's really happening here? Well what's happening is that we have one one call at some point. So we have one transaction that some point is calling a smart contract that's another chain and then returns and continue execution. So we see this kind of context uh switching I mean you are running in one chain you context switch to another chain and then you go back to the other chain. So easy uh so in easy mainly what we do is

we collect all these state all these context switching between chains and we can put them in a in a lock. I mean is all the all the things that sequentially are happening. So I start a transaction. This transaction is doing a call to another chain. This other chains do a return and then we end the we end the transaction. Okay. And we can set up this in a log. You can understand that this is going to be in the blobs. Okay. And all these all these calls I mean or returns all these uh context switching they're going to be in a blob. Okay. So that they actually and uh if we summarize is we have u current states of the rollups. We have these logs of things that are happening can be transactions or calls between uh calls and we just want to prove that these

state transitions that are happening in this different chain are consistent with the blobs that are there blobs are format are consistent and all these generate the the the places and of course the when uh these calls affect the L1 because everything that happens in L1 is actually executed uh following the same the same rules. Okay. But from the proving perspective, this is very much so what we need to prove. I mean this consistency between the the states that we are changing and the and the and the locks that are happening here. Okay, this is a more complex uh idea. So here is instead of having uh one roll up and one call here we have three roll apps

one each one calling uh one another and with nested calls and you can add even an extra thing here is that can be uh reversed I mean these calls can revert so maybe there are some states that they just need to revert to some specific state so things are a little bit more complex but at the end it's just a lock of things of of context switching that are happening Okay, another important concept I mean before going deep to the to the to the to the proof is the I mean the text I mean the idea of the state transition function uh here is a we call it action-driven state transition function with it's a very specific it's a little more more deep I mean in in a

normal chain you have a state you process a transaction and you get a new state okay in this case uh we don't have really we don't have only transactions because I mean when when we have a call I mean this is not really a transaction. It's just a uh each of the pieces. So it's something it's a piece of code that's executing um in a given in a given moment. So I'm doing a call and maybe the result is uh so the end of this um action is that this call is not a return is maybe calling an instead call in another chain. Okay. So we have this idea of so we have an action that can be a call it can be a return it can be a same transaction and you execute something you change the state. So something is happening here and then you

get a new you get a new state but you get another action that happens uh continues. Maybe this action can be an end transaction if it's an end but it can be maybe another call or a return to the previous call. Okay, we have also I'm going to pass here we have also some revert info that this state function can give if there are some reverts that happen there. But this is important. So and this is very much what a chain needs to define. I mean these rules is what a what a new chain can be defined. These rules can be ethereum if it's an EVM chain but it can be maybe a wasam chain or it can be any any sort of chain. The nice thing of of of easy is that uh each uh chain can define their own state transition function and it's full

control of this. Okay. So if we see the call I mean if we see the proof and the things that we need to prove it's mainly we need to prove three things. Well the first is we have these blobs. Okay. So we have this the these locks of um um context switching that are happening calls returns that goes from one place to the other. Okay, this is a blob. So we need to parse these blobs. So we do all this is encoded in blobs. So we need to parse these blobs. Okay, check that the consistency everything is matched so that there is no lost calls and so that everything is correct in there. Okay, this is what the each blob proof. So we can have a blob and then I get a blob proof and then the consist of these blobs. Okay, the other thing that I need

to verify in chain is this um uh actiondriven state transition functions. So I want to prove that each of the individual each of the individual um each of of the individual contextes. So it is these green squares there. So this these parts are essentially correct according to the uh rules that the change define all these chains they define it via a verification key of a specific circuit. Okay. So this is the ADSTF uh adapt uh proof and adapter. This is what's verifi doing these parts.

Okay. And the other part that needs to be done in the proof is um I mean collecting all the information that comes from L1. I mean I want to build the proof that I mean this if you start with this state or I need to collect for example the verification keys of the different chains or I need to collect all the interactions with L1. So everything that happens to L1 and it's something that's going to be in the smart contract in the call of the smart contract. I need to verify that this is correct according to the lock that's happening there. Okay. So we have like three pieces we have like these three big uh proving parts. Okay. And then all these needs to be aggregated and at the end generating a prof. Okay. In order to do that in this we are using a I mean

it's what we call it's a cryptographic accumulator. Okay. The idea of a cryptographic commulator is kind of a hash function but the idea is not I mean it's for sets. Okay. So the idea is that if you have uh um two elements and you hash them I mean if you hash normally it depends on the order. Okay. The idea is that uh in an accumulator when you have two elements and you hash them it don't matter if you uh switch or reverse them. Okay. So this is the idea of the uh cryptographic uh uh cryptographic accumulator. Okay. And the cool thing of this uh uh uh structure is that in this uh it allows you to have like many proofs. Okay. And each proof can add something things to the accumulator can

add elements which are hashes of something and can subtract things from the element. Okay. And the the full idea of building this proof is that we can divide the the work of this proof in these different different elements and when we aggregate at the end we are adding or subtracting this accumulator. So aggregating is just adding the accumulator. Uh so and at the end uh the accumulator needs to be zero. So everything that's um added needs to be subtracted. Or if you want everything that's proven so when we want to actually when we assume something we add something to the accumulator and when we prove that assumption then we subtract that accumulation. So at the end everything that's assumed is proved.

Okay. So if we see these different pieces for example when when we are processing a blob actually what we are proving well we are proving that the blob commitment so the blob commitment that will come somebody is I'm proof that this blob commitment is is is correct okay so I'm in this case I'm subtracting from the the proof there what I am assuming I'm start I'm assuming that u um the starting uh rollup state uh of the at the blobs the starting the roll states that happens at the stop are given once I'm assuming this okay and I am proving I'm proving that at the end of the rollups this is going to be the the state but in order to do that for example I need to assume

that the uh state transition functions of each of the states are correct okay so if you see for example in the next in the in the in the adaptor in the in the state transition functions actually what here I'm proving it so I'm subtracting them so whatever I'm assuming in the in the in the when I'm parsing the blob, I'm assuming that this state transition function is correct. When I'm parsing the the the the the the when I'm when I'm verifying the state transition function of a given uh slice of a rollup, I'm proving so I'm subtracting. So at the end, everything that's uh assumed it's added, it's subtracted. So at the end, it needs to be it needs to be zero. Okay. What else

uh is here? Well, I'm assuming here because this is they have different rollups. So here I'm assuming that the a given rollup app ID has a given proving key. So that the state attention function is that. So if I'm using this roll up, I'm assuming that this roll up is ID and this somebody needs to tell somebody needs to prove that uh this rollup ID has this this exact verification key. Okay. And also here I'm assuming a lot of L1 transactions. So everything that is L1 transaction I need to assume that actually these transactions are in the are in the hash or are in the in the L1 transaction.

Okay. And this is where the third uh part the is the hash composing I mean this is just taking a lot of parameters and composing a hash. Okay the hash of an L1. So here is all the information that's coming um from L1. Okay. So in this case for example I'm taking all the blue the blob commitments that so I'm here and this this this proof actually is building a hash. So I'm taking all the blob commitments as I'm there I'm putting them in a I'm building a hash. So with this I guarantee that the blobs that I parsed in the blob u in the blob provers are actually the ones that comes from the L1 that's telling me that are happen in the L1. This is how I link what's happening L1 what happens in the

proof. Okay, in the other side they have all the u uh starting blob roll out and the ending blob rollup. So the rollups is keeping all the roll-ups and this is very much so the the starting block rollups this is again this comes from the the this this um so this comes from the L1 so everything that's coming from L1 here I'm proving that in L1 is uh there is some uh uh state transition functions okay and then the in the in the blobs in the blobs uh I'm uh I'm uh uh assume so I'm assuming so this is I'm what I'm assuming is what I'm starting here you see that when I have like different blobs that they connect one each other so the starting of a blob is

added and the so the the ending of a one blob is um uh added uh so it's subtracted and the starting of the next blob is uh added so one one cancel out each one so at the end you have in the accumulator only the starting point and ending point okay and this is what in the in when I'm meeting the hash this is what actually I'm putting in the hash and this is what I'm the information that I'm putting to uh to the to the L1. Okay. Um of course here um I'm hashing all the L1 interactions. All these L1 interactions is to be in the call data on the when I'm submitting a blob. So so and this is going to be some structures that will be in the smart contract that are the ones that will be executed that will execute it in easy so that when

there is a some roll up two that's calling a rollup one this code is executed in L1 and the other way around. So when something is happening in L1 that's calling to L2 well all this interaction is record here so that everything is proven in the L2. So all these L1 interactions are also um proven here assume when I'm parsing uh the blob uh there okay and finally this is important is the the the verification key for each uh for each roll up. This is um this is important and and tricky. Okay, because verification key is variable.

Okay, so this is a so I'm here what I'm saying is I'm proving so because this comes from the hash or here I give the warranty that the proving key has this verification key. Okay, and in the uh in the in the in the in the in the pars uh in the blobs so I'm assuming so this roll up and the verification key important to mention here that this is this idea we have the proof and the adapter. Okay. And this is a trick interesting trick that we are doing here because we are proving something that's valuable. So we are proving something we are proving in advance. I mean a rollup.

So you need to have a prover that's proving something in advance according to some verification key because I mean a rollup uh that it will be added um next year. It will have its own uh state transition function. So it will have a will have a circuit with its own verification key. But we need to guarantee that this this everything matches. Okay. So the idea here is that we do a one uh recussion level. So the the circuit will define its own statization function. It's all circuit. It will have its own verification key. This is what will be um configured in the smart contract. Okay. And it's going to be when uh trusted smart contract this this adapter that recursively will verify this u this other circuit according to the verification key and

we'll add to the accumulator of the full proof that will prove that this um um state transition function of for this uh roll up is correct. Okay. And having this u idea of this adapter that connects it's double proof I mean that refies is what allows us to prove things that are not defined yet because they are depending on the verification key. Of course the circuit needs to follow some certain rules but but because it's just the verification key is very short but that's but that's the the the full idea of the uh of the of the easy. Okay.

Um once we have this of course we have the aggregation circuit. Aggregation circuit is just very much is proving. So so here um so the aggregation circuit they just takes um two proofs of any kind and it adds the accumulator and it proves both sides. Okay. And it generates a new proof. Okay. And you can aggregate aggregate aggregate until there is just one single proof. And then there is a final and there is there is a final circuit that actually verifies this aggregation circuit plus the the L1 uh hash proving because in L1 you have only one hash so you you have a single one and finally and finally we have the plon uh so once we have this proof we can convert it to a plunk so that's

easily verifiable uh easily verifiable on chain okay and well and here is a challenge I mean we need to build all these these proofs we need to build all these proofs um um really fast I mean ideally in a time block. Okay. So this structure what allows is this can this model and important to say that for example we are start so when we are building a proof at that point we can start build so when we're building a a batch of uh of of of transactions we can start building the proof very much at the beginning as we are adding because we are creating a blob we I can start generating the proof for that blob um

and creating a transaction I can start generating all the state transition proofs for those transactions And the cool thing of this is that aggregation first is super fast. So one aggregation circuit it takes like uh um about 80 milliseconds. And the second advantage is that this aggregation does not require any order because the the idea of this accumulator don't matter the hash is exactly the same. So um you can accumulate you can aggregate as you generate. So you generate two blobs you can already aggregate them. Okay, you aggregate aggregate aggregate. So the final so the idea is that we the last three seconds is this is when we are doing the final part or this we are

trying to reduce this but uh the idea is that when we are when we reach this point that the the we stop building it the remaining work for generating the proof needs to be minimal. Okay. So this needs to be in a pipeline way and this is um one of the important properties of uh uh of ZISK that uh I mean that we are building currently we are in 3 seconds. I we believe that we can go even even lower on there but this is the real challenges that uh we are working for for for for easy. Okay. Um as I mentioned before uh currently in this we are very much uh so we just launched 1.0

so it's very much is about auditing uh going deep using AI for formal verifying and and and and there are some uh well just focusing uh stabilizing this uh circuit. Okay. And of course in this building all the easy uh proving system so that works as soon uh as possible and here is a list of of course in this we have a list of u other topics that are interesting but are a second priority at this point. Okay. So, but it's like well one is quite important is moving. So I don't know if people know but uh in so there are some there are some concerns about uh poson functions

actually posedon 2 is somehow deprecated uh people is going back to poson one and it's possible that we may have some version for blake because I mean cryptographers don't like uh this um arithmetic uh functions and for us uh uh for us is important and the other things are things about optimizations this BA uh improvements. I mean there is a other things that are interesting. Okay. So I want to finish here and absolutely open for questions. [applause] Thank you very much. Uh we have time for two questions for Jordi. Does anybody have a question they want to share?

>> Yes. Up here at the back we can get a microphone up there. Give us a couple of minutes. You're a long way away. >> Uh, hi. I have a um I was just wondering when you think of like synchronous composability and what it can do for rollups to kind of have like atomic kind of crosschain interactions. Uh, do you think that kind of like paradigm could benefit mainet itself? like if you were trying to pursue some kind of like native sharding, could you kind of use this technology to actually um use like like create one big L1 essentially instead of relying on like separate L2s if you know what I'm kind of mean.

>> They are not I mean um yeah these are two models uh but this is like thinking that u you can scale I mean you can do all the computations in the world in a single processor. Okay. So definitively uh there is a lot of u motivations for having L2s. Of course one is to um uh split the work especially for example when an L2 has a lot of transactions that they touch only two only transactions. You can process much more of them. So first is the capacity. Okay. But the other thing and this is the probably the one that I like more is that this allows you to extend Ethereum. I mean this idea is not only so having

many rollups is not about u it's not only about u doing ethereum bigger it's extending the functionality of ethereum this allows you to build your own chain that maybe is a specialized for voting or maybe your chain is a private chain with your own rules uh Martin before was talking about uh opinionated chains and you can have a chain that I mean definitively you can decide to change the state route if there is an hack uh from an attacker. This is not acceptable from the the perspective but maybe perfectly acceptable actually required in a in a specific uh roll up. So this is another motivation for having rollups. So the idea of u having many chains it goes

beyond the scalability which it does. It's more about extending about building um I mean expanding Ethereum expanding the functionality of Ethereum and making Ethereum more um specialized for different applications keeping the essence of Ethereum which is the composibility so that one chain that maybe it's private that belongs to some uh exchange company that has its own rules it should be able to call maybe arbitrum or call uh uh some smart contract some unis swap calls a chain of course will have the the same the same

rules I mean a chain will see that is receiving a call and it's giving back a return okay and when you are connecting to this chain you will get a call and receive a return and you want like an oracle okay but you don't depend on that another important thing that mentioned here is um and this is one of the designs that we're me we are not mentioning very much but this This is important and easy. So one in order to follow a chain you don't need to follow all the other chains even if you connect to those chains following a chain is just following L1 following those lops extracting information because in this in this in these things you you get all

the inputs and outputs that you get from your chain. So you can extract all this information so you can rebuild your state of your chain ignoring what's happening in the other chains. You are just getting what affects to your chain. So this allows to scalable. So having different chains. So not everybody have to synchronize everything. You are synchronizing your chain synchronizing your chain. Of course, maybe the composer if they need to connect to chains, they the composer probably will have to synchronize with chains, but it's just the composer, not the um an RPC client that's just uh providing some information. So, it has a lot of advantages. So it's u uh I mean and and and to be clear I want uh Ethereum to scale as much as I as we can and and we

need Ethereum to scale and it's important that L1 scale as much as important among other things because for example one of the limitations if you're talking about one of the limitations of easy is for example that the data the data availability we're talking about the blocks we're putting a lot of information to the blobs so we need high data availability in Ethereum but one thing is the the blobs and the Another thing is the is the the in the Ethereum u I mean it chain okay [snorts] haven't talked about validiums okay validiums again it's perfectly possible for um validiums to connect easy the only thing is that the state um you the difference is that in order to build the

full state of a balium you need some extra information that comes from other sources this is perfectly valid because you are setting up the I mean you are setting the Okay, the only thing is that in order to do calls to this um um to these chains or the other way around uh the composer needs to have access to this data. Okay, but because there isn't there there is this independence other chains that connect to this chain they don't really need uh um to have access to the full bidium chain. They need to have access to the interactions that this is what's in happening in the in the blobs.

>> Okay, thank you very much Julia. I don't think we have time for another question, but if anybody does have more questions from Jordi, I'm sure you'll be able to find them in the conference. Thank you very much. [applause] Next up, we have another another easy themed talk. Um, I'm very proud to welcome Philip Shamos to the stage. Um, Philillip is the head of infrastructure at Nosis. Um, in most appcons he has the job of coming up and talking about glamorous topics like hard forks. Today he has something even more exciting.

He's here to talk about the technical implementation path for Nosis Chain with the easy framework.