Web3 Galaxy Brain 🌌🧠

Nicholas: Welcome to Web3 Galaxy Brain. My name is Nicholas. Each week I sit down with some of the brightest people building Web3 to talk about what they're working on right now. My guest today is Nick Dodson, co-founder and CEO of Fuel. Fuel is a modular execution layer that's designed to facilitate performant L2 roll-ups. On this episode, Nick and I discuss the history of roll-up design, the scaling challenges facing the EVM, and how his years of experience writing Solidity, EVM Assembly, and participating in the EIP process contributed to Fuel's design. We dive into Fuel's underlying UTXO model, which allows Fuel nodes to validate transactions in parallel across multiple cores simultaneously. Finally, we discuss predicates, which are stateless conditions that can be attached to Fuel transactions, allowing users to pay for gas in ERC-20s, Sol, or other coins, and to sign transactions with different elliptic curves, like BLS, P256, or EDDSA. It was great learning more about the exciting technology Fuel's been cooking up for the past few years from Nick. I hope you enjoy the show. As always, this show is provided as entertainment and does not constitute legal, financial, or tax advice or any form of endorsement or suggestion. Crypto has risks, and you alone are responsible for doing your research and making your own decisions. Nick, welcome to Web3 Galaxy Brain. Thanks for coming on the show.

Nick Dodson: Awesome. Yeah, I'm happy to be here.

Nicholas: We were talking just a second ago about microphones and things. You actually had a past life as a drummer in a band, right?

Nick Dodson: Yeah, very much so. For a very long time, yeah.

Nicholas: It was like a Toronto indie rock band?

Nick Dodson: Yeah, so I mean, I guess the closest thing you could call it is like synthwave or synthpop, like that sort of thing. So like Depeche Mode, New Order, Madonna, that kind of thing.

Nicholas: Love it. And you have like a musical family, right?

Nick Dodson: Yeah, my dad's a musician, my sister's a musician, full-time. So it's definitely a family of musicians.

Nicholas: That's very cool. And I was reading also that you studied philosophy, right?

Nick Dodson: Yeah, I studied. I studied philosophy because computer science didn't... I was sort of doing that in my normal time or like outside of school time. So for me, it just made more sense to just study something more gripping. So yeah, philosophy was the way to go. But philosophy, though, I dropped out with only a few courses left to basically start doing crypto. So I started that journey pretty early, at least in my life.

Nicholas: I think it might be a relatable story. For lots of people, I like to get into a little bit when people have non-traditional entry points into crypto because I think so many people in crypto are these kind of... I think about Rudolph, you know, the claymation Rudolph on Misfit Island. I feel crypto can sometimes be like that. And it's not always traditional computer science routes that lead people to this industry.

Nick Dodson: No, 100%. I think there's a surprising amount of philosophy dropouts, actually. It seems to be a reoccurring trend, reoccurring pattern that I see. Yeah.

Nicholas: Yeah. So you discovered blockchain pretty early, right? In the history of blockchains altogether. Can you give us a little insight? Yeah.

Nick Dodson: I started working with blockchain like around 2013. So for me, initially, it was just like running the, you know, a very original like Bitcoin client, like trying that sort of stuff out. Then I got into doing a lot more mining, that kind of thing. So I was doing a lot of mining out of my house. I was heating my house with mining heat. And like doing that for like a little while. And then...

Nicholas: Were you really able to turn down the heat on the house as a result? Oh, yeah.

Nick Dodson: Oh, yeah. It was really hot. It was very, very hot. I had like seven or eight like rigs going at once and it was enough heat to like heat a basement. Yeah.

Nicholas: What was the compute at that time?

Nick Dodson: What kind of cards were you using? I forget how much compute I had. I had like seven or eight rigs going each with like anywhere from like four to six cards, something like that. So it was, it was enough GPU power for like a pretty good setup. Yeah.

Nicholas: Very cool. And then you kind of discovered, well, I guess you started around 2010 or something. You discovered blockchain, but then 2013 you really get involved and you're ready for Ethereum when it drops, right? Yeah.

Nick Dodson: I think, I think I sort of stumbled into it in very early, like 2010-ish, but I just ignored it. I thought it was sort of stupid and ridiculous and then I didn't really understand it. And then 2013 rolls around, then I start to really take a look at it. I'd seen a few interviews with people and stuff and decided to take a closer look.

Nicholas: And how did you discover Ethereum?

Nick Dodson: I discovered it because I was on the Bitcoin forum and I was asking the Bitcoin, you know, forum, "Hey, why don't we expand the op return from, you know, like 40 bytes to one megabyte?". So I could actually do things with Bitcoin. I could actually put code in there. I could, you know, do something with it. And then basically the, I had no idea about Bitcoin block wars and maximalism and all that stuff. I just was practically trying to fix the issue. And they basically blew up, like it was extremely emotional. It was very intense. And then at the very end, some guy just wrote, "You should check out Ethereum.". And then after that one moment, everything, everything changed and started to dive into Ethereum. Yeah. Amazing.

Nicholas: So that must've been, was Ethereum even in production at that time?

Nick Dodson: That was probably like 20, I guess it must've been 2014, something like that. I'd have to look back exactly when that was. So like 2014, maybe even early 2015, I'm not sure. Yeah.

Nicholas: Something like that. And so Ethereum gave you the opportunity to do what you wanted, which I guess was write applications.

Nick Dodson: Yeah. I think it really combined the interest of these like blockchains and trying to do something more interesting with them than just send transactions. Yeah. So it was really kind of opening the door to that whole thing. Oh, sorry. Here. Okay. Full on dog situation. Okay. But yeah. So basically, yeah, Ethereum combined a lot of the sort of decentralization intrigue and these decentralized economies with actual smart applications. And it felt like that was something that made a lot of sense. At the time they were pitching it as like the world computer and these other things. And as you start using it and building stuff with it, it's like... Well, that was a nice pitch, but it wasn't really what it actually was. I think it was more, maybe call it the world state machine or something else, but it wasn't as sexy as world computer. So I think that's...

Nicholas: The difference in your mind being that you wouldn't want to do like fully scaled applications for billions of people on Ethereum?

Nick Dodson: A hundred percent. Yeah. I feel like it was sort of pitched as that idea because it kind of was in a way, but it was just a very extremely slow world computer. So take it as you... Yeah. As you may. But yeah, I think that even at the very, very early onset of Ethereum, we were thinking about, at least in the space, it was initially conversations about basic things like registries and we knew we could maybe do a name registry and you could do like... I had this idea for registering like VIN numbers and stuff inside of it, things like that. But they were really simple ideas at the time. We weren't thinking Uniswap or anything like that. At least at the time. It was that early, early onset. So...

Nicholas: So I guess it wasn't totally obvious in those early days that, at least for now, it seems like tracking values in a decentralized way without any kind of custodian or middleman or arbiter seems to be like the greatest flex for Ethereum, but it wasn't so obvious so early on. Exactly.

Nick Dodson: Yeah. I think early on, we knew we could do some kind of exchanging, but we did most of the exchanging off-chain and then it would just sort of settle on chain. Yeah. And that was like some of the early exchanges on Ethereum. And I think it was like EtherDelta was one of them and that was like really popular at the time. And then after that, there was some attempts at trying to make it more decentralized, but I think it was... I forget which team really came up with sort of the Uniswap model. I think it was 0x or something like that. They had actually come up with it. And then of course, like the Uniswap system came out and it removed a bunch of fees from that design. And then that became sort of the de facto DEX model that we have now. Yeah.

Nicholas: So during this time, you moved over to working at ConsenSys, right? Yeah.

Nick Dodson: Yeah. So I was working at ConsenSys. Like Joe found me on the Ethereum forums and then we started going back and forth and yeah, Joe was basically just trying to, I mean, I think at that point he was very excited that anyone was using Ethereum. So the fact that there was someone who was building any kind of application on Ethereum at that juncture, he was thrilled. Like he was like, I don't know who you are, but you know, let's, you know, let's get you supported in whatever way we can. So it was very like early days, but it was a very supportive kind of situation. And then, you know, basically started working with them more formally. And at that point I'd already put out stuff around very early project I was working on called Wayfund, which is like crowdfunding. And then there was another one called Boardroom and that was for governance and, and both. So I was doing tokens and voting basically. I think there was 10 apps on the Ethereum homepage and I had two of those apps on the homepage.

Nicholas: So cool.

Nick Dodson: Yeah.

Nicholas: It's funny that, what is this? almost 10 years later, we're still kind of working through the same ideas as some of the most popular applications. Not a lot has changed. Yeah.

Nick Dodson: Not a lot has changed. I think that like, look, those are, the thing is, well, not a lot has maybe changed. You could say that more stuff has been proved out. And at least, at the very least, those things alone are extremely valuable, at least to humans, both voting and tokens. So effectively, like you don't need to go much further than voting and tokens. If you actually want to say like, is Ethereum valuable to the world, like even just those two things alone, not, don't even include exchanging, don't even include these other things is already like enormously valuable. But of course there's a lot more we can do. So, you know, it doesn't.

