This article is Part III of a multi-part series by Fuel Labs covering topics related to scalability and execution on Ethereum. This series aims to provide comprehensive insights into the challenges associated with enhancing Ethereum's performance and capacity and the current solutions working to make it more efficient and scalable for widespread adoption.

Fuel started as an optimistic rollup on Ethereum with the release of Fuel V1 in late December 2020. Fuel V1 aimed to provide Ethereum with a trust-minimized side chain that inherited the security of Ethereum but had a radically redesigned execution model using the unspent transaction output (UTXO) model. Fuel V1 was the only rollup that achieved the inheritance of Ethereum security (now defined as “stage-2” status by L2Beat) in practice with no third-party multi-sig and full optimistic fraud proving.

Most current blockchain projects rely on general-purpose virtual machines like the EVM and WASM. While such architectures brought us far, a gap exists to address specific scaling needs beyond pre-2018 monolithic architectures. General-purpose virtual machines (VMs), while versatile, often lack the optimizations necessary for the unique demands of blockchain execution (see Part II).

The Fuel evolution since V1 is expansive and strategic. We have dedicated the last three and a half years to redefining and rebuilding our architecture from scratch. Our architecture deeply addresses common issues faced by modern blockchains, such as the need for a flexible programmatic machine, an asset-oriented transaction model, multi-threading, parallelism, state sustainability, and cross-chain interoperability.

Today, we’re excited to dive deeper into the heart of Fuel: the FuelVM.

A Purpose-Built VM for Rollups

The Fuel Virtual Machine (FuelVM) incorporates 17 years of blockchain design to bring the Ethereum community a reliable machine architecture built for longevity. The FuelVM provides an architecture  similar to low-level reduced instruction set machine architectures such as the RISC-V ISA, ARM ISA, and virtualized architectures like Web Assembly and ePBF. Our VM also incorporates insights from past blockchain machine architectures such as Bitcoin scripts, the Ethereum Virtual Machine, and the Move Virtual Machine.

The FuelVM is designed and tailored for the unique challenges of rollups, aiming to solve both state-sustainable and performant execution.

The FuelVM was built with the understanding that disk IO is the slowest part of computing and is typically used for active blockchain state during full node verification. The FuelVM enables developers to move away from stateful application designs often enabled by smart contracts by providing more feature-rich state-minimized facilities such as native assets, ephemeral scripting, and ephemeral spending conditions, which takes pressure off full node verification (as they do not need to be stored in state), by trading state lookups and storage (IO) for bandwidth, CPU and memory. By providing alternative methods for developers to build more state-minimized applications, we can achieve the aims of better full node sustainability, keeping the architecture accessible to all and decentralized, following in the footsteps of Ethereum’s core values.

Here’s a more comprehensive list of design considerations for the FuelVM:

Performance and Efficiency

• Runtime execution performance

• State sustainability

• Disk I/O overhead

• Bandwidth optimization

• Parallel processing capabilities

Security and Verification

• Virtualization and sandboxing

• Interactive verification game complexity

• Fraud provability

• Adversarial execution safety (DOS mitigation)

Cryptographic Operations

• Access to common blockchain cryptographic functions (hashing, signature verification)

• Ethereum compatibility (Keccak256 hashing, Secp256k1 signature verification)

• Bitcoin-style spending conditions (P2SH)

Smart Contract Functionality

• Ethereum-style smart contracts

• Native asset management

• Access to external call facilities

• Ephemeral coding capabilities (scripts and predicates)

Arithmetic and Data Handling

• Big number arithmetic

• Arithmetic runtime safety (safe math, overflow registers)

• Runtime memory read accessibility to transaction data

Gas and Resource Management

• Gas metering potential and overhead

• Power consumption considerations

Advanced Features

• ZK circuit complexity

• Instruction parsing complexity

The development of the FuelVM represents a significant evolution from the initial Fuel V1 launch in 2020. Fuel V1 was the first optimistic rollup on Ethereum and one of the only fraud-provable state machines. While transactions per second (TPS) is typically a poor metric to analyze an architecture, it's helpful to understand the potential of the FuelVM more broadly for projects seeking to incorporate our VM. As of May 2024, the FuelVM can achieve asset transfer benchmarks of 12k TPS per core on a higher-end CPU, and can likely achieve much higher results with more optimizations.

Let’s explore how the FuelVM and Fuel’s unique UTXO transaction model achieves enhanced performance and flexibility through critical innovations, such as parallelized transaction execution, state minimization, and user-friendly features.

Parallelized Transaction Execution through UTXOs

Fuel’s parallelized transaction execution model is a cornerstone of its efficiency and scalability. Parallelization dramatically improves throughput and reduces latency compared to traditional sequential processing methods. It allows tasks to be broken down into smaller sub-tasks that can be executed simultaneously on multiple processing units.

Parallelization is built upon a foundation of Access Lists and the UTXO (Unspent Transaction Output) model, which works in tandem to enable concurrent processing of non-conflicting transactions.

