Welcome to Inside Fuel, our review of technical developments and everything happening on the Fuel Network. Take a moment to catch up on all the latest news.

Building the fastest modular execution layer would not be possible without an incredible contributor team. Here are the newest additions to the team this month:

According to the Rust In Blockchain monthly review, Fuel is one of the most active Rust-based projects this Winter with Fuel: 548 merged PRs, 406 closed issues, and 256 open issues between December 2022 and January 2023, ranking us in the Top 5 of the most active Rust-based blockchains.

John Adler took part in the Bankless Podcast to explain why and how modular blockchains will set the path for the autonomous future.

He also joined the OxResearch podcast to explain how Fuel differentiates itself from other rollups.

We hosted the third episode of Sway Day, a monthly discussion about all things Sway. This time, we went over all the 2022 development accomplishments and set 2023 expectations with John Adler.

At the end of 2022, you can remember that:

• 3,168 issues have been filled since the beginning of Sway.

• The Sway repository has grown from 0 to 350+ stars.

• Reentrancy analysis is possible directly at the compiler level with Sway:

• The Fuel Labs repository has been in the Top 5 of Rust in Blockchain for an entire year in terms of closed PRs and consistently in the Top 1 in terms of opened/closed issues.

• Our well-documented and approachable documentation keeps bringing more and more third-party contributors and builders (currently 25+ projects are building on Fuel).

• Fuel and Sway have experienced a notable rise in popularity over the past year, marked by a substantial increase in open-source contributions and participation in our Grants Program to build projects on Fuel using Sway.

In 2023, you can expect:

• A compiler optimization in terms of bytecode size.

• More backends will be supported by Sway (i.e. EVM backend is already under development).

• Generic and trait constraints will be improved, abstractions will be a lot more economic and powerful.

• More applications to be ported from Solidity/Vyper to Sway.

• An improvement of the reentrancy analysis at the compiler level.

• Enhanced tooling and language features.

Fuelup is the official package manager and multiplexer for Fuel that installs The Fuel Toolchain from the official release channels. It enables you to easily install pre-packaged toolchains, keep them up to date, or even create custom toolchains and switch between them.

Binaries are executed through Fuelup as proxies allowing flexibility in the execution of tools.

It simplifies building and maintaining Sway applications with forc and fuel-core for common platforms.

Support for overriding toolchains added to Fuelup:

Developers can specify a specific version of a component in a TOML file (fuel-toolchain.toml) at the root of their Sway project. fuelup will automatically use the specified version when working in that directory.

The way fuelup handles binaries has also been updated - fuelup now uses a generalized store found in ~/.fuelup/store to cache your binary downloads. This means that there will be no more duplicate components of the same versions across different toolchains, and creating a new toolchain with an already downloaded component takes almost no time.

The purpose of the Sway Applications repository is to demonstrate what can be built with Sway and to promote good development practices.

​That being said, the repository should be deemed as a living project since the applications will be actively maintained, and thus it is likely that none of them will ever reach their final form!​

The repository is young so there isn't anything for anyone to use yet, however, we have lots of applications in development, and lots more planned to be worked on in the near future.

So far, the applications are planned to have a smart contract to demonstrate Sway, tests written in Rust to demonstrate the Rust-SDK, and a user interface to demonstrate the use of the Typescript-SDK.

This part presents the applications that have gone through some level of scrutiny and have been deemed acceptable to be merged into the master branch.​

NOTE

This does not mean that they are complete nor that development has ceased.

New Fractional NFT application: The Fractional NFT application will lock an NFT into a fractional-NFT(f-NFT) contract and allow users to purchase the newly minted fractionalized tokens. These tokens can then be bought and sold on an AMM or return them to the distribution contract if a buyback is initiated. If all tokens are returned, the admin may unlock the NFT from the f-NFT contract and regain full ownership.

