Fuel Network: Ethereum Rollups and Blockchain Scalability

Fuel Network: Ethereum Rollups and Blockchain Scalability

•
Simeon Cholakov & Simão Amaro
• 51 min read

At Three Sigma, we recognize the intricate opportunities within the Web3 space. Based in Lisbon, our team of experts offers premier services in development, security, and economic modeling to drive your project's success. Whether you need precise code audits, advanced economic modeling, or comprehensive blockchain engineering, Three Sigma is your trusted partner.

Explore our website to learn more.

1. Introduction of Fuel Network

Fuel is an operating system specifically designed for Ethereum rollups, aimed at supporting the growing needs of decentralized economies. Set to launch its mainnet in Q3 2024, Fuel builds on the success of Fuel V1, the first optimistic rollup on Ethereum to achieve stage 2 security in 2020.

Unlike traditional Layer-2 solutions, Fuel is purpose-built for Ethereum rollups, enabling developers to create scalable, secure, and customizable decentralized applications (dApps) and app chains, overcoming the limitations of monolithic Layer-1 architectures and general-purpose VMs.

The Problem: Challenges in Ethereum Rollups

The rise of modular Layer-2 (L2) chains in the Ethereum ecosystem highlights a gap between rollups and monolithic Layer-1 blockchains in terms of performance and features. Current rollup architectures, designed for L1s, struggle with parallel execution and state management, leading to suboptimal performance and developer challenges.

To bridge this gap, Fuel introduces a new architecture built from the ground up that is optimized for Ethereum rollups, integrating parallelization, state minimization, and interoperability.

The Solution: Fuel's Purpose-Built Architecture

To bridge this capability gap, Fuel introduces a novel architecture specifically optimized for Ethereum rollups. This architecture addresses the core issues by integrating:

  • Parallelization: FuelVM supports parallel transaction execution, leveraging modern multi-core processors to significantly enhance throughput and reduce latency.
  • State Minimization: Fuel utilizes a UTXO model to manage state efficiently, ensuring that the growth of blockchain state is controlled, thereby preserving decentralization.
  • Interoperability: Fuel’s design allows for seamless and secure interaction between different rollups, enabling a connected ecosystem of decentralized applications.

By focusing on these key areas, Fuel delivers a high-performance execution environment that meets the evolving needs of the Ethereum ecosystem.

What is a Rollup Operating System in Ethereum?

Fuel is a comprehensive OS for Ethereum rollups, functioning as the software layer atop Ethereum’s hardware foundation. It includes:

  • FuelVM: The core engine providing parallelization, state minimization, and customizability.
  • Sway: A blockchain-specific language combining Solidity and Rust's strengths for high-performance dApps.
  • Forc Toolchain: Tools for easily building and deploying dApps on Fuel chains.

Motivation for Creating Fuel

The creation of Fuel was driven by a need to address specific challenges and gaps in the Ethereum ecosystem. Here’s an overview of the motivations behind Fuel:

Addressing Performance Gaps

Existing rollup solutions, while advanced, still lag behind monolithic L1s in terms of performance and feature set. Fuel aims to bridge this gap by providing a high-performance execution environment specifically optimized for rollups.

Enhancing Developer Experience

By offering a purpose-built virtual machine (FuelVM) and a domain-specific language (Sway), Fuel simplifies the development process, enabling developers to create efficient and high-performance dApps without the limitations imposed by general-purpose architectures.

Promoting Decentralization

Fuel's state-minimized design helps maintain decentralization by reducing the resource demands on nodes, making it more feasible for a larger number of participants to operate nodes and contribute to the network.

Facilitating Interoperability

With built-in interoperability features, Fuel aims to create a cohesive and interconnected ecosystem where different chains can communicate and collaborate seamlessly, fostering innovation and growth.

Customization and Specialization

Recognizing the diverse needs of different applications, Fuel provides the flexibility to deploy customized app chains, allowing developers to optimize their chains for specific use cases and performance requirements.

Future-Proofing Ethereum

By addressing the limitations of current rollup solutions and introducing advanced features tailored to the modular, rollup-centric future envisioned by the Ethereum Foundation, Fuel positions itself as a key player in the evolution of the Ethereum ecosystem.

Differences from Other Ecosystems

Let’s dive into a quick comparison between Fuel, Arbitrum One, and Base, as we explore how these Ethereum Layer 2 rollups stack up across key categories!

Core Purpose

  • Fuel: It’s core purpose revolves around delivering the fastest execution layer for the modular blockchain stack. It achieves this by optimizing for maximum throughput and decentralization, employing innovative consensus mechanisms and data availability layers. Fuel's architecture is particularly focused on minimizing trust assumptions and enhancing censorship resistance, which are critical for achieving true decentralization. The project aims to push the boundaries of what is possible in blockchain throughput while maintaining a strong focus on security and decentralization.
  • Arbitrum One: As a general-purpose rollup, Arbitrum One is designed to scale Ethereum by providing faster and cheaper transactions. Its compatibility with existing Ethereum dApps makes it a popular choice among developers who want to scale their applications without modifying their codebase. Arbitrum achieves this through its AnyTrust protocol, which balances scalability with security.
  • Base: Built by Coinbase, Base aims to bring the next billion users on-chain by providing a secure and user-friendly environment. It focuses on ease of use, particularly for developers targeting consumer applications. This is part of Coinbase's broader strategy to integrate blockchain technology into its existing infrastructure and user base, enabling seamless interaction between traditional finance and decentralized applications.

