Nick Dodson: Fuel Labs – Modular Execution Blockchains #474

Transcript

welcome to episode of the show which talks about the Technologies projects and people driving decentralization and the blockchain revolution I'm Sebastian cuccio and I'm here with my colleague Freda Ernst today we're speaking with Nick Dodson he's the co-founder of CEO 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 evns 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 only 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 usdc 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 uh so that all your funds stay on your Hardware wallet so join tenth and tens of thousands of users on this next Generation wallet by downloading today on iOS or Android at omni.app Nick thank you for joining us uh on this week's episode of epcenter um yeah uh let's maybe start off by talking about your background so you were previously accepted I think you were one of the earliest employees there um what was your role and uh what kind of stuff were you building

yeah so um first of all yeah thanks thanks for for having me um yeah consensus uh I started initially I didn't think I was early with consensus although I did find out later on in time that um I think it was like number 15 or 16 or something like that um 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 uh you know basically really simple things I think there was one exchange and then there was something I was working on which was way fun and another project called boardroom um so both those projects were

um you know projects that consensus wanted to um you know kind of fund and help and and grow um so so I was working working on that uh with them and then uh and then after that um you know started to work on some libraries and other things um which are still used in you know things like metamask and stuff like that so um also wrote a fair bit of infrastructure did a fair bit of writing um and yeah that would kind of Encompass consensus uh for me um you know something like that he then left consensus and you started fewer Labs with uh John Adler um how did you meet and how did you

decide to work together yeah so John I met in the Toronto office of consensus and um 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 um initially I felt like um who's the crazy guy in the office so I'd heard so many times um this kind of like rhetoric or I I've just heard I've heard it so many times that I didn't really uh pay much attention to it but um you know after I left consensus and you know wanted to work on a few

different pieces of infrastructure um for ethereum some wallets things like that I started to think about what technology we had available for ethereum to actually you know do scaling and at the time there was nothing like Layer Two or nothing like um in anything that we have now Z ZK even it was very minimal um and uh 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 wasn't great it wasn't well architected so I 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-Ups to me um and it was like a three-hour conversation in the cafe back and forth but I was pretty convinced at that time that this was something um you know something worth working on something worth spending some time on uh so from that point then we we essentially started fuel um right there so I was like middle 2019 something like that yep yeah that's cool uh I mean so fuel is a project that I haven't like followed very much but I mean like I I'm now much more involved by saying the cosmo 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 two as well with uh with ethereum two after the merge now people are thinking about blockchain's in a much more modular way um 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 uh how does it interact with these other layers yeah so I think to start with that question um I think it starts with just we like the the blockchain systems that we've been building so so initially going from Bitcoin and then

going into some of the 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 to construct them and that's going to create architectural issues and because of you know the fact that blockchains are immutable and they 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 in 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 um you know ethereum made a lot of um very interesting and some really good design decisions at the early kind of you know stage of the project but unfortunately just due to its nature and due to the way that the architecture Works um there was too many things that were designed uh sort of not for scale um 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 a node to process

transactions and so um 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 and namely parallel transaction execution for ethereum is a big one um 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 um 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 physic in the design where you know you need to design for pricing of operations not just necessarily low level operations or efficient operations everything that has to be accounted for in that in that field so when it comes to any one of these chains or any 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 physic 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 and that ecosystem has been great in sort of addressing some aspects of blockchain you know scale or or you know basically getting blockchains to Global adoption which is effectively you know developing tendermens and these consensus systems and and I think a lot of their work has been extremely beneficial for 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 to do smart contracts and do kind of global settlements even though the machine is is not nice to process and the system is not necessarily a great system for scale um you know I think with the Advent of sort of layer 2 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 um I think they can solve certain case specific issues with blockchain where you can get some benefits I think Celestia 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 like fault tolerant or censorship resistant way so Celestia is really trying to address that in a wholehearted way and I think I think it does a pretty good job and then I think as well ethereum does a pretty good job just being a

