Introduction

We can think of Ethereum as the foundational hardware that powers the world of rollups, much like a physical computer. Built on top of this hardware are Rollup Operating Systems, which serve a similar role to operating systems like Windows or macOS on a computer. Their primary function? Tackling scalability issues to make the system more efficient and capable of handling a higher volume of transactions. Within these Rollup Operating Systems, we can identify three key components that parallel some aspects found in traditional computing:

1. Virtual Machine: Think of this as the computer’s processing power. Its job is to execute commands and run applications, making it crucial for the system.
2. Programming Language: Computer software is created using languages like Python, C, or Java. Blockchain developers use languages like Solidity or Vyper to write smart contracts.
3. Toolchain: Software developers use various tools to compile, debug, and distribute their applications. The toolchain serves a similar purpose for blockchain developers, allowing them to manage the lifecycle of their blockchain applications and making deployment faster and easier.

These three elements within the rollup operating system must function well together for the Ethereum network to scale effectively via the rollup-centric roadmap.

Problems of the Rollup Stack

Common issues that arise with the movement from Monolithic to Modular blockchains include increased complexity, fragmentation, decreased dApp composability, and lower developer familiarity. These common drawbacks have been discussed a lot, but a variety of issues remain that haven’t been addressed thoroughly.

General Purpose Architectures

Over the last few years, developers have experimented with many applications on smart contract platforms with varying degrees of success. The applications that have found sustained interest largely revolve around issuing, transferring, and trading tokens.

General-purpose computer architectures like RISC-V, WASM, MIPS, x86, etc., have been designed for CPUs and are being utilized for designing blockchain virtual machines. These architectures are great for building traditional applications like email, game consoles, browsers, and a wide range of web2 systems.

However, the job of a blockchain is fundamentally different from that of a generalized computer. A blockchain needs to cater to state management, asset exchange, settlement, cryptographic proofing, and other specialized operations. A large majority of traffic on blockchains is around the creation, transfers, and utilization of assets, and as such, the architecture for the third generation of blockchains should be built around making these actions more secure and optimized.

Force Fitting L1 Architectures for Rollups

While Ethereum rollups have made significant strides in performance and features, there is still a large capability gap between monolithic L1s and Ethereum rollups in terms of both performance and feature set.

L2 teams are trying to achieve high performance with parallelized virtual machines. However, most of these architectures being implemented were intended for monolithic L1s and failed to address the evolving demands of Ethereum’s modular, rollup-centric reality.

Force-fitting L1 architectures into a rollup setup forces developers to navigate compromises in design — limiting performance, adoption and ultimately hindering Ethereum’s vision for a globally decentralized network. Furthermore, we need to understand that attaching high throughput to the EVM will not be enough to compete with alt-L1s and their better user experience.

State Growth

State growth is the continuous accumulation of crucial data like account balances, smart contract code that is necessary for state transitioning a blockchain, and it presents a significant challenge for many blockchains today. Each new block adds more data to state on every validating full node, leading to an indefinite expansion of data as blockchain use and adoption increase. While numerous solutions address execution layers and data availability, the fundamental issue of state growth remains largely unaddressed. Without a strategy to manage state growth, all blockchains and rollups will eventually face limitations due to state bloat.

The Geth team has highlighted that the current client bottleneck is state read and write access. Initially, it was assumed that the entire state Merkle tree would fit within a standard device’s RAM. However, this assumption has proved unrealistic, with the state now exceeding 900 GB and projected to grow by 50–100 GB annually. As a result, most nodes now rely on SSDs for state storage. However, SSD storage availability in devices has comparatively struggled to keep pace with state size growth — a cost that will further impact the network’s decentralization.

 

Please stop saying this. Ethereum isn’t slow because of Geth. You could 10x the gas limit and Geth would be perfectly happy.

Ethereum is slow because the state grows like crazy. Whether Geth or any other client, it’s the same shit. You need to store that state somewhere. https://t.co/YS5gyRI1oJ

— Péter Szilágyi (karalabe.eth) (@peter_szilagyi) September 26, 2023

The constant expansion of the on-chain state is the most substantial scalability challenge for blockchains, and it’s a problem that will only get amplified as activity ramps up. Frequent, intensive interactions with the stored state are necessary to validate new transactions. If verification and state change implementation become too slow, transaction processing speed will become irrelevant as the limiting factor. State bloat in blockchains is a path to reduced node decentralization, as running validator nodes becomes increasingly difficult for smaller operators.
Fuel is a rollup operating system thoughtfully crafted after examining these and other limitations of current rollup systems. Pioneered by the team that launched the first Optimistic rollup, Fuel is not another rollup stack but a rollup operating system built for Ethereum.

The Fuel team has undertaken a large challenge to tackle: interoperability, state growth, inefficient blockchain virtual machine architecture, sub-par user experience, and developer experience — all simultaneously. At the core of their solution sits the modular execution layer, FuelVM. A variety of unlocks are expected with the launch of FuelVM:

