Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Nick Dodson: Fuel Labs – Modular Execution Blockchains

Episode Date: December 17, 2022

As crypto adoption increases, so does the pressing need for blockchain scalability. Monolithic blockchains provide data availability, consensus and execution on a single, base layer, which makes scaling them a difficult endeavour. Multiple layer-2 (L2) scaling solutions have been proposed to address computation and/or data availability, but they reach the same design bottlenecks: limited bandwidth, account state models, sequential transaction processing, etc. Modular blockchains separate the core functionalities, redesigning them as customisable building blocks. This allows for greater flexibility and scalability, adapting blockchain structure to its intended function.We were joined by Nick Dodson, CEO and co-founder of Fuel Labs, to discuss modular execution layers and how they approach different aspects of blockchain design and scalability.Topics covered in this episode:Nick’s background and founding Fuel LabsWhy most blockchain designs are not scalableThe vision behind Fuel Labs’ modular execution layerThe difference between L2 roll-ups and modular execution layersBlockchain design philosophies and integrationsUTXO and multi-thread parallel transactionsUTXO vs. account model systemsFuel Labs’ own virtual machine (VM)Multiple native assets supportDeveloper experience switching to Sway DSLBridging to a settlement layer and interoperabilityBuilding on FuelEpisode links: Fuel LabsFuel Labs on TwitterNick on TwitterSponsors: Omni: Access all of Web3 in one easy-to-use wallet! Earn and manage assets at once with Omni's built-in staking, yield vaults, bridges, swaps and NFT support.https://omni.app/ -This episode is hosted by Friederike Ernst & Sebastien Couture. Show notes and listening options: epicenter.tv/474

Welcome to Episode of the show, which talks about the technologies, projects, and people driving decentralization and the blockchain revolution. I'm Sebast Sincuicicchio and I'm here with my colleague Fredike Ernst. Today we're speaking with Nick Dodson. He's the co-founder and CEO of Fuel Labs. They're building a fast modular execution layer. Before we talk to Nick, though, about Fuel Labs and get into all the details, let me first tell you about our sponsor this week. Omni is your new favorite multi-chain mobile wallet. Omni supports more than 25 protocols so you can manage all your assets in one place across all major EVMs. layer twos, and non-EVMs. But what's really special about Omni is that you can do all the most important things in Web3

directly in the wallet itself. So you want to get yield? Well, Omni allows you to get the best APIs with zero fees and three taps. If it's staking, liquid staking, lending via Ave, or yield via urine, Omni lets you do it. If you need to exchange USTC for ETH on atom or on Cosmos, Omni aggregates all major bridges and dexes so you can bridge and swap across all supported networks in one transaction directly in your wallet. That's pretty cool.

If you love NFTs, Omni offers the broadest NFT support of any wallet so you can connect and manage your favorite NFTs across all chains in one place. Omni is truly the easiest way to use Web3. And most importantly, Omni is fully self-custodial. That's really important, meaning that you never have to trust anyone with your assets other than yourself. If you want, you can even use Omni's ledger integration, which is also a cool feature, so that all your funds stay on your hardware wallet. So join tens of thousands of users on this next generation wallet by download it today on iOS or Android at Omni. Dot app.

Nick, thank you for joining us on this week's episode of WebCenter. Yeah, let's maybe start off by talking about your background. So you were previously at Concessus. I think you were one of the earliest employing. employees there. What was your role and what kind of stuff were you building? Yeah. So, first of all, yeah, thanks for having me. Yeah, consensus, I started initially I didn't think I was early with consensus, although I did find out later on in time that I think it was like number 15 or 16 or something

like that. And initially I was brought in to basically build out some early stage apps on Ethereum. So some of the first apps on Ethereum were, you know, basically really simple things. I think there was one exchange and then there was something I was working on, which was Wayfund and another project called Bordroom. So both those projects were, you know, projects that consensus wanted to, you know, kind of fund and help and grow. So I was working on that with them. And then and then after that, you know, started to work on some libraries and other things, which are still used in things like Metamask and stuff like that. So also wrote a fair bit of infrastructure, did a fair bit of writing.

And, yeah, that would kind of encompass consensus for me, you know, something like that. You then left consensus and you started fuel labs with John Adler. How did you meet and how did you decide to work together? Yeah, so John, I met in the Toronto office of consensus. And initially he came, he came into the office one day and said that he had solved scalability for Ethereum or for, you know, EVM-based blockchains, things like that. And initially, I felt like, who's the crazy guy in the office? So I'd heard so many times this kind of like rhetoric or, I, I, I've heard it so many times that I didn't really pay much attention to it. But after I left consensus and wanted to work on a few different pieces of infrastructure for Ethereum, some wallets, things like that, I started to think about what technology we had available for Ethereum to actually do scaling.

