#A DAO do Protocolo (pDAO)

A DAO do Protocolo Rocket Pool (pDAO) é responsável por moldar a direção do protocolo e é administrada pela governança RPL. Seus membros e seu poder de voto são compostos por operadores de nós, grandes e pequenos, todos participando diretamente do protocolo. Ela serve à comunidade Rocket Pool em geral, incluindo detentores de rETH, Operadores de Nós e detentores de RPL. A pDAO prioriza a segurança do protocolo Rocket Pool e a saúde da Rede Ethereum. Para uma definição explícita de quem e o que é a pDAO, sinta-se à vontade para consultar a carta da pDAO.

#Novos recursos da pDAO no Houston

#Execução on-chain das responsabilidades da pDAO

A Atualização Houston introduz uma substituição on-chain para o processo de execução do sistema de governança da pDAO. Ele usa um sistema otimista de prova de fraude que permite que qualquer operador de nó levante propostas e vote em propostas para ajustar "parâmetros do protocolo pDAO" e gastar fundos do tesouro. Para ver uma lista abrangente de parâmetros controláveis pela pDAO, clique aqui. Antes do Houston, a equipe principal era responsável por executar as tarefas da pDAO a pedido do processo de governança da comunidade. Por exemplo, a equipe realiza os pagamentos mensais do IMC e GMC conforme os cronogramas de pagamento votados pela governança. O plano era que esse poder residisse temporariamente com a equipe até que uma nova estrutura de poder fosse estabelecida para assumir essas responsabilidades. O Houston remove essa dependência da equipe, tornando o protocolo mais descentralizado e sem necessidade de confiança.

#Conselho de Segurança

A atualização Houston também inclui um novo conselho de segurança para ajudar a reagir rapidamente no caso de quaisquer problemas potenciais com o protocolo. Esses membros podem ser eleitos pela pDAO e têm a capacidade de propor e executar mudanças sem demora. A pDAO tem o poder de eleger e remover membros do conselho de segurança. É um papel sério e a pDAO deve desenvolver requisitos de entrada fortes e processos para remover membros obsoletos. O guardião da pDAO será o único membro do conselho de segurança no início do Houston.

#Gastos Recorrentes do Tesouro

O RPL tem uma taxa de inflação de 5%. 22% dessa inflação é direcionada para a pDAO conforme definido em RPIP-25. A pDAO pode usar esses fundos para diversos fins. Por exemplo, incentivos como bônus para provedores de liquidez (LP), subsídios e recompensas para melhorias e projetos de terceiros, e financiamento do desenvolvimento do protocolo Rocket Pool. A atualização Houston também introduz um novo recurso que permite pagamentos recorrentes do tesouro feitos a um beneficiário especificado a cada período de recompensas.

#Propostas da DAO do Protocolo (pDAO)

Qualquer nó com poder de voto diferente de zero pode levantar ou participar de uma proposta da pDAO a qualquer momento. As propostas podem ser de um dos seguintes tipos:

• Alteração das configurações da pDAO
• Gastos únicos do tesouro
• Gastos repetidos do tesouro (comitês de gestão)
• Membros do conselho de segurança

Para maior detalhe e fundamentação, consulte tipos de propostas. É importante entender que uma proposta da pDAO é uma entidade on-chain que existe para executar mudanças no nível do protocolo.

#Ciclo de vida de uma proposta da pDAO

Uma proposta deve ser prevista pelo processo de governança antes de acabar on-chain. Consiste em 4 Períodos, todos eles parâmetros controláveis pela pDAO:

• Período de Atraso de Voto: proposal.vote.delay.time
• Fase 1 de Voto: proposal.vote.phase1.time
• Fase 2 de Voto: proposal.vote.phase2.time
• Execução: proposal.execute.time

#Período de Atraso de Voto

Para decidir o resultado de uma proposta, o protocolo deve conhecer o quórum necessário. Um proponente calcula esse valor off-chain e o envia junto com sua proposta. O valor é otimisticamente aceito, mas no caso de fraude, verificadores podem realizar um processo de desafio/resposta para provar que o valor está incorreto. Propostas inválidas são então descartadas.

Alguns motivos pelos quais proponentes e desafiadores são obrigados a travar RPL.

• proposal.bond incentiva propostas válidas e desincentiva spam.
• proposal.challenge.bond incentiva a derrubada de propostas inválidas/maliciosas.

Desafiadores fornecem um índice na árvore de Merkle-sum que eles estão alegando estar incorreto. Qualquer operador de nó pode participar no desafio de propostas fraudulentas (e ganhar uma recompensa ao fazê-lo). Sinta-se à vontade para ler sobre o Processo de Desafio da pDAO se você estiver interessado em participar. Uma proposta não derrotada em um desafio até o final do período de atraso de voto entrará nos estágios de votação.

#Período de Voto 1

Durante um período de votação, Operadores de Nós e Delegados podem votar com uma das quatro opções:

1. Abstenção: O poder de voto do eleitor é contribuído para o quórum, mas não é nem a favor nem contra a proposta.
2. A Favor: O eleitor vota a favor da execução da proposta.
3. Contra: O eleitor vota contra a execução da proposta.
4. Veto: O eleitor vota contra a proposta e também indica que considera a proposta como spam ou maliciosa.