great settlement layer I think the um kind of bandwidth increases we're going to see with like 4844 and stuff like that are gonna are gonna 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 um 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 ultra 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 gnosis chain or how can we help someone like a cosmos chain or tenement chain or ethereum how can we help them with their scalability goals but also bring them a system that's complete from a scaling and devex 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 and devex as it's like core kind of thesis and we're sort of letting settlement and data availability and things like consensus um you know be dealt with by other systems and that's the way I sort of sort of see it um fuel will will have many execution layers settling on ethereum probably some with Celestia's data availability some with ethereum uh and some with no data availability so like a committee um and uh I think 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 ideas I have even more questions now so there's there's certainly a lot to unpack here so maybe um before we kind of dive into the nitty-gritty details about kind of for instance how you actually manage to parallelize transaction computation and so on let's kind of look at the at the big picture right so basically if you have if you have um in the blockchain world you have different functions that are kind of um uh that are fulfilled traditionally

um or by say ethereum so for instance you you had data availability consensus settlement and execution and basically everything was done by by uh by ethereum and now after the merge I mean basically data availability this kind of already um uh there were pretty good Integrations uh even before the merge so things like are we for instance um but uh after the merge we now have consensus and execution clients right and in principle they kind of run independent of each other um and then uh you still have you know this extra execution layer on top of everything and basically that's kind of like the word of L tools on ethereum so

and I mean um fewer did actually start out as an optimistic roll up on the ethereum well basically just that um so how what exactly does the pivot to a module execution layer actually entail so what what what is that even how is it different from an edge who 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 twos in the in the space right now are not really designed for extremely high bandwidth um 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 Celestia you really end up having to design a completely different style of execution system that is not necessarily you know one that like an ebm based system could ever accomplish which is really trying to give you full like parallel transaction execution and trying to leverage all of that that data or as much of that data as possible so the distinction we make is that a module execution layer is really designed for a high bandwidth system so it's a distinction uh from or away from layer twos even though it can take the form of

a layer two specifically and can take the form of like an optimistic roll upon ethereum it can also take other forms such as like you know pallidiums or other things that you know we've 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 you know 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 um their bandwidth so we just make a distinction between modular execution um and and Layer Two specifically just

because we're trying to we're trying to leverage all the benefits that modular blockchains give us and high bandwidth is like a like a key aspect of that um versus like a typical like Layer Two which is more optimized and 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 try to do you know tens of thousands of transactions that's like the least of your worries yeah do you think this is this assessment is going to change when we get if and when we get dank sharding um I don't think so I mean I think

um you know for fuel and what we're trying to 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 grow up but at the same time we're also designing our system for extremely high bandwidth that's far beyond what I think 4844 or or dank sharding or or any of these um kind of upgrades would would entail um and that amount of data can be significantly larger so um 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 on Celestia we could open the bandwidth significantly so

you know you have to sort of plan for like a a lot of bandwidth and not just necessarily the bandwidth of like what ethereum has or what Celestia has so for us it's this full parallel transaction execution across the board that allows us to capitalize on all of that yeah if you're a developer right now and like you're you're thinking of building an app um there you know there is any number of ways you could do that uh and also like several different platforms and programming languages and ecosystems but looking at looking at it purely from a like stacked perspective uh what what are the consideration when should uh take into account when choosing

to go modular or like you've got this great graph on uh on a blog post where you've got like on one side monolithic Centric and and then uh on the other axis our monolithic Centric and modular Centric on one access and then you know data availability consensus settlement and execution on the other and there's like you know six different ways that one can build you know on a blockchain um 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 celestium which I'm not even really sure what it is or like validium or right yeah so I mean I think the spectrum is always going to be between

something like price security and and and that's it so you're you're basically in a situation where you're 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 this system and 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 these 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 uh 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 um and having access to the ethereum ecosystem via the fact that the the bridges will interoperate with ethereum you know very very easily but as well if there's other chains um such as something like noses chain or something else like that where you're going to have execution layers as well um then you know execution can can also happen there and you can also deploy to those systems um and so 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 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 um I would just say for a project you're looking to deploy into Fuel and you're looking to deploy into kind of this newer ecosystems newer Paradigm of thinking

