FastPay: The Heart of Sui

Thanks to FastPay, a groundbreaking technology that forms the foundation of a horizontally scalable Byzantine Fault Tolerant (BFT) system, Sui has unlocked the potential for unprecedented transaction throughput. FastPay allows a set of authorities called a committee to support more transactions throughput by adding more shards or workers, achieving a horizontally scalable system.

Today, we will delve into FastPay, explaining how they work while keeping everything as simple as possible so that general readers can comprehend and understand.

Overview

In the FastPay paper, FastPay is introduced as a side chain of the main blockchain, called Primary for short. FastPay consists of two types of participants: users, or account owners, and authorities. Users are individuals who maintain accounts on FastPay, utilizing them to engage with other accounts by sending and receiving funds. Authorities, as its name suggests, authorize or certify payments and keep track of all accounts in FastPay.

A payment is considered finalized when a sender gets a sufficient number of signed messages, which approve the payment's validity, from at least 2/3 of all authorities—referred to as a "quorum." The FastPay protocol is considered BFT because it can tolerate up to 1/3 of Byzantine or faulty authorities.

How does it work

Figure 1: This figure illustrates the transaction flow in FastPay.

Ref: arxiv.org/pdf/2003.11506.pdf

Instead of letting a validator batch user transactions into a block and broadcast the block to other nodes like traditional blockchains, FastPay revolves around users who initiate a transaction. Assume Alice wants to send some funds to Bob. Alice first creates a transfer order ➊ by specifying Bob's FastPay address, the amount to transfer, a sequence number, and lastly, Alice's signature for the data. Note that a sequence number is a unique number starting from 0, which acts like a nonce in blockchains and is used to prevent a malicious actor from repeatedly submitting the old transaction to the network. Alice then sends the signed transaction to all authorities.

Upon receiving the Alice transaction request, each authority will check the validity of the transaction ➋ by ensuring that:

(i) The signature is valid.

(ii) Alice has no pending transactions.

(iii) The amount of the fund is positive.

(iv) Alice's balance is sufficient.

(v) The sequence number matches the expected sequence number.

The matched expected sequence number here means that if Alice's latest sending transaction before this transaction is N, the expected sequence number must be N+1. If the transaction passes all the checks, the authority then records the Alice transfer as pending and sends back his/her signature to Alice ➌.

Once Alice is able to gather the signatures of a quorum, i.e., 2/3 of all authorities, she can form a certificate for the corresponding transaction. Now, to finalize the payment, Alice can broadcast her certificate to the authority committee ➍ or send the certificate to Bob ➎ as a proof, allowing Bob to broadcast it to the authorities on her behalf ➏.

When an authority receives the confirmation order or the certificate, it will proceed to:

(i) Check if the number of signatures is sufficient to form a certificate.

(ii) Decrease Alice's balance according to the sent amount.

(iii) Increase the sequence number by one to ensure the uniqueness of each transaction.

(iv) Change the previous pending status of the Alice account to none.

(v) Keep the certificate to his/her list of all certificates.

(vi) Increase Bob's balance according to the sending amount,

which is shown in the step ➐ in figure 1 above. This concludes the interaction between Alice and Bob on FastPay.

Horizontal Scaling

Each payment that occurs in FastPay requires minimal state sharing. An independent transaction, that is, a transaction sent by Alice to Bob and Charlie to Dave, is independent and requires up to two interactions between two accounts, which means that each payment transaction can be handled independently. For simplicity, let’s imagine that one computer is required for one transaction at a time, so these asynchronous transactions can be distributed to different computers. This allows an authority to horizontally scale their system by adding more computers, where each computer processes a stream of transactions in parallel with the others. In the real world, one just needs to scale up the number of CPUs to handle more transactions instead of computers.

Some Results

The fact that the horizontally scalable architecture makes FastPay seem to be a quite promising protocol for supporting a large number of transaction loads at a time. There are also many variables that affect the performance of the model. The number of authorities and shards is one of the obvious parameters. Even though scaling up the number of shards leads to a higher system’s throughput, increasing the number of authorities, on the other hand, makes the confirmation of transactions slower.

Figure 2: The confirmation order throughput plot with the number of shards and the in-flight parameter (the maximum number of transactions that are allowed into the system at any time).

Figure 3: The confirmation order throughput plot with the number of authorities for 45 and 75 number of shards, where in-flight parameter is fixed to 1,000.

Ref: arxiv.org/pdf/2003.11506.pdf

Figure 2 shows that the throughput of the system is increasing linearly with the number of shards, as we expected at first. Then, it plateaus after around 48 shards (according to the paper). This happens because they run on a 48-core physical machine. Figure 3 is quite interesting. It shows that system throughput decreases drastically when the number of authorities increases. This behavior is intuitive because a user needs more time to interact with all authorities to form a certificate.

Conclusion

Sui has extended the idea of FastPay to achieve horizontal scaling for independent transactions and achieve exceptional throughput. However, blockchain interactions aren’t limited to just independent payments. In general, they involve interactions with share states, such as providing liquidity, NFT marketplaces, and swapping through liquidity pools. In these scenarios, FastPay alone may not suffice, requiring the help of other protocols and extra design. Although FastPay seems to not be suitable for general use cases, they pave the way for blockchains for horizontal scaling, offering the new idea for other protocols to extend upon its foundation and explore new breakthroughs in blockchain technology.