Execution Environment

  • Fuel: Fuel’s execution environment is powered by its own Virtual Machine, the FuelVM, which is designed for high performance and parallel execution. By implementing long-suggested improvements from the Ethereum ecosystem—such as parallel transaction execution and support for multiple native assets—FuelVM enhances throughput and reduces costs. Using a UTXO model, FuelVM pre-identifies state dependencies, enabling full nodes to leverage multiple CPU cores for greater efficiency. This architecture delivers significantly higher compute power and transactional throughput compared to traditional EVMs, making Fuel ideal for scalable, high-performance applications.
  • Arbitrum One: Arbitrum’s execution environment is built around the Arbitrum Virtual Machine (AVM), which is fully compatible with the Ethereum Virtual Machine (EVM). This compatibility allows developers to migrate their Ethereum dApps to Arbitrum seamlessly, without requiring code changes. The AVM maintains the security and functionality of the EVM while introducing optimizations that enhance gas efficiency and transaction throughput. By preserving EVM compatibility, Arbitrum ensures that developers can continue using their existing tools and workflows, while benefiting from the scalability and reduced costs of a Layer 2 solution.
  • Base: Base operates with EVM-equivalence, ensuring that any Ethereum smart contract or dApp can run on Base without modification. This design leverages the security and familiarity of the Ethereum Virtual Machine (EVM), allowing developers to seamlessly transition their projects to Base while continuing to use existing tools and development processes. By maintaining EVM-equivalence, Base provides a scalable, user-friendly Layer 2 environment that integrates smoothly with the broader Ethereum ecosystem, offering the same security guarantees as the Ethereum mainnet.

State Minimization

  • Fuel: Optimizes performance and scalability by implementing a higher degree of statelessness, meaning nodes don’t need to store and manage large amounts of data like transaction histories or account balances. This reduces storage and computational overhead, allowing Fuel to process transactions more efficiently and scale more effectively. By minimizing the state that nodes must maintain, Fuel speeds up transaction processing, leading to faster confirmation times and a more responsive network compared to other blockchain solutions.
  • Arbitrum One: Leverages state channels and off-chain computation to minimize on-chain state, reducing the load on the Ethereum mainnet. By conducting most transactions and contract executions off-chain, Arbitrum enhances scalability and lowers costs. The system uses the Arbitrum Virtual Machine (AVM) and EthBridge to efficiently compile and execute Solidity contracts off-chain while ensuring security through its AnyTrust guarantee. If disputes arise, Arbitrum’s on-chain resolution mechanism swiftly and economically handles them, ensuring minimal impact on the Ethereum network.
  • Base: Utilizes state minimization techniques similar to Arbitrum, focusing on efficient data usage and reducing on-chain state to enhance scalability. By minimizing the amount of data that needs to be stored and managed on-chain, Base improves transaction efficiency and supports higher throughput, making the network more scalable and responsive.

Interoperability

  • Fuel: Fuel's modular architecture is designed for interoperability by separating the execution layer from other components, such as the consensus and data availability layers. This separation allows Fuel to interact with other rollups and blockchains by implementing cross-chain messaging protocols and bridges. These features potentially enhance cross-chain compatibility, making Fuel a versatile and adaptable part of the broader blockchain ecosystem.
  • Arbitrum One: Arbitrum achieves high interoperability with Ethereum through its use of standard Ethereum addresses and compatibility with the Ethereum Virtual Machine (EVM). This enables seamless asset transfers and interactions with Ethereum’s Layer 1 and other Layer 2 solutions. Arbitrum also uses its custom-built bridges to facilitate secure communication and value transfer between Arbitrum and the Ethereum mainnet.
  • Base: Base is designed with interoperability as a key focus by adhering to EVM-equivalence and integrating directly with Ethereum’s Layer 1. It leverages standard Ethereum protocols and tooling, ensuring that assets and data can move freely across the Ethereum network and other rollups. Additionally, Base incorporates cross-chain bridges and Coinbase's existing infrastructure to enhance its compatibility within the broader blockchain ecosystem.

Development Tools

  • Fuel: Fuel offers a new programming language called Sway, specifically optimized for the FuelVM. Sway is designed to help developers write efficient and high-performance smart contracts tailored to Fuel's architecture. In addition to the language, Fuel provides a robust developer environment, including custom-built tools like Forc and Fuelup, which streamline the development process for applications running on the Fuel network.
  • Arbitrum One: Arbitrum provides broad support for existing Ethereum development tools such as Solidity, Foundry, and Hardhat. This ensures that developers can easily port their applications from Ethereum to Arbitrum without needing to learn new languages or adapt to different tools. Arbitrum's developer environment is fully compatible with the Ethereum ecosystem, enabling a smooth transition and leveraging existing knowledge and workflows.
  • Base: Base focuses on ease of use by offering full support for standard Ethereum development tools, including Solidity, Foundry, Hardhat, and others. This compatibility ensures that developers can build on Base without altering their existing processes. Furthermore, Base integrates seamlessly with Coinbase's developer products, providing additional resources and tools to create a streamlined development experience, particularly for consumer-facing applications.

