DAPPCON 2025: Fuel, The Execution Endgame - Nick Dodson

Transcript

[Applause] All right. So, um, today I wanted to pitch my own project because I seem to do all these technical presentations around other things. And I think, um, I think it's actually a great opportunity to show what we've been working on a little bit with fuel. And also as well there was a a point about the only uh layer 2 that deployed to stage 2, but uh Fuel was actually the first to do that in December 2020. So we we definitely um we definitely have a long history with layer 2s. Um but uh yeah, I'd love to just go over maybe why fuel is important

to the current landscape and as well um try to give everyone a sense of some of the techniques that we use to both improve execution while also retaining things like verifiability, decentralization, trying to um really balance both of them. Um and I think um you know hopefully hopefully you guys get something from that. So um I think it's really useful today to talk about blockchains in relation to Hyperlid mainly because Hyperlid if any of you don't know um it's a project that's come to a lot of uh popularity recently and Hyperlid is actually going to be very very important for like this presentation but also for just guiding the discussion in general around

blockchains. The main reason why is because it's a next step in evolution in what blockchains will do for human beings. And originally because of blockchain's constraints, we've basically been designing them for minimal sort of execution constrained environments like AMMs. Uh and AMMs are like a perfect example of like you know very simple algorithms that we run uh we run them in in kind of these blockchain setups and you know you get swapping. Um they're not great. There's a lot of problems with them but uh they work enough and we've made them good enough to kind of perform the different tasks that we want to see. But order books um are something that's always been really difficult to run on chain and even if you could do it there's a lot of issues around them. Um there's a lot of new

markets coming up um a lot of different derivatives uh synthetic assets etc. Um, but even with systems like Hyperlid, um, there's a lot of problems and they mainly come from the fact that, um, when you're building something like a product, you just sort of like do the product. And Hyperlid really did a great job at building a great high performance perplex. But what they didn't do was make a system that could actually be really scalable and composable. They just sort of really focused in on that product itself. and because they didn't focus on say all these other blockchain challenges which is totally reasonable if you're just trying to get something to to work well um you kind of miss all these other opportunities and then now when you try to slap on some of these

other architectures like the EVM um as you see with things like Hyper EVM what ends up happening is you have this sort of older slower or harder to scale architecture like the EVM slapped onto a very application specific architecture like an order book and And it's very hard to get the interplay to work well especially at scale especially in a composable environment. And I think that if we really want to see blockchains uh be adopted by humans in general I think the first step that we need to take is bringing all the centralized exchange volume that we see right now on you know Binance and everything else bringing that onchain and the second we can actually bring all that onchain then we've hit like the next step. So because

those are all of blockchain's users, but currently many of them are still on just like effectively websites with servers calling themselves maybe blockchain people, but really they're just trading assets. I think a huge milestone for blockchain will be can we actually bring all those people on chain and it will probably be many chains, but can we actually do it? Um, and so if we wanted to do that and we wanted to make it composable, there's a lot of challenges and and this is sort of, you know, where we kind of uh see the next step. So again, you kind of have this super high highly performant architecture uh designed for order books um which you know works really well but then you try to like slap on additional primitives like whatever unis swap is or lending systems and all these other things and

it's very hard to make these two really seamlessly composable at scale low latency all these other things that all these other properties that you want. Um and you know eventually you're going to get a lot of problems. So, Hyperlid might be really good at doing order books, but it's probably not really good at doing all this EVM stuff. Um, and so basically, you get this scaling Hyperlquid issue where it's like, hm, well, not only is it very hard to actually like scale all of this, but there's a lot of side effects to doing the design that that's been done here.

Um, the state of the chain explodes, right? That storage system that needs to be sort of in the um, uh, basically readable. So that's uh and in sort of like the hot path um so that you can actually verify everything that explodes. Um as well there's sort of execution chaos where you have sort of like one architecture that's maybe appsp specific and another one that's inefficient. You're trying to blend them. It's very difficult. Um and then there's as well developer pain because the whole chain wasn't really configured for setup for this particular kind of thing. So you have a lot of patchwork and band-aid architectures going on and then basically no existing chain that you currently see sort of solves all these things at once.

And so really when we say um you know execution is the endgame what we're trying to say is is basically that um if you want to actually bring the world onchain this execution side of blockchain is like extremely extremely important and how it's architected has tremendous consequences. If you architect it incorrectly the state blows up and then no one can verify it. If you architect it uh in a way that might be really application specific uh that's great that's going to solve maybe one problem but then it's going to create other problems with things like composability. So this is where fuel actually comes in and why I wanted to just kind of speak about fuel. So um Fuel is a a layer 2 um and it's a mainly focused on um high performance execution