Nicholas: Yeah. I guess you could say even like in something like video games, I don't know, they're different, but something like Flappy Bird or other kinds of like physics-based games still are echoes of things like Pong from way back. So some of these kind of killer applications with technologies, they don't go away. Maybe they get new forms, but the kind of core insight about what makes them sticky sticks around. And it's not just speculation either. It's just the mechanic that's relevant for the technology.

Nick Dodson: Yeah. A hundred percent. I think the, I think the problems don't change, but the ways we solve them change. So like, you know, if you've got to go from point A to B, you have the like horse and buggy, then, you know, or you have like the cart, then the horse, and then, you know, a car and then, you know, a taxi and then Uber, you know, it's same problem, different, different solves. Yeah. Right.

Nicholas: But while you're at ConsenSys, my impression is that you kind of over the years figured out how painful some of the design decisions that were initially made in Ethereum were.

Nick Dodson: Yeah.

Nicholas: Is that right?

Nick Dodson: Yeah. It was basically, it was a very painful set of years building anything that worked. Because even when we started, we didn't have RPC providers that were reliable or anything like that. And in ConsenSys, like we, basically what we ended up doing was this one guy at ConsenSys, Herman, he started just spinning up nodes and putting them under a load balancer. And I'd even asked him like, so how are we going to, how does this make money? How does this work? And he's like, we just run them. We just run them and we just keep it going. And I'm like, but like, this doesn't make any sense. And he's like, we just do it. And like, that's the very early days, like in Fura and, you know, they've subsequently, you know, have their team and everything else has been built up over time. But like, it was very simple at that, at that point.

Nicholas: So basically solving your own problems as developers, you had these problems, so you just go solve them and they become these spin-outs out of ConsenSys or stay within ConsenSys, but become their own brands. Yeah.

Nick Dodson: And I think like, you know, it's the same with MetaMask too, like it was just the fact that there could be, you know, basically a wallet that is an extension that you could sign transactions with was like pretty substantial at the time. That was like a whole other way of looking at it. And initially Aaron wanted to use like an iframe instead of an extension. And they like flirted with that quite a bit, but it ended up being that the, the extension model was like a little safer as they ended up going with that. And we still use that model now. But honestly, all of these things were huge UX hurdles and they ended up being enormous nightmares. Like even with the plugin, even the best possible plugin you could ever create, the fact that you have to deal with gas and seed phrases and all this other stuff ended up making the experience like pretty horrible. Yeah. Yeah.

Nicholas: So there's like a bunch of issues that came up that I guess inspired this whole turn towards roll-ups. My understanding of the history. Is that first Barry Whitehat proposes this roll-up GitHub repo, that's a ZK roll-up. And then only later on does the ZK sort of get stripped out and it's like, actually we can do it optimistically and we don't need the ZK in order to be able to do roll-ups. Is that, is that what happened?

Nick Dodson: I mean, there's, there's a bunch of different kind of origin stories you could say to this whole idea. I think that, you know, when we were looking at like scalability options, Fuel initially had started as just a wallet. So. So we just wanted to build a simple wallet that would transact on Ethereum and make the transactions cheap. And you would think that would have been a doable thing just to do that. But it ended up being that that alone was so impossible if you wanted to retain the security of Ethereum while doing something cheaper. And this kind of leads you down like a giant rabbit hole on what options are available. So at the time it was just Plasma and state channels. And there was like talk of ZK, like it was very academic. Yeah. And research at that point. Extremely slow, extremely immature. And and then you had like other things like BLS and stuff which were forming as far as like standards. But it wasn't very, very clear. And that was like twenty eighteen twenty nineteen at least state of things. And yeah, I think I think a lot of the idea stems from the fact that with Plasma they were experimenting with using a Ethereum as sort of this giant state transition mechanism that would sort of officiate things. But you would do a lot of it off-chain, or you would do a significant portion off-chain. Then we have the research into ZK, which was sort of crossing over that to say, well, we could prove all this execution is true to Ethereum. So that really helps a significant amount. But then you start to realize that, well, wait a second. But in order to prove it's true, you need to have the data. So if you lose the data, it might be the case that you can't show Ethereum that it's true. So the data has to be available in order to contextualize what the ZK is and continue for it to transition states into the future. So this is where you start to float around with, okay, well, you need to store the data somewhere. And you need to store the data, whether it's Plasma or whether it's something else. And you get into more fundamental ideas about scaling in general. And that's where Lazy Ledger and these other ideas pop up as well. And there's papers around data. Availability sampling and other things that start to bring in more concepts of, you know, it's all about storing the data because you can kind of prove whether it's sort of a Plasma kind of model where it's like a little more optimistic or you have a model that's more ZK. You need to blend that with storing the actual data somewhere. And then whatever your point of data storage is, is sort of your security, basically, at least to progress things and to move state forward, et cetera. So. So it's a. I think it's like we'd have to go back and look at all the papers and all the different dates in terms of the timeline. But, yes, there's a bunch of different actors involved between Barry Whitehead, Vitalik, like, you know, early Celestia people. And and as well, like just sort of this progression of Plasma that's happening with, you know, the Plasma team at the foundation. But basically, Vitalik writes this one post that calls it a roll up. And, you know, Defines it better. And then all of a sudden the whole community sort of it's like the starting gun to, OK, we know this will probably work. We have enough evidence, we have enough support, we have enough papers, we have enough information. like this will probably work. This is probably better in the short term than figuring out sharding, which was more of the idea for scaling at the time. So I think that's kind of that early days of roll ups before everything was starting to formalize. And then there was as well one other important. Player to all of this, which was called Truebit, which was really the sort of ancestor project to Arbitrum. So they were working on a very similar form of interactive verification game, but they couldn't solve the data problem, which was effectively this other thing. And and so they had a lot of this idea of interactive verification games way before everyone else. They were working on it for quite a while and Arbitrum inherited those ideas. And then sort of perform them over initially their own VM, but then they moved to WASM after and the WASM interpreted layer. So, yeah, it's pretty messy. There's a lot of different interesting characters doing all this stuff, but it was not necessarily coherent. And of course, Vitalik being so prominent when he starts to gather everything together and define something, then that sort of becomes what it is essentially, at least in the research space. So, yeah, then after that point, we start to dive into roll ups again. Yeah. Right.

Nicholas: So as we move into roll ups, there is a kind of evolution of the thinking of how a blockchain functions and splitting apart its various layers, including data availability. Can you explain how? execution layer, settlement layer, data availability, how do all of these parts fit together and which ones is Fuel interested in? Yeah.

Nick Dodson: So I think as we got more into this idea of, you know, splitting up different things, you know, we started to think about, you know, what's the best way to do this? I mean, there were different concerns and different pieces of a blockchain into different areas. This formulation of different terms came along that we didn't really have before. I mean, you could say that it was sort of there beforehand and different bits and pieces, but we wouldn't have conceptualized the blockchain in different layers or different settings. So I think, like, a simple analogy is just to say that like initially, the Internet was probably just like a few computers. And if you would ask someone at the time, like, what is the Internet? internet, they would have just said, well, it's these computers. And you go, yeah, but do you have a special computer for networking? Do you have a special layer for, you know, encrypted comms? Do you have a special layer for this? And they would have been like, no, but like in theory, you could split them up, but like, why would you do that? I just do it all on my one computer and I connect and there's 10 people connected. and it's great, you know, but like little did that one person know. you would have billions of people connected to it. And of course you need to split up the concerns. So in a similar vein, you can say that splitting up blockchain into different layers of different concerns follows the same principle of you need to specialize the different concerns and then you need to improve upon each one of them individually. And so when we come to this idea of having different terms of different layers of different sections of a blockchain in general, it's really taking everything that a monolithic single chain would have and then splitting it up into different concerns. Um, and so there, the thing is it's not a perfect picture in my opinion, and you can try to come up with very, you know, researchy, very, very specific ways to define each thing. I would just argue that, um, it, it generally follows a few different categories. So, um, so we typically define it as like, um, like data availability, um, execution and settlement, um, are like, you know, sort of three, uh, three of the layers. Now, of course things are getting even more weird and complicated because people want to also centralize other pieces of it. So they want to say there's also these things that we're sequencing with. So we're decentralizing pieces of block, uh, you know, block developments. And then, um, as well, there's going to be other layers in between. So basically like, uh, yeah, it's, it's hard to say how far this is going to go and what it would really mean, but it, it comes down to that. There's most likely settlements, data execution, and data, and data, and data, and data, and data, and data, and data, and data, is like a little bit of a tricky one, because you could say that there's data availability, which is sort of making the data available enough so that you can continue the state and, uh, prove any, any infallibility. Um, and then there's data storage, which is really just storing all of the blockchain data in general. And those are sort of somewhat very different things, but even though it's roughly the same amount of data that you're going to need for each. Um, so, so yeah, that, that's kind of a general composition.

Nicholas: Yeah. Why is it roughly the same amount of data that you need for each? Because for the, like fault proofs, you only need the roots, right?

