Immer wenn eine Transaktion von einem Knoten empfangen wird, überprüft der Knoten ihre Gültigkeit. Zu diesem Zweck prüft es für jede Transaktionseingabe, ob diese Eingabe Teil des UTXO-Sets ist. Nach meinem Verständnis wird das UTXO-Set in der Chainstate-Datenbank gespeichert, die in einer LevelDB
Struktur gespeichert ist.
Ich dachte zuvor, dass das UTXO-Set im Speicher verfügbar gehalten wird, aber da ich erfahren habe, dass es derzeit etwa 1,2 GiB groß ist , erscheint das unwahrscheinlich.
Ich gehe also davon aus, dass die Chainstate-DB auf der Festplatte gespeichert ist, aber mehrmals pro Sekunde darauf zugegriffen wird, um Transaktionseingaben zu überprüfen. Welche Speicherauslastung verursacht dies auf einem Knoten?
Sie haben Recht, UTXO-Set wird mit leveldb auf der Festplatte im Verzeichnis .bitcoin/chainstate gespeichert. Es wird in komprimiertem Zustand gespeichert und hat eine aktuelle Größe von etwa 1,5 GB
Um den Zugriff zu beschleunigen, verwendet Bitcoind einen In-Memory-Cache, der mit der Option -dbcache konfiguriert werden kann.
Ich gehe also davon aus, dass die Chainstate-DB auf der Festplatte gespeichert ist, aber mehrmals pro Sekunde darauf zugegriffen wird, um Transaktionseingaben zu überprüfen. Welche Speicherauslastung verursacht dies auf einem Knoten?
Der Zugriff auf die leveldb-Datenbank selbst ist wie der Zugriff auf jede andere nosql-Datenbank. Sie suchen im Grunde nach dem Schlüssel, der der utxo ist, und erhalten einen Wert als Ausgabe, den Sie deserialisieren und in einer Speichervariablen speichern müssen
-dbcache
den Speicher langfristig mit einigen Spitzen, wenn ich auf die Datenbank zugreife?
Jannes