Technology

Fuel is a type of optimistic rollup, meaning that instead of providing its own security through fresh validators like sidechains, Fuel obtains its on-chain security directly from mainnet Ethereum.

As a quick reminder, at its core, an optimistic rollup chain is simply a smart contract on mainnet Ethereum. An OR moves the heavy computation and data storage that would be normally executed on L1 Ethereum off-chain to a new rollup network. Only a small portion of each batch of transactions is ultimately recorded on the mainnet, creating a much smaller computational impact on the L1. Since only one small data portion is registered on L1 and the majority of computation is handled off-chain, fees can be greatly reduced (compared to if the entirety of the transactions were executed on L1).

By default, Optimistic rollups “optimistically” assume all transactions are valid. However, that’s not always the case. To combat this seemingly reckless optimism, checks and balances are put into place. There’s a period of time after withdrawals where anyone can identify and dispute transactions they believe are incorrect or fraudulent. If the whistleblower can mathematically prove fraud occurred by submitting the correct fraud proof, the rollup will revert the fraudulent transactions, penalize the fraud, and even reward the watcher.

In Fuel’s case, transactions are sent to L1 Ethereum as a calldata rollup block with a parameterizable bond. This bond acts as the insurance on the block. If the block is invalid, a portion of the bond is burned, with the rest going to the validator proving it was invalid.

This ensures that Fuel’s blockchain network remains validated and directly punishes those that attempt to submit falsified or fraudulent blocks. Optimistic rollups like Fuel actively help scale Ethereum’s throughput because of this security model. Fuel benefits from the added robust security of the Ethereum network, and Ethereum benefits from improved throughput due to the layer-2 transactions not adding to the demand for Ethereum block space.

Fuel Virtual Machine

Fuel distinguishes itself from other rollups by utilizing its very own virtual machine (VM), called FuelVM, rather than the Ethereum Virtual Machine (EVM). A typical VM can interact with smart contracts and generally describes the rules for modifying blocks on a network.

For Ethereum, the EVM is a software-based computing environment (consisting of Ethereum clients) that replicates the capabilities of a single computer but can be globally accessed. Any entity participating in the Ethereum network must run the EVM to compute state transitions. If all nodes run the same EVM (same rules), all nodes are aware of global state changes. The EVM updates the global state (transactions, wallets, smart contracts, etc.) with each block, ensuring network consensus.

Ethereum virtual machine diagram. Source: Twitter/LuozhuZhang

For builders utilizing the EVM, composability means they can leverage one or more of the following:

Ethereum's Social Graph: addresses are the same across EVM chains, meaning that any new project or chain can leverage the metadata associated with a user/address to solve cold-start problems
Tooling and infrastructure: Some tools include Gnosis Safe, WalletConnect, Zerion, Metamask, and Etherscan. There are many open-source toolkits like OpenZeppelin, Hardhat, and Foundry.
Interoperability: Cross-chain governance, ERC-20 token trading identical address system, etc.

Because Fuel is using its very own VM, this means that Fuel is not actually EVM compatible and cannot leverage these advantages. Therefore, the compatibility between it and Ethereum is not as strong/frictionless as other rollups.

Therefore, it stands to reason that Fuel must have very good reasons for abandoning the uber-popular EVM standard and building their own VM, right? If you ask the Fuel team, yes.

While the EVM has inarguable network effects, it is not optimized for rollups. This is because the EVM was created long before rollups were invented. Since then, small changes to the EVM can add big benefits. One example is optimizing how rollup data is posted to the L1. Currently, rollups post their batched transactions as calldata to the L1. This is extremely inefficient and constitutes nearly 90% of the rollup fees. Optimizing this, as Ethereum plans to do in the future with EIP-4844, can reduce rollup fees by ~10x. By using its own VM, Fuel can reach higher maximum throughput, making it faster and more efficient than other chains/rollups.

