Fuel: Scaling Ethereum with Optimistic Rollups

Transcript

[Music] hello everyone my name is john adler and i'm here to talk about fuel and scaling ethereum with optimistic roll-ups so let's start with a brief introduction about myself i'm currently with fuel labs where we're building fuel a high-performance optimistic roll-up chain previously i was working at consensus as a layer 2 scalability researcher and i created the optimistic roll-up design paradigm from that research so let's talk a bit about the scaling problem first of all since obviously you know optimistic roll-ups are supposed to scale blockchains

bitcoin can do between three and seven transactions per second ethereum can do somewhere around 15 or if we're just considering simple payments it's more like 30 and meanwhile visa can handle 10 000 plus transactions per second at peak capacity and we would like to increase this number we'd like to increase transactions per second or throughput without decreasing decentralization or requiring new trust assumptions obviously it's pretty simple if we just you know trust visa to process all our payments correctly then we don't need a blockchain so we'd like to you know not insert new trust assumptions and i said throughput before which is not exactly scalability so scalability is throughput divided by

decentralization it's the ratio and what exactly do we mean by decentralization let's get let's let's find out so first let's see what is the scaling bottleneck uh one common talking point is that for example uh eos is more scalable than ethereum because it's centralized around 21 block producing nodes and you might see graphs like you see over here you know if the os has 21 block producer blocks producing nodes with approximately even distribution of some some simple resistance control mechanism and meanwhile ethereum and bitcoin have you know six mining pools five mining pools that control the majority of the hash rate which

seems odd because if if the number of nodes had anything to do with the transaction throughput then you would expect a theorem in bitcoin to support more transactions per second than eos's so it's wrong that the number of nodes has anything to do with throughput why because consensus is not the bottleneck so let's see what decentralization is on ethereum we want a non-consensus full node with approximately these hardware specs a four core cpu eight gigabytes of ram and an nvme ssd that should be able to fully validate the chain at a rate approximately 30 times as fast as it grows in other words it's able to catch up when it's doing an

initial block download on bitcoin our specs are we want a non-consensus full node to run on a raspberry pi and a hard disk drive and that must be able to validate the chain at a rate approximately 100 times as fast as it grows and in eos we want a non-consensus phone load with some absurdly high specs that are right here let's say 64 core cpu only one terabyte of ram and so on and it must fully validate the chain approximately one times as fast as it grows so you can't really catch up after if you drop off so in other words decentralization is measured by the cost to run a full node it is not the number of full nodes or the number of

nodes in general that let alone full or not and this is a social contract you know every blockchain has a social contract of how much it should cost to run a full node and it has nothing to do with consensus so let's see how ethereum scaling bottleneck compares to bitcoin how does that manifest uh why can despite the fact that you know that presumably you can say the decentralization of ethereum is less because the cost of a full node is much more than bitcoins why is it that ethereum can only do twice the tps you can do 15 to bitcoin seven and the answer is that is because of evm execution uh you can do much more complex smart contracts on ethereum than you can do in bitcoin

uh and the second thing is then this is the the big one is state accesses and state growth so the ethereum's uncompressed state size is approximately 60 gigabytes nowadays this can't fit in ram therefore you have to put it on an ssd ideally an nvme ssd which means you're going to have very large very long access times uh bitcoin state the utxo set is approximately three gigabytes give or take uh so this is kind of where the biggest the biggest problem comes in this is why ethereum can't do that many more transactions per second despite having much higher hardware requirements to run a full node so how can rollups help solve this particular bottleneck how does it how does it

target this particular bottleneck the roll-up design paradigm is essentially you do state access as an execution off chain and you only use the base ethereum chain for data availability and ordering and then you ensure that the validity of this data that you're just posting on chain you can ensure that it's valid using one of three methods one is a validity or zero knowledge proof so the zk roll ups the other one is fraud proofs plus a timeout and this is optimistic roll-ups and the third is an interactive verification game plus a timeout and this is what teams like arbitrarily doing so why can roll-ups scale and there's a star here which we'll discuss shortly so with the roll ups the consensus nodes

like miners and so on and also non-consensus nodes so users only need to make data available and order it they don't have to execute transactions and this is great because you can't have less execution than no execution just ordering transactions is basically the optimal amount of work you can do which is not there's nothing right you're not executing anything you're just ordering the transactions uh so now where does the can come in from where the cam come in you might have seen interesting interesting numbers like this you know you have a 10 million uh gas gas limit per block you know each transaction in the rob let's say it's aggressively 100 bytes that's actually quite large it can be much smaller

you look at the gas cost of call data 16 gas per byte and you have a 12 second block time this gives you 500 transactions per second then you can you can look around the internet and you see many estimates of this uh but this isn't exactly correct why because if everything everyone was just using you know let's let's consider a thought experience if everyone was using a single evm optimistic rollups then that wouldn't increase scalability we wouldn't be able to fit more transactions per second if we want to maintain the same hardware requirements and we want to maintain the same rate at which we can catch up uh we would still be limited to 15 transactions per second with a single evm roll-up some other gutches and there'll be a few

