Fuel Overview

This section of the docs goes over the fundamental technical details of the Fuel rollup chain: what it is, how it works, and why it is scalable and secure.

Background

Fuel is an optimistic rollup, a special sidechain architecture that is both trust-minimized and permissionless. Unlike a traditional sidechain, where the safety of user funds is dependent on the honest majority of some set of validators that is disjoint from the main chain's miners, optimistic rollups borrow security directly from the main chain (Ethereum).

The simplified version of optimistic rollups is as follows. Anyone may construct a rollup block off-chain and submit it to Ethereum as calldata (i.e. simple binary data attached to a transaction). Each block submitted in this manner must build upon the previous rollup block (a contract keeps track of block header hashes for the rollup chain) and include a parametrizable bond. If a block is invalid, a compact fraud proof can be submitted and processed on-chain by anyone, which will roll back the rollup chain to the previous block, burn a portion of the bond, and reward the fraud prover with the rest. After a parametrizable timeout, rollup blocks are finalized, and are considered valid (i.e. can no longer be proven fraudulent) and their bond unlocked. Withdrawals are initiated by burning coins on the rollup, then completing the withdrawal after that rollup block has finalized.

Interacting with Fuel

Fuel node interacting with Ethereum.

Users send Fuel transactions to a Fuel node, which enters the node's mempool as an unconfirmed transaction. The client combines transactions into a Fuel block, which is then sent to Ethereum as calldata, at which point the Fuel block is confirmed. The node also reads deposit events from Ethereum, adding deposits as spendable state elements on Fuel.

Fuel normal (above) and forced (below) transactions.

There are two ways of getting Fuel transactions included in blocks. In the first, under normal operation, the users send transactions to a Fuel node, which then combines them into batches (roots), and finally into a block (which contains several roots). In the second, a user wants to use their own Fuel node to submit a new block, i.e. a forced transaction. In this case, they can create a root and block independently of any other node and submit it to Ethereum directly.

Entering Fuel.

Depositing funds into Fuel is done by simply sending them to the Fuel contract (or optionally through a token funnel), at which point the deposits will be added to the state of the Fuel chain.

Exiting Fuel normally (above) with quickly (below).

Withdrawing funds from Fuel can be done in two ways: standard and fast. For standard withdrawals, a user simply burns their coins on Fuel, then after a delay, can complete the withdrawal on Ethereum. For fast withdrawals, a user contacts a liquidity provider and atomic swaps funds from Fuel to Ethereum in a matter of minutes.

Architecture: A High-Level View

Fuel is unique among Ethereum rollups in that it uses a UTXO-based transaction system. This allows for parallel transaction validation, and in the future stateless predicate validation for spending conditions, greatly increasing scalability compared to contemporary accounts-based blockchains and rollups.

Each transaction can spend up to eight inputs and produce up to eight outputs. This allows atomic multi-user transactions, e.g. for an on-chain atomic exchange, which also means that non-custodial exchanges can be built on top of Fuel. The deterministic and stateless nature of computing state element (UTXO) IDs produced and consumed by transactions enables long chains and even trees of pre-signed transactions to be constructed.

State elements (UTXOs and deposits) can be colored, i.e. represent different assets. This allows transactions to natively handle both ETH and any ERC-20 token.

Fuel supports a number of spending conditions that allow for powerful implicit expressivity:

• HTLC outputs, which have both a hashlock and a timelock. These enable cross-chain atomic swaps (including between Fuel and Ethereum for instant withdrawals). They can also be used as a signaling mechanism (e.g. to vote in a DAO), and when combined with a chain of pre-signed transactions, for cancellable subscriptions.
• Return outputs, which are unspendable and can include a long binary blob. These can be used to build applications that are executed client-side and use Fuel for timestamping messages cheaply.

The fraud proof scheme used by Fuel is unique in that it does not require state serialization (computing the Merkle root of the state) after every transaction, or even after every block. State serialization is one of the biggest bottlenecks for Ethereum and accounts-based rollups today, and remains a Herculean challenge to optimize implementations around. This, along with parallelizable transaction validation, make Fuel the most scalable rollup in the world.

Fuel's block production model is entirely permissionless, and requires no token (and will never require a token). Anyone may start by submitting a root, a bundle of Fuel transactions, to Ethereum. The root can then be included in a Fuel block by anyone, with a small caveat. The Fuel operator has a short period of time (on the order of minutes, a parameter) where they are the only one that can use this root in a block. This allows the operator to reliably provide a soft confirmation to a recipient that a transaction will be included in the next Fuel block. While this is the default and preferred configuration, using an operator is a system parameter that can be disabled trivially on contract creation if soft confirmations aren't needed.

What To Read Next

For a detailed analysis of Fuel's security guarantees, and how it compares to other scaling technologies, see the next page. (Warning: this document assumes a high level of technical proficiency.)

A more in-depth survey of Fuel's components is given here, with block and transaction architecture descriptions also available.

The canonical serialization scheme is defined here.

Finally, the parameters used for deployments across different networks is found here.