• Parallelization: By executing transactions in parallel, Fuel can scale to users’ increasing demand for transaction bandwidth
• State Minimization: Fuel implements a number of solutions to reduce state growth, preserving and enhancing node decentralization
• Interoperability: Lightweight block design and compact Merkle proofs enable efficient chain introspection and cross-chain communication
• User Friendliness: Native account abstraction (AA) and multiple signature schemes that allow any wallet from any blockchain to connect to the Fuel network
• Fast Finality: Fuel will achieve transaction finality comparable to ZK rollups through a combination of Hybrid (Optimistic + ZK) proving and fast finality mechanisms

Embracing Modular Execution

As blockchains evolved, there’s been a shift towards modular architecture for scalability. Fuel aims to build the fastest modular execution layer (MEL) within this stack.

But what exactly is a modular execution layer?

A MEL is a verifiable computation system for modular blockchains. It leverages modular/lazy blockchains for data availability and offers fraud or validity proofs for verifiability.

The core idea behind modular scaling is quite simple: as long as verification (block validation) remains decentralized, computation (block production) can be passed onto a comparatively narrow set of actors. As long as verification is decoupled from computation, invalid blocks won’t be added to the chain. These MELs offer two core benefits over their monolithic counterparts:

1. Monolithic chains couple computation and verification, limiting scalability. MELs decouple these processes, improving security and scalability.
2. Over time, monolithic chains become locked into inefficient computation technologies. MELs can focus on and optimize for efficient computation.

Decoupling Computation and Verification

In monolithic blockchains, computation and verification are performed by the same entities – validators (full nodes). They execute a transaction and include the state transition in a block when a transaction is posted. Once a block is created and propagated, other full nodes download and re-execute the transactions to confirm their validity.

Applications or users that need to access the blockchain’s state but don’t want to incur the high cost of running a full node can run light clients. Light clients in monolithic chains assume blocks provided by full nodes include only valid transactions, making the trust assumption that the majority of full nodes are honest.

MELs delegate the resource-intensive execution to powerful block producers, who bundle and execute batches of transactions before periodically posting them to the base chain. To keep block producers honest, additional non-block-producing nodes (verifiers or provers) download and re-execute blocks to ensure validity. In optimistic MELs, any verifier can take action via fraud proofs when they detect an invalid transaction. Thus, on optimistic MELs like Fuel, light clients only need to rely on a single honest full node to guarantee the chain’s validity.

While larger blocks in MELs do place a higher burden on the full nodes performing validation, the honest minority assumption means that centralization in this area is less of a threat. Modular Light clients run with significantly higher security guarantees, as fraud and validity proofs enable them to identify invalid transactions based on proof from a single honest full node. As such, the execution layer can be optimized for computation and scale while relying on the security-optimized lower levels of the modular stack.

 

Optimizing for Efficient Computation

Monolithic chains often get locked into inefficient technologies when it comes to the speed and variety of computation they support. For every improvement made to Ethereum and the EVM over the years, many more potential innovations could not be implemented due to the need to maintain backward compatibility.

We constantly see new L1 blockchain launches, each promising a myriad of improvements. However, after the initial improvements, upgrading these blockchains becomes difficult, leading to a new cycle of launches with another round of incremental improvements. This has resulted in an ecosystem of incompatible blockchains, fragmenting liquidity and developer attention.

Execution layers using the EVM can capitalize on the existing ecosystem of Solidity applications and developers, but they fail to make the most of the expanded design space offered by the modular stack. A benefit of moving to modular design is that each layer is independent of the others, allowing innovation to happen on one layer without a complete overhaul of the entire stack.

By adopting new and improved VM designs, modular execution layers like FuelVM optimize for efficient, scalable computation and a superior developer experience. FuelVM, designed for fast transaction execution, incorporates learnings from Ethereum, Solana, Bitcoin, and Cosmos. This modular approach helps Fuel build solutions that keep rollup execution layers from becoming outdated over time.

With a broad understanding of Fuel’s high-level benefits, let’s dive into the network’s architecture to explore mechanisms and infrastructure that enable Fuel to address challenges in rollup stacks and create a powerful modular execution layer.

UTXO Model

UTXO stands for unspent transaction output. The way to understand UTXOs is that for each transaction, the entirety of the balance, or the amount of coins, gets spent. The amount you send to your intended recipient goes to them, and the rest gets burned, then minted again, resulting in new unspent output. A notable feature of UTXOs is that they are atomic. That is, transactions consume them in their entirety and create new ones.

What does it even mean to consume a UTXO?

The intuition lies in the validity rules defining how execution is performed over UTXOs. For coin UTXOs, the well-known validity rule is that the sum of outputs can’t exceed the sum of inputs.

Fuel uses a UTXO model similar to Bitcoin’s transaction model. In Fuel V2, the entire state is represented as a UTXO set. The UTXO transaction model is unpopular in smart contract chains, as it was considered infeasible to use UTXOs for contracts that would need to be accessed multiple times within a block, e.g., the ETH/USDC Uniswap pool on Ethereum.

