Ich bin letzte Nacht nochmal durch die <a>$DUSK </a>Dokumentation gegangen, um wirklich herauszufinden, wie gut der Konsens unter Stress standhält. Ich habe mit dem standardmäßigen Block-Production-Mechanismus angefangen, aber vor allem der Fallback- und der Notfall-Mechanismus haben mich zum Nachdenken gebracht.
Wenn etwas Extremes passiert, etwa wenn plötzlich ein großer Teil der Provisionsgeber offline geht, versucht das Netzwerk nicht einfach blind weiter und scheitert dann.
Sobald eine Schwelle von 100 fehlgeschlagenen Iterationen erreicht ist, wird ein Notfallmodus ausgelöst. Standarditerationen werden eingefroren, und es wartet dann auf eine offene Iteration, bis genug Provisionsgeber wieder online sind, um ein Quorum zu erreichen.
Das ist ein solider Sicherheits-Backstop, aber es bringt mich zu der Frage: Wie lange könnte das in einem realen Szenario dauern, und welche Governance-Auswirkungen hätte es, wenn ein paar große Stakeholder die Mehrheit der erforderlichen Anteile halten, um explizit einen Notfallblock anzufordern?
Dann gibt es noch Finalität. Sie verwenden eine rollierende Regel, bei der k=2 aufeinanderfolgende tentative oder nicht bestätigte Blöcke erforderlich sind, damit der Status eines Blocks in Richtung Finalisierung weitergeführt wird. Das wirkt wie eine saubere, logische Art, mit natürlichen Forks umzugehen, die durch Netzwerk-Latenz verursacht werden.
Am meisten überrascht hat mich die Aufteilung der Belohnungen: 10% an den Blockgenerator, 80% an das Abstimmungskomitee und 10% an Dusk. So viel Ertrag an die Wähler zu geben, statt nur an den Blockproduzenten, fühlt sich wie eine sehr bewusste Designentscheidung an, um Dezentralisierung zu fördern.
Hat hier jemand schon mal einen Provisioner auf Testnet betrieben? Wie oft siehst du Forks tatsächlich, bevor die Fallback-Logik sie aufräumt?
#dusk @Dusk
$BTW $HEMI
Wenn etwas Extremes passiert, etwa wenn plötzlich ein großer Teil der Provisionsgeber offline geht, versucht das Netzwerk nicht einfach blind weiter und scheitert dann.
Sobald eine Schwelle von 100 fehlgeschlagenen Iterationen erreicht ist, wird ein Notfallmodus ausgelöst. Standarditerationen werden eingefroren, und es wartet dann auf eine offene Iteration, bis genug Provisionsgeber wieder online sind, um ein Quorum zu erreichen.
Das ist ein solider Sicherheits-Backstop, aber es bringt mich zu der Frage: Wie lange könnte das in einem realen Szenario dauern, und welche Governance-Auswirkungen hätte es, wenn ein paar große Stakeholder die Mehrheit der erforderlichen Anteile halten, um explizit einen Notfallblock anzufordern?
Dann gibt es noch Finalität. Sie verwenden eine rollierende Regel, bei der k=2 aufeinanderfolgende tentative oder nicht bestätigte Blöcke erforderlich sind, damit der Status eines Blocks in Richtung Finalisierung weitergeführt wird. Das wirkt wie eine saubere, logische Art, mit natürlichen Forks umzugehen, die durch Netzwerk-Latenz verursacht werden.
Am meisten überrascht hat mich die Aufteilung der Belohnungen: 10% an den Blockgenerator, 80% an das Abstimmungskomitee und 10% an Dusk. So viel Ertrag an die Wähler zu geben, statt nur an den Blockproduzenten, fühlt sich wie eine sehr bewusste Designentscheidung an, um Dezentralisierung zu fördern.
Hat hier jemand schon mal einen Provisioner auf Testnet betrieben? Wie oft siehst du Forks tatsächlich, bevor die Fallback-Logik sie aufräumt?
#dusk @Dusk
$BTW $HEMI