Die gefährlichste Doppel-Signatur kommt nicht unbedingt von Bösewichten.
Ich habe mir das Anti-Slashing-Dokument für Finality Provider von @BabylonLabs_io angesehen. Das EOTS-Design ist sehr hart: Unter derselben Höhe zwei widersprüchliche Blöcke signieren, würde den privaten Schlüssel offenlegen und die entsprechenden Delegatoren einem Slashing-Risiko aussetzen. Das klingt so, als würde man gezielt „schlechte Leute“ erwischen, aber offiziell wird auch selbst darauf hingewiesen: Hardwarefehler, Softwarefehler oder eine Beschädigung der Datenbank können dazu führen, dass ehrliche Betreiber in genau dieselbe Falle tappen.
Das Spannende hier ist also nicht, ob man bestrafen kann, sondern wie man Fehlalarme vermeidet. Babylon teilt die Verantwortung auf zwei Prozesse auf: fpd zeichnet lastVotedHeight auf und fordert grundsätzlich keine Signaturen für alte Höhen mehr an; eotsd speichert die Signaturhistorie. Wenn in derselben Höhe dieselbe Nachricht eingeht, gibt es das alte Ergebnis zurück. Wenn eine andere Nachricht eingeht, meldet es direkt eine Doppel-Signatur-Warnung. So wie an der Tür und im Tresor jeweils ein Schloss: Wenn ein Teil der Zustände schiefgeht, kann der andere immer noch blockieren.
Aber zwei Schlösser bedeuten nicht, dass es automatischen „Häuserdienst“ ohne Betrieb gibt. Offiziell wird verlangt, dass man sich mit vertrauenswürdigen und korrekt antwortenden Genesis-Nodes verbindet, dass beide Datenbanken nicht beschädigt werden, und es wird außerdem empfohlen, die Dienste getrennt zu betreiben, HMAC zu aktivieren, regelmäßig Backups zu erstellen und den RPC selbst zu betreiben. Beim Upgrade kann es zu kurzfristigem Verbindungsverlust kommen; nach einem Neustart kann die Höhenbewertung fehlerhaft sein; Backups können in einen alten Zustand wiederhergestellt werden – das sind alles Betriebsprobleme, die sich nicht durch das Austauschen eines kryptografischen Schlagworts beseitigen lassen.
Das ist entscheidend für die Sicherheits-Erzählung von $BABY . Je eindeutiger das Slashing, desto stärker die Netzwerkzwänge; aber dieselbe „Messer“-Logik verlangt vom Betreiber auch höhere Kosten für Monitoring, Backups und Wiederherstellung. Sicherheit ist nicht mit dem Tag der Protokollveröffentlichung erledigt, sondern damit, dass man bei jedem Neustart keine Fehler macht.
Darum schaue ich mir den Finality Provider von #baby nicht nur nach der Anzahl und dem Delegationsvolumen an, sondern vor allem nach Doppel-Signatur-Warnungen, nach Zwischenfällen bei Node-Upgrades, nach Backup- und Wiederherstellungsübungen sowie danach, ob der Betreiber redundante Pläne öffentlich macht. Echte Netzsicherheit entsteht nicht durch die sechs Worte „Bösewichte werden sicher bestraft“, sondern dadurch, dass ehrliche Menschen in der verwirrendsten Stunde immer noch nicht aus Versehen falsch signieren.
$ETH $VIC
Ich habe mir das Anti-Slashing-Dokument für Finality Provider von @BabylonLabs_io angesehen. Das EOTS-Design ist sehr hart: Unter derselben Höhe zwei widersprüchliche Blöcke signieren, würde den privaten Schlüssel offenlegen und die entsprechenden Delegatoren einem Slashing-Risiko aussetzen. Das klingt so, als würde man gezielt „schlechte Leute“ erwischen, aber offiziell wird auch selbst darauf hingewiesen: Hardwarefehler, Softwarefehler oder eine Beschädigung der Datenbank können dazu führen, dass ehrliche Betreiber in genau dieselbe Falle tappen.
Das Spannende hier ist also nicht, ob man bestrafen kann, sondern wie man Fehlalarme vermeidet. Babylon teilt die Verantwortung auf zwei Prozesse auf: fpd zeichnet lastVotedHeight auf und fordert grundsätzlich keine Signaturen für alte Höhen mehr an; eotsd speichert die Signaturhistorie. Wenn in derselben Höhe dieselbe Nachricht eingeht, gibt es das alte Ergebnis zurück. Wenn eine andere Nachricht eingeht, meldet es direkt eine Doppel-Signatur-Warnung. So wie an der Tür und im Tresor jeweils ein Schloss: Wenn ein Teil der Zustände schiefgeht, kann der andere immer noch blockieren.
Aber zwei Schlösser bedeuten nicht, dass es automatischen „Häuserdienst“ ohne Betrieb gibt. Offiziell wird verlangt, dass man sich mit vertrauenswürdigen und korrekt antwortenden Genesis-Nodes verbindet, dass beide Datenbanken nicht beschädigt werden, und es wird außerdem empfohlen, die Dienste getrennt zu betreiben, HMAC zu aktivieren, regelmäßig Backups zu erstellen und den RPC selbst zu betreiben. Beim Upgrade kann es zu kurzfristigem Verbindungsverlust kommen; nach einem Neustart kann die Höhenbewertung fehlerhaft sein; Backups können in einen alten Zustand wiederhergestellt werden – das sind alles Betriebsprobleme, die sich nicht durch das Austauschen eines kryptografischen Schlagworts beseitigen lassen.
Das ist entscheidend für die Sicherheits-Erzählung von $BABY . Je eindeutiger das Slashing, desto stärker die Netzwerkzwänge; aber dieselbe „Messer“-Logik verlangt vom Betreiber auch höhere Kosten für Monitoring, Backups und Wiederherstellung. Sicherheit ist nicht mit dem Tag der Protokollveröffentlichung erledigt, sondern damit, dass man bei jedem Neustart keine Fehler macht.
Darum schaue ich mir den Finality Provider von #baby nicht nur nach der Anzahl und dem Delegationsvolumen an, sondern vor allem nach Doppel-Signatur-Warnungen, nach Zwischenfällen bei Node-Upgrades, nach Backup- und Wiederherstellungsübungen sowie danach, ob der Betreiber redundante Pläne öffentlich macht. Echte Netzsicherheit entsteht nicht durch die sechs Worte „Bösewichte werden sicher bestraft“, sondern dadurch, dass ehrliche Menschen in der verwirrendsten Stunde immer noch nicht aus Versehen falsch signieren.
$ETH $VIC