AMA Fuel Labs

Fuel Labs claims to be the world’s fastest modular execution layer with high security, flexible throughput, scalability solutions, and a focus on a superior developer experience. John Adler, who designed optimistic rollups, and the Fuel team developed a high-performance alternative to the EVM (Ethereum virtual machine) called FuelVM, which can be deployed as a Layer 2 rollup or L1 on any blockchain. The FuelVM is designed to scale by parallelized execution based on a strict access list and UTXOs. They are creating the FuelVM to address the current issues of state bloat, dynamic multi-resource pricing, native asset systemization, and centralization of the sequencer role. They are also building Sway, a high-level language inspired by Rust, to empower developers to write reliable and efficient smart contracts.

John Adler, Co-Founder of Fuel and Celestia Labs, joined us for an AMA on October 7th.

vVv: Before we jump into Fuel, please give us a quick overview of your background and journey in the blockchain space.

John: I was doing my graduate studies at the University of Toronto, and my advisor was involved in the early days of Ethereum so he would introduce students to the concept of blockchain and Ethereum. One day I was walking with my research group, and they began speaking about how Ethereum had tripled in price from 30 cents to $1. I had no idea what this was back then, so I started looking into it. The thing that really interested me about Ethereum was the heavy relationship with compilers and virtual machines. Coincidentally, this was a side passion of mine and one that I still needed to research formally while at the university.

A few years later, I decided to leave my graduate studies and join Consensus to do research on Layer 2 scalability. There I met Mustafa, one of my Co-founders at Celestial Labs, and read his papers on fraud proofs and laser ledgers which inspired me to propose the first public design of optimistic rollups. From there, we wanted to see how far we could scale Ethereum, which led to the inception of Fuel Labs.

vVv: Most people see Layer 2 rollups only as a solution to scale, optimize throughput, and to lower fees. However, Fuel Labs goes far beyond this idea by expanding the base functionality of Ethereum. Could you introduce Fuel as a modular execution layer and explain how it’s different compared to other Layer 2 rollups?

John: We refer to Fuel as the fastest modular execution layer. The Fuel protocol and the FuelVM are designed with two things that synergize to increase throughput. One of them is that the protocol itself allows for parallel transaction execution, and this means many transactions can be executed at the same time instead of sequential execution. This gave us a significant increase in throughput, which significantly increases the speed at which transactions can be executed, making the FuelVM much faster than the EVM. Learning from EVM shortcomings, the FuelVM is also designed to be less wasteful.

A modular execution goes a step further than a rollup and doesn’t have trust minimized to a bridge with an Ethereum contract. We use a Merkle tree so that you can show clients their transactions in a particular block without having to reveal all transactions in that block. There is also flexibility and other small aspects that come into play which we’ll dive into later.

vVv: Could you give us more insights on how Fuel can parallelize executions? Because it’s not natively possible on Ethereum.

John: There are two nuanced points here. One is how it is accomplished, and the other is how it is accomplished in a way that the EVM can only replicate with significant changes. Starting with the first one on how it is accomplished, every transaction in Fuel must specify a strict access list. In other words, it is mandatory for contracts that the transaction may touch, not will touch. This access list must be a superset of the contracts that the transaction will touch. If it’s a subset, then the transaction will revert if you attempt to access the contract outside of this access list. This has been proposed in Ethereum before. You can modify the transaction format on Ethereum to support this, but it would require significant non-backward compatible changes and a lot of infrastructural changes, for example, wallets and so on. However, it could be done, and there are proposals positing parallel transaction execution without such overhauls. The issue with such proposals is that they rely on optimistic concurrency. That basically means that if you execute a transaction and it turns out that the transaction tried to access something outside of its access list, it will get rolled back and then will be reattempted when the contention has been resolved. This is an issue for two reasons; the first is that rolling back and executing is a waste of resources. If these are not accounted for in the gas model, it could result in a denial of service factor. Someone may present a benchmark of some proof-of-concept implementation or even a production implementation of an optimistic concurrent parallel EVM, and using historical transactions; it’s ten times faster than a single-threaded EVM. However, that is irrelevant because historical transactions are not adversarial to this exploit vector. If a protocol was created in the past, and this exploit vector did not exist, it would not be exploited. It’s a critical nuance for anyone designing blockchain protocols that are looking at the past is irrelevant, as the past was not trying to exploit your protocol. If you’re creating a whole new protocol, you must look at the worst-case scenario and make simulations of those transactions. That’s what you have to run your challenge against, not history. This denial of service factor is basically unavoidable for optimistic concurrency systems. To have parallel transaction execution, you need it to be enshrined in a format that will work even in the worst case. The only possibility is to create strict access lists or access lists at the transaction level. And in the case of Fuel contracts, they will tell you which state elements that transaction will touch.

