ZK8: zkEVM: compatibility and equivalence - Alex Gluchowski - zkSync

Transcript

foreign spicy topic I think of zika evm compatibility versus equivalence so give it away for Alex hello everyone thank you um yeah so I'm from CK Singh which is uh uh the um project aiming to bring evm compatibility to the world of ZK Roll-Ups we built the very first functional ZK roll-up on ethereum which is now known as a kissing version one uh and it's live on mainnet for two years

with simple payments and back then it was hardly conceivable that we will be able to do generic programming in such a short period of time but here we are we introduced the concept of the KVM um one and a half years ago raised a significant amount of funds from from different investors like boundaries and Horowitz last year to implement it and we opened the first public test net for zkvm in January last year and now it's very stable and we are about to launch on mainnet in just 43 days we're very committed to this date um so the kissing is a mission driven project we're we're like our mission is to accelerate the mass adoption of crypto to Achieve Personal sovereignty

and every design decision we make technologically is considered from this perspective so like whatever we're going to discuss like always keep this in mind like this is the the central charging point for us so um and this is why we had to embrace the KVM it was clear already two years ago that evm kind of is going to win the um the protocol Race Across all the standards um that were emerging it became de facto lingua Franca of the internet of value that is that is becoming true with ethereum and other blockchains uh this is like JavaScript you know it's going to be sticky for a very long time there are a lot of tools Services libraries

um written for evm specifically and it's just going to stick once alternative at once are pivoting all to evm I have to support it um and ZK I don't have to explain it in at this Summit like it's the Holy Grail it's it's the only technology we have that actually breaks out of the blockchain trail Emma so the combination is what brings us to the cavia um now if we are talking about the KVM uh we initially set out to build something compatible with evm standard there's been since then a lot of talks about equivalence is a separate concept like compatibility is not enough you have to be like fully equivalent to to satisfy

all the developer needs uh but the reality is it's a spectrum it's not a binary switch and vitalik recently a few weeks ago I had a really good blog post about this introducing several types of compatibility like degrees of compatibility from like just mere source code compatibility to uh which you could call full equivalence and they are nicely put on the spectrum of performance and compatibility and you can see that we were trading off performance the higher on the compatibility we go so I want to give a detailed overview of the types and give you some intuition on why uh like what are the trade-offs what matters uh and

why it is so from the perspective of uh GK environment and where we are with the kissing so we'll as you can see like the the types are basically just adding one by one features type four is the very basic one where we take source code we can deploy anything written for evm and it will just work in exact same way as you expect or like basically the same way right but you cannot deploy byte code and the API will might not be 100 compatible and you certainly don't have like full block route equivalence but the higher you go up like you just add one by one those stitches so um there is a really big difference

between Type 4 and everything above Type 4 is um Native compilation like when you take the source code and compile it into risk like architecture it's not exact tricks risk standard but like it's reduced instruction set we do it using llvm compiler from Yule and we use solidity native compiler to get to you and we also have a Viper compiler which which compiles directly to lvm intermediate representation then from there to our ZK evm uh instruction set which is optimized for being provable in the ZK environment so it's optimized for us to be able to prove the execution trace of a program

that runs the zkvm opcode set in order to to do this we had to carefully choose the op codes to make them really optimal for the this environment so like if you're going with um an architecture that was designed for PC for phenomenon architecture you will not have this optimal property of having all the op codes as small as possible as close as possible in the course profile to each other so that you like you really have this micro basic blocks because in the ZK circuit that proves an execution Trace at each step at each cycle of the

circuit we have to implement all the constraints for this one step so like essentially the cost of each cycle is the sum of all of our op codes so that means you want as little up codes as possible and you want them to be like really really mini really basic like not taking too much complexity instead implementing the complexity through like using multiple op codes if you need that and optimizing that at compiler time uh so this gives you the lowest possible transaction cost from like for on the prover side from all the other approaches like buy orders of magnitude probably by more than one

order of magnets we will see why and but like this is this is a really important thing but the second important thing is it gives you the ability to experiment and go beyond what is possible with evm and Implement new features in an efficient way uh that is important for user experience and developer experience for user experience one good example is account abstraction we support in ziki sync version 2. um so you can do multi-call out of box so you just do one click in metamask or your wallet and you can execute multiple calls you can support um smart contract based wallets out of the box like Argent wallets working natively without having to like

instantiate them and do like complex operations to pay to just get to work etc but developer experience is really important and it's it's going Beyond just like pure convenience you can take libraries that are eaten for uh you know in any modern language that supports cell VM front end like golang C plus plus python rust and you just can compile them natively into our VM and use them as libraries and connect you to them to your smart contracts and using the really low cost like absolutely pushed to the bottom uh execution costs you can do like quite complex computations whether mathematical or like compression or

