Fuse’s Road to Scaling Payment Throughput. Part 1

This article is the first installment in the series summarizing the Fuse scaling research conducted by computer science researcher Dr. Israel Gottlieb. It lays out the scaling outlook for Fuse, explains the choice of optimistic rollups as the preferred approach to scaling in the short-to-medium run and discusses Arbitrum as the first option for implementing the actual scaling solution.

A more detailed version co-written by Dr. Gottlieb and Fuse’s Content and Partnerships Manager Daniil Gorbatenko will be published separately soon, so please stay tuned.

While the Fuse Network blockchain is not currently experiencing any issues with transaction throughput, it is no secret that as we move closer to realizing our vision of bringing crypto payments and decentralized finance (DeFi) to the masses, we will need to significantly scale our chain’s current processing capacity.

Fuse Scaling Challenge

To determine the scaling requirements for Fuse, it helps to consider its performance gap that needs to be closed. We will measure performance in transactions per second (tps). For the payment processors like Visa and Mastercard, with whom Fuse intends to fully compete, there are widely varying estimates. At the high end, Visa itself claims a theoretical maximum capability of 65K tps, while other sources suggest the actual traffic is between 1k and 4k tps, depending on demand. We will focus on the lower bound of 2.5K tps (the average between 1K and 4K) as Fuse’s target capacity here.

It can of course be objected that blockchain platforms like Solana enable much higher transaction throughput but they achieve this through trading much higher centralization for speed, a tradeoff that the Fuse team does not consider to be in the best interest of its community.

Fuse is investing substantially toward scaling for higher performance. The goal is to be online with the most performant technology — just as soon as it becomes reliably secure. Currently, the Fuse Network blockchain has an average block interval of 5 seconds. For practical purposes, the AuRa consensus algorithm used by Fuse Network implies that a transaction can be considered finalized — or not reversible on the chain — after just one block confirmation.

