Bankless - Alpha Leak | The Bull Case for Modular Blockchains

Episode Date: December 8, 2022

In this episode, David is joined by Co-Founder of Fuel Labs and Celestia, John Adler. Fuel is the fastest modular execution layer and Celestia is the first modular blockchain network. John and David explore how modular blockchains are shaping the future of the space, what Fuel is, why it’s different than other L2s on Ethereum, why John believes Fuel is the leading L2, and so much more. ------ 📣 Opolis | Get 1000 $WORK and 1000 $BANK https://bankless.cc/opolis  ------ 🚀 SUBSCRIBE TO NEWSLETTER: https://newsletter.banklesshq.com/?utm_source=banklessshowsyt  🎙️ SUBSCRIBE TO PODCAST: http://podcast.banklesshq.com/  ------ BANKLESS SPONSOR TOOLS: ⚖️ ARBITRUM | SCALING ETHEREUM https://bankless.cc/Arbitrum  ❎ ACROSS | BRIDGE TO LAYER 2 https://bankless.cc/Across  🦁 BRAVE | THE BROWSER NATIVE WALLET https://bankless.cc/Brave  💠 NEXO | CRYPTO FINANCIAL HUB https://bankless.cc/Nexo  🔐 LEDGER | NANO HARDWARE WALLETS https://bankless.cc/Ledger  ⚡️FUEL | THE MODULAR EXECUTION LAYER https://bankless.cc/Fuelpod  ------ Topics Covered 0:00 Intro 3:56 John’s Background 5:30 Creating Optimistic Rollups 6:56 Fuel’s Design Choice 9:50 Defining a Rollup & Modular Execution Layers 18:00 More Modular L2s 18:53 Fuel Flexibility 20:36 Data Compression 21:24 Fuel VM 26:55 The Fastest 35:27 Reducing Waste & Speed 38:42 Fuel Origin & Roadmap 48:59 Fuel’s Growing Ecosystem 52:36 Where Are L2s Going? 1:00:50 Call to Action For Listeners ------ Resources: John Adler https://twitter.com/jadler0  Fuel Labs https://twitter.com/fuellabs_  Celestia Labs https://twitter.com/CelestiaOrg  ----- Not financial or tax advice. This channel is strictly educational and is not investment advice or a solicitation to buy or sell any assets or to make any financial decisions. This video is not tax advice. Talk to your accountant. Do your own research. Disclosure. From time-to-time I may add links in this newsletter to products I use. I may receive commission if you make a purchase through one of these links. Additionally, the Bankless writers hold crypto assets. See our investment disclosures here: https://www.bankless.com/disclosures 

Bankless Nation, welcome to this episode of Alpha League, where we are talking about Fuel Network with John Adler. Fuel Network is a layer two on Ethereum, but it's a different kind of layer two. And that's really what I wanted to explore here today. What about fuel is so different? Why is it built in the way that it is? Why does John Adler believe that he is skating to where the puck is going where every other layer two is to focus a little bit too much on the short term? In this episode, you'll learn about why fuel is being. in the way that it's built, how it's different from the Ethereum virtual machine and why the fuel VM, the fuel virtual machine, is new and improved and shiny and super fast and super executable and is going to be, according to John, the logical conclusion of a layer two. You'll also learn a little bit about the inner workings of fuel beyond the fuel VM, the other parts of the fuel network that make it tick, and overall just get John's philosophy onto the layer two space. Fuel is a sponsor of the bankless podcast, but that is not why we

are making this episode. We are making this episode so we can dive all the way down into the details that make fuel tick so we can learn more about it. So without further ado, we'll get into this conversation with John Adler of Fuel right after we talk to some of these fantastic sponsors that help you go bankless. The reality today is that five corporations control the entire world of social media. They own our names. They restrict our content. They monitor our every move. And their time is up. Thanks to our sponsor, Diso. Diso is a layer one blockchain built from the ground up to decentralize and scale social networks. With DeSo, you can own your own identity,

content, and social graph, and take it with you across hundreds of applications already built on the censorship-resistant DeSo blockchain. DeSo's storage advantages make it finally possible to build infinite state applications that can efficiently store and index large amounts of content and data fully on-chain. DeSo also offers multiple crypto-native monetization primitives

for developers and creators, including social NFTs, social DOWs, social tokens, and social tipping. So in order to experience the social layer of Web3, go to DeSo.com and claim your username. That's d-eso.com. If you've been listening to Bankless, you know that we're fans of the modular blockchain thesis.

The idea that blockchains will separate execution from data availability and consensus, allowing all three to become the best versions of themselves. And Fuel has built the fastest modular execution layer in the industry. By supporting parallel transaction execution, fuel unlocks significantly faster throughput for the web-free world. Fuel also goes beyond the limitations of the EVM with its own Fuel VM,

which is more efficient and optimized, opening up the design space for developers. And lastly, Fuel brings a powerful developer experience with its own domain-specific language, sway, and a supportive tool chain called Fork. With Fuel, you can have the benefits of smart contract languages like Solidity while adopting the improvement made by the Rust Tooling ecosystem, letting the fuel development environment go beyond the limitations of the EVM. If you want to learn more, there's a link in the show notes to see how you can get involved with a fuel network. In all of my years in crypto, I've never been hacked, scammed, or lost money to a thief.

And a lot of that credit goes to my Ledger Hardware wallet. The Ledger NanoX and the Ledger NanoS Plus hardware wallets allow users like you and me to secure and manage all of our crypto assets and our NFTs, all with the security of storing users' private keys offline and out of reach from hackers. The Ledger NanoX is the perfect hardware wallet for managing your crypto and NFTs on the go because it connects to you. phone with Bluetooth and has a nice big screen for easy transaction readings. Ledger has also upgraded the iconic Ledger NanoS and made the new Ledger NanoS device more Defy and NFT-friendly, making it the perfect hardware wallet for beginners. Ledger has truly maximized for both ease of use and security. So discover which Ledger device is best suited for your journey by going and visiting shop.

Dotledger.com. Welcome Bankless Nation to this edition of AlphaLeak, where we are talking to John Adler about Fuel Network. John, welcome to the show. David, thanks for having me. John, you want to introduce yourself a little bit and provide some background and how you got into crypto and will lead into that story all the way through to where we are now with Fuel Network. Yeah, sure.

So currently I am, I guess most recently and also currently, I'm one of the co-founders of Fuel Labs and also Celestial Labs, which are building two separate components of a modular blockchain stack, which we'll dive into a bit later. How I got into blockchain, this is a story that I feel like I tell this every podcast, but basically my old grad school advisor when I was in grad school at UFT was really into blockchain. He was involved in the early days of Ethereum and so on. So he's been around there for a while. One thing he likes to show students is this selfie he took with a Mount Gawks sign guy in Japan.

