#The Protocol DAO (pDAO)

La Rocket Pool Protocol DAO (pDAO) è responsabile di plasmare la direzione del protocollo ed è gestita dalla governance RPL. I suoi membri e il loro potere di voto sono costituiti da operatori di nodo, grandi e piccoli, tutti direttamente coinvolti nel protocollo. Serve la comunità di Rocket Pool in generale, inclusi i possessori di rETH, gli operatori di nodo e i possessori di RPL. La pDAO dà priorità alla sicurezza del protocollo Rocket Pool e alla salute della rete Ethereum. Per una definizione esplicita di chi e cosa sia la pDAO, sentiti libero di dare un'occhiata allo statuto della pDAO.

#Nuove funzionalità della pDAO in Houston

#Esecuzione on-chain delle responsabilità della pDAO

L'aggiornamento Houston introduce una sostituzione on-chain per il processo di esecuzione del sistema di governance della pDAO. Utilizza un sistema di prova di frode ottimistica che consente a qualsiasi operatore di nodo di sollevare proposte e votare su proposte per regolare i "parametri del protocollo pDAO" e spendere fondi del tesoro. Per vedere un elenco completo dei parametri controllabili dalla pDAO, clicca qui. Pre-Houston, il team principale era responsabile dell'esecuzione dei compiti della 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 una nuova struttura di potere non fosse stata istituita 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 dalla pDAO e hanno la capacità di proporre ed eseguire modifiche senza ritardi. La pDAO ha il potere di eleggere e rimuovere membri dal Security Council. È un ruolo serio e la pDAO dovrebbe sviluppare requisiti di ingresso forti e processi per rimuovere membri stagnanti. Il guardiano della pDAO sarà l'unico membro del Security Council all'inizio di Houston.

#Spese ricorrenti del tesoro

RPL ha un tasso di inflazione del 5%. Il 22% di questa inflazione è diretto verso la pDAO come definito in RPIP-25. La pDAO può utilizzare questi fondi per una varietà di scopi. Ad esempio, incentivi come bonus per 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 abilita pagamenti ricorrenti del tesoro effettuati a un beneficiario specificato ogni periodo di ricompense.

#Proposte della 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 pDAO
• Spese del tesoro una tantum
• Spese ricorrenti del tesoro (comitati di gestione)
• Appartenenza al Security Council

Per maggiori dettagli e motivazioni, fare riferimento ai tipi di proposta. È importante comprendere 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 preannunciata dal processo di governance prima che finisca on-chain. Consiste di 4 periodi, tutti parametri controllabili dalla 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 è accettato ottimisticamente, 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 i proponenti e gli sfidanti sono tenuti a bloccare RPL.

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

Gli sfidanti forniscono un indice nell'albero Merkle-sum che stanno sostenendo essere errato. Qualsiasi operatore di nodo può partecipare alla sfida di proposte fraudolente (e guadagnare una ricompensa nel farlo). Sentiti libero di leggere sul processo di sfida della pDAO se sei interessato ad aderire. 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, gli operatori di nodo e i delegati possono esprimere un voto con una delle quattro opzioni:

1. Astieniti: 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 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 hanno seguito prima i processi off-chain. Il comando smartnode rocketpool pdao proposals finalize viene utilizzato per finalizzare una proposta sottoposta a veto 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 sia raggiunto o meno.

#Periodo di voto 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 comunque esprimere un voto durante il periodo 2. Gli operatori di nodo 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 i prompt. Il potere di voto del delegato sarà ribaltato dal potere di voto del delegante.

Il risultato di una proposta si conclude quando il periodo di voto 2 è terminato. Affinché un risultato sia determinato (ed eseguito), il potere di voto totale di proposal.quorum deve essere raggiunto entro la fine di proposal.vote.phase2.time. Se il quorum viene raggiunto e si raggiunge il consenso, 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 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à 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 sottoposta a veto.

E questo è tutto! Tieni presente che tutte le variabili menzionate sopra sono parametri controllabili dalla pDAO. Clicca qui per un elenco completo di ogni parametro che la pDAO ha l'autorità di modificare usando 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 invia 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 che vengono inviate on-chain. Il protocollo si basa su verificatori per controllare i dettagli inviati dal proponente.

Qualsiasi nodo può partecipare al tracciamento e alla verifica della correttezza delle proposte. Per aderire 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 controllerà le nuove proposte, verificherà la loro correttezza e invierà sfide alle proposte non valide. L'unico prerequisito è che il blocco RPL sia abilitato.

