Alpha Leak | The Bull Case for Modular Blockchains

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

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:01David Hoffman?

  Bankless Nation, welcome to this episode of Alpha Leak, where we are talking about Fuel Network with John Adler. Fuel Network is a Layer 2 on Ethereum, but it's a different kind of Layer 2. 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? And why does John Adler believe that he is skating to where the puck is going, where every other Layer 2 is focused a little bit too much on the short term? In this episode, you'll learn about why Fuel is built 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 2.

• 0:46David Hoffman?

  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 2 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, DESO. DESO is a Layer 1 blockchain, built from the ground up to decentralize and scale social networks.

• 1:29David Hoffman?

  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 DAOs, 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 E S O dot com. If you've been listening to Bankless, you know that we're fans of the modular blockchain thesis.

• 2:11David Hoffman?

  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 web3 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 improvements 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

• 2:56David Hoffman?

  to see how you can get involved with a Fuel network. In all of my years in crypto, I have never been hacked, scammed, or lost money to a thief. And a lot of that credit goes to my Ledger hardware wallet. The Ledger Nano X and the Ledger Nano S 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 Nano X is the perfect hardware wallet for managing your crypto and NFTs on the go because it connects to your phone with Bluetooth and has a nice big screen for easy transaction readings. Ledger has also upgraded the iconic Ledger Nano S and made the new Ledger Nano S device more DeFi and NFT friendly, making it the perfect hardware wallet for beginners. Ledger has truly maximized for both ease of use and security.

• 3:41David Hoffman?

  So discover which Ledger device is best suited for your journey by going and visiting shop-ledger.com. Welcome, Bankless Nation, to this edition of AlphaLeak, where we are talking to John Adler about Fuel Network. John, welcome to the show.

• 3:54Speaker 01

  Hey, David. Thanks for having me.

• 3:56David Hoffman?

  John, you want to introduce yourself a little bit and provide some background on how you got into crypto? And we'll lead into that story all the way through to where we are now with Fuel Network.

• 4:05Speaker 01

  Yeah, sure. So currently, I'm, I guess, most recently, and also currently, I'm one of the co-founders of Fuel Labs and also Celestia 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, uh, this is a story that I, I feel like I tell this every podcast, but basically my old grad school advisor, when I was in grad school at U F T was really into blockchain. Uh, he was involved in the early days of Ethereum and so on. Uh, so he's, he's been around there for a while. Uh, one thing he likes to show students is this selfie he took with a Mt. Gox sign guy in Japan. If you remember those, like this guy with the sign like giving back or give us back our bitcoins or whatever in, in Japan when Mt. Gox happened and then he was selfie with that guy.

• 4:50Speaker 01

  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. Uh, after that, uh, I guess I went to consensus to do, uh, general layer two scalability research, so things like channels, uh, 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 constructions such as sovereign roll ups and so on. Uh, but yeah, and then after that I left consensus to start few labs and celestial labs. That's kind of the T L D R of my journey.

• 5:30David Hoffman?

  So you, uh, 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, is that what you said?

• 5:40Speaker 01

  Yeah, I guess you could say that. Uh, there was a bunch of competing and close design architectures floating around at the time, which is, 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 as optimistic roll ups. Uh, that specifically has certain properties such as, uh, it uses fraud proofs for validity, permissionless block production to ensure state liveness, uh, and data availability on the main chain.

• 6:19Speaker 01

  Uh, so combining these stability properties is something that other people hadn't written about before, which is ki- it's 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.

• 6:31David Hoffman?

  Hmm.

• 6:31Speaker 01

  But like, at the time, people weren't really thinking about uh 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. Uh, so because of that, people weren't too interested in that particular avenue of research.

• 6:57David Hoffman?

  Okay, so you've been a, you started as a scalability researcher at Consensus. You said you worked in in state channels, plasma, and then ultimately became uh optimistic rollups, which means you've seen the full trajectory of Ethereum scaling research since day one. Uh, since like we started with like, oh, we're going to scale Ethereum with state channels, not realizing that that uh is limited. Um, to where we are now with optimistic rollups, but but you've taken optimistic rollups uh in a slightly different direction than I would say is like the status quo, where the status quo was something like Arbitrum or Optimism, where they are trying to be EVM equivalent. You're gone off in a, in a new direction. Can you talk about that philosophy or design choice with Fuel? Uh, and how it's perhaps different than the optimistic rollups than most people are familiar with?

• 7:42Speaker 01

  Sure. So first of all, it might be good to kind of give an intro to what Fuel is. Uh, the TLDR is that it's the fastest modular execution layer.

• 7:52David Hoffman?

  Okay.

• 7:53Speaker 01

  Uh, fastest because uh it supports transaction throughputs, uh transaction throughput along, you know, proportional to the cost to run a full node, uh that is better than any other modular execution layer out there. Uh, and modular execution layer because it's something that's slightly more than just a rollup. Uh, so we could perhaps talk about the Modular execution layer part first.

• 8:17David Hoffman?

  Sure.

• 8:17Speaker 01

  And then go to the fastest part.

• 8:19David Hoffman?

  Hmm.