vVv: Is the protocol optimistic, or is it a ZK? Fuel Labs claims it’s agnostic to either of those. Can you talk a little bit about that?

John: The Fuel protocol does not inherently require one or the other. We aren’t personally maximalists of either technology. For us, it doesn’t matter what technology will be the winner in the long term. We will use the most practical technology that offers our users the best security. Currently, that is fraud proofs; maybe in a few years, it will be ZK proofs or perhaps something else entirely that does not exist yet. Our protocol has no bias or requirement on any of these proof systems.

vVv: A related question came up when looking at the Fuel configurations. It can be a Layer 2 rollup, a Layer 1, and a side chain. How does this all work related to integration with other Layer 1 blockchains?

John: The software implementation and the protocol are designed with an agnosticism to various components. It was built both as a modular protocol and as a modular software stack. For example, this agnosticism allows us to prevent requirements like a specific base layer, Ethereum, an EVM chain, or anything like that. 

We’ve researched other protocols which claim modularity, but their implementation proves otherwise. They often harbor very strict dependencies in the protocol itself. They receive events from Ethereum, which are RLP (recursive-length prefix) encoded, and retain the backward compatibility baggage of the EVM. Those are enshrined into the actual consensus rules of their execution system. We don’t have any hard dependence on the protocol or software stack. The base layer is just a plugin, which you can swap out to a different adapter that will read messages from, for example, Solana, or another EVM chain if you want to change your RPC (remote procedure call) endpoint, or Celestia if you don’t even want to have a smart contract. All these things are relatively easy to swap in our software implementation.

vVv: Does Fuel include all the components to run a complete Layer 1 solution?

John: Not at this time; the implementation is still in the development stage. The protocol in theory, is designed to be modular, but the implementation isn’t finished for all these, as this takes a while and requires a lot of engineering. We do have the best engineering team in the space if I do say so myself, but it’s a load of work. The implementation of things that aren’t modular executions that are connected to Ethereum is still a work in progress. Right now we’re deep into working on the first iteration, which is something connected to Ethereum.

vVv: What would be the benefit of running Fuel as a Layer 1?

John: If people create a second implementation based on our specifications, it takes a specs-first approach to development. Where there’s actually a written specification that is fairly easy to understand. It’s not like the Ethereum yellow paper with lots of math, but more like a software engineer’s specification, which everyone can read and use to reimplement a client of the protocol in any language they want. It’s not obligated to use our implementation; they can rewrite their own. If they take on the implementation of the protocol and run it as a Layer 1, you might lose the connection to the Ethereum community. Still, you gain the ability to be self-sovereign. This means you can fix bugs, exploits, and other things in ways you can’t do for a smart contract. There are pros and cons.

vVv: Coming back to your virtual machine, you not only developed this FuelVM, you also created your own development language called Sway. We’ve seen you make a statement that your programming language will be the dominant one for smart contract developments in the coming years. Can you elaborate why Sway will be the number one development ecosystem for smart contracts in the future?

John: I will start by giving the listeners unfamiliar with Sway, a short background. It’s a high-level language similar to Solidity based on Rust, and can be compiled to various blockchain VM bytecode formats. It’s like a simplified subset of Rust and has various blockchain-specific extensions. It’s important to note that Sway is not our language and is not a language for the FuelVM but rather a high-level language that empowers you to have reliable and efficient smart contracts. It currently compiles down to the Fuel virtual machine, but we are actively working for the user to be able to write smart contracts for Ethereum in Sway.

Blockchain VMs differ from traditional architectures because they have a notion of cross-contract calls. These things live in the state, and you can call them from one to the other. They also have the idea of contract storage, where each contract has access to some hashmap where you can store things. Some blockchains, such as Fuel, also have additional properties, such as assets. Ethereum, for example has Ether as an asset. Assets can move around with cross-contract calls, and contracts can store assets. Fuel has multiple native assets, not something like five, but more like 2256. Every contract can mint its own fungible token as a native asset. So in the DAI contract and the DAI assets, once those are native assets, they can be sent with a contract call. 

