The Missing Piece in Execution

This is Part II of a multi-part series by Fuel Labs that covers topics related to scalability and execution on Ethereum. This series aims to provide comprehensive insights into the challenges associated with enhancing Ethereum's performance and capacity, as well as the current solutions working to make it more efficient and scalable for widespread adoption.

The execution layer is responsible for executing smart contracts and processing transactions (see Part I of this series), enabling various apps and services to be built within the Ethereum ecosystem. Over 60 Layer 2 (L2) chains have emerged in the last few years, all working on different solutions to scale Ethereum's execution layer.

In general, L2s provide the following advantages:

  • Lower Transaction Fees: By minimizing on-chain transactions, L2s can cut gas fees, making small transactions feasible and improving user experience.

  • Enhanced Security: Offloading transactions can provide additional security, protecting sensitive data while maintaining the integrity of the blockchain.

  • Lower Barriers to Entry: Lower costs and improved performance can attract more developers and users, fostering a vibrant ecosystem around Ethereum.

Despite the advantages L2s offer, they still fall short. A problematic trend in the current landscape is the persistent chase after EVM compatibility. Many solutions are attempting to replicate the EVM in various contexts, without fundamentally questioning whether this approach is optimal for modern blockchain needs. Although EVM compatibility offers advantages in terms of developer familiarity and existing ecosystem support, it also perpetuates many of the inefficiencies and limitations inherent in the original EVM design.

While we see the prominence of EVM L2s, we also see the recent increase in experimenting with alternative VMs to innovate the execution layer. Let’s take a look at the benefits of such solutions and the opportunities that exist for building.

The Current Execution Landscape

The execution landscape for blockchain technology has evolved rapidly with a surge of new frameworks entering the market. These include various virtual machines (VMs), modular frameworks and rollups.

General purpose VMs like WASM and RISC-V offer promising advancements in blockchain performance. WASM provides a more flexible and efficient execution environment compared to the EVM, supporting multiple programming languages and faster execution speeds.

However, integrating them into blockchain ecosystems poses challenges, requiring significant adjustments to existing infrastructure. One of the biggest critiques of systems like WASM and Risc-V are that they were designed as either an ISA or VM for the browser, rather than for blockchains. They were never built for the kind of gas-metered processing that blockchains use. WASM's instruction set was not even deterministic, making it ill-suited for blockchain execution. Additionally, these systems can struggle with less mature debugging tools, lack of integrated memory safety, and inherent vulnerabilities from memory-unsafe languages.

More recently, we’re seeing the attempt at adopting Layer 1 VMs like the Solana Virtual Machine (SVM) and MoveVM into rollup setups. SVM’s parallel transaction processing boosts efficiency but introduces challenges in ensuring transaction consistency and managing concurrent operations, which can impact stability and increase development complexity.

MoveVM introduces innovations in resource management by treating digital assets as first-class entities with strict rules against duplication or loss. Designed with code originally meant for Facebook’s Libra blockchain project, MoveVM offers familiarity to developers from that ecosystem.

However, porting to MoveVM involves a steep learning curve for developers accustomed to traditional VM models. MoveVM, like the SVM, are VMs inherently designed for monolithic architectures and were not originally designed for rollups, although they can be applied and deployed in modular architectures. Both MoveVM and SVM use highly state-incurring designs, where state constantly builds up over time. While the SVM tries to address this with application-level solutions, such as only posting Merkle proofs, it still lacks a clear strategy to manage ever-growing state for smart contracts. This highlights why arbitrary execution environments are problematic for blockchains. Blockchains need to be designed with full nodes as the customers. Designing with full node limitations in mind ensures adherence to the right physics of computing.

