With the development of Layer 2 and Rollups, Ethereum’s ecosystem is shifting towards modular architecture. One of the biggest obstacles to the mass adoption of blockchain technology is scalability. Layer 1 scaling solutions focus on block production rather than block verification. Modular blockchain infrastructure aims to promote the adoption of Web3 with scalability, security, and decentralization features, and focuses on easy integration, rapid delivery, and user experience. Modular blockchains are becoming the most discussed topic, where modularization means dividing the consensus layer, data availability layer (DA), settlement layer, transaction execution layer, etc. among different chains, rather than having one chain handle all modules. The execution layer can exist as its own blockchain or use the underlying blockchain to ensure validity and data availability. In general, these three layers have already existed, but they are coupled in the Ethereum network without clear boundaries and division of labor. The purpose of modular blockchains is to decouple these layers and handle privacy security, node validation, transaction confirmation, data storage, and fraud proof functions separately in the technical environment of Layer 2 applications, thereby achieving on-chain scalability. The Rise of Modular Narrative The “impossible triangle” of blockchain technology has always been a problem for developers and users, and Layer2 solutions have been designed to solve this core problem. Specifically, the Layer2 approach involves moving the computation and processing of data to the second layer network of Ethereum, while the first layer network is mainly responsible for security, i.e., consensus. It is worth noting that modular public chains are mainly proposed as a solution for Ethereum upgrade, and their narrative logic revolves around Ethereum. However, other on-chain projects are currently referencing this for performance improvement. Modular public chains aim to divide the system into multiple modular components, giving it blockchain characteristics and even sub-functions such as DEX, stable coins, NFTs, and derivatives. Developers can extract these new modules, order and combine them arbitrarily to achieve more advanced functionalities. It wasn’t until the second half of last year that modular public chains were mentioned again, as Ethereum’s Layer2 solutions began to rise, and Layer2 is an important foundation and prerequisite for implementing modular public chains.

Competition among Modular Execution Layers

The Ethereum ecosystem has achieved scalability, security, and interoperability by separating the execution layer from the underlying blockchain through technologies such as Layer 2 and Rollup. Currently, there are several modular public chain execution layer projects that focus on providing a data availability layer, such as Celestia, LazyLedger, and DataShards; some that focus on providing an execution layer, such as Optimism, Arbitrum, and zkSync3; and others that focus on providing cross-chain bridging and protocol aggregation, such as Polygon, Connext, and Hop Protocol. They are all actively developing and deploying their own solutions, and collaborating with various decentralized applications to enhance user experience and network efficiency. There is a certain degree of competition and cooperation among these modular public chain execution layer projects because they all face common challenges and opportunities, and our evaluation dimensions should always revolve around security, scalability, interoperability, and cost-effectiveness. The author summarises the following typical categories of projects:

• Projects based on Optimistic Rollup, such as Optimism and Arbitrum. These projects use fraud-proof mechanisms to ensure the effectiveness of the execution layer, while providing high-speed parallel transaction execution and low-latency confirmation time.
• Projects based on ZK Rollup, such as zkSync, StarkNet, Hermez, Scroll, Taiko, and Aztec. These projects use zero-knowledge proof technology to ensure the effectiveness of the execution layer, while providing high compression ratio and privacy protection.
• Projects based on Plasma, such as Polygon Plasma, OMG Network, and Matic Network. These projects use side chains and exit mechanisms to expand the throughput of the execution layer, while providing compatibility and interoperability with Ethereum.
• Projects based on cross-chain bridging, such as Connext and Hop Protocol. These projects use multi-signature or relay nodes to transfer assets and data to different execution layers or underlying blockchains, while providing flexible protocol aggregation and route selection.

Public blockchain: a significant boost in speed

