On The Brink with Castle Island - John Adler (Fuel Labs, Celestia) on building the fastest modular execution layer (EP.307)

Episode Date: April 14, 2022

In the second episode in our modular blockchain mini-series, we sat down with John Adler, the inventor of optimistic rollups and co-founder of Fuel and Celestia. Fuel is the fastest execution layer for the modular blockchain stack. The technology enables parallel transaction execution and offers flexible throughput and the highest security required to scale. FuelVM offers developers a superior experience and the ability to go beyond limitations faced by the EVM and other virtual machines.   In our conversation, we discuss: The importance of data availability for maintaining censorship resistance Fuel as a modular execution layer with configurable consensus, data availability, and settlement Why Fuel Labs is building the entire blockchain stack to offer the best possible developer and user experience How FuelVM supports parallel transaction execution and other notable improvements over EVM To learn more about some of the concepts we cover, here are a few incremental resources John mentions in the episode. John Adler: Wait, it's all resource pricing? John Adler: Secure Off-chain Data Availability for Rollups John Adler: FuelVM Bootcamp Follow John on twitter and Fuel on Github Intro/outro track: OmgKirby #664 (used with permission)

Hi everyone. This is Ria from Castle Island Ventures. Welcome back to On the Brink and to this episode with John Adler, who's the inventor of optimistic roll-ups and co-founder of Celestia and Fuel, which is the focus of the conversation today. This is the second episode in our modular blockchain series. And as a reminder, in our first episode, we spoke with Nick White about Celestia as a consensus and data availability layer. But in this episode, we unpack the modular execution layer, specifically Fuel, which is the next module that sits on top of a consensus and data availability layer like Celestia.

Fuel Labs is building the entire blockchain stack from the modular execution layer to the programming language to the tool chain to offer developers the best possible experience building on top of fuel. This episode gets technical, but John does a great job of explaining fuels design decisions from a blockchain basics and first principles perspective and does really explains why fuel is able to offer and be the fastest modular execution layer. So with that, let's turn into the conversation. Hi, everyone. This is Ria from Castle Island Adventures. Welcome back to On the Brink. and the second episode in our modular blockchain series. Today we have none other than John Adler, the inventor of optimistic roll-ups and co-founder of Fuel Labs and Celestia. So last week we had Nick White,

who's the CEO of Celestia Labs on the podcast. So we'll start the conversation by talking about fuel, which is the fastest execution layer for the modular blockchain stack. As a reminder, Celestia offers the consensus and data availability layer that an execution layer like fuel can build on. Fuel enables parallel transaction execution, the highest flexible throughput, and maximum security needed for scaling. And it addresses limitations in the EVM while offering a superior developer experience as a result. So use a lot of words and terms there that we'll definitely unpack in this episode. But before we get into what all of that means, John, can you tell us a little bit about your

background and your role operating Fuel Labs and Celestia? Sure. Thanks for having me on. So like you said, my name's John Adler. I'm the chief research officer at Fuel Labs and also Celeste Labs and a co-founder of each project. essentially what that means is I do protocol research and specification work, so making sure that all the components of the protocol all fit together nicely from a theoretical perspective. Also, you could say I'm a glorified PR reviewer where I just approve PRs for most of my day. What was your background prior to Fuel and Celestia? Sure. So prior to this, I was at consensus.

doing layer 2 scaleability research, so things like plasma, stay channels and whatnot. That's where I had my first interaction with Mustafa and also Nick Dodson, co-founders of Stastia Labs and Fuel Labs respectively. And prior to that, I was a university student, actually a PhD dropout, for real, unlike some people. I was a graduate student at University of Toronto doing various blockchain research and so on. Decentralized oracles were a pretty hot topic at the time. And then I got my first exposure to blockchain through my advisor for my graduate studies. He was quite heavily involved in the early days of Ethereum and in cryptocurrency stuff before them.

One thing he liked showing his students is a selfie he has with the Mount Gok sign guy. If you remember when Mount Gawks happened back in the day, there was like this famous Mount Gok sign guy that says, there's a sign that says, you know, give us back or Bitcoins or whatever in Japan. And I thought my advisor actually has a selfie with him on the day that it happened. So yeah, that's kind of how I got my initial exposure to cryptocurrencies and to Ethereum and so on. And then from there it was basically a done deal. That's some fun trivia.

So you mentioned you worked on other layer two scaling solutions and research at consensus. And one thing we talked about with Nick was different approaches to scaling, but, you know, we specifically talked about increasing node requirements and sharding and how those approaches technically shouldn't be considered scaling. Could you walk us through some of the challenges with prior layer two scaling efforts? And yeah, let's just start there. Sure. So the two primary, let's go the three primary ones, were side chains, state channels, and plasma prior to roll-ups really coming onto the scene. So side chains are simply another blockchain that has a trust-minimized one-way bridge

from the parent chain to the side chain. but it doesn't have a trust-minimize backwards bridge or reverse bridge. So that means you can move funds from, let's say, Ethereum to Polygon, just to give an example, because Polygon being a proof-a-stake-side chain. So you can move funds in that direction completely trustlessly. There's nothing that the Ethereum miners can do to steal the money in any way, or to corrupt this bridge in this direction. But to move funds backwards, you need to rely on some mechanism that has fundamentalized, mentally last security than the main chain,

than Ethereum in this case. And this is because, well, there's two reasons. The first is the fact that the main chain does not know whether the side chain is valid or not. And the second is that the main chain does not know whether blocks on the side chain are available or not, which falls into this whole data availability thing that Celestia is doing that I'm sure you had, you know,

a lot of interesting conversations can't put Nick on this topic. So the second approach is state channels. And for this, yes, it can provide, you know, potentially a huge number of transactions per second. They can be very expressive. It has the same security as Ethereum. This is all great. But they don't allow open participation.

You can't have someone new join a payment or stay channel that already exists between a certain set of parties. So, you know, if you and I have a state channel together or playing some chess game or a trading or something, someone else can't just come in without asking our permission and participate in this construction. They would have to do something like to create a whole new state channel, the whole new state channel that had to be instantiated that included the three parties. And if you wanted four parties, you'd have to include all the four parties and a new state channel and so on. So it doesn't allow this kind of open, permissionless participation that blockchains have. So you can't build a uniswap in a state channel, unfortunately. You can build a uniswap that works for the people in the state channel when it's created. But uniswap doesn't actually just do that.

Uniswap also allows anyone to just come in and create a pool or anyone to come in and trade, not just the people that are currently on the blockchain when uniswap, when a pool was deployed, for example. Anyone can come in at any time in the future. The third approach was plasma. In this case, plasma uses a clever mechanism that essentially allows you to guarantee that if some state change happens in the plasma that is invalid, that it can be challenged on the main chain. So this is how it guarantees correctness. And it happens that the particulars of this challenge game work fine, even if the data, data is unavailable, but this imposes a constraint on what kind of transitions can be challenged.

