NEAR Whiteboard Series with NEAR | Technical Deep Dive Sessions, 16 Aug 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: Whiteboard Series with NEAR | Ep: 50 Bowen Wang & Matter Labs Unpack ZKSync

Description

Marcin Michalski , Chief Protocol Architect at Matter labs and Stas Bezkorovainyi - Software Engineer at Matter labs - unpack ZKSync alongside Bowen Wang, Protocol Director at Pagoda
--
Join NEAR's community:
Website: https://near.org/
Reddit: https://www.reddit.com/r/nearprotocol/
Discord: https://near.chat/
Medium: https://medium.com/nearprotocol
Blog: https://near.org/blog/
Twitter: https://twitter.com/NEARProtocol
GitHub: https://github.com/near https://github.com/nearprotocol
Dev Docs: https://docs.near.org/
Create a wallet: https://wallet.near.org/create
Apps on NEAR: https://awesomenear.com/
Learn to Build On NEAR: https://www.near.university/
Grants & Funding: https://near.org/grants/
#Blockchain #FutureisNEAR #NEAR #nearprotocol
#nft #dao

A

Okay, hello, everyone. This is Bowman from near welcome to another episode of the iport session, and today it's our honor to have folks from Zeke Singh. Here, uh let me introduce you: I'll have Martin and stats from metal labs and yeah. Do you guys want to talk uh just like briefly introducers of an or like talk a few sentences about what what you guys are working on.

B

So we do the ZK, but like we're, we're from matlabs we're working on the ZK sync, which is currently the top ZK proof L2, and during this whiteboard session, we'll explain to you a little bit more. How what? What does it do, how it works and all the cool things that are already there and even better things that are coming very soon.

C

um I think Marshall has already said most of it. The keysync is an L2 scale in solution, so basically our job is to make a system which has the same security properties as ethereum, but a lot cheaper and with battery ux.

A

Okay uh sounds good, I, guess yeah since uh you're already in whiteboard sessions, we do a very deep technical dive, so um maybe be good for um like either one of you, maybe both of you to give us an overview on the technical level, how the executing works and then we will dive uh deep into some specific topics, sure feel free to grab the marker right.

B

So, basically, during this session, we're gonna split it into roughly three pieces, so first we're gonna talk about what l2s actually are, how they differ from l1's like near Solana. Second, is we're gonna talk about? You know how we utilize the zero knowledge proofs and how do we compare with other l2s that are depending on optimistic rollups and at the end, we're going to talk a bit more about scalability how they scale and how do we plan to scale it even more coming in the future so yeah? Let's, maybe quickly start off what is L2?

B

How does it differ from L1, so the main goal of the L2 is you want to have something that can stash mention can share the security from ethereum like if you think about l1's l1s are like independent Islands. So if you, if you imagine this is like ethereum- and this is another one like near they're- fully independent- if something bad happens to near it won't. But if it did it's it's independent from from ethereum they don't they don't directly interact.

B

The goal of the L2 here, like ZK sync, means that even if something bad happens to it, the security is actually on the ethereum layer, which means- and we've got to dive deeper into this in a second but the idea being that, even if something bad happens to the company, you can still recreate. You can still get your funds out. You can still recreate the state, even if there is malicious things going on out.

C

So practically it means that on L1 we would have a smart contract to which which will store the root hash of the L2 state and the the main job of nl2 is to, and the its architecture in general is to ensure that its state is always updated. According to rules that is uh typically L1, they need some consensus, they're already in consensus for, say, security to make sure that all the computations are valid, but in case of l2s they're by Design work correctly.

C

If, if the underlying layer is correct, so that's the the main promise and that's why building notice is a lot, sometimes maybe a lot easier than l1's, because consensus would be needed for censorship resistance, but for security itself, you can get it right out of the box.

A

Yeah sure I think um you guys mentioned this very interesting part, which is just a kind of interaction with a one right. I think that maybe we can dive deeper into what the smart contract does and and how it's um kind of maybe the full like life cycle of interaction between like L1 and L2. Maybe, let's yeah, maybe let's start with like describing a bit about what that smart contract looks like right. Is it is it just like? Is there anything special to it compared to like other smart contracts on each.

B

Sure so the way, if you zoom in into this picture, basically, if we Imagine This, is the ethereum, and this is our smart contract in there. So the important feature the smart contract need to have is on one side. It should verify it should verify that things that are happening on L2 are actually legit and later we're going to talk about the difference between like optimistic verification versus EK saying, but the tldr is like this contract. If something goes wrong, this contract should react.

B

The second thing is for the whole stage. Recovery L2 is an L2 at least to the full L2. It's a roll up. If you can really recover the state based only on L1 data, so this contract is somehow keeping all the you know, all the necessary States, all the state Deltas, what not inside and last but not least, this contract is actually also keeping the value when you think about if it exists on L2 from the L1 perspective, it's hidden inside this contract.

