Fuel VM: High-Performance Execution Layer

Before getting into concepts like Layer 2 (L2), rollups, monolithic and modular blockchains, it’s important to understand why L2 exists in the first place and what makes monolithic blockchains different from modular ones, along with the problems they are trying to solve.

A monolithic design has all four main blockchain components:

• Execution – Maintains the state of the Blockchain
• Settlement – resolve disputes and ensure the validity of the blocks
• Data availability – ensure the availability of data. 
• Consensus – ensures the order of transactions.

Monolithic blockchains Combine all the components in one layer. Because of this, during high traffic on Ethereum, the network gets clogged, and users face high transaction fees and slow transactions. as we have seen in incidents like the Metaverse land sell by Yuga Labs.

On the other hand, a modular blockchain separates these parts into different layers, each handling a specific component.

Why do we need l2/rollups? 

The blockchain scalability trilemma says that no blockchain can fully achieve all three together: scalability, decentralization, and security simultaneously, it will always be two out of three. For example, blockchains like Ethereum follow a monolithic design, which focuses more on decentralization and security, but they sacrifice scalability, which leads to network congestion.

Source: researchgate

Scalability Solution

Rollups and L2 solutions came into play to tackle this scalability issue. These systems group many transactions off-chain and later send them to the main Layer 1 blockchain, where the settlement happens. This boosts scalability while keeping the base network secure and decentralized. 

As the batching of transactions happens off-chain, to securely submit the transactions on layer 1, two categories are present in layer two or rollups which are optimistic and ZK rollups. 

• Optimistic Rollups – don’t involve fraud-proof while executing the transactions off-chain and submitting the transaction data to layer 1. If the state of the transaction is incorrect, then the fraud-proof is submitted, and if the proof is valid, then the state is omitted, and the operator will be punished.

             Example Solution: Optimism, Arbitrum, Metis, Boba Network

Source: Trapdoor-Tech

• ZK Rollups –  involve executing transactions off-chain and submitting the transaction data to layer 1. Then, the ZK rollup will create proof that the transaction is correct.  Unlike optimistic rollups, the L1 will not accept the state from L2 without confirming the proof created using zero-knowledge that the state was correct. 

            Example Solution: ZkSync, Starknet

Now, A new design pattern comes into the scene, essentially offloading the task, such as consensus or settlement, to other chains to make scalability way better for the blockchains:

Modular Blockchains  – as described earlier, the difference between a monolithic and modular blockchain is that a monolithic blockchain has all four components under a single layer. However, a modular blockchain separates them into different layers. 

• First Movers – 
  • Celestia first adopted this design pattern as a modular data availability layer.
  • Then, another first mover named fuel, a modular execution layer. 

Benefits of Modular Blockchains

• Scalability

Most monolithic blockchains can not achieve scalability because of the scalability trilemma theory. Scalability is the main problem that modular blockchain solves by separating the execution from consensus and data availability and purely focusing on execution. At the same time, a high degree of security can be achieved by relying on ethereum for consensus and data availability.

• Creating new blockchains

Launching a new blockchain using a modular stack is easy as one can focus on the minimum, such as execution, and delegate other blockchain components, such as settlement, to another blockchain. 

Drawbacks of Modular Blockchains

• Security

Compared to the monolithic blockchain, which guarantees security, modular blockchains can’t guarantee security, if any other layer that handles consensus or data availability is compromised, the modular chain can be at risk.

•  Complexity

With great benefits come greater complexities. Implementing modular chains is no easy task. For example, Ethereum’s data sharding plan relies on data availability sampling to prevent data withholding by nodes on a shard. Similarly, execution layers require mechanisms like fraud and validity proofs to ensure the security layer can validate off-chain state transitions.

What is FUEL?

Fuel is a next-generation execution layer for Ethereum. It’s an operating system for ethereum rollups. Fuels help rollups solve the PSI – parallelization, state-minimized execution, and interoperability. To its core, fuel is an optimistic rollup with some unique features that set it apart from other solutions.

What’s the main purpose of the Execution layer? – This is the layer where the user interacts with the blockchain through deploying smart contracts, transferring funds, or signing transactions. It’s where all the transactions and state changes are processed. 

Here are some key features of Fuel that you should pay attention to:

• Parallelization

Fuel enables parallel transaction processing, which sets it apart from other blockchains. It eliminates the serial process bottlenecks which means it uses more thread and cores of a CPU. Because of this, fuel can compute efficiently and give more throughput than other rollups on Ethereum. Therefore, it increases the scalability. 

• UTXO Model

Fuel uses the UTXO ( Unspent transaction Output) Model like Bitcoin, which is a blockchain model that basically doesn’t keep track of account balance. Instead, it uses inputs and outputs to manage the state. Which enables Parallelization. Because of the independence of UTXOs, each UTXO is a distinct piece of data representing a specific amount. For example, if Alice has two UTXOs – 5 BTC and 10 BTC – spending 5 BTC doesn’t have any impact on 10 BTC. This independence of UTXO enables multiple transactions to be processed without conflict, and since these UTXOs don’t rely on each other, they can be performed simultaneously, which enables parallelization and boost throughput. 

• FuelVM

As Fuel states that it learns from the ethereum ecosystem, it implemented the improvement suggested to the Ethereum VM. Because of the need to maintain backward compatibility, EVM couldn’t implement those suggestions, which led to tradeoffs such as parallel transaction execution. 

FuelVM is essentially used for building applications and smart contracts using sway language. The transaction on fuelVM occurs through UTXOs.

•  SWAY Language

SWAY is a domain-specific language (DSL) specifically built for writing smart contracts on fuel. Sway is based on Rust, which is a popular language in other blockchains such as Cosmos, Near, and Solan, so developers coming from that background can easily build smart contracts on top of fuel. 

There are four types of programs in sway

1. Contracts – the contracts on fuel are callable and stateful, unlike predicates or scripts.
2. Libraries – in sway, libraries are used to define new common behaviors.
3. Scripts – in fuel, a script is a runnable bytecode on the chain that executes once to perform a specific task. A script has no ownership or can not be called by a contract, and they don’t have any persistent storage.e 
4. Predicates – In sway, predicates are programs that return a boolean value to represent ownership of some resources and have no access to contract storage.

Security Risks on SWAY:

• Reentrancy

Reentrancy attacks can cost billions of dollars, as we have seen in Ethereum. Sway contracts can also be vulnerable to reentrancy attacks if developers don’t give proper attention to mitigate the risk of reentrancy attacks. Fuel uses an anti-reentrancy library,y, which can mitigate the risk but still can’t mitigate cross contract reentrancy vulnerabilities. 

• Business logic issues

Sway-based smart contracts can also have business logic issues such as:

1. Denial of Service (DOS) 
2. Uninitialized storage
3. Unprotected initializations
4. Missing storage updates
5. Missing authorizations on sensitive functionalities.  etc.  

Also, there exists a static analyzer for Sway-based contracts as well. SWAY-ANALYZER

Conclusion

Choosing between monolithic blockchain and modular blockchain requires understanding your project’s needs and acceptable trade-offs, as both design has their benefits and drawbacks. A monolithic blockchain guarantees security, while if a project requires faster and cheaper operations like those offered by Fuel, then a modular stack will be better suited for it. 

Any design doesn’t ensure the whole solution; it’s just a riddle we all try to solve in the web3 space. It will be fascinating to see how modular solutions like fuel and others can solve more complex problems and make web3 a better space. 

If you are developing on FuelVM and want to get your sway-based smart contract audited, you can reach out to BlockApex.