Welcome to episode of the show, which talks about the Technologies, projects, and people driving decentralisation and the blockchain revolution. I'm service Equity. Oh, and I'm here with my colleague for the AKA Ernst. Today we're speaking with Nick Dodson, he's the co-founder and CEO of few laps. They're building a fast modular execution layer before you talk. Look, Nick. The about few labs and get into all the details. Let me tell you first tell you about our sponsor this week.
Omni is your new favorite multi-chain, Mobile Wallet only supports more than 25 protocol. So you can manage all your assets in one place across all major EVMS. Layer twos and nany vm's. But what's really special about Omni is that you can do. All the most important things about three directly in the wallet itself. If you want to get yield, well, I'm Lee Omni allows you to get the best apis with the zero fees and three Taps. If it's Making liquid staking lending via Ave or yield via
urine. Omni lets you do it. If you need to exchange u.s. DC for eith on Adam or on Cosmos on the Aggregates, all major Bridges indexes. So you can bridge and swap cross all supportive networks in one transaction directly in your wallet. That's pretty cool. If you love it if he's Omni offers the broadest NFC support of any wallet, so you can connect and manage your favorite entities across. All chains in one place on the is, truly the easiest way to use
web three. And most importantly on the is fully self custodial. That's really important meeting that you never have to trust anyone with your assets other than yourself if you want. You can even use omnes Ledger integration which is also cool feature. So the all your fun. Stay on your Hardware wallet. So join tens of thousands of users on this next Generation wallet by downloading today on iOS or Android at army.mil. Nick, thank you for joining us on this week's episode of
epicenter. Yeah, let's maybe start off by talking about your background. So you were previous existence. I think you were one of the earliest employees there. What was your role and what kind of stuff are you building? Yeah, so first of all, yeah, thanks. Thanks for having me. Yeah, consensus. I started initially. I didn't think I was early with consensus, although I did find out. 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. And there was one exchange and then there was something I was working on, which was way fun than, and another project called boardroom. So, both those projects were projects. Consensus wanted to kind of fund and help and grow.
So I was working working on that with them and then and then after that, I started to work on some libraries and other things which are still used in things like meta masks 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. Something like that. He then left consensus and you started few Labs with John Adler. How did you meet? And how did you decide to work
together? Yes. Oh John, I met in the Toronto office of consensus and initially. He came came into the office one day and said that he had solid scalability for etherium, or for ebm base. Blockchains things like that and initially, I felt Like here's the crazy guy in the office. So I'd heard so many times this kind of like rhetoric or I've just heard. I've heard it so many times that I didn't really pay much attention to it.
But you know, after I left consensus and, you know, wanted to work on a few different pieces of infrastructure for theorem some wallets, things like that. I started to think about what technology we had available for Theory. I'm too To actually do scaling. And at the time, there was nothing like layer 2 or nothing, like anything that we have now, zzk, even it was very minimal. And basically, everyone was focused on payment channels or
plasma. 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 or wasn't, well architected. So, I sent John a message and said, okay, you know, like what What was this stuff that you're
working on? And then he basically described optimistic Roll-Ups to me and it was like a three-hour conversation, the cafe back and forth, but it's pretty convinced that 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. Yes, 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. I saying the cosmos space and, you know, Celestia has kind of captured the captured, the narrative, and like modular block chains has really captured a lot of the narrative. I think, in that space, I think it's a theory mm to, as well with with theorem to after the merge. Now, people are thinking about blockchain so much more modular way. But yeah, like where does this
all fit together? And in this module is stack of Education, settlement, consensus and data availability. Where does fuel set? And how does it interact with these other layers? Yes, I think to start with that question. I think it starts with just we like the blockchain systems that we've been building.
So, so initially going from Bitcoin and then going into The real coins and then going into a cerium, 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 in Ashley you're not so sure as to how you want to construct them and that's going to create architectural issues and because of 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 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 us for a very long time. And unfortunately, for aetherium you know, theory of 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. Not for scale and it ended up really hampering theorems 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 theorem 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 Cracks 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 set 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 has to be accounted for in that in that field. So when it comes to any one of these chains are any any Block Chain itself, typically you see similar physics play out and you need to design a system that's going to be tailored for that physic Physics. But on top of that, when it
comes to block chains right now. I mean there's probably thousands of blockchains out there. I think Cosmos you know and and that ecosystem has been great instead of addressing some aspects of blockchain scale or or you know basically getting blockchains to Global adoption which is effectively in a developing tenements and these consensus systems 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 K specific chains. I think for aetherium, 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. 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 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 Celestia solves this problem of who's watching the data and we're 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.
We are using ends up being a lot safer than spreading the data into different silos where 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 tolerance 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 theorem does a pretty good job of just being a
great settlement layer. I think the kind of bamboo Increases we're going to see with like for a 44 and stuff like that are going to are going to help a lot. But in terms of how I see all these things playing out to be, 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, the 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 gnosis chain or how can we help? Unlike a cosmos chain or tenement chain or aetherium, 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 feels really trying to tackle execution and devex. As it's like, core kind of thesis and we're sort. Out 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 layer settling on
etherium. Probably some with Celestia's data. Availability some of the theorem and some with no data availability, so like a committee and I think that is an appropriate way to solve different problems. Jack's scalability needs while still retaining the etherium community and you know, all the benefits that a theorem brings to the table. So maybe that gives you some answers. I sort of tried to walk through a bunch of different topics there. How many ounces?
So many ideas? I have even more questions now. So best, there's certainly a lot to unpack yet. So maybe before we kind of dive into the nitty-gritty details about kind of, for instance, how you actually managed to parallelize transaction commits computation, And so on, let's kind of look at the at the big picture, right? So basically, if you have, if you have in the blockchain world, you have different functions that are kind of that are fulfilled traditionally or if I say theorem.
So for instance, you had data availability consensus settlement, and execution and basically everything was done by bayi theorem. And now after the match, I mean, basically data availability this kind of already, there were pretty good Integrations. Even before the marriage. So things like are we for instance but after the match 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 are touzani Theory. Mm. So fewer did actually start out as an optimistic roll up on the a theory. Well, basically, just that So, what exactly does the pivot to a module execution? They are actually entail. So what, what what, what is that even?
How is it different from an heir to if it then satyrs to a theory? Many ways to me? That sounds like exactly the same thing. Yeah. So the distinction we make is that a lot of the layer 2 is in the space right now, are now really designed for extremely high bandwidth systems, so they're really optimized for a different. Two fundamentally different problem, which is really just trying to fit as many sort of transaction B onto a theory of
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 evm 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 module executioner is really designed for a high bandwidth system. So it's a distinction from, or away from layer 2 is even though it can take the form of a layer to specifically and can take the form of, like, announcements to grow up on a theorem. It can also take other forms such as like, you know, Palladiums or other things that, you know, we've heard kind of
discussions around as well. It can also be its own layer 1 so it can be configured in many different settings, but the, the major distinction is that it's designed for a high bandwidth modular Block Chain. 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 etherium as they try to expand their their bandwidth.
So we just make a distinction between modules execution, and, and layer to specifically just because Trying to leverage all the benefits that modular block chains, give us and high bandwidth is like a key aspect of that versus like a typical like layer to which is more awesome rise to design. For essentially trying to work on a theory of right now which is like trying to pack bits and bites onto etherium, which is not necessarily a great optimization.
Once you, you know, actually tried to do tens of thousands of transactions, that's like the least of your worries. Do you think this is this assessment is going to change when we get if and when we get dang 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 players who are outsourced roll up. But at the same time, we're also designing our system for extremely high bandwidth. That's far beyond what I think for a 44, or dank charting, 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 a lot of bandwidth and not just necessarily the bandwidth like what aetherium has or what Celestia has. So for us, it's just full Paulo transaction execution across the board that allows us to
capitalize on all of that. If you're a developer right now and 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 in ecosystems. But looking 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 A graph on on a blog post, where you've got, like, on one side, monolith, eccentric. And and then on the other axis are monolithic Centric and modular eccentric on one axis. And then data, availability, consensus settlement. And the execution on the other end, there's like, six different ways that one can build it 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 Selman, roll-up, or like Celestia? Mm, which I'm Not even really sure what it is or like the Lydia more, right? Yeah. So, I mean, I think the spectrum is always going to be between something like price security and and and and that's it.
So you're 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 actually need from the system? And, and then, finally, likely the case, where do I want assets to be able to settle to or be interoperable? Go with you. No. 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 work 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 aetherium and having access to the theory of ecosystem, the the fact that the the bridges will interoperate with the theorem, you know, very, very easily but as well, if there's other chains, such as something like nose is chain or something else like that where you're going to have execution
list as well, then, you know, execution can can also happen there. And you can also deploy those systems 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 typically VM 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 looking to deploy into Fuel and you're looking to deploy into kind of, this newer, ecosystems, newer, Paradigm of thinking, they'll be a few different execution layers for you to deploy to and initially, with fuel, will 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.
Ins and granularity, which is going to be really, really important versus just having them deployed to some layer one over here or somewhere, one over there, where effectively their apps, 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 into the tech stack itself so fewer as a system has the ability to kind of paralyzed Transaction computation. How do you go about this? How do you make sure that you don't touch on the same addresses in different paralyzed threads? Yeah, so I think the easiest way to break those down. It's just that when you're processing transactions you would like to multi-thread.
So you'd like to process different chunks of transactions, all 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 UT EXO's.
So, basically, the you txo model is what we initially set out to build with, with our first roll up on a theorem and what we still carry through today with our designs and the UT Excel 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, BAE Systems, and etherium based
systems. And I think there are ways to address it, but because of the way, the system is 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 see a lot more scale potential. 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 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 in the parallel threads in the parallel process it and this allows us to retain verification times of the node such that you know basically nodes can retain something like a two-week sing time. But still process tens of thousands of transactions. Which is very important for just
a centralization general. So you want your sink times to be lower. So yeah, that's kind of the the Crux of just our system and UT X OS allow you to accomplish that by just saying, okay well you know every you T XO 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 your notating things like the state differentials of the block producers notating those. And then that's it. It's a very simple way to accomplish it and the reason why you takes those 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 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. Blockchains in general. And we can accomplish that because of UT X 0s, because we know it's utx, OS. That every you T XO cannot be double spend. And so with these inherent guarantees, you can basically start removing a lot of these big chunks of processing that we typically do with etherium nodes. So there's significant advantages to using UT X OS
without any ux, downsides. So essentially, you can still accomplish all the same things we do with the theory. Mm, there's be no downside or Rachel there at all for our developer it's literally all upside. Yeah bidding like a smart Contracting platform on UT EXO's is a lot more difficult than doing it on an account model of though, right? So how much do you actually have to what we actually have to pay for gaining, others upside?
So I would argue that, I mean if you use fuel right now, even with our other car and sdks, you'll notice that it's now harder to use it than it is to use etherium it. Actually oh yeah yeah Nick I'm not I'm not talking about that the dev. I'm talking about the stack itself. So basically the cool part of coil, right? Yeah, I mean basically with UT X OS, 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 parallels with exit 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 UT EXO's 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, and no Global accounts fruit. And these things get removed pretty quickly.
So, again, it 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. This is that's that answer your question. Yeah, kind of some. So maybe that me, let me kind of reframe this. So, I mean, most of the blockchains where you txo based, right? So basically, you txo was The Gnome. Why did you theory of opt for an
account-based balance mother? And do you think if it were to be redesigned today or relaunch day 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, Time, we learned at least with processing that. These accounts models are actually pretty horrible to
parallel process. If you're continuing to Merkel eyes, every single account, and have a root for every single block. So, I think, the original design decision was just that it was simpler and it was easier to reason about the and the thing is like, you know, that's a totally reasonable decision to make at the early stages of aetherium. However, I think given everything we know now and given how D TX home systems work and how even current modern blockchains work.
So if you look at salon Des designer Aptos and you know so we 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 UT X OS and I think you TX has give you really the best results. So I think it The theorem was redesigned today. I think the huge EXL model still better. The in pretty much every way.
Yeah, I think they would use you to EXO's. Let's put it that way and by that I mean just vitalik and Gavin. Yeah. Oh, I struggled to see vitalik and Gavin get back together. But yeah, if you would 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 architecture as 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 Away the evm processes, the way that Solano and these other chains process.
And, and trying to look at the properties that we want to achieve, we kind of realize 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 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, wazza 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 blotch, a 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
key. One, another one is retaining like clients, and another one is fraud from Leti. So building a virtual machine that's actually easy to fraud prude on things. Like a theory of my things like Solano. 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 had to convince all these steps 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 different settings.
As layer to Sizzler ones, it can really be an architecture. We can use for blockchain for 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 Giants. 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 the motivations. So for a developer that like a solution, Developer. That's used to building on evm or let's say a kazim, awesome developer that's building on kazim Azam 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 etherium doves 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 that the ebm things about things to awasum Deb or someone running on like, you know, a low-level runtime. It's basically going to be a little different in the sense that At the VM itself has some key op codes for things like managing fungible coins through YouTube, are you txo system? And probably some other little key differences like certain opcodes we've added that are beneficial.
Super beneficial for doing resource-constrained processing which block, chains 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 we've added into the virtual machine, but basically, the virtual machine itself, has some really key differences from the VM such as the fact that it's 64-bit, not to 256, it uses registers, instead of Stack system, it has
a different memory model. Our call model Works in some similar ways, but in other ways can give you Difficult 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 aetherium Deb's 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 in. Ignore backwards compatibility. So, just from an engineering perspective, we get to benefit from just Saying well we'll bring over everything. We like her 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 I would describe it or think about it. So you also say that you support multiple native assets, how is it different from a theorem? And who what do you pay gas in and who determines what you pay gassin? Yeah, so on the front of multiple native assets. Oh so essentially our system and in our machine is designed inherently to support basically treating native assets more assets, that people create like
native assets. So in a theory we only have one native asset which is just either and unfortunately ethers 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 a theory, we have to do them at the Ation are smart contract level and now 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 it, State and Ricci realising it and actually hampers a lot of the the processing. So so on our side we basically say okay well, any token can be a native assets or can spit out this own kind of, you know, token that can be and live.
The UT exosystem 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, the state level, you're just doing one state, right?
And that's it. And again, there's no re serialization 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 this. So massive upside and it allows developers to tap into the
native assets system. And there's like a huge, huge benefit something that a theorem, really desperately lacks because every toe You just end up creating an EOC 20 and unfortunately that's pretty hard to scale when you really try to get into the Crux of it. So as I was one side of it in terms of fees, so the chains that will settle on ethereum
will all have these a neith. So like we're pretty Ethan Maxey and that sense and this Crypt 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 a you know these these execution lives on a theorem. It's like the case that eith
will be the the fee. However you will be able to have things like private men pools and be able to accept, you know, fees and die, or us DC, or these sorts of things as well, whatever the block producers want to want to accept. But in general right now, are our current plan is just to use
ether as the as the fees. It's the learning curve for like, on the like, zoso solidity is have inspired by JavaScript and right, you know what, like what is it, but the language actually look like is it sort of similar to solidity in this sense or yeah? So taxed only 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 is looking like rust, inherits a lot of nice things from solidity and inherent.
Organize things from, you know, some of these are kind of language that we see in space but the predominant inspiration is still rust. And for Dev coming from ethereum, I'd say the learning curve is pretty low. Most literature jobs 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 because the language is a blockchain specific language or is designed to Target block chains.
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 dads 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, bunch of move devs as And then, in terms of, in terms of Solana and what their experience is like, you know, basically they're they're more in the rust category and they're using R Us 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 wasum as well. And so, it's way. We really try to patch that up and say, can we give developers an incredible.
So 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 etherium, with whatever the second layer is. Yeah, so the bridge that we have that, we also recently released in beta 2, or a recent test network, is some very similar to optimism. You could say. So there's a lot of inherited properties there to optimism, some inspiration, from Harvard from as well. So it's a generic like arbitrary message passing bridge, but you can basically Bridge anything you can bridge at everything from your see 20s.
Seven, honey, once you can do all sorts of arbitrary messaging in and out of the system and basically fuel gives you full settlements. And, you know, the properties that you're looking for as a Dev to settle on something about something like ethereum, but for any kind of token. So for example, if you wanted to create an NFC on a fuel, have it massively, scalable meant, millions of them and then have some of them be able to come back under with your IAM settle
you could do that. You can also just take you SCC and dime these other things. Put them over the bridge and they become native Assets in the fuel and can benefit from our UT access system. So essentially we get to fully interoperate with the theorem liquidity and and you know, and that goes for a friend of T's a fundable tokens so I'd be the best way to describe it. Yeah. Okay. And what about the notes that actually run fuel? So who runs those?
Yeah. So, currently we're starting out with a single sequencer or model. So, similar to arbitrament optimism, with some, some fallbacks, that's mainly just to get everything set up and to allow Deb's to actually get to production after that point, though we will actually look to decentralize block production. And this is like, a key piece of architecture and The centralizing 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 2 is an optimistic Roll-Ups. So you get a essentially like a decentralized sequencer, you could say and the way that we accomplished 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 a theorem itself and data availability, being secure and on something like a theorem or something like Celeste yet.
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 were talking about bridging just briefest previously here.
What does bridging look like in a modular stack ecosystem or application, it 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 is you know more broadly. I think that one of the biggest challenges Is right now is creating trustless or trust minimize bridging standards
across different ecosystems. So the etherium evm ecosystem has solutions for bridging across evm chains polka dot has also their own protocol Cosmos as 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 he is GX you know as as these chains become more modular and you know some abusing the evm execution and others might be using like Waze mm but they're all using that the 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 were operated does the modulo stack facilitate this interoperability 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, like a bridge to something like a
theory. I'm so, you know, a bridge that we've seen with, you know, Arbiter more optimism, that kind of setup and those bridges are more about, I would say settlement and as well, we use them for different aspects of like block production and posting headers and things like
that. Other Bridges though. That you want, you want some Key Properties, if you really want to achieve trust minimize bridging, so some nice properties that you get with modular block chains, or with blockchains or execution lies 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 the said earlier, And if you can do that, you can create these trust minimize Bridges. Where essentially set up having like a multi sitting on both sides, you can actually have two smart contracts on both sides of
the bridge. And so let's say you were bridging from one fuel instance to another fuel incense on aetherium because both of these layers have the same date availability and they have the same you know, headers or they have any easy to Respect Blockhead our system, you can basically create a trust minimize bridge between the two of them. And it's trust minimized because you're not really relying on necessarily things like multi 6
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 on Celestial would be the same. So you know, You basically, you share data availability and so, you know, one executioner can actually introspect the other and that's like a very key property with trust minimize
bridges. That I think will be a huge game changing set of factor for why you would want to pick a modular Block Chain versus just picking these layer ones, because we've already seen so many bridges fail with, multi, cigs that really? If we're going to continue to build newer, blockchains you're going to want these He's in your block chains, so that you can actually enter operate. All the liquidity, it also works well for upgradability when
you're doing a new execution. Learn 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 change that are applications that are using different data. Availability Lera. They 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 aetherium data availability and Celestia and I don't know like what other data availability there. Is that really where like if change certain if the ecosystem starts moving towards is more modular stack. And there are kind of data availability monoliths. Are we going to need to have like some bridging between these data? Availability layers are, can they validate each other?
Yeah, I mean, ideally, you would want them to interoperate but then you have basically Actually different different layer ones trying to interoperate with each other. So you're still going to inherit the same sort of fill failure, properties of sort of typical Bridges between their 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 best possible thing you can do.
So like, if systems, like arbitrament autism actually had better to centralize sequencing, then you could, you could have a lot of nice guarantee. He's between bridging between those execution, errors, insulin-like fuel if it was deployed tomorrow on ethereum because etherium would be the shared data availability and execution are you know in that in that case and so I would just say that.
Yeah, you still have the same failure points if the if essentially they are there 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 a projects, our current philosophy with fuel is that we really don't need thousands of projects to build our own fuel. We need only like ten good ones.
So for us like we don't care about having 500 and ft rug pull projects on our system. It's not really anything we need. Care about or that benefits anybody the projects that we currently have building on fuel. We've huge axis. A few nft systems and then a few Landing systems. And I would say that the key differentiating things about them are going to be that they can leverage sort of things like, feels account abstraction or they can leverage like paralyzation.
They can leverage some unique properties of other fuel VM or about sway about having a significantly larger. ER 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 evm systems. But it'll still be accessible to people with things like meta, Mass wallets, and ethereum
volume. So that's really the best part is the accessibility is still with etherium 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. Like some some notable names are like Helix and pool sharks and
and eunuch as well. And I'd say a lot of the projects that are building on fuel are far more ideologically or philosophically aligns 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. I just another project or a copycat project quiz, so what's
the roadmap look like? So when Maynard sort of hesitant to give a date from a net but I'll preliminarily say that there's two tests Nets until something will happen. So we just need to do about two more tests nuts. And then I would say that we're in a pretty good space to be actually going to go into the net and You know, I would say it'll be probably another two quarters, something like that, if I were to guess but that that would be my 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. That's so everything still being kind of scaffold and put together but you can basically build anything that you would want right now. Anyway, so don't hesitate to actually start. Getting fuel 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 dot Network. So everything is available through that. That's where you can find all of our dogs. And basically, we got a ton of like great tutorials guides, Etc. We're always looking to improve the docks. So that's like an ongoing thing just get your ducks. Excellent. I went through the last night and they, yeah, they accident. I took, I took several notes for our own dogs, so amazing. Yeah, I mean, we still, there's still even more we can do.
So it's what will continue to increase the the docks, 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 Deb's 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 the stuff so Bluefin Hasek. I'm excited to see how this would go and how long, the two tests 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 podcast. 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, .t V /, subscribe for a full list of places where you can watch and listen, while you're there, be sure to sign up for the newsletter so you get new episodes in your inbox as the 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, but thanks so much and we look forward to being back next week. 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, but thanks so much and we look forward to being back next week.