A

Yeah yeah I think the uh the the maybe I think that the first two parts are probably like has a lot of stuff underneath that we can have like a multiple hours of conversation just about them, or maybe, let's start with something simple like how does the uh like the value part work right, let's say: um I'm a user I store like some usdt or usdc on uh dick, is in college that actually uh reflected on on L1 yeah.

C

So only one um okay, so right now I'll talk about the first version of the casing, because it was like a bit easier, simpler, but the second version is uh slightly more complex, but no, not that much okay. So there it worked like that uh users. Here's a contract on ethereum use, there's a function for depositing and now, when users deposit uh some funds, they transfer them to this contract.

C

Basically, and then uh there is, there would be like a certain we can say queue of operations which coming from L1 to L2, then this deposit, it gets appended to this queue and then, whenever the operator of the nl2, when it tries to push a new block, create a new block, it sends his transaction here and that besides some various other data about transaction It, also says: okay, I processed some like, for instance, three deposits and then uh through and then like these deposits.

C

They just get popped out of queue and if the verify process is secure, as Martian said, it is achieved by different ways in different Roll-Ups. But uh since verify process is secure, we can be sure that if this guy indeed process three deposits, then it was also reflected in the state route which was published here. It's like.

D

C

So like when the block is proposed also the new State Route is published as well. So now we know that this the good photo reflects that certain addresses for which the deposit was done now contain the balances.

A

And and when you say deposit here doesn't mean like, um does it work for any like erc20 token or like? Is there some like restriction for.

C

40 years it went a token it's just that uh in the first version we only supported. We can call it simple. Let's say 20 tokens in the sense that if you deposit X tokens, you can only get X tokens back.

C

So there is no room for like tokens which you can deposit, and this time you retrieve like 2x with yeah in the second version of the kissing, whenever a deposit is done, it's actually being done like as a call to L2 contract, and then yes, and then this and in the second version, this L2 contract could, for instance, uh withdraw some larger amounts. But if it implements it on its own and.

A

Then for easy self, you need to wrap it first and then, like yeah.

C

Yeah for for each it basically maintained in this contract and on O2. It says that okay, now, this balance has certain amount of heat here.

A

um And how this and and so basically, from the L1 point of view, the contract is holding all that balance right.

C

So from L1 point of view, this is just a simple contract.

D

C

Yeah, it's just you know whenever uses the interacts with it right, just normal interaction on layer, one right and whenever a new block is pushed still too it's just a again normal interaction with this contract, just done by a different user called operator which.

A

Operates the blockchain and then like internally, the uh the usual balances are kept in the L2 state.

C

Yeah so like yeah, all the balances, like their plain text, say it's just it's only Captain O2 right and.

A

The the audio state is essentially the yeah, maybe I'm, going to briefly touch on the uh slightly more complex topic or maybe much more complex topic of State. um The my understanding is that L2 status has to be fully compatible with L1 state, in the sense that you need to use the same state structure and so that you can oh, it doesn't have to be. Okay, no.

B

It doesn't have to be like the way the way to think about it is like so yeah. We can talk about the state part, so there are two cases that we need for States. So the first, the important thing is, you need to be able to reconstruct the full state right of L2 based on L1. So this is one, and the second is state is also used for verification. So the way the stuff is being pushed is we do push. Let's call it like a state route of a miracle tree.

B

Where is a Merkle tree or a vertical tree, or something else it kind of depends on on the contract itself, because.

A

This doesn't it's like astrological one you can. There is a way to verifying smart contracts. Okay and.

B

Then, roughly there are two approaches of what you can do, what you can put inside the state, so some people I mean some companies are putting the all the inputs of the transactions. So if you imagine the transaction coming into L2, they just put all the inputs. In our case in case of ziki sync, we are putting actually the outputs putting the state divs off this right.

A

Yeah yeah, yeah uh I think that's a very interesting part, maybe we'll dive deeper into that after, but like um just talking about the state itself, like um you said like yeah, this doesn't really matter what format you have as long as you kind of like do like a state produced and so on. So like what does the kissing use today for uh the state.

C

Our current state is basically a miracle tree, okay, uh for which, firstly, we have a few uh shards, which is Resort for, like some possible features in the future. Okay, like uh ziki Porter, not sure if, if you'll have enough time to discuss it, but we do talk about it sometimes and okay, so the currently used chart like so. Firstly, there are I think eight eight bits. Like eight eight layers, then the only chart is the roll-up one, and then we have like.

C