And at the time, there was nothing like Layer 2 or nothing like anything that we have now, ZK, even it was very minimal and basically everyone was focused on payment channels or plasma and those solutions weren't very good and they were pretty subject to a lot of faulty kind of thinking or you know just technology that that wasn't great or wasn't well architected so I sent John a message and said okay you know like what what was the stuff that you were working on and then he basically described optimistic roll-offs to me and it was like a three-hour conversation at a cafe back and forth But it's pretty convinced at that time that this was something, you know, something worth working on, something worth spending some time on. So from that point, then we essentially started fuel right there.

So I was like middle 2019, something like that. Yeah, that's cool. I mean, so fuel is a project that I haven't like followed very much. But I mean, like I'm now much more involved, like saying the cosmos space. And, you know, Celestia has kind of captured the. captured the narrative and like modular blockchains has really captured a lot of the narrative, I think, in that space. I think of Ethereum 2 as well with with Ethereum 2 after the merge now, people are thinking about blockchains in a much more modular way. But yeah, like where does this

all fit together? And you know, in this modular stack of execution, settlement, consensus, and data availability, where does fuel sit and how does it interact with these other? layers. Yeah, so I think to start with that question, I think it starts with just we, like the blockchain systems that we've been building. So initially going from Bitcoin and then going into some of the all coins and then going into Ethereum, you know, we, I think the original designers didn't really know all the exact constraints or how things would actually play out with those architectures. So when you put them together initially, you're not so sure as to how you want. want to construct them. And that's going to create architectural issues. And because of the fact that

blockchains are immutable and they work in a specific way, backwards compatibility is something that is very important to retain. And so this ends up kind of burying you and your decisions a little bit because you can't break backwards compatibility. So the decisions you make early on with the blockchain are the ones that you typically have to stick with for a very long time. And unfortunately for Ethereum, you know, Ethereum made a lot of very interesting and some really good design decisions at the early kind of stage of the project. But unfortunately, just due to its nature and due to the way that the architecture works, there was too many things that were designed sort of not for scale.

And it ended up really hampering Ethereum's ability to kind of get to scale. And I think across the ecosystem, whether it's like Cosmos or any other blockchain, all of them actually suffer from a lot of processing issues that are really related to how much processing you can squeeze out of a node to process transactions. And so we've only really over the past few years actually figured out ways to kind of better utilize the nodes and better utilize processing in a blockchain setting or in a peer-to-peer setting to actually resolve some of these scalability issues. And namely parallel transaction execution for Ethereum is a big one. And there's very few chains that actually try to address that or solve that. And that's just using all the threads and cores of your CPU to actually process transactions. And another one is just that the actual virtual machines themselves that we build smart contracts on or build smart contracts to target are also designed in a way that is very constrained and unfortunately is very, very expensive.

And so the virtual machines we've typically used have not been flexible or not been cognizant of all of the sort of physics of processing that you typically see with blockchains. And blockchains are really weird machines because you need to price every operation. Otherwise, it's easy to bring the chain down. And when you're pricing every operation, this ends up creating a weird sort of physics in the design where, you know, you need to design for pricing of operations, not just necessarily. low-level operations or efficient operations, everything it has to be accounted for in that field. So when it comes to any one of these chains or any blockchain itself, typically you see similar physics play out and you need to design a system that's going to be tailored for that physics or physics. But on top of that, when it comes to blockchains right now, I mean,

there's probably thousands of blockchains out there. I think Cosmos, you know, and that ecosystem has been great in sort of addressing some aspects of blockchain, you know, scale or, you know, basically getting blockchains to global adoption, which is effectively, you know, developing tendermints and these consensus systems. And I think a lot of their work has been extremely beneficial for that setting and as well also allowing other devs to create these sort of, you know, more case-specific chains. I think for Ethereum, it's really just bringing us the ability to do smart contracts and do kind of global settlement, even though the machine is not nice to process and the system is not necessarily a great system for scale. I think with the advent of sort of layer two and how we're approaching execution now, we're sort of addressing that.

And basically, how I see things playing out in terms of the ecosystem, I think app-specific chains are really important. I think they can solve certain case-specific issues with blockchain where you can get some benefits. I think Celestria solves this problem of who's watching the data and where because you get that with, you know, state channel systems and other systems like that where, you know, it comes down to for security that having a single source of data that a bunch of people are using ends up being a lot safer than spreading the data into different silos where it can just vanish. and then you can never actually run or challenge or execute a system in a global, like, peer-to-peer decentralized and fault-tolerant or censorship-resistant way. So Celestia is really trying to address that in a wholehearted way, and I think it does a pretty good job. And then I think as well, Ethereum does a pretty good job of just being a great settlement layer. I think the kind of bandwidth increases we're going to see with like 4844 and stuff like that are going to help a lot.

