Our tech team has been heavily working on Integritee Network’s sidechains. Our goal was to find limits to measures such as throughput, and the number of concurrently connected clients, which block times work better — 300ms or six seconds? — but also the size of the state, and other details. Read through and get reminded about how numbers and stats matter.
The objective of benchmarking was to find limits to the following measures:
- Throughput: How many transactions per second (tps) can we process on a sidechain for different blocktimes (300ms, 6s)?
- Number of concurrently connected clients
- Size of the state (and #Accounts)
For sdk-v0.1.0-polkadot-v0.9.26, running on Intel(R) Xeon(R) E-2176G CPU @ 3.70GHz with 32 GB RAM
- With a 300ms blocktime we can process up to 1900 tps and at least 38 tps at a state size of 4000 accounts
- With a 6s blocktime we can process up to 900 tps and at least 10 tps at a state size of 100’000 accounts (around 20MB)
- Typical throughput is 500 tps
- At least 250 clients can connect to one validateer concurrently and send at least one tx per block
With identified state handling improvements, we should be able to improve state size degradation by 6x:
- With a 300ms blocktime 38 tps at a state size of 24’000 accounts
- Down to 300ms block time
- 500 tps typical per sidechain, degrading above 5’000 accounts state size
- 250 wss concurrent client connections per validateer
- Overall sharded throughput of Integritee Network currently extrapolates to 50k tps (improvements of Polkadot protocol and our sidechain finality can potentially push this towards an estimated 1–4M tps)
During benchmarking, a variety of performance improvement opportunities were identified:
With Polkadot improvements (asynchronous parachain validation allowing 2s weight with 6s block time), this may increase by an estimated 10x.
With block confirmation rollups, this may increase by an estimated sqrt(49): 7x leading to a potential in the order of 2.8M tps for isolated shards.