The FuelVM supports a variety of program types, including smart contracts, scripts, libraries, and predicates, which offer unique advantages over traditional EVM interactions. By allowing multiple contracts to be called within a single transaction using a script, FuelVM efficiently manages UTXO spending conditions with predicates. These predicates determine transaction validity by evaluating to either True or False, enabling cost and fee prediction without arbitrary gas variable ordering.

UTXO and predicate usage minimizes state growth and introduces account abstraction (AA), addressing state bloat issues that can impact blockchain performance and lead to centralization. As scripts and predicates don't store data like smart contracts, they don't contribute to state growth, enabling sustainable growth and user activity for Fuel. Native multisigs in FuelVM allow for more efficient group transactions without storing state on-chain.

Account abstraction via predicates enables programmable transaction validation, with Fuel implementing stateless account abstraction to prevent state bloat. This feature allows developers to create custom verification schemes at the application level, offering use cases such as social recovery, transaction fee subsidization, and wallet compatibility with various signature schemes. While Ethereum is working towards incorporating AA, Fuel's ability to program based on outputs sets it apart, enhancing flexibility and efficiency.

Additionally, nearly all dapps in Ethereum are written in Solidity, while the FuelVM uses its own programming language called Sway. Sway is a domain-specific language that is based on the well-known Rust programming language and is utilized on Fuel to write smart contracts.

Solidity is designed to compile down to Ethereum Virtual Machine (EVM) bytecode. However, Solidity has its problems, and other languages like Vyper and Scilla for coding more secure and auditable smart contracts are on the rise. Despite this, Solidity’s syntactic similarity to JavaScript – one of the most popular programming languages in the world – affords it the unique advantage of having a less prohibitive learning curve compared to other languages.

Ethereum virtual machine layer. Source: Medium/ChainLinkGod

Transactions and Data Availability

On the Fuel rollup chain, transactions are executed and transmitted to a Fuel node, "rolled up" into a batched block, and then submitted for confirmation to the Ethereum L1 network. However, Fuel is “modular” in the sense that it doesn’t have to use Ethereum as the Data Availability (DA) layer. It can use alternatives such as Celestia and Polygon’s Avail to save even further on costs.

A Fuel Network node interacting with Ethereum

As a reminder, full nodes download and validate every transaction that has ever occurred on the chain since its genesis. Light nodes (typically) only check block headers. This means light clients are “lightweight” nodes that require fewer computing resources than a full node. This makes them more egalitarian because they are cheaper and typically easier to run, helping to further decentralize the network.

However, light clients assume transactions/state changes are valid by default and follow whatever the majority commits to as a valid transaction (rather than verifying for itself). They rely on fault proofs supplied by full nodes for transaction validation. This enables light clients to independently and accurately detect erroneous transactions, providing nearly the same security assurances as a full node.

A light client can contest the authenticity of states by getting fault proofs. When a node's state is contested by a fault-proof, consensus is reached by a full node re-executing the appropriate transactions, resulting in the dishonest node's stake being reduced.

Data availability is critical in this regard because as long as all the execution data is made available on the mainnet, the chain does not require every node to execute every transaction in order to validate transactions and reach consensus.

Because rollups can cryptographically guarantee (via a proof) that the transactions are valid, these transactions can now be executed by just a single node and posted to the L1, where it can be cross-checked by L1 nodes. All L1 nodes download the rollup’s data but only a certain portion of them execute the transactions/construct the rollup state, thereby reducing overall resource consumption. Additionally, the data within a batch is highly compressed prior to being submitted to the L1, further decreasing the resource burden. This is how rollups help trustlessly scale a blockchain without requiring an increase in node resources.

However, a rollup’s TPS is dependent on the data capacity of their L1 for throughput. The more data capacity on L1, the higher the (theoretical) throughput for rollups. Once an L1 runs out of data capacity for the rollup, the limit has been reached and no additional transactions can be processed. Therefore, now the limiting factor for a blockchain’s scalability is its data availability.

UTXO Transaction System

