Modular March EP 19: The Power of Fuel Network's Rollup OS with CEO Nick Dodson

Transcript

welcome to modular March I'm handy this is Robbie and we are the rollup modular March is an educational experience about all things Moder [Music] enjoy [Music] [Applause] [Music] welcome to modular March we have another

episode today with Nick Dodson the CEO fuel of course join with Rob GM Rob and welcome Nick hey how's it going um should I do a quick intro on myself sure yeah sure all right uh y so I'm Nick the CEO of fuel um and yeah very very happy to be here awesome yes stoked to uh get into this presentation let's let's do it awesome all right well so um so for today I thought um I thought we'd go deep into some of the problem space and then um kind of how fuel is approaching solving some of the current problems in

the landscape right now and and how we're thinking about building things I'm sure given the amount of presentations you guys have been doing um you know for for modular March I I I'm sure there's like a a ton of content already on like numerous topics so I'll try to be brief with the problem section and then just try to go um heavy into uh into some of our solutioning but yeah so let's uh let's dive into it so first of all um the problem so right now in the roll of space uh just to to dive right into it um you know it's 2020 for um we're doing a lot of rollups now there's a lot of new um different chains coming out there's a lot of new architectures in in

the space um basically you can kind of briefly categorize the architectures that are in the space into two sort of broad categories one of them is um you know architectures that were really designed for monolithic layer one blockchains so um you know if you're familiar with monolithic and modular architecture you'd know that that's sort of like layer ones that um really are trying to design for everything and um and effectively the evm fits into this category so uh does move and so does a salon ofm in a sense these are architectures and virtual machines that were really designed for um you know monolithic chains uh and on the other side of the spectrum you have arbitrary

Computing uh environments and so in that sense you have things like wasm and mips and risk 5 being used so a lot of the architecture right now for rollups in 2024 is really divided along these two these two lines right and um you know when we get into just thinking about this problem some more you can kind of see in the in the current rollup landscape um you know most chains right now are using either monolithic lay one or some kind of mixture of an arbitrary Computing environment um and monolithic lay one maybe there's one or two that were really designed for the tasks that we're really doing rollups like darket but the rest of them are really using

architectures that we've seen in the space that makes sense you know you see the evm out there um it's everywhere so there's a big business model around it um same with salana same with movm so it sort of makes sense from a business perspective to do this but of course A lot of these architectures were never intended to be used in what we what we now Define as rollups so uh maybe a helpful analogy for at least how I see some of the problem transpiring in the space so um like a simple analogy would be like you wouldn't put you know Windows uh like desktop on a phone it just wouldn't make any sense um Windows desktop not configured for your hands not configured for mobile networking not

configured for a ton of stuff that you typically experience with a phone and you know when you look at the way something like an iPhone's built or an iPhone's constructed they constructed everything around exactly how it's used they constructed everything around you know networking around the fact that your hand is touching things the fact that uh you know there's certain battery constraints right and so it brings up this bigger problem which is we're using all these monolithic layer one architectures or we're using these arbitrary Computing architectures but we're using them for something that they weren't really intended for which is rollups and so the analogy sort of holds here like that and to bring up some useful um useful

tweeting you know basically when we look at the constraints we look at the current space for rollups um you know we're starting to see that people are figuring out that um you know you can't just get everything you want out of the existing architectures so nothing is Magic and nothing is for free and basically you know we we probably talked a lot about you know parallel execution you probably talked about a lot of things like State blo and other things with previous podcasts well they're all interl and they're all really complex set of problems and when you're reusing these previous monolithic designs you're going to inherit all the same problems that they have nothing's for free

nothing's really changing and you can't just magically you know turn up the dials and say well it's a rollup so everything's fixed now um and so a way to yeah yeah if you don't mind could you um would you mind breaking this tweet down for uh like a five World sure yeah so with rollups and particularly blockchains we want to do a lot of transactions um but unfortunately when you start doing a lot of transactions there's problems with that so for example if your systems designed where a lot of transactions basically depend on each other um we call this like state or state contention um basically um you