So you can't have any arbitrary state transition that's true incomplete, like you have an Ethereum. The limitations are specifically that every single piece of state in the plasma must be owned by at least one person. So something like a coin or some funds. that's owned by someone, okay, you can challenge that. So if you just do simple payment transfers, plasma works just fine. But if you're looking to do some sort of generic smart contracts, something like Uniswap,

the Uniswap contract doesn't actually have an owner. It just exists, right? It's there, an immutable smart contract. There is no owner to it. Since there is no owner to it, you cannot actually run this challenge game over some piece of state that has no owner. just due to the technicalities of how this challenge game works. So these are kind of the previous attempts and these are the limitations. And this is kind of where roll-ups come in, if we're okay with transitioning to this next topic.

Yes, let's do it. Okay, so what does a roll-up do? Going back to my description of sidechains in the shortcoming, a roll-up is a blockchain, just like any other blockchain. It's a blockchain with a bridge, as Ackymanian would like to say. and it has a trust-minimized two-way bridge. So not just one direction from the main chain to the side chain, but it also has a trust-minized bridge going back.

And it accomplishes this by having some mechanism to guarantee that the roll-up chain's blocks are valid, and some mechanism to guarantee that the roll-ups blocks are available. So the valid part is the easy part. We'll talk about the available stuff soon, but the valid part is the easy part, which is there's two ways to without, well, okay, there's three ways of ensuring that a block is valid. The first is you just literally fully validate it yourself. Obviously, this would be kind of terrible for a scaling solution because of every Ethereum node had to fully validate the roll-up.

Well, I mean, at that point, it's just a block size increased. It's not a roll-up. So it's not a separate thing, right? So that's kind of not the way you want to do it. The other approach is zero knowledge proofs or validity proofs that they're sometimes called. This is a proof that the rollout block is just some cryptographic proof that the rollout block is valid. That it does in fact, that if you apply all the transactions, that the state route at the end is in fact, you know, the valid state route after applying all those transactions. And the third way of ensuring correctness is with fraud proofs.

So this is essentially a proof that a block is incorrect. So essentially the mechanism is someone posts some claim that, you know, here is a new block on the roll-up. Here's the new state route. Here are the transaction inside it. And if no one disputes this block with a fraud proof within some window of time, then the main chain just says, okay, I guess it's valid. Because no one has disputed it. And if it was invalid, someone would have disputed it by now. And this is a relatively long-time window, something like a week, let's say.

So even if there's a bug in the off-chain code or something like that, there's plenty of time to fix that and actually properly submit a fraud proof. Any questions about this so far? No, I'm following. Okay, good. So now we should get to the availability part, which is, again, where roll-ups have a lot of, or have a big distinction from sidechains, which is, unlike side chains, which keep all of their data entirely off the main Ethereum chain, roll-ups post their data to Ethereum or to some other place that guarantees some data availability under certain assumptions. An example of that would be Celestium, which is something I talked about at Heath Denver just last month, I think, which is essentially using Celestia for data availability and using Ethereum as a settlement layer,

so for disputing the actual fraud proofs or validity proofs, or I guess disputing. fraud proofs and verifying validity proofs. So the, but the most naive way you can do it is just literally take all the data in the rollout block and you're just posted to Ethereum. And Ethereum doesn't actually execute the transactions in the rollout block. So it doesn't do full validation. It just takes the zeros and ones and downloads them and that's it. So all the data is in fact available. It just not executed.

The execution happens off-chain and can be verified on-chain via either a validity proof or a rod proof. And this is one way that roll-ups can make more efficient use of the very limited resources of a consensus layer. Now, why do you need data availability? Why is it not sufficient to just have correctness? Why do you also need data availability? And why do you need it for ZK roll-ups as well? Because ZK roll-ups cannot have an invalid block. So for optimistic roll-ups, it's very obvious, and it's that if the data is not available, then honest actors cannot actually create a fraud proof because they cannot prove something is invalid

if they don't know what that something even is. So you need to make sure that data is available. And I should probably take a step back and kind of define data availability for the listeners who haven't listened to next episode with Celestia, which is that data is available if it has been public, In other words, if the entire world has access to that data. And it's not the same thing as, for instance, data retrievability,

where you can download the data from a specific node. Data availability is, has the entire world seen the data at some previous point in time? And if the answer is yes, then under certain assumptions like, you know, this is a strike sound effect or, you know, the internet never forgets, If it's something sufficiently interesting, then the internet should never forget and the data should never be able to be unpublished. So some very weak assumptions there. Mind you, blockchains today also work under the same principle because no one is incentivized to actually keep all the blocks of, let's say, the Bitcoin history. Full nodes can just discard them and they'll still continue operating just fine.

So the only reason that Bitcoin blocks are still retrievable is because they're sufficiently interesting. So it's kind of an orthogonal concern. Okay. So going back, I think there's like a tangent there, but going back to, you know, why data availability. So for fraud, again, for fraud proofs is obvious. You need them because it's impossible for an honest actor to construct a fraud proof. Why do you need them for validity proofs? And this is something, and the consequences of this are something that's very important.

important because it reveals to us why validity proofs aren't the magical thing they're advertised as, as much, which is that if the data is not available, then it could be the case that someone who's creating the roll-up blocks creates a roll-up block that while valid, no one actually knows what's in the roll-up block, and therefore no one can actually do anything with a chain. So they cannot withdraw their funds and I cannot add new transactions to the chain because they don't, they no longer know the state of the chain, even though they know that it's valid. And this is why data availability is so important, even if you know the chain is valid. Because a blockchain doesn't just provide correctness on the state transition. One common thing that Bitcoin proponents like to claim Bitcoin provides is censorship resistance.

and censorship resistance has nothing to do with the correctness of the chain, right? It has to do with, can I insert my transaction into the chain? If you can't do that, then it's not censorship resistant, even if the chain is completely valid. Even if no one steals any money whatsoever, even if all the blocks are perfectly valid, there's no reorgs happening, no nothing. If you can't get your transaction in, then it's not censorship resistant, and you're losing one of the key properties that we want out of systems like Bitcoin and Ethereum and so on. or any properly decentralized blockchain. So you cannot, you can't avoid the need for data availability, even if you use ZK proofs, even use validity proofs.

And this applies to chains like Mina, for example, formerly known as Coda. They claim to have an OO of one blockchain where you only need to verify a single recursive proof and you know the chain is valid. And while the statement is correct, that is not actually sufficient for decentralized blockchain. Because that just doing that doesn't actually give you something. censorship resistance because no one, like sure, you know that the chain is, the mean a chain is valid, but you don't know that the transaction history is available. And if it turns out it's not available, then you could end up with a chain that no one can actually use except for

the cabal that controls it. I definitely want to get into data availability and data availability layers with you and, you know, talk a little bit more about Ethereum as a data availability. bilibili layer and obviously Celestia. But before we do that, so we talked about, you know, what a roll-up is and how it works. But I was reading one of your pieces from, I think, November 2019 titled The WISE of Optimistic Roll-Ups where, you know, you say there's been a lot of content on how they work at that point in time, but not why it works and why it really facilitate sustainable scaling. Could you expand on that a little bit?