Access Lists categorize transactions into Read-Only, Write-Destroy, and Write-Create. Each transaction specifies all the resources it will interact with, including UTXOs and contract identifiers. By analyzing these lists before execution, the FuelVM can identify transactions that do not share overlapping resources and execute them in parallel, maximizing efficiency.

Source: Exploring the FuelVM

The UTXO model plays a crucial role in facilitating this parallel execution. Since UTXOs are unique and can only be spent once, Fuel can effectively parallelize transactions that do not interact with the same UTXOs. Our approach ensures each transaction operates on distinct, unspent outputs, minimizing conflicts and enabling simultaneous processing.

To illustrate this concept, consider two simple token transfer scenarios: Alice sending 1 ETH to Bob and Charlie sending 100 USDC to David. In both cases, the transactions involve distinct assets. The transactions are processed simultaneously without conflict through the following steps:

1. Alice initiates her transaction, including a Read-Only Access List for her ETH balance and a Write-Destroy Access List for the UTXO representing the 1 ETH.

2. Concurrently, Charlie creates his transaction with a Read-Only Access List for his USDC balance and a Write-Destroy Access List for the UTXO representing the 100 USDC.

3. Fuel’s execution engine verifies both transactions, confirming their validity and lack of overlap in their Write-Destroy Access Lists.

4. With no conflicts detected, the FuelVM processes both transactions in parallel, sending Alice's ETH to Bob and Charlie's USDC to David simultaneously.

5. Both transactions are quickly confirmed and completed.

This parallelization boosts transaction processing capabilities and addresses scalability challenges historically plaguing blockchain systems. By allowing non-conflicting transactions to be processed concurrently, Fuel provides a robust solution for managing high transaction volumes in rollup environments, ensuring effective scaling as demand for blockchain space grows.

Native Assets and Predicates

The FuelVM's asset-oriented design complements its parallelized execution. Built-in opcodes allow applications to create and manage multiple native assets directly within the virtual machine. This design choice significantly improves execution performance by enabling native asset manipulation at a lower level. The lower-level asset manipulation is made possible by using primitives like the UTXO system instead of the more complex state storage typically required in traditional smart contracts.

Manipulating native assets at the transaction level is inherently cheaper and more efficient because it bypasses the need for extensive state changes and third-party libraries. Ourur approach also offers a better user experience. Handling native assets, such as sending ETH, is more straightforward than the alternative of dealing with ERC-20 tokens, which often require setting approvals and additional steps. Our approach results in faster, more cost-effective transactions and a streamlined process for developers and users alike.

Another crucial aspect of the FuelVM's design is the implementation of predicates. Predicates are a pivotal innovation within the FuelVM, serving as lightweight, stateless contracts that significantly enhance transaction processing and execution performance.

Predicates enable the creation of conditional transactions, allowing devs to set complex conditions for executing transactions within the FuelVM.

Our design and functionality offer several key benefits, which are as follows:

• Lightweight and Stateless: Unlike traditional smart contracts that maintain extensive state information, predicates stateless by design. Their statelessness means they do not store data between executions, allowing a reduction in overhead and simplifying the execution process. The stateless nature of predicates ensures fast and efficient processing without complex state management.

• Native Account Abstraction: One of the most significant advantages of predicates is their role in facilitating native account abstraction. Predicates enable a flexible and efficient way to manage and interact with assets. For example, predicates can execute transactions involving multiple steps, such as executing complex trades or managing assets, without requiring intermediary contracts. This capability simplifies interactions and reduces the need for complex contract structures, making it easier for users to perform sophisticated operations with fewer steps.

• Streamlined Transaction Processing: Predicates streamline the transaction process by handling specific tasks directly and efficiently. Predicates can validate and execute transactions based on predefined rules or conditions, bypassing the need for redundant processing or additional validation steps. Streamlining in this manner contributes to faster transaction times and reduced computational costs.

• Enhanced Execution Performance: Predicates' combination of statelessness and handling tasks directly improves execution performance. Minimizing the data processed and stored reduces the system's burden and accelerates transaction execution. Such minimization proves particularly valuable in high-throughput environments, where performance and efficiency hold crucial importance.

Fuel’s Approach to State Growth

State growth in blockchain systems involves expanding the data that nodes must store and manage. As blockchain networks evolve, accumulating state data can cause challenges like increased storage, slower transaction processing, and higher operational costs.

State growth rates have varied since Ethereum's inception in 2015. Currently, the state grows at around 2.62 GiB per month, down from a peak of 5.99 GiB per month. This rate projects the total state size between 396 GiB and 606 GiB in five years. Recent declines in growth are mainly due to reduced NFT & ERC-20 activity. The current state growth rate is the lowest since 2022.

Source: Paradigm

Fuel addresses state growth challenges with innovative state minimization techniques that effectively manage and reduce the state data footprint. Let's discuss some of them.

Native State Rehydration