Nick Dodson: So, um, for, so it depends. if you're talking about just CK rollups, then the more minimal amount of data would just be all of the state dips. Um, so you could just include all the different state transitions, um, as just hashes. And that's enough for you to rebuild the state and then progress it. Um, and, and exit, for example, whereas with a fraud proving system, you do need to provide what we call like witness data. So it's like, it's everything. So every single bit of data that you're actually going to need, um, now there is some tricks you can use to compress all of that, but you're going to need to post all the data. So typically, people in the space associate with CK as more efficient for theory and roll ups, because you're just posting state deaths versus posting all the transaction data, all the witness data, et cetera. Um, so that's typically what the association is. Um, fortunately for fuel, we have our own techniques that should remove all of that from ever being an issue. Even in the optimistic setting. But Fuel itself is very agnostic to either of these techniques. I see.

Nicholas: And so the StateDiff's version would be just the changes to storage then? Yeah.

Nick Dodson: So I guess the way you can conceptualize it is that State also is complex in and of itself. You could consider State as all the different accounts in a system. You can consider it all the different storage slots of a smart contract. And in some cases, it's other information as well. And so, yeah, it's basically all of those State changes. Any kind of State that lasts longer than a single transaction would have to be stored in Diffs. So you need to point to what you're changing, and then you would need to post the new hash of what it's going to become. So you need to post all these different hashes in a block to progress the State transition forward.

Nicholas: I see. So those are questions of data availability and simultaneously part of the execution, if it's sort of off-chain. If it's off-chain, roll-up execution, then we're in the same conversation with these as regards to their being stored on Ethereum or some other data availability layer.

Nick Dodson: Yeah, you're just talking about, like, how much data can we put through Ethereum? that allows me enough time to be able to withdraw my funds. in the event that I need to withdraw, or in the event that I need to progress the State in order to say, hey, I'm withdrawing, get me out of here, because I don't want to be here. So it's sort of like, that's sort of the case with ZK. With optimistic roll-ups, you have to post all of the data. And then... At any point, you have to be able to challenge. So you have to say, hey, like, this block is invalid, this transaction is invalid, et cetera. And you have to have enough data there in order to be able to challenge it. from the last point of what we call finalization, when we just agree that the State is valid and is unchallenged, basically. Yeah, so they progress in different ways and change State in different ways.

Nicholas: And have we covered the settlement layer aspect?

Nick Dodson: Yeah, so for settlement, like, again, this is another term that, like, I don't love particularly, but it sort of makes sense. It's sort of say that Ethereum is sort of the final word on the State of things. So Ethereum is the defining layer where you can challenge things or where you can prove things to say that I'm progressing, you know, my blockchain, my execution, whatever you want. And so Ethereum becomes sort of this final layer where assets are and where these State transitions are. And in the worst case, you can leave these sort of what we call these execution layers, you can leave them and go back to Ethereum and that's sort of your safe decentralized home. It's expensive. It's not ideal for, you know, the entire planet to use all the time. But it's a place to get out of just in the event that these other systems don't work. Yeah. Or that you want to exit or move to a different version of these systems.

Nicholas: So we can play around in an execution layer, a virtual machine that lives outside of Ethereum that has different advantages that will ultimately, as long as we have access to it. To its data, its data is available, then we can know for certain that the proofs that are being written to the settlement layer are accurate, or at the very least, if they're not accurate, there are escape hatches so that we can recover our funds back to L1.

Nick Dodson: Yeah. Ethereum becomes this giant judge and arbiter of all these potential different State transitions. And if everything works really well, Ethereum has to do very little and just do some ZK proofs, maybe be available for some fraud proving. And that's it. And in general, most people won't want to go back. To it. in general, most people won't want to touch it. And as well, it will be this sort of home for very secure data that you have, you know, hundreds of thousands of people validating, hundreds of thousands of people staking, you know, millions of dollars, you know, just to be able to ensure that this actually transition transitions well. So you have billions and billions of dollars of security there to ensure that this whole system progresses forward.

Nicholas: And the reason for that is because Ethereum is Lindy. It's been around longer and has kind of a huge bounty on its security, given how much you could steal. And also it has the staking, the huge set of stakers who are staking an asset that is relatively stable in value compared to other crypto assets. I'm curious, does it does the score change with something like Eigen layer or I don't know, Celestia or something else where maybe we don't need Ethereum to be that thing, given some of the kind of we didn't get into detail on it. But some of the challenges with. Solidity and the EVM that are maybe not the most future proof designs and yet quite difficult to change over time. Do you think that Eigen layer and things like this change the score on on L1 being the settlement layer?

Nick Dodson: I think that so I come from like pre 2017 crypto. So for me, I have very deep concerns about things like restaking and also very deep concerns about node requirements and very deep concerns about things that a lot of people seem to not be so concerned. About, I guess, until a regulator comes along and it's like, well, wait a second, did actually or is it not? because if it if it isn't, then we should probably just like, you know, put in our own rules and control the entire thing. Right. And, you know, I think some of the ideals of the original idea about crypto is that, you know, governments didn't really do the right thing for the people. They didn't really design a good system that they couldn't advantage or overly advantage themselves. And thus we needed something that is outside. Of a single government just to give us a trapdoor, you know, to give us an escape hatch from, you know, money going out out of whack or, you know, basically governments not doing what the people actually need. So I think that, you know, Bitcoin really starts that idea. I think Ethereum really completes the idea as far as enough of a mechanism to build these other kinds of escape hatches or build these other kinds of systems that allow us to be people of the entire. Planet and not bound too heavily to a single government or a single country. So in that sense and in those ideals, I would say that Ethereum itself and its security and the way that it's constructed is such that like the node requirements are very low and you can run an Ethereum validator on a Raspberry Pi. It's sort of like a meme, but that's actually very important to the underlying core properties of what it takes to validate and progress Ethereum. And I think that, you know, I think it's really important that Ethereum use it and have access to it in the planet, right? And I think that like fundamentally the core value of what Ethereum is to the entire planet is rooted in that specific thing. And if you take that away or you start to increase those node requirements or increase those things onto what is the Ethereum network or the Ethereum stakeholders, there's significant risk that you start losing that case. You start losing that case because. Sure. You want to be an Ethereum staker, but that's not good enough now. Now you want to take all your assets and restate them and you want to run more node requirements or have bigger risk assumptions around all these different things. And then that's where I think a lot of stuff falls apart. And I think that you start to lose the sort of core ethos of what Ethereum is actually securing. And I think Ethereum should remain very simple and very dumb. Almost the EVM is enough for us to do ZK validation and fraud proving. That's enough. That's enough for us to state transition. And then the blob and sharding roadmap that we have is enough for us to have enough data to be able to witness the world state transitions. At least enough for, I would say, the foreseeable future. So, you know, for example, like with fuel, like as it currently stands, by estimation and we'll have to prove it with benchmarks. So just this is take it with a grain of salt. But let's say with the first iteration of 4844, which is coming in like a month on Ethereum, we can do 5000 TPS and transfers. We use all the 4844 data. So I'd have to ask you this, like if we could fill up all of Ethereum with 5000 TPS per second, right? That's per second. So that's the rate, right? Do we really have 5000 TPS right now? I mean, I don't think we do. I don't think Solana taps that. I don't think most things really tap that. There's not enough people here yet to use that. Now, that's 5000 TPS over the first set of blobs for Ethereum. Now, take that 5000 TPS and then multiply that another 16 times, right? Now you've got a lot of TPS. Now, I'm not going to say it's enough, right? I'm not going to say that that's like enough for everything. It's enough for everything we want to do with this because there's other things we want to do than just transfers. But the fact is, is that with just this data, we could do 5000 TPS. It's like, well, let's fill that up first. Before we actually want to go and do something else, right? So while I think I'm very appreciative that there's other teams that are building their own communities and their own blockchains and their own stuff, their own ideas and progressing those like Celestia or like EigenLayer. I think that they each introduce different risks and risk tolerances. They also have different node requirements that are somewhat completely inaccessible to most people on planet Earth. And they break a lot of the social contract, in my opinion, of what the original Ethereum is supposed to be. So I think Fuel, because I'm pre-2017 crypto and I seem to care about this and no one else does, I would hope that Fuel would continue on these values as a project. And that goes into anything that we have with node requirements or anything else such that, like, it's fine to have a roll-up with a high node requirement because a roll-up only requires at most one person to protect it. So, you know, one computer to run it. That's okay. Maybe you need a few. That's all right. But when you're putting it on the entire network, like every single validator, right, 10,000 validators, you're requiring that they have this kind of connection speed and this kind of node requirement. To me, it fundamentally changes the whole game. So, yeah, these are like where I think some of the stuff stems from, just to go down that rabbit hole. But I think it's a very important rabbit hole to go down. It comes down to what the social contract is of Ethereum, particularly what we want out of blockchain. And I think Ethereum right now, fortunately, very cypherpunk. It's very. run it on a Raspberry Pi and we can progress. the world state transitions enough. And I see Vitalik gravitating towards this direction spiritually. And I think the community is gravitating towards this as well, because this is the selling point. Like that's actually the biggest win we have over every other layer one competitor is that we're true to the ideals of what really fundamentally makes crypto different and valuable. Otherwise, you're just a federated server. You know, you're just a federated server. Go have fun with Jeff Bezos and Amazon. That's great. But that's not what this was about. You know?