Security

  • Fuel: Fuel prioritizes security by leveraging advanced cryptographic techniques and a rigorous approach to system design. It emphasizes decentralization and resilience, aiming to create an execution layer that is robust against vulnerabilities common in complex blockchain environments. Fuel employs cutting-edge cryptographic methods to secure its consensus mechanism, transaction processing, and state management, ensuring that the network remains secure even under adverse conditions.
  • Arbitrum One: Arbitrum enhances security through its fraud-proof system, which ensures that all off-chain computations are verifiable and disputes can be efficiently resolved on-chain. This security model is built on Arbitrum's AnyTrust protocol, which provides strong guarantees against fraudulent activities. Extensive audits by top security researchers and a focus on secure operational practices further reinforce Arbitrum’s commitment to maintaining a highly secure Layer 2 solution.
  • Base: Base places a strong emphasis on security, leveraging the same security model as other optimistic rollups, which includes a robust fraud-proof system to validate off-chain computations. Additionally, Base benefits from Coinbase's institutional-grade security practices, including rigorous audits, comprehensive security reviews by top security researchers, and adherence to best practices in both software development and operational security. This combination ensures a highly secure environment for developers and users alike.

Ecosystem and Adoption

  • Fuel: Still in its early stages but rapidly growing due to its high-performance promises. The ecosystem is more specialized and might attract developers looking to push the boundaries of blockchain throughput.
  • Arbitrum One: One of the most widely adopted rollups with a large and growing ecosystem. It is favored by many existing Ethereum dApps for scaling.
  • Base: Backed by Coinbase, Base is positioned for rapid adoption, particularly by projects that are looking to leverage Coinbase’s vast user base and financial infrastructure.

Future Prospects

  • Fuel: Although still in its early stages, Fuel is rapidly growing due to its high-performance capabilities. Its ecosystem is more specialized, likely attracting developers who are focused on pushing the boundaries of blockchain throughput and performance.
  • Arbitrum One: Arbitrum is one of the most widely adopted rollups, boasting a large and expanding ecosystem. It is favored by many existing Ethereum dApps for scaling, making it a popular choice for developers looking to enhance their application's performance without leaving the Ethereum ecosystem.
  • Base: Backed by Coinbase, Base is well-positioned for rapid adoption, particularly by projects aiming to leverage Coinbase’s vast user base and financial infrastructure. This strong backing gives Base a significant advantage in attracting developers and users alike.

Community and Governance

  • Fuel: Fuel’s community is relatively small but steadily growing, particularly among developers and early adopters. As the ecosystem matures, governance is expected to become more decentralized, allowing the community to have greater influence over the network’s future direction. The community actively engages through channels such as the Fuel Discord and Fuel Technical Forum, where discussions on development and governance are ongoing.
  • Arbitrum One: Arbitrum features active community governance through the Arbitrum DAO, which allows token holders to participate in key decisions about the network's future. The DAO model empowers the community to have a direct say in protocol upgrades and governance proposals. Community discussions and governance activities are primarily coordinated through the Arbitrum Discord and Arbitrum Twitter, along with formal proposals posted on Arbitrum’s governance forums.
  • Base: While Base’s governance model is still being established, it is anticipated to align closely with Coinbase’s strategic vision, potentially blending centralized oversight with decentralized community involvement as the project evolves. The Base community engages through platforms such as the Base Twitter, where updates are shared. As the project matures, more formal governance structures are likely to be introduced, enabling greater community participation.

2. Description of Fuel

Fuel is an advanced operating system specifically designed for Ethereum Rollups. It addresses key challenges in the blockchain space, such as parallelization, state minimized execution, and interoperability, without compromising on any aspect. Fuel's innovative approach ensures higher performance and efficiency for rollups.

