[Witness] Update - March 2026 | steemd

Mein letzter Post ist 5 Monate her... In der Zwischenzeit ist viel passiert. Allerdings bekommt ihr vielleicht auch nicht viel davon mit, da vieles eben im Hintergrund passiert und ich nicht wegen jeder Kleinigkeit einen Post absetze. Ich möchte euch insofern mitnehmen in die aktuellen Entwicklungen... und ich schreibe heute nur auf Deutsch.

Proposal 98

Ich hatte in meinem letzten Post schon darauf hingewiesen, dass die Grundlage der Blockchain-Umgebung aktualisiert wird (wobei es jetzt schon abgeschlossen ist). Betroffen sind unter anderem folgende wesentliche Bibliotheken:

• Rocksdb (Datenbanksystem, mit dem die Blockchain-Daten in einem Knoten gespeichert werden)
• Boost (sehr umfangreiche Bibliothek, die vom steemd-Code genutzt wird).

Ich hatte in den letzten Wochen hauptsächlich damit zu tun, nach Fertigstellung und vor dem Einfügen den Code zu testen und herauszufinden, ob die Blockchain die Daten unverändert speichert und abruft.

Replay

Ich kann euch gar nicht sagen, wie oft ich in den letzten Wochen einen Replay der gesamten Blockchain durchgeführt habe. Es waren unzählige Male. Und jedes Mal tat sich ein neues Problem ... und später eine neue Erkenntnis auf. (Replay heißt übrigens, dass die gesamte Blockchain-Datenbank aus einem vorhandenen block_log neu angelegt wird. block_log ist eine Datei, in der alle Blöcke gespeichert sind.)
Zunächst brauchte ich für Tests eine kleinere Version der Blockchain. Also musste ich erstmal herausfinden, wie die Daten im block_log gespeichert sind. Ich möchte mir auf meinem lolalen System schließlich nicht mehrere 300GB Files ablegen. Mittlerweile kann ich jede gewünschte Größe erzeugen. So hatte ich einen block_log mit den ersten 100, 1000 und 1 Mio. Blöcken usw. So konnte ich auch lokal und mittels Debugging das Verhalten des Blockchain-Codes untersuchen.
Nach unzähligen Rückschlägen (diverse Server fielen plötzlich aus, RAM wurde knapp - dazu später mehr, die Datenbank wurde nicht richtig auf die Platte geschrieben, etc.) habe ich vor einigen Tagen dann wirklich einen definierten Stand bei 99 Mio. Blöcken sowohl in der bisherigen Version als auch in der neuen Code-Version erhalten.

Definierter Datenbankzustand

So ein Datenbankvergleich macht natürlich nur dann Sinn, wenn man Datenbanken vergleicht, die auf demselben Stand sind. Es nützt ja nun wenig, wenn in der einen Datenbank 1000 Blöcke gespeichert sind und in der anderen nur 999. Dann sind die Daten zwangsläufig verschieden.
Hier musste also ein definierter Zustand her, der Replay musste also bei einem bestimmten Block enden. Das allein ist kein Problem. Hierfür gibt es eine Start-Option. Allerdings beendet sich steemd bei Erreichen dieses End-Blockes. Wenn wir aber API-Anfragen an diesen Knoten senden wollen, um Daten abzufragen, muss steemd aber aktiv sein. Hier habe ich schon sehr früh eine Option eingebaut, mit der man den Knoten sozusagen "schlafen" legen kann. Er bekommt dann keine neuen Blöcke mehr aus dem Netzwerk und lauscht aber auf API-Anfragen.

Datenbank-Vergleich

Während ich also versuchte, einen definierten Zustand zu bekommen, haben der Chiller und ich darüber nachgedacht, wie man die Daten in der Datenbank vergleichen könnte. Auch das hielt einige Überraschungen bereit. Wundert es euch, wenn ich erzähle, dass die KI das total easy fand und auch gleich einen passenden Python-Code bei der Hand hatte? Wundert es euch auch, wenn ich erzähle, dass dieser ... und die zahlreichen anderen Codes nicht funktionierte? Was habe ich da ausprobiert. Das geht deshalb nicht (so einfach) von außerhalb, weil man die internen "Ablageregeln" (einfach ausgedrückt) kennen muss. Dies sind aber so komplex konstruiert, dass man die nicht so einfach und auf die Schnelle "nachbauen" kann. Das hat die KI einfach mal ignoriert oder andere unbrauchbare Vorschläge gemacht. Irgendwann kam der natürlichen Intelligenz (mir) die Idee, dass ich die "Regeln" dann "einfach" aus dem bestehenden System heraus nutzen kann. So entstand dann die Idee des nunmehr für den Vergleich genutzten Tools.

