#Il Protocol DAO (pDAO)

Il Rocket Pool Protocol DAO (pDAO) è responsabile della direzione del protocollo ed è gestito dalla governance RPL. I suoi membri e il loro potere di voto sono costituiti da node operator, grandi e piccoli, tutti direttamente partecipanti al protocollo. Serve la comunità Rocket Pool in generale, inclusi i possessori di rETH, i Node Operator e i possessori di RPL. Il pDAO dà priorità alla sicurezza del protocollo Rocket Pool e alla salute della Rete Ethereum. Per una definizione esplicita di chi e cosa è il pDAO, dai un'occhiata alla carta del pDAO.

#Nuove funzionalità del pDAO in Houston

#Esecuzione on-chain delle responsabilità del pDAO

L'aggiornamento Houston introduce una sostituzione on-chain per il processo di esecuzione del sistema di governance del pDAO. Utilizza un sistema di prova di frode ottimistica che consente a qualsiasi node operator di presentare proposte e votare su proposte per regolare "parametri del protocollo pDAO" e spendere fondi della tesoreria. Per vedere un elenco completo dei parametri controllabili dal pDAO, clicca qui. Pre-Houston, il core team era responsabile dell'esecuzione dei doveri del pDAO su richiesta del processo di governance della comunità. Ad esempio, il team esegue i pagamenti mensili IMC e GMC secondo i programmi di pagamento votati dalla governance. Il piano era che questo potere risiedesse temporaneamente con il team fino a quando non fosse stata istituita una nuova struttura di potere per assumere queste responsabilità. Houston rimuove questa dipendenza dal team, rendendo il protocollo più decentralizzato e trustless.

#Security Council

L'aggiornamento Houston include anche un nuovo security council per aiutare a reagire rapidamente in caso di potenziali problemi con il protocollo. Questi membri possono essere eletti dal pDAO e hanno la capacità di proporre ed eseguire modifiche senza ritardi. Il pDAO ha il potere di eleggere e rimuovere membri dal security council. È un ruolo serio e il pDAO dovrebbe sviluppare forti requisiti di ingresso e processi per eliminare membri obsoleti. Il guardiano del pDAO sarà l'unico membro del security council all'inizio di Houston.

#Spese Ricorrenti della Tesoreria

RPL ha un tasso di inflazione del 5%. Il 22% di questa inflazione è diretto verso il pDAO come definito in RPIP-25. Il pDAO può utilizzare questi fondi per una varietà di scopi. Ad esempio, incentivi come bonus per liquidity provider (LP), sovvenzioni e premi per miglioramenti e progetti di terze parti, e finanziamento dello sviluppo del protocollo Rocket Pool. L'aggiornamento Houston introduce anche una nuova funzionalità che abilita pagamenti ricorrenti della tesoreria effettuati a un beneficiario specificato ogni periodo di ricompense.

#Proposte del Protocol DAO (pDAO)

Qualsiasi nodo con un potere di voto diverso da zero può presentare o partecipare a una proposta pDAO in qualsiasi momento. Le proposte possono essere di uno dei seguenti tipi:

• Modifica delle impostazioni del pDAO
• Spese uniche della tesoreria
• Spese ricorrenti della tesoreria (comitati di gestione)
• Membership del security council

Per maggiori dettagli e motivazioni, consulta i tipi di proposta. È importante capire che una proposta pDAO è un'entità on-chain che esiste per eseguire modifiche a livello di protocollo.

#Ciclo di Vita di una Proposta pDAO

Una proposta dovrebbe essere prevista dal processo di governance prima di finire on-chain. Consiste di 4 Periodi, tutti parametri controllabili dal pDAO:

• 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

Per decidere l'esito di una proposta, il protocollo deve conoscere il quorum richiesto. Un proponente calcola questo valore off-chain e lo invia insieme alla proposta. Il valore è ottimisticamente accettato, ma in caso di frode, i verificatori possono eseguire un processo di sfida/risposta per dimostrare che il valore è errato. Le proposte non valide vengono quindi scartate.

Alcune ragioni per cui i proponenti e gli sfidanti sono tenuti a bloccare RPL:

• proposal.bond incentiva proposte valide e disincentiva lo spam.
• proposal.challenge.bond incentiva l'eliminazione di proposte non valide/dannose.

Gli sfidanti forniscono un indice nell'albero Merkle-sum che sostengono essere errato. Qualsiasi node operator può partecipare alla sfida di proposte fraudolente (e guadagnare una ricompensa nel farlo). Sentiti libero di leggere sul Processo di Sfida del pDAO se sei interessato a partecipare. Una proposta non sconfitta in una sfida entro la fine del periodo di ritardo del voto entrerà nelle fasi di voto.

#Vote Period 1

Durante un periodo di voto, Node Operator e Delegati possono esprimere un voto con una delle quattro opzioni:

1. Abstain: Il potere di voto del votante è contribuito al quorum ma non è né a favore né contro la proposta.
2. For: Il votante vota a favore dell'esecuzione della proposta.
3. Against: Il votante vota contro l'esecuzione della proposta.
4. Veto: Il votante vota contro la proposta e indica che ritiene la proposta spam o dannosa.

