Fountain Codes: a way to reduce blockchain storage costs

The discussion revolves around the efficiency and practicality of blockchain storage strategies, particularly focusing on the utilization of deterministic droplet composition based on a per-peer seed and block height. This approach allows peers to construct droplets as they proceed, which not only saves data but also ensures unbiased random selection of droplets. With the parameters $k=1,000$ and $s=10$, the method demonstrates how specific sets of droplets for predetermined blocks are determined and constructed incrementally as the blockchain grows. This strategy results in significant storage savings, requiring just a fraction $s/k$ of the space that would be needed to store all blocks.

The economic implications of this method are further discussed, suggesting various savings ratios such as 100x and 20x, which translate into substantial reductions in disk space usage—from approximately 7GB to 35GB—compared to the traditional requirement of storing around 700GB of old blocks. Such an approach could potentially enhance the availability of blockchain copies for download, making it a strategic choice for future-proofing blockchain technology despite minimal immediate improvements in availability. Currently, there are about 27,000 NODE_NETWORK_LIMITED listening nodes and 24,000 NODE_NETWORK listening nodes, indicating a minor increase in available copies from 24,000 to 24,030 with the adoption of this new method.

Additionally, the strategy impacts network dynamics during Initial Block Download (IBD) by increasing the number of connections required with pruned peers, who typically do not facilitate IBD. The suggestion includes optimizing connection strategies such as using block-relay-only connections during IBD and then reconnecting for transaction relay post-IBD to manage the load effectively. Moreover, issues related to peer reliability and data integrity are touched upon, emphasizing the potential need to disconnect or ban peers providing incorrect data while retaining any useful droplets they might have provided.

Finally, the discussion briefly addresses technical considerations related to the serialization sizes of blocks within droplets, noting possible complications when blocks within a droplet vary significantly in size. This scenario could amplify storage requirements, although it is viewed as a manageable risk unless $k$ (the total number of blocks) is exceedingly large, highlighting the nuanced challenges in implementing this blockchain storage optimization technique.