have problems with just managing what we call like this the statefulness of a blockchain but you also have problems with um incurring States so if you're making tons of transactions that's great well now you have tons more data to store you have tons more things to keep track of you have you have so much more stuff that could depend on each other that um could basically bottleneck a system right and so effectively when you have um you know a very high throughput blockchain well there's side effects to that and there's problem with that and really if you don't have a good strategy for how you're going to manage the state of things right which is just you know you have this I have this and as well if you make a transaction I make a

transaction and they touch the same piece of State how you going to deal with all of that right so both state contention and this sort of like big bloat of state that we're having with blockchains is causing a lot of issues um and so really it's not so much that you can just do a lot of transactions that's fine you can Des design a system you could write a python script tomorrow that does a lot of things that look like a transaction and and process that just fine the big question is is like what are really all the side effects of this what do you really need to run this system what do you need to keep track of um what are all the interdependencies and unfortunately for a lot of blockchains and a lot of designs they don't really have a good solution for

this they don't really have ways that developers could fix some of this stuff so you know it's one thing to be like well I can do a lot of TV s well sure you can write a server tomorrow that does hundreds of thousands of TPS right but the design of the system the way that it works is actually the most important thing if you want to build a blockchain if you want to build real decentralized networks and that's no different for lir ones it's no different for rollups so um yeah maybe that's a explanation quick clarification on on the state bloat it does historical State contribute to the bloat or is it yeah so I would say that um there's a few different ways to think about state so really um when when you're thinking

about the problem you're thinking about a few different things one is what does the node need to keep track of right now in order to progress things right so what does it need to have sort of on hand in its uh in its database to make sure that if someone makes a transaction they can process it and know that it's valid um and then another side of it is you know keeping all this historical information over time uh which is more like what you would do with things like archive nodes and stuff like that so archive nodes are um you know they're part of a lot of normal blockchain architecture but they're sort of separate whereas state is sort of like what does the node need to keep on hand in order to progress things into the future right and that's like what does

it need to keep in a database effectively so for typical blockchains that aren't ZK this is what you'd have to deal with continually and even for ZK you would still want the state information because you would need to know how to build new state in the first place so both systems actually have to keep track of State uh in this way that makes sense got it thanks cool so um so one way to think about this this problem this is like a helpful way that we've described it is trying to solve for PSI so performance sustainability and interoperability right you want your blockchains to be super performant super fast you also want them to be sustainable like you don't want to run a super computer right and I think a lot

of the a lot of the negativity around certain chains is that effectively their node requirements are too high and they're running what is effectively like a supercomputer and there's no plan for exactly how they're going to manage the database of those systems how they're going to manage the state access of those systems so they're very contentious and they're they're very large um and then as well you have to manage for interoperability which is really a new thing you want blockchains particularly rollups to be able to talk with each other and you you want them to be able to introspect each other and you want to be able to go over on one rollup make a swap go over to another do some lending come back and do another swap probably have that happen in a very short period of time or in the same you

know block for example so you want to be able to do these things so we want to solve for these particular problems right and unlike sort of traditional problem solving that you've seen in the space um you know you actually want to solve for all three so uh this is what I sort of described for as like the rollup trilemma which in the blockchain trilemma where it was like decentralization security and performance which is like a little different where they were like picked two you know in this case I'm going to say you actually want all three and you just want them so you there's no there's no pick two here it's just pick all three or or nothing basically so you want rollups to be super fast you want them to be sustainable and you want them

to be interoperable um and you know in the state of the architecture nowadays like everyone wants all these things so for this I call it the rollup trma um and to look at sort of the landscape what's happening in the space and I'm sure you guys have covered this with a lot of the modular stuff you've done um there's the landscape is like rapidly evolving right now so there's tons of different execution environments there's tons of different sequencing options tons of different proving options um lots of different data availability layers uh and lots of different settlement layers so there's a crazy phenomenon happening where if you are building a blockchain as a rollup you've got crazy amounts of options happening right and all of these will touch or interplay with um effectively

