Nach dem Maghreb habe ich angefangen, in Dusk-Consensus-Notizen zu graben, und bin immer wieder zu der stillen statistischen Lücke zurückgekehrt, die dort beharrlich sitzt. @Dusk
Das Design der Succinct Attestation zielt auf deterministische Finalität ab. Sobald ein Block ratifiziert ist, wird er unter normalen Bedingungen als final behandelt, und das Protokoll sagt, dass es im gewöhnlichen Betrieb keine Reorgs geben sollte, die sich für Nutzer bemerkbar machen.
Gabelungen können jedoch weiterhin auftreten, wenn Verzögerungen oder Überlastungen dazu führen, dass mehr als eine Iteration in derselben Runde den Konsens erreicht. Die offizielle Regel ist einfach: Halte den Block aus der niedrigsten Iteration fest und verwerfe die anderen. Es gibt außerdem eine rollierende Finalität – ein Block wird zunächst als akzeptiert betrachtet, kann noch ersetzt werden, solange er nur attestiert wurde, und wird erst dann unveränderlich, wenn spätere Blöcke ihn bestätigen.
Der statistische Punkt ist der, an dem ich hängen geblieben bin. 3 Gabelungen in 1.000 Versuchen sehen genauso aus wie 300 Gabelungen in 100.000 Versuchen, wenn man nur die rohe Rate betrachtet. Ohne Standardfehler und 95%-Konfidenzintervalle kann man nicht erkennen, ob die Schätzung stabil ist oder nur Rauschen. Für korrektes Testen braucht man große Stichprobenumfänge, etwa die vorgeschlagenen 100.000 zufälligen Validator-Delay-Profile und mehrere Latenzmuster – nicht nur ein einziges freundliches Netzmodell.
Die offiziellen Dokumente beschreiben die Fork-Regeln und behaupten Finalität mit niedriger Latenz. Sie veröffentlichen jedoch keine großskaligen Ergebnisse mit Konfidenzintervallen unter verzerrten oder unfreundlichen Verzögerungen.
Diese statistische Lücke war schwerer zu ignorieren, als ich erwartet hatte. Eine niedrige beobachtete Fork-Rate ist nützlich. Zu wissen, wie unsicher diese Rate ist, wenn das Netzwerk chaotisch wird, ist es, was tatsächlich Vertrauen aufbaut. Ich kaufe mir immer noch die Frage, ob diese statistische Ebene in den öffentlichen Materialien sichtbar sein wird.
#dusk $DUSK
Das Design der Succinct Attestation zielt auf deterministische Finalität ab. Sobald ein Block ratifiziert ist, wird er unter normalen Bedingungen als final behandelt, und das Protokoll sagt, dass es im gewöhnlichen Betrieb keine Reorgs geben sollte, die sich für Nutzer bemerkbar machen.
Gabelungen können jedoch weiterhin auftreten, wenn Verzögerungen oder Überlastungen dazu führen, dass mehr als eine Iteration in derselben Runde den Konsens erreicht. Die offizielle Regel ist einfach: Halte den Block aus der niedrigsten Iteration fest und verwerfe die anderen. Es gibt außerdem eine rollierende Finalität – ein Block wird zunächst als akzeptiert betrachtet, kann noch ersetzt werden, solange er nur attestiert wurde, und wird erst dann unveränderlich, wenn spätere Blöcke ihn bestätigen.
Der statistische Punkt ist der, an dem ich hängen geblieben bin. 3 Gabelungen in 1.000 Versuchen sehen genauso aus wie 300 Gabelungen in 100.000 Versuchen, wenn man nur die rohe Rate betrachtet. Ohne Standardfehler und 95%-Konfidenzintervalle kann man nicht erkennen, ob die Schätzung stabil ist oder nur Rauschen. Für korrektes Testen braucht man große Stichprobenumfänge, etwa die vorgeschlagenen 100.000 zufälligen Validator-Delay-Profile und mehrere Latenzmuster – nicht nur ein einziges freundliches Netzmodell.
Die offiziellen Dokumente beschreiben die Fork-Regeln und behaupten Finalität mit niedriger Latenz. Sie veröffentlichen jedoch keine großskaligen Ergebnisse mit Konfidenzintervallen unter verzerrten oder unfreundlichen Verzögerungen.
Diese statistische Lücke war schwerer zu ignorieren, als ich erwartet hatte. Eine niedrige beobachtete Fork-Rate ist nützlich. Zu wissen, wie unsicher diese Rate ist, wenn das Netzwerk chaotisch wird, ist es, was tatsächlich Vertrauen aufbaut. Ich kaufe mir immer noch die Frage, ob diese statistische Ebene in den öffentlichen Materialien sichtbar sein wird.
#dusk $DUSK