Ehrlich gesagt ist Babylons Architektur in der Idee tatsächlich schön – „ein nativer Bitcoin-Staking-Protocol, entworfen, um die Sicherheit von Bitcoin auf andere Netzwerke zu erweitern“. Damit kann man $BTC halten lassen, ohne Brücken zu schlagen, ohne zu verpacken, ohne ein Custody einzugehen: BTC direkt staken. Aber zwischen „schön“ und „sicher“ liegt noch eine ganze Reihe von Lücken, die noch nicht ausgefüllt wurden.
Babylon läuft nur als BTC-Light-Client und ist auf externe Relayer angewiesen, um Bitcoin-Block-Header zu aktualisieren. Die von Zellic offengelegten Szenarien haben mir einen Knoten im Kopf gemacht: Während die Babylon-Chain ausfällt, produziert das Bitcoin-Netzwerk weiterhin Blöcke. Wenn die Nodes neu starten, hält der Light-Client die aktuelle Höhe weiterhin für den Stand vor dem Ausfall. Ein böswilliger Mining-Pool kann vorab eine Forkkette einreichen, sodass der Babylon-Node vorübergehend glaubt, die Hauptkette sei korrekt. Der Angreifer muss nicht die Hashpower des Bitcoin-Hauptnetzes übertreffen – es reicht, nach dem Neustart schneller als ein ehrliches Relayer-Set zu laufen.
Auch EOTS mit Einmal-Signaturen hat mich nicht wirklich beruhigt. Zellic stellte fest, dass alle Babylon-Signaturschemata, die auf Secp256k1 basieren, die variable Timing-Implementierung über skalare Multiplikationen mit variabler Zeit nutzen – das birgt eine Timing-Side-Channel-Schwachstelle. Dadurch könnte der nonce geleakt werden, was eine Wiederherstellung des privaten Schlüssels ermöglicht. Die Sicherheitsmitteilung von GitHub deckte außerdem eine Signatur-Replay-Schwachstelle weiter auf – Angreifer können ein ungültiges PubRand-Versprechen injizieren.
Auch die Sperrgrenzen im Bitcoin-Skript sind fragil. Die von GHSA-4rmq-mc2c-r495 offengelegte Schwachstelle zeigt: Wenn FP die aktive Menge im selben Block verlässt, sind Delegatoren, die sich bereits vollständig von BTC abgekoppelt haben, trotzdem noch im Besitz von nicht-null „ActiveSatoshis“ – sie erhalten weiterhin Belohnungen, obwohl sie 0 BTC staken.
Die Blockproduktionsgeschwindigkeit beider Ketten ist völlig unterschiedlich, und der Staking-Status hat eine zeitliche Verzögerung von mehreren Minuten. Das zoneconcierge-Modul von Babylon verwendet bei der Verarbeitung von IBC-Paketen die nicht-deterministische Map-Iteration von Go – dadurch entstehen bei verschiedenen Nodes unterschiedliche Durchlaufreihenfolgen, und die gesamte Chain kommt zum Stillstand (halt).
Zum Schluss gibt es noch die Kettenreaktion durch die Überlastung des BTC-Netzwerks. Im August 2024, in der Phase „Cap-1“, schossen die Bitcoin-Gasgebühren von 0,5 USD auf 132 USD. Bei einem Staking-Limit von 1000 BTC waren etwa 21.000 Transaktionen nötig, um erst nach dem Füllen von 6 Blöcken fertig zu sein. Das Entsperr-Skript ist die Gebührenrate fest eincodiert; die Entsperrkosten machten zeitweise 45% der Gebühren im Bitcoin-Netzwerk aus.
Ein Protokoll, dessen Existenz oder Untergang von der Überlastung des BTC-Netzwerks abhängt – bist du sicher, dass es den nächsten Gas-Krieg übersteht?
#baby $BABY @BabylonLabs_io
Babylon läuft nur als BTC-Light-Client und ist auf externe Relayer angewiesen, um Bitcoin-Block-Header zu aktualisieren. Die von Zellic offengelegten Szenarien haben mir einen Knoten im Kopf gemacht: Während die Babylon-Chain ausfällt, produziert das Bitcoin-Netzwerk weiterhin Blöcke. Wenn die Nodes neu starten, hält der Light-Client die aktuelle Höhe weiterhin für den Stand vor dem Ausfall. Ein böswilliger Mining-Pool kann vorab eine Forkkette einreichen, sodass der Babylon-Node vorübergehend glaubt, die Hauptkette sei korrekt. Der Angreifer muss nicht die Hashpower des Bitcoin-Hauptnetzes übertreffen – es reicht, nach dem Neustart schneller als ein ehrliches Relayer-Set zu laufen.
Auch EOTS mit Einmal-Signaturen hat mich nicht wirklich beruhigt. Zellic stellte fest, dass alle Babylon-Signaturschemata, die auf Secp256k1 basieren, die variable Timing-Implementierung über skalare Multiplikationen mit variabler Zeit nutzen – das birgt eine Timing-Side-Channel-Schwachstelle. Dadurch könnte der nonce geleakt werden, was eine Wiederherstellung des privaten Schlüssels ermöglicht. Die Sicherheitsmitteilung von GitHub deckte außerdem eine Signatur-Replay-Schwachstelle weiter auf – Angreifer können ein ungültiges PubRand-Versprechen injizieren.
Auch die Sperrgrenzen im Bitcoin-Skript sind fragil. Die von GHSA-4rmq-mc2c-r495 offengelegte Schwachstelle zeigt: Wenn FP die aktive Menge im selben Block verlässt, sind Delegatoren, die sich bereits vollständig von BTC abgekoppelt haben, trotzdem noch im Besitz von nicht-null „ActiveSatoshis“ – sie erhalten weiterhin Belohnungen, obwohl sie 0 BTC staken.
Die Blockproduktionsgeschwindigkeit beider Ketten ist völlig unterschiedlich, und der Staking-Status hat eine zeitliche Verzögerung von mehreren Minuten. Das zoneconcierge-Modul von Babylon verwendet bei der Verarbeitung von IBC-Paketen die nicht-deterministische Map-Iteration von Go – dadurch entstehen bei verschiedenen Nodes unterschiedliche Durchlaufreihenfolgen, und die gesamte Chain kommt zum Stillstand (halt).
Zum Schluss gibt es noch die Kettenreaktion durch die Überlastung des BTC-Netzwerks. Im August 2024, in der Phase „Cap-1“, schossen die Bitcoin-Gasgebühren von 0,5 USD auf 132 USD. Bei einem Staking-Limit von 1000 BTC waren etwa 21.000 Transaktionen nötig, um erst nach dem Füllen von 6 Blöcken fertig zu sein. Das Entsperr-Skript ist die Gebührenrate fest eincodiert; die Entsperrkosten machten zeitweise 45% der Gebühren im Bitcoin-Netzwerk aus.
Ein Protokoll, dessen Existenz oder Untergang von der Überlastung des BTC-Netzwerks abhängt – bist du sicher, dass es den nächsten Gas-Krieg übersteht?
#baby $BABY @BabylonLabs_io