Neben
der Blockkette gibt es noch zwei weitere Datenbanken, die für das
Funktionieren von Bitcoin essentiell sind: Der Transaktionspool und die
Chainstate (UTXO) Datenbank,
Transaktionspool (Mempool)
Mit "landet im Transaktionspool" ist folgendes gemeint: Jeder Full Node hat seinen eigenen
lokalen Transaktionspool. Das ist jeweils eine Datenbank, in der alle
anstehenden Transaktionsanforderungen gespeichert werden. Die Inhalte dieser Datenbanken
können sich von Full Node zu Full Node geringfügig unterscheiden, weil je nach
Netzwerkzustand wahrscheinlich nicht jeder Full Node von allen
Transaktionsanforderungen erfährt. Jeder Full Node prüft die ihm vorliegenden Transaktionsanforderungen
auf Gültigkeit, d.h., ob die Adresse, von der aus versendet werden
soll, existiert, ob darauf tatsächlich der behauptete Betrag liegt, und
natürlich auch, ob die Anforderung von jemandem kommt, der Kontrolle
über die Adresse hat, von der aus versendet werden soll (Im Klartext:
Ob derjenige, der die Bitcoins versenden will, diese tatsächlich
besitzt).
Angenommen, ich habe die Adresse A in der Vergangenheit mehrfach
verwendet, sprich, Bitcoins darauf überweisen lassen, bzw. davon
Bitcoins versendet. Das ist zur Wertaufbewahrung zwar schlecht, kann
aber für den Alltagsgebrauch sehr praktisch sein. Beispielsweise liegt
jetzt 1 Bitcoin drauf, vor 2 Wochen waren es 1.2, vor 2 Monaten 0.7,
davor 2.4, ..., usw. Alle damit verbundenen Transaktionen sind auf der
Blockkette gespeichert, in Blöcken, die ungefähr die Kalenderzeiten
repräsentieren, an denen die Transaktionen stattgefunden haben. Je mehr
Zeit zwischen den Transaktionen vergangen ist, umso weiter liegen die
Blöcke, in denen sie verzeichnet sind, auseinander. Wenn von der
Adresse A beispielsweise zu 8 verschiedenen Zeiten Bitcoins versendet
wurden, dann existieren auf der Blockkette an 8 Stellen Eintragungen,
die besagen, dass von A aus Bitcoins an eine andere Adresse versendet
worden sind.
Wie überprüfen die Full Nodes, dass meine Transaktionsanforderung
valide ist, vereinfacht gesagt, dass auf der Adresse A tatsächlich wie
behauptet 1 Bitcoin liegt? Wie wird sichergestellt, dass die
Transaktionsanforderung immer auf den neuesten Eintrag bezüglich
Adresse A auf der Blockkette verweist, und nicht auf einen älteren
Eintrag, der ggfs. viel mehr Bitcoins ausweist? Es läuft im Grunde
darauf hinaus: Wie wird verhindert, dass Bitcoins, die in der
Vergangenheit von Adresse A aus versendet worden sind, später nicht
nocheinmal versendet werden können, letztlich Bitcoins nicht mehrfach
ausgegeben werden können? Die Antwort ist denkbar simpel, und dennoch selbst in Fachliteratur schwer zu finden:
Chainstate (UTXO) Datenbank
Es wird nicht die Blockkette durchsucht, sondern es wird auf eine
separate, klassische Datenbank zugegriffen, die alle Adressen enthält,
auf denen sich nach aktuellem Stand überhaupt Bitcoins befinden. Jede dieser Adressen kommt darin genau einmal vor, und zwar jeweils mit der aktuellen Anzahl darauf befindlicher Bitcoins. Diese Datenbank wird Chainstate, oder UTXO (Unspent Transaction Output) Datenbank genannt, ist 2020 ca. 3 Gigabyte gross, und befindet sich im Arbeitsspeicher (RAM) des Full Node Computers. Es leuchtet
unmittelbar ein, dass auf diese Weise sehr schnell verifiziert
werden kann, ob Transaktionsanforderungen berechtigt sind oder nicht. Ähnlich wie bei
den Transaktionspools weiter oben beschrieben, hat jeder Full Node
seine eigene individuelle Chainstate Datenbank. Diese sind allerdings,
im Gegensatz zu den Transaktionspools, alle miteinander identisch.
Aus dem zuvor beschriebenen lässt sich ableiten, dass Full Nodes
mindestens 4 GB RAM haben müssen (2020 belegt die Bitcoin Core Software
in der Tat weniger als 4 GB Arbeitsspeicher). Während auf der Blockkette
alle jemals stattgefundenen Transaktionen verzeichnet sind, enthält die
Chainstate Datenbank also nur die aktuell relevanten Informationen.
Dabei handelt es sich im Prinzip um Kontostände (wobei nur diejenigen
Konten vorkommen, die Guthaben aufweisen).
Wie entsteht die Chainstate Datenbank eigentlich?
Wer sich jemals gefragt hat, wieso der Download der Blockkette so lange
dauert, wo doch die Downloadgeschwindigkeit nur von der
Internetverbindung abhängt, ahnt jetzt die Antwort: Beim
Herunterladen wird die Chainstate Datenbank aufgebaut. Dazu muss die
gesamte Blockkette von Anfang an durchkämmt, also alle jemals
stattgefundenen Transaktionen analysiert werden.
Dabei werden die Transaktionen insbesondere nicht
auf Validität geprüft, denn das wurde früher bereits durch alle Full
Nodes getan, und die Bestätigungen durch die Miner in den Blöcken
verewigt.
Das Herunterladen dauert also nur deshalb so lange, weil die Chainstate
Datenbank aufgebaut wird. Während des Aufbaus kommen immer wieder neue
Adressen hinzu, andere wiederum verschwinden (weil die zugehörigen
Bitcoins ausgegeben wurden), und kommen ggfs. später wieder hinzu (weil
wieder Bitcoins darauf überwiesen wurden).