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.
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.
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.
The protocol layer refers to the core layer of the blockchain system, defining its rules and mechanisms. Here:
The application layer refers to the layer where users interact with the blockchain through applications (user interfaces, dApps, and smart contracts). Here:
"Transfer" can be confusing because its meaning changes with context:
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.
Let’s distinguish the following transfer scenarios:
Given their impact on performance, let’s distinguish how transfers are generated:
Finally, let’s define key network parameters impacting performance:
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?
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:
| Gear | tDur | TxPT | Scenario | Gen | S. Contract | Txs | TfPS |
|---|---|---|---|---|---|---|---|
| #1 | 2.5 | 1024 | 1-to-1 | Tx | N/A | 410 | 410 |
| #2 | 2.5 | 1024 | 1-to-Many | SC | QUTIL-1 | ~10,250 | 410 |
| #2 | 2.5 | 1024 | 1-to-Many | SC | QUTIL-2 | ~16,525 | 410 |
| #3 | 2.5 | 1024 | 1-to-Many | SC | AIRDROP-1 | 1,024 | 150k |
| #3 | 2.5 | 1024 | 1-to-Many | SC | AIRDROP-2 | 1,024 | 1M |
| #4 | 2.5 | 1024 | 1-to-All | SC | AIRDROP-3 | 4 | 20M |
| #5 | 2.5 | 1024 | 1-to-Many | SC | QUTIL-3 | 1 | 55M |
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).
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.
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.
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.
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).
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).
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 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:
| Gear | tDur | TxPT | Scenario | Gen | S. Contract | Txs | TfPS |
|---|---|---|---|---|---|---|---|
| #1 | 0.2 | 4096 | 1-to-1 | Tx | N/A | 20,480 | 20,480 |
| #2 | 0.2 | 4096 | 1-to-Many | SC | QUTIL | ~10,250 | 20,480 |
| #3 | 0.2 | 4096 | 1-to-Many | SC | AIRDROP | 1 | M? |
| #4 | 0.2 | 4096 | 1-to-All | SC | AIRDROP | 1 | M? |
Do you think this is fast? Time to buckle-up.
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?
| Qubic | Without SC | With SC |
|---|---|---|
| 1-to-1 | Modest | Unknown |
| 1-to-Many | N/A | Fastest |
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.
| Gear | tDur | TxPT | Scenario | Gen | S. Contract | Txs | TfPS |
|---|---|---|---|---|---|---|---|
| #2 | 2.5 | 1024 | 1-to-1 | SC | VROLLUP-26 | 410 | 10,660 |
| #2 | 2.5 | 1024 | 1-to-1 | SC | VROLLUP-90 | 410 | 38,950 |
| #2 | 0.2 | 4096 | 1-to-1 | SC | VROLLUP-26 | 20,480 | 532,480 |
| #2 | 0.2 | 4096 | 1-to-1 | SC | VROLLUP-90 | 20,480 | 1,843,200 |