Am Montag Nachmittag im Büro blieb der Technische Direktor, Wang, kurz stehen, als er an meinem Arbeitsplatz vorbeiging: „Hast du dir Babylons IBC-Interchain-Modul angesehen? Die Sachen aus dem Cosmos-Ökosystem: Wenn man die Version updatet, gibt es doch eine Unterbrechung—wie lösen sie das?“ Ich öffnete die IBC-Dokumentation von Babylon und blätterte eine halbe Stunde, bis ich zu der Seite mit den Abhängigkeiten von ibc-go kam. Da verharrte mein Finger auf der Tastatur.
Das Projekt hat tatsächlich einiges zu bieten. Babylon unterstützt IBC nativ auf Basis von Cosmos SDK und leitet per Relayer BTC-Zeitstempel und Checkpoints an die konsumierenden Chains weiter. In V2 wurden zudem Module wie IBC Callbacks und Packet Forwarding eingeführt; das Design passt zu dem Label „Bitcoin-Sicherheitsnetz“.
Aber nachdem ich die Logik zur IBC-Kompatibilität zerlegt hatte, traten die Probleme klar zutage.
In den GitHub-Issues von Babylon wird ein zentraler Widerspruch dokumentiert: Cosmos-Relayer setzt auf ibc-go v8, die Hauptanwendung hingegen benötigt ibc-go v10. Die Unterschiede zwischen den Schnittstellen der beiden Versionen reichen aus, damit die Interchain-Kommunikation direkt abbricht. ibc-go v8.4.0 brachte zudem eine Sicherheitslücke in der Deserialisierung ans Licht; offiziell wurde eindringlich empfohlen, dass alle Chains sofort upgraden sollen. Babylon ist gleichzeitig von v8 und v10 abhängig—jede Seite-Upgrade-Entscheidung kann einen Kompatibilitätsbruch auslösen.
Noch unzuverlässiger ist das nichtdeterministische Risiko bei der Status-Synchronisation über Chains. Das Modul zoneconcierge verarbeitet IBC-Datenpakete mit der Go-Map-Iteration—die Iterationsreihenfolge einer Go-Map ist auf verschiedenen Knoten völlig unterschiedlich. Das führt dazu, dass die Knoten Datenpakete in unterschiedlicher Reihenfolge verarbeiten, inkonsistente Statuszusagen entstehen und die Folgen reichen von fehlgeschlagenem Konsens, Chain-Halt bis hin dazu, dass der Relayer die Datenpakete wegen nicht passender Sequenznummern nicht zustellen kann.
Das Audit von Zellic fand 32 Probleme: 7 im kritischen Level und 3 im Hochrisiko-Level. Wenn die Cosmos-Consumer-Chain nach einem Upgrade die IBC-Version nicht kompatibel halten kann, wird die Interchain-Kommunikation direkt unterbrochen—die angebundenen externen PoS-Chains verlieren dann den Bitcoin-Schutz, und genau das ist der Kernwert von Babylon: „Sicherheit von Bitcoin an die Consumer-Chain weiterreichen“. Die Versionskompatibilität ist dabei der schwächste Punkt.
Das Obige ist nur meine persönliche Meinung und stellt keine Anlageberatung dar. Glaubst du, dass Babylons IBC-Modul den anhaltenden Druck durch fortlaufende Versionsiterationen im Cosmos-Ökosystem aushalten kann? Schreib gern in die Kommentare—ich freue mich auf den Austausch.
#baby $BABY @BabylonLabs_io
Das Projekt hat tatsächlich einiges zu bieten. Babylon unterstützt IBC nativ auf Basis von Cosmos SDK und leitet per Relayer BTC-Zeitstempel und Checkpoints an die konsumierenden Chains weiter. In V2 wurden zudem Module wie IBC Callbacks und Packet Forwarding eingeführt; das Design passt zu dem Label „Bitcoin-Sicherheitsnetz“.
Aber nachdem ich die Logik zur IBC-Kompatibilität zerlegt hatte, traten die Probleme klar zutage.
In den GitHub-Issues von Babylon wird ein zentraler Widerspruch dokumentiert: Cosmos-Relayer setzt auf ibc-go v8, die Hauptanwendung hingegen benötigt ibc-go v10. Die Unterschiede zwischen den Schnittstellen der beiden Versionen reichen aus, damit die Interchain-Kommunikation direkt abbricht. ibc-go v8.4.0 brachte zudem eine Sicherheitslücke in der Deserialisierung ans Licht; offiziell wurde eindringlich empfohlen, dass alle Chains sofort upgraden sollen. Babylon ist gleichzeitig von v8 und v10 abhängig—jede Seite-Upgrade-Entscheidung kann einen Kompatibilitätsbruch auslösen.
Noch unzuverlässiger ist das nichtdeterministische Risiko bei der Status-Synchronisation über Chains. Das Modul zoneconcierge verarbeitet IBC-Datenpakete mit der Go-Map-Iteration—die Iterationsreihenfolge einer Go-Map ist auf verschiedenen Knoten völlig unterschiedlich. Das führt dazu, dass die Knoten Datenpakete in unterschiedlicher Reihenfolge verarbeiten, inkonsistente Statuszusagen entstehen und die Folgen reichen von fehlgeschlagenem Konsens, Chain-Halt bis hin dazu, dass der Relayer die Datenpakete wegen nicht passender Sequenznummern nicht zustellen kann.
Das Audit von Zellic fand 32 Probleme: 7 im kritischen Level und 3 im Hochrisiko-Level. Wenn die Cosmos-Consumer-Chain nach einem Upgrade die IBC-Version nicht kompatibel halten kann, wird die Interchain-Kommunikation direkt unterbrochen—die angebundenen externen PoS-Chains verlieren dann den Bitcoin-Schutz, und genau das ist der Kernwert von Babylon: „Sicherheit von Bitcoin an die Consumer-Chain weiterreichen“. Die Versionskompatibilität ist dabei der schwächste Punkt.
Das Obige ist nur meine persönliche Meinung und stellt keine Anlageberatung dar. Glaubst du, dass Babylons IBC-Modul den anhaltenden Druck durch fortlaufende Versionsiterationen im Cosmos-Ökosystem aushalten kann? Schreib gern in die Kommentare—ich freue mich auf den Austausch.
#baby $BABY @BabylonLabs_io