Ethereum Foundation DevCon 6 - Layer 2s Track, 15 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

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

Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/scroll-pre-alpha-testnet-upgrade/

Why do we need secure scaling? How is Scroll different from existing zkRollups? What can Scroll bring to users and developers?
In this 20-minute session, we will introduce the design, principles, and the whole workflow of zkEVM, demonstrate our bytecode-level compatible zkEVM on testnet, and show you how easy it is for developers to deploy smart contracts on it.

Speaker(s): Ye Zhang
Skill level: Intermediate
Track: Layer 2s
Keywords: Layer 2,zkEVM,EVM-equivalent

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

A

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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?

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

It can be even further as we move move to like multi-block aggregation.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

So that's in stage one like we. We started this collaboration.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

B

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.

A

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.

B

Can I know the data availability strategy for scroll.

A

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.

C

Thanks for the talk, um what's the impact of York's on ethereum, on the components like the sequencer coordinator and the prover.

A

uh So you're asking like how, for.

C

How do you handle lyrics on layer, one three orgs the organizations or blocks.

A

uh You mean like one, they are once block, are not confirmed or yeah.

C

If blocks to get already organized yeah.

A

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.

D

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.

D

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.

A

You yeah that's a very cool question so for the first one as I mentioned like we will have two versions.

A

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.

A

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.

A

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.

A

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.

A

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.