Sure. So this was kind of an early piece that if I do say so myself, might have, I don't want to call them inaccuracy, so much as things that weren't like complete thoughts based on what we know nowadays, which is that it was kind of heading in the direction of the modular blockchain just before that notion it really became popular.

Right? Because this was, I mean, November, November 2019 is a long time ago. So essentially, the intuition here is that with systems like a roll-ups, it doesn't really matter if it's optimistic or Z-K,

because, you know, we can debate technicalities and stuff, but the differences between the two are much, much less than either, you know, the proponents of either camp would have you believe.

So it's like, it's a technical detail. That doesn't really matter. Any roll-up. The interesting thing it does specifically is that it takes state. Not so much execution, but the most important thing is it does, it takes state and it moves it from the chain, from the layer that does consensus, and it moves it to some other layer. Why is this important? Because the single most worrying

thing about any chain that strives to be decentralized or something like Ethereum and Bitcoin is the size of the state. Because state cannot be. discard it, A, you need state if you want to be a full node, if you want to validate new blocks. You can discard history, but you need to keep the state around. So like everyone's account balances or in Ethereum, also the smart contract storage and so on. You need to keep that around. But also, the larger the state grows, the more expensive it is to actually do lookups and modifications to the state. In other words, it actually slows down the entire chain as the state grows.

So it's a very big problem. It's like a big bottleneck that you really don't want to have a huge state size unless you have some better state representation that can alleviate some of these concerns. For example, Bitcoin, when I introduced Segwit, it offered a 4x discount on witness data. So this means signatures. And non-winness data didn't get any discount. Some people complained, well, it's just a straight block size increase. that's terrible, but the truth is a little bit more nuanced than this, which is that if the block size in terms of number of bytes is not actually the bottleneck, if the bottleneck

is state size, then it's not so bad if you quadruple the block size, but don't also quadruple how much the state can grow. And that's essentially what Segad provided, that it essentially allows you to have 4x larger blocks in terms of bytes, but how many actual changes or additions to the state you can make didn't grow 4x. It maybe increased some small percent because of this discount. And for anyone who's curious about the technical stuff around this, I actually gave a talk at ECC. I want to say last year in Paris about resource pricing, where I went over in detail about this example, specifically this example, the Segwit. So, and the kind of high-level idea is that witness data, so in other, signatures, don't

enter the state. As before, state is things like account balances, you know, for Ethereum, or it's like a UTXO set on Bitcoin. But the UTXO set doesn't actually care about the signature. It only cares about the balance, right? It only cares about, you know, here's a UTXO. It's owned by something, right? it has a certain amount of coins, and that's this.

But the actual signature of how that UTXO came to be isn't actually part of the state. It's part of the history. So it can be pruned. It can be discarded. So this is why the discount comes in. So Bitcoin kind of led this notion that state size is a big problem. Ethereum is also encountering this problem. So the ability to move state from the consensus layer to some other layer,

is good because it means that the consensus layer, which, you know, there's no, I mean, I guess there's a social layer, social coordination layer below the consensus layer. But you kind of don't want to hit that very often unless there's something catastrophic going on. But the consensus layer, you know, there's no real like technological layer below it. So you probably don't want to have that be bloated. You want to, you want that base layer to be simple. You want it to be lean. You want to be lightweight. You want nodes. You want the ability. for people to run nodes to actually validate this base consensus layer to be very cheap. And then you can move a lot of the state growth problem. You can move it into layer two or into an execution layer. Now, I want to kind of bring up a very, like, important point here, which is that just because you've moved it to a layer two doesn't mean the problem goes away. It actually stays there. You just moved it from one place to another.

you don't actually get a free lunch where just because something is a roll-up magically means it can do a million transactions per second and there's no downside and no shortcoming and no security issue whatsoever because a roll-up is just a blockchain and it's a blockchain with a bridge. Which I think we'll discuss maybe a bit further

on what these shortcomings are. Yeah, so maybe now is a good time to do just that. Maybe can you walk us through fuel and its key components. And as you're going through that, maybe provide context on how those components differ and provide advantages over the designs of other roll-ups deployed on Ethereum to address what you were just talking about, which is just because you move, just because you move it to another layer doesn't make the problem go away. Yeah, so the intuition behind it is as follows, which is that on Bitcoin, for example, or on Ethereum, right, let's take our favorite, quote-unquote decentralized blockchain, you know, because we all hate Solana, they're all centralized and so on, right?

Let's take our favorite decentralized blockchain, supposedly. Why is it that Bitcoin is limited to, say, four megagite blocks with, you know, again, a discount for witness data because of state growth and so on? Or why is it that Ethereum is limited to, I think, about 13 million gas every 12 seconds or every 13 seconds? Why do we have this limit? Why isn't the limit 10 times larger or 100 times larger or 1,000 times larger? It's because through social coordination, we have decided on a particular cost to run a fully validating node. Because we want to guarantee, like users want to guarantee that the blocks are all valid, and the blocks are all available, and that even if all of the miners or stakers who do not control the chain,

they're simply service providers that can be fired if they misbehave, that even if all of them got together and attacked the chain, that they could recover. And one common argument in Bitcoin, for example, is that if 51% of miners were to attack the chain, that the users could get together, you know, spin up mining hardware and stuff, and maybe have more than 51% of the chain and actually produce a new longer chain. Now, whether that particular argument is correct or not is orthogonal, but the point being,

users can't do that if they can't run a full note. So it's not sufficient to know, again, it's not sufficient to know that the blocks are valid. You also have to be able to produce new blocks, so you need to know they're fully available, and you need to know the whole state so that you can produce new blocks. So you need all these properties for a regular blockchain.

Now, a roll-up is just a blockchain, just like any other blockchain with a bridge. So just because it's a roll-up doesn't magically mean that users can now, it doesn't mean that users now no longer need to do those exact same things. You just still need to be able to fully validate the chain to make sure it's valid. This could be alleviated through the use. use of zero knowledge proofs, right? Because those are a compact way of proving to you that the chain is valid. But zero knowledge proofs do not help you with availability, and they don't help you get the current state. To get the current state, you still need to actually apply all the state

transitions. You still need to apply all the transactions to get the final state so you can produce a new block. And just being a roll-up, like there's no, there's no argument for why you don't have to do all this, because there is no argument. You still have to do this because there's still blockchain. Now, there is one particular line of argument that isn't used when talking about why roll up scale, which, you know, as I just said, they don't really, which is that, well, you went from like you having to run a full node to you now not having to run a full node, but you can trust one honest party if there's a fraud proof or you can just trust the validity proof, right? That's not a good argument because in the worst case, it is not sufficient, again,

to know that the block is valid. The absolute worst case is that you will have to fully validate the chain yourself to get the current state. And you can't meter blockchains based on the happy case because that's a grieving vector. You must meter them based on the worst case scenario. So the fact that there is a more efficient happy path that in the regular operation of the chain, if no one's attacking it. Roll-ups, okay, you can just trust there's one honest operator. Sure you can, but that doesn't allow you to have a million times larger blocks because you can't meter that block size based on the happy path. You need to meter it based on the absolute worst case, which is that the roll-up operator is similar to the validators on an approve of stake chain or the miners on