Fuel’s implementation circumvents this challenge by separating:

1. Coin UTXOs – Have a balance and spending condition (exclusive owner for each UTXO)
2. Contract UTXOs – Contract UTXOs additionally also have code, storage, and a unique contract ID. The validity rules for contract UTXOs also have additional constraints. Fuel defines some new validity rules that include:
   1. Contract UTXOs are locked behind special anyone-can-spend spending condition
   2. A transaction consuming a contract UTXO creates a new contract UTXO with the same spending condition and contract ID but potentially new storage and balance
   3. Contract UTXOs spent in the same transaction can interact with each other.

Skepticism about smart contracts UTXOs has existed in the past due to contention problems in Cardano’s first AMM implementation. The problem arose because they were forcing users to sign over contract UTXOs. In popular contracts like top AMM pools, many transactions in a single block could be trying to swap into the same pool. The first transaction in the implementation consumed the UTXO, and all subsequent transactions trying to spend the same UTXO failed because it no longer existed.

Solving Contention in Smart Contract UTXOs

However, a simple workaround for the above contention problem allows smart contracts to be built in a UTXO transaction model.

Why does Cardano not just do this? https://t.co/lH0N9RJk4d pic.twitter.com/OWTNWeQIv9

— Eric Wall | BIP-420😺 (@ercwl) September 4, 2021

The trick is to have multiple parties sign over a different part of the contract UTXO. When initiating a transaction, a user signs over the contract ID, not the contract UTXO. This way, users indicate which contract they want to interact with but don’t force the contract to be in a particular state before and after execution. This is done because users don’t know the state of the contract (i.e., precise Contract UTXO) at the time of execution, as a block producer would determine the final position in the block. Instead, it should be the role of block producers to determine which exact contract UTXO a transaction is going to spend.

Unlike users, block producers determine the order and thereby know the state of the contract at the time of execution. Hence, they determine the exact input (contract UTXO) that the transaction will spend and sign over it. Upon execution, the contract UTXO is consumed and replaced by a new one representing the post-state of the contract.

FuelVM is not just limited to smart contracts as the only program type like other blockchains. A Sway program can be either a contract, a predicate, a script, or a library. A library is simply a project designed for code reuse and is never directly deployed to the chain. Predicates and Scripts have unique properties that help Fuel achieve parts of the end goal, such as state minimization, better interoperability, and creating a better end-user experience.

Predicates and Scripts — Upgrading UX

Predicates are delegate functions that return either True or False based on transaction input and output metadata. On Fuel, Predicates are represented as an ‘0x’ address. However, predicates are not derived from a private key but rather derived from the hash of its bytecode. Similar to Ethereum addresses, Predicate addresses can receive tokens and send tokens. However, unlike Ethereum addresses, the conditions to spend tokens belonging to a Predicate are defined by the underlying function.

We can think of it as a function where assets under that predicate are unlocked and can be spent by the caller if the boolean condition is evaluated to be True. The predicate can own and control UTXOs. Notably, anybody can theoretically execute the transaction as long as they can construct the transaction to evaluate the predicate as true.

Unlike contract code, predicate code is never “deployed” to the chain. To create a predicate, someone simply writes the code for the predicate and then uses a compiler to generate a code hash without interacting on-chain. Since the hash is deterministic and collision-resistant, the coins locked in this address can only be spent if the predicate conditions are met. To spend a predicate, the user would need to provide the predicate bytecode (that matches the hash/address) and a transaction that has the predicate resolving to true.

Developers have already started building core on-chain applications using predicates:

• Spark – a predicate-based central limit orderbook
• Bako – a native multisig for the fuel network

Predicates are in their early phase of development and will initially be constrained by the number of bytes as a way to meter them. In the upcoming upgrades, the team is going to constrain predicates with gas, allowing for the use of loops in predicate logic. This upgrade will make it possible to do cryptography like custom hashing and signature verification.

Scripts are short-term logic included along with transactions that is not stored in the state post-execution. Unlike EVM transactions, which can call a single contract directly, Fuel transactions can execute a script that may call zero or more contracts. Scripts allow complex multi-step actions or multi-contract interactions to be executed as a unit and then discarded, avoiding the state bloat associated with storing those interactions on-chain.

Scripts are differentiated from Predicates as they do not represent ownership of any resources (coin UTXOs) and cannot be called by a contract. Also, Scripts are state-aware. While they have no persistent storage (because they only exist temporarily during the transaction), they can call contracts and act based on the returned values and results.

We can expect improvements in UX combined with minimal state bloat thanks to Scripts across a wide variety of on-chain actions. Other examples of things from Ethereum that can benefit from Scripts include:

