# The Future of Layer 2: Research, Development, and Next-Gen Technologies by Ed Felten | Devcon SEA

- Speakers: [Ed Felten](https://streameth.org/speakers/ed-felten)
- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-07
- Duration: 25:39
- Watch: https://streameth.org/watch/yt-6GHjgjD9Va8
- YouTube: https://www.youtube.com/watch?v=6GHjgjD9Va8

## Description

Discussion around L2 blockchain research and development. What are the major challenges for L2s to advance, and what solutions are being explored? What will the L2 space look like next year and beyond? The talk will be illustrated with examples from Arbitrum’s research and development.

Speaker(s): Ed Felten
Skill level: Intermediate
Track: Layer 2
Keywords: Layer 2s, Scalability, arbitrum

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

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.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] good afternoon everybody thanks for your time today uh I want to talk about where we're going with Layer Two now everybody seems to say and I agree that our mission should be to on board the next billion users that is easy to say but not so easy to do many people who have tried to do it have not succeeded but I want to talk about what we need to do as a community to bring the ethereum stack to the next billion users and our approach has to start with this notion of alignment and I I think vitalic answer to the question about alignment is a very good one but ultimately to me what it comes down to is aligning with our users because if we all align with our users then we will be aligned with each other and by meeting the needs of our users be able to actually attract that billion users online so I think we should always be thinking what is it that our users need and want and how can we provide it and if that's our North Star then I think we have the best chance of getting to that billion now I want to talk about six big moves that ethereum either is making or will be making um in order to get to that point six important areas of emphasis um and that'll basically be the framework for this talk Big Move number one is to build in layers this is something ethereum is already doing um and here we we can learn and have learned an important lesson from the most successful protocol in all of human history namely tcpip right so tcpip basically works in layers um and by doing that it achieves a couple of really important things one is it gives a degree of modularity to the design so that it can adapt more easily and each layer can focus on doing one thing and doing it very well but also by building in layers you notice that that stack of layers is not a just a line it's a tree so by building in layers we can have variety and diversity at each layer and that is really important for the strength of the ecosystem both to meet different needs and also to experiment with different approaches um vitalic caught on to this very early unsurprisingly and this is really what the rollup Centric road map is about it's about the idea that the ethereum should be a stack and that stack should be built in layers well how's it going uh it's going pretty well Layer Two and layer three together if you look at what throughput they've been providing and you measure that in units of ethereums what you can see is on a typical day layer two and three together is about 30 times the TPS of L1 about 80x the gas used about 40x the call data and they're roughly 100 layer 2 and layer three chains so to illustrate that let me show you a a uh a simple bar graph here and this is to scale showing the amount of gas used on a typical day on L1 L2 and L3 and many people are surprised that the L1 bar is about 1 and a half% but also that the L3 bar is about as big as the L2 bar um so if you ask what uh has the L2 road map the rollup Centric road map been successful I think it has because it's taken us from this tiny bar at the bottom to now having to change the scale to fit onto the scale everything that's happening so that's been a big success but how do we take this even further well um in order to take it even further uh we can move to the second big move which is to connect everything um and so we get to this topic of L2 and L3 interoperation which is one of the really hot topics of discussion in the Community these days now it's important to connect everything but it's important how we connect everything because there are many different ways at the technical level we can manage and control the interoperation and the choices that we make here are really important uh for uh how and whether we can provide what our users need now in terms of how we can do interoperation again I think we can learn a lot from the internet from how the internet does interoperation again the most successful interoperable protocol in all of human history uh and internet interoperability really I think is built around these five principles one focus on being fast as fast as you reasonably can given the constraints you have second to be standards based those things that you can standardize especially things like naming and data formats uh you should standardize and there's work going on in the ethereum stack and the ethereum community to do that um third interoperation on the Internet is asynchronous meaning that uh when two boxes interact when two components interact they don't stop and wait for each other um because that other component might be slow or indeed it might not uh respond at all notice that uh uh next fault tolerant the idea that in interacting with some component you uh you don't uh you're able to deal with the case where it fails or doesn't respond you design with that in mind and you're constantly thinking about well what happens if the other component is not there how am I going to cope how can I keep serving the user and then finally security conscious to think about is the other maybe the other component that you're interacting with might be compromised what are the consequences of that those last three asynchronous fault tolerant and security conscious um you know it's tempting to try to sweep them away under the rug but in fact I think we can learn something really important from the internet which is even two boxes in a data center that are just centimeters apart managed controlled and programmed by the same parties even those even those boxes interact with each other asynchronously and in a fault tolerant way uh and so I think there's really deep wisdom in designing in that way now when we talk about interoperation there's kind of two different approaches that people take to L2 L3 interrup one of them is uh sort of clusters approach where things are tightly coupled you have the you have the same governance you have the same infrastructure uh and you have um tight constraints on what software you can run and how on all of these boxes to try to get them to be essentially identical in the hopes that you can get Advantage some advantage in speed um by doing that so that certainly is one approach and and there are people who are going in that direction trying to get interoperation by forcing uniformity but think a better model is a model that's more like the internet I mean there are uses for the tightly coupled model that's what's used say in on the internet in within a single data center but if you're talking about interacting more broadly I think thinking about a more Loosely coupled model of interoperation and that's consistent with this idea of asynchronous fault tolerant and security conscious and I think this is where we need to focus on going because ultimately uh this is the approach that will give us a more robust and more practical system Big Move number three developers developers and of course um we have to show this so what does that mean what do developers need what do they want to be as useful as uh to be as useful and productive as possible I would argue that what they want is really uh three main things one is to be able to use familiar standard and battle tested uh uh tools for programming that means programming languages it means tools and debuggers and fuzz testers and all of those sorts of things second they want something that runs fast uh and third they want uh they want an uh environment where different smart contracts are fully composable right that's really the big strength of why we're on a blockchain right is so that you a programmable blockchain is so that you can get these things to work together so uh in the arbitrum uh stack our approach to this is stylus uh and the idea of the multi-m um and that is rather than having just a single virtual machine a single way of deploying programs instead the multi-m approach says we can have a single uh uh execution environment that has evm in it and a and a web assembly VM and we can build that in such a way that they are fully composable um uh in in the way that programmers want this gives you the benefit of being able to run evm code if you want to being able to write smart contracts in rust or C++ run them in a fully composable way on the same chain not separate silos but a single unified composable environment I think this is a big step forward and we're seeing other teams starting to work in this direction as well big new Big Move number four is to make it fast but make it fast for real and that means don't cook up a a sort of a fake Benchmark so that you can have a giant TPS number to quote um really focusing on the factors that uh limit uh performance in real life that is we want to understand what happens when we're running on a real chain uh on real equipment and with a real uh workload of of of lots of different diverse uh contracts and transactions on a chain that has a big state and a long history this is the the world that uh that the chains actually execute in uh so how can we get to the point where we can push performance to the Limit but in a way that's realistic and focusing on the thing that again really matters for users and developers instead of just trying to make a glitzy number that we can never really uh back up okay so I think there are basically five five approaches that are going on and being worked on in the community to get there and I want to start with the first one which is benchmarks this is certainly uh outside of our community the development of benchmarks has been really important finding standardized ways to measure realistic performance both standardized and realistic are important here right standardized because you want to be able to compare in a fair apples to Apple's way across different systems and as well as you experiment with different approaches to design in your single system to be able to have a strong and valid comparison and realistic performance also is important so that you're you're testing in an environment that is as close to realism as possible so that the numbers you get actually are a good predictor of of how fast something will go second faster execution people work are working on developing faster VMS working on things like more efficient database representations uh to get better performance out of the same Hardware third is the use of parallelism and this in particular I think means finding parallelism that exists naturally already in the workload don't make the don't make developers worry about parallelism instead just discover well we can run this transaction and that transaction at the same time because they're non-interfering discover that take advantage of it and make sure that your gas pricing and gas limit uh system is appropriately dealing with that so that you can have Fearless parallelism for developers fourth resource pricing now we know that today um as soon as one resource on a node hits a bottleneck you slow down and raise the price of all of the resources that are needed to execute that chain we can do better than that by having more accurate more nuanced gas pricing we can make sure that we make better use of the uh of the capacity of of of the ordinary nodes that we want to run our chain on uh while at the same time remaining safe I think there's really significant improvements in throughput available just by being smarter about how we track and price resources on the same hardware and then finally sharding in the cases where you need it to get horizontal scaling with less friction um by simply taking uh by taking a chain and dividing it into a series into a set of very closely coupled uh subchains now that's not for everyone because there is not zero friction in interacting across those shards but in cases where it's needed uh this I think will be also a valuable tool so a lot of things going on to try to make it fast Big Move number five is technical decentralization um and all of the major L2 L3 Stacks have gone some distance down this road to decentralization um but we need to keep doing this to make sure that at a technical level our systems are decentralized uh so what does decentralization mean well it means that actual power is dispersed so to give you a couple examples from uh from the arbitrum stack uh one of them that is uh that is upcoming soon uh for the Dows consideration is bold which is a new uh dispute resolution protocol which is the first and only fully secure fraud-proof system that has these characteristics it's resilient against up to seven days of censorship on uh on the ethereum Chain it has a fixed completion time no matter how many adversarial Stakes are there um bold will be able to resolve uh any disagreement uh with a fixed limited uh completion time it allows honest parties to pull their Stakes so if you're a participant and you don't have enough funds for to stake you can find a whole bunch of other people and they can trustless combine their Stakes into a single pooled stake um and once you come up with one stake from across all of the honest parties in this shared way you're good to go and you can guarantee the safety of um of the chain and it doesn't rely on a security Council veto mechanism as part of its core security model that is if the security Council if the arbitrum security Council goes away and does nothing the system is still secure the only purpose of the Security Council is to deal with the critical vulnerability and the guarantee after this is in place is that any one user with their ordinary laptop can enforce safety and progress of the chain that's possible of course only possible because we have L1 underneath us providing that uh that core of security but this is a really powerful security guarantee I want to talk as well about sequencing because decentralizing the sequencing function is will be for the arbitrum stack at least the very last step in technical decentralization there's a lot to like about the current first come first served U model of sequencing uh has all these nice properties I've listed here but there are two properties at the bottom that it doesn't currently have one is that it doesn't currently internalize me value for the chain and two is that it's not currently decentralized it relies on a centralized sequencer which to be clear is not trusted for the safety or liveness of the chain it's only trusted to report which transactions have arrived and in what order but we'd like that to be decentralized so uh in terms of capturing Revenue there are a bunch of different approaches some uh some systems are experimenting with priority gas auction uh in in the arbitrum stack the one we like is time boost um which basically involves creating an express lane at the first come first serve sequencer um and giving a Time advantage to a party who wins an excl exclusive license by winning an auction uh uh giving them an exclusive time advantage over a one minute period the idea here is to capture me revenue for the chain um in this auction while doing as little while maintaining the very fast block times and uh and protection against front running and other good properties of this uh of this system and critically um this uh this can be done in a decentralized way so this this gives you uh internalized me value for the chain um you can also decentralize the sequencer um and that's an important thing to do uh there's an ongoing research project uh in the arbitrum stack between offchain labs and espresso systems uh to move to a committee-based sequencing scheme so that you have a committee of sequencers and provided that some suitable majority of them are honest the behavior will be just like an honest centralized sequencer so you get the uh the nice properties of honest centralized sequencing but without having to trust any particular party okay so that gets you to the decentralized stage and at least for arbitrum once we have once bold has been uh has been deployed assuming the da approves it and once this sequenc or decentralization step is done then the technical decentralization road map is finished other Stacks as well are working on trying to get to the end of their decentralization road maps but I want to talk finally about Big Move number six which is decentralized control um and here I think we can again look to the to the story of the internet and I want to start with this famous essay written by John Perry Barlo in 1996 called the Declaration of Independence of cyberspace which explained that cyberspace was this new area and government could have no influence there big companies could have no influence there this was the birth of freedom for all of humanity forever basically well so that was 1996 last week we had Corey docto who is in some ways a kind of intellectual descendant of Bar's thinking uh wrote this um after about 10 seconds of sheer Joy what we got was all new Gatekeepers who were at least as bad and even more powerful than the old ones and the net became basically five giant websites each filled with screenshots of the other four right so if we look at what has happened in sort of the web 2 space this original idea that it would fully decentralized and not uh and not subject to the control of powerful entities that didn't turn out so what happened I think what happened was that the community uh is that that Community lost sight of what decentralization really means decentralization is more than just a right on paper to participate what it means is that power is truly dispersed to the community the question is not who has a on paper right to participate the question is who holds the power so when we talk about decentralizing governance of l2s and l3s um I want to sort of draw a distinction between a phrase which I promise was already on my slide before uh a very interesting talk with the same title happened uh yesterday of the day before decentralization theater decentralization theater is where you go through the motions and say the words but you don't do it there's pretty words about Community but your system's really really custodial Dow votes are just advisory a multisig action is part of the plan and not just an emergency backup and you have a theoretical right to participate but you lack real power true decentralization means you have an active Independent Community the Dow holds the master keys when the Dow votes it's not just a polite request to some multisig controlled by insiders to do something the Dows votes Direct cause action onchain the security Council if there is one is chosen by the Dow and anyone can run a notor validator and Stakes can be pulled I think that's true decentralization of power so with those six moves I think we can align ourselves with users and get to that next billion users the future of L2 I think is the future of ethereum and vice versa um we are we are a unified ethereum stack we're not pushing and pulling against each other or shouldn't be and finally the principle I'd like you all to remember is to that we should all be trying to maintain in the L2 and L3 space is that if it's your chain it should be your rules thanks and we have some time I think for questions absolutely let's give our speaker nice big round of applause can I just say as a former lecturer myself I recognize when there's another educator on stage clear slides great presentation straight to the point let's go right to our questions ladies and gentlemen first one on the screen when will arbitrum become a ZK rollup uh the answer to that is when the cost and practicality of ZK proving at the scale that arbitrum needs is uh is there um my view on ZK versus optimistic is that uh if we switched arbitrum to be a ZK rollup tomorrow our users wouldn't really notice optimistic versus ZK has very little effect on user experience y ZK rollup has some technical advantages um uh our team has been working really aggressively at looking at ZK proving Technologies and working with teams but in my view it's not really time to do that yet uh that time will come uh I gave a talk at the bass conference at um uh at Colombia a couple months ago it's available online about an approach to doing this I think actually the endgame is a combination of optimistic and ZK proving where you can get the best of both worlds all right thank you very much for the answer fantastic why WM and not r i c v why wasm and not risk five it's there's a bunch of reasons one is that fundamentally it's because wasum is designed for this type of application wasm is a very wasm is designed for it it's type safe by Nature you can safety check wasm code statically at load time and then you get very strong safety properties when you do that that's number one number two is that wasum was designed not only with a uh not only as uh instruction set but wasm was designed with fast execution in mind um and there's been a tremendous amount of effort to make fast execution engines for wasum because that's built into browsers it's built into consumer software um and so it's a much more mature the execution of wasum efficiently is much more mature and the tool for making sure that you do it uh efficiently are much more mature Fant and so we settled on WM early and and I still think it's the right choice yep excellent answer moving on we got a time for maybe two more two three more what do you think about synchronous composability between different l2s so um I think you can aim for synchronous composability but I actually think that here this is a place where we can learn a lesson from the internet uh remember what I talked about before how those two blade servers that are a centimeter from each other in the same data center still interact asynchronously because it's a more robust way to to interact I think the notion that one chain should stop and wait for another is something that we should question um that um you could do synchronous composability I think there's a real cost in in throughput um of having one chain stop and wait for for another if you just rename synchronous as stop and weight composability um I think it becomes clearer why you might not want it fantastic people love that answer as well and let's go to the next question at the top how can we avoid different L2 ecosystems such as arbitrum optimism Etc becoming silos of data and value great question yeah uh it is a great question it's a super important question and one that a lot of folks are working on uh and the answer is basically that story about L2 interrup what we need is a set of Open Standards and open mechanisms for interoperation right rather than focusing on how can I do great interop within my silo or within my tech stack we need to figure out how we can have an ethereum wide interoperation framework not just data format standards but also standards for mechanisms and what it what guarantees that these uh systems provide to each other uh that's not easy to do but I think we can do it it's a really active topic for our research team um and really eager to work with teams across the sector on on making this available for everyone all right we got well 20 seconds let's see if we can finish one question for the final how can you claim bold is decentralized if Bond size is 3,600 E I have a my answer is partly spicy and partly not my spicy answer is that you could make it smaller but you would be sacrificing security um and so I think that's necessary but I think most importantly the fact that you can pull Stakes is critical here it's not 3600 from one party it's 3600 to in total from all of the honest party uh all of the honest parties trustless stake pooling is key to making this work you could make the Stak smaller