Scaling Ethereum Summit | An Introduction to zkRollup and zkEVM - Haichen Shen

foreign [Applause] [Music] with that we are ready for our next talk and for that I'd like to invite our next speaker hi chat I just gonna be talking about how Zito roll ups of the kdpms work especially from the context of how scroll is designing it and uh you can already saw him talk about the prizes they're giving you already talked about we already saw a lot of talks around how to think about these Technologies as blow-ups become more and more common and uh we're going to go into a lot more depth here now so without further Ado like to welcome him on stage and uh and get started so my chin it's great to have you here again yeah thank you for the introduction and thank you for having me here to present to all of the people I mean that they score boy and then skating we serve me event we're all excited so I'll only take it from here and uh all the best okay cool uh yeah hello everyone I'm hijin from scroll so today I'm going to give a introduction to the ZK Rob and then the zika even and I'm going to dive uh or just introduce like how does it give him spill you know what is ckm it's going to prove so give like a little bit more insights of like how we are building the CK event from the school okay so first of all we all know ECM is great because it's decentralized and secure and it has a humongous of community and developers are building on top of that but ECM also has its own problem that it's not built to be scalable so to handle like thousands of transactions per second so this is because of the blockchain Dilemma that one blockchain cannot achieve scalability decentralization and security at the same time and we all know like the so decentralization means that the chain cannot can run without any Trust dependencies on a small group of centralized actors and this is typically interpreters to be like the not trusted by any set of nodes and security means that go you can sustain the attack from a large proportion of the nodes uh reading the uh inside inside the networks and a scale basically just means that that's the blockchain can process more transactions than a single node and we know that the ECM and other like the traditional blockchain file for Bitcoin they all prioritize the decentralization and security and then thus and such that it both suffer from the scalability issues so to take a deep uh closer look at why ethereum or like other blockchains is not scalable it's because like the uh we can show like this like a diagram of this how exam works so users send transactions to and insert node and then the transaction will then be broadcasted to a P2P networks the proposals then will submit a block then everyone in the network will download this block and re-execute all of transactions inside this block to reach consensus so that means like all of the full nodes need to do the same thing like same contribution computation for every blocks and because the ECM is widely decentralized so hundreds of thousands of nodes will repeatedly uh during the same competition for every block and that's why the same is not like good for scalable because it sacrificed some like the uh it's actually fight it has a lot of redundancies in computation just for being resistant and being censorship resistant and then also being decentralized so how does the certain community plan to solve the scalability problems so about two and a half years ago Metallica post this blog post on the Forum so about the raw about this row of centric roadmap So the plan is to scale the exams through the Roll-Ups chains that can process more transaction on the layer 2 but having and then having the efficient settlement and finalization on the layer one uh just go uh to achieve the scalability and without sacrificing lots of the Securities for that so now let's take a look at how the rock Works in general so here now you have two chains the first uh the layer one in the same it serves as the settlement layers for any transaction happen on the layer twos and the layer 2 is becomes a less a less decentralized blockchain so that I can process more transaction blocks at a faster pace and periodically the layer 2 will batch all of transactions and Ascend sufficient data to the layer 1 with some sort of the proof to finalize all of the transactions that in this batch uh happen on layer 2's so the requirements for a Rob tipping and grow up is that the users can recover the latest State a state route on the layer 2 purely relying on the data stored in the layer ones and then there are two types of the uh Roll-Ups uh right now so one is the Optimus drop and the other is the secure up so I'll give like first similar intellect about what is the Optimus raw so the option is dropped is that it will just submit the transacting data to the layer 1 waiting for a period of time for the challenges so if no one challenged like the there is any validation within that batch for a certain period of time then that batch of generation will be considered finalized under their web and it cannot be reverted anymore however the drawback of this optimism approach is that the waiting period time is sufficient is quite long so that people need to wait for seven days uh to ensure that connection can be considered its finalized on the day one that's why like that people will like tend to work on another type of rock it's called a zika Rob and in the zika Rock uh every time like we will not only submit the data to the layer one but it will also accompany with a zika proof that can be easily and cheaply verified on the layer one and once this proof is verified by a small contract under extremes and then that batch of transactions can be then sync up finalized that's how I can achieve fast finality for the zkira with the zq rod so but like the actually the for the let's simplify the diagram a little bit so for the ZK rocks so basically you need to under layer 2 you need to build a drawer that's going to generate a ZK proof and then accompany with some datas and then both were submitted to the layer 1 for settlement and finalizations uh but the problem with the the key wrap is that it is non-trivial to build a ckrop system for many reasons so first is that to generate a proof for some competitions you need to write down your program logic in the form of arithmetic circuit and it's quite complicated and hard to uh to being like using only the additions modifications and some of the mass assertions in the circuit to express your computation your program logics uh and also he requires certain overhead to handle like the uh to uh to generate this linkage proof for the zkrops and also like even worse that uh different programs and different applications may have a different circuit such that like you need to encode or every application you need to write a new circuit to be able to using the zkrops and even words that there will be no composability between the different application specific ZK drops how to solve this problem of this no compatibility with different applications especially executor is that we need to build a general purpose dkrop that can run any type of applications and then one of the type is like you can uh is where we are building it's called Decay evm it what we do is try to put the same virtual machine into a ZK circuit so that any application any depths are written using the solidity like built on top of the uh ECM can be run directly on the in the uh on the on the layer twos and using the ZK evm to General to generate the CK proof without any applications are Deploy on the layer choose so that's the benefit of the having the ZK evm in the layer 2 in the secret Rod is that you can achieve the composability and it being also very developed developer friendly because all the developers need to know is still the solidity and using the same control chains Foundry hard hats anything like you're using uh on the layer ones you can also use it on the layered shoes but there are also some drawbacks for building the decaying event and so one reason is it's very hard to build so the same virtual machines uh is not built for the ZK so it's not very ZK friendly so you need to be very careful and a lot of like the and it's very hard to build like putting the entire exam virtual machines into the CK pool and then due to like this incompatibility of the basic field with the finite field using it in the zero Notch proof and also there's a lot of special up quotes like cat track or some bitwise operations and also the uh the signature verifications the ecdsa signature verification they are all quite special functions like and they need to spend a lot of effort to building the Z Cape CK circuit and also to generate the proof for the dkum there's quite large uh proving overhead for that so that's why like initially people are more tend to building the application specific uh they keep wrap instead of being as a king game so why is does it even possible now so there are many extreme reasons first we are not having better new knowledge proof systems we have like a lot of New Primitives such as the polynomial commitments the custom Gates lookup arguments and the recursive proofs all those like recent advancements in the new Notch uh proof protocols that makes the uh building the ziki event more practically uh available like viable in a second we have more Hardware acceleration available wherever right now like the mode and more like the state of Arts GPU approval items and then we also uh were expecting the fpga or A6 some accelerator DK accelerator Solutions in the future I can further bring down the cost of generating SDK proof and assert is that we have a lot of new open source tool toolings and Frameworks available and also like not to mention like the the school is building the sea Kingdom in the open uh Source communities with the exam Foundation like the PSE team from the exam foundation and other open source communities so there's lots of tools and resources available in the open source so that making the DQ including like the uh a variable and a practical so now let's dive in deep into a little bit like about the cake again so there's like a few different sneaking event flavors uh which the people they all call the ziki even the first is language level compatibility uh with the ethereums so that means like you can compile some evm friendly language like solidity or euro into a snot friendly medium which differs from the ebms and the second is spico level which you directly interpret the event by code directly inside the SDK circuit so that you don't need to use a different compiler's uh you can reuse all the same tool chains to directly use that and then you can run under the decaying game and then the last one would be the consensus level which you target for the full equivalence as they see uh with the evm using on the layer ones that means that this levels in Kem Can directly prove any level blocks and here like the what we are building in the scroll is that we're trying to Target for a biker level compatible or equivalent uh evm such as like the developers can using all of the existing tools to building on top of the scroll okay now uh next we're going to talk more about the Z key there and first let's focus on what the ziki even trying to uh prove so let's simplify the uh they send like the or the evm how it works so first of all at one time step like T you have like a state root trees that including all of the state accounts uh informations and also the any storage uh any storage stored in the smart contract and at that time uh you'll receive a new transaction and trying to do any like the uh transfers or executing some small contracts so you input these two as the input to the E7 virtual machines by going to execute and output the result will be a new word state with a different route after you apply the transactions and then looking inside what happens inside there's a virtual machine you'll basically get like a few different modules first you have a state machine that's going to interpret all of the byte codes inside your inside any smart contracts and you have stack and memory for any transient uh data by keeping the memory and also your access to two database one is the the bytecode database I go to load the smart contract from that and execute them in a second you have a storage database that can keep any uh State account information as well as like the any storage like the stored in the smart contract so let's like uh take one further step into looking at what happens like when executing the small contract so after you give like these two inputs the word stage and then the transaction to the design virtual machines and then what it happens like you're going to execute Optical by op code uh written inside a smart contract and it will end up with a execution Trace with different steps like it would do in a crush and then some push and then some M store and load and they do like the low summer call data on the generations and then execute like any special logic from the uh from the smart contract that will be finally ends up like modifying some data in the storage and in the state or country that will be generated a new state or state so now what we can even try to do like the ad like the additional steps inside this like the whole pipeline of the executions is that the ziki evm is taking the specification of the of the user virtual machines and then it was taking uh take also the same input data from the uh how the extended virtual machine does is take the word State uh snapshot and not taking any new transactions as the input data and what they're going to prove is that you're going to prove this execution Trace generated from the virtual machines is correct and it will also prove that the state routes were Transit from the old state route to the new state route so to summarize a little bit like the what does exam is trying to prove it's like your first Ninja approve the execution Trace generated from by running the essential virtual machine is correct and unique in a second that you need to prove the globe's global state state routes Transit from the old route to the new root okay so this is like some high level like the things about how what they came in is going to improve and then let's dive a little deep into the how we build the Z King event uh in the circuit so remind that uh I just explained that the ziki event is trying to prove that uh the trend execution Trace is correct uh with like after applying certain transactions and then executing some of the smart contract so that would be the logic is quite similar to what happens inside the circuit where the call circuit in the ZK event that we're building is a called evm circuit but event circuit is basically a state of machines mimic the uh the steam machine inside the instant virtual machines so you are also mapping all of the steps inside your execution Trace into your circuit which is looks like just uh in the in just like the Blue Table it'll be just looking like uh a two-dimensional Matrix and then each step will map to uh a slot inside the circuit as well so like 21 mappings to the steps and then one step will be corresponding to any op codes you are executing inside the execution Trace so the each step inside the circuit will having slightly different height due to the complexity of different up quotes for example the multiplayer the multiply op code on even maybe like it's more complicated than add up code so it may be taking more roles and more resources in the circuit to prove the correctness of that outcode and then if you uh take a closer look at the each step slot inside the circuit you will be separated into different sections or different sections so you'll be having the step contact not keeping some contacts of like the the stack pointers the program counter so the informations in a second will be a case which are going to switch on different op code specific uh constraints for example there'll be like the one case for each op code uh corresponding to like the two op codes you have inside acceleration machines but that this is basically a switch uh statements like you you reach engines at any languages and then the series section will be any up close special weakness that's going to help you to prove the correctness of any op code yeah it's like just explain like the for the step context you're keeping certain informations but for this current step is for example which code hash are you executing like it decides like which uh contract you are escalating and then some guests like you left it in the transactions the program counter that pointer and the current state route Etc they're more more informations and then for the k-switch it will be uh basically a bunch of selectors corresponding to each of codes in the in the instant virtual machines and also different error cases that's also important that you need to handle uh you need to prove and handle all all possible errors that will happen inside when executing the transactions and also we need to make sure that exactly only one uh case is is Switched down under each step and the last one will be some Optical specific weaknesses will be like some of the uh input data for example like the the word like the you're getting uh you're going to add together another results you can do and then there will be also some additional witness that's going to help you to prove the crackers of your job code so let's take an add up code as an example you see what happens inside the uh in the indexing key event constraints so first of all you need to constrain the step context is transitioned correctly from the previous steps so for example in the current step if I'm executing an adult code so the program Contour the next step program under will be increased by one from the current step and at the step pointer will shrink by one because to add up code the Pops to a keyword from the stack and push one back to the stack and then the gas left will be like reduced by three because the add up code will consume three gas in the evm and second it will be a hard case switch that means I got only one of the case like one of the up uh the case will be selected we just add here so that means like this so first you need to prove uh each uh all code will be our case the selector will be zero or one and then finally when you can stream like all of them sum equal to one and then last will be some Optical specific weakness here uh in that example we because of this uh field incompatibility between the circuit and then the the event so even award has 256 bits but inside the inside the circuit you can represent a value up to 253 bits so that's why you need to break down uh you need to break down the uh those word into two parts like with the high uh 122 uh 122 8 bit and then low 1028-bit values and then so you need to do like additions from for you need to say like the for the low uh 1228 bits the a low plus below will be equal to zero plus some of the carry-on like into the into the next high 108 bit and then do the same lessons for the high 1228 82 of 122 8 Bits uh additions here and now further what you need to do is then to prove that uh the uh the word a b are correctly popped from the stack and in the uh the output C is correctly pushed back to the stack so what you're going to do is you introduce an additional lookup table that help you as an auxiliary data structure to help you to prove any stack or memory operations gear so here what you're going to do uh for proving the stack pop is that you just do a lookup thinking like that okay so I'm pop up like the stack at a certain uh stack pointers which is a read and then that's all going to like the value you are going to pop up from the stack and then after you do the calculation of the word c here inside the circuit you're going to push back uh push the stack back and right back to the correct address inside the lookout tables and because these local tables is also constrained uh it's also constructed after the executions so that we need to have additional circuit to constrain that the lookup table is constrained correctly so this is some of the uh just high level explanation of the uh building the ZTE event circuit uh there'll be like a lot more details but if you're interested you can definitely look at the open source repo to uh to dive more deep into how the code is constrained there but just give you a high level of the architecture of the thinking event so the ZK email although we call it the circuit but it actually construct with a lot of sub circuits together uh to function together and string together such that it can be built uh to constrain that all of the executions happen in the user virtual machine so in the beginning for the ziki um you have the the core part is the evm circuit a service a stick machine to uh constrain each uh op code that has happened like inside the ethern virtual machines but for some of the seeking unfriendly unfriendly up quotes like the end or xor those uh bitwise operations the expansion or upgrade and then the catch up computations will be relying on like offload those kind of competition into the lookup tables and that will be further constrained by other circuits to help you to constrain the whole uh this up code and a second for any stack memory and storage operations we'll be relying on a ram lookup table as I just showed before so those like a ram lookup table that can it serves as a database that consists of the all of the records of stack and memory and storage operations so inside the ebm circuit you don't need to reason about like the crackheads of those operations but you just find a match inside that inside the lookup table the database of all the records now once you have a match inside this wrap tables you will consider the stack and uh push and pullbacks correctly the memory read and write is correct inside the um circuit and then you have some additional lookup tables to help you to load correct by code from the from the smart contract and you can load certain informations from the from the transaction coordinators and it's unblock metadata From the Block lookup tables so all these lockup tables will be then further constrained by some other circuits to help you to prove that those lookup tables is correctly constructed inside the circuit and then to in order to uh serve this um to constrain help you to write those all of the lookout table circuit you will also introduce some additional uh Lookout tables and additional circuits the final there will be some local Precision tree circuit will be constraining any reader write to the storage and state trees and then also there will be some transaction signature uh circuit you see dssing circuit helping to verify the transaction signature is correct and then there will be some RP encoding for the transaction here uh that would be some RP lookup table and RP circuit and then finally you will introduce a public input circuit that's going to connect the public input data that you uploaded with the drop and then constrain like the certain data is correctly calculated uh in in the in the Holy key event circuit okay so lastly like about scroll is that we are building the zika event with the community like with a lot of community members not only like scroll is doing that and and we also like the having this design and all of the code has been peer reviewed by the communities by the community members from like us and from the PSA team of the exam foundations and also like other many more uh people like who are interested in the dqvm and then contributing to those ethereum repost and if you're also interested you can also take a look at the repo and then you'll uh welcome you to contribute to the to the same report together and then lastly about our principles like the four while we are building the ZK event to scale the exams we still like to follow our principles when reading things first we aim to build an evm equivalency can drop so that it can achieve the Best in Class user and developer experience and second we still like to keep a Security First mindset when building the layer choose so we are like that we first have the zke members ZK raw protocols that can explicitly prove the practice of any executions and transactions on the layer 2 and we also actively uh having this external and internal auditings on our code base and also being a building with the community building like in the open so that like all of the code can be also peer reviewed by others not only like us building like in-house code and third we also believe in the decentralization matters in the later context which we think like it will be the key property of the blockchain to be censorship resistant and contribute also social resistant so that we are committed to decentralized across all different layers including we're having a tumor decentralized approval Network and a decentralized sequence or validator Network and then last like I'll just uh just just talk about like the we also have like a hacker song Bounty program in this event uh and then we will have three different tracks first we will ask you to deploy your smart contract on top of the school test net uh that's a public tested on the goodie and then the support deployment process will be just very similar to what you do on the top of the exams you only need to change RPC endpoint and the second is that we love to notch uh so show us your best application building new use cases that leverages the power-ups they're not proofs and the third track is that we want to see the developers and apps taking advantage of the cheap gas fees and a faster block time on the layer tools and you can benefit from the layer 2 scaling property and faster in additive with the dkrops and I hope you enjoy like the hacking on topless school test that and for more information you can also check out this website okay uh that's all about like my talk and thank you everyone for listening to the talk again I can take any questions from the audience actually that was that was awesome that was such a good review on how everything is set up uh my we don't have enough time for questions because um make sure that we can get to the next talk there's a Time concern on the other end but I'd love to kind of maybe just ask you one little thing as we get the next speaker setup which is if you have a wish list of what you would like people to build on school or just on sdkd is there something that you've been really wanting to see that you haven't seen yet or you think there's something that other people should try what's uh what's on your wish list uh yeah that's a good question so I think that which is like we we see like I think like the sneaky events including like for general purpose so any type of applications any like Innovative like the applications can be also like built on top of that of the scroll uh CK event uh later tooth but like I think like some interesting thing would be uh you can see like any ZK applications that'd be interesting uh like privacy or like any private votings or anything like this um like social application like identities like those applications innovates like the more easily underscore so that's an interesting point so maybe maybe I also misunderstood how would private building work here is it just the fact that you don't get to see the weights or like you where's the Privacy coming from in this example uh yeah so like to to just clarify like that actually the ziki wrap usually doesn't provide privacy by default so there's like it's more for the skating uh and the compression of the transaction happen but for like the any private applications you're probably like having the private Shield pool so that anyone can hide the identity of like the voters that you don't need to review your boat but you can still verify that someone uh in the in the pool in the dial like a uh loaded like that and only you can only about once so here's the same checks on like making sure that nobody's abusing it and having the information be right yeah that's awesome yeah well thank you so much and uh with that we are ready for our next talk so go hack on scroll and uh we'll see what people built thank you thank you Spectrum