Introduction

Blockchains are comprised of the following core layers:

• Data availability layer (where relevant data is made available)
• Consensus layer (where the blockchain reaches consensus on the validity of transactions)
• Execution layer (where transactions are executed) and
• Settlement layer (where transactions are finalized).

A monolithic blockchain is a blockchain that contains all 4 key layers. The majority of blockchains are monolithic, such as Ethereum (excluding rollups), Solana, BNB Chain etc.

A modular blockchain refers to the specialization of the above core layers, whereby the various layers utilize each other and combine to form a complete system. The thesis for a modular blockchain is that the specialization of layers combines to form a far superior overall system than that of a typical monolithic system.

Source: Celestia

Modular blockchains aim to overcome the blockchain trilemma of security, decentralization and scalability. There has been no clear way thus far for how monolithic chains can address this issue, despite a proliferation of new L1s appearing over the past couple of years.

• Ethereum has sacrificed scalability at the base layer while focusing on decentralization and security.
• Solana has arguably sacrificed decentralization while focusing on scalability and security.

The apparent inability to surmount the blockchain trilemma has shifted attention towards a modular blockchain future.

In a modular system:

• Data availability layer
  • ensures that data is available, e.g. Celestia.
• Consensus layer
  • focuses on ordering transactions.
• Execution layer
  • focuses on processing transactions, e.g. Fuel.
• Settlement layer
  • focuses on ensuring the validity of transactions.

Ethereum, for example, is focusing on becoming a unified data availability, consensus, and settlement layer - while transaction execution is outsourced to execution layer specialists e.g. Arbitrum, Starkware, and Fuel.

• Of course, Ethereum also currently operate as a monolithic blockchain as well, with transaction execution occurring at the L1. The problems with this approach are clear, with slow transaction times and extremely expensive transaction fees.

The thesis behind modular blockchains is that the specialized separation of layers can enable greater security, scalability and decentralization than could otherwise be achieved.

• For example, Ethereum rollups such as Arbitrum and Starknet scale Ethereum by moving transaction execution off-chain (at L2) while leveraging data availability, consensus and settlement of Ethereum L1.

State Growth

State growth simply means the growth of the overall size of a blockchain. A blockchain is a distributed database, and as it grows its validating nodes need to become more powerful (to download the growing data). As a result, validator costs rise, resulting in the blockchain becoming more centralized. Pushing the state to L2 helps alleviate this problem at the L1 level.

However, one thing that also needs to be taken into consideration is state growth at L2. L2s themselves can be considered blockchains and are not immune to the state growth issues being faced at L1. This is an issue that has received little attention, but as L2s themselves achieve wider adoption they too will experience state growth which can slow down the blockchain and result in greater hardware requirements.

This is a problem that Fuel seeks to avoid.

Enter Fuel

An execution layer simply handles transaction execution while delegating the other components to another blockchain. An example of this is Arbitrum (an execution layer) and Ethereum.

Fuel is marketed as ‘Modularizing the execution layer’, which refers to Fuel operating as an execution layer that is capable of a number of different configurations, e.g. as an Optimistic Rollup on Ethereum, or leveraging Celestia for DA and Ethereum for consensus and settlement.

Fuel is focusing on long-term scalability by modularizing the execution layer with the goal of minimizing state. Fuel has created its own virtual machine to achieve this end, opting to start afresh and avoid the constraints of building solely within the EVM. Although it is opting out of the powerful network effects of the EVM with this design choice, it can potentially offer a better developer and user experience in the long run. By minimizing state, Fuel is seeking to create an execution layer that enables hardware requirements for validators that are affordable enough for sufficient decentralization.

Note that Fuel V1 was deployed to Ethereum mainnet in 2020. It is an Optimistic Rollup for payments (not a smart contract platform) with open block production, fraud proofs and immutable smart contracts.

However, all references to Fuel in this article are in relation to Fuel V2.

Proposed Instances Of Fuel

Source: Fuel

The above diagram shows the team’s expectations regarding Fuel’s versatility and is a good visualization of Fuel’s modularity. Note that it does not reflect the current state of Fuel (which is yet to be launched), and this report focuses on Fuel as an execution layer.