But in terms of how I see all these things playing out, I mean, it's always really hard to say how the future is going to go. But already I'm starting to see that across the board, you know, we should not be so religious about how we execute things on blockchains because essentially these architectures are still very new and there's a lot of room to grow and improve. And so with fuel, we look to build an execution layer. that can be extremely modular and fit into many of these different settings or be on top of different settings and be configurable in different ways. And so trying to maximize the amount of execution that blockchains can do in general and not trying to be alter a maximalist about like our own system or our own chain, but instead look at all these existing chains and go, well, how could we help someone like Nosis chain

or how could we help someone like a Cosmos chain or Tenderman chain or Ethereum, how how can we help them with their scalability goals, but also bring them a system that's complete from a scaling in DevX perspective and something that I think developers would be really excited to use and that really does address a lot of the scalability issues that we see in the space. So fuel is really trying to tackle execution in DevX

as its core kind of thesis, and we're sort of letting settlement and data availability and things like consensus, you know, be dealt with by other systems. And that's the way I sort of sort of see it. Fuel will have many execution layers settling on Ethereum, probably some with Celestia's data availability, some with Ethereum, and some with no data availability, so like a committee.

And I think that is an appropriate way to solve different projects, scalability needs, while still retaining the Ethereum community and, you know, all the benefits that Ethereum brings to the table. So maybe that gives you some answers. I sort of tried to walk through a bunch of different topics there. So many answers. So many answers. I have even more questions now.

So there's certainly a lot to unpack here. So maybe before we kind of dive into the integrity details about kind of, for instance, how you actually manage to parallelize transaction computation and so on, let's kind of look at the big picture, right? So basically, if you have in the blockchain world, you have different functions that are kind of, that are fulfilled traditionally, all by say, Ethereum. So for instance, you had data availability, consensus, settlement and execution. And basically everything was done by Ethereum. And now after the merge, I mean, basically data availability, this kind of already, there were pretty good integrations even before the merge.

so things like are we, for instance. But after the merge, we now have consensus and execution clients, right? And in principle, they kind of run independent of each other. And then you still have, you know, this extra execution layer on top of everything. And basically that's kind of like the word of L2 is on Ethereum. So fuel did actually start out as an optimistic roll-up on the Ethereum. Well, basically, just that. So what exactly does the pivot to a module execution layer actually entail?

So what is that even? How is it different from an L2 if it then settles to Ethereum anyways? To me, that sounds like exactly the same thing. Yeah, so the distinction we make is that a lot of the layer 2s in the space right now are now really designed for extremely high bandwidth systems. So they're really optimized for a different, like a fundamentally different problem, which is really just trying to fit as many sort of transaction bytes onto Ethereum as possible. And the thing is when you open up the data availability and when you just kind of look at a system

with a lot more data availability like Celestria, you really end up having to design a completely different style of execution system that is not necessarily, you know, one that like an EVM-based system could ever accomplish, which is really trying to give you. full parallel transaction execution and trying to leverage all of that data or as much of that data as possible. So the distinction we make is that modular execution layer is really designed for a high bandwidth system. So it's a distinction from or away from layer two's, even though it can take the form of a layer two specifically and can take the form of like an optimistic role upon Ethereum. It can also take other forms such as like, you know, philidiums or other things

that we've heard kind of discussions around as well. It can also be its own layer one. So it can be configured in many different settings. But the major distinction is that it's designed for a high bandwidth, modular blockchain. And this is really one that you really only see currently with something like Celestia, but you'll probably start to see a little more of with Ethereum as they try to expand their bandwidth.

So we just make a distinction between modular execution. and layer two specifically just because we're trying to leverage all the benefits that modular blockchains give us. And high bandwidth is like a key aspect of that versus like a typical like layer two, which is more optimized than designed for essentially trying to work on Ethereum right now, which is like trying to pack bits and bytes onto Ethereum, which is not necessarily a great optimization once you, you know, actually tried to do, you know, tens of thousands.

of transactions, that's like the least of your worries. Do you think this assessment is going to change if and when we get dank sharding? I don't think so. I mean, I think, you know, for fuel and what we're trying to build, like we're looking to leverage all the data that we can on Ethereum as much as possible, just like any other layers who are optimistic rollout. But at the same time, we're also designing our system for extremely high bandwidth. that's far beyond what I think 484 or Deng sharding or any of these kind of upgrades would entail.

And that amount of data can be significantly larger. So whatever, Celestia is going to pull off and as well, potentially even if we just wanted to run as a side chain, so we didn't want to use data availability of Celestia, we could open the bandwidth significantly. So, you know, you have to sort of plan for, like, a lot of bandwidth and not just necessarily the bandwidth, like, what Ethereum has or what Celestia has. So for us, it's just full parallel transaction execution across the board that allows us to capitalize on all of that. If you're a developer right now, like, you're thinking of building an app, there, you know,