• 8:19Speaker 01

  Cause the fastest part has like, it's one word, but it has like a million different conus to why it's like that.

• 8:23David Hoffman?

  Right.

• 8:24Speaker 01

  Uh, so the modular execution layer, for those of you who, uh, for those of you who aren't familiar with rollups, uh, should I maybe give like a one minute summary of a rollup?

• 8:34David Hoffman?

  Love it.

• 8:35Speaker 01

  Okay. So a rollup is a blockchain, like any other blockchain, uh, and it's attached, it's attached to some data layer. Uh, and then.

• 8:44David Hoffman?

  A data layer is like a, an layer, a layer one, like Ethereum or something else.

• 8:49Speaker 01

  Yes, it could be Ethereum, it could be Bitcoin Cash, if you're in 2017 and you're Vitalik, uh, 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 Lexalana is, right? It's effectively its own data layer.

• 9:07David Hoffman?

  And we would call that kind of a monolithic.

• 9:09Speaker 01

  But then there'll be monolith, yes. With a modular blockchain, the data layer is another completely separate blockchain. Uh, so, uh, a rollup will post its data to a data layer, uh, and it will progress its state transition function, just like any other blockchain does, and it will be able to, it'll allow users to verify that the blockchain is valid, but the rollup rather, just so there's no ambiguity here, allow users to verify the rollup 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. Cause that's not, it's not a rollup, it's just like to the blockchain.

• 9:47David Hoffman?

  Right.

• 9:48Speaker 01

  Uh, it's just like, I don't know, sidechain or something.

• 9:51David Hoffman?

  Right. So maybe one definition to unpack is like, a rollup is a blockchain that posts its data, as in posts its blocks to another blockchain. And that, the fact that it's posting its own blocks to another blockchain makes it a rollup, not its own independent blockchain. Is that a fair definition?

• 10:08Speaker 01

  Uh, that's a necessary but not sufficient condition.

• 10:11David Hoffman?

  Okay.

• 10:11Speaker 01

  You also need additional conditions, such as you would need fraud and validity.

• 10:15David Hoffman?

  Right.

• 10:15Speaker 01

  Fraud or validity proofs.

• 10:16David Hoffman?

  Yeah.

• 10:17Speaker 01

  Uh, and you would also need a mechanism for permissionless insertion of transactions into the rollup somehow.

• 10:23David Hoffman?

  Right.

• 10:24Speaker 01

  Uh, cause if you don't have that, then the rollup can be, uh, halted or it can be censored. Uh, so you need all three, these three properties. Uh, so.

• 10:34Speaker 01

  What's a modular execution layer? With a rollup, most rollups, you don't necessarily need what's called a settlement layer. What a settlement layer is, a blockchain, it could be the same as the data layer, such as in the Ethereum model for rollups, 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 rollup. You don't technically need that for a rollup to be a rollup, like you could have a sovereign rollup that could be its own settlement layer, or that could use another settlement layer, or just like use peer-to-peer for verifying fraud or validity proofs. But regardless, with a settlement layer,

• 11:18Speaker 01

  the settlement layer is concerned with this two-way bridge, right? 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 root to be valid. As long as a state root is valid, or as long as the root 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 rollups 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?

• 11:59Speaker 01

  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 Merkle tree, so that light clients can actually get a Merkle proof to their transaction being included in a block, right? And if you didn't have light clients, you wouldn't need a Merkle tree. Like, full nodes do not care about a Merkle tree of transactions, or even a Merkle tree of state. Like, Solana full nodes, the Solana blockchain does not have a state root, like a root, a Merkle root over the blockchain state, all account balances and contract state. It doesn't have that. And full nodes, Solana full nodes still run, but you can't have Solana light clients, or other...

• 12:43Speaker 01

  Solana has a weird way of doing light clients, but let's say you can't have Solana light clients just as a generalization without a state root. Similarly, if you don't have a transactions root, you can't have light clients either. So some rollups have kind of taken the notion of...

• 12:58Speaker 01

  The a layer two is just a rollup and it's just concerned with this two-way bridge and nothing else. Uh, 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? Cause now you're running a rollup 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 rollup light client off-chain that you can run. How do you know the rollup is valid? Like, I guess you can trust that there's some powerful computer, like, you know, verifying it and so on. Uh, but you run an Ethereum full node? Cause if you don't run an Ethereum full node, then you don't actually know the rollup. Has any notion of validity or anything like that, right?

• 13:37Speaker 01

  So the trust model becomes very weird if you don't have off-chain light clients. In addition to, not just like the trust model of has the rollup been corrupted? But the trust model of even interacting with a rollup. Right? Cause then you just trust in Fura to just give you all the data, honestly, right? There's no like Merkle proofs that your transaction has been included in the block. How do you know it has been, right? Uh, you just have to trust in Fura completely. At that point, well, why even have a rollup? So a modular execution layer.

• 14:04Speaker 01

  If I can use an analogy, it's kind of like the difference between USB three. And Thunderbolt three. Right? Where Thunderbolt three is basically, for those of you who aren't familiar, the USB standards due to, you know.

