Dusks Materialien beschreiben "deterministische Abwicklung
als ein Kernmerkmal — sobald eine Transaktion finalisiert ist,
ist sie endgültig, ohne probabilistisches Reorg-Risiko.
Das wird als ein eindeutiger Vorteil dargestellt
gegenüber Chains mit probabilistischer Finalität.
Ich denke, der zugrunde liegende Kompromiss wird dabei übergangen.
Deterministische Finalität ist genau deshalb wertvoll, weil sie
die Phase entfernt, in der man "abwartet, ob das reorged wird".
Aber dieses Zeitfenster zu entfernen, beseitigt auch den natürlichen
Korrekturmechanismus, den Chains mit probabilistischer Finalität
haben, wenn etwas schiefgeht — eine schlechte
Transaktion, ein kompromittierter Schlüssel, ein ausgenutzter Vertrag.
In einer probabilistischen Chain gibt es zumindest ein kurzes
Fenster, in dem offensichtlich betrügerische Aktivitäten
theoretisch angefochten werden könnten, bevor sie tief bestätigt sind.
Deterministische Abwicklung bedeutet, dass es, sobald etwas final ist,
per Design kein Protokoll-gestütztes Rückgängigmachen gibt.
Für regulierte Finanzmärkte ist das oft der richtige Kompromiss
— Institutionen wollen Gewissheit statt Wiederherstellbarkeit,
und bei echten Streitfällen gibt es außerhalb der Chain rechtliche Mittel.
Aber das bedeutet auch, dass die gesamte Last von "eine
schlechte Transaktion gar nicht erst finalisieren lassen" auf
alles verlagert wird, was Transaktionen vor der Finalität überprüft —
dieselbe operative Schicht, bei der Dusk mit seinem eigenen Bridge-
Vorfall gezeigt hat, dass sie ein Schwachpunkt sein kann, getrennt vom Protokollkern.
Deterministische Abwicklung ist eine echte institutionelle Anforderung.
Sie ist auch ein Design, das exakt für die Kategorie operativer Fehler, die Dusk bereits
einmal erlebt hat, null Toleranz hat — allerdings auf der Schicht um das Protokoll herum und nicht im Protokoll selbst.
@Dusk #dusk $DUSK
als ein Kernmerkmal — sobald eine Transaktion finalisiert ist,
ist sie endgültig, ohne probabilistisches Reorg-Risiko.
Das wird als ein eindeutiger Vorteil dargestellt
gegenüber Chains mit probabilistischer Finalität.
Ich denke, der zugrunde liegende Kompromiss wird dabei übergangen.
Deterministische Finalität ist genau deshalb wertvoll, weil sie
die Phase entfernt, in der man "abwartet, ob das reorged wird".
Aber dieses Zeitfenster zu entfernen, beseitigt auch den natürlichen
Korrekturmechanismus, den Chains mit probabilistischer Finalität
haben, wenn etwas schiefgeht — eine schlechte
Transaktion, ein kompromittierter Schlüssel, ein ausgenutzter Vertrag.
In einer probabilistischen Chain gibt es zumindest ein kurzes
Fenster, in dem offensichtlich betrügerische Aktivitäten
theoretisch angefochten werden könnten, bevor sie tief bestätigt sind.
Deterministische Abwicklung bedeutet, dass es, sobald etwas final ist,
per Design kein Protokoll-gestütztes Rückgängigmachen gibt.
Für regulierte Finanzmärkte ist das oft der richtige Kompromiss
— Institutionen wollen Gewissheit statt Wiederherstellbarkeit,
und bei echten Streitfällen gibt es außerhalb der Chain rechtliche Mittel.
Aber das bedeutet auch, dass die gesamte Last von "eine
schlechte Transaktion gar nicht erst finalisieren lassen" auf
alles verlagert wird, was Transaktionen vor der Finalität überprüft —
dieselbe operative Schicht, bei der Dusk mit seinem eigenen Bridge-
Vorfall gezeigt hat, dass sie ein Schwachpunkt sein kann, getrennt vom Protokollkern.
Deterministische Abwicklung ist eine echte institutionelle Anforderung.
Sie ist auch ein Design, das exakt für die Kategorie operativer Fehler, die Dusk bereits
einmal erlebt hat, null Toleranz hat — allerdings auf der Schicht um das Protokoll herum und nicht im Protokoll selbst.
@Dusk #dusk $DUSK