If you remember, this guy with a sign like giving back or Bitcoins or whatever in Japan when Mount Gawks happened. And then he has a selfie with that guy. So he's been around for a while. He kind of introduces students to blockchain. and then since then, you know, that's kind of where I got exposure. After that, I guess I went to consensus to do general layer two scalability research, so things like channels, plasma, and so on. That's also where I created the optimistic roll-up design paradigm,

or I guess at the time, it was called minimal viable merge consensus because it was intended to be minimally viable and not the end game. Since then, I think we've come up with slightly better construction, such as sovereign roll-ups and so on. But yeah, and then after that, I left consensus to start fuel labs and Celeste Labs. That's kind of the TLDR of my journey. So you created the, you said you created the optimistic roll-up design structure. Does that mean you created what we now know as optimistic roll-ups?

Is that what you said? Yeah, I guess you could say that. There was a bunch of competing and close design architectures floating around at the time, which should surprise no one, right? Everyone was kind of in a hodgepodge of various ideas with different parameters in terms of data availability, how to do validity and so on. But I was kind of the first person to at least publicly publish the exact construction that we now know is optimistic roll-ups that specifically has certain properties, such as it uses fraud proofs for validity, permissionless block production to ensure state liveness and data availability on the main chain. So combining these stability properties is something that other people hadn't written about before, which is kind of odd because if you think about it, it's not exactly a complicated construction,

but it's one of those things where it's like it's obvious in retrospect. But like at the time, people weren't really thinking about these kind of constructions. I think it's because at the time the prevailing narrative was plasma and people didn't like the idea of posting all the data on chain because they thought it was like it was a regression compared to the quote, unquote infinite scalability of plasmas. So because of that, people weren't too interested in that particular avenue of research. Okay, so you've been a, you started as a scalability researcher at consensus. You said you worked in state channels plasma and then ultimately became optimistic role of, which means you've seen the full trajectory of Ethereum scaling research

since day one, since like we started with like, oh, we're going to scale Ethereum with state channels, not realizing that that is limited. To where we are now with optimistic. roll-ups, but you've taken optimistic roll-ups in a slightly different direction than I would say is, like, the status quo where the status quo or something like arbitram or optimism, where they are trying to be EVM equivalent. You're gone off in a new direction. Can you talk about that philosophy or design choice with fuel and how it's perhaps different than the optimistic roll-ups than most people are familiar with?

Sure. So, first of all, it might be good to kind of give an intro to what fuel is, the TLD. is that it's the fastest modular execution layer. Okay. Fastest because it supports transaction throughputs, it's transaction throughput along, you know, proportional to the cost to run a full node that is better than any other modular execution layer out there.

And modular execution layer because it's something that's slightly more than just a roll-up. So we could perhaps talk about the modular execution layer part first. Sure. And then go to the fastest part. because the fastest part has like, it's one word, but it has like a million different cone as to why it's like that. Right. So the modular execution layer,

for those of you who, for those of you who aren't familiar with roll-ups, should I maybe give like a one-minute summary of a roll-up? Yeah, love it. Okay, so a roll-up is a blockchain, like any other blockchain, and it's attached to some data layer. And then... A data layer is like a layer one, like Ethereum or something else.

Yes, it could be Ethereum. It could be Bitcoin Cash if you're in 2017 and you're Vitalik. It could be Celestia. It could be eigenlayer if you want. It could be, it could be, you could actually have a blockchain that is its own data layer, kind of like Ethereum is today or like Solana is. It's effectively its own data layer. And we would call that kind of a monolithic. But then there'll be monolithic, yes. With a modular blockchain, the data layer is another completely separate blockchain. So a roll-up will post its data to a data layer, and it will progress its state transition function, just like any other blockchain does. And it will be able to allow users to verify that the blockchain is valid, but the roll-up rather, just so there's no ambiguity here.

It'll allow users to verify the roll-up is valid using either fraud or validity proofs or if we have any other acute construction to verify validity without actually fully validating the chain. because then it's not a roll-up, it's just like to the blockchain. Right. It's just like, I know, side chain or something. Right. So maybe one definition to unpack is like a roll-up is a blockchain that post its data, as in post its blocks to another blockchain. And that the fact that it's posting its own blocks to another blockchain makes it a roll-up, not its own independent blockchain. Is that a fair definition? That's a necessary but not sufficient condition.

Okay. You also need additional conditions such as you would need fraud and fraud, Fraud or validity proofs. And you would also need a mechanism for permissionless insertion of transactions into the roll-up somehow. Right. Because if you don't have that, then the roll-up can be halted or it can be censored. So you need all three, these three properties. So what's a module execution layer?

With a roll-up, most roll-ups, you don't necessarily need what's called a settlement layer. a settlement layer is a blockchain. It could be the same as the data layer, such as in the Ethereum model for roll-ups, the Ethereum acts as both the data and settlement layers. The settlement layer will verify these fraud or validity proofs, thus allowing you to have a two-way bridge of funds between the settlement layer and the roll-up.

You don't technically need that for a roll-up to be a roll-up, like you could have a sovereign roll-up that could be its own settlement layer or that could use another settlement layer, or just use peer-to-peer for verifying fraud or validity proofs. regardless, with a settlement layer, the settlement layer is concerned with this two-way bridge. And for a two-way bridge to work, what you really need for certain VMs or certain execution systems, what you really only need is for some state route to be valid.

As long as a state route is valid, or as long as the route of something, let's say withdrawals, is valid. that is sufficient, that is both necessary and sufficient, to have a two-way bridge. Now, the problem is that some roll-ups have taken this to an extreme in terms of optimization and have decided to forego everything else. So if you look at the Bitcoin design paper, right, Satoshi spends one entire section of the Bitcoin design paper talking about light clients, or simplified payment verification clients at the time, right? and he talks about, hey, let's put the transactions in a Merkel tree

so that light clients can actually get a Merkel proof to their transaction being included in a block. Right? And if you didn't have light clients, you wouldn't need a Merkel tree. Like full nodes do not care about a Merkel tree of transactions or even a Merkel tree of state. Like Solana full nodes, the Solana blockchain does not have a state route, like a Merkel route over the blockchain state,

all account balances and contract state. It doesn't have that. And full nodes, Solana full nodes still will run. but you can't have Salana-Ly clients, or rather, Slana has a weird way of doing like-clients, but let's say you can't have Salana-L-Ly clients just as a generalization without a state route.

Similarly, if you don't have a transactions route, you can't have like clients either. So some roll-ups have kind of taken the notion of, a layer two is just a roll-up, and it's just concerned with this two-way bridge and nothing else, and they've optimized away things like a transactions route, and they just have a transaction hash. and then you can't actually have an off-chain light client to the system,