• 14:16Speaker 01

  The, you know, designed by council. Uh, is, uh, you know, has a bunch of optional components. So you can get like a USB cable. That, uh, doesn't include certain features, like let's say a 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, cause it only has power. Right? Like a Thunderbolt three cable has all the features. Similarly to Thunderbolt four and USB four, right? There's just, there's all, it is all the features. So you're guaranteed if you get one of these cables, it's more expensive, but it has all the features. Right? Uh, and that's kind of the analogy is that, uh, just a rollup and just a layer two. Uh, will be kind of like a USB three cable. You don't know what you're getting. Uh, potentially you could want to do something and you can't. Uh, a modular execution layer, you're gonna think of it like. Uh, like a Thunderbolt cable where it's like a rollup that has all the features.

• 15:00Speaker 01

  And one of the important features that it has is the ability to run an off-chain light client. So you have the properties of a rollup, you know, the trust minimization, the permissionless, the trustless two-way bridge. But you also have the ability to run a light client for that rollup. And that allows you to really have like trust minimized infrastructure.

• 15:20David Hoffman?

  Okay, I'm gonna need you to check my understanding on this. I'm gonna try and like regurgitate what you said and you'll you'll correct me in some particular way. Okay, so you're saying a lot of rollups or and you're talking about the Bitcoin whitepaper 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? It's 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.

• 15:59David Hoffman?

  And so when you're talking about a layer two that doesn't have this like light 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 in Fira? So you're saying that we need a module rather than just a rollup, which is the USB C model,

• 16:40David Hoffman?

  which is, you know, some one-off solution to create a rollup 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 their own the rollup that they're on, which means they're kind of just trusting the operators of that rollup without being able to do it themselves. And you're saying a modular execution layer has solved this problem by producing a more like abstracted layer two, a more abstracted and abstraction layer between the Ethereum

• 17:25David Hoffman?

  layer one or any layer one and the fuel layer two. Is that a fair conclusion? Check me where I got wrong here.

• 17:31Speaker 01

  Pretty fair, except the last part. I wouldn't say it has more abstractions. I would say it just has more features.

• 17:35David Hoffman?

  Okay. Okay.

• 17:37Speaker 01

  More features.

• 17:37David Hoffman?

  Everything up to that last part is good.

• 17:39Speaker 01

  Pretty much, yeah. It's not a bad analogy, yeah. But yeah, so that's kind of where the module execution layer comes in. It's that we're really pushing for a system that isn't just a rollup. And it's not just a bridge, but rather has all those features that you would expect out of a blockchain today that allows trust minimizing infrastructure. So now we've done.

• 18:00David Hoffman?

  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 Arbitrum or like a rollup 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?

• 18:20Speaker 01

  You could say that, yes. That's actually not a bad way of putting it in the sense that traditional rollups, now they're moving towards being modular execution layers following Fuel's lead. But like more these traditional rollups that issue everything except for the two-way bridge, 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. We must operate in this stack and nothing else.

• 18:53David Hoffman?

  Okay, so what kind of flexibility does Fuel gain by this design choice, by this design philosophy?

• 19:00Speaker 01

  So it gains, well, one, it gains security for end users and two, it gains flexibility. So just so clear, it's not just flexibility, it's also security. We covered 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. All right, if you don't tightly couple yourself to a very specific stack, you know, this is layer one, this is a rollup. If you don't tightly couple yourself, then that means you have more opportunity to go in different ecosystems, right?

• 19:36David Hoffman?

  So the fuel layer two can settle both its data both on Ethereum and Celestia and another layer one?

• 19:44Speaker 01

  If you wanted to, yes.

• 19:45David Hoffman?

  Okay, that's kind of what I meant about like abstraction, like as in like we could extract away which data layer really is important to fuel. So there's no, there's no like layer one or data layer that fuel really calls home.

• 19:57Speaker 01

  Let's look at that again. And I think a lot, 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 the specifically 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, right? It prevents you from, it prevents you, or rather, it makes it harder to ensure that your code is clean and free from like weird legacy stuff.

• 20:36David Hoffman?

  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 on to any data availability layer. Is that, is that correct?

• 20:54Speaker 01

  No, that's orthogonal. Those are two different parts. Like the, the fact that you can, the fact that, you know, you have the ability to run a trust, it's not, that's not, that's not the only property that, you know, there's difference between Thunderbolt and USB analogy here, right? There's additional properties. That's a major one that I talked about because of security, but there's 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.

• 21:23David Hoffman?

  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, Arbitrum 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.

• 21:47Speaker 01

  Yeah, sure. So now we're getting to the fastest part.

• 21:50David Hoffman?

  Yes, cool.

• 21:50Speaker 01

  Uh, and similarly to how the model 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 flex flexibility part. Uh, so in terms of performance period, uh, 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 goutches there, you can learn how the Fuel VM works in like an hour. It's very, it's very simple because it's basically the EVM, but improved is what I like to call it. Uh, it has a number of architectural changes that aren't too important, I think, to dive into. Things like it uses registers instead