Nicholas: Yeah. Yeah. I don't want to get derailed by it too much. But even in a world where or in a blockchain where the node requirements are low enough that you can run them on a Raspberry Pi, there are still like a variety of threats. Lido, Eigen layer, etc. To aggregation of staking such that it can compromise the network's integrity. I don't know. The details around what number of independent stakers you need for the network to be decentralized.

Nick Dodson: I don't think there's a magic number ever. I think it's just sort of like, again, what could happen in adversarial scenarios and what is sort of the social layer demand from this. But I think that unfortunately, Eigen layer, you don't get anything for free with physics and blockchains in general. And unfortunately, there's a lot of getting stuff for free with restaking that I don't quite like. And in that sense, the tradeoff is, well, we're increasing the risk significantly for things to go wrong for stakers. And then we're also increasing the amount of what we're decreasing, in my opinion, the crypto economic security of things like pretty significant. Because that wasn't factored into the original staking designs, like the fact that you would have people take additional computing risk on top of this. And so, like, basically, this is a fault of proof of stake. Essentially that. Well, you could have proof of stake, but you could have the same person take enormous amounts of stake that are outside the system. And that's just a flaw of the system, I would say. Yeah.

Nicholas: I wanted to go back, and we will get into the details of Fuel, because I'm really excited to talk about the specifics of Fuel and what its design is and what it prioritizes. But first, you mentioned a little bit, we talked about, talking about roll-ups, about sort of backing out to L1 if anything goes wrong in the roll-up. Yeah. I'm curious about, and you also mentioned this 5,000 TPS figure. First of all, with the 5,000 TPS, I mean, there is this issue of, like, induced demand, right? Where if the price, like, you look at a chain like Polygon POS or something, and the gas was so cheap, or at times has been so cheap that there's just a huge amount of bot activity that ends up, in the case of Polygon POS, at least previously, causing these, like, huge reorgs, like 100-plus block reorgs, etc. Not that that's specifically a problem for roll-ups. Yeah. But it's not clear, I guess. I guess that if you just increase the bandwidth that you'll get more, you know, you may just get more sort of low-grade kind of transactions. Do you have any thoughts on that?

Nick Dodson: So bandwidth is only one area of, again, blockchain that you're going to have to deal with when it comes to this. It really doesn't solve much. You can increase data and still have enormous issues elsewhere. And issues just build up all over the place. With a system that progresses state through time and needs to hold certain bits of it and needs to do things. You can do so in a very efficient manner. that's, like, really quick and verifiable for everybody. Yeah. It's -- the tradeoffs are immense. So, yes, you can do enormous amounts of TPS. But how are you set up to be ready for that in the long term? And essentially with, I think, blockchain design in general, like, sure, you can increase the node requirements. You can increase the bandwidth. And you can get, you know, anywhere from 160,000 to a million TPS per CPU core. Depending on if you use GPUs or not and these other things. Right? You can do all of that. That's wonderful. The other issue is, is that, like, well, where do we keep all this data? And who keeps it? And when? And how? And what's a sustainable plan for that data if you could actually do all of it? And, of course, if you can process all this stuff and it's really costing you an enormous amount to process, like, you're going to charge more for it. And you're going to want to see what the bidders are on this particular block space. Before you just go selling it to anybody. So, there is a market here. There's a market for block space. And there's a market that's constantly shifting and moving. And the players that can give the block producer a better deal and give them more money and do more transactions potentially for that are the ones that are going to sort of win the game, basically. And with Ethereum, we do have a limited number of block space. And we have a lot of people that want to use it. We have a lot of people that want to use it for different things. So, it's not to say that bandwidth really solves very much here. It doesn't. You still have a very aggressive market. But what it does do is it opens up a bigger creative field where now both ZK and Optimistic Rollups, they can do a lot more than we could have done before. And in that space, we can use it more creatively, producing more fees and then thus making that space more valuable. So, you know, it's one thing to say you can do a few hundred TPS. It's another thing to say I could do a few thousand. Right? And when you do a few thousand, that's potentially a lot more fee generating, which does flow back up to Ethereum stakers and Ethereum block builders. So, effectively, you can call it -- it's more creative bandwidth, basically. But creative bandwidth. In and of itself, the bandwidth is not that really great. And, yes, you could just put everything on it like we do now. Maybe it gives some of these Optimistic Rollups a few more hundred TPS. It's not really a massive deal. But when you really talk about advanced solutions. And you talk about the way the space could be creatively used. And you also talk about ZK and other things. Well, then things become a lot more interesting. You can do a lot more TPS with it than people think.

Nicholas: The second question I had was if -- is the premise of -- I mean, if we're able to reduce the -- or increase the bandwidth, reduce the cost of interaction by creating Rollups that are just more convivial because they're lower cost and can handle a greater number of transactions. And if the purpose is to scale to a larger number of users by that kind of gesture, does the Optimistic Rollup design in which your security is sort of? the last word on security is that you can back out to L1. Does that not depend on all of the assets that we're interacting with on the L2s being L1 native assets? Which kind of precludes the possibility of new assets on L2s being the interesting ones. Like if you imagine, I don't know, someone who is not yet using blockchain, but if the price drops low enough and if there are interesting enough things they can do, create a meme coin, create an NFT, do some kind of swapping of something that is an L2 native asset. Do they get any of the actual security guarantees that Rollups promise if the asset isn't itself an L1 native asset?

Nick Dodson: I would say so, yeah. Because it's not so much about the asset. It's more about if the asset wants to come out of a Rollup and live on Ethereum, there just needs to be a canonical and deterministic asset. That's not really the issue. The issue is, is the state transitions through the Rollup valid and being validated by the security of Ethereum, right? And so that's actually more, I would say, the question. It's like, is the entire Rollup itself state transitioning in such a way that is inheriting the security of Ethereum, right? That's the greatest Rollup you can build. is you could say, I've created this really great execution environment. I'm doing all these transactions. All these people love it. And I'm inheriting it. I'm validating the security of Ethereum. All these people who are validating Ethereum are helping secure my network that we just built outside of Ethereum. We built completely on our own, right? That's like what you want, right? That's the ideal situation. is to say, we have the security of Ethereum. But in order to say that, you have to make some pretty good arguments, right? In order for Arbitrum or ZkSync to say this, they need to make some pretty good arguments. So with ZkRollups, the argument is just that. Well, hey. So long as the data is made available to state transition these state diffs and the ZK proof is there, you can basically always ensure that at some point you can just transition out and you can withdraw and go back to the safety hatch. And the validation of the state transition happens in the ZK proof. So it's always so long as the circuit's good, you're great. You're done. You're golden. You've inherited the security of Ethereum. For an optimistic rollup, we basically say, well, so long as we have a long enough period to submit that any of the state transitions are invalid, right? So long as there's enough of a period there that it's basically enough that anyone in the world could submit a thing that just says, there's invalidity, right? You need seven days. Just submit one little message on Ethereum that says, there's invalidity here. Let's hit pause until we work it out, right? We consider that enough security to say you've inherited the security of Ethereum, right? So they're different games with different tradeoffs. But basically, that's the sort of game you play with Ethereum. And the most interesting thing is, is that really, if you can get that seven day, it's a made up number. It could probably be one day, really, given how crypto economically safe Ethereum is. But the idea would be that if you could get that period down on Ethereum just somehow to a few hours for an optimistic rollup. There would be no need for ZK rollups. Because basically, you want the ZK rollup to say it's true by this point. And you do so by cryptographic proof. But if you could do it just by validating on a regular machine once and just having some kind of mechanism to say, hey, it's true. Then you wouldn't need ZK rollups at all. But we have both techniques working because Ethereum costs a certain amount to censor and break or fork. Takes some time. Takes a certain amount of time. So seven days is like considered enough. One day is probably more than enough for an optimistic rollup. But basically, these are the sort of things at stake on this particular mechanism that make this work. So and the whole idea is you want to be able to say we've inherited the security of Ethereum. We've given enough opportunity. We've given enough time. We've given enough effort into all of this that so long as there's no bugs in the contract, this is inheriting the security. Yeah.

Nicholas: So, yeah, let's jump right into fuel. So maybe can you explain what was the impetus for creating fuel and how does it distinguish itself from other rollups and from Ethereum? What makes it special? What is fuel?