um you know doing some Transformations whatever you need like complex stuff like a processing large arrays of data working on like doing voting for example on on certain subsets on a certain snapshot of uh of your blockchain state Etc so this is something you would lose this second point you would lose if you went for fully video equivalence like for like essentially for any um any degree of compatibility above type four the main con for the main disadvantage of this approach is that obviously we won't support op code level compatibility so all the tools that work at opcode level won't work so we will need to re-implement them luckily there

are only a few of them so mostly it's debuggers and tracers and we can just work with the vendors to like there are a few of them that are popular we can just Implement support for ZK VM and they will work also okay um this is type four and yeah as I said like we embrace it at the keysync from day one of our launch initially uh because it's really critical to our mission to be able to support like real Mass adoption Mass adoption means excellent ux where users have better ux than they would expect from like Neo Banks and all the webto applications so you really don't want to

bother them with um with inconveniences with like multiple clicks etc etc and you really want to be able to support use cases that require the absolute marginal bottom of the costs such as social networks you know like we're talking about orders of magnitude so there is a difference between 10 cents per transaction and 0.1 sample transaction like this like it's quantitative but it really leads to entirely new skates new use cases being unlocked that are not possible if your transaction costs are in the range of sense and not like micro sense milliseconds Etc but all the types above Type 4 are let's call them CIS complex instruction sets

because you have to interpret or like natively execute evm uh op codes and they are complex they like some of them are simple like add some more you know jump compare uh would be basically what we also have in Easy KVM instruction set but you have some really ugly ones like push 32 where like you're manipulating 32 variables of your uh stack Etc like we're like working with storage working with some pre-compiles like hashes so there are two ways you can solve you can try to solve this one would be to implement a circuit that natively supports all those OP codes

as you can see the cost of a cycle would grow like will it just explode because you will have to like maintain the dish cycle you would natively have to implement uh like all these complex instructions and yeah the the this would be like the most expensive like prohibitively expensive approach in my opinion second approach would be to try to interpret Sisk and that is that is actually doable but it just gives you this order of magnitude or more overhead because if you remember here uh like

each opcode is is really small it's just like one cycle right but then to be able to interpret this op code if you just encounter add you would need to add micro instructions that like read this the the the op code make a choice like what branch do we have to go like compare execute and then update the counter each of that would be a separate transaction and then you would add a lot of them for like really complex instructions but you still would add an order of magnitude more to simple instructions so that is still sub-optimal but uh it is doable and in fact like we don't want to stop there

it is completely possible to implement the this interpreter just as a contract on the like natively compiled contract which you can write in its assembly in Rust in solidity and whatever is is most convenient to write so this would make ZK sync instantly a both Type 4 and type 3 system or like in in this classification we just go up to type three but we will be able to support both native code program compiled into risk zkvm and bytecode like that for some reason people don't want to migrate maybe because it's like super sensitive on security and they just want to to like be you know if they

don't trust the new compiler yet so they want to use the old tested code which is bottle tested with a lot of money on layer one or maybe it's just some Legacy code that just needs to be running for whatever reason maybe some like small uh or maybe like a good example would be deploying um to the same address on like multiple chains right so you really want to preserve the the same uh byte code so you can prove that it's the same hash as uh the the same like instruction hash of the contract called hash as on other chains like layer one so that would be doable by just implementing this simple interpreter in fact there are this interpreters already written in optimistic Roll-Ups because they need to

execute evm inside DVM so like one option would be to take those this code and adjust it another option is just to write something in from scratch and rust which I think is going to be way more efficient and then to get to type 2.5 we only need to support like 100 of the API what that means is all the cryptographic functions all the hashes and all the pre-compiles uh the hashes we're basically going to support from day one when we launch on mainnet like what we currently have on testnet and when we launch an um I mean that in 43 days we will have k-chack and Shadow 5 6 natively supported they're quite cheap thanks to um Blanc and custom Gates and lookup tables they're not very not much more expensive than Paterson hashes or like

algebraic hashes so we are actually natively using them other compiles we expect to be supporting by the end of year like the most complex one is probably the pairing computation the Enterprise experience and like well maybe other pairings in the future so uh but there is work going on on this so we will support them it's not a big deal and that's the only difference between Type 3 and type 2.5 so as you can see the the performance is essentially the same uh you know like you could get some boost in performance if you you avoided uh normal hashes and would switch to algebraic once but like if you really want to do that you you you're much better off with Type 4

anyway then you're probably writing your code optimized for for the key environment now if you go on to go up uh or actually yeah before that um it's important to note is that when we start with Type 4 it's like starting with a really powerful machine that can like you know like a new Macbook or like some some new processor that can simulate older systems mainframes or like MS-DOS or like older versions of Unix but you cannot really do the other way around you can take an old like 80s 90s machine and run a modern Market hasn't it so you really have to start at the bottom and go up because you cannot do