there are any number of ways you could do that and also like several different platforms and programming languages and ecosystems. but looking at it purely from a like stack perspective, what are the consideration one should take into account when choosing to go modular or like you've got this great graph on a blog post where you've got like on one side monolithic centric and then on the other axis or monolithic centric and modular centric on one access and then data availability, consensus settlement, and execution on the other.

And there's like six different ways that one can build on a blockchain. Yeah, what are the considerations that one needs to take into account when like wanting to choose whether to do like sovereign roll up or settlement roll up or like celestialium, which I'm not even really sure what it is or like validity. Right. Yeah. So, I mean, I think the spectrum is always going to be between something like price security and. And that's it. So you're basically in a situation where you're looking at, well, how much does it cost for me to actually deploy and run my system? And then how much security do I actually need from the system? And then finally, likely the case, where do I want assets to be able to settle to or be interoperable with, you know, at the at the sort of end stage, if there is going to be a lot of assets there. And as well, what kind of ecosystems you want exposure to. So with fuel, we don't. we're extremely agnostic to these variables. You can deploy to a fuel execution layer that will be low in price, but potentially, you know, less security.

And then you can deploy to a layer that has a higher price point, but also a higher grade of security. And you can still have the benefits of settling on something like Ethereum and having access to the Ethereum ecosystem via the fact that the bridges will interoperate with Ethereum, you know, very, very easily. But as well, if there's other chains, such as something like Nosis chain or something else like that, where you're going to have execution layers as well, then execution can also happen there, and you can also deploy those systems. Or if it's Cosmos chains or if it's layer ones using a fuel execution layer. So basically you get all the nice benefits and gradients of security, but you also get the guarantee that you can actually get to scale. You can get to the maximum amount of scale we can get out of these systems.

And that, I think, is something you don't get with typical EVM systems, is have they really, at the design stage, maximize the amount of processing and the amount of efficiency that you can get out of the system? And also the kinds of things you can do with the system. So I would just say for a project, you're looking to, to deploy into fuel and you're looking to deploy into kind of this newer ecosystem's newer paradigm of thinking, there'll be a few different executional areas for you to deploy to. And initially with fuel, we'll start with one, but you'll have a gradient of options between

price and security and settlement. And so I think it's giving developers a lot more options and granularity, which is going to be really, really important versus just having them deploy. to some layer one over here or some layer one over there where effectively their app's just going to go and die. And they're not going to have the settlement or interoperability characteristics that I think they would want for their application. Yeah, absolutely. So maybe let's go into the tech stack itself. So fuel as a system has the ability to kind of paralyze transaction computation.

How do you go about this? How do you make sure that you don't touch on the same address? in different parallelized threads. Yeah, so I think the easiest way to break this down is just that when you're processing transactions, you would like to multi-thread. So you'd like to process different chunks of transactions all at the same time. And I think this is like a really key differentiator benefit of systems that have been redesigned or systems like fuel that can do this.

But the core way that we achieve it is through UTI. So basically the UTXO model is what we initially set out to build with our first roll up on Ethereum and, you know, what we still carry through today with our designs. And the UTXO model just allows you to basically notate, okay, these transactions are going to touch these areas of state. And you can just statically analyze the blocks beforehand and you can parallel process them. So this is something that has been a real struggle with EVM-based systems and Ethereum-based systems. And I think there are ways to address it, but because of the way the systems are architected, they're still not really well architected for this reality. And so even the benefits of paralyzing something like the EVM are minimal versus actually

redesigning the system to be inherently designed for this property from the get-go. I think you can see a lot more scale potential. But yeah, the simple answer is that every transaction just notates what it's going to touch and state. And then when you get that notation, you basically say, okay, well, we know these transactions are going to touch this. These transactions are going to touch that. So you can break that up into parallel threads and the parallel processes. And this allows us to retain verification times of the nodes such that, you know, basically nodes can retain something like a two-week sync time, but still, you know, process tens of thousands of transactions, which is very important for just decentralization in general. So you want your sync times to be lower.

So yeah, that's kind of the crux of just our system. And UTXOs allow you to accomplish that by just saying, okay, well, you know, every UTCSO is only spent once. And so every time you spend either, you know, some asset or some contract, you basically just notate, okay, well, I'm going to spend this contract. So I'm going to interact with it. and then you're notating things like the state differentials or the block producers notating those.

And then that's it. It's a very simple way to accomplish it. And the reason why UTXOs are also beneficial here versus just doing an account-style system is that with fuel, we actually don't have, we don't have global state routes and we don't have global account routes. And we don't need to researize those every time we process things. So this is actually a huge benefit when you get into the nuances of just processing blockchain in general. And we can accomplish that because of UTXOs, because we know with

