ZisK: A zkVM Foundation for Next-Gen Blockchains | Jordi Baylina - ZisK

Hey guys, welcome back. Uh, we're moving right along. Up next, we're going to have Jordi Bellina talking about a ZK VM foundation for next generation apps. Hello everybody. I'm Jord Bellina from Zisk.

Uh, very quick. I mean, Zisk is, as you know, is 64bits ZK VM. I mean service 5 based and the main properties as is open source is uh uh security is 128 bits proven security and quantum resistant and uh well yeah we're we're building that for the last uh for the last two years currently. Okay. So but I want to talk a little bit today about the the the vision that I see uh from the how the future blockchains I mean how how the blockchain will look like in the future and it's just the vision I mean we don't have the crystal ball but just want to explain here so the idea is this important separation between data and execution we can understand that blockchains at the end is going to be just data availability maybe blobs okay and uh well uh this data availability will be when you execute this data you deterministically uh you will get a a state or something like that.

Okay. So the idea is I mean a good example for example is when you have a normal blockchain I mean normal blockchain you have a lot of transactions imagine all theum transactions uh from the genesis block you could execute I mean you could query these transactions and uniquely you could get a state okay and the cool thing of the zk thing is that you can do this query you can get this state and you can do you can have this proof that you have this state. So when you have a new block you can use this new state you can proof the the previous block you get the new data that's in the blobs and then you get the newest state. So you can this is a way of having also a blockchain. Okay but this extends uh this extends more uh to other things.

I mean I not only need to have transactions I can have maybe atestations or hash of other information there. Okay. And here is the the the concept of uh uh what we call dynamic consensus or uh static consensus. I mean dynamic consensus is the consensus that will reach every block. I mean maybe this data that appears in every block and the static consensus is how we process this data and this something that doesn't change.

I mean this is the protocol itself. I mean the how Ethereum process the transactions is something well it changes in the forks but in general doesn't change and this is the static consensus. So defining a new blockchain can be as easy as defining this static consensus and you just start putting data. So you don't need to do any fork on the main on the main chain. Okay.

Um so um well I'm going to assume but let let me explain a little bit so maybe a specific detail and this is how this model can be applied to have a um we call synchronous composibility between rollup apps or even between roll apps and and L1. So what's a synchronous compos composibility? Well, the idea is that if you are in a in a if you are executing something in the smart contract maybe mainet on one roll app, you can do a call to another uh smart contract that's in another chain. Okay, this call may return. Okay, and all these you do it atomically in a single transaction and this can here is two chains but can be 10 chains.

This call is maybe it's calling back, it's going the other. So, but the idea is that you connect the chain just doing a single call I mean a n code that already exist um in Ethereum. Okay. So let's assume first let's forget a for a moment for uh uh on the for the layer one. Okay.

So let's think about multiple roll apps that they want to connect all together. Well following the original uh schema that I mentioned before you can put all the transactions in the L1. So okay you have all the transactions. These transactions they may call one roll up to the other. They may call they may so one transaction may call three roll apps and another transaction can call four they affect five rollups.

Okay. But what's clear is that if you put all these transactions on chain you deterministically you can compute the state of all these rollups as if you execute these transactions in a synchronous in a synchronous way. Okay. So the you can have the same idea. The only thing is instead of having one state, you can have like three states, but you can put all the transactions that you want in um in in the blobs.

Okay. And then you just put it in there. Of course, you put it on you can put it in mainet and you put it together with uh with a proof. Okay. So, um this is a little bit how it would work.

Uh I mean this is a a block. So, we have 12 seconds of a block. So the idea is that you could build transactions. Of course there are transactions that may two roll apps. So you need to process the st the states in parallel.

Okay. But the idea is that while you're even while you're doing this where you're building this block you can also start generating the proof and at the same at at some point you can release all the transactions and you release the proof of these. So you can update this is the idea of the called base rollups here. Okay. This is the idea that you can in the same block you are updating many many rollups and all of them they they change the say all of them you you change the state at the same at the same at the same time.

Okay. Uh the important part here is that uh and this is what enables real time proving is that uh if you put the data and you put the proof at the same time this simplifies a lot the protocol. Of course you need to build this proof which is more expensive but this is what in Z we can do it very well but this is uh uh what allows to uh improve a lot on that. Okay. So now let's go a little bit quick about how you could do that in so how can you call from L1 to L2 and L2 to L1 even with even without forking uh today's Ethereum.

So how can we do this composibility between L1's and L2s? Okay. Well, for this let's start let's put an example here. Okay. So, imagine that you have a user A.

User A is called the DAO, but this DO contract at the same time is calling uh maybe a white list for saying if he can vote or can vote and then it returns back. Okay. But there are some smart contracts that are running in L1, some smart contracts that are running uh in in a rollup in a in a in an L2 in a rollup. Okay. So the first idea is okay we define this idea of proxy contracts.