This means you can say goodbye to approve and transfer exploits and a rush to revoke your approvals before your tokens are stolen.

This allows us to have certain things you don’t get on Solidity. One of them is explicit error handling. That’s something that Solidity doesn’t have, as it doesn’t have generics and sum types. Generics means that there is logic you only need to write once which you can apply over different types during compile time. Sum types are unions that allow you to represent different types in a single overlapping memory space. This prevents you from wasting a bunch of access memory or space. On Sway and Rust, there is a thing called a result. A result allows you to wrap the result of some fairly valubale operation. An example of a valuable operation would be recovering a public key from a signature and a message hash. In Solidity, this is easy to recover; if the signature is invalid, it will set the address to zero. The problem arises if you forget to check your code. Anyone worldwide can send an invalid signature and pretend to be address zero. If you now use address zero as a burn address because you don’t have a burn functionality, then anyone can just take all the money or tokens. Solidity doesn’t enforce anything, and you have to perform checks at runtime that are potentially reasonably expensive. A result now wraps the result of an operation. Ultimately, trying to get a result during an operational error leads to the whole system reverting. Reversion is hugely favorable because it means that people can’t steal your money if the transaction reverts. This is obligatory because it’s enforced at compile time within the type system. You must unwrap because you can’t use a result directly because the result wraps an actual value. And this is just one of the many ways Sway empowers you to write reliable smart contracts. Solidity is just a fundamental language design and does not allow or empower you to write safe smart contracts. You need to manually check and remember all these rules and have auditors. There are no tools within the compiler to tell you anything. Also, Sway contracts will be fundamentally easier to write. 

The other question is why Sway, and not Rust, or something else? Why a whole new language?  Building your own compiler allows you to add checks at compile time in the compiler itself, leveraging the entire compiler flow and all the analysis. 

What’s still possible and a big problem in Solidity contracts is exploitation due to reentrancy. If you use a Rust SDK, it does not want a compiler. And if you write idiomatically in the SDK, you can perhaps avoid blockchain-specific vulnerabilities such as reentrancy. An example of idiomatic writing is checks-effects-interaction, where you are not vulnerable to reentrancy. But by doing this, you have to manually write and check if you’ve written in an idiomatic way because the compiler doesn’t tell you that. It doesn’t tell you which pieces of code are vulnerable to reentrancy. We currently have an experimental branch in the Sway compiler that will tell you if your contract is vulnerable. We expect zero vulnerability possibilities if the warnings of our compiler are turned on.

Another reason we think Sway will become the dominant language is that despite being fairly new, it’s one of the most mature languages in terms of features. We have possibilities like exhaustive pattern matching, type inference, generics, sum types, and an extensive standard library written in Sway. The language is already at a state where it’s more mature than any other language in the blockchain space today, and this gap is only going to grow in the future. We are moving faster than any other project or language in the space.

vVv: How difficult is it for Rust developers to transition to Sway?

John: Sway is a simplified subset of Rust that doesn’t have a barrow checker. If you’ve written Rust it will take no time for you to adapt to Sway because the fundamentals are the same as the EVM. For an intermediate Solidity developer, it should be no more than 1-2 hours to become proficient in Sway and to start writing contracts.

vVv: Please tell us a bit about the current grants program. Do you have a specific focus for the type of projects you want to sponsor?

John: We’re giving out grants to bootstrap other ecosystem projects. There’s not a restriction on grant sponsorship. We are interested in a variety of avenues, such as projects that build fundamental infrastructure at the protocol level, smart contracts, or libraries. However, longer-term self-sufficient projects are the most preferred as they have the greatest growth potential and ability to become profitable. They will also be the ones to foster a lot of user growth in the ecosystem. If you want to build something on Fuel, whatever it may be, please reach out to us either for the grants program or to build something in general.

vVv: Will Fuel work with standard wallets, for example, Metamask, or would users need a Fuel-specific in-house developed Wallet?

John: We are currently developing our own in-house wallet. There will be an extension similar to Metamask, but we’re adding things like transaction simulation, easier view-only mode, easier Impersonator mode, and a few other things. Of course, it will be free and open source, unlike Metamask. Also, it will not be compatible with Metamask because you can only have one Web3 provider. We’ll be integrating functionality directly into our wallet, so you don’t have to worry about switching between browsers or having to uninstall-reinstall Metamask. This is where Fuel, as a protocol, has certain flexibilities that we alluded to earlier. It’s not just about speed and security; it’s also about flexibility. We can execute transaction permissions on the application layer versus the protocol layer, which makes it possible for other wallets like BTC and ETH to function on top of Fuel.