Fuel employs a UTXO-based transaction system that is similar to Bitcoin’s. Doing so enables Fuel to validate multiple transactions in parallel rather than one at a time, greatly improving its transactional scalability. Transactions can include up to eight inputs and outputs, allowing for multi-user transactions and far greater scalability. Utilizing Unspent Transaction Outputs (UTXOs) facilitates concurrent order execution, allowing for the simultaneous processing of independent orders across several CPU threads.

To achieve parallelism, FuelVM employs access lists. This means each transaction must specify the contracts it could potentially interact with, preventing the concurrent execution of transactions that impact the same contract. The resulting parallelization significantly boosts throughput in contrast to transaction ordering, which contributes to EVM inefficiency.

As the EVM maintains a global state, various actors can engage with its smart contracts. However, with UTXOs, a concurrency issue may arise, as a UTXO and its corresponding smart contract can only be utilized once. This creates a bottleneck, as multiple users typically need to interact with a single smart contract simultaneously, but concurrency restrictions prevent this from happening.

Fuel circumvents this problem by employing contract UTXOs. Users provide contract IDs for the contracts they plan to interact with instead of UTXO IDs. This allows block producers to determine which UTXO a transaction will use and the subsequent state of the related contract. Each transaction consumes the contract UTXO, and a new one with an updated state is generated.

Fuel supports both HTLC and Return outputs to occur. HTLC outputs enable cross-chain atomic swaps. Return outputs cannot be spent and can be utilized for timestamping messages.

Visualizing fuel transactions. Source: Delphi Digital — Visualizing fuel transactions. Contract UTXO represents the state of the contract at a point in time. Source: Delphi Digital

Fuel's block structure is similar to other UTXO models. Blocks contain a typical header that includes the following information:

Block Producer
Previous Block Hash
Block Height
Block Number
Max Token ID
Address ID
List of Roots
Root Length

A key differentiator here is that addresses can be registered to avoid utilizing the full address and instead relying on a shorter, faster numerical ID. This potentially creates an attack vector but otherwise makes transacting more efficient overall. Blocks also contain a root header where the list of transactions can be expressed in two ways:

As a Merkle root
As a simple hash function

Transactions themselves utilize the general laws of UTXO systems as each state transaction can only be produced or utilized a single time. This prevents double-spending attacks. Inputs tell which state elements (tokens) to unlock and spend, while outputs are the new state elements that are created after. Fuel uses a system of inputs, metadata, and witnesses (digital signatures or authorizations) to validate and complete transactions on the network.

A flowchart of witnesses' role in Fuel Network's transactions — A flowchart of segregated witnesses' role in Fuel Network's transactions. Source: Fuel Network

Witnesses on Fuel can be both normal and segregated witnesses. Normal witnesses are necessary to authorize a transaction on the blockchain. Segregated witnesses are separated from other transaction data. Not bundling witness data with inputs lowers the overall load and allows for each input to create a witness index. This index allows multiple inputs to use the same witness, increasing the scalability of the transaction throughput but reducing overall costs for consumers.

Economics

A key principle of blockchain economics is centered around the demand for block space. On Ethereum, block space is in very high demand, which results in higher gas fees to be included in a block. If a user pays more for gas, that user is prioritized. This dictates transaction speeds on a network. Fuel being a layer-2 blockchain network, also faces these challenges.

The fees associated with transacting on Fuel are calculated through two traits:

Transaction Size (in bytes)
USD Value Target per byte

The projected average transaction cost is expected to range between $0.01 and $0.03.

Fuel plans to leverage its economic model by utilizing rollup scarcity (i.e., block space). By tokenizing the scarcity of block space, nodes can bond tokens in order to receive fees associated with producing blocks. Higher demand leads to higher fees, which coincides with a greater demand to run a node. The difference here between Fuel and Ethereum is found with the end user. As demand on Ethereum’s blockchain rises, fees for users also rise. On Fuel, users do not need the bonded token to utilize the rollup, so, therefore, increasing block demand does not hurt the users.