Seu poder de voto será incluído na opção de sua escolha.

Isso pode ser feito usando o comando:

rocketpool pdao proposals vote

Se o quórum de veto (conforme definido pelo parâmetro proposal.veto.quorum) for atingido, a proposta é imediatamente derrotada e o proponente perde seu vínculo. Isso é para dissuadir spam, propostas de baixa qualidade ou propostas que não passaram primeiro pelos processos off-chain. O comando smartnode rocketpool pdao proposals finalize é usado para finalizar uma proposta vetada queimando o vínculo de RPL travado do proponente.

A duração do período 1 é determinada pelo parâmetro proposal.vote.phase1.time. A proposta fará a transição para a fase 2 independentemente de proposal.quorum ser alcançado ou não.

#Período de Voto 2

Delegados podem votar durante o período de voto 2, mas seu voto vale apenas seu poder de voto local. Eleitores que não votaram no período 1 ainda poderão votar durante o período 2. Operadores de nós que discordam da escolha de seu delegado terão a oportunidade de reverter o voto de seu delegado.

O processo de reverter um voto é bastante simples, basta chamar rocketpool pdao proposals vote durante o período de voto 2 e seguir as instruções. O poder de voto do delegado será revertido pelo poder de voto do delegador.

O resultado de uma proposta é concluído quando o período de voto 2 termina. Para que um resultado seja determinado (e executado), proposal.quorum poder de voto total deve ser alcançado até o final de proposal.vote.phase2.time. Se o quórum for atingido e o consenso for alcançado, a proposta passará os períodos de votação e será marcada como bem-sucedida.

#Execução

Uma vez que ambos os períodos de votação tenham passado e a proposta seja bem-sucedida, a proposta pode ser executada e a mudança (definida pela carga útil) é aplicada ao protocolo Rocket Pool. Para executar uma proposta, use o comando:

rocketpool pdao proposals execute

Você será solicitado a selecionar uma proposta para executar, a proposta será aplicada ao protocolo após esta etapa!

Após a proposta ter passado pelos períodos de votação, o proponente pode reivindicar seu vínculo de RPL travado, a menos que a proposta tenha sido derrotada por um desafio ou vetada.

E é isso! Lembre-se de que todas as variáveis mencionadas acima são parâmetros controláveis pela pDAO. Clique aqui para uma lista abrangente de cada parâmetro que a pDAO tem autoridade para alterar usando propostas on-chain.

#Processo de Desafio

A árvore completa de poder de voto da rede é armazenada off-chain devido aos limites de gas. Quando um usuário envia uma nova proposta, ele é responsável por construir a árvore de votação da rede no número do bloco alvo. Esta árvore é gerada off-chain, mas verificável por meio de raízes Merkle que são enviadas on-chain. O protocolo depende de verificadores para verificar os detalhes enviados pelo proponente.

Qualquer nó pode participar no rastreamento e verificação da correção das propostas. Para participar dessa responsabilidade, use o comando rocketpool service config, navegue até o menu Smartnode and TX Fee Settings e marque a caixa Enable PDAO Proposal Checker.

Quando esta configuração está habilitada, o nó verificará novas propostas, verificará sua correção e enviará desafios para propostas inválidas. O único pré-requisito é que o Bloqueio de RPL esteja habilitado.

Esta verificação é executada a cada 5 minutos em conjunto com algumas outras tarefas relacionadas ao nó. Vamos percorrer um exemplo de como é desafiar uma proposta fraudulenta. Podemos usar o comando smartnode rocketpool service logs node para monitorar o progresso:

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

Podemos ver que nosso nó capturou uma proposta fraudulenta e iniciou o processo de desafiá-la. O bloco 1283202 é o bloco no qual a proposta 177 foi levantada, o que significa que o poder de voto para esta proposta será calculado no bloco 1283202. Se você estiver interessado em ver como esses Voting Info Snapshots se parecem, você pode localizá-los neste diretório: ~/.rocketpool/data/voting

Como o proponente foi pego enviando informações de votação incorretas, nosso nó faz uma chamada de contrato Function: createChallenge na proposta 177 no índice 5 e aguarda o proponente responder ao desafio.

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.

Como as informações de votação do proponente estão incorretas, ele não será capaz de responder ao desafio a tempo (determinado por proposal.challenge.period). A proposta é considerada derrotada neste ponto. Quando a proposta é derrotada, nosso nó automaticamente faz a chamada de contrato defeatProposal na proposta 177 no índice 5 para encerrar a proposta.

Agora que a proposta é derrotada, nosso nó (o desafiador) pode reivindicar seu vínculo de RPL original, bem como o vínculo de RPL do proponente como recompensa por derrotar uma proposta fraudulenta.

Se você está curioso para se aprofundar nos detalhes do sistema de propostas e desafios da pDAO, dê uma olhada nas especificações técnicas. Sinta-se à vontade para pular para esta seção sobre o processo de desafio se você estiver interessado em estudar um exemplo que entra em detalhes de baixo nível.