Key Components of Fuel:

  • FuelVM
    • Enhanced Ethereum VM: FuelVM incorporates long-suggested improvements to the Ethereum Virtual Machine (EVM) that couldn't be implemented due to backward compatibility constraints.
    • Parallel Transaction Execution: It supports parallel transaction execution, enabling the use of multiple CPU threads and cores that are often idle in single-threaded blockchains.
    • UTXO Model: By using a strict state access list in the form of a UTXO model, FuelVM allows full nodes to identify transaction dependencies before execution, significantly boosting compute, state access, and transactional throughput.
  • Sway Language
    • Developer Experience: Fuel introduces Sway, a domain-specific language (DSL) designed for a superior developer experience.
    • Based on Rust: Sway is based on Rust, incorporating its safety-first semantics and compile-time analysis features.
    • Smart Contract Paradigm: From Solidity, Sway adopts the concept of a smart contract language with built-in top-level contract storage and blockchain mechanisms, ensuring ergonomic and safe contract programming.
    • Static Auditing: Sway supports static auditing for smart contracts, enhancing safety and reliability.
    • Performance and Optimization: Sway is highly performant with extensible optimization passes and a modular backend, capable of targeting various blockchain architectures.
  • Fuel Token Bridge
    • Seamless L1-L2 Communication: The Fuel Token Bridge enables smooth and secure interaction between Ethereum (L1) and Fuel (L2), facilitating asset transfers and data exchanges across these layers.
    • Advanced Message Protocol: The bridge operates with a robust protocol that ensures the integrity and efficiency of transactions, utilizing concepts like UTXOs, epochs, and finality.
    • Cross-Layer Integration: By managing the complexities of cross-layer communication, the Fuel Token Bridge enhances the interoperability and scalability of blockchain applications.
  • Sway Libraries
    • Extending Functionality: Sway Libraries provide a collection of utilities and helper functions that extend the capabilities of Sway beyond the standard library, aiding developers in blockchain development.
    • Variety of Libraries: These include libraries for convenience functions, standards support, data types, security functionalities, and more, ensuring developers have the tools they need for robust contract development.
    • Asset Libraries: Focused on Native Assets, these libraries provide helper functions for working with standards like SRC-20, SRC-3, and SRC-7 on the Fuel Network.
    • Access Control and Security: Sway includes libraries like the Ownership, Admin, Pausable, and Reentrancy Guard libraries, which enhance the security of smart contracts by providing mechanisms for access control and protection against attacks.
    • Cryptography Libraries: These libraries extend cryptographic functionalities beyond what the standard library offers, including tools like the Bytecode and Merkle Libraries for on-chain verification and off-chain computation verification.
    • Math and Data Structures: The Sway Libraries also include specialized libraries for mathematical operations and complex data structures, such as the Fixed Point Number Library, Signed Integers, and the Queue library, which enable advanced functionality in smart contracts.
NOTE: Sway is a language under heavy development therefore the libraries may not be the most ergonomic. Over time they should receive updates / improvements in order to demonstrate how Sway can be used in real use cases.
  • Sway Standards
    • Standardized Development: Sway Standards provide a repository of standards for the Sway language, enabling consistent and reliable contract development across the Fuel ecosystem.
    • Draft and Proposed Standards: The repository contains standards at various stages of development, encouraging the use of draft standards and providing opportunities for community feedback to refine and improve these standards.
    • Integration with Forc: To use a standard, developers can easily import it by adding the appropriate entry to their Forc.toml file, ensuring seamless integration into Sway smart contracts.
    • Comprehensive Range of Standards: The repository includes a variety of standards, such as SRC-20 for Native Assets, SRC-3 for Mint and Burn functionality, SRC-5 for Ownership control, and many more, covering aspects from asset management to security and contract deployment.
    • Community-Driven Development: Developers are encouraged to propose new standards and contribute to the evolution of Sway standards, fostering a collaborative environment that drives innovation in the Fuel ecosystem.
    • Documentation and Implementation: Each standard is accompanied by detailed documentation, including how to implement the standard ABI in your contracts, ensuring developers can efficiently adopt and utilize these standards in their projects.
  • Fuel TypeScript SDK
    • Comprehensive Development Toolkit: The Fuel TypeScript SDK provides a range of methods and utilities in TypeScript, allowing developers to efficiently build on and interact with the Fuel network.
    • Contract Deployment and Testing: It enables seamless deployment, interaction with, and testing of Sway contracts directly within the TypeScript environment.
    • dApp and Development Environment: Developers can quickly bootstrap decentralized applications and set up local development environments using the create fuels CLI.
    • Secure Wallet Management: The SDK supports generating and importing wallets from private keys, mnemonics, or JSON files, with secure client-side storage options.
    • Custom Transaction Crafting: Developers can craft and modify transactions by adding resources, policies, and signers, ensuring flexibility and control over transaction submissions.
    • Type Safety with Typegen: The SDK integrates typegen to generate types for Sway programs, ensuring end-to-end type safety throughout the development process.
  • Fuel Rust SDK
    • Versatile Development Toolkit: The Fuel Rust SDK provides developers with the tools needed to compile, deploy, and test Sway contracts within the Rust environment.
    • Network Interaction: It supports both using the testnet and running a local Fuel node, enabling robust testing and deployment workflows.
    • Custom Transaction Handling: Developers can craft and sign transactions with hand-crafted scripts or contract calls, offering fine-grained control over transaction execution.
    • Type-Safe Rust Bindings: The SDK allows for generating type-safe Rust bindings of contract ABI methods, ensuring secure and reliable contract interactions.
  • Fuel Wallet SDK
    • Unified Wallet Connection: The Fuel Wallet SDK acts as a connection manager, allowing your dApp to connect to the Fuel Wallet and any other wallet compatible with the Fuel Network through a unified API.
    • Seamless Integration: It simplifies the process of integrating wallet connectivity into your dApp, with support for both React and non-React environments.
    • Installation and Setup: The SDK can be easily installed via npm, along with the necessary @fuels/connectors and fuels packages, ensuring seamless communication with the Fuel Network.
    • Default and Custom Connectors: Developers can use default connectors provided by the SDK or create custom connectors to tailor the connection experience.
    • React Support: For React developers, the SDK offers a set of hooks and a user interface (UI) for effortless interaction with connectors, streamlining the development of wallet-connected dApps.
  • Fuel GraphQL API
    • Powerful Query Interface: The Fuel GraphQL API enables developers to query the Fuel blockchain for a wide range of on-chain data, including transactions, balances, block information, and more.
    • Transaction Simulation and Submission: It allows users to simulate transactions before submitting them, ensuring accuracy and reliability in transaction processing.
    • Interactive Playground: The API is complemented by an interactive GraphQL playground, an IDE that provides a graphical interface for testing queries, mutations, and types, along with query validation and schema context.
    • Accessible RPC Endpoint: Developers can access the Fuel GraphQL API via a dedicated RPC endpoint, making it easy to integrate into various applications and workflows.
  • Forc
    • Fuel Orchestrator Tooling: Forc, short for Fuel Orchestrator, is a powerful command-line toolset designed for developers working within the Fuel ecosystem.
    • Project Scaffolding and Management: Forc provides a variety of commands for scaffolding new projects, formatting code, running scripts, deploying contracts, and more, offering a streamlined development experience.
    • Testing and Deployment: Developers can use Forc to test and deploy Sway contracts efficiently, making it an essential tool for project lifecycle management in Fuel.
    • Rust-Like Experience: Forc is inspired by Rust’s cargo tool, making it familiar to developers with a Rust background and providing similar functionalities tailored to the Fuel ecosystem.

