Früher habe ich ein Protokoll oft danach bewertet, ob es Lücken gibt, die zum Verlust von Vermögenswerten führen können. Wenn es keine Möglichkeit gibt, Geld zu stehlen oder die Kontrolle über das Netzwerk zu übernehmen, habe ich das meist als Implementierungsfehler angesehen, die bald behoben werden.

Aber als ich ein Security-Advisory und die Diskussion auf GitHub zu Babylon gelesen habe, gab es eine Einzelheit, bei der ich innehalten musste. Ein Validator kann eine Vote Extension senden, bei der das Feld block_hash ignoriert wird. Nur ein scheinbar sehr kleines Datenfeld – aber ausreichend, um andere Knoten beim Überprüfen der Nachricht zum Absturz zu bringen, wenn dieser Fall nicht korrekt behandelt wird.

Zunächst dachte ich, das sei nur ein Programmierfehler. Dann merkte ich, dass ich zu sehr auf die Folgen geschaut und dabei vergessen habe, welche Rolle er im System spielt. Dieser Fehler ermöglicht keinen Bitcoin-Diebstahl und erzeugt auch nicht direkt eine andere Chain. Was er jedoch beeinflusst, ist die Verfügbarkeit des Netzwerks. Ein Validator kann dazu führen, dass der Verifizierungsprozess in einen Runtime-Panic gerät. Wenn mehrere Knoten gleichzeitig in diesen Zustand geraten, wird die Fähigkeit, die Liveness des Netzwerks aufrechtzuerhalten, beeinträchtigt.

Was mich jedoch besonders nachdenklich gemacht hat, liegt an anderer Stelle. Babylon erbt die Sicherheit von Bitcoin durch Mechanismen wie Timestamping und Checkpoints, aber die gesamte Vermittlungsschicht (Koordinationsschicht) wird weiterhin als Software von Babylon selbst realisiert. Aus meiner jetzigen Perspektive ist das der Teil, der am spannendsten zu beobachten ist. Vielleicht lautet die Frage nicht, ob Bitcoin sicher genug ist, sondern wie schnell die Implementierung, die mit Bitcoin verbunden ist, reifen wird – wenn das System unter realem Druck betrieben werden muss.
#baby $BABY @BabylonLabs_io