Viele Menschen denken bei „Endgültigkeit“ sofort an „Wie viele Blöcke muss man abhaken, bis man nicht mehr ändern kann?“, also an das Konzept eines Alles-oder-Nichts, einer Art One-Cut-Policy. Nachdem ich das Design der „rolling finality“ von Dusk gelesen habe, wurde mir klar, dass diese Vorstellung zu grob ist.
Es teilt den Blockzustand in vier Stufen ein: accepted, attested, confirmed, final. Es geht nicht strikt schwarz-weiß nach oben, sondern schrittweise. Blöcke aus niedrigeren Runden können, falls es ihnen nicht gelingt, genug „Fehlnachweise“ zusammenzubekommen, noch durch spätere Blöcke ersetzt werden. Mit zunehmender Anzahl bestätigender Blöcke türmt sich die Bestätigung jedoch immer weiter auf, und die Wahrscheinlichkeit von Forks sinkt exponentiell. Am Ende wird der Zustand in eine irreversible „final“-Phase „eingeschlossen“.
Im Kern quantifiziert dieses Design die Frage „Wie lange muss man warten, bis man sich sicher fühlen kann?“ als eine Kurve – statt als eine feste Zahl.
Was mich besonders interessiert, ist, wie es Spekulation verhindert – zum Beispiel indem jemand absichtlich in dieser Runde nicht mitmacht, um später die Blockierungsprämien aus den nachfolgenden Runden „aufzusammeln“. Das Protokoll baut dafür mehrere Gegenmaßnahmen ein: Abstimmungsanreize, zusätzliche Punkte und den Ausschluss von der Berechtigung, in der nächsten Runde selbst Blöcke zu produzieren. Dazu kommt eine Obergrenze für die Iterationsanzahl. Damit werden die Lücken aus der Spieltheorie nach und nach geschlossen – nicht einfach nur durch Strafen.
Allerdings werde ich je tiefer man in die Details schaut, desto skeptischer: Dieses Mechanismus-Design setzt voraus, dass die Komiteegröße groß genug und die Netzwerkkommunikation schnell genug ist. Falls es eines Tages zu Netzwerktrennungen kommt oder die Verzögerungen in der Nachrichtenübertragung deutlich länger werden: Würde die Annahme „bestätigende Blöcke akkumulieren sich schnell“ dann nicht bereits zuerst zusammenbrechen? Ob sich Sekunden-Endgültigkeit und Robustheit unter extremen Netzwerkbedingungen tatsächlich gleichzeitig erreichen lassen, kann ich derzeit nicht mit Antworten sehen, die mich vollständig überzeugen.
@Dusk #dusk $DUSK
Es teilt den Blockzustand in vier Stufen ein: accepted, attested, confirmed, final. Es geht nicht strikt schwarz-weiß nach oben, sondern schrittweise. Blöcke aus niedrigeren Runden können, falls es ihnen nicht gelingt, genug „Fehlnachweise“ zusammenzubekommen, noch durch spätere Blöcke ersetzt werden. Mit zunehmender Anzahl bestätigender Blöcke türmt sich die Bestätigung jedoch immer weiter auf, und die Wahrscheinlichkeit von Forks sinkt exponentiell. Am Ende wird der Zustand in eine irreversible „final“-Phase „eingeschlossen“.
Im Kern quantifiziert dieses Design die Frage „Wie lange muss man warten, bis man sich sicher fühlen kann?“ als eine Kurve – statt als eine feste Zahl.
Was mich besonders interessiert, ist, wie es Spekulation verhindert – zum Beispiel indem jemand absichtlich in dieser Runde nicht mitmacht, um später die Blockierungsprämien aus den nachfolgenden Runden „aufzusammeln“. Das Protokoll baut dafür mehrere Gegenmaßnahmen ein: Abstimmungsanreize, zusätzliche Punkte und den Ausschluss von der Berechtigung, in der nächsten Runde selbst Blöcke zu produzieren. Dazu kommt eine Obergrenze für die Iterationsanzahl. Damit werden die Lücken aus der Spieltheorie nach und nach geschlossen – nicht einfach nur durch Strafen.
Allerdings werde ich je tiefer man in die Details schaut, desto skeptischer: Dieses Mechanismus-Design setzt voraus, dass die Komiteegröße groß genug und die Netzwerkkommunikation schnell genug ist. Falls es eines Tages zu Netzwerktrennungen kommt oder die Verzögerungen in der Nachrichtenübertragung deutlich länger werden: Würde die Annahme „bestätigende Blöcke akkumulieren sich schnell“ dann nicht bereits zuerst zusammenbrechen? Ob sich Sekunden-Endgültigkeit und Robustheit unter extremen Netzwerkbedingungen tatsächlich gleichzeitig erreichen lassen, kann ich derzeit nicht mit Antworten sehen, die mich vollständig überzeugen.
@Dusk #dusk $DUSK
秒级最终性够用了,鲁棒性问题是过度担心
0%
极端网络条件没验证过,我持保留态度
0%
更想看到真实的分叉/攻击场景压力测试数据
0%
0 Stimmen • Abstimmung beendet