What do we need to do to take Etherium to the next Cerium users Ed Felton

so i'm ed i'm a co-founder at arbitram and my own history on this problem of how to scale ethereum goes back to this highly futuristic location uh princeton university um i taught at princeton for about 25 years and that's where arbitram our product was born and around 2014 being being an academic and musing about things i started musing about this concept of smart contracts and it was it seemed clear that smart contracts were an amazing thing that they opened up all kinds of new applications and opportunities and that um and that we had to figure out how to do them and how to do them at scale but it also became clear pretty soon that scaling smart contracts were going to be is going to be a big problem why because if you think about the natural way of building a smart contract system you end up with something kind of like ethereum where you have a virtual machine you're emulating it you're running it on individual nodes and that just doesn't have the horsepower that you need to serve a zillion users so great technology scaling is an issue and it was out of that conversation that we had that arbitrarium was born now the first implementation of arbitrary actually goes back to this the fall of 2014 this is a bunch of these are three students three undergraduates then at princeton they actually built a proto version of arbitram way back then before ethereum existed we already had a baby version of an l2 that that would be able to scale ethereum or whatever smart contract system came along and was awesome so this was the start this is where the idea was born the idea of trying to scale smart contracts now of course right a lot of people are doing it that's my personal story of how i got into this all right so ethereum came along ethereum was awesome people liked it in the early period of scaling at first it didn't really matter right there wasn't enough traffic there weren't enough users there weren't enough contracts um to actually reach the gas limit in the early days right machines got faster the gas limit went up everyone was happy fees were low but then of course it happened right ethereum got popular started to hit the gas limit and fees went up so this is a graph of the gas used by ethereum over time and you can see it goes up a lot over time and you can also see these sort of plateaus these flat plateaus in the in the graph say over up over here over here what that is is ethereum hitting the gas limit right this is the point where you're consistently using up all or most of the gas limit and as a result people have to bid against other people in order to get access to the gas and and and that is the limit on scalability actually starting to bite right so that happened it hit the gas limit fees went up and this is when the demand for scaling really started to be heard right now it's kind of inevitable that this would happen as soon as ethereum got popular and it did happen okay so there's a bunch of things that people have done and are doing to try to drive scalability up one of them is rollups i mean if you're not familiar with rollups the basic concept is not too difficult the idea is we're going to move the computation and contract storage off chain so that we don't have to burden the nodes or or minors of ethereum with all of that we're going to record the call data of contracts on chain we'll batch it we'll compress it so we can store it as efficiently as possible as on chain call data but by moving a lot of the load off chain and by compressing the rest of it we can reduce the footprint on the ethereum chain of of contract activities that are going on so but of course the problem that you need to solve then is how can we make sure that all of this off chain activity is done correctly and so uh various roll-ups then settle transactions correctly back to l1 and the design of a roll-up is fundamentally driven around well how does your fraud proof or correctness proof work that is how is it that you guarantee that the off-chain stuff that gets done is settled properly there's different approaches optimistic roll up zk roll ups if you're interested in that debate there's a panel at 6 30 over on the main stage come and watch um the the various um uh projects go at it right but that's the basic idea of roll ups move stuff off chain right so roll-ups have been pretty successful i i have to brag about our own arbitrum we launched about six months ago we have now over 300 projects launched on the system over 400 000 unique addresses have used it and about 4 billion dollars of value is on chain we have integrations lots of integrations with major exchanges tools infrastructure providers and so on so we're not unique in having some of these in having some of these things we are i think doing extremely well but it's a sign of what rollups can do and of course the most important part of all of this is the large and enthusiastic community that has developed around our technology and to some extent around around other roll-up technologies now back in october of 2020 vitalik wrote this post on ethereum magicians which i think was a real turning point in how he and others have thought about the development of ethereum it's called a roll-up centric ethereum roadmap and it really represents a change in a kind of vision of how ethereum can grow and scale in the future and one that if you look at the um the ethereum ecosystem is likely to be all in on roll-ups plus some plasma in channels as a scaling strategy for the near and mid-term future so this reflected a vision of how ethereum should evolve in which the role of ethereum layer 1 would primarily be to provide a settlement layer a security a security foundation and an interchain interoperability mechanism four roll-ups that would sit on top of it but most of the heavy lifting of getting contract execution done would be done by roll ups and and that's what you see starting to emerge now okay so with that context let me talk about what are the problems that we as a community need to address and solve in order to scale to the next zillion users that could be the next 100 million the next billion the next six billion depending on on your own your own tastes and how ambitious you're feeling what do we need to do to take this far beyond the ethereum community of today and really there are a bunch of dimensions along which you can try to scale and grow the capacity and to grow as much as we need to grow you need to push all of these dimensions at the same time because it's really the product of these different uh sort of growth factors that you need to get in order to get there so you need and i'll go into each of these a little bit more you need faster nodes you need more call data capacity you need more parallelism and you need some way of managing the problem of storage bloat which is the dragon that will rise up and and burn you if you don't uh if you just ignore it all right so faster nodes there's different approaches to this let me sketch briefly our approach in arbitram which is what we call arbitrary nitro our next uh coming upgrade basically it's a way of taking the architecture that we've had before substituting out this sort of custom vm emulation code and replacing it with the core of geth so it's sort of a beautiful marriage between our existing technology and geth to get the best of both this then these things then get compiled together as a single code base to form the l2 nodes that gives you the performance that geth offers and the ability to to follow the upgrades of geth as geth gets faster and as guest follows uh ethereum hard forks you then can compile that into web assembly using standard tools and then we can do our fraud proof technology over that web assembly so this is a um and so what this and that sits on top of l1 ethereum so what that gives you is the ability to run native code geth as the core engine of the rollup that eliminates a layer of emulation and it means a really significant speed up so we're doing this in our nitro upgrade uh test net date to be announced very soon optimism is doing something pretty similar um it as they move toward an architecture that's closer to what we've been using all right so that's faster nodes we need to continue to push the core evm emulation engine is one of the components that needs to get faster people are working on this and in our team and i know other teams stand ready to adopt faster evm engines as they become available and sufficiently compatible with what geth does all right we also need more call data capacity right roll ups store the call their call data in a compressed and batched form but they store it in l1 call data and the reason they do that is to make sure that everyone has the information they need to follow along with the state of the chain and to be a full-fledged first-class participant in the correctness protocol of the roll-up chain right but call date is limited and that's one of the things that can limit the ability to scale out roll-ups to uh to higher capacity and so there's a bunch of proposals to improve this vitalik put forth a uh what he what he characterized as a pre-eip um just in the last couple weeks um the the blobs proposal is what um we call it internally basically the idea is that you can you could attach to a transaction a set of data blobs those blobs are not call data meaning that they're not available to the execution engine they're not available to contracts contracts only get a sort of digest like a hash but really a fancy vector commitment thingy they get that sort of digest or commitment to the contents of the blob right so that is cheaper for nodes to support therefore there can be more of it at a lower cost but it's sufficient for roll-ups to do the job that they need to do because we need on-chain l1 contracts that run our chain to know a commitment to or hash of all that data but we just need off chain nodes off chain l2 nodes to be able to see the blob data so this is designed to really service to really meet the needs of rollups enroll protocols can use this right away this thing is designed to transition very smoothly into what will come along later which is eth2 data sharding e2 data sharding when it arrives is going to is going to offer a lot more ability to put data on chain it's a thing that e2 will really excel at and that's going to make a huge difference in driving up the capacity of of roll-up type tech so we're really eager to have this come as i know the other roll-up teams are too all right let me talk briefly about storage blow storage bloat is the thing that nobody in the scalability world wants to talk about but i'm going to talk about it for a minute and the core problem of storage bloat is just this that evm storage is forever when a contract allocates some storage it writes some bits to a storage location the ethereum model says that storage has to be available in that contract storage space forever and that means that as contracts run as they allocate storage that the the state of your chain this total amount of storage in your chain grows and grows and grows and nodes that are working on your chain need to need to store all that stuff in a database and eventually get some of it into ram and so this database just bloats and the more you scale out the more transactions you run the faster your storage will blow right it's a real issue on ethereum it's caused repricing of some instructions and it's a thing that that the gigabrains working on ethereum protocol have wrestled with over time every roll-up either is wrestling with this or will soon figure out to their horror in the future that they need to right so eventually if you don't do anything about storage bloat then nodes just can't store all this stuff anymore and your chain grinds to a halt there's also an insidious effect of storage bloat which is that an action that someone's taking in the present and paying fees for in the present is imposing a cost on all nodes in the future and so if you and so you need to think carefully about the economics of fees around this but that's a whole other uh that's a whole other discussion all right so what can we do about storage blow well ethereum is moving toward adopting storage exploration probably coming to ethereum not too far in the future so that storage that is very old and hasn't been touched for a very long time can be forgotten by nodes nodes will only remember a sort of hash or digest of it so that users can recover it but the burden on ordinary nodes won't just grow infinitely having more efficient representations of storage finding ways of storing the same information while using fewer bytes in a storage device also pretty important that can buy you a constant factor that's nice probably necessary and then of course the final thing that you need is sustainable pricing that means that the fees that people need to pay to run transactions on l2 that allocate storage need to be large enough that people actually stop and think about how much storage that you use like anything else the basic philosophy of fees and gas in in ethereum and similar chains is if you're an end user if you're a transaction you got to pay for you have to pay for the cost that you impose on the system right and so storage fees need to be enough to be sustainable so that people are paying for the cost that they're imposing on future nodes and future validators all right so we need to address the storage blood stuff we need to do all of these things going forward the next piece we need to deal with is more parallelism right how can we do more things at the same time right because the first thing to know about improving performance is if you want to improve performance you can either do the same things faster or you can do more things at the same time those are the only two approaches right so how can you do more things at the same time one thing you can do is have a chain that runs transactions in parallel now that's a little bit tricky because the fundamental model of ethereum is the transactions run one at a time if two transactions don't interfere if they don't touch the same storage in a way that um in a way that makes the order of their execution matter then you can run them at the same time and there's various tricky methods to be able to get some degree of parallelism when transactions are truly independent of each other right and so that's going to have to happen that's a nice constant factor but not much more right to get beyond that if you want more parallelism where you go where you have to go is some form of sharding uh having multiple chains multiple roll-up chains whether it's using the same technology or not there's lots of different ways that people are thinking about this thinking about it as multiple separate chains with with some form of bridging thinking about it as a single technology that's fundamentally sharded or thinking about things like l3s where people can run kind of side chains on top of an l2 all of that conversation is going on there's a really rich design space lots of teams thinking about this as we are but there's some really key challenges as you do that as you think about that the first one is how is bridging and composability supposed to work right you have different chains they might have different technologies they might be optimized in different ways from a user standpoint you want smooth bridging and smooth composability separate roll-ups and roll-ups and l1 necessarily run it asynchronously from each other that one of them can't really stop and wait for another one and so that means you have a form of composability that's fundamentally different from what you have on l1 and so we need to figure out how to think about how to build tooling about how to how to write applications that use this kind of asynchronous composability while we're also figuring out how to actually move the bits and bytes and how to do the proper authentication between chains so that all of this can run in a way that's secure and that brings me to the final piece and the one that i think is the most challenging and that is the question of trust models if you have an application or an ecosystem that is scattered across multiple chains if one of those chains has a centralized element then everyone across all of that whole ecosystem has to pay the security risk take the security risk from that centralized element so even if your chain over here is perfectly decentralized if you are interacting in a in a way that trusts anything that's happening on some chain with the centralized element then congratulations you have a centralized element or if some other chain has a committee and they assume that five out of seven of that committee is honest you're interoperating with that congratulations you have the same assumption so how to figure out how to manage these trust assumptions so that people don't inadvertently uh so that people aren't inadvertently taking risks that they don't know about that's one of the core challenges just how to think about and model this and then the practicalities of how to disclose to users and how developers can think about it some really deep and interesting problems there okay but i think ultimately all this comes together as we start to move into the inter-chain and multi-chain future together which to me looks a lot like yosemite awesome sometimes overcrowded um but but really a place that you would like to be and a place that actually unlike yosemite can handle almost an unlimited number of zillions of people so the big challenge i think many of the things i've talked about are problems we can work through is technology the one that i think is deepest and most interesting the one that has i think the most scope for innovation is what is the inner chain and multi-chain future look like how do we build it how can we build a system that lets users not have to worry about this stuff lets protocol developers worry about it in a structured way and allows developers to just do their thing okay um this ends this ends the rant let me just end with the obligatory slide saying we at arbitram are hiring we're hiring all roles tech and non-tech come and join us um in my um totally unbiased opinion we are the strong the best team in crypto if you're interested jobs at offchainlabs.com now we've left some time for challenges conversation discussion so please um uh i'd like to hear what you think and debate me debate each other and i'll be coming to you with the mic questions applause first yes do it it's always a good thing who has a question they'd like me to come over i just need the exercise perfect hey uh one i love arbitrary i use it all the time there's some really cool projects on there notably treasure dao but anyways my question for you is at this conference i've talked to a lot of people it seems like the general consensus is that optimistic roll-ups are a temporary solution until zk roll-ups are like figured out uh what's your take on that okay cue the zk ranch um now this is a little preview of what you're going to hear from me on the panel probably at 6 30 over in the main stage so here's what i think is the case about this it's a that the that optimistic systems have a large and fundamental cost advantage over zk and the reason is if you just think about what is required for what is required to deal with a contract that doesn't add instruction just to add two numbers in an optimistic system what you have to do is add two numbers in a zk system you have to add two numbers and then do 500 to a thousand expensive crypto ops to prove it right that is a huge constant factor difference in how much work you can get done per unit time and how how much compute power you need to have to handle the same number of transactions if you want to talk about how much you can scale i would much rather be in a position of just needing to do the ad then i needed to do the ad and um the needing to do the ad and like a thousand um big a big number ops right so that's a fundamental difference that is permanent right so zk people might be able to shave that thousand down to 500 or even 200 but still it's a big it's a big it's a big difference right there's a permanent cost advantage for optimistic i think that's not going away now we're currently in what i think is a temporary regime where call data is very expensive relative to other resources right and when the zk people talk about cost they're really talking about call data footprint now i think their accounting sometimes is a little bit dodgy there's a little bit of hollywood accounting they do when they sort of count how much storage they use versus wii use but nonetheless they do have some advantage which in call data but over time the cost of call data is going to be driven down once eth2 sharding comes once more sophisticated data availability solutions become available call data will not be the main source of cost the main course the main limit to scalability is how much work can you get done uh with a certain number of cpus in a certain amount of time and that's where that constant factor cost advantage comes in finally the last piece of the rant is this that you know this is a race if this is a race the optimistic folks are ahead right it's a marathon we're 10 minutes ahead uh right and they say in 10 minutes we're going to be there where you guys are now right but 10 minutes from now we're going to be further down the road right so when they get to that future where they're able to do what we've been doing for six months we're gonna you know we will have improved as well so it's they need to do more than just improve rapidly they need to improve much more rapidly than we do in order to catch up i also don't think that's going to happen now that said if the day comes when we believe that z case zeke that end to end zk emulation of evm is the way to go we'll switch we'll bring our you know we'll bring treasure down we'll bring our community with us thanks probably a longer answer than was indicated but um thank you one more question here in the front well don't trip fantastic thought thank you fantastic talk thank you so much i learned a lot i am interested if roll-ups are not inherently an ethereum solution i'm interested in uh why you're settling to ethereum and if you're planning on uh maybe settling to other chains in the future too yeah yeah we settled to ethereum because we believe in the ethereum technology and the ethereum community fundamentally right we're going where the community is and you know we think we think ethereum will be the interface of the future and we think ethereum will be the will be the settlement layer that is going to be used at large scale in the future right so is ethereum a perfect technology is it the way if italic could go back and like redesign you know and everyone could go back and redesign it now would they do it the same exactly the same no right but i think of ipv4 i think of x86 i think of all the technologies that came in early developed a huge developer community and became the standard of compatibility and the standard of interoperation um and then engineers came along and um you know and built products that made it work and i think that's what is happening with ethereum i think it's what's going to happen and that's why we're on ethereum fundamentally we believe this is the future that the community is more important than a temporary limited technical advantage that somebody else might claim