Nick Dodson: Yeah. So it stemmed from initially, as I mentioned before, we just wanted to create a wallet on Ethereum. So that was it. And we just in this wallet, we just wanted a world where we could have a cheap transaction, which you would think wouldn't be too much to ask from a system that makes transactions. Right. But as it turns out, that was not great. So this led down a giant path first to basically building the first production optimistic rollup on Ethereum. So we did that with Fuel V1. And the idea there was to make transactions cheaper. So literally load in these tokens we have on Ethereum, put them in the system, and then I can make transactions cheaper. Now, how did we do that? We used a cheaper model for executing the transactions. Right. In that model, it was a UTXO model. It allowed for an interesting kind of transaction design. And in that, it was, you know, maybe 10, 20x cheaper than sending it on Ethereum at that juncture. Right. So that was where it started. And then as we built that system out and as we started to realize that the space was gravitating towards DeFi and it wasn't just about sending transfers around, maybe doing really basic atomic swaps, which is what Fuel V1 could do. But it was about actually doing basic atomic swaps. It was about making very sophisticated kinds of DeFi. We realized that we needed to shift our focuses of research from how do we make a transfer or an atomic swap cheaper to how do we make all of DeFi significantly cheaper, but also really wholeheartedly fix some of the issues that we saw with Ethereum. And so we decided that while you could in many ways just have the EVM and basically do it again, just throw it in a rollup. Right. You're recreating all the same problems which got us here in the first place. So it's like problem inception. You know, it's like, yes, you can take this thing that's problematic. And then because everyone's using it, you can just throw it in a rollup. And, you know, that's wonderful. You can. It'll make it cheaper for Ethereum. But it just basically shoves that cost up now to a different layer. So you can do that once.

Nicholas: So you can get the benefit of familiarity, but not an architectural improvement.

Nick Dodson: That's right. So you're still really restrained. Both with the kinds of designs you can do. And the amount of throughput you can handle. So we decided that we wouldn't go that direction. So we took the very, very painful direction of not doing that, of basically going completely against the entire community, the wishes of everybody, the advice of thousands of people, and decided to build a completely bespoke architecture that solves a lot of the issues that we had seen with Ethereum. So in many senses, we decided to build a different kind of system that would hopefully address the core issues. The core issues of sustainability that we saw with Ethereum address the throughput issues, address the ways that users use blockchains, right? So imagining that it's really about how users actually use this stuff that affects the core design all the way down to the virtual machine, all the way down to the rollup. So, unfortunately, with blockchain, like, everything matters. Every single design decision you make matters. Everything has catastrophic effects in different places if it's not designed correctly. So you need to take into consideration all of this. And we were very fortunate that both we could look back at all these other systems. We could look back at even newer systems. So we looked at Move. We looked at Solana. We looked at, you know, a lot of the ZK stuff that was being done. We looked at the EVM designs. We looked at Bitcoin. We looked at everything, basically.

Nicholas: And it's around 2019, 2020?

Nick Dodson: Yeah. This is, like, within 2020. We were starting to build this research up. But 2021 was when we really started to build the sort of fully-fledged idea of doing our own virtual machine and our own system for this.

Nicholas: So pretty recent.

Nick Dodson: Yeah. Pretty recent. December 2020 was when we launched Fuel V1. Then sort of days after that, we just sort of set out to actually do this next thing, which was let's go and fix actual blockchain processing in a way that no one's ever done it before. And so, in a sense, we did it. We incorporated a lot of these design decisions that we saw. And there's a lot of incredible work that's been done, both in the research space and in all these different communities. But, of course, being very opinionated and very picky, and picky for reasons of real throughput, centralization, sustainability for blockchain, we didn't go with anyone in particular. We didn't like things about all these different architectures. But we picked the best stuff from everyone that we could. And we tried to create something that... I think, you know, right now, we've got a lot of ways to go to really prove to everybody that this would be a superior advantage for everything. But I think that over time will make sense because the calculus will make sense because the pressures will be known. And people who today run an EVM chain will now start to really, really feel how bad that decision was and what kinds of architectures they'll be looking forward in the future. And that also goes for Move and Solana as well.

Nicholas: Yeah. I've heard you say... So, first of all, I think it's worth noting that it's not just picking and choosing from in the abstract. But you've been in the trenches of building with EVM for a long time. So, you know the pain points intimately.

Nick Dodson: I know them very well.

Nicholas: I heard in some other interview, you're talking about writing assembly for projects years ago and optimizing things at a low level. And these are not new issues for you. So, you're deeply familiar with the limitations of ERCs. There's a lot of these that haven't been picked up over the years and just inefficiencies in the account model, serial... Yes. ...single threaded execution in the EVM. These kinds of issues come up. Do those seem like the high-level big pain points?

Nick Dodson: I mean, there's so many. Just the list is enormous. But yeah, with EVM design, it usually comes around a few different things. One is that there's giant Merkle trees everywhere that are stored in state that have to be updated one by one in a linear fashion. And yes, you can pipeline these, but it's such a waste of resources to have to go through. And just to retain this one structure, actually pipeline all this information. So, accounts...

Nicholas: Just to dive in a little bit on that. In EVM, you add a leaf and then Merkleize again. And this is computationally intensive as compared to what? Yeah.

Nick Dodson: So, if you can imagine this, right? An ERC20 transfer. Let's just go zoom into that for a second. Every time you make a transfer, just one transfer. What you have to do is you have to go... You find the account of which it's subtracting from. You find the account which you're going to add to, right? And then for that account you're subtracting from, you change that value. And then there's a tree that's supposed to encompass every value, which is a size of 256 depths, right? So, then you have to go up this giant tree and you have to rehash and restore 256 depths for that one value. And then you have to go to the next value. And then you do the same thing. You update this giant Merkle tree. Just for one transfer. So, that's all this work that we have to go back and forth to disk. We have to do all this hashing. We have to do all this stuff. Just to make one transfer on one smart contract on Ethereum. Now, imagine every single state element, every single piece of state in Ethereum. You have to do the same operation.

Nicholas: And you have to do it each time the state changes, not...

Nick Dodson: Each time. Each time. Because you don't know necessarily how the leafs are going to change. There's maybe some efficient pathways to like sort of do this better. But the thing is just the way that it's constructed. It's like you unfortunately have to do this and it's really painful in your fashion.

Nicholas: It's actually kind of impressive that you can compute 30 million gas worth of that on a Raspberry Pi for something like... You picture like a cow swap transaction or something like... Zero X transaction with a ton of different state transitions. Yes.

Nick Dodson: That's, you know, again, CPUs even now, even in Raspberry Pi are actually super powerful. They can do a lot of work. They can do a lot of stuff. So, it's not to undermine the fact that this is... This is very, very important stuff and it's also stuff that like you want to do. But at the same time, it's like enormously painful to process. It's very, very baggy. It's very, very slow. It touches a lot of the drive which ends up being very, very slow. So, building these systems and processing them is enormously difficult. So, that's one thing. You have the same process happening with the accounts tree which is separate. And effectively, this leads you to a lot of bagginess both in state and IO. And to build this state and IO, it really significantly slows the system down. So, that on top of other design choices that were made like 256 bit words and the way that Ethereum encodes and decodes, the way that smart contracts work, the way that transactions work, the way that things work in Ethereum, it accumulates to this giant thing where it's like, yes, it's kind of coherent, it's kind of simple, it kind of works. But man, does this thing suck. know like it's just horrible to build anything sophisticated with and like we want to build sophisticated kinds of designs like we want to build sophisticated kinds of financial infrastructure. and we can't right. and that's the the really painful thing. it's like we're all so close we're all here we're all ready we're all sophisticated we all know what we want and you can't do it you know. and then that's sort of the the frustration right that's been building up for many years. so everyone's got different ideas to get rid of that. but for ours you know the idea was that if you use UTXOs. they come with interesting properties. they come with a property that basically instead of having this model where every time you touch a state element you have to re-mercolize everything. instead you can get rid of all those trees. you can get rid of all that stuff because every UTXO is unique and every UTXO cannot be double spent. and by that you can infer that that all you need to post is sort of the spends and the inputs and the outputs. And that ends up giving you the diffs for everything. And that ends up giving you the state transitions. And that ends up making everything valid. And as you validate through time, this is the way that things hold up. So effectively, UTXOs end up being sort of like what ZK tries to do with just posting state diffs in a sense. But every block for fuel is just diffs. So you don't need to have these giant Merkle trees anywhere. Now, we still use the same Merkle tree concept within smart contracts. And smart contracts take the form of these input/output spendable elements. But it's localized. So there isn't this giant tree. It's localized to each smart contract, which means that now I can have thousands of different smart contracts, some touching each other, some not. And those become inputs and outputs in the system. And that is a significant win, because it allows all the cores and threads of your CPU to validate everything and make sure that it's true. And you can just keep adding more threads and cores as you need more resources over time.

Nicholas: Yeah. So you can-- just to really make that clear, you can-- and this is one of the big selling points of fuel-- is parallel validation? Parallel execution?

Nick Dodson: Parallel execution is what I would call it.

Nicholas: And that's because under a UTXO model, there's no possibility that the same input and output-- Yeah. And they are being manipulated on two parallel threads, so you can process them. So does that mean that essentially-- I guess I think of a blockchain as a single-threaded history of transactions in blocks. But here, you're able to validate-- simultaneously validate, let's say, two halves of a single block at the same time. And it doesn't-- They don't depend on the prior states. You're able to do them simultaneously without a problem.