256 B3 like uh so what one key means. It means just uh that for if some address under some key was written, then the wiki in this Merkel tree. It would be hash from address and key and to add to the point of marching that the state does not need to correspond to ethereum on ethereum. All the state- and you know the mainly used hash function is yeah and where everywhere instead can check is used. But in our case we use the more ZK friendly function.

D

C

D

C

Yeah we use Blake and that's one of the examples, so basically only one, we just store this miracle root and with each verify step we prove that okay, like after this block, has happened, we transferred we correctly transition from this Mercury to some other one.

A

B

It's actually the interesting part. It's it has a fixed depth. Oh.

A

It's just like it's.

B

Always the Deep: this is partially because of the of the zero knowledge proving this makes it far easier to do the xenology proof. It.

A

Has and then what is the The Depths 200? Oh 200, of the devs history? Okay, okay I saw the wishes 256, but then what is.

C

The oh! No! No! It's it's that! Okay! Sorry!.

A

I meant like okay, okay, yeah, that yeah and then, but what's the what's, the wish on the like on each level.

C

No, it's it's porous Merkel tree.

A

C

It's just which is needed. Okay,.

A

Okay, um that's quite interesting, um yeah I think that's! Maybe the question for now about State um yeah. Should we talk about this um like what the kissing is doing differently from other people by um I guess this is relates to the data availability um of um of Altus, but I think the kissing is putting State tips, um L1 versus um I believe most other l2s are doing the transactions yeah.

B

So this is actually the interesting part because you could not put state divs if you're, using the optimistic verification right. So this kind of forces us to talk about the ZK in ZK, saying so Rusty when you think about how does the contract on L1 verify that the L2 did the right job? So there are two main approaches right. It can be optimistic.

B

Which is basically what's called fraud proofs.

B

Or it can be ZK. The thing is, the idea of the optimistic is like okay, the L2 is doing their job and then it gives people amount of time to submit the fraud proof basically to submit the challenge right to and if no one submits a challenge for a given time in case of arbitrary or optimism, we're talking like seven days or something like this, then we consider that the whole thing was successful. Now, in case of ZK, we actually we're going to go far deeper into this.

B

We we actually do the zero knowledge proof of the execution. So now, if you think about the the status having status for optimistic, would not work because you need in order to create a fraud proof, you need to have inputs for the transaction, to rerun the transactions yourself and then say something went wrong in case of zika. You actually have a choice. You can do either you can do either inputs or state that's up to you, but in most of the scenarios, not all but most of the scenarios, the they say this will be smaller.

D

B

Of course, there are some use cases where you can say like okay, the call data the inputs to transactions are tiny, but then it changes a lot of States. But again you know. In most cases this will be smaller and the other very cool thing about state divs is if we would, if you do multiple transactions right, let's say next to each other- that kind of gets batched before public level, one. If you modify the same slot multiple times, we charge you only once because we have to write it to L1 only once so.

B

This allows a very nice compression and in theory, if we let's say batch, you know one hour worth of transactions, I'm exaggerating here. Of course we don't but like hypothetically, if we did like one hour all the rights, let's say all the D5 swaps, all the like things happening to the same cells. The same slots would get nicely compressed and this would drastically lower the cost of the other one. Actually.

A

Speaking of compression like do you just write that data verbatim to uh to uh call data or, like you actually compress the stative by using some some compression right.

C

Now we just write it: okay, okay, so they're like we actually use a small compression even now so like in the most native version.

C

We could just write key and value where key is the key in this Merkle tree and the value is just 256 bit value, but uh we use the following thing: is that if a key which is started to buy it has been published once then we remember its ID, we kind of like say: okay, now we assign this some incremental ID and then, if it's modified again in the future, instead of publishing the whole 32 bytes, we just publish ID and value, and we just say oh and this one is eight bytes.

C

So whenever an account transfers for the first time well, he has no answer for balances Etc. They need to be initialized. We can call it initialized in the sense that their keys should be published and that's why it costs slightly higher.

A

C

They transfer afterwards.

A

Yeah, but this is wishing one block right: origin, no.

C

No, this ID, it could be reused for future blocks. Oh.

A

Okay, okay, so for, like all future blocks,.

C

Yeah for all the future, so.

A

Essentially, you need to keep this in the state somehow right.

C

Yeah, so actually, our key is not just the value, but it's actually a pair of value and ID and for each block. We know which what is like, the maximal ID, which was used, and then we assigned just ID to a new initial rights. We call such rights initial in the order of appearance of the key.

C

About within the batch within the batch, we don't even need to use like any additional compression, because if there are a lot of updates to one slot within one batch, we just publish one key in value yeah. That's it.

B

Right because this actually brings an important point that we didn't mention is that in case of L2 we actually generate. If you imagine, multiple transactions are being put together, then we create a one. What we call L1 batch.

D

B