which is weird, right? Because now you're running a roll-up, and okay, do you run, like, who do you trust in that case? Like, if you think about the model, who do you trust? If you don't have a roll-up light client off-chain that you can run, how do you know the roll-up is valid? Like, I guess you can trust that there's some powerful computer, like, you know, verifying it and so on. But do you run an Ethereum-full node?

Because if you don't run an Ethereum-full node, then you don't actually know the roll-up has any notion of validity or anything of that, right? So the trust model becomes very weird if you don't have off-chain like clients. In addition to not just like the trust model of has the roll-up being corrupted, but the trust model of even interacting with a roll-up, right? Because then do just trust in Fura to just give you all the data, honestly, right? There's no like Merkel proofs that your transaction has been included in the block. How do you know it has been, right?

You just have the trust in Fura completely. At that point, well, why I even have a roll-up? So a modular execution layer, if I can use an analogy, It's kind of like the difference between USB 3 and Thunderbolt 3, right? Where Thunderbolt 3 is basically, for those you who aren't familiar, the USB standards due to, you know, the, you know, designed by counsel is, you know, has a bunch of optional components. So you can get like a USB cable that doesn't include certain features, like let's say display. So you can get a USB cable that you say, oh, I can use this to connect like, you know, to a display, but like you can't because it only has power. Right?

like a Thunderball 3 cable has all the features, similarly to Thunderball 4 and USB 4, right? It is all the features. So you're guaranteed if you get one of this cable it's more expensive, but it has all the features, right? And that's kind of the analogy, is that just a roll-up and just a layer 2 will be kind of like a USB 3 cable.

You don't know what you're getting. And potentially you could want to do something and you can't. A module execution layer, you can think of it like a Thunderball cable where it's like a roll-up that has all the features. And one of the important features that it has is the ability to run an off-chain-like client.

So you have the properties of a roll-up, the trust-minimization, the permission-less, the trustless to a bridge, but you also have the ability to run a light client for that roll-up. And that allows you to really have, like, trust-minimized infrastructure. Okay, I'm going to need you to check my understanding on this.

I'm going to try and, like, regurgitate what you said, and you'll correct me in some particular way. Okay, so you're saying a lot of roll-ups, and you're talking about the Bitcoin white paper and Satoshi, emphasis on these light clients, emphasis on Merkel roots. And like my interpretation of just like what is a Merkel tree, what is a Merkel system, is a compression system. It's a system of putting a bunch of transactions

into a smaller bit of data. And by making that bit of data more manageable, you allow more people to verify it, more people to actually verify the validity of the transactions that happened. And so when you're talking about layer two that doesn't have this like like client enabled properties or just like any sort of like system for the layer two that makes it more manageable for other people to check the validity of. You're saying that it kind of runs into the same problem that Bitcoiners previously would critique

Ethereum of is like, yo, your nodes are way too big. Only so many people can validate the chain. What's the point of having a trustless system if like you're the ability to run a node? is so goddamn difficult that everyone has to just trust and fura. So you're saying that we need a mod, rather than just a roll-up, which is the USBC model, which is, you know, some one-off solution to create a roll-up, and all it does is verify the two-way bridge, so you can get your assets there, but it doesn't allow users to actually verify the validity of the chain because these chains are just not optimized. It doesn't have any sort of like compression tool, like a Merkel tree, for example.

and that means that no one can run a light client, which means no one can validate the roll-up that they're on, which means they're kind of just trusting the operators of that roll-up without being able to do it themselves. And you're saying a modular execution layer has solved this problem by producing a more abstracted layer two, a more abstracted, an abstraction layer between the Ethereum layer one or any layer one and the fuel layer two.

Is that at a fair conclusion? Check me where I got wrong here. Pretty fair, except the last part. I wouldn't say it as more abstractions. I would say it just has more features. Okay. Okay. So everything up to that last part is good.

Pretty much, yeah. It's not a bad analogy here. But yeah, so that's kind of where the module execution layer comes in. It's that, you know, we're really pushing for a system that isn't just a roll-up, and it's not just a bridge, but rather it has all those features that you would respect out of a blockchain today that allows trust-minitized infrastructure. So now we've done... It seems to be following the same trajectory of just like modularity in general, right?

So the Ethereum layer one is becoming modular. And I think maybe the generalized critique is that like something like optimism or arbitram or like a roll-up as we know it is like a monolithic version of a layer two. And you're trying to make a more modular version of a layer two. Is that also fair? You can say that, yes. That's actually not a bad way of putting it in the sense that traditional roll-ups. now they're moving towards being modular execution layers following fuels lead but like more these traditional lobes that you know issue everything except for the two-way bridge

you could that is not a bad analogy to think of them as more like a monolithic modular execution system whereas like they kind of tightly couple themselves to a very specific layer one and they say we must operate in this exact one one we must operate in this stack and nothing else okay so what kind of flexibility does fuel uh gain by this design choice by this design philosophy? So it gains, well, one it gains security for end users and two, it gains flexibility.

So, so just so clear, it's not just flexibility, it's also security. We cover the security just prior, so in terms of flexibility, it allows fuel to be run or deployed, rather, to,

there's last constraints on which layer ones it can use for data availability and settlement. If you don't tie the couple yourself to a very specific stack, you know, this is layer one, this is a roll-up. If you don't type of a couple yourself, then that means you have more opportunity to go in different ecosystems, right? So the fuel layer two can settle both its data both on Ethereum and Celestia and another layer one?

If you wanted to, yes. Okay, that's kind of what I meant about, like, abstraction. Like, as in, like, we could extract a way which data layer really is important to fuel. So there's no, there's no, like, layer or data layer that fuel really calls home. That's a good. And I think a large parts of our node just refer to the data layer as like DA layer as opposed to Ethereum. Right. If you look at some other chains, they'll call this specifically thing, Ethereum or they'll call it EVM. Right. In our case, we've tried very hard to abstract that away. Not out of necessarily any ideological like concerns about Ethereum, which there are none, but more about the more you tie yourself to any specific thing, the more like weird code that you might inherit without. even intending it. It prevents you from necessary, it prevents you, or rather, it makes it

it harder to ensure that your code is clean and free from like weird legacy stuff. Sure. And importantly, it's that light client Merkel tree aspect that we were talking about that enables this property, right? It is the compression of all the data into like a little nice, neat bundle of data that allows for that data to be able to go onto any data availability layer. Is that, is that correct? No, that's orthogonal. Those are two. two different parts. Like the fact that you can, the fact that, you know, you have the ability to run a trust. It's, it's not, that's not, that's not, that's not, that's not the only property that, you know, there's a difference between Thunderbolt and USB analogy here, right? There's additional

