Gestern beim gemeinsamen Abendessen schmuggelte der alte Zhou, der Sicherheits-Audits macht, sich eine Portion zu: „Babylon Light-Client ist ziemlich interessant. Die Bitcoin-Finalität ist letztlich ein Graben zum Schutz, aber der Light-Client kann nicht mal einen Fork sehen.“
Zuhause öffnete ich ein Dokument und starrte lange auf „Bitcoin-secured PoS“. Mit der wirtschaftlichen Sicherheit von Bitcoin PoS-Ketten als externe Verteidigungslinie zu geben – die Idee ist wirklich hübsch. Wer jemals ein Konsensprotokoll geschrieben hat, muss zugeben, dass dieses Design der aggressivste Sicherheitsversuch in der Branche ist.
Aber als ich den Light-Client weiter auseinandernehme, beginnt mir der Rücken kalt zu werden.
Die Babylon-Kette läuft nur mit BTC-Light-Nodes, verlässt sich ausschließlich auf Blockheader- und UTXO-Skript-Prüfungen. Wenn es in Bitcoin zu Uncle/Orphan-Blöcken, Reorgs oder tiefen Rollbacks kommt, kann der Light-Client das überhaupt nicht erkennen. Der Auditbericht von Zellic ist noch deutlicher: Wenn die Babylon-Kette panic auslöst und abstürzt, erkennt der Light-Client nach dem Neustart immer noch die Absturzhöhe als die aktuellste – also die Höhe vor dem Crash. Ein böswilliger Mining-Pool kann während der „Fenster“-Zeit eine Fork-Kette ausgraben und Fork-Blockheader vorher einreichen; der Light-Client behandelt den Fork dann vorübergehend als Hauptkette – Staking-Transaktionen könnten auf dem falschen Fork bestätigt werden.
Noch schlimmer für meinen kalten Rücken ist EOTS. Babylons zentrale Innovation ist „extrahierbare einmalige Signaturen“, verwendet für plattformübergreifende Slashing-Beweise – „if an FP signs two different blocks at the same height, the private key is exposed“. Der Logik-Kreis ist geschlossen. Aber Zellic fand, dass die eotsmanager-Funktion GenerateRandomness bei der Verwendung von SetByteSlice den Rückgabewert nicht prüft: Beim Überlauf auf die Secp256k1-Gruppenordnung wird der nonce zu einer nicht-gleichverteilten Größe. Tritt so ein Überlauf auf, kann man in Kombination mit dem HNP-Algorithmus den EOTS-Privatschlüssel wiederherstellen. Noch tödlicher ist GHSA-7mm3-vfg8-7rg6: Das x/finality-Modul hat keine Domain-Separation – Angreifer können eine PoP-Signatur als MsgCommitPubRandList umreplayen und ungültige Commitments injizieren.
Bitcoin-Finalität als Graben zum Schutz – doch der Light-Client sieht keine Forks. Selbst entwickelte Kryptografie fürs Slashing, aber selbst den Überlauf der Zufallszahl wird nicht geprüft. Was meinst du, alter Zhou?
Das Obige ist nur meine persönliche Meinung und stellt keine Anlageberatung dar. Hast du eine andere Sichtweise? Schreib gern in die Kommentare – lass uns darüber sprechen.
#baby $BABY @BabylonLabs_io
Zuhause öffnete ich ein Dokument und starrte lange auf „Bitcoin-secured PoS“. Mit der wirtschaftlichen Sicherheit von Bitcoin PoS-Ketten als externe Verteidigungslinie zu geben – die Idee ist wirklich hübsch. Wer jemals ein Konsensprotokoll geschrieben hat, muss zugeben, dass dieses Design der aggressivste Sicherheitsversuch in der Branche ist.
Aber als ich den Light-Client weiter auseinandernehme, beginnt mir der Rücken kalt zu werden.
Die Babylon-Kette läuft nur mit BTC-Light-Nodes, verlässt sich ausschließlich auf Blockheader- und UTXO-Skript-Prüfungen. Wenn es in Bitcoin zu Uncle/Orphan-Blöcken, Reorgs oder tiefen Rollbacks kommt, kann der Light-Client das überhaupt nicht erkennen. Der Auditbericht von Zellic ist noch deutlicher: Wenn die Babylon-Kette panic auslöst und abstürzt, erkennt der Light-Client nach dem Neustart immer noch die Absturzhöhe als die aktuellste – also die Höhe vor dem Crash. Ein böswilliger Mining-Pool kann während der „Fenster“-Zeit eine Fork-Kette ausgraben und Fork-Blockheader vorher einreichen; der Light-Client behandelt den Fork dann vorübergehend als Hauptkette – Staking-Transaktionen könnten auf dem falschen Fork bestätigt werden.
Noch schlimmer für meinen kalten Rücken ist EOTS. Babylons zentrale Innovation ist „extrahierbare einmalige Signaturen“, verwendet für plattformübergreifende Slashing-Beweise – „if an FP signs two different blocks at the same height, the private key is exposed“. Der Logik-Kreis ist geschlossen. Aber Zellic fand, dass die eotsmanager-Funktion GenerateRandomness bei der Verwendung von SetByteSlice den Rückgabewert nicht prüft: Beim Überlauf auf die Secp256k1-Gruppenordnung wird der nonce zu einer nicht-gleichverteilten Größe. Tritt so ein Überlauf auf, kann man in Kombination mit dem HNP-Algorithmus den EOTS-Privatschlüssel wiederherstellen. Noch tödlicher ist GHSA-7mm3-vfg8-7rg6: Das x/finality-Modul hat keine Domain-Separation – Angreifer können eine PoP-Signatur als MsgCommitPubRandList umreplayen und ungültige Commitments injizieren.
Bitcoin-Finalität als Graben zum Schutz – doch der Light-Client sieht keine Forks. Selbst entwickelte Kryptografie fürs Slashing, aber selbst den Überlauf der Zufallszahl wird nicht geprüft. Was meinst du, alter Zhou?
Das Obige ist nur meine persönliche Meinung und stellt keine Anlageberatung dar. Hast du eine andere Sichtweise? Schreib gern in die Kommentare – lass uns darüber sprechen.
#baby $BABY @BabylonLabs_io