#Il Protocol DAO (pDAO)

Il Protocol DAO (pDAO) di Rocket Pool è responsabile di dare forma alla 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 detentori di rETH, i Node Operator e i detentori 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 sia il pDAO, dai un'occhiata allo statuto 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 ottimistico di prova di frode che consente a qualsiasi Node Operator di sollevare proposte e votare su proposte per regolare i "parametri del protocollo pDAO" e spendere fondi della tesoreria. Per vedere un elenco completo dei parametri controllabili dal pDAO, clicca qui. Prima di Houston, il team principale era responsabile dell'esecuzione dei compiti del pDAO su richiesta del processo di governance della comunità. Ad esempio, il team effettua i pagamenti mensili IMC e GMC secondo i programmi di pagamento votati dalla governance. Il piano era che questo potere risiedesse temporaneamente nel team fino a quando non fosse stata stabilita una nuova struttura di potere per assumere queste responsabilità. Houston rimuove questa dipendenza dal team, rendendo il protocollo più decentralizzato e senza fiducia.

#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 rimuovere i membri inattivi. 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 i fornitori di liquidità (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 consente 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 non nullo può sollevare o partecipare a una proposta pDAO in qualsiasi momento. Le proposte possono essere di uno dei seguenti tipi:

• Modifica delle impostazioni del pDAO
• Spese una tantum della tesoreria
• Spese ricorrenti della tesoreria (comitati di gestione)
• Appartenenza al 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:

• Periodo di ritardo del voto: proposal.vote.delay.time
• Fase di voto 1: proposal.vote.phase1.time
• Fase di voto 2: proposal.vote.phase2.time
• Esecuzione: proposal.execute.time

#Periodo di Ritardo del Voto

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 viene accettato in modo ottimistico, 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.

Alcuni motivi per cui ai proponenti e agli sfidanti è richiesto di bloccare RPL.

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

Gli sfidanti forniscono un indice nell'albero di Merkle-sum che sostengono sia errato. Qualsiasi Node Operator può partecipare alla sfida di proposte fraudolente (e guadagnare una ricompensa nel farlo). Sentiti libero di leggere il 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.

#Periodo di Voto 1

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

1. Astensione: Il potere di voto del votante contribuisce al quorum ma non è né a favore né contro la proposta.
2. A favore: Il votante vota a favore dell'esecuzione della proposta.
3. Contro: Il votante vota contro l'esecuzione della proposta.
4. Veto: Il votante vota contro la proposta e indica anche 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) viene raggiunto, la proposta viene immediatamente sconfitta e il proponente perde la sua garanzia. Questo serve a dissuadere spam, proposte di bassa qualità o proposte che non sono passate prima attraverso i processi off-chain. Il comando smartnode rocketpool pdao proposals finalize viene utilizzato per finalizzare una proposta vetata bruciando la garanzia RPL bloccata 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 venga raggiunto o meno.

#Periodo di Voto 2

I delegati possono votare durante il periodo di voto 2, ma solo il loro voto vale solo il loro potere di voto locale. I votanti che non hanno votato nel periodo 1 potranno comunque 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 ribaltare il voto del loro delegato.

Il processo di ribaltamento di un voto è abbastanza semplice, basta chiamare rocketpool pdao proposals vote durante il periodo di voto 2 e seguire le istruzioni. Il potere di voto del delegato verrà ribaltato dal potere di voto del delegante.

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

#Esecuzione

Una volta che entrambi i periodi di voto sono passati e la proposta ha 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à richiesto 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 la sua garanzia RPL bloccata, a meno che la proposta non sia stata sconfitta da una sfida o vetata.

E questo è tutto! Tieni presente che tutte le variabili sopra menzionate 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 è archiviato off-chain a causa dei limiti di gas. Quando un utente invia una nuova proposta, è responsabile della costruzione dell'albero del potere di voto della rete al numero di blocco target. Questo albero viene generato off-chain ma è verificabile tramite le radici di Merkle inviate on-chain. Il protocollo si basa sui verificatori per controllare i dettagli inviati dal proponente.

Qualsiasi nodo può partecipare al monitoraggio e alla verifica della correttezza delle proposte. Per accettare 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 controllerà le nuove proposte, verificherà la loro 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 compiti relativi al nodo. Esamineremo un esempio di come appare la sfida di 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 catturato una proposta fraudolenta e ha iniziato il processo di sfidarla. Il blocco 1283202 è il blocco in cui è stata sollevata la proposta 177, il che significa che il potere di voto per questa proposta verrà calcolato al blocco 1283202. Se sei interessato a vedere come appaiono questi Voting Info Snapshots, puoi trovarli in questa directory: ~/.rocketpool/data/voting

Poiché il proponente è stato catturato nell'invio di 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 viene 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 è stata sconfitta, il nostro nodo (lo sfidante) può richiedere la loro garanzia RPL originale così come la garanzia RPL del proponente come ricompensa per aver sconfitto una proposta fraudolenta.

Se sei curioso di approfondire i dettagli del sistema di proposta e sfida del pDAO, dai un'occhiata alle specifiche tecniche. Sentiti libero di passare a questa sezione sul processo di sfida se sei interessato a studiare un esempio che va nei dettagli di basso livello.