I mean when we have the DAO that's running in L2 it will be a proxy. This is a counterfactual contract. I mean it's a contract that's still there that somehow represents the DAO that's in the in2 but it is running in L1. Okay. And his address is deterministically the address is a function of the of the of the address of the L2 and the and the and the chain ID of the L2.

Okay. So this is something that's uh contract that represents itself. Okay. And how this how this works. Okay.

Well the other part is that we are building so here we will build a set of executions. How we read a table of executions. Okay. So what this table means? Well, this table means um if you are if if this roll up one is in the state 0x111 or whatever and you do a call.

So what happen? Well, you are going to have this new state and actually the result is going to be this return or in this case because it's a nested call you and the result is that you need to do a call to another contract in L1. Okay. And we continue. So this is you see the execution this will do a call then you gen will be this will be this part is in the execution you you you probably you execute the is white list and then the return then returns and and here so you have this table of executions that happens here.

So how this would work? Well, this special proxy contract actually what it does it uh it starts with uh so it receive the call and this call it well when this receive the call actually it do a look it do a look up to this table it sees that is the call is the first the first line so actually what it does it uh updates the state of the chain updating the state of the chain is equivalent to actually executing this state because this is what it means and uh well the result is going to be another call. So this Dow is going to do the call to the W to the white list is going to mulate this call. The call is going to return. Okay.

And then this return it will check in this execution is what happen if you if you execute this execution with a new state in this case a ZX2 ZX2 in there. Well, you get another return and then this emulates back the return to the user. So the effect here is that the user um the user is going to be uh so it's like the same thing that if they were executing uh one uh one each other okay so how would this process be I mean if you are a block builder you want to execute this well probably these transactions maybe are going to be some meta transaction somehow but the idea is that first of all maybe you need to create this um uh proxy contracts so it's going to be in a single transaction. You are going to create the proxy contracts. You are going to send this state transition function.

This transition function will go with a single zk proof that all these entries in the execution table are right, are correct. They are following the the rules. Then you are actually going to execute these transactions following of course the calls emulated with proxies that were already developed that were already deployed. Uh then you do that. So they will be um simulated.

I mean they were going to be executed as it it was okay and well maybe it's a state that if you want to do more transactions that don't affect fruit lab you can put all these together okay and all this goes with a single proof that uh goes together okay so this is how uh it works okay the cool thing also of this model is the idea that the the rollups you can define your own kind of roll-ups I mean the roll-ups they don't need to be EVM rollups it can be was rollups or you can define your own standardization function The main idea is that the stand function can accept calls and can emit calls. Okay. But the call is the only thing that they need to they need to process as that. Okay. And even that the the good thing of this is that uh these calls without you can I mean you can do you can define an app chain.

I mean you can define you can extend Earium somehow in the with the state transitions that you want. They can be private. Okay. the and even if the state transition function changes or they have their own governance for changing this the state transition function this does not break the full of the networks of course if there is a malicious network this activating within malicious network it will be wrong but this will not affect the rest of the the rest of the chains is an exception if this call includes value it includes ether then uh of course you need to take in account that so the maybe the smart contract in L1 is to keep this accountability this into rollup uh compos um uh uh on that but that's fine I mean this uh you just bring this accountability so that a rollup cannot send cannot call more value than the one that received before that's the only thing you need to take in account and yeah so well just a couple of things on that all this system it's absolutely orthogonal to preconfirmations I mean pre-confirmations is another story and can be built on top of that so if you want to accelerate the the blocks this is for uh other And uh also is that what I explained it you don't even need to fork. I mean we can create that without forking uh L1.

I mean we can start building tomorrow. Actually we start we started somehow to do some uh some work on that. I put here for reference here are some work and some papers and some work that we are start uh uh working on that. And yeah, I mean coming back a little bit to what this this is just an example of many other things that you can use uh with DK and to finish uh my presentation just a quick update of the current status of um the current benchmarks that we have in uh in in in Z today. we are able to prove in real time uh with 16 GPUs we can prove almost all the blocks in uh real time with an average of 9 seconds and in the upcoming version I mean the 07 that we probably are going to release during the next week we already expect a 30% uh improvement there okay uh currently the idea is that this version is going to be frozen is going to be uh stabilizes uh we need to build a little bit the packaging of all that I mean SDK and document mentation on that.

Okay. So maybe 08 it will contain all these packaging on top of that but then we want to focus very much on uh on security and formal verification and making this uh very provable. Okay. So that's it. Uh that's what explain if anybody want is interested in CK please use it.

We are here for the community and we want uh the community to use it. Thank you very much.