um there'll be a few different execution labs 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 deployed 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 um you know characteristics that I think they would want for their application yeah yeah absolutely so um maybe let's go into the into the tech stack itself so

um fuel um as a system has the ability to kind of paralyze um transaction computation how do you go about this how do you make sure that you don't touch on the same addresses uh in different uh 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 um 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 utxos so basically the utxo model is what we initially set out to build with 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 um 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 uh 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 from the get-go I think you can you can see a lot more scale uh potential um but yeah the simple 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 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 a parallel process it and this allows us to retain verification times verification times of the node 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 um so you you want your sync times to be lower um so yeah that's kind of the the Crux of of just our system and and utxos allow you to accomplish that by just saying okay well you know every utxo 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 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 utxas are also beneficial here versus just doing an account style system is that with fuel we actually don't have um we don't have Global State routes and we don't have Global account account routes and we don't need to re-serialize those every time we process things so this is actually a huge benefit when you get into the nuances of just processing um blockchains in general um 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 um building like a smart Contracting platform on utxos is a lot more difficult than doing it on an account model though right so what how much do you actually have to what do we 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 with our car and sdks you'll notice that it it's

it's no harder to use it than it is to use ethereum it's it's actually oh yeah yeah Nick I'm not I'm not I'm not talking about the the dev I'm talking about the stack itself so basically the the cool protocol right yeah I mean basically with utxos you're going to pay a little more on the data side um most likely just because you're notating more stuff however if you wanted to accomplish parallels with accent 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 um there's not many it would literally just be that there's a little more data um but again the positive upsides are

enormous there's no Global state tree no Global accounts root um 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 on a normal machine um is that does that answer your question yeah kind of so so maybe that may let me kind of reframe this so um I mean most early blockchains were utxo based right so basically utxo was the norm um why did ethereum opt for an account based uh balance model um and do you think if it were to be redesigned today or relaunched 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 um and I think over time we learned at least with processing that these accounts models are actually pretty horrible to parallel process uh if you're continuing to miracleize every single account um and have a route for for every single block so I think the original design decision was just that it was simpler and it was easier to reason about um the and the thing is is like you know 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 and how even current modern blockchains work so if you look at Solana's design or Aptos and you know so we design um basically we we don't necessarily need to do it that way um or if you do it that way you basically lose something else which is you either lose like clients or um you lose uh 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 utxl model is still better um in pretty much every way yeah I think

they would use utxos let's put it that way and by the I mean just vitalik and Gavin yeah oh I I struggled to see vitalik and Gavin get back together but uh yeah I don't think so fuel also has its own virtual machine and that is distinctly different from the evm um 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 um unfortunately you know going through the way the evm processes the way that Solana and these other chains process and and trying to look at the properties that we wanted to achieve um we kind of realized that uh 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 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 Solana move chains quasim 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 um and the properties that we're aiming for there are essentially you know this physic of having to price every operation that's a key one another one is retaining uh like clients and another one is fraud probabilities so building a virtual machine that's actually easy to fraud prove on things like ethereum or things like Solana 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 um and so inherently um you know that that comes with the uphill battle of saying well we have to convince all these deaths 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 twos 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 runtimes that are fine but they're not necessarily designed for like clients and if you tried 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 so for a you know a developer that like a zoology developer that's used to building on evm or let's say a

cosmoplasm developer that's building on Cosmos and with rust uh what are going to be the main differences uh for for like those two uh developer kind of backgrounds and um what are they going to have to learn in order to use this VM yeah so the ethereum devs will have the easiest time um 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 and some of the ways of the evm thinks about things um to a wasendev uh or someone running on

like you know a low-level runtime um it's basically going to be a little different in the sense that um the VM itself has some key op codes for things like managing uh fungible coins uh through our utxo system um and probably some other little key differences like certain op codes we've added that are beneficial super beneficial for doing resource constraint processing which blockchains are resource constrained um but that actually have huge benefits because um 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 um but uh these kinds of operations are

