Exploring the FuelVM
Introducing Sway and the FuelVM
Fuel Labs is building a novel execution layer for scaling the next generation of blockchain applications. The FuelVM is designed to be modular — it can plug in as the execution engine for any blockchain. Primarily, the FuelVM will be deployed as a Layer 2 rollup on Ethereum, but in theory, it can be deployed anywhere as an L2 or even as another L1. The FuelVM is designed to scale Ethereum without increasing the node requirements but rather by getting more out of the existing hardware.
Fuel Labs is also building a novel DSL for writing contracts for the FuelVM called Sway. Sway is inspired by both Rust and Solidity to create the ideal smart contract programming language.
What is the FuelVM?
The FuelVM is a fully purpose-built, custom virtual machine for executing smart contracts. Designed from the start to be easily fraud-provable, the Fuel VM can be used as the transaction execution layer for an optimistic rollup.
The FuelVM is optimized to better utilize hardware to increase the throughput of transaction execution. Concretely, it is UTXO based and forces every transaction to explicitly define the UTXOs that it will touch. Since the execution engine can identify exactly what state every transaction touches, it is able to trivially find the transactions that are not contentious and parallelize them.
You can read the full FuelVM spec here or watch John Adler’s video run-through here.
Why does the VM matter?
In a smart contract blockchain system, the VM is the system that can understand smart contract code and execute state transitions based on the rules defined in this code. The VM is the operating system for the smart contract blockchain.
As of today, smart contract VMs have not iterated much beyond the initial versions presented in Ethereum. All widely used smart contract chains (bar Solana) today are using the same VM as Ethereum: the EVM.
In today’s world, the EVM is “good enough” because the main bottleneck of scaling is not the rate at which transactions are executed, but rather the bandwidth that the consensus engine can support (blockspace). With the progression of layer 2 scaling solutions and DA solutions like Celestia, EIP-4844, Danksharding, and EigenDA, the cost of posting rollup transaction data to L1 will no longer be the primary constraint.
In this imminent environment where bandwidth is cheap, the next bottleneck will be computational throughput: how fast a system can execute transactions while keeping the underlying hardware requirements low enough for sufficient decentralization. The FuelVM has the advantage of being designed with these considerations for the future in mind and can optimize accordingly.
FuelVM’s Differentiators
Execution + Validation Parallelization
The secret behind the FuelVM’s parallelizable virtual machine is its strict access lists — which require users (in reality, clients or wallets) to indicate which contract(s) their transaction will touch. It is helpful to inspect what exactly makes up a transaction in the FuelVM.
- Inputs: list of all contract UTXOs that the transaction will touch + data to unlock the UTXO or predicate script.
- Outputs: define the UTXOs that will be created
- Gas Information: gas price + gas limits
- Witnesses: metadata + digital signature for authorization
The critical point here is the explicit “inputs” list, which lists all the UTXOs that will be consumed. This includes “special” contract UTXOs. If, before executing any code, the VM is able to tell which contracts a transaction will touch, it can safely execute all other non-contentious state-accessing transactions in parallel.
Notice that since transaction outputs are explicitly included for validation, in the process of asserting that a block that another node proposed was correct, there is no need to execute 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 the network, they can achieve even greater parallelization and can catch up faster.
Native Asset System
In the EVM, there is one native asset: ETH. All other assets are implemented via a smart contract that handles accounting for balances (ERC20). In Fuel, developers are free to implement assets in smart contracts, BUT, there is an option to allow the VM to handle this natively.
There are a few considerable advantages to native assets over an ERC20-style smart contract for balance management. First, native asset manipulation is cheaper (in terms of gas) than manipulating state in a smart contract. This can be attributed to its running at lower-level primitives (UTXO system is used instead of manipulating storage). Second, native assets have better UX, similar to how sending ETH is much simpler than sending ERC20s (no need for setting approvals).
Native Account Abstraction + Predicates
Account abstraction has been a hot topic of research and several attempts have been made at EIPs (EIP-86, EIP-2938, EIP-3074, EIP-4337, EIP-5003) over the years in the Ethereum community. It is difficult to implement and upgrade Ethereum to support account abstraction primarily because of the engineering bandwidth of core teams/technical debt plus the associated complexity, and a long list of higher priority items. Many rollups have the opportunity to implement account abstraction from the start on their novel execution environments. Among these is the FuelVM, which, in addition to native account abstraction, will also include an interesting new primitive: predicates.
A predicate is a pure (does not access state) contract script that simply returns a boolean (true or false). UTXOs can be locked behind a predicate so they can only be spent whenever the conditions defined in the predicate are met. This leads to an interesting UX opportunity where users can set a transaction to execute only under certain conditions, and then once the predicate is met, their transaction can automatically execute. Also, predicates can be pruned when they are destroyed, so they do not contribute to state bloat.
Trivial demonstrative example: User sets a transaction to buy X tokens whenever the price meets the threshold defined in the predicate. Voila, the pièce de résistance, fully on chain trustless limit orders that won’t bloat the state!
Multi-dimensional Resource Pricing
Resource pricing is one of the most critical components of a smart contract blockchain. Decentralization is maintained by keeping the resource requirements of the chain at reasonable, affordable levels. Resource pricing allows the system to charge users for consuming “work” from the nodes in the network.
In the EVM, one of the most common reasons for the introduction of EIPs has been for opcode re-pricing. This is inherent to the fact that opcodes have hardcoded gas prices, and the underlying price of resources do not scale proportionally to each other (historically, CPUs improve more rapidly than SSDs). Ideally, these systems would be able to price each resource completely independently, so that the entire fee system can dynamically adjust for the underlying hardware system changes.
The FuelVM will be able to implement dynamic multi-resource pricing that can incentivize node runners to optimize their underlying hardware better while still optimizing for the maximum “utility per block.”
This drawing demonstrates a situation where one smart contract has significantly higher demand than others. With localized resource pricing, other contracts are not impacted to the same extent. An NFT drop is a good example of this. This is not exactly how it works with resource pricing vs contract pricing (proposed Solana style), but the effect is very similar. A smart contract with a specific resource profile will be priced differently than another contract. For the NFT drop example, the hot contract might have a resource profile that is very storage intensive but very computationally cheap. Smart contracts that have high compute requirements relative to storage would not be as impacted by the noisy NFT drop.
The Solana strategy of breaking the fee markets on accounts or contracts adds a layer of abstraction between the actual underlying resources and the demand for them. This means that there can still be situations where fees are very low, but the strain on the nodes is very high. For example, there can be an extremely high storage load on the system because of an event where, for example, many different NFTs are being minted simultaneously, but the fees are very low because not all this traffic is happening on a single account. The per-account fee model does solve the hot partition problem for accounts but leaves scenarios where the system is not correctly pricing underlying resources, so it can still lead to failures.
It is simply cleaner and more accurate to price the system based on the underlying hardware resources instead of trying to add a network-specific abstraction layer like accounts to base the multi-market resource pricing on.
State-bloat Considerations
As mentioned multiple times by the geth team, the current bottleneck in geth is with I/O for state read and write access. Initially, the idea was that 100% of the state Merkle-Patricia-trie (MPT) would fit on the RAM of a standard device. This is not the case anymore as the state has grown to over 900 GB and is expected to grow approx 50–100 GB per year, which is unreasonably large for anyone to fit in RAM, so most nodes have turned to SSDs to store state. Historically, SSDs do not improve as quickly as the state size is growing, so this cost will continue to impact the decentralization of the network. This is a critical problem that Ethereum researchers have been discussing for some time.
The FuelVM is instead being constructed with this problem front of mind. There have been a couple of talks by Fuel Labs’ co-founder, John Adler, about the role resource pricing plays in the way that state or other resources are consumed by smart contracts. By a combination of appropriate resource pricing and a more clear data model for state pruning with the UTXO system, the FuelVM will be able to keep the state under control, reducing the cost of running a node, which is equivalent to increasing the decentralization of the network.
Decentralization of the “sequencer”
Although Layer 2s allow us to offload computation effort from the main chain, they still need to provide a mechanism to order transactions. Many layer 2 solutions are launching with what has been referred to as the “sequencer”. The sequencer is a privileged node that is responsible for ordering transactions, executing state transitions, and then submitting the state root update along with compressed transaction information to Layer 1 Ethereum. It is obvious, but notable, that a single super-computer responsible for sequencing can execute more transactions per epoch than a multitude of smaller computers redundantly executing the same sequence of transactions.
There are several key problems with this centralized sequence role that needs to be getting more attention!
- Controlling the ordering of transactions is very profitable. We have observed in Ethereum and other blockchains that MEV is one of the main sources of income for those who order blocks. A single party controlling ordering and MEV capture eventually leads to worse execution for users as we see in traditional finance today.
- A centralized sequencer can be a single point of failure both from an availability and regulatory perspective. If a single or a small number of organizations are running sequencers they can go down or be taken down. This is a liveness risk to the network.
- A centralized sequencer may censor transactions on the Layer 2. The sequencer gets to choose whatever transactions and place them in any order during the construction of a block, this leads to the ability to censor. In fairness, many L2s handle this case by providing “forced transaction” mechanisms, which allow users to bypass the sequencer and directly get transactions included by leveraging the L1.
- Sequencers can make inconsistent promises about the state of the chain to users of the rollup. This is often referred to as equivocation, which basically means that the sequencer can make a misleading promise about some state of the L2. This comes from the fact that fast finality on the rollup is a trusted step, a sequencer can abuse this trust that leads users to do things they do not intend.
How does Fuel solve these problems?
First of all, Fuel is not just a rollup or an L1 blockchain, rather, it is a system that simply applies state transitions that can be posted to an L1 if configured as a rollup or operate in a network to achieve consensus as an L1. The key difference is that the Fuel execution engine does not care about consensus or transaction ordering. Fuel is only responsible for applying the transactions as quickly as possible. But, since Fuel can run on such light hardware and verification is so cheap, it is plausible that Fuel can bootstrap a diverse and decentralized consensus network that does do consensus for much cheaper than an equivalent system running a less performant execution engine like the EVM.
Additionally, the Fuel team is thinking about layer 2 tokenomics with decentralization, MEV, and these other considerations in mind. Fuel co-founder, John Adler, wrote a post on a token model for layer-2 blockchains in January that lays out a design for a token that helps decentralize block production by allowing rollups to tokenize block space scarcity through the right to collect fees as a block producer. Fee collection is only one portion of the income for block producers, as we have seen in other chains, MEV is another large portion of the income. Similarly to block space scarcity, MEV income will also be tokenized via the right to produce blocks.
The 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, whereas the account model is more similar to a bank ledger. Account systems naturally lead to hot pieces of state because every transaction is trying to access the same account, while the UTXO, if designed correctly, is less contentious. This characteristic enables better parallelization and also can prevent state bloat by simplifying the process of state pruning.
Sticking with the cash vs. bank ledger metaphor, it becomes clear why parallelization can tend to be much easier with UTXO. 2 cash transactions can happen at the same time and they don’t need to have any knowledge of each other, while if there were to be 2 account updates on a ledger, both transactions would have to update the same shared ledger.
The VM Wars
Other teams, beyond Fuel, are working on next-generation virtual machines for smart contract blockchains such as Mysten Labs and Aptos, who are working with the MoveVM that was originally designed by engineers at Facebook as part of the Libra project. This further bolsters the thesis that there is demand for novel execution environments in order to support the next generation of blockchain applications. All of these projects have interesting approaches and make different trade-offs.
In the years that the MoveVM sat stagnant when Libra was busy fighting legal battles, a lot changed in the crypto world. Fuel was able to adapt to those changes and stay agile in an extremely fast-paced industry, while Move fell slightly behind. That being said, since Move has spun out of Facebook and new large financing rounds have been completed, they are certainly getting ready to go to war!
Conclusion
- Unlike other L2s, Fuel has plans to decentralize the sequencer role from the start by designing the VM so that expensive hardware is not required to increase scale.
- Fuel is flexible. It can be deployed in many environments, but the priority is to be Ethereum aligned as an Optimistic Rollup.
- Fuel’s UX will be much better than the EVM’s because of native and novel ways of interacting with the chain, such as account abstraction, scripts, and predicates.
- The UTXO data model is naturally less contentious than the account data model and will lead to more parallelism AND less state bloat.
