#dusk $DUSK Denke immer noch über diese Frage zur Settlement-Timing vor ein paar Tagen nach. Also habe ich nach einer echten Antwort gesucht, statt es einfach offen zu lassen – und ehrlich? 😂 Turns out: Dusk’s Base Layer hat dafür ein ganzes benanntes System.
Also der Konsens bei DuskDs läuft jede Runde über drei Phasen, genannt „succinct attestation“. Ein Komitee wird durch deterministische Sortition ausgewählt, gewichtet nach Stake: erst eine Proposal-Phase, in der ein Kandidaten-Block erzeugt wird, dann eine Validation-Phase, in der die Komiteemitglieder darüber abstimmen, ob er wirklich gültig ist, und dann eine Ratification-Phase, in der sie erneut abstimmen, um dieses Ergebnis zu finalisieren und dabei ein Quorum zu erzeugen, wenn genug zustimmen. Was mir aber aufgefallen ist: Wenn ein Block diese drei Phasen durchläuft, ist das noch nicht das Ende der Geschichte.
Es gibt vier benannte Finalitätszustände. „accepted“ bedeutet, er hat die drei Schritte in dieser Runde geschafft. „confirmed“ heißt, dass spätere Blöcke nun darauf aufbauen. „stable“ bedeutet, er ist tief genug begraben, um probabilistisch nicht mehr umkehrbar zu sein. Und „final“ heißt: deterministisch, kryptografisch garantiert – und er kann buchstäblich nicht rückgängig gemacht werden.
Was ich seit dem Finden davon immer wieder im Kopf habe, ist: Das beantwortet tatsächlich einen Teil dessen, woran ich bei DuskEVM Settlement-Timing festhing. Apps haben vier echte, benannte Checkpoints, gegen die sie bauen können, statt nur anhand von verstrichener Zeit zu raten. Aber es wirft auch eine neue Frage auf: Welcher von diesen vier Zuständen ist für einen bestimmten Use Case wirklich gut genug? Braucht eine regulierte Finanz-App, bis „true final“ gewartet wird – oder ist „stable“ in der Praxis für die meisten Transaktionen ausreichend?
Trotzdem: eine explizite Abstufung mit echten Namen statt eines vagen Gefühls für Bestätigungen ist eine wirklich nützliche Design-Entscheidung für jeden, der darauf aufbaut.
Ehrlich gesagt: weiß nicht, ob die meisten Apps am Ende auf „voll final“ warten oder ob „stable“ zum praktischen Default wird, auf den alle sich einigen??
🤔
#dusk @Dusk $DUSK
Also der Konsens bei DuskDs läuft jede Runde über drei Phasen, genannt „succinct attestation“. Ein Komitee wird durch deterministische Sortition ausgewählt, gewichtet nach Stake: erst eine Proposal-Phase, in der ein Kandidaten-Block erzeugt wird, dann eine Validation-Phase, in der die Komiteemitglieder darüber abstimmen, ob er wirklich gültig ist, und dann eine Ratification-Phase, in der sie erneut abstimmen, um dieses Ergebnis zu finalisieren und dabei ein Quorum zu erzeugen, wenn genug zustimmen. Was mir aber aufgefallen ist: Wenn ein Block diese drei Phasen durchläuft, ist das noch nicht das Ende der Geschichte.
Es gibt vier benannte Finalitätszustände. „accepted“ bedeutet, er hat die drei Schritte in dieser Runde geschafft. „confirmed“ heißt, dass spätere Blöcke nun darauf aufbauen. „stable“ bedeutet, er ist tief genug begraben, um probabilistisch nicht mehr umkehrbar zu sein. Und „final“ heißt: deterministisch, kryptografisch garantiert – und er kann buchstäblich nicht rückgängig gemacht werden.
Was ich seit dem Finden davon immer wieder im Kopf habe, ist: Das beantwortet tatsächlich einen Teil dessen, woran ich bei DuskEVM Settlement-Timing festhing. Apps haben vier echte, benannte Checkpoints, gegen die sie bauen können, statt nur anhand von verstrichener Zeit zu raten. Aber es wirft auch eine neue Frage auf: Welcher von diesen vier Zuständen ist für einen bestimmten Use Case wirklich gut genug? Braucht eine regulierte Finanz-App, bis „true final“ gewartet wird – oder ist „stable“ in der Praxis für die meisten Transaktionen ausreichend?
Trotzdem: eine explizite Abstufung mit echten Namen statt eines vagen Gefühls für Bestätigungen ist eine wirklich nützliche Design-Entscheidung für jeden, der darauf aufbaut.
Ehrlich gesagt: weiß nicht, ob die meisten Apps am Ende auf „voll final“ warten oder ob „stable“ zum praktischen Default wird, auf den alle sich einigen??
🤔
#dusk @Dusk $DUSK