UTXOs that every UTXO cannot be double spent. And so with these inherent guarantees, you can basically start removing a lot of these big chunks of processing that we typically do with Ethereum nodes. So there's significant advantages to using UTXOs without any UX downsides. So essentially you can still accomplish all the same things we do with Ethereum. There's to be no downside or differential there at all for a developer. It's literally all upside. Yeah. Building like a smart contracting platform on UTXOs is a lot more difficult than doing it on an account model though, right? So how much do you actually have to what do you actually have to pay for gaining all this upside? So I would argue that I mean if you use fuel right now even with our

current SDKs, you'll notice that it's no harder to use it than just use Ethereum. It's actually... Oh, yeah, yeah. Nick, I'm not... I'm not talking about the dev. I'm talking about the stack itself. So basically the cool protocol. Right. Yeah, I mean, basically with UTXOs, you're going to pay a little more on the data side, most likely, just because you're notating more stuff. However, if you wanted to accomplish parallel transaction execution with a standard model of just metadata, you'd still end up paying similar fees anyway. So the if we're talking about just what the downside of using UTXOs is, there's not many.

It would literally just be that there's a little more data, but again, the positive upsides are enormous. There's no global state tree, no global accounts route, and these things get removed pretty quickly. So again, that just means that transactions are going to be cheaper, and you're going to be able to process a lot more of them on a normal machine. Does that answer your question? Yeah, kind of.

So maybe let me kind of refresh. this. So, I mean, most early blockchains were UTXO based, right? So basically, UTXO was the norm. Why did Ethereum opt for an account-based balance model? And do you think if it were to be redesigned today or relaunch today, that would change? Yeah. So I think the core design behind just doing the accounts model was just that it was simpler and it was easier to reason about and manage. and I think over time we learned, at least with processing, that these accounts models are actually pretty horrible to parallel process if you're continuing to mercilize every single account and have a route for every single block. So I think the original design decision was just that it was simpler and it was easier to reason about.

And the thing is, that's a totally reasonable decision to make at the early stages of Ethereum. However, I think given everything we know now and given how the UTXO systems work and how even current modern blockchains work, so if you look at Salonnas design or Aptos and, you know, sui design, basically we don't necessarily need to do it that way. Or if you do it that way, you basically lose something else, which is you either lose like clients or you lose sort of processing benefits that you would get. with UTXOs, and I think UTXOs give you really the best results. So I think of Ethereum was redesigned today, I think the UTXO model is still better in pretty much every way. Yeah, I think they would use UTXOs, as put it that way. And by the I mean, just Vitalik and Gavin, yeah.

Oh, I struggle to see Vitalik and Gavin get back together, but yeah. I don't think so. Fuel also has its own virtual machine. that is distinctly different from the EVM. How is that so? Yeah, so basically, like, we didn't, with fuel, we didn't want to do any of this. To start, like, this whole project,

and a lot of it has been us basically going through the current state of the art architectures and just kind of the available architectures we have around us. And really looking at what that is and how that works and going, okay, well, like, what do we, what do we have available? And unfortunately, you know, going through the way the EVM processes,

the way that Salana and these other chains process and trying to look at the properties that we wanted to achieve, we kind of realized that doing our own VM would still give us the absolute best results for the developer and for blockchain in general for the ecosystem. It would make the largest contributions to the ecosystem that we can make and be most beneficial. And so the fuel VM is really, it takes lessons primarily from the EVM, but it also takes lessons from Salana and MoveChains, Wazam, Mips, and some of those other architectures, and basically tries to give you a blockchain virtual machine that is as close as we can realize to the kind of best blockchain virtual machine we can design as of today. And the properties that we're aiming for

there are essentially, you know, this physic of having to price every operation. That's a one. Another one is retaining light clients and another one is fraud-proofability. So building a virtual machine that's actually easy to fraud-proof on things like Ethereum or things like Salana. So these are actually all key properties, some of which are brand new that didn't exist before, that we wanted to incorporate into this virtual machine. And so inherently, you know, that comes with the uphill battle of saying, well, we have to convince all these debts to use it. However, the architecture really speaks for itself and I'd say that devs that use it probably don't want to go back to anything else. And as well, they can see that because of the way that it's designed, it can exist in so many different places.

So it can exist on different chains and in different settings as layer two's, as layer ones. It can really be an architecture we can use for blockchain for, you know, many decades from now versus just trying to inch along existing architectures but dealing with backwards compatibility issues. And also, you know, using other run times that are fine, but they're not necessarily designed for like clients. And if you try to make them like client friendly, these designs would fall apart. Like they would basically lose a lot of their processing benefits. So the designs we picked are inherently for trying to give the blockchain community the best possible virtual machine we can think of. And build that in a modular way that's extremely reusable for everyone. So that's kind of the motivations.

