#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 dirigido por la gobernanza de 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 titulares de rETH, Operadores de Nodos y titulares de RPL. El pDAO prioriza la seguridad del protocolo de 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 consultar el estatuto del pDAO.

#Nuevas características del pDAO en Houston

#Ejecución on-chain de las 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 crear propuestas y votar sobre propuestas para ajustar "parámetros del protocolo del pDAO" y gastar fondos del tesoro. Para ver una lista completa de los parámetros controlables por el pDAO, haz clic aquí. Pre-Houston, el equipo central era responsable de ejecutar las tareas del pDAO a petición del proceso de gobernanza comunitaria. Por ejemplo, el equipo realiza los pagos mensuales de IMC y GMC según los calendarios de pago votados por la gobernanza. El plan era que este poder residiera temporalmente en el equipo hasta que se estableciera una nueva estructura de poder para asumir estas responsabilidades. Houston elimina esta dependencia del equipo, haciendo que el protocolo sea más descentralizado y sin necesidad de 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 papel 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 al pDAO según lo definido en RPIP-25. El pDAO puede usar estos fondos para una variedad de propósitos. Por ejemplo, incentivos como bonos de proveedores de liquidez (LP), subvenciones y recompensas para mejoras y proyectos de terceros, y financiamiento del desarrollo del protocolo de Rocket Pool. La actualización Houston también introduce una nueva característica que permite pagos recurrentes del tesoro realizados a un beneficiario especificado cada período de recompensas.

#Propuestas del DAO del Protocolo (pDAO)

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

• Cambiar configuraciones del 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 del pDAO es una entidad on-chain que existe para ejecutar cambios a nivel de protocolo.

#Ciclo de vida de una propuesta del pDAO

Una propuesta debe ser prevista 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 Demora de Voto: proposal.vote.delay.time
• Fase de Voto 1: proposal.vote.phase1.time
• Fase de Voto 2: proposal.vote.phase2.time
• Ejecución: proposal.execute.time

#Período de Demora 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 optimistamente, 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 los proponentes y desafiadores 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 desafiadores proporcionan un índice en el árbol Merkle-sum que están alegando 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 que no sea derrotada en un desafío al final del período de demora de voto entrará en las etapas de votación.

#Período de Voto 1

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

1. Abstención: El poder de voto del votante se contribuye al quórum pero no está ni a favor ni en contra de la propuesta.
2. A favor: El votante vota a favor de que la propuesta sea ejecutada.
3. En contra: El votante vota en contra de que la propuesta sea ejecutada.
4. Veto: El votante vota en contra de la propuesta así como indicando que considera la propuesta como spam o maliciosa.

Su poder de voto se incluirá en la opción que elijan.

Esto se puede hacer usando el comando:

rocketpool pdao proposals vote

Si se alcanza el quórum de veto (según lo definido por 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 de 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 pasará a la fase 2 independientemente de si se alcanza o no proposal.quorum.

#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 anular el voto de su delegado.

El proceso de anular un voto es bastante simple, solo llama a rocketpool pdao proposals vote durante el período de voto 2 y sigue las indicaciones. El poder de voto del delegado será anulado por el poder de voto del delegante.

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

#Ejecución

Una vez que ambos períodos de votación hayan pasado y la propuesta sea exitosa, la propuesta puede ejecutarse y el cambio (definido por la carga útil) se aplica al protocolo de 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 anteriormente 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 mediante 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 requisito previo 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. Veamos un ejemplo de cómo se ve desafiar una propuesta fraudulenta. Podemos usar el comando de 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 que se creó 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 lucen estas Instantáneas de Información de Votación, puedes localizarlas en este directorio: ~/.rocketpool/data/voting

Debido a que el proponente fue sorprendido enviando información de votación incorrecta, nuestro nodo hace una llamada de 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.

Dado que 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 automáticamente hace la llamada de contrato defeatProposal en la propuesta 177 en el índice 5 para finalizar la propuesta.

Ahora que la propuesta es derrotada, nuestro nodo (el desafiador) 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, consulta 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 entra en detalles de bajo nivel.