Is there a research, BIP proposal or simple discussion about possible improvement on the size required to run a full node and a way to shrink/prune the history of bitcoin and have fast sync?
Let me try to narrow a bit the topic: would be interesting to have a way to have fast node sync, with few memory required to store an updated “fullnode”.
I was thinking if may be useful to have a kind of UTXO snapshot periodically (let say every 2016 blocks) where a node would generate a UTXO snapshot and put the hash (a merkle tree hash or whatever struct fits well) in the block header
having this, nodes may do a lot of different kind of sync based on their needs, e.g. they may validate “header first” by using these “snapshot headers”, require a specific snapshot using something similar to “assumevalid” without the need to validate all prior transactions nor having to download blocks, because the utxo set is all what they need to validate next blocks on top of the snapshot height. Of course such nodes can’t serve old blocks, similar to how pruned node ares, but they can validate and sync fast.
Of course my thought isn’t indeep this is why I’m wondering what’s current state about this topic because I’m quite sure it’s something that periodically pops out.
Beside this, I’ve a more broader question, that may sound a bit rhetorical but still legit: is bitcoin history that important? Having snapshots (as consensus, every node has to generate it at the same height, its hash has to be stored on block header, etc…) could theoretically cause the block containing the snapshot act as a new genesis that move bitcoin ahead An utxo that’s spent, isn’t useful anymore like a transaction that have all its utxo spent, so removing them shouldn’t cause any harm except probably transactions using OP_RETURN but they may be stored in another kind of “DATA Snapshot”.
I can’t think about a valid reason (except of course for initial sync) that makes the full history of bitcoin needed to be stored and served, did I miss something?
this kind of “dynamic genesis” still would allow a node that chose to store the whole chain compatible with a node that want to start from last snapshot, everyone can validate and serve blocks (of course the latter could serve only from snapshot genesis). It’s kind of similar to what we have with checkpoint with the difference that’s set in consensus and not hardcoded in code (that’s one of the reason why checkpoint failed)
Open to criticisms that add something to the discussion.