Rückschläge beim Vergleich

Für den Account-History-Vergleich hatte ich ein bereits vorhandenes Tool verwendet, dass API-Anfragen an beide Knoten richtet und die Ergebnisse dann vergleicht.
Schon bei dem Vergleich von 10 Mio. Blöcken sind die Knoten jedoch mehrfach vom System beendet worden. Die Abfragen haben den RAM derart beansprucht, dass das System irgendwann diese Prozesse beendete.

_{Hier sieht man beim Speicher (Mem und Swp) die vollen Balken.}

Bis ich den Grund gefunden hatte, vergingen einige Stunden beim Debuggen und Testen. Es war der steemd-interne Cache, der alle Abfragen zwischenspeichert. Das ist nun mal die Aufgabe eines Caches, aber leider sieht der aktuelle Code keine Bereinigung vor... jedenfalls dann nicht, wenn keine neuen Blöcke reinkommen. (Zur Erinnerung: das hatte ich deaktiviert, da ich ja einen definierten Zustand brauchte.)
Als ich dann in mein Tool noch die Cache-Bereinigung eingebaut hatte, funktionierte nun endlich alles reibungslos.

Finaler Erfolg

Tja, irgendwann vor ein paar Tagen hatte ich dann endlich den Container mit dem Vergleichs-Tool gestartet, und dieser hat ohne zu murren die Datenbanken-Einträge der beiden steemd-Versionen verglichen... Mit Erfolg (hier ein Auszug aus dem log):

Timing enabled for comparisons
Memory usage reporting enabled
Running in serial mode (no multithreading)
-------------------------------------------------------
Open database from /var/steem/db1
884335ms block_log.cpp:142             open                 ] Log is nonempty
884340ms block_log.cpp:151             open                 ] Index is nonempty
Revision: 99000000, Head Block: 99000000
-------------------------------------------------------
Open database from /var/steem/db2
893140ms block_log.cpp:142             open                 ] Log is nonempty
893140ms block_log.cpp:151             open                 ] Index is nonempty
Revision: 99000000, Head Block: 99000000
-------------------------------------------------------
account_index:
--- Size: DB1: 1940572    | DB2: 1940572   
--- Progress finished (1940572/1940572)
--- Elapsed time: 64.286s
--- DB1 memory: Index cache usage: 46282771, Index cache size: 100000
--- DB2 memory: Index cache usage: 46282771, Index cache size: 100000
--- Comparison result: equal: 1940572, diff: 0
--- DB1 memory: Cache usage: 46282771, Cache size: 100000
--- DB2 memory: Cache usage: 46282771, Cache size: 100000

comment_vote_index:
--- Size: DB1: 916346408  | DB2: 916346408 
--- Progress finished (916346408/916346408)
--- Elapsed time: 6459.21s
--- DB1 memory: Index cache usage: 4700000, Index cache size: 100000
--- DB2 memory: Index cache usage: 4700000, Index cache size: 100000
--- Comparison result: equal: 916346408, diff: 0
--- DB1 memory: Cache usage: 4700000, Cache size: 100000
--- DB2 memory: Cache usage: 4700000, Cache size: 100000

... und nun?

Ich denke, wir können die Änderungen, die bisher nur im Entwicklungs-Stadium waren, nunmehr in den Production-Code übernehmen. Alle Top-Zeugen sollten dies entsprechend checken und ihre Meinung dazu äußern. Und darauf können wir dann die weitere Entwicklung der Steem-Blockchain aufbauen...

Steem Search on https://moecki.online/ My Full Node on https://api.moecki.online For fast account recovery set your recovery account to @moecki.recovery. My Github Vote here

28.03.2026