things that um you know we've added into the virtual machine but basically the virtual machine itself has some really key differences from the evm such as the fact that it's 64-bit and 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 share Global memory context and so these little key differences end up being really really helpful um 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 to redesign the system and do something different and not and ignore backwards compatibility um so just from an engineering perspective we get to benefit from just saying well we'll bring over everything we like from all these systems and ignore backwards compatibility and just give you the best system we can possibly think of like today so that's kind of the way way I would describe it or think about it so you also say that um you support multiple native assets how's that different from ethereum and who what do you pay gas in and who determines what you pay gas in yeah so on the front of multiple native assets so so essentially our system and our machine is designed inherently to

support basically treating native assets uh more assets that people create like native assets so an ethereum we only have one native asset which is just ether and unfortunately ether's the only one that gets really the benefit of low-level kind of clients 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 contract and affecting its state and re-serializing it and actually hampers a lot of the the processing so so on our side

um we we basically say okay well any token can be a native asset so it can spit out this own kind of um 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 um you you get significant processing benefit which means just it's like way lower cost um really on the the state level you're just doing one state right and that's it um and again there's no re-serialization and and these sorts of things that we see with uh current blockchains uh it

literally is just affecting one state right um and so this just means cheaper transactions uh 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 this so massive upside um and it allows developers to tap into the native asset system um and that's like a huge huge benefit uh 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 so that's one side of it in terms of fees so the chains that will settle on ethereum will all have fees uh in each

so like we're pretty uh eath Maxi in that sense um and this crypto economic reasons for this but it's also just that I think um for us like we look at Fuel and what fuel is as a system again to help scale these other systems um and so you know if we're deploying uh you know these these execution layers on on ethereum it's likely the case that eth will be the the fee however you will be able to have things like private mempools and be able to accept you know fees and die or usdc or or these sorts of things as well whatever the block producers want to want to accept um but in general right now our our current plan is just to use eth as the as the fees yeah

what's the learning curve for uh like on the uh like so you know solidity is kind of inspired by JavaScript and right 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 our DSL really looks like it looks a lot like rust so that would be the that'd be the best way to describe it uh is looking like rust um it inherits a lot of nice things from solidity it inherits a lot of nice things from um you know some of these other kind of languages that we see in space but the predominant inspiration is still rust um and for Dev coming from ethereum I'd

say the learning curve is pretty low uh most solidity devs can take a look at Sway and learn it in like a day or two it's really in fact even a few hours probably maximum um 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 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 like most devs that come over especially from ethereum they don't want to leave and even move devs really prefer it

um 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 they're more on 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 um that we also recently released in beta 2 are a recent test network is some very similar to optimism you could say it's just a lot of inherited properties there to optimism some inspiration from arbitrim as well um so it's a generic like arbitrary message passing bridge but you can basically Bridge anything uh you can Bridge everything from uh erc20s to 720 ones you can do all sorts of arbitrary messaging in and out of the system and basically fuel you know gives you full

settlements and you know the the properties that you're looking for as a Dev to settle on something like ethereum um but for any kind of token so for example if you wanted to create an nft on on fuel have it massively scalable mint you know 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 usdc and die and these other things put them over the bridge and they become native assets uh in fuel and can benefit from our utxo system so essentially we get to fully interoperate with ethereum liquidity and um and you know and that goes for

for nfts and for fundable tokens um so that'd be the best way to describe it yeah okay and what about the notes that actually run fuel so who runs those So currently we're starting out with a single sequencer or a model so similar to arbitrary and optimism um you know with some some fallbacks that's mainly just to get everything set up and and to allow devs to actually get to production um after that point though um we will actually look to decentralize block production and um this is like a key piece of architecture and in decentralizing Block production what we mean is is being able to 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 rollups so you get a essentially like a decentralized sequencer you could say um and the way that we accomplish that is really through a tenement-like system however you get all the upsides of tenement and not the downsides which is that the security of the system is typically taken care of by ethereum itself and data availability being secure and on something like ethereum or something like Celestia so um you basically get to do everything you really want with a 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 yeah I want to take a step back a little bit here and and uh we talked about bridging just briefly previously here um what is that what what does bridging look like uh in a modular stack ecosystem or uh application uh 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 had was you know more broadly I I think that um one of the biggest challenges right now is uh creating trustless or trust minimized bridging standards across