• 22:34Speaker 01

  of a stack, which leaves the higher performance and higher performance, both in terms of register, like a 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. Uh, but that's kind of like, that's kind of getting a bit too much into the weeds. Uh, 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 introducible into the EVM without a lot of bike shedding. Along with all the architectural changes that will emulate certain EIPs on Ethereum, uh, or that, you know, implement them in spirit.

• 23:14Speaker 01

  So I'll give you a few examples. One of them is, uh, memory copy, right? People would really like to have a memory copy instruction because it would just make certain operations much, much cheaper, especially custom cryptography. Uh, the current approach is you can delegate call into, uh, the identity precompile, or sorry, not delegate call, I guess, no static call. You can call into the identity precompile and then, you know, copy your data and then get it returned and then, okay, you have your memory copy. Now, that's fairly expensive because, you know, you have to call a precompile versus just an instruction. Uh, 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.

• 23:59Speaker 01

  There's a lot of governance complexity in the Ethereum space because you know, you don't want to just accept every single EIP that people propose because then the EVM would get very bloated and be impossible to maintain, right? And as we all know, public goods funding on clients is kind of fairly limited, which makes me somewhat happy that the Paradigm team is now choosing to maintain a Rust EVM implementation. Because nowadays, we can be pretty guaranteed that at least we'll have one thing that's high performance. That is also Rust, 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.

• 24:38Speaker 01

  So, you know, in the field of VM, we have a memory copy. Boom. End of story. It allows you to cheaply copy a memory from one place to another. Hello, custom cryptography. Another example is transient stores.

• 24:50David Hoffman?

  Sorry, can you, can, so that was like pretty technical and for a non-technical person like me, I, can you just like really distill down the impact of that? Maybe for, for developers and for, for users, if it does impact them?

• 25:02Speaker 01

  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, a 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 EDDSA as opposed to Ethereum's ECDSA. And EDDSA is used by Near, 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, they have a rainbow bridge or something, right? They'd like to construct a bridge.

• 25:45Speaker 01

  But to verify each EDDSA signature with custom cryptography implemented in the EVM is on the order of 1 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 in the field, people will be able to and HashCloak 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 field game. So you'll be able to write custom cryptography, different hashing, algorithms, different signature schemes,

• 26:28Speaker 01

  so that you can do things like bridging to other chains and whatnot, and you can do that reasonably economically.

• 26:35David Hoffman?

  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 settles down to, which is where we get this like fastest claim, right?

• 26:50Speaker 01

  Among other things, yes.

• 26:52David Hoffman?

  Okay, all right. So tell us about like the 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?

• 27:06Speaker 01

  Yeah, so I was about to talk about more, more, more parts about the fastest, but okay, we'll talk about this.

• 27:12David Hoffman?

  Well, if we're not done talking about the fastest parts, we should absolutely talk about the fastest parts.

• 27:17Speaker 01

  Sure, I have a few more to add.

• 27:18David Hoffman?

  Okay, yeah, where's next in the fastest? Yeah.

• 27:21Speaker 01

  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 Tstore and Tload, which are effectively, let's 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 Uniswap contract, right, it has some 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 Uniswap contract calls, I don't know, the DAI contract, right? Then the DAI contract doesn't have access to the memory of the Uniswap contract.

• 28:05Speaker 01

  But it'd be really nice if we had access to some, some memory or some storage, whatever you're gonna call it, that persisted across the transaction. So across calls in a single transaction and that was discarded at the end. So it can be used across transactions, but it could be used across calls. That's what Tstore and Tload are. There's an EIP for this and it allows you to do nice things. One thing it allows you to do is it allows you to check for reentrancy 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.

• 28:45Speaker 01

  Like, you can go into like 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-Storage would give you. So you could wait, you know, whatever the amount of time this EIP can, you know, can wait for, uh, while it's in the back burner to be implemented, or you can just build on Fuel. Uh, and, uh, so this, this is part of potentially the flexibility that I was talking about. The fastest is, you know, both performance, but also flexibility. Uh, in terms of performance, uh, it might also be worth talking about the Fuel Protocol itself. Cause the Fuel Protocol isn't just a Fuel VM. The Fuel Protocol is designed to run multiple instances of the VM in parallel.

• 29:30Speaker 01

  Uh, because each transaction in the Fuel system, uh, declares which contracts it will touch. If you know which contracts two transactions will touch and they touch like this joint sets of contracts, you can execute them in parallel because there's no like hard dependency between these two transactions. So this allows us to execute transactions and therefore instances of the virtual machine in parallel. Uh, and that's kind of the overarching Fuel Protocol. So it's not just like, you know, 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 fifteen, twenty years or something like that, right?

• 30:16Speaker 01

  I remember when I was a kid, I was playing Half-Life 2 on a single core Pentium 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. Uh, and that was like the fastest single core processor at the time. Uh, this was like right on the cusp of, you know, dual core processors starting, started to become a thing. Uh, and you're nowadays, I have, you know, on my desktop, I have 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, that was like twenty, twenty years later. Uh, oh geez, I'm old.