vVv: Talking about flexibility, we’ve learned a lot about the architecture of Fuel, and we would like to understand the puzzle pieces on a broader scale. How do you see the modular blockchain narrative, and how does Fuel fit in this narrative? Can you explain your vision of this future modular blockchain world?

John: The current state of affairs is that a variety of execution systems are leveraging Ethereum L1 call data for data availability which is pretty expensive even with the current bear market prices and gas usage of Ethereum. As soon as we see a new bull market, prices will increase, and when you mint an NFT, you can say goodbye to cheap rollup fees. That’s not a long-term solution. Unfortunately, many projects that are currently leveraging Ethereum for data availability have various gas schedules and other assumptions based on the current state of things built into their system. This current state of things is where call data on Ethereum is 100% rounded to the nearest integer of a transaction price. When you have scalable modular data layers such as Celestia or Ethereum sharding, then the price of data in the data layer could be much cheaper, at least temporarily. While we can’t guarantee the price, we can at least say a lot will increase the capacity and throughput of data availability. All the protocols that have made assumptions about the current state of affairs deeply ingrained are not priced correctly and may have accrued baggage over time because of short-term pricing.

A critical example of this is when call data is costly, there is no avoiding that as a cost with a layer 2 application. You will use the state of the rollup because the state is very cheap, and call data is expensive. This is the opposite of what contracts on Ethereum have been doing for the past years, where they are trying to move away from state because state is expensive, and call data is cheap.

Right now teams have to rewrite their entire contracts to use more state instead of call data. It’s impossible to port your contracts directly over to protocols like Arbitrum and Optimism unless you want to be gas inefficient. To account for this difference, one has to rewrite their contract from scratch completely. What happens now is that these protocols will end up with a huge amount of state bloat in a very short amount of time, because they have priced things to encourage state bloat instead of discouraging it. This is something we are very cognizant about. The Fuel protocol is built forward-looking and not backward or current looking. It’s built for a modular future where there is a huge capacity for data availability, which we believe is a very near future. I gave various talks about this at Layer 2 Amsterdam and at EthCC (Ethereum Community Conference) on the nuances around resource pricing for state growth. If anyone is more interested in the topic, please check it out. The TL;DR is that you can influence how people make use of resources on your blockchain through the gas schedule and pricing with various instructions and other resources. We are very cognizant of using too much data, and we encourage it by using things that are stateless, such as call data.

vVv: Do you think the EVM will offer native parallel execution in the future?

John: This would be strict access lists and not an optimistic concurrency. I’m unsure if it will happen as there are a few issues related to the Layer 2 roadmap. There is a lot of drive right now to move EVMs into Layer 2s or into side chains, and have some equivalence between the Layer 1 and Layer 2 EVMs so you can use them interchangeably and reuse the tools, wallets, contracts, and other things. This will discourage the innovation of the execution layer at Layer 1. There is no need to innovate the Layer 1 EVM if the Layer 2 EVMs can support higher throughput. Now you have parallel execution across Layer 2s, not within. That is a weird feedback cycle because discouraging innovation at Layer 1 means that if Layer 2 wants to stay equivalent to Layer 1, they can’t innovate. If they do start innovating, you will have fragmentation. There will be EVM Optimism EVM Arbitrum, all different versions of the EVM. That will be chaos and bad for everyone, users and developers alike. But if you innovate rapidly at Layer 1, how do you innovate specifically right? Will you cater to what Arbitrum wants or to what Optimism wants? They might differ in primitives, users, and cryptography, and it will become a political and complex situation. Getting back to the question of whether or not the EVM will support strict access lists would raise the question of whether you require a new transaction format or if you could repurpose optional access lists. At the very least, it would require a breaking change to the EVM or to the transaction format. This would mean you need things that buy-in from the Layer 2s. You would need innovation and each implementation to support this, which is difficult when the current leading implementation is gas, and gas has a lot of backward compatibility baggage. I will not claim it will never have strict access lists, but these breaking improvements of the EVM happen very slowly, and it’s not something I would expect anytime soon, if ever.

Listen to the Spotify recording below for the full Fuel Labs AMA.