properties. That's a major one that I talk about because of security, but those other ones, like just building your software in a modular way, abstracting away, what is the data layer and what can it actually provide. That's, that's another property. Okay. One of the big new things about fuel is the fuel VM, which is a meaningful separation from the Ethereum virtual machine, which so many rollups, Arbitrum, again, Obitram optimism just emulate. They recreate the EVM as close to, close to the EVM as possible. This is not fuel's design choice. So talk about the philosophy behind this design choice and kind of how it fits into the overall broader fuel stack. Yeah, sure. So now we're getting to the fastest part. Yes, cool. And similarly to how the module

the execution layer has both a security component and a flexibility component, as does the fastest part. It has the fastest part, and it also has a flexibility part. So in terms of performance period, the fuel VM is designed based on the EVM, actually. So if you're familiar with the contract execution semantics of the Ethereum virtual machine and some of the nuances and gauches there, you can learn how the fuel VM works in like an hour. It's very simple because it's basically the EVM but improved, is what I like to call it. it has a number of architectural changes that aren't too important, I think, to dive into. Things like it uses registers instead of a stack, which leads to higher performance.

And higher performance, both in terms of register machine, like a program on a register machine being executed is faster than on a stack machine. And also because it reduces gas accounting overhead. but that's kind of like that's kind of getting a bit too much into the weeds. The kind of interesting things that the fuel VM brings to the table in terms of performance is the fact that it can introduce new instructions that wouldn't really be introduceable into the EVM without a lot of bike shedding. Along with all the architectural changes that will emulate certain EIPs on Ethereum or that, you know, implement them in spirit. So I'll give it a few examples. One of them is memory copies.

right people would really like to have a memory copy instruction because it would just make certain operations much much cheaper especially custom cryptography the current approach is you can delegate call into the identity pre-compile or sorry not delegate call i guess static call you can call into the identity to pre-compile and then you know copy your data and then get it returned and then okay you have your memory copy and that's fairly expensive because you know you have to call a pre-compile versus just an instruction and people wish that for things like custom cryptography, they had a memory copy instruction. Why can't you implement it? The answer is all because the EIP process is very involved. There's a lot of governance, complexity in the Ethereum space because you don't want to just accept every single EIP that people are proposed because then the EVM would get very bloated and be impossible to maintain.

And as we all know, public goods funding on clients is kind of fairly like. limited, which makes me somewhat happy that the paradigm team is now choosing to maintain a Rust EVM implementation. Because now at least we can be pretty guaranteed that at least we'll have one thing in this high performance. That is also rest, which is nice. That is maintained. And we don't have to worry about public goods funding as much.

But regardless, back to the topic at hand. So, you know, in the fuel VM, we have a memory copy. Boom. End of a story. It allows you to cheaply copy memory from one place to another. Hello, custom cryptography. Another example is transient stores. Sorry, can you can, so that was like pretty technical.

And for a non-technical person like me, I, I, can you just like really distill down the impact of that? Maybe for developers and for users, if it does impact them. It will impact people who want to build custom cryptography in the EVM and it'll impact people who want to use custom or use cryptographic primitives that aren't natively supported by the VM. So in the EVM, you have access to. let's say signature verification for Ethereum's curve. But you can't really verify signatures for other curves. One

popular curve, or one popular signature scheme is E. DDSA, as opposed to Ethereum's ECDSA. And EDDSA is used by Neer. It's used by Solana. It's used by Cosmos. It's used by a bunch of chains. But they shouldn't be using it because it's garbage. But regardless, they use it. People would like to, for instance, construct

a bridge. Like a, I think what do you have a rainbow bridge or something, right? They'd like to construct a bridge. But to verify verify each EDDSA signature with custom cryptography implemented in the EVM is on the order of one million gas versus 3,000 gas for an ECDSA signature verification. Like that disparity is on the order of, you know, three orders of magnitude difference. That should not be the case. Like maybe we're talking about a factor of two, three. I don't know, something like that difference is what it should be.

Not three orders of magnitude difference. So the fuel VM people will be able to and hash cloak is actually. writing. I think they wrote a BLS signature verification in Sway, which we'll get to Sway later, but they wrote it for the fuel game. So it'll be able to write custom cryptography, different hatching, algorithms, different signature schemes, so that you can do things like bridging to all their chains and whatnot, and you can do that reasonably economically. Okay. And so that's all about just like having one transaction or all transactions on fuel, just overall have like a smaller footprint on whatever data layer that it's,

down to, which is where we get this, like, fastest claim, right? Among other things, yes. Okay. All right. So tell us about, like, the current state of the fuel network. Like, when did it get started? What are you guys working on right now? Where is there a roadmap?

And where are we in that roadmap? Yeah. So, I was about more parts about the fastest. But, okay, we'll talk about this. Oh, if we're not done talking about the fastest parts, We should absolutely talk about the fastest parts. Sure. I have a few more to add.

Okay. Yeah. Where's next in the fastest? Yeah. Okay. So there's a few other EIPs that have been implemented. One of them is transient storage. Some people from Uniswap have been pushing T-Store and T-load, which are effectively

and see how I can distill this. So storage on Ethereum allows you to persist things across transactions, right? and memory persists only within a particular call. So if I call the UNUSOP contract, right, it has a memory and that persists only within this call. So you have two options. You either persist things across transactions or you persist things only within a call.

What happens if the UNUSOP contract calls, I don't know, the Dye contract, right? Then the Dye contract doesn't have access to the memory of the UNICEP contract. But it would be really nice if we get access to some memory or some storage, whatever you're going to call it, that persisted across the transaction, so across calls in a single transaction, and that was discarded at the end.

So it couldn't be used across transactions, but it could be used across calls. That's what T-Store and T-load are. There's an EAP for this. And it allows you to do nice things. One thing it allows you to do is it allows you to check for re-entrancy at runtime without having to use storage, which is very expensive. Then you can use T-Storage. All the things you can do, I mean, I don't know, there's a bunch of things you can do with this. So the fuel VM has a shared memory architecture where memory is persisted across calls.

Like, you can go into more like deep dive into the technicals, but the essence is that it has memory that is some storage location that is persisted across calls. So it already has whatever T store would give you. So you could wait, you know, whatever amount of time this EIP can, you know, can wait for while it's in the back burner to be implemented or you can just build on fuel. and so this is part of potentially the flexibility that I was talking about. The fastest is both performance but also flexibility. In terms of performance, it might also be worth talking about the fuel protocol itself because the fuel protocol isn't just a fuel VM. The fuel protocol is designed to run multiple instances of the VM in parallel

because each transaction in the fuel system declares which contracts it will touch. If you know which contracts two transactions will touch and they touch this joint sets of contracts, you can execute them in parallel because there's no hard dependency between these two transactions. So this allows us to execute transactions and therefore instances of the virtual machine in parallel. And that's kind of the overarching fuel protocol. So it's not just like a single VM that runs transactions one at a time. It's more like an orchestrator that runs multiple instances of the VM in parallel. And leveraging parallel transaction execution is also where we get a lot of