• 30:51Speaker 01

  So, uh, but what have processors done? Well, my, my processor has, you know, thirty. I forget it was thirty-two or sixty-four. It has a shitload of threads, right? And the old Pentium four 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 the, 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 gonna be multi-core. And it's gonna have like at least a minimum of eight threads unless you go really cheap and buy like, you know, an Intel Atom processor or something. It's gonna have at least, you know, eight threads.

• 31:33Speaker 01

  So, you know, those resources are unused currently in a single-threaded V M's. Might as well use them.

• 31:38David Hoffman?

  So, the first thing that you said is that Fuel Network, you have a transaction that calls two different contracts and we can have this, uh, instead of having to call memory twice, there's only like one persistent memory. Uh, I'm gonna mess up the way that 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, uh, which, uh, like, uh, 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. And then we all.

• 32:10Speaker 01

  That's a good way of putting it. Uh, and one, one thing we like to say is that we reduce waste. Uh, cause a lot of, it turns out that a lot of ways people want to use the E V M have to use the E V M wastefully. It's not necessarily even that the E V M must be inherently slow. And you must like completely change the architecture because we didn't. The Fuel V M is based on the E V M. Uh, it's that, that it turns out people want to use the E V M in certain ways and the E V M doesn't have a good way of doing certain things. Therefore, people used what, they use wasteful ways of doing those things.

• 32:41David Hoffman?

  They use workarounds which ultimately become wasteful in terms of computational resources.

• 32:45Speaker 01

  Exactly. And we just provide efficient ways of doing those things.

• 32:49David Hoffman?

  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. ACROSS is the fastest, cheapest, and most secure cross-chain bridge. With ACROSS, you don't have to worry about high fees or long wait times. Assets are bridged and available for use almost instantaneously. ACROSS's bridges are powered by Ooma's Optimistic Oracle to securely transfer tokens between Layer 2s and Ethereum. ACROSS is 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

• 33:33David Hoffman?

  to quickly and securely bridge your assets between Ethereum, Optimism, Polygon, Arbitrum, or Boba Networks. The Brave Wallet is your secure, multi-train on-ramp into Web3, and it's built directly into the Brave Privacy Browser. Gone are the days of managing multiple wallet extensions that put you at risk of phishing, 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

• 34:17David Hoffman?

  with a mission to make Web3 easier to navigate for its over 55 million users. Wallet 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/banklist and click the wallet icon to get started. Arbitrum One is pioneering the world of secure Ethereum scalability and is continuing to accelerate the Web3 landscape. Hundreds of projects have already deployed on Arbitrum One, producing flourishing DeFi and NFT ecosystems. With a recent addition of Arbitrum Nova, gaming and social dApps like Reddit are also now calling Arbitrum home. Both Arbitrum One and Nova leverage the security and decentralization of Ethereum and provide a builder experience that's intuitive.

• 35:00David Hoffman?

  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 Arbitrum Nitro, it's also now 10 times faster than before. Visit arbitrum.io, 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 full node in a way that's not very wasteful.

• 35:43David Hoffman?

  And this is kind of the theme that I'm gathering here, is that a transaction on Fuel is minimalist in that it only uses the minimum amount of computational resources it requires 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?

• 36:06Speaker 01

  Yeah, that is it. It's not like anything magical, like, oh, you know, we used to be engineers at Qualcomm, and we know how to build kernels and shit on 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 magical reengineering of anything, of hardware or anything like that. You just say, you know, waste less. I know, boom, your transaction's faster.

• 36:35David Hoffman?

  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 rollup?

• 36:42Speaker 01

  That is hard to say without optimizations, in the sense that there's like a design aspect to it, like the design of the protocol, and that there's 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

• 37:02Speaker 01

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

• 37:38David Hoffman?

  Okay. Is there some sort of like, what number are you going for? If that's fair, like what number do you want to see?

• 37:44Speaker 01

  Uh, well, I mean, if you, if you, hopefully 100x on the same computer.

• 37:49David Hoffman?

  100x faster than a typical optimistic rollup?

• 37:52Speaker 01

  Yes.

• 37:53David Hoffman?

  Okay. So I, I know like Arbitrum likes to do a add.

• 37:57Speaker 01

  Add another zero?

• 37:59David Hoffman?

  They, 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 wanted to 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 is 700 Ethereum's?

• 38:22Speaker 01

  Add another zero.

• 38:24David Hoffman?

  Add another zero.

• 38:25Speaker 01

  No, I mean, add a zero to the, to the 7x. So I don't know.

• 38:31Speaker 01

  Some, something, something along those lines.

• 38:33David Hoffman?

  Okay. Well, that's a, that's a certainly a big number. Have we, have we covered all the, the fast part of fuel?

• 38:39Speaker 01

  Uh, yes. I think we're ready to move on to your previous question about roadmaps. Maybe, maybe we could repeat it in brief.

• 38:45David Hoffman?

  Yeah. So when did fuel, when did the fuel project really get started? Uh, what is the roadmap and where are we on that roadmap?

• 38:52Speaker 01

  It depends what even my fuel project, I guess I can talk about the origins of fuel.

• 38:56David Hoffman?

  Sure.

