Explore FuelVM: A Custom Virtual Machine Purpose-Built for Execution of Smart Contracts

Original title: "Exploring FuelVM: A Custom Virtual Machine Purpose-Built to Execute Smart Contracts"

Original author: Ryan Sproule, medium

Original compilation: RR

This article comes from the WeChat public account: Old Yuppie

Introduction to Sway and FuelVM

Fuel Labs is building a new execution layer for scaling the next generation of blockchain applications. FuelVM is designed to be modular - it can serve as the execution engine for any blockchain. First, FuelVM will be deployed as a layer 2 rollup of Ethereum, but in theory it could be deployed anywhere as an L2 or even another L1. FuelVM is designed to scale Ethereum not by increasing node requirements, but by getting more out of existing hardware.

Fuel Labs is also building a new DSL for FuelVM called Sway for writing contracts. Sway was inspired by Rust and Solidity to create the ideal smart contract programming language.

What is FuelVM?

FuelVM is a custom virtual machine built entirely for the purpose of executing smart contracts. Fuel VM was designed from the beginning to be easy to prevent fraud and can be used as a transaction execution layer for optimistic rollup.

FuelVM is optimized to make better use of hardware to increase the throughput of transaction execution. Specifically, it is based on UTXOs and forces each transaction to explicitly define the UTXOs it will touch. Since the execution engine can identify exactly which state each transaction touches, it can easily find transactions that are not in dispute and parallelize them.

Why are VMs important?

In the smart contract blockchain system, the VM can understand the smart contract code and A system in which state transitions are performed by rules defined in code. VM is the operating system of the smart contract blockchain.

So far, the smart contract VM has not had a what iteration. All currently widely used smart contract chains (except Solana) use the same VM as Ethereum: EVM.

Currently, the EVM is "good enough" because the main bottleneck for scaling is not transaction execution Speed, but the bandwidth (block space) that the consensus engine can support. With the development of Layer 2 scaling solutions and DA solutions like Celestia, EIP-4844, Danksharding, EigenDA, etc., the cost of publishing rollup transaction data to L1 will no longer be a major constraint.

In this upcoming environment where bandwidth is cheap, the next bottleneck will be computational throughput Volume: How fast the system can execute transactions while keeping the underlying hardware requirements low enough to achieve sufficient decentralization. FuelVM has the advantage of being designed with these futures in mind and can optimize accordingly.

Differentiation of FuelVM

Execution + Validation Parallelization

The secret behind FuelVM's parallelizable virtual machine is its strict access list - it requires users to indicate which contracts their transactions will involve. It is helpful to check the exact composition of transactions in FuelVM.

Input: list of all contract UTXOs that the transaction will touch + data to unlock UTXO or predicate script .

Output: Define the UTXO that will be created

Gas information: Gas price + Gas limit

Witness: Metadata + Digital Signature Authorization

The key point here is the explicit "input" list, which lists all UTXOs that will be consumed. This includes "special" contract UTXOs. If the VM can figure out which contracts a transaction will touch before executing any code, it can safely execute all other uncontested state access transactions in parallel.

 Both transaction execution and verification can take advantage of parallelism (and verification to an even greater degree).

Note that since the transaction output is explicitly included in the validation, before asserting another node Overlapping transactions do not need to be executed in order to determine whether the proposed block is correct. This means that validation can happen completely in parallel regardless of state contention. In practice, this means that when nodes are synchronized with the network, they can achieve greater parallelization and catch up more quickly.

Native asset system

In EVM, there is a native asset: ETH. All other assets are realized through smart contracts that handle balance accounting (ERC20). In Fuel, developers are free to implement assets in smart contracts, however, there is an option that allows the VM to handle this natively.

In terms of balance management, native assets are several considerably larger than ERC20 style smart contracts The advantages. First of all, the operation of native assets is cheaper than the operation state in smart contracts. This can be attributed to the fact that it operates on lower-level primitives (the UTXO system is used instead to manipulate storage). Second, native assets have a better user experience, similar to how sending ETH is much simpler than sending ERC20 (no need to set up approval).