New Timelock application: The purpose of a timelock is to restrict the execution of a transaction to some window of time. The transaction usually involves a transfer of funds e.g. via an escrow, vesting schedule, deferred payment, etc. however, it may also be used for valueless execution i.e. calls to a contract to perform computation. The transaction arguments are hashed and stored in a queue awaiting a subsequent call for execution. A user may choose to execute the transaction during the window of time or cancel the transaction by removing it from the queue.

• Introduction of the Sway reference, a more technical Sway source of documentation;

• Introduction of  __smo intrinsic;

• Start-up of the work on the EVM backend;

• Introduction of configuration-time constants;

• Improvement of Error messages for methods called, mismatched ABI methods, improperly used types, and more;

• Addition of balance tree and output message effects to CEI analysis;

• Addition of a better parser recovery for incomplete path expressions/patterns;

Bug fixes:

• To trait constraint resolution to allow for the correct trait methods to be found;

• To dead-code-analysis to prevent false reporting dead code;

• To prevent stack overflow from infinite type unification;

• To type inference to prevent unsound type inference and internal compiler errors;

• To calculate missing patterns in nested enum matching in match expressions;

• To block repeated ABI/trait declarations;

• To disable self-parameters for ABI methods;

• Introduction of a Byte type;

• Addition of bitwise operations for u8, u16, u32;

• Optimization of U128 and U256 division;

• Remove std::context::gas in favor of std::registers::context_gas();

• Introduction of low-level call functionality;

• Switch to using the Bytes type for the send_message data parameter;

• Enhance the Result library;

• Introduction of the Never enum;

• Authorization for comma-separated annotations;

• Addition of CSS styling, favicon, and  --document-private-items option to forc doc;

• Introduction of #[test(should_revert)] attribute to indicate a unit test should revert;

• Allow the LSP to start with partial config;

• Addition of LSP option to hide compiler warnings and errors;

• Addition of the #[payable] annotation to ABI methods;

• Enable the LSP to work with multiple projects simultaneously;

• Addition of support for calling into contract ABIs from unit tests;

• Addition of an interface for generating links between items & modules in forc doc;

• Introduction of build flag to print the dead-code-analysis graph;

• Introduction of workspace testing feature to forc test;

• Addition of workspace support for forc clean;

• Bug fix to prevent an occasional git checkout race when running multiple instances of forc concurrently;

• Bug fix to correct executable output for arm64 binaries;

• P2P Block Sync (adds the ability to run syncing full-nodes):

  • Includes the addition of two new services, Synchronization, and Block Importer;

  • Enables libp2p in the standard fuel-core binary;

• Ports and Adapters Re-Architecture:

  • Breaks the internals of fuel-core into easily unit-testable and reusable libraries;

  • Paves the way for alternate implementations such as light clients;

• Improved DataBase (DB) performance (less cloning);

• Introduction of gas schedule framework & revised gas prices:

  • The new framework allows us to automatically reprice the gas schedule based on benchmark output;

  • More gas price changes to come as we implement contract state merklization and optimize the DB further;

• Gas-metered predicates:

  • Predicates are priced using the standard gas schedule and their execution budget is deducted from the transaction gas limit. Previously they were only priced based on the number of bytes they added to the transaction;

• Replacement of the integer logarithm in the VM with Rust std lib impl from 1.67 (Now requires Rust 1.67 to use fuel-core & FueVM);

• Binary MMR for block headers implemented;

• Gas prices are now configurable as part of chainconfig / genesis block;

• FuelVM is now a monorepo containing all fuel-based dependencies of the VM;

• Update of GTF arg constants to match the spec;

Rust SDK:

• 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;

• Introduction of the Predicate data encoder;

• Rework of theabigen! macro: now supporting multiple contracts, predicates, and scripts all in the same macro invocation;

• Introduction of the predicates API;

• Better dependencies importing experience;

Typescript SDK:

• Better and more reliable log parsing;

• Overall ergonomics improvements;

• Introduction of abi-typegen CLI;

• Live documentation rework;

• Twitter

• Discord

• LinkedIn

• YouTube

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.

• Explore our current job openings

• Apply for a grant

• Learn Sway