these things right like depending on what you pick depending on how you go about it it's going to affect any one of these things right so we've got this wide landscape of things happening and obviously for a developer this is going to be pretty daunting right and like there's a lot of issues here in just what do I pick and how do I navigate this space right so there is sort of a need to bring some clarity and some Harmony around how this is all going to work and what people can actually do with all this stuff so a helpful analogy here is um we actually saw similar things happen with Computing and also like the early internet so you can think about different pieces of the stack is sort of different things that you would do with the system so you know some

tasks are more like CPUs some tasks are more like networking some task are more like GPU some tasks are more like storage and some task more like iio and we've got users and we've got applications and typically um how we've dealt with this in the past is we've built operating systems so operating systems are this sort of low-level code that helps us just deal with all of these different things right they help us manage all this stuff so that when users are using applications um they're not thinking about like you know oh my CPU is too slow or you know I don't have enough storage the users are just using applications in the space right and so similarly we think of the rollup problem as a very similar issue right where

effectively you have users you have applications and you need some kind of operating system to really bring everything into order and design for all the problems that we currently see in the space right and do you know the right thing and so um this is where we kind of get into a little bit more about Fuel and what it is so fuel is really an operating system for the rollup landscape and for the rollup space itself so fuel brings a lot of things to the table in terms of our virtual machine our networking our proving or as well the way that we do da adaption um and the idea is just that similar to how computers and Hardware have an OS right that deals with you know all the

different tasks that your computer has to deal with our Ro of os does something very similar which is basically just trying to say hey like um you know you're going to need proving you're going to need really you know a c kind of state transition that works really well for for blockchain you're going to need bridging you're going to need sequencing you're going to need all these things um you know we will come in and we will harmonize all these things for you right and so in this sense what fuel's always trying to do is give you the right tool for the job so something that's really going to come in and solve a lot of these issues that we experience in the space um and also just design things that are more harmonious with the the current landscape and the current space so we say this solution is really

rollup OS itself um and so you know to cover some of the things that um we kind of bring to the table here in terms of the modular landscape itself um so fuel has the fuel virtual machine we have a unique proving model is hybrid proving as well we have da adapters that you'll be able to use to select whatever da layer you want as well we have a very unique set of tools that allow you to build applications in a way that the space doesn't really offer and then as well we have a network so a network of different rollups that can interoperate with each other and basically um you know address a lot of the current problems that we see in the space in relation to in operation so to talk

about some of the virtual machine and and sort of how this works so the fuel VM um really it it packs a a big punch and it's really is well influenced and informed by all the previous virtual machines that we seen in the space so whether it's the salono VM move VM the evm wasum all these different VMS that we see in the space we basically educated the design of all of those things into a single virtual machine so we have a very highly performant sort of 64-bit uh virtual machine um it's capable of doing a lot of transactions so you know something like right now at least and it's unoptimized currently so around 12,000 TPS per core on ethereum

if we're fully optimized with da compression something like 5,000 TPS for for transfers so it can do a lot of TPS quite frankly um as far as the way that it works um Fuel and the fuel VM uses a utxo model so um you know if you've ever looked at or seen Bitcoin before it's something similar to that but ours is much more advanced so really we have you know a utxo model but it works over not just coins like in Bitcoin but it also works over contracts so you get all the same things that you can do with the evm but you get this really unique um sort of State access system um that allows you to use both coins and contracts

together in in a single transaction and you can do many and you can do many different types with many different people owning many different things so it's a really sophisticated transaction model in and of itself and on top of that you can do things like scripts uh which we don't really have with ethereum right now and as well you have things like accounts uh which are predicated accounts so these we call like spending conditions and this enables you to do a whole crazy host of things but um before we get into that um happy to like pause here in terms of like fuel virtual machine stuff and like we could talk over that if we need to before we get into the into the VM I've got a question about the utxo model versus the account model like sure my understanding was