performance gains because modern CPUs haven't really increased their single core speed in like the past like 15, 20 years or something of that, right? I remember when I was a kid, I was playing Half-Life 2 on a single core Pentium 4.4 and I was running at like, I don't know, 4.2 gigahertz or something like that. I'm sure a lot of people had a Pentium 4 back in the day if you're my age. And that was like the fastest single core processor at the time. This was like right in the cusp of, you know, dual core processes started to become a thing. And you nowadays, I have, you know, on my desktop, my processor is what, like 4.8 gigahertz boost, right? So that's not even that much faster than 4.2, right?

And that was like, those like 20 years later. Oh, geez, I'm old. So, but what have processors done? Well, my processor has, you know, 30, I forget it was 32 or 64. It has a shitload of threads, right? And the old Pentium 4 had one thread. So, you know, that is, you know, almost two orders of magnitude, more performance. that is unused in a single core VM.

So with parallel transaction execution, then this kind of unlocks just using resources that are sitting there not being used. Like it doesn't require a more expensive machine. It's just those resources are, regardless of what CPU you buy nowadays, it's going to be multi-core. And it's going to have like at least a minimum of A-threads

unless you go really cheap and buy like, you know, an Intel atom processor or something. It's going to have at least, you know, A-threads. So, you know, those resources are unused currently in a single-thread at VMs. Might as well use them. So the first thing that you said is that the fuel network, you have a transaction that calls two different contracts, and we can have this.

Instead of having to call memory twice, there's only like one persistent memory. I'm going to mess up the way that's described. But like it's just like it sounded like just a more efficient way of accessing memory in the fuel network across contract calls, which like, again, limited developer experience, but it really just sounded like there was just like less resource load. per transaction in order to get a transaction done. That's a good way of putting it. And one thing we like to say is that we reduce waste. It turns out that a lot of ways people want to use the EVM have to use the EVM wastefully.

It's not necessarily even that the EVM must be inherently slow. And you must completely change the architecture because we didn't. The fuel VM is based on the EVM. It's that it turns out people want to use the EVM in certain ways. and the EVM doesn't have a good way of doing certain things, therefore people use wasteful ways of doing those things. They provide efficient ways. They use workarounds, which ultimately become wasteful

in terms of computational resources. Exactly. And we just provide efficient ways of doing those things. The Layer 2 era is upon us. Ethereum's Layer 2 ecosystem is growing every day, and we need Layer 2 bridges to be fast and efficient in order to live a Layer 2 life. A cross is the fastest, cheapest, and most secure cross-chain bridge.

With a cross, you don't have to worry about high fees or long wage. times, assets are bridged and available for use almost instantaneously. Across's bridges are powered by Uma's optimistic Oracle to securely transfer tokens between layer 2's and Ethereum. Across's critical ecosystem infrastructure and Across V2 has just launched. Their new version focuses on higher capital efficiency, layer 2 to layer 2 transfers, and a brand new chain with Polygon, all while prioritizing high security and low fees. You can be a part of Across's story by joining their Discord and using Across for all of your

layer 2 transferring needs. So go to across.TO to quickly and securely bridge your assets between Ethereum, optimism, polygon, arbitram, or boba networks. The Brave wallet is your secure, multi-chain on-ramp into Web3, and is built directly into the Brave privacy browser. Gone are the days of managing multiple wallet extensions that put you at risk of fishing, spoofs, and tracking. With the Brave wallet, you can securely manage your crypto assets across more than 100

different chains, including Ethereum, Layer 2s, Solana, and more, all without downloading risky extensions. The Brave wallet is easy to set up and removes the headache of jumping between wallets and extensions. It's lightweight but packed with great features, like built-in token swaps, buying and holding NFTs with a gallery view, and support for hardware wallets. But also much more than that, because Brave is shipping new features every single month, with the mission to make Web3 easier to navigate for its over 55 million users. Wall extensions are a thing of the past.

So get started with Brave's Web3 Ready browser today and experience a decentralized web seamlessly without all the clutter. You can download the browser at brave.com slash banklist and click the wall icon to get started. Arbitrum 1 is pioneering the world of secure Ethereum scalability and is continuing to accelerate the Web 3 landscape. Hundreds of projects have already deployed on Arbitrum 1 producing flourishing defy and NFT ecosystems. With a recent addition of Arbitrum Nova, gaming and social daps like Reddit are also now calling Arbitrum home. Both Arbitrum 1 and Nova leverage the security and decentralization of Ethereum and provide a builder experience that's intuitive, familiar, and fully EVM-compatible.

On Arbitrum, both builders and users, will experience faster transaction speeds with significantly lower gas fees. With Arbitrum's recent migration to Arbitram Nitro, it's also now 10 times faster than before. Visit Arbitrum. where you can join the community, dive into the developer docs, bridge your assets, and start building your first app. With Arbitrum, experience Web3 development the way it was meant to be. Secure, fast, cheap, and friction-free.

So there's something that you said in the very beginning of this, where it was like something about the relationship between the fuel stack, the fuel technology, and a full node. And it was like the fuel allows you to leverage the full resources of a fold node in a way that's not very wasteful. And this is kind of the theme that I'm gathering here is that a transaction on fuel is like minimalist in that it only uses the minimum amount of computational resources it requires to get to get itself. executed. And then also on top of that, you're adding like multi-core, multi-threading with the fuel VM. Is that kind of a simple way to explain what fuel is? Yeah, that is it. It's not like anything magical. Like, oh, you know, we used to be engineers at Qualcomm and how to build like kernels and shit on like routers. This is like very simple just reduce waste. Reduce waste in terms of, you know, make transactions. You can make transactions execute faster by making them waste less, right?

You don't need, like, you know, magical reengineering of anything, of hardware or anything like that. You just say, you know, waste, waste less. I know, boom, your transaction's faster. Is there any, are there any numbers that you can put behind this? Like, how many more times faster is fuel than, like, your typical optimistic roll-up? That is hard to say without optimizations in the sense that are, there's, like, a design aspect to it, like, do designing the protocol, and that does an implementation aspect. and the implementation obviously requires optimization work that is independent of like the fundamental design of the protocol our implementation is currently undergoing the like the VM implementation

is currently going optimization work as we speak it's been ongoing for like the past month or so that has greatly reduced overheads uh i think like on the order of 10x just off optimization work but until those optimizations are complete then it doesn't really make sense to give any numbers because if the overhead is so high because it hasn't been optimized out yet, then there's not really any comparison to make. But you really should be comparing against an optimized VLVM versus an optimized EVM. It's still a little ways away, but it'll be ready in the not too distant future. Okay.

Is there some sort of like, what number are you going for, if that's fair? What number do you want to see? Well, I mean, if you're, hopefully 100x on the same computer. 100x faster than a typical optimistic roll-up. Yes. Okay. So I know like Arbitrum likes to do an add-add-an-other-zero? They like to just say the, I think the last number we got out of Arbitrum is that we are seven times faster than Ethereum.

