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

Captions as YouTube publishes them, usually machine-generated, so product and people names can be misheard.

1. 0:03

   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 so we do the ZK but like we're we're from matlabs we're working on the ZK sync which is

2. 0:39

   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 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

3. 1:15

   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 so basically during this session we're gonna split it into roughly three pieces so first we're gonna talk about what l2s

4. 1:46

   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 how does it differ from L1

5. 2:16

   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

6. 2:46

   interact 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

7. 3:11

   on out 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 if if the

8. 3:53

   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 yeah sure I think um you guys mentioned this very interesting part which is just a kind of interaction with a one right I

9. 4:22

   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 sure so the way if you zoom in into this picture basically if we Imagine This is the ethereum

10. 4:56

    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

11. 5:19

    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 yeah yeah I think

12. 5:52

    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 so

13. 6:18

    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 basically

14. 6:48

    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

15. 7:18

    instance three deposits and then uh through and then like these deposits 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 yeah so like when the block is proposed also the new State Route is published as

16. 7:52

    well so now we know that this the good photo reflects that certain addresses for which the deposit was done now contain the balances 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 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

17. 8:23

    X tokens you can only get X tokens back 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 then for easy self you need to wrap

18. 8:55

    it first and then like yeah 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 um and how this and and so basically from the L1 point of view the contract is holding all that balance right so from L1 point of view this is just a simple contract okay yeah it's just you know whenever uses the interacts with it

19. 9:20

    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 operates the blockchain and then like internally the uh the usual balances are kept in the L2 state yeah so like yeah all the balances like their plain text say it's just it's only

20. 9:42

    Captain O2 right and 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 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

21. 10:11

    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 where is a Merkle tree or a vertical tree or something else it kind of depends on on the contract itself because this doesn't it's like

22. 10:37

    astrological one you can there is a way to verifying smart contracts okay and 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

23. 11:02

    outputs putting the state divs off this right 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 our

24. 11:25

    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

25. 11:56

    only chart is the roll-up one and then we have like 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

26. 12:36

    check is used but in our case we use the more ZK friendly function no Blake we use Blake 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 so it's actually the interesting part

27. 13:03

    it's it has a fixed depth oh it's just like it's 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 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 the oh no no it's it's that okay sorry I meant like okay okay yeah that yeah and then

28. 13:27

    but what's the what's the wish on the like on each level no it's it's porous Merkel tree yeah so it's just which is needed okay 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

29. 13:59

    kissing is putting State tips um L1 versus um I believe most other l2s are doing the transactions yeah 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

30. 14:30

    optimistic which is basically what's called fraud proofs 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

31. 15:03

    in case of ZK we actually we're going to go far deeper into this 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

32. 15:27

    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 okay 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

33. 15:51

    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 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

34. 16:27

    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 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 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 we could just write key and value

35. 16:58

    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 so

36. 17:31

    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 and whenever they transfer afterwards yeah but this is wishing one block right origin no no this ID it could be reused for future blocks oh okay okay so for like all future blocks yeah for all the future so essentially you need to keep this in the

37. 18:02

    state somehow right 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 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

38. 18:41

    value yeah that's it 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 and 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 right yeah yeah that makes sense

39. 19:07

    and to add about compression we do plan in the future to have even better one but that is what we have done yeah like uh roughly how large is the size of the uh stative for every block 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

40. 19:39

    until we reach the possible limit of the batch size and then we publish the budget yes so dank sharding should drastically allow us to lower the cost of of the publishing of the pub data okay okay 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

41. 20:14

    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 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

42. 20:37

    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 right yeah yeah yeah yeah but I think I'm thinking about a uh

43. 21:04

    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 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

44. 21:30

    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 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 yes

45. 21:54

    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 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 better be otherwise say like if you actually store the transaction data then like even if the

46. 22:17

    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 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

47. 22:38

    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 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 uh and 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

48. 23:19

    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 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

49. 23:44

    bit about how the um like the VM or like the the key part actually works right 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

50. 24:17

    solidity so you can write a normal solidity code compile with our compiler and then get get this deployed 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 uh sorry to interrupt I think it's not just about compatibility right because I

51. 24:49

    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 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 right

52. 25:11

    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 this is the compiler and yes we are aware that this is kind of an additional risk factor right the same way how Soul C is a risk factor for everybody doing the AV yeah that's something good before we go deeper

53. 25:44

    okay 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 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

54. 26:09

    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 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