more gotchas in the side uh you might have seen you know comparisons like this where you know zk roll up the producers of the roll up have to do a lot of work but verification is very cheap because you just have to verify succinct proof you don't have to you know fully execute every transaction and in an optimistic role if you want to be safe if you don't want to add additional trust assumptions you do need to fully validate every transaction hence why the previous slide we said an evm optimist to grow up does not result in additional throughput without tradeoff somewhere else and you know on the on the surface level it seems reasonable that you know this is what this is this is what validity proofs do they allow you to prove some exponentially more

expensive thing and you know exponentially less work uh but this isn't exactly true uh this is not sufficient because what happens if all the royal block producers just go offline and then no one is around to give me a merkle branch a miracle proof that i need to withdraw my coins or to further transact on the call up then what i have to do is apply every single state transition from the rollups genesis and it turns out that let's say simple balance transfers you know alice just transfers some money to bob that's basically 99 just a transition there's basically no computation being done there just a simple comparison which is trivial uh so it turns out that in zika roll ups

it is not sufficient to just validate the validity proof you also in the worst case and therefore you must metric your system based on this worst case in the worst case you must apply every single state transition from genesis and that is not exponentially cheaper uh so because of this validity proofs only scale pure computation with no side effects they do not scale the number of state transitions and if you're just comparing you know simple alice transfers to bob state transitions then using validity proofs does not provide any additional scalability compared to for instance full validation compared to optimistic rollups okay so let's talk about the now i spend

a lot of time you know telling you why optimistic roll-ups and roll-ups in general don't provide scalability or in what cases they don't provide scalability but you know let's talk about now how they can provide scalability what are what are some benefits of optimizing scroll ups so we note that sharding increases throughput by allowing you to execute many uh parallel execution threads well you can run many parallel executions throughout xavier 64 shards you're running 64 execution things in parallel uh and as long as you don't need to fully validate all of them like if you're just current you just care about one chart then you can get some decent scalability gains from there within a single shard you don't get

scalability but you can run multiple of them in parallel and it turns out you can do the same thing with rollups they allow dynamic heterogeneous sharding which is dynamic because you the number of shards can vary it's not fixed by consensus right you can run as many roll-ups and parallels as you want and it's heterogeneous because each roll-up can be different and this brings us to our second point optimistic roll-ups allow you to explore different execution and data models without hard forks to the base chain and different execution and data models potentially allow for more throughput with the same node hardware requirements for example you can have a utxo based chain and this is what we're doing at fuel labs you can have a custom vm that might not

be as efficient as a utxo based chain but is suitable for interactive verification games this is what the guys at off chain labs are doing and it's fully evm compatible or for instance you can have the movie m and an optimistic roll up or you could have solana's virtual machine or you could have state rent or you could have application specific execution stuff like if you just want to do uni swap you can just have a uni swap optimistic roll up or you can have for instance an evm but add access lists so that you can have some parallel execution so what are we doing at fuel and what's our design philosophy so there's kind of three things one of them is the utxo data model over the accounts data model over dbm with a focus on stable coin payments but

it can be used to transfer any token any erc20 token and potentially any non-fungible token and this allows you to build things like non-custodial exchanges on top of it and other applications like instant withdrawals social media networks and so on and we use an efficient fraud proof scheme that does not require state serious serialization in other words you do not have to compute a merkle root after every transaction or even after every block because it turns out that this state serialization operation is a huge bottleneck for ethereum and you know the reason that state accesses are so expensive in ethereum is because of the state serialization operation and lastly instead of allowing ethereum style you know stateful smart contracts

stateful smart contracts which are sequential in nature we allow uh or we're going to allow stateless predicate scripts similar to what bitcoin has which are much more performant because they can be executed in parallel and they don't require state accesses so the design philosophy here and why we made these design decisions is we want a highly efficient and parallelizable execution model as opposed to the evm which is sequential and this allows us to achieve things like a thousand transactions per second on consumer hardware quite easily because and at this point the bottleneck for us is very much the data availability throughput of ethereum and not client-side execution or client-side validation and we have no state serialization

uh another nice property that arises from this is that because we're using these stateless predicates you no longer really have to worry that much about gas you know it's the predicate cost whatever it costs you don't have to worry about you know the denial of servicing anything it can mostly be measured in terms of its size but you know you can do some other minor stuff but the cost of a predicate is completely deterministic uh so you don't have to worry about gas uh lastly this uh this design is meta-transactional so the roll-up block producer pays fees pays ether fees uh to include these raw blocks on chain but users don't have to which means users no longer need to be exposed to the volatility of ether

uh they no longer need to worry about paying insane transaction fees and ether and so on uh they can just get onboarded directly onto the rollup use the rollup and then they'll be just fine just there so we very much optimize for maximum performance as opposed to short-term ease of use which is what you would see for instance in the evm on a roll-up uh you know our philosophy is very much uh it might be a little bit more difficult to use you know currently nowadays especially if you're used to like truffle ganache and all this other stuff it might be a little more difficult to use fuel but the trade-offs are a massive increase in transaction throughput without increasing node hardware requirements without increasing the cost

to run a full node so if you'd like to know more about us you can follow us on twitter at fuel labs underscore our website is fuel.sh and we recently released our v1 fuel testnet along with uh some some additional things like a wallet and a live fuel plays pokemon demo that you can interact with and our github is uh the fuel labs organization so with that if you have any questions feel free to reach out to me or us on on twitter or whatever anywhere else and uh yeah that's it thank you for listening [Music]