回复: [Hyperledger Fabric] The assumed use case of Ledger checkpoint feature #fabric #ledger-checkpoint


david liu <david-khala@...>
 

Dear Atsushi,

 

For the question 1, my thought is to ensure we use external backup procedure before terminating peer1 and peer2.

For the question 2 I wonder what is question bothering you since there is no a question mark in description.
But for the question in title I will say yes but I guess you are asking what will happen if a peer use malicious snapshot. Is it?

 

发件人: fabric@... <fabric@...> 代表 nekia
发送时间: 2020826 15:35
收件人: fabric@...
主题: [Hyperledger Fabric] The assumed use case of Ledger checkpoint feature #fabric #ledger-checkpoint

 

Hi Manish, Wenjian and team,

I watched the recorded video of the last contributor meeting where you shared the demo of Ledger Checkpoint feature. I'm looking forward to using this new feature :)

I have a couple of questions about the assumed usage of this feature:

 

  • Is the following understanding correct?
    Let's say, there are 2 peers (peer1, peer2) bootstrapped from genesis block and 2 peers (peer3, peer4) bootstrapped from a checkpoint in a chennel. If both peer1 and peer2 leave from the channel, there is no peer possessing all block data on its local. In this case, as we can see at the end of RFC, the channel is same as if it had been bootstrapped from a snapshot of same height. In another word, user can't retrieve data prior to the checkpoint from any peers. Whether this situation is acceptable or not is completely depending on the policy of network participants. If the participants still want to get access pruned data in some reasons (e.g. for analytics purpose, etc.) even in this situation, then fabric need to provide archiving feature somehow.

 

  • Is it possible for a peer to pretend that it's bootstapped from a checkpoint?
    Now we are thinking to prune data from peer bootstapped from genesis block by using a tool completely separated from peer command. As far as looking at the latest codebase, if we prepare "unofficial" bootstrappingSnapshot.info on the peer by hand, it looks that the peer will recognize that it's been bootstapped from a pseudo checkpoint after restarting node.


Kind regards,
Atsushi


nekia
 

Hi David,

Thank you for the reply. 

Let me make more clear about the question (the idea) 2.
In the current fabric peer, if I just prune local block data by deleting some of blockfiles, that will cause crash of peer clash when accessing deleting block afterward. But if a pseudo checkpoint is generated by 3rd part tool which is officially authorized to get access to the peer's local file system, and the checkpoint is pointing to the first block within the blocks on its local, then the crash can be avoided. That's because the peer recognizes with the pseudo checkpoint that some blocks have already been deleted from local file system. 

I also think that officially proposing ledger archiving/pruning as another feature of peer (e.g. peer prune ...) without employing any tricky ways such as I mentioned above is another option. But if I do that without any changes to peer node, I thought it's the only way.

Thanks,
Atsushi