55. 26:33

    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 and that makes it in how do you handle function is really one of the most difficult so like uh on ethereum cash check is an OP code yeah but for instance things like sha are done by pre-compiles and basically in the guessing we have both

56. 27:02

    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 it's like a like handwritten very optimized like circuit yes yes yes yes one of the benefits of the compiler it allows you to do things to things like that right right yeah um and uh maybe like talking a bit about

57. 27:27

    the ZK part right like what what proving system is the question using today magic okay no 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 it's just gonna 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

58. 27:50

    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 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

59. 28:21

    you're watching us you try it out we announced how do you say it 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

60. 28:53

    the a100s or whatever is the top GPU that you can get and with the current AI boom they are tricky to get 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

61. 29:24

    time verification gas 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 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 yes so like you you prove the proving yeah using a different thing that allows you to stay with like kcg which is so

62. 29:54

    much 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 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

63. 30:20

    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 yeah let's just shut up because you have a like one sequencer doesn't really matter right now I mean just remember this is like a universal processor

64. 30:53

    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 exactly so this is part this is the thing that we're doing right now so

65. 31:18

    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 but 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 and maybe let's talk a bit about

66. 31:48

    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 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

67. 32:14

    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 1 verifies that the proof is correct and

68. 32:40

    that's 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

69. 33:05

    some constraints that we have the other ones might be time related the other ones are actually the pub data related for example we want to make sure that you know the amount of public data doesn't exceed the ethereum limits what not right 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

70. 33:29

    you like kind of use a thresholder 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 right right yeah like I have like a thousand catch up here like 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

71. 33:54

    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 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

72. 34:18

    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 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 we're going to put this in the next one so it's not going to fail from user perspective okay okay so should I guarantee not to not to fail yeah okay there are plenty of cases where transaction would fail but this is

73. 34:42

    okay okay 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 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

74. 35:14

    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 it's more like you know the function gets all the inputs and it kind

75. 35:39

    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

76. 36:05

    or even simpler equals free right will be 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

77. 36:35

    pieces 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

78. 36:59

    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 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

79. 37:30

    like check all the computation then you have a separate thing that like checks all the state is correct that's actually very similar how our program works like yeah so 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

80. 37:56

    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 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 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

81. 38:37

    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 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

82. 39:09

    complexity hidden in there and then the witness generation is that also down in power like it should also prioritized or is it yeah so this is like here a very much simplified that but the idea is like 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

83. 39:33

    in there yes okay okay 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 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

84. 40:04

    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 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

85. 40:27

    we're we are compensated so I see yeah actually on that topic maybe can you talk a bit about the L2 like how do you charge like transactions right 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

86. 40:58

    the the operations that require writing to L1 do have a variable cost okay so 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 you today it might cost you like 200 right right and then maybe tomorrow it will cost 400 right right so this does vary right right and and that's mostly the cost of

87. 41:32

    posting as call data to to our loan yeah most of the cost is posting the call data but also cost of proven it also is 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

88. 42:04

    right right and is that like an expense how expensive is that in terms of like is it I 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 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

89. 42:33

    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 so it is a lot less than status but not negligible yet but in the long run it is negligible which actually brings us to an interesting topic because you know we do we do publish State this today

90. 43:04

    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 Labs database like disappearing and you're not being able to like recover

91. 43:28

    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 that would be a CK Porter

92. 43:56

    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 the way you would

93. 44:19

    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 other one yeah and then you sort of like yes things were talking about like this viridium or like I think the guessing called hyperscaling all right are we going to talk about that too did I say in two seconds amazing okay okay but like because the question here is like yeah is there like a third

94. 44:42

    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 would say there are two options here

95. 45:06

    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 but if someone wants to design their own

96. 45:36

    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

97. 46:07

    yeah so that will be his choice of everyone because 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 if you want to near something else file coin or

98. 46:37

    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 so this allows the hyperscaling the hyper Bridges because what it means is that

99. 47:09

    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 this means that multiple ZK stack deployed chains or sub chains whatever

100. 47:33

     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 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

101. 48:02

     only proving the like the past like since last class so 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 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 right but this is exactly why I'm talking that this that's why this requires like the Stark

102. 48:28

     approach it actually does allow you to do recursive yeah yeah 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 okay yeah roughly the time um so yeah anything else that larcenos does want to to add about awesome technology that decreasing has developed I would say just come to our website and

103. 49:02

     try out the casing read about DK stack and the 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

104. 49:28

     this is like one of the most exciting Technologies uh like of the current of the current blockchain yeah yeah 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