Wenn sich der Kurs in den frühen Morgenstunden plötzlich stark nach unten bewegt, ist das Gefährlichste nicht, dass ein Trade nur zehn Sekunden zu langsam ausgeführt wird, sondern dass du glaubst, er sei bereits ausgeführt – und das System dir Minuten später sagt: Die betreffende Transaktion gilt nicht.
Das ist auch das zentrale Problem, das mir bei der Fortsetzung des Aufbaus des Konsensmechanismus um @Dusk am meisten am Herzen liegt. Viele öffentliche Ketten werben damit, wie viele Transaktionen sie pro Sekunde verarbeiten können, aber in den Finanzmärkten zählt etwas anderes: In dem Moment, in dem auf dem Bildschirm „abgeschlossen“ angezeigt wird – wurde das Eigentum an den Vermögenswerten wirklich vollständig und unwiderruflich festgelegt?
Ducks Succinct Attestation sorgt nicht dafür, dass ein einzelner Knoten zugleich Blöcke erzeugt und sich selbst bestätigt, sondern teilt jede Runde des Konsenses in drei Türen.
Die erste Tür ist der Vorschlag. Das System wählt aus den Stakern den Blockproduzenten aus. Er ordnet die Transaktionen und sendet einen Kandidatenblock aus.
Die zweite Tür ist die Verifikation. Ein zufällig ausgewähltes Komitee prüft, ob der Block gültig ist, und stimmt über das Ergebnis ab. Hier geht es um die Frage: Können diese Transaktionen in das Ledger aufgenommen werden?
Die dritte Tür ist die Genehmigung. Ein weiteres Komitee bestätigt das Verifikationsergebnis erneut. Sobald die erforderliche Stimmenzahl erreicht ist, entsteht ein Beweis und die endgültige Bestätigung ist abgeschlossen. Anders gesagt: Aufgabenstellen für das Aufstellen, das Korrigieren und die finale Unterschrift werden nicht vollständig von derselben Gruppe übernommen.
Früher fragte ich mich, ob ein dreistufiges Design den Prozess nicht zu schwer macht. Später wurde mir klar, dass Dusk darauf setzt, mit kleineren, zufällig ausgewählten Komitees die Kommunikation im gesamten Netzwerk zu reduzieren – und zugleich zwei unabhängige Bewertungen beizubehalten. Die Website nennt derzeit eine finale Endgültigkeit von etwa 10 Sekunden. Sobald ein Block die Genehmigungsphase durchlaufen hat, ist das Ergebnis deterministisch. Unter normalen Umständen müssen Nutzer nicht mehr Dutzende von Bestätigungen mit zählen, und man muss sich auch keine Sorgen machen, dass ein Reorg eine bereits akzeptierte Ausführung wieder „zurückdreht“.
Das ist besonders wichtig für Finanztransaktionen. Nimm an, der „Asset-Leg“ wird bereits als Abwicklung angezeigt, aber der „Payment-Leg“ schlägt wegen eines Reorgs fehl. Dann steht nicht nur eine einzelne fehlgeschlagene Überweisung an – sondern Eigentumsverhältnisse, Buchhaltungsaufzeichnungen und die Verantwortlichkeiten gegenüber dem Gegenparteirisiko geraten gleichzeitig in Konflikt. Was die deterministische Endgültigkeit wirklich reduziert, ist das Risiko-Fenster nach dem Abschluss, in dem man nicht weiß, ob es am Ende „wirklich gilt“.
Aber auch diese drei Türen bedeuten nicht absolute Sicherheit. Ob die Größe des zufällig ausgewählten Komitees ausreicht, ob Knoten konzentriert sind und ob bei Netzwerkstau eine stabile Endgültigkeit beibehalten werden kann, muss durch langfristige Daten verifiziert werden. So schön das Protokolldesign auch ist – es muss auch Knoten-Ausfälle und extreme Verkehrsaufkommen überstehen.
Darum schaue ich bei $DUSK nicht nur auf die beworbene Zahl „10 Sekunden“. Ich möchte vor allem kontinuierliche Endgültigkeit sehen, die Beteiligungsquote der Komitees und den Anteil an anomalien Runden.
#dusk
Das ist auch das zentrale Problem, das mir bei der Fortsetzung des Aufbaus des Konsensmechanismus um @Dusk am meisten am Herzen liegt. Viele öffentliche Ketten werben damit, wie viele Transaktionen sie pro Sekunde verarbeiten können, aber in den Finanzmärkten zählt etwas anderes: In dem Moment, in dem auf dem Bildschirm „abgeschlossen“ angezeigt wird – wurde das Eigentum an den Vermögenswerten wirklich vollständig und unwiderruflich festgelegt?
Ducks Succinct Attestation sorgt nicht dafür, dass ein einzelner Knoten zugleich Blöcke erzeugt und sich selbst bestätigt, sondern teilt jede Runde des Konsenses in drei Türen.
Die erste Tür ist der Vorschlag. Das System wählt aus den Stakern den Blockproduzenten aus. Er ordnet die Transaktionen und sendet einen Kandidatenblock aus.
Die zweite Tür ist die Verifikation. Ein zufällig ausgewähltes Komitee prüft, ob der Block gültig ist, und stimmt über das Ergebnis ab. Hier geht es um die Frage: Können diese Transaktionen in das Ledger aufgenommen werden?
Die dritte Tür ist die Genehmigung. Ein weiteres Komitee bestätigt das Verifikationsergebnis erneut. Sobald die erforderliche Stimmenzahl erreicht ist, entsteht ein Beweis und die endgültige Bestätigung ist abgeschlossen. Anders gesagt: Aufgabenstellen für das Aufstellen, das Korrigieren und die finale Unterschrift werden nicht vollständig von derselben Gruppe übernommen.
Früher fragte ich mich, ob ein dreistufiges Design den Prozess nicht zu schwer macht. Später wurde mir klar, dass Dusk darauf setzt, mit kleineren, zufällig ausgewählten Komitees die Kommunikation im gesamten Netzwerk zu reduzieren – und zugleich zwei unabhängige Bewertungen beizubehalten. Die Website nennt derzeit eine finale Endgültigkeit von etwa 10 Sekunden. Sobald ein Block die Genehmigungsphase durchlaufen hat, ist das Ergebnis deterministisch. Unter normalen Umständen müssen Nutzer nicht mehr Dutzende von Bestätigungen mit zählen, und man muss sich auch keine Sorgen machen, dass ein Reorg eine bereits akzeptierte Ausführung wieder „zurückdreht“.
Das ist besonders wichtig für Finanztransaktionen. Nimm an, der „Asset-Leg“ wird bereits als Abwicklung angezeigt, aber der „Payment-Leg“ schlägt wegen eines Reorgs fehl. Dann steht nicht nur eine einzelne fehlgeschlagene Überweisung an – sondern Eigentumsverhältnisse, Buchhaltungsaufzeichnungen und die Verantwortlichkeiten gegenüber dem Gegenparteirisiko geraten gleichzeitig in Konflikt. Was die deterministische Endgültigkeit wirklich reduziert, ist das Risiko-Fenster nach dem Abschluss, in dem man nicht weiß, ob es am Ende „wirklich gilt“.
Aber auch diese drei Türen bedeuten nicht absolute Sicherheit. Ob die Größe des zufällig ausgewählten Komitees ausreicht, ob Knoten konzentriert sind und ob bei Netzwerkstau eine stabile Endgültigkeit beibehalten werden kann, muss durch langfristige Daten verifiziert werden. So schön das Protokolldesign auch ist – es muss auch Knoten-Ausfälle und extreme Verkehrsaufkommen überstehen.
Darum schaue ich bei $DUSK nicht nur auf die beworbene Zahl „10 Sekunden“. Ich möchte vor allem kontinuierliche Endgültigkeit sehen, die Beteiligungsquote der Komitees und den Anteil an anomalien Runden.
#dusk