So there is like Arbitrum has seven Ethereum's worth of scale. I know that that measurement has offended other layer twos, but like if you want to, could like tell a normie like me, how much more scale does it have? That's like a nice thing to say. So like does it go and say that like, okay, then. fuel as 700 Ethereum's? I don't know, the zero. Just as that was like, no, I mean, I don't know zero to the 7X. So I don't know.

Something along those lines. Okay. Well, that's certainly a big number. Have we covered all the fast part of fuel? Yes. I think we're ready to move on to your previous question about roadmaps. Maybe we could repeat it in brief. Yeah.

So when did the fuel project really get started? what is the roadmap and where are we on that roadmap? It depends what even my fuel project. I guess I can talk about the origins of fuel. Sure. Which is that I think it was in 2019. Yeah, I think it was in 2019 when I left consensus to start it up with Nick and then Sam joined shortly thereafter,

very shortly thereafter. It was basically the three of us in a cave with a box of scraps subsisting off of a single small grant from the Ethereum Foundation and we launched Fuel V1 was it at the end of 2020? No, that seems too long. Okay, maybe we started this in 2020. The years are all fuzzy.

I think we started in 2020. We launched Fuel V1 at the end of 2020. And we had started, and Fuel V1 was just for payments. It was the first and currently only real optimistic roll-up, in other words, ones with A fraud-proof, B, permissionless, permissionless block production, C, posting data onto Ethereum, and D, no upgrade ability that exists on Ethereum today. And it was the first optimistic roll-up,

regardless of true optimistic roll-up or not, that was deployed to main in Ethereum. Right at the end of the year, December 31st. Just so we could say we deployed it in that year, a whole year before any other role. And that wasn't the end game. It was just for simple payments,

but it wasn't the end game. We knew from the beginning that we wanted to build a system that allowed Ethereum to scale, not just in payments, but that allowed Ethereum itself to scale. And that means general purpose smart project execution. And towards the end of that year, we had actually started working on what would become Fuel v2. We started thinking about the VM architecture. We started thinking about the language, and here's maybe some fun piece of history. We had actually talked to some people about if we had a VM interpreter in,

rust that we can file down to Wasam if we could use an interactive verification game over the implementation rather than the protocol itself. And this turns out, we had chatted with some researchers about this, and it turns out that that's the exact approach that both arbitram and optimism ended up unveiling as nice innovations in the future. What a good coincidence. So we ended up not going down that approach for various reasons. One of which is that you're tying yourself to a particular implementation and any weird bugs that that implementation may have any weird inconsistencies.

It also makes it harder to maintain. And one thing that's very important with these systems, and this will come into play of why we build sway, is that building and maintaining are not the same thing. You can sure build a system very quickly if you take some general purpose thing and run it over the implementation of your DM interpreter. But then how do you maintain it? then you have to like maintain two different instances of your VM interpreter, one that's, you know, that you can run quickly and one that you can run the IVG over. It's, it's very, it's gets very tricky on how maintenance is done. So this also leads us to our language, right?

We had also been thinking about what to do with our language. We looked into move. We were thinking of also of using the move VM, but the move VM is not designed to be fast and it's not designed to be flexible. It's designed for a very, very particular. in a very different way of reasoning about assets. And the move language was also very immature at the time. And I'll tell you in the past two years or so, since we looked at Move,

I think this was at the very end of 2020. Yeah, at the very end of 2020, the language really hasn't changed that much. Like, Sway has grown from literally nothing because it was created from scratch to the most mature blockchain development language in existence, if I do say so myself, from nothing, and so I, or sorry, and Move has basically not changed at all in the past two years. So it's a good, there's a good choice not to use it.

So in addition to, you know, it being immature and it following a weird different paradigm, one of the reasons not to use it is that it would be an upstream dependency. For anyone who's worked in an open source code base, it's really nice to use if your upstream dependencies are maintained, right? If they're maintained. If they're maintained, then you can use them. If there's a bug, you ask the maintainer, hey, can you fix this? Release new version and all's good. The problem is when it's not maintained, then you have a choice. You can either fork it yourself and maintain it yourself. So now you're maintaining some code that you didn't write. It's not in your style. It doesn't have the same conventions.

I mean, do you completely change the style to your conventions, right? And completely change how they do things to work with your conventions. At that point, it's like, can anyone else even use it? Or are you just solo maintaining it. And if it's like a big thing, that could be very, that transition could be very expensive and it could happen at a very inopportune time. So when it comes to building, sure, taking on an upstream dependency is nice and easy. It makes things fast to build. But again, it's not just about the building, it's about the maintaining. And having an upstream dependency like that, especially something that's like, you know, some software from Facebook, then Libra, then DM. Now it's, like, move is being forked to, like, different, their aptos has their flavor of move. Sui has

the flavor of move is like who even owns like is there even a single maintainer with a core move language I don't even know at this point right and having an upstream dependency of that is really really bad for maintaining your code so we chose to build sway instead right from scratch I feel like before I talk about sway is it maybe good to go back to the roadmap question I think sway and also the fork conversation are similar should we also talk about fork sure okay I can also let you lead if you have a direction you want to go in oh well I was going to finish kind of at talking I was going to finish talking about you know the timeline and roadmap thing as opposed to just diving into more tactical stuff

cool because this was more like a history lesson of you know how we got to where we are right we launched VLV1 we started thinking about field v2 and these were some of the things we were thinking about like move and then IVG and all the other stuff we ended up basically building the whole thing from scratch to avoid upstream dependencies and other issues of that. Since then, we've been building for the past two years. The organization has grown from, well, zero contributors other than the founders. I think we made our first hire in January, end of January, something like that. Sorry?

Of this year? No, of 2020. 2020. Okay. Or, no, 2020, 2021. Sorry. Okay. We launched field beyond the end of 2020.

and then we started building fuel v2 in earnest 2021 January up until now. So the past two years. Dates are hard. So, you know, we made our first hire. We've since grown to, I think, almost 70 contributors and the organization from no one back in the beginning of 2021. So I think we've done a pretty good job building out one of the best teams in crypto, especially, well, for sure, one of the best compiler team and just one of the best teams, period. across our whole stack and crypto.

Mostly engineers, believe it or not. Like 60 of those people are engineers. We really do need to hire more non-engineers. So if you are out there and you're a non-engineer, if you're into BD or if you're into public communication and content writing, if you're into project management, I'm trying to think of that, please read out to me after this because we always need more of those. So yeah, and then since then we've basically been building,

