die Dämmerungs-Details, zu denen ich immer wieder zurückkam, waren: Ein Block kann eine Success-Attestation haben und dennoch nicht final sein.
Mein erster Blick auf „Succinct Attestation“ war einfacher.
Ein Vorschlag landet.
Die Validations erreichen eine Supermajorität an gültigen Stimmen.
Die Ratifikation bestätigt das.
Aggregierte BLS-Signaturen beweisen das Quorum.
Ist das nicht genug?
Nicht ganz.
Dusk’ Abschnitt zu der rollierenden Finalität teilt einen Block in akzeptiert, attestiert, bestätigt und final.
Wenn ein Block in Iteration I > 0 erzeugt wird, während eine frühere Iteration noch keine Fail-Attestation hat, kann er eine Success-Attestation tragen und wird nur als akzeptiert markiert.
Denn „das Komitee erreichte das Quorum“ klingt sehr nah an „dieser Block kann nicht verschwinden“.
Beides sind bei Dusk unterschiedliche Aussagen.
Die ungelöste frühere Iteration ist weiterhin relevant. Wenn ein Block mit niedrigerer Iteration später Einigkeit erreicht, kann ein Fallback den akzeptierten Block ersetzen und dessen Nachfolger verwerfen.
Also belegt die Success-Attestation, dass Einigkeit passiert ist.
Sie beweist jedoch nicht immer, dass die Kette das Auswählen abgeschlossen hat.
Ein attestierter Block landet entweder in Iteration 0 oder hat Fail-Attestationen, die jede frühere Iteration abdecken, sodass kein Block mit niedrigerer Iteration ihn direkt ersetzen kann. Bestätigt hängt von späteren Blöcken ab. Final wird erst erreicht, wenn der Block bestätigt ist und sein Vorgänger bereits final ist.
Das hat „Finalität in Sekunden“ für mich weniger nach einem einzelnen Ereignis wirken lassen und eher nach einer Grenze, die eine Anwendung korrekt lesen muss.
Eine Anwendung auf Dusk fragt nicht nur, ob Konsens etwas unterschrieben hat.
Sicherheiten freigeben?
Eine Sicherheitsübertragung erkennen?
Lass einen anderen Vertrag den Zustand als unumkehrbar behandeln?
Das verdient möglicherweise nicht dieselbe Schwelle.
Meistens passiert das wohl schnell. in Ordnung
Der Randfall ist es, der mich interessiert: Ein Block wirkt erfolgreich, eine Anwendung reagiert darauf, und eine niedrigere Iteration ist immer noch am Leben.
Dusk versteckt diese Lücke nicht. Es benennt sie.
Akzeptiert ist nicht final.
Und als ich das bemerkte, änderte sich meine Integrationsfrage.
Nicht: „Hat der Konsens Erfolg gehabt?“
Wie unumkehrbar muss dieser Anwendung Dusk erscheinen, bevor sie handelt?
@Dusk $DUSK #Dusk $ACE $APR
Mein erster Blick auf „Succinct Attestation“ war einfacher.
Ein Vorschlag landet.
Die Validations erreichen eine Supermajorität an gültigen Stimmen.
Die Ratifikation bestätigt das.
Aggregierte BLS-Signaturen beweisen das Quorum.
Ist das nicht genug?
Nicht ganz.
Dusk’ Abschnitt zu der rollierenden Finalität teilt einen Block in akzeptiert, attestiert, bestätigt und final.
Wenn ein Block in Iteration I > 0 erzeugt wird, während eine frühere Iteration noch keine Fail-Attestation hat, kann er eine Success-Attestation tragen und wird nur als akzeptiert markiert.
Denn „das Komitee erreichte das Quorum“ klingt sehr nah an „dieser Block kann nicht verschwinden“.
Beides sind bei Dusk unterschiedliche Aussagen.
Die ungelöste frühere Iteration ist weiterhin relevant. Wenn ein Block mit niedrigerer Iteration später Einigkeit erreicht, kann ein Fallback den akzeptierten Block ersetzen und dessen Nachfolger verwerfen.
Also belegt die Success-Attestation, dass Einigkeit passiert ist.
Sie beweist jedoch nicht immer, dass die Kette das Auswählen abgeschlossen hat.
Ein attestierter Block landet entweder in Iteration 0 oder hat Fail-Attestationen, die jede frühere Iteration abdecken, sodass kein Block mit niedrigerer Iteration ihn direkt ersetzen kann. Bestätigt hängt von späteren Blöcken ab. Final wird erst erreicht, wenn der Block bestätigt ist und sein Vorgänger bereits final ist.
Das hat „Finalität in Sekunden“ für mich weniger nach einem einzelnen Ereignis wirken lassen und eher nach einer Grenze, die eine Anwendung korrekt lesen muss.
Eine Anwendung auf Dusk fragt nicht nur, ob Konsens etwas unterschrieben hat.
Sicherheiten freigeben?
Eine Sicherheitsübertragung erkennen?
Lass einen anderen Vertrag den Zustand als unumkehrbar behandeln?
Das verdient möglicherweise nicht dieselbe Schwelle.
Meistens passiert das wohl schnell. in Ordnung
Der Randfall ist es, der mich interessiert: Ein Block wirkt erfolgreich, eine Anwendung reagiert darauf, und eine niedrigere Iteration ist immer noch am Leben.
Dusk versteckt diese Lücke nicht. Es benennt sie.
Akzeptiert ist nicht final.
Und als ich das bemerkte, änderte sich meine Integrationsfrage.
Nicht: „Hat der Konsens Erfolg gehabt?“
Wie unumkehrbar muss dieser Anwendung Dusk erscheinen, bevor sie handelt?
@Dusk $DUSK #Dusk $ACE $APR
SELECTIVE DISCLOSURE
0%
DUSKVM
0%
DUSK'S MOONLIGHT
100%
DUSK'S PHOENIX
0%
1 Stimmen • Abstimmung beendet