Der peinlichste Moment in einer Wertpapier-Abwicklungs-Chain: Es ist nicht unbedingt ein Hackerangriff, sondern eher, dass niemand eindeutig etwas Böses tut – und doch lässt sich das Ledger nicht weiterblättern. Knoten fallen aus, es kommt zu Netzwerkpartitionen, das Komitee schafft nicht die nötige Anzahl Stimmen; das Geld ist nicht weg, aber alle müssen warten. Bei einer öffentlichen Chain heißt das „Stau“, für einen Finanzmarkt kann es sich direkt zu einem Abwicklungsunfall entwickeln.
Ich habe das Whitepaper zum „Emergency Mode“ von @Dusk erneut gelesen und festgestellt, dass es sich nicht nur so tut, als würde so etwas nicht passieren. Succinct Attestation führt pro Runde höchstens 50 Iterationen aus; wenn 16 Iterationen hintereinander fehlschlagen, geht das Protokoll in den Notfallmodus. Schritt-Schritte, die im normalen Ablauf per Timeout abbrechen, werden deaktiviert. „NoCandidate“ und „NoQuorum“ dienen dann nicht mehr als Ergebnis, das den Fortschritt auslöst. Die bereits gestarteten Iterationen warten stattdessen weiter, bis ein Kandidatenblock im Kandidatenbereich verfügbar ist und in den beiden Phasen Verifikation und Freigabe tatsächlich die gesetzliche Stimmenzahl erreicht ist.
Die Intention dieses Designs ist sehr klar: Im Normalbetrieb kann Konsens wegen Timeouts zur nächsten Runde von Teilnehmenden wechseln; in Extremfällen darf man aber nicht dauerhaft auf „niemand ist da“ hoffen, um das Problem einfach zu überspringen. Das System lässt lieber mehrere offene Iterationen parallel hängen, statt früher oder später aufzugeben – und wartet darauf, dass ein Block gefunden wird, den das Komitee bestätigen kann, um die Wahrscheinlichkeit zu erhöhen, dass das Ledger weiter vorankommt.
Doch die Kosten stehen ebenfalls im Whitepaper. Parallele Iterationen können dazu führen, dass in derselben Runde mehrere Kandidatenblöcke einen Konsens erhalten; das erhöht wiederum das Fork-Risiko. Das Protokoll kann dann nur den Kandidatenblock mit der niedrigsten Iterationsnummer zur Konvergenz bringen. Wenn es am Ende immer noch nicht gelingt, den Betrieb wiederherzustellen, können die meisten Stimmrechtsinhaber gemeinsam eine Notfall-Leerblockanfrage stellen, die keine Transaktionen enthält. Ein Dusk-Knoten erzeugt dann einen neuen Seed, sodass das Netzwerk diese Runde überspringen kann.
Ich werde das nicht als „niemals Abschalten“ verstehen. Es ist eher ein Handbuch für Katastrophenwiederherstellung: Es erkennt an, dass Konsens ins Stocken geraten kann, und legt zugleich fest, wer die Wiederherstellung vorantreiben darf und was dabei geopfert werden kann. Wenn ich mir später die Fähigkeiten zur Finanzabwicklung von $DUSK anschaue, interessiert mich vor allem, wie oft der Notfallmodus tatsächlich ausgelöst wird, wie lange er anhält, wie viele Forks entstehen und wie oft Leerblöcke angefordert werden – nicht nur, wie viele Sekunden im Normalzustand für das Produzieren eines Blocks benötigt werden.
Echte Infrastruktur auf Institutsniveau bedeutet nicht, dass nie Fehler auftreten. Sondern: Wenn Fehler passieren, sind die Regeln für die Behandlung im Voraus festgeschrieben – und die Kosten sind für alle sichtbar.
#dusk
Ich habe das Whitepaper zum „Emergency Mode“ von @Dusk erneut gelesen und festgestellt, dass es sich nicht nur so tut, als würde so etwas nicht passieren. Succinct Attestation führt pro Runde höchstens 50 Iterationen aus; wenn 16 Iterationen hintereinander fehlschlagen, geht das Protokoll in den Notfallmodus. Schritt-Schritte, die im normalen Ablauf per Timeout abbrechen, werden deaktiviert. „NoCandidate“ und „NoQuorum“ dienen dann nicht mehr als Ergebnis, das den Fortschritt auslöst. Die bereits gestarteten Iterationen warten stattdessen weiter, bis ein Kandidatenblock im Kandidatenbereich verfügbar ist und in den beiden Phasen Verifikation und Freigabe tatsächlich die gesetzliche Stimmenzahl erreicht ist.
Die Intention dieses Designs ist sehr klar: Im Normalbetrieb kann Konsens wegen Timeouts zur nächsten Runde von Teilnehmenden wechseln; in Extremfällen darf man aber nicht dauerhaft auf „niemand ist da“ hoffen, um das Problem einfach zu überspringen. Das System lässt lieber mehrere offene Iterationen parallel hängen, statt früher oder später aufzugeben – und wartet darauf, dass ein Block gefunden wird, den das Komitee bestätigen kann, um die Wahrscheinlichkeit zu erhöhen, dass das Ledger weiter vorankommt.
Doch die Kosten stehen ebenfalls im Whitepaper. Parallele Iterationen können dazu führen, dass in derselben Runde mehrere Kandidatenblöcke einen Konsens erhalten; das erhöht wiederum das Fork-Risiko. Das Protokoll kann dann nur den Kandidatenblock mit der niedrigsten Iterationsnummer zur Konvergenz bringen. Wenn es am Ende immer noch nicht gelingt, den Betrieb wiederherzustellen, können die meisten Stimmrechtsinhaber gemeinsam eine Notfall-Leerblockanfrage stellen, die keine Transaktionen enthält. Ein Dusk-Knoten erzeugt dann einen neuen Seed, sodass das Netzwerk diese Runde überspringen kann.
Ich werde das nicht als „niemals Abschalten“ verstehen. Es ist eher ein Handbuch für Katastrophenwiederherstellung: Es erkennt an, dass Konsens ins Stocken geraten kann, und legt zugleich fest, wer die Wiederherstellung vorantreiben darf und was dabei geopfert werden kann. Wenn ich mir später die Fähigkeiten zur Finanzabwicklung von $DUSK anschaue, interessiert mich vor allem, wie oft der Notfallmodus tatsächlich ausgelöst wird, wie lange er anhält, wie viele Forks entstehen und wie oft Leerblöcke angefordert werden – nicht nur, wie viele Sekunden im Normalzustand für das Produzieren eines Blocks benötigt werden.
Echte Infrastruktur auf Institutsniveau bedeutet nicht, dass nie Fehler auftreten. Sondern: Wenn Fehler passieren, sind die Regeln für die Behandlung im Voraus festgeschrieben – und die Kosten sind für alle sichtbar.
#dusk