Welcome to Inside Fuel, our review of technical developments and everything happening on the Fuel Network. Take a moment to catch up on all the latest news.

Building the fastest modular execution layer would not be possible without an incredible contributor team. Here are the newest additions to the team this month:

According to the Rust In Blockchain monthly review, Fuel is one of the most active Rust-based projects this Winter with Fuel: 548 merged PRs, 406 closed issues, and 256 open issues between December 2022 and January 2023, ranking us in the Top 5 of the most active Rust-based blockchains.

John Adler took part in the Bankless Podcast to explain why and how modular blockchains will set the path for the autonomous future.

He also joined the OxResearch podcast to explain how Fuel differentiates itself from other rollups.

We hosted the third episode of Sway Day, a monthly discussion about all things Sway. This time, we went over all the 2022 development accomplishments and set 2023 expectations with John Adler.

At the end of 2022, you can remember that:

• 3,168 issues have been filled since the beginning of Sway.

• The Sway repository has grown from 0 to 350+ stars.

• Reentrancy analysis is possible directly at the compiler level with Sway:

• The Fuel Labs repository has been in the Top 5 of Rust in Blockchain for an entire year in terms of closed PRs and consistently in the Top 1 in terms of opened/closed issues.

• Our well-documented and approachable documentation keeps bringing more and more third-party contributors and builders (currently 25+ projects are building on Fuel).

• Fuel and Sway have experienced a notable rise in popularity over the past year, marked by a substantial increase in open-source contributions and participation in our Grants Program to build projects on Fuel using Sway.

In 2023, you can expect:

• A compiler optimization in terms of bytecode size.

• More backends will be supported by Sway (i.e. EVM backend is already under development).

• Generic and trait constraints will be improved, abstractions will be a lot more economic and powerful.

• More applications to be ported from Solidity/Vyper to Sway.

• An improvement of the reentrancy analysis at the compiler level.

• Enhanced tooling and language features.

Fuelup is the official package manager and multiplexer for Fuel that installs The Fuel Toolchain from the official release channels. It enables you to easily install pre-packaged toolchains, keep them up to date, or even create custom toolchains and switch between them.

Binaries are executed through Fuelup as proxies allowing flexibility in the execution of tools.

It simplifies building and maintaining Sway applications with forc and fuel-core for common platforms.

Support for overriding toolchains added to Fuelup:

Developers can specify a specific version of a component in a TOML file (fuel-toolchain.toml) at the root of their Sway project. fuelup will automatically use the specified version when working in that directory.

The way fuelup handles binaries has also been updated - fuelup now uses a generalized store found in ~/.fuelup/store to cache your binary downloads. This means that there will be no more duplicate components of the same versions across different toolchains, and creating a new toolchain with an already downloaded component takes almost no time.

The purpose of the Sway Applications repository is to demonstrate what can be built with Sway and to promote good development practices.

​That being said, the repository should be deemed as a living project since the applications will be actively maintained, and thus it is likely that none of them will ever reach their final form!​

The repository is young so there isn't anything for anyone to use yet, however, we have lots of applications in development, and lots more planned to be worked on in the near future.

So far, the applications are planned to have a smart contract to demonstrate Sway, tests written in Rust to demonstrate the Rust-SDK, and a user interface to demonstrate the use of the Typescript-SDK.

This part presents the applications that have gone through some level of scrutiny and have been deemed acceptable to be merged into the master branch.​

NOTE

This does not mean that they are complete nor that development has ceased.

New Fractional NFT application: The Fractional NFT application will lock an NFT into a fractional-NFT(f-NFT) contract and allow users to purchase the newly minted fractionalized tokens. These tokens can then be bought and sold on an AMM or return them to the distribution contract if a buyback is initiated. If all tokens are returned, the admin may unlock the NFT from the f-NFT contract and regain full ownership.

