Scroll 🛠 Scaling Ethereum with Rollups and Zero Knowledge Proofs

foreign [Applause] [Music] to the scroll Workshop scaling ethereum with Roll-Ups and zero knowledge proofs joining us today is Daniel Hill who will be taking us through the session and with that I'll pass it over to Daniel to get the session started hi everyone thanks for joining oh this is a scaling ethereum uh with Roll-Ups and zero knowledge proofs introduction to scroll and the ZK evm just for a heads up this is a pretty non-technical talk I'm hoping to give a real overview get people's uh I don't know get get the get the basic building blocks and mental models of Roll-Ups there for people who it might still be confusing too um our co-founder Hai Shen gave a little bit of a demo going deep into some of the architecture and how zika EVMS work so if that is up your alley a bit more check out the YouTube recording but with that I'm going to jump in here I am Daniel Helm I lead developer relations at scroll and if you are unfamiliar with scroll we are building a scaling solution for ethereum that is a ZK roll up okay so that might be a lot if you don't know who we are you might go to our website and you see this you see the native ZK evm scaling solution for ethereum it's a ZK evm based ZK roll-up on ethereum and all this jargon right like if you read this and you're unfamiliar with even what a scaling solution for ethereum means it might leave you feeling a bit like this so the goal of this talk is to to get people more accustomed to what this jargon means and and get you started building and deploying on scroll if you're only kind of getting started with these kind of solutions but if you are new here uh if you only take away one thing I want it to be that for users and devs scroll is pretty much ethereum um for the most part it's gonna feel and look just like using ethereum and to show that to make it a little bit less scary to think about ZK Roll-Ups I want to do a quick live demo we could go to something like uniswap v3.scramble.io a little demo test app we've got here and I could go to connect my wallet and it's going to ask me to not connect uh well the last way to connect I do that and then it'll say that I need to connect to the scroll Alpha Network which is a test net that we deployed about a week and a half ago maybe two weeks on top of Worley but I can then change my network but then you know the amount of Ridge squarely East that maybe I want to wrap into West I can wrap those and just like interacting with any other dap or smart contract here it's going to look and feel just like interacting with mainnet or a test net and the only difference being that the block times are going to be a little bit faster so we'll get into a bit of that here in the middle of the talk but I just wanted to show like nothing scary here for the most part you're just talking about interacting with uh with what feels like ethereum and that's that's by Design so let's get into understanding what scroll is what we're building and we have to start this kind of story off with part one blockchain scalability so you're underneath Global hackathon I'm sure you know a little bit about the promise of ethereum right but it is this platform for decentralized applications and we have this one network where we can share code and data create all these new possibilities and it is open to all anyone can join in undoing this great Collective work where we are doing all sorts of new consensus problems and everyone joins in as long as there's not too many people at once right this is the problem if you have too many people at once you might run into this right you go to deploy your smart contract you go to swap a token maybe mint nnft and you see that the estimated gas fee is insane right and and that is not usability you see this and you say oh maybe this network isn't open to me it no longer feels accessible to me so that's the scalability issue right and why do we run into this well this is the issue of ethereum blocks which I'm sure this audience is is very acquainted with we have transactions that are asking the network to do some amount of work right computational work we measure these things in gas and every block can only do so much work this is limited and at some point uh you know the block has to decide okay we have too many too much work too many transactions who do we decide but we're going to choose the work of the transactions that are paying the most for that work and so this is generally just the idea of block space that you'll hear right if it fills up gas prices increase in order to you know incentivize people to only make transactions that need to be making transactions uh but you also are edging out people that can't afford it so people yeah this is the gender problem scalability as engineers and developers I think the first thing we start to do is say all right that sounds like a problem let's fix it there's an annoyance there's got to be an engineering solution here and I think the first kind of approach so you can take is say well let's make the chain do more work if if we can only do so much work in a block let's just double that and then we half the fees are good to go right well though we have to look back at ethereum ethereum is this decentralized network of nodes and validators and every time we have something happening on the network right every single one of these nodes has to do that work everyone has to do the work so they can come to consensus and say this was our old State we caught this transaction did some work this is our new state and now we all agree on where the change should be and so what we you know see when we look at that is that when you say make the chain do more work what you're actually saying is make every single node in the network do more work right and that can maybe become a problem because when you have a super computer uh it's gonna say sure I can do a lot more work like ethereum is easy a couple transactions doing a little bit of work not a big deal but then when you look at people running you know Raspberry Pi's for their validators smaller machines maybe other resource constraints like bandwidth or whatever else uh not so happy anymore right you start pricing out or resourcing out uh these players from your network and so then we have what was a happy healthy Network looking a bit more like this and when we have all these sad nodes that can no longer participate in the network the network becomes weaker it becomes more sensitive to to to Bad actors and that's not what we want so this is a super high level understanding of one aspect of what we call the scalability trilemma this thing has a name I'm sure scaling ethereum you've heard this stated many times but the general gist of the scalability trilemma is this you have to pick two of these three items at the tips of the triangle right you need to be scalable or secure or decentralized as a blockchain network you only get to pick two so when we said let's make the chain do more work what we were really doing is go in with this typical high TPS chain solution right maybe the salon a solution where we might resource out uh we push out you know resource intensive yeah resource weak nodes in our network but in an effort to to scale it so what's our new solution well what if we said make a new network wow we can just spin up a whole new one right this might look like this we have a whole bunch of validators on ethereum but we can just kind of split them in half and we'll say on the left half you'll still be called ethereum but on the right half we'll call you ethereum prime you'll be this kind of other network that looks and feels and acts just like ethereum but now we have twice as much block space right this is great um well this is great until we start saying that now we have maybe half the amount of security half the amount of validators and I'm securing each Network so now uh the the network on the left becomes more prone to Bad actors not to mention we also have to figure out how to like bridge this divide of the line that's now separating the networks because we have two blockchain Networks and so this might be considered like the multi-chain ecosystem right this is another solution that you'll see in the space but it has its trade-offs and and things we don't like about it so um yeah that that's the the scalability trilemma in a nutshell if you want to learn more about this grin keep talking about it but but vitalik has kind of a classic blog post that introduce this as an idea so if you just search like metallic scalability uh trilemma I bet you'll find it so let's jump into part two layer twos and roll ups how are we going to try and get around this annoying problem well remember we've got ethereum this great decentralized Network that we've done all this work to make secure and we said that you know what it does is it does work right it has blocks and every block it does a big chunk of work modeled here by a beautiful gray box but what if we like break down this box into into the sub work that it does and maybe this is our minting in nft this is our swapping some tokens and try to imagine what would it look like if we took some piece of of ethereum's work and we said okay what if we just devoted that work to securing some other network what if we made sure that a new network wasn't breaking its rules using work on ethereum um and so this is kind of the novel idea here right what we can do is we can have an off-chain protocol that we secure using ethereum so some kind of like definitions here we have a layer two and it exists as its own off-chain protocol using a layer one as an important piece of its architecture and we call this being deployed on top of that layer one when we get into the idea of a Roll-Ups specifically we're going to be using that layer one for certain security guarantees so that could be you know ordering our transactions that could be data availability censorship resistant correctness things that you can go find probably more technical talks about uh and and the the larger scaling ethereum presentations but the the the kind of key Insight here is that when we talk about Roll-Ups on ethereum what we want to do is inherit the security of ethereum and that's the word that gets used by taking all these things that are these security guarantees we get to like Outsource them from the perspective of the off-chain protocol and rely on ethereum to to take care of these things and so what that looks like in our you know triangle here is that we get ethereum to lock down our security side uh and at that point we could actually start to say things like make a new network and make the trade do more work right because we no longer have the the issue of these security aspects and we can move towards scalability by doing both of these things we could make a new network that is able to do more work but still inherit the security that ethereum brings to us so you've probably seen a ton of these different projects that build on this right we have a layer one like ethereum and then we have all these layer twos and a whole ecosystem of them and you can see some some icons here but scroll is playing in the space as well so we're playing this game of Engineers we're designing our way to scale ethereum we've already decided that ethereum can give us our security but but what should we make our roll up do right because now we just have an off chain protocol we haven't specified anything about it we can do it whatever we want here um and maybe the Insight that I would bring here is that ethereum has an incredible ecosystem already um we're all kind of a part of this community by being part of things like youth Global uh and we already get to gain the benefits of the tools the educational resources the users the communities the smart contracts all of these things pre-exist in the ethereum ecosystem and they're what make it so rich and kind of like so attractive to Developers and so the kind of question is if we're going to inherit the theory of security why not try to inherit all of these things too right like why make someone learn a whole new paradigm if we can make these things also kind of get extracted into to what we're building on top of ethereum and so where we can let's just behave like ethereum's virtual machine and that's the thing that takes in the transactions and and does the work on the network if we can just mimic that as closely as possible then we're in a special position where all of the tools and resources and communities can just basically copy paste their code and redeploy somewhere else and benefit from from the scalability benefits and surprise surprise this is this is what scroll is doing and this is what we're building so let's get a little bit more into the technicals of how we're doing that but generally like I said for most users in dense using scroll is just like using ethereum and that's because we're designed in this way here okay so we said we're going to use some of ethereum's work to make sure that an off-chain protocol a new network isn't breaking its rules there's different flavors of this and different Roll-Ups are doing different ways to approach this so you've got scroll on the top here and a project like optimism or arbitrum on the bottom if you've learned anything about them you have probably heard of them or them labeled as optimistic Roll-Ups right and what they do is they have something called a fraud proof or a fault proof the idea is that they do a bunch of data they they do a bunch of work off chain but they put the transaction data back on the L1 and then they wait a little while and they say we're going to assume that this is all good to go and then we'll give someone seven days to say no someone's breaking the rules and if no one says that then uh we'll just continue uh knowing that everything's good in the off chain protocol now scroll on the other hand we are not an optimistic roll-up we are a ZK roll up back to this kind of jargon thing zero knowledge roll up and let's take a look a little bit at what is securing scroll if we don't have the the optimistic ideas of the other roll-ups to get into this we're going to need a super fast primer on zero knowledge proofs so deep breath we've made it through two parts we've looked at the scalability problem we've looked at kind of the protocol and how layer ones can secure our Layer Two but now we have to get into this kind of magic of zero knowledge proofs which I think in oftentimes get really complicated really mathy but hopefully this is going to be the simplest explanation you've ever seen and it'll hopefully get you the gist of what you need to know so let's do a little thought experiment what if we add a big block of work any sort of work and we wanted to do this work over some sort of data or input and it's a lot of work it's a really big amount of work that can only be done by an army of super computers right a really uh crazy amount but we can imagine that we had this special magical wand that made a receipt of that work and that proof of the work could be then passed to a much smaller computer that had a different program that was used to just verify it so this smaller computer didn't have to go redo all the work it maybe didn't even have to look back at the data but somehow there was a magical incantation that could create a receipt where we were able to verify the proof and just kind of trust the output all right this is seems pretty magical so magical that I think we'd have to use a time machine to get something like this we'd have to take the time machine all the way back to 1991. um okay so in 1991 we had a field emerging with papers like checking computations and poly logarithmic time and in the summary abstract here you'll see descriptions like in this setup a single reliable PC can monitor the operation of a herd of supercomputers working with possibly extremely powerful but unreliable software and untrusted Hardware so this is the idea of our small little Raspberry Pi being able to verify the work of an army of supercomputers right so this is a field that's been around for a while and recently it's been evolving very quickly and this is the field of zero knowledge proofs so we can change our kind of hypothetical here and to better understand how we're using our knowledge proofs we can say what if the work being done is not you know just some random work what if the work being done is actually the evm and what we have is the input are a bunch of transactions so we had new transactions the evm processes them and updates us to the newest state of the blockchain and what if the network was not a bunch of super computers but a network like scroll so what if scroll was doing this kind of work and we need someone that we trust you know we might not trust scroll as a network but we need something that we trust to verify this proof for receipt and we trust ethereum right we trust the computations that are done there because of all the reasons that we love etherea and so we can use a little bit of that computational work on ethereum to verify the proof of everything off chain happening on scroll and say yep Scrolls following the rules Scrolls acting just like an evm should act and now we can trust now that we've verified that the next state is the true state okay this explanation totally ignores this idea of private inputs into zero knowledge proofs this is things like privacy protocols a ZK evm doesn't need these so I'm glossing over them here but just so you know like this is a whole nother uh fascinating and exciting part of zero knowledge proofs but we are not using the Privacy aspect we are using What's called the succinctness aspect of this proofs and so we're able to take a bunch of computation and smush it down into a tiny proof okay so scroll it is a ZK roll up and on chain on layer one we are we have a smart contract that is a ZK evm proof of verifier and so we were able to pass proofs to that verifier along with some other data in order to say we are secured as an off-chain protocol all right so part four into scroll now why scroll so I talked a little bit about this but ultimately we've designed Scrolls so that it has great developer experience in terms of other Roll-Ups you might hear of other ZK EVMS but what is important about Scrolls that we are byte code equivalent with the ebm that means when you compile your smart contract uh what you end up with some byte code and those things refer to different op codes and stuff but that by code that you would commit on mainnet is the exact same byte code that you would put on our Network which gives it really really good compatibility with developer tooling existing contracts you don't have to go re-audit anything because you're not just compatible with solidity as a language but what the solidity compiles down into um scroll now as as the softchain protocol gives us a lot more throughput and so we have created more secure block space for ethereum which means that scroll is going to save your users some gas fees and because we're able to do this work faster we can also get quicker feedback to users so scroll aims at having about three second block times compared to ethereums 12. uh but the last thing that I think is like a wise girl that I like to emphasize is is alignment right so we we like to really believe that we're building an ethereum's Vision um this plays out in a lot of ways but the way I like to think about it is that there's scaling ethereum the technology but there's also scaling community and scaling ethos they're scaling all these things that aren't purely technological that that make ethereum a special Community um and we try to be heavily aligned with those things um and I think it comes through also in our Origins we are a open source project we initially actually came out of work on the ethereum foundation's privacy and scaling Explorations project where they're building in zkevm and we're still constantly committing code back to that repo and if you're more interested in alignment in our vision for for long term check out our website and some of the blog articles there so I'd like to just take a quick look at what it looks like um as transactions come into our sequencer so I got a layer one you know um well let's jump into a layer two we have transactions they come into a sequencer and they get executed right RX execution environment is just get if you're familiar with it just slightly modified um but what happens is our sequencer does a few things it's going to execute transactions that are coming in it's also going to watch for new deposits and our Bridge contract on the layer one and then it's going to roll up these uh not blocks but batches of blocks and say all that call data all this transaction data it's going to stick that back on ethereum and we that's for data availability purposes so all the you know swaps and mints that you're doing that data actually gets committed to ethereum so that later when we use approver to create a proof we can also commit the proof tip on chain and that roll-up contract can say four all this data coming in and the Old State we can say this new proof we can verify the update to that that state and this proverb here is oversimplified because this is actually a whole proving network uh and the goal right now is to get mainnet out and then the next work is to to make this a fully decentralized prover Network so that it is open and permissionless for anyone to provide proofs for scroll and then the beautiful goal after that is to decentralize our sequencer uh but this is a pretty complicated design space and we're still working through exactly what the details of that are going to be and yeah so I'm gonna just buy block give a walk through what it looks like when transactions come in on scroll uh running a type on time so I'm gonna try to do this quickly but we can imagine scroll having all of these blocks that come in we can batch these together and then literally write that to ethereum and then once we have the proof generated at a later block on ethereum uh emit that to ethereum as well and so you can think about different transactions of having different states I won't get too much into this but when a transaction is in scroll at all we can call it pre-committed once we've written that back to ethereum you can consider that committed we've committed to that data but not until that proof has been finalized on chain can we really say that the transaction is finalized and so this could be 20 minutes but that's quite different than the seven day waiting period for optimistic roll-ups and what this looks like kind of working across time we can imagine transactions coming into our sequencer that it bundled in a block the data and call data from that get committed onto the rollup contract on L1 and we now have that block being committed right that information then gets passed to the coordinator we call this a trace of the work that's done um and that gets passed to approver who's going to generate a proof this might take several blocks but that's okay we can make these things in parallel and so we can go through and create a handful of these blocks and keep passing them off to different proof generators eventually these proofs will get created and this is actually our pre-alpha Network on Alpha we have blocks uh we have batches of these blocks that kind of similar to this will then get committed on chain and verified and so now we see that once we've verified this all the blocks included in it are now finalized and that's kind of those states that I described earlier if you're interested in like diving deeper into this we have a roll-up explorer that shows a little bit of how this works but remember for most users in Debs scroll is pretty much ethereum but faster cheaper and accessible to more users at once if you're interested in trying out scroll we launched our Alpha test net on gwarly about two weeks ago and you can use it as you saw I used our uniswap example here but all it takes is an RPC change or to deploy there or to interact with it it's on top of whirly and if you need some bridged squarely don't hesitate to reach out in the East Global Discord and scroll Channel and let us know and we will send you some gwarly if you're interested in looking at how to connect your wallet testing out the bridge that's at scroll.