This is kind of what we prove, and this is what we actually put on ethereum, so the proofs are per whole batch right. We don't do like proofs for every single transaction right.

C

Right, yeah yeah that.

A

Makes sense and.

C

To add about compression, we do plan in the future to have even better one, but that is.

A

What we have done, yeah, like uh roughly how large is the size of the uh stative for every block.

C

Steady forever block I would say how we're on right now is that we have typically have bashes as large as possible. Okay, so we can just say you know like 100 kilobytes, but that's not some. You know like limit of ZK sync, it's mainly just a limit of the they call data size of ethereum, so we just run until we reach the possible limit of the batch size, and then we publish the budget.

A

B

So dank sharding should drastically allow us to lower the cost of of the publishing of the pub data. Okay, okay,.

A

um Yeah, actually one one question: that's like I was thinking about this um stative approaches uh when Martin was talking about it like um like how does if someone wants to say, like um I, want to prove that the specific transaction happened on uh decisync? Is there a way to to do that? I understand the state is like yeah, you, you, like people, can reconstruct a state and so on, but like if someone wants to say like I want to, you know, prove like this transaction. Specific transaction has happened in the past.

C

Right now, the short answer is no, so we are like thinking about it like, maybe maybe we'll allow it in the future, but uh like right now, it's not possible so yeah. The main security property of rollup is that even if the operator goes down, it was like completely malicious and responsive users can become new operators. They basically can. You know like continue the state and be people to process new blocks so that users can withdraw their funds, for that only state is needed right.

A

Right, yeah, yeah, yeah yeah, but I think I'm thinking about a uh an extremely malicious Corner case, which is, let's say or like maybe not malicious, but like some 40 Corner case, which is let's say like um dk6 sequencer has some bug and also the the prover has some bug as well.

A

So like you essentially in accidentally, did a invalid stage or like incorrect State transition and the state division is posted and then the proof happens to not like happens to prove that, maybe because it is under construction or something like happens to be able to check out then like. Yes, if, like let's say, matalabs disappears. Yes, people kind of like like recover the state and so on, but like they would not be able to identify the some State transition. The password was incorrect. Yes, what's.

B

Worse, it's like yeah they it's not only that you cannot see a given transaction. Is there you don't even know how many transactions? Yes.

A

B

So, like you have in theory, if you just observe L1, you see magic, you see his proofs and then just random State changes right. So.

A

Yeah yeah, but so basically they're like it's relying on the fact that or rely on the assumption that proofs are should be correct, like they they better be. They.

B

Better be otherwise.

A

Say like if you actually store the transaction data then like even if the well, it's still very bad, for the proofs are not correct, but at least you can there's a way for like Independent party to just like re-round the whole history and like.

C

No but I mean you said that if the proofs are incorrect, if the proofs incorrect, then after all these transactions even like, if you don't public stages, but you know like pure transactions, even after all of them, like has been published, the state which is stored here could be changed to incorrect one, because how it works is that the operator basically sends the state changes and then the proof and the only difference with transactions that they would suggest transactions and the proof.

C

And so, if proof is uh validated on layer, one right the transition will be done. So, yes, they would be able to, in theory, rerun them yeah, but.

A

B

To be fair, this is actually one of the big challenges when you, when you explain people like how optimistic robs and fraud proofs work, yeah, it's kind of natural right, you'll be like yes and I can rerun it. If something is wrong, I can be like hey. This is wrong and it gets reverted start talking about the ZK proof. It's really the first time and the second and the third and the fourth time you read it. It looks like magic, yeah you're, like how.

A

How yeah? Okay, let's talk about the magic, um maybe let's erase some of some of this stuff? uh Oh so yeah, I! Guess, um let's maybe talk a bit about how the um like the VM or, like the the key part, actually works right.

B

Okay, so uh a couple important things- and here we'll also be talking not only about the ziki Singh, but also a bunch of other, a bunch about a bunch of other l2s that are in this space. So roughly what we have in the casing is we have ZK zkvm, so this is today it's not fully evm compatible. That's what we're working on. There are some some still like caveats in there, but it is still based on solidity, so you can write a normal solidity code, compile with our compiler and then get get this deployed.

B

We are again there are some competitors that are using directly evm whatnot. It's usually a trade-off between performance, like proof performance, and you know the the compatibility yeah um right so.

A

Sorry to interrupt I think it's not just about compatibility right, because I believe this step here today is not proved right like basically it's like you have compiler that is open source that people can verify or like people can look at. What did the code actually does, but I I don't believe this transformation is there's like some kind of like verification that shows that it actually does what no.

B

Yeah, so this part is done by the user right right, there's a system. We we don't do compilation on our site. We just get the byte code.

A

