Jede Runde des Konsenses fügt einen neuen Block hinzu, aber das Whitepaper sagt: Diese Runde ist nicht ein einmaliges Durchlaufen, sondern besteht aus mehreren Iterationen, und jede Iteration wiederum aus drei Schritten. Im Abschnitt 3.2 des Whitepapers werden diese drei Schritte Proposal, Validation und Ratification genannt.
Zuerst der erste Schritt: Proposal. Der DS-Algorithmus wählt zufällig einen Provisioner als Blockerzeuger aus, der für die Generierung eines Kandidatenblocks verantwortlich ist und ihn an das gesamte Netzwerk broadcastet. Wenn der Kandidatenblock innerhalb der vorgegebenen Timeout-Zeit nicht erzeugt oder nicht empfangen wird, gibt dieser Schritt NIL aus und geht direkt zum nächsten Schritt über – aber wenn man keinen Kandidatenblock in der Hand hat, worüber wird dann später abgestimmt? Die Antwort ist: keine leere Stimme abzugeben, sondern NoCandidate zu wählen, was bedeutet: „kein Kandidatenblock ist verifizierbar“.$DUSK
Zweiter Schritt: Validation. Der DS-Algorithmus wählt zufällig ein Team von Abstimmungskomitees (Voting Committees), um den Kandidatenblock aus dem vorherigen Schritt zu verifizieren. Wenn der Kandidatenblock gültig ist, wird Valid gestimmt; wenn er ungültig ist, wird Invalid gestimmt; wenn es keinen Kandidatenblock gibt, wird NoCandidate gestimmt. Das Abstimmungskomitee benötigt eine absolute 2/3-Mehrheit, um quorum zu erreichen. Falls das Quorum bis zum Timeout noch nicht erreicht wird, wird NoQuorum ausgegeben. Die Ausgabe dieses Schritts ist ein ValidationResult, das den Abstimmungstyp enthält, der das Quorum erreicht hat, sowie die aggregierte Signatur aller Stimmenden.@Dusk
Dritter Schritt: Ratification. Es wird erneut ein neues Abstimmungskomitee gewählt, um das Ergebnis der Validation zu bestätigen. Wenn im vorherigen Schritt ein Valid-Quorum erreicht wurde, bestätigen sie dieses Ergebnis; wenn im vorherigen Schritt NoQuorum oder ein Fehlschlag vorlag, stimmen sie NoQuorum. Dieser Schritt stellt sicher, dass das Verifikationsergebnis nicht nur von einer Minderheit entschieden wird, sondern von mehr Provisionern anerkannt wird.
Wenn die Ratification Success ausgibt, wird der Kandidatenblock offiziell als neuer Block akzeptiert, und die Runde ist beendet. Wenn Fail oder unknown ausgegeben wird, geht es zur nächsten Iteration über: erneut wird ein Blockerzeuger ausgewählt und erneut wird abgestimmt. Das Whitepaper sagt, dass die maximale Anzahl an Iterationen durch einen globalen Parameter bestimmt wird; die aktuelle Einstellung ist 50. Wenn 16 aufeinanderfolgende Iterationen fehlschlagen, wechselt das Protokoll in den Notfallmodus (Winkel 10).
Die Kernlogik des dreistufigen Designs ist das Ausbalancieren (Checks and Balances): Der Blockerzeuger kann nur Kandidatenblöcke erzeugen, aber nicht abstimmen; das Verifizierungskomitee kann nur verifizieren, aber nicht bestätigen; das Bestätigungskomitee kann nur das Validation-Ergebnis bestätigen, aber nicht erneut verifizieren. Keine einzelne Rolle kann allein über das Schicksal eines Blocks entscheiden.#dusk
Zuerst der erste Schritt: Proposal. Der DS-Algorithmus wählt zufällig einen Provisioner als Blockerzeuger aus, der für die Generierung eines Kandidatenblocks verantwortlich ist und ihn an das gesamte Netzwerk broadcastet. Wenn der Kandidatenblock innerhalb der vorgegebenen Timeout-Zeit nicht erzeugt oder nicht empfangen wird, gibt dieser Schritt NIL aus und geht direkt zum nächsten Schritt über – aber wenn man keinen Kandidatenblock in der Hand hat, worüber wird dann später abgestimmt? Die Antwort ist: keine leere Stimme abzugeben, sondern NoCandidate zu wählen, was bedeutet: „kein Kandidatenblock ist verifizierbar“.$DUSK
Zweiter Schritt: Validation. Der DS-Algorithmus wählt zufällig ein Team von Abstimmungskomitees (Voting Committees), um den Kandidatenblock aus dem vorherigen Schritt zu verifizieren. Wenn der Kandidatenblock gültig ist, wird Valid gestimmt; wenn er ungültig ist, wird Invalid gestimmt; wenn es keinen Kandidatenblock gibt, wird NoCandidate gestimmt. Das Abstimmungskomitee benötigt eine absolute 2/3-Mehrheit, um quorum zu erreichen. Falls das Quorum bis zum Timeout noch nicht erreicht wird, wird NoQuorum ausgegeben. Die Ausgabe dieses Schritts ist ein ValidationResult, das den Abstimmungstyp enthält, der das Quorum erreicht hat, sowie die aggregierte Signatur aller Stimmenden.@Dusk
Dritter Schritt: Ratification. Es wird erneut ein neues Abstimmungskomitee gewählt, um das Ergebnis der Validation zu bestätigen. Wenn im vorherigen Schritt ein Valid-Quorum erreicht wurde, bestätigen sie dieses Ergebnis; wenn im vorherigen Schritt NoQuorum oder ein Fehlschlag vorlag, stimmen sie NoQuorum. Dieser Schritt stellt sicher, dass das Verifikationsergebnis nicht nur von einer Minderheit entschieden wird, sondern von mehr Provisionern anerkannt wird.
Wenn die Ratification Success ausgibt, wird der Kandidatenblock offiziell als neuer Block akzeptiert, und die Runde ist beendet. Wenn Fail oder unknown ausgegeben wird, geht es zur nächsten Iteration über: erneut wird ein Blockerzeuger ausgewählt und erneut wird abgestimmt. Das Whitepaper sagt, dass die maximale Anzahl an Iterationen durch einen globalen Parameter bestimmt wird; die aktuelle Einstellung ist 50. Wenn 16 aufeinanderfolgende Iterationen fehlschlagen, wechselt das Protokoll in den Notfallmodus (Winkel 10).
Die Kernlogik des dreistufigen Designs ist das Ausbalancieren (Checks and Balances): Der Blockerzeuger kann nur Kandidatenblöcke erzeugen, aber nicht abstimmen; das Verifizierungskomitee kann nur verifizieren, aber nicht bestätigen; das Bestätigungskomitee kann nur das Validation-Ergebnis bestätigen, aber nicht erneut verifizieren. Keine einzelne Rolle kann allein über das Schicksal eines Blocks entscheiden.#dusk