approve of work chain, all decide to get together and launch a majority attack to corrupt the chain. users have to be able to defend against that and to do that, well, the chain had better to be metered based on that worst case, not in the happy case. Okay, so now how does fuel deal with this and what does it do differently than other roll-ups? First of all, I should say that fuel isn't a roll-up. It's actually a modular execution layer, or in other words, an execution layer for the modular blockchain stack. So what does this mean? it means that it's a blockchain, again,

this is like a recurring theme, which is that all the things are just blockchains with a few other properties. It's a blockchain that is verifiable. So you can verify its correctness using fraud proofs in this case. If you wanted to, you could also use zero knowledge proofs. So and beyond, you know, being verifiable,

it can have a configurable data layer or a configurable consensus layer, rather. So this means that you could run an instance of fuel as a classic optimistic roll-up that uses Ethereum for data availability and consensus and settlement. You could also run fuel using Celestea for data availability and Ethereum for consensus and settlement. Or you could run fuel that uses Celestia for availability and consensus and does its own settlement. Or you could run an instance of fuel that's. does, that uses Celestea for consensus and data availability, and that uses this thing that Celestea called Sevemos, which is like a settlement layer that runs atop of Celestia, an EVM

settlement layer that runs atop of Celestia, and this instance of fuel could reuse Sevmos for settlement. And this is the power of being a modular execution layer that you're not tied to one particular data layer, one particular consensus layer, one particular settlement layer, but rather that you are modular, that you can deploy multiple instances onto, you know, with different configurations. So fuel or the fuel network is not a roll-up, rather it can be deployed in multiple instances in different configurations. Now, one thing that's, now, you know, one thing that if you're actually building a modular execution layer, if you're not building an Ethereum roll-up,

you'll actually notice that there's some interesting difference in how resources are priced. So for an Ethereum roll-up, and this is why confining yourself to just being a roll-up is limiting, for an Ethereum roll-up today, the most expensive resource is call data on Ethereum. It's making data available and having consensus on it on Ethereum. It's by far the most expensive thing today for two reasons, the first, because Ethereum, in block space is very scarce. And the second, and this is the interesting thing, and for those of you who want to know more,

I'm actually giving a talk about some of these things at ECC this year, or I think I am. It's that so far, roll-ups have not hit their capacity limit so that full nodes kind of slow to a crawl. Because very few people are running full nodes for roll-ups, like Arbitram or optimism or ZK Synch or whatever, very, very few people actually are running full nodes

so they don't notice that the chain under high load, if it's under the same load as Ethereum, it's not going to be any cheaper to run a full node. And if the chain has 10 times as many TPS as Ethereum, good luck, you're not running a full node on an end user laptop. It's not going to happen. Even with that few TPS, even with like 100 or something, right? You can look at Polygon.

The chain is like constantly crashed, and the block explorers are constantly crashing even at a load of, you know, a few X of Ethereum. And that's, you know, block explorers that have very powerful computers. You're not going to run a Polygon full node or a Binat smart chain full node. It's not going to happen because they're just blockchains ultimately. Being a roll-up doesn't magically alleviate, you know, the fact that you still have to run a full node. And if you're a fork of death, congrats, it's a fork of guess. You're still limited by the same thing that gets is limited by.

So in a modular world, data, availability and consensus and consensus on that data availability is actually, I wouldn't say much cheaper, but it has much higher capacity than what Ethereum has today while maintaining the same security and decentralization guarantees. And I'm sure Nick talked about this in the previous episode, but essentially Celestia by not doing execution, by not having a large amount of state, by not having true and completeness and so on, on the main layer, one chain on the Celestia chain, it means that all of the resources off the full nose that run can be spent towards a single thing, which is just data availability.

Sorry, there's data availability. So it's like just a whole bunch of bandwidth. No compute, because there's no compute on Celestia, no storage, no nothing, just a whole bunch of data availability. So what this means is that under a similar load, to where, you get in an Ethereum, fees will be much cheaper on systems like Celestea or Ethereum post-data sharding. Data will be much cheaper.

And all the roll-ups today, except for fuel, which, again, is not a roll-up, rather it's a module execution layer, are essentially optimizing for very expensive call data and a very cheap state, which will actually be the downfall of every one of these projects because they will grind to a halt as soon as their state grows too much. You can see there's various people on Twitter saying, wow, this is so amazing. I can use, you know, some optimist or whatever, I can just use state freely, or I have to change how I optimize my code to use very little call data, but just use a shitload of state. Yes, they're making these optimizations today, but it means a year or two from now when call data

becomes very cheap all of a sudden, that state isn't going to go anywhere. where that state is going to stick around forever, because you cannot discard state. It means every single one of these roll-up chains that you see today, a couple of years from now, will be bogged down to a crawl because they'll have, you know, even larger state size than when Ethereum has today, and they'll have to deal with it because you can't discard that state.

And this is where fueled there's something different by being a modular execution layer, because we know that in the not too distant future, when roll-ups are not roll-offs, but just execution layers, are the primary way in which users will interact with smart contracts and with blockchains. You want to optimize for the world that is going to be, and you want to optimize for the same issue that blockchains have had since the beginning, which is state.

Because the fact that call data is expensive today is a temporary problem. It will go away very soon, but state is not a temporary problem. It is a permanent problem that will rain forever. And fuel by using a fundamentally, different execution model than Ethereum. By using UTXOs, it allows you to have much better performance over state accesses and so on and much better ways of handling with state. And we can cover details shortly of how it does all these things, the technology.

But essentially, it allows you to handle state much better so that in the not too distant future where the world is going, fuel won't be bogged down by having chains with huge state because oops, it didn't plan for this future to happen. Got it. So I guess what is the, for lack of a better word, state of fuel today? So you know, you talked about fuel as a modular execution layer given it can have this configurable consensus. You can deploy different instances and different configurations. What is the configuration today? And then what is the ideal configuration in the future?

Sure. So fuel v1, which is like our legacy work, and it was essentially built by a few guys with no money in a cave with a box of scraps, was the first optimistic roll-up to be deployed to Mainet Ethereum. To this day, it's actually the only roll-up that is actually trust-minimized. that doesn't contain upgradability or Dow or a white list or not having fraud proofs.

It has all that. It has fully decentralized block production, fully permissionless. Anyone can use it. And the fraud proofs are there and complete and so on. Even to this day, it's the only roll-up that's an actual roll-up. But Fuel v1 only does simple payments. And we wanted something more, which is where Fuel v2, as it used to be called, came in, or the fuel network, or fuel, as we call it now.

which is underactive development. So the fuel network currently is in development. It hasn't launched in Maynit yet. TASnet will be launching very shortly. I can't give any exact dates, but it'll be launching very shortly. Maybe by the time this episode comes out, one will have already launched.

And it's undirective development. Now, I should talk, I think, a bit about what we're developing, specifically, because it's an undirected development. we're actually developing an entire blockchain stack, not just a blockchain, because just a blockchain on its own isn't particularly useful. You need the most obvious thing you do that's user-facing is you need a wallet. But under the hood of all that, well, you need an SDK

