Fuel: Modular Execution Case (Part 2)

Modular execution cases

The modular architecture will allow the blockchain to scale at an order of magnitude rate. As a core part of the modular stack, the execution layer is in a phase of rapid innovation.

Fuel is building the fastest execution layer for a modular blockchain stack, and in Part 1, we explored how the modular execution layer enables scalability by decoupling computation from validation.

https://mirror.xyz/coincapital.eth/ZfEP-rJmkSkCN2f5tmBc2_IcpcuLFgqJ5ZX0wxUJdpI

We also talked about the second core advantage, which enables the modular execution layer to scale by orders of magnitude than the monolithic execution layer:

Monolithic chains are locked into inefficient technologies in terms of the speed and variety of computation they can support. On the other hand, modular execution layers can be specifically designed to optimize efficient computing.

This article explores the second core advantage, with a particular focus on how Fuel is revolutionizing the way blockchain processes computation.

Monolithic chains: The challenge of iterating at Layer 1

Monolithic chains are locked into inefficient technologies in terms of the speed and variety of computation they can support.

When blockchain was first conceived, there was only one use case: digital cash. The Bitcoin blockchain is designed to be optimized for this narrow use case.

Soon after Bitcoin’s launch, people began to realize that blockchain’s potential in use cases goes far beyond money. The narrative quickly shifted from “distributed ledgers” to “distributed computers.” The Bitcoin community tried to support this use case with colored coins, but it was clear that it was not versatile enough to truly support trustless distributed computing; It is locked into its original use case. A new architecture is needed.

Recognizing this problem, the creators of Ethereum set out to build a blockchain that could support a distributed Turing-complete virtual machine: the Ethereum Virtual Machine (EVM). With the launch of Ethereum in 2015, the blockchain has evolved to support arbitrary computation in a trustless environment. Now, anyone can build and start a computer program (smart contract) and have it run on distributed computers.

Ethereum was conceived less than five years after the blockchain concept emerged. In the 7 years since the launch of Ethereum, new concepts have been invented, which represent a bigger leap forward than Ethereum has made on Bitcoin. But like Bitcoin, the Ethereum blockchain is mostly locked into the core architecture of its launch.

For every improvement made to the Ethereum blockchain and EVM over the years, there are many more potential innovations that cannot be implemented due to the need to maintain backwards compatibility.

As a result, whenever new innovations are incubated, the blockchain community continues to fund, build, and launch new blockchains. Countless new Layer 1 blockchains have been rolled out, promising to iterate on the concept of trustless distributed computing, but they all run into the same challenge: Upgrading the blockchain to support new features and improvements is difficult (and often impossible).

As a result, the cycle continues, and we continue to see new blockchain launches with piecemeal improvements to its predecessor. In the process, we have left behind an ecosystem of mostly incompatible blockchains, with increasing fragmentation of liquidity, funding, user experience, and share of developer ideas. At the same time, the energy that could have been spent on true innovation is instead being used to attract the attention of investors, developers, and end users.

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 a modular stack is independent of the others, innovation can be made on one layer without the need for a complete overhaul of the entire stack. The execution layer can compete on execution. Data availability tiers can compete on data availability. Each layer can be optimized for its intended purpose without breaking backward compatibility.

A shared settlement layer centralizes liquidity in one place, so new layers of execution can be built without dispersing liquidity or increasing friction in the end-user experience. Natively enabled trust-minimized bridging means that communities can spend fewer resources on interoperability efforts and instead focus on exploring meaningful innovations.

With the advent of modular stacks, we can move away from different L1 ecosystems competing on vanity metrics to a more cohesive, interoperable, and scalable stack.

Modular execution: Beyond EVM

While there are a large number of first-tier blockchains promising to improve on the original design of the EVM, its first-mover advantage has allowed the EVM to gain a foothold as the “default” runtime environment in the blockchain ecosystem. Smart contract development became synonymous with Solidity, the programming language of EVM, and it has attracted most potential blockchain developers. As a result, most of the execution layers currently under development are based on EVM-based rollups.

There’s a good reason to do this: using EVM gives rollups access to the marketplace of existing applications written in Solidity, as well as the large number of end users who are already familiar with those applications. EVM is a great tool for seeding new ecosystems because it already has such a large share of the developer market.

But, as we’ve explored, the need to maintain backward compatibility means that EVMs can’t adopt many innovations. In addition, the core design of the EVM is optimized for monolithic chains, not modular stacks.

Some limitations of EVM include:

Sequential execution – EVM does not support parallel transaction execution, so it is much less computationally efficient than other virtual machine designs.

Proof of fraud – Ethereum’s account-based model means that generating and executing proof of fraud on the EVM chain is very expensive and inefficient, making it a sub-optimal choice for a modular execution layer.

Solidity – EVM’s most popular programming language, Solidity, is notorious for providing a poor developer experience in a way that makes it difficult to write secure smart contracts.

Fuel: Optimized for modular execution

The advent of modularity means that the execution layer can take advantage of Ethereum’s liquidity and security without being limited by EVM.

Fuel: Modular Execution Case (Part 2)

By adopting new and improved virtual machine design principles, the modular execution layer can be specifically optimized for efficient and scalable compute, a superior developer experience, and maximum security.

Fuel is using this new design space to build the fastest modular execution layer.

Fuel virtual machine

One of Fuel’s core innovations is the all-new virtual machine, FuelVM. The advent of the execution layer built on Ethereum provides new opportunities to improve past virtual machine designs without being constrained by the need for backwards compatibility.

While slow transaction execution for EVMs may be sufficient in a pre-modular world where bandwidth is a core bottleneck, improvements made on the new modular stack, including on L1 Ethereum, mean that compute throughput is becoming a major limit when scaling.