that Bitcoin wasn't able to have Smart contracts because they have the utxo model so how are you able to get smart contracts using this utxo model what is your general thesis on why you chose this model yeah so I I think that the utxo model got a very bad WP both from Bitcoin and from cardono so basically a lot of the things that were said about it are not related to the utxl model but just the way the system is constructed and thus this huge problem happened where effectively the community blamed utxos for something that they didn't do and then uh you know we kind of had this Divergence but all utxos really mean is that you're just defining what areas of

State you're going to touch right however you want to Define that and then you're going to produce something and you're just going to say hey I've changed all these different things right so when you look at the inputs here you're just saying hey I'm touching these coins and I'm touching these contracts there's nothing crazy about that but that's actually the utxo model and then when you have outputs you're just saying hey I'm going to you know send these coins here I'm going to change these contract State here there's nothing crazy about that and there's no Divergence from the ethereum experience of smart contracts or anything like that so you really get to have everything you ever wanted with the utxo model with no downsides um quite frankly the only downside is that maybe it can use a

little more data sometimes um but quite frankly that's worth it because you want to Define when you're processing transactions it's like hey these this group of transactions touches this over here this group of transactions touches this over here right and then you can say send this to thread one send this to thread two right and so when you have that it makes processing super simple and so um you know the utxo model got a very bad rep uh but quite frankly it does nothing in the way of a transaction other than just trying to say hey I'm touching these things now there's some subtleties right cardano implemented too much determinism so they basically couldn't build Unis swap because Unis swap has this contentious State that's

like you know the amounts in the pool and you don't know what the final amounts are going to be when you're making a transaction it's settled later by U the block Builders right so effectively it creates this huge contention and you know you can only make like one transaction per block per app or some crazy dumb thing like that now we just didn't design it that way so we just designed it with the similar way ethereum does which is basically just to say hey like you know if you're touching this contract um then basically you can have five six different people touch the same contract we just order it and line it up in such a way that um you don't need to know the final state of things until later on anyway so there's no contention there basically even if you

touch the same contract so so effectively the utxl model gives you what you really want which is u a state access list of what you're touching in state um and so um similarly with predicates um predicates allow you to then take these things like coins here and then basically do like what would be considered maybe a count abstraction over those coins and you can just Define like what are my spending conditions and a lot of the time you don't even need to use Smart contracts at all um you can just use predicates and use these stateless scripts and you can imagine that like right now we're processing maybe 50 to 500,000 people's transactions

daily with blockchain right but imagine if you had the whole world running through these chains like the entire world right billions of people you can't have contentious State like you basically you would cause it' be way too difficult um for the system to have to comprehend all these things you wouldn't want someone in India holding you up when you're making a transaction in you know like Germany right like it just would be awful so you want to try to break away from using stateful smart contracts and you want to go to things that more lighter they're easier to process they're easier to handle and so predicates give us that ability to to kind of do this um and basically in the next slide just covering some of the crazy things we can do with predicates

but and again this is without Smart contracts we can do things like multisig BLS aggregation social recovery we can support any wallet so metam Mass Phantom secure Enclave we can do things like fee payers so basically you know pay gas and any coin you can set settle really complex trades right um you know really complex trading conditions as well um you can settle really complex intense right um and the idea is that because we're designing for things like sustainability we wanted to opt in these kinds of designs to say developers really want these things they actually want to build better systems that are more sustainable they're lighter they're easier to manage they're easier to

maintain so predicates are really a part of that for us in our virtual machine design um so I can pause there but um yeah hopefully that answers your question too yeah it does and this is a a special result of the fuel VM that you get both the the utxo model and the predicates yeah it's basically everything coming together into one really nice package so we're taking the best of Bitcoin we're taking the best of um basically uh move you could say the best of a lot of these different blockchains and putting them into one architecture and making that into something that um is actually pretty special so so this is on the virtual machine side so just touching on some of the things there is way more

