The assumed use case of Ledger checkpoint feature #fabric #ledger-checkpoint


nekia
 

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