#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 os quais estão participando diretamente do protocolo. Ela serve a 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 livre para dar uma olhada na carta da pDAO.

#Novos recursos pDAO em Houston

#Execução on-chain de responsabilidades pDAO

A Atualização Houston introduz uma substituição on-chain para o processo de execução do sistema de governança pDAO. Ela usa um sistema de prova de fraude otimista 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. Pré-Houston, a equipe principal era responsável por executar as responsabilidades 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 com a equipe temporariamente até que uma nova estrutura de poder fosse estabelecida para assumir essas responsabilidades. 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 atraso. 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 pDAO será o único membro do conselho de segurança no início de Houston.

#Gastos Recorrentes do Tesouro

RPL tem uma taxa de inflação de 5%. 22% desta inflação é direcionada para a pDAO conforme definido em RPIP-25. A pDAO pode usar esses fundos para uma variedade de propósitos. Por exemplo, incentivos como bônus de provedor de liquidez (LP), subsídios e recompensas por 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 não-zero pode levantar ou participar em uma proposta pDAO a qualquer momento. As propostas podem ser um dos seguintes tipos:

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

Para mais detalhes e justificativa, consulte tipos de proposta. É importante entender que uma proposta pDAO é uma entidade on-chain que existe para executar alterações ao nível do protocolo.

#Ciclo de vida de uma proposta pDAO

Uma proposta deve ser prevista pelo processo de governança antes de acabar on-chain. Ela consiste em 4 Períodos, todos os quais são parâmetros controláveis pDAO:

• Período de Atraso de Voto: proposal.vote.delay.time
• Fase de Voto 1: proposal.vote.phase1.time
• Fase de Voto 2: 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 saber 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.

Algumas razões pelas quais proponentes e desafiantes são obrigados a bloquear RPL.

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

Desafiantes fornecem um índice na árvore 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 livre para ler sobre o Processo de Desafio pDAO se você estiver interessado em optar por participar. Uma proposta não derrotada em um desafio até o final do período de atraso de voto entrará nas fases 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 votante é contribuído para o quórum mas não é nem a favor nem contra a proposta.
2. A Favor: O votante vota a favor da proposta ser executada.
3. Contra: O votante vota contra a proposta ser executada.
4. Veto: O votante vota contra a proposta bem como indicando que considera a proposta como spam ou maliciosa.

O seu poder de voto será incluído na opção da 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 alcançado, a proposta é imediatamente derrotada e o proponente perde sua garantia. Isso é para dissuadir spam, propostas de baixa qualidade, ou propostas que não passaram pelos processos off-chain primeiro. O comando smartnode rocketpool pdao proposals finalize é usado para finalizar uma proposta vetada queimando a garantia RPL bloqueada 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 apenas seu voto vale apenas seu poder de voto local. Votantes que não votaram no período 1 ainda poderão votar durante o período 2. Operadores de nós que discordarem da escolha do seu delegado terão a oportunidade de reverter o voto do seu delegado.

O processo de reverter um voto é bem simples, basta chamar rocketpool pdao proposals vote durante o período de voto 2 e seguir os prompts. O poder de voto do delegado será revertido pelo poder de voto do delegante.

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 alcançado e o consenso for atingido, a proposta passará pelos 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 pelo payload) é 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 este passo!

Depois que a proposta tiver passado pelos períodos de votação, o proponente pode reivindicar sua garantia RPL bloqueada, a menos que a proposta tenha sido derrotada por um desafio ou vetada.

E é isso! Tenha em mente 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 mudar usando propostas on-chain.

#Processo de Desafio

A árvore completa de poder de voto da rede é armazenada off-chain devido a 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 de bloco alvo. Esta árvore é gerada off-chain mas verificável através 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 optar por essa responsabilidade, use o comando rocketpool service config, navegue até o menu Configurações de Smartnode e Taxa TX, e marque a caixa Habilitar Verificador de Proposta PDAO.

