Sign in Subscribe
Testnet

Announcing “Beta-3”, Fuel’s Third Public Testnet

The new beta-3 testnet brings P2P networking, introducing the ability to run synchronizing full nodes on Fuel.

Fuel Labs

• 6 min read
Announcing “Beta-3”, Fuel’s Third Public Testnet
This article has been translated by the Fuel Ambassadors in Russian.

We are thrilled to announce the launch of the beta-3 testnet, adding P2P networking on Fuel. With this third testnet, Fuel enters the later stages of testing and reaches a crucial milestone on its way to mainnet, a modular future that enables true scalability for the Ethereum ecosystem.

In November, we launched beta-2, adding bridging support so developers could experiment with cross-chain dapps on Fuel. We are excited to see a vibrant ecosystem emerge on Fuel, now home to more than 25+ projects. Since its introduction, beta-2 has settled more than 900,000 transactions and seen immense interest from developers, projects and community members.

Exciting new possibilities await with beta-3.

P2P Networking Now on Fuel

beta-3 expands on the features of beta-2, introducing P2P networking and the ability to run synchronizing full nodes. This enables the beta-3 APIs to scale up to and reach the level of demand observed in beta-2. In a following testnet, we’ll enable public P2P access so anyone can run local nodes connected to Fuel.

Please note that beta-3 is not an incentivized testnet. There will be no direct rewards for participation in this network.

Key Features

Below is a full list of key features for the beta-3 testnet:

⛓️ Block Sync

Synchronizing full nodes can sync with the Fuel network via P2P networking. This is primarily useful for things like being able to fork mainnet state for contract testing or having a dedicated full node for application indexing purposes. While P2P is enabled, this is currently only for trusted connections that we use for speeding up/scaling the API.

🤝 Single Shared Network

beta-3 is a shared, public developer- and user-facing testnet. Developers can deploy contracts and users can then interact with those contracts.

🚰 Faucet

Anyone can use the faucet to get some test ETH to deploy or interact with contracts. Available here.

📃 GraphQL Endpoint

The Fuel Core node uses GraphQL instead of JSON RPC. A playground for the public GraphQL endpoint for beta-3 is available here.

🔍 Block Explorer

A block explorer (still heavily a work-in-progress) is available here.

If you have any questions (development-related or otherwise), you can join the Fuel Labs Discord and head to the #questions channel under the Testnet category. Be sure to follow our Twitter for updates.

What's New

Compiler

  • The compiler is now able to handle large design more robustly and efficiently due to various backend optimizations that have been introduced, resulting in bytecode size reduction of up to 30%. New features and enhancements have also been introduced such as support for mutable static arrays, the #[payable] annotation, eliminating the need for ~ to accesses associated functions, the ability to return a Vec from a script, and the ability to pass in predicate data via main() in predicates.

🌐 Client

  • Block sync support for running local nodes (see key features above)
  • Gas metered Predicates - Predicate fees are calculated similarly to scripts, unlocking the ability for standard control flows such as loops or dynamic jumps. Gas used by predicates is deducted from the overall txn gas limit, preventing expensive opcodes from being underpriced.
  • Revised gas schedule - The vm opcodes are repriced based on a far more accurate benchmarking system. The gas schedule will continue to adjust over time as more features and optimizations are added, and the new pricing framework will make it easier to detect changes and adjust pricing as necessary.
  • Many new Database optimizations for better API performance.

🔧 Tooling

forc test highlights

  • You can now use the #[test(should_revert)] attribute to describe a unit test that is expected to revert. This enables testing failure states.
  • Test output now displays the name, file path and line number of failed tests.
  • Foundations for contract calling in unit tests: When running forc test on a contract project, forc will first build and deploy the contract before building and running the unit tests. This enables early support for contract calling in unit tests.

fuelup highlights

  • Now supports toolchain overriding with fuel-toolchain.toml. This enables pinning directories and repos to specific fuelup channels and component versions, improving the reproducibility of Fuel projects.

forc doc highlights

  • HTML generated by forc doc now supports improved module navigation.
  • New and improved styling and markdown rendering.

Other highlights

  • forc test and forc fmt now support workspaces and will run for each member package.
  • Forc.toml now supports specifying a salt for contract dependencies.
  • Added a simple forc tx plugin command for constructing serialized transactions via CLI.