However, in practice, Fuse Network’s transaction throughput is determined not by the raw consensus speed but by the maximum block gas limit, which currently stands at 10 million. The gas price of the simplest transaction (native FUSE token transfer is 21,000, which means that Fuse Network can process up to 476 such transactions per block or 121 per second.

However, popular ERC20-compatible tokens like USDC are potentially more important for the payments industry that Fuse is working to disrupt. Transfers of tokens like USDC on EVM chains like Fuse Network are more computationally costly, and their gas price at around 86K reflects that. The chain can handle around 30 USDC sends per second. If we set the Fuse target throughput at 2.5K tps per second, Fuse Network’s throughput for USDC-like transfers needs to be increased by a factor of 83.

Starting with Optimistic Rollups

There are multiple scalability approaches currently available to EVM chains. The most prominent include optimistic rollups, zero-knowledge (ZK) rollups and Plasma. After analyzing them in-depth, Fuse’s research team concluded that in the current circumstances, optimistic rollups represent the most attractive solution.

ZK rollups are a promising avenue for scaling and may, in fact, prove to be the more successful methodology in the long run. However, they currently have two major drawbacks that make them less useful in the short run. They are complex to understand and implement, and the application contexts to which they can be readily applied today are also limited. It will take more experience with this technology before it can be freely applied to a generalized transaction framework such as the full capability of the EVM. It remains to be seen whether the current R&D efforts by multiple teams will bring ZK rollups where they need to be.

Plasma is a generic category of layer-2 (L2) solutions wherein a L2 chain does things quickly — according to rules of some governing contract on layer 1 (L1) — and users that have a problem with some transaction have 1–2 weeks to submit a fraud-proof on L1. The current main weakness of Plasma is that it is not really a standard solution for all the smart contract transactions that can be handled by the EVM. Rather, Plasma-based protocols are typically restricted to specific small sets of transactions with specific dispute resolution rules developed for them at the L1 Plasma implementation level.

In contrast to ZK rollups and Plasma, optimistic rollups (OR’s) use technology that is well-understood and straightforward to implement in a generalized manner — today.

OR implementations achieve higher scale, lower transaction time and lower cost by bundling a large number of transactions into a L2 block. They then submit key authentication and security data to L1 for the block as a whole, rather than for each transaction individually. The strategy here is to amortize the cost of registering a full block on L1 over the many individual transactions it contains — roughly equivalent to transacting ‘wholesale’ as opposed to ‘retail’. This cost reduction applies to transaction time as well as gas paid on L1.

The OR approach is similar to Plasma in one major respect. It also enables spinning out L2 chains that can process transactions much faster than the parent chain without caring much about the transaction validity (thus, its “optimistic” nature). There is also a time window for users to challenge transactions that happen on L2 on the main chain (the challenge period). However, crucially, unlike Plasma, OR is directly applicable to all the EVM-supported transaction types, meaning that an OR-based L2 can just take over much of the L1 activity without worrying about the kinds of transactions involved.

Last but not least, OR enables what is dubbed as the “any trust” guarantee. This means that one honest validator challenging an invalid transaction is sufficient for an that transaction to be identified and handled during the challenge process.

Furthermore, a single L1 chain like Fuse Network can rely on multiple OR-based L2 chains for scaling, hence the goal of reaching 2.5K ERC20 transactions per second becomes achievable. In fact, a single OR-based L2 chain is estimated to be able to process thousands of transactions per second (although estimates vary widely and depend on the implementation), which could be sufficient for Fuse’s payment-centric target throughput.

Having chosen OR, Fuse’s research team has been considering the two most mature alternative implementations of the technology — Arbitrum and Optimism. Let us dive into the former.

OR Option 1: Arbitrum

The first OR option available for Fuse scaling is Arbitrum — an L2 solution built by Offchain Labs. The first implementation of the Arbitrum tech went live earlier this year, and it already has the highest total value locked among L2’s according to L2BEAT, standing at around $3.5 billion at the time of writing.

Arbitrum’s approach to scaling L1’s can be summed up with the following two principles:

  • Do almost everything on L2. Do what you absolutely must on L1. L2 can run much faster than L1, and at much lower cost. A challenge protocol is expected to be a rare event. Just as important — when a challenge does happen, nearly all of it executes on L2 — only the last step of final arbitration is submitted to L1 (see technical section below for more detail.
  • Once a transaction has been submitted to the L1, the results are deterministic. This implies that there can be only one correct way to compute the result of the submitted transactions, and if 2 validators disagree — one of them is wrong, and the challenge protocol will identify them. The challenge period chosen for the flagship Arbitrum implementation is approximately one week.

The key advantage of Arbitrum is that, in line with the first principle above, it does not rely much on L1 from the computational standpoint to function. Arbitrum’s challenge protocol focuses on finding the particular point of disagreement between the two contesting viewpoints about a submitted transaction.

This is done by using Arbitrum’s unique bisectional challenge protocol that is described in more detail in the supplementary in-depth article mentioned above. In short, the entire challenge protocol runs on the Arbitrum-based L2 to zero in on the single opcode (lowest-level EVM operation) that is at the core of the particular transaction dispute. That opcode is then executed on the L1 level. This challenge protocol is enabled by Arbitrum Operating System, or ArbitrumOS.

This allows significantly reducing what is posted to the L1 chain as well as the computational cost of verification, as well as the L1 fees. The block gas limit of the L1 chain also becomes essentially irrelevant to the throughput capacity of the L2.

However, this currently comes at the cost of requiring an extensive, sophisticated challenge process that also takes at least 1 week to complete in the currently operational implementation.

In Part 2 of this series, we will discuss the other OR option Fuse has been considering — namely, Optimism, and reveal which of the two has ultimately been selected for Fuse Network scaling, and why.

Follow our social media channels to stay updated on recent news and developments at

More Articles

© 2024 Fuse. All Rights Reserved.