It's known that even when pruning comes there will continue to exist the historical node.
Having a pruned node is enough to be considered as equally a full node as a historical node, or would the pruned one need to rely on a historical one to be considered a valid full node?
Similarly would a rebroadcaster representative be capable to use a pruned node?
Just wondering how pruning would work as a relief to the network...
pedfx
All 2 comments
Hi, it is probably best if I just pass on Roy's answer to this question from last week as it is quite detailed.
"Ledger pruning is still being planned, and there will likely be nodes which contain more or less history for a group of accounts (up to the entire ledger). However, this will not increase centralization because the only blocks of the ledger that will be elided from a full node will be blocks that are validated by their successors. In Nano, each frontier (the head block of an account's chain) is the head of a Merkle tree with 1 or 2 predecessor blocks (2 if it's a receiving block, 1 otherwise) and the confirmation of that block, therefore, confirms every predecessor in the Merkle tree. This is what enables lazy bootstrapping to be successful but it also allows for many blocks to be elided from full node ledgers since 1. Nothing can be built on top of them. Blocks may have only one successor, frontier blocks have no successors so they cannot be elided since their successor has been confirmed by a majority of the network by weight; 2. Nothing can be built referencing them. Sending blocks may only be received once, if the corresponding receiving block has been generated for a send block then no further references can be made to it. That is, the majority of blocks currently on full nodes will never be used again and are only useful for verifying that the Merkle tree constructed is valid, which also has to be confirmed with the network for the head of those Merkle trees, which means validating the head of those Merkle trees, so just don't store a copy of the unreferencable (either by predecessor or receiving) blocks. If a node wants a copy of the full ledger for historical or analysis purposes there will be nodes on the network keeping a full ledger that can be validated by any node based on their current set of blocks without relying on any external resources, centralized or decentralized at that point."
nanotroy
on 22 Aug 2018
Closing based on "thumbs up". Eventually documentation will follow implementation.
rkeene
on 23 Aug 2018
Related issues
frankh
路
3Comments
BitDesert
路
6Comments
henry701
路
5Comments
hskang9
路
4Comments
cryptocode
路
4Comments
Most helpful comment
Hi, it is probably best if I just pass on Roy's answer to this question from last week as it is quite detailed.
"Ledger pruning is still being planned, and there will likely be nodes which contain more or less history for a group of accounts (up to the entire ledger). However, this will not increase centralization because the only blocks of the ledger that will be elided from a full node will be blocks that are validated by their successors. In Nano, each frontier (the head block of an account's chain) is the head of a Merkle tree with 1 or 2 predecessor blocks (2 if it's a receiving block, 1 otherwise) and the confirmation of that block, therefore, confirms every predecessor in the Merkle tree. This is what enables lazy bootstrapping to be successful but it also allows for many blocks to be elided from full node ledgers since 1. Nothing can be built on top of them. Blocks may have only one successor, frontier blocks have no successors so they cannot be elided since their successor has been confirmed by a majority of the network by weight; 2. Nothing can be built referencing them. Sending blocks may only be received once, if the corresponding receiving block has been generated for a send block then no further references can be made to it. That is, the majority of blocks currently on full nodes will never be used again and are only useful for verifying that the Merkle tree constructed is valid, which also has to be confirmed with the network for the head of those Merkle trees, which means validating the head of those Merkle trees, so just don't store a copy of the unreferencable (either by predecessor or receiving) blocks. If a node wants a copy of the full ledger for historical or analysis purposes there will be nodes on the network keeping a full ledger that can be validated by any node based on their current set of blocks without relying on any external resources, centralized or decentralized at that point."