#O DAO do Protocolo (pDAO)

O Rocket Pool Protocol DAO (pDAO) é responsável por moldar a direção do protocolo e é administrado pela governança RPL. Seus membros e seu poder de voto são compostos por operadores de nó, grandes e pequenos, todos participando diretamente do protocolo. Ele serve a comunidade Rocket Pool em geral, incluindo detentores de rETH, Operadores de Nó e detentores de RPL. O 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 é o pDAO, sinta-se à vontade para dar uma olhada na carta do pDAO.

#Novos recursos do pDAO em Houston

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

A Atualização Houston introduz uma substituição on-chain para o processo de execução do sistema de governança do 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 de protocolo do pDAO" e gastar fundos do tesouro. Para ver uma lista abrangente de parâmetros controláveis pelo pDAO, clique aqui. Pré-Houston, a equipe principal era responsável por executar as funções do 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 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 pelo pDAO e têm a capacidade de propor e executar mudanças sem demora. O pDAO tem o poder de eleger e remover membros do conselho de segurança. É um papel sério e o pDAO deve desenvolver requisitos de entrada fortes e processos para remover membros obsoletos. O guardião do pDAO será o único membro do conselho de segurança no início do Houston.

#Gastos Recorrentes do Tesouro

RPL tem uma taxa de inflação de 5%. 22% dessa inflação é direcionada ao pDAO conforme definido em RPIP-25. O 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 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 do DAO do Protocolo (pDAO)

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

• Mudança de configurações do 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 proposta. É importante entender que uma proposta do pDAO é uma entidade on-chain que existe para executar mudanças no nível do protocolo.

#Ciclo de vida de uma proposta do 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 do pDAO:

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

#Período de Atraso de Votação

Para decidir o resultado de uma proposta, o protocolo deve conhecer o quorum necessário. Um proponente calcula esse valor off-chain e o submete 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 desafiadores 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.

Os desafiadores fornecem um índice na árvore Merkle-sum que eles alegam 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 do 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 votação entrará nos estágios de votação.

#Período de Votação 1

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

1. Abstenção: O poder de voto do eleitor contribui para o quorum mas não é nem a favor nem contra a proposta.
2. A favor: O eleitor vota a favor da proposta ser executada.
3. Contra: O eleitor vota contra a proposta ser executada.
4. Veto: O eleitor vota contra a proposta bem como 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 quorum de veto (conforme definido pelo parâmetro proposal.veto.quorum) for atingido, a proposta é imediatamente derrotada e o proponente perde sua garantia. Isso é para desencorajar spam, propostas de baixa qualidade, ou propostas que não passaram por processos off-chain primeiro. O comando smartnode rocketpool pdao proposals finalize é usado para finalizar uma proposta vetada queimando a garantia de 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 atingido ou não.

#Período de Votação 2

Delegados podem votar durante o período de votação 2, mas apenas 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ó que discordam da escolha de seu delegado terão a oportunidade de anular o voto de seu delegado.

O processo de anular um voto é bem simples, apenas chame rocketpool pdao proposals vote durante o período de votação 2 e siga as instruções. O poder de voto do delegado será anulado pelo poder de voto do delegatário.

O resultado de uma proposta é concluído quando o período de votação 2 termina. Para que um resultado seja determinado (e executado), proposal.quorum poder de voto total deve ser atingido até o final de proposal.vote.phase2.time. Se o quorum for atingido e o consenso for alcançado, 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 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 este passo!

Após a proposta ter passado pelos períodos de votação, o proponente pode reivindicar sua garantia de 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 pelo pDAO. Clique aqui para uma lista abrangente de cada parâmetro que o 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 submete 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 via raízes Merkle que são submetidas on-chain. O protocolo depende de verificadores para verificar os detalhes submetidos 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 Smartnode and TX Fee Settings, e marque a caixa Enable PDAO Proposal Checker.

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

Esta verificação é executada a cada 5 minutos em conjunto com algumas outras tarefas relacionadas ao nó. Vamos passar por um exemplo de como desafiar uma proposta fraudulenta se parece. 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ó pegou uma proposta fraudulenta e iniciou o processo de desafiá-la. 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 Voting Info Snapshots, você pode localizá-los neste diretório: ~/.rocketpool/data/voting

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

Se você estiver curioso para se aprofundar nos detalhes da proposta do pDAO e sistema de desafio, 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.