stuff in the fuel VM but you know just wanted to touch on a few things um to go into more of the proving side so um basically fuel uses what we call like um it's like an optimistic and ZK hybrid so essentially um we combine both techniques together where if you have an invalid block you just submit it to a ZK proof if it proves that the fraud is you know uh is there then you just remove that block but you just keep producing new blocks from the most recent valid um block and so the system really never stops um but effectively you have this much easier way to prove that a block is invalid this also gets the fuel

architecture ready for ZK um which we do really like but we're just using a little more pragmatically especially if our system's going to be doing you know you know 12,000 TPS per core for example that's one core so one core in your M1 can do 12,000 TPS now if you do eight you multiply that by eight right now to do that same work over a ZK requires like lots of things like a crazy amount of stuff and warehous yeah a warehouse now mind you that might work for certain things and that might be totally fine for certain things and asex and other things are going to come all kind kinds of crazy stuff but for now fuel is more pragmatic about how we want to use

proving in ZK so for us like we'll use it right now when things are invalid eventually maybe as they get more efficient we'll use it for when everything is valid um so basically just using the technique in different ways but yeah the idea is we have a much more simplified game it's a single round game and when there's an invalid block just prove that slash the block keep going so this allows us to do a few things like we can reduce eventually uh bridging time down um and as well I also released a paper on uh or re research on what we call fast finality optimistic rollups which effectively can get the finality of an optimistic rollup down to potentially even one ethereum block if

you have the right kind of design in there so so essentially um we have lots of different ways to make optimistic rollups into the system that we really want to see um but ZK is playing a role for for us in multiple different ways um so um so yeah that's just like a you know I can pause here as well but um yeah happy to go into I got a question here too and your answer might just be go read the paper but like it is is one way to think about this essentially that it's an optimistic rollup and then there's a fallback to ZK in the case of uh essentially that that s-day dispute window that no one really likes no one really takes the canonical Bridge because it because of that s-day dispute

period um you basically have the optimistic settlement on the L2 and then in in that case where you're either going back to the L1 or in the case where someone calls dispute that's when you fall back to this ZK uh proof to prove that the the fraud is there and invalidate that or re so let me um describe a few different things so with this there's a lot of nuance um so basically the way to think about the 7-Day window um is sort of it actually doesn't have a lot to do with the mechanism itself so whether you're using this CK dispute prover or you're using just a pure ivg model like what optimism is implementing or or arbitrum

the 7-Day window is really just you're trying to give enough time to submit a transaction to say hey there's something wrong and then you go through the whole process of the game right but unfortunately the way that ethereum's designed um you know if someone just fills up ethereum blocks for a long time um and you make that window Too Short then basically you have this big issue where like you can't get in the flag transaction to say like hey there's something wrong you can't get it in so an attacker a smart one you know could basically attack all these systems right um so this mechanism uh is just trying to simplify the s-day window down um sort of in a sense of we know we can

probably safely get the window down to 24 hours um regardless of the mechanism just to try to do that um but the finality post that I made is actually a little different the finality post um takes the optimistic rle up on its head and it sort of says well um instead of trying to submit a transaction only when there's fraud what you do is you have everyone submit constantly that they're things are okay and if one of those transactions is missing then you know that there's actual fraud and you start expanding the window passively so you flip it on its head and then that way um a censor can't censor you so it's an interesting post it's definitely going

to be part of our sort of finality model uh for offering um fuel rollups um but the idea is just that when you flip it on its head you no longer have this censorship is issue because you're basically saying if there's a missing transaction then we assume censorship and the window just passively expands up to something like seven days so basically um this allows us to do some pretty wild stuff like you can have many different optimistic rollups that are coming to finality effectively like a soft finality um just so long as everyone checks in um all the different validators in the pool check in um so it's a slightly different model U to what's described here in the sense of

