The Case for Modular Execution (Part 2)
This article has been translated by the Fuel Ambassadors in Russian.
The Case for Modular Execution
Modular architecture will enable blockchains to scale by orders of magnitude. As a core part of the modular stack, execution layers are in a stage of rapid innovation.
Fuel is building the fastest execution layer for the modular blockchain stack. In Part 1 we explored how modular execution layers enable scalability by decoupling computation from verification.
We also touched on a second core benefit which enables modular execution layers to scale by orders of magnitude more than their monolithic counterparts:
Monolithic chains are locked into inefficient technologies when it comes to the speed and variety of computation they can support. On the other hand, modular execution layers can be specifically designed to optimize for efficient computation.
This post explores this second core benefit, with a specific focus on how Fuel is revolutionizing the way blockchains handle computation.
Monolithic Chains: The Challenge of Iterating on Layer-1s
Monolithic chains are locked into inefficient technologies when it comes to the speed and variety of computation they can support.
When blockchains were first conceived of, there was a single use case in mind: digital cash. The Bitcoin blockchain was designed to optimize for this one narrow use case.
Soon after the launch of Bitcoin, people started to realize the potential of blockchains for use cases far beyond money. The narrative quickly shifted from “distributed ledger” to “distributed computer”. The Bitcoin community attempted to support this use case through colored coins, but it was clear that it was not versatile enough to truly support trustless distributed computing; it was locked into its original use case. A new architecture was required.
Recognizing this problem, the creators of Ethereum set out to build a blockchain which could support a distributed Turing-complete virtual machine: the Ethereum Virtual Machine (EVM). With the launch of Ethereum in 2015, blockchains had evolved to support arbitrary computation in a trustless environment. Now, anyone could build and launch a computer program (smart contract) and have it run on a distributed computer.
Ethereum was conceived of less than half a decade after the concept of blockchains came into existence. In the 7 years since Ethereum launched, new concepts have been invented which represent an even greater leap forward than the progress Ethereum made over Bitcoin. But like Bitcoin, the Ethereum blockchain is mostly locked into the core architecture it launched with.
For every improvement that has been made to the Ethereum blockchain and the EVM over the years, there are many more potential innovations that cannot be implemented due to the need to maintain backward compatibility.
As a result, the blockchain community has continued funding, building, and launching new blockchains every time a new innovation is hatched. Countless new layer-1 blockchains have launched on the promise of iterating on the concept of trustless distributed computing, but they all run into the same challenge: it’s hard (and often impossible) to upgrade blockchains to support new functionalities and improvements.
And so the cycle continues, where we continue to see new blockchains launching with piecemeal improvements over their predecessors. In the process, we are left with an ecosystem of mostly incompatible blockchains, with ever-increasing fragmentation of liquidity, funding, user experience, and developer-mindshare. Meanwhile, the energy that could be spent on true innovation is instead directed toward getting attention from investors, developers, and end-users.
Crypto has a serious problem.
— Mustafa Al-Bassam 🧱 (@musalbas) October 18, 2022
We're stuck in an endless cycle of new L1 smart contract platforms. Each purport to fix the problems of the L1s in the previous cycles.
These L1s rinse and repeat the same bizdev strategy of prior L1s, building copy-cat DeFi & NFT ecosystems. pic.twitter.com/wsrva4f5RD
Competition is healthy and necessary for a thriving ecosystem. But this competition is happening at the wrong level.
The modular blockchain paradigm promises to solve this problem. Because each layer in the modular stack is independent of the others, innovation can happen on one layer without a complete overhaul of the entire stack. Execution layers can compete on execution. Data availability layers can compete on data availability. Every layer can optimize for its intended purpose without breaking backward compatibility.
Shared settlement layers enable liquidity to be pooled in one place, so new execution layers can be built without fragmenting liquidity or adding friction to the end-user experience. Natively enabled trust-minimized bridging means the community can reduce the resources spent on interoperability efforts and instead focus them on exploring meaningful innovations.
With the advent of the modular stack, we can move away from a disparate ecosystem of L1s competing on vanity metrics, and toward a more cohesive, interoperable, upgradeable stack.
We believe innovation does not require launching a new L1, but can happen at the execution layer
— Fuel Labs (@fuellabs_) September 13, 2022
Modular Execution: Moving Beyond the EVM
Despite the plethora of layer-1 blockchains promising improvements over the EVM's original design, its first-mover advantage enabled the EVM to gain a foothold as the "default" runtime environment in the blockchain ecosystem. Smart contract development became synonymous with Solidity (the EVM's programming language), which has captured the majority of would-be blockchain developers. Because of this, most execution layers currently under development are EVM-based rollups.
There is a good reason for this: using the EVM enables rollups to tap into a market of existing applications written in Solidity, as well as a large cohort of end-users who are already familiar with those applications. The EVM is a great tool for seeding a new ecosystem, as it already has such a large share of the developer market.
However, as we already explored, the need to maintain backward compatibility means that the EVM has been unable to adopt many innovations. In addition, the core design of the EVM is optimized for a monolithic chain, not a modular stack.
Just some limitations of the EVM include:
- Sequential Execution - The EVM does not support parallel transaction execution, making it much less computationally efficient than other VM designs.
- Fraud Proofs - Ethereum’s account-based model means generating and executing fraud proofs on EVM chains is extremely costly and inefficient, making it sub-optimal for modular execution layers.
- Solidity - The most popular programming language for the EVM, Solidity, is notorious for providing a poor developer experience, and is designed in a way that makes it difficult to write secure smart contracts.
Fuel: Optimized for Modular Execution
The advent of modularism means that execution layers can leverage Ethereum’s liquidity and security without being restricted by the limitations of the EVM.
By adopting new and improved VM design principles, modular execution layers can specifically optimize for efficient & scalable computation, superior developer experience, and maximum security.
Fuel is taking advantage of this new design space to build the fastest modular execution layer.
FuelVM
One of the core innovations of Fuel is a completely new virtual machine, the FuelVM. The advent of execution layers built on Ethereum presents a new opportunity to improve on past VM designs, unconstrained by the need to be backward compatible.
While the EVM’s slow transaction execution may have been sufficient in a pre-modular world where bandwidth was the core bottleneck, improvements made within the new modular stack (including on L1 Ethereum) mean that computational throughput is becoming the primary constraint when it comes to scaling.
In anticipation of this new paradigm, the FuelVM is designed to optimize for fast transaction execution. Taking learnings from the EVM, Solana, WASM, Bitcoin, and Cosmos, the FuelVM is designed to reduce wasteful processing of traditional blockchain virtual machine architectures, while vastly increasing the potential design space for developers.
The FuelVM adopts many innovations that have been suggested and supported by the EVM community, but couldn't be implemented due to the need to maintain backward compatibility. Just a few examples are highlighted below (see here for the full list).
Superior DevEx with Sway and Forc
The Fuel protocol was designed with developer experience at the forefront. The FuelVM has been built alongside its companion language, Sway: a Rust-based domain-specific language designed specifically to leverage a blockchain VM. Unlike Solidity, which was developed after the creation of the EVM, Sway has been created from the ground up to have convenient and efficient ops built-in. By basing Sway on Rust, Fuel makes smart contract development safer and more performant through the use of strong static analysis and compiler feedback.
From a tooling perspective, Fuel improves on the EVM ecosystem with the Forc toolchain. With Forc, developers can get everything they need to start creating Sway applications for the Fuel VM with a single toolchain. Fuel takes a curated, "batteries-included"-yet-modular approach to providing tooling, with a comprehensive, standardized, canonical set of tools that covers not only the lower levels of the stack (like protocol and VM implementations), but also the higher levels (such as package management, editor support, common-use plugins, and much more).
Writing dapps on Fuel is honestly so nice because you don't have to configure wagmi, hardhat/foundry, ethers.js. You don't have to copy/paste your ABI in your front-end project. All the tooling is integrated seamlessly and just works.
— cami ᵍᵐ (@camiinthisthang) October 5, 2022
Better developer experience 🤝 Ethereum
Fuel’s developer environment retains the benefits of smart contract languages like Solidity while adopting the paradigms introduced in the Rust tooling ecosystem, making the learning curve for Sway easily manageable for all levels of developer experience.
Parallel Transaction Execution
The ability to execute transactions in parallel is a highly desirable property, especially as modern processors become increasingly multi-threaded. As such, it was a core consideration when designing the Fuel protocol.
Parallel transaction execution requires the ability to determine and handle dependencies between transactions. In order to avoid overlap when processing the transactions on separate cores, the shared state that may be touched by each transaction needs to be identified upfront (via “access lists”), so transactions can be partitioned into sets which don’t have any possible interactions with one another.
Because of the constraints of its account-based design, Ethereum is not able to support these access lists, so is forced to process transactions sequentially (i.e. one after the other). EIP-648 proposed the addition of access lists to Ethereum, but this has never been implemented due to other inefficiencies it would introduce.
Learning from this limitation, Fuel has implemented strict state access lists in the form of a UTXO model, giving it the ability to use multiple CPU threads and cores that are typically idle in single-threaded blockchains. As a result, Fuel can execute transactions in parallel, delivering far more compute, state accesses, and transactional throughput than its single-threaded counterparts.
As well as providing efficiency optimizations, the ability to process multiple transactions in parallel allows for security improvements, as it enables transaction throughput to scale without a comparable increase in the resource requirements to verify those transactions. This reduces the barrier for running a full node, leading to a more decentralized network of verifiers.
Optimized for Fraud Proofs
Fraud proofs are a core technology in the modular blockchain stack. In Part 1, we explored how modular execution layers can leverage fraud proofs to enable trust-minimized light clients, allowing for security under the assumption that only a single honest full node is available.
With trust-minimized light clients and shared settlement & data availability layers, it is possible to build trust-minimized bridges between modular execution layers, something which is impossible to achieve between L1s. This allows for the experimentation with and deployment of new blockchain designs without fragmenting security or liquidity.
Because of the benefits fraud proofs provide, Fuel was designed and built specifically to be fraud-provable in a low-cost, efficient manner.
Whereas Ethereum’s account-based model means that the cost of constructing fraud proofs for it is unbound, Fuel optimizes for fraud proofs by using the UTXO model. UTXO fraud proofs achieve efficiency by simply requiring each spend of a UTXO to "point" to the creation of the UTXO, without having to refer to a global state tree. Proving that either a) the pointer is invalid, or b) whatever is being pointed to doesn't match whatever is being spent, is sufficient for exhaustively proving fraud.
As an added benefit, the FuelVM instruction set is designed to be fraud-provable within the EVM. This means Fuel can use Ethereum as a settlement layer, leveraging its deep liquidity and large user base while remaining unconstrained by the limitations of the EVM.
Other Benefits
On top of the above points, Fuel has implemented a number of other improvements, including:
- Support for multiple native assets
- Native account abstraction & predicates
- Multi-dimensional resource pricing
- Sequencer decentralization
An explanation of these improvements is out of scope for this article, but Blockchain Capital provides an excellent deep dive into these additional benefits.
Summary
- The monolithic paradigm leads to an ecosystem of incompatible L1s competing on vanity metrics, fragmenting liquidity, funding, and developer-mindshare. Fuel adopts the premise that innovation does not require launching a new L1, but can happen at the execution layer.
- Modular architecture enables MELs such as Fuel to focus on efficient computation without worrying about backward compatibility. Faster computation not only leads to higher throughput, but also makes running validators more efficient, improving decentralization. This enables Fuel to contribute to Ethereum’s scalability without being held back by the inefficiencies of the EVM.
- Execution layers that use the EVM can capitalize on the existing ecosystem of Solidity applications and developers, but fail to make the most of the design space offered by the modular stack. Fuel is leveraging this new design space with the FuelVM, designed from the ground up to be fraud-provable and to provide the best developer experience.
- Fuel introduces innovations that optimize for the rapidly approaching modular future, enabling a new generation of blockchains that go #BeyondMonolithic..
Follow Us
About Us
Fuel is the fastest execution layer for the modular blockchain stack. Powerful and sleek, the technology enables parallel transaction execution, empowering developers with the highest flexible throughput and maximum security required to scale. Developers choose the FuelVM for its superior developer experience and the ability to go beyond the limitations of the EVM.