Gestern Abend kamen Lao Zhao und der Affe zu mir nach Hause, um zu trinken. Als wir über Babylon Genesis redeten, haben beide gleichzeitig auf den Tisch geklopft und mich gebeten, mal nachzuschauen, was im Whitepaper steht. Heute Mittag habe ich mir das Design „dual-quorum staking“ lange und genau angesehen.
„100 CometBFT-Validatoren, die CometBFT-Konsens ausführen, zusammen mit 60 Bitcoin-staked Finality Providers, die Bitcoin-Finality-Signaturen hinzufügen.“ Als externe Schutzschicht für eine PoS-Kette mit bitcoinscher ökonomischer Sicherheit zu versehen, ist tatsächlich eine sehr schöne Idee. Jeder, der schon einmal an verteilten Systemen gearbeitet hat, wird zugeben müssen, dass dieses Design aktuell der aggressivste Sicherheitsversuch ist.
Aber wenn man die Machtstruktur entlang der Konsensschicht weiter aufdröselt, wird mir richtig unbehaglich.
Die Stimmrechte der Finality Providers sind direkt an die Menge der delegierten BTC gekoppelt. Es gibt für BTC-Delegation keine Obergrenze, sodass riesige Wale große Mengen BTC bündeln und an nur einen Provider delegieren können. Wenn ein einzelnes Entity die Stimmrechte monopolisiert, kann es Blockzensur durchführen und böswillige Reverts umsetzen.
Noch beunruhigender ist für mich die Schwachstelle beim Epoch-wechsel. Babylon rotiert Validatoren epochenweise, und in der GitHub-Sicherheitsmitteilung GHSA-rj53-j6jw-7f7g wurde offengelegt: Wenn man eine Nachricht zum Ändern des Validator-Sets an der Grenze einer Epoch sendet, führt das dazu, dass die gesamte Kette halt macht. Entwickler haben herausgefunden, dass das Protokoll bei fehlendem Block-Hash einen Nullpointer dereferenziert und dadurch panic auslöst; ein böswilliger Validator kann absichtlich das Hash-Feld in der BLS-Abstimmungserweiterung weglassen. Wenn mehrere Validatoren das gleichzeitig ausnutzen, kommt es zum Absturz und das bremst die Blockproduktionsgeschwindigkeit aus. Die Schwachstelle wurde als „High severity“ markiert, und bis zum Zeitpunkt der Offenlegung hatte die offizielle Stelle noch keine Antwort veröffentlicht.
CometBFT sagt: „Ich habe zugestimmt“, Finality Providers sagt: „Ich habe auch unterschrieben“—aber im Moment des Epoch-wechsels steht die ganze Kette still. Wetten wir darauf, dass diese Schwachstelle nicht ausgenutzt wird?
Obiges sind nur persönliche Ansichten und stellt keine Anlageberatung dar. Hast du eine andere Meinung? Schreib gern im Kommentarbereich mit.
#baby $BABY @BabylonLabs_io
„100 CometBFT-Validatoren, die CometBFT-Konsens ausführen, zusammen mit 60 Bitcoin-staked Finality Providers, die Bitcoin-Finality-Signaturen hinzufügen.“ Als externe Schutzschicht für eine PoS-Kette mit bitcoinscher ökonomischer Sicherheit zu versehen, ist tatsächlich eine sehr schöne Idee. Jeder, der schon einmal an verteilten Systemen gearbeitet hat, wird zugeben müssen, dass dieses Design aktuell der aggressivste Sicherheitsversuch ist.
Aber wenn man die Machtstruktur entlang der Konsensschicht weiter aufdröselt, wird mir richtig unbehaglich.
Die Stimmrechte der Finality Providers sind direkt an die Menge der delegierten BTC gekoppelt. Es gibt für BTC-Delegation keine Obergrenze, sodass riesige Wale große Mengen BTC bündeln und an nur einen Provider delegieren können. Wenn ein einzelnes Entity die Stimmrechte monopolisiert, kann es Blockzensur durchführen und böswillige Reverts umsetzen.
Noch beunruhigender ist für mich die Schwachstelle beim Epoch-wechsel. Babylon rotiert Validatoren epochenweise, und in der GitHub-Sicherheitsmitteilung GHSA-rj53-j6jw-7f7g wurde offengelegt: Wenn man eine Nachricht zum Ändern des Validator-Sets an der Grenze einer Epoch sendet, führt das dazu, dass die gesamte Kette halt macht. Entwickler haben herausgefunden, dass das Protokoll bei fehlendem Block-Hash einen Nullpointer dereferenziert und dadurch panic auslöst; ein böswilliger Validator kann absichtlich das Hash-Feld in der BLS-Abstimmungserweiterung weglassen. Wenn mehrere Validatoren das gleichzeitig ausnutzen, kommt es zum Absturz und das bremst die Blockproduktionsgeschwindigkeit aus. Die Schwachstelle wurde als „High severity“ markiert, und bis zum Zeitpunkt der Offenlegung hatte die offizielle Stelle noch keine Antwort veröffentlicht.
CometBFT sagt: „Ich habe zugestimmt“, Finality Providers sagt: „Ich habe auch unterschrieben“—aber im Moment des Epoch-wechsels steht die ganze Kette still. Wetten wir darauf, dass diese Schwachstelle nicht ausgenutzt wird?
Obiges sind nur persönliche Ansichten und stellt keine Anlageberatung dar. Hast du eine andere Meinung? Schreib gern im Kommentarbereich mit.
#baby $BABY @BabylonLabs_io