and um some of the big things that you could say Fuel does really really well is um we have a very lightweight transaction model that's um very easy to verify uh and as well um we have a new virtual machine architecture and we have a new language um and these things combined allow us to do um highly expansive uh execution in an environment that uh can still be verified at home and um can still retain a lot of these nice properties that we uh that we want from blockchain. So it really brings sort of the best of all different kinds of blockchain design into a single architecture. Um and this is why the architecture is really built for the next sort of 30 years of blockchain and not just sort of the next you know one

or two you could say. Um and so in terms of the design targets for metrics, um so right now like uh what we're aiming at is to try to get fuel's uh current um layer 2 up to around 150,000 TPS um 1 to 4 second bridging time um as well um 1 millisecond soft confirmations with collocation um as well trying to aim for decentralized sequencing retaining composability in that space. So you could have say many hyperlquids, many lending markets, many different things all in the same space still retaining home verifiability. Uh so reducing this uh incurred state as much as possible uh and then supporting sort of bridging in

wallets from any chain or any wallet or any asset. So this is really the design targets that we want for this architecture to really try to bring um all this volume that we see in centralized exchanges onchain. Um and what I would say is is uh one one of the most important aspects of this is definitely the UTXO side of our architecture. So Fuel is built on a UTXO model and this allows us to do many things at once. It allows us to um basically process uh uh transactions in parallel both in the execution side and in the verification side. Um it's also much uh lighter weight on state because um you can apply all these interesting techniques such that with a layer 2 you

don't actually need a global state tree. So eliminating Merkel trees is actually a huge reason why fuel's architecture is so efficient. Uh and as well for fault proofs they're really really good because um you can basically apply all of these different uh kind of logical assumptions around them just based upon the way that UTXOs work. And it's fundamentally just a state diff, but it's a state diff that has to always either be created or be pointing to something. And because you have this inference, you can basically design um a really robust fault proving system. Or you can also design very minimally efficient state tree global state tree architecture if you wanted to go for valid or you wanted to go for um you know some kind of zk design. Um as well

just to highlight for privacy um while we don't focus on privacy right now for the orderbook product that we are working on uh we will use um many different uh uh mixing levels um with ZK mixers just to ensure that um uh while the trading remains very highly performant that traders identities can still be protected um so and the UTXO model is actually fantastic for doing privacy um so in terms of the expansive execution ution space that we have. So, um the fuel virtual machine is really uh key to this and I'll show you sort of a slide of that next. Um basically because we've redesigned the virtual machine and we've redesigned the uh transaction

model, it gives us a lot more room to work uh when we process things. So, this actually makes things like onchain order book matching and other things uh really straightforward. Um we've recently added soft confirmations which allows us to get really nice low latency especially if you're closer to um the core builder. Um and as well high throughput uh is basically uh part of the architecture by default. Um both from the fuel VM and as well the the the UTXO architecture. So for things like uh the user experience and for market makers both of these is really really really key. Um, and then as well because we have things like scripts, um, composing between different contract architectures is really easy.

Uh, and then as well, um, we're fully set up for things like account abstraction. Again, playing off of the UTXO model. Um, and and as I said before, scripting makes things super straightforward for, um, composing between these different these different systems. So, the Fuel VM actually takes inspiration from a lot of different virtual machines. Um, and there's many reasons why we decided to build our own VM versus just taking something off the shelf. Um, I would say the most akin VM to it is probably Risk 5. Um but basically the the core principle behind it is we want to design a virtual machine architecture that pairs nicely with a transaction model gives you expansive throughput gives you a really rich instruction set um but is actually

calibrated for um basically these sort of uh uh gas metering that we do with blockchains. And when you factor in just gas metering alone um the whole design of the VM changes basically. So gas metering actually changes the whole way you would want a virtual machine to work which is why risk 5 is actually like a terrible decision because it's not really built for um metering in that sense and as well there's just a lot of additional instructions you would want to add anyway uh and it would just kind of become a different virtual machine. I mean you could dump it all into the e-all instruction but it's not really that great. So the fuel VM pairs really nicely against the UTXO model. Um and the UTXO model pairs really nicely against this concept of predicates. And

