The Case for a Qubic Stablecoin - Part 4: Fast, Faster, Qubic

We explain the difference between transfers and transactions and walk readers through various transfers scenarios to showcase Qubic’s impressive throughput. By highlighting real-world speed tests, we demonstrate what sets Qubic apart from other blockchains.

Qsilver, Aug 22, 2024.

Recap

In the first three parts of this series, we’ve laid the groundwork for our vision of a Qubic-based stablecoin. We have highlighted the current lack of a compelling answer to the essential “why to build on Qubic?” question, how SteCo’s current marketing efforts are misaligned, and proposed a strategic shift towards positioning Qubic around “ultra-high performance”, as a catalyst for ecosystem growth and long-term success.

Introduction

Now, we turn our focus to a crucial technical question: How fast is Qubic? This question is not straightforward. To fully understand Qubic's performance and its implications for our stablecoin vision, we must first clarify some key concepts. Bear with us while we explain the differences between transactions and transfers, transfer scenarios and transfer generation methods. By the end of this post, you should have a solid grasp of how Qubic’s speed stacks up against competitors and how we plan to leverage Qubic to build the fastest stablecoin the world has ever seen.

Before We Start

Key Concepts

The protocol layer refers to the core layer of the blockchain system, defining its rules and mechanisms. Here:

• A transaction is a single operation that involves a change of state in the ledger.
• A transfer is a sub-operation within a transaction that moves assets from one address to another.

The application layer refers to the layer where users interact with the blockchain through applications (user interfaces, dApps, and smart contracts). Here:

• A cryptocurrency transfer is the most common type of transaction, where one user transfers an amount of cryptocurrency to another user.
• Other types of transactions include smart contract executions, oracle data requests, state channel settlements, token transfers, token minting/burning, Non-Fungible Tokens (NFT) creation/transfer, staking, borrowing/lending, exchange orders, voting/governance actions, chain governance updates, rewards/dividend distributions, identity verifications, data storage/modification, cross-chain operations… an open list only limited by developers’ imaginations and which therefore varies depending on each blockchain.

"Transfer" can be confusing because its meaning changes with context:

• At the protocol level, a transfer is a sub-operation within a transaction.
• At the application level, a transfer is one type of transaction out of many.

To add to the confusion, a single transaction, such as a smart contract execution, can trigger multiple transfers. For instance, a payroll smart contract that distributes 1 QU each to 100 employees involves 100 transfers, all initiated by a single transaction.

Design differences across blockchains also contribute to this confusion. For instance, borrowing on Ethereum requires a smart contract, but on Celo, it's a native transaction type at the protocol level.

This complexity overwhelms end users. Since cryptocurrency transfers are the most common transaction type, they end up equating both (as in “a transaction serves to transfer crypto!”). Never mind that transactions are capable of much more. Users employ a protocol-level term to describe an application-level benefit.

Transfer Scenarios

Let’s distinguish the following transfer scenarios:

• One-to-One (1-to-1): A single transaction sends an asset from one address to another address. E.g. a transfer between accounts, an e-commerce payment.
• One-to-Many (1-to-Many): A single transaction sends an asset from one address to multiple addresses. E.g. benefits disbursement, payroll.
• One-to-All (1-to-All): A single transaction sends an asset from one address to all addresses in a chain. E.g. Universal Basic Income (UBI), aidrops.

Transfer Generation

Given their impact on performance, let’s distinguish how transfers are generated:

• Transaction-generated: A transfer generated from a transaction (Tx).
• Smart Contract-generated: A transfer generated from a smart contract (SC). The amount of transfers generated will depend on the type of smart contract.

Network Parameters

Finally, let’s define key network parameters impacting performance:

• Tick duration (tDur): A unit of time during which a set of transactions is processed and finalized. Current tick duration is around 2.5 seconds.
• Transactions per Tick (TxPT): The maximum number of transactions that can be processed during a single tick. Current transactions per tick are 1,024.

Deciding What to Measure

In the crypto world, blockchain performance is typically measured at the protocol level using the Transactions Per Second (TPS, or TxPS) metric. This measures the number of transactions—a change of state in the ledger—that a blockchain can process in a single second. For instance, TON has achieved 104,715 TxPS by leveraging sharding, while Ethereum aims to exceed 100k TxPS using rollups.

Qubic doesn’t excel in TxPS, but that’s okay. From a marketing perspective, TxPS is an inward-facing metric—more relevant for crypto teams and investors who enjoy boasting about their blockchain's capabilities in crypto feuds. However, what truly matters to end users is whether they can complete a payment instantly, even when thousands of others are trying to do the same at the exact moment. In other words, they don’t care about transactions per second (TxPS) but about transfers per second (TfPS). And here, for seamless payment experiences—crypto transfers at the application level—, where it truly matters, Qubic wears the crown. Or does it?

Performance Today

With an understanding of key concepts (transactions vs. transfers), metrics (TxPS vs. TfPS), transfer scenarios (1-to-1, 1-to-Many, 1-to-All), transfer generation methods (Tx-generated vs. SC-generated), and network parameters (tick duration and transactions per tick), we can now explore how fast Qubic operates at the application level. As we examine the various combinations, we encourage you to think of Qubic as an engine shifting through different gears.