So for a developer that, like a Sology developer that's used to building on EVM or let's say a Cosmwasm developer that's building on Cosmwasum with Rust, what are they going to be the main differences for like those two developer kind of backgrounds and what are they going to have to learn in order to use this VM? Yeah, so the Ethereum devs will have the easiest time porting all their ideas over. It's very similar. It works in very similar ways to the EVM, and we carry over a lot of the benefits of things like the state API or storage API and some of the ways of the EVM thinks about things.

To a WASM dev or someone running on like, you know, a low-level runtime, time, it's basically going to be a little different in the sense that the VM itself has some key op codes for things like managing fungible coins through our UTXO system, and probably some other little key differences like certain op codes we've added that are beneficial, super beneficial for doing resource-constrained processing, which blockchains are resource-constrained, But that actually have huge benefits because they're kind of like compound operations. So like a dynamic mem copy, for example, is something that like Ethereum desperately needs, and I hope eventually it will get.

But these kinds of operations are things that, you know, we've added into the virtual machine. But basically, the virtual machine itself has some really key differences from the eBM, such as the fact that it's 64-bit, not 256. It uses registers instead of a stack system. It has a different memory model. Our call model works in some similar ways, but in other ways can give you significant benefits because we have things like a shared global memory context. And so these little key differences end up being really, really helpful.

And you see Ethereum devs all the time trying to solve all these weird problems that only come up because of the shortcomings of the EVM. And really the right way to fix those things would just be to redesign the system and do something different and not and ignore backwards compatibility. So just from an engineering perspective, we get to benefit from just saying, well, we'll bring over everything we like for all these systems and ignore backwards compatibility and just give you the best system we can possibly think of today. So that's kind of the way I would describe it or think about it.

So you also say that you support multiple native assets. How is that different from Ethereum? and what do you pay gas in and who determines what you pay gas in? Yeah, so on the front of multiple native assets, so essentially our system and our machine is designed inherently to support basically treating native assets, more assets that people create like native assets. So in Ethereum, we only have one native asset, which is just ether.

And unfortunately, ether is the only one that gets really the benefit of low-level kind of client's optimizations and things like that. So when you create tokens on Ethereum, you have to do them at the application or smart contract level. And that really hampers the amount of scale you can create or the scale you can, you can kind of access because you're always kind of going back to the smart contracts and affecting its state and re-serializing it. And it actually hampers a lot of the processing. So on our side, we basically say, okay, well, any token can be a native asset. So it can spit out this own kind of, you know, token that can be and live in the UTXO system. And when you have that,

it just allows you to do significantly more processing over the tokens because each token becomes kind of an atomic bundle that can go out of a contract and come back into a contract. And so when you have that, you get significant processing benefit, which means just like way lower cost. Really on the state level, you're just doing one state right and that's it. And again, there's no re-serilization and these sorts of things that we see with current blockchains. It literally is just affecting one state right. And so this just means cheaper transactions. It means cheaper transactions for, you know, whether you're doing these like payments use cases or if you're just doing a lot of transacting in general, it gives you all of this massive upside.

And it allows developers to tap into the native asset system. And that's like a huge, huge benefit. It's something that Ethereum really desperately lacks because every token, you just end up creating an EOC20. And unfortunately, that's pretty hard to scale when you really try to get into the crux of it. So that's one side of it. In terms of fees, so the chains that will settle on Ethereum will all have fees in ETH. So like we're pretty ETH maxi in that sense. And there's crypto economic reasons for this,

but it's also just that I think for us, like we look at fuel and what fuel is as a system, again, to help scale these other systems. And so, you know, if we're deploying, you know, these execution layers on Ethereum, it's likely the case that ETH will be the fee. However, you will be able to have things like private mempools and be able to accept, you know, fees and, you know, fees and die or USC or these sorts of things as well, whatever the block producers want to want to accept. But in general, right now, our current plan is just to use ETH as the fees. What's the learning curve for like on the like so, so solidity is kind of inspired by JavaScript and right. You know, like what, what is it, but does the language actually look like?

Is it sort of similar to solidity in this sense or? Yeah. So, so sway, or. So, so sway are, our DSL really looks like, it looks a lot like rust. So that would be the, that would be the best way to describe it is looking like rust. It inherits a lot of nice things from solidity. It inherits a lot of nice things from, you know, some of these other kind of languages that we see in the space, but the predominant inspiration is still rust. And for dev coming from Ethereum, I'd say the learning curve is pretty low. Most solidity devs can take a look at sway and learn it and like,

