Blockchain scaling has received extensive attention in the past decade with a large number of protocols proposed in the literature such as Prism.
In this blog post, we will take a first-principles approach to scaling the Subspace protocol.
For any blockchain system, we have at least three physical constraints: (1) communication constraint - the upload bandwidth of a participating node, (2) computation constraint - the number of transactions executed per second by a node, and (3) storage constraint - the number of transactions stored by a node. The goal of blockchain scaling is to achieve the maximum possible throughput under these physical constraints, measured by TPS. (Delay is another important metric for blockchain scaling, which is beyond the scope of this post.)
In a conventional blockchain design, a participating node (often referred to as a full node or a miner) has to download, store, and execute all the transactions. This requirement leads to several upper bounds. For example, the throughput cannot exceed the average upload bandwidth divided by the average size of transactions. Let us put some numbers here to illustrate this. For instance, if the average bandwidth is 10M bits per second and the average size is 250 bytes, then the throughput cannot exceed 5000 TPS under the communication constraint - too small for certain applications.
Can we achieve a throughput of 500,000 TPS? One way is to increase the upload bandwidth to at least 1G bps, but it sacrifices decentralization because nodes with low bandwidth cannot participate. Another way is to break the requirement of having every node download, store, and execute all the transactions. As we have seen in the previous blog posts, the Subspace protocol already breaks the requirement of every node storing and executing all the transactions via distributed storage and decoupled execution. Therefore, our final step is to break the bandwidth requirement to achieve scalability, which will be explained in the coming Part 2.