#El DAO del Protocolo (pDAO)

El DAO del Protocolo de Rocket Pool (pDAO) es responsable de dar forma a la dirección del protocolo y es administrado por la gobernanza RPL. Sus miembros y su poder de voto están compuestos por operadores de nodos, grandes y pequeños, todos los cuales participan directamente en el protocolo. Sirve a la comunidad de Rocket Pool en general, incluyendo a los titulares de rETH, Operadores de Nodos y titulares de RPL. El pDAO prioriza la seguridad del protocolo Rocket Pool y la salud de la Red Ethereum. Para una definición explícita de quién y qué es el pDAO, siéntete libre de echar un vistazo a la carta del pDAO.

#Nuevas funciones del pDAO en Houston

#Ejecución on-chain de responsabilidades del pDAO

La Actualización Houston introduce un reemplazo on-chain para el proceso de ejecución del sistema de gobernanza del pDAO. Utiliza un sistema de prueba de fraude optimista que permite a cualquier operador de nodo presentar propuestas y votar sobre propuestas para ajustar "parámetros del protocolo pDAO" y gastar fondos del tesoro. Para ver una lista completa de parámetros controlables por el pDAO, haz clic aquí. Pre-Houston, el equipo principal era responsable de ejecutar las tareas del pDAO a instancias del proceso de gobernanza de la comunidad. Por ejemplo, el equipo lleva a cabo los pagos mensuales del IMC y GMC según los calendarios de pago votados por la gobernanza. El plan era que este poder residiera temporalmente con el equipo hasta que se estableciera una nueva estructura de poder para asumir estas responsabilidades. Houston elimina esta dependencia del equipo, haciendo el protocolo más descentralizado y sin confianza.

#Consejo de Seguridad

La actualización Houston también incluye un nuevo consejo de seguridad para ayudar a reaccionar rápidamente en caso de cualquier problema potencial con el protocolo. Estos miembros pueden ser elegidos por el pDAO y tienen la capacidad de proponer y ejecutar cambios sin demora. El pDAO tiene el poder de elegir y remover miembros del consejo de seguridad. Es un rol serio y el pDAO debe desarrollar requisitos de entrada sólidos y procesos para eliminar miembros obsoletos. El guardián del pDAO será el único miembro del consejo de seguridad al inicio de Houston.

#Gastos Recurrentes del Tesoro

RPL tiene una tasa de inflación del 5%. El 22% de esta inflación se dirige hacia el pDAO como se define en RPIP-25. El pDAO puede usar estos fondos para una variedad de propósitos. Por ejemplo, incentivos como bonos para proveedores de liquidez (LP), subvenciones y recompensas por mejoras y proyectos de terceros, y financiación del desarrollo del protocolo Rocket Pool. La actualización Houston también introduce una nueva función que permite pagos recurrentes del tesoro hechos a un beneficiario especificado cada período de recompensas.

#Propuestas del DAO del Protocolo (pDAO)

Cualquier nodo con un poder de voto no nulo puede presentar o participar en una propuesta pDAO en cualquier momento. Las propuestas pueden ser de uno de los siguientes tipos:

• Cambiar configuraciones pDAO
• Gastos únicos del tesoro
• Gastos recurrentes del tesoro (comités de gestión)
• Membresía del consejo de seguridad

Para mayor detalle y justificación, consulta tipos de propuestas. Es importante entender que una propuesta pDAO es una entidad on-chain que existe para ejecutar cambios a nivel de protocolo.

#Ciclo de vida de una propuesta pDAO

Una propuesta debe ser anticipada por el proceso de gobernanza antes de terminar on-chain. Consiste en 4 Períodos, todos los cuales son parámetros controlables del pDAO:

• Período de Retraso de Voto: proposal.vote.delay.time
• Fase 1 de Voto: proposal.vote.phase1.time
• Fase 2 de Voto: proposal.vote.phase2.time
• Ejecución: proposal.execute.time

#Período de Retraso de Voto

Para decidir el resultado de una propuesta, el protocolo debe conocer el quórum requerido. Un proponente calcula este valor off-chain y lo envía junto con su propuesta. El valor se acepta de forma optimista, pero en caso de fraude, los verificadores pueden realizar un proceso de desafío/respuesta para probar que el valor es incorrecto. Las propuestas inválidas luego se descartan.

Algunas razones por las que se requiere que proponentes y desafiantes bloqueen RPL.

• proposal.bond incentiva propuestas válidas y desincentiva el spam.
• proposal.challenge.bond incentiva la eliminación de propuestas inválidas/maliciosas.

Los desafiantes proporcionan un índice en el árbol Merkle-sum que alegan que es incorrecto. Cualquier operador de nodo puede participar en desafiar propuestas fraudulentas (y ganar una recompensa al hacerlo). Siéntete libre de leer sobre el Proceso de Desafío del pDAO si estás interesado en optar por participar. Una propuesta no derrotada en un desafío al final del período de retraso de voto entrará en etapas de votación.

#Período de Voto 1

Durante un período de votación, los Operadores de Nodo y Delegados pueden emitir un voto con una de cuatro opciones:

1. Abstain: El poder de voto del votante se contribuye al quórum pero no está ni a favor ni en contra de la propuesta.
2. For: El votante vota a favor de que la propuesta sea ejecutada.
3. Against: El votante vota en contra de que la propuesta sea ejecutada.
4. Veto: El votante vota en contra de la propuesta además de indicar que considera la propuesta como spam o maliciosa.

Su poder de voto se incluirá en la opción de su elección.

Esto se puede hacer usando el comando:

rocketpool pdao proposals vote

Si se alcanza el quórum de veto (como lo define el parámetro proposal.veto.quorum), la propuesta es inmediatamente derrotada y el proponente pierde su bono. Esto es para disuadir el spam, propuestas de baja calidad o propuestas que no han pasado por procesos off-chain primero. El comando del smartnode rocketpool pdao proposals finalize se usa para finalizar una propuesta vetada quemando el bono de RPL bloqueado del proponente.

La duración del período 1 está determinada por el parámetro proposal.vote.phase1.time. La propuesta entrará en la fase 2 independientemente de si se alcanza proposal.quorum o no.

#Período de Voto 2

Los delegados pueden votar durante el período de voto 2, pero solo su voto vale su poder de voto local. Los votantes que no votaron en el período 1 aún podrán emitir un voto durante el período 2. Los operadores de nodos que no estén de acuerdo con la elección de su delegado tendrán la oportunidad de revocar el voto de su delegado.

El proceso de revocar un voto es bastante simple, solo llama a rocketpool pdao proposals vote durante el período de voto 2 y sigue los mensajes. El poder de voto del delegado será revocado por el poder de voto del delegatario.

El resultado de una propuesta se concluye cuando termina el período de voto 2. Para que se determine un resultado (y se ejecute), se debe alcanzar proposal.quorum de poder de voto total al final de proposal.vote.phase2.time. Si se alcanza el quórum y se llega a consenso, la propuesta pasará los períodos de votación y será marcada como exitosa.

#Ejecución

Una vez que ambos períodos de votación han pasado y la propuesta es exitosa, la propuesta puede ser ejecutada y el cambio (definido por el payload) se aplica al protocolo Rocket Pool. Para ejecutar una propuesta, usa el comando:

rocketpool pdao proposals execute

Se te pedirá que selecciones una propuesta para ejecutar, ¡la propuesta se aplicará al protocolo después de este paso!

Después de que la propuesta haya pasado los períodos de votación, el proponente puede reclamar su bono de RPL bloqueado, a menos que la propuesta haya sido derrotada por un desafío o vetada.

¡Y eso es todo! Ten en cuenta que todas las variables mencionadas arriba son parámetros controlables por el pDAO. Haz clic aquí para obtener una lista completa de cada parámetro que el pDAO tiene autoridad para cambiar usando propuestas on-chain.

#Proceso de Desafío

El árbol completo de poder de voto de la red se almacena off-chain debido a los límites de gas. Cuando un usuario envía una nueva propuesta, es responsable de construir el árbol de votación de la red en el número de bloque objetivo. Este árbol se genera off-chain pero es verificable a través de raíces Merkle que se envían on-chain. El protocolo depende de verificadores para verificar los detalles enviados por el proponente.

Cualquier nodo puede participar en el seguimiento y verificación de la corrección de las propuestas. Para optar por esta responsabilidad, usa el comando rocketpool service config, navega al menú Smartnode and TX Fee Settings, y marca la casilla Enable PDAO Proposal Checker.

Cuando esta configuración está habilitada, el nodo verificará nuevas propuestas, verificará su corrección y enviará desafíos a propuestas inválidas. El único prerrequisito es que el Bloqueo de RPL esté habilitado.

Esta verificación se ejecuta cada 5 minutos junto con algunas otras tareas relacionadas con el nodo. Revisaremos un ejemplo de cómo se ve desafiar una propuesta fraudulenta. Podemos usar el comando del smartnode rocketpool service logs node para monitorear el progreso:

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 nuestro nodo ha detectado una propuesta fraudulenta y comenzó el proceso de desafiarla. El bloque 1283202 es el bloque en el cual se presentó la propuesta 177, lo que significa que el poder de voto para esta propuesta se calculará en el bloque 1283202. Si estás interesado en ver cómo se ven estos Snapshots de Información de Votación, puedes localizarlos en este directorio: ~/.rocketpool/data/voting

Como el proponente fue atrapado enviando información de votación incorrecta, nuestro nodo hace una llamada al contrato Function: createChallenge en la propuesta 177 en el índice 5 y espera a que el proponente responda al desafío.

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 la información de votación del proponente es incorrecta, no podrá responder al desafío a tiempo (determinado por proposal.challenge.period). La propuesta se considera derrotada en este punto. Cuando la propuesta es derrotada, nuestro nodo hace automáticamente la llamada al contrato defeatProposal en la propuesta 177 en el índice 5 para terminar la propuesta.

Ahora que la propuesta está derrotada, nuestro nodo (el desafiante) puede reclamar su bono de RPL original así como el bono de RPL del proponente como recompensa por derrotar una propuesta fraudulenta.

Si tienes curiosidad por profundizar en los detalles del sistema de propuestas y desafíos del pDAO, echa un vistazo a las especificaciones técnicas. Siéntete libre de saltar a esta sección sobre el proceso de desafío si estás interesado en estudiar un ejemplo que profundiza en detalles de bajo nivel.