io Alpha and really importantly we have guide.scroll.io and oops um there you'll find our developer documentation so if you go here you'll find our developer info but most importantly you'll find our developer quick start which not only shows the network information but also copy pasting lines for hard hat Foundry remix truffle brownie ethers and scaffold if to get going uh with just some copy pastes into your current deployment well so if you're going to be hacking just want to do one last show for our prizes we're gonna have twenty thousand dollars in prices in total we have a prize pool for just deploying your smart contract on scroll no matter what other prizes you apply to you can deploy on scroll as well to be part of our prizable for ten thousand dollars we also have a track for Applied ZK projects we don't expose any of those CK Primitives we talked about but if you're building in ZK we want you on our chain so we've got two prizes for twenty five hundred dollars and then we have the last one here called cheap and fast block space utilizer and we really just want to see people testing the design space of of what is possible with cheaper gas fees and three second confirmation times from the adapt perspective so check out our prizes and happy to answer questions if I have 60 seconds to do so but yeah you've got some time there's um uh there was one question about uh from Stephen how long does it usually take for scroll to go through a zkp from pre-commit to finalized and what are the differences between scroll and ZK sync polycon and CK evm great question so from pre-commit to finalized pre-commit to committed is the fast one right basically we wait until there's enough blocks to fill up about 50 million gas um which just depends on how much activity there is on the network but let's say it's nine seconds and then we make a transaction on ethereum and so then we're committed there um the the longer one is is the proof when we hit mainnet I believe the goal is for those to always come in under 20 minutes um right now I don't know that we have enough provers on the network to keep up with the demands but the fast way to Jack is the check I roll up Explorer and you can see that the last handful of blocks because they're coming in very quickly are all pre-committed well let's just say we looked at quite a few here we have a lot committed and so I've already gotten back an hour and these are still not committed so it seems like our provers are not keeping up with the amount of transactions we're having coming in which is uh a blessing and a curse to have a whole lot of testnet activity on your network um but yeah right now it seems like it is several hours but um yeah 20 minutes is where we're aiming for but we have to scale up the number of proverbs on the network to do that okay what are the differences between scroll and ZK sync and polycon ZK ebm um one of the major differences between us and ZK sync is is that idea that I described earlier where ZK sync is what we call language compatible with solidity and so you are taking solidity you're compiling it into an environment for their VM whereas uh polygon and ourselves have a model where we are byte code compatible you are compiling it just like you would for mainnet and that thing gets deployed uh on our networks and there are other kind of architectural differences about the approach that us and polygon are taking um I don't think I want to like dive too deeply in there but yeah so curious what are popular UK cases of scroll at the moment um so right now yeah it's been two weeks we are a General application platform um and so really what we've been mostly seeing are the things that we've been encouraging people to make and so at eth Denver two weeks ago we got a lot of projects that were like applied ZK because we had bounties there we had a lot of projects around decentralized social media because we had a bounty for that um but we've also had a handful of game devs using scroll which is really exciting because that's the place where cheap transactions and fast transactions are really helpful um and in general just any anything designed for ethereum already uh is it's a good use case for for scroll and yeah we've we've also gone through some governance processes for projects like uniswap and Ave and so on our test net we'll have those contracts that you can interact with um the unit swap ones are live the away ones are still a little bit away if you want to interact with the pre-existing environments on scroll um is it possible to use scroll with start JS or Iden um I know the answer for snark JS yes um just like you can um yeah basically I think the the setup for that I'm not a ZK developer but my understanding is that so in Cairo you can like compile a solidity contract to verify a proof and so you could compile that proof for Generation using stark.js either in node or in a browser and then emit that on chain using you know metamaster or whatever and if it works in the UVM context it's going to also work in the the scroll context is it possible to deploy scroll evm to a different data availability layer um in theory yes right like we have the ZK evm and that kind of lives as a separate component to the role of architecture that we're doing the data availability and of commitments and proofs too so if you yeah whether to put together a weird project where you took our open source repos and you you know committed to eigenlayer's D.A or Celestia's d a and then verified somewhere else that could be fascinating but it's not necessarily what we're looking at doing for the moment we're really interested in committing to to ethereum like our our we pay gas in ethereum on our Network right like we're very interested in inheriting the security of ethereum and furthering the the goals of ethereum itself and 4844 is going to really help us do that in terms of data availability um this question was missed is the proof block posted directly after the data block on L1 no so um kind of as you can maybe see in this diagram like the the proof for these three you know data availability blocks um can come way later and that's fine right we can keep committing to the newest state of what our off-chain protocol thinks is the latest State um but from the L1 from the bridge perspective and maybe pulling funds out we're only going to trust that once we have a ZK proof that can kind of prove up to a certain uh chain head if that makes sense hopefully that answers your question or re I don't know if I've missed any no that was um that was one that was missed so I just copied and pasted it down there oh everything else um there was just one comment I guess that uh Meyer mentioned that it took 17 minutes for Theirs to get finalized um but yeah and that's another interesting thing I think for the 17 minutes too that's probably how long it will take to um gets bridged from funds from the L1 to the L2 right if you're bridging Worley from L1 to L2 we have to make that transaction and then basically that sits on our on our relayer and it's going to say I'm not going to make this on the L2 until I'm really you know till the L1 is called this transaction safe and that just has to do with epochs and finality on the layer one is that why it takes you know somewhere usually around I think 8 to 16 minutes um for for that bridging to occur so also well cheers I think that's uh all the questions we have um so yeah thanks so much for joining us today and for the great presentation uh Daniel and um if anybody has needs has any follow-up questions I'm just going to post uh Discord link to the scroll Channel feel free to reach out there thank you so much I'm going to add to the last coming question on my way out here and it says what circuits to scroll use uh check out hyshin's talk from the intro but we have a repo that was forked from the ethereum foundation's privacy and scaling Explorations ZK evm repo it's all available on GitHub it's all written in Halo 2 and um yeah if you are a smart contract developer that also yeah wants to be thinking about the the circuit side of things check out those repos and we we love open source contributors so all right last answer there thank you so much Rory and everyone for listening and I hope to see some projects deploy and scroll awesome cheers thank y'all right