Wie wählt das Clique-PoA-Konsensprotokoll den nächsten Blockminting-Knoten aus?

Wie wählt das Clique-PoA-Konsensprotokoll den nächsten Mining-/Mining-Knoten aus? Ist es zufällig (innerhalb der Grenzen der Anzahl von Blöcken, die verstrichen sein müssen, bevor ein Knoten einen anderen Block prägen/minen kann)?

Ich bin weiter verwirrt, als ich auf https://www.rinkeby.io/#stats schaue und sehe, dass sie eine Netzwerk-Hashrate und Schwierigkeit auflisten.

@j-doe, hast du eine Antwort auf diese Frage gefunden? Ich habe das gleiche Problem.
@IvanBurlutskiy Ich habe keine endgültige Antwort gefunden, sorry. Soweit ich das beurteilen kann, "rennen" die Knoten nur um das Signieren von Blöcken (wenn sie berechtigt sind, da die erforderliche Anzahl von Blöcken seit dem letzten Signieren verstrichen ist). Um zu verhindern, dass das „Rennen“ zu nahe ist und Gabelungen verursacht, wird dem Blockintervall eine zufällige „Offset“-Zeit hinzugefügt. Dadurch signiert ein Knoten vor den anderen. [Ich bin mir nicht sicher, ob irgendetwas davon richtig ist, aber es ist meine naive Lesart des Codes]

Antworten (1)

Alle Details sind hier dokumentiert: https://github.com/ethereum/EIPs/issues/225

Kurz die Fakten für ein System mit N Sealern:

  • Jeder Block hat einen bevorzugten Versiegeler (im Gegenzug Signieren), der die Blockschwierigkeit auf 2 setzt
  • Wenn der bevorzugte Sealer den Block nicht unterschreibt, können andere Sealer einspringen (außerhalb der Reihe), aber sie können die Blockschwierigkeit nur auf 1 setzen
  • Der bevorzugte Sealer wechselt durch Anwendung von Round-Robin
  • Die Gabeln können immer noch passieren, die schwerste Kette (-> Blockschwierigkeiten hinzugefügt) gewinnt (-> GHOST-Protokoll)
  • Robbenfänger, die nicht an der Reihe sind, werden ihren Vorschlag verzögern, um dem Robbenfänger in der Reihe eine bessere Chance zu geben, dass sein Vorschlag über das Netzwerk verbreitet wird.
  • Wenn ein Sealer in Clique einen Block signiert, darf er die nächsten floor(N / 2)Blöcke nicht versiegeln