Could pruned nodes eventually help with Intial Block Download?

[Antidote47k]

I was going through this week’s Optech newsletter and I came across Lucas Lima’s proposal on delving Bitcoin which essentially explains how fountain codes could help pruned nodes contribute to Initial Block Download (IBD).
One of the major drawbacks of running a pruned node is that while it saves storage space, it can’t help new nodes with IBD because it no longer has the complete blockchain. If more pruned nodes could contribute to IBD, the burden of storing and serving historical blockchain data won’t fall entirely on archival nodes

The core concept of the idea is that instead of storing every old block, a pruned node would store encoded pieces called droplets. Now a new node will not need all the original  pieces, it will only need enough droplets collected from different peers to reconstruct the original data.
Lucas wrote a Blogpost explaining the proposal in more detail for anyone interested in the technical side of it.
 
While the proposal is interesting it also comes with some trade offs. Developers have pointed out concerns that the proposal would require multiple connected peers to function, compared to a single archival node. There are also concerns about slower IBD, possible node fingerprinting, a larger DoS attack surface and more computational power will be required to encode and decode droplets.
What do you think? Should more responsibility for helping IBD be distributed across the network, even if it introduces additional complexity?

[retaur]

This might be solving a problem that doesn't exist and won't exist for quite a bit of time.

Nodes were very resource intensive I don't think they are anymore as the internet and computers got stronger and more budget friendly.

I'm also wonder if making more things like this actually starts to discourage people from running full nodes themselves and that could be a bad thing if it limits decentralisation or enthusiasm for the tech.

[ABCbits]

The core concept of the idea is that instead of storing every old block, a pruned node would store encoded pieces called droplets. Now a new node will not need all the original  pieces, it will only need enough droplets collected from different peers to reconstruct the original data.
Lucas wrote a Blogpost explaining the proposal in more detail for anyone interested in the technical side of it.

The idea is really cool, but i doubt it's practicality. If i understand it correctly, a fresh node (haven't download any block) probably need to download droplets few hundred different nodes to reconstruct whole blockchain data. And if you want to reduce the number of node, each node to store more or bigger droplet, which means higher storage requirements.

Nodes were very resource intensive I don't think they are anymore as the internet and computers got stronger and more budget friendly.

But considering UTXO growth and price rise of RAM and storage, IMO running node isn't that budget friendly.

[Mia Chloe]

If i understand it correctly, a fresh node (haven't download any block) probably need to download droplets few hundred different nodes to reconstruct whole blockchain data. And if you want to reduce the number of node, each node to store more or bigger droplet, which means higher storage requirements.

Instead why not just download the whole Blockchain and sync? Pruning is efficient for storage optimization but when it comes to assisting other nodes to synced I doubt they will be of much help. To start with I don't 💬 the pruning would even be possible is the Merkel tree wasn't a thing.

Even as a node of you try to share a snapshot the receiver will also need to verify the snap shot is an authentic one based on the actual data that's in the block chain.

[NotATether]

I have a pruned Bitcoin node and a Monero node, and I disagree with this whole "pruned node IBD contribution" idea. The very act of running a node contributes to the ecosystem in other ways. For example, my nodes are attached to BTCPayServer, and doing this has actually allowed me to fix a few bugs that I found in the BTCPayServer software.

[ABCbits]

If i understand it correctly, a fresh node (haven't download any block) probably need to download droplets few hundred different nodes to reconstruct whole blockchain data. And if you want to reduce the number of node, each node to store more or bigger droplet, which means higher storage requirements.

Instead why not just download the whole Blockchain and sync? Pruning is efficient for storage optimization but when it comes to assisting other nodes to synced I doubt they will be of much help. To start with I don't 💬 the pruning would even be possible is the Merkel tree wasn't a thing.

That's exactly why blog mention the pruned droplet doesn't only most recent blocks and block header, but also multiple random set of blocks called "droplet".

Even as a node of you try to share a snapshot the receiver will also need to verify the snap shot is an authentic one based on the actual data that's in the block chain.

Yeah. The goal of the idea isn't to avoid verification, but rather giving node (who doesn't want to store whole blockchain) have bigger role on IBD. Note that pruned node currently only relay latest 288 blocks, no matter how many recent block it actually store.

If signaled, the peer MUST be capable of serving at least the last 288 blocks (~2 days).

[Mia Chloe]

Yeah. The goal of the idea isn't to avoid verification, but rather giving node (who doesn't want to store whole blockchain) have bigger role on IBD. Note that pruned node currently only relay latest 288 blocks, no matter how many recent block it actually store.

Hmmm that does make sense. I think was missing the main point initially since I was thinking if a new node still has to reconstruct and verify the blockchain from all these droplets there didn't seem to be any practical advantage over simply downloading and syncing the blockchain normally.

Based on the idea that pruned nodes already reduce storage requirements while still validating the chain, even if they can't serve historical blocks. But it's all clear now though thanks.

[Antidote47k]

This might be solving a problem that doesn't exist and won't exist for quite a bit of time.

Nodes were very resource intensive I don't think they are anymore as the internet and computers got stronger and more budget friendly.

I'm also wonder if making more things like this actually starts to discourage people from running full nodes themselves and that could be a bad thing if it limits decentralisation or enthusiasm for the tech.

Well I think your concerns about discouraging people from running full nodes is valid but it’s not necessarily replacing them, the proposal is to help shoulder the burden and blockchain keeps growing everyday so when you put things into perspective, the long-term storage requirements are a scalability consideration.
 

The idea is really cool, but i doubt it's practicality. If i understand it correctly, a fresh node (haven't download any block) probably need to download droplets few hundred different nodes to reconstruct whole blockchain data. And if you want to reduce the number of node, each node to store more or bigger droplet, which means higher storage requirements.

I think this is a fair point, there is definitely a trade off between reducing the amount of data each node stores and number of nodes needed to reconstruct the blockchain, more data leads to more storage requirements and less  data stored per node would require more participating nodes. The practicality of coordinating enough sources and ensuring reliable reconstruction is something that would need to be carefully considered.
That said I think the motivation behind the proposal is genuinely an interesting one because it’s trying to address  long term challenge which is maintaining historical data availability as the blockchain continues to grow without without requiring every participant to maintain a full archival node

I have a pruned Bitcoin node and a Monero node, and I disagree with this whole "pruned node IBD contribution" idea. The very act of running a node contributes to the ecosystem in other ways. For example, my nodes are attached to BTCPayServer, and doing this has actually allowed me to fix a few bugs that I found in the BTCPayServer software.

Yeah I agree with you but the proposal is not necessarily disputing the fact that pruned nodes already contribute to the network in other ways, the idea is that it could also contribute to IBD by contributing historical data with a lower storage barrier while keeping node operation more accessible.