we launched a, oh sorry, for the first year, we built in stealth mode. And then on January 2nd, 22, so this year, so about 12 months ago, or 11 months ago now, to the date, actually. Oh, it's December 2nd. So 11 months ago, then we released all of our code base in public. Since then, we've actually been building in public. And there's an important distinction between us and potentially some other projects. But not only is our code all open source, our entire stack. except for a couple of minor components,

but those will change soon. We also build in public. Some other projects, roll up or not, will, for instance, build entirely in private and they'll release some blob at the end, and it's not even open source.

Or sure, it's open source, but they don't actually build in public. They'll, like, push things out, you know, push things out, just, you know, boom, here's something. We were working on this for the past year. Now you know about it. At fuel labs, everything we build for the fuel protocol is built in public.

And it's also planned in public. We don't have a private issue tracker that people can't see. You can go on our GitHub. You can communicate with people through issues, through PRs and stuff. And that's how we do our work. So it's a big part of our ethos. It's not just about the software and the blockchain. It's also about how is it built?

Because people are a very important part of our culture. So yeah. So we made all the code public at the beginning of this year. Since then, we've launched three TASNETs. One of them was for SwaySwap, a port of Uniswap, the hybrid of Unisovvvvvvvvvvvvvvvvvvvvvvvvvv ported to the Sway language, deployed to a private Devnet. Then we launched two public test nets, Beta 1 and Beta 2, each of these about two months apart, that had just increasing number of features, and increasing sophistication and stability and so on.

I think we are. gearing up for a beta 3 tasknet sometime early next year, let's say. That's kind of it for the, and that's kind of it for the spoiler. So there'll be a few more task nets. We're rapidly approaching a main at launch. What form that I'll take will leave with your future announcements. But yeah, that's effectively how things have gone in terms of development for the past couple, three years. So how will an ecosystem come to be on fuel? What's the idea behind that? Because if I'm understanding this correctly, you can't just copy and paste uniswap code

and deploy it to fuel. That's why you're talking about with some sort of iterated code to make it work on the fuel network. How do you expect an ecosystem to come to be on fuel? How do you expect that story to go? Yeah, it's not just how I expect an ecosystem come. It's, I can describe how an ecosystem came to fuel.

We already have a burgeoning ecosystem of very excited developers that are really engaged into the project and the language and just in a general ecosystem that have, you know, basically they've taken a look at Sway, they're taking a look at the VM and they're like, wow, there's so much better than any other chain I can get. Even today, and there's the early days with rough edges. Imagine like a year from now when we've polished all those rough edges even more. It's going to be insane. And we already have like, you know, a dozen or so projects that are building on us on Tessnet. We hosted a Twitter space with one of them,

Pool Shark last night on the sway you can look at the sway lang Twitter and it has a space from just just last night just last night if you're in eastern time I guess if you're in different time zones then it's not night and maybe not yesterday but uh you know they're building an amm that's concentrated liquidity liquidity if you recall it correctly right we have a few other ones like an nfti marketplace and some other stuff that are being built today so this isn't like we have to attract developers out of nowhere. It's like we already have an ecosystem of developers being built that are already here. And that's only going to continue to grow. Of course. Yeah. Do you have any like stats on users or daily transaction volume or any any stats of adoption like that?

That is something I don't have off the top of my head. I'll have to talk to our growth late on this. I'm sure she has, I'm sure she has some like a whole whole bunch of numbers and stuff, but that's not my area of expertise. I just do protocol design. Would data like that be something available in something like Dune Analytics or does the fact that it's a fuel VM make finding data on fuel a little bit harder because it's not as easily plug and playable as other roll-ups? Yeah, it's not currently as plug and playable

so it wouldn't appear in Dune. That being said, it's all on chain and the test nets are public. Like, beta 2 is a public test net. It has an open GraphQL endpoint that I know can query. I should also point out that it's not just like the fundamental protocol that has been improved over the EVM.

We also made improvements to things like we have a native GraphQL interface. So you don't have to use a third-party service like the graph, the index things, and then expose a GraphQL endpoint. If you're, you know, some, if you're like doing or whatever, right? We also have a first-party indexer service. So if you want to build an application and then, you know, run various indexing on that, you know, like things like, you know,

pools over time and like user, you know, accounts over time and all this, all this stuff, we actually have a first part. indexing service that you can plug into our node. You don't have to use a third party like the graph, wait for integrations, wait for all that governance and all that stuff. You can just use our index or boom. It just works. That's all like a single unified tool chain.

And you can get all your indexing done that you can then plug into analytics websites. You know, of course, it's not currently plug and play into June, but, you know, eventually why not? There's no reason that it can't happen. Or there's no reason you can't just run some GraphQL queries against the node on yourself because, again, the beta two network is public. And like, you can just, you can just, the block. chain, it's all in chain, as they say. Right? You just square the chain.

Do you have like an attitude or philosophy as like, is, do you, where do you think the whole entire broad landscape of Ethereum layer two is going? Because each layer two has its own kind of directional philosophy. Optimism is really focused on like their bedrock and OPET, OPE stack. ZK Sync wants to do its Prover circuit with a bunch of layer threes. Do you have any sort of like belief as to like where the broad landscape of all Ethereum layer twos will go. And I'm assuming, like, you think that fuel is kind of leading in a particular direction that you think is the right direction. But do you have any takes about, like, where the logical conclusion of Ethereum layer

twos go? So I think there's two facets to that question. One of them is potentially where do I think it's going to go in the short term. And the second is where I think it's going to go in the long term. Sure. So I'm pretty convinced in the short term that we're going to see two things happening. The first one is convergence around the EVM as a focal point, as it exists today. Other than fuel, of course.

So this will look like what we see today. We have a bunch of blockchains going, or a bunch of roll-ups going from, you know, I guess we're EVM compatible to, okay, now we're EVM equivalent, right? and then they're all going to deploy their solutions that are quote-unquote EVM equivalent. But then the next step to this, and this is still in the short term, is people will want more. They'll want more flexibility. They'll want more speed. They'll want more something. Right.

And we can see this already. You know, you have projects that talk about, oh, why don't we add account abstraction? Why don't we add native support for T-Store, right? Hey, you know, I'm on, I don't know, roll up. X, Y, Z, let's implement a store and get people who have been excited about it all this time to use us. People want more.

And you're going to end up, I think, in a weird scenario where well, okay, that's the long-term thing. We're going to talk a weird scenario in the long-term thing. Okay, so in terms of that, you know, people want more. People want improvements to both EVM and infrastructure like RPCN points and stuff. You know, they'll want parallel transaction execution

in a way that isn't a denial service vector because, you know, some people are saying, hey, let's, you know, apply a parallel transaction execution to the EVM with concurrent, concurrency. That's a denial service factor, or rather, well, it's a denial service factor or it does nothing, which is always the rock and a hard place. It either does nothing or it's a denial service factor in the worst case. Like, it is adversarial. And the our Ethereum team is using this approach, which is why I think they're using the wrong. approach, of course. Fuel is not using optimistic concurrency, right? It's using like enforced parallelism in the transactions themselves. And therefore, it's part of the actual consensus of

