genswiftsyncbitmap, chaincfg, blockchain: implement swiftsync#2478
genswiftsyncbitmap, chaincfg, blockchain: implement swiftsync#2478kcalvinalvin wants to merge 4 commits into
Conversation
for clients In order for the clients to take advantage of swiftsync, we need provide the bitmap to the clients. This tool generates the bitmap and writes it in the data directory of the given network (mainnet, signet, etc).
Add the SwiftSyncData structure which contains precomputed bitmap data for fast UTXO set bootstrapping. The bitmap indicates which transaction outputs have been spent up to a certain block height, allowing nodes to skip transaction replay during initial sync. Include embedded bitmap data for signet covering blocks 1 through 285205. The bitmap is stored in chaincfg/data/ and embedded at compile time using go:embed.
Implement swift sync which uses precomputed bitmap data to rapidly construct the UTXO set during initial block download. Instead of replaying all historical transactions, swift sync checks each output against the bitmap: bit 0 means unspent (add to UTXO cache), bit 1 means spent (skip). Key features: - Skip all transaction validation during swift sync range - Persist bitmap bit index for resumability across restarts - Verify block hash at swift sync boundary to ensure chain correctness - Safety check prevents enabling swift sync on existing chain data Swift sync is automatically enabled when checkpoints are enabled and SwiftSyncData is available in chain parameters.
Add a checkpoint at the swift sync boundary height (285205) for signet. Swift sync requires at least one checkpoint to be enabled as a security measure to validate the chain before trusting the precomputed bitmap.
Pull Request Test Coverage Report for Build 21129009243Details
💛 - Coveralls |
|
Will review this |
|
Took a look at this alongside 2140-dev/swiftsync and https://gist.github.com/RubenSomsen/a61a37d14182ccd78760e477c78133cd. Some notes on compatibility, since the reference implementation has changed a bit since this PR was opened: Output filteringThe reference impl skips OP_RETURN and scripts >10,000 bytes when building the bitmap — they're provably unspendable so they're not counted. This PR indexes every output. This means the bit indices won't line up between the two implementations even if the encoding matched. Worth aligning early since it affects any cross-implementation tooling. Bitmap formatThe reference recently switched to Elias-Fano encoding per block. It is quite different, and more complicated, than the flat bit field. It does trim a good amount of MBs though. The 3.3x speedup from just skipping validation/lookups is impressive. One thing worth thinking about: the spec's main selling point is that the accumulator makes block processing fully order-independent, which opens the door to downloading and processing blocks from multiple peers in parallel. Would be great to see that as a follow-up once the accumulator is in place. That's where the really big IBD gains come from. |
|
We've formalized the recommended approach more with the following specifications, which detail the new hintsfile format. |
|
I ran the IBD with 128MB utxcache until signet height 285205 and master processed average of 17 blocks/s while SwiftSync processed average of 36 blocks/s. Nice job. |
5 participants
Change Description
This is a first implementation of SwiftSync for btcd. SwiftSync enables fast UTXO set bootstrapping during initial block download by using a precomputed bitmap that indicates which transaction outputs have been spent.
Instead of replaying and validating all historical transactions from genesis, nodes can use the bitmap to directly construct the UTXO set:
The main benefit is performance improvement during ibd. On this PR when testing on signet, it was 3.3x faster than on master.
Without SwiftSync on master to block height 285,205 took 22m 59s.
Ran with command:
pprof:
With SwiftSync on this PR to block height 285,205 took 6m 56s.
Ran with command:
One caveat is that we can't generate the SpendJournals for the blocks that are processed with SwiftSync.
Note that the aggregator part of SwiftSync is not yet implemented which makes this not safe to run for production uses.
This is a first pass at the implementation and is not final. Feedback welcome.
Steps to Test
Steps for reviewers to follow to test the change.
Pull Request Checklist
Testing
Code Style and Documentation
📝 Please see our Contribution Guidelines for further guidance.