#DappCon22 : Day 3 - zkEVM: Compatibility And Equivalence, Alex Gluchowski

Transcript

and for the first talk the title is zkevm compatibility and equivalence and I like to welcome Alex gluhovsky [Applause] statistic Clicker okay just a sec oh I see okay hello hi everyone I'm very excited to be here welcome depcon I'm from ZK sync my name is Alex cam co-founder of matter Labs which is the company behind the kissing I'm going to talk about DK evm and equivalence versus compatibility as

Concepts and how they uh what trade-offs they bring I want to start with introducing the kissing really quickly that's a ZK roll-up that is going to bring the first zkvm to mainnet in now under 45 days um ZK Sync has been the first EV first ZK roll-up ever built for ethereum we introduced the idea of ZK VM last year in the beginning of last year we're laterally raised a significant amount of money from Andreessen and other investors to implement this vision and we opened the first public zkvm testnet in in January last year it's not

running very stably and about to be launched soon on on the mainnet the mission of ZK sync is to accelerate the mass adoption of crypto for personal sovereignty and every design decision in the technical space we do we approach from the perspective of this mission so we'll walk through these slides and uh take this perspective again and uh the uh this is why we had to embrace zkvm we didn't actually have an alternative uh to this approach to scaling ethereum because ZK is the only technology we have that can potentially reach infinite

scalability without giving up the properties that make ethereum valuable without actually um break like you know if if you don't go for SDK you have to be restrained in the blockchain trilamma and either give up decentralization like not have every transaction verified by every single ethereum node or you have to give up security and you have to trust some people with certain security trade-offs and ZK solves both problems for you completely and evm is has become de facto lingua Franc of what will become the the internet of value that is the like for basically all blockchains are now embracing Decay sorry evm as the standard and there are so many tools

Services libraries written for it that it's really hard to to escape the the ecosystem you have to stay within the ecosystem and if you stay within the evm ecosystem then you have heard about this dichotomy whether can you go for uh full equivalence or is it sufficient to be just compatible in fact the dichotomies is uh slightly wrong we have a full spectrum reaching between the full equivalence to to just mere compatibility with some stages in between vitalik buterin had a beautiful article a couple of days a couple weeks ago now uh um introducing several types of evm approaches to AVM compatibility uh

putting them on this nice color between performance and compatibility and I want to walk you through them and give you some intuition on where the costs differences are coming from in terms of ZK implementation and uh then what then then show where ziki sync is in this uh on this landscape so we will start so the the the the yeah we'll start with basically with type four with the bottom degree where we we just have compatibility on the source code level you can take any code written for evm environment compile it for the specialized execution environment uh optimized for zero knowledge probes and

you get the maximum performance but you have the least degree of compatibility you get the maximum performance because you compile this is how we we do it we approach uh we compile solidity to first to Yule with Native solidity compiler then we use our llvm compiler to produce lvm intermediate representation then we compile it into the actual ZK VM byte code which is a risk uh kind of uh op code set optimized specifically to be proven in the ZK environment what it means is every instruction that we have in our opcode is selected in such a way that they all pretty equal in terms of

number of constraints which actually determine the costs of of proving operation in the easy key environment so uh since all of them are equal the at each cycle we have to actually execute all of them well we have to put all of them in our circuit so the costs are equaling the um essentially the the sum of the like the of all the op codes that we want to use so at each cycle we execute the sum of all the op codes right so since since they are like relatively small breaking down into like the most Atomic pieces the sum is going to be minimal and then

you can have complex uh programs compiled in like uh in a way that uses the the the the the the op codes in the most optimal way so this this gives you like the sum is small so the the uh the performance is highest with types one two three uh in order to reach full evm byte code compatibility you have to go for complex instruction set so you have to actually interpret evm op codes in the ZK uh and the cost of each cycle is going dramatically up whether you're using certain up codes

or not because in the evm we have some up codes that are very heavy very complex and it would be really hard to to interpret them in uh in the circuit uh so that creates a massive a dramatic uh boost of the costs and just going from source code to to evm compatibility this is why we start easy kissing when we launch now on mainnet we will be Type 4 system uh because for our mission it's critical that we have an option to offer developers the uh the highest performance so that we can actually onboard millions of people using some uh use cases uh like social networks or

gaming or just like a lot of payments that will require you to optimize the the absolute uh maximum amount of your application to to support the very very low cost per single transaction but it doesn't mean that we have to stop there if we have some really powerful environment we can always [Music] um simulate lower complexity environments right so if you have a Macbook you can always run some older versions of Windows those you know NYX systems from from 70s and this is what we're doing so we as a Next Step we're going to implement a

smart contract that can interpret evm op codes natively this is going to be a lot more expensive so the performance will go down but will enable us to take certain applications that are written in evm byte code that for some reasons people don't want to convert and recompile for this environment maybe for because they are already audited and you want to keep the absolute compatibility with the audit and do not not do the the re-auditing maybe because they are optimized in certain ways for you know just you want to keep them for historical reasons uh you will be able to do it uh at the cost of uh of having lower performance