• 38:56Speaker 01

  Uh, which is that I think it was in 2000. Nineteen. Yeah, I think it was in two thousand nineteen when I left Consensus. Uh, to start it up with Nick and then Sam joined shortly thereafter, very shortly thereafter. And 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 V one. Uh, was it at the end of twenty twenty? Oh, that's that seems too long. Okay, maybe we started, maybe we started this in twenty twenty. The the years are all like, the years are all fuzzy. I think we, okay, I think we started in twenty twenty. We launched Fuel V one at the end of twenty twenty. Uh, and we had started, and Fuel V one 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.

• 39:41Speaker 01

  Uh, permissionless block production, C, posting data onto Ethereum, and D, no upgradability. Uh, 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. Uh, right at the end, right at the end of the year, December thirty first. Uh, just, just so we could say we deployed it in, in that year, a whole, a whole year before any other, uh, any other roll.

• 40:05David Hoffman?

  Yeah.

• 40:06Speaker 01

  Uh, and, uh, that wasn't the end game. It was just for simple payments, uh, but it wasn't the end game. Uh, 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 meant, uh, general purpose smart contract execution. And towards the end of that year, we had actually started working on what would become Fuel V two. We started thinking about the VM architecture. We started thinking about the language, and here's maybe some fun piece of history. Uh, we had actually talked to some people about, uh, if we had a VM and VM interpreter in Rust that we can compile down to Wasm.

• 40:48Speaker 01

  If we could use an interactive verification game over the implementation, rather than the protocol itself. Uh, and this is, turns out, uh, we had chatted with some researchers about this, and it turns out that that's the exact approach that both Arbitrum and Optimism ended up unveiling as neat, as nice innovations, uh, in, in the future. What a good coincidence. Uh, 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 built Sway,

• 41:31Speaker 01

  is that building and maintaining are not the same thing. You can sure build a system very quickly if you, you know, take some general purpose thing and run it over the implementation of your VM interpreter. But then how do you maintain it, right? 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 IBG over. It's very, it 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 also of using the Move VM. But the Move VM is not designed to be fast and it's not designed to be flexible.

• 42:12Speaker 01

  It's designed for a very, very particular and 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, well, literally nothing, because it was created from scratch to, you know, the most mature blockchain development language in existence, if I do say so myself, from nothing. And Sway, or sorry, and Move has basically not changed at all in the past two years. So it was good, there's a good choice not to use it.

• 42:56Speaker 01

  So in addition to, you know, it being immature and it following a 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, then you can use them. If there's a bug, you ask the maintainer, hey, can you fix this, release a newer 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. You, I mean, do you completely change the style to your conventions, right? And completely change how they do things to work with your conventions?

• 43:41Speaker 01

  At that point, it's like, can anyone else even use it? Or you're just solo maintaining it? And it was 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 a 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, it's like Move is being forked to like different, Aptos has their flavor of Move. Sui has their flavor of Move. It's 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.

• 44:26Speaker 01

  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?

• 44:35David Hoffman?

  I think Sway and also the fork conversation are similar. Should we also talk about fork?

• 44:43Speaker 01

  Sure, okay.

• 44:44David Hoffman?

  I can, I can also let you lead if you have a direction you want to go in.

• 44:47Speaker 01

  Oh, well, I, I, I was gonna finish kind of talking, I was gonna finish talking about, you know, the timeline and roadmap thing, as opposed to just diving into more tactical stuff. Because this was more like a history lesson of, you know, how we got to where we are, right? We launched FLOV1, we started thinking about FLOV2, and these were some of the things we were thinking about. Like Move and then IBG and all the other stuff. We ended up basically building the whole thing from scratch to avoid upstream dependencies and other issues like that. Since then, we've been building for the past two years. The organization has grown from, well, zero contributors other than the founders.

• 45:22Speaker 01

  I think we made our first hire in January, end of January, something like that. Of this year? Sorry? Of this year? No, of 2020. 2020, okay. Or, no, 2020, 2021, sorry. Okay. We launched, we launched Fuel V1 at the end of 2020, and then we started building Fuel V2 in earnest, 2021, January, up until now, so the past two years. Uh, dates are hard. Uh, so you know, we made our first hire, we've, we've since grown to, I think, almost 70 contributors, uh, in the organization from now on, uh, back in, uh, back in the beginning of 2021. So I think we've done a pretty good job building out, uh, one of the best teams in crypto.

• 46:01Speaker 01

  Especially, well, for sure, one of, for sure, the best compiler team, and just one of the best teams, period, uh, across our whole stack, uh, in crypto. Uh, most, mostly engineers, believe it or not, uh, like 60 of those people are engineers. We really, we really do need to hire more non-engineers. So if you're, if you are out there and you're a non-engineer, you know, if you're into like BD, if you're into, uh, public communication, content writing, uh, if you're into like project management, anything like that, please read out to me after, after this, because we always need more of those. Uh, so, and then since then, we've basically been building, we launched a, oh, sorry, for, for the first year, we built, uh, in stealth mode.