this is just for voting and progressing state but um the whole idea is just that um the combination of these techniques can allow us to really significantly reduce um the finality time optimistic rollups which was a huge burden before because it was like you know you want to deploy an arbit from lirer 3 well you got to wait seven days to withdraw to that right it's like that sucks you know but now actually with fast finality optimistic rollups and as well using things like the ZK techniques you can simplify the actual game and you can lower the finality window so um I didn't really cover that too much on this because it's still sort of like active research but the idea is just to say that um we have the ways now to do a lot

of different really cool things um and uh and as well even that other technique does use ZK so it's not to say like gets rid of ZK it's just to say we use it slightly differently than ZK rollups right now yeah um yeah so that's on on that point but there's sort of a difference between the proving mechanism versus like the finality window and the challenge window and that sort of stuff like they're kind of separate yeah um cool uh so in terms of da um as well like fuel will aim to support all of the common da layers that you see so um our first one's going to be 444 da but of course we'll allow for options

for Celestia and ail uh igen da near da all the other kind of Da layers that are out there um so we'll have full da sort of adapters for for all these things um right now we just got to focus on ethereum uh as we get our first layer two out um but we'll allow for these other da options after on the tooling side um we also have our own language we have our own tool chain called fork and we have our own uh infastructure so essentially um this problem of like having to go between five different tools or all these different you know pieces of infrastructure Etc um is now completely simplified so when you have your own language it also means you can do everything you can do testing you

deployment you can do indexing you can do everything with the one language um so sway will really be sort of the ultimate blockchain language that that people can use um and Fork will allow you to do it all in one tool chain so you don't need to have five six different tool chains you can deploy an app with that you can deploy a rollup with that you don't need to go anywhere else as a as a developer sort of answers all your questions and then as well for fuel infra all these other things like um providing really rapid um soft confirmations providing all kinds of different data and streaming infrastructure all the things that you typically see with blockchain but providing that for a very high throughput chain so doing it for the evm is one thing it's like 15 TPS doing it

for something that could do you know thousands of TPS it has to be designed a certain way so um we try to provide all the necessary tooling and especially with our language and you know um all the different attacks you typically see uh with solidity and everything else it's nice that you have a different blockchain language that tries to address some of these problems um so on the right is all of the reentrancy attacks uh that have happened on ethereum it's not all of them too it's just a it's just a section of them uh and then uh on the left is a smart contract with re-entrancy inside of it um so naturally you know when you're designing a language for a blockchain you want to address some of these things

and sway does um and sway brings a much simpler kind of system or interface to the to the table so full standards being available for everything as well like re-entrancy prevention is provided in the standard Library itself and just bringing in all the new things that we know about language design into the table like traits and all this other stuff so it should be a very fulfilling language for developers to use and something that they can be really productive in really really quickly um Nick real quick on the sway part uh forgive me for my lack of programming knowledge but isn't creating your own language risky and also isn't it just recreating the same problem of solidity where it's like users have or devs have

to go and learn this entire new language and kind of start from scratch versus something that they may already know yeah so I think there's a few points to that so so one is that it's not inherently that solidity is bad because it's blockchain language uh in fact I think that's one of the best things about solidity is that it is designed for what it's for now mind you because of the way the evbm is constructed because of the way solidity works sometimes it's really hard to pick up things like rency with it and as well the language was designed iteratively over time with many different code maintainers so it kind of succumbed to a lot of like grammatical complexity that it might not have needed to um but solidity actually its problems are

basically that it didn't have other great languages to look at and I think rust was still a developing language at the time so it couldn't really model itself after something really strong now on the flip side if you do use rust to make smart contracts it's also horrible in a different way so when you use rust or C to write a smart contract those languages were really designed for systems like they were designed for systems programming right and when you use something again that's not designed for what it is you end up with this like super Band-Aid mess where like sway right now looks like it's only you're only writing what you really need for your smart contracts you're only defining and setting things up for exactly how the thing works with rust

