cculianu
commented
1 year ago Something like this already exists. There is a checkpointing mechanism that does functionally this. It's not well documented; but Electron Cash uses it. Any header behind the checkpoint is not downloaded, only headers after. The checkpoint itself is a super-merkle-root of sorts as you describe, essentially.
The proper SPV proof-of-inclusion that fulcrum supports is the merkle tree proofs under the blockheader.
The downside of this for many consumers of this API is that they need to have the blockheader. And to make a blockheader be useful they need to have all the blockheaders before it. Which grows with a leisurely pace of a little over 4MB per year.
What about the idea that fulcrum picks a yearly blockheight (say 800000 and again at 850000) and calculates a merkle tree of all the historical merkletrees ever mined. What clients then can do is include just the latest super-merkle-root in their software, 32bytes. A 32-byte checkpoint that can be included in libs/apps that consume fulcrum data.
Then an extra API call is added to fulcrum where an extend is requested for a merkle proof. Extending the one that ties their transaction to a blockheader, this API would provide a merkle proof tying the merkle-root in that blockheader to the checkpoint of the users asking (the one at 800000, for instance).
The logic here is that some apps will prefer to just have the blockheaders, but many others don't think that is feasible. In fact, I think the majority of consumer of fulcrum data do NOT actually properly validate their merkle-proofs because they don't want to download the entire blockheader history. This is especially true for web based usage of fulcrum data.
Adding this super-merkleroot can make a huge difference in how many will start to practice safety and do proper SPV which is to check merke-proofs.