Ethereum continues to dominate the web3 area in many aspects even if it operates in a market where new L1s are becoming more and more common. It has a sizeable development and user base, a clear path for scaling on the consensus & data availability layer, and a ton of liquidity. As proven by the numerous rollups and L2 scaling solutions based on Ethereum, there is unquestionably a lot of value to be gained by constructing inside the current Ethereum ecosystem.
But at the same time, there is a growing narrative that the EVM and Solidity are becoming less important. EVM compatibility is no longer a make-or-break feature when it comes to new blockchains - even ones building on top of Ethereum.
The consensus & data availability layer's constrained bandwidth, not the speed at which transactions are executed, is currently the fundamental barrier to scaling. The EVM's delayed transaction processing capabilities are "good enough" in this situation since they still exceed the bandwidth that Ethereum can offer. Modular blockchains could be the key to a whole new world of crypto. A modular blockchain focuses on only a few functions and offloads the rest to separate layers - it allows for better specialisation and optimisation of specific tasks.
Fuel was designed to address scaling Ethereum by transcending the EVM. Current L2s and rollups are primarily designed for monolithic blockchain stacks, meaning they are typically not optimised for large amounts of L1 bandwidth potential. Fuel is uniquely configured to handle this potential. By adopting new and improved Virtual Machine (VM) design principles, modular execution layers like Fuel can specifically optimise for efficient & scalable computation.
Figure 1 - Fuel’s modular configuration for scaling.
The main distinction between Fuel and the current crop of optimistic rollups is that FuelVM, the new VM architecture it uses together with its toolchain and language have present aspects of WASM, EVM, and Solana's SeaLevel. The fact that FuelVM operates over a UTXO-based data architecture may be its most notable feature.
You're not entirely incorrect if your first thought when you hear about UTXOs is P2P payments. Fuel's initial use case revolved around payments. Since 2020, it has been operational on the Ethereum mainnet and it remains the only rollup that offers immutable smart contracts, fraud proofs, and permissionless block generation. But Fuel V2, which guarantees smart contracts on UTXOs in the Ethereum paradigm, is what intrigues us—and perhaps you as well! What really is an UTXO model?
In Bitcoin, the state is represented as a series of UTXOs, where each UTXO stands for a different state element. Since Bitcoin is mostly used for payments, the state only establishes who may possess how many bitcoin. State elements, also known as UTXOs, are hence currencies with a specific balance and spending requirement.
Figure 2 - Several Inputs and Outputs are enabled in each transaction, as a result of using a UTXO-based transaction model.
Similar to Bitcoin, in Fuel V2 the entire state is represented as a UTXO set. The difference is that some of these UTXOs are coin UTXOs and others are contract UTXOs. In addition to a balance and spending condition, contract UTXOs have a code, storage, and a unique contract ID. As a result of this, it allows Fuel to conduct atomic multi-user transactions, which unlocks a new world of possibilities for dApps on top of Fuel. That is, transactions consume the contracts in their entirety and create new ones. Each input in a UTXO-based system is only produced and consumed once, which means that the rollups chain’s state is stored as a key-value. Since computing state elements with UTXO IDs is deterministic and stateless, once consumed, it allows for long chains and ‘trees’ of pre-signed transactions as well.
As a result of the state database only needing to be checked for the existence of consumed elements, it allows for interesting possibilities and interactions between users and transactions.
Solana played a major role in popularising parallel transaction execution processing through the Sealevel runtime, which distributes incoming transactions over many cores so they don't alter the same state in the virtual machine's memory. This is due to the fact that Solana transactions, like UTXOs, define every state that a transaction will read or write while it is being conducted, allowing for parallel processing. Like Ethereum, Solana is account-based. Contrary to Ethereum, each node makes sure that the accounts that are accessed several times are only shown once, sequentially.
So how does this help a rollup like Fuel? It achieves this because it can use the UTXO architecture to do transactions concurrently. As a result, Fuel is able to utilise more CPU threads and cores than are typically available in single-threaded blockchains. Fuel can therefore offer more computation and transaction throughput than other Ethereum rollups.
Knowing what portion of the state transactions will alter before they are executed is key to parallelisation. This is known as access lists. Random access lists are now a part of EVM transactions. Since it is impossible to determine whether two transactions are accessing the same state element, a single-threaded process must be used to carry out each transaction one at a time. It is a waste of resources if your CPU has 8 cores and 7 of them are idle.