um as a Next Step we will have to support the full API compatibility for all the pre-compiles and all the hash functions All The cryptographic Primitives of ethereum which is not very complex in fact we're going to support all the hashes indicating from day one the shot 256 catch up are going to be there from day one so we will only need to support the other pre-compiles uh specifically the bn256 elliptic curve pairings so that you can do recursive zero knowledge proofs verification in the casing but once this is done we will be type 2.5 system and we expect this to be probably by the end of year uh and then if we go up vitalik's

classification type 2 and type 1 are the systems that actually fully compatible fully equivalent to ethereum uh in the sense that gas cost calculation will be exactly the same as in layer 1 and for type 1 it would also include the block Rook uh block route verification with uh uh full consensus checks with full block headers now this degree of equivalence is actually um uh yeah oh yeah by the way a very very important thing like if we start with if we started with with a higher level if we started with evm equivalence we would not be able to go back because

you can always simulate something less complex on a more advanced system uh but you cannot really emulate a Mac OS modern one on some old Mac this would just not work from the from the performance perspective right but yeah going up is actually counterproductive for layer twos because the different gas cost profile um that we have in layer twos is actually there to be because the different operational layer tools costs uh cost a lot less than the cost in layer one and you want to reflect it in your gas metering in layer 2. because if you don't do this you're either opening

yourself up to a denial attack uh denial of service attack vector or you're just not giving people the uh the sparing in the uh in the storage cost and the computation cost which you could give them because those types of operations are a lot less expensive in uh in a properly built roll-up or validium for that matter uh so the type 2 type 1 systems could be useful if we wanted to prove if ethereum layer 1 itself uh but that would also close you from from the ability to use the the ultra optimized um applications specifically designed

for the ZK environment which will enable this million of users use cases so this is why we expect the kissing to stay at type 2.5 level system and that's it I want to open the the questions now because I think questions are going to be most interesting [Applause] thank you when playing with different evm chains namely mainnet on one side and like arbitrum or optimism on the

other there is a big difference that almost nobody is looking at which is the Assumption around block time stamp and block numbers and the regularity of this no this doesn't show in the layers you presented or Vitality came up with but it affects things like governance and time blocks and a lot of user application so do you have any comments on on this kind of feature which are like more hidden more user space and how you want to to implement them basically and so are you talking about implicit assumptions that blocks have certain duration because though those are the the implicit right like blocks can actually happen anytime and ethereum the next block in proof of work can be found

like half a second after the previous one yeah it's also the implicit assumption that the block timestamp is a monotonic function on some Roll-Ups like a hundred blocks could have the same timestamps because they are anchored to the same L1 block uh no no no in the key sync I mean I'm not talking about leaking on some more Labs it happens like that um so so what's the question so how do you implement block numbers and block timestamp and will that cause any compatibility issues with existing mainlet code yeah so that's what I'm saying like we at City sync we follow the ethereum convention so we have times like blocks in layer 2 have their separate enumeration they're detached

from the Block numbering of layer 1 and the block time stamps increase monotonically and they must be like it's it's constrained uh in the easy environment that they have to grow up so in this regard we're following like from the perspective of the application there is no difference from ethereum like you the conventions are preserved in variants are preserved I cannot talk about the other olives hey Alex hello thanks for joining us so the uh I would like to ask a question about time if finality times what are the what are they today what they will

be in the future and how difficult problem is that that's a great question so we have uh with any kind of roll up the we want user experience to be better than what you have on layer one so transactions are normally confirmed faster if you have a centralized sequencer it's pretty easy you can just always take a transaction from a user in your API and immediately confirm once we have decentralized sequencer and we're executing working on it you will have we will be aiming for very short blocks like ideally sub second blocks so that your transaction from the point of view of the user is confirmed

immediately the finality is reached though when you have a checkpoint on layer one and you like in in case of ZK roll up you'll provide the proof that this new state is actually valid so you need to be able to generate this proof uh so the there are two factors that influence the uh the finality one is how long does it take us to generate the proof for a number of transactions for one or more blocks right now this number is physicsync version one it's it's about 20 minutes for uh for like a batch of blocks for the keysync version two it's gonna be a lot less the the there are two reasons one is

that we're using a a much better Hardware we're actually going to use GPU accelerators for proving that are much faster than uh than um using CPUs and the second factor is that all the blocks are constructed recursively in parallel so we only have a few levels of recursion and each step of recursion is is very cheap so we expect the block generation times to go down to like potentially under one minute and maybe even like it at some point in the future it will be like just a few seconds so we would theoretically be able to generate the proofs for our blogs like every ethereum block uh that that that that is perfectly