Right right, yeah! So basically your if the compiler has some bug that may like not be like compared to like. If you just directly deploy um well I guess there are people still trusting the solidity to even bite code.

B

This is the compiler and yes, we are aware that this is kind of an additional risk factor.

A

Right the same.

B

Way how Soul C is a risk factor.

A

For everybody doing the AV yeah.

B

That's something good before we go deeper.

C

B

Right so this actually allows us to have a little bit different assembly that is more zke ZK friendly. uh Now, when we talk about but before we go deeper questions.

A

uh Yeah, maybe like uh I, think the you have different op codes right, maybe like I, don't know whether you're like familiar with all the differences in off codes, but maybe like, if there's some like important ones that you want to highlight uh in terms of like what are the I think uh I think like exynx VMS support fewer up or like. Maybe there are some different op codes that you support.

B

Yeah so I, don't remember the exact details, but from what I do remember is that some of the opcodes in evm are very easy, K uh unfriendly partially, because we do have like in ZK VM. We have like one circuit yeah, it's handling most of the op codes, I think almost all of them and the moment if we wanted to do like evm opticals directly, the circuit would have been a lot larger because has to handle like the largest possible inputs.

A

And that makes it in how do you handle function is really one of the most difficult. So.

C

Like uh on ethereum cash check is an OP code yeah, but, for instance, things like sha are done by pre-compiles.

D

C

Basically, in the guessing, we have both cash rack and Char dance pre-compiles. So whenever users do catch up instead of running just an OP code, there's actually a call down to the pre-compile, it receives the pre-meases. So.

A

It's like a like handwritten, very optimized like circuit. Yes,.

C

Yes, yes, yes,.

B

One of the benefits of the compiler- it allows you to do things to things like that. Right.

A

Right, yeah, um and uh maybe like talking a bit about the ZK part right like what what proving system is the question using today? Magic, okay, no.

B

It's all magic, it's all magic, it's all black magic. If you're, really following this video right now, I mean take a pause briefing.

D

It's just gonna.

B

Go crazy and- and you know honestly, there are plenty of videos out there that Focus just on the proving system, so he will just touch like bits and pieces, but roughly up to right now we're using a snark based system- oh okay, with a bunch of changes, because people are calling it snarks, but they're, of course, devils in the details so like how do you do copy constraints and Gates? What not? And here we have the whole crypto team and I would suggest a completely separate, very deep dive to explain how they differ.

B

My perspective is the snark system with kcg commitments on L1 right, so we use the kcg we use them at the same time, literally today, if you're watching us, you try it out, we announced how do you say it?

B

No idea, uh okay, we should edit this out. So when I was Buju, which is a new proof system that we're rolling out, that is more Stark based with fry verifier. Okay, the main trade-offs in there is the old proof system, it's run on gpus, but it requires around 80 gigs of GPU Ram in order to run it. This means that if you really want to run it, you need to get the a100s or whatever is the top GPU that you can get and with the current AI boom, they are tricky to get.

B

Let's say something about expensive: they are not there all right. The new proof system with Starks allows us to kind of optimize it down to I, think 16 10 12 gigs of amp, which suddenly allows you to run it on the like regular, gpus, okay. But of course, this being a stark. There are some trade-offs yeah in there, especially on the proof size and on the verification, time, verification gas.

B

So we do have some optimization that we're working on right now in order to wrap this final proof right and kind of still do the kzg, but like plan kcg, but only for the last part only.

A

For the last part, so the way to think about is, like you proved the whole thing like a kind of Nova style like or like you do like it's like a patch thing and then like.

B

Yes, so, like you, you prove the proving.

D

B

Using a different thing that allows you to stay with like kcg, which is so much.

A

More but like uh yeah, that's interesting because, like once, one disadvantage with kids ages that you need to do trust is set up. Pressure right. I saw like by moving to Stark you're, trying to like essentially like remove that like trusses or like. Is that not a concern for Dickerson.

C

That's an additional bonus, but I mean it's uh it's one of the future proof concerns, but it's not like a major concern because, for instance, dunk sharding, it's also done with EGD and trusted setup, so I mean, and uh also like ECG like ecdsa and most of the signatures, which are used in ethereum I'm, not sure about other blockchains, but uh like their modern, Quantum, secure right so like since we derive security from layer, one like it doesn't matter too much right now, right.

A

Yeah, let's just shut up because you have a like one: sequencer, doesn't really matter right now,.

B

I mean just remember, this is like a universal processor.

A

Okay, okay, that makes sense, um but yeah I think um my understanding is that snark? Yes, you said the one of the advantages of Stark is that the proof size is quite small uh like that how to set um or like does that have any effect on like uh decreasing, by switching to like a stark based model which larger proof, size and yeah. So so, like that, maybe costs more calories.

B

