Um zu entscheiden, ob eine neue Transaktion gültig ist, durchsucht eine Node nicht die ganze Blockchain. Sie schlägt in einer Tabelle nach: dem UTXO-Set, der Liste jedes Coins, der existiert und noch nicht ausgegeben wurde.
Was gespeichert wird
Jeder Eintrag ist über seinen Outpoint (txid + Output-Index) keyed und hält Betrag, Locking-Script, die Höhe des erzeugenden Blocks und ein Flag, falls er aus einer Coinbase-Transaktion stammt. In Bitcoin Core heißt diese Datenbank Chainstate und liegt in LevelDB im Ordner chainstate.
Wie Blöcke sie ändern
Wenn ein Block verbunden wird, werden seine ausgegebenen Inputs entfernt und seine neuen Outputs hinzugefügt. Bitcoin Core speichert auch „Undo“-Daten je Block, sodass bei einer Reorganisation, die einen Block entfernt, die ausgegebenen Coins wiederhergestellt werden können.
Geschwindigkeit und Speicher
Lookups passieren für jeden Input jeder Transaktion, daher zählt Geschwindigkeit. Bitcoin Core cached Coins im RAM, gesteuert über -dbcache. Version 31.0 hob den Default von 450 MiB auf 1.024 MiB auf Systemen mit mindestens 4.096 MiB RAM. Ein größerer Cache kann den ersten Sync stark beschleunigen.
Größe
Das UTXO-Set ist viel kleiner als die volle Kette, aber immer noch mehrere Gigabyte auf der Platte, und jede Full Node muss alles behalten. Jeder neue Output wächst es, bis er ausgegeben wird – viele winzige Outputs kosten also alle. Das ist ein Grund für Dust-Limits.
Pruning
Eine Pruned Node kann alte Blockdateien löschen und nur etwa 550 MiB davon behalten, muss aber den vollen Chainstate halten. Pruned Nodes validieren trotzdem alles.
Snapshots
Bitcoin Core kann das Set mit dumptxoutset exportieren. Mit assumeutxo kann eine neue Node einen solchen Snapshot laden, wenn sein Hash einem im Quellcode hinterlegten entspricht, und die Historie dann im Hintergrund prüfen. Mehr dazu unter Initial block download.