a day or two. It's really, in fact, even a few hours, probably maximum. Because the language is a blockchain-specific language or it's designed to target blockchains, it's not like learning rust off the bat or these other systems languages. You're really getting a language that's, you know, very familiarized with all these concepts and, you know, things that we typically do with blockchains. So a dev will feel very at home kind of using sway. And I think currently we see that. Most devs that come over, especially from Ethereum, they don't want to leave and even move devs really prefer it. So we've already started to sway pill a bunch of move devs as well. And then in terms of in terms of Solana and what their experience is like, you know, basically

they're more in the Rust category and they're using Rust to target a lot of things. However, again, using a systems language to target a blockchain, as we've learned. is a horrible experience, and even that goes for WASM as well. And so with SWAY, we really try to patch that up and say, can we give developers an incredible sort of blockchain development experience that feels like they have full control over the system and feels like the compiler is really designed for actually targeting blockchains. And in this case, specifically the fuel VM,

but Sway will also be able to target things like the EVM in the future as well. How is fuel connected to the Ethereum or whatever the settlement layer is? Yeah, so the bridge that we have that we also recently released in beta 2 or a recent test network is very similar to optimism, you could say. So there's a lot of inherited properties there to optimism, some inspiration from arbitram as well. So it's a generic like arbitrary message passing bridge, but you can basically bridge anything. You can bridge everything from ERC20s to 721s.

You can do all sorts of arbitrary messaging in and out of the system. And basically fuel gives you full settlements and the properties that you're looking for as a dev to settle on something like Ethereum. But for any kind of token. So for example, if you wanted to create an NFT on fuel, have it massively scalable, mint, millions of them, and then have some of them be able to come back onto Ethereum and settle, you could do that. You can also just take USC and dye in these other things, put them over the bridge, and they become native assets in fuel and can benefit from our UTXO system. So essentially, we get to fully interoperate with Ethereum liquidity, and that goes for NFTs and for fungible tokens.

So that would be the best way I'd describe it. Okay. And what about the nodes that actually run fuel? So who runs those? Yeah. So currently we're starting out with a single sequencer model, so similar to arbitram and optimism, you know, with some fallbacks. That's mainly just to get everything set up and to allow devs to actually get to production.

After that point, though, we will actually look to decentralized block production. And this is like a key piece of architecture. And in decentralizing block production, what we mean is being able to have, have many different block producers, not a single sequencer, but you still get to benefit from all of the nice upsides of things like layer twos and optimistic roll-ups. So you get essentially like a decentralized sequencer, you could say. And the way that we accomplish that is really through a tendermint like system. However, you get all the upsides of tendament and not the downsides, which is that the security of the system is typically taken care of by Ethereum itself and data availability,

being secured on something like Ethereum or something like Celestia. So you basically get to do everything you really want with a blockchain. You get to have all the nice properties that you're looking for. And you don't really have very many downsides. So that's that's kind of where we're headed with that. I want to take a step back a little bit here. And we talked about bridging just previously here. What does bridging look like in a modular stack?

ecosystem or application. Does bridging happen at the application layer, at the execution layer, or does it happen at lower layers in the stack? And the other question I have was, you know, more broadly, I think that one of the biggest challenges right now is creating trustless or trust-minimized bridging standards across different ecosystems. So the Ethereum, EVM ecosystem has solutions for bridging across EVM chains. Pocodot has also their own protocol. Cosmos has their own protocol. I'm not quite sure what's happening sort of like in Solana and other ecosystems.

I think probably Avalanche also has like, I think they do have a bridging protocol that leverages SGX. You know, as these chains become more modular and, you know, some might be using the EVM execution and others might be using like, was them, but they're all using, they're all sharing data availability and maybe sharing consensus or sharing some other layer. How do we reason about creating standards here that allows these chains that are operating? Does the modular stack facilitate this intravability? Yeah. So I think with bridging, you have, you have a few different kinds of bridging here. So one being just bridging that, you know, we typically see with just having an execution layer bridge to something like Ethereum. So, you know, a bridge.

that we've seen with arbitram or optimism that kind of set up. And those bridges are more about, I would say, settlements. And as well, we use them for different aspects of like block production and posting headers and things like that. There's other bridges, though, that you want some key properties if you really want to achieve trust-minimized bridging. So some nice properties that you get with modular blockchains or with blockchains or execution layers that share the same data availability is that each execution layer can

introspect each other. So basically, you can introspect from one layer, you can say, what is the headers and the state of this other layer? And if you can do that, you can create these trust-minimimized bridges where essentially instead of having like a multi-sing on both sides, you can actually have just smart contracts on both sides of the bridge. And so let's say you bridging from one fuel instance to another fuel instance on Ethereum. Because both of these layers have the same data availability and they have the same, you know, headers or they have an easy to introspect, you know, block header system, you can basically create a trust-minimized bridge between the two of them.

