#dusk $DUSK @Dusk
ursprünglich dachte ich, ein Block sei entweder final oder eben nicht, eine einzige klare Zeile.
die rollierende Finalität ließ mich das überdenken.
der tatsächliche Mechanismus geht vom Chain-Tip rückwärts bis zum letzten finalisierten Block, indem er die Stakes der Provisor-Bezahler hinter Timeout und die dabei gewonnenen Zertifikate mitzählt. sobald diese laufende Summe an irgendeinem Zwischenblock H 67% des gesamten Stakes erreicht, wird H als final markiert, rückwirkend.
das ist keine einzelne Abstimmung, die irgendetwas entscheidet. das ist eine Schwelle auf Basis von kumuliertem Stake, die über eine Reihe von Blöcken hinweg geprüft wird – nicht in genau einem Moment.
ich habe nachverfolgt, warum ein System mit nur einer Stimme dieselbe Garantie nicht bieten kann. eine Stimme, selbst wenn sie entscheidend ist, beweist nur, was ein Teil des Netzwerks in genau diesem Moment dachte. sie berücksichtigt nicht, was passiert, wenn der Tip selbst nie finalisiert, oder wenn Kandidaten mit geringerer Iteration noch immer offene Ansprüche hinter sich haben.
die eigenen Engineering-Notizen von Dusk bestätigen außerdem, dass sich das kürzlich geändert hat – von einer festen Nachfolgeranzahl zu einer variablen, je nachdem, wie viele nicht attestierte Kandidaten mit geringerer Iteration es in derselben Runde gab. die Schwelle ist nicht statisch; sie passt sich an, wie chaotisch diese konkrete Runde tatsächlich war.
also schützt die rollierende Finalität nicht vor einer einzigen schlechten Stimme. sie schützt vor der Lücke zwischen dem Eindruck, etwas sei geklärt, und der tatsächlichen Ansammlung genügend gewichteter Bestätigung, um unumkehrbar zu werden.
fühlt sich eine rückwirkende Schwelle von 67% Stake wie eine stärkere Garantie an als eine einzelne entscheidende Stimme – oder verlagert die Komplexität die Unsicherheit nur an eine andere Stelle, wo sie sich versteckt??
$RE
$HEMI
ursprünglich dachte ich, ein Block sei entweder final oder eben nicht, eine einzige klare Zeile.
die rollierende Finalität ließ mich das überdenken.
der tatsächliche Mechanismus geht vom Chain-Tip rückwärts bis zum letzten finalisierten Block, indem er die Stakes der Provisor-Bezahler hinter Timeout und die dabei gewonnenen Zertifikate mitzählt. sobald diese laufende Summe an irgendeinem Zwischenblock H 67% des gesamten Stakes erreicht, wird H als final markiert, rückwirkend.
das ist keine einzelne Abstimmung, die irgendetwas entscheidet. das ist eine Schwelle auf Basis von kumuliertem Stake, die über eine Reihe von Blöcken hinweg geprüft wird – nicht in genau einem Moment.
ich habe nachverfolgt, warum ein System mit nur einer Stimme dieselbe Garantie nicht bieten kann. eine Stimme, selbst wenn sie entscheidend ist, beweist nur, was ein Teil des Netzwerks in genau diesem Moment dachte. sie berücksichtigt nicht, was passiert, wenn der Tip selbst nie finalisiert, oder wenn Kandidaten mit geringerer Iteration noch immer offene Ansprüche hinter sich haben.
die eigenen Engineering-Notizen von Dusk bestätigen außerdem, dass sich das kürzlich geändert hat – von einer festen Nachfolgeranzahl zu einer variablen, je nachdem, wie viele nicht attestierte Kandidaten mit geringerer Iteration es in derselben Runde gab. die Schwelle ist nicht statisch; sie passt sich an, wie chaotisch diese konkrete Runde tatsächlich war.
also schützt die rollierende Finalität nicht vor einer einzigen schlechten Stimme. sie schützt vor der Lücke zwischen dem Eindruck, etwas sei geklärt, und der tatsächlichen Ansammlung genügend gewichteter Bestätigung, um unumkehrbar zu werden.
fühlt sich eine rückwirkende Schwelle von 67% Stake wie eine stärkere Garantie an als eine einzelne entscheidende Stimme – oder verlagert die Komplexität die Unsicherheit nur an eine andere Stelle, wo sie sich versteckt??
$RE
$HEMI