Fuel - A Trustless Scalable Sidechain

Transcript

good morning everyone my name is John Adler I'm here to talk about fuel I trust the scalable side chain so I'm with fuel labs and these slides will be posted online a bit later so first of all before we kind of talk about our solution and how we do it and so on we should probably talk about motivation and why we want to do this and how it will actually provide scalability so what we're targeting is the scalability problem and as you hopefully all know one as we've seen over the past 10 years Bitcoin and aetherium are extremely unscalable so they have a very low transaction through but you a Bitcoin which is doing maybe three to seven transactions per second etherium is

doing fifteen or if you're just counting simple payments it can maybe do up to 30 and meanwhile Visa is doing you know several orders of magnitude more transactions per second and that's kind of the number we at least want to reach and hopefully surpass and we want to increase our transactions per second so scalability without decreasing decentralization and you know what do we mean by this so we should look at the scaling bottleneck so there's a common talking point that to use this as an example EOS is more scalable than a theorem or Bitcoin because it's centralized around 21 block producers and as you can see and the picture on the right here Bitcoin in mysterium there's maybe four

mining pools that control the majority of the hash rate so you would expect that Bitcoin in a theorem should be more scalable than EOS if that validator counter block producer count actually affected scalability so it's wrong that the number of nodes has any effect on scalability because consensus is not the bottleneck so what is the bottleneck it's this it's a social contract and on a theorem we want non-consensus full nodes to be with a fork or CPU approximately eight gigabytes of RAM and an nvme SSD to be able to fully validate the chain at a rate that's about ten times as fast as it grows in a Bitcoin this parameter is different you know you want a weaker computer like a Raspberry Pi to be able to validate the chain

faster than it grows 30 to 30 times faster and the Neos the parameter is that you want a very powerful server to be able to just barely keep up to the chain and the social contract it has nothing to do with consensus or the number of notes so we want to increase scalability without increasing node hardware and network requirements so why is it that a theorem can only do 15 transaction per second which is about double what bitcoin you can do despite having way higher node requirements and the reason is EVM execution so a theorem can do more complex smart contracts than Bitcoin right it's not limited to state those

predicates so I can do you know the stateful smart contracts a Kuna swap compound all this amazing dfi stuff is only possible because etherium can do stateful contract execution and there's downside for this which is that state accesses and snake growth are kind of the biggest things that are hindering aetherium scalability right now aetherium is uncompressed state size is around 45 gigabytes which is you know quite a bit larger than that gigabytes of RAM we expect notes to have and this is why you need to put the state on disk so on an SSD and this is why you need an nvme SSD I mean while bitcoins use also their state is about two gigabytes so there's kind of the huge blocker you know state accesses so why do i do roll-ups now scale a thing I'm

specifically so the role of design paradigm is one that's very nice and the one that's gaining traction in the blockchain world which is let's move state and execution off chain and use the main chain just for data availability and ordering so the separation of execution from availability and ordering as a as a new design paradigm that's going to be very exciting to see in the coming years and then you can ensure the block validity of this roll-up chain using one of three things you can either use a literally proof like ZK roll-ups you can use a fraud proof plus the synchrony assumption this is what optimistic roll-ups is or you can use an interactive verification game plus the synchrony assumption and this is what the guys are often labs are doing so Y can roll up scale and we'll discuss the

can in the next slide so with roll ups the consensus nodes are only respond before making that available and ordering it they don't execute transactions and as we saw in the previous few slides executing transactions is very much the bottleneck in aetherium because of the stateful EBM execution and is very powerful because that you literally can't do last execution that no execution so I said can there's a catch here which is you know you often see that optimistic roll-ups can scale EVM contracts as we currently know it to you know 200 transaction per second a thousand transaction per second a hundred thousand transaction per second you may have heard so you know you see calculations like this you have 10

million gasps hundred bytes per transaction around sixteen gasps provide for call data at twelve seconds per block and this gives you around five hundred twenty one transaction per second on each one but does not the whole story because if everyone was using say a single IBM optimistic roll-ups then you wouldn't actually get any scalability because again the bottleneck is execution and you want people to use the roll-up and be able to fully validate it with the same node requirements that we currently have for aetherium so if you're not increasing the node requirements your EVM and the roll-up will still be limited to fifteen transactions per second despite the fact that a serum can process way more data availability so the unique benefits

about to mr. grow up can be kind of compared to charting so sharding provides an increased transaction per second not because there are fewer nodes on each shard but because you can execute many execution threads in parallel and there's kind of the same thing that you can do at the roll-ups you have a single layer for data availability and then each roll-up can be considered as a form of dynamic heterogeneous charting where you can spin up more or less shards at will and each of them can have a different execution model which leaves us the point two which is that you can experiment with different and potentially better data and execution models and you can do this without hard forking the etherium chain for instance you can have a you TXO data model that's just for payments which is what we're