the chain. It's part of the rules, you know, that there is going to be an opportunity for parallelism. And then you can enforce certain payments and stuff around this. If someone doesn't, you know, if someone makes a bunch of transactions that are all targeting the same state, you should pay more and so on. Right. But you can do this as part of consensus because it's actually part of the transaction. It's not just some implementation detail like concurrency is. So what I think is going to happen is that people want more. And guess what? In that wanting more, that is fuel. Fuel is years ahead, plural of any other chain in terms of building the next step of the EPM. In terms of implementing these EIPs, like T-Store, in terms of count

abstraction, in terms of EIP 3074 for authenticated calling, in terms of flexible transactions with scripts. All of these things, fuel has from the beginning, right? So when people start looking for more, well, guess what? Fuel has been there for years, right? And we're years ahead of anyone else. So there's going to be no competition. There is no second best, as someone would say. So you're just saying that fuel is the philosophy of skating to where the puck is going. Yes. Cool. And that falls into what I foresee is what's going to be some long-term consequences of this EVM convergence, which is that as people want more, we have now crossroads. It's either people are going to, people are going to accept that they can't get more,

which is not good. Like I really wouldn't like that eventuality. Or people are going to just say, hey, let's use fuel, because fuel has, it has everything we want. It has all the more we want. And it's already implemented. We don't have to wait years. Right. It has better language, better tooling, better VM, better everything. Why wait, when we can just use fuel? That's, I think, the ideal scenario, both for fuel and myself personally and also for the Ethereum ecosystem, I think. Because there's a third scenario, which I think is really bad, which is that each of these roll-ups, which a lot of them have certain financial interest and political interests, are going to start pushing through Ethereum governance changes to the EVM that benefit them.

And if they don't get those changes, then they're going to start fragmenting. What is the EVM? right imagine if arbitram and optimism have two different ideals around some feature of ethereum right like arbitram really wants feature x optimism doesn't like feature x and thinks it should be feature y and an example of this is actually you know ethereum itself the bm like baselayer ethereum had such a thing happen where there were two competing proposals which ironically weren't actually competing necessarily but there were two competing proposals for how to implement bLS signature verification in the EVM, which I don't actually know why it was needed ultimately, because you don't actually, apparently you don't need it for withdrawals.

People are saying you needed it to enable withdrawals, but then it didn't happen. Then it turns out you don't need it for withdrawals. So I don't even know why it was needed. But regardless, I think the reasoning at the time was to enable withdrawals, which is, which we know, even that's pretty important, right? And that's still taking a while. So there were two proposals. One of them was implement BLS pre-compiles.

The other one was implement basic pre-compiles. basic pre-compiles for general cryptography that people could then use to specialize at the application layer instead of at the consensus layer for BLS specifically. Now, the BLS-specific ones, you know, maybe they're faster and cheaper, but then they're required, you know, you specifically need to know that BLS, the other one that's more general, right, but it could be more expensive. And there's like a bunch of fierce competition and governance around which one of these two should be accepted. Of course, neither of them ended up being accepted. But, you know, when you have a situation like this,

imagine if you have two roll-ups and each of them think, you know, one of these is better. What the fuck happens to governance then? Especially when these roll-ups are, when they say they're EVM equivalent. Like, do they just stop improving their chain and fuck their users and send them all to fuel? I mean, I would like that, right? And I think that may be the ideal scenario for Ethereum, because then it avoids this, this disaster scenario,

of all these roll-ups now competing with each other, for Ethereum governance. They're not competing with each other for users. They're competing each other over Ethereum governance and having a war through Ethereum governance for which features get implemented in the EVM because they have to stay EVM equivalent. And if they don't,

then potentially an even worse scenario happens where now each of these roll-ups branches off and has their own flavor of EVM and fuck EVM equipment. And then they call themselves the EVM. And it's like, well, what do you do with the solidity compiler? Do they each have a different version of the solidity compiler that can be used

for their flavor of the EVM? Like, then how do two? how do tools work and stuff, right? Like, both of these scenarios are really, really horrific. And that's what I foresee post-EVM convergence, that people will want more, and this more will lead to what I hope is the ideal case that people realize fuel is that more?

And it is bringing scalability to Ethereum and bringing improvements to Ethereum with all the security guarantees and trustlessness, and decentralization ethos and open-building ethos, that Ethereum really values and they'll go to fuel. Because if not, then it's looking very grim in terms of whether the long-term consequences of roll-up team is fighting on the Ethereum governance arena for their own purposes.

Well, John, this is why I love these conversations, because it's only developers that can actually think in these such long-term time horizon, like game theory scenarios. So that's definitely something that I now have to consider. So thank you for sharing that. Well, now maybe we won't sleep as well at night. Well, I've never been bearish on Ethereum actually being able to problem solve. But yeah, the problems do only seem to get larger and larger as we go out into the future. If you had a call to action for listeners, developers, whoever might be listening to this episode,

to help join the effort to make fuel success, what would you ask? I would ask that you keep an open mind and try it. You don't have to take my word for anything, but you also shouldn't take anyone else's word. right? Don't believe what you hear on Twitter necessarily, and don't believe anything you hear out of my mouth. What you should believe in is the code. Go look on our website. Go look at our docs. Go play around with our tooling and our chain and see for yourself that there is no second best. And where are all of the links to go get that done? Yeah. So if you want to, I mean, the main portal to everything is just fuel.network, the website, fuel.network. You can also look us up on GitHub directly, like GitHub.com slash fuel. Labs. You can follow us on Twitter, which is at Fuel Labs underscore.

Potentially that might be changing soon, soon AlphaLeak. But yeah, that's kind of where you can go to kind of get started on socials and just code and stuff. Awesome. Well, John, thank you so much for joining me on this AlphaLeak episode, speaking of Alpha Leaks, and explaining to me the fuel ecosystem. I appreciate it. Thanks so much for having me, David, and the Bankless Nation. Hey, we hope you enjoyed the video. If you did, head over to Bankless HQ right now to develop your crypto investing skills and learn how to free yourself from banks and gain your financial independence. We recommend joining our daily newsletter, podcast, and community as a bankless premium subscriber to get the most out of your bankless experience. You'll get access

to our market analysis, our alpha leaks, and exclusive content, and even the bankless token for airdrops, raffles, and unlocks. If you're interested in crypto, the bankless community is where you want to be. Click the link in the description to become a bankless premium subscriber today. Also, don't forget to subscribe to the channel for in-depth interviews with industry leaders, ask me anythings, and weekly roll-ups where we summarize the week in crypto and other fantastic content. Thanks everyone for watching and being on the journey as we build out the bankless nation.