#Das Protocol DAO (pDAO)

Das Rocket Pool Protocol DAO (pDAO) ist verantwortlich für die Gestaltung der Ausrichtung des Protokolls und wird durch RPL-Governance betrieben. Seine Mitglieder und ihre Abstimmungsmacht setzen sich aus Node Operators, groß und klein, zusammen, die alle direkt am Protokoll teilnehmen. Es dient der Rocket Pool-Community im Allgemeinen, einschließlich rETH-Inhabern, Node Operators und RPL-Inhabern. Das pDAO priorisiert die Sicherheit des Rocket Pool-Protokolls und die Gesundheit des Ethereum-Netzwerks. Für eine explizite Definition, wer und was das pDAO ist, werfen Sie gerne einen Blick auf die pDAO-Charta.

#Neue pDAO-Funktionen in Houston

#On-Chain-Ausführung von pDAO-Verantwortlichkeiten

Das Houston-Upgrade führt einen On-Chain-Ersatz für den Ausführungsprozess des pDAO-Governance-Systems ein. Es verwendet ein optimistisches Fraud-Proof-System, das es jedem Node Operator ermöglicht, Vorschläge einzureichen und über Vorschläge zur Anpassung von "pDAO-Protokollparametern" und zur Ausgabe von Treasury-Mitteln abzustimmen. Eine umfassende Liste der vom pDAO kontrollierbaren Parameter finden Sie hier. Vor Houston war das Kernteam für die Ausführung der pDAO-Aufgaben im Auftrag des Community-Governance-Prozesses verantwortlich. Zum Beispiel führt das Team die monatlichen IMC- und GMC-Zahlungen gemäß den durch Governance abgestimmten Zahlungsplänen durch. Der Plan war, dass diese Macht vorübergehend beim Team liegt, bis eine neue Machtstruktur eingerichtet ist, um diese Verantwortlichkeiten zu übernehmen. Houston beseitigt diese Abhängigkeit vom Team und macht das Protokoll dezentraler und vertrauensloser.

#Security Council

Das Houston-Upgrade umfasst auch einen neuen Security Council, der dabei hilft, bei potenziellen Problemen mit dem Protokoll schnell zu reagieren. Diese Mitglieder können vom pDAO gewählt werden und haben die Fähigkeit, Änderungen ohne Verzögerung vorzuschlagen und auszuführen. Das pDAO hat die Macht, Mitglieder des Security Council zu wählen und zu entfernen. Es ist eine ernsthafte Rolle, und das pDAO sollte strenge Eintrittsanforderungen und Prozesse zur Entfernung inaktiver Mitglieder entwickeln. Der pDAO-Guardian wird zu Beginn von Houston das einzige Mitglied des Security Council sein.

#Wiederkehrende Treasury-Ausgaben

RPL hat eine Inflationsrate von 5%. 22% dieser Inflation werden an das pDAO weitergeleitet, wie in RPIP-25 definiert. Das pDAO kann diese Mittel für verschiedene Zwecke verwenden. Zum Beispiel Anreize wie Liquidity Provider (LP)-Boni, Zuschüsse und Prämien für Verbesserungen und Projekte von Drittanbietern sowie die Finanzierung der Entwicklung des Rocket Pool-Protokolls. Das Houston-Upgrade führt auch eine neue Funktion ein, die wiederkehrende Treasury-Zahlungen ermöglicht, die in jeder Belohnungsperiode an einen bestimmten Begünstigten geleistet werden.

#Protocol DAO (pDAO) Vorschläge

Jeder Node mit einer Abstimmungsmacht ungleich Null kann jederzeit einen pDAO-Vorschlag einreichen oder daran teilnehmen. Vorschläge können einer der folgenden Typen sein:

• Änderung von pDAO-Einstellungen
• Einmalige Treasury-Ausgaben
• Wiederkehrende Treasury-Ausgaben (Management Committees)
• Security Council-Mitgliedschaft

Für weitere Details und Begründung siehe Vorschlagstypen. Es ist wichtig zu verstehen, dass ein pDAO-Vorschlag eine On-Chain-Entität ist, die existiert, um Änderungen auf Protokollebene auszuführen.

#Lebenszyklus eines pDAO-Vorschlags

