Key Insights
- Fuel is a modular execution layer that uses the FuelVM and a new programming language, Sway, aimed at overcoming the limitations of the EVM.
- Though Fuel will ultimately support multiple rollup configurations, its first iteration will be fraud-proof based using Ethereum for settlement.
- Fuel uses the unspent transaction output (UTXO) model instead of the account-based model used by Ethereum. This approach helps improve user app experiences with functionalities like predicates, which are conditions for how a UTXO can be spent.
- To aid developers in adjusting to a new development stack, Sway comes with a toolchain called Forc to allow for package management in one place.
New players are constantly entering the multi-chain race, with rollups and app chains competing for developer and user attention. Among them is Fuel, a modular execution layer for highly configurable rollups. Fuel introduces an entirely new virtual machine, the FuelVM, which allows builders to tap into a range of capabilities to develop novel applications.
Project Background
Fuel V1 was the first optimistic rollup on Ethereum for payments, without smart contract capabilities, and to this day, it is the only optimistic rollup with a permissionless fraud-proof system. The latest round included participants such as Blockchain Capital and Stratos Capital, and the capital will support the development of Fuel V2, which recently launched its third testnet. Though the Fuel stack will contain the capability to function as a monolithic chain, the team is building Fuel V2 as a fraud-provable modular execution layer.
Refresher on Rollups & Modular Blockchains
There are three main functions of a blockchain.
- Consensus: Verifies the state of the blockchain and provides security as it ensures that all added transactions are valid.
- Data Availability (DA): Ensures that all data (regardless of veracity) is made available and transparent for the entire node network to view and verify. This provides the guarantee that the chain can be trusted.
- Execution: This layer acts upon smart contracts as transactions occur to update the chain’s state. Computation alters the state of the blockchain and is cued from smart contracts or signed transactions. Rollups, which are execution environments, execute transactions on separate blockchains and post the compressed transaction data back to the L1.
- Settlement: The settlement layer handles proofs and settles disputes — it is also where finality occurs and is baked into the monolithic model. Sovereign rollups have their own settlement function.
Because monolithic blockchains handle all these functions on one chain, they quickly become inefficient, creating the blockchain trilemma. In the case of Ethereum, as usage increased, the execution function was outsourced to rollups so that the Layer-1 (L1) could focus on security and decentralization. Because rollups have smart contracts on Ethereum to verify state, they inherit its security.
But rollups can scale only so much as the capacity of the DA solution it uses. For example, since Ethereum handles all the functions of a monolithic chain, its DA capacity creates an upper limit for rollup scalability. Celestia, previously known as LazyLedger, a modular DA layer, championed the concept of a modular blockchain. It was built to only focus on DA and consensus and handles a bigger DA capacity than Ethereum, allowing for better rollup performance.
Where Fuel Fits in the Modular Blockchain Stack
As a modular execution layer, Fuel can effectively be used as part of a monolithic chain or as an execution environment that uses separate layers for settlement, consensus, and data availability. With modularity at its core, Fuel can achieve high bandwidth because it is not limited to any one configuration. The first implementation of Fuel will be an optimistic rollup that settles to Ethereum; but the execution layer is ultimately proof and chain-agnostic.
The Fuel Architecture
Relatively speaking, the EVM is slow and expensive. Ethereum also struggles to make changes to the EVM as they may affect backward compatibility, which ensures that new upgrades or forks will not break existing smart contracts. These limitations prompted the development of FuelVM, which has been designed to surpass the limits of the EVM and includes coveted features such as efficient transaction processing and safety measures built into the accompanying programming language from the get-go.
The UTXO Model
For its accounting model, Fuel uses the UTXO model, inherited from Bitcoin. In the UTXO model, assets are stored on the ledger as a directed acyclic graph (DAG) between addresses. In a transaction, unspent outputs are consumed to create new outputs.
By contrast, the account-based model adds and subtracts transactions from addresses stored in a database of network states. Ethereum, Solana, all EVM-based chains, and many other smart contract networks use an account-based model, which is similar to how accounts work within banks. As a user (owner of the private key) signs a transaction to transfer tokens, their accounts are debited that amount, while the receiver’s account is credited with that amount.
Because Fuel uses the UTXO model, it does not use wallets or accounts. Instead, every prompted transaction burns and creates tokens. Each UTXO is uniquely identified and can only be spent once, which helps prevent double-spend. In addition to a coin UTXO that UTXO-based systems typically have, Fuel also has contract UTXOs, which contain amount of coins, contract ID, hash, and a storage root.
Parallel Order Processing
The use of UTXOs enables parallel order processing, where orders which have no dependence on each other can be executed in parallel, across multiple CPU threads at once.
FuelVM uses strict access lists to enable parallelization. That is, each transaction has to include what contracts it may touch to avoid simultaneously executing transactions that affect the same contract. Parallelization generates dramatically higher throughput compared to ordering transactions, a driver of EVM inefficiency.
How Fuel Navigates Concurrency
Because the EVM stores global state, different agents can interact with its smart contracts. With UTXOs, the concurrency problem may occur, which is where a UTXO can only be used once as well as the smart contract associated with it. Cardano utilizes an extended UTXO model and has faced this issue, particularly in DeFi applications. A bottleneck is created because transactions typically require multiple users to interact with a single smart contract at once, but concurrency prevents them from doing so.
The use of contract UTXOs helps Fuel avoid this issue. Since contract UTXOs are uniquely identified by their contract ID, users provide contract IDs for contracts they intend to interact with instead of UTXO IDs. Then, it is up to the block producers to decide which UTXO a transaction will spend and the resulting state of the associated contract. Each transaction consumes the contract UTXO and a new one with a new state is created.
Minimizing State Through Scripts & Predicates
The FuelVM supports the following program types: smart contracts, scripts, libraries, and predicates. Unlike the EVM, where each interaction with a contract is a separate transaction, FuelVM can call multiple contracts in one transaction with a script.
Predicates are the conditions under which a UTXO can be spent. A predicate evaluates to either True or False to determine if a transaction will take place. If a predicate does not match its authorized condition, the transaction is invalid – it does not get included in a block, and no gas is spent. This is possible because transaction outputs rely on outputs from previous transactions, forcing a level of atomicity. The cost and validity of transactions can be predicted prior to execution. Fees can also be predicted as there is no arbitrary ordering based on a gas variable.
The main benefits of UTXO and predicates are the minimization of state growth and the introduction of account abstraction (AA). As blockchains grow, they are prone to state bloat. State bloat results in increased pressure on the chain’s performance and the requirements for running nodes. As fewer nodes can keep up with the resulting hardware costs, the risk of centralization grows. Rollups offload some state growth from the L1, but unfortunately, they are also prone to state bloat as usage increases.
Since scripts and predicates do not store data as a smart contract does, they do not contribute to state growth. Without this impending strain on Fuel, it can continuously sustain users and their activity as it grows.
Because each UTXO takes in multiple inputs and create corresponding outputs, it is easier to involve multiple users in a transaction. With the EVM, a multisig is a set of permanent contracts, but with FuelVM, native multisigs let users set up a predicate to initiate transactions, without storing state on-chain. This yields faster and more efficient activity for groups of users.
Account Abstraction via Predicates
UTXOs and predicates naturally result in account abstraction, which allows for programmable transaction validation. Further, Fuel implements stateless account abstraction, which means it doesn’t depend on external state and doesn’t contribute to state bloat. On Fuel, one can program a predicate to be spent based on an output, e.g., the transaction is only valid if X happens. Developers are also able to define custom verification schemes at the application level, since AA is not prescribed to the protocol.
Ethereum is on its way to including AA in the core protocol, but won’t have the feature of being able to program based on outputs. Fuel AA enables use cases such as social recovery, apps subsidizing transaction fees, and using wallets with different signature schemes.
Trust-Minimized Light Client Security
In a monolithic chain, a user can run a full node to verify the chain’s state for maximum security. But, as a network scales, hardware requirements may become prohibitively expensive for average users that wish to provide security. The Bitcoin whitepaper outlined the idea of a light client, which is a minimized version of a full node that can provide partial security, allowing users to verify blocks without needing to run a full node. In this scenario, users only download block headers and assume that the majority full nodes validators in the system are being honest and rejecting malicious transactions.
On Fuel, light clients can participate in verifying blocks through fraud proofs, without the need of trusting any parties to being honest. Light clients enhance the chain’s security guarantees without invoking centralization or scalability concerns. This moves the needle towards allowing user sovereignty, low computation requirements, but with high security guaranteed.
Multiple Native Tokens
Though there are no public details about a native Fuel token, the eventual token will be used for staking and challenging a transaction, but ETH will be used for transaction fees. But, unlike account-based systems that have one token with first-class treatment (e.g., ETH on Ethereum), any asset minted on Fuel will obtain almost all the same functionalities as a native token.
Within the FuelVM, any contract can mint a UTXO-based native asset through a set of opcodes. Each of these tokens then inherit the benefits of native calling and optimization. No one asset has special native functionality.
Further, users can send assets without the use of token contracts to track ownership, like in account-based blockchains, thereby reducing dependence on smart contracts and potential vulnerabilities. The token contract will only be needed to handle burning and minting.
Better DevEx with Sway
Sway is a programming language inspired by Rust. It was built for the FuelVM, with the goal of bringing modern programming language principles to blockchain, while improving upon what Solidity and Move offer. Sway offers modern language design with structs, trait-based inheritance, generic types, and more, enabling developers to write expressive and extensible applications. To support developers getting adjusted to Sway, the team built out Forc, a Sway toolchain for building, deploying, and testing Sway code. It includes a package manager that provides easy access to Sway tooling. Other integrated tooling includes a VSCode extension, testing infrastructure, and block explorer.
The safety component of the Sway language is crucial. It features compile-time analysis passes to check code for potential vulnerabilities and bugs, an example is the compile-time reentrancy violation check. If Sway finds that a smart contract is vulnerable to a reentrancy attack (withdrawing funds from a smart contract to transfer to an unauthorized contract repeatedly), then Sway will not allow the app to be deployed. This feature is not available via Solidity and historically, DeFi projects have suffered from several such vulnerabilities.
Regardless of the developer experience around a new language, the new community and tooling will take a while to get used to. Adoption of new languages like Sway only happens if developers see an established foundation to tap into for audited, composable code, along with liquidity to sustain apps. For an entirely new VM like Fuel, this will likely take time, even with ongoing efforts like developer tooling, business development, and an ongoing grants program.
What’s Cooking on Fuel?
Multiple teams are building with/on Fuel across the Web3 stack, with most concentrated on batching transactions using parallelization in both DeFi and other consumer applications.
Elix is a DEX focused on providing efficient trades with low slippage. The team borrows principles from proven mechanisms, such as the concentrated liquidity pools on Curve, allowing users to trade under ideal circumstances. Because Elix will use Fuel, it can leverage parallel processing, which means faster trades with high-security guarantees.
Thunder is an NFT marketplace that enables bulk trades in a single transaction with minimal fees. For the seasoned NFT trader, this marketplace looks like a more seamless trading experience, with fast transaction times through parallelization.
Risks and Concerns
Aside from the expected implementation and smart contract risks, there are a few key concerns due to the nascency of the project. While Fuel implements many different features to produce an execution layer for developer flexibility and better usability, there is little established infrastructure for developers – something they get with the EVM. Developers might find challenges working with new code and tools that are not as battle-tested and audited as Solidity-based contracts.
Fuel will be entering the race alongside already successful general-purpose rollups, and zkEVMs en route to mainnet. It will face staunch competition from existing optimistic rollups, given that Arbitrum and Optimism now command approximately $3 billion in TVL and offer cheap and fast transactions. To distinguish itself from the incumbent L2s, Fuel will need to introduce a slew of native applications exclusively available to Fuel that provide efficient and safer experiences.
Parting Thoughts
Fuel offers features such as modularization, a brand-new VM, and the byproducts of the UTXO model – setting it up for high bandwidth. These allow it to differentiate itself from Ethereum and some of its limiting design features. Fuel’s approach provides a fertile ground for applications and user experiences that Ethereum has yet to offer. That said, it will take some time before Fuel V2 is on mainnet and can compete for market share with established rollups. But, making thoughtful design choices may set it up for long-term sustainability.
