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


david liu <david-khala@...>
 


Sounds like you are looking for a peer could be started as a service normally while do not necessarily need replay and verify from genesis block. And your provided way is a slightly complex steps to do that.

But I see the complexity so far is acceptable.

Best Regards,
David Liu

发件人: fabric@... <fabric@...> 代表 nekia <atsushin@...>
发送时间: 2020年8月28日 16:48
收件人: fabric@... <fabric@...>
主题: Re: 回复: [Hyperledger Fabric] The assumed use case of Ledger checkpoint feature #fabric #ledger-checkpoint
 
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