3
1
The following idea is so simple that I cannot believe that it is really new. It must have been presented and discussed at length (and rejected) previously, but I submit it nevertheless, for lack of having found any mention of such discussions.
The basic idea is simple : when a (full) node successfully adds a block to its copy of the blockchain, it broadcasts an inv message giving its address and the identity of the block.
Every node is thus able to maintain for every block a list of nodes having that same block in their blockchain. That inventory will normally be separate from the local blockchain.
Now every node can decide, based on local considerations, whether to include a block in its local blockchain or to only include a small placeholder and call upon other nodes if and when the full contents of that block are required. That would be a base for a genuinely “distributed” blockchain.
In practice, all nodes would probably want to initially include all full blocks, since at that time they would not have identified enough nodes carrying the same block. A capability to replace an existing block with a reference to other nodes would therefore be required. To that effect, block headers should include a reference to the (local) list of alternate source nodes for that block.
A node could then simply erase the payload of a node in its copy of the blockchain, retaining only the header unchanged, including the hash of the full block and of the previous block to retain continuity of the chain. Of course that should be broadcast so that the ofher nodes update their local table of alternate sources.
When a scan of the blockchain hits a block with an empty payload, the node could return a "block unavailable" answer (for instance if multiple nodes are being queried), or the local list of alternate sources for that block could be used to retrieve a copy (or many copies for verification purposes), which could be checked using the hash retained in the abbreviated header.
Some mechanism for ensuring that each block exists in full version on a sufficient number of nodes would be required.
What is wrong with that proposal ?
Agreed, but some nodes must keep the entire blockchain. I understand that presently many thousands do, and that their number is considered problematically low by some.Those are the nodes I am talking about. Now you say that the size of the blockchain is not a problem for those. II have every respect for your opinion, but I have also read comments to the contrary. – Gérard Dréan – 2016-07-25T19:18:58.347
In a nutshell, my suggestion would introduce an intermediate status between full node and thin client,"half-full" nodes being able to keep summaries of certain blocks. The local blockchain would include a mix of full blocks and summary . Peers would be called upon when the full contents of a summary block are needed. That would be best implemented by using a derivative of the SPV protocol on a block-by-block basis rather than for the entire blockchain. There should be a mechanism to ensure that a node always keeps certain blocks in full format (that might turn out to be a tricky part). – Gérard Dréan – 2016-07-26T09:37:48.010
My hope is that, even if the number of full nodes decreases, the number of « half-full » nodes will more than compensate, and that for each block in the blockchain, the number of nodes with a reliable copy of that block will increase.
That being said, I am quite prepared to accept that, after going through the likely behaviour of node operators and through the arithmetic of additional storage required vs storage saved, plus additional processing required, the whole proposition may be pointless as you suggest. I feel personally unable to go through that reasoning, for lack of relevant data. – Gérard Dréan – 2016-07-26T09:38:24.857