Nick Dodson: 100%. Yeah. So you have full capability to-- to statically analyze the block before you process it and basically notate, hey, like, these transactions are going to touch this. These transactions are going to touch that. And then you can-- that's like a simple analysis, right, just looking at the pointers and the data. And then you can break that up into threads and parallel process that. And not only can you parallel process a block, you can parallel process many blocks. So you can do all of them-- you can do hundreds of blocks at a time, basically, for each thread. And so when you have that kind of scope and that kind of dynamic, you end up being able to parallel process enormous amounts of transactions. So inherently, parallelism is part of our design. But it's also that in using UTXOs, UTXOs also use a lot less state because they are destroyed from state when you spend them. And so with some clever techniques, you can basically reduce state significantly. because while you're going to have people that might have a few UTXOs under their belts, like, all those things have to be stored somewhere anyway. And you end up realizing that, like, yes, you get a bit of duplication here and there. But UTXOs end up being really-- they're sustainable because if I spend it and my balance is zero, I no longer need to keep an eye on that. Like, for that asset, it's gone now. And that ends up being much more sustainable, too, on state. Whereas with that giant tree, you have to keep everything all the time.

Nicholas: I mean, I guess it shows what a sort of app layer noob I am. But it seems extremely ambitious to me to swap out the underlying model from an account model to UTXOs.

Nick Dodson: Yeah, but UTXOs are far superior. Yeah. The properties are enormous. And we're not even getting into yet the application-specific properties of them, because we also have things that allow you to use UTXOs in clever ways.

Nicholas: And like-- Would predicates-- predicates are things Apple-- Exactly, yeah.

Nick Dodson: So think of this. With Ethereum, you only have really two ways to do things. You can make a transaction. You can make a transaction to deploy a smart contract. And that's kind of it. And so you kind of have-- --smart contracts. And you have transactions to talk with them, basically. And that's all you can do, right? With Fuel, we have way more stuff available. So you have things like scripts. You have things like predicates. You have things like UTXOs, transaction design, smart contracts. You get all the benefits and nice things of Ethereum in terms of smart contracts. So we don't lose that. But we give the developer all new kinds of ways to do things, different ways to approach all the same problems in completely different, more sustainable ways. So-- Yeah. --you can use the UTXO model itself. And you can say, hey, OK, what if I wanted to do half my app, but I don't want to use a smart contract because it's too expensive? I don't even want to pay for that state. I just want to do it at the transaction level alone. I don't want to touch state, smart contracts, or anything. The idea is that with predicates, you can do an enormous amount of stuff. What predicates are is instead of me sending to your address, I send to a hash. And the hash is a script. And if the script returns true-- Yeah. --basically, something will happen. The assets are spent. And whoever spends them in that transaction can dictate where they go. With that model, you can do atomic swaps. You can do exchanges. You can do aggregation. You can do all kinds of different transaction design that you just couldn't do before. And that's never touching state, really. It's really just at the bandwidth and execution level. And the idea there is-- it's really that you want to provide the dev as many ways as possible to not use smart contracts and not use the systems that are really heavy, maybe sparingly. And what we've learned is we can do crazy things with predicates. We can basically say, hey, I've got a predicate that says-- and predicates are stateless, so they don't have any state to them. But in Fuel, they can introspect the transaction itself. They can look at all the data in the transaction. And with that, you can basically have state elements that are like UTXOs. And you can do this thing called state rehydration, where you can-- basically, graffiti a state root onto a UTXO element. UTXO elements are only spendable by the predicate. And with that, you can do smart contracts, but through predicates, but without any state. And you rehydrate the state over bandwidth every time. And in that, you have a much more efficient system, basically, something that a smart contract would never be able to give you. But because you have UTXOs and predicates, you can do this now. Now, at a global scale, that's way better than having everyone have their own smart contract. Like, imagine if everyone had their own Gnosis save. We could never build a system to handle that with the EVM. But if everyone did this method, we could support the entire world. So it's possible.

Nicholas: Yeah. I guess WorldCoin is testing that theory currently on Polygon, if I recall.

Nick Dodson: Yeah, good luck. I mean, really and sincerely, in my deepest heart, I really wish you the best. And I really, really hope that it works out for you. Yeah, if that makes sense.

Nicholas: So my understanding of predicates is that, basically, instead of deploying a smart contract that subsequent transactions will interact with, you can add a kind of in-memory static function that will execute whenever people interact with the-- I guess it generates a UTXO, a hash that you can interact with. And as such, you can do interesting things, like even restrict transactions based on different kinds of signature schemes or pay for transactions. So you can do different kinds of transactions in different tokens. Is that also an element of predicates?

Nick Dodson: Yeah, so imagine this. So because we have the spending condition thing, it's like a license to create any kind of account you want. So it's a very clean system, too. It's not trying to say that every account is a smart contract. Remember that. That's an interesting idea, but that's really stateful. As we've learned, smart contracts are very stateful. So what this is a little different is to say that, OK, we have this spending condition. That's great. But the spending condition could say, hey, I'll only be spendable if you provide me this ED255 signature from this Solana signing format. OK, well, now I can support Solana wallets. OK.

Nicholas: because you're just verifying the signature.

Nick Dodson: Exactly, just validating the signature. And then you can say, hey, you know what? That's cool. I'd like to also support P256, so I can support web auth and signing. And now I'm signing with my secure enclave. I can support that. And then you can also design the predicate to say, hey, you know what? When I look at the transaction, the first two inputs and outputs, I don't need to provide those. Anyone else can provide them. If they want to provide an ETH something else, that's fine. That other person could be a fee payer, could be someone that submits the ETH. And then you maybe agree on something, and they sign their portion, you sign yours. The transaction's true. It can be sent. But now you can do all kinds of really interesting design. where multiple parties can settle in different ways with different assets covering different elements of the execution at different times, so fuel because it has multiple inputs, multiple outputs, multiple witnesses, scripts, predicates, and smart contracts-- that gives you enough facility to basically process all the different kinds of sustainable transactions that you you would want in such a way that we can retain decentralization we can make things very very efficient but we can also do really extraordinary designs where you could have a trend. a single transaction that has like a cosmos wallet involved a solana wallet involved an aptus wallet involved each paying with different assets each paying the core asset with eth from a fee payer. that's also doing an atomic swap.

Nicholas: that's also calling three smart contracts all in one transaction from different parties all settling at the same time and with that act could it also act like a kind of static library that people could access for arbitrary uh transactions? or is it a specific transaction that we're like unlocking? you know i put a kind of a vault of one eth up and you need to sign with x y and z wallets across cosmos and solana. or could it be more generic than that?

Nick Dodson: you can do both. you can do both. you could have the design such that a fee payer comes along and it sees a partially formed transaction. that goes okay. i'll tag on some eth to that and then make spendable and that'll work right. you can also have a smart contract that has some stipulation around it. you could also have an asset that's tied to a predicate that anyone can see and they can just come along and spend it but they have to spend it under certain conditions and again because the predicate can introspect the transaction data itself. it can see all the data that was posted. this means that you can get very very clever and very very creative with what kinds of in-memory predicates you have and you can do designs that in blockchain we've never ever thought of before. basically it's very very good cool.

Nicholas: um i kind of one of the things that i i i've discovered about fuel is that you're sort of planning for the landscape five or ten years from now when these kinds of consequences of single threaded uh you know whatever highly stateful design and one of the things that comes up in that is this um concern with stateful like uh the kind of existing optimistic roll-ups and account abstraction in the form of four three three seven on the evm kind of making this mistake and uh being overly concerned with is it uh call data cost as opposed to state cost which is actually ultimately going to resolve to be the more problematic one in a post 4844 world? maybe could you explain a little bit of that why that's the case for someone who sort of hasn't seen the light yet?

Nick Dodson: yeah i think every design has a trade-off in blockchain because you only have so much. you have limited compute space for what each validator is processing so effectively. um with the way that some of these things are panning out both with 4844 and also with the way that account abstraction is being designed in the community i think that there's a lot of mistakes that are going to be made because the system is both not flexible enough. it doesn't take into consideration all the kinds of multi-party settlement that would probably happen. it ends up being too rigid and then it ends up probably being too stateful and that gets you back into the same problems that put us in this whole position in the first place. it's like all these things are just repeating over and over again and right now i think the problem is that we're not going to be able to do that exactly. you don't have to try and figure out how to do it anymore. so i think it's really important to try and get somewhere where the market can see what these ideas are and then start to work to understand that we just don't have a lot of information to do it but you really need the. and then maybe you start to think like okay i want this to happen and i'm going to do it in the next to a wallet, to a hardware wallet, to credit cards, et cetera, it doesn't matter. Whatever user you've got, you can support them in a journey of being non-custodial and interacting with these things. And the user experience is incredible. And that's what you really, really want out of the system. And the current state of things is such that people are not understanding all of the core trade-offs of, well, if it's a little staple, that's fine. But it's like, OK, but wait a second. Now multiply that over the world, because that's what the TAM is of our technology. And it's like, now you haven't designed the right thing. So for us, we're designing for a world where I think we want to have billions of people actually use it. But also, even just for us to even try to introduce it to them, it would need to even be somewhat approachable to begin with. And you would want to think about these things and have these things covered so that you could actually bring this to the world and it would actually work in this way, but still retain the cypherpunk things, as I mentioned before, that make it valuable in the first place. Otherwise, it's not even worth doing. You could just do it with a server and do whatever you want.

