Minimum viable light client via FlyClient-style checkpointing

Appreciate your feedback! Originally I had in the write-up “the shared benefit of a super-light client should provide the necessary incentives to ensure stakeholders keep this data updated” but looks like it did not make it into the final version.

There’s a couple things here. We do have coordination problems and tragedy of the commons, but because anyone can update maybe it’s not so bad.

If it’s just running the infrastructure to collect the blocks and pay a nominal transaction fee, you only need 1 person to do it. Could be any of us. Rough calculation of updating every 100 blocks (3200 bytes for headers + 65 byte signature + 72 bytes for inputs + 128 bytes for outputs) * (1800/100) blocks per epoch * 6 epochs per day @ 1,000 shannons/KB is 0.0037422 CKB per day in fees.

Any wallet services that use the data would have an interest in keeping it relatively updated to minimize data their users need to sync.

The issue comes in when transaction fees go up imo. So someone would have to have enough interest in seeing this working even if it will cost them some money. Maybe they do, maybe they don’t. Worst case is if no one does, everyone downloads block headers until someone feels compelled to improve the situation and update the data.

A way around this is if miners would be willing to accept the transactions with no fee. Which is a bit awkward but does get us around the incentive problem.

I have mixed thoughts around bolting incentives onto this, the task of light client data feels like it is a protocol level concern. Curious if you or anyone else has any ideas.