it the other way around and this is why we're doing this but if we wanted to go up higher um it's kind of it doesn't really make sense for an O2 so the type 2 would mean that your gas calculation is exactly the same as uh in ethereum with like at every op code is metered in exactly the same way as it's done on on layer one and block root hash would include like consensus mechanism and all the storage updates Etc so from the application standpoint it's uh you know it doesn't matter because you don't have access to you cannot introspect State on ethereum really um so

having consensus there would deprive you of the of the ability to experiment with consensus layers and in Layer Two but like that that could be pro and con but like the having guest metering is really disadvantageous and counterproductive because the cost profile in layer twos will always be in favor of uh computation and like uh over and like cheaper storage over layer one in layer one you have wild difference in in different types of resources how they emitter it uh compared to layer two right so if you force people to meter it the same way as it's metered on layer one you

will be either not having the advantages that layer 2 offers you like really cheap computation really cheap storage or you will be opening yourself to a denial of service attack Vector neither way is good so the only thing why you would want to use the type 2 type 1 systems potentially would be to try to prove ethereum itself like the the blocks like every single block of ethereum and uh going back to to Genesis or like latest three genesis but that would actually only give you the ability to quickly sync a node not not much beyond that because every new block would be coming like really fast every few seconds probably we don't have

the uh proof latency yet for like a couple of years to to be able to generate the proof so fast for like ethereum especially with like all the inefficiencies of type 1 compatibility so it's really not not a big deal so you would be like if ethereum wanted to become a fully succinct chain what they could do is just reduce the block limit to like from 12 million gas or 30 million gas to just like half a million gas make the blocks really lightweight and like kind of force everyone into l2s and keep the L1 just for the very you know like raise the gas erase the storage costs like really high and uh reduce the block uh the gas limit

so that like full nodes only work with a few storage slots that are actually commitments from roll-ups and everything else is happening in the Roll-Ups there's a much easier way to to approach this than trying to go to for a full type one com like equivalence what would it be real equivalent uh so yeah that's why we're starting with um type four and and going like really fast to type 2.5 what's the casing uh that's it thank you very much um really happy to take any questions and I also want to add that we are actively hiring and if you are interested in in zero knowledge proofs or if you are like want to do an engineering like whatever like we're

open in all roles both technical non-technical so please talk to me after the call after the uh the uh this talk uh thank you for attention we're really happy to take any questions foreign as usual does anyone have any questions wow really all right well I have a question actually um yeah so it's um it's not just an L2 problem for the metering resources actually it would be essentially any ZK chain or if this succinct verification right um the only their difference between metering for certain resources also like comes from the fact that you now have

succinct proofs for certain things so your computation is cost is also different so it wouldn't just be an L2 difference between L1 it would also be the fact that you have like your say transitions are verified by Sync proofs no or is that incorrect um so the the difference comes from the fact that in uh like you're you're trying to measure the cost of running a full node if you're running in a layer one full node you have to be able to access storage like really fast so first of all you're using computational resources which are limited because you're running it on a single processor you cannot use even like take use of multi-core because it's always executed sequentially until we have some like really fancy parallel processing of transactions uh so that's one thing uh

and you like you you just like you have to account for the fact that you're running it on tens of thousands or hundreds of thousands of machines right so like you have to increase to add this overhead there with ZK you don't have this because you only run it once on your approver it gives you some overhead maybe 100 x maybe a thousand X but that's it that's flat and then you can add like 1 million full nodes and they will all take that and for the storage is coming from the fact that you have to maintain ssds that are really efficient in like random access that's that's the the problem like with data availability when you just put the bandwidth when we push the storage data from uh storage to call data all you

need to do is just download a chunk of data directly a continuous chunk of data from the network you don't have to jump on on disk from point to point so that is like any any layer one like if you have a succinct layer one uh you will probably have the same profile as roll up yes cool all right we have one more at least one more question so uh the big benefit of web3 is the fact that it is permissionless and self how big is the risk in your opinion of some big company like uh startware conquering all the you know roll-ups

and just forcing old web 2 censorship in web3 no that's that's a terrific question uh that is definitely the risk is increasing because the L2 uh it's very tempting to have like higher centralization because you are like safe anyway right you can have a single centralized operator who will be sequencing transactions and then we're all roll up so it's the same security as ethereum and then you give this one entity the right to standard transactions so like we need to be racing now to decentralize L2 sequencers ASAP like all of the Roll-Ups like whoever doesn't do this doesn't have a right to it like you know they can be doing some corporate chain