that's like you have five million different annotations you have like 10 different ways that you need to constrain the system just to make it work properly and that's because it's not really designed to build smart contracts it can but it probably isn't the best tool so sway tries to mediate between all the things we learn from solidity all the nice things we learn from Modern programming and rust and it tries to give that to a developer and quite frankly learning sway is going to be really easy for someone with solidity because you have things like um a blockchain language that's designed for things like storage and abis and everything else so that'll be very familiar to a solidity Dev like they'll look at this and be like takes two seconds and as well similarly with Russ like they'll be very familiar with the

syntax and the uh intention of the language so effectively you might think yes it is more risky but actually all we're doing is bringing the best stuff from what we saw with previous blockchain languages the best stuff from rust and trying to bring that to a Dev in a way that um you know makes a lot of sense and is actually designed for the job of building these smart contracts so yeah are there uh trans compilers that like if I want to write it in solidity or rust or hypothetically even if I wanted to write something in like natural English language like it'll just kind of translate over so um I really shouldn't do this but I could share

something if you want to see something yeah uh okay let me see if I can share my screen real quick so this we haven't released yet um but you can use it right now let me just present my screen for a second um okay so here's sway playground so this is actually public um you see my screen yeah yeah okay so you can actually just hit this solidity Tab and we actually have these full transpilation demos now so you can fully transplate here's solidity on on the left here's the sway on the right and again this is more educational so here I'll pick an E20 token so you can see like sway is actually pretty nice

language in the sense that because we took these nice things from solidity we actually have a much easier time transplating the logic over um so this we haven't launched yet so I guess just don't bring it up too much in the tweets um but uh but yeah this is really meant to try to train solidity devs into sway really quick right and make that process super simple um so so anyway um and we'll have a lot more really Dynamic translation um later as well so uh it'll only get better from here and as well we also want to have sway Target other backends so there's all kinds of blockchains that could really benefit from a frontend like sway basically um

so like Aztec or or miden um it's really hard to build a language so we we spent a lot of time on this so basically I think could benefit from it if we could get it to to work so anyway that's um maybe a sneak peek um but yeah yeah so you can you can take a look at that that's like sway playground. org um cool okay oh any other stuff on sway or next next slide all good so um so the last thing which is also a little bit of alpha is um we actually are putting together a sequencer for fuel too and the sequencer allows for um the sequ saying of um both block production and transactions over

many different rollups so the idea is that um fuel has a very special virtual machine and has a very special kind of transaction system and we can really create a lot of interesting advantages with this at the sequencing level where blockchains can really actually look at each other and talk to each other if you're putting the transactions in the same funnel and so um so fuel will have its own sequencer but we'll always allow people to pick the sequencer they want so if they want to use this espresso they want to use a combination of like espresso and fuel sequencer they'll be able to do things like that um and so effectively we want to give people as many options as possible but we also want to offer our own selfishly because we think we can offer a lot of really

interesting design patterns in value so basically um you know when it comes to you know producing uh blocks for different rollups you would have the you know transaction go to the builders the builders um are then going to either via an auction or depending on how the rollup setup you know many different models are then going to decide um the sequence um and then that basically goes into uh execution and um gets passed off or it gets passed off into um just going down the bridge um back to ethereum so um this diagram is not the best diagram because it goes from sequencer to rollup but the point is just that um um contextually speaking you can have um

these fuel Builders they could build for potentially different rollups um and um you know you'll have sort of a a system in which rollups can not only have blocks being built for them but also they can interoperate so the rollups can see each other and they can introspect each other which is something that um you want to do as fast as possible and you want to do um basically at the earliest possible stage and so with fuel you can have um two different rollups that are basically looking at each other's block Construction they're looking at each other's block design um and then they're basically like filling in different information from different chains um and given the way that predicates work and other things in in

our virtual machine design um you can basically have things like trades that settle when certain trades happen in different chains you can have all kinds of sort of instantaneous interoperation going on and when you mix these models with things like our fast finality Gadget you get this really crazy sort of system of rollups that we just haven't really seen yet because we've been working with the evm we've working with move and you know these VMS are not really designed in this way so for fuel because we design it from the beginning this way in operation is going to be really smooth and the sequencer is going to help with that process um gotcha real quick there if you don't mind yeah um the the big like sequencer situation is

