#La Protocol DAO (pDAO)

La Protocol DAO (pDAO) de Rocket Pool est responsable de façonner la direction du protocole et est gérée par la gouvernance RPL. Ses membres et leur pouvoir de vote sont composés de Node Operators, grands et petits, qui participent tous directement au protocole. Elle sert la communauté Rocket Pool dans son ensemble, y compris les détenteurs de rETH, les Node Operators et les détenteurs de RPL. La pDAO donne la priorité à la sécurité du protocole Rocket Pool et à la santé du réseau Ethereum. Pour une définition explicite de qui et ce qu'est la pDAO, n'hésitez pas à consulter la charte de la pDAO.

#Nouvelles fonctionnalités de la pDAO dans Houston

#Exécution on-chain des responsabilités de la pDAO

La mise à niveau Houston introduit un remplacement on-chain pour le processus d'exécution du système de gouvernance de la pDAO. Il utilise un système de preuve de fraude optimiste qui permet à tout Node Operator de proposer et de voter sur des propositions pour ajuster les "paramètres du protocole pDAO" et dépenser les fonds de la trésorerie. Pour voir une liste complète des paramètres contrôlables par la pDAO, cliquez ici. Avant Houston, l'équipe centrale était responsable de l'exécution des tâches de la pDAO à la demande du processus de gouvernance communautaire. Par exemple, l'équipe effectue les paiements mensuels IMC et GMC selon les calendriers de paiement votés par la gouvernance. Le plan était que ce pouvoir réside temporairement avec l'équipe jusqu'à ce qu'une nouvelle structure de pouvoir soit mise en place pour prendre en charge ces responsabilités. Houston supprime cette dépendance à l'équipe, rendant le protocole plus décentralisé et sans confiance.

#Conseil de sécurité

La mise à niveau Houston comprend également un nouveau conseil de sécurité pour aider à réagir rapidement en cas de problèmes potentiels avec le protocole. Ces membres peuvent être élus par la pDAO et ont la capacité de proposer et d'exécuter des changements sans délai. La pDAO a le pouvoir d'élire et de retirer des membres du conseil de sécurité. C'est un rôle sérieux et la pDAO devrait développer des exigences d'entrée solides et des processus pour éliminer les membres inactifs. Le gardien de la pDAO sera le seul membre du conseil de sécurité au début de Houston.

#Dépenses récurrentes de la trésorerie

RPL a un taux d'inflation de 5%. 22% de cette inflation est dirigée vers la pDAO comme défini dans RPIP-25. La pDAO peut utiliser ces fonds à diverses fins. Par exemple, des incitations telles que des bonus pour les fournisseurs de liquidité (LP), des subventions et des primes pour des améliorations et des projets tiers, et le financement du développement du protocole Rocket Pool. La mise à niveau Houston introduit également une nouvelle fonctionnalité qui permet des paiements récurrents de la trésorerie à un bénéficiaire spécifié à chaque période de récompenses.

#Propositions de la Protocol DAO (pDAO)

Tout nœud avec un pouvoir de vote non nul peut proposer ou participer à une proposition de la pDAO à tout moment. Les propositions peuvent être de l'un des types suivants :

• Modification des paramètres de la pDAO
• Dépenses ponctuelles de la trésorerie
• Dépenses récurrentes de la trésorerie (comités de gestion)
• Appartenance au conseil de sécurité

Pour plus de détails et de justification, référez-vous aux types de propositions. Il est important de comprendre qu'une proposition de la pDAO est une entité on-chain qui existe pour exécuter des changements au niveau du protocole.

#Cycle de vie d'une proposition de la pDAO

Une proposition doit être annoncée par le processus de gouvernance avant de se retrouver on-chain. Elle se compose de 4 périodes, qui sont toutes des paramètres contrôlables de la pDAO :

• Période de délai de vote : proposal.vote.delay.time
• Phase de vote 1 : proposal.vote.phase1.time
• Phase de vote 2 : proposal.vote.phase2.time
• Exécution : proposal.execute.time

#Période de délai de vote

Afin de décider du résultat d'une proposition, le protocole doit connaître le quorum requis. Un proposeur calcule cette valeur hors chaîne et la soumet avec sa proposition. La valeur est acceptée de manière optimiste, mais en cas de fraude, les vérificateurs peuvent effectuer un processus de défi/réponse pour prouver que la valeur est incorrecte. Les propositions invalides sont alors rejetées.

Quelques raisons pour lesquelles les proposeurs et les challengers sont tenus de verrouiller du RPL.

• proposal.bond incite les propositions valides et décourage le spam.
• proposal.challenge.bond incite à la suppression des propositions invalides/malveillantes.

Les challengers fournissent un index dans l'arbre Merkle-sum qu'ils allèguent être incorrect. Tout Node Operator peut participer au défi des propositions frauduleuses (et gagner une récompense en le faisant). N'hésitez pas à lire sur le processus de défi de la pDAO si vous êtes intéressé à y participer. Une proposition non défaite lors d'un défi à la fin de la période de délai de vote entrera dans les étapes de vote.

#Période de vote 1

Pendant une période de vote, les Node Operators et les délégués peuvent voter avec l'une des quatre options :

1. Abstention : Le pouvoir de vote du votant contribue au quorum mais n'est ni pour ni contre la proposition.
2. Pour : Le votant vote en faveur de l'exécution de la proposition.
3. Contre : Le votant vote contre l'exécution de la proposition.
4. Veto : Le votant vote contre la proposition et indique qu'il considère la proposition comme spam ou malveillante.