Il loro potere di voto sarà incluso nell'opzione di loro scelta.

Questo può essere fatto usando il comando:

rocketpool pdao proposals vote

Se il quorum di veto (come definito dal parametro proposal.veto.quorum) è raggiunto, la proposta viene immediatamente sconfitta e il proponente perde il suo bond. Questo serve a dissuadere spam, proposte di bassa qualità o proposte che non sono passate attraverso processi off-chain prima. Il comando smartnode rocketpool pdao proposals finalize viene utilizzato per finalizzare una proposta vetata bruciando il bond RPL bloccato del proponente.

La durata del periodo 1 è determinata dal parametro proposal.vote.phase1.time. La proposta passerà alla fase 2 indipendentemente dal fatto che proposal.quorum sia raggiunto o meno.

#Vote Period 2

I delegati possono votare durante il periodo di voto 2, ma il loro voto vale solo il loro potere di voto locale. I votanti che non hanno votato nel periodo 1 potranno ancora esprimere un voto durante il periodo 2. I node operator che non sono d'accordo con la scelta del loro delegato avranno l'opportunità di annullare il voto del loro delegato.

Il processo di annullamento di un voto è abbastanza semplice, basta chiamare rocketpool pdao proposals vote durante il periodo di voto 2 e seguire i prompt. Il potere di voto del delegato sarà annullato dal potere di voto del delegante.

Il risultato di una proposta è concluso quando il periodo di voto 2 è finito. Affinché un risultato sia determinato (ed eseguito), proposal.quorum potere di voto totale deve essere raggiunto entro la fine di proposal.vote.phase2.time. Se il quorum è raggiunto e il consenso è raggiunto, la proposta passerà i periodi di voto e sarà contrassegnata come riuscita.

#Execution

Una volta che entrambi i periodi di voto sono passati e la proposta ha avuto successo, la proposta può essere eseguita e la modifica (definita dal payload) viene applicata al protocollo Rocket Pool. Per eseguire una proposta, usa il comando:

rocketpool pdao proposals execute

Ti verrà chiesto di selezionare una proposta da eseguire, la proposta verrà applicata al protocollo dopo questo passaggio!

Dopo che la proposta ha superato i periodi di voto, il proponente può richiedere il suo bond RPL bloccato, a meno che la proposta non sia stata sconfitta da una sfida o vetata.

E questo è tutto! Tieni presente che tutte le variabili menzionate sopra sono parametri controllabili dal pDAO. Clicca qui per un elenco completo di ogni parametro che il pDAO ha l'autorità di modificare utilizzando proposte on-chain.

#Processo di Sfida

L'albero completo del potere di voto della rete è memorizzato off-chain a causa dei limiti di gas. Quando un utente presenta una nuova proposta, è responsabile della costruzione dell'albero di voto della rete al numero di blocco target. Questo albero è generato off-chain ma verificabile tramite radici Merkle inviate on-chain. Il protocollo si basa su verificatori per controllare i dettagli inviati dal proponente.

Qualsiasi nodo può partecipare al monitoraggio e alla verifica della correttezza delle proposte. Per partecipare a questa responsabilità, usa il comando rocketpool service config, naviga nel menu Smartnode and TX Fee Settings e seleziona la casella Enable PDAO Proposal Checker.

Quando questa impostazione è abilitata, il nodo verificherà nuove proposte, ne verificherà la correttezza e invierà sfide a proposte non valide. L'unico prerequisito è che il Blocco RPL sia abilitato.

Questo controllo viene eseguito ogni 5 minuti insieme ad alcuni altri doveri relativi al nodo. Esamineremo un esempio di come appare sfidare una proposta fraudolenta. Possiamo usare il comando smartnode rocketpool service logs node per monitorare i progressi:

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

Possiamo vedere che il nostro nodo ha rilevato una proposta fraudolenta e ha iniziato il processo di sfida. Il blocco 1283202 è il blocco in cui è stata sollevata la proposta 177, il che significa che il potere di voto per questa proposta sarà calcolato al blocco 1283202. Se sei interessato a vedere come appaiono questi Voting Info Snapshot, puoi trovarli in questa directory: ~/.rocketpool/data/voting

Poiché il proponente è stato sorpreso a inviare informazioni di voto errate, il nostro nodo effettua una chiamata al contratto Function: createChallenge sulla proposta 177 all'indice 5 e attende che il proponente risponda alla sfida.

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.

Poiché le informazioni di voto del proponente sono errate, non sarà in grado di rispondere alla sfida in tempo (determinato da proposal.challenge.period). La proposta è considerata sconfitta a questo punto. Quando la proposta è sconfitta, il nostro nodo effettua automaticamente la chiamata al contratto defeatProposal sulla proposta 177 all'indice 5 per terminare la proposta.

Ora che la proposta è sconfitta, il nostro nodo (lo sfidante) può richiedere il suo bond RPL originale e il bond RPL del proponente come ricompensa per aver sconfitto una proposta fraudolenta.

Se sei curioso di approfondire i dettagli del sistema di proposte e sfide del pDAO, dai un'occhiata alle specifiche tecniche. Sentiti libero di saltare a questa sezione sul processo di sfida se sei interessato a studiare un esempio che entra in dettagli di basso livello.