Modular blockchain architecture breaks down the blockchain’s functionality into different layers, such as the execution layer, security layer, and data availability layer. This can increase the efficiency, flexibility, and interoperability of the blockchain. Parallel transaction-class products can execute transactions in parallel and ensure the validity of transactions through various verification mechanisms. This can increase the blockchain’s processing power, throughput, and confirmation speed. They can support more tokens and smart contracts, allowing users to transfer assets between different blockchains, expanding the blockchain’s use cases, such as DeFi, NFTs, and Web3. Arbitrum is a classic execution layer solution based on Optimistic Rollup technology that can implement efficient, low-cost, and highly compatible smart contracts on Ethereum. Arbitrum can use arbitrary data technology to increase transaction throughput and confirmation speed. Meanwhile, StarkNet is an execution layer platform based on ZK-Rollup technology that can implement scalable, secure, and privacy-protected decentralized applications on Ethereum. StarkNet can use zero-knowledge proof technology to ensure transaction validity and data availability. These two approaches currently dominate the execution layer technology route. However, parallel processing requires a strict list of state accesses to ensure that transactions do not interfere with each other. At the same time, modular blockchain relies on other layers to provide security, consensus, and data availability, which may increase complexity and cost. Additionally, parallel processing may reduce transaction confirmation speed because all parallel branches need to complete before the entire block can be confirmed. In response to these issues, Fuel, an execution layer protocol based on the UTXO model, can run on different blockchains. Fuel can execute transactions in parallel and enable asset transfers between different blockchains through optimised optimistic yanking technology. Fuel uses a virtual machine called FuelVM, which can quickly verify transactions and blocks and supports multiple tokens and smart contracts. Fuel uses a technology called Optimistic Yanking, which allows users to transfer assets between different blockchains without waiting for long confirmation times or paying high fees.

Fuel: Parallel Transactions on the Execution Layer

Fuel is the earliest Optimistic Rollup deployed on the Ethereum mainnet, with its V1 version launched at the end of 2020. It provides scalability by using a different execution model from EVM, namely, a highly parallelisable minimal execution system based on the UTXO model, supporting ETH and all ERC-20 tokens. However, due to the low user adoption of Fuel V1 and the lack of support for smart contracts, it did not receive much attention from users. After the launch of Fuel V1, Fuel Labs, the development team of Fuel, quickly shifted all development efforts to V2 and positioned it as a modular execution layer, a verifiable computation system designed for modular blockchain stacks. Fuel’s main feature is its use of a new VM architecture, FuelVM, which comes with its toolchain and language. FuelVM draws on the characteristics of WASM, EVM, and Solana’s SeaLevel, and its most notable potential lies in its execution on the UTXO-based data model. Compared to today’s Optimistic Rollups, Fuel’s biggest difference is its use of the UTXO-based data model, with its first version designed for P2P payments. Fuel V2 is expected to achieve smart contract functionality similar to Ethereum, with the VM designed for application-specific payment Rollups, a custom VM that provides more inference convenience, but not as obvious for general Rollups like Ethereum. The technology stack of FuelV2 has three core pillars:

FuelVM

FuelVM aims to reduce waste in traditional blockchain virtual machine architecture while increasing potential design space for developers. Fuel uses a UTXO data model, similar to Bitcoin, where the entire state is represented in the form of a UTXO set. The difference is that some UTXOs in Fuel V2 are token UTXOs, while others are contract UTXOs. Unlike token UTXOs, contract UTXOs have code, storage, and a unique contract ID in addition to the balance and spending conditions. A significant feature of UTXOs is that they are atomic, meaning transactions consume them entirely and create new UTXOs. For contract UTXOs, Fuel defines some new validity rules. Important rules include: contract UTXOs are locked behind spending conditions that anyone can consume; when a transaction consumes a contract UTXO, it creates a new contract UTXO with the same spending conditions and contract ID but may have new storage and balance; contract UTXOs used in the same transaction can interact with each other. The advantage of Fuel is that the UTXO model allows Fuel’s blockchain to process transactions more quickly and efficiently. However, its disadvantage lies in the technical difficulty of implementing the UTXO model, which requires more code than the account model implementation. Additionally, as the UTXO model is not well-suited for smart contracts, using contract UTXOs requires following new validity rules, which require technical knowledge and experience. Nevertheless, Fuel continues to evolve and improve, and it is expected to achieve more functionality and application scenarios in the future.

Parallel transaction execution

Fuel uses a strict state access list in the form of a UTXO model, giving it the ability to execute transactions in parallel and providing advantages in computation, state access, and transaction throughput. Fuel is a blockchain based on the UTXO model, and its biggest advantage is the ability to execute transactions in parallel, something that many other blockchains lack. The core of this technology is to determine the part of the state that a transaction will modify through the access list, thus achieving parallel execution. This means that if the UTXOs spent in a transaction do not overlap, they can be executed separately, fully utilising the performance of multi-core CPUs. This technology is not only applicable to transactions within a block but can also be executed across blocks, making the synchronisation speed of nodes entering (or re-entering) the network faster. In contrast, blockchain based on an account model can also achieve parallel execution, but requires more considerations such as strict access list regulations. Meanwhile, single-core performance is no longer sufficient to meet the demand, and the use of multi-core CPUs is becoming more and more common, with the multiplication effect of multi-core processing being beneficial for improving execution efficiency. Therefore, Fuel’s parallel execution technology will become increasingly important in the future.