• 46:40Speaker 01

  Uh, and then on January 2nd, 2022, so this year, so about 12, 12 months, or 11 months ago now, to the date, actually, oh, it's December 2nd, so 11 months ago, then we released all of our codebase in public. Uh, since then, we've actually been building in public. And there's an important distinction between, uh, us and potentially some other projects. But not only is our code all open source, our entire stack, uh, except for a couple of minor components, but those will change soon. Uh, we're also, we also build in public, right? Some other, some other projects, roll up or not, uh, will, for instance, build entirely in private and they'll like release some blob, but then it's not even open source.

• 47:23Speaker 01

  Right? 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. Uh, Fuel Labs, everything we build for the Fuel Protocol is built in public. And it's also planned in public. We don't have like a private issue tracker that people can't see. Like 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 very part, a big part of ethos. Uh, it's not just about, you know, the software and the blockchain. It's also about how is it built because people are a very important, uh, part of our, our culture. Uh, so yeah, so we made all the code public, uh, the beginning of this year. Since then, we've launched three tasknets.

• 48:09Speaker 01

  One of them was for Sway Swap, a port of Uniswap, the hybrid of Uniswap V1 and V2, ported to the Sway language, deployed to a private devnet. Then we launched two public tasknets, Beta 1 and Beta 2, uh, each of these about two months apart. Uh, that, uh, had just increasing number of features, uh, and increasing sophistication and stability and so on. Uh, I think we are gearing up for a Beta 3 tasknet sometime early next year, let's say. Uh, that's kind of, that's kind of it for the, that's kind of it for the spoiler. So there'll be a few more tasknets. Uh, we're rapidly approaching a mainnet launch. Uh, what form that'll take, uh, will leave to future announcements.

• 48:52Speaker 01

  But yeah, uh, that's effectively how things have gone, uh, in terms of development for the past couple of, three years.

• 48:59David Hoffman?

  So how, how will an ecosystem come to be on Fuel? Uh, what's the, the idea behind that? Because, uh, if I'm understanding this correctly, like you can't just copy and paste Uniswap code and deploy it to Fuel. That's why you were talking about with like some sort of, uh, iterated code to make it work on the Fuel network. How do you, how do you expect, uh, an ecosystem to come to be on Fuel? How, how do you expect that story to go?

• 49:20Speaker 01

  Yeah, uh, it's not just how I expect an ecosystem to come. It's, I can describe how an ecosystem came to Fuel. Uh, we already have a burgeoning ecosystem of, uh, very, uh, excited developers that are really engaged into the project, uh, and the language and just in a general ecosystem. Uh, that have, you know, basically they've taken a look at Sway, they've taken a look at the Fuel VM and they're like, Wow, there's so much better than any other chain I can get, even today. And this is the early days with rough edges. Imagine like a year from now when we've polished all those rough edges even more, it's gonna be insane. And we already have like, you know, a dozen or so projects that are building on us on testnet. We hosted a Twitter space with one of them, PoolShark, last night on the Sway.

• 50:05Speaker 01

  You can look at the Swaylang Twitter, and it has a space from 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, you know, they're building an AMM that's concentrated liquidity, liquidity if I recall correctly, right? We have a few other ones, like an NFT marketplace, and some other stuff that are being built today. So this is like, we have to attract developers out of Norris. Like, we already have an ecosystem of developers being built that are already here. And that's only gonna continue to grow.

• 50:40David Hoffman?

  Of course, yeah. Do you have any like stats on users or daily transaction volume or any stats of adoption like that?

• 50:45Speaker 01

  That is something I don't have off the top of my head. I'll have to talk to our growth lead on this. I'm sure she has, I'm sure she has some, like a whole bunch of numbers and stuff, but that's not, that's not my area of expertise. I just do protocol design.

• 50:58David Hoffman?

  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 rollups?

• 51:10Speaker 01

  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 testnets are public, right? Like Beta 2 is a public testnet. It has an open GraphQL endpoint that anyone 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 to index things. And then, you know, expose a GraphQL endpoint if you're, you know, some, if you're like Dune or whatever, right? We also have a first-party indexer service.

• 51:46Speaker 01

  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 party 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 and it's all like a single unified tool chain. And you can get all your indexing done that you can then plug into analytics, analytics websites. You know, of course, it's not currently plug and play into Dune, 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 blockchain is all

• 52:30Speaker 01

  on chain, as I say, right? You just query the chain.

• 52:35David Hoffman?

  Do you have like a attitude or philosophy as like, is, do you, where do you think the whole entire broad landscape of Ethereum layer twos is going? Because each layer two has its own kind of directional philosophy. Optimism is really focused on like their bedrock and OP stack, CK 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, any takes about like where the logical conclusion of Ethereum layer twos go?

• 53:15Speaker 01

  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, you know, fuel, of course. So this, this will look like what we see today. We have a bunch of blockchains going, or a bunch of rollups going from. You know, I guess we're EVM compatible to, okay, now we're EVM equivalent, right? Uh, and then they're all gonna deploy their solutions that are quote unquote EVM, EVM equivalent.

