Zwei Händler im Saddar-Markt in Karachi behaupteten früher beide, sie hätten mir zuerst die gleiche Handyhülle verkauft, und der Ladenbesitzer ging einfach mit dem weiter, der als Erster das Quittungsbuch in die Hand bekommen hatte. Ich dachte, Dusk handhabt konkurrierende Blöcke ähnlich grob: Wer auch immer das Netzwerk zuerst sieht, gewinnt.
Das ist jedoch rückwärts zu dem, wie Fallback tatsächlich funktioniert. Wenn zwei Kandidatenblöcke beide in derselben Runde Konsens erreichen – was durch verzögerte oder verlorene Nachrichten bei Netzwerkstau passieren kann – bevorzugt Dusk nicht denjenigen, der zuerst eintraf. Es bevorzugt denjenigen, der den Konsens bei der niedrigsten Iterationsnummer erreicht hat. Ein Block auf Iteration 5 kann durch einen Block auf Iteration 2 ersetzt werden, wenn der Block mit der niedrigeren Iteration ebenfalls Quorum erreicht. Das Fallback-Verfahren setzt die lokale Kette auf den Zustand direkt vor dem Block mit der höheren Iteration zurück, akzeptiert stattdessen den Block mit der niedrigeren Iteration und verwirft jeden Nachfolger, der auf dem verworfenen Block aufgebaut wurde.
Was meine Denkweise tatsächlich verschoben hat, ist die Ausnahme bei Iteration 0. Ein Block, der bei Iteration 0 Konsens erreicht, kann niemals durch einen Block mit einer niedrigeren Iteration ersetzt werden, weil es keine niedrigere gibt. Er kann zwar später zurückgedreht werden, aber nur, wenn zuerst etwas Upstream von ihm – einer seiner Ahnen – zurückgedreht wird. Daher ist Finalität bei Dusk nicht wirklich etwas, das am Status eines einzelnen Blocks hängt; sie wird von allem vererbt, was darunterliegt.
Was das Whitepaper nicht quantifiziert, ist, wie oft solche Forks tatsächlich auftreten, sobald das Netzwerk unter realer Staukonzentration im Maßstab steht – nicht nur theoretisch.
Hat schon jemand einen echten Fallback-Vorfall bei einem Dusk-Block gesehen?
#dusk $DUSK @Dusk
Das ist jedoch rückwärts zu dem, wie Fallback tatsächlich funktioniert. Wenn zwei Kandidatenblöcke beide in derselben Runde Konsens erreichen – was durch verzögerte oder verlorene Nachrichten bei Netzwerkstau passieren kann – bevorzugt Dusk nicht denjenigen, der zuerst eintraf. Es bevorzugt denjenigen, der den Konsens bei der niedrigsten Iterationsnummer erreicht hat. Ein Block auf Iteration 5 kann durch einen Block auf Iteration 2 ersetzt werden, wenn der Block mit der niedrigeren Iteration ebenfalls Quorum erreicht. Das Fallback-Verfahren setzt die lokale Kette auf den Zustand direkt vor dem Block mit der höheren Iteration zurück, akzeptiert stattdessen den Block mit der niedrigeren Iteration und verwirft jeden Nachfolger, der auf dem verworfenen Block aufgebaut wurde.
Was meine Denkweise tatsächlich verschoben hat, ist die Ausnahme bei Iteration 0. Ein Block, der bei Iteration 0 Konsens erreicht, kann niemals durch einen Block mit einer niedrigeren Iteration ersetzt werden, weil es keine niedrigere gibt. Er kann zwar später zurückgedreht werden, aber nur, wenn zuerst etwas Upstream von ihm – einer seiner Ahnen – zurückgedreht wird. Daher ist Finalität bei Dusk nicht wirklich etwas, das am Status eines einzelnen Blocks hängt; sie wird von allem vererbt, was darunterliegt.
Was das Whitepaper nicht quantifiziert, ist, wie oft solche Forks tatsächlich auftreten, sobald das Netzwerk unter realer Staukonzentration im Maßstab steht – nicht nur theoretisch.
Hat schon jemand einen echten Fallback-Vorfall bei einem Dusk-Block gesehen?
#dusk $DUSK @Dusk
