En helt ny fullnode må laste ned og sjekke hver blokk siden 2009 før den kjenner nåværende tilstand. Dette er initial block download (IBD), og det er det tyngste arbeidet en node noensinne gjør.
Headere først
Noden laster først bare ned blokkheadere, 80 byte hver, opptil 2 000 per melding. Den sjekker arbeidsbeviset deres og velger kjeden med mest arbeid. Bitcoin Core krever også en minimumsmengde totalt arbeid (nMinimumChainWork), og sjekker først en peers headere før den lagrer dem, slik at falske lavarbeids-kjeder ikke kan kaste bort minnet dens.
Blokker i parallell
Med header-kjeden kjent henter noden blokker fra flere peere samtidig, opptil 16 i flukt per peer, innenfor et glidende vindu på 1 024 blokker. Blokkene kobles deretter i rekkefølge. Hver oppdaterer chainstate.
Snarvei 1: assumevalid
Å sjekke hver signatur er den tregeste delen. Hver Bitcoin Core-utgivelse inkluderer et nylig blokkhash. Med assumevalid hoppes script- og signatursjekker over for den blokken og dens forfedre, hvis den er i kjeden som synkroniseres. Bitcoin Core 31.1 bruker blokk 938 343. Alt annet verifiseres fortsatt, og UTXO-settet bygges fullt. For å sjekke hver signatur, start med -assumevalid=0.
Snarvei 2: assumeutxo
I stedet for å bygge UTXO-settet fra scratch kan en node laste et snapshot med loadtxoutset. Snapshotet avvises med mindre hashet matcher ett i kildekoden. Bitcoin Core 31.1 lister snapshots for høyder 840 000, 880 000, 910 000 og 935 000. Noden er brukbar nær tippen raskt, mens den sjekker hele historien fra genesis i bakgrunnen.
Hva gjør IBD raskere
- En SSD i stedet for en spinnende disk.
- En større
-dbcache. Siden versjon 31.0 er standarden 1 024 MiB på maskiner med minst 4 096 MiB RAM. - En god nettverkstilkobling.
Tillit
Begge snarveiene hviler på verdier som gjennomgås offentlig i åpen kildekode. De lar ikke en node godta en kjede med mindre arbeid, og begge kan slås av.