Rollups, which do rely on Ethereum’s security and decentralization, significantly enhance Ethereum's scalability by acting as execution layers. The diversity of options rollups offer has undoubtedly driven innovation and competition in the space. But a significant issue remains; most rollup architectures are simply an adaptation of general purpose or L1 designs. The implications being that rollup infrastructures are generally not optimized or designed specifically for rollups. The prevailing rollup architectures fail to solve rollup-specific problems such as interoperability between different L2s.

Most rollups also do not adequately tackle the problem of state growth, leading to inefficiencies and increased costs over time. In fact, rollups generally have the same state problems as Ethereum. Addressing this gap is a crucial area where most L2 solutions fall short, hence the need for more specialized and optimized approaches.

“Rollups do not remove the need to worry about state size; in fact, rollups have state size problems of exactly the same type as the Ethereum chain itself.” - Vitalik Buterin.

The current state of the execution landscape reveals a significant opportunity; by designing a system specifically tailored to address the unique challenges faced by modern blockchains, we can move beyond the constraints imposed by existing solutions, all while retaining Ethereum’s security.

The Missing Piece in Execution

The end goal is to build for a future on Ethereum—the largest security network—where thousands or even millions of application-specific chains can coexist. Building for such a future requires both maximum vertical scalability (for performance and state sustainability) and horizontal scalability (for interoperability). To realize such a goal, we must  reimagine blockchain execution from the ground up.

We need an execution layer specifically designed to balance high performance with minimal resource requirements. It’s easy to create a system that’s fast, but the real challenge is to build one that operates efficiently on low-resource, inexpensive hardware. A successful execution layer should balance high performance with minimal computational demands, making it accessible and sustainable for a wider range of users.

To scale Ethereum to millions of applications, we need an execution layer designed from the ground up for the job.

Introducing Purpose-Built Execution

The debate between general-purpose and purpose-built architectures prompts a critical examination of the core functions of blockchains. A prevailing thought process exists within the blockchain design space that mirrors traditional computing systems. and forces developers to make compromises that  prevent us from harnessing blockchain’s true potential.

We now have an opportunity to design blockchain systems with purpose-built execution, meaning addressing specific needs and goals, rather than adapting existing frameworks not originally created for the job at hand.

Purpose-built execution is about alignment, creating an execution environment that supports the goals and ideals of blockchain technology. Such an approach recognizes that the execution layer is not just a technical component of a blockchain system, but a fundamental piece that can either enable or hinder the realization of blockchain's full potential.

Unlike general-purpose execution environments, which aim to be versatile and handle a wide range of tasks, purpose-built execution focuses on solving specific challenges related to performance, efficiency, and scalability. Creating a custom-made execution layer that meets the specific needs of rollups or other specialized blockchain solutions addresses the shortcomings of general-purpose environments.This means creating an execution layer that is custom-made to meet the specific needs of rollups or other specialized blockchain solutions.

Starting from scratch ensures that every aspect of the system is optimized for efficiency, performance, and scalability, tailored specifically for its role in executing transactions and smart contracts. Focused designs allow for more effective handling of issues such as state minimization, interoperability, and resource management, ultimately paving the way for a more robust and adaptable execution environment.

Using general-purpose systems to solve blockchain tasks causes countless headaches for developers. General purpose systems have also resulted in poor user experience, fragmented tooling, and security issues. To solve these blockchain-specific tasks, we must rethink the execution architecture from the ground up. The solution? Design the right tool for the job.

Final Thoughts

Rethinking our approach to the execution layer can unlock new levels of performance, accessibility, and functionality in blockchain networks. We believe our approach will pave the way for more widespread adoption of blockchain technology and the realization of its transformative potential across various industries and use cases.

In the next part of our Execution Layer series, we'll take a closer look at how Fuel implements the principles of purpose-built execution and the implications for the future of Ethereum and the rollup space. We'll examine the FuelVM’s features, our approach to solving long-standing challenges in the execution layer, and the potential implications on the broader Ethereum ecosystem.

Subscribe to Fuel Labs
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
Verification
This entry has been permanently stored onchain and signed by its creator.