focusing on what we're going to talk about in the next few slides you could have a custom vm that was specifically tailored for interactive verification games that has constant time for each instruction so this is what the octane labs guys are doing you could have libras movie em inside a row up you could have you know the EBM but augmented with things like state rent or access lists and so on but it wouldn't be the plain AVM it would be an Augmented version of the evm or you can do with another application specific execution models so let's you know focus on that first one the YouTube so data model and our fuel fuel roll-up chain so it's centered around a few critical design features the first one is DxO

data model not the account data model that were used to an etherium and we kind of have focus and stable coin payments but you can technically transfer any token and build things like non-custodial changes and social media sites and so on on top of fuel and the DxO data model of course is this you know much more performant and have much much better state access patterns done the account data model and we're also using an efficient probe fraud proof scheme which I wrote about here on earth research and this allows you to have fraud proofs without having to bother with serializing the state tree after each transactions after each transaction and finally we also allow or we will allow a fairly expressive stateless

predicate script so think like Bitcoin but more expressive because we don't have to you know deal with all that the package of Bitcoin core so the design philosophy around this is that the utx no data model is highly efficient to execute and allows for parallelizable validation so we can easily get 1,000 transactions per second on a our current our current implemented system on consumer hardware and for us unlike for EVM roll-ups for us the bottleneck is very much data availability throughput and not execution so we would very much benefit from some layer for example like e2 that has a much higher data availability throughput

there's also ease of use since we're not doing general-purpose smart contracts we don't need to gasp we can have you know the execution time or the validation of the transaction is fixed there's known beforehand so transaction gasless and you can think of it kind of like a meta transactional layer where the roller block producer will accept any token for instance died to pay their own fees internally and they will pay the users on chain eath fees so you can imagine systems where entire you know hordes of regular users that aren't in the crypto can use things like dice table coin payments without having to be exposed of the volatility of ether and stuff like that so our paradigm for permissionless nuts because all roll-ups

need to have some way of allowing users to forcibly include transactions inside the roll-up chain or become a rollup block producer themselves so our paradigm is happy case centralized but always have a fallback to fold these decentralization so this means that you know in the in the happy case where everything is going smoothly there's no censorship going on there's no double spends going on and everything like that you might as well just use a centralized operator because it's more efficient it's more convenient but it's always important to always be able to seamlessly fall back to fold in decentralization if this operator ever misbehaves one last interesting thing is that this roll-up chain can serve as a meta finality layer especially useful

for payments you may have heard things like optimistic roll-ups allow instant secure trust us hero confirmations of transactions this is this is not true you know you you need your transaction you need to roll up a lock to be included on the etherium chain to have any measure of security the reason for this is that mev oh sorry now we'll go to a point to you can however have secured like you can prevent your roll-up chain from getting reorg if the main chain gets reward because you know the mev of roll-up locks that are already revealed and they're made public and they're committed to the main chain since there's known then you can just have some shared bond pool and then

if the roll-up operator equivocates so if they reorg their roll-up trim then you can slash the bond since that maybe is known then you can actually do this securely so you can think of it like some sort of meta finality they are on top of a theorem so even if the chain gets gets reorder gets changed then the row up chain can actually say the same which is nice because now you no longer need to wait 15 confirmations for exchanges you can actually accept a one confirmation deposit or a dollar from an exchange so that's very powerful so if we want to go beyond charting so you know we discussed earlier that you know charting provides you know multiple execution threads which is great but charting only could provide the constant

factor increase in transaction per second right we have 64 shards then you get 64 times the data throughput maybe under certain ideal conditions but can we do better than committee based chartering the answer is yes we can if you have a need of data availability layer with only client-side execution then you can exploit sublinear data availability checks and these also scale with the number of users which is unique property among our block chains so if you're interested in this paradigm please check out those editor so that about wraps it up where to find us you can find us on Twitter at few labs underscore our website is fueled on Sh and here's our github we've released an open beta test net that's currently running two of them ones unwrapped and

the other ones I'm Gurley more recently last thing last week we open up some nodejs sdk code so that you can quickly spin up something like a wallet integration and so on so if you're interested please follow us give us a give us a call or a show if you have any questions and so on that's what that's where to find us [Applause] there are any questions for the next couple months wait would you be able to that outside because we don't have sort of sorry about that yeah oh yeah if you want to have you want any questions then I'll be outside Thank You Man is Alexi here Alexi