If you want more cryptocurrency analysis, including full-length research reports, trading signals, and social media sentiment analysis, use the code "Publish0x" when subscribing to CryptoEQ.io to make your first month of CryptoEQ just $10! Or simply click the button above!

Fuel is a permissionless optimistic rollup (OR) protocol built on top of Ethereum. However, Fuel has a few critical design differences from existing OR implementations, such as Arbitrum and Optimism, in pursuit of low transaction fees and optimal scalability. Below we outline some of the tech behind Fuel, but to learn more, including the tokenomics and potential vulnerabilities, click here for the full article!

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 for 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 their own VM, Fuel can reach higher maximum throughput, making it faster and more efficient than other chains/rollups.

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 less 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 the 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. 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. 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 (token) 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 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.

Continue reading here for more Fuel tech, economics, and more!