different ecosystems so you know right you know the the ethereum evm ecosystem has solutions for bridging uh across evm chains um you know polka dot has also their own protocol uh 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 uh I think they do have a bridging protocol that leverages STX uh you know as as these chains become more modular and you know some might be using the evm execution and others might be using like I don't know wasm but they're all using like they're all sharing data availability and maybe sharing consensus or sharing some other layer

um how do we reason about creating standards here that allows These Chains to operate and does the modular stack facilitate this interoperability yeah so I 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 you know Arboretum or optimism that kind of set up um and those bridges are are more about I would say settlements and and as well we we use them for for different aspects of like block production and posting headers and things like that there's other Bridges though that you want

um 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 minimized 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 of the bridge and so let's say you were 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 um you know uh headers or they have any easy to introspect um 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 that would be one way to describe it if you're building execution systems on on Celestia it would be the

same so you know you basically you share data availability and so you know one execution layer can actually introspect the other um 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 you know really if we're going to continue to build new newer blockchains you're going to want these properties in your blockchains um so that you can actually interoperate all the liquidity it also works well for upgradability when you're doing a new execution layer

and you want to move things over you can also you know move you you can introspect the previous state you can also move assets and liquidity over so some really Key Properties there that are really nice yeah and for for chains that are applications that are using different data availability there and I think I guess like that's kind of like the bottom layer in the stack are we going to need like interoperability between data availability like you know ethereum data availability and Celestia and I don't know like what other data availability there is that really where like if if change certain if the ecosystem starts moving towards this more modular stack and there are kind of data availability monoliths um right are we going to need to have

like some bridging between these data availability layers or can they uh 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 fail failure of properties of sort of typical Bridges between layer ones so I would say that the real benefit comes from bridging between execution layers on the same layer one is going to be the the best possible thing you can do so like you know if systems like arbitrary and autism actually had better decentralized sequencing then you could you could have a lot of nice guarantees between

bridging between those execution layers insulin like fuel uh if it was deployed tomorrow on on ethereum because ethereum would be the shared data availability and execution layer you know in that in that case um and so I would just say that yeah you still have the same failure points um if the uh if essentially they they're they're separate layer ones yeah so still the same problem how does this translate into ecosystem so there's currently only um 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 um 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 ruggable projects on our system it's not really anything we need or care about or that benefits anybody um the projects that we currently have building on fuel we have we have a few gxes a few nft systems and then a few lending systems and I would say 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 paralyzation 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 or system than what you typically see with ebm systems but it'll still be accessible to people with things like metamask 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 so that would be the way that I would describe it um like some some notable names are like

elix and pool sharks and uh and and eunuch as well um 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 um 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 yeah cool so what's the roadmap look like so one minute so I sort of hesitant to give a date from mainnet but um I'll preliminarily say that uh

there's two test Nets until something will happen uh so uh we just need to do about two more test Nets and then I would say that we're you know in a pretty good space to um you know be actually going to going to mainnet um and you know I I would say it'll be probably another two quarters something like that um if I were to to guess um but that that would be my my somewhat Alpha drop there uh yeah uh however I will say that with fuel itself like everything you would want to build you can build right now over the test notes so everything's still being kind of scaffolded and put together but um you can basically build anything that

you would want right now anyway so um don't hesitate to actually start investigating Fuel and you know building stuff with it yeah if you're a project so where can people come and find out more about Fuel and get started so you can just start with fuel.network so everything's available through that that's where you can find all of our docs and basically we've got a ton of like uh you know great tutorials uh guides Etc um we're always looking to improve the docs so that's like an ongoing thing um just continue the books are excellent I went through them yeah they are

accident I took I took several notes for for our own dog so yeah amazing amazing yeah I mean we still there's still even more we can do so it's uh we'll continue to increase the the docs and 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 A system that I think devs actually would really like to use and that gives them everything they need um 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 so yeah cool fantastic uh I'm excited to see how this will go and how long the two test

Nets will take and to see if there's an action awesome amazing thank you Nick