Published on: 2014-04-10T22:33:36+00:00
The email thread and forum discussions revolve around various proposals and ideas for improving the storage and distribution of the blockchain. One suggestion is to form "superblocks" that are chained together, which would allow participants with limited resources to serve full portions of the blockchain. However, it is noted that the block chain mostly consists of random bytes that do not compress well, making this proposal challenging to implement.Another proposal discussed is the possibility of nodes compressing and storing earlier transaction sets as archive sets to conserve disk space and network activity. The idea is that nodes could serve up these archive sets conditionally, with only a certain number open at any given time while the others remain compressed on disk. This would allow nodes to have all full transactions but still not respond about every possible transaction. The archival process could be based on a rotational request period or done periodically. Clients would have to piece together archive sets from different nodes if there aren't enough archive nodes to cover the entire chain.The concept of a fixed range for nodes that host all history is also explored. The suggestion is to burn the node implementation, block data, and live operating system on a read-only medium, allowing for the distribution of 'pieces of history' in a self-contained form. This would be useful when nodes that host all history become rare. Peer selection would involve seeking nodes that have the least rarity in the ranges they offer, rather than preferring to fetch blocks from someone with a large range if they are one of only a few nodes with that range.In a separate forum discussion, the idea of having a static node that only serves a fixed range of blocks, such as the first 100000 blocks or a specific range like block 100000-200000, is proposed. The main concern raised is why a node would not follow the consensus, as verifying blocks is relatively cheap and bandwidth is necessary for serving historic blocks. It is suggested that nodes should keep the most recent blocks for reorgs and add the fixed range they serve. Peer selection should prioritize nodes that offer the needed blocks and have the least rarity in the ranges they provide.The discussion then shifts to chain pruning, with the argument that it is more practical to specify blocks to keep in terms of megabytes rather than time, as nodes have resource constraints. A new addr field is proposed to specify how many blocks from the chain head are stored, and nodes can connect to check if their chain head minus the number of blocks stored is higher than the current chain height. If so, a getaddr request would be made to find nodes storing far enough back.Overall, these discussions highlight the ongoing efforts to find efficient storage and distribution solutions for the blockchain, taking into account factors such as compression, resource constraints, and peer selection. The proposals and ideas presented aim to address the challenges posed by the size and nature of the blockchain while ensuring the integrity and accessibility of its data.
Updated on: 2023-08-01T08:44:30.223786+00:00