Leur pouvoir de vote sera inclus dans l'option de leur choix.

Cela peut être fait en utilisant la commande :

rocketpool pdao proposals vote

Si le quorum de veto (tel que défini par le paramètre proposal.veto.quorum) est atteint, la proposition est immédiatement défaite et le proposeur perd sa caution. Ceci est destiné à dissuader le spam, les propositions de faible qualité ou les propositions qui n'ont pas suivi les processus hors chaîne en premier. La commande smartnode rocketpool pdao proposals finalize est utilisée pour finaliser une proposition vétoée en brûlant la caution RPL verrouillée du proposeur.

La durée de la période 1 est déterminée par le paramètre proposal.vote.phase1.time. La proposition passera à la phase 2 que proposal.quorum soit atteint ou non.

#Période de vote 2

Les délégués peuvent voter pendant la période de vote 2, mais leur vote ne vaut que leur pouvoir de vote local. Les votants qui n'ont pas voté lors de la période 1 pourront toujours voter lors de la période 2. Les Node Operators qui ne sont pas d'accord avec le choix de leur délégué auront l'opportunité d'annuler le vote de leur délégué.

Le processus d'annulation d'un vote est assez simple, il suffit d'appeler rocketpool pdao proposals vote pendant la période de vote 2 et de suivre les invites. Le pouvoir de vote du délégué sera annulé par le pouvoir de vote du délégant.

Le résultat d'une proposition est conclu lorsque la période de vote 2 est terminée. Pour qu'un résultat soit déterminé (et exécuté), le pouvoir de vote total proposal.quorum doit être atteint à la fin de proposal.vote.phase2.time. Si le quorum est atteint et que le consensus est atteint, la proposition passera les périodes de vote et sera marquée comme réussie.

#Exécution

Une fois que les deux périodes de vote sont passées et que la proposition est réussie, la proposition peut être exécutée et le changement (défini par le payload) est appliqué au protocole Rocket Pool. Pour exécuter une proposition, utilisez la commande :

rocketpool pdao proposals execute

Vous serez invité à sélectionner une proposition à exécuter, la proposition sera appliquée au protocole après cette étape !

Après que la proposition ait passé les périodes de vote, le proposeur peut réclamer sa caution RPL verrouillée, sauf si la proposition a été défaite par un défi ou vétoée.

Et c'est tout ! Gardez à l'esprit que toutes les variables mentionnées ci-dessus sont des paramètres contrôlables par la pDAO. Cliquez ici pour une liste complète de chaque paramètre que la pDAO a l'autorité de modifier en utilisant des propositions on-chain.

#Processus de défi

L'arbre de pouvoir de vote complet du réseau est stocké hors chaîne en raison des limites de gas. Lorsqu'un utilisateur soumet une nouvelle proposition, il est responsable de la construction de l'arbre de vote du réseau au numéro de bloc cible. Cet arbre est généré hors chaîne mais vérifiable via les racines Merkle soumises on-chain. Le protocole s'appuie sur des vérificateurs pour vérifier les détails soumis par le proposeur.

Tout nœud peut participer au suivi et à la vérification de l'exactitude des propositions. Pour participer à cette responsabilité, utilisez la commande rocketpool service config, naviguez vers le menu Smartnode and TX Fee Settings, et cochez la case Enable PDAO Proposal Checker.

Lorsque ce paramètre est activé, le nœud vérifiera les nouvelles propositions, vérifiera leur exactitude et soumettra des défis aux propositions invalides. La seule condition préalable est que le verrouillage RPL soit activé.

Cette vérification s'exécute toutes les 5 minutes en conjonction avec quelques autres tâches liées au nœud. Nous allons passer en revue un exemple de ce à quoi ressemble le défi d'une proposition frauduleuse. Nous pouvons utiliser la commande smartnode rocketpool service logs node pour surveiller la progression :

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

Nous pouvons voir que notre nœud a détecté une proposition frauduleuse et a commencé le processus de défi. Le bloc 1283202 est le bloc dans lequel la proposition 177 a été soulevée, ce qui signifie que le pouvoir de vote pour cette proposition sera calculé au bloc 1283202. Si vous êtes intéressé à voir à quoi ressemblent ces instantanés d'informations de vote, vous pouvez les localiser dans ce répertoire : ~/.rocketpool/data/voting

Parce que le proposeur a été pris en train de soumettre des informations de vote incorrectes, notre nœud fait un appel de contrat Function: createChallenge sur la proposition 177 à l'index 5 et attend que le proposeur réponde au défi.

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.

Étant donné que les informations de vote du proposeur sont incorrectes, il ne pourra pas répondre au défi à temps (déterminé par proposal.challenge.period). La proposition est considérée comme défaite à ce stade. Lorsque la proposition est défaite, notre nœud fait automatiquement l'appel de contrat defeatProposal sur la proposition 177 à l'index 5 pour terminer la proposition.

Maintenant que la proposition est défaite, notre nœud (le challenger) peut réclamer sa caution RPL d'origine ainsi que la caution RPL du proposeur en récompense pour avoir défait une proposition frauduleuse.

Si vous êtes curieux d'approfondir les détails du système de proposition et de défi de la pDAO, consultez les spécifications techniques. N'hésitez pas à passer à cette section sur le processus de défi si vous êtes intéressé à étudier un exemple qui entre dans les détails de bas niveau.