Am Mittwochabend schickte mir der ehemalige Kollege Kobayashi eine Nachricht: „Hast du dir die Off-Chain-Datenspeicherung von Babylon angesehen? Alle Staking-Delegationsbeziehungen liegen in einer Off-Chain-Node-Datenbank, on-chain gibt es nur Hashes.“ Ich öffnete die Babylon-Dokumentation und mir wurde ganz kalt, als ich den Satz las: „The Babylon Staking Protocol maintains an index of staked Bitcoin“.
Auf der Bitcoin-Blockchain wird nur der UTXO-Sperrstatus aufgezeichnet. Die Babylon-Genesis-Chain, als Cosmos-SDK-Chain, ist dafür zuständig, den Staking-Status und die Ausschüttung der Belohnungen nachzuverfolgen. Der Großteil der Staking-Delegationsbeziehungen und die Delegationsaufzeichnungen werden in der Off-Chain-Node-Datenbank gespeichert. On-chain verbleibt nur eine Hash-Zusammenfassung. Wenn die Node-Datenbank zerstört wird, können die Staking-Belohnungen der Nutzer nicht zurückgefordert werden.
Das Audit von Zellic wies darauf hin, dass die acht Kernmodule von Babylon an mehreren Stellen erhebliche Hochrisiko-Gefahren aufweisen. Die Sicherheitsforschung von OpenZeppelin zeigte zudem vier typische Schwachstellen, darunter eine unsachgemäße Verarbeitung des Delegationsstatus und das Umgehen der Slashing-Mechanismen. Die Wiederherstellung von Delegationsbeziehungen hängt von Off-Chain-Indexern ab. Sobald die Datenbank ausfällt, wird der gesamte Staking-Status zu einer nicht nachvollziehbaren, verdorbenen Buchung.
Noch unsicherer ist das Risiko einer Manipulation durch die Oracle-„Confirmations“-Vorhersage (bestätigte Blöcke). Babylon liest die Blockheader über einen BTC-Light-Client, um zu beurteilen, ob das Staking wirksam ist. Wenn sich Oracle-Knoten absprechen und falsche Blockhöhen melden, kann Babylon glauben, das Staking sei bereits wirksam, noch bevor das Bitcoin-Mainnet es bestätigt. So könnten gefälschte Staking-Nachweise genutzt werden, um Belohnungen zu erschleichen.
Auch die Lücken durch Komprimierung von Status-Snapshots sind genauso kritisch. Babylon komprimiert regelmäßig den PoS-Chain-Status zu Snapshots und schreibt diese on-chain. Wenn in dem Komprimierungsalgorithmus Fehler an den Grenzen vorliegen, könnten die Daten für große Staking-Adressen abgeschnitten werden, was zu falscher Vermögensberechnung führt. Entwickler haben offengelegt, dass ein böswilliger Validator am Epochrand das Feld für den Blockhash in der BLS-Abstimmungserweiterung auslassen kann, wodurch ein Knoten abstürzt.
Hindenrank stufte Babylon als C ein, mit einer Risikobewertung von 57/100—15 Punkte über dem Branchendurchschnitt. Kryptografie kann beweisen, dass das BTC-Staking korrekt ist, aber sie kann nicht beweisen, dass die Off-Chain-Datenbank nicht zerstört wird, dass die Oracle-Knoten nicht gemeinsame Sache machen oder dass der Komprimierungsalgorithmus die Daten nicht abschneidet.
Das oben Genannte ist nur meine persönliche Meinung und stellt keine Anlageberatung dar. Glaubst du, dass Babylons Off-Chain-Speichermechanismus einer Datenbankzerstörung oder einer Oracle-Manipulation standhalten kann? Schreib gerne im Kommentarbereich mit.
#baby $BABY @BabylonLabs_io
Auf der Bitcoin-Blockchain wird nur der UTXO-Sperrstatus aufgezeichnet. Die Babylon-Genesis-Chain, als Cosmos-SDK-Chain, ist dafür zuständig, den Staking-Status und die Ausschüttung der Belohnungen nachzuverfolgen. Der Großteil der Staking-Delegationsbeziehungen und die Delegationsaufzeichnungen werden in der Off-Chain-Node-Datenbank gespeichert. On-chain verbleibt nur eine Hash-Zusammenfassung. Wenn die Node-Datenbank zerstört wird, können die Staking-Belohnungen der Nutzer nicht zurückgefordert werden.
Das Audit von Zellic wies darauf hin, dass die acht Kernmodule von Babylon an mehreren Stellen erhebliche Hochrisiko-Gefahren aufweisen. Die Sicherheitsforschung von OpenZeppelin zeigte zudem vier typische Schwachstellen, darunter eine unsachgemäße Verarbeitung des Delegationsstatus und das Umgehen der Slashing-Mechanismen. Die Wiederherstellung von Delegationsbeziehungen hängt von Off-Chain-Indexern ab. Sobald die Datenbank ausfällt, wird der gesamte Staking-Status zu einer nicht nachvollziehbaren, verdorbenen Buchung.
Noch unsicherer ist das Risiko einer Manipulation durch die Oracle-„Confirmations“-Vorhersage (bestätigte Blöcke). Babylon liest die Blockheader über einen BTC-Light-Client, um zu beurteilen, ob das Staking wirksam ist. Wenn sich Oracle-Knoten absprechen und falsche Blockhöhen melden, kann Babylon glauben, das Staking sei bereits wirksam, noch bevor das Bitcoin-Mainnet es bestätigt. So könnten gefälschte Staking-Nachweise genutzt werden, um Belohnungen zu erschleichen.
Auch die Lücken durch Komprimierung von Status-Snapshots sind genauso kritisch. Babylon komprimiert regelmäßig den PoS-Chain-Status zu Snapshots und schreibt diese on-chain. Wenn in dem Komprimierungsalgorithmus Fehler an den Grenzen vorliegen, könnten die Daten für große Staking-Adressen abgeschnitten werden, was zu falscher Vermögensberechnung führt. Entwickler haben offengelegt, dass ein böswilliger Validator am Epochrand das Feld für den Blockhash in der BLS-Abstimmungserweiterung auslassen kann, wodurch ein Knoten abstürzt.
Hindenrank stufte Babylon als C ein, mit einer Risikobewertung von 57/100—15 Punkte über dem Branchendurchschnitt. Kryptografie kann beweisen, dass das BTC-Staking korrekt ist, aber sie kann nicht beweisen, dass die Off-Chain-Datenbank nicht zerstört wird, dass die Oracle-Knoten nicht gemeinsame Sache machen oder dass der Komprimierungsalgorithmus die Daten nicht abschneidet.
Das oben Genannte ist nur meine persönliche Meinung und stellt keine Anlageberatung dar. Glaubst du, dass Babylons Off-Chain-Speichermechanismus einer Datenbankzerstörung oder einer Oracle-Manipulation standhalten kann? Schreib gerne im Kommentarbereich mit.
#baby $BABY @BabylonLabs_io