Ich dachte über den Konsens von @Dusk nach – anhand einer einfachen Situation.
Stell dir zwei Personen vor, die unterschiedliche Wege zum selben Ziel nehmen. Die eine startet zuerst, wird aber aufgehalten. Die andere startet später und kommt zuerst an.
Entscheidest du automatisch, dass die zweite Route die richtige war?
Genau das fand ich an Dusk’s Fork-Resolution-Design interessant.
Succinct Attestation funktioniert in Iterationen. Wenn eine Iteration fehlschlägt, kann das Protokoll weitergehen. Aber wenn mehrere Iterationen schließlich gültige Kandidaten hervorbringen, gibt Dusk der niedrigsten Iteration den Vorrang.
Wenn also sowohl Iteration 2 als auch Iteration 5 das Quorum erreichen, gewinnt nicht einfach Iteration 5, weil sie später fertig wurde, sondern weil sie erfolgreich war.
Das Protokoll interessiert sich dafür, wo der Kandidat im Konsensprozess erschienen ist.
Das wird besonders spannend mit Rolling Finality. $DUSK berücksichtigt nicht aufgelöste Kandidaten aus niedrigeren Iterationen, statt jede erfolgreiche spätere Iteration sofort als endgültig zu behandeln.
Da steckt auch noch ein subtiler Anreiz dahinter. Validatoren haben Gründe, dabei zu helfen, frühere Iterationen aufzulösen, statt einfach auf das Neueste zu warten.
Ich mag dieses Design, weil es Konsens weniger wie ein Wettrennen und mehr wie eine kontrollierte Abfolge von Versuchen behandelt.
Für die finanzielle Infrastruktur könnte diese Unterscheidung wichtig sein.
Vielleicht geht es bei deterministischer Finalität nicht nur darum, schnell zu einer Einigung zu gelangen. Es geht auch darum zu wissen, welche Einigung Priorität verdient.
#dusk $DUSK #DUSK
Stell dir zwei Personen vor, die unterschiedliche Wege zum selben Ziel nehmen. Die eine startet zuerst, wird aber aufgehalten. Die andere startet später und kommt zuerst an.
Entscheidest du automatisch, dass die zweite Route die richtige war?
Genau das fand ich an Dusk’s Fork-Resolution-Design interessant.
Succinct Attestation funktioniert in Iterationen. Wenn eine Iteration fehlschlägt, kann das Protokoll weitergehen. Aber wenn mehrere Iterationen schließlich gültige Kandidaten hervorbringen, gibt Dusk der niedrigsten Iteration den Vorrang.
Wenn also sowohl Iteration 2 als auch Iteration 5 das Quorum erreichen, gewinnt nicht einfach Iteration 5, weil sie später fertig wurde, sondern weil sie erfolgreich war.
Das Protokoll interessiert sich dafür, wo der Kandidat im Konsensprozess erschienen ist.
Das wird besonders spannend mit Rolling Finality. $DUSK berücksichtigt nicht aufgelöste Kandidaten aus niedrigeren Iterationen, statt jede erfolgreiche spätere Iteration sofort als endgültig zu behandeln.
Da steckt auch noch ein subtiler Anreiz dahinter. Validatoren haben Gründe, dabei zu helfen, frühere Iterationen aufzulösen, statt einfach auf das Neueste zu warten.
Ich mag dieses Design, weil es Konsens weniger wie ein Wettrennen und mehr wie eine kontrollierte Abfolge von Versuchen behandelt.
Für die finanzielle Infrastruktur könnte diese Unterscheidung wichtig sein.
Vielleicht geht es bei deterministischer Finalität nicht nur darum, schnell zu einer Einigung zu gelangen. Es geht auch darum zu wissen, welche Einigung Priorität verdient.
#dusk $DUSK #DUSK