Fountain Codes: a way to reduce blockchain storage costs

The email mainly explores an innovative approach to enhancing data recovery in distributed networks by optimizing the use of anonymity groups and storage reduction. The strategy involves selecting a set number of blocks, specifically 1008, which matches half of a retarget interval, and defining 100 anonymity groups. Each node within this framework selects its anonymity set once and maintains specific droplet compositions across intervals to ensure efficient data recovery and bandwidth utilization.

A significant aspect of this method is the introduction of a storage reduction factor of approximately 1.6% (1/63), resulting in a total storage requirement of around 11GB and an addition of about 32MB per week. This is achieved through a unique arrangement of droplets, 1600 in total, ordered by degree and designed according to the Robust Soliton distribution with specific parameters (c=0.0 and δ=0.1). This structured setup allows each node to store and manage data more effectively, with the potential to connect to 76-80 honest peers across different anonymity groups to recover all necessary data.

Additionally, the proposed system facilitates the detection of dishonest peers upon downloading any compromised droplets, thereby maintaining data integrity. The flexibility of the system is further highlighted where the parameter 'r' can be adjusted per node, allowing for variations in storage requirements by selecting multipliers for storage use. This nuanced approach suggests a balance between optimal encoding methods like Reed-Solomon and the precise error detection offered by the SeF-peeling scheme.

In practical terms, the implementation of this system during Initial Block Download (IBD) would involve downloading blocks in batches of 1008, processing them, and then proceeding to the next set. This could potentially compete for memory resources on systems with lower memory capacities, especially if the block cache for peeling competes with other critical caches like leveldb utxo. The discussion also hints at a possible need to adjust the size of 'k' to manage memory usage more efficiently, although reducing 'k' might necessitate an increase in the number of required peers or the amount they need to store.