Is there a analysis, BIP proposal or easy dialogue about potential enchancment on the scale required to run a full node and a technique to shrink/prune the historical past of bitcoin and have quick sync?
Let me attempt to slim a bit the subject: can be attention-grabbing to have a technique 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 type 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 suits effectively) within the block header
having this, nodes could do a number of completely different type of sync primarily based on their wants, e.g. they could validate “header first” by utilizing these “snapshot headers”, require a selected 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 prime of the snapshot top. In fact such nodes cannot serve outdated blocks, just like how pruned node ares, however they will validate and sync quick.
In fact my thought is not indeep because of this I am questioning what’s present state about this subject 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 many others…) might 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 could be saved in one other type of “DATA Snapshot”.
I am unable to take into consideration a legitimate purpose (besides after all for preliminary sync) that makes the total historical past of bitcoin wanted to be saved and served, did I miss one thing?
this sort of “dynamic genesis” nonetheless would permit a node that selected to retailer the entire chain suitable with a node that wish to begin from final snapshot, everybody can validate and serve blocks (after all the latter might serve solely from snapshot genesis). It is type 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 purpose why checkpoint failed)
Open to criticisms that add one thing to the dialogue.
