Scaling Ethereum with Rollups – John Adler

hello everyone hopefully I'm in the right place I'm not someone stop me now so today I'm going to be talking about scaling aetherium with roll ups so my name is John Adler I am with fuel labs and we're building an often integral of implementation so first let's talk about the scalability problem we all know that no Bitcoin can process around three transactions per second maybe up to seven depending on how how big their aetherium can process around 15 transactions per second maybe if you're doing just simple payments I can get up to 30 and meanwhile visa can process you know five to ten thousand transactions per second this is you know generally the scalability problem we want to increase transactions per second so the scalability and we want to do this without decreasing decentralization so there's a few potential solution that have kind of been proposed over the past ten years for channels and you know more recently for plasma now channels aren't really great for scaling the capital efficient they don't support open or participation contracts like uni swap and generally they have a poor UX in terms of capital because you have to lock up your money and it can't be used elsewhere so channels aren't really scaling solution they're an interactivity solution they allow instant finality which is great block chains can provide that but they're not really scaling solution plasma is a little bit better but plasma cash is kind of the only plasma variant that provides us with a good security guarantees and plasma cash also doesn't support open participation with smart contracts and it requires things are checkpoints to proven coin history which makes it you know actually use a non-trivial amount of block space and big problems plasma as that is permissioned so ideally we want something that allows open participation is permissionless and distrust less and capital efficient and we're willing to sacrifice the instant finality the channels provides we're okay with having at blocked or potentially a slower agency for transactions or okay without sacrifice but you know we don't want to sacrifice on anything else we want everything else so before we figure we before we see the you know the solution that we're going to talk about which is obviously roll-ups because the subject of this talk let's see what is the scalability bottleneck and how does roll-up tackle this bottleneck so one common talking point is that yes is centralized and it is more sure it's it's more scalable than etherium because it's centralized around 21 bloc producing notes it's kind of a common talking point but and if you take away one thing from this talk it should be this that this is wrong if we look at you know the the charts of block producers on EOS versus etherium and Bitcoin you'll see that a theorem for mining pools control the majority of hash right Bitcoin for mining pools control the majority of hash right so there's fewer nodes so why is it that the EOS is more scalable than a theorem in Bitcoin and the answer is that the number of nodes actually has nothing to do with scalability and that's because consensus is not the bottleneck so what is the actual bottleneck is this on aetherium we want a non consensus full mode with the following specs approximately four core CPU API bytes of RAM and an nvme SSD to be able to fully validate the chain at a rate as ten times faster than it grows then blocks are produced with Bitcoin the parameters are different we want a non-consensus node with a Raspberry Pi and hard disks drive must be able to fully validate the chain approximately 30 or 50 times faster than it grows and yes is different they choose a different parameter they want non-consensus nodes to run a 64 core CPU have one terabyte of RAM rated nvme SSDs and that kind of computer should be able to fully validator chain approximately as fast as it grows and this is a social contract it is not consensus this is not and note at no point here did I say anything about number of nodes about the consensus process and that's because number of nodes has nothing to do with scalability it is all about what are the hardware and network requirements we have for user to run a full node to do full validation so how does aetherium scale and bottleneck manifesto so how do we get from that hardware specs to fifteen transaction per second we have to get there somehow your why is it that a theorem can we do fifteen despite the fact that you know there has much higher node hardware requirements than Bitcoin and Bitcoin can do maybe half of that the two reasons the first one is that theorem can support more complex transactions I can do you know these stateful state richly stateful cheering complete smart contracts that we all know and love etherium for as opposed to bitcoins you know stateless predicates and the second reason is because of state accesses and state growth generally accessing state during aetherium transactions is a very expensive process and the theorem state size uncompressed is around forty five gigabytes compared to bitcoins to gigabytes and this is actually why an nvme SSD is needed because the theorem state is too large to fit into round on most consumer hardware so roll ups to the rescue so what's the roll-up design paradigm it's basically you do do you take all the state you move it off chain we do execution on this state also off chain and you only use the etherium main chain for data availability so you just post the roll-up chains blocks as call data make the data available and that way you don't have to worry about the data withholding attack that is a big problem for regular side chains this allows us to build trust to minimize permissionless scalable side chains for the first time ever in the history of blockchain and you can't do this on bitcoin and you can ensure the validity of these of the side chains blocks with several different different things one is the validity proofs or zero knowledge proof and this scheme is known 0gk roll-ups another thing you can do is you just have a fraud proof and then a synchrony assumption so someone commits to block if no fraud proof has been submitted within a long period of time say a few days or a week then you just say it's valid the last thing you can do is an interactive verification game plus the synchrony assumption and this is what the guys at off chain Labs are doing I don't think this one here is a good name yet as a general name but you know it's an alternative to too optimistic robots so Y can roll up scale so with the roll-ups consensus nodes and miners miners and non-consent snows so the users don't need to execute the role of transactions they only need to order data and make it available so you know imagine taking a movie and just downloading it or you know you have a Linux ISO and you just download it and put on your disk you can do that very very quickly and you know this doesn't require a lot of resources so by separating data availability and ordering from execution now you have a system that can potentially scale and this is kind of almost the best thing you can do because there's no lower execution - no execution how do we do all the execution of chain on chain there's no execution you can't really do better than us so the last night is it can with a star so I can so let's kind of look at the profile of verification cost versus bilac production costs so in normal block chains and an optimistic roll-ups this cost is symmetric so in order to run a full node as a non consensus node versus a consensus node it's basically the same cost they're both doing the same thing and since the symmetric it's easy to analyze with zk roll up things get a little more complicated and with chains that embed ZK proofs directly at the consensus layer for instance quota because sure the verification cost is very cheap so as a non consensus no we didn't keep up the block production cost is much more expensive so this means the potentially block production is more centralized so this becomes you know much more complex to analyze so ignore it for now and you can extend what we talked about earlier about unconcerned knows to also talk about consensus nodes but for now let's Matt let's analyze the symmetric case of optimistic roll-ups and what I'm gonna say now might surprise you but if everyone had a single EVM after mr. grow up and all the blocks based on a theorem was just filled with data availability for this roll-up we would not have a few hundred transactions per second like you've been told we would have 15 transactions per second we'd have zero scalability gains and that's because the end users would still have to fully validate this roll-up channel and if you had a VM in the row of chain well guess what unless you increase the hardware network requirements of the users you're they're still only going to be able to be able to execute on the same hardware 15 transactions per second right so row ops does not scale because there are fewer users using this particular roll-up chain right the number of users has nothing to do with scalability it's all about the hardware network requirements so if I've often mr. grow up doesn't matter give us any scalability whatsoever if we use it on the EVM what does it allow us to scale and the intuition here is that sharding in general like what's being used in e2 it provides us with increased transactions per second because it allows us to do many execution threads in parallel there's nothing to do with the number of users is all about many execution threads in parallel and guess what after mr. groves allows us to do it allows us to do dynamic heterogeneous sharda so you can have a single data availability layer the etherium chain and then you can have several roll-up chains that all execute essentially in parallel independently this means that you can do the knot you can get the nice benefits the charting will get you and you get this on a theory m1 and heterogeneous because each chart is different unlike in the two design where all chars need to be exactly the same here are shards can be different and one okay and one nice thing that it allows you to do is it allows you to experiment and explore with different execution data models without any hard work on the main chain for instance a few labs we're doing one with aut XO data model you can also have somewhere custom VM that's well-suited for interactive verification games which often lab is doing you can use mu libros movie m if you want you can you can do state rent and you can have application specific execution so one thing I want to drive home so this is the hackathon is that your application specific optimistic robots can and should be a thing and it's something that you should think about designing you know doing an EVM again as said before it doesn't provide any scalability build application specific optimistic rollouts they work they can scale they're simpler they're easier to meet her around and they're not really that hard so beyond optimistic roll ups and charting can we get better than this yes we can we can actually do we can actually get sub linear cost on data availability by doing by using data availability tracks and the kind of design paradigm around this is being implemented laser letter which you can check out if you're interested so the TLDR number of knowns known affect scalability consensus doesn't affect scalability it's all about the hardware requirements for user to fully validate and because of this the EVM doesn't really provide scalability instead why don't you just explore with different execution and data models and you know don't wait for someone else to build a scalable office to grow up train for you you can reach out to me you can reach out to anyone else and optimistic roller community and you can build application specific roll ups that scale very well okay that's it thank you everyone [Music] you [Music]