Fuel, The Execution Endgame

So, today I wanted to pitch my own project because I seem to do all these technical presentations around other things and 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 point about the only layer 2 that deployed to stage 2, but fuel was actually the first to do that in December 2020. So we definitely have a long history with layer 2s, but yeah I'd love to just go over maybe why fuel is important to the current landscape and as well 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 really balance both of them and I think hopefully you guys get something from that. I think it's really useful today to talk about blockchains in relation to Hyperliquid, mainly because Hyperliquid, if any of you don't know, it's a project that's come to a lot of popularity recently and Hyperliquid is actually going to be very, very important for this presentation but also for just guiding the discussion in general around blockchains. The main reason why is because it's the next step in evolution in what blockchains will do for human beings and originally because of blockchains constraints, we've basically been designing them for minimal sort of execution constrained environments like AMMs and AMMs are like a perfect example of very simple algorithms that we run, we run them in kind of these blockchain setups and you get swapping. They're not great, there's a lot of problems with them, but 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 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. There's a lot of new markets coming up, a lot of different derivatives, synthetic assets, et cetera, but even with systems like Hyperliquid, there's a lot of problems and they mainly come from the fact that when you're building something like a product, you just sort of like do the product and Hyperliquid really did a great job at building a great high-performance PerfStacks, but what they didn't do is 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 work well, 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, 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 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 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 Binance and everything else, bringing that on-chain.

And the second we can actually bring all that on-chain, 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? And so, if we wanted to do that and we wanted to make it composable, there's a lot of challenges, and this is sort of, you know, where we kind of see the next step.

So, again, you kind of have this super highly performant architecture designed for order books, which, you know, works really well, but then you try to like slap on additional primitives like whatever Uniswap is or lending systems, all these other things, and it's very hard to make these two really seamlessly composable at scale, low latency, all these other things, all these other properties that you want, and, you know, eventually you're going to get a lot of problems. So, HyperLiquid might be really good at doing order books, but it's probably not really good at doing all this EVM stuff. And so, basically, you get this scaling HyperLiquid issue where it's like, hmm, well, not only is it very hard to actually like scale all this, but there's a lot of side effects to doing the design that's been done here. The state of the chain explodes, right, that storage system that needs to be sort of in the, basically readable so that's, and in sort of like the hot path so that you can actually verify everything, that explodes. As well, there's sort of execution chaos where you have sort of like one architecture that's maybe app-specific and another one's inefficient, you're trying to blend them, it's very difficult.

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 execution is the endgame, what we're trying to say is basically that if you want to actually bring the world on chain, 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 in a way that might be really application-specific, 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 Fuel is a layer two, and it's mainly focused on high-performance execution, and some of the big things that you could say Fuel does really, really well is we have a very lightweight transaction model that's very easy to verify, and as well, we have a new virtual machine architecture and we have a new language, and these things combined allow us to do highly expansive execution in an environment that can still be verified at home and can still retain a lot of these nice properties that we want from blockchain. So it really brings sort of the best of all different kinds of blockchain design into a single architecture, 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 one or two, you could say. And so in terms of the design targets for metrics, so right now what we're aiming at is trying to get Fuel's current layer two up to around 150,000 TPS, one to four second bridging time as well, one millisecond soft confirmations with co-location, as well as trying to aim for decentralized sequencing, retaining composability in that space, so you could have, say, many hyperliquids, many lending markets, many different things all in the same space, still retaining home verifiability, so reducing this incurred state as much as possible, and then supporting sort of bridging and 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 all this volume that we see in centralized exchanges on chain. And what I would say is 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 basically process transactions in parallel, both in the execution side and in the verification side. It's also a much lighter weight on states, because you can apply all these interesting techniques such that with a layer two, you don't actually need a global state tree, so eliminating Merkle trees is actually a huge reason why Fuel's architecture is so efficient, and as well, for fault proofs, they're really, really good, because you can basically apply all of these different 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 a really robust fault-proofing system, or you can also design very minimally efficient global state tree architecture, if you wanted to go for Validium or you wanted to go for some kind of ZK design. As well, just to highlight for privacy, while we don't focus on privacy right now for the order book product that we are working on, we will use many different mixing levels with ZK mixers, just to ensure that while the trading remains very highly performance, that traders' identities can still be protected.

