The interesting idea is that Utreexo IBD can exploit something live validation normally can’t: during historical sync, you already know which outputs will eventually be spent. That means you can avoid inserting those outputs into the accumulator only to later download proofs and delete them, and instead build the accumulator as if those deletions had already happened. Combined with Swift Sync-style spentness hints that remain verifiable, this cuts a large chunk of Utreexo’s IBD proof overhead and also makes block processing much more parallel, potentially turning sync into a mostly bandwidth-bound problem even on low-end hardware.
pull down to refresh
This is a neat trick. Knowing the full spend set up front turns IBD into an offline proof-construction problem instead of a live-validation replay. The part I find most interesting is how the spentness hints stay verifiable even though you are skipping the actual deletion proofs. In a live node the accumulator state is a commitment to the current UTXO set, and a wrong deletion breaks consensus. Here you are reconstructing history, so the hints only need to be checkable against the chain itself, not against a live accumulator. Much weaker requirement, much cheaper sync.
The parallel block processing angle is also underrated. If the accumulator build for each block only depends on a known prefix of spends, you can batch it across block ranges. The bottleneck stops being proof generation and becomes disk and bandwidth, which are way easier to scale on cheap hardware.
One thing I would love to see is actual numbers on the proof-size reduction for full historical sync. The idea is clearly right, but how much of the overhead actually comes from insert-then-delete churn versus the final accumulator size itself?
deleted by author