• DEX routing contracts (Uniswap, 1inch)
• Platforms using DSProxy (MakerDAO, DeFiSaver)
• General transaction batching (Gnosis Safe, EIP-4337)
• Bots that typically deploy multiple smart contracts to execute similar strategies across different tokens

Parallelization

Parallelization is like transforming a congested single-lane road into a multi-lane expressway to ease congestion, where transactions can be processed alongside each other. Leveraging the power of multi-core processing, parallelization drastically reduces transaction wait times and enhances the network’s efficiency.

Execution

Parallelizable execution is now a popular idea and has been embraced as a valuable feature to improve blockchain performance. The funding and market interest in upcoming L1s like Monad, Sui, Aptos, Sei, and teams like Movement Labs bringing parallelizable VM architecture to the Ethereum rollup ecosystem is at an all-time high.

The EVM currently uses a single-threaded approach to process transactions one after another without optimally utilizing the remaining cores within a CPU. If your CPU has 8 cores, 7 of them are sitting idle, which is a waste of resources. With parallel execution, we want all 8 cores in a CPU to process multiple transactions at once. This requires that no two transactions modify the same state simultaneously to avoid conflicts.

There are two main approaches to parallel execution.

1. Deterministic approach: This requires strict access lists to keep track of what state dependencies each transaction has, i.e., storage, contracts, and account balances. Here, it becomes the role of the developers to define upfront access lists, which can add complexity to the development process. This prevents multiple conflicting transactions from modifying the same state at once. Solana and Sui follow this deterministic approach to parallelization.
2. Optimistic approach: Here, all transactions are executed in parallel, assuming that no transaction conflicts with another. If any conflicts do arise, those transactions will be re-executed sequentially. Optimistic parallelization does not burden developers with specifically defining and maintaining access lists. Fuel and other parallel EVMs like Monad and Sei employ this approach.

Fuel’s UTXO model gets this ability for free because it already divides the state into elements (coin and contract UTXOs) that transactions must specify before spending. Thus, transactions that spend non-overlapping UTXOs can be sorted out and executed in parallel. This allows FuelVM to take advantage of all the advantages of multi-core processing.

Predicates used in Fuel’s account abstraction also lend a lot of parallel processing opportunities to the network because they are autonomic and don’t touch the state. Thus, the only thing needed to validate them is the transaction data itself. This means that a good chunk of Fuel’s transaction processing associated with account abstraction can be done additionally in parallel.

Validation

Since transaction outputs are explicitly included for validation, asserting that a block that another node proposed was correct does not require executing the overlapping transactions sequentially. This means that validation can happen fully in parallel regardless of state contention. In practice, this means that when nodes are syncing to the network, they can achieve even greater parallelization and catch up faster.

Asset-Oriented Design

The EVM has one native asset: ETH. All other assets are implemented via a smart contract that handles accounting for balances (ERC-20, ERC-721, ERC-1155). In Fuel, developers are free to implement assets in smart contracts, but the option exists to allow the VM to handle these assets natively.

Fuel sees blockchains as core settlement utilities for creating, managing, and moving assets globally, so assets play a central role in its architecture. Optimizing asset movement and handling has been a major design decision for the development of the VM. There are a few considerable advantages to native assets over an ERC-20 style smart contract for balance management.

1. Native asset manipulation is cheaper (in terms of gas cost) than manipulating the state in a smart contract. This can be attributed to its running at lower-level primitives (the UTXO system is used instead of modifying storage)
2. Native assets have better UX, similar to how sending ETH is much simpler and secure than sending ERC-20s (no need for setting and signing approval transactions, which has been associated with some recent exploits and targeting individual users through social engineering attacks)
3. State minimization is another benefit of integrating native assets. They require much less state, primarily because they don’t need to be part of a globally serialized Merkle state tree typically used for ERC-20 tokens.

The UTXO model further strengthens the asset-oriented design by enabling more interesting multi-input, multi-output, multi-witness, and multi-party transactional design. What this means is that a single transaction can have many kinds of coin inputs and outputs, smart contracts inputs and outputs, witness types, scripts, and spending conditions. This is far more flexible than the two typical types of transactions – calls or smart-contract deployment transactions- that we mostly see on EVM systems.

State Minimization

Across the crypto ecosystem, there’s a growing realization of the importance of addressing state growth. Teams are only now adopting strategies to tackle this critical scalability bottleneck. The common approaches fall into two main categories:

• Retroactive Optimization: These methods aim to manage and reduce an existing state footprint. They include pruning, compression, and economic incentives to encourage the release of unused state.
  • Examples: Solana’s rent model and Ethereum’s proposed state expiry mechanisms.
• Proactive Minimization: This approach involves making architectural changes that inherently promote state-efficient design. The aim is to prevent unnecessary state bloat right from the start of transaction design.
  • Examples: Fuel’s UTXO model with appended predicates and scripts.

