# Fuel 101
###### tags: `FuelJourney`
## What is Fuel?
Fuel is the fastest execution layer for the modular blockchain stack. Fuel delivers maximum security and the highest flexible throughput for decentralized applications, with a focus on a superior developer experience.
## Overview
Before learning about Fuel's technology stack, let's understand the premise of Fuel as a modular execution layer and its role in scaling Ethereum.
### The Modular Blockchain Paradigm
The blockchain space is moving away from the traditional monolithic design, towards a new design paradigm called Modular Blockchains to achieve massive scalability.
Let's understand what modular blockchains are, what are the fundamental differences between monolithic and modular designs, and why do we need modular blockchains.
#### What is a modular blockchain?
Blockchains comprise of four main components:
1. **Execution**: Transaction execution to update state
2. **Settlement**: Dispute resolution and bridging
3. **Consensus**: State definition and validation
4. **Data availability**: Making block data available
Traditionally, all of the four components above, put together in a single tightly coupled layer, form a monolithic design for blockchains. Blockchains are now moving away from this monolithic design, giving rise to modular blockchains.
A modular blockchain decouples the various components of the tightly coupled layer to allow for specialization at a specific layer, delivering significant optimizations.
#### Monolithic vs. Modular Execution Layer
**Monolithic Architecture:** Monolithic L1s do not separate the execution layer from the consensus, settlement and data avalability layers. As a result, the resources available are limited.
Some constraints and challenges with a monolithic architecture:
- **Costly & inefficient transaction verification:** Transaction verification requires full nodes to download the entire chain and execute them locally, leading to costly verification.
- **Resource constraints:** Throughput is constrained by the resource requirements of a single node since the blockchain is replicated, not distributed, across nodes.
- **Shared resources:** Operating all four functions of the blockchain on the same finite set of compute resources means lesser capacity for each individual component.
- **Scalability:** Coupling computation and verification on the same layer leads to and limited scalability.
**Modular Execution Layer:** On the other hand, **Fuel is a Modular Execution Layer** that is designed for high-bandwidth modular blockchains and can better capitalize on high shared data availability. It also has the following additional properties:
- **Trust-Minimised Light Clients:** With a modular execution layer, users can run an off-chain light client, allowing users to validate the chain without running a full node.
Fuel’s design lets light clients validate blocks through fraud proofs. This eliminates the need for a trusted party while maintaining low resource requirements and achieving high security. For monolithic chains like Ethereum, there is an ideological incentive to keep the computation requirements for full nodes low to allow users to be truly sovereign.
Because Fuel was built for fraud proofs, the resource requirements for full nodes can be higher, thus increasing bandwidth capacity while still allowing users to verify the chain through trust-minimized light clients.
- **Flexibility:** A modular execution layer is not tightly coupled to a specific layer-1, allowing for greater flexibility and to operate in multiple different configurations, for instance:
- **As a rollup or L2**
A rollup is an off-chain network built on top of an L1 that executes transactions off-chain, bundles them, and posts them as a single transaction on the L1.
Fuel is designed to run a modular execution layer, similar to rollups or layer-2s on Ethereum. L2s and rollups are typically not optimized for large L1 bandwidth, unlike Fuel, which is uniquely configured for that capability.
- **As an L1**
An L1 is a blockchain network responsible for handling all functions of a chain including settlement, execution, data availability, and consensus.
The Fuel technology includes all these functions to run as an L1. The common configurations for running in this mode would be proof-of-authority and a proof-of-stake via a Tendermint-BFT style.
> ❗️Note: While Fuel can run in this configuration, its mission is to enhance existing blockchains such as Ethereum as a high-performance execution layer.
- **As a state channel**
A state channel is a smart contract that enforces off-chain transactions between predefined parties. Each transaction updates the state of the chain and is cryptographically provable on-chain.
The FuelVM is well suited for multi-party channel designs where all parties must have access over the chain's state at each communication step.
- **As a sidechain**
A sidechain is a blockchain with a one-way trust-minimized bridge from the base chain.
The Fuel technology can also run as a sidechain to an existing L1. This means there is a message passing bridge between the L1 and Fuel. In this configuration, data availability would be handled by the side chain, while settlement is handled by the L1.
There would also be an option to run it in a semi-provable configuration, whereby fraud proofs can be used to ensure better validity guarantees using the L1 as an arbitrator.
#### Why do we need Modular Blockchains?
- Highest security & flexible throughput
- Scalability without compromising security & decentralization
In order to achieve high throughput, most blockchains sacrifice security and/or decentralization. The true challenge is to design a system that solves for the "Scalability Trilemma" i.e., a system that is scalable, secure, and decentralized.
In the next sections, you will learn how the Fuel technology is designed to enable scalability on Ethereum while keeping the above two criteria in mind.
## Fuel: The Fastest Modular Execution Layer
Now that you have understood the problem with the existing L2s and the role of Fuel in enabling massive scalability on Ethereum, let's dive deeper into Fuel's technology and how it optimizes modular execution.
Fuel defines a modular execution layer as a verifiable computation system designed for the modular blockchain stack.
More concretely, a fraud- or validity-provable blockchain that leverages a modular blockchain for data availability.
### Highest security & flexible throughput
Fuel specializes in achieving high security & flexible throughput using the following key technologies:
1. **Parallel transaction execution**
2. **Fuel Virtual Machine (FuelVM)**
3. **Developer tooling with Sway Language and Forc**
### Parallel Transaction Execution
Fuel delivers unmatched processing capacity through its ability to execute transactions in parallel by using strict state access lists in the form of a UTXO model. This enables Fuel to use far more threads and cores of your CPU that are typically idle in single-threaded blockchains. As a result, Fuel can deliver far more compute, state accesses, and transactional throughput than its single-threaded counterparts.
#### State Access Lists and UTXOs
Fuel supports parallel transaction execution through strict (i.e. mandatory) access lists, similar to EIP-648. Each transaction must specify which contracts the transaction may interact with; if a transaction attempts to access a contract not in this list then execution will revert. With these access lists, execution can be done in parallel across transactions that touch disjoint sets of contracts. See here for additional context.
Access lists are implemented with UTXOs. UTXOs give other nice properties, but for the purposes of parallel transaction execution serve simply as strict access lists.
### Sway Language: Fuel's Rust-based DSL
Fuel provides a powerful and sleek developer experience with our own domain-specific language, called [Sway](https://twitter.com/swaylang), and a supportive toolchain, called [Forc](https://crates.io/crates/forc) (the Fuel Orchestrator).
The Fuel development environment retains the benefits of smart contract languages like Solidity, while adopting the paradigms introduced in the Rust tooling ecosystem. Now, developers can have a completely vertically-integrated experience where every component from the virtual machine through to the CLI works in harmony.
**Resources to get started with Sway:**
- [Sway Book](https://fuellabs.github.io/sway/latest/)
- [Sway Reference Applications](https://github.com/FuelLabs/sway/tree/master/examples)
- [Workshop: Developing Smart Contracts with Sway](https://www.youtube.com/watch?v=SctJwG2LPK8)
### The Fuel Virtual Machine
The FuelVM is a a blazingly fast verifiable blockchain virtual machine. It is designed to reduce wasteful processing of traditional blockchain virtual machine architectures, while vastly increasing the potential design space for developers.
The FuelVM learns from the Ethereum ecosystem, implementing improvements that were suggested to the Ethereum VM (EVM) for many years but couldn’t be implemented due to the need to maintain backward compatibility.
#### Fuel Contract & Call Model
Fuel uses a similar model to Ethereum for contracts and cross-contract calls. Contracts may call other contracts with a CALL similar to an Ethereum message call). Unlike the EVM, which can only forward its base asset with a call (i.e. ETH), the FuelVM can forward a single native fungible asset with a call.
Transactions may initiate contract calls. Ethereum transactions may call a single contract directly. Fuel transactions instead execute a script (arbitrary bytecode attached to the transaction), which may call any number of contracts.
#### FuelVM vs. EVM
FuelVM learns from the EVM, Solana, WASM, Bitcoin, and Cosmos. Let's take a look at some fundamental differences between FuelVM & EVM.
##### 1. FuelVM & Fraud-provability
Fraud proofs are a blockchain verification mechanism whereby a claim on a new block is accepted unless a proof that the claim is invalid is provided within some configurable time window. This allows trust-minimized light clients to be secure under the assumption that only a single honest full-node is available in the network to produce fraud proofs.
Both the Fuel protocol and the FuelVM are designed to be fraud-provable in restrictive environments such as the Ethereum Virtual Machine.
In order to understand Fraud-proofs in FuelVM fully, let's take a look at a few important concepts:
- **UTXO Model**
The UTXO model is a new paradigm in transaction verification adopted by systems like Bitcoin that enables efficiency and cost-effectiveness of transactions.
A UTXO stands for **"Unspent Transaction Output"**. As the name suggestes, a UTXO is a part of the transaction that remains unspent after the transaction is executed. A UTXO in a transaction can be expressed in terms of an input and an output. Once the transaction is executed, the output is recorded as input for the next transaction. We will learn more about this transaction format and the input and output types in more detail later in the guide.
Once a transaction on the network is initiated by a user, the UTXO with the corresponding address of the owner of the contract is called and saved along with the recipient's address associated with the UTXO transferred to them.
As opposed to the account-based transaction model used by Ethereum, the FuelVM and the Fuel protocol use the UTXO model for fraud-provability.
- **UTXO Fraud-proofs**
State-transition fraud proofs are a general-purpose fraud proof mechanism, but come with the downside of requiring a global state tree—an inherently sequential bottleneck.
UTXO fraud proofs avoid this bottleneck; they simply require each spend of a UTXO to "point" to the creation of the UTXO. Proving the pointer is invalid, or that whatever is being pointed to doesn't match whatever is being spent, is sufficient for exhaustively proving fraud.
##### 2. Shared memory architecture
**The EVM** uses a linear memory without a defined limit. Allocating memory costs a quadratic amount of gas, which severely limits the amount of memory usable in a single context (i.e. contract call). In addition, the EVM has a separate memory space per context. Contexts may communicate with each other by copying data to call data and returning data buffers.
**The FuelVM** has a globally shared memory architecture. Memory is allocated statically with a known upper bound, allowing for straightforward implementation of heap types such as vectors. Memory in the FuelVM is globally readable across contexts, but locally writable. Each context may only write to portions of the stack and the heap which it has ownership over.
This allows you to pass data around between contracts without expensive storage and pass chunks of data without having to serialize or copy from call data to memory.
##### 3. Multiple native assets
In Ethereum, the only native asset is Ether. On the contrary, Fuel allows contracts to mint UTXO-based native assets using a set of easy asset opcodes. These assets have the benefits of native-level call and optimization.
Any single asset may be forwarded with a call. Contracts have a balance of all possible assets instead of only the base asset.
> 💡 Note: Only the base asset is usable to pay for gas fees.
##### 4. 64-bit Computing
Modern processors have 64-bit registers, and all of the instruction set operates on 64 bits. Those are the most efficient instructions, and when you deal with 256 bits, you’re dealing with big numbers, and since modern processors aren't made to handle those numbers natively, it means you have to do more in the software.
##### 5. Register-based
The FuelVM is a register-based virtual machine instead of a stack-based virtual machine. This means that it require fewer instructions to do the same work than stack-based VMs. Since every operation is priced, optimizing to reduce the number of operations needed to do the same amount of work has outsized benefits.
##### 6. The FuelVM removes approve/transferFrom
The FuelVM removes the need for approve/transferFrom UX with scripts. Unlike the EVM, the FuelVM has scripts, which allow many actions to happen from an origin sender without a contract being deployed. Read more in the Fuel Specification [here](https://fuellabs.github.io/fuel-specs/master/protocol/tx_format/input.html).
##### 7. Atomic UTXO paradigm
Fuel uses a system of UTXOs which enable a more efficient system fo transfer and ownership of assets, where the accounts tree doesn't have to be rebuilt every time funds are transferred.
Read more about the UTXO model here.
## The Fuel Specification
The Fuel Specification describes the Fuel protocol and the the FuelVM. You can read the full spec [here](https://fuellabs.github.io/fuel-specs/master/fuel-specs.html)!
To be able to follow along the next set of guides with ease, let's take a look some important components of the Fuel protocol as specified in the spec.
### The Fuel Transaction Format
Fuel has the following transaction format:
- **Transaction**
The enum `transaction` expresses the type of transactions being performed through a particular contract. It returns one of the following data types:
1. `TransactionScript`: Indicates that the transaction is a script
2. `TransactionCreate`: Indicates that the transaction creates a contract of type ContractID
3. `TransactionMint`: Indicates that the transaction is created by the block producer and is not signed
```rust=
enum TransactionType : uint8 {
Script = 0,
Create = 1,
Mint = 2,
}
```
Transaction is invalid if transaction is of type create.
- **Input**
The enum `Input` expresses the type of input and the data it returns. An `InputType` returns one of the following data types:
1. `InputCoin`: Indicates that the transaction input is a coin
2. `InputContract`: Indicates the coins owned by a contract before transaction execution
3. `InputMessage`: Indicates that the transaction input is a message
```rust=
enum InputType : uint8 {
Coin = 0,
Contract = 1,
Message = 2,
}
```
Transaction is invalid if the input type is of type message.
- **Output**
The enum `Output` expresses the type of transaction output and the data it returns. An `OutputType` returns one of the following data types:
1. `OutputCoin`: Indicates the coins available for the transaction output to send
2. `OutputContract`: Indicates the coins owned by a contract after transaction execution
3. `OutputMessage`: Indicates that the output is a message sent with the base asset coins
4. `OutputChange`: Indicates that the output's amount may vary based on transaction execution
5. `OutputVariable`: Indicates that the output's amount and owner may vary based on transaction execution
6. `OutputContractCreated`:
```rust=
enum OutputType : uint8 {
Coin = 0,
Contract = 1,
Message = 2,
Change = 3,
Variable = 4,
ContractCreated = 5,
}
```
Transaction is invalid if the output type is ContractCreated
## Developer Tooling
### The Sway toolchain
- **Sway Standard Library:** A native library of helpful types and methods.
- **Forc:** The Fuel toolbox that helps you build, deploy, and manage your Sway projects.
- **Fuelup:** The official Fuel toolchain manager helps you install and manage versions.
- **Rust SDK:** Test and interact with your Sway contract with Rust.
- **Typescript SDK:** Test and interact with your Sway contract with TypeScript.
- **Fuel Indexer:** Easily make your own indexer to organize and query on-chain data.
The Sway toolchain is sufficient to compile Sway smart contracts. Otherwise, note that if you want to run Sway smart contracts (e.g. for testing), a Fuel Core full node is required, which is packaged together with the Sway toolchain together as the Fuel toolchain.
Get started with Sway in the [Sway Guide]()!
### Networks
- **Beta-1 testnet**
The Beta-1 network is the first public Fuel testnet, shared by all developers and users that interact with it. Developers may deploy contracts to it at will—no permission or whitelisting required—and users may interact with deployed contracts as well.
Read more about Beta-1 [here](https://fuellabs.github.io/fuel-docs/master/networks/beta-1.html)!
- **Beta-2 testnet**
The Beta-2 network is launched with a bridge to Ethereum's Goerli test network. With this network, developers are able to build and test cross-chain dapps, laying the foundations for projects building on Fuel to tap into Ethereum's massive liquidity and existing user base.
Read more about Beta-2 [here](https://fuellabs.github.io/fuel-docs/master/networks/beta-2.html)!
### SDKs:
- **TypeScript SDK**
The Fuel TS SDK is a toolkit for build dapps on The fuel network. You can use the SDK to execute scripts, interact with contracts, list transactions, balances and more.
- **Rust SDK**
Rust SDK for Fuel. It can be used for a variety of things, including but not limited to:
- Deploying, and testing Sway contracts
- Launching a local Fuel network
- Crafting and signing transactions with hand-crafted scripts or contract calls
- Generating type-safe Rust bindings of contract methods, & more!
> ❗️ fuels-rs is still in active development.
### Wallet SDK (& Browser Extension)
Fuel has a beta wallet extension that can be downloaded. Keep in mind this is an alpha version. For now, it isn't possible to download the extension directly from Chrome Extensions Store.
For instructions on how to download the extension, check out the docs [here](https://fuels-wallet.vercel.app/docs/install/#installing-extension)!
Fuels is an SDK that allows developers to let users interact with the Fuel node via the Fuel wallet. Check out the API reference [here](https://fuels-wallet.vercel.app/docs/api/)!
### Indexer
The Fuel Indexer is a standalone binary that can be used to index various components of the blockchain. These indexable components include blocks, transactions, and receipts and state within a Fuel network, allowing for high-performance read-only access to the blockchain for advanced dApp use-cases.
Events can be indexed by the Fuel Indexer by using WASM modules, as described in the Hello World example.
Get Started with the Fuel Indexer in the [Indexer Guide]()!
### GraphQL API
The Fuel GraphQL API allows you to query the Fuel blockchain for a wide range of on-chain data. It can be used to query transactions, balances, block information, and more. You can also use it to simulate and submit transactions on the Fuel network.
Get Started with the API in the [GraphQL guide]()!
Sign in with Wallet
Connect another wallet