Incognito Performance

We evaluate the performance of Incognito based on its real workload on the mainnet, as well as on simulated workloads.

In evaluating the performance of the Incognito network, we focus on the privacy transaction throughput, more specifically the metric of transactions per second (TPS). Note that Incognito uses a UTXO based ledger. In most cases, fewer than 32 existing UTXOs are used as inputs and 2 new UTXOs are produced as outputs.

Figure 1. Transactions per second based on the number of inputs per transaction on a shard

In Figure 1, we show the TPS metric of one shard and two fixed outputs. In the best case, we have 4 TPS and only one input, and in the worst case, approximately 0.5 TPS and 32 inputs. It will be possible to improve the transaction throughput by using the batch verification technique presented in [Bunz et al., 2018]. We expect transaction throughput to increase twofold after this feature is implemented.


Figure 2. Transactions per second based on number of shards


Figure 3. TPS comparison among Incognito, Monero, Zcash, Grin, and Beam

Transaction throughput scales out linearly with the number of shards. Currently, with 8 shards active, Incognito is able to handle 26-33 TPS in the most common case (two inputs and two outputs per transaction). We are working on a new network topology to scale to 64 shards. With this, Incognito will achieve 266 TPS, a significantly higher number than that of other privacy blockchains. For example, 4 TPS for Monero1, 6 TPS for Zcash2, 10 TPS for Grin3 and 17 TPS for Beam4. Details are shown in Figures 2 and 3.

Related Topics


[Bunz et al., 2018] Bunz, B., Bootle, J., Boneh, D., Poelstra, A., Wuille, P., and Maxwell, G. (2018). Bulletproofs : Short proofs for confidential transactions and more. In 2018 IEEE Symposium on Security and Privacy (SP), pages 315-334. IEEE.


How is sharding going to affect Incognito’s performance? Is it a linear relationship between TPS and number of shards? Are there any penalties from cross-shard interactions?

If there are, I think each shard should strive to be “stand-alone”, meaning a dapp should reside on only 1 shard to lower the amount of cross-shard interactions.

Number of in-shard transaction per second increases linearly with the number of shards. While the delay or the number of cross-shard transaction won’t be effected when we increase the number of shards.