Quando esta configuração está habilitada, o nó verificará novas propostas, verificará sua correção e enviará desafios a propostas inválidas. O único pré-requisito é que o Bloqueio 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 Verificando desafios de proposta da DAO do Protocolo para defender...
rocketpool_node  | 2024/04/05 02:19:26 Verificando propostas da DAO do Protocolo para desafiar...
rocketpool_node  | 2024/04/05 02:19:26 [Network Tree] Não foi possível carregar a árvore de rede para o bloco 1283202 do disco, então ela deve ser regenerada.
rocketpool_node  | 2024/04/05 02:19:26 [Propostas PDAO] A árvore de rede para o bloco 1283202 não existia, criando uma.
rocketpool_node  | 2024/04/05 02:19:26 [Voting Info Snapshot] Não foi possível carregar a árvore de rede para o bloco 1283202 do disco, então ela deve ser regenerada.
rocketpool_node  | 2024/04/05 02:19:26 [Propostas PDAO] Snapshot de informações de votação para o bloco 1283202 não existia, criando um.
rocketpool_node  | 2024/04/05 02:19:26 A proposta 177 não corresponde aos artefatos da árvore local e deve ser desafiada.
rocketpool_node  | 2024/04/05 02:19:26 [Voting Info Snapshot] Arquivo carregado [vi-1283202.json.zst].
rocketpool_node  | 2024/04/05 02:19:26 [Network Tree] Arquivo carregado [network-tree-1283202.json.zst].
rocketpool_node  | 2024/04/05 02:19:26 Enviando desafio contra a proposta 177, índice 5...
rocketpool_node  | 2024/04/05 02:19:26 Esta transação usará uma taxa máxima de 16.067134 Gwei, para um total de até 0.003252 - 0.004878 ETH.
rocketpool_node  | 2024/04/05 02:19:26 A transação foi enviada com hash 0x327e59e398bf2141a0d9273947d1da5c255606c45afaca428ab092186300eac2.
rocketpool_node  | 2024/04/05 02:19:26 Você pode acompanhar seu progresso visitando:
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 são esses Snapshots de Informações de Votação, 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 espera que o proponente responda ao desafio.

rocketpool3_node  | 2024/04/05 02:56:51 Verificando desafios de proposta da DAO do Protocolo para defender...
rocketpool3_node  | 2024/04/05 02:57:01 Verificando propostas da DAO do Protocolo para desafiar...
rocketpool3_node  | 2024/04/05 02:57:01 [Network Tree] Arquivo carregado [network-tree-1283202.json.zst].
rocketpool3_node  | 2024/04/05 02:57:01 A proposta 177 não corresponde aos artefatos da árvore local e deve ser desafiada.
rocketpool3_node  | 2024/04/05 02:57:01 [Voting Info Snapshot] Arquivo carregado [vi-1283202.json.zst].
rocketpool3_node  | 2024/04/05 02:57:01 [Network Tree] Arquivo carregado [network-tree-1283202.json.zst].
rocketpool3_node  | 2024/04/05 02:57:01 A proposta 177 foi derrotada com o índice de nó 20, enviando derrota...
rocketpool3_node  | 2024/04/05 02:57:01 Esta transação usará uma taxa máxima de 19.078965 Gwei, para um total de até 0.002061 - 0.003091 ETH.
rocketpool3_node  | 2024/04/05 02:57:01 A transação foi enviada com hash 0x8cc01dff37205dc98e53f4e9fae7f3c802ecc1c69a01f53e734115a73401287e.
rocketpool3_node  | 2024/04/05 02:57:01 Você pode acompanhar seu progresso 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 Aguardando a validação da transação...
rocketpool3_node  | 2024/04/05 02:57:13 Proposta derrotada com sucesso.

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 está derrotada, nosso nó (o desafiante) pode reivindicar sua garantia RPL original, bem como a garantia RPL do proponente como uma recompensa por derrotar uma proposta fraudulenta.

Se você estiver curioso para mergulhar nos detalhes da proposta pDAO e sistema de desafio, dê uma olhada nas especificações técnicas. Sinta-se livre 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.