Fuel introduces the concept of native state rehydration, a method for efficiently managing state changes. Instead of continuously maintaining and updating a global state, a Fuel application would compartmentalize state changes into smaller, manageable segments that are stored as non fungible tokens (NFTs) within its native asset architecture. Our approach allows on-demand access to state data when required, reducing the overall storage burden and improving transaction processing efficiency. By only rehydrating the state data needed for a specific transaction, the FuelVM minimizes the data load on nodes and enhances the speed of state access.

State Minimization Techniques

Scripts: In the FuelVM, scripts are temporary logic embedded within transactions. These scripts execute specific functions or operations without permanently altering the global state. Since scripts are ephemeral and confined to the transaction context, they do not contribute to long-term state growth as they can be pruned after being executed.

Predicates: Predicates take inputs and return a boolean value to determine transaction success. Unlike traditional smart contracts, predicates do not read from or write to the global storage. The absence of storage operations in predicates ensures that they do not contribute to state growth. A predicate can validate transactions based on specific conditions without altering the global state, thus streamlining transaction processing.

UTXO Model: In the UTXO model, each transaction consumes previous UTXOs and produces new ones. A localized approach to state management means that state changes are confined to the specific UTXOs involved in a transaction rather than affecting the global state. Fuel full nodes will only need to store 32 byte hashes of each UTXO to ensure future state transitions are valid, which means that by moving more applications to native assets and predicates, we can reduce the bulk of blockchain state by a significant factor. As a result, the UTXO model reduces the complexity of state management, supporting scalability and efficiency.

Fuels state minimization approach offers several key advantages, including efficient state management by compartmentalizing state changes, which leads to faster transaction processing. State minimization also improves scalability, enabling Fuel to handle a larger volume of transactions without performance degradation. Additionally, by reducing reliance on a global state, Fuel enhances decentralization, allowing more nodes to participate in the network without being overwhelmed by extensive state data.

Source: Delphi Digital

Example Use Cases

The following examples showcase the power and versatility of the FuelVM and demonstrate the possibilities when deploying our tech stack. For a broader view of the evolving ecosystem, check out the Fuel ecosystem page.

Parallelized On-Chain Order Books

The Fuel paves the way for transformative applications, primarily with its use of the UTXO model to anchor order book exchanges, as demonstrated by projects like Spark. The UTXO model offers a more efficient trading experience, with reduced latency and simplified state management compared to traditional approaches. By addressing issues like slow transaction processing and state bloat, Spark makes decentralized exchanges more scalable and practical.

Stateless Multi-Sigs

Bako Safe provides a stateless multi-sig wallet built on the FuelVM's predicate construct. Bako Safe strengthens security and offers non-custodial asset management with features like collective vaults, enabling secure contract visualization and signing.

Cross-Chain and Multi-Asset Compatibility

The FuelVM excels in cross-chain interactions through its native account abstraction and support for diverse signature schemes. Fuelet, a wallet built specifically for the Fuel ecosystem, exemplifies this cross-chain potential by offering a unified interface for managing assets across multiple networks. Fuelet is designed to enhance interoperability and enables seamless integration with wallets from various blockchains. Users can connect and interact with the FuelVM using their preferred wallets, bridging different blockchain ecosystems without sacrificing security or functionality.

For example, in a recent development, Fuel added support for Solana wallets by enabling dApps built on Fuel to connect with any SVM wallet, in addition to its existing EVM wallet support. This SVM integration allows users to securely use Solana wallets like Phantom, Solflare, and Backpack to create Fuel accounts, sign transactions, and swap assets natively within these wallets. Several Fuel dApps also adopted this approach, including MIRA Protocol, which now supports both Ethereum and Solana wallets on its DEX. The MIRA protocol DEX is available on the Fuel Sepolia Testnet.

Parallelized NFT Marketplaces

The FuelVM's capabilities extend beyond trading and wallet integration to incorporate other crucial blockchain applications. Thunder is an NFT marketplace that enables bulk trades in a single transaction with minimal fees. Through parallelization, Thunder provides a more seamless trading experience with fast transaction times for seasoned NFT traders.

Decentralized Identity and Reputation Systems

Meanwhile, Kassiopeia demonstrates the FuelVM's potential in decentralized identity and reputation systems, utilizing the platform's unique features to create a robust and privacy-preserving identity layer for Web3 applications. Kassiopeia further illustrates how the FuelVM's capabilities can be applied to solve complex challenges across various domains of blockchain technology.

Conclusion

Fuel addresses key challenges in rollup technology through its UTXO model, stateless predicates, and state minimization techniques. These innovations aim to improve scalability and efficiency in decentralized applications.

This brings us to the end of our three-part Ethereum series, covering topics related to scalability and execution on Ethereum.

And stay tuned for our next series! In the meantime, check out our docs at docs.fuel.network to start building on Fuel.  Also, check out FuelVM-powered applications firsthand on our Testnet.

Further Reading