like I cannot talk for starkware like we don't want to become a corporate chain we want to build a permissionless protocol in the spirit of ethereum we are fully aligned ideologically with ethereum we're fully embracing the effects of ethereum so we're going to be fully open source permissionlessly open source it's very very important to us so we haven't open sourced version 2 yet we're going to do it after the audits but when we do with together with the launch it's going to be MIT Apache license so anybody can Fork it not just open source for read-only purposes and like copyright version right um so that you can Fork it away if the the chain that like we we initially launch is not fully decentralized it's not embracing the ethos you you should be able to move away this is why we're

supporting uh priority queues for like forced exits and they are going to be working in the batch mode so that you can do Mass exits so like if you have so the way it's going to work is you're going to have some decentralized consensus running the the sequencer uh it can have some trade-offs it can be less valid letters it can be more validators but if some chain like and there will be multiple chains like maybe a cell freeze maybe is a separate instances if some of them are sensor and transactions from the users the user should just say crew we're going to mass exit to a different instance run by someone who is not centering because they have a better digitization are you are you aware of any proprietary

like um like I don't know Technologies by stockware that uh give them like benefits over the casing provider yeah well like patented I don't know is that is this thing at this point that is not a thing because what they're building is is Cairo like it's a completely different direction from what we're doing they're they're diversing like they are uh yeah essentially diversity from ethereum they're going there they're telling you you have to learn this new language re-implement our recording it re-implement the entire ecosystem all the tools all the libraries from scratch and and just use those libraries and then you're gonna use it under Polaris license which is uh under copyright and you only may use it

with one single sequencer that is designated by by this multi signal or whatever like um uh engraved in in the Polaris license right and then you don't have a choice you cannot Fork away so like that's a classical lock-in which might be beneficial if you are a corporation you know you want your slas you want guarantees so you're going to go there and again you're going to use it and then you're going to have your support or whatever it that's not our way our way is to be compatible with ethereum so that like you don't have to learn stuff you just take existing code take existing libraries we support like web free API completely hundred percent with um other reads rights uh uh based on that we are we have Integrations now

with chain link with the the graph where you can use those apis just the same way you you would use them on layer one on on other Roll-Ups uh and um so like and you can Fork away that's the most important thing should be able to Fork away that's what what like what makes blockchains beautiful it's a little harder with with layer tools with like there are some specifics with upgradability that make it really hard to you know you you cannot Fork win all situations if like if there are vulnerabilities that are immediately requiring fix that is still a hard problem that I don't have a perfect solution to uh but for normal operation if you're just being censored by validators you should be able to mass exit away well I think this is the last question

unfortunately because we're about to get to the break time but foreign but I just wanted to ask because it seems like in order to to allow for the censorship resistance we need both uh validators and improvers that are acting in the best interests of uh of that cause but then given that the the approvers are like you said working on an overhead of like a thousand a thousand X to whatever if I would be doing what like what incentivizes people to to run uh approvers um you know proofers are actually easier so the validators are uh like more at risk of centralization because we want the the best ux best ux means low

latency for transactions you want transactions to be confirmed instantly uh the programs can be fully permissionless so once a block is formed by the consensus of the sequencer anyone can be building that block so there will be some Provisions some some like some sequence which is expected to run so that you don't have a race like the two people do not work on the same proof at the same time but that is minor like anyone who has the block data from the from the consensus can can be building the block and the proofs are going to be decentralized very broadly because we are using uh GPU accelerators like we we brought the latency down to just like some seconds like half a minute a minute for uh because we everything is around in parallel on

different gpus the gpus uh give you a boost of several uh orders of magnitude of um of improvement over CPUs and when I say boost of performance I always mean the costs but the latency is going to remain flat because like the latency is determined by the number of steps of recursion uh and at each step we do like 20 uh like we we can aggregate to any different proofs or like more and then you know like you you just have like three steps that give you blocks of basically arbitrary size of tens of thousands of transactions each step takes like 15 seconds on a powerful GPU and these gpus are abundant we have a

lot of them now freed up this morning with emerge and they are not going anywhere and like we will always have a lot of gpus like running on computer like you know gaming and machine learning and all this stuff which we will be able to reuse and and the best thing about gpus is they are very decentralized they are enhance of a lot of people so we'll be able to build a network of decentralized provers that uh just like do this job and and we aggregate so like Proverbs are less at risk validators because of latency is more important but my guess is we will have several instances maybe like SNL free and like l3s are coming very soon uh where like Samuel freeze will be optimizing for latency maybe for high

performance trading but some of them will be optimizing for censorship resistance and you will have hundreds of thousands of validators to make sure that you actually always get your transaction include great thank you so much Alex uh let's give it up one more time