Eine Zollabfertigung, die ich im Hafen von Karachi verfolgt habe, hing drei Tage lang im Status „in Prüfung“ fest, bevor sie auf dem Portal ohne Zwischenstufen direkt zu „freigegeben“ sprang. Ich hatte erwartet, dass Dusk-Blockendgültigkeit genauso funktioniert: erst dann final, dann final bestätigen – ein einziger Sprung. So funktioniert „rolling finality“ jedoch überhaupt nicht.
Es gibt vier klar unterscheidbare Zustände, durch die ein Block läuft, und der Sprung zwischen ihnen hängt vollständig davon ab, was in den vorherigen Iterationen passiert ist. Ein Block startet als „attested“, wenn in dieser Runde null vorherige Iterationen fehlgeschlagen sind, d. h. kein anderer Kandidat konnte ihn theoretisch schneller zum Konsens bringen. Wenn irgendeine vorherige Iteration fehlschlug, ohne dass es eine Fail-Attestation gab, startet er stattdessen als „accepted“ – das bedeutet, dass theoretisch ein Block aus einer niedrigeren Iteration ihn noch ersetzen könnte.
Der Teil, der meine Sicht wirklich verändert hat, ist, dass „confirmed“ und „final“ nicht wirklich etwas über den Block selbst aussagen. Ein „attested“-Block wird „confirmed“, sobald ein einzelner Nachfolger attestiert oder bestätigt ist. Ein „accepted“-Block hingegen benötigt 2-mal n aufeinanderfolgende attestierte oder bestätigte Blöcke, die direkt auf ihm gestapelt sind, wobei n die Anzahl der nicht attestierten vorherigen Iterationen ist. So können zwei ähnlich alte Blöcke völlig unterschiedliche Zeitspannen brauchen, um dasselbe Vertrauensniveau zu erreichen – abhängig allein davon, wie „sauber“ ihre Iterationshistorie war.
Was mir das Whitepaper nicht liefert, ist eine echte durchschnittliche Zeitspanne, in Sekunden oder in Blöcken, dafür, wie lange es auf Live-Dusk-Infrastruktur dauert, von „accepted“ zu „final“ zu gelangen. Diese Zahl kann ich nicht einfach herleiten.
Der eigentliche Test für DUSK ist, ob dieser variable Pfad zur Finalität sich immer noch schnell genug anfühlt für alltägliche Nutzer, die Gelder bewegen.
Hat irgendjemand verfolgt, wie lange eine echte Transaktion gebraucht hat, um auf Dusk den Status „final“ zu erreichen?
#dusk $DUSK @Dusk
Es gibt vier klar unterscheidbare Zustände, durch die ein Block läuft, und der Sprung zwischen ihnen hängt vollständig davon ab, was in den vorherigen Iterationen passiert ist. Ein Block startet als „attested“, wenn in dieser Runde null vorherige Iterationen fehlgeschlagen sind, d. h. kein anderer Kandidat konnte ihn theoretisch schneller zum Konsens bringen. Wenn irgendeine vorherige Iteration fehlschlug, ohne dass es eine Fail-Attestation gab, startet er stattdessen als „accepted“ – das bedeutet, dass theoretisch ein Block aus einer niedrigeren Iteration ihn noch ersetzen könnte.
Der Teil, der meine Sicht wirklich verändert hat, ist, dass „confirmed“ und „final“ nicht wirklich etwas über den Block selbst aussagen. Ein „attested“-Block wird „confirmed“, sobald ein einzelner Nachfolger attestiert oder bestätigt ist. Ein „accepted“-Block hingegen benötigt 2-mal n aufeinanderfolgende attestierte oder bestätigte Blöcke, die direkt auf ihm gestapelt sind, wobei n die Anzahl der nicht attestierten vorherigen Iterationen ist. So können zwei ähnlich alte Blöcke völlig unterschiedliche Zeitspannen brauchen, um dasselbe Vertrauensniveau zu erreichen – abhängig allein davon, wie „sauber“ ihre Iterationshistorie war.
Was mir das Whitepaper nicht liefert, ist eine echte durchschnittliche Zeitspanne, in Sekunden oder in Blöcken, dafür, wie lange es auf Live-Dusk-Infrastruktur dauert, von „accepted“ zu „final“ zu gelangen. Diese Zahl kann ich nicht einfach herleiten.
Der eigentliche Test für DUSK ist, ob dieser variable Pfad zur Finalität sich immer noch schnell genug anfühlt für alltägliche Nutzer, die Gelder bewegen.
Hat irgendjemand verfolgt, wie lange eine echte Transaktion gebraucht hat, um auf Dusk den Status „final“ zu erreichen?
#dusk $DUSK @Dusk