you know why use decentralized shared sequencers if you're rollup operator why give away all your Revenue espresso is like no you don't have to asri is like no you don't have to no kid Etc so that problem is kind of being solved by the shared sequencer level in a sense at least being thought of and iterated on when it comes to fuel sequencer what is going to be the financial or economic situation between rollup operators and fuel um kind of Dow or however we want to Overlay that yeah so so I think with sequencing um there's a few different things so most blockchains are not dealing with what fuel's model is right and so they're not really set up for that now they might say they are but if you ask someone like Josh they'll be

pretty honest with you and be like we're mainly doing the evm right now right which means that you know for a new architecture like fuel it's pretty rough to actually get the kinds of things you want inside of a sequencing environment right and secondly sequencing can happen in a more additive way so when we decided to go down the route of doing a sequencer we know that um we probably could at different stages tap into other sequencers for different things um and so I actually think that sequencing can happen over a bunch of different layers and not just have to happen through through one specifically but moreover there's a lot of different kinds of design that we wanted to do with utxos that are sort of settling in a stream

format you can say so long before it ever gets to you know ethereum or like a final settlement layer almost at the meol level there's kinds of Trades and settlement happening via utxos and Via predicates and that's something we uniquely can can Advantage right so for fuel as we build out our architecture we want to really be able to have apps and uh devs really advantage that because it's really the fastest kind of trading the fastest kind of transactional design you can possibly do right it's way before it's almost even in a blockchain you're already settling things you're already moving things around right like as high frequency as you can get it so the reason why we wanted to do our own

sequencer is because we wanted to really um you know show out show off you could say all the different things that fuel can do um but also because at a very basic level we just want to decentralize our block production and quite frankly um you know for the kinds of architecture that we make and we we build we'd prefer to be able to tweak that pipeline so that devs get the best experience users get the best exp experience and of course we'll always offer other sequencers as you try to deploy rollups so you don't like it you want to use espresso or asria go ahead you know I think it's just we we want to um really have the best Showcase of our Tech so maybe that's the answer yeah cool Al righty

awesome so um what I got I only have a few more slides left so it's h it's it's closing out um but uh but yeah so to kind of it up um you know we have a whole Suite of tools we have a whole set of architecture um for you know rollups themselves all designed to really meet a lot of the problems that you see in the space um and basically we try to address a lot of these problems with um just good design whether it's like performance where we have the VM and the transaction model or sustainability which is more in the transaction model in the predicates or interoperability which is like the transaction model in the sequencing we try to provide the developer um really comprehensive

operating system to really build incredible rollups and ones that can you know scale they can perform really well and they can also be very very sustainable um and you could just imagine systems both like conduit and also um something like fuel is a service where you just select the sequencer select your GA layer select you know your proving model deploy it's done and you have you know rollups that can do um you know 12,000 DPS per core so it'll be a pretty wild reality for for for that and it's already starting to happen with other architectures and really between these different these different tools these different ideas um we want to really comprehensively solve a lot of the problems that we see in the space

with again good design good architecture um and yeah that's basically uh basically end of presentation yeah well you better watch out because Josh is coming for all the RAS providers so FAS has got a got a hotthead for him I uh I believe it but uh you know I I know all of Josh's weaknesses so it's it's okay uh we we every time we we meet at a conference we have a good good conversation so yeah good man we really appreciate you coming on and um giving us a live demo a full um conversation and answering some of our questions for sure and um yeah I guess the last question that that we have which

everybody has for for you and fuel is Wen when yeah so um soon TM uh and you know like if you're if you go back into like old ethereum uh folklore uh it's like two two weeks TM is the is the statement so you know yeah they said two weeks TM and it took them another eight months so something like that so somewhere between two weeks and eight months sounds sounds plan yeah all right thank you man awesome all right thanks guys