Interestingly, Fuel is not designed for a specific chain (like Arbitrum is for Ethereum) and is expected to be deployed on top of the likes of:

• Ethereum, Celestia, or any settlement layer,
• Ethereum and Celestia, and
• As a settlement layer between Celestia and chain X.

This is very dynamic approach that allows Fuel to be a plug-and-play tooling for other modular layers to select from based on their needs.

Upon its upcoming launch, some of the initial configurations of Fuel could be:

• As an Optimistic Rollup that uses Ethereum for data availability and settlement.
• Fuel as an execution layer, leveraging Celestia for data availability and Ethereum for settlement and consensus.

The diagram shows Fuel’s proposed versatility across the blockchain stack. It will be interesting to see which becomes the dominant use case for Fuel. As it is primarily built as an execution layer, one would expect this to be the main use case. It is likely that the first iteration of Fuel will be as an execution layer on top of Ethereum. When Celestia goes live, Fuel will almost certainly build atop it given the overlap between the founders and aligned visions of the two projects.

• Celestia and Fuel are key projects in the modular blockchain space. Fuel focuses on the execution layer, while Celestia focuses on the data availability layer. An scalable execution layer requires a scalable data availability layer and vice versa in order for both to reach their potential. The Co-Founder of both projects, John Adler, has stated that they have been designed with each other in mind. Check out Nansen’s report on Celestia here.

Although Fuel can wear many hats across the modular stack, it is seen first and foremost as an execution layer. Interestingly, it can operate as an Optimistic Rollup (using fraud proofs) or ZK-Rollup (using validity proofs). Initially, it will operate as an Optimistic Rollup; however, it can also use validity proofs as well (ZK-Rollup).

Architecture

UTXO Model

• Unspent Transaction Output (UTXO) is a type of blockchain accounting model.
• UTXO blockchains do not have wallets or accounts - coins and contracts exist as UTXOs.
• An example of this is the Bitcoin blockchain. The UTXO is the output of a transaction received by the user and essentially represents the balance of a coin held by a certain address. Transactions consume UTXOs and create new ones that reflect the new state.
  • More simply, on Bitcoin the UTXO represents the amount of BTC that a user has left after completing a transaction.
    • The unspent output is deposited back into the database as an input which can be used later for another transaction.
  • Read more here.

Bitcoin uses the UTXO model only for coins (BTC).

Fuel’s state is represented by both contract and coin UTXOs.

• Each contract UTXO carries the state and balance of a contract, uniquely identified by a contract ID.

It is worth comparing the UTXO model to the account-based accounting model that most other smart contract chains use, e.g. Ethereum. In this model, tokens are a balance in an account controlled by a private key or smart contract. The network is required to track all balances in all accounts and update the state through the sequential processing of transactions into blocks representing the new state. This design limits network throughput and does not efficiently leverage hardware (only a single thread of a CPU).

Fuel’s UTXO model does not necessarily require the sequential processing of transactions which enables parallel execution (multiple transactions occurring at the same time).

Source: Fuel

Concurrency Issue With UTXOs

However, the nature of UTXOs calls into question how it is feasible for complex smart contracts to be consumed and recreated with each transaction. One example of the difficulties experienced using the UTXO model for smart contracts is on Cardano.

• Cardano experienced issues with a UTXO model for an AMM. As each UTXO can only be used once, only one person could interact with the smart contract at once. DeFi applications often have multiple people interacting with the smart contract simultaneously. This means that with the UTXO model only one transaction would succeed (and consume the UTXO) meaning all else would fail. This is called the concurrency issue.

How does Fuel avoid this problem?

On Fuel, there are different parts of a transaction to be signed:

• Users do not directly sign the UTXO but rather sign the contract ID - indicating their intent to interact with the contract. As a result, the user will not directly change the state and thus cause the UTXO to be consumed.
• Rather, block producers will be tasked with how the various transactions in a block will affect the overall state and therefore the contract UTXO. The UTXO is spent and replaced with another representing the new state. At the time of writing, Fuel are yet to publish lower level details on how the block producers will work in the system.
• Consumed contract UTXOs create new UTXOs with the same core features but updated storage and balances.