Developer experience

Fuel uses its own specific domain language, Sway, and supporting toolchain, Forc, to provide a powerful and smooth developer experience. The development environment retains the advantages of smart contract languages such as Solidity while adopting paradigms introduced by the Rust tool ecosystem and including syntax that utilizes the blockchain VM. To address the problem of state growth, FuelVM uses two programs - scripts and predicates - to enhance Turing-complete smart contracts. Unlike the EVM, FuelVM users do not directly call contracts but instead run scripts to call multiple contracts. The beauty of scripts is that they are prunable and once executed, they are completely pruned without any impact on the state. Predicates are similar to scripts, but do not read contract storage during execution and are completely stateless. The main purpose of scripts and predicates is to turn FuelVM into a semi-stateless execution. In FuelVM, applications can be more inclined to state or execution based on the function and resource prices of the application. Additionally, Fuel also supports various complex applications, such as support for multiple local assets, authorisation and transfer in a single transaction, mixers, and privacy applications, providing great flexibility.

The Road to Modular Execution Layer

The main value proposition of Rollups today is to scale Ethereum and extend its capabilities where possible. Rollups achieve this in two ways: 1) by moving state (and execution) off-chain, i.e., from L1 to L2, and 2) through parallel computation, i.e., multiple Rollups can run simultaneously on Ethereum. Rollups alleviate the problem of Ethereum state growth by moving some of the state off-chain, but this doesn’t magically eliminate the need to maintain the state. While Ethereum nodes do not need to maintain it, Rollup nodes are required to do so. Currently, there isn’t much focus on state optimisation in the Rollup space. Instead, most of the focus is on reducing L1 data because it is the most expensive cost item for Rollups. About 2/3 of Arbitrum’s fees exist in the form of L1 calldata. EVM Rollup optimises the data published to L1, attempting to compress it as much as possible to provide users with cheaper fees. What we haven’t considered is that costs will change dramatically in the modular era. With the underlying layer starting to provide a lot of data (thanks to data availability sampling techniques), Rollups will soon enjoy data at an order of magnitude cheaper. At the same time, since less attention is paid to state growth, state size will quickly become a major bottleneck in the modular world. Any blockchain, whether Rollup or L1, incurs permanent costs to the network for operations that increase state. These operations not only consume resources for current nodes but also for all future nodes.

Currently, Fuel has successfully built several demonstration use cases, such as AMMs, multi-signature, oracle, and DAO voting. In the future, the Fuel team plans to build demonstration use cases for other products, such as lending, NFT markets, etc. While the UTXO-based execution method may be counterintuitive, I believe Fuel’s unique capabilities will foster new applications and push the limits of the current DeFi space. Overall, I am excited about the potential that Fuel brings to the modular stack. The data availability layer can expand data, but to achieve a fully decentralized user experience, we also need to expand execution. Fuel is expected to fill this gap. From our assessment perspective, Fuel’s security is provided by the Ethereum mainnet, which means that Fuel does not need its own validators or consensus mechanism and is not at risk of attack or fork. However, this also means that Fuel depends on the security and stability of Ethereum, and if Ethereum experiences a malfunction or upgrade, it may affect Fuel’s operation. Fuel’s scalability is achieved through its efficient transaction format and low confirmation time, allowing Fuel to process thousands of transactions per second and complete transaction confirmations within seconds. However, this also means that Fuel needs to compete for resources and users with other rollup chains, and if other rollup chains provide higher throughput or lower latency, it may affect Fuel’s attractiveness. Fuel’s interoperability is achieved through its cross-chain transfer function and multi-token support, allowing Fuel to be compatible and interoperable with Layer 1 and Layer 2 networks such as Ethereum, Arbitrum, Optimism, Polygon, etc. However, this also means that Fuel needs to compete for efficiency and security with other cross-chain solutions, and if other cross-chain solutions provide faster, cheaper, or safer transfer services, it will also affect Fuel’s competitiveness. In the future, Fuel can support various types of transactions and computations, including transfers, payments, smart contracts, oracles, etc. This allows Fuel to adapt to different use cases and needs to provide efficient and flexible services. At the same time, accelerating integration and interoperability with various modular blockchain networks, including Ethereum 2.0, Celestia, etc. This will allow Fuel to leverage the data availability and consensus security of these networks and provide cross-chain transfer and interoperability functions. Fuel can further improve its execution efficiency and performance by increasing innovation and optimising its technical solutions, including Merkle Patricia Trie, Zero-Knowledge Proofs, etc. These measures are expected to expand its universality as a modular execution layer in the future.