Is there a analysis, BIP proposal or easy dialogue about doable enchancment on the dimensions required to run a full node and a approach to shrink/prune the historical past of bitcoin and have quick sync?
Let me attempt to slender a bit the subject: could be fascinating to have a approach to have quick node sync, with few reminiscence required to retailer an up to date “fullnode”.
I used to be pondering if could also be helpful to have a sort of UTXO snapshot periodically (let say each 2016 blocks) the place a node would generate a UTXO snapshot and put the hash (a merkle tree hash or no matter struct matches effectively) within the block header
having this, nodes might do a number of totally different sort of sync based mostly on their wants, e.g. they might validate “header first” through the use of these “snapshot headers”, require a particular snapshot utilizing one thing just like “assumevalid” with out the necessity to validate all prior transactions nor having to obtain blocks, as a result of the utxo set is all what they should validate subsequent blocks on high of the snapshot top. After all such nodes cannot serve previous blocks, just like how pruned node ares, however they will validate and sync quick.
After all my thought is not indeep this is the reason I am questioning what’s present state about this matter as a result of I am fairly certain it is one thing that periodically pops out.
Beside this, I’ve a extra broader query, that will sound a bit rhetorical however nonetheless legit: is bitcoin historical past that vital? Having snapshots (as consensus, each node has to generate it on the similar top, its hash needs to be saved on block header, and so forth…) may theoretically trigger the block containing the snapshot act as a brand new genesis that transfer bitcoin forward An utxo that is spent, is not helpful anymore like a transaction which have all its utxo spent, so eradicating them should not trigger any hurt besides in all probability transactions utilizing OP_RETURN however they might be saved in one other sort of “DATA Snapshot”.
I can not take into consideration a sound motive (besides after all for preliminary sync) that makes the complete historical past of bitcoin wanted to be saved and served, did I miss one thing?
this type of “dynamic genesis” nonetheless would enable a node that selected to retailer the entire chain suitable with a node that need to begin from final snapshot, everybody can validate and serve blocks (after all the latter may serve solely from snapshot genesis). It is sort of just like what now we have with checkpoint with the distinction that is set in consensus and never hardcoded in code (that is one of many motive why checkpoint failed)
Open to criticisms that add one thing to the dialogue.
