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?
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?