FuelVM

FuelVM is a specialized virtual machine designed to advance the Ethereum ecosystem by implementing long-suggested improvements to the Ethereum Virtual Machine (EVM). It addresses limitations that couldn't be overcome in the EVM due to the need for backward compatibility. Key features include parallel transaction execution and support for multiple native assets.

FuelVM’s architecture leverages strict state access lists in a UTXO model, allowing it to execute transactions in parallel. As a result, Fuel delivers unmatched processing capacity, utilizing far more threads and cores of your CPU, which are typically idle in single-threaded blockchains. This allows Fuel to provide far greater compute, state accesses, and transactional throughput than its single-threaded counterparts.

FuelVM Specification Overview

Introduction

FuelVM is purpose-built to support Ethereum rollups, focusing on scalability, performance, and security. The specification outlines the types, instruction set, and execution semantics critical to the VM’s operation.

Key Parameters

  • CONTRACT_MAX_SIZE: Maximum contract size in bytes.
  • VM_MAX_RAM: 64 MiB of maximum RAM allocation.
  • MESSAGE_MAX_DATA_SIZE: Maximum size of message data in bytes.

Semantics and Instruction Set

  • FuelVM instructions are 32 bits wide, combining an 8-bit opcode, 6-bit register identifier, and an immediate value of 12, 18, or 24 bits.
  • 64 registers are available, with the first 16 reserved for special purposes (e.g., program counter, stack pointer, heap pointer).

VM Initialization

  • A monolithic memory of VM_MAX_RAM bytes is allocated at each run.
  • A stack and heap model is used for dynamic memory allocation, with the stack growing upwards and the heap downwards.

Contexts and Execution

FuelVM supports four execution contexts: predicate estimation, predicate verification, scripts, and calls. These contexts define isolated execution environments, each with its own memory ownership and execution rules.

  • Predicate Estimation & Verification: Evaluates whether a transaction’s UTXO predicates (conditions for spending) are met, using a set amount of gas.
  • Script Execution: Involves running transaction scripts with specified gas limits, validating the transaction and updating the blockchain state.
  • Call Frames: Manage memory access and execution rights during cross-contract calls, ensuring that each contract’s state is isolated and secure.

Ownership and Executability

FuelVM enforces strict memory ownership rules, ensuring that each context or contract can only access its allocated memory regions. Memory outside these boundaries is non-executable, providing strong protection against unauthorized access or modification.

UTXO Model in FuelVM

The UTXO (Unspent Transaction Output) model implemented by FuelVM is a fundamental departure from the account-based model used in Ethereum. In a UTXO system, each transaction output is treated as a unique and discrete unit, akin to individual currency bills, whereas Ethereum tracks balances as cumulative totals, similar to a bank account.

Why UTXOs Matter

The UTXO model offers enhanced transparency, security, and flexibility in transaction management. Each UTXO corresponds to a specific amount, providing fine-grained control over how digital assets are spent and tracked. This model is particularly well-suited for high-performance environments like FuelVM, where parallel execution and state minimization are critical.

UTXOs in Action

To illustrate how UTXOs function within FuelVM, consider the following detailed example:

  1. Selecting UTXOs: Suppose you have the following UTXOs in your FuelVM account: You wish to send 15 units to another user, with a transaction fee of 1 unit. The FuelVM SDK selects UTXO 2 (20 units) to cover the total cost of 16 units (15 units to the recipient plus 1 unit for the fee).
  • UTXO 1: 10 units
  • UTXO 2: 20 units

    You wish to send 15 units to another user, with a transaction fee of 1 unit. The FuelVM SDK selects UTXO 2 (20 units) to cover the total cost of 16 units (15 units to the recipient plus 1 unit for the fee).
  1. Spending UTXOs: Once UTXO 2 is selected, it is fully spent to execute the transaction. The 15 units are transferred to the recipient, and the 1 unit is deducted as a transaction fee.
  2. Generating New UTXOs: Since the selected UTXO was larger than the total transaction cost, a new UTXO is created to return the change. In this case, a new UTXO worth 4 units (20 - 16 = 4) is generated and added back to your account.

