Introduction

TPS stands for transactions per second. It is a measurement unit defined as the number of atomic actions performed by a certain entity per second. 

It has been one of the key metrics for evaluating the capacity, scalability, and efficiency of a credit card payment system, especially when managing high transaction volumes, such as during peak shopping seasons. Later, it has also been adopted for the data transaction rate of a cryptocurrency. However, in both cases, TPS has deviated from the initial meaning.

For example, a credit card payment involves several internal steps oblivious to a buyer, such as transaction initiation and request, authorization request and response, confirmation, clearing, settlement, and reconciliation. However, TPS in this case measures only the number of transactions that can be initiated and authorized within a single second, and not necessarily their settlement and all (atomic) steps prior to it. While initiation and authorization happen in real-time, settlement may take up to a few days since it’s a batch process. 

For cryptocurrencies and blockchain technologies, there is no generally accepted notion of TPS and the definition varies depending on the network. For some, TPS means the throughput of transfer orders, while for others the throughput of confirmation orders. Some take into account internal transfers, spam transactions, or simplified workloads, when these shouldn’t even be part of the equation.

In this blog post, we will dive deep into TPS, finality, and what they mean for FastSet. We will highlight some metrics and emphasize the need to move beyond the limitations of the chain technology and adopt the set to achieve true scalability and higher TPS.

Why TPS still matters

TPS may be discouraging to use as a metric in Web3 since there is so much heterogeneity and inconsistency around.

One needs to pay special attention to the architecture of a chain to understand what TPS actually means for it and to figure out if the numbers have been artificially inflated or not.

Nevertheless, TPS is a means for measuring above all the scalability of a system. Yes, security and decentralization are also relevant. However, we knew how to secure the network and make it decentralized. Achieving true scalability has been more challenging, but FastSet attains it by renouncing the chain and the total order restriction for its settled transactions. More here.

We keep TPS on the table because we do not compromise on decentralization and security. We simply provide a better, next-generation protocol achieving naturally high TPS. 

TPS and finality on FastSet

In FastSet, TPS refers to the number of claims per second that can be effectively settled. Transactions are a typical example of claims, but FastSet is more than just settling transactions. Any verifiable statement can be settled on FastSet.

Let's briefly recall the 7-step protocol of FastSet (Figure 1).

Figure 1: FastSet protocol.

A client broadcasts to all validators an ordered block of verified claims in a signed message (Steps 1 and 2). Each validator checks the validity of each block and, if everything checks, it approves the block by signing the message (Step 3) and sending it back without updating its state yet (Step 4). Once a client collects enough approvals from the validators (i.e., a quorum is met), a confirmation message is broadcast to all validators, certifying the claim (Step 5). Once a validator becomes aware of the certificate, it proceeds to update its state (Steps 6 and 7). Eventually, all validators will consistently settle all the valid claims made by the clients.

For more details, see our documentation or whitepaper.

So, in FastSet, a transaction in TPS refers to the entire settlement process of a claim, from when the verified message enters the network (first purple arrow in Figure 1). Steps 3 through 7. Such a “transaction” may imply several atomic actions, but that’s not the TPS definition we’re going with. 

In FastSet, TPS stands for the number of transactions/claims settled by the network in one second. Or the number of claims reaching finality in one second.

Before we talk numbers, let's briefly cover what finality means in FastSet.

While TPS shows the performance and scalability of the entire network, finality refers to its latency, from the perspective of one transaction. In brief, finality means the time it takes the network to settle one claim.

In FastSet, we have two notions of finality: global and local. Local finality refers to how much it takes for one validator to validate the claim, i.e., Steps 3 and 4. Global finality adds to local finality Steps 5 through 7. It collects all the claim signatures after local finality, aggregates them into one aggregated signature—the validation certificate for the claim, sends the certificate back to all validators, and settles the claim by applying its effect (e.g., updating the balances). 

Both notions refer to one validator, as in FastSet validators do not communicate with each other. However, there is an important difference between the two, as global finality is as final as it can be, meaning that the state of the validator is changed irreversibly. For local finality, there is no state change yet, at least not with respect to the claim that has been validated by that validator.

100k+ TPS and sub-100ms finality

At the launch of the Devnet last month, we advertised 100K+ TPS:

Since, we hit 126K+ TPS and we’re not stopping:

Take a moment to observe the value behind these results. They have been obtained on middle-end machines, and not large enterprise rigs.

The affordable hardware not only shows the potential for broader decentralization, but also the difference the FastSet protocol makes on Web3.

FastSet is a horizontally scalable protocol. This is due to the fact that, in FastSet, we do not enforce a total order on claims. Being much more flexible on claim ordering processing, but preserving the same security guarantees, FastSet validators can process claims in parallel.

Local finality is under 1ms because the validator simply checks and signs the claim as valid. It also “freezes” the claim sender until global finality, meaning it cannot process other claims from that sender until the initial claim is settled. Global finality adds a round-trip message on top of local finality, which is as optimal as it can theoretically be. That’s why in FastSet, it is under 100ms.

Conclusion

At Pi Squared, TPS stands for how many claims can be validated and settled within a single second. It captures the entire settlement process. No wordplay. No artificial inflation. 

FastSet scales horizontally, and our theoretical results prove that mathematically, we have no maximal limit on TPS. We can already process more transactions per second than traditional blockchain technologies, and if we want to increase our TPS, we can simply add more validators to the network. 

Stepping away from the chain and embracing the set is what is really needed for true scalability and higher TPS.