Ein Vorschlag sollte durch den Governance-Prozess angekündigt werden, bevor er On-Chain geht. Er besteht aus 4 Perioden, die alle pDAO-kontrollierbare Parameter sind:

• Vote Delay Period: proposal.vote.delay.time
• Vote Phase 1: proposal.vote.phase1.time
• Vote Phase 2: proposal.vote.phase2.time
• Execution: proposal.execute.time

#Vote Delay Period

Um das Ergebnis eines Vorschlags zu bestimmen, muss das Protokoll das erforderliche Quorum kennen. Ein Antragsteller berechnet diesen Wert Off-Chain und reicht ihn zusammen mit seinem Vorschlag ein. Der Wert wird optimistisch akzeptiert, aber im Falle von Betrug können Verifizierer einen Challenge/Response-Prozess durchführen, um zu beweisen, dass der Wert falsch ist. Ungültige Vorschläge werden dann verworfen.

Einige Gründe, warum Antragsteller und Herausforderer RPL sperren müssen:

• proposal.bond incentiviert gültige Vorschläge und schreckt Spam ab.
• proposal.challenge.bond incentiviert die Beseitigung ungültiger/bösartiger Vorschläge.

Herausforderer geben einen Index in den Merkle-Sum-Tree an, von dem sie behaupten, dass er falsch ist. Jeder Node Operator kann an der Anfechtung betrügerischer Vorschläge teilnehmen (und dabei eine Belohnung verdienen). Lesen Sie gerne über den pDAO Challenge Process, wenn Sie daran interessiert sind, sich anzumelden. Ein Vorschlag, der nicht in einer Challenge bis zum Ende der Vote Delay Period besiegt wird, tritt in die Abstimmungsphasen ein.

#Vote Period 1

Während einer Abstimmungsperiode können Node Operators und Delegaten mit einer von vier Optionen abstimmen:

1. Abstain: Die Abstimmungsmacht des Wählers wird dem Quorum zugerechnet, ist aber weder für noch gegen den Vorschlag.
2. For: Der Wähler stimmt für die Ausführung des Vorschlags.
3. Against: Der Wähler stimmt gegen die Ausführung des Vorschlags.
4. Veto: Der Wähler stimmt gegen den Vorschlag und zeigt an, dass er den Vorschlag als Spam oder bösartig betrachtet.

Ihre Abstimmungsmacht wird in die Option ihrer Wahl einbezogen.

Dies kann mit folgendem Befehl durchgeführt werden:

rocketpool pdao proposals vote

Wenn das Veto-Quorum (wie durch den Parameter proposal.veto.quorum definiert) erreicht wird, wird der Vorschlag sofort besiegt und der Antragsteller verliert seine Kaution. Dies soll Spam, Vorschläge von geringer Qualität oder Vorschläge abschrecken, die nicht zuerst Off-Chain-Prozesse durchlaufen haben. Der Smartnode-Befehl rocketpool pdao proposals finalize wird verwendet, um einen abgelehnten Vorschlag zu finalisieren, indem die gesperrte RPL-Kaution des Antragstellers verbrannt wird.

Die Dauer von Periode 1 wird durch den Parameter proposal.vote.phase1.time bestimmt. Der Vorschlag geht unabhängig davon, ob proposal.quorum erreicht wird oder nicht, in Phase 2 über.

#Vote Period 2

Delegaten können während der Vote Period 2 abstimmen, aber ihre Stimme zählt nur mit ihrer lokalen Abstimmungsmacht. Wähler, die in Periode 1 nicht abgestimmt haben, können in Periode 2 immer noch eine Stimme abgeben. Node Operators, die mit der Wahl ihres Delegaten nicht einverstanden sind, haben die Möglichkeit, die Stimme ihres Delegaten aufzuheben.

Der Prozess der Aufhebung einer Stimme ist ziemlich einfach: Rufen Sie einfach rocketpool pdao proposals vote während der Vote Period 2 auf und folgen Sie den Anweisungen. Die Abstimmungsmacht des Delegaten wird durch die Abstimmungsmacht des Delegierten aufgehoben.

