Scroll Design and Architecture

Transcript

hello everyone I'm Hai Chang I'm Kat here I'm today to talk about the scroll design and architectures and how we transform the ZK even circuits into a layer 2 uh zika raw player tools okay next please so okay so for those who uh doesn't know haven't heard about the scroll so and then let me just use one single sentence to summarize what screw is building so the school is building a general purpose evm equivalence EQ drop layer 2 Chainz 2 scale the ethereum so that's a very simple like a straightforward and before I dive into any technical

details let me first describe the principles that this in the back to guide our designs decisions so first and foremost we believe that ensuring the user security should always come first so in school that means all of the layer 2 transactions should share the same security level as the base layer the assume layer even without trusting any layer 2 operators and then we should never trade off any uh the user security for any other properties and second maintaining uh an effective ethereum scaling Solutions should give users and developers a seamless migration pass from the existing developers or existing devs and developer toolings they would believe that maintaining the evm

equivalence is the best way to achieve this property and third as suggesting previously talk a lot about the censorship right decentralization is one of the key property to achieve the censorship resistance and we believe this is also one of the Key Properties we should achieve and then even in the layer 2 context and then this decentralization can help the protocols ensure the protocol to be resistant to the any censorships or coordinating tax and inside the scroll though we consider all aspects of decentralization across all layers including the sequencers provers and then a community of the users and Developers and then fourth uh for a user on a layer 2 to achieve a great user experience on

the layer 2. we believe there are two Key Properties we need to achieve first the transaction fee should be uh low and then orders of magnitude the lower than the base layers the ECM and a second the users on layer 2 should experience uh instant preconformations on the layer 2 transactions and the reasonably fast finality time on the settlement layers to achieve these two properties you also need to achieve very great efficiency when designing the zq raw layer 2 Chains and then let's take a look at see how the design principles guide our those principles guide our design decisions first the user security and even recruitments lead to a ZK evm based CK

drop Solutions so first people already know that ZK Rob is a secure as sap guaranteed by the mass and the zero knowledge protocols behind that and then the zke even is the Holy Grail inside the CK drop as I maintain the evm equivalence as well as achieving the same security from the zkrop and SEO knowledge proof protocols and then uh and then second uh the decentralization uh principle leads us to design a decentralized proven networks when we're designing the ZK event circuits we quickly realized that putting the evm into a ZK proof will result in a large overhead because of uh because of the incompatibility of the base Fields so that leads us to design a

decentralized and working less proven networks that can help generate the zq proof ZK proofs and scale up so there are two two key benefits from the having a decentralized proven networks first we will We design and build our proving infrastructure to be highly scalable so that we can easily scale up the proving Powers by adding just including more proving nodes in the network and the second and the community will be incentivized to build a more sustainable uh substantially uh better and more effective Hardware us and software Solutions and then they will can run the proving nodes themselves instead of relying on the scroll to running all of

the approving in the centralized ways it didn't next time and then third the efficiencies so we focus on like we believe that to achieve better efficiencies we need to leverage a lot of innovative research driven solutions from all of the communities our ziki even designs leverage and takes advantage of a lot of recent breakthrough inside the serial knowledge proof systems the proof aggregations and the ZK Hardware accelerators and we also build in an open source community in an open source way like our circuits and then things like that has been open source from the day one and then this allows us to be built with our open

source Community including the PSA team Foundation foundations and other open source Community contributors and I believe like with the discussion and then the collaboration with all of the open source Community we can find and build a best and most efficient solutions for the DK evm and SDK Rob chains okay okay now let's take a look at the scroll architectures so it involves two layers one is the layer one which is a layer and the second is a layer two or scroll are chains so in this layer one serum we're mainly deploy two contracts one is the bridge contract for bridging any assets between the layer 1 and layer 2 and for other general purpose messages and second is the Rob contract that's going to record any data availability uh

from the layer 2 Chains as well as the ZK proof to and verify that and in the layer 2 we have the scroll node uh which uh which is going to be responsible for accepting uh processing the layer 2 transactions generating layer 2 uh blocks as well as like the accepting RPC course so if you take a look at a closer uh to the to the screw node there are three modules in total the sequencer the layer and coordinate and the sequencer is basically the key component inside the scroll node that's basically a process the layer two transactions access RPC requests calls and then generates the layer 2 blocks our sequence implementation is based on a fork of the gold ECM which is one of

the most popular and commonly used execution client for the ECM and then but we made some tweaks of the goism to adapt for the layer 2 purpose and then by forking directly forking the goal is same implementation we believe that it can achieve the best and compatibility and uh for all of the uh with the ECM as well as like all of the RPC interfaces and next the relayer is going to be basically it's responsible for relaying any tokens and message between layer 1 and layer 2 by watching those any logs and events from the bridge contract that really also upload any data from the layer 2 uh layer 2 blocks and then to the roll-up contracts as well as roll up

