What's the point of reducing your utxo set if you're gonna store the whole blockchain
Discussion
Efficiency
To turn your question around, what's the point of a 12GB utxo set when 12KB gets the job down?
done*
Efficiency, requires a bunch of network calls and more proofs to verify a block
> requires a bunch of network calls
Do you have more details on this? It looks like you are saying utreexo nodes make *more* network queries than normal nodes. What additional calls to the network do they make?
> more proofs to verify a block
Utreexo nodes receive slightly more data alongside blocks (i.e. they receive additional merkle inclusion proofs), but (1) not much more (2) the extra data is ephemeral: after validating the proof, they may discard it, as, upon storing the block, they can reconstruct the proofs upon request from other nodes that may ask them for it in the future. To me, that seems worth exploring! Maybe it's *more* efficient
actually, now that I think about it, it may be even *better* than that. Since utreexo nodes can reconstruct the proofs from blocks themselves, they probably *don't* need the proofs to be submitted alongside the blocks. Just give them the blocks themselves and they can create the proofs on their own
ah, wait...I don't think it *can* produce the proofs without access to the full utxo set...hmm...
In general the answer is you need fast read access to the utxo set all the time to run a validating node, right.
I don't think you need fast read access to the utxo set after IBD, because you have an average of 10 minutes to validate new blocks and that's enough time to do it with slow read access
*during* IBD, I think it's a different story. But even there, MergeSync looks promising. It lets users download the blockchain first, without validating changes to the utxo set, and then *afterwards* efficiently extract the utxo set by creating an array representing all tx inputs ever used in any transaction in any block (in the format txid:vout) and injecting into that same array all tx outputs ever created (in the same format), and then removing all duplicates. What you're left with is the utxo set, without needing to update it *during* IBD.
combining these two ideas, I think you can run a fully validating node without fast read access to the utxo set, i.e. with low ram requirements. Just use MergeSync to do IBD, and after that, slow read access suffices
If not blocksonly, you need to validate each gossiped tx, though?
I mean I'm just wiseacring here, talking generally; I don't know anything concrete.