This table summarizes our performance test results. For clarity, we present the table with constant network parameters, although in practice, tDur varied from test to test:

First Gear

In first gear, with no smart contracts involved, each transaction directly generates one transfer. To maximize the number of transfers, we need to maximize the number of transactions. Under current network parameters, Qubic can process 410 TxPS (1,024 TxPT / 2.5 tDur). This performance is significantly higher than Bitcoin (3-7) and Ethereum (15-30), but still modest when compared to Algorand (1,200), Avalanche (4,500), or Solana (65,000).

Second Gear

In second gear, we use the QUTIL SC (formerly Sendmany SC) which allows you to batch 25 1-to-Many transfers within a single transaction. This increases TfPS to 10,250 (410 TfPS * 25), putting Qubic on par with most other chains, but only in the 1-to-Many transfer scenario.

A variation of second gear (see QUTIL-2 in the table above) involves chaining QUTIL SC executions. The initial transaction triggers a QUTIL SC call for 25 payments, which generates 25 transfers. Each transfer, in turn, triggers another 25 QUTIL executions, creating a cascading effect. After three iterations (25 x 25 x 25), this process results in 15,625 transfers. However, since each transfer must be processed within a transaction, we’re still constrained by the 1024 TxPT limit. Consequently, it takes 16 fully saturated ticks (15,625 Txs / 1,024 TxPS), or 40 seconds (16 ticks * 2.5 tDur) to complete the entire process under optimal conditions. In summary, this approach does not increase overall throughput and remains applicable only to the 1-to-Many transfer scenario.

Third Gear

In third gear, we use the AIRDROP SC which allows you to send the same amount to each address in the spectrum—a list of all Qubic addresses stored in the RAM of Computor Nodes. Since very few use cases (if any) require sending the same amount to all Qubic addresses (~450k), the 1-to-All transfer scenario has limited real-world applicability. However, it’s still useful for testing the Qubic engine under real-world conditions, as we measure total processing time (tick processing + SC processing).

In our initial test on the testnet (AIRDROP-1 in the table above), we created 1,024 airdrops (to ~450k addresses each) per tick, fully utilizing the 1,024 Tx allowed per tick. The theoretical target of 460.8M TfPS (1,024 TxPT * 450k addresses) resulted in “only” 150k TfPS. While this outcome might seem disappointing, it reveals that either we found a bug or Qubic isn’t optimized for processing numerous instances of the same smart contract simultaneously, especially on testnet. However, these results are valuable as they highlight the performance impact under such conditions.

For a proper third gear test (AIRDROP-2), we changed the AIRDROP SC to transfer 1 QU instead of a token. This resulted in “only” 1M TfPS, again due to the usage of testnet virtual machines (instead of bare metal) and too much SC overhead.

Fourth Gear

In the fourth gear, we conducted a custom, fully artificial test (AIRDROP-3) where four airdrops were created, each with spectrum addresses handling 100 different transfers to determine maximum achievable performance. Typically, mainnet outperforms testnet due to its higher-performance systems and the use of multiple nodes rather than just one or two. To closely simulate mainnet conditions, we used a bare-metal testnet. Against the theoretical target of 180M TfPS (4 airdrops * 450k addresses * 100 transfers per address), we achieved 20M TfPS. This transfer rate is sustainable over the entire epoch, not just a peak performance, indicating the robustness of Qubic’s throughput capabilities. While the throughput is mind boggling (it would take just a couple hours to send everybody in the world some QU), it is specific to 1-to-All transfer scenarios and lacks real-world applicability.

Fifth Gear

A recent test by Qubic’s Core Development Team recorded 55M TfPS. This was achieved through another custom, fully artificial test (QUTIL-3), using a custom QUTIL smart contract in a loop, focusing solely on CPU time. Technically speaking, the fifth gear was a 1-to-Many (not 1-to-All) transfer scenario. However, as the addresses were sourced from a predefined pool generated inside the SC (not from actual transactions) and the amounts to transfer were randomly generated inside the SC (not from actual transactions), this test also lacks real-world applicability.

To understand the discrepancy between our 20M and their 55M results., you can think of these tests in terms of “flight time”. Valis' tests measured the time required from gate to gate (tick processing + smart contract processing), while Qubic’s core team measured only the actual time on the air (smart contract processing).

An Uneven Crown

Qubic’s current transfer performance in 1-to-Many/All transfer scenarios is in a league of its own. The disparity is so significant that has led Come-from-Beyond to publicly speculate whether Qubic’s smart contract engine is more performant than the engines of all other cryptocurrencies combined. While others discuss scaling solutions to reach thousands of transactions, Qubic effortlessly handles millions of transfers without the need for layer 1 (sharding) or layer 2 (rollups, side chains, or state channels) scaling solutions. However, Qubic’s current transfer performance in the most common 1-to-1 transfer scenario, the one needed in the majority of real-world case scenarios, including a stablecoin, is nothing to boast about (410 TfPS).