Bitcoin and Ethereum offer different approaches to blockchain state management. Bitcoin’s UTXO model, which references previous transaction outputs, results in a leaner state. On the other hand, Ethereum’s account-based model focuses on programmability through smart contracts, leading to a larger, more complex state. This difference highlights the balance between streamlined state management and the flexibility needed for intricate on-chain computations.

Think of state management as a spectrum. Ethereum currently sits at the fully stateful end, requiring all network nodes to hold and maintain the entire state. As Ethereum’s usage and rollup adoption increase, so does the burden on the state. On the flip side, a leaner model minimizes storage requirements by accessing only relevant state elements. Ethereum is itself currently transitioning along this spectrum.

Emerging blockchains and layer 2 rollups are pursuing various strategies for state growth. Here’s a comprehensive look at the various priorities and designs being considered.

Fuel’s State Minimization Plan

Fuel takes a unique approach, tackling state growth at its root while still ensuring developers have more computing and design choices. With the UTXO model, Fuel introduces a lean and adaptable paradigm for transaction design, execution, and state management. Unlike complex accounts holding balances and internal contract logic, UTXOs represent discrete, independently trackable units of state. This simplifies the overall structure of the on-chain state that needs to be maintained, focusing on lean transactions that minimize state growth.

Fuel’s approach goes beyond reducing the size of the stored state. It’s about enabling developers to construct transactions that inherently minimize state impact. This focus on efficient state utilization could prove to be a more sustainable solution than simply optimizing access to a constantly growing state. Fuel tackles state growth with three key features:

1. Native Assets: Fuel treats assets as first-class citizens. Unlike Ethereum, where token standards like ERC-20s are implemented as layered smart contracts, assets within Fuel are baked into the core protocol as if they were native assets. This eliminates the additional state footprint associated with managing external contracts, streamlining both assets and their interactions.

For reference, Tokens deployed under the 3 major standards on Ethereum occupy nearly 50% of its entire state.

A transfer of an asset in Fuel only touches one database key-value pair instead of tens of pairs per transfer. Using Native assets and a UTXO-based transaction model eliminates unnecessary state changes accompanied by approval and transferFrom functions.

2. State rehydration: Fuel introduces the concept of ‘native state rehydration’, allowing developers to manage smart contract states more efficiently. Instead of storing the entire state on-chain, developers can break it down into smaller chunks, storing minimal records or root hashes.

 

Each smart contract uses localized state trees, eliminating the need for a global state tree. When specific state elements are needed, they can be “rehydrated” from external sources as needed over the increasing bandwidth capacity, similar to selectively retrieving files from an archive.

State rehydration over bandwidth enables access to the necessary state only when required, contrasting with Ethereum’s approach of storing everything on-chain. This process involves either the user or the dApp providing the necessary data, often relying on indexers to query and verify the data on-chain. This method is expected to be more cost-effective and sustainable compared to directly storing the entire state on-chain.

3. Predicates & Scripts: Predicates, as discussed earlier, are completely stateless. Predicates authorize transactions without themselves needing to access the global state, and their code is also not stored in a state. Instead, a hash of this code is used to calculate the “address” of the predicate. When a user sends a transaction that uses a predicate, their transaction must provide the full bytecode, effectively “rehydrating” this state.

Scripts are short-term logic included in transactions but not stored in the state. They allow complex multi-step actions or multi-contract interactions to be executed as a unit and then discard the logic, avoiding the state bloat associated with storing those interactions on-chain.

Stateless Account Abstraction

Account abstraction has been limited in its adoption on the Ethereum mainnet due to the additional gas overhead associated with UserOp transactions. But on rollups, after the introduction of blobs via EIP-4844, the cost of transacting has reduced considerably, making UserOp transactions almost as cost-effective as an EOA-initiated transaction.

Multiple rollup teams have been pushing for increased adoption of account abstraction either natively (Starknet, Zksync, Base) or through initiatives like gas credits (On-chain Summer by Base).

But one important distinction that most users and even application developers are unaware of is that there exists two types of account abstraction:

1. Stateless: Doesn’t depend on the external state
2. Stateful: Depends on the external state and needs access to the chain’s state

In a stateful AA implementation, the smart contract that defines validity conditions has access to the chain’s state. The problem with this is that a condition that is true in one block may not be true in another. For example, if a user wants to execute a transaction at block #n automatically. At block #n, they could submit a user operation into the mempool, which would be valid at the time. When the bundler tries to put it into the next block, it is not valid because the block number has increased.

The receiving node has to spend resources validating something that will never be on-chain and can’t blacklist what sent the transaction because it was valid at the time of sending. With stateless account abstraction, transactions never run the risk of changing validity. Fuel implements stateless AA with Predicates.

Benefits of Fuel’s Implementation

1. Custom verification: At its core, Fuel’s implementation of AA offers developers and users more flexibility because verification is not encoded at the protocol level. Fuel’s account abstraction allows developers to define custom verification schemes at the application level.
2. No state bloat: With predicates, there’s no need for contracts, state, or storage. Stateless account abstraction minimizes state bloat since predicates, even when spent, never enter the blockchain state and only the transaction history as a UTXO.

