[WIP] feat: assume-valid swift sync

[JoseSK999]

Description and Notes

This PR depends on #836

I've changed the catch_up context so that your florestad starts with SwiftSync. It will also request legacy blocks, so this runs witnessless, but just for testing purposes. A future PR should actually implement the witnessless version.

Now, once your florestad starts, it will try to read the hints file from the same datadir as your node uses. Default directory is .floresta in the root for mainnet (and .floresta/signet, etc.). So you need to have the hints file there, named signet.hints or testnet.hints or bitcoin.hints.

I got mine from the server hosted by 2140-dev:

curl -o signet.hints http://utxohints.store/hints/signet

NOTE: to run florestad on mainnet you need to pass -- --no-assume-utreexo.

So you paste the hints file in the datadir, and then florestad will be able to run SwifSync. Four things can happen:

• SwiftSync finishes correctly ✅
• SwiftSync hints are invalid as the final agg is not zero ‼️
• An invalid block is found (below SwiftSync stop height) 😢
• We finish SwiftSync but the supply is invalid 💀

In the last three cases we abort SwiftSync and switch to SyncNode. There is an integration test showing how we would react against an invalid block.

If you finish SwiftSync you better stop the node because our acc is Stump::new() and you reject blocks/proofs (TODO allow SwiftSync to build the accumulator). ALSO to run this a couple of times you will need to remove the chaindata folder, so that it starts from 0 again.

This should be >10x faster than SyncNode for IBD as we avoid the utreexo proof bottleneck. In my case it was ~12x faster.

[Davidson-Souza]

curl -o signet.hints http://utxohints.store/hints/signet

HTTPS*. HTTP will return a 301

[JoseSK999]

Fixed an error with our inflight requests: we must not drop any of them before completion, even if redo_inflight_request fails. If redoing fails, we insert again the request (it will be retried later with another peer).

[Davidson-Souza]

I've added a little log to see how many inflights we have on average, and it's a sound 200 (the maximum we can have). At least on my not-that-great countryside internet, I'm basically limited by my bandwidth (it's as fast as I can download it). The next step is to improve our peer selection code to only keep fast peers during swiftsync

[Davidson-Souza]

I've increased the max MAX_CONCURRENT_GETDATA to 1_000, and got some interesting numbers:

Before (5 runs)

real	20m1.191s
real	25m44.877s
real	18m6.661s
real	20m35.805s
real	17m26.390s

After (5 runs)

real	9m8.240s
real	9m49.056s
real	8m52.187s
real	9m19.082s
real	9m15.768s

Another thing we can do is a dynamic algorithm to pick a optimal max requests

Edit: This is signet, from the network.

[JoseSK999]

That’s nice. Since we process blocks very fast, with any arrival order, we only keep them in memory for a few milliseconds at most. So we can in theory be more aggressive with MAX_CONCURRENT_GETDATA.

[Davidson-Souza]

The average for this is ~3.5k inflight blocks. It almost never maxes out

[Davidson-Souza]

@JoseSK999 can you please rebase this with the latest changes in #836? I want to profile this

[JoseSK999]

Rebased with the new SipHash24-based aggregator.

[luisschwab]

I noticed that the node will start to download filters after SwiftSync is done, even though IBD is not finished.

[JoseSK999]

Yeah because we first need to implement a way to construct the utreexo acc while in SwiftSync. This PR currently only showcases pure SwiftSync: we could in theory save the UTXOs in a db, but Floresta needs utreexo to continue validating.

[JoseSK999]

Pushed 07d4f86, which builds on the changes from #845 to compute each txid once (reuse the txids from merkle root check for outpoints)

[JoseSK999]

Incorporated the changes from #847, so we do header-chain selection properly