凌晨两点，老陈扔过来一个链接：“Babylon，用比特币给PoS链当保安，你瞅瞅。”
我点开文档，盯着“Bitcoin-secured PoS”看了很久。“Babylon enables native bitcoin staking directly on the Bitcoin blockchain without intermediaries.” Mit der ökonomischen Sicherheit von Bitcoin als externer Verteidigungsschicht, so dass die PoS-Kette die endgültige Bestätigung von BTC teilt – diese Idee ist wirklich schön. Jeder, der ein Konsensprotokoll geschrieben hat, muss zugeben, dass das derzeit der aggressivste Sicherheitsversuch in diesem Bereich ist.
Doch als ich dem leichten Client weiter folge und das System auseinandernehme, wird mir allmählich ganz mulmig.
Die Babylon-Chain führt nur einen BTC-Light-Node aus; sie ist nicht in der Lage, den gesamten Bitcoin-Blockverlauf vollständig zu synchronisieren. Stattdessen verlässt sie sich auf Block-Header und UTXO-Skriptprüfungen. Der Auditbericht von Zellic stellt klar fest: Wenn das Babylon-Netzwerk aufgrund eines panic abstürzt, wird nach dem Neustart der btclightclient weiterhin die Absturzhöhe als neuesten Zustand betrachten. In diesem Zeitfenster kann ein böswilliger Mining-Pool zuvor einen Block-Header einer Fork einreichen. Der Light-Client wird die Fork vorübergehend als Hauptkette behandeln – Staking-Transaktionen könnten dann auf der falschen Fork bestätigt werden. Wenn das Bitcoin-Netzwerk einsame Blöcke, Reorganisations oder tiefe Block-Rollbacks hat, kann der Light-Client das nicht erkennen.
Noch beunruhigender für mich ist EOTS. Das ist die herausziehbare Einmal-Signatur, eine zentrale Innovation von Babylon, die für Cross-Chain-Penaltiemissbrauch-Nachweise verwendet wird – „if an FP signs two different blocks at the same height, the private key is exposed, leading to automatic slashing“. Klingt wunderschön, aber Zelic hat beim Audit festgestellt, dass die eotsmanager-GenerateRandomness-Funktion beim Verwenden von SetByteSlice den Rückgabewert nicht prüft: Wenn das Überlaufen die Ordnung der Secp256k1-Gruppe betrifft, wird der nonce zu einer nicht gleichverteilten Verteilung. Zwar ist die Wahrscheinlichkeit gering, aber sobald ein Overflow-Sample auftritt, kann man mit dem Hidden-Number-Problem-Algorithmus den EOTS-Private-Key wiederherstellen. Noch tödlicher ist GHSA-7mm3-vfg8-7rg6: Das x/finality-Modul hat keine Domänentrennung; Angreifer können eine PoP-Signatur in MsgCommitPubRandList umreplayen und ungültige PubRand-Commitments injizieren.
Du nutzt die Endgültigkeit von Bitcoin als Burggraben, aber der Light-Client sieht die Forks von Bitcoin nicht – du setzt bei der Penaltiemacherei auf selbst entwickelte Kryptografie, und bei der Zufallszahlengenerierung von EOTS wird nicht einmal das Überlaufen geprüft. Wem glaubst du: der Bitcoin-Kette, oder dieser Code-Implementierung?
#baby $BABY @BabylonLabs_io
我点开文档，盯着“Bitcoin-secured PoS”看了很久。“Babylon enables native bitcoin staking directly on the Bitcoin blockchain without intermediaries.” Mit der ökonomischen Sicherheit von Bitcoin als externer Verteidigungsschicht, so dass die PoS-Kette die endgültige Bestätigung von BTC teilt – diese Idee ist wirklich schön. Jeder, der ein Konsensprotokoll geschrieben hat, muss zugeben, dass das derzeit der aggressivste Sicherheitsversuch in diesem Bereich ist.
Doch als ich dem leichten Client weiter folge und das System auseinandernehme, wird mir allmählich ganz mulmig.
Die Babylon-Chain führt nur einen BTC-Light-Node aus; sie ist nicht in der Lage, den gesamten Bitcoin-Blockverlauf vollständig zu synchronisieren. Stattdessen verlässt sie sich auf Block-Header und UTXO-Skriptprüfungen. Der Auditbericht von Zellic stellt klar fest: Wenn das Babylon-Netzwerk aufgrund eines panic abstürzt, wird nach dem Neustart der btclightclient weiterhin die Absturzhöhe als neuesten Zustand betrachten. In diesem Zeitfenster kann ein böswilliger Mining-Pool zuvor einen Block-Header einer Fork einreichen. Der Light-Client wird die Fork vorübergehend als Hauptkette behandeln – Staking-Transaktionen könnten dann auf der falschen Fork bestätigt werden. Wenn das Bitcoin-Netzwerk einsame Blöcke, Reorganisations oder tiefe Block-Rollbacks hat, kann der Light-Client das nicht erkennen.
Noch beunruhigender für mich ist EOTS. Das ist die herausziehbare Einmal-Signatur, eine zentrale Innovation von Babylon, die für Cross-Chain-Penaltiemissbrauch-Nachweise verwendet wird – „if an FP signs two different blocks at the same height, the private key is exposed, leading to automatic slashing“. Klingt wunderschön, aber Zelic hat beim Audit festgestellt, dass die eotsmanager-GenerateRandomness-Funktion beim Verwenden von SetByteSlice den Rückgabewert nicht prüft: Wenn das Überlaufen die Ordnung der Secp256k1-Gruppe betrifft, wird der nonce zu einer nicht gleichverteilten Verteilung. Zwar ist die Wahrscheinlichkeit gering, aber sobald ein Overflow-Sample auftritt, kann man mit dem Hidden-Number-Problem-Algorithmus den EOTS-Private-Key wiederherstellen. Noch tödlicher ist GHSA-7mm3-vfg8-7rg6: Das x/finality-Modul hat keine Domänentrennung; Angreifer können eine PoP-Signatur in MsgCommitPubRandList umreplayen und ungültige PubRand-Commitments injizieren.
Du nutzt die Endgültigkeit von Bitcoin als Burggraben, aber der Light-Client sieht die Forks von Bitcoin nicht – du setzt bei der Penaltiemacherei auf selbst entwickelte Kryptografie, und bei der Zufallszahlengenerierung von EOTS wird nicht einmal das Überlaufen geprüft. Wem glaubst du: der Bitcoin-Kette, oder dieser Code-Implementierung?
#baby $BABY @BabylonLabs_io