New Timelock application: The purpose of a timelock is to restrict the execution of a transaction to some window of time. The transaction usually involves a transfer of funds e.g. via an escrow, vesting schedule, deferred payment, etc. however, it may also be used for valueless execution i.e. calls to a contract to perform computation. The transaction arguments are hashed and stored in a queue awaiting a subsequent call for execution. A user may choose to execute the transaction during the window of time or cancel the transaction by removing it from the queue.

• Introduction of the Sway reference, a more technical Sway source of documentation;

• Introduction of  __smo intrinsic;

• Start-up of the work on the EVM backend;

• Introduction of configuration-time constants;

• Improvement of Error messages for methods called, mismatched ABI methods, improperly used types, and more;

• Addition of balance tree and output message effects to CEI analysis;

• Addition of a better parser recovery for incomplete path expressions/patterns;

Bug fixes:

• To trait constraint resolution to allow for the correct trait methods to be found;

• To dead-code-analysis to prevent false reporting dead code;

• To prevent stack overflow from infinite type unification;

• To type inference to prevent unsound type inference and internal compiler errors;

• To calculate missing patterns in nested enum matching in match expressions;

• To block repeated ABI/trait declarations;

• To disable self-parameters for ABI methods;

• Introduction of a Byte type;

• Addition of bitwise operations for u8, u16, u32;

• Optimization of U128 and U256 division;

• Remove std::context::gas in favor of std::registers::context_gas();

• Introduction of low-level call functionality;

• Switch to using the Bytes type for the send_message data parameter;

• Enhance the Result library;

• Introduction of the Never enum;

• Authorization for comma-separated annotations;

• Addition of CSS styling, favicon, and  --document-private-items option to forc doc;

• Introduction of #[test(should_revert)] attribute to indicate a unit test should revert;

• Allow the LSP to start with partial config;

• Addition of LSP option to hide compiler warnings and errors;

• Addition of the #[payable] annotation to ABI methods;

• Enable the LSP to work with multiple projects simultaneously;

• Addition of support for calling into contract ABIs from unit tests;

• Addition of an interface for generating links between items & modules in forc doc;

• Introduction of build flag to print the dead-code-analysis graph;

• Introduction of workspace testing feature to forc test;

• Addition of workspace support for forc clean;

• Bug fix to prevent an occasional git checkout race when running multiple instances of forc concurrently;

• Bug fix to correct executable output for arm64 binaries;

• P2P Block Sync (adds the ability to run syncing full-nodes):

  • Includes the addition of two new services, Synchronization, and Block Importer;

  • Enables libp2p in the standard fuel-core binary;

• Ports and Adapters Re-Architecture:

  • Breaks the internals of fuel-core into easily unit-testable and reusable libraries;

  • Paves the way for alternate implementations such as light clients;

• Improved DataBase (DB) performance (less cloning);

• Introduction of gas schedule framework & revised gas prices:

  • The new framework allows us to automatically reprice the gas schedule based on benchmark output;

  • More gas price changes to come as we implement contract state merklization and optimize the DB further;

• Gas-metered predicates:

  • Predicates are priced using the standard gas schedule and their execution budget is deducted from the transaction gas limit. Previously they were only priced based on the number of bytes they added to the transaction;

• Replacement of the integer logarithm in the VM with Rust std lib impl from 1.67 (Now requires Rust 1.67 to use fuel-core & FueVM);

• Binary MMR for block headers implemented;

• Gas prices are now configurable as part of chainconfig / genesis block;

• FuelVM is now a monorepo containing all fuel-based dependencies of the VM;

• Update of GTF arg constants to match the spec;

Rust SDK:

• 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;

• Introduction of the Predicate data encoder;

• Rework of theabigen! macro: now supporting multiple contracts, predicates, and scripts all in the same macro invocation;

• Introduction of the predicates API;

• Better dependencies importing experience;

Typescript SDK:

• Better and more reliable log parsing;

• Overall ergonomics improvements;

• Introduction of abi-typegen CLI;

• Live documentation rework;

• Twitter

• Discord

• LinkedIn

• YouTube

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.

• Explore our current job openings

• Apply for a grant

• Learn Sway