Exploring FuelVM: A Custom Virtual Machine Built Specifically for Executing Smart Contracts
FuelVM is designed to be modular, allowing it to serve as the execution engine for any blockchain.Original Title: 《Exploring the FuelVM》
Author: Ryan Sproule
Compiled by: 老雅痞
Introduction to Sway and FuelVM
Fuel Labs is building a new execution layer to scale the next generation of blockchain applications. FuelVM is designed to be modular—it can serve as the execution engine for any blockchain. Initially, FuelVM will be deployed as a Layer 2 rollup for Ethereum, but theoretically, it could be deployed anywhere as L2 or even another L1. FuelVM aims to scale Ethereum without increasing node requirements, but rather by extracting more from existing hardware.
Fuel Labs is also building a new DSL called Sway for writing contracts for FuelVM. Sway is inspired by Rust and Solidity, creating an ideal programming language for smart contracts.
What is FuelVM?
FuelVM is a custom virtual machine built specifically for executing smart contracts. From the beginning, FuelVM was designed to be fraud-proof and can be used as the transaction execution layer for optimistic rollups.
FuelVM is optimized to better utilize hardware to improve transaction execution throughput. Specifically, it is based on UTXO and enforces that each transaction explicitly defines which UTXOs it will touch. Since the execution engine can accurately identify the state touched by each transaction, it can easily find non-contentious transactions and parallelize them.
Why is VM Important?
In smart contract blockchain systems, the VM is the system that understands smart contract code and executes state transitions based on the rules defined in that code. The VM is the operating system of the smart contract blockchain.
So far, there have been no iterations of smart contract VMs beyond the initial version provided by Ethereum. Currently, all widely used smart contract chains (except Solana) use the same VM as Ethereum: the EVM.
At present, the EVM is "good enough" because the main bottleneck in scaling is not the speed of transaction execution, but the bandwidth (block space) that the consensus engine can support. With the development of Layer 2 scaling solutions and DA solutions like Celestia, EIP-4844, Danksharding, and EigenDA, the cost of publishing rollup transaction data to L1 will no longer be a major constraint.
In this upcoming environment where bandwidth is cheap, the next bottleneck will be computational throughput: how fast the system can execute transactions while keeping the underlying hardware requirements low enough to achieve sufficient decentralization. The advantage of FuelVM is that it considers these future factors in its design and can be optimized accordingly.
Differentiated Advantages of FuelVM
Execution + Verification Parallelization
The secret behind FuelVM's parallel virtual machine is its strict access list—it requires users to specify which contracts their transactions will involve. Checking the exact composition of transactions in FuelVM is very helpful.
Input: A list of all contract UTXOs that the transaction will touch + data for unlocking UTXOs or predicate scripts.
Output: Defines the UTXOs that will be created.
Gas Information: Gas price + Gas limit.
Witness: Metadata + digital signature authorization.
The key point here is the explicit "input" list, which lists all UTXOs that will be consumed. This includes "special" contract UTXOs. If the VM can determine which contracts a transaction will touch before executing any code, it can safely parallelize all other non-contentious state access transactions.
Note that since transaction outputs are explicitly included in the verification, there is no need to execute overlapping transactions in order when asserting whether a block proposed by another node is correct. This means that verification can be fully parallelized regardless of state contention. In practice, this means that when nodes sync with the network, they can achieve greater parallelization and catch up faster.
Native Asset System
In the EVM, there is one native asset: ETH. All other assets are implemented through smart contracts that handle balance accounting (ERC20). In Fuel, developers can freely implement assets in smart contracts, but there is an option that allows the VM to handle this natively.
In terms of balance management, native assets have several significant advantages over ERC20-style smart contracts. First, operations on native assets are cheaper than manipulating state in smart contracts. This can be attributed to running at a lower-level primitive (the UTXO system is used instead of manipulating storage). Second, native assets provide a better user experience, as sending ETH is much simpler than sending ERC20 (no need to set up approvals).
Native Account Abstraction + Predicates
Account abstraction has been a hot topic of research, with the Ethereum community making several attempts over the years through EIPs (EIP-86, EIP-2938, EIP-3074, EIP-4337, EIP-5003). Implementing and upgrading Ethereum to support account abstraction is challenging, mainly due to the core team's engineering bandwidth/technical debt combined with the associated complexity and a long list of higher-priority projects. Many rollups have had the opportunity from the start to implement account abstraction in their novel execution environments. FuelVM is one of them, and in addition to native account abstraction, it will include an interesting new primitive: predicates.
Predicates are pure (non-state accessing) contract scripts that only return a boolean value (true or false). UTXOs can be locked behind a predicate, so they can only be used when the conditions defined in the predicate are met. This presents an interesting UX opportunity where users can set transactions to execute only under certain conditions, and once the predicate is satisfied, their transactions can be executed automatically. Additionally, predicates can be pruned when destroyed, so they do not lead to state bloat.
A simple demonstration example: a user sets a transaction to purchase X tokens as long as the price meets the threshold defined in the predicate. Voilà, the pièce de résistance, completely on-chain trustless limit orders that do not cause state bloat!
Multidimensional Resource Pricing
Resource pricing is one of the most critical components of smart contract blockchains. It maintains decentralization by keeping on-chain resource demand at reasonable, affordable levels. Resource pricing allows the system to charge users for the "work" of nodes in the network.
In the EVM, one of the most common reasons for introducing EIPs is the repricing of opcodes. This is because opcodes have hardcoded gas prices, while the underlying price of resources does not scale proportionally (historically, CPU improvements have been faster than SSDs). Ideally, these systems would be able to price each resource independently, allowing the entire fee system to dynamically adjust based on changes in the underlying hardware system.
FuelVM will be able to implement dynamic multi-resource pricing, which can incentivize node operators to better optimize their underlying hardware while still maximizing "per-block utility."
This image demonstrates a situation where the demand for smart contracts is significantly higher than for other smart contracts. With localized resource pricing, other contracts will not be affected to the same degree. NFT airdrops are a great example. This is not exactly the same as resource pricing versus contract pricing (Solana style), but the effect is very similar. Smart contracts with specific resource profiles will be priced differently than other contracts. In the case of NFT airdrops, a hot contract may have a storage-intensive but very low computational cost resource profile. In contrast, smart contracts that require a high amount of computation relative to storage will not be affected by noisy NFT airdrops.
Solana's strategy of breaking the account or contract fee market adds a layer of abstraction between the actual underlying resources and their demand. This means that there can still be situations where fees are very low, but the pressure on nodes is very high. For example, due to an event (such as many different NFTs being minted simultaneously), the storage load on the system may be very high, but the fees are very low because not all traffic occurs on one account. The fee model for each account does address the hot partitioning problem of accounts, but leaves the system unable to price the underlying resources correctly, which can still lead to failures.
Pricing the system based on underlying hardware resources is cleaner and more accurate than trying to add a network-specific layer of abstraction for resource pricing based on multiple markets.
State Bloat Considerations
As the Geth team has mentioned multiple times, the current bottleneck in Geth is the I/O of state reads and writes. The initial idea was that 100% of the Merkle Patricia Trie (MPT) state would fit into the RAM of standard devices. The situation has changed now, as the state has grown to over 900 GB and is expected to grow by about 50-100 GB per year, which is unreasonable for anyone, so most nodes have turned to SSDs to store the state. Historically, SSDs have not improved rapidly with the growth of state size, so this cost will continue to affect the decentralization of the network. This is a key issue that Ethereum researchers have been discussing for some time.
In contrast, FuelVM was built with this issue in mind. Fuel Labs co-founder John Adler has often discussed the role of resource pricing in the process of smart contracts consuming state or other resources. By combining appropriate resource pricing and a clearer data model with the UTXO system, FuelVM will be able to keep state under control and reduce the cost of running nodes, which effectively increases the decentralization of the network.
Decentralization of the "Sequencer"
While Layer 2 allows us to offload computational work from the main chain, they still need to provide a mechanism to order transactions. Many Layer 2 solutions are initiated using so-called "sequencers." A sequencer is a privileged node responsible for ordering transactions, executing state transitions, and then submitting the state root along with compressed transaction information to Layer 1 Ethereum. Notably, a supercomputer responsible for sequencing can execute more transactions per epoch than many small computers redundantly executing the same transaction sequence.
There are several key issues with this centralized sequencing role that need more attention!
Controlling the order of transactions is very profitable. We observe in Ethereum and other blockchains that MEV is one of the main sources of income for those who order blocks. As we see today in traditional finance, unilateral control over ordering and MEV capture ultimately leads to a decline in user execution capabilities.
From a usability and regulatory perspective, a centralized sequencer can be a single point of failure. If one or a few organizations are running the sequencer, they could be incapacitated or shut down. This poses a living risk to the network.
A centralized sequencer can censor Layer 2 transactions. The sequencer can choose any transaction and place them in any order while building blocks, creating the potential for censorship. Many L2s address this by providing a "forced transaction" mechanism that allows users to bypass the sequencer by directly including transactions through L1.
Sequencers may make inconsistent chain state commitments to rollup users. This is often referred to as equivocation, which essentially means that the sequencer can make misleading commitments about certain states of L2. This is because the rapid finality of rollups is a trusted step, and a sequencer might abuse this trust, leading users to do things they did not intend to do.
How Does Fuel Address These Issues?
First, Fuel is not just a rollup or L1 blockchain; rather, it is a system for applying state transitions that can publish state transitions to L1 if configured as a rollup or run as L1 in the network for consensus. The key distinction is that Fuel's execution engine does not care about consensus or transaction ordering. Fuel is only responsible for applying transactions as quickly as possible. However, because Fuel can run on such lightweight hardware and verification is so cheap, Fuel can guide a diverse and decentralized consensus network, which is much cheaper than running an equivalent system with a poorly performing execution engine like the EVM.
Additionally, the Fuel team is considering a Layer 2 tokenomics that combines decentralization, MEV, and other considerations. Fuel co-founder John Adler wrote an article in January about Layer 2 blockchain token models, outlining a token design that helps decentralize block production by allowing rollups to tokenize the scarcity of block space through the right to charge fees as block producers. Fees are just one part of the income for block producers; as we see in other chains, MEV is another significant part of the income. Similar to the scarcity of block space, MEV income will also be tokenized through block production rights.
State Model: UTXO vs Account-Based
The best way to conceptualize the difference between the UTXO data model and the account model is as follows: UTXOs can be likened to cash bills, while the account model is more like a bank ledger. The account system naturally leads to state bloat because each transaction attempts to access the same account, while UTXOs, if designed correctly, have less contention. This characteristic allows for better parallelization and can also prevent state bloat by simplifying the state pruning process.
Continuing with the cash vs. bank ledger analogy, it becomes clear why parallelization using UTXOs is much easier. Two cash transactions can occur simultaneously without needing to know any information about each other, whereas if there are two account updates on a ledger, both transactions must update the same shared ledger.
VM Wars
In addition to Fuel, other teams are also developing next-generation virtual machines for smart contract blockchains, such as Mysten Labs and Aptos, which is using the MoveVM, initially designed as part of the Libra project by Facebook engineers. This further supports the argument that new execution environments are needed to support the next generation of blockchain applications. All these projects have interesting approaches and make different trade-offs.
During the years when MoveVM was stagnant while Libra was busy with lawsuits, the cryptocurrency world underwent many changes. Fuel has been able to adapt to these changes and remain agile in a fast-paced industry, while Move has lagged slightly. Nevertheless, with Move having separated from Facebook and completing a new large funding round, they are certainly ready for battle!
Conclusion
Unlike other L2s, Fuel plans to decentralize the sequencer role from the start by designing the VM, eliminating the need for expensive hardware to scale.
Fuel is flexible. It can be deployed in many environments, but its priority is to align as an Optimistic Rollup with Ethereum.
Fuel's user experience will be much better than the EVM, as it adopts native and novel ways to interact with the chain, such as account abstraction, scripts, and predicates.
The contention of the UTXO data model is naturally less than that of the account data model, leading to more parallelism and less state bloat.