• 54:00Speaker 01

  Uh, but then the next step to this, and this is still in like the short term, is people will want more. They'll want more flexibility, they'll want more speed, they'll want more something, right? Uh, 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, you know, let's implement T store and get people who have been excited about it all this time to use us. And people will want more, uh, and you're gonna end up, I think, in a weird scenario. Where, uh, well, that's the long-term thing, we're gonna talk a weird scenario in the long-term thing.

• 54:40Speaker 01

  Okay, so in terms of, you know, people want more, people want improvements to both EVM and infrastructure like RPC endpoints and stuff. Uh, you know, they'll want parallel transaction execution in a way that isn't a denial service vector. Uh, because, you know, some people are saying, hey, let's, you know, apply a parallel transaction execution to the EVM with concurrent, uh, con- concurrency. That's a denial service vector, or rather, well, it's a denial service factor or it does nothing. Uh, which is always the rock and the hard place, it either does nothing, or it's a denial service vector. In the worst case, like if it's adversarial, uh, and the, our Ethereum team is using this approach. Uh, which is why I think, I think they're using the wrong approach, of course.

• 55:22Speaker 01

  Uh, Fuel is not using optimistic concurrency, right, it's using like enforced parallelism in the transactions themselves. Uh, 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. You know, if someone doesn't, you know, if someone, you know, makes a bunch of transactions that are all targeting the same state. They 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. Uh, so what I think is going to happen, uh, is that, you know, people want more. And guess what? In that wanting more, that is fuel, right?

• 56:03Speaker 01

  Fuel is years ahead plural of any other chain in terms of building some, the next step of the EPM. In terms of implementing these EIPs like T store, in terms of account abstraction, uh, in terms of, you know, EIP 3074 for authenticated calling. Uh, in terms of flexible transactions with scripts, all of these things fuel has from the beginning, right? Uh, 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, as someone would say.

• 56:34David Hoffman?

  So you're, you're just saying that, that fuel is the philosophy of skating to where the puck is going?

• 56:38Speaker 01

  Yes.

• 56:40David Hoffman?

  Cool.

• 56:40Speaker 01

  Uh, and that falls into what I foresee is what's going to be some long-term consequences of this EVM conversions, 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, uh, which is not good. Like, I really wouldn't like that eventuality. Or people are going to say, hey, let's use fuel because fuel has, has, it has everything we want. It has all the more we want. That's already implemented. We don't have to wait years. Uh, right. Has better language, better tooling, better VM, better everything. Why wait when we can just use fuel? Uh, that, that's, I think, the ideal scenario, both for fuel and myself personally, and also for the Ethereum ecosystem, I think.

• 57:22Speaker 01

  Uh, because there are the, there's a third scenario, which I think is really bad, which is that each of these rollups, uh, which, you know, a lot of them are, have certain financial interests 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 Arbitrum and Optimism have two different ideals around some feature of Ethereum, right? Like Arbitrum really wants feature X, Optimism doesn't like feature X and thinks it should be feature Y. And an example of this is actually Ethereum itself, the EVM, like base layer Ethereum had such a thing happen

• 58:07Speaker 01

  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 what we know. It was even that's still, 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 for general cryptography

• 58:49Speaker 01

  that people could then use to specialize at the application layer instead of at the consensus layer for BLS specifically. All right. Now, the BLS specific ones, you know, maybe they're faster and cheaper, but then they required, you know, you specifically need to know about BLS. The other one is more general, right? But it could be more expensive. And there was like a bunch of fierce competition in 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 rollups and each of them think, you know, one of these is better. What the fuck happens to governance then? Especially when these rollups 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?

• 59:32Speaker 01

  And I think that may be the ideal scenario for Ethereum, because then it avoids this, this disaster scenario of all these rollups 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, which features get implemented in the EVM, because they have to stay EVM equivalent. And if they don't, then potentially even an even worse scenario happens, where now each of these rollups branches off and has their own flavor of EVM and fuck EVM equipments. 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 tools work and stuff, right?

• 1:00:13Speaker 01

  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 of people will 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 what are the long-term consequences of rollup teams fighting on the Ethereum governance arena for their own purposes.

• 1:00:50David Hoffman?

  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, so thank you for sharing that.

• 1:01:07Speaker 01

  Well, now maybe you won't sleep as well at night.

• 1:01:11David Hoffman?

  Well, there's, 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 a success, what would you ask?

• 1:01:29Speaker 01

  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.

• 1:01:52David Hoffman?

  And where are all of the links to go get that done?

• 1:01:55Speaker 01

  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/fuellabs. You can follow us on Twitter, which is at fuellabs underscore. Potentially that might be changing soon, soon, Alpha Leak. But yeah, that's kind of where you can go to kind of get started on socials and just code and stuff.

• 1:02:22David Hoffman?

  Awesome. Well, John, thank you so much for joining me on this Alpha Leak episode. Speaking of Alpha Leaks, and explaining to me the Fuel Equus system. I appreciate it.

• 1:02:29Speaker 01

  Thanks so much for having me, David, and the Bankless Nation.

• 1:02:32David Hoffman?

  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, podcasts, 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,

• 1:03:14David Hoffman?

  and weekly rollups 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.