Exactly so, this is part. This is the thing that we're doing right now, so we're still experimenting with a bunch of approaches, but on one side, Starks do allow us to prove a lot more blocks right. So the idea is that with Stark, we would kind of try to prove multiple blocks or, like multiple L1 batches kind of doing the recur recursive proofs. What not, which will allow us to amortize the cost.

D

B

Again, this is still in the middle of like testing and gas optimizations. What not so you know, stay tuned and we'll we'll see how it goes. Okay,.

A

And maybe let's talk a bit about like how the proving system like integrate into the like uh out to itself right, there's just uh like from basically from like a political protocol, point of view like how does the proof generation work with the um like the broad production and so on? You.

C

Can generally consider proof production as a black box because there's, for instance, a lot of motion like in the space to create some, maybe decentralized markets for proving Etc because like if you, if proven, becomes centralized. Actually it's just like another point of centralization and uh yeah, but right now, how generally works is that once we have a block, we firstly publish a state on layer, one and then we on our servers. We start generating the proof and once the proof is generated, we just submit the proof to layer, 1 and layer.

C

1 verifies that the proof is correct and that's.

B

It yeah so if we want to go a bit deeper with this, the way to think about it is like this. If you imagine, you have like a sequencer here, so sequencer keeps receiving the L2 transactions and it's trying to put them in a batch, so we actually have a bunch of Criterion of when do we decide that the batch is full. One of them is some arbitrary thing, like okay thousand transactions, like some constraints that we have the other ones might be time related. The other ones are actually the pub data related.

B

For example, we want to make sure that you know the amount of public data doesn't exceed the ethereum limits. What not right.

A

Yeah yeah. Actually, on that specific topic like how do you determine the size so that you know, for example, the proof generation doesn't take like forever or like it like? Is there like a concept of some kind of like cash that you like kind of use, a thresholder.

B

Yeah, so the good news about our proof system is we're not really limited by the gas, but there are some operations that were kind of we're optimizing. For example, amount of ketchup.

A

Right right, yeah, like I, have like a thousand catch up here like.

B

Exactly so kind of each so so the way you think you can think about is like we're doing a box and dimensional box packing right and if one dimension kind of exceeds the limit, then we have to like stop the ah okay, stop. The batch I see it, but here in case of sequencer we're doing, we can do like try to see if it fits and if not, we can pull it out. Okay, if we do a bunch of like okay, does it fit? No, this one doesn't fit. Okay, let's put something else: yeah.

A

But but I understand that but like when the cost sound like transaction to randomly fail from like from, like usual point of view, it doesn't understand like why just fail button transaction after it succeeds. For example, like you have like this transaction that got taken out, but then, like I, don't know like a transaction which is like I, don't know how the nouns works here, but, like some other transactions invited the transaction called code.

B

Here, the way, the way to think about is like when we see that something is sticking out we're just going to close the block. Okay.

A

B

To put this in the next one, so it's not going to fail from user.

A

Perspective: okay, okay, so should I guarantee not to not to fail yeah.

B

Okay, there are plenty of cases where transaction would fail, but this.

A

Is okay? Okay,.

B

The sequencer kind of trying to grow the block, and then it's you know it's ready, yeah and the L2 block is ready, and then stash mentioned we do publish it to L1. As like, hey heads up, there's like this block coming and then what's happening separately.

B

You can think about it as a complete separate process is doing the proving now prover is actually kind of taking these existing blocks that it kind of hopes that they will be like correct and doing the whole, so-called witness and and proof generation, because the way to kind of have to see how how deep we can go with this. But um you know normally the the way you think about the function is like: okay, get the function with some inputs and it produces some outputs right in case of approval.

B

It's more like you know, the function gets all the inputs and it kind of succeeds or fails. So like everything is given there with the example of like, let's say in the function you're reading, like here, you're reading some value from some memory cell here for the prover. What will happen as the input? It will? Not be just this value from the memory cell, we're going to provide like hey the whole Miracle path in this, so a simple operation of, like you, know, read or even simpler equals. Free right will be.

B

You know in normal executions like okay, put right right. That's there in case of Proverbs, we'll be like hey. Can you check that? If the previous state was this and you executed this, then the next state is this. Is this whole thing like true yeah right? So that's kind of what proverb is proof you can think about proof. It's like doing like a search kind of along the way. So this means that the prover is actually split into two pieces.

B

One of them is called witness generation, and this is the heavy part, because this is the part that takes each of these operations and kind of blow them up. I mean like okay. This is actually like this path on the Miracle tree and we're adding this here, and this is the path of the Merkle tree after we finished execution and witness can get like gigabytes many gigabytes inside and then this gets passed and that's where the magic happens with like polynomial writing whatnot, and this gets passed to the actual GPU part. This is doing.

A