so that the wallet knows how to interact with the blockchain. In addition to that, well, the smart contracts that run on the blockchain, they need some way of being written. They need some way of being tested. And then you also need things like analytics. Just because you have some contract running on chain, well, you need some way of actually indexing all the things that are happening. So all of those things, from the language to the tooling, to the testing, to the debugging,

to the deploying, to the indexing, to the new node, to a new virtual machine. All of that is being built in-house. in one unified integrated tool chain that is like an iOS-like experience so that it's not fragmented, it's not, oh, I don't know if I'd use an external plugin, which one of the file do I choose,

which one is maintained, which one works with the latest compiler. You don't have to ask any of those questions. It's an integrated iOS-like development experience where everything works together. So we're essentially building the entire stack, and this is maybe why it's taken a bit of time. That being said,

I think we're still ahead of various roll-up teams that are trying to do much, they have much less lofty goals. They're just trying to build a blockchain. Various projects are still trying to actually build out, and there's still an active development, just a blockchain. We have an entire blockchain stack that's going to be launching on TestNet soon and may not be not too long after and its entire stack. You know, one thing you mentioned was creating this iOS-like experience and fuel places a lot of emphasis on developer experience and aims to offer better tooling, a better experience than what is currently offered by, you know, maybe more narrowly focused EVM-based roll-ups.

Why is developer experience important to you? And how does fuel unlock improvements over EVM, for example? Sure. So to answer that question, a lot of roll-ups advertise as themselves being EVM-compatible, so you can use your favorite Ethereum tools, right? But if you told someone, hey, you can use Truffle with your roll-up today. And that was the selling point of the roll-up. You could use truffle today.

It's EVM-compatible. Everyone would laugh at your face, and they would call you an idiot who doesn't know what the fuck they're doing, because no one uses truffle anymore. It's an Ethereum tool that was very popular a couple years ago, and then it fell out in favor of hard hat. And if you told someone, hey, if you told someone today, if you told someone six months ago, it's compatible with Hardhat and nothing else, maybe they would pass. If you told someone today is compatible with hard hat and nothing else, they would again laugh at your face. Because no one uses hard hat anymore. Everyone is starting to love this new development tool chain called Foundry, spearheaded by Georgius Constantobulus. It's a very, it's a, it's a, it's substantial, as having used it myself, it's substantially better than what, uh, than what hard hat and especially truffle were.

But it still has a long ways to go until it reaches feature parity with a new, experience parity with what we already currently offer. for fuel, which is the fork tool chain, the fuel orchestrator. So the fact that a roll-up can tell you it works with your favorite Ethereum developer tools is essentially irrelevant because these favorite tools change every few years. It shows you how much value there actually is in that. People don't mind migrating to new tool chains if they did. Hart Hat would have never taken off and Foundry would have never taken off. People will migrate to new tool chains if they are substantially better than the status quo, and this is what fork offers.

So it's the very little things that add up. It's little things like if you want to have dependencies in a solidity project, well, dependencies don't actually exist in solidity. It doesn't have the notion of importing a file. You actually need your tool chain, and every single one of these tool chains, Truffle, Hardhat, and Foundry do, importing of dependencies in slightly different ways that are incompatible. And it's a source of endless frustrations. One example of this is I actually opened an issue in the Truffle repository that for three years, I think, didn't get fixed.

It's still open. I closed it recently because no one knew the Truffle anymore, and I wanted to clear up my issues. But like the Truffle developers didn't even take a look at it in the past 30 years. It was essentially if you're trying to import a file that includes the word import in its file name, then this will fail. Because again, solidity is not what's doing with importing. It's the tool chain. Rust is a very, it's like a paradigm shift in language development because rust is not just rust, the language. It's rust plus cargo. It also includes an entire tool chain called cargo

that is building, testing, dependency management, dock building, linting, and so on, all on a single a unified tool chain called cargo. And it's, Rust has essentially taken the world by storm because all the previous languages like C or C++ or Java or Python or whatever operated very much like Solidity does today. Fragmented ecosystem, not a lot of focus on tooling,

a bunch of pontification about useless language features that no one really ultimately cares about. Rust just came in and essentially just demolished all of them. Everyone is crazy about Rust because not only is the language better, the tool chain is miles ahead. And this is what we're building with four. Dependency management is one example. That's a very big pain point for the solidity tooling.

Another thing is the sway. I guess I didn't say our high-level language is called sway. So is the equivalent of solidity. And four could be the equivalent of cargo for rust or hard hat or foundry or I guess forge in the solidity land. So our high-level language called sway, that the sway compiler built from scratch using rest. The sway compiler can do things that the Ethereum compiler wouldn't be able to.

Or if the, not that the Ethereum compiler, sorry, not that the Solidity compiler fundamentally cannot, but that the Solidity Compilered compiler just don't care about implementing any of these features. One example is reentency. Literally just this morning, like five hours ago or something, from the time of recording this call, there was an exploit on a contract. There's March 31st, 2022, so I can date this.

And there was an exploit in a contract that was revealed. They already fixed it, right? So this is a public disclosure of this bug. And it was a re-entrancy. It's March 31st, 2022, and there are re-entrancy bugs happening. Maybe it's just quickly for audience members who don't know what re-entrancy is. Can you quickly describe that? Absolutely.

So re-entrancy is when a contract ends up calling itself, and it ends up calling the same function again, kind of like in a recursive manner, but through another contract. So an example of this is the Dow hack. Someone had a function to withdraw your token, so they basically said, okay, first I'm going to call the token contract to withdraw the token. hopefully I'm not mixing up the exact specifics of the Dow versus how reentency works in general, but the DAO is vulnerable to a form of this exploit. So it's essentially, imagine this. You have a function that wants to withdraw a token. So it'll start by sending the token.

Then it will decrease your balance. The contract keeps track of everyone's balances. So first it withdraw the token, then it decrease the balance. This is like a natural, intuitive way of doing it. But the problem is if the token contract is malicious, or if you're withdrawing to a contract or something, that contract can execute code. And what it can do is it can actually call the withdrawal function again.

And since you have not updated the balance of the user, then the withdrawal function thinks you have the original balance. And it calls withdraw again to the same contract, which then calls the function again and so on. And you can drain an account in this way. This is why reentency is so dangerous. And it's fixed in one very easy way. It's that first you should update the balance,

like the contracts view of what balance each user has, and then you withdraw the token. So this is known the check effects interaction, because the effects is the updating of the balance, and the interaction is interacting with another contract. So send them some tokens. So if you do it in the order check effects interaction, instead of the bad check interaction effects,

then you're guaranteed that a re-entrancy is impossible. Or rather, if someone tries to do a re-entrancy, call that it just won't do anything, which is also fine. So the solidity compiler to this day will not warn you if you have effect after an interaction, right, even though it should be able to, because I mean, the Solidity compiler knows what code you're writing, it should see if you're trying to change some storage after you do an external contract call, that's a violation of the check effects interaction pattern, that's a potential a re-entency vector. Maybe you should warn the user. Solvitit compiler has not done this after