Sway

The team behind Fuel created the Sway programming language with the goal of optimizing the developer experience and enabling superior applications. It is a domain-specific language inspired by Rust but designed for smart contracts. Sway is designed to minimize costs and maximize contract-level safety.

• Sway has a similar syntax to Rust.
• Seeks to incorporate blockchain-specific safety checks and zero-cost abstractions, allowing developers to write reliable and efficient smart contracts.
• The Fuel team lists some differences between Solidity and Sway here.
• The Fuel team is focusing on building out Forc
  • Fuel’s build system that provides tooling and commands for Fuel developers.

The team has built a relatively extensive standard library considering how young the language is. This gives Sway a variety of features and enables the compiler to move quickly.

Fuel Co-Founder John Adler has used the analogy of an ‘iOS-like experience’ for building out an extensive toolkit for developers where there is one unified and integrated toolchain that is not fragmented. The rationale for this is sound and if Fuel can continue building out a unified toolkit for developers, an easier onboarding experience could help catalyse the ecosystem.

The Fuel team has strongly emphasised the benefits of Sway. Note that the language is in its infancy and wider feedback from unaffiliated developers is lacking.

Learn more about Sway here.

Scripts and Predicates

Scripts and predicates are key tools leveraged by Fuel to improve the user experience.

Scripts: Programs that enable a single transaction to call multiple contracts without the need for routing. A key example of this is removing the need to approve a contract before transferring funds; using scripts, this can be done in a single transaction. A key feature of scripts is that they are removed from the blockchain once executed and therefore do not contribute to state bloat.

Predicates: A contract script that does not access state and is used to enable stateless account abstraction.

• Account abstraction refers to the aim of reducing the two account types on a blockchain (wallet addresses and contracts) to one - reducing complexity for users.
• Account abstraction on Fuel can enable:
  • Account access control with Solana, Cosmos or Ethereum
  • Multi-sig accounts
  • Atomic UTXO-based order book exchanges
  • An account in which there is a hot signer for small amounts e.g. below $500 and a cold signer for larger amounts e.g. $500+.

Predicates can be used to execute transactions when certain conditions are met e.g. as a buy order. This is an interesting use case, as predicates do not contribute to state bloat and can be pruned when they are used.

Fuel leverages Scripts and Predicates to enhance performance. Scripts are essentially bytecode that is used to execute a transaction. Importantly, Scripts are able to perform multiple actions at the same time, which differs from Ethereum. For example, the FuelVM can have an approval and a transfer in a single transaction, whereas on the EVM this would be two separate transactions.

The purpose of incorporating scripts and predicates is to enable the execution of multiple calls in a single transaction and because they are better at maintaining state compared to contracts.

Scripts and predicates are intended to complement smart contracts. True to Fuel’s purpose of avoiding state bloat, they restrict state growth as they do not hold storage (unlike contracts). Ultimately, the rationale for leveraging scripts and predicates is to enable semi-stateless execution on Fuel.

Key points to note:

• State and execution are not mutually exclusive.
• Depending on the pricing of state and execution and an application’s functionality, the application can choose to rely on one rather than both.
• Various dApps could technically have their contracts replaced with scripts if computation is cheap compared to state. This is possible on an execution layer with high computational bandwidth.

Parallelization

Fuel enables parallel execution of transactions e.g. multiple transactions executing at the same time.

This differs from the EVM where transactions are processed sequentially. This is made possible by using strict access lists. With access lists, each transaction needs to specify which contracts it may interact with. If a transaction interacts with a contract that was not specified, then it will revert. Parallel execution is possible for transactions that do not interact with the same contracts (as outlined on the strict access lists). This should enable Fuel to leverage multiple threads and cores of a CPU to validate transactions at the same time. This is noteworthy, as single thread performance improvement over time has been relatively low, whereas the number of threads has increased. Therefore, it appears that leveraging multiple threads rather than relying on single thread improvement is a better strategy.