the ZK proofs into the Rob contracts as well um and then third module the coordinator the coordinator received an execution Trace from the sequencer once like every new block is generated and then it can dispatch its execution trees to the rollers which basically we call like the rollers are the provers for the ZK through generations and those rollers are using the utilizing uh basically the rollers is running the ZK event in behind to generate the validity proof uh to prove the correctness of all of the transaction has happened executed in a layer twos and we expect that the rollers to be running on a hardware accelerators our current implementation use GPU approvers to speed up the proof

Generations but we expect that the community in the future can come up with better either like software Solutions or better Hardware to further reduce the proof generation time and reduce the cost to generate the CK proof and those all of the rollers were constructed I decentralized The Proven networks and it will be run and then managed by the community not only by the scroll team uh and then if we take a closer look at what happens inside the rollers actually it's more complicated than just running a ZK even circuit so first the ruler will receive the execution Trace uh from generated by the sequencer so the execution Chase includes a few things first it has the accuracy execution steps like step by step well of course

you executed when you're executing these transactions and the second it will have the block headers and then the transaction data are going to be needed for the uh to to generate the ZK proof it will also include a contract by code to make sure like the by code you executed will be correctly verified inside the ZK evm proofs as well as like there will be uh the Merkel proofs that are going to improve uh used to prove any state transition from all state route to the new state route and then next the execution Trace will be passed into the circuit input Builder but it's going to transform all of the information included inside the execution Trace into your joint circuit the waiting is into the circuit uh and it will be like the uh expanded the data

a lot because when you're trying to prove that you also need to generate a lot of auxiliary data and to fit into the witness of the circuits and then when we talk about the ZK even actually it's not consists only single circuit but actually it comes with a set of circuits so for example at least here like the evm circuit which is the core circuit inside the ZK evm that is going to prove the state transition of the virtual machine of the certain virtual machines and it will execute like the op code by op code but I won't go like much details into the event circuit and other circuits uh in this talk and then second the ram circuit is going to be responsible to constrain any read write operations that happens inside the external virtual machine found for any

stack pops and pushes and a memory read and write and any story changes and then third the story circuit is going to prove the uh the stage root transitions uh basically improving the local tree that translate from the old state route to the new State Route by applying all of the storage uh changes to the uh to all of the countries and then the stage the storage is inside each contract account and there will be some other a few uh auxiliary circuits are going to help the event circuit to prove some complicated opcodes such as the shot 3 the cash functions okay and then all of these circuits will be generating a single uh each circuit will generally approves if you're just uploading all our proofs immediately to

the layer 1 Roll-Ups contract then we're results in a much more overhead in terms of the cost and then the gas cost on the exam so in order to reduce the uh this overhead of multiple proofs from those set of the circuits we further apply an aggregation circuit that's basically it mimic the verification logic happened inside the verifier of the those proofs and then you you can aggregate this multiple proofs from the Z key element into an aggregations proof yeah and then we call this aggregation proof like because like this is execution is Chase is for a single block so we call this like a block proof and then this is like what happens

inside a single uh a single roller and then you can expect like the proof generation the whole proof generation processor takes us a longer time than the block generation time so you can expect the uh you can expect there will be multiple rollers that are going to execute and generate this block proof for different blocks in parallel and then to further reduce the overhead of the verification cost on the layer one so we can then apply another layer of aggregations so basically you can aggregate these multiple block rules using the same aggregation circuit and then q and aggregation proof that would be like the final proof will be roll up into the layer one ECM chains okay now let's putting this everything

together and then see how the SQL zkrop work in the actions in this timeline uh graph so first the sequencer inside the scroll node was going to generate the layer two blocks and then once like the block is proposed by the sequencer we just call it a pre-committed block so the pre-committer just means that the block has been proposed by the sequencer and included in the layer 2 Chains but it's not a canonical part of the scroll layer too because there's nothing like that has the no block information has been posted to the Sim the user can still uh like act on top of those pre-committed blocks in anti-speaking like if the user trusted the sequences in the layer 2.

and then once the uh the layer 2 block has been generated so we'll extract X will extract some certain informations From the Block headers and transaction data and upload them into the layer 1 Rob contracts for the data availability and once that data available uh once that like the transaction has been confirmed on the layer 1 for the data availability then we then the block status Transit from the pre-committed to the committed blocks so here the committed means that a block data has been already uploaded to the layer ones and then you cannot like that any modify those of the data on the layer twos and then what happens like the next is that we will also like meanwhile you

also extract the execution Trace from these layer two blocks and send to the coordinator which then forward this piece of Trace into one of the idle rollers for the ZK proof generations to generate the block proof um and then you can see like there will be multiple blocks uh happen like in parallel and then the proof generation will be run on different approvers on different rollers so on and so forth and then after a while like the uh if the proof generation has been already generated by the rollers and reply to the uh reply to the coordinators the coordinator is going to batch a few blocks proofs together and then uh issue another special request to the uh uh to

another rollers are going to generate the aggregate proof Generations uh render aggregate proof generation is not going to aggregate multiple block proofs into a single aggregation uh single aggregation proof yeah and then that aggregation proof will be replied back like to the coordinator and then now we're going to submit it to the layer 1 for verifications and notice that all of the previous data availability uh the data that has been draw up in the Rob contract will be also the input to this verification contract are going to verify the data that previously uploaded to layer 1 as well as the aggregation proof to the uh aggregation proof of these blocks and then once that transaction has been