how many years has it been in existence? Six years. The sway compiler will do this for you. The sway compiler can also do amazing things with this type system. So one big example that was all over Twitter just a few weeks ago was this notion of payability, ABI method payability. So if an API method, so the API method being some function, you know, some function you can actually call on the contract. If it's marked as payable, then that means it can receive ether. If it's not marked as payable, then that means it cannot receive ether. So if you try to send ether, it will revert. And this is, you know, to protect user funds and so on.

Now, there's a problem with this, which is that if something is not payable, the EVM like bytecode, the contract that executes will actually. have a runtime check. In other words, it costs gas. It costs the real money every time you call this function. Even if you're not sending any ether, it still has a check if you're sending ether, it is to do a check. So not only do this increased contract size, which again, which you know increases the cost to deploy the contract, it also incurs a runtime cost every single time you cost this function, which could add up to, you know, maybe millions or tens of millions of dollars throughout the lifespan of all the contracts that do all these checks. Now, what happens, and this was on, you know, all their age on Twitter just a few weeks

ago is people to optimize their contracts, you know, the solidity optimizers, would actually just add payable to everything. They would just add a payable keyword because the payable keyword, but it actually doesn't do that check. So adding the keyword, ironically, is cheaper than not adding the keyword. So now you end up with contracts with just every function is payable just because it's cheaper, even if it's supposed to not be payable. And people are, you know, do this to save gas because gas is on Ethereum so expensive. Instead, if you have a compiler in a language with a proper type system, you can do things like at compile time, if you try to forward an amount that is not zero to an ABI method

that is not payable, then this should be a compile time error, not a runtime check that occurs some runtime cost. This should be done entirely at compile time, but this is something that the Sway compiler will be able to do. That this notion of payability is something that can be promoted to the type system. And this kind of stuff is known as a zero cost abstraction.

It's essentially moving stuff from runtime into compile time because presumably, you know, you compile once enough that you want the runtime to be as cheap as possible. And this is why Rust is so popular. This is why it's so fast. It's because it really fully embraces this notion of zero cost abstractions that other

high-level languages like Python for instance, of JavaScript do not have, those incur runtime costs for doing various things. And so does solidity. The sway language is modeled on Rust. It's a Rust-based language, and it fully embraces this notion of zero-cost abstraction. So it can do things like this,

like completely free, safe payability, just promoted to the type system. And these are the kinds of little things that really add up not just to performance of the smart contracts, but it ironically adds to security and safety of how you build smart contracts, because if developers, if smart contract developers are adding payable, you know, if they're adding payable everywhere,

smart contract developers are writing in-line assembly because your optimizer is not good enough, then they're writing contracts that have a fundamentally larger attack surface. They're fundamentally harder to audit, to read, to reason about, and could have a larger attack service or a larger bug surface, I should say. The safest, the way you can get the safest smart contracts is actually by making the language safe and optimized by default so that users don't have to be forced to go down

and do these hacky things to squeeze out every last bit of gas savings. Users should just write the language as it is and that the compiler handle everything. And that's what Sway will provide. That's super interesting. And thank you for going into all of that detail to kind of display why something like Sway is so much so powerful. I guess one question I have based on that is given all of these challenges that solidity presents, why has it persisted in the way that it has?

There's a very simple answer for this. And some people say it because Stilogy is like JavaScript is not going to go anywhere. It's around forever. Similarly, you know, people said C is not going to go around anywhere. No one is ever going to use Rust or I guess before Rust existed. No one is ever going to use language other than C for the Linux kernel. All those people are eating their hats. You know, Linux kernel is going to use Rust.

You know, browsers are being rewritten in Rust. Everything is being rewritten in Rust because the language is better. But also, the tooling in Rust is just so much better than what it is in C and C++ and any other language, really. The reason that solidity is the dominant smart contract language in the Ethereum space is not because solidity is good. It's because everything else is worse. And especially the tooling around everything else is worse.

How many other smart contract languages really exist? There's Viper, I guess. That doesn't even allow you to have libraries. right? The tooling around this is non-existent. There's FA, which doesn't actually exist. That's still an active development, right? You can't write anything with it. But what other smart contract languages exist? The answer is not many, and the ones that do exist don't have any tooling support.

Because the people who develop them, maybe they just develop the language, and they don't develop any tooling around this. A language without tooling is useless. And this is what Fuel is doing different than some other teams that have tried to just develop a language. which is that we're not just developing the language. We're developing the language and a whole complete tool chain that's modeled off of Russ' amazing tool chain. And it all works together nicely and uniformly. So we talked about sway versus solidity.

And now I know you have a lot of thoughts on this too, but maybe we can get into fuel VM versus EVM. And something you said earlier was, you know, fuel allows you to handle state. much better and maybe maybe that fits into this discussion. So could we talk about that a little bit? Yeah, so the, I actually gave a boot camp to some nice, energetic young solidity developers, not too long ago.

It's the Fuel VM boot camp that's on Fuel Labs' YouTube channel. And I think it's probably linked to some other places, but you can search Fuel VM boot camp if you want me to go, if you want like an hour long discussion on some nitty grid, nitty gritty details. Yeah, I'll link that in the show notes.

Yeah. Oh, thank you. Okay. I'll ping you later to give you an exact link. So to give you kind of like the intuition, sorry, the intuitions, the high level core ideas of what makes it so,

so much interesting than just another EPM or just the EVM period. It supports, for starters, it supports parallel transaction execution. So unlike the EVM, where every single transaction, transaction must be executed sequentially, which, as you may imagine, is kind of not great when modern processors, their single core performance hasn't really increased that dramatically in the last 10 years. But, you know, not looking at now versus 10 years ago, processors have many, many more cores.

They can support many, many more threads. So you kind of want to leverage that because their single core performance hasn't improved much. So just unlocking parallel transaction execution with nothing else would already be an amazing improvement. Literally, Solana's primary distinguishing feature over the likes of the EVM is the fact that it enables parallel transaction execution. But Solana does it at the cost of a lot of added complexity and a lot of unsafety. And this is why you see there's various hacks on the slana programs and stuff because they forget to check accounts. they forget to do, you know, they forget to do things. You're not going to forget to do things with sway and the fuel of EM

because there's nothing to forget. It's going to be a much safer to write code in because it's not just like, you know, Slana is where it's not just untieped buffers floating around. So it supports parallel transaction execution. That's like the primary thing that, you know, just will hit you, hit you right in the face as soon as you walk in the door. there's a bunch of subtleties in the VM

that make it fundamentally better for what Ethereum's workload happened to be that when Ethereum was created, they didn't really know Ethereum would be used in this way. One example is a lot of the traffic on Ethereum involves moving around fungible tokens. Well, it would be nice, sorry,

a lot of the traffic in terms of the gas cost, but I should also say that moving, around tokens is actually a very scary operation, and you don't have to look farther than re-entrancy. Because of the fact that tokens on Ethereum are represented as just literally entries in a smart contract storage. They don't have a notion of, you know, a die token actually existing. It's literally just there's some field in the storage of the contract that happens to be called balances in the solidity code, but that, you know, the EVM doesn't know what this is, it's just some storage field, and that represents the user's balance of die. But there's