predicates are sort of these lightweight um uh scripts or accounts that we have. And um because of the assumptions around how predicates work, which is something we take from Bitcoin, um it ends up um allowing us to do uh really rich and interesting designs where you have in a single transaction something like many inputs, so many different coins and we also have native assets as well. So you can have a transaction with many different coins, many different contracts, um a script that operates over those contracts in that transaction and then many different kinds of outputs. Um and we avoid this sort of um bad problem that Cardano ran into where they basically used the UTXO model, but they applied too much determinism to how their system worked such that you could

only make transactions if you knew all the state changes and that ends up creating horrible side effects. uh Fuel works very similar to Ethereum just with a much more powerful upgraded uh transaction and virtual machine model such that users don't need to know every aspect of the state change. They just commit to the kinds of constrained state changes that uh we're used to like trading on unis swap or whatever. Um you don't know every detail but you're willing to to sacrifice it. So with this model we can really push throughput into like insane levels um and still do so with like consumer level devices. Um, and then Sway is very much like um a Rustl like uh DSL similar to Noir actually um but it basically allows you to have uh a really great developer

experience as you're trying to build these kinds of primitives and these kinds of scripts. Um so it's very very good at that and um it has all the nicities of Rust but it also brings in some of the nice concepts that we actually like from Solidity not all the bad parts. uh and writing things like an order book or writing things like um you know well all the stuff you're familiar with or used to uh becomes actually really streamlined and really straightforward. Um so even just for an example like here's a counter contract. You can see we've kind of brought in some of these concepts of AI and storage from Ethereum from solidity but uh we've also retained a lot of the Rust paradigms that we like uh like traits such that um you have a nice mixture between sort of um you know the syntax

and concepts of blockchain but mixed with uh sort of all the nicities of Rust. Um so Sway is actually a super powerful kind of tool that uh will help you intermediate between all these different systems at once and it makes writing contracts very familiar to especially Solidity or Rust devs. So where Fuel wins is definitely on um retaining very very light state um expansive onchain execution uh developer friendliness right with uh an all-in-one tool chain and things like Sway. Um we still want to aim for Ethereum security. We're going to be pulled off the layer 2 list soon because we didn't add fault proofs yet. So I know Bartk's in the the audience. Hi Bartekch. Uh but we will uh make sure we add those. Um and as well

um retaining hyperlid like UX um but doing it in a very composable and sustainable way. Something that's um practically very unachievable in EVM settings. Uh and is actually very achievable when you rearchitect the transaction model in the virtual machine. Um and even a note on uh as well on fallroofing and security. Um if you add a global route over uh fuel to make something like validium, you can also just make the tree such that it points to UTXO uh pointers which are only eight bytes and that drastically reduces the size of global trees. So for any of you that have like looked into really intense blockchain architecture stuff uh you'll know that like you can have sort of significant savings uh in

terms of a manageable high performance blockchain. Um so in terms of just the the kind of future we want to enable. So you know orderbook execution can compose seamlessly with DeFi. Scalability doesn't compromise security or decentralization. uh and as well developers can build sort of you know with confidence basically that uh you know there's a robust system underneath um and I think that um you know sort of a part of what we want to do is bring all of this uh uh trading that's going on right now in centralized exchanges which is very opaque very subject to all kinds of negative uh consequences. We want to bring that into, you know, our blockchain world, uh, with better onchain execution, better fairness,

better properties of, um, of just sort of knowing what you're doing and knowing what you're running. And you have to remember, too, that even with systems like Hyperlid, it's kind of like a giant black box. You don't really know what algorithms are being run. Not a lot of things are open source. It doesn't uh, constrain itself to more transparent principles of having things like fault proving and fault proving state transitions, etc. Uh, and basically the way that it's designed is sort of good to get something going, but effectively it's just a centralized exchange masquerading as a decentralized exchange. And what you really want is for actually all this execution, all this stuff to be um, verifiable by anybody both by reading the code, by running it at home. Um, you want to bring that down to sort of the original ideas of blockchain, the original

concepts of what we want to do. I think that's like the ultimate uh, philosophical endgame that you would want to get to. Um so for fuel uh you know I really believe fuel is the execution endgame. It combines a lot of these um very important learnings and lessons from every kind of blockchain architecture that's out there and it brings it into a single kind of cohesive system that um you know again I think is something we can use for the next 10 to 20 years without having all these downstream side effects of things like the EVM or risk 5 or architectures that quite simply were not really designed to scale um given the current uh climate that we have with with blockchain applications. Uh and one last shout out is um so we are doing a builder