Nicholas: So something like, for example, roll-up improvement proposal 7212, I think, is coming to base, or the Optimism ecosystem soon. But in order to take advantage of that, you need to have a smart account. So the concept is that regular users will have pass key, signers. They'll never see their private key or seed phrase. Only the public key will be-- will be shared in the constructor of a 4337 account on some roll-up. But this is highly stateful, right? There's no way to get a P256 signature verified inside of a vanilla EVM transaction. You need to have it be a user operation that's being propagated from a 4337 mempool to via a bundler, via an EOA transaction into an entry point. that then triggers the--.

Nick Dodson: Yeah, yeah. I mean, already, again, it's just band-aiding a significant issue, right? And so with ours, all we did to support WebAuth and P256 and everything was, the VM just has P256 in it. And then in the predicate, you just go, verify P256. Just make sure that the P256 signs over the transaction, and you're done. And that's totally stateless. It completes native-level account abstraction, native-level security. There's no fancy tricks or anything. It's just what it is. That's your account.

Nicholas: And it's not just another roll-up saying, oh, well, we'll just put P256 as an opcode or as a precompile.

Nick Dodson: Because it's a user experience issue that stems from the transaction design, which also stems from, well, how expensive and stable is that transaction design in relation to everything else? And how exactly are you wiring the whole thing together? Yeah, so unfortunately, you really do need all the things that Fuel brings to the table if you really want to solve these problems. Otherwise, you're basically left with a very half-baked solution or a Band-Aid solution. And Fuel is not about Band-Aiding. It's just about, well, we'll just solve these things now. And if people don't see the value in that, we'll try to show them. And over time, it'll be very, very apparent why we did this and why we did all the things with Fuel in the first place. But for us, it is a long game thing. And we want to make sure that the tech that we build is both really, really compelling, completes a really incredible user experience, but also is completely sustainable and decentralized and keeps to those values. And in that, in that whole package, both with our virtual machine, our language, and everything else, we're sort of calling all of that a roll-up OS.

Nicholas: And we're calling--. Yeah, so this is the new latest announcement, right?

Nick Dodson: Yes. Yeah. So in that, we're just trying to say that with all these different things, you can say that there's arbitrary OS, there's different kinds of OSs out there for roll-ups. We are the roll-up OS. The one that designed for roll-ups from the beginning, since the start of the project, all the way through to now. So in a sense, this has always been what we wanted. And all these different tools, all these different things that we've made are all in the support of roll-ups themselves.

Nicholas: So it's a VM. It's a programming language. It's a set of developer tools that are designed not to prioritize familiarity or bridging over the Solidity developer set via EVM equivalents, but, instead, really designed from the ground up for roll-up, to be the perfect roll-up, ideally. Yes.

Nick Dodson: And not only that, some tag lines to remember will be any wallet, any asset, out of the box, native level. Second thing is that Sway, you write once, and that's it. You get everything for free. So write once in Sway. You don't need to write it again. All the business logic tests everything.

Nicholas: In what case would you have to write it again if it were a roll-up with a different set of--.

Nick Dodson: Well, for example, if you write a smart contract and you have to write indexing, well, you'd have to use Rust or something else. What if that was all in Sway? What if everything you wrote for your app, back-end to front-end, the entire conception of the app, was just Sway? Maybe a front-end bit of code, and that's it. That's the dream. You write once. You get everything for free.

Nicholas: So let's talk about Sway a little bit, because we didn't really get into it. But we talked about all these incredible predicates and things that you can do in UTXOs and some of the efficiency. But how, from the perspective of someone who's maybe written a little bit of Solidity or who's taken a read-through of a contract or two on EVM, how do you think about writing this code in Sway? How complicated is it?

Nick Dodson: So Sway is very much-- user experience-wise, it's going to be similar to-- if Solidity was nice and actually designed well and designed in a way with a more sophisticated type system, and a more sophisticated way of understanding language design. And in a sense, it's like if Rust and Solidity had a child, basically. And we took the nice things about Rust, and we took the nice things about Solidity, and we created something new. And in that sense, both Solidity and Rust devs would feel very at home. But I also feel like even people who are just familiar with smart contract coding in general would feel very, very at home. And Sway is really designed for smart contract development, but it's also designed for blockchain development. So really, everything from what we want to do with it, like testing, like deployment scripts, like indexing, all these different things, will all work in Sway. And Sway is flexible enough to really accommodate that. Solidity, not so much. But Sway is very flexible in that sense. And with Sway as well, the idea will be that I can write it in Sway, and I can get Arbitrum Stylus for free. I can get a Solana backend for free. All these different blockchains I can get, I can get it for free when I write it once in Sway, because it's a blockchain language.

Nicholas: So you can write code that would be executed in a Solana EVM?

Nick Dodson: So the plan for Sway will be that-- and this is the plan. It's not what it is now. Right now, you just write fuel apps. The plan is that you'll write your app in Sway. And if you wanted the code to target the Solana backend, we'll have a backend for you. If you want Wasm, you'll get Wasm. If you want the EVM, you'll get the EVM. But you write it once in Sway. And it targets all these other environments.

Nicholas: So turning the different environments into a compilation problem, rather than requiring an entirely separate language.

Nick Dodson: And each of them having a tuned standard library for them. And I think that, in that sense, that's your big win as a developer to learn it. Because why would I want to learn it if I can just write fuel apps, right? Like, if I'm just talking really harshly about fuel, it's like, we're pretty niche, right? So why would I want to learn, as a dev, a new language? Well, it's like, well, what if I told you you could do all your business logic in it, and it was a nice language? And you wouldn't need to rewrite things again, right? You just write it once. You get all this stuff for free. In that sense, that might be worth learning, right? That's an offer.

Nicholas: might be writing the bridge contracts, or the vault contracts on, say, Solana or something, in order to get assets into fuel.

Nick Dodson: So I'm talking about, forget fuel. Just writing Solana.

Nicholas: Mm-hmm.

Nick Dodson: Yeah, yeah.

Nicholas: like verifying contracts, or what? Like, Etherscan won't verify Sway.

Nick Dodson: Well, the thing is, of course, there's always compilation issues, et cetera. But I would just say that-- or support and tooling issues. But the main thing is that if you're going to build a new language, you might as well make it maximally useful, and maximally useful for what developers want, which is blockchain development. So the end state will be that Sway should be this very generic, general-purpose blockchain language that really can target all kinds of different back ends. But for now, it's just for fuel, and we're going to build the best environment we can with fuel. But we hope that we can expand that out over time, yeah.

Nicholas: Mm-hmm. I know we're going a little long today, but I just had two questions I wanted to get to. Modularity is also really important in the fuel ecosystem. What does modularity mean in fuel, and how does someone take advantage of that modularity?

Nick Dodson: Yeah, so modularity is very important, I would say, to just our ethos of design in general. So everything we do, both internally within the project in terms of our-- construction of things, and also the way that the space is transforming is in the ethos of modular itself. And in this sense, I'd say that it's just good design to build stuff that can be used in different ways, where it can find value in different ways. So for us, we want people to run a fuel rollup, for example. But if they want to pick Celestia, or Vale, or EigenLayer as their back end, that's up to them, right? If they want to pick Ethereum as their back end, we've got a great compression solution for 4844. If they don't want to pick any of those, they don't have to. And as well, if they want to write smart contracts in Solidity and then deploy those to Fuel, that will also be possible. You want different layers of the stack to be flexible in different ways. If you want all your users to be able to have Cosmos wallet support, but run a rollup that is settling to Ethereum that's posting to IBC somehow and going somewhere else, we can support that. But we give you all these things for free. We give you a system that is sustainable, parallelizable, high throughput, very in the ethos of decentralization and to the values of blockchain itself, and very accommodating to all the kinds of designs that you would really want to do, like high performance designs. And doing so in a way that was truly designed for rollups.

Nicholas: Yeah. What is it about the architecture that-- it sounds very ambitious to make everything modular, every piece of it. Every piece of the code can be plugged into something different. What is it about the architecture that allows you to do that? Or how do you achieve such an ambitious goal without being overextended?

