Smart contracts in a ZK rollup - 0xPoland S01E04

good so i think it's time uh for our second guest um so yeah uh we have alex buchowski from zuko sings the ceo i'm especially happy to have him as a guest today because zk sync is probably the highest profile uh zero knowledge roll up today definitely definitely top of the game and yeah without further ado alex thank you for joining us today thank you mark yeah uh i'm not sure if everything all right with the sound let me let me check with our with our team alex can you say something yes one two i have a little bit of a little bit sounds a little bit weird yeah can you try to reconnect maybe just just in case yeah let's give it a moment let's make let's make sure the sound is fine so it's gonna be complex topics um so it's good to hear everything right uh i get a confirmation from the backhand team that there was a problem with the sound how about know alex hello is it better okay great uh thank you mark for inviting me and thank you uh uh bartek for a really really well uh structured explanation uh and introduction into roll-ups and skating problem overall and i actually wanted to talk a bit about this and compare different solutions but you did such a great job that i i don't have to do this anymore uh i will rather argument the arguments and just make a bit more uh make a couple of extensions and then talk about zika sync and uh how we want to achieve fully generic composable smart contracts which are avm compatible on ckc um so uh the couple of things which i wanted to add uh throughout the the session were i also believe that long-term zika roll-ups will be the the end the end game for scaling because of uh the properties that make them actually as secure as the underlying layer one so this is a unique solution in this regard this is why we're all very excited uh but i also think that in the near term there are a couple of use cases which cannot be handled by optimistic roll-ups and uh some projects are better off waiting a little longer if there is a delay in release and jumping right on their ezekie roll ups one of these cases is nfts because the withdrawals with nfts cannot be mitigated with the techniques robotic mentioned which i'm by the way are really excited uh with maker and the diaminting stuff which was just announced on twitter uh looking forward to see more details about it but with nfts uh there is no way to accelerate withdrawal with some liquidity providers because all the nfts are unique so you really have to wait two weeks and not only to withdraw to wear one but also to withdraw to any other l2 solution if you want to move them around so that that's one case the second thing where i'm really excited about zika roll ups compared to optimistic roll-ups is composability uh what i mean by this is on ethereum d5 is really successful because you can have a lot of different protocols interacting with each other and increasing the value of each other's offering and of course you can have the same thing in in all types of roll-ups in optimistic roll-ups in zika roll-ups but with optimistic roll-ups the more value you lock in a single instance of an optimistic roll-up the more risks you expose your funds to so if you have a lot of different protocols and billions of dollars of value you will you will potentially invite some troubles because what what can happen is that the optimistic roll-up will be attacked by the miners not by the validators of the roll-up itself so what miners can do is to run a censorship attack which we have not observed yet uh ever on layer one but we also never had an incentive for this the way it will work is um there will be fraudulent transaction and then all of the validators of an optimistic roll-up will rush to submit a fraud proof but the miners will just censor them and they can be coordinated in a completely trusted way so imagine an attacker comes along and says uh i'm renting out 51 of the hash power somewhere on cloud services with a lot of uh processing power maybe some gpus maybe some fpgas uh and i'm going to overthrow all blocks that include the fraud proof transactions to this particular optimistic roll-up i'm not going to do anything bad about any other transaction affecting any other account so like all all all other transactions will be fine i will include them and all miners that include those normal transactions i will build on top of their blocks only if other miners include the fraud proof of transaction then then i will revert there uh their blocks and as a miner you face a dilemma either you become like a activist and you try to include the fraud proof transaction in your block and you know it's going to be reverted uh or maybe you try to organize with other miners but if you don't have 51 hash power uh this this might be problematic you just might not be able to to uh to do this in the near term or you just comply uh and as a minor on proof-of-work system uh the compliance with the attacker can be completely anonymous because you just withdraw your hash power from the mining pool uh which is legit and you you put it to the mining pool which supports the attack and so the the cost of this attack is actually pretty low it's in the range of a couple of like 50 to 100 million dollars right now so uh it's sufficient for the attacker to have this amount of money shown on some smart contract as a plausible commitment to to to to the attack so that they actually will will perform it for one week and then all the miners will just have to comply uh so zika roll ups are completely immune to to this kind of problem um and uh and if these attack uh with 50 51 censorship and uh yeah generally much shorter uh confirmations and the ability to actually verify every transaction by all of the full nodes of ethereum which we have currently around 10 000 uh is is really exciting because like this is a true scaling solution as patek said so okay zk sync um we started two years ago to work on on zika roll-ups as a research project we launched last summer the first version which does payments uh our payments have been integrated in a bunch of protocols in uh in different wallets and a git coin grants campaigns um in uh golem uh payouts which are gonna actually start live tomorrow on the mainnet but we we started with payments because it was the most basic layer on which we wanted to build the generic functionality of smart contracts we did not want to go into any specific protocol like building an mm or building some exchange because we don't want to compete with projects that will be building on top of zika sync we want to remain a neutral platform uh which will be turned into a decentralized protocol right now it's operated by a single sequencer which does not have any impact on the security because security is guaranteed purely by smart contract since your knowledge proofs uh but it's it's not good from decentralization standpoint and we we're gonna introduce multi-validator consensus and we've been working on bringing smart contracts to zika sync and i'm going to talk a bit more about technology so that you understand how uh what are the challenges and how we're solving on them i think it's pretty interesting uh so the the end goal for zika sync is to support smart contracts which are evm compatible and have all the properties of contracts on ethereum so if you have some code written in solidity and you have some uh dapps with some apis that interact with this code uh ideally you should not need to do any changes you should be able to just take this code deploy it on zika sync and use it completely the same way use it on ethereum and also interact with other contracts and we believe that this is we are very close to this goal we will actually show something in the near term but we started with a slightly different approach a year ago we worked on a computing language and programming language called zinc which was a non-turing complete programming language as opposed to deterring complete solidity and the reason for this was that to make something zero knowledge proof friendly you need to build a zero knowledge circuit so you need to build a special function which you can prove under some your knowledge proof system uh so to to to recap what is the zero knowledge proof you can have some function f that takes some arguments x y is that uh and produces some output uh let's say r uh and we like you can have a prover one party which tries to convince the other party the verifier that they have computed the result of this function and the evaluation of this result is r and the computation is correct without actually disclosing what x y and z are uh so and this process is called the proving that you you produce a small cryptographic proof uh maybe uh couple of kilobytes [Music] size of data which the verifier can take apply some simple mathematical operations in it and get a result of true or false whether the proof is correct or not so uh interesting thing is you can omit x y and z or you can omit just uh y and z so this this is going to be hidden x is going to be known to both parties and the function itself and the result also are going to be known to both parties so the the the uh in place of this function we can have something really simple like a hash function so i can prove to you that i i know such x that let's say sha 2 5 6 of the x equals some value right and if i produce the proof you can check it you will be sure that i actually know x i could not computationally fake it but we can do something a lot more complex we can put a state transition function in place of this f uh which will prove that we actually took a number of transactions applied them to the previous state root which is known so we will have a state transition function which takes r the root hash of the blockchain or of our roll-up uh which takes a set of transactions and the new root hash which will be the result of the application of all these transactions to our state and it produces the result of true if this state transition is valid all right and we can prove it uh the problem is these functions must be representable in the form of arithmetic circuit what that means is they they must be expressed in a sequence of uh simple mathematical operations such as plus and multiply uh and you can't really have loops there you you like it it has to be one single function which you have you can write in in single line uh so they are fixed size you can represent complex algorithms there are ways to break them down in like if you if you have loops of some fixed size you can break it down in arithmetic operations and just write a long list of these operations and it will represent a circuit and this is actually what we do for example in case of shadow five six so for uh for a proof system uh which is r1 cs based r1cs is a language to describe the proof systems you take something like 25 000 constraints so 25 000 linear um equations to represent this single function and if you have something more complex like a state transition of of a roll-up which makes just even simple payments not even trades or contracts then it will be like many hundreds of thousands of applications of some hash functions some some more complex logic right but it has to be fixed um and to make it fixed the the only option we had was to make uh a language which describes the program which is not variable so the program has to be of the constant length the execution trace of the program had to be of the constant length uh so we wrote the this language called zinc and it's interesting that for example the viper language which is used by curve also has this property it's also a non-turing complete language so it was possible to take any program written in viper and translate it to zinc almost one by one like line by line you just rewrite it and then we build the compiler this compiler would produce the uh the the virtual machine which being executed would produce the these constraints and then also the proof for a given set of data so we did the curve uh we did the the demo together with curve we demonstrated how this works we built a test net uh it's actually possible to take uh programs write them in zinc now and deploy on this testnet but then we discovered a very interesting way how we can do the contracts which at turin complete and this opened the way for solidity to be brought to zika sync and the key component which was missing uh which allowed us to finally do this was recursion so we we have we use a proof system called plonk uh which since early last year support uh had the support of recursion we implemented it on uh zk sync it's now live in production uh which makes our uh the cost of transactions on zika sync are the lowest among all existing roll-ups and the way it works is you can create a zero knowledge proof that doesn't prove some functions but instead proves that it verified some other zero knowledge proofs and uh so for example you could you could take like this would be the proof of a single block of transactions which contains some fixed number of transactions let's say maybe 500 or 1000 or something and then you can have as many of them as you want and you can just recursively put them in a tree of proofs so the the bottom line will be will be our like basic blocks and then the this line would be the proofs of the basic blocks combined together by by many in the same block and then you can have maybe some more layers if you need and eventually you will have a single top level proof which verifies all of the underlying blocks and all of the underlying transactions which is recursively converging here right so you can use it to to create blocks of arbitrary size even though a single block is of a fixed size uh and and this means the verification of zero knowledge proof of the single proof uh will cost some constant uh cost on on layer one which is around five hundred thousand gas for plonk but it will be amortized among many thousands of the transactions so the cost per transaction is going to be very low so how do we apply this to small contracts and specifically to solidity smart contracts so the the interesting thing about uh solidity is so generally yeah how do you how can you create zero knowledge proofs of during complete execution so it would be hard because like you would like we cannot have uh a single recursive block for every operation because we have many thousands of operations in a in the stack trace of an execution of a single smart contract on evm but we can have a single proof of a big block which contains many execution steps at each step and we would have a fixed size of the steps and at each step we would access memory load an instruction uh from from the next memory memory point uh according to the program counter uh and we would execute a single instruction and the way we would execute a single instruction is we would create like on each step we would have a conditional select with multiple instructions uh and we would just check against each of them is it a add no is it a sub no is it a move yes okay so execute move right so this means that the this circuit would be pretty large because we would have like if we have let's say 30 instructions and 1000 steps we would have to have a number of constraints proportional to the product of these two numbers which might be pretty large right especially if you have a very long execution trace the problem with solidity is that certain instructions in evm are a lot more expensive than other instructions so they are not homogenic you have the cost profile is completely different in operations such as add which adds two numbers costs something like two or three guests or one guess maybe even but an operation of s store which you use to to update a storage slot in in storage so this is one gas and this store is 20 000 gas right so if we designed this circuit to contain the each each of the cell uh or each each of the slots here would be as large as the most expensive operation it would be prohibitively expensive like we would not be able to to support it because like it would mean essentially that if your program has 1 000 execution uh steps then you would have to pay as much money as as you need for like 1 000 as stores which which is out of order but what we can do with recursion is we can have the these instructions very simple and very small and we never like just just limit it to the most basic operations such as arithmetic operations memory access and some basic hashes and whenever you have a more complex operation such as s-store or k-chuck hash or shoto56 or signature verification we will just accumulate those uh the like accumulate the requests for those operations in some special registers we would maintain the list of these registers and then we would pass them to separate circuits which are specialized just for those operations so we would have a special circuit which only does storage access and we would have some fixed number of s-store operations uh which would be a lot less than the normal execution trace and then we would have a separate circuit just for ketchup hash and just for uh shatter five six and just for signature and so on and then we will recursively combine them together just like we did over here so instead of having simple blocks with all the same types of transactions we would have simple blocks with these basic transactions and a few specialized blocks with heavy operations depending on how many of these heavy operations we actually need to use in uh for for a specific block of the roll-up so some blocks will contain a lot of storage accesses but some will contain a lot of signature verification or hashes or something so this is roughly how it works and we decided to go all in on solidity and completely shifted our focus to this and uh we we we will we actually made a huge progress since uh uh last couple of months and we will have a public test net uh probably within within like a month two three months from now maximum and we're definitely launching this this year with evm compatibility uh full composability so it will be possible to call one contract from the other and have a sequence of calls in a single atomic transaction we'll have events we'll have all the things that that you know from solidity except maybe for some age cases such as like some very complex cryptographic pre-compiles maybe we won't support them from the first version but the rest we we actually intend to support and it's going to work just the same way it's working on ethereum and we're super excited about this uh so that's it i think it's gonna be i'm not sure how how deeply technical or not it was i'm gonna take questions and uh i think i'm sure there's gonna be a lot of interesting questions to discuss mark hello so i'm not sure why i'm still alive or mark and bartek are here uh yeah i i can also read the chat so maybe we uh yeah i know i'm live so like uh yeah would be great to to have some questions here so there's some problem with the with the video but we will just post questions in chat i will read them and try to give some answers so what is the plan a plonk proof system you mentioned it's called plonk written like this and we're back is a proof system which uses polynomial commitments so it's it's a um it's an interesting hybrid system between uh snarks and starks so it's it's actually a snark it's a succinct non non uh interactive argument of knowledge and it just uses a similar arithmetization technique as starks so you can do very efficient specialized circuits you can do hashes or or some specific arithmetics in different on different curves in a very efficient way so i i just encourage you to google plonk and you will find more information awesome we have another question coming on a second now let's see what starts so one why one weeks for optimistic roll up how much it actually takes to compute fraud proofs so the fraud proof you can calculate it instantly the reason you need one or two weeks for withdrawals from an optimistic roll-up is if the validator submits an invalid state you need to give people enough time to submit the fraud proof and actually make sure that it's included by the miners in the block this one week is exactly to prevent the problem which i was talking about previously it can happen that the validators will detect a fraudulent transaction we'll submit it uh but the miners will just ignore it and by the way and this is so i'm i'm i'm a little i'm obviously biased because i'm working on zq roll roll-ups [Music] but i still want to be a bit contrarian here and say that i actually think the miners should be allowed or they are allowed essentially by the protocol to not include transactions to like censor transactions at their will because that's freedom isn't it so they should be incentivized to behave in a certain way and this is the beauty of blockchain and the beauty of capitalism overall like everybody's doing their selfish thing but overall because we have rules uh to punish crime and uh like just being nice and and and bringing value is more profitable than than trying to screw people up right because you're just gonna make more of of of being productive even if it's your like if you're completely selfish and i think we should build systems that are resilient against manipulation not try to rely on some social coordination not try to build something which will be shaking but it could be uh yeah i i personally second that for sure but there's this interesting caveat here in that uh when i personally think about this problem uh if we had zero knowledge proofs a couple of years ago maybe we could have asked all the minus to actually include zero knowledge proof right inside the block it's just that you know it actually takes time uh to compute it and it will take space inside the block uh it's just simply faster not to do it and rely on others to do the validation right so there's this interesting uh uh between relying on speed and crypto economic grantees versus actually provers uh needing to compute um this proof right i mean let's let's uh you know be realistic i mean this does not come for free right you need to actually do the heavy lifting uh when you compute this proof it's much easier to verify but to compute the proof you need to run you know some bulky uh uh computing power i believe right this is true and this is by the way a very interesting point so we actually indeed need to run a lot more uh computations than is necessary for a transaction so like probably by a factor of ten thousand so like for for every simple operation in uh in our blocks we need to do ten thousand operations to produce the proof however uh number one amortized cost of the zero knowledge proof per single transaction is completely negligible it's in the range of 0.1 to 0.01 per per transaction so unless you need to do some like super tiny micro transactions uh nobody is going to notice people are willing to pay a lot more right the second aspect of it is uh can anybody around the prover will it not lead to a centralization where like only a few select uh validators can be running a zero knowledge proof while the instrument service because like you need this lots of this hardware and it's gonna be like miners that you have to to how to buy and keep it and that's interestingly not the case because with zero knowledge proofs you can and we actually do this we run them on demand in the cloud providers and you can have a generic setup that works with any cloud provider so and you have a lot of them they they're competing so you can have something that works on google cloud and digitalocean and microsoft azure and different ones in aws and so on and you run them on demand so like you only run this server the moment you have a block you can spin it up in a matter of seconds and you shut it down in a matter of seconds so you only you you run the server only literally to just compute the like maybe like five ten to twenty minutes to compute the proof of the block and then you don't need it anymore and anyone can and and and the hardware you run it can be completely untrusted it's not like the validation service where you hold your private keys those ones have to be secured those are better off at your premises where you actually control the hardware control the access but the proof generation you can delegate it to anyone because they are self-verifying if the proof doesn't fit then it won't be accepted by uh by the contract and it's really cheap to verify the the proof so for these reasons i think that this is a non-issue for zika rollers just just because it's negligible and anybody anyone can do this awesome let's i have i would like to continue on the topic but i think we have a few more questions so let's let's start with the questions and see what the question is zika roll up should be faster than optimistic or up what are the tps oh no not the tps discussion please like the worst discussion you can have with technical people on blockchain is the price of bitcoin and but the second best comes yes but well unless we're like unless you're a a uh uh one of the l2 projects we love tps we love talking about tps because of course we have the largest dps and so we like to measure that but uh so like both optimistic and zika roll-ups are limited by the uh like the bottleneck is the size of ethereum block for call data it's not the computation behind the the probes or the the uh hardware requirements for your full node there we can have like unlimited tps for both optimistic and secure labs but we can only include a limited number of public data chunks in the ethereum call data and so the question becomes how much data do you need per transaction in each case in ezekiel up case and then optimistic column case and then you can take the ethereum block limit of currently something like 12.5 million gas uh you know that one single byte of data costs uh 16 gas and you can make a simple calculation and you will know what's your tps right because the block is produced every 13 seconds or so so interestingly for zika roll ups and optimistic roll uh the they might have slightly different profiles of costs because uh for optimistic roll-ups you have to post the same inputs as you do on ethereum today so exactly the same input for transaction as an ethereum plus the signature plus if you're using a single round optimistic roll-up like optimism does you need to put a the new root hash of the transaction our bit room doesn't need that because they use uh uh true bit style verification with multiple rounds so they can they can skip the hash so i'm gonna i'm gonna write this down so optimistic you put ethereum input signature and root hash root hash is four bytes the signature is 65 bytes ethereum input depends on the transactions of a simple payment it can be something like i think 100 bytes um now signatures could be abstracted away and they could aggregate the signatures with bls but none of the projects that are currently building optimistic roll-ups doing this for now so let's just assume this is the uh which you get there for zika roll ups you have two options option one is to include only this part only the ethereum uh the transaction input this is sticks in input right so this is option one please so this is zk option one is just this so this is already so i think well what's what's uh here you have from two uh maybe maybe it's like 40 bytes right so 40 bytes here uh then it's going to be already smaller than current versions of optimistic by about a buck factor of two three now the second option for zika roll-ups which optimistic roll-ups do not have is to only publish the outputs the outputs meaning like for each of the changed slots you publish the key so the the account id the slot number and then the value which you put in the slot so it depending on how many slots you update for in the transaction uh and uh on on the size of key in value it can be somewhere from a few bytes to maybe 40 bytes maybe 60 by let's let's say 64 bytes but the interesting thing is you don't have to publish it for every single transaction you have an option to publish it only once at the end of the block for uh like just for the latest state of the update so imagine if you have a uni swap and a lot of users interact with it and they make updates and you update a single trading pair then at the end you will only need to publish one of these updates and not every single transaction so and yeah tps currently are in the range of like 2 000 dps for if for zika roll-ups uh four simple payments let's measure everything with payments for optimistic roll-ups i heard the number of like something like 200 400 let's say 400 for payments for contracts it will vary because the inputs will be different i have one question that kind of adds to that if ethereum comes with charts in the version two obviously we can multiply that by number of shards but can we is that sharded zk rollout or can we kind of move things around so alex if i can take this uh and obviously excellent stopped mr graf yeah i mean the vitalik uh he posted you know a quite detailed analysis of the expected uh tps uh using if1 and the future e2 and it's not just about charts it's about the cost of storage so if to uh really uh gives us much more space to actually put all the transaction info so uh i think with the current solutions on if one we can expect like um two orders of magnitude of the speed up so instead of 15 tps uh you'll end up with maybe one thousand so a few thousand tps depending on the actual solution uh on if two uh vitalik's estimation is that that's gonna be over 100 000 uh dps right uh so that's that's like a significant but again that's because we will be able to put a big chunks of data on if2 another state again just data which is right once read type of data right and data is cheap i mean the way uh we should all think about data is that the you know logs are super cheap uh storage is cheap uh what's really uh problematic uh is the state access right we should do everything to sort of minimize the state size uh whereas you know just storing logs we can like store as much as we want because it's like almost zero cost yeah i i think it's worth it that state is something that is uh stored in specially designed database based on merkle trees which we talked about on one of previous meetups while the call data is basically the history of all transactions and like it can be stored like in the cloud and very cheap storage while the uh merkle tree data needs to be stored very fast as the drives and today the biggest bottleneck in scouting ethereum is the speed of those databases not anything else not the consensus algorithm not anything else and alex i think i think i actually heard it from alex for the first time which is super unintuitive when you come from outside the blockchain space if you don't know internals how it works it kind of came as a shock to me the speed of the database is the bottleneck of scaling issue as of today and uh so that's super interesting but i want to ask following a question if we have really a lot of this call data and it grows really big into many terabytes then it's becoming difficult to run a full node so it kind of adds up to centralization so it's not like no it's not because i mean the it's not about the the size of a call data i mean you can easily download terabytes of data in in hours whatever this is not the problem the problem is the state size and validation time of all the transactions that's literally the problem right if you wanted to do this because with the zika relapse you don't have to because i mean you've got to prove that the state's correct but with any other construction if you really wanted to run the full node you have to run through all the transactions downloading terabytes of data i mean think about it how much time does it take right now to do the full uh node sync on ethereum right that's probably going to take days or maybe weeks downloading terabytes of data that's going to take hours on fast internet uh connection so that's not that's not the bottleneck at all eight at 8k moving in movies and torrents super fast as long as it has you wonderful let's let's take another question then well i guess it might be that one we might address to alex what is the major roadblock now for zk for zero knowledge honestly we don't have a roadblock now it's just a matter of engineering so it's the all the fundamental questions of research yourself it's it's just like we know what to do we have a road map we'll publish it uh soon and uh yeah it's just a matter of like finishing the i think there's so much optimism right behind zika well there's a lot of opportunities behind well i want to say i'm super excited and we've been you know i've been in engineering space for almost four years now and remember the days announcing layer two and all this stuff and waiting forever for those things to happen and finally last end of the last year we have first things working with the casing being one of the most notable examples and like you know it's not fully it's not you know solidly compiled back then but it was really exciting to see things working now optimism seems to be just around the corner now we have a great news from zk sdk uh sync again with with the solidity compilation so like if anyone has any doubt yet if it's worth joining the blockchain space now if you're not in the blockchain space now already then i think that those breakthrough things are happening just now do we have i think we have at least one more question that one we already i think discussed let's see we have anything else the talk was fantastic yes thank you uh question you mentioned some solidity functions might not be available in early versions what are the use cases that might be impacted by this i think this is this is like eap in 1962 which by the way we created and we we introduced and implemented uh uh these are like some heavy precompiles for elliptic curve operations to verify other types of uh of snarks or like make pairings over elliptic curves of like different types but you don't really need them because you can implement them with your knowledge groups so what we will support eventually is native support for recursion where you will be able to write your own pre-compiles for for like anything so that gives me a perfect excuse for the question i wanted to ask earlier might want to allow other people to ask questions first can you build a zk roll up on zika roll up can we build layers absolutely oh yeah oh yeah you can do that and like what this gives you is uh shielded transactions which will cost essentially the same as normal ones so the cost of like privacy will be like maybe you will pay double the cost of like simple transaction and of course you can build a zika roll up on top of optimistic roll up and vice versa right so this is like no well well no not nothing not really because for optimistic roll-ups you will have to pause the proofs and they are very big for like the proof systems like plonk are around like i think 1.5 or 2 kilobytes which is a lot if you have to put it on on on solidity on on a call data for if you use something like uh starks for transparency then you have to put the uh like 100 kilobytes of data and this is going to be very very expensive optimistic co-ops with zika roll-ups you don't have to publish all of that you omit it you just verify it recursively and then you you can be sure that transaction was correct but you omit the date itself but again i mean it's sort of i kind of feel that given the high gas prices and all the upcoming changes especially with 52 as well you have to expect to pay more and more for state update and potentially even the state rent will be introduced whereas uh posting data like logs uh will become cheaper and cheaper to the point that it will be literally free almost right this is how you scale potentially right you sort of turn the blockchain into this huge data store with just state commitment rather than the full state and the the actual computation will be for sure eventually done off chain on another uh place right there's just literally no point of doing a lot of computation on l1 true so yeah well sorry go ahead no i don't know i just want to say we have a few more questions i propose to do two more questions because i think there are there are yeah let's do one at least one more question and then we can go to discord hopefully this is actually interesting one because in case of many competing dk technologies system and that goes to optimistic as well i guess could there be a serious risk down the line of competing technologies beating up gas prices so how often before we go to that how often do you publish zero knowledge versus will zk how often do you publish a proof on the l1 for l2 maybe maybe let's start it well we you you can do it as soon as you have enough transactions so with right now we do it every couple of hours uh but you can you could also at the very high flow potentially do it every five minutes or even every minute so this can actually happen that like l2 solutions will um will consume quite substantial portion of uh ethereum block size for proofs or for call data uh but they will still like you you always have to measure it amortized against a single transaction in the block which will be relatively low otherwise nobody would use this filter solutions okay and again i don't think you should be concerned so much about the gas price on the base layer if you sort of assume that eventually base layer will become this global settlement layer right i mean this is literally this cost will be spread across different roll-ups and uh and uses we hope that eventually users won't need to pay much and uh from the end user's perspective you know that's gonna be like it used to be three years ago right and by the way uh if any of you follows uh other kind of side chains if you like or block chains like copies of ethereum um advertising low gas fees you probably will notice that one of the reasons for the low gas fees on these blockchains is because you know there's not that much traffic on them right uh once they get to ethereum state um they will be facing this unfortunate dilemma either they will centralize or they will have to raise gas fees there's just no easy solution to this right and the reason why ethereum is uh so expensive the true reason is because there's just so much demand um sure yeah so can we have two more questions that all kind of relate to each other so let's try to put two questions uh at the time it's all relating to fees uh on the blocks to inordinate levels oh this freezing out competiting class funded system it seems like this could lead to a massive increase in gas prices so that's kind of continuation on the previous one but i think it's it's worth mentioning because the next one is also writing how low are the fees on layer 2 and how are the feats of operation on layer 2 cupboards oh i think we already covered that so i said that is your knowledge proof uh part is negligible and the uh the costs are in the range that you can compute so for i i can say that for a simple transfer on zika sync you would have to pay something like 500 gas on chain part compared to 6 60 000 gas like 40 to 60 000 gas for erc 20 token transfer for optimistic roll-ups it's probably a couple of thousand gas per transfer i think it's also worth mentioning that i think there are fees on every single roll up that are used to cover the fees on l1 right so that that's also like because it seems there are a few questions around like how do you gonna pay all these fees on layer one well we're gonna earn with lower fees on player two we're gonna earn per hour so so like in the future i think it's it's kind of should be it's the image that we can start seeing it might be obvious or not but it seems that in the future we might have ethereum that is basically a security layer for player two and we don't really do many things on layer one we don't really run transactions maybe a very big one like moving fonts between layers but we basically submit those proofs and everything happens or majority of the work happens or layer two right so it etune becomes kind of the centralized central mind the one the source of security rather than a place where you would go and actually withdraw money or do any business but if we actually do consider you know this previous question uh what happens when you know the block size on l2 goes to this inordinate level uh i think we will probably reach uh again the scalability limit and the gas prices will indeed uh be high uh however we're talking to orders of magnitude higher than today right so now it's a question of can we get to orders of magnitude more transactions and users of ethereum blockchain and if that happens within the year i certainly would be the first one to be super happy about that right because we're looking all of us are looking at a very bright future if that happens okay guys so last question last question i wanted to ask that question someone else asked this question so here comes this question how can composability between rollout be handled so now the question comes i'm on one roll up doing my business now i want to do my business on the other roll up i have to go through the main chain that's probably expensive can we do better than that so i think well a short answer is that you know you have to start learn and love asynchronous transactions alex anything you would like to ask i agree you can't have composability the same way you're used to on ethereum and i think it's going to be a deal breaker for many use cases actually for most use cases so like there are a few use cases where you don't care about this if you just want to make at market trade then you can like some people just put a uh an order overnight with some good price and they wait for this order to be executed this this will obviously work you can just send this request and then whatever chain executes it's faster you will send it there send it back but for things like composable defy you really want them to be on one chain otherwise it just won't work what about the cost of migrating because i imagine it might be quite the interior might be quite it's already quite expensive and might be even more it will be way more expensive yeah so like you you uh you have those cheap transactions so i have 50 bucks 100 bucks i want to just move it to another thing but then it goes i don't know 10 bucks oh you'll be using no no you'll be using state channels to do that between roll-ups i think and liquidity providers that will sort of allow you to actually move liquidity over and they will maintain position on l1 so for small users i don't think there's going to be a problem if you're like a whale yes you will pay those fees but you know even with today's prices because we have to put everything into the context right even with today prices it's actually cheaper uh to trade on on on the baseline if your trade is significantly large because the centralized exchanges will sort of you know uh charge fee on your transaction anyway right so for big liquidity providers the current fees are still quite low interestingly enough right and they might actually provide liquidity for state channels that will allow you to cheaply move your liquidity across chains i think that's definitely possible and i would expect such rails to exist for let's say what we call a retail users if you like right uh people just having you know like regular accounts and just wanting to move let's say i don't know a few hundred dollars from one roll up to another right there's literally no need for you to sort of go back to l1 and go to another l2 it's almost like having chips from one casino and you wanted to play in another casino and you sort of you know meet the guy that would do swap with you because maybe they want to go the opposite way right uh you wanted to go from casino a to casino b there's somebody else going the opposite direction why go to l1 where you know you could simply swap the chips and in fact uh and i know for a fact that the biggest problem for wales today in exchanging uh their money on ethereum it's not the cause of transaction but empowerment laws something to talk about on previous meet up it's that the the markets are not big enough they're moving the markets when they're exchanging amounts that are like in hundreds of thousands of dollars or millions of dollars so indeed the price of uh the fee is not far from the problem and they hate going back to centralized exchanges to do that and a lot of them some just split and uh all of us you know not being whales you know we also experience some interesting side effects you know the one nice one is what we call a drunk whale effect uh which is a whale that does something really silly while potentially being drunk right and that can cause you know like a flash crash on one particular exchange you know they can rip through the whole order book you know with one trade and whatnot right and that will sort of you know create this you know huge amount of arbitrage um in the ecosystem uh raising the gas price right for you know for at least few minutes um before everything sort of settles again right [Music] well the joy of using blockchain