With this model, Fuel does not need a fee-paying token like ETH. Token holders will retain the rights to collect fees as a block producer, so demand for the token is directly related to the demand for the rollup. Therefore, there is not only a utility for the token (produce blocks) but a market behind it as well.

There is also no need for a governance token in the ecosystem. Rather than use a governance token and risk centralized control, the bonded token can be utilized for leader selection. In other words, the token operates on a leader selection algorithm which dictates who is permitted to progress the chain by producing a new block.

Fuel Value Proposition

Based on the mechanics and economic design of Fuel, it is trying to accomplish one major objective: making the movement of tokens faster & cheaper. This is a major problem with scalability in stablecoin use cases. On Ethereum, there is a tremendous amount of demand surrounding the movement of funds to & from exchanges.

Fuel will be able to handle large payment volumes without disrupting the end user. Based on the estimates for transaction prices on Ethereum, fees for users could be substantially lower than on mainnet Ethereum. This accomplishes two major things:

It removes Ethereum congestion caused by ERC-20 token transfers
it can increase the maximum transaction throughput of Ethereum altogether

Depending on the volume of transactions that Fuel can support, the platform has theorized it could raise the transaction per second (TPS) capabilities of Ethereum by a factor of five, up from 10 TPS to 50 TPS. Ethereum’s major problem is related to state size, which is estimated to exceed 35 GB. State is a large data structure for Ethereum that hosts all accounts and balances as well as a machine state.

Fuel will be able to offload some of that state demand and significantly reduce the gas costs of moving ERC-20 tokens. So, Ethereum frees up space and increases transaction throughput, while Fuel sees higher demand for rights to produce blocks on the network.

SwaySwap and Non-Custodial Exchanges

Fuel can support much faster non-custodial and decentralized exchanges on its network due to the efficiencies of the optimistic rollup design. Currently, there is a live demo of a non-custodial exchange called SwaySwap live now.

SwaySwap has a commonly seen DEX interface, fast finality speeds, and low costs. Users can seamlessly swap tokens (in this case, ETH and DAI) using the swap tool or stake capital in the DEX pool. While not actually active, what it does do is display the potential user experience of a fully operational DEX on Fuel that can take advantage of the transaction throughput and low gas fees (about $0.03 on average so far).

Fuel Network's SwaySwap liquidity pool user interface

Vulnerabilities

Fuel at the moment is a bit unproven in terms of true functionality as it is still being developed. Apart from that, there are some general drawbacks with certain designs, along with the typical potential vulnerabilities seen with similar UTXO chains. To begin, it must be acknowledged that the true level of TPS Fuel can achieve is unknown. Right now, the network is still in its infancy, as it has no usable applications. The closest usability is found in the SwaySwap demo.

Fuel user interface — Fuel Network block explorer. Source: Mainnet

Another thing to note with Fuel is it potentially lacks the compatibility and advantages associated with being an EVM. Not to mention, Fuel has its own steep learning curve as developers will be required to utilize the Sway programming language to create applications on top of Fuel. Another disadvantage with Fuel compared to other optimistic rollup layer-2 technologies is the lack of instant finality of transactions. Blocks only become valid for Fuel when they are committed to Ethereum, so finality can end up being longer for on-chain transactions.

In terms of attack vectors, Fuel could theoretically fall victim to an attack based on its transaction register ID design. Someone could craft blocks with transactions that do not have an ID and theoretically push them through with a front-run confirmed ID. Fuel has taken measures to prevent this through more intricate security checks surrounding ID identification, but until the network experiences real activity, it is impossible to gauge the effectiveness of this.

Wallets and User Experience

In order to get involved with the Fuel protocol prior to its full release, users will need to download a wallet and obtain testnet ETH.

Visit https://faucet-beta-2.fuel.network and enter the wallet address you obtained previously. Provide the required information and select 'GIVE ME ETHER.' Be aware that it may take some time for the ETH to be transferred to your wallet.

Loading...