Nick Dodson: I think the thing is, for us right now, we just want to ship our core rollup. So this year is going to be really about that for us, and shipping the main rollup and getting that out the door. Beyond that, though, you have to think that people are going to come to your project in different ways with different needs and different ideas. Different ideas about security, different ideas about users, different ideas about how they want things to happen. And surprisingly, if you can accommodate it for your own rollup, you can accommodate a lot of other things for a lot of other systems if you just design it correctly. So for us, we're in a fortunate position that things are designed knowing that this would happen. This is built for rollups. It's built for these realities that we're seeing. Projects want to launch their own changes. They want to launch their own sovereign systems. And we want to support that. We want to support that in a really big way. For a lot of different people, that's got a lot of design packed inside of it. So for us, that's really the end state, is that we knew rollups would be really powerful and that a lot of teams would want to use them from the first day we started our designs. And that filters through all the virtual machine design all the way through to the language and everything else that we have.

Nicholas: The last question I had was really around kind of go to market and marketing. I know you've said a few times in other interviews, too, that sort of-- low quality projects are not something that you're particularly interested in attracting to fuel, or it's not a priority for you to get kind of the most D-gen activity on fuel. But it does also have an impact. I mean, we saw recently like Blast, something like that, getting, I don't know, a billion and a half in TVL with a multi-sig as it's rollup. And other projects that-- I mean, so many projects, more than we can even name, that are maybe not as strong on the technicals, but are very good at the marketing, or go to market aspect. Do you think that is going to become increasingly important for fuel? Or do you think that in the long term, you're just going to have so many years' worth of built-up technology, having foreseen the inevitable problems that EVM-based solutions and Solana and other VMs are going to face, that ultimately, people will just have to-- there will be no way to catch up with fuel in terms of technology, given the years put into it, such that the marketing is not as urgent?

Nick Dodson: I think-- I think that fuel is very, very long-term in how we think about everything. So there's a lot of short-term wins you can get with total degeneracy. I don't think that's really-- if that was really the end sum of all this work that we put into this, I don't think that would really be very fun. So I think that at the end of the day, we're not completely ignorant to the fact that there's a lot of degeneracy happening, and that unfortunately, the space is driven by a lot of that. And to be honest, it's like, so long as people don't get hurt in terms of their financial means, it's all just part of the process of growing a new kind of financial system. That's great. But I think that unfortunately for us, we're plagued by being these engineers that want to actually fix these things, and we want to actually do it correctly. So I think with fuel, I would hope that if people want to build their own chains, they want to do their own stuff. And they want to enable a certain high level of degeneracy. I certainly would never want to stop that. And I don't think we're a project that-- we admire it as much as we fear it. So I think that we're not an anti-degeneracy project. I would just say that we're also fairly agnostic to that. And in fact, I would argue that fuel will create such levels of higher order degeneracy that you would wish that could have happened on saline.

Nicholas: 5,000 degens per second.

Nick Dodson: Yeah.

Nicholas: So just-- I would not be concerned about that.

Nick Dodson: I think we're going to enable more than enough of that. I think for us, our main struggle as a project and something that we need to overcome is really communicating the vast sum of different things that we've done in a way that people can at least just digest them over time and realize the solution we have, versus overwhelming someone with 5 million different design decisions we've made, and then just be like, and it's amazing. Come over here. I think it needs to be sort of a back and forth between developers over time. But we're very confident that we can win developers, because we know what we've built, and we know what we've done, and we know the kind of solution this is going to be. And we don't need to do temporary short-term gains and wins to feel good about that. I think for us, it's about long-term thinking and long-term build that is going to create a lot of value for the space. Yeah.

Nicholas: I know you've also prided yourself on building Fuel entirely in public, right?

Nick Dodson: I muted myself. Yeah, exactly. So for us, we're building multiple test nets out in public. And basically, the one thing that we will want to change in the ethos of the whole space is we do have a BSL over some things, and that will go away eventually. It was mainly because we saw some super degenerate behavior from certain projects kind of beating people to the punch before they launch. And I think that for us, we just want to make sure we had a bit of time before we go live. But in general, that goes away, and we want to make everything very, very open source.

Nicholas: It's very open source. Yeah. And how many people are working on Fuel now, both inside the company and sort of in the open source space around it?

Nick Dodson: Yeah, I think in the open source space around it, probably around 30 to 40 devs outside of the project, I would say. And-- For us, as a starting project, we're very happy with that. And then as well, internally, we have about, I think, 70 right now, 60 of those engineers, so a lot of engineering. Yeah.

Nicholas: Big team. And a lot of projects you're working on. Yeah. I guess the last thing I wanted to ask is, for people who hear this and are like, it sounds great, and it sounds like more than just sort of remedying some gripes with the EVM, it sounds like there is actually a big vision here, which I think can be kind of the concern when you hear someone saying, oh, we're going to fix all the problems that we found in the EVM, that it might just be sort of a patch job. But swapping out for the UTXO model, predicates, there are a lot of new concepts here, Sway, et cetera, that are not just Band-Aids or actually remedies to the kind of Band-Aid solutions that you might see emerging in the EVM ecosystem where it's so difficult to make changes to the EVM. If people are interested and they want to play around with this, is there a wallet people can mess around with? Are there some apps people can try? And is there like a demo example, boilerplate kind of app, if someone wants to, I don't know, throw together a token or an NFT or something simple?

Nick Dodson: Yeah, 100%. So for wallets, they should definitely try Fuelette. They're the most advanced wallet we have. We have our own wallet, which is kind of turning more into a developer wallet, because we don't want to maintain our own wallet. For apps, there's definitely like Spark and a few other projects that-- like Thunder, the NFT marketplace, they should definitely try that as well. in terms of just a silly, stupid game to play that's kind of interesting. Just Sway Farm is pretty great. And then as far as just trying out things and building stuff, our quick start's pretty simple with just a counter contract. We want to change that into something more interesting, because counter contracts are kind of boring. We want to do something more. But in the docs, the docs.fuel.network, there's just a quick start there for that. We have a bunch of fully fledged standard library modules that are there to support devs that are really well-maintained. And then as well, we have a deep set of example apps that are built out for devs as well. And then we have a TypeScript kind of fuels. It's called Fuels. And that, you can just create a whole project really fast, like TypeScript project, fully fledged out React and everything else. So there's a bunch of stuff available, basically, to build everything out quickly. I think for us-- it's less about that. We can always make that better. And it's always a struggle to get the docs right and make that better. The main question you have to ask yourself is, why? Why are you here? Why would you build with us? And I think that for us, the why is much more important as to a project as to why they're here than it is the project itself. I think that for us, we really want to make sure that people understand we're doing this for a purpose which is maybe a little deeper than just-- just a flash in the pan execution project or something like that. Yeah.

Nicholas: people who are interested in doing scaled applications, reaching real end users-- Exactly. --and planning for the future, maybe want to flex some of these cool features that we've talked about. But really, with the goal of getting-- I don't know. We've had a lot of guests on the show recently talking about things like passkey, the passkey-based account abstraction wallets. But it sounds like that could be interesting. and user applications on top of Fuel that--. Sure. --skip some of these steps and deliver an interesting and compelling experience.

Nick Dodson: The passkeys thing, I'll send you it on the--.

Nicholas: Oh, yeah, great.

Nick Dodson: Yeah, yeah, we did that in Istanbul. Yeah.

Nicholas: OK, I'm going to take a look, and I'll put it in the show. And where do people in the Sway and Fuel communities hang out? Where's the spot?

Nick Dodson: So we're doing an event at Denver called Execution Day. So they should definitely come to that if they're going to Denver. As far as online, we just started a Farcaster channel, I think. So that would be a good place where it's probably better signal-to-noise ratio. The forum.fuelnetwork, best place to ask questions, because they're long-lived. People can search them later. So we like to answer all the really heavy technical questions at the forum. And then we have our Discord and Twitter and stuff. But to me, Discord is just like, I can't-- I don't know, I can't look at or focus on Discord. So I think the forum is probably the best place. And as well, just like trying to meet us at the various ETH events, et cetera, we're around. And happy to get on the phone and talk about everything and go through stuff. Yeah.

Nicholas: Also, are you going to be in Denver?

Nick Dodson: Yeah.

Nicholas: Yeah. All right.

Nick Dodson: I reluctantly tweeted, I haven't yet met someone who was excited about Denver. And I won't personally comment on my own thoughts about Denver. But I think, yeah, at least a lot of people will be there.

Nicholas: Yeah. I think that's where everyone goes. 100%.

Nick Dodson: Yeah.

Nicholas: If you want to check out that AuthN wallet, it's authn-sign.vercel.app. I'll put it in the show notes. Nick, thank you so much. This was a great conversation. It's great to get to learn more about Fuel Sway, Rollup OS, and everything you've been working on. It's pretty exciting.

Nick Dodson: Awesome. Awesome. All right. Thanks so much. Thanks so much, Nick.

Nicholas: Thank you. Hey, thanks for listening to this episode of Web 3 Galaxy Brain. To keep up with everything Web 3, follow me on Twitter, @Nicholas, with four leading ends. You can find links to the topics discussed on today's episode in the show notes. Podcast feed links are available at web3galaxybrain.com. Web 3 Galaxy Brain airs live most Friday afternoons at 5:00 PM Eastern time, 22:00 UTC, on Twitter Spaces. I look forward to seeing you there.