The evaluation like couldn't you split into two parts where, like one is like pretty purely proving the state, the other is proving the computation and, like you like, somehow aggregate it at the end or like you um like, basically like the the compute part assumes all the state is correct and it just like runs through and can stretch like check all the computation. Then you have a separate thing that, like checks, all the state is correct. That's.

C

Actually very similar how our program works.

A

D

C

We have you know, like the main circuits, which respond, which are response for computation, like we call the Main and they like the responsible for add more. You know like most of the computation not for cash checks but yeah, and we have a bunch of like different other things, like uh you know, like memory manager like Etc and then uh like all these things like, for instance, no like this main computation whenever it does some memory load. You know it is some unit of memory.

C

It just blend the trust that I hope this value is correct, yeah, it just and then like. We just store, for instance, somewhere here, like some commitment to all the memory.

C

And then you know like this memory circuit, it would prove that okay understand commitment. This memory is correct. It also remembers that there is some commitment and then uh during the final aggregation phase. In the end, it's just all proven that. Okay, like all the commitments, are right, yeah so like and the same for storage, the same for catch hacks and a lot of other things which we need optimize. So.

B

If we go that deep, there are actually like 13 of these right, so they're, like 13 different circuits that are responsible for different parts, about like storage writing. Storage reading then like aggregations, leave nodes, scheduler et cetera, so there's a bunch of exciting complexity. Hidden.

A

In there and then the witness generation is that also down in power like it should also prioritized or is.

B

It yeah so this is like here a very much simplified.

A

That but the idea is like.

B

Yes, we are actually doing. Let's say this: this thing is doing with the generation for the main VM for for this main circuit, and this and then we do for, for the like, larger leaves larger and larger. Okay, okay, it sounds very complex, so it's like a multi multi-step process in there. Yes, okay, okay,.

A

um And then I guess a question regarding like this: maybe the post, Improvement or one like how this um like, let's say the ethereum is software cutting is cutting contrasted right. How would that affect the key sync? It.

C

Does affect us in the sense that the users they have to pay for the proving they have to pay for the data published. So there are things which we do like we on one hand we try to have lower gas price for the user, so we you know like there is a small congestion. We might just wait, but uh on the other hand, we want the finality to be in reasonable time and we won't prove to be polishing reasonable time.

C

So in this case well uh like for this block, in particular, we'll have to take a loss, but in the next block we'll raise the gas price for the like for the current levels, so that you know we get compensated and, on average we're we are compensated. So.

A

I see yeah actually on that topic. Maybe can you talk a bit about the L2 like how do you charge like transactions right.

B

So, basically, if you think about the L2 gas price, there is a dependency on L1 right. We do publish data to L1, which means we have to somehow show this cost in there right. The way we we do. This is on one side. We do have a thing that's called like, so we do have an L2 gas price. It's like separate from L1, but the the operations that require writing to L1 do have a variable cost.

D

B

The way you can think about it is if L1 gas price is, let's say, 1000 whatever and L2 gas price. Is you know five, then let's say doing a right? That's sorry doing an operation that requires you to write to L1, might cost.

D

B

Might cost you like 200 right right and then maybe tomorrow it will cost 400 right right.

A

So this does vary right, right and, and that's mostly the cost of posting as call data to to our loan.

C

Yeah most of the cost is posting the call data, but also cost of proven. It also is.

B

The proof itself also has to end up like on the on layer, one right so kind of if you can think about like each L1 bash. If we put on layer, one is gonna cost us some Pub data that people that kind of depends on transactions, plus these many bytes on this much this much L1 gas to do the actual, even the actual kcg thing in the application right.

A

Right, and is that, like an expense, how expensive is that in terms of like, is it I.

C

Guess that's not meaningful question, but is it all relative so like uh on one hand it is a constant cost or like with kcg like with general, like PSG based systems, it's a constant cost so like.

C

If we had like infinite amount of transactions, it would call it we could call it negligible yeah, but uh right now like exactly right now in the future, I think we will aggregate more blocks for one proof, but right now we have one batch and one proof and because of that, I would say that an average cost, for you know like various overhead from block like for verification, other things it's like one, third or maybe one-fourth, of of a price of a budget. So it's it's.

C

So it is a lot less than status, but not negligible yet, but in the long run it is.

B

Negligible which actually brings us to an interesting topic, because you know we do. We do publish State this today because we were like fully allowed to roll up. But the thing that we're working on is something with stash hinted at the beginning. Was the thing that we're calling ZK Porter, because the question might be like hey what? If I don't need to publish my state to L1 what, if I'm fine with taking some risk? Because, again the risk here is, you know the the matter.

B