And the UTXO model is actually fantastic for doing privacy. So in terms of the expansive execution space that we have, the Fuel virtual machine is really key to this, and I'll show you a slide of that next. Basically, because we've redesigned the virtual machine and we've redesigned the transaction model, it gives us a lot more room to work when we process things, so this actually makes things like on-chain order book matching and other things really straightforward. We've recently added soft confirmations, which allows us to get really nice low latency, especially if you're closer to the core builder. And as well, high throughput is basically part of the architecture by default, both from the Fuel VM and as well the UTXO architecture.

So for things like the user experience and for market makers, both of these is really, really, really key. And then as well, because we have things like scripts, composing between different contract architectures is really easy. And then as well, we're fully set up for things like account abstraction, again, playing off of the UTXO model. And as I said before, scripting makes things super straightforward for composing between these different systems. So the Fuel VM actually takes inspiration from a lot of different virtual machines, and there's many reasons why we decided to build our own VM versus just taking something off the shelf.

I would say the most akin VM to it is probably RISC-V, but basically the core principle behind it is we want to design a virtual machine architecture that pairs nicely with the transaction model, gives you expansive throughput, gives you a really rich instruction set, but is actually calibrated for basically the sort of gas metering that we do with blockchains. And when you factor in just gas metering alone, 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 RISC-V is actually a terrible decision, because it's not really built for metering in that sense, and as well, there's just a lot of additional instructions you would want to add anyway, and it would just kind of become a different virtual machine. I mean, you could dump it all into the eCall instruction, but it's not really that great. So the Fuel VM pairs really nicely against the UTXO model, and the UTXO model pairs really nicely against this concept of predicates.

And predicates are sort of these lightweight scripts or accounts that we have, and because of the assumptions around how predicates work, which is something we take from Bitcoin, it ends up allowing us to do 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, a script that operates over those contracts in that transaction, and then many different kinds of outputs. And we avoid this sort of bad problem that Cardano ran into, where they basically used the UTXO model, but they applied too much determinism to how their system works, such that you could only make transactions if you knew all the state changes, and that ends up creating horrible side effects. Fuel works very similar to Ethereum, just with a much more powerful, upgraded 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 we're used to, like trading on Uniswap or whatever, and you don't know every detail, but you're willing to sacrifice it.

So with this model, we can really push throughput into insane levels, and still do so with consumer-level devices. And then Sway is very much like a Rust-like DSL, similar to Noir, actually, but it basically allows you to have a really great developer experience as you're trying to build these kinds of primitives and these kinds of scripts, so it's very, very good at that. And it has all the niceties of Rust, but it also brings in some of the nice concepts that we actually like from Solidity, not all the bad parts, and writing things like an order book or writing things like all the stuff you're familiar with or used to becomes actually really streamlined and really straightforward. 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 ABI and storage from Ethereum, from Solidity, but we've also retained a lot of the Rust paradigms that we like, like traits, such that you have a nice mixture between the syntax and concepts of blockchain, but mixed with all the niceties of Rust. So Sway is actually a super-powerful kind of tool that 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 retaining very, very light state, expansive on-chain execution, developer friendliness, right, with an all-in-one tool chain and things like 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 Fulpers yet, so I know Bartek's in the audience, hi Bartek. But we will make sure we add those, and as well, retaining hyper-liquid like UX. But doing it in a very composable and sustainable way. Something that's practically very unachievable in EVM settings, and is actually very achievable when you re-architect the transaction model in the virtual machine.

