The FuelVM introduces a unique primitive blockchain construct called a predicate. A predicate is essentially a new mechanism for authorizing transactions. In Ethereum, the only way to have permission to transfer ether or call a smart contract function is to own the private key of the account that owns that ether or initiates the transaction. The other option is to lock the assets in a smart contract that has some custom authenticate logic (smart contract wallet). The limitation of smart contract wallets in the Ethereum Virtual Machine (EVM) is that all transactions still must be initiated from an externally owned account (EOA). This leads to challenges around the behavior of smart contracts that depend on the transaction sender field (msg.sender != msg.origin).

A predicate is not a smart contract but still allows custom authentication logic for spending coins. This means that predicates can be spent without the need for a private key, unlike any EVM transaction. In practice, this means users can construct predicates that can be spent fully permissionless. When combined with the Fuel concept of scripts, the user experience for interacting with smart contracts becomes supercharged.

What is a Predicate?

On-chain, a predicate looks like an address, much like the Ethereum address we are familiar with 0x123…789. Users can send coins to it, receive coins from it, etc. like Ethereum addresses; however, a predicate is not derived from a private key. Rather, the address of a predicate is derived from the hash of its bytecode.

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, there is no interaction with the chain. Since the hash is both deterministic and collision-resistant, the coins locked in this address can only ever be spent if the predicate conditions are met. To spend a predicate, someone would provide the predicate bytecode (which must match the hash/address that the coins are behind) and a transaction that has the predicate resolve to true.

Critically, a predicate can only access the data in a transaction, it cannot view the current chain state. Allowing a predicate to access the chain state can create a denial-of-service (DoS) vector because one transaction can evaluate conflicting results (both true and false) depending on the state of the blockchain that is flip-flopping underneath it. In order to avoid this, predicates must be deterministic and pure (not read state). In order to prevent DoS, a node cannot do work on behalf of a client unless the client compensates them (the transaction is valid and gas is paid) or the client can be blocked because the request was intentionally malicious (transaction is invalid and gas cannot be paid).

To access the coins sent to a predicate, users just need to provide a transaction that will have this predicate evaluate as true. Notably, anybody can theoretically provide this transaction as long as they are able to construct the transaction that will evaluate to true.

Power of Predicates

The reason predicates are so powerful is that they can work in great tandem with two other key FuelVM features. One, the fact that transactions explicitly define all inputs and outputs, and second, the ability of the VM to inspect the full transaction data. This means that a predicate can inspect exactly what a transaction is going to do before it even executes the transaction.

In practice, this allows the predicate to check things like which smart contract will the transaction interact with and which accounts will receive coins. This leads to an extremely expressive authentication engine.

By Example -- Predicate OTC Swap

First off, a swap is just 2 simple token transfers. Why is this complicated? Let’s use a classic pattern in computer science to understand how a swap actually works. We know that in order to swap two variables it is required to create a temporary variable. This is the same when trying to swap tokens.

fn swap(a, b) {
    let temp = a;
    a = b;
    b = temp;
}

Directly transferring coins to another person without a temporary “escrow” leaves the opportunity for the other participant to walk away without transferring their side of the trade.

Instead, the non-atomic swap can be made atomic, trustlessly, using the predicate to coordinate. The predicate just needs to define the condition in which the taker can spend the coins. So, the maker would create a predicate with a spending condition that guarantees that the output coin that they are expecting is an output to the spending transaction and they are the receiver. This means that nobody can spend the predicate unless they send the correct coins to the maker. Once the maker defines this predicate, the static bytecode for the predicate is hashed, and the maker can transfer the coins to this hash.

The expressiveness of this predicate is not limited here. Theoretically, the maker can add any conditions they want to the predicate. For example, they can leave an escape hatch condition that allows them to cancel the swap and transfer the coins back to their own account (this prevents the free option problem that was heavily explored in HTLCs).

More Predicates in Practice

Let’s explore what else can we do with the power of predicates.

Enforce that coin transfer update a smart contract

Only allow coins to be spent if they will also update some state on a smart contract. With this system, users can maintain on-chain state about historical asset holdings. This is useful, for example, in a voting token where users want to snapshot balances at a block height.

Virtual atomic bundles by script locking

It is possible in a predicate to enforce that a predicate can only be spent if the transaction is constructed by a specific script bytecode. This script bytecode can include several unrelated transactions, but guarantees that the coins can only be spent if the full script is executed.

Script locking actually unlocks a lot of very interesting UX patterns where users can tie the behavior of several different contracts or assets together by binding them in the predicate spending conditions.

Off-chain fraud monitoring

Users can lock their coins behind a predicate that can only be spent if a centralized fraud monitoring entity also signs off on it. This brings money transfer UX more like a credit card or bank in traditional finance. Obviously, users can give themselves the power to override, because they are still the owner of the coins.

Transaction automation

Since predicates can be constructed in a way that anyone can execute them, it would be trivial to automate transactions based on time or conditions. The predicate itself can include a bounty in its logic for some relayer to take if they execute the on-chain task on user’s behalf.

Trust-less order flow markets

Using the predicate hash as a way to obscure an order, users can guarantee that only a block builder that knows that predicate hash 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.

Conclusion

Account abstraction has been a topic at the forefront of discussion within the Ethereum world since the chain itself launched. Due to prioritization and technical migration complexity, we have not seen any major changes in production to date. New execution layers, such as layer 2s, present the opportunity for innovation on account abstraction without any dependency on the Ethereum core protocol. Fuel’s predicate design is the result of years of learning from both the Bitcoin and Ethereum communities and offers perhaps the most expressive and rigorously designed way to achieve full account abstraction and much more.

For a more high-level overview of the other unique properties of the FuelVM see my previous post.

Disclaimer: Blockchain Capital is an investor in Fuel Labs.

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!

1. 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.

2. 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.

3. 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.

4. 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.