Fuel has not published estimates as to its potential scalability, in contrast to other projects that often disclose unrealistic estimations of transactions per second. However, the team expects at least 1,000 TPS on the canonical Fuel instance. Note that different instances of Fuel will have separate sets of nodes, enabling scalable throughput. It will be worth watching out for more details on Fuel’s potential scalability as more information becomes available.

How Fuel Seeks To Beat The EVM

FuelVM has built in various features that are currently Ethereum Improvement Proposals (EIPs). The Fuel team has built its infrastructure in such a way that seeks to learn from the ‘mistakes’ of previous blockchains so to avoid having to implement complex upgrades down the line due to the difficulties with backwards compatibility.

Designed for Fraud Proofs

The EVM was not designed with fraud proofs in mind and as a result, the construction of fraud proofs (required for Optimistic Rollups) is actually rather complex. In fact, it generally requires a secondary layer such as MIPS to be interpreted into a fraud provable system. Vitalik Buterin recently stated on the Bankless podcast that Optimistic Rollup’s failure to make substantial progress on fraud proofs has come as a surprise. Fuel, however, has been designed with fraud proofs in mind.

Fuel’s use of UTXO makes general fraud proof construction easier than account-based models like Ethereum which have unbound fraud proof costs. In addition, Fuel’s ability to execute transactions in parallel means that the parallelization of fraud proofs is possible.

Interoperability

Fuel Co-Founder Nick Dodson claims that shared data availability and trust-minimized light clients facilitate trust-minimized bridges for Fuel to other modular execution layers e.g. Arbitrum. This is not possible between arbitrarily different L1s.

Fuel is not live yet, and although the rationale behind the design decisions appears sound, it is uncertain whether or not it will transpire in practice.

Multiple Native Assets

Ethereum’s only native asset is ETH. However, Fuel can have multiple. Native assets have first-class citizen properties such as transfers with a contract call rather than going through a separate token contract. This eliminates various vulnerabilities associated with contract-based tokens, and provides a more uniform developer experience. This means that tokens launched on Fuel will can have these properties (unlike on Ethereum, for example, where ERC-20s lack these first-class citizen properties).

64-bit words are used instead of 256-bit as in EVM

Fuel made this design decision with the reasoning that it is overall more efficient as most architectures nowadays are 64-bit, and 256-bit can result in the overflow problem, elaborated more on here. The Fuel team claim that 256-bit word size is unnecessary as libraries on the FuelVM can be made at the application level to handle larger numbers.

Register-based VM

Fuel is building with a register-based VM with the aim to gain greater efficiency and make the blockchain faster and cheaper. This can be achieved as register-based VMs generally need less instructions than stack-based VMs.

Examples: Solana uses a register-based VM. Ethereum uses a stack-based VM.

FuelVM Enables Multiple Actions In A Single Transaction

The FuelVM uses scripts that allow multiple actions to occur without needing to deploy a new contract for each. For example, this means there is no ‘approve and TransferFrom functions’ as experienced on EVM chains. Instead, this can occur in a single transaction and could help reduce the situation whereby signing approvals gives hackers access to funds in your wallet.

Globally Shared Memory vs Context-Local Memory

All contract calls on Fuel share memory that is readable throughout the system. On Ethereum, each contract has its own memory, call data and return data. Having globally shared memory enables data transfers across contracts without expensive storage.

Fuel Network Security

On Fuel, light clients will verify blocks through fraud proofs. This should enable Fuel to have low resource requirements for validators and maintain satisfactory security so long as there is one honest and properly functioning full node producing the fraud proofs. Fuel is seeking to minimize the requirements to run full nodes in order to satisfactorily decentralize consensus. However, there is not publicly available information on this yet.

SwaySwap

SwaySwap is an application live on Fuel’s testnet with ultra-fast transaction confirmations. It is pointed to by the Fuel team as a demonstration of Fuel’s performance capabilities. While it has a very impressive performance, it should be noted that it is just one single application on testnet and cannot definitively represent how Fuel will perform when deployed, especially if certain instance(s) gain large numbers of users across multiple dApps.

Team