And even a note as well on fault-proving and security, if you add a global root over Fuel to make something like a Validium, you can also just make the tree such that it points to UTXO pointers, which are only 8 bytes, and that drastically reduces the size of global trees. So for any of you that have looked into really intense blockchain architecture stuff, you'll know that you can have sort of significant savings in terms of a manageable high-performance blockchain. So in terms of just the kind of future we want to enable, so, you know, order book execution can compose seamlessly with DeFi, scalability doesn't compromise security or decentralization, and as well, developers can build with confidence basically that there's a robust system underneath. And I think that's sort of a part of what we want to do, is bring all of this trading that's going on right now in centralized exchanges, which is very opaque, very subject to all kinds of negative consequences. We want to bring that into our blockchain world with better on-chain execution, better fairness, better properties 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 HyperLiquid, 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 constrain itself to more transparent principles of having things like fault-proving and fault-proving state transitions, etc. 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 verifiable by anybody, both by reading the code, by running it at home. You want to bring that down to the original ideas of blockchain, the original concepts of what we want to do.

I think that's like the ultimate philosophical endgame that you would want to get to. So for Fuel, I really believe Fuel is the execution endgame. It combines a lot of these very important learnings and lessons from every kind of blockchain architecture that's out there, and it brings it into a single cohesive system that, 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 RISC-V, or architectures that quite simply were not really designed to scale given the current climate that we have with blockchain applications. And one last shout-out is, so we are doing a builder residency for Fuel. So it's going to be three weeks, and it's in August in Costa Rica.

If you would like to build on this architecture, build something super high-performance, or high-performance payments app, or say the next HyperLiquid, for example, we'll be down there, resourcing everything as heavily as we can, and just trying to push sort of a new wave of ecosystem for Fuel. So yeah, thanks for listening, and yeah, it was a pleasure, yeah. Thank you, Nick, and we have time for a few questions. Down here. Hey Nick, you mentioned that privacy was not a focus yet, so that dangling yet is intriguing.

Yeah, I mean, I think that, so in order to hit a lot of the targets that we want to hit for execution, basically privacy is quite slow. So if you try to do it with basically any number of different techniques, 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, the UTXO model allows us to be well set up for mixing privacy primitives, because the UTXO model, if you've looked into privacy itself, you'll know that the UTXO model is really actually excellent for these kinds of primitives. So I think that the end state of all this should be something that's both highly scalable and highly private, and as well that you don't need to rely on data availability 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 this execution architecture can handle many hyper liquids of volume in the same kind of continuous composable space, and then from that point we can do a bunch of other interesting things. But I will make sure that we have like tornado-like mixing points across the order book, just to ensure that there's a nice level of privacy for whales and traders on our order book. Yeah. We have time for one more question.

Right up there. Hi. Thanks for the presentation. In order to achieve your goals, do you anticipate any problems or challenges of the networking layer, the peer-to-peer layer? So for example, nodes getting overloaded or needing more smarter architectures or things like that?

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

And the pressures on the peer-to-peer layer are more related to our soft comp system and some of these other things. There will be some challenges there. But I think that if you have peer-to-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, say, like the builder level or fault proving, then that is sort of more on the peer-to-peer layer before the DA is posted.

And then there's another level beyond that, which is sort of the soft comp level, and that's sort of attestations issued by the builders. And those are at sort of the highest level. And in those levels, again, there's a different gradient to security. So a market maker or a trader is fine taking a soft comp attestation, whereas someone who really cares about their money, maybe like a huge whale, they might want to wait all the way down to DA posting. But what's nice about Layer 2s is that Fuel doesn't necessarily need to care about every aspect of this.

It's just more or less that we try to design our system 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. And as well, with a more recent unreleased state design that I have for smart contract state, I think it'll showcase why building with EVMs specifically is completely unsustainable, but when you adopt the UTXO paradigm, smart contracts that work like Ethereum, like Ethereum smart contracts, can actually be fully sustainable 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 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 Dawson from Fuel Labs. Thank you. And next up, we have Philip Chalmers from Gnosis Chain to talk about recent and future hard forks.

So please give it up.