Transaction Flow Example

Let’s break down the transaction flow further:

  • Initial State:
    • UTXO 1: 10 units
    • UTXO 2: 20 units
  • Transaction:
    • Sending 15 units with a 1 unit fee.
  • Processing:
    • FuelVM selects UTXO 2 (20 units).
    • 15 units are transferred to the recipient.
    • 1 unit is deducted as a fee.
  • Result:
    • UTXO 2 is marked as spent and cannot be used again.
    • A new UTXO of 4 units is created and added to your account.

After this transaction, your FuelVM account will have:

  • UTXO 1: 10 units
  • New UTXO: 4 units

Benefits of UTXO in FuelVM

  • Parallel Processing: By handling UTXOs as independent entities, FuelVM can execute multiple transactions simultaneously, as long as they don’t touch the same UTXOs, significantly enhancing throughput.
  • State Minimization: The UTXO model naturally minimizes the state by ensuring that spent UTXOs are removed from the system, helping to keep the blockchain’s state size under control.
  • Transparency: Each transaction’s inputs and outputs are explicitly defined, making it easier to audit and verify transactions.

Fuel's Token Bridge

To help you better understand how everything works together, let's take a deep dive into how the Fuel Token Bridge operates under the hood. Fuel's Token Bridge seamlessly facilitates interactions between Ethereum (L1) and Fuel (L2). In this exploration, we'll cover the foundational concepts, the bridge's flow, and the unique mechanisms that power communication between these two layers.

Core Concepts

To understand the operations of the Fuel Bridge, it's essential to clarify some key concepts that will be referenced throughout:

  • Layer 1 (L1): The Ethereum blockchain, where smart contracts and assets originate.
  • Layer 2 (L2): The Fuel blockchain, designed to scale Ethereum by offloading transaction processing.
  • Fuel Block: A unit of the Fuel blockchain containing transactions and cross-layer messages.
  • Epoch: A collection of Fuel blocks that are grouped and finalized together.
  • Messages: Data packets exchanged between L1 and L2, categorized as either incoming or outgoing.
  • Relayed Messages: Messages from L2 that need to be sent and validated on L1.
  • Fuel Sequencers: Validators on L2 who manage transactions and maintain the blockchain's state.
  • Finality: The point at which a transaction or message is considered irreversible and permanent.
  • Bridge Contracts: Smart contracts on both L1 and L2 that manage asset transfers and message validation.

Architectural Overview

The Fuel Bridge is a sophisticated system designed to facilitate seamless communication between Ethereum and Fuel. It operates using an advanced message protocol that ensures secure and efficient transmission of data and assets between the two layers.

Message Flow from Ethereum (L1) to Fuel (L2)

Fuel’s message-passing system allows users to send messages and assets from Ethereum to Fuel. The process is initiated on Ethereum and completed by Fuel's sequencers as follows:

  1. Event Emission: An Ethereum user interacts with the FuelMessagePortal contract on L1, triggering the sendMessage function, which may include an attached ETH value.
  2. Event Listening: Fuel sequencers monitor for the MessageSent event emitted by this interaction, parsing the message and preparing it for inclusion in a Fuel block.
  3. UTXO Creation: The message is converted into an Unspent Transaction Output (UTXO) on L2, reflecting the original Ethereum message within the Fuel blockchain.
  4. Recipient Action: The recipient on L2 can utilize this UTXO, enabling them to interact within the Fuel network with the transferred assets or data.

This ensures that messages and assets are securely transferred and integrated into the Fuel ecosystem.

Message Flow from Fuel (L2) to Ethereum (L1)

The Fuel Bridge also supports the return flow from L2 to L1, involving a more complex process that ensures the validity of L2 transactions on L1:

  1. MessageOut Receipt: Users on Fuel initiate transactions that generate MessageOut receipts, specifying details like the recipient’s address on Ethereum and the amount to be transferred.
  2. Block Commitment: These transactions are collected into blocks by Fuel sequencers, which are then grouped into epochs. The last block of an epoch is committed to Ethereum via the FuelChainState contract.
  3. Finalization: After a set period, the committed epoch is finalized on Ethereum, making the transactions within it immutable.
  4. Proof Submission: Users on Ethereum submit proof of the L2 transaction's inclusion in a finalized epoch to the FuelMessagePortal contract, triggering the release of corresponding assets or execution of the associated action on L1.

This process ensures that any message or asset moving from L2 to L1 is verified and trustworthy.

ETH and ERC20 Asset Transfers

The Fuel Bridge supports the transfer of both ETH and ERC20 tokens. Below are the simplified steps for each:

