#dusk $DUSK @Dusk
Dusk's Rollend-„Finality“-Mechanismus hat sich kürzlich von der Zählung einer festen Anzahl aufeinanderfolgender nachgewiesener Blöcke auf eine variable Anzahl verlagert, die darauf basiert, wie viele Kandidaten mit geringerer Priorität im selben Durchlauf nicht zur Attestierung gelangt sind. Ich habe das zweimal gelesen.
Die meisten Leute nehmen an, dass „vertrauenslos“ bedeutet: Ein System, das nie angepasst werden musste — die Mathematik funktioniert entweder oder eben nicht, dauerhaft.
Mein erster Eindruck passte zu dieser Annahme. Wenn Konsens wirklich vertrauenslos ist, warum müsste dann der konkrete Mechanismus, der die Finalität bestimmt, nach dem Launch überhaupt geändert werden?
Dann habe ich mir angesehen, was diese Änderung tatsächlich offenbart. Das eigene Engineering-Update von Dusk beschreibt diese Verschiebung als eine Verbesserung, wie das Netzwerk mit chaotischen Durchläufen umgeht — Durchläufe, in denen mehrere Kandidaten ohne saubere Auflösung konkurrierten. Das ist kein Bugfix für kaputte Mathematik. Es ist ein Hinweis darauf, dass das ursprüngliche Threshold-Design Annahmen über typische Netzwerkbedingungen traf — Annahmen, die überdacht werden mussten, als sich herausstellte, dass reale Durchläufe chaotischer waren, als das Anfangsdesign es vorgesehen hatte.
Dieser Unterschied ist wichtiger, als er klingt. Ein wirklich annahmenfreies System bräuchte keine Logik der zweiten Version, um Edge Cases zu behandeln, die es angeblich bereits abgedeckt hat.
Wo ich letztlich lande: Konsensmechanismen werden nicht einfach „vertrauenslos“ und bleiben dann dauerhaft dort. Sie kommen ihm näher durch Iterationen, die offenlegen, welche Annahmen das ursprüngliche Design nicht vollständig berücksichtigt hat — und das Rolling-Finality-Update von Dusk ist ein dokumentiertes Beispiel dafür, wie genau das passiert.
Dusk's Rollend-„Finality“-Mechanismus hat sich kürzlich von der Zählung einer festen Anzahl aufeinanderfolgender nachgewiesener Blöcke auf eine variable Anzahl verlagert, die darauf basiert, wie viele Kandidaten mit geringerer Priorität im selben Durchlauf nicht zur Attestierung gelangt sind. Ich habe das zweimal gelesen.
Die meisten Leute nehmen an, dass „vertrauenslos“ bedeutet: Ein System, das nie angepasst werden musste — die Mathematik funktioniert entweder oder eben nicht, dauerhaft.
Mein erster Eindruck passte zu dieser Annahme. Wenn Konsens wirklich vertrauenslos ist, warum müsste dann der konkrete Mechanismus, der die Finalität bestimmt, nach dem Launch überhaupt geändert werden?
Dann habe ich mir angesehen, was diese Änderung tatsächlich offenbart. Das eigene Engineering-Update von Dusk beschreibt diese Verschiebung als eine Verbesserung, wie das Netzwerk mit chaotischen Durchläufen umgeht — Durchläufe, in denen mehrere Kandidaten ohne saubere Auflösung konkurrierten. Das ist kein Bugfix für kaputte Mathematik. Es ist ein Hinweis darauf, dass das ursprüngliche Threshold-Design Annahmen über typische Netzwerkbedingungen traf — Annahmen, die überdacht werden mussten, als sich herausstellte, dass reale Durchläufe chaotischer waren, als das Anfangsdesign es vorgesehen hatte.
Dieser Unterschied ist wichtiger, als er klingt. Ein wirklich annahmenfreies System bräuchte keine Logik der zweiten Version, um Edge Cases zu behandeln, die es angeblich bereits abgedeckt hat.
Wo ich letztlich lande: Konsensmechanismen werden nicht einfach „vertrauenslos“ und bleiben dann dauerhaft dort. Sie kommen ihm näher durch Iterationen, die offenlegen, welche Annahmen das ursprüngliche Design nicht vollständig berücksichtigt hat — und das Rolling-Finality-Update von Dusk ist ein dokumentiertes Beispiel dafür, wie genau das passiert.