no notion of die as an actual thing in the EVM. So when you try the transfer die, well, you're doing a smart contract call, which an avi smart contract call you do is to an untrusted smart contract, which can call the contracts, can reenter, can do, can execute arbitrary a code. It's very scary. And there's like many subtleties around literally just transferring tokens. That's not as easy as just, oh, just transfer. No, no, no, no. Like you can talk to people who deal with Ethereum security and stuff and they can talk all day about how to transfer tokens properly,

which would already tell you that there's something fishy and something wrong going on here, that no one can just tell you, just do this. There's always considerations. Most recently, I remember a good friend of mine, James Press, which I think talked to, about this bug, not a bug, sorry, an exploit, where essentially if you tried to do, if you did a contract call and you wanted to forward only a certain amount of gas,

you know, let's say, yeah, I say, okay, I'm going to do a contract call, you only get 10,000 gas. You would think that that contract can only use 10,000 gas and it can use them more, so it can't agree for you. It turns out it can, because what it can do is it can return to you a huge amount of data, and then you have to process that data, and that could end up consuming a million gas, and end up costing you thousands and thousands of dollars. And there's nothing you can do to stop this purely at the, you know, calling of the contract

because this is returning data to you. And it happens, this literally, you know, baked into language, doesn't have features to prevent this from happening. So, okay, so now you need a safe transfer, and then you need extra safe transfer and so on. Right, there's like, just go to 10 levels deep. Just token transfers. We're like, we haven't even gotten to, like, any of the other complex smart contract parts.

So one thing the fuel VM has is multiple native assets. So a token is, actually exactly the same as the native asset. Let's say ether. If you have a fuel instance on top of Ethereum that uses Ether that uses Ether as this native asset, the Dye token or whatever is exactly the same first class citizen properties as Ether.

You can transfer it with a contract call just like you would Ether. You don't have to go through a separate token contract. So this already on its own, without doing anything else, already eliminates a huge class of vulnerability dealing with token transfers. There's a bunch of other improvements to the VM. It's a register-based VM instead of stack-based.

This will allow it to be much more performed because it reduces the overhead of gas accounting. What other things are particularly interesting without going too much into detail? Yeah. So one thing that, so we talked about, you know, parallel transaction execution as one of, one of fuels like core features and advantages. We talked about how something like Sway and the compiler,

what's it called? Well, the Sway compiler is called the Sway compiler, but the fork is the tool chain. Sorry, the tool chain, yeah. It facilitates like greater security in building these applications. Another feature that you've talked about is flexible transaction throughput. Could you talk about that a little bit? Yeah, so what fuel provides isn't just, you know, a high scale, high security, both in terms of the fact that it's a modular execution layer. So like the fundamental blockchain security, but also smart contract security. It also provides all of these features while also being flexible. So it allows you to build sharing complete smart contracts that are expressive like, not only are they expressive like Ethereum contracts, that are actually more expressive, like strictly more expressive than what you can get out of Ethereum and the UVM.

And this is different than some other platforms where, okay, they might say, okay, you know, we're highly scalable, we're highly secure. But you can only do a small fraction of what you can do in Ethereum, and that's the cost you have to, you know, that's the sacrifice you have to make to get that scalability and the security. In our case, fuel, it can provide all of those great, you know, benefits of decentralization and so on. and I can provide you with a way to execute transactions that's strictly more flexible than the UVM. Okay. I want to zoom out a little bit. And since we're coming up on the hour, I want to talk about, you know, how has your experience building fuel informed your, you know, building Celestea? How do they complement one another? And I guess how do you envision? you know, five, ten years from now, where fuel will be and where Celestia will be.

Sure. So I think of fuel and Celestia as solving two sides of the same problem, two sides of the same coin, which is that you want to have a highly scalable blockchain, not a blockchain, but you want to have, let's say, you know, high throughput, high decentralization, high security, smart contracts to execute so users can use them.

That's like the ultimate goal. Now, a data layer, even if it's highly scalable, if you don't have an execution layer, if you don't have a highly scalable execution layer, the fact that the data layer can fit a large number of bytes per second is essentially irrelevant because that's useless. The interesting thing about blockchain is not the fact that they can just, you know, fit zeros and ones together,

but that we can all agree on a shared state. We can all agree that Alice has five coins and Bob has three coins at a particular time. If all we know is just some zero and ones, that's not particularly interesting. So we need execution on top of a data layer, some sort of execution. It doesn't actually even need to be a blockchain-based execution.

It could be something exotic we haven't even thought of yet, but need some sort of execution. If not, the data layer is much less exciting. Fuel, likewise, on the online, On the other hand, rather, it's an execution layer. So it's built to be highly scalable. It can actually execute transactions, but it's not very useful if the data layer that runs under it that it uses can only process a tiny number of bytes per second,

which is what we see currently with current blockchains that are not optimized to be data layers. Blockchains that have other things, other processes using our resources, things like Ethereum, for example, right? The EVM is turned complete. it's richly stateful. Those all use up resources on the full modes, resources that could be used for bytes per second, just raw data availability. And that's why the data availability throughput of Ethereum is so low.

So, you know, an execution layer with a very, you know, very unscailable data layer is not interesting. A data layer with a very unscailable or no execution layer is also very uninteresting. So to really solve the blockchain scaling problem, you need to tackle it from both sides. And this is why both of these projects are so interesting to me. And both projects have essentially worked synergistically to each other in terms of how they're designed, because I did mention at the beginning, I designed protocols.

So it's a little thing like the Merkel trees that are proposed to be used in Celestia. That the cosmos ecosystem is particularly interested in this new Merkel tree design called a sparse Merkel tree that has many nice properties over the previous day trees that have previously been new. for other blockchains like Ethereum or like Cosmos. Fuel is using literally the same specification, the same Merkel tree, it's just implementing it in rust instead of Go, like Celestia's implemented and Go. So it's using like Celestia spec-compliant merciletries, for example.

Why? Because, I mean, it works for one, it should work for the other, right? It's a good data structure. Fuel has also kind of informed how certain parts of Celestia were designed from coming from an execution point of view, execution layer point of view. One example is we have this thing called optiment in Celestia,

which is, I'm not even sure what it's a part of Monteau of anymore, but it's essentially a replacement for tendermint, but that posts its data to Celestia, as opposed to using, you know, tendermint consensus and using the tendermint, you know, block propagation, all that stuff, it posts its data to Celestia.

Now, if you're trying to run a roll-up directly on top of Celestia, like a roll-up chain, directly on top of Celestia, they use the Celestia only, and it has its own, you know, intrinsic settlement, it's its own settlement layer, for example. You need some way of posting block headers and block bodies to Celestia. And the naive way is obviously a block header is called a header, so you post it first, and then you post a body, body, right? I mean, it's literally called a header. So obviously it should go first. That's the, you know, intuitive way of doing it. But while thinking about how would I run fuel on top of Celestia, it turns out that if you put the