Labs database like disappearing and you're, not being able to like recover your state but I'm willing to take this risk because, let's say I have some less valuable things and then I can save on all the like. Pub data costs right. So this is something what we call ZK Porter or validium right and if you kind of look at the example mentioned the beginning with like our state, it was like this Shard that we published to the this is the robot and then here is The Shard.

B

That would be a CK Porter that would not be published. So the idea being that, if you interact, if you kind of decide explicitly like okay, my contract is some low value. Nft I, don't mind about like this state is appearing. If something goes bad, but I really want to cut my costs, then suddenly you can kind of deploy your account here right. The cool thing about this model is like these are still synchronous calls. So, like you still interact with this.

B

The way you would normally do, but all the state changes here would not be published, so you will not be able to recover the state from from from the.

A

Other one yeah and.

B

A

You sort of like yes, things were talking about like this viridium or, like I, think the guessing called hyperscaling all.

B

Right are we going to talk about that too did I, say in two seconds: amazing.

A

Okay, okay, but like because the question here is like yeah: is there like a third assumption, which is that I still somewhat care about my security of my, like all the availability of my data, but maybe like I, don't want to pay as high of a cost? Let's say: I want to use like a separate data availability solution, I, don't post on Instagram post like somewhere else like like near for example like? Is it like a like? Is that a thing that I think is thinking about I.

C

Would say there are two options here: first, one is faziki Porter. Our end goal is to not rely only in Metro Labs. There will be like obviously, some decentralization in this in this regard, like uh almost in all validiums they're. Always you know, like not one particle that stores the data, because just losing one database is too easy, like at least then you know at least 10 parties usually store, like maybe less but depends that's one thing and uh I would say that's already good enough for a lot of people.

C

But if someone wants to design their own data availability solution, they can do it, but uh you know each case needs to be designed separately, so I would say they they have to in ethereates possible because zero knowledge proofs they give you ability of computation and how you publish data. Well, it's up to the designer. So maybe someone couldn't deploy an L3 on the casing. Maybe they can deploy an L2 using ZK stack and it's like the uh our future tooling to help develop roll ups and uh yeah.

C

So that will be his choice of everyone, because.

B

It's actually a very good point is this: is what we're announcing right now? Is the ZK stack the ability to take the ZK technology? This is the whole thing. That's open source we're actually making it easier for people to run and allow you to go ahead, and you know deploy your own. Your own chain separately right your own chain, and then you can choose a different data availability layer.

B

If you want to near something else, file coin or whatnot, and the really cool thing is now we're going to go more into scaling and Hyper Bridges the really cool thing about. If you're running the ZK stack and you're using the same ZK evm the same proofs, it allows everybody else to verify your proof without like to verify your state and computation very efficiently, very quickly right.

B

So this allows the hyperscaling the hyper Bridges, because what it means is that you know you don't need, because in case of optimistic roles, you have to like replay all the transactions to make sure that you're up to date or not in this case you don't because you know you know the circuits, you can verify them very quickly, and you know this is the right state. So this is another thing that we're announcing the the hyper scaling, the hyper Bridges. What not?

B

This means that multiple ZK stack deployed chains or sub chains, whatever you want to call it, they can operate between each other very efficiently and we're- and you know here- I'll- send people to the the medium post that we're posting right now for all the details, but the idea being that this allows them to kind of share multiple Bridges right and again, a great interoperability between them.

A

Actually, yeah, that reminds me a question like the proof is approved like recursive. Is it like proving like averaging up to like this point or is only proving the like the past, like since last class, so.

B

Today, our proofs are not recursive, I mean we're just proving the state that you can think about State transition from X to y. uh But yes in in theory, you could especially with the Stark bass proofs, you you could do it.

A

Because if you don't recurse, then you cannot just like in order to verify, you still need to verify all the all the proofs.

B

Right, but this is exactly why I'm talking that this, that's why this requires like the Stark approach, it actually does allow you to do recursive, yeah, yeah,.

A

Yeah, okay, yeah so yeah. If you only need to variety to like one proof, yeah that would be very cool. um Okay, um I think we're kind of running out of time. uh How much time do you have left?

A

Okay, yeah roughly the time um so yeah anything else that larcenos does want to to add about awesome technology that decreasing has developed.

C

I would say just come to our website and try out the casing read about DK stack and the.

B

Yeah one one thing I would say: is that really the as I mentioned earlier, the ZK looks like magic and it is Magic you're going to read it once twice five times and then after the 12 20th time we'll be like. Oh that's how it works. They actually encourage you to take a look and again don't give up really don't give up, because at the end this is like one of the most exciting Technologies, uh like of the current of the current blockchain yeah yeah.

A

The future yeah, okay, uh thanks a lot Martin and stats for uh walking me through uh the uh how the case Inc Works um and yes thanks again um for coming and we will post the uh links in the in the show notes.