Ich dachte früher, dass eine Epochen-Grenze in Dusk größtenteils ein Zeitereignis ist – eine Epoche endet, eine andere beginnt.
Wenn ich genauer hinschaue, glaube ich, dass diese Formulierung eine wichtige System-Einschränkung verfehlt.
Eine Epoche ändert den Zustand, anhand dessen die Eignung von Provisionern bewertet wird, während der Konsens weiterhin innerhalb einer begrenzten Menge an Rechenaufwand arbeiten muss. Das macht die Grenze mehr als ein Kalenderzeichen: Es ist ein Punkt, an dem sich der Teilnahmezustand ändern kann, ohne dass die Konsensarbeit unbegrenzt wachsen darf.
Die technische Kette, die ich interessant finde, ist:
epochen-Übergang → Eignungszustand ändert sich → Konsens bewertet den neuen Zustand → die Berechnung bleibt begrenzt.
Das führt zu einem subtilen Trade-off.
Wenn Änderungen an Stake oder Eignung den Konsens sofort und ohne klare Grenzen beeinflussen dürften, könnten Knoten vor komplexere Zustandsübergänge gestellt werden. Wenn Änderungen durch Bedingungen der Epoche eingeschränkt werden, erhält das Protokoll ein saubereres Zustandsmodell, aber die Teilnahmeänderungen werden weniger unmittelbar.
Was mich überrascht hat, ist, dass Zeitsegmentierung und Rechenlimits unterschiedliche Probleme lösen können, während sie sich gleichzeitig gegenseitig verstärken.
Eine Epoche beantwortet die Frage, wann sich der Konsenszustand ändern kann.
Ein begrenzter iterativer Prozess beantwortet, wie viel Arbeit der Konsens ausführen darf.
Die offene Frage lautet: Wenn sich die Provisioner-Menge eines Netzwerks schneller ändert, wie sollte die Epochenlänge zwischen Stabilität des Zustands und Reaktionsfähigkeit abwägen?
@Dusk_Foundation $DUSK #dusk
Wenn ich genauer hinschaue, glaube ich, dass diese Formulierung eine wichtige System-Einschränkung verfehlt.
Eine Epoche ändert den Zustand, anhand dessen die Eignung von Provisionern bewertet wird, während der Konsens weiterhin innerhalb einer begrenzten Menge an Rechenaufwand arbeiten muss. Das macht die Grenze mehr als ein Kalenderzeichen: Es ist ein Punkt, an dem sich der Teilnahmezustand ändern kann, ohne dass die Konsensarbeit unbegrenzt wachsen darf.
Die technische Kette, die ich interessant finde, ist:
epochen-Übergang → Eignungszustand ändert sich → Konsens bewertet den neuen Zustand → die Berechnung bleibt begrenzt.
Das führt zu einem subtilen Trade-off.
Wenn Änderungen an Stake oder Eignung den Konsens sofort und ohne klare Grenzen beeinflussen dürften, könnten Knoten vor komplexere Zustandsübergänge gestellt werden. Wenn Änderungen durch Bedingungen der Epoche eingeschränkt werden, erhält das Protokoll ein saubereres Zustandsmodell, aber die Teilnahmeänderungen werden weniger unmittelbar.
Was mich überrascht hat, ist, dass Zeitsegmentierung und Rechenlimits unterschiedliche Probleme lösen können, während sie sich gleichzeitig gegenseitig verstärken.
Eine Epoche beantwortet die Frage, wann sich der Konsenszustand ändern kann.
Ein begrenzter iterativer Prozess beantwortet, wie viel Arbeit der Konsens ausführen darf.
Die offene Frage lautet: Wenn sich die Provisioner-Menge eines Netzwerks schneller ändert, wie sollte die Epochenlänge zwischen Stabilität des Zustands und Reaktionsfähigkeit abwägen?
@Dusk_Foundation $DUSK #dusk