Gestern Abend habe ich die neue $AEON gejagt und für 26 u verkauft. Vor der Tokenausgabe wurde auf dem Platz derart übermächtig nach dem „Grille“-Mindset geschrien, „Grille, Grille, Grille“ – der Typ von dem „Grille“-Sprech halt. Aber ganz ehrlich: Ich hätte besser $BABY kaufen sollen, um mein Grille-Setup durchzuziehen.
Wenn wir über BABY sprechen: Gestern Nacht habe ich Code geändert, bis in den frühen Morgen. Lao Zhou hat mir dann eine Nachricht geschickt: „Hast du dir Babylons Slashing-Mechanismus angeschaut? Mehrere Quellen melden Beweise – schon ein bisschen Netzwerklatenz kann dazu führen, dass das als böswillige Doppel-Signatur gewertet wird.“
Ich habe das Dokument geöffnet und lange auf „slashing mechanism“ gestarrt. „The protocol implements a slashing mechanism where staked assets may be forfeited if protocol security rules are violated.“ Mit „Slashing als Abschreckung für böswilliges Verhalten“ – wer jemals einen Konsens-Algorithmus geschrieben hat, muss zugeben, dass das im PoS-Sicherheitsmodell der wichtigste Baustein ist.
Aber wenn man den Beweiserfassungs-Flow weiter zerlegt, wird mir richtig mulmig.
Slashing stützt sich darauf, dass mehrere Quellknoten Beweise melden – der Vigilante-Component macht regelmäßig Roundtrips zu Babylon-Knoten, um Beweise für Fehlverhalten zu sammeln. Nach der Einreichung müssen die Beweise verifiziert, geprüft und abgestimmt werden; der Ablauf ist komplex. Das Problem ist: Netzwerklatenz, Paketverluste – und das System kann es als böswillige Doppel-Signatur einordnen. Ein Finality Provider wurde wegen Netzwerkzucken fälschlich als böswillig eingestuft, und 0,1 % der BTC-gestakelten Menge wurden direkt vernichtet; danach ging es in den permanenten „Slashed“-Status.
Der von Zellic offengelegte Prüfbericht macht mir noch mehr Sorgen: Wenn ein Angreifer den RPC-Endpunkt des EOTS-Managers aufruft und dabei keinen HMAC-Schutz hat, kann er das Slashing gegen einen Finality Provider manuell auslösen. Auch OpenZeppelin hat Kernlücken wie Slashing-Umgehung und Delegations-Status-Handling offengelegt. Es wird nicht nur bei wirklich böswilligem Verhalten geschlachtet – auch externe Angreifer können Lücken ausnutzen, sodass du „ge-slash’t“ wirst.
Am tödlichsten ist: Es gibt keinen automatischen Einspruch- oder Rollback-Mechanismus. Nachdem die Slashing-Transaktion im Bitcoin-Netzwerk ausgeführt wurde, werden die Assets direkt an eine nicht ausgebbare Burn-Adresse gesendet. Die Unumkehrbarkeit von Bitcoin-Skripten bedeutet: Dieser Fehler lässt sich für immer nicht mehr gutmachen.
Slashing zur Abschreckung von Fehlverhalten ist richtig. Aber ein System, das auf komplexer Beweiserfassung beruht und keinen Einspruchsmechanismus hat – ein bisschen Netzwerklatenz kann es schon zu „böswillig“ machen, und diese Rechnung lässt sich niemals zurückholen. Wetteiierst du darauf, dass deine Knoten nie falsch beurteilt werden?
Das oben ist nur meine persönliche Meinung und keine Anlageberatung. Hast du eine andere Sichtweise? Schreib gern im Kommentarbereich.
#baby @BabylonLabs_io
Wenn wir über BABY sprechen: Gestern Nacht habe ich Code geändert, bis in den frühen Morgen. Lao Zhou hat mir dann eine Nachricht geschickt: „Hast du dir Babylons Slashing-Mechanismus angeschaut? Mehrere Quellen melden Beweise – schon ein bisschen Netzwerklatenz kann dazu führen, dass das als böswillige Doppel-Signatur gewertet wird.“
Ich habe das Dokument geöffnet und lange auf „slashing mechanism“ gestarrt. „The protocol implements a slashing mechanism where staked assets may be forfeited if protocol security rules are violated.“ Mit „Slashing als Abschreckung für böswilliges Verhalten“ – wer jemals einen Konsens-Algorithmus geschrieben hat, muss zugeben, dass das im PoS-Sicherheitsmodell der wichtigste Baustein ist.
Aber wenn man den Beweiserfassungs-Flow weiter zerlegt, wird mir richtig mulmig.
Slashing stützt sich darauf, dass mehrere Quellknoten Beweise melden – der Vigilante-Component macht regelmäßig Roundtrips zu Babylon-Knoten, um Beweise für Fehlverhalten zu sammeln. Nach der Einreichung müssen die Beweise verifiziert, geprüft und abgestimmt werden; der Ablauf ist komplex. Das Problem ist: Netzwerklatenz, Paketverluste – und das System kann es als böswillige Doppel-Signatur einordnen. Ein Finality Provider wurde wegen Netzwerkzucken fälschlich als böswillig eingestuft, und 0,1 % der BTC-gestakelten Menge wurden direkt vernichtet; danach ging es in den permanenten „Slashed“-Status.
Der von Zellic offengelegte Prüfbericht macht mir noch mehr Sorgen: Wenn ein Angreifer den RPC-Endpunkt des EOTS-Managers aufruft und dabei keinen HMAC-Schutz hat, kann er das Slashing gegen einen Finality Provider manuell auslösen. Auch OpenZeppelin hat Kernlücken wie Slashing-Umgehung und Delegations-Status-Handling offengelegt. Es wird nicht nur bei wirklich böswilligem Verhalten geschlachtet – auch externe Angreifer können Lücken ausnutzen, sodass du „ge-slash’t“ wirst.
Am tödlichsten ist: Es gibt keinen automatischen Einspruch- oder Rollback-Mechanismus. Nachdem die Slashing-Transaktion im Bitcoin-Netzwerk ausgeführt wurde, werden die Assets direkt an eine nicht ausgebbare Burn-Adresse gesendet. Die Unumkehrbarkeit von Bitcoin-Skripten bedeutet: Dieser Fehler lässt sich für immer nicht mehr gutmachen.
Slashing zur Abschreckung von Fehlverhalten ist richtig. Aber ein System, das auf komplexer Beweiserfassung beruht und keinen Einspruchsmechanismus hat – ein bisschen Netzwerklatenz kann es schon zu „böswillig“ machen, und diese Rechnung lässt sich niemals zurückholen. Wetteiierst du darauf, dass deine Knoten nie falsch beurteilt werden?
Das oben ist nur meine persönliche Meinung und keine Anlageberatung. Hast du eine andere Sichtweise? Schreib gern im Kommentarbereich.
#baby @BabylonLabs_io