The general benefits of AA will be extended to FuelVM, including Social recovery of wallets, batching transactions, sponsored transactions, walletless web3 login, and using non-ETH tokens to pay for gas. However, Fuel’s implementation of account abstraction through predicates uniquely enables some user experiences.

1. Off-chain fraud monitoring: Users can lock their coins behind a predicate that can only be spent if a fraud monitoring entity also signs off on it. This would bring money transfer UX closer to a credit card or bank in traditional finance, but with the power to override the centralized authority.
2. Building intent systems or transaction automation: The predicate itself can include a bounty in its logic for some solver to take if they execute the on-chain task on the user’s behalf.
3. Order flow markets: Predicates with their bytecode hashing can be used to create a private swap order that guarantees only a function caller/block builder that knows the bytecode behind the predicate address can execute the transaction. This is a way for order makers and order takers to make an off-chain agreement about the execution of a given order but then fully execute the order trustlessly.
4. Fully on-chain central limit order book (CLOB): Spark uses a predicate-based DEX architecture. It uses a data availability layer to enable public order visibility and on-chain verification by checking the Predicate address balance. An illustration of a simple trade on Spark:

Hybrid Proving

Most readers will be familiar with the two major categories of Layer-2 scalability solutions for Ethereum – optimistic rollups (ORUs) and zero-knowledge (ZK) rollups. However, Fuel introduces an innovative concept – Hybrid Proving, which combines the strengths of both types of systems. This blend of ORUs’ simplicity and ZK rollups’ instant execution verification allows Fuel to deliver enhanced scalability and security. Before we understand how Fuel’s Hybrid proving works, we should understand how Optimistic rollups structure the verification process.

In Stage 2 ORUs, a sequencer set formed from bonded participants can attest to a state root for each rollup block. Anyone can challenge these state roots. If a challenge is initiated, the attester and the challenger play an “Interactive Verification Game” (IVG) to identify the exact execution step on which they disagree. This single execution step is then executed on light clients, typically implemented on the Ethereum mainnet.

The primary aim of this game is to minimize the computation required on the rollup light client to verify a fault proof. If we had to run the entire rollup block to verify that the attester attested to a wrong state root, the L2 throughput would be limited by the L1’s throughput.

How does Hybrid Proving differ from existing optimistic rollups?

Hybrid Proving resolves these challenges differently. If an invalid block is submitted and challenged, the evidence is run through a ZK proving system, delivering a definitive verdict about the block’s validity. Instead of playing the IVG and executing every single step on-chain, the challenger merely proves a single rollup block. Within Hybrid Proving for a single rollup block, the zk-proof becomes the fault proof.

FuelProver

A core component making this verification game possible is the FuelProver. It is built with Ethereum’s philosophy of multiple client implementations, bringing robustness and resilience to Fuel’s security model. It will be compatible with various ZK-proving architectures, ensuring it’s up-to-date with the latest advancements in ZK technology.

FuelProver adopts a multi-prover model and introduces faster on-chain actionable finality in the Ethereum Optimistic rollup ecosystem. The waiting periods associated with multiple rounds of fraud challenge games in ORUs are significantly reduced, ensuring the swift bridging of digital assets.

The FuelProver’s agnostic approach allows for integration with various underlying architectures while retaining the benefits of Fuel’s virtual machine and parallel transaction execution. This flexibility paves the way for a smooth transition towards full ZK rollups in the future without compromising on current scalability needs.

Fast Finality Gadget

The 7-day withdrawal period for optimistic rollups is a major drawback of using ORUs. Fuel plans to tackle this limitation using a mechanism proposed for fast finality – a “check-in” based dynamic challenge window. Instead of having a fixed 7-day fraud proving window, validators are required to periodically “check-in” every epoch with one of three states:

1. True – No invalid state transitions were witnessed in the last epoch.
2. False – An invalid state transition was witnessed, initiating fault-proving process.
3. No report – The validator is offline or being censored.

If all validators check in with “True,” the state can be finalized within 1 Ethereum slot. If a validator reports “False,” the fault-proving game commences, and the state finalizes after the game concludes. If a validator fails to report (“No-report”), it is treated as potential censorship, and the challenge window dynamically can extend up until the maximum safe window of 7 days.

The key idea is that an honest minority, even if censored, can passively extend the finality window to the maximum safe duration of 7 days by not reporting, effectively thwarting censorship attacks without submitting any transactions. This empowers a single honest minority to resist multi-billion dollar censorship attacks on Ethereum by doing nothing, ensuring the system reverts to the safer long finality window when under attack.

Griefing Risk

However, a risk associated with the mechanism is if a validator joins the network and intentionally fails to post the check-in. This is a grieving attack that would revert the finality to the maximum 7-day window. The Fuel team has suggested economic and cryptographic solutions to mitigate this attack vector.