ETH Transfer from Ethereum to Fuel

  1. User Interaction: The user sends ETH to the FuelMessagePortal contract on Ethereum.
  2. Message Inclusion: Fuel sequencers detect the transaction and include it as a UTXO on Fuel.
  3. UTXO Spend: The recipient on Fuel can now spend the ETH as a UTXO in the L2 environment.

ERC20 Transfer from Fuel to Ethereum

  1. Burn Tokens: The user initiates a transaction on Fuel, burning their ERC20 tokens and generating a MessageOut receipt.
  2. Block Commitment: This receipt is committed to Ethereum in a finalized Fuel epoch.
  3. Proof and Withdrawal: The user submits proof of the transaction on Ethereum, and the FuelERC20Gateway releases the equivalent ERC20 tokens on Ethereum.

L2 (Fuel) ETH Withdrawal

ETH withdrawals from the Fuel blockchain to Ethereum involve generating a MessageOut receipt, specifying the desired Ethereum address as the recipient and the amount to be withdrawn.

Withdrawal Process

  1. Transaction Initiation:
    • A Fuel entity initiates a transaction generating a MessageOut receipt, specifying the Ethereum address and the withdrawal amount.
    • This transaction is picked up by the L2 network and included in one of its blocks.
  2. Epoch Commitment:
    • A block committer updates the FuelChainState contract on Ethereum by committing the last epoch of the Fuel blockchain.
    • After a certain time period, the epoch is considered valid, allowing the user to proceed.
  3. Proof Submission and ETH Release:
    • The user gathers the necessary Merkle proofs that validate the L2 chain’s activity.
    • The user calls the relayMessage function in the FuelMessagePortal contract, providing the proofs.
    • Upon validation, the ETH locked in the portal contract is released to the specified recipient on Ethereum.

L2 (Fuel) ERC20 Withdrawal

ERC20 withdrawals from the Fuel blockchain to Ethereum involve a message-passing mechanism from L2 to L1 entities.

Withdrawal Process

Transaction Initiation:

  • The user sends a transaction to the L2 Bridge Contract's withdraw function, along with the tokens to be withdrawn.
  • The function burns the tokens and generates a MessageOut receipt directed to the L1 Bridge Contract, with the payload containing an ABI-encoded call to finalizeWithdrawal.

Epoch Commitment and Finalization:

  • The block containing the receipt is committed through the block committer.
  • After the epoch is committed and finalized on L1, the user prepares the necessary proofs of inclusion.

Proof Submission and Token Release:

  • The user calls the relayMessage function in the FuelMessagePortal contract with the proofs.
  • Upon validation, the L1 Bridge Contract’s finalizeWithdrawal is executed, and the tokens are released to the recipient.

Block Committing

The Fuel blockchain is designed for scalability, enabling it to generate blocks at a faster rate compared to other blockchains without compromising on security. This is achieved through a hybrid optimistic-ZK rollup approach, where the Fuel blockchain inherits the security of the Layer 1 (L1) blockchain it is anchored to.

Block Creation and Commitment Process

Block Generation:

  • The Fuel blockchain continuously generates blocks containing transactions and cross-layer messages.
  • These blocks are grouped into epochs (e.g., an epoch may consist of 10,800 blocks). The last block of each epoch summarizes and identifies the entire epoch.

Epoch Commitment:

  • The last block of an epoch is committed to the L1 blockchain through a transaction to the FuelChainState contract.
  • This transaction is accepted optimistically, meaning it is considered valid unless proven otherwise. Validation of blocks and decentralization of entities that commit blocks are outside the scope of this document.
  • The commitment is registered with a timestamp from the L1 blockchain.

Finalization:

  • After a designated time period, the commit and its corresponding block are considered final.
  • This finalization allows entities on the L1 chain to execute and relay messages originating from the L2 chain to their L1 recipients.

Decimals Adjustment

Fuel employs a design principle focused on minimizing execution costs and state growth. One aspect of this is using 64-bit integers (u64) to represent balances, in contrast to the 256-bit integers used by the ERC20 standard on Ethereum.

Key Considerations:

  • Precision Loss: The difference in bit size and decimal precision (9 decimals on Fuel vs. 18 on Ethereum) can lead to precision loss when bridging amounts. Fuel enforces deposits that do not incur dust losses, rejecting transactions that would otherwise lose precision.
  • Refund Mechanism: If a transferred amount exceeds Fuel’s capacity to mint the L2 counterpart, a refund message is generated, allowing users to retrieve the original deposit on L1.

DApps interacting with the bridge should be aware of these limitations and truncate amounts accordingly to avoid transaction reverts.

Incompatibilities and Single Points of Failure (SPoF)

ERC20 Incompatibilities

Some ERC20 tokens may not be fully compatible with the Fuel bridge, particularly those with:

  • Rebasing balances
  • Fee on transfer
  • Hyper supply (> 2^64 units) or hyper precision (high decimal counts)

These tokens may exhibit unexpected behavior or result in a total loss of funds.

Single Points of Failure (SPoF)

Critical entities within the system perform mission-critical tasks, including:

  • Security Council and Smart Contract Ownership: Managed by a security council (via multisig), responsible for key administrative functions.
  • Fuel Blockchain Sequencer/Validator: Currently operates under a Proof of Authority scheme. Compromise of the private key could lead to rogue block generation.
  • Block Committer: Links Fuel blockchain activity with Ethereum. Rogue data uploaded by a block committer could enable fraudulent behavior if undetected within the finalization window.

