Thanks for proposing this! NIPoPoWs such as FlyClient is a key component on our light client roadmap, that makes it a research+engineering hybrid problem. Whether to use FlyClient and how to adopt FlyClient largely depends on how much confidence we have on its design proposal - a hard fork might be the cleanest way to add FlyClient but it’s also possible to do it on application layer.
As the FlyClient in the original paper is designed and only proved secure for Bitcoin, we need to devise a proper variation for CKB before we implement it. I can see some obstacles and I’ll just quote them below:
There’re two problems to solve when we apply FlyClient to CKB:
- FlyClient assumes fixed epoch length while NC-Max (the consensus algorithm used in CKB) has variable epoch length;
- FlyClient assumes original NC style difficulty adjustment, which depends only on timestamps of the first block of each epoch, while difficulty adjustment in NC-Max depends on the number of uncles in the last epoch.
I think we need to improve the Variable Difficulty MMR design in FlyClient paper to accommodate NC-Max, probably adding more auxiliary fields to MMR interval/leaf nodes. A Merkle proof for uncle inclusion of sampled nodes is not enough, because at epoch transition the verifier needs to verify the difficulty adjustment is correct, which means verifying the number of uncles in the last epoch is correct. So certain epoch information should be encoded in MMR nodes.
FlyClient on CKB is definitely doable. If you could put together a more concrete proposal we’d be happy to discuss and see how can we make it secure and optimal.
So it’s important to have a concrete and convincing design before we go implementing it, which is already on the research team’s plan. For this grant proposal, I think we can either delay the discussion until a design emerges or modify the proposal to include protocol design and make it a milestone if you’re interested.