Why do we need sharding?

Using bots trading DIP-20 tokens on the Internet Computer mainnet, we have determined that having more than about 150 users simultaneously trying to send traditional tokens will result in significant delays and timeouts, requiring users to continuously retry their transactions until they are successful.

Bots tried to execute 1 transaction each, all at the same time. If there was an error, each bot retried after 1-4 seconds.

Starting at around 150 concurrent users, there are minor inconveniences: a few rejected calls that need to be retried and ~4-20 second delays.

However, starting at around 750 concurrent users, the transaction backlog starts to pile up, and transaction times start to grow exponentially into the minutes.

These results on mainnet are also consistent with tests on a local replica, which also determined that transactions were unfeasible starting at around 1,000 concurrent users.

How do we solve this scalability problem?

While this problem can be somewhat incrementally diminished as the Internet Computer scales up individual throughput to its subnets, there will still be a limit to how many users can transact at the same time. The problem is that all transactions have to be processed sequentially in order to avoid double spending.

To solve this problem, and also to take advantage of the Internet Computer's "infinite scalability", we assign users to different shards, and shards communicate with themselves as described in the next section.