Users should exercise caution and stay informed of these risks when interacting with the Fuel bridge system.

3. Description of Sway

Sway is a domain-specific programming language designed for creating smart contracts on blockchain platforms, particularly the Fuel Virtual Machine (Fuel VM). Inspired by Rust's systems programming approach, Sway brings modern programming features and tooling to smart contract development while ensuring performance, control, and security through extensive static analysis.

Why Use Sway?

Domain-Specific Design: Sway is tailored for the blockchain environment, allowing it to optimize trade-offs for fast, secure, and cost-effective smart contracts with features suited to blockchain needs.

Advantages Over Solidity: Unlike Solidity, which is limited by the Ethereum Virtual Machine's historical quirks, Sway offers a modern language with generics, algebraic types, and trait-based polymorphism. It also provides a comprehensive toolchain with code completion, formatting, documentation generation, and deployment tools, ensuring a smooth development process.

Advantages Over Rust: While Rust excels in general systems programming, its complex memory management is costly in the blockchain context. Sway, written in Rust, adapts its benefits—like a modern type system and safety features—to the blockchain environment, offering familiar syntax and powerful features without Rust's overhead.

In conclusion Sway combines the best of modern programming practices with blockchain-specific optimizations, providing a robust, secure, and efficient language for smart contract development.

Sway Program Types

A Sway program has a specific type: contract, predicate, script, or library. The first three types are deployable to the blockchain, while a library is designed for code reuse and is never directly deployed. Each Sway file must declare its program type, and a project can include multiple libraries but only one contract, script, or predicate. Scripts and predicates require main functions as entry points, while contracts publish an ABI.

Contracts: Used for protocols or systems operating within fixed rules, such as staking contracts or decentralized exchanges (DEX).

Scripts: Facilitate complex on-chain interactions that are temporary, like creating a leveraged position through a series of transactions on a DEX and Lender.

Libraries: Contain reusable code for common tasks, such as fixed-point or big number math.

Sway Language Basics

Sway is a statically typed, compiled language with type inference and traits, designed to make smart contract development safer and more efficient through strong static analysis and compiler feedback. Here's a quick overview of Sway's basic elements:

Variables

Variables in Sway are immutable by default, but can be made mutable using mut

1// Immutable variable
2let foo = 5;
3
4// Mutable variable
5let mut foo = 5;
6foo = 6;

Built-in Types

Sway supports several primitive types:

1let a: u64 = 42;
2let b: bool = true;
3let c: str[4] = __to_str_array("sway");

Functions

Functions in Sway are declared using the fn keyword.

1fn add(a: u64, b: u64) -> u64 {
2    a + b
3}

Structs, Tuples, and Enums

Sway supports struct types for grouping related data, tuples for fixed-size collections of multiple types, and enums for defining types that can be one of several variants.

1struct Point {
2    x: u64,
3    y: u64,
4}
5
6let p = Point { x: 10, y: 20 };
7
8enum Color {
9    Red: (),
10    Green: (),
11    Blue: (),
12}
13
14let color = Color::Red;

Methods and Associated Functions

Methods and associated functions are defined within impl blocks.

1struct Foo {
2    bar: u64,
3    baz: bool,
4}
5
6impl Foo {
7    fn is_baz_true(self) -> bool {
8        self.baz
9    }
10
11    fn new(bar: u64, baz: bool) -> Foo {
12        Foo { bar, baz }
13    }
14}

Constants

Constants are immutable values that are evaluated at compile time.

1const MAX_LIMIT: u64 = 100;

Control Flow

Sway supports standard control flow constructs like if, else, match, while, and for.

1fn main() {
2    let number = 6;
3
4    if number % 2 == 0 {
5        // Even number
6    } else {
7        // Odd number
8    }
9
10    let result = match number {
11        1 => "one",
12        2 => "two",
13        _ => "other",
14    };
15}

Sway combines modern programming practices with blockchain-specific optimizations, providing a robust, secure, and efficient language for smart contract development. With its clear structure and support for various types and control flow mechanisms, Sway ensures developers can create tailored solutions for diverse blockchain applications.

Conclusion

In conclusion, Fuel and the Sway programming language provide a robust and user-friendly environment for developing high-performance decentralized applications on Ethereum. With Fuel's advanced features and Sway's modern, blockchain-optimized syntax, creating secure and efficient smart contracts becomes straightforward.

This concludes Part I of this Fuel Ecosystem Deep-dives!

In the next and final section, we will explore these capabilities in action by building an English Auction contract. This example will demonstrate how Sway's tools and features can be leveraged to create decentralized solutions like an English Auction, which operates without a third party and ensures strong settlement assurances.
Stay tuned as we dive into the implementation and testing of this contract using Harness!

Reach out to Three Sigma, and let our team of seasoned professionals guide you confidently through the Web3 landscape. Our expertise in smart contract security, economic modeling, and blockchain engineering, we will help you secure your project's future.

Contact us today and turn your Web3 vision into reality!