correctly executed and confirmed then we can translate those blocks that be included inside this aggregation proof as the finalized blocks and this like the final Xbox that means that it has been a canonical part of the school layer tooth and have already been you have access to the data of those blocks and as well as like those blocks has been secured and verified by a ZK proof okay yeah okay so that's like about uh everything about like our architecture and Designs so we have been running this pre-alpha test and of everything like we mentioned before uh for like about like over a month and our pre-alpha test and that consists two parts the one is the scroll layer one which is a fork of the same utilizing the proof of authority

based consensus and then scroll layer 2 which is a zero Notch based row of test net deployed on top of the scroll layer one and then on top of this uh test net we provide a few pre-deployed demo applications including the faucet on the layer 1 not going to issue the test tokens for the user to play with our test net and then the bridge we're going to transfer the tokens between the let's go layer 1 and scroll layer 2 and then swap as basically a fork of the units of V2 deployed on the layer 2 for some of the tokens or provide liquidities and then and then we're also going to generate all of the data available we'll roll up the data availability to the scroll

layer once as well as generating the Xeno knowledge proof uh the validity proof on the Fly and then you can see like the uh all of the blocks the state of the blocks we're going to translate from the pre-committed to commit it and then finally like going to be finalized by the availability proof inside this Rob's Explorer and then to become an early tester and contributors you can sign up at our signup.school.io um yeah and I was also like the letting more and more uh users and testers into our test net for that okay so previously it's all about the scroll and then so the next few minutes I'm going to talk about the ethernet roadmap and how the

external door Mark is going to impact the scroll uh as well as like other layer Tools in general so everybody know like the on the the graph on the right is the roadmap like the ECM Foundation has put for the roadmap and then we know like the merges is coming very soon like the probably two weeks and then there comes like a follow with the uh the search and with the tank charting and then the uh The Verge and then the plurge and then the spurge and don't have everything to that so first of all like for the proof sticks and the merge it doesn't have immediate impact to the layer choose but it's very great for the exam to achieve better Energy Efficiency like to be more eco-friendly but it's it's also like a

important stepsons for coming for the incoming tank chartings which has greatly reduced the uh the rub cost for the uh for the layer twos and then like I'm also going to talk about the end goals uh which like very ambitious co-foundation for the ECM is going to ZK stock everything so what happens after that this product then charting language comes like earlier and then we'll have the tank chartings is that it has a new type of the transaction called blob transactions where then after this like the problem charting now you can put a lot of data out of the layer 2 transaction data into this blocks like which is going to be very cheaply installed on us under those like the uh storage chartings and then

inside the real coordinator which is going to be accessed by the smart contractor in the layer one is only to be like a few uh simple things including the pre-state route the post State Route and then the ZK proof or the case commitment and now using those uh very like succinct information is then you can make sure like the uh still use the all of the Translating data like and I guarantee that the data will be stored in only Sims for the data availabilities so with this like the product chartings you can greatly reduce the cost of the layer 2 to uh to roll up any transactions to the layer ones because currently even though like the if you want to verify a zero knowledge proof under layer one it's still like compared to the data availability so the data available still takes the uh the most

significant part of the cost for the layer juice um and then like not only like that so we also know like that this product and then tradings so with the tank charting like you can have further uh a better use for data per blocks meaning I can put more data into the after you have the tank tradings and also because it can reduce a lot of the for the data very availability than bandwidth so it means like you can scale up like a more transactions So currently if you're talking about layer tools you can probably think of like a limit of 2000 transactions per second on the layer choose but with the product and sharing or dang chatting it could be like the one two two uh order of magnitudes like the higher than the current like

estimation of the layer 2 throughputs okay so last I was going to talk about like the so the end goal of the ECM like they're going to snacks sticky snack everything's so first like a very exciting topic is going to say like if we can integrate the ZK evm in the base layer so this will requires like the ZK email will be exactly like the achieve the exact semantics or all of the specs as the current ethernet virtual machine does and then second if you want to include the ZK evm inside the base layers basically you need to achieve a reasonable uh uh efficiencies like you cannot wait uh significant delay the confirmation the finality of a layer 1 blocks so you need to still like combining the new bricks through an

Innovations in the cryptography for greater efficiencies and simplicities um and the third deck is like the so people are thinking like also uh finally same it's like a CK snack everything that means like there's not only the seek it's not the execution client is also means that you can also think it's not uh the consensus layers by like doing some ck associations so it'll be like the ziki snack everything's um and then like finally I think the final server we're trying to upgrade uh for the quantum resistance like the post Quantum uh safety needs like that for using the new like the uh protocols like the zika products and then we scroll like it will be very open again it will be very glad to uh contribute to any

things like that on the same road maps and then trying to see like if you can help like contribute to all of things like in the open source communities okay uh thank you uh and then just remember you can sign up on our pre-offer test net at scient.gov.io and thank you very much thank you thank you hygiene