By now, less technical readers may feel they have been fooled by grandiose claims of “millions” of TfPS only to discover such metrics, in fourth and fifth gear, belong to artificial conditions, limited measurements, and unlikely transfer scenarios, with no real-world applicability. It is important to understand that performance testing is required for system optimization. Moreover, different teams working on Qubic have different goals and, therefore, different testing needs. Valis is focused on the application level and tests closer to real world performance (~20M). Qubic’s Core Development Team is focused on the protocol level and tests internal time (~55M).

Performance Tomorrow

Why is Valis advocating for repositioning Qubic as an “ultra-high performance” chain, embodied in a Qubic stablecoin, if the performance in 1-to-1 transfer scenarios is modest? Because we are confident that Qubic’s 1-to-1 performance will see a radical improvement in the near future, thanks to the contributions of two teams.

Qubic Core Team

Qubic is renowned for its unorthodox, performance-driven choices, such as bare metal servers, running entirely on RAM, and avoiding OS and virtual machines. These decisions, coupled with ever-increasing hardware requirements, set Qubic apart.

The first priority on the Qubic Core Team Roadmap is to achieve a stable tick time of 1-2 seconds. Ultimately, ticks could be accelerated to 5 per second, achieving a 12.5x increase in performance by reducing tick duration from 2.5 seconds to 0.2 seconds.

RAM requirements for computor nodes will increase to 1TB on September 4 and to 2TB on December 4 . As RAM increases is not far-fetched to think of 4,096 TxPT.

With faster and bigger ticks, things start to look different. Qubic will move from 410 TxPS (1,024 TxPT / 2.5 tDur) to 20,480 TxPS (4,096 TxPT / 0.2 tDur). These are optimistic; as throughput rises, other bottlenecks may arise, but you get the idea:

Do you think this is fast? Time to buckle-up.

Valis Team

Qubic achieves mind-blogging performance in SC-generated TfPS but, so far, all SCs have focused on the 1-to-Many transfer scenario. What would happen if we were able to leverage Qubic SCs in the most difficult benchmark to get maximum speed, the 1-to-1 transfer scenario?

Just as Ethereum reduced gas costs with L2 rollups, a similar approach can be applied to Qubic. While Qubic has no gas costs to minimize, our goal is to maximize the number of 1-to-1 transfers that can be encoded into a single transaction.

We have identified a method capable of rolling up 26 to 95 1-to-1 transfers per SC Tx using the current 1,024 TxPT limit. We expect this capacity to quickly rise from 26x to 95x due to Qubic’s efficient address reuse. Using a 90x conservative estimate, this translates to ~40k TxPS with current network parameters. With a 12.5x network capacity boost, this could reach 1,8M TxPS in 1-to-1 transfer scenarios.

Kneel to the Crown

The contributions above will make Qubic the undisputed leader in TfPS, across all transfer scenarios and chains. “The Fastest” is a short, straight, and powerful marketing claim with broad appeal in the crypto world.

The “ultra-high-performance” positioning answers the critical why question so loud and clear that can single-handedly attract entrepreneurs from all verticals to build on Qubic. Coupled with the first safe, transparent, consistent, instant, scalable, and free stablecoin in the world, it has a real chance to make Qubic a powerhouse on economic stability, liquidity and DeFi.

“uPoW for AI” is new and shiny and pretty, but shiny doesn’t last. To succeed, Qubic needs actual customers, willing and able to buy our product.

If you think Qubic is pretty, you should see it in a crown.

Coming Up: Valis Proposal

In the final part of our series, we will outline our plan to bring a Qubic-based stablecoin to life. We’ll cover our fundraising strategy, potential sources of capital, and how we plan to use the funds. We'll set clear goals and explain how this initiative will drive long-term value and growth for the Qubic ecosystem.

Read “The Case for a Qubic Stablecoin” Series

1. 🇺🇸The Case for a Qubic Stablecoin - Part 1: The Why Question
2. 🇺🇸The Case for a Qubic Stablecoin - Part 2: Marketing Qubic
3. 🇺🇸The Case for a Qubic Stablecoin - Part 3: The Best Option
4. 🇺🇸The Case for a Qubic Stablecoin - Part 4: Fast, Faster, Qubic
5. 🇺🇸The Case for a Qubic Stablecoin - Part 5: Growing the Ecosystem

For the latest updates, join the Valis Discord, follow us on X, and bookmark our blog.

On this Page

• The Case for a Qubic Stablecoin - Part 4: Fast, Faster, Qubic
• Recap
• Introduction
• Before We Start
• Key Concepts
• Transfer Scenarios
• Transfer Generation
• Network Parameters
• Deciding What to Measure
• Performance Today
• First Gear
• Second Gear
• Third Gear
• Fourth Gear
• Fifth Gear
• An Uneven Crown
• Performance Tomorrow
• Qubic Core Team
• Valis Team
• Kneel to the Crown
• Coming Up: Valis Proposal
• Read “The Case for a Qubic Stablecoin” Series