doable the other question is um is it economically Justified because it proved with easy K proof on layer 1 needs to be verified and the verification costs something like half a million gas 600 000 gas for a snark proof and we're using Planck which is which is the bearing-based snark if we used Starks or like Stark similar systems like redshift plonky2 it would go up currently to like 5 million gas so you have to pay one like five million guests for for a block of and transactions so you have to amortize the cost of this block of this 5 million gas

across all the transactions if you only have a few of them it would be too expensive per transaction right so we want to wait for a block with sufficiently many transactions to to make it justifiable so right now on the keysync the this waiting time and for version one is is a few hours but we are only doing Simple payments uh I know that Starkville for example has it like much longer like I think they're doing the checkpoints every like a few times per day maybe twice a day but I think that with easy kissing version 2 especially with the addition of ZK Porter which introduces very very cheap transactions additionally to the roll-up transactions because you don't publish the data

availability on chain we will have a lot more throughput and it it will be a lot more Justified to have like very frequent checkpoints like if every few minutes maybe in like maybe every 10 minutes that's my guess but we will only see it in the experiments more questions right then oh there is a question right there uh yeah thanks for your presentation do

you guys uh for the ZK sync 2.0 support all the Geth calls or maybe you could talk a little bit about the like what you guys support or what you don't sure yeah that's that's the much easier part because the Geth calls the web free API uh is something the server can completely simulate so yes we will support close to 100 compatibility not 100 from day one but we will we will get to 100 because there are also some nuances like you you also have hooks you have other like more complicated operations but all the basic queries work just exactly the same way as they work on ethereum so we're currently integrating uh chain link we already integrated the graph the the graph is already indexing the kissing version to

test net by using the normal web free API so you as a developer will be able to use the web free API directly or using all the services that rely on of the API like the graph in exactly the same way so it's yeah from from developer perspective it's fully compatible still have a few more minutes if anyone else wants to ask so if we can like if talking about the tools generally uh all the tools that read the state are going to be working out of the box the tools that ride the state are like in in from day one of the key sync my

net um there are differences in the way like um how you deploy contracts because you need to compile contracts so you cannot just take the same tools like you're you're like natural truffle or a waffle or a hard hat environment and just um keep using it relying on the same web free API to push transactions because the byte code if you just keep compiling your contracts and solidity to evm of course this CVM byte code won't be workable that's why we have some plugins for for the deployment environment so that you have you inject an intermediate step in your scripts to to compile

solidity into ZK VM before you actually deploy contracts but like everything that reads code is is the same reads the state the difference that will always be the tools that we won't be able to support staying at uh at type 2.5 uh like because of Type 4 because of our source code like compatibility and having to compile these things uh is the anything that works at opcode level like debuggers tracers those things will never work out of the box we will have to integrate them

separately and work with the vendors to provide specific support for zksync in order to support them but those are like a very limited set of uh of tools that are currently popular and we will just be supporting all of them so you you will be able to use the same UI for the debugger like tenderly or like whatever you're using uh but under the hood you will just have different op codes and you will see these different op codes you will not see the evm up codes you will see the ZK VM by code but that is like [Music] um I think most people like I personally always use console log over debugger and this is what you always will be able

to use and just like re-execute the transaction from a certain state from in a certain position changing the code seeing what happens there like this is a lot more powerful than tweaking the the op code uh you know like disassembly and and trying to guess what happened there sure I'm just talking about the The Source codes and the type for layer will you you would mention solidity will you be also be supporting Viper yes we do support wiper actually it's it's already working yes so we will support solidity natively because it compiles into you and then we have like close to 100 compatibility we support Viper by compiling Viper directly into our L like we have a lvm front end for Viper so we

compile it directly into this intermediate representation but it works well and then we will be able to add uh llvm front ends for existing languages that already have llvm front ends like all the modern languages have it rust golang C plus plus uh python like whatever you and you want to use of course you want to use the language that is most suitable for for smart contracts but you will also be able to just take existing code bases for libraries and bind them into smart contracts so you write your normal smart contract interface and solidity but then you import some mathematic library or some cryptographic library or or compression mechanism whatever written in other

languages and you will be able to natively integrate it and be making calls into it in the kissing so like being separate from ethereum gives you a leverage to be able to experiment to add features on top of the existing compatibility if you go for strict equivalence you don't have this option if you are like if you have an option for equivalence and an option for experiments it's interesting because we natively support account abstractions for example in uh in in the kissing from day one and Argent is is heavily using this feature like um because you you like it adds so much more to the ux being able to do multi-calls

like with a single click from your meta mask it's powerful like not having to approve every single transaction uh or like not having to mess approved spending of your funds from for some smart contract is really powerful because it gives you the ux and security um and binding in like other languages is very powerful Etc so like we want to experiment we don't want to ossify now with what we have in uh in evm all right thank you very much Alex thank you guys [Applause]