In response to this new paradigm, FuelVM aims to optimize fast trade execution. Drawing on the experience of EVM, Solana, WASM, Bitcoin, and Cosmos, FuelVM aims to reduce wasteful processing of traditional blockchain virtual machine architectures while greatly increasing potential design space for developers.

FuelVM incorporates many innovations that have been suggested and supported by the EVM community, but were not possible due to the need to maintain backward compatibility. Only a few examples are highlighted below (see here for a complete list).

Fuel: Modular Execution Case (Part 2)

Advanced DevEx with Sway and Forc

The Fuel protocol is designed with developer experience first. FuelVM is built alongside its companion language, Sway: a Rust-based, domain-specific language specifically designed to take advantage of blockchain VMs. Unlike Solidity, which was developed after the creation of the EVM, Sway was created from the ground up with convenient and efficient operation built in. By being based on Sway on Rust, Fuel makes smart contract development safer and more efficient by using powerful static analysis and compiler feedback.

From a tool perspective, Fuel improves the EVM ecosystem with the Forc toolchain. With Forc, developers can get everything they need to start creating Sway applications for Fuel VMs using a single toolchain. Fuel takes a well-planned, “battery-included” but modular approach to delivering tools, with a comprehensive, standardized set of specification tools that cover not only the lower levels of the stack (such as protocol and VM implementation), but also the higher levels (such as package management, editor support, common plugins, and more).

Fuel’s developer environment retains the benefits of smart contract languages like Solidity while adopting the paradigm introduced in the Rust tool ecosystem, making Sway’s learning curve manageable and suitable for all levels of the developer experience.

Parallel transaction execution

The ability to execute transactions in parallel is a highly desirable property, especially as modern processors become increasingly multithreaded. Therefore, this is a core consideration when designing the Fuel protocol.

Parallel transaction execution requires the ability to identify and handle dependencies between transactions. To avoid overlap when processing transactions on different cores, you need to predetermine the shared state that each transaction might touch (via an “access list”) in order to divide the transactions into collections that do not have any possible interaction with each other.

Due to the limitations of its account-based design, Ethereum cannot support these access lists and is therefore forced to process transactions sequentially (i.e. one after the other). EIP-648 proposed adding access lists to Ethereum, but it was never implemented because of the other inefficiencies it would entail.

Drawing lessons from this limitation, Fuel implements strict state access lists in the form of a UTXO model, enabling it to use multiple CPU threads and cores that would normally be idle in a single-threaded blockchain. As a result, Fuel can execute transactions in parallel, providing more computation, state access, and transaction throughput than its single-threaded counterpart.

Fuel: Modular Execution Case (Part 2)

In addition to providing efficiency optimizations, the ability to process multiple transactions in parallel improves safety because it enables transaction throughput to scale without a corresponding increase in the resource requirements for validating those transactions. This reduces the barrier to running full nodes, resulting in a more decentralized network of validators.

Optimized for proof of fraud

Proof of fraud is the core technology of the modular blockchain stack. In Part 1, we explored how the modular execution layer leverages proof of fraud to achieve trust-minimized light clients, enabling security with the assumption that only one honest full node is available.

Fuel: Modular Execution Case (Part 2)

By trusting minimized light clients and shared settlement and data availability layers, trust-minimized bridges can be built between modular execution layers that are not possible between L1s. This allows experimentation and deployment of new blockchain designs without decentralizing security or liquidity.

Because of the benefits offered by proof of fraud, Fuel is specifically designed and manufactured for proof of fraud in a low-cost, efficient manner.

While Ethereum’s account-based model means that the cost of building a proof of fraud for it is unconstrained, Fuel optimizes proof of fraud by using the UTXO model. UTXO fraud proof improves efficiency by simply asking every UTXO spend to “point” to the creation of a UTXO without having to reference the global state tree. Proof that a) the pointer is invalid, or b) that whatever points to does not match what was spent, is sufficient to prove fraud exhaustively.

As an added benefit, the FuelVM instruction set is designed to prove fraud in EVM. This means that Fuel can use Ethereum as a settlement layer, leveraging its deep liquidity and large user base while not being limited by EVM restrictions.

Other benefits

In addition to the above, Fuel has implemented a number of other improvements, including:

Support for multiple native assets

Native account abstractions and verbs

Multi-dimensional resource pricing

Sequencers are decentralized

An explanation of these improvements is beyond the scope of this article, but Blockchain Capital has a good in-depth look at these additional benefits.

summary

The monolithic paradigm has led to an ecosystem of incompatible L1s competing on vanity metrics, dispersing liquidity, funding, and developer mind shares. Fuel adoption is based on the premise that innovation does not need to start a new L1, but can occur at the execution level.

The modular architecture allows MELs, such as Fuel, to focus on efficient computing without worrying about backward compatibility. Faster computation not only leads to higher throughput, but also makes running validators more efficient, resulting in greater decentralization. This allows Fuel to contribute to Ethereum’s scalability without being hampered by EVM inefficiencies.

The execution layer using EVM can leverage the existing ecosystem of Solidity applications and developers, but cannot take full advantage of the design space provided by the modular stack. Fuel is leveraging this new design space from FuelVM to design from the ground up that proves fraud and provides the best developer experience.

Fuel introduces innovations for a fast-approaching modular future, enabling a new generation of blockchain, #BeyondMonolithic.

Fuel: Modular Execution Case (Part 2)

Fuel official website: https://www.fuel.network/

Twitter: https://twitter.com/fuellabs_

Discord Community: https://discord.com/invite/fuelnetwork

YouTube Video: https://www.youtube.com/channel/UCam2Sj3SvFSAIfDbP-4jWZQ

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/fuel-modular-execution-case-part-2/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-11-05 09:48
Next 2022-11-05 09:52

Related articles