Fuel’s team has some overlap with that of Celestia. For example, John Adler is co-founder of both Celestia and Fuel Labs. Adler helped pioneer Optimistic Rollups while a blockchain researcher at Consensys. Check out Nansen’s deep dive into Celestia here. Fuel’s other founder Dodson was an early Solidity developer on Ethereum.

Interestingly, Fuel has existed since 2019 - and had only raised $1.5m. However, on September 7th 2022 Fuel announced a $80m round which was led by Blockchain Capital and Stratos, with participation from Alameda.

Learn more about Fuel

• A builder’s guide to Fuel
• Fuel documentation

Grant Programmes

Fuel is running grant programmes to incentivize developers to build on the protocol. Grants range from $10,000 - $150,000. It is likely that these will be scaled up following Fuel’s $80m raise in September.

Check out more details on the grants program here.

Token

Fuel is yet to launch and there are no official announcements for a token. However, it is likely that the project will launch a token at some point. Check out this article here in which John Adler explores different L2 token models.

He argues against using typical token models:

• Generic PoS token

  • He argues that this is not necessary for a rollup as they already derive security from Ethereum and it adds the additional risk of a majority of validators being able to censor certain transactions at the L2 level.

• Fee token

  • This is argued to be ‘worse than useless’ as it adds an additional element of friction. While a fee token makes sense from a value accrual perspective, in reality it is likely to hamper the user experience. Ultimately, the best user experience is likely to win out in an increasingly competitive space, and an additional friction point from a fee token would likely jeopardize this.

• Governance token

  • Adler argues that this is not a good option as it can lead to governance capture of the rollup. This is an additional risk users should be well aware of when using rollups. The risk is lessened when there is wide token distribution. Note that this is rare in crypto, especially among younger projects.

Adler’s rejection of the above token models is interesting as they encompass what the vast majority of tokens are today. Tokenomics is a contentious issue, and there is merit to the argument that the majority of tokens lack intrinsic value and even legality.

An Alternative For Rollups?

Rollups themselves experience block space scarcity, and could potentially tokenize this scarcity by enabling block producers to collect fees. Of course, as demand for transactions increases so too do fees for block producers, and vice versa. To reduce friction, users would not necessarily need to pay these fees in a specific token (but rather whichever token they are transacting with).

The purpose of this model is to decentralize block production. This is something that current rollups need to implement sooner rather than later to avoid censorship resistance that comes from the centralization of block production.

• This would require node operators to bond the Fuel native token in order to produce blocks and collect fees.
• This model means that the token is only for block leader selection - which means that the rollup isn’t susceptible to governance attacks. Block leaders means that all nodes do not need to come to a majority to pass a block - making the blockchain faster.

It will be interesting to see if this token model emerges, and what modifications Fuel will incorporate (if any). Execution layer token design will be extremely important, and it is likely that the rollups that provide the best user experience will win out. Satisfactory value accrual to the token is also very important, and the fee mechanism should provide this.

Risks and Considerations

Developer Adoption

• While Fuel may be developing a technically superior virtual machine than that of the EVM and other competing virtual machines, the blockchain space has become highly crowded, with a number of blockchains with enormous business development funds to capture the attention of developers and a waning number of users. Fuel’s recent $80m raise will be important for Fuel to attract talent to building on it. Check out Nansen’s article from January 2022 showing the enormous incentive programs of competing blockchains.
• On this note, 9 of the top 10 blockchains by TVL use the EVM. This is a clear example of its dominance. However, it is not an indicator of future success, and building a custom VM that overcomes its shortcomings is arguably a strong strategy, as the EVM compatible/equivalent space has become saturated. Building a VM with the potential to enable superior user and developer experience is likely a better bet to rise above the crowd. As mentioned above, the Fuel team is focused on building out an ‘iOS-like’ developer experience.
• Execution Risk: Fuel is an exciting project and the rationale behind its design decisions is sound. However, its professed key use cases are yet to be tested properly, and only time will tell if it can deliver on its promises.

Smart Contract Risk

• Fuel is pioneering a new virtual machine and modular execution layer design. This level of innovation comes with the risk that it may not be executed as intended. Should this transpire, early developers may struggle building fully secure applications from the get go.

Key Terms