Anastasia Labs conecta la gobernanza de Cardano con la ejecución de dApps

Anastasia Labs ha demostrado una conexión directa entre la gobernanza de Cardano y la ejecución dentro de una aplicación descentralizada. A lo largo de 13 transacciones confirmadas en SanchoNet, una dApp de ejemplo respondió a un cambio promulgado en los parámetros del protocolo aumentando su propia comisión de 1 ADA a 2 ADA.

La prueba en SanchoNet conecta la gobernanza con cambios en la dApp

La gobernanza de Capa 1 de Cardano puede aprobar cambios en los parámetros del protocolo, retiros de la Treasury, hard forks y actualizaciones del Constitutional Committee. Las dApps individuales suelen operar bajo sistemas de gobernanza separados que pueden depender de claves de administrador, billeteras multifirma o DAOs específicas de la aplicación.

Anastasia Labs desarrolló un patrón de diseño de código abierto que permite a una dApp usar una decisión de gobernanza de Cardano promulgada como autorización para cambiar su propio estado. La implementación fue escrita en Aiken para Plutus V3 y publicada en el repositorio aiken-design-patterns del equipo.

La demostración utilizó una acción de gobernanza que modificó una entrada en el modelo de costos de Plutus V3. Después de que el cambio completó el proceso de gobernanza y se activó en SanchoNet, la dApp reconoció el modelo actualizado y acuñó un token de autorización llamado PASS. Una transacción final quemó el token y aumentó la comisión de la aplicación de 1 ADA a 2 ADA.

El ledger de Cardano proporciona la señal de gobernanza

La implementación no inspecciona el historial de votación ni depende de la identidad de una acción de gobernanza específica. En su lugar, verifica el modelo de costos de Plutus activo aplicado por el ledger de Cardano después de que se haya promulgado el cambio de parámetro.

Esto elimina la necesidad de un oráculo externo para confirmar que una propuesta ha sido aprobada. La validación tampoco requiere una clave de administrador del proyecto, aprobación multifirma ni un indexador de backend. El ledger aplica el nuevo parámetro, mientras que el validador de la dApp compara el modelo de costos activo con el valor registrado en su propuesta.

La prueba de 13 transacciones abarcó la publicación de scripts de referencia, la inicialización de los estados de la aplicación y de gobernanza, el envío de la acción de parámetro vinculada, la acuñación del token PASS tras la promulgación y la ejecución del cambio de comisión.

Philip DiSarro de Anastasia Labs describió el resultado como la prueba de algo previamente considerado imposible. Los contratos inteligentes de Plutus no pueden leer directamente el resultado de una acción de gobernanza promulgada mediante un campo dedicado. El patrón de diseño en su lugar autentica el modelo de costos activo disponible durante la ejecución del script.

Solo las dApps de adopción voluntaria pueden usar el modelo

El patrón no otorga a la gobernanza de Cardano control sobre aplicaciones arbitrarias. Los desarrolladores deben integrar deliberadamente los validadores requeridos, definir los cambios de estado permitidos y conectar la ejecución a la señal de gobernanza seleccionada.

La prueba publicada solo demostró un cambio en la comisión de una aplicación de muestra. Anastasia Labs ha identificado actualizaciones de contratos, cambios de parámetros de dApps, operaciones de la Treasury y controles de emergencia como posibles aplicaciones, pero esos casos de uso no formaron parte de la ejecución documentada en SanchoNet.

El modelo también tiene limitaciones no resueltas. Su señal no está vinculada a un Governance Action ID único, su configuración de temporización depende de una configuración multifirma y la autorización requiere un cambio real en un modelo de costos de la red. No se ha anunciado ninguna auditoría de seguridad independiente, integración en producción ni despliegue en la mainnet de Cardano.

El resultado es un patrón de diseño de aplicaciones de código abierto, no una nueva función del protocolo de Cardano. Ofrece a los desarrolladores una ruta comprobada para reemplazar una clave de aprobación controlada por el proyecto con una decisión de gobernanza de Capa 1 promulgada, siempre que la dApp esté diseñada desde el principio para aceptar esa autoridad.