Native account abstraction + predicate

Account abstraction has always been a hot topic of research. EIP-5003) made several attempts. Implementing and upgrading Ethereum to support account abstraction is difficult, largely because of the core team's engineering bandwidth/technical debt plus associated complexity, and a long list of higher priority projects. Many rollups have had the opportunity to implement account abstraction on top of their novel execution environments from the start. FuelVM is one of them, and in addition to the native account abstraction, it will include an interesting new primitive: predicates.

A predicate is a pure (no state access) contract script that just returns a boolean value (true or false). UTXOs can be locked behind a predicate, so they can only be spent when the conditions defined in the predicate are met. This presents an interesting UX opportunity where users can set transactions to only execute under certain conditions, and then once the predicate is met, their transaction can be executed automatically. Also, predicates can be pruned when destroyed, so they don't cause state bloat.

Simple demonstration example: the user sets a transaction, as long as the price meets the threshold defined in the predicate, Just buy X tokens. Voila, pice de rsistance, fully on-chain trustless limit orders without state inflation!

Multidimensional resource pricing

Resource pricing is one of the most critical components of the smart contract blockchain. Maintain decentralization by keeping on-chain resource requirements at reasonable, affordable levels. Resource pricing allows the system to charge users for the "work" of nodes in the network.

In EVM, one of the most common reasons for introducing EIP is opcode repricing. This is because opcodes have hardcoded gas prices, and the base price of resources does not scale proportionally (CPUs have historically improved faster than SSDs). Ideally, these systems would be able to price each resource completely independently, so that the entire billing system could dynamically adjust to changes in the underlying hardware system.

FuelVM will enable dynamic multi-resource pricing, which can incentivize node runners to better Optimize its underlying hardware while still maximizing "utility per block".

This graph demonstrates a situation where the demand for smart contracts is significantly higher than for other smart contracts. With localized resource pricing, other contracts are not affected to the same degree. NFT airdrops are a good example. This is not exactly the same as Resource Pricing vs. Contract Pricing (Solana style), but the effect is very similar. Smart contracts with specific resource profiles are priced differently than other contracts. For the NFT airdrop example, a hot contract might have a resource profile that is storage-intensive but computationally cheap. Smart contracts that are computationally intensive relative to storage will not be affected by noisy NFT airdrops.

Solana's strategy to break the account or contract fee market is between the actual underlying resources and the demand for them adds a layer of abstraction. This means it is still possible to have very low fees but very high stress on nodes. For example, due to one event (e.g. many different NFTs being minted at the same time), the storage load on the system could be very high, but the fees are very low since not all traffic happens on one account. The per-account fee model does solve the problem of hot partitioning of accounts, but leaves a situation where the system cannot price the underlying resources correctly, so it can still lead to failure.

It is simpler and more accurate to price the system based on the underlying hardware resources rather than trying to add This network-specific abstraction layer accounts for the pricing of resources in a market.

Precautions for state expansion

As the geth team mentioned many times, the current bottleneck of geth lies in the I/O of state reading and writing. The original idea was that 100% of the Merkle Patricia trie (MPT) state would fit in standard device RAM. Things are different now as the state has grown to over 900 GB and is expected to grow by about 50-100 GB per year which is unreasonable for any one person, so most nodes have moved to SSDs to store state . Historically, SSDs have not improved rapidly with state size growth, so this cost will continue to affect network decentralization. This is a key question that ethereum researchers have been discussing for some time.

Instead, FuelVM was built with this in mind. Fuel Labs co-founder John Adler has spoken several times about the role resource pricing plays in how smart contracts consume state or other resources. By combining proper resource pricing and a cleaner data model with the UTXO system, FuelVM will be able to keep state under control, reducing the cost of running nodes, which equates to increased decentralization of the network.

Decentralization of "sorter"

< /p>

Although Layer 2 allows us to offload computation from the main chain, they still need to provide a mechanism to order transactions. Many layer 2 solutions are started using so-called "sequencers". A sequencer is a privileged node responsible for ordering transactions, performing state transitions, and then submitting state root updates along with compressed transaction information to Layer 1 Ethereum. It is worth noting that a single supercomputer responsible for sequencing can execute more transactions per epoch than many small computers that redundantly execute the same sequence of transactions.

