Scroll Pre-Alpha Testnet Upgrade by Ye Zhang | Devcon Bogotá

foreign [Music] my name is yeah I'm the co-founder of scroll today I'd like to introduce growth architecture and our pre-oper test net upgrade before diving into more detail for those who are not familiar with who you are so scroll is a general purpose screen solution for ethereum so in short it's just making ethereum cheaper faster with a higher throughput and more specifically we are building an evm equipment indicator app so Technic speaking is a liquid up solution which is considered to be the most secure screening solution with shortage finality based on math and we are also evm equivalent by saying that I mean like in our digital up it's by code level equivalent which means developer can reuse everything that they use on ethereum layer one and two links including like hard hat and also develop development tooling and we can achieve like native by code level compatible which means you can make the code from layer 1 to layer 2 seamlessly and so in the rest of the talk it will be divided into into two parts in the first half I will talk about the architecture of scroll and how your transaction is being processed down scroll and in the second half I will talk about our important upgrade for our test net and the roadmap like in a filler future so now let's to take a look at the architecture of scroll so before dive into more detail to give you a better sense of how screw work let's take out the traditional like architecture for liquid op so the idea of thickerope is that instead of sending all the transactions to layer one you send all your transactions to a layer to node and then layer to node will run something on our proof algorithm and the generator proof so the proof will be verified on Smart contract layer one and so verifying is the proof is mathematically equivalent to executing order transactions so that's how you you get the scalability because for example if you only get 10 TPS it can so but but each connection is verifying some proof which is equivalent to executing 100 transactions then you can scale your your network massively so intuitively uh like the architectural scroll look like this so you need some sequencer which is sequencing the transaction after receiving that and the challenge layer two blocks and then you also need some relayer to relay message between layer 1 and layer 2. for example like there are some deposit from layer 1 directly through the bridge back and your relay need to relay this message from layer 1 to layer 2. and also there are some deposits where like sequencer I need to send this message to the relayer and after sequencer sequencing the transaction the catching layer two blocks it wasn't to the approver and the approver will run some algorithms like we want to proof algorithm and a generative proof and the relayer will submit it proof necessary data and a unique feature of screw is that we are not running this program in a centralized way but instead we have a decentralized proven Network for generating a proof so in our architecture we have a coordinator which will receive blocks from the sequencer and the generator execution trees it will dispatch the execution trace for different blocks to different products in our Network and the proof we call them rulers in our Network to distinguish from from miners they were around the KVM and the generative proof and then we'll send back group to the coordinator the coordinator will then send to the relayer and the relay up to the layer one so so the magic thing actually happens on the ruler side where you are running some vkvm and generating proof for the validity of all the transactions inside the block so now let's take a look at the what's happening inside the roller so after receiving this execution Trace from the coordinator of a certain block uh the the dollar will around the KVM so what is the key evm so the KVM is composed of several circuits so the the circuit means so for so one circuit can verify certain functionalities for certain parts for example evm circuit can verify that your evm like State machine moves correctly from for example like push to pop and to the next next by by next up code you are executing and then Ram circuit is useful to prove that your read and write for this virtual machine is consistent for example you you previously write to some place and then you read so this Ram circuit can can prove that those are consistent and there is also a story circuit which means when you are updating the storage you are you are doing things correctly and there are some other circuits to prove some other like functionalities for for evm including like ecd as a circuit for Signature and some bicycle circuits and some catching circuits for other functionalities and you need a circuit inputer in between to translate your execution Trace directly fetch from gas to the Circuit specific weakness um and then like so intuitively the KVM show will have multiple proofs right because it need to have a proof for evm circuit I have a proof for Ram circus so but so all those proofs need to be verified on layer one efficient so what we do here is that we build another aggregation circuit so this aggregation circuit is used for proving that the proof is correct so for example like you know your evm the aggregation circuit is saying that events even prove the crack run proof of the cracked and other circuit proofs are also correct so this is your aggregation circuit and in the end you will only have one block proof for for the whole for the whole block uh to prove that your execution Trace is correct and uh moreover like notice it was to notice that our our coordinator will dispatch block to different Proverbs so those dollars were General proof in parallel for different blocks they are not competing for the same block which will like have a better utility for the poor networking in our Network in our system because all the programs are doing something useful they are not doing something redundant um and now let's take a look at how your transaction is being processed on scroll and the workflow of scroll from a timeline perspective so from so let's start with the workflow of liquor up so uh if I'm layer one because you need a consensus so you generate block very slowly and on Layer Two you can generally block much faster and with a higher throughput so you generate multiple blocks and then after a period of time you roll up your transaction data and uh and the journey to let it prove to prove that all the transactions are correct and send that to ECM layer one but worth to notice that this block data doesn't really rely on validity proof it's used for data availability so what you can do here is that also part of course design that we separate this block data with validity proof so you will like submit the block data first on chain to get some like committed version which for example users can see their their transaction on chain uh like without even without the proof and the and then like you wait for some proof generation to to finally finalize your your transaction so accordingly like you have three different features for your layer 2 transaction one is called pre-committed which means your transaction is sent to a sequencer and the sequencer has already included your transaction in layer 2 block so it will send back a pre-confirmation which is just maybe three seconds and something like that so you get this free confirmation from the from our sequencer and the next state is called committed which means we already draw up your data on chain and which may which usually takes minutes and so users can this is a much stronger confirmation because users can see their data and they even like replace the data by themselves and finally it's finalized which indicates that uh you are regarding the proof and the proof got verified on layer one so that's the final state where you get the final confirmation on layer one because your proof is generated and verified let's take a look at the like from a timeline perspective so you send your connection to a to a sequencer and the sequencer has included your connection in the block so the the orange one it means the block is pre-confirmed and then like the the sequencer will upload your uh like data and with some proof to layer one drop contract and then like your your your blog get committed and then the sequencer will dispatch this block to the coordinator and the coordinator will find will improver inside our Network for proof generation like to to generate proof for this block and similarly for the next block sequencer will also like after committing this this block will also like coordinator to find the final ruler in the in the in the whole system and similarly you can do the same thing for for block three and block four uh and uh after after those proof generation the the approver will send back the proof to the coordinator and the coordinator received multiple proof and then we do another like dispatch to dispatch those those proofs to another prover and let the approver do some aggregation to further reduce the the verification cost because you can actually aggregate multiple block proofs inside one inside using one proof and then after this proof aggregation you finally get one proof which can prove that uh P1 P2 P3 are correct which means uh they they block one block two block three the transaction inside are valid and then you submit this plot it's the music profound chain for a vacation and uh the the the rough contract will use the previously input as some public input and they've proved to verify that it is correct and then like finally your blog get finalized so that's the final state for uh for a transaction um and we have built a special raw RP floor to show the block status so for example you you have like a few seconds ago uh you have pre-committed block uh which is the orange one and minutes ago you have multiple committed blog and there is a commit transaction hash where you can find which connection is committing your data and you can find your data Unchained um and there is also like finalized transaction hash which means for example your your proof gets verified and there is a finalized transaction has here for showing like which transaction content is proof and we like when you get verified so this is a special Explorer like built by us for letting users to know that what's happening like inside and now uh like after some like talking about the technical uh background uh I will introduce our Scrolls pre-alpha test net and where we are so three months ago we have released our test net our pre-alpha test net um that version is mostly for the community users where we can get user feedback uh like they can they can play without pre-deployed applications for example a photocop unit Swap and also through their familiar like wallet like metamask so it's all for users and users can also Bridge the assets between layer one layer two like for example they can experience the deposit and withdraw they can also see their transaction status through this real active Explorer so that's that's where we are like it's all for collecting feedback from the community to improve our UI and ux and also fix some bug ahead of time and uh we'd like to thank the our community for their helpful feedback so that we fix a lot of like bugs on the UI side and they improved our uh our front end a lot and we have onboarded over 10 10 000 users to test our bridge and depth and at the meantime we are still scaling our power pulling infrastructure to support 100 000 users hour wait list so the reason for that is that we don't open enough Proverbs for this for this test net so once we open this like decentralized poor Network for everyone we can scale out the users or the transactions throughput like massively a few days ago we make a very big announcement which is the upgrade version for our pre-alpha test net um so it's a very important milestone for us where uh so the most important upgrade for our test net is that we are not only a test net only for users and for pre-deployed contracts but we it's a test net for for the developers where uh developers can support can deploy arbitrary smart contracts on us so it's very important because it's like you know it's not only like interacting between users but you can actually you know Deploy on things on that and you can experience the seamless migration without any need to change any line of your code you can just directly copy paste your code from layer 1 and directly Deploy on layer 2. and we also support all the tools around because we are natively evm compatible native and even you couldn't see on the backup level we can support remix hard hat and unit Foundry and all the tools around and we like days ago we have a hexagon that is global for like a high class to to register to our test net and deploy things on us we have also done some live demo at East Global and also like yesterday at the VK Community session where like we let the community to deploy smart contract on us and we have opened this register to all the developers so if you want to become an early tester or the contributor Step at scroll.io early Dev and like you can you can experience how how easy it is that it is to to deploy things around us now just a quick summary for for user and developers so the developer experience will be exactly the same as the ECM layer one uh and uh so for the concrete performance so layer to block generation takes less than sets three seconds which means for example like for users you can get your pre-confirmation like within three seconds it can be even further as we move move to like multi-block aggregation it can be even bring down to like one second and your experience will be pretty good and the deposit really takes two minutes because you need to wait for six layer one blocks so it's not because of us but you need to wait for a clear one block block confirmation and withdraw takes uh around like six minutes or more depending on your concrete like how many products you have in your network and what's your throughput so URL this takes like two minutes to to one hour but they first approve our generation already like for one block is six minutes so it's very fast and uh yeah so that's for for our pre-off test net and now let's talk a little bit about our roadmap and uh and where we are and what we we plan to do from a high level our roadmap look like this so in phase one we have a pre-alpha test net for users and the developers so users can interact and developer can deploy arbitrary contract through uh right they are they registered and uh in field 2 we will move to Alpha test net which we will move to Let's very very soon which is a permissionless version and like anyone can do I could use that without any any permission and the developer can deploy like any contract without like register and so that's for our test set we are moving to that very soon and in phase three we open this layer 2 proof ourselves into the to the poor Community or you relate has a large overlap with the minor community so which means in this three we will open proof generation for anyone to be the approver and they can run their their poor machine and be one of our proven nodes to generally prove for us so that's in phase three and then we will move to field 4 which is our mainnet so the distance between like those like before magnetic that one is that uh because the evm contains many lines of code which has metallic indicates that it won't be bug free for quite a long time so we need very rich secure auditing for our VK VM to be really confident that we we can we can reach the state of magnet and also we need to wrap up the some of the rest leaky circuits to make that more sound and also improve our performance massively like through pre-oxidization and circular optimization and in the fifth file we will apply some research results which we are we are doing like during the like in parallel with the development is that for example a decentralized sequencer to make the sequencer more censorship resistant and also like we we can take we can we can we are doing some survey for some we are not the virtual machine and see if there are some interesting part to improve our leak events efficiency and so that's our like high level roadmap and the one thing which we hear really like a lot of things from the the community that people usually ask about our decentral approver and what's the requirement for running such a poor node and what our like plan for for for Hardware so like so I will tell a little bit more about our plan for this Hardware acceleration so we have three stages so in stage one uh we will build a private leaky event like GPU cluster for running this this prover so or we have already built a very fast GPU solution to generate proof our liquid circuits so the current performance is really good like for example one million guys only take six minutes to generate proof like people usually think uh like VK generating they could prove takes a has such overhead and is unaffordable but you know like it's actually very fast on on our GPU improver and beside that besides the GPU solution we have built we have also built a private GPU cluster to provide the very stable computation power for for our test net at this stage um and uh so it's already there and it's already live there and meanwhile we are collaborating with several large companies which are aiming at like making they want to prove faster they are they a hardware companies and they build more customized solutions for uh for making improve our faster for example they are building some ipg solution Asic solution and the GPU solution so that's in stage one like we we started this collaboration we already built a cluster there and then in stage two we will give access to our Hardware Partners to run our approver so they can test their approvers and a general proof for us but as stage two it's still for large Partners which they are committed to General proof for us and uh something like that and we believe that using even more customized approver can shorten the financial time and massively improve the user experience because you get cheaper approver and with even faster finality and so that's day two and in C3 we will finally move to this permissionless poor where I call that layer to proof Outsourcing where you are letting the external parties to run run the approver and uh we will open source our GPU approver with a permissionless license for everyone to use so even now like our CPU foreign totally open source you can already run the CPU approver uh if you want but just the CPU GPU proverb will ask you like you know improving the performance and will be open source later and anyone can be can run our approver and the product that will be permissionless and they can anyone can generate proof at home for us and we can also buy some customized Hardware from those companies or even stick to use because there are some companies are providing some provider service so you can stick there and use their service to generate proof for us so that's basically our our plan for this Hardware acceleration um and uh one last thing is that so we have very solid and decentralized Tech Team so we have four directions one is the infrastructure team which is building out our uh the whole infrastructure making that more more robust and to support the permissionless testnet and it's really based in Asia and Europe and we have Decay team each building the VK circuits and some critical parts and for example optimizing the approval performance um so those two are like engineer teams and we have we are we are across like six or seven time zones uh it's totally decentralized and also besides the engineering team we also have an in-house security team which makes things really special because the security team because we really care about user security right there are so many like Bridges or platform get hacked so we have this security team which composed of several experts like expertise in blockchain security smart contract auditing and crypto cryptography so they will be like in charge of our our security of the whole system and also like collaborate with external hikers and Auditors to to make our system more secure and finally we have a research team exploring very like multiple research reactions when example how to differentiate the sequencer and how to upgrade the next generation's proof system and doing a lot of interesting research like that and also around ethereum like we we are actually contributing to to a lot of eips and uh yeah so that's part of the research team and our vision is that we want to onboard the next billion of users for e3m because we think you know making the transactions really cheap and uh and your confirmation really fast will make more users going to ethereum ecosystem and everything we build is totally open and especially for the they came in part we are copyed with the with a large community for example the privacy and scaling exploration team for example foundation and several other community members and we want to find for decentralization across different levels like starting from designation of the approver so if you are a vision online and you really like what we are building and uh we are still hiring and check out our hiring page and uh I think yes that's it and thank you for um yeah hi um so obviously you have this like kind of cool infrastructure with like the prover and the sequencer could you talk about how like gas fees work in scroll how do you like price transactions yes so the gasket currently we hardcore that to be exactly the same as if I'm layer one but it's my subject to change if it doesn't match the approving cost but it will be minor mostly targeting some pre-compiled very extensive pre-compiled which are not leaky friendly but most OP codes will be the same and right now it's exactly the same so hi can I know the data availability strategy for scroll yeah so that's a good question so currently we are direct like directly submitting the road transaction data on chain as part of the data availability and we do believe that dunk charting and other like cheaper like Data Solutions coming very soon and also like by submitting the the low transaction data like users can replace the transaction when you are in the committing stage so you don't need to wait you know wait for the proof generation time to get a stronger confirmation ahead of time and yeah hey thanks for the talk um what's the impact of York's on ethereum on the components like the sequencer coordinator and the prover uh so you're asking like how for uh how do you handle lyrics on layer one three orgs the organizations or blocks uh you mean like one they are once block are not confirmed or yeah if blocks to get already organized yeah yeah yeah so so basically when your collection is within there too uh it can be comfortable really fast so this regard like the the it will only influence your deposit so for now like we just wait for six blocks and uh but yeah in the future it might have to change if you think it's not so safe enough but for now like we just wait for six blocks thank you for the presentation um I have two questions one of them is about the hardware component how do you make sure that there's like a decentralized network of like the people who are provers if you're like working with specific companies like how do you make sure that the approvers are a decentralized network versus being like centralized to one or two specific like fpga companies or GPU companies that become very large stakers and then my second question is so this this this process for decentralizing this the prover can you talk about some of the differences for challenges in decentralizing the sequencer like how does those two processes differ and like what are some of like the the different considerations for decentralizing a sequencer versus the prover thank you yeah that's a very cool question so for the first one as I mentioned like we will have two versions firstly that as we are collaborating with the external companies we will also open source a permissionless license GPU approver so anyone can directly use the gpuer if they don't want to use fpga or some other companies and we are not incentivizing the fast approver because for example like even if someone has an Asic approver or someone has a RPG approver uh they don't necessarily like you can beat you because so the strategy is that we will have a time period for submitting the proof as far as you can like submit the proofing time like you can be like incentivized so it doesn't necessarily you have to generate like you know one minute you can always beat the the other Brewers so it's more like for parallelization and how you are like making use of the computation power across the whole network in parallel it's not like so even if you have those Hardware partners for like companies you can still choose like whether you just want to run the independent layer using GPU prover or you need your service and so that's for for question one and for question two so so what we are when we are thinking of this is that so the program is easier to be decentralized because for example we are having for now like at this stage we're having a centralized coordinator so you can still have some like you know for example verifying improved and doing something like that and so when we are thinking of design the program sequencer because it's actually two communities because the poor Community requires specialized Hardware but the sequencer might be like just some some level of like uh decentralization and when you're making the the sequencer decentralized there are some like problems like for example like uh you if you want to do some like fourth grade draw and like all the interactions there if if it's much much harder there than like using a centralized sequencer so that's my part of the the problems and also like how you incentivize between like sequencer and approver and how to balance those those incentivizes that's also part of the the challenging problem we face and how to make your the whole system more efficient because you you still need some consensus there among those sequencers and uh yeah if that