Vor ein paar Tagen habe ich in Hongkong an einer Veranstaltung teilgenommen und mit einem älteren Kollegen Kaffee getrunken, der seit vielen Jahren Node-Betrieb macht.
Wir haben über <0>@BabylonLabs_io </0> gesprochen, und ich habe aus dem Stegreif gesagt: „Wenn man das BTC-Ergebnis durch Self-Custody in PoS bringt, dann sollte diese Architektur-Logik der Sicherheit doch im Grunde die Cross-Chain-Bridges überflüssig machen, oder?“
Der Kollege hat einen Schluck Kaffee genommen, gelächelt und gesagt: „Die Code-Architektur lässt sich wirklich nicht aussetzen. Aber ihr aus Marketing und Investment seid zu leicht von idealisierten Modellen in die Irre geführt.“
Er hat mir zwei äußerst fiese Blindspots aus der realen Welt auseinandergepflückt:
Der erste heißt „Netzwerküberlastungs-Arbitrage“.
Babylons Strafeinziehungs-Mechanismus ist nicht sofort abgeschlossen; nach dem Fehlverhalten müssen die Strafeinziehungstransaktionen in einem Zeitfenster in das BTC-Hauptnetz eingewoben werden. Aber was, wenn der Angreifer sich bewusst dafür entscheidet, im BTC-Hauptnetz aktiv zu werden, wenn es extrem überlastet ist und die Gebühren auf mehrere hundert sat/vB hochschießen? Dann bleiben die Strafeinziehungstransaktionen im Mempool stecken und warten. Der Angreiferknoten kann diese „Todeszone“-Zeit nutzen, um im Derivatehandel zu hedgen – und sogar das Risiko auf uninformierte Liquiditätsanbieter zu übertragen.
Der zweite Punkt ist noch bodenständiger und heißt „faule Dezentralisierung“.
Der On-Chain-Code mag noch so passgenau und lückenlos sein – Off-Chain laufen die Knoten immer noch auf Menschen. Er hat privat gezählt: In der Gruppe der Betreiber, die Babylon fahren, nutzt mehr als die Hälfte aus Bequemlichkeit den gleichen, führenden Cloud-Anbieter und dessen Rechenzentrum für das Hosting. Auf dem Papier wird die Dezentralisierung bis zur Decke hochgejubelt. Aber auf der physischen Ebene reicht es, wenn ein einziges LAN-Kabel im Rechenzentrum ausgetauscht wird oder die Regeln des Cloud-Anbieters geändert werden – dann wird das Ganze wieder auf den Ausgangspunkt zurückgeworfen.
Der letzte Satz des Kollegen ging ziemlich unter die Haut: „Alle gehen davon aus, Sicherheit stecke in den Formeln aus dem Whitepaper. Aber die echten Angriffe treffen nie das, was im Dokument steht – sondern das, was in der Realität am faulsten und am sparsamsten ist.“
#baby $BABY
Wir haben über <0>@BabylonLabs_io </0> gesprochen, und ich habe aus dem Stegreif gesagt: „Wenn man das BTC-Ergebnis durch Self-Custody in PoS bringt, dann sollte diese Architektur-Logik der Sicherheit doch im Grunde die Cross-Chain-Bridges überflüssig machen, oder?“
Der Kollege hat einen Schluck Kaffee genommen, gelächelt und gesagt: „Die Code-Architektur lässt sich wirklich nicht aussetzen. Aber ihr aus Marketing und Investment seid zu leicht von idealisierten Modellen in die Irre geführt.“
Er hat mir zwei äußerst fiese Blindspots aus der realen Welt auseinandergepflückt:
Der erste heißt „Netzwerküberlastungs-Arbitrage“.
Babylons Strafeinziehungs-Mechanismus ist nicht sofort abgeschlossen; nach dem Fehlverhalten müssen die Strafeinziehungstransaktionen in einem Zeitfenster in das BTC-Hauptnetz eingewoben werden. Aber was, wenn der Angreifer sich bewusst dafür entscheidet, im BTC-Hauptnetz aktiv zu werden, wenn es extrem überlastet ist und die Gebühren auf mehrere hundert sat/vB hochschießen? Dann bleiben die Strafeinziehungstransaktionen im Mempool stecken und warten. Der Angreiferknoten kann diese „Todeszone“-Zeit nutzen, um im Derivatehandel zu hedgen – und sogar das Risiko auf uninformierte Liquiditätsanbieter zu übertragen.
Der zweite Punkt ist noch bodenständiger und heißt „faule Dezentralisierung“.
Der On-Chain-Code mag noch so passgenau und lückenlos sein – Off-Chain laufen die Knoten immer noch auf Menschen. Er hat privat gezählt: In der Gruppe der Betreiber, die Babylon fahren, nutzt mehr als die Hälfte aus Bequemlichkeit den gleichen, führenden Cloud-Anbieter und dessen Rechenzentrum für das Hosting. Auf dem Papier wird die Dezentralisierung bis zur Decke hochgejubelt. Aber auf der physischen Ebene reicht es, wenn ein einziges LAN-Kabel im Rechenzentrum ausgetauscht wird oder die Regeln des Cloud-Anbieters geändert werden – dann wird das Ganze wieder auf den Ausgangspunkt zurückgeworfen.
Der letzte Satz des Kollegen ging ziemlich unter die Haut: „Alle gehen davon aus, Sicherheit stecke in den Formeln aus dem Whitepaper. Aber die echten Angriffe treffen nie das, was im Dokument steht – sondern das, was in der Realität am faulsten und am sparsamsten ist.“
#baby $BABY