Sharding as a blockchain scaling solution doesn’t work

Getting your Trinity Audio player ready...

Imagine if Chase Bank and Citibank required that their ledgers were in sync before committing a new transaction to their database. This is how Ethereum and any other account-based blockchains operate. In an account-based model, users have a balance of their tokens or coins associated with an address or an account.

Take John from the U.S. who lives paycheck to paycheck. On Thursday, John has zero dollars in his bank account at Chase. Tomorrow, (a Friday) John gets paid. To spend his money, he must wait until the credit to his account arrives. From Chase Bank’s perspective, John cannot spend from his account until the balance is positive. John can only buy dinner at a fancy restaurant on Friday night after the credit clears at the bank. The credit must be processed before the debit, in order. This is manageable for a private database where only one entity is responsible for maintaining updates to their ledger, but not for an open, public ledger where many parties are constantly writing updates to various accounts.

Ethereum (and other account-based models) must process transactions sequentially. This is why gas prices on the network rise when high demand exists to use the network. Users bid up fees above each other to get their transaction sequentially processed before the other.

To solve this scalability problem, Ethereum developers have proposed sharding (or more commonly known in computer science as multi-threading) to solve this issue. Different nodes process different sets of transactions horizontally across the ledger to increase throughput. However, if we consider the implications when more transactions are being processed, we can conclude that this solution is akin to kicking the can down the road.

Firstly, given the above banking example only certain transactions can be processed across shards in parallel, those that do not update the same account or state of an object (think a digital pet, or attributes of an in-game weapon). If Shard A attempts to process the debit of John’s dinner before Shard B attempts to process John’s required credit, then the transactions are invalid. Therefore, shards are limited to parallelizing only certain transactions. Secondly, as demand increases transactions that need to be processed, how many shards is enough?

If demand across the network is 1,000,000 transactions per second, and we have 8 nodes who can process 125,000 each, what happens when one of the nodes cannot handle that volume?

Suddenly the bottleneck becomes the weakest node on the network who is too slow or crashes from the high demand. If sharding works at 1 million transactions it may not work at 10 million or 100 million. Sharding is a mitigation at best, not a long-term solution. Perhaps this is why the technique has not been implemented yet, but “could ship sometime in 2023.”

Compare this approach to a UTXO-based model where the spending conditions of coins do not depend on another. For example, if I have a $1 and $5 bill in my pocket, I can spend the $1 without any consideration of the $5 bill. This is the trade-off Satoshi Nakamoto accepted when designing Bitcoin and one of the fundamental reasons it scales. Technically the $1 and $5 can be spent at different places at the same time, regardless of order. This is the opposite of John’s case above where transactions are required to be processed in order.

However, the trade-off is global state which while it is useful, does not scale. State can be calculated independently by users off-chain, for example summing up the coins associated with a Bitcoin address to get its ‘state.’ Nodes however do not care or have any such concept of balances, which is why Bitcoin horizontally scales simply by throwing more hardware and resources at the problem.

Watch: The BSV Global Blockchain Convention panel, The Future World with Blockchain