residency for fuel. Uh so it's going to be three weeks and it's in August in Costa Rica. Uh if you would like to build on this architecture, build something you know super high performance or you know high performance payments app or you know say the next hyperlid for example um you know we'll be down there resourcing everything as heavily as you can um and just trying to uh uh push sort of a new wave of ecosystem uh for for fuel. So, um, yeah, thanks for for listening and, uh, yeah, it was a pleasure. Yeah, thank you, Nick. And we have time for a few questions down here.

Hey, Nick. Uh, you mentioned that privacy was not a focus yet. Uh, so that dangling yet is intriguing. Yeah, I mean I think that um so in order to hit a lot of the targets that we want to hit for execution basically uh privacy is quite slow. So if you try to do it with um basically any number of different different techniques, uh you're going to end up slowing down a lot of the user experience. So the big focus right now is definitely on execution and expansive execution. However, um the UTXO model allows us to be well set up for mixing privacy primitives because a UTXO model, if you've looked into privacy itself,

you'll know that the UTXO model is really actually excellent for these kinds of uh um these these kinds of primitives. So I think that um you know the the end state of all this should be something that's uh both highly scalable and highly private uh and as well that you don't need to rely on data availability uh for your own funds. You can always just pull them out so long as you have the proofs to pull them out. And I think that's like definitely where you want to head. But right now I think what we want to do is showcase that um this execution architecture can handle you know many hyperlquids of volume in the same kind of continuous composable space and then um from that point we can do a bunch of other interesting things but I will make sure that we have uh

like tornado like um tornado like mixing points uh across the order book just to ensure that there's um a nice level of privacy for whales and traders on uh on our order book. Yeah. Uh we have time for one more question right up there. Uh hi thanks for the presentation. Uh in order to achieve your goals do you expect um do you anticipate any problems or challenges at the networking layer at the peer-to-peer layer. So for example nodes getting overloaded or uh needing more smarter architectures or things like that. Yeah 100%. So um basically I

think that the kind of peer-to-peer that we think about uh at least for um how blockchains currently work is very uh oriented around layer 1 architecting. So basically it's with the assumption that all these different nodes have to coordinate and um it's usually over things like consensus and stuff like that. Um what's nice about the layer 2 model is that we kind of pan a lot of that off to either Ethereum or other layers and then the kinds of um decentralized sequencing or building that we actually want uh can be somewhat lighter in terms of how it's actually organized um such that the peer-to-peer layer itself while it's like a gossip layer um you'll always be able to get all the state changes eventually from DA

if you wanted and um the pressures on the peer-to-peer layer are more related to like our softcom system and some of these other things there will be some challenges there but I think that um if you have peerto-peer there's different levels of security that you care about so if you want finality then you're caring about the DA layer and that's much slower and then if you go a next level up then maybe you care about um say like the builder level or fault proving um then that is sort of more on the peer-to-p peer layer before the DA is posted and then there's another level beyond that which is sort of the softcom level and that's sort of attestations issued by the builders uh and those are at sort of the highest level and in

those levels like again there's a different gradient to security. So a market maker or trader is fine taking a softcom atestation whereas like someone who really cares about their money maybe like a huge whale they might want to wait all the way down to DA posting. Um but what's nice about layer 2 is that um fuel doesn't necessarily need to care about every aspect of this. Uh it's just more or less that um we tried to design our system uh both to calibrate for peer-to-peer overhead and for DA overhead. So there's a lot of compression that we can do and UTXOs are actually very very compressible. Um and as well uh with a more recent unreleased state design that I have for uh

contracts uh smart contract state um I think it'll showcase why building with EVM specifically is um completely unsustainable. But when you adopt a UTXO paradigm, smart contracts that work like Ethereum uh like Ethereum smart contracts can actually be fully sustainable um if you adopt the UTXO paradigm. So I think that there's like some real hidden gems with UTXOs that are very very underexplored right now. And they mean a lot for all of blockchain because they mean a lot for sustainability, for privacy, for like a lot of different things. So um yeah, hopefully that answers that question and Nick will be around after the talk. So if you have any more questions for him, you can meet him out here in the event.

Please give it up for Nick Datson from Fuel Labs. Thank you. And next up, we have Philip Shammers from Nosis Chain to talk about recent and future hard forks. So please give