And it's trust-minimized because you're not really relying on necessarily things like multi-sigs on both sides. And so this gives you some huge benefits when you're actually moving and bridging liquidity between these execution systems. So that would be one way to describe it. If you're building execution systems on Celestia, it would be the same. So, you know, you basically, you share data availability. And so, you know, one execution there can actually introspect the other. And that's like a very key property with trust minimized bridges that I think will be a huge.

game-changing sort of factor for why you would want to pick a modular blockchain versus just picking these layer ones because we've already seen so many bridges fail with multi-sigs that really if we're going to continue to build newer blockchains you're going to want these properties in your blockchains so that you can actually interoperate all the liquidity. It also works well for upgradeability when you're doing a new execution layer and you want to move things over. You can also, you know, move you can introspect the previous state. you can also move assets and liquidity over.

So some really key properties there that are really nice. For chains that are applications that are using different data availability layer, and I guess that's kind of like the bottom layer in the stack, are we going to need like interoperability between data availability, like Ethereum data availability and Celestia and I don't know, like what other data availability layer? Is that really where like if the ecosystem starts moving towards as more modular stack and there are kind of,

of data availability monoliths. Right. Are we going to need to have like some bridging between these data availability layers or can they validate each other? Yeah, I mean, ideally you would want them to interoperate, but then you have basically potentially different different layer ones trying to interoperate with each other.

So you're still going to inherit the same sort of failure of properties of sort of typical bridges between layer ones. So I would say that the real benefit comes from bridges between execution layers on the same layer one is going to be the best possible thing you can do. So if systems like arbitralorpe and autism actually had better to centralized sequencing, then you could have a lot of nice guarantees between bridging between those execution layers and something like fuel if it was deployed tomorrow on Ethereum, because Ethereum would be the shared data availability and execution layer in that case.

And so I would just say that, yeah, you still have the same failure points if the, if essentially they're separate layer ones. Yeah. So still the same problem. How does this translate into ecosystem? So there's currently only a test net out. But who are the people building on fuel? Yeah. So right now I'd say we have like a small kind of following of projects. Our current philosophy with fuel is that we really don't need thousands of projects to build on fuel. We need only like 10 good ones. So for us, like we don't care about having 500 NFT rug bull projects on our system. It's not really anything we need or care about or that benefits anybody. The projects that we currently have building on fuel, we have a few

dexes, a few NFT systems, and then a few lending systems. And I would say that, that the key differentiating things about them are going to be that they can leverage sort of things like fuels account abstraction or they can leverage like paralyization. They can leverage some unique properties about the fuel VM or about sway, about having a significantly larger amount of memory available at computation time. And just like all these little key details will allow them to create a highly differentiated product from or system than what you typically see with ebm systems but it'll still be accessible to people with things like metamass wallets and ethereum volume so that's really the best part is the

accessibility is still with ethereum and all that sort of stuff it's just all that underlying architecture allows you to do way more um so that would be the way that i would describe it um like some some notable names are like gilix and pool sharks and uh and eunuch as well And I'd say a lot of the projects that are building on fuel are far more ideologically or philosophically aligned to, I think, the values of building these kinds of centralized systems and building something that is actually fundamentally unique and not something that is just going to be another like, I don't know, just another project or a copycat project. Cool. So what's the roadmap look like? So when Maynard? I'm sort of hesitant to give a date from Mainnet, but I'll preliminarily say that there's two test nets until something will happen.

So we just need to do about two more test nets. And then I would say that we're in a pretty good space to be actually going to Mainnet. And, you know, I would say it'll be probably another two quarter or something like that if I were to guess. but that would be my somewhat alpha drop there. However, I will say that with fuel itself, like everything you would want to build, you can build right now over the test nets. So everything's still being kind of scaffolded and put together,

but you can basically build anything that you would want right now anyway. So don't hesitate to actually start investigating fuel and building stuff with it, yeah, if you're a project. So where can people come and find out more about fuel and get started? Yeah, so you can just start with fuel.network. So everything's available to that. That's where you can find all of our docs. And basically, we've got a ton of, like, you know, great tutorials, guides, etc.

We're always looking to improve the docs. So that's like an ongoing thing. The docs are excellent. I went through them. Yeah, they are excellent. And I took several notes for our own docs. So yeah. Amazing.

Yeah. I mean, we still, there's still even more we can do. So it's, we'll continue to increase the docs and as well, just everything across the board. So we're in taking as much feedback as we can from devs because we have a unique opportunity here to build a system that I think devs actually would really like to use. And that gives them everything they need. So like that that's going to be very key for us. And it allows us to differentiate in a big. way from existing tool chains that have had to sort of learn the hard way how to build a lot of

this stuff. Cool. Fantastic. I'm excited to see how this will go and how long the two test nets will take and to see this in action. Awesome. Thank you, Nick. Thank you for joining us on this week's episode.

We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, guests or other podcast listeners, you can follow us on Twitter. And please leave us a

review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.