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.