Fuel: Bringing Scalability to Ethereum
EDCON 2021 · 28 Aug 2021 · 10:23
John Adler of Fuel Labs examines the bottlenecks that limit Ethereum throughput while keeping full-node verification accessible. He explains how rollups separate execution from data availability, why rollups still face their own decentralization constraints, and how Fuel's optimistic-rollup design and Sway language approach parallel execution and contract development.
Speakers
Topics
From EDCON 2021, hosted by EDCON.
Transcript
hello everyone today i'm here to talk to you about bringing true scalability true scalability to ethereum with fuel a little bit about me uh my name is john i'm currently with fuel labs we're the leaders in blockchain scalability r d and we're building fuel which is the most scalable optimistic roll-up on ethereum previously i was a consensus doing layer 2 scalability research and i created the optimistic roll-up design paradigm while i was there so before we talk about true scalability let's talk about the scaling problem what scalability means ethereum is limited to about 15 transactions per second or you can do maybe 30 if you're talking simple
payments but more specifically you can do about 1.3 million gas per second you know irrespective of how many transactions that is because transactions could be complex and the problem is that we want to increase transactions per second which is called throughput without decreasing decentralization and recall the sting scalability is transactions per second divided by decentralization so it would be pretty easy to increase transactions per second if you decrease decentralization but that's not scalability we really want scalability so what is decentralization you know we've said what throughput is transactions per second what is decentralization first what decentralization is not a
common talking point is that so-called centralized blockchains like eos let's say just as an example uh the talking point is they have much more throughput than ethereum because they're centralized around a small number of validators let's say eos is 21 block producers but this is wrong that's not why they have a higher throughput uh if it were the case as you can see in these diagrams on the right over here uh ethereum and bitcoin you would expect them to have more transactions per second uh than ethereum because uh they have a smaller number of mining pools essentially ethereum four mining pools have more than 51 percent of the hash rate bitcoin what four maybe five mining pools have you know majority
of the hash rate for four and five is less than 21. so it was just about the number of nodes you'd expect ethereum and bitcoin to be able to process much more transactions but they don't because consensus is not the bottleneck something else is what is decentralization uh on ethereum we want a user running full node on the proximability specs a four core cpu eight gigabytes of ram and an nvme ssd we want them to be able to fully validate the blockchain at a rate approximately 100 times as fast as it grows and this is called initial block download we want to be able to catch up to the tip because otherwise you would never be able to actually
fully validate the trend right on eos uh the specs for a full node are much much higher you would expect something like a 64 core cpu one terabyte of ram you know rated nvme ssds all all that jazz and you'd not even be able to catch up to the chain you would just just be able to validate as it goes but as soon as you go offline for a second then you're done you can't catch up anymore so decentralization is actually the cost to run a full node for the user and we need this and this is critically important because if we aren't sure that block producers aren't including invalid transactions that give themselves you know a billion dollars if we don't know this isn't happening we don't have control over our money right
people can just inflate the supply of the coin infinitely and we wouldn't know uh if in order to have control of the money we need to be able to validate the supply of the token and to make sure all transactions are valid and this is a social this is a social contract it does nothing to do with the consensus protocol it doesn't matter if you're using proof of work proof of stake bft chain based avalanche you know eos dpos it doesn't matter what you use because the protocol is completely irrelevant uh decentralization is the cost to run a fully validated node okay so now there's decentralization but how does this manifest in terms of a bottleneck right ethereum can do 15 transactions per second on the aforementioned hardware but why is it 15
why is isn't it 150 why isn't it 1500 on this hardware right we're not talking about increasing the hardware here we've already fixed our hardware requirements the reason is 15 is because of evm execution it's complex it's costly you can do really complex smart contracts but the real the real big pain point is around state accesses and state growth the ethereum state is currently around 100 gigabytes and the circ this is in a merkle tree uh which means you're doing a bunch of random disk reads every time you try to write or read from a state and this is why you need an nvme ssd uh if like or even a regular santa ssd is going to have a really really hard time doing this uh so
uh state uh the state of the uh of a chain is you know things like account balances contract swords and stuff and this needs to be kept around by all full nodes if you don't know everyone's account balance you can't validate new transactions you can discard historical transactions they're just like the actual transactions themselves but you always need to keep around state it can't be pruned so things like state growth are also very important you know you don't want this state to be even at one terabyte because then all full nodes will be a minimum of one terabyte in size which is really bad all right so roll ups to the rescue uh rollups have a very convenient design paradigm which is while you move state and execution off chain and you just use ethereum for data availability
this seems like a really really good idea because now roll up nodes only need to you know make data available and order it which is very cheap but they don't execute transactions and they don't have state accesses or state growth based on those transactions so this is very powerful because you can't do less execution than no execution this seems like it's you know potentially a huge amount of scalability but there's a caveat here which is that roll-ups are still blockchains and as we said before the decentralization of a blockchain and the whole reason that you know blockchains are self-sovereign is that users can fully validate the state of the chain to make sure that it's not invalid right we don't want to trust the big bank to tell us whether or not a
chain is valid or not we want to be able to determine that ourselves and verify that ourselves right verify don't trust uh as opposed to the opposite so if everyone were using a single evm roll up which if you remember that is the bottleneck of execution on ethereum uh you wouldn't be able to get 700 780 transactions per second as you see here uh you would be able to still only have 15 transactions per second on the single evm roll up unless you want to decrease decentralization unless you want to make your users have less sovereignty over their money uh this 700 ae transactions per second is not the amount of transactions that a
single evm rollout can process rather it is the number it's the amount of data availability throughput that the ethereum chain could support so it could support a total of 780 transactions per second across multiple robs so you could do a form of sharding if you want to call it that where you know you have 100 15 you know there are 50 uh roll-ups that are running 15 transactions per second each you know that gives you about 780 of my math is right uh give or take so you could do something like that but you wouldn't be able to get a single evm roll up at anything more than 15 transactions per second unless you're sacrificing decentralization which we don't want to
do how is fuel different done on evm roll up it's specifically built around a different execution model than the evm and this execution model is more scalable specifically the core ideas of all iterations of the fuel blockchain are that we're using the utxo data model as opposed to the accounts data model so this is similar to bitcoin as opposed to ethereum and this means you can do parallel transaction validation and we have an efficient fraud proof scheme that doesn't involve a global state route or a global state tree so the fuel v1 blockchain it was the first optimistic roll-up deployed on mainnet ethereum it was deployed last year actually uh it is currently the only optimist to grow up without upgradeability so it's
fully trustless it's also the only optimistic roll-up to the best my knowledge with permissionless transaction inclusion so it's both fully trustless and fully permissionless now it's very very maximally efficient and uh because of its parallelizable execution model and because it doesn't do smart contracts it's only for simple payments can we do better yes we can this is where fuel v2 comes in and this is where it brings true scalability fuel v2 will have full ethereum style smart contracts but also in the utxo data model so with the utxos we get highly parallelizable transaction validation but we also get the nice way that ethereum does smart contracts versus other more obtuse ways like what solana has for instance
uh and uh by coincidence we also have a much more flexible transaction model that allows you to do many more interesting things than what ethereum does uh we also introduce a russ-based smart contract language which is called sway you can watch uh the talk here that's linked at ecc alex gave a talk and soy to introduce it uh this allows users to write more secure higher performance smart contracts much easier and it introduces many things that solidity does not have like traits generics uh enums uh spilling so that you can have more than 16 local variables macros zero cost abstractions extends extensive standard library and so on so how do you stay up to date with what you're doing you can follow me on
twitter at jr0 you can follow us at fuel labs underscore here's our website and our github and most importantly if you're a rust type script solidity or if you're non-technical uh that's fine we're hiring both technical and non-technical positions uh here and you can click on the link here or you can dm me on on twitter we're hiring thanks