Questo controllo viene eseguito ogni 5 minuti in concomitanza con alcuni altri compiti relativi al nodo. Esamineremo un esempio di come 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 Controllo delle sfide alle proposte della Protocol DAO da difendere...
rocketpool_node  | 2024/04/05 02:19:26 Controllo delle proposte della Protocol DAO da sfidare...
rocketpool_node  | 2024/04/05 02:19:26 [Network Tree] Impossibile caricare l'albero di rete per il blocco 1283202 dal disco, quindi deve essere rigenerato.
rocketpool_node  | 2024/04/05 02:19:26 [PDAO Proposals] L'albero di rete per il blocco 1283202 non esisteva, creandone uno.
rocketpool_node  | 2024/04/05 02:19:26 [Voting Info Snapshot] Impossibile caricare l'albero di rete per il blocco 1283202 dal disco, quindi deve essere rigenerato.
rocketpool_node  | 2024/04/05 02:19:26 [PDAO Proposals] Lo snapshot delle informazioni di voto per il blocco 1283202 non esisteva, creandone uno.
rocketpool_node  | 2024/04/05 02:19:26 La proposta 177 non corrisponde agli artefatti dell'albero locale e deve essere sfidata.
rocketpool_node  | 2024/04/05 02:19:26 [Voting Info Snapshot] File caricato [vi-1283202.json.zst].
rocketpool_node  | 2024/04/05 02:19:26 [Network Tree] File caricato [network-tree-1283202.json.zst].
rocketpool_node  | 2024/04/05 02:19:26 Invio sfida contro la proposta 177, indice 5...
rocketpool_node  | 2024/04/05 02:19:26 Questa transazione utilizzerà una tariffa massima di 16.067134 Gwei, per un totale fino a 0.003252 - 0.004878 ETH.
rocketpool_node  | 2024/04/05 02:19:26 La transazione è stata inviata con hash 0x327e59e398bf2141a0d9273947d1da5c255606c45afaca428ab092186300eac2.
rocketpool_node  | 2024/04/05 02:19:26 Puoi seguire i suoi progressi visitando:
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 sarà calcolato al blocco 1283202. Se sei interessato a vedere come sono questi Voting Info Snapshots, 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 Controllo delle sfide alle proposte della Protocol DAO da difendere...
rocketpool3_node  | 2024/04/05 02:57:01 Controllo delle proposte della Protocol DAO da sfidare...
rocketpool3_node  | 2024/04/05 02:57:01 [Network Tree] File caricato [network-tree-1283202.json.zst].
rocketpool3_node  | 2024/04/05 02:57:01 La proposta 177 non corrisponde agli artefatti dell'albero locale e deve essere sfidata.
rocketpool3_node  | 2024/04/05 02:57:01 [Voting Info Snapshot] File caricato [vi-1283202.json.zst].
rocketpool3_node  | 2024/04/05 02:57:01 [Network Tree] File caricato [network-tree-1283202.json.zst].
rocketpool3_node  | 2024/04/05 02:57:01 La proposta 177 è stata sconfitta con indice di nodo 20, invio sconfitta...
rocketpool3_node  | 2024/04/05 02:57:01 Questa transazione utilizzerà una tariffa massima di 19.078965 Gwei, per un totale fino a 0.002061 - 0.003091 ETH.
rocketpool3_node  | 2024/04/05 02:57:01 La transazione è stata inviata con hash 0x8cc01dff37205dc98e53f4e9fae7f3c802ecc1c69a01f53e734115a73401287e.
rocketpool3_node  | 2024/04/05 02:57:01 Puoi seguire i suoi progressi visitando:
rocketpool3_node  | 2024/04/05 02:57:01 https://holesky.etherscan.io/tx/0x8cc01dff37205dc98e53f4e9fae7f3c802ecc1c69a01f53e734115a73401287e
rocketpool3_node  |
rocketpool3_node  | 2024/04/05 02:57:01 In attesa che la transazione venga convalidata...
rocketpool3_node  | 2024/04/05 02:57:13 Proposta sconfitta con successo.

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 è sconfitta, il nostro nodo (lo sfidante) può richiedere la sua garanzia RPL originale e la garanzia RPL del proponente come ricompensa per aver sconfitto una proposta fraudolenta.

Se sei curioso di approfondire i dettagli del sistema di proposte e sfide della 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 nei dettagli di basso livello.