🧩 Language Server

  • The language server has been optimized to work with multiple projects simultaneously, allowing users to easily switch between projects without interrupting their workflow.
  • Improved warnings and error diagnostics have been implemented, providing more accurate and detailed information about potential issues.
  • Code actions have been added for auto-generating an impl block for an abi definition.
  • Preliminary support for neovim, providing users with even more flexibility in their development environment.

SDK

  • Rust SDK
    • Block manipulation, used for testing smart contracts under specific scenarios;
    • Easier testing infrastructure setup: describe your test wallets, contracts, scripts, predicates, and deployments all in a single macro;
    • Parsed and human-readable revert errors to make smart contract debugging friendlier;
    • Transaction fees can now be paid using Messages, i.e., bridged assets;
    • Predicate data encoder;
    • abigen! macro rework: now supporting multiple contracts, predicates, and scripts all in the same macro invocation;
    • New predicates API;
    • Better dependencies importing experience;
  • Typescript SDK
    • Better and more reliable log parsing;
    • Overall ergonomics improvements;
    • New abi-typegen CLI;
    • Live documentation rework;

🔌 Front End

  • Fuel Wallet
    • Transaction Previews enable a better preview of complex transactions, such as the ones containing multiple operations, like transferring assets to multiple addresses, calling contracts, or doing both simultaneously.
    • Multi-Account support now is possible to manage multiple addresses inside the Fuel Wallet.
    • Transaction History lets users see all the transactions made from the Account without leaving the wallet.
    • New package @fuel-wallet/sdk for Type support. When developing with Fuel Wallet, you can import our TypeScript package to have types of our Wallet and better integration with current projects using Fuel TS SDK.
    • Create accounts using Private Key. On specific cases like development, you may need to create a new account using a Private Key not related to the current wallet seed phrase.
    • Add custom assets. Now DApps and Users can add metadata to custom assets on the wallet make possible to have not only the official tokens list from Fuel but customizable assets from third party applications.

🗃 Indexer

  • Combine your compiled Sway contract ABI and GraphQL schema to build indexers that compile to WASM.
  • Re-deploy new indexers without re-deploying your contracts.
  • Index as much or as little of FuelVM block information as you'd like.
  • The forc-index plugin
    • A new Forc plugin used to create, build, and deploy new indexers using a set of simple commands.
  • Revamped documentation! (checkout the new Quickstart)

Application Development

Developer Education

  • We’ve updated and released new resources for developers:
  • Developer Quickstart in Fuel Book (To learn how to build & deploy their first fullstack dapp on Fuel)
  • Discourse to check FAQs, post questions, and get support from community members and Fuel contributors.

For Developers

More beta-3 documentation is available here.

🚰 Faucet

  • Valid transactions are required to deploy contracts and interact with the network, which requires coins. Testnet ETH can be obtained from the faucet by completing a captcha.

💰 Wallet

  • A persistent CLI wallet (with binaries for Linux and MacOS) is available here.
  • A web/browser plugin wallet is under active development, available here.

⚡️ Getting Started

  • For an overview of Fuel, take a look at the Fuel documentation.
  • To begin building on Fuel, check out the developer quickstart. This guide provides an end-to-end walkthrough for developers building a dapp on Fuel.

🌴 Smart Contract Language (Sway)

Note that the beta-3 testnet is under active development and may see breaking upgrades and even regenesis events.

Go Beyond Monolithic

Modular blockchain design is quickly becoming the foremost solution to the challenge of scaling blockchains by orders of magnitude. The industry is rapidly moving away from monolithic blockchain designs and towards modular ones.

We believe innovation does not require launching a new L1, but can rather happen at the execution layer. Fuel Labs is leading this charge with Fuel, the fastest modular execution layer.

Unconstrained by the limitations of the EVM, Fuel approaches scalable execution from a modular-first perspective, allowing for significant improvements over the EVM's inefficient execution environment and thus enabling maximum decentralization and the highest flexible throughput.

With this new movement, we have an opportunity to start fresh and build a fundamentally new generation of blockchains that go #BeyondMonolithic.

Follow Us

About Us

Fuel is the fastest execution layer for the modular blockchain stack. Powerful and sleek, the technology enables parallel transaction execution, empowering developers with the highest flexible throughput and maximum security required to scale. Developers choose the FuelVM for its superior developer experience and the ability to go beyond the limitations of the EVM.

Become a Contributor

Sign up for more like this.

Enter your email
Subscribe