header first, then the body, that this messes up certain guarantees you get around ordering of bytes. And what you should do is you should actually put the body first and you should put the header, or if you want to call it a footer, last. And if you do it that way, you actually get certain nice guarantees that allow you to prove some things compactly. There's like, I wrote an ADR in the Celesteo about this, if anyone is curious about some of the technical nuances of this decision. but this is something that I got as I was thinking of, well, how to implement an actual execution layer on top of Celestia, how it fuel work, and this is what led me to this particular design choice.

So there's a lot of interplay between the two projects that they synergistically build and help each other. Yeah. You know, I think initially when I heard that you're obviously playing a really core role in both of these projects, I mean, that just seems like a very challenging day-to-day, But like you said, there's so much synergies in being involved deeply in both projects that help you build, you know, the best execution layer and the best consensus and data availability layer. So that makes a lot of sense.

One thing I also wanted to ask you was, you know, I think Ekram at Celestia hosted a great Twitter spaces with you and Eric Wall and some others. and one of the questions was something like, what are you most excited about? And you said innovation in execution environments. And I'm sure you were referring to fuel, but maybe expand on that as it relates to fuel and maybe even beyond fuel, if you have any thoughts there. Yeah, so the most obvious connection is that it does relate to fuel.

But in a broader sense of the Ethereum space is, I think a lot of Ethereum maximalists have taken the defensive posture of saying the EVM has won, no one will displace the EVM, EVM the standard, and any chain who doesn't try to do the EVM will die and lose. The issue with this maximalist approach is that it kind of puts you in this cage, in this box, that you need to support the EVM as it currently exists, because if you accept that the EVM isn't the standard, then that means other chains have the potentially to beat Ethereum, which is, of course, a very dangerous prospect to even think about, right? It's a thought crime for the Ethereum maximalists.

The truth is actually the exact opposite, which is that Ethereum is not stuck with the EVM. Once we accept that Ethereum is not stuck with the EVM because execution layers allow you to experiment with new execution models without losing security, then suddenly you realize, the EVM isn't, it doesn't have to be the standard. Ethereum can win.

It can succeed. It can be the best blockchain. Even if the EVM ends up completely failing, even if no one ends up really using the EVM for anything substantial in the next 10 years, that is fine because everything can happen in execution layers. And that is modularism, not maximism. That with the advent of modular execution layers like fuel, we will see experimentation beyond the EVM on Ethereum,

not directly, but through execution layers, so that they will still have the same security as Ethereum. They'll still have the same decentralization principles that Ethereum started with and that distinguishes it from blockchain like Solana. And they'll be able to have, you know, they'll actually be able to progress and grow these execution layers. We'll be able to evolve them.

We won't be stuck with an ossified EVM forever. The EVM does not have to be stuck. Sorry, Ethereum does not have to be stuck with the EVM as you currently know it. It has the opportunity to expand beyond it with systems like fuel, and we shouldn't waste this opportunity being EVM maximalists because Ethereum is not the EVM. Ethereum can go beyond it. And one last question that I have for you, and we talked about this a little bit as it relates to the discussion on Sway versus solidity and how Sway optimizes for a better developer experience, that that's obviously trickles down to end users.

So maybe just could we go a little bit deeper on that? Because, you know, I think one of the key barriers to entry to the space is still the user experience. So how do the design decisions that you've made in building fuel trickle down to the user experience of applications that are building on fuel? So one very powerful thing that will be directly facing end users is since we're building the entire blockchain stack, one thing we're doing is we're making the functionality that our node can provide if you turn on some flags, not by default, but that the node can provide if you turn on some flags much more than what Geth provides, the Go-Eetherium implementation. So, Geth, for example, doesn't really let you debug a transaction, which is kind of bad because, you know, I mean, it's the leading Ethereum implant. It's essentially the only Ethereum implementation that people actually use in production. You'd expect it to, you know, I would expect to be able to debug a transaction, you know, to step through it and stuff, but I can't do it. I have to go use something else.

I can't do things in Geth, like simulate a transaction and see how much gas it would use. I have to do weird things, like do some bisection thing to estimate. the gas estimation on Ethereum is some weird bisection game, where they essentially cut the gas in half or whatever until they find some point where the transaction no longer reverts. But Go Ethereum should just provide some nice mechanism in how it estimates gas. There is an estimate gas endpoint, but it doesn't do the nice thing. It just does some weird bisection game.

But it should provide these things. So since we provide the entire blockchain stack, including our full node, it means we can do things like the developer-facing experience is things like debugger. But from the user-facing experience, you can get nice things like proper gas estimation. You can get things like a simulated execution of your transaction. So before you even sign your transaction, rather than saying, okay, I sign a transaction and it goes off to who knows where, I don't know what's going to happen with it,

you can actually simulate your transaction against the node and see what its results, what the outcome of that transaction might be. And like Ethereum mall, it's just don't show you this. Like if you go do unisop trade, it doesn't actually tell. you when you sign the transaction, will it revert or not? And so many times people sign transactions and it reverts because it's out of gas. That should never, ever happen. There's no excuse whatsoever for you to run a transaction and it to run out of gas in a way that's like obviously it doesn't have enough gas. Not like if it's, maybe it's off

by 10 gas, but like there should be no way that it just catastrophically runs out of gas because the wallet should tell you. But the wallet can't tell you because go Ethereum is too primitive. the theorem full nodes are too primitive in this regard. So the way that the user is going to immediately see a much better user experience, like the user and not the developer, by using fuel is that our full node actually allows you to have much better estimations around things like gas or transaction outcomes, and this will be directly visible in wallets, for example.

John, it's so incredible to hear how thoughtful and intentional that you've been in building fuel and obviously Celestia and and, you know, how you're really thinking about each and every stakeholder involved. So I'm super excited for a future where both fuel and Celestia are live. It's been such a pleasure to have you on the podcast. Thank you so much for all the time and for taking us down so many different rabbit holes and and explaining things in the way that you have. You mentioned a lot of talks that you've given, which I'll definitely link in the show notes,

because I'm sure people will want to go deeper after listening to this conversation. But thank you so much. As a last question, what's the best way for people to stay on top of what you're doing at Fuel and Celestia and you personally? Yeah, so you can follow us on Twitter at At Fuel Labs underscore.

Although my personal preference would be if we followed us on GitHub, the organization is just Fuel Labs, where basically all our work is just in public repos. So if you want to follow along, if you want to start experimenting with Sway, the Sway repository under the Fuel Labs org, or if you want to open some PRs and contribute to the project, there's many good first issues across our entire organization. We are hiring actively across basically any role whatsoever. So engineering, non-engineering. If you can think of it, we're probably hiring for that.

If there's not a direct posting, also you can reach out to us via DMs or whatever. So we have a job posting site that you can find via site. If you want to follow me directly on Twitter, I'm at J. Adler Zero. The Zero was actually chosen intentionally because you can type it easily without having to press shift on your phone. to do like most people use an underscore but underscores are hard to type because you have to like go through it to a shift and then press the underscore so the zero was actually intentionally chosen instead of an underscore very clever um and i'll definitely link all of those thank you so much john thank you for having me it's great to be on