1. Bonding and Slashing: Require validators to bond capital that can be slashed if they go offline for an extended period without legitimate reasons like reporting fraud. The slashed amount can scale linearly the longer they are offline.
2. MPC: Each Validator node could use secure multi-party computation to operate in a decentralized way, reducing the risk of the whole validator going offline if one particular signer is inactive.

The system proposed by the Fuel team is to create economic incentives and penalties for validators to consistently check in on time while still allowing an extended window in case of legitimate issues before slashing occurs. The ultimate goal with the entire proving setup with the hybrid proving, bonded validators and fast finality mechanism is to lower the finality and withdrawal periods to be shorter than most ZK rollups (i.e., less than StarkNet at 12 hours and zkSync at around 24 hours).

Interoperability Through Introspection

Introspection refers to the ability of smart contracts to examine, analyze, and understand their properties and the state of the blockchain. This capability allows smart contracts to modify their work based on the state of the network. With the ability to introspect easily, any external chain can also confirm the validity of transactions and state on Fuel.

The EVM schema is straightforward. Blocks contain transactions, and transactions contain logs. Contracts emit events that appear on-chain as logs and are decoded by indexers. To understand the unlocks enabled by Fuel’s introspection ability, we need to understand:

1. Receipt Roots:
   • These hashes, derived from transaction records and logs emitted within a block, are stored in the block header to efficiently confirm transaction outcomes, including success or failure.
2. Transaction Root:
   • Another hash in the block header represents all transactions in the block. Each leaf node embodies a transaction, forming the Merkle root, which facilitates verification of transaction inclusion in a block without exhaustive processing.
3. State Root:
   • The state root represents the current blockchain state and is a Merkle tree hash summarizing all account balances after block processing. It ensures integrity and consistency by swiftly verifying account states without traversing all historical transactions.

Using these roots, we can generate Storage and State proofs. Storage proofs allow us to prove that something is committed to the state and is valid using cryptographic commitments. If we can provide such proofs, it is a verifiable claim that something happened on the blockchain. Whereas state proof provides evidence that a certain account or smart contract holds a particular balance, possesses certain properties, or has undergone specific transactions up to a certain block height. These Merkle proofs allow light clients to get answers to questions like:

• What is the current balance of a particular account?
• Does this account exist?
• Was this transfer event for token A emitted in block B?

Using storage proofs, multiple possibilities can be unlocked across application, middleware, and infrastructure layers. Just at the application layer, these proofs can allow for cross-chain voting and streamlined token distribution without asset bridging. They can also empower identity and reputation systems in a multichain world, enabling users to prove ownership and usage history or even establish on-chain credit scores. In DeFi, these proofs can facilitate cross-chain lending and on-chain insurance settlements, fostering a more interconnected and efficient financial ecosystem.

EVM has receipt roots but only contains receipts of logs emitted from smart contracts. Something as commonplace as ETH transfers is unprovable and difficult to discover on the EVM. Smart contracts on Ethereum can only access the block hash of the 256 most recent blocks. Theoretically, one could prove the existence of any previous block using a proof since the hash of any recent block is derived from the hashes of earlier blocks. In practice, generating such proofs may become difficult, as the proof would need significant data. We would also need to rely on ZK proofs to reduce the proof size and verify proofs efficiently.

Having access to historical block hashes is useful as it can allow verification of proofs against them. This challenge is further complicated in the multi-chain ecosystem, where data retrieval and verification across different execution layers is even more difficult.

For example, sourcing the account balance for an arbitrary ERC-20 token on Ethereum through a State proof would require parsing through the global state tree for sourcing the token contract through a Merkle tree of depth-256. This would be followed by a storage proof through another Merkle tree of depth-256.Fuel takes a different approach with its schema. Blocks and transactions have the same relationship, but each transaction contains an array of Input and Output Receipts, allowing a lot more information to be gathered about what happened in transactions and the block from easier-to-digest proofs. This is possible because FuelVM emits better receipts and the absence of a global state root.

FuelVM events appear on-chain as Log and LogData receipt types, similar to EVM logs. There are 13 types of Receipts: Call, Return, ReturnData, Panic, Revert, Log, LogData, Transfer, TransferOut, ScriptResult, MessageOut, Mint, and Burn, providing easy access to a lot more information about the transactions. Inputs can be of type InputCoin, InputContract, or InputMessage, and Outputs can be of the type CoinOutput, ContractOutput, ChangeOutput, VariableOutput, or ContractCreated. All of these fields mentioned can be retrieved with the same ease as retrieving logs in EVM. As a result of the rich receipts/logs, FuelVM opens up a whole new world of possibilities for creative indexing and proving.

Instead of having a global state root, every smart contract on Fuel has a local state root and a Merkle tree of depth 256. The Merkle tree for transactions in a block is a local tree with a shallower depth (approximately ~16) due to the limited block size in the FuelVM. As mentioned earlier, Fuel exposes a receipt root per transaction, which is also shallow with a Merkle tree with depth-16, which is far easier to descend and prove.