There are several key issues in this centralized sorting role that need more attention!

Controlling the order of transactions can be very profitable. We have observed in Ethereum and other blockchains that MEV is one of the main sources of income for those who order blocks. As we see in traditional finance today, unilateral control over sequencing and MEV capture ultimately leads to a reduction in users’ ability to execute.

From a usability and governance perspective, a centralized orderer can be a single point of failure. If one or a few organizations are running sequencers, they may be crippled or shut down. This is a living risk to the web.

A centralized orderer can review second layer transactions. The orderer can choose any transaction and place them in any order during block building, which creates the ability to censor. Many L2s handle this situation by providing a "forced transaction" mechanism that allows users to bypass the orderer and include transactions directly by leveraging L1.

Sequencers may make inconsistent chain state commitments to rollup users. This is often called equivocation, which basically means that the orderer can make misleading commitments about some state of L2. This is because fast finalization of rollups is a trusted step, and a sequencer could abuse that trust to cause users to do things they didn't intend.

How does Fuel solve these problems?

First of all, Fuel is not just a rollup or L1 blockchain, on the contrary, it is an application A system of state transitions that can publish state transitions to L1 if configured to rollup or run as L1 in the network for consensus. The key difference is that Fuel's execution engine doesn't care about consensus or transaction ordering. Fuel is only responsible for applying transactions as quickly as possible. However, because Fuel can run on such lightweight hardware, and verification is so cheap, Fuel can bootstrap a diverse and decentralized consensus network that is better than an equivalent running on a less performant execution engine such as the EVM. Systems are much cheaper.

Furthermore, the Fuel team is considering a combination of decentralization, MEV and other considerations second layer token economics. Fuel co-founder John Adler wrote in January about token models for second-layer blockchains, laying out a way to tokenize blocks by allowing rollups to earn fees as block producers. The scarcity of space, thereby helping to decentralize the token design of block production. Fees are only one part of block producer revenue, as we have seen in other chains, MEV is another large part of revenue. Similar to the scarcity of block space, MEV revenue will also be tokenized through block production rights.

State Model: UTXO vs Account Based

The best way to conceptualize the difference between a UTXO data model and an account model is as follows: UTXOs can be compared to cash bills, while account models are more like in the bank ledger. Account systems naturally lead to state bloat, since every transaction is trying to access the same account, and UTXOs are less contentious if designed correctly. This feature enables better parallelization and also prevents state bloat by simplifying the process of state truncation.

Continuing with the cash vs. bank ledger analogy, it becomes clear why parallelization using UTXOs is easy many. Two cash transactions can happen at the same time, they don't need to know anything about each other, whereas if 2 accounts are updated on one ledger, both transactions must update the same shared ledger.

VM War

In addition to Fuel, other teams are also developing next-generation virtual machines for smart contract blockchains, such as Mysten Labs and Aptos, which is using a virtual machine originally designed by Facebook engineers. MoveVM, part of the Libra project. This further supports the argument that new execution environments are required to support next-generation blockchain applications. All of these projects have interesting approaches and make different trade-offs.

In the few years MoveVM has stagnated, while Libra has been busy fighting lawsuits, cryptocurrency The world has changed a lot. Fuel was able to adapt to these changes and stay nimble in an extremely fast-paced industry, while Move was slightly behind. Still, now that Move has spun off from Facebook and a new big funding round is done, they are definitely ready to go to war!

Conclusion

< /p>

Unlike other L2s, Fuel plans to decentralize the sorter role from the start by designing the VM so that expensive hardware is not needed to scale.

Fuel is flexible. It can be deployed in many environments, but its priority is as an Optimistic Rollup aligned with Ethereum.

Fuel will have a much better user experience than EVM due to native and novel ways of interacting with the chain such as account abstractions, scripts and predicates.

The controversy of UTXO data model Naturally smaller than the account data model, and leads to more parallelism and less state bloat.

Original link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia