Am vergangenen Wochenende schickte mir mein ehemaliger Kollege Kobayashi eine Nachricht: „Das BTC-Staking-Skript von Babylon ist irgendwie interessant, aber irgendwie stimmt da etwas nicht.“ Also klickte ich den Zellic-Prüfbericht an, und als ich zu dem Abschnitt über den Pfad des Skripts kam, blieb mein Finger über der Tastatur stehen.
Dieses Projekt hat tatsächlich Substanz. Babylon ermöglicht es Nutzern, BTC mithilfe nativer Bitcoin-Zeit-Lock-Skripte und des Taproot-Upgrades ohne Cross-Chain-Bridge in einer selbstverwalteten Adresse zu sperren. Das Staking-UTXO-Design sieht drei Auszahlungswege vor: einen Time-Lock-Pfad, einen Entbindungs-Pfad und einen Slashing-/Konfiszierungs-Pfad. Der Time-Lock stellt sicher, dass Staker ihre BTC letztlich zurückbekommen, selbst wenn Babylon vollständig ausfällt.
Doch nachdem ich die Mechanik des Skript-Locks auseinandergebaut hatte, trat das eigentliche Problem zutage.
Der Entbindungs-Pfad erfordert die Signatur des Stakers plus eine Signatur eines Covenant-Komitee-Mitglieds, das den Schwellenwert übersteigt. Zellic stellte einen tödlichen Szenariobereich fest: Wenn ein böswilliges Komitee-Mitglied eine falsche Signatur zurückgibt, wird die Entbindungs-Transaktion direkt von der Babylon-Kette abgewiesen, wodurch das Vermögen des Stakers während der gesamten Sperrzeit nicht abgerufen werden kann. Noch beunruhigender: Dieses böswillige Mitglied wird keinerlei Strafe erhalten. Der Konfiszierungs-Pfad hängt von einem EOTS-Signaturmodell ab – wenn die Logik zur Auslösebedingung fehlerhaft ist, kann ein böswilliger Knoten schaden, ohne überhaupt geslashed werden zu können.
Zellic weist außerdem darauf hin, dass die btc-staking-ts-Bibliothek an mehreren Stellen eine fehlende Eingabeprüfung aufweist: Es werden keine Nicht-Negativität bei Zahlen geprüft, Indexwerte werden nicht auf ihren zulässigen Bereich validiert, und stakingTimeLock ist nur zwei Byte lang (wenn die Eingabe > 65535 ist, kommt es zu einem Overflow). Die Prüfung warnt: Das Fehlen von Eingabevalidierung kann zu unerwartetem Verhalten oder zu einem Abbruch des Codes führen.
Defekte in der Urteils-/Konditionslogik der Skript-Entsperrung führen zu zwei Extremen: Entweder kann ein böswilliger Knoten nicht geslashed werden, oder aber ein normaler Nutzer wird sein gestaktes Vermögen grundlos gesperrt. Bitcoin-Skripte sind ohnehin nicht Turing-vollständig; die Überlagerung mehrerer Signaturpfade auf einem begrenzten Skriptumfang macht das Risiko für Fehler an den Randbedingungen nur noch wahrscheinlicher. Kryptografische Beweise können weder garantieren, dass das Covenant-Komitee nicht aus Versehen falsch signiert, noch dass die Eingabeprüfung keinen Overflow verursacht.
Das Vorstehende ist nur meine persönliche Einschätzung und stellt keine Anlageberatung dar. Glaubst du, dass dieses Skript-Mechanismusdesign alle extremen Szenarien abdeckt? Schreib gern im Kommentarbereich, was du darüber denkst.
#baby $BABY @BabylonLabs_io
Dieses Projekt hat tatsächlich Substanz. Babylon ermöglicht es Nutzern, BTC mithilfe nativer Bitcoin-Zeit-Lock-Skripte und des Taproot-Upgrades ohne Cross-Chain-Bridge in einer selbstverwalteten Adresse zu sperren. Das Staking-UTXO-Design sieht drei Auszahlungswege vor: einen Time-Lock-Pfad, einen Entbindungs-Pfad und einen Slashing-/Konfiszierungs-Pfad. Der Time-Lock stellt sicher, dass Staker ihre BTC letztlich zurückbekommen, selbst wenn Babylon vollständig ausfällt.
Doch nachdem ich die Mechanik des Skript-Locks auseinandergebaut hatte, trat das eigentliche Problem zutage.
Der Entbindungs-Pfad erfordert die Signatur des Stakers plus eine Signatur eines Covenant-Komitee-Mitglieds, das den Schwellenwert übersteigt. Zellic stellte einen tödlichen Szenariobereich fest: Wenn ein böswilliges Komitee-Mitglied eine falsche Signatur zurückgibt, wird die Entbindungs-Transaktion direkt von der Babylon-Kette abgewiesen, wodurch das Vermögen des Stakers während der gesamten Sperrzeit nicht abgerufen werden kann. Noch beunruhigender: Dieses böswillige Mitglied wird keinerlei Strafe erhalten. Der Konfiszierungs-Pfad hängt von einem EOTS-Signaturmodell ab – wenn die Logik zur Auslösebedingung fehlerhaft ist, kann ein böswilliger Knoten schaden, ohne überhaupt geslashed werden zu können.
Zellic weist außerdem darauf hin, dass die btc-staking-ts-Bibliothek an mehreren Stellen eine fehlende Eingabeprüfung aufweist: Es werden keine Nicht-Negativität bei Zahlen geprüft, Indexwerte werden nicht auf ihren zulässigen Bereich validiert, und stakingTimeLock ist nur zwei Byte lang (wenn die Eingabe > 65535 ist, kommt es zu einem Overflow). Die Prüfung warnt: Das Fehlen von Eingabevalidierung kann zu unerwartetem Verhalten oder zu einem Abbruch des Codes führen.
Defekte in der Urteils-/Konditionslogik der Skript-Entsperrung führen zu zwei Extremen: Entweder kann ein böswilliger Knoten nicht geslashed werden, oder aber ein normaler Nutzer wird sein gestaktes Vermögen grundlos gesperrt. Bitcoin-Skripte sind ohnehin nicht Turing-vollständig; die Überlagerung mehrerer Signaturpfade auf einem begrenzten Skriptumfang macht das Risiko für Fehler an den Randbedingungen nur noch wahrscheinlicher. Kryptografische Beweise können weder garantieren, dass das Covenant-Komitee nicht aus Versehen falsch signiert, noch dass die Eingabeprüfung keinen Overflow verursacht.
Das Vorstehende ist nur meine persönliche Einschätzung und stellt keine Anlageberatung dar. Glaubst du, dass dieses Skript-Mechanismusdesign alle extremen Szenarien abdeckt? Schreib gern im Kommentarbereich, was du darüber denkst.
#baby $BABY @BabylonLabs_io