By providing rich receipts and localized state roots at the contract level, Fuel makes introspecting state and receipts much easier for application developers. 

Register Based Machine

FuelVM is a register-based machine similar to Solana BPF. This is unlike EVM, which is a stack-based machine. The main difference is that stack-based machines have smaller instructions than register-based machines but generally need more instructions to get things done. Register-based machines require fewer and more efficient opcodes to achieve similar functionality. Fewer instructions enable register-based machines to go faster.

Unlike CPUs or other general-purpose architectures, each instruction (opcode) in a blockchain is priced, and functions requiring more instructions will cost an end user more. Node operators spend sizable computational resources on resource pricing in stack-based blockchain virtual machines, which can be better utilized for more transaction processing in a register-based machine like the FuelVM.

The Sway Programming Language

The Fuel protocol has been designed with better developer experience at the forefront. FuelVM has its own Rust-based, domain-specific language called Sway. Unlike Solidity, which was developed after the creation of the EVM, Sway has been created in parallel with the FuelVM to have convenient and efficient opcodes built in. By basing Sway on Rust, Fuel makes smart contract development safer and more performant through the use of strong static analysis and compiler feedback.

Rust has, within the span of 9 years, become a major programming language, with 13% of developers working with it in some capacity. Interestingly, it is the most admired of all the languages covered by the Stack Overflow Developer Survey 2023, a title it has now held for 8 years. SlashData’s State of the Developer Nation report indicates there were around 2.8 million Rust developers in 2023, and the number has tripled in the past two years. The Fuel team hopes to take this interest and growth in the Rust ecosystem and bring the developer mindshare to its ecosystem through Sway.

Sway unlocks a safer and more flexible blockchain development experience compared to Solidity. It has other features like in-memory vectors, traits, modern language servers, and it follows modern programming paradigms of Rust language design. Sway is also multi-context and can be used to produce code for predicates, scripts, smart contracts, indexing, deployment, and testing. Many of these tasks are done independently on many existing blockchains.

The team envisions Sway as an alternative smart contract programming language not only for FuelVM but also for other architectures like EVM, MoveVM, and SVM. By expanding Sway’s adoption across various blockchain ecosystems, they aim to establish it as the standard for developing the next generation of faster, safer, and more efficient smart contracts.

This is a lofty and challenging goal, especially since Rust’s versatility for non-Web3 applications made it easier for Web2 developers to transition into smart contract programming. The industry has also seen limited success in programming languages purpose-built for writing smart contracts. Development activity in the Fuel ecosystem development activity stagnated in 2023 and is recovering back from the beginning of the year as mainnet approaches.

Forc — Development Toolkit

Going beyond just creating a programming language for writing smart contracts, Fuel improves the developer experience with the Forc (”Fuel Orchestrator”) toolchain. Inspired by Rust’s package manager Cargo, developers can get everything they need to create FuelVM applications using Sway within the Forc toolchain. Forc takes a “batteries-included” approach (i.e., the product comes with all the parts required to use it fully), yet uses a modular approach to provide tooling. Developers can choose which tools from the toolkit they need for their development needs.

Forc will be available with a comprehensive, standardized set of tools covering not only the stack’s lower levels—like protocol and VM implementations—but also the higher levels—like package management, editor support, and common-use plugins.

Currently, the Sway Playground has an interesting tool from the toolchain that any reader can try out called Charcoal. It has been created so EVM developers can start building and experimenting within the fuel ecosystem. Charcoal is a Solidity -> Sway Transpiler. Charcoal Transpiler is a type of translator that takes the source code of a program written in a Solidity as its input and produces an equivalent source code in Sway.

 

Solidity to @SwayLang Transpiler achieved externally 🫡

We added an S2S transpiler to the Fuel Toolchain to make it easy for Solidity developers to learn Sway, transpile Solidity contracts, and onboard to Fuel:https://t.co/auSOSUztw5 pic.twitter.com/E9oNs3aP7q

— Fuel (@fuel_network) April 23, 2024

Such tools allow many simpler applications from the EVM ecosystem to be easily ported to the FuelVM ecosystem. Tools like the Charcoal transpiler act as a gateway to attract developers and educate them about the possibilities that Sway and FuelVM unlock.

Conclusion

Fuel promises to enrich the modular stack with its innovative contributions and address crucial aspects essential for the advancement of a Modular Ethereum. By implementing state minimization techniques, parallelized execution, hybrid proving, and introducing a purpose-built programming language, Fuel can emerge as a pivotal player in reshaping the idea of an execution layer.

Despite the complexity of executing over UTXOs, Fuel’s distinct capabilities hold the potential for the emergence of new types of applications. Instead of building for Ethereum’s current state, Fuel is building for the future of modularity, which sets it apart from all current rollups. The upcoming mainnet launch will mark just the beginning of Fuel’s journey, as the team harbors ambitious plans to expand and further refine its offerings.