Das Ergebnis eines Vorschlags steht fest, wenn Vote Period 2 vorbei ist. Damit ein Ergebnis ermittelt (und ausgeführt) werden kann, muss bis zum Ende von proposal.vote.phase2.time die gesamte Abstimmungsmacht von proposal.quorum erreicht werden. Wenn das Quorum erreicht wird und ein Konsens erzielt wird, wird der Vorschlag die Abstimmungsperioden bestehen und als erfolgreich markiert.

#Execution

Sobald beide Abstimmungsperioden bestanden sind und der Vorschlag erfolgreich ist, kann der Vorschlag ausgeführt werden und die Änderung (definiert durch die Payload) wird auf das Rocket Pool-Protokoll angewendet. Um einen Vorschlag auszuführen, verwenden Sie den Befehl:

rocketpool pdao proposals execute

Sie werden aufgefordert, einen auszuführenden Vorschlag auszuwählen. Der Vorschlag wird nach diesem Schritt auf das Protokoll angewendet!

Nachdem der Vorschlag die Abstimmungsperioden bestanden hat, kann der Antragsteller seine gesperrte RPL-Kaution beanspruchen, es sei denn, der Vorschlag wurde durch eine Challenge besiegt oder abgelehnt.

Und das war's! Denken Sie daran, dass alle oben genannten Variablen vom pDAO kontrollierbare Parameter sind. Klicken Sie hier für eine umfassende Liste aller Parameter, die das pDAO mit On-Chain-Vorschlägen ändern kann.

#Challenge Process

Der vollständige Network Voting Power Tree wird aufgrund von Gaslimits Off-Chain gespeichert. Wenn ein Benutzer einen neuen Vorschlag einreicht, ist er dafür verantwortlich, den Network Voting Tree bei der Ziel-Blocknummer zu erstellen. Dieser Tree wird Off-Chain generiert, ist aber über Merkle-Roots überprüfbar, die On-Chain eingereicht werden. Das Protokoll verlässt sich auf Verifizierer, um die vom Antragsteller eingereichten Details zu überprüfen.

Jeder Node kann an der Verfolgung und Überprüfung der Richtigkeit von Vorschlägen teilnehmen. Um sich für diese Verantwortung anzumelden, verwenden Sie den Befehl rocketpool service config, navigieren Sie zum Menü Smartnode and TX Fee Settings und aktivieren Sie das Kontrollkästchen Enable PDAO Proposal Checker.

Wenn diese Einstellung aktiviert ist, überprüft der Node neue Vorschläge, verifiziert ihre Richtigkeit und reicht Challenges für ungültige Vorschläge ein. Die einzige Voraussetzung ist, dass RPL Locking aktiviert ist.

Diese Überprüfung läuft alle 5 Minuten in Verbindung mit einigen anderen Node-bezogenen Aufgaben. Wir werden ein Beispiel durchgehen, wie das Anfechten eines betrügerischen Vorschlags aussieht. Wir können den Smartnode-Befehl rocketpool service logs node verwenden, um den Fortschritt zu überwachen:

rocketpool_node  | 2024/04/05 02:19:16 Checking for Protocol DAO proposal challenges to defend...
rocketpool_node  | 2024/04/05 02:19:26 Checking for Protocol DAO proposals to challenge...
rocketpool_node  | 2024/04/05 02:19:26 [Network Tree] Couldn't load network tree for block 1283202 from disk, so it must be regenerated.
rocketpool_node  | 2024/04/05 02:19:26 [PDAO Proposals] Network tree for block 1283202 didn't exist, creating one.
rocketpool_node  | 2024/04/05 02:19:26 [Voting Info Snapshot] Couldn't load network tree for block 1283202 from disk, so it must be regenerated.
rocketpool_node  | 2024/04/05 02:19:26 [PDAO Proposals] Voting info snapshot for block 1283202 didn't exist, creating one.
rocketpool_node  | 2024/04/05 02:19:26 Proposal 177 does not match the local tree artifacts and must be challenged.
rocketpool_node  | 2024/04/05 02:19:26 [Voting Info Snapshot] Loaded file [vi-1283202.json.zst].
rocketpool_node  | 2024/04/05 02:19:26 [Network Tree] Loaded file [network-tree-1283202.json.zst].
rocketpool_node  | 2024/04/05 02:19:26 Submitting challenge against proposal 177, index 5...
rocketpool_node  | 2024/04/05 02:19:26 This transaction will use a max fee of 16.067134 Gwei, for a total of up to 0.003252 - 0.004878 ETH.
rocketpool_node  | 2024/04/05 02:19:26 Transaction has been submitted with hash 0x327e59e398bf2141a0d9273947d1da5c255606c45afaca428ab092186300eac2.
rocketpool_node  | 2024/04/05 02:19:26 You may follow its progress by visiting:
rocketpool_node  | 2024/04/05 02:19:26 https://holesky.etherscan.io/tx/0x327e59e398bf2141a0d9273947d1da5c255606c45afaca428ab092186300eac2

Wir können sehen, dass unser Node einen betrügerischen Vorschlag erwischt hat und den Prozess der Anfechtung begonnen hat. Block 1283202 ist der Block, in dem Vorschlag 177 eingereicht wurde, was bedeutet, dass die Abstimmungsmacht für diesen Vorschlag bei Block 1283202 berechnet wird. Wenn Sie sehen möchten, wie diese Voting Info Snapshots aussehen, finden Sie sie in diesem Verzeichnis: ~/.rocketpool/data/voting

Da der Antragsteller beim Einreichen falscher Abstimmungsinformationen erwischt wurde, führt unser Node einen Vertragsaufruf Function: createChallenge für Vorschlag 177 bei Index 5 durch und wartet darauf, dass der Antragsteller auf die Challenge antwortet.

rocketpool3_node  | 2024/04/05 02:56:51 Checking for Protocol DAO proposal challenges to defend...
rocketpool3_node  | 2024/04/05 02:57:01 Checking for Protocol DAO proposals to challenge...
rocketpool3_node  | 2024/04/05 02:57:01 [Network Tree] Loaded file [network-tree-1283202.json.zst].
rocketpool3_node  | 2024/04/05 02:57:01 Proposal 177 does not match the local tree artifacts and must be challenged.
rocketpool3_node  | 2024/04/05 02:57:01 [Voting Info Snapshot] Loaded file [vi-1283202.json.zst].
rocketpool3_node  | 2024/04/05 02:57:01 [Network Tree] Loaded file [network-tree-1283202.json.zst].
rocketpool3_node  | 2024/04/05 02:57:01 Proposal 177 has been defeated with node index 20, submitting defeat...
rocketpool3_node  | 2024/04/05 02:57:01 This transaction will use a max fee of 19.078965 Gwei, for a total of up to 0.002061 - 0.003091 ETH.
rocketpool3_node  | 2024/04/05 02:57:01 Transaction has been submitted with hash 0x8cc01dff37205dc98e53f4e9fae7f3c802ecc1c69a01f53e734115a73401287e.
rocketpool3_node  | 2024/04/05 02:57:01 You may follow its progress by visiting:
rocketpool3_node  | 2024/04/05 02:57:01 https://holesky.etherscan.io/tx/0x8cc01dff37205dc98e53f4e9fae7f3c802ecc1c69a01f53e734115a73401287e
rocketpool3_node  |
rocketpool3_node  | 2024/04/05 02:57:01 Waiting for the transaction to be validated...
rocketpool3_node  | 2024/04/05 02:57:13 Successfully defeated proposal.

Da die Abstimmungsinformationen des Antragstellers falsch sind, kann er nicht rechtzeitig auf die Challenge antworten (bestimmt durch proposal.challenge.period). Der Vorschlag gilt an diesem Punkt als besiegt. Wenn der Vorschlag besiegt ist, führt unser Node automatisch den Vertragsaufruf defeatProposal für Vorschlag 177 bei Index 5 durch, um den Vorschlag zu beenden.

Da der Vorschlag nun besiegt ist, kann unser Node (der Herausforderer) seine ursprüngliche RPL-Kaution sowie die RPL-Kaution des Antragstellers als Belohnung für die Besiegung eines betrügerischen Vorschlags beanspruchen.

Wenn Sie sich für die Details des pDAO-Vorschlags- und Challenge-Systems interessieren, schauen Sie sich die technischen Spezifikationen an. Springen Sie gerne zu diesem Abschnitt über den Challenge Process, wenn Sie ein Beispiel mit vielen technischen Details studieren möchten.