Saltar al contenido
Financial Context Wiki

¿Cómo funciona un timelock de gobernanza?

Un timelock de gobernanza convierte una acción aprobada en una operación observable públicamente que debe esperar antes de ejecutarse. Descubre cómo funcionan los ID, los roles, los retrasos, el vencimiento, la cancelación y las ventanas de salida.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

Respuesta directa

Un timelock de gobernanza es un controlador de ejecución, no otra votación. Después de que la gobernanza autoriza una carga de datos, un proponente autorizado programa la operación exacta. El contrato registra cuándo puede empezar a ejecutarse y rechaza la ejecución antes de ese momento. Este retraso permite observar una actualización, un cambio de parámetros, una transferencia de tesorería o un cambio de roles pendientes antes de que entren en vigor.

El retraso anunciado es solo una parte del control. Hay que revisar el ID de la operación, el momento de ejecución más temprano, cualquier regla de vencimiento, la operación predecesora, el proponente, el ejecutor, el cancelador, el administrador y todas las demás vías que puedan controlar el contrato objetivo. Un timelock de 48-hour no proporciona una ventana de salida de 48-hour si la operación se programa tarde, la supervisión se demora, los retiros tardan más o existe otra clave privilegiada capaz de realizar el mismo cambio de inmediato.

Un timelock no decide si una acción es legítima o segura. Proporciona tiempo para que las personas y los monitores automatizados decodifiquen las llamadas, simulen sus efectos, cancelen o pausen cuando estén autorizados, comuniquen el cambio y salgan de sus posiciones cuando exista una vía de salida real.

Cómo funciona

  1. La autoridad se asigna al timelock. El timelock debe ser propietario del contrato objetivo o tener en él el rol pertinente. Si un gobernador no tiene autoridad sobre el objetivo, aprobar una propuesta no cambia nada; si un administrador independiente conserva autoridad paralela, esa vía puede eludir el retraso.
  2. Un proponente programa una operación exacta. En el TimelockController de OpenZeppelin, el ID de una operación individual es el hash de target, value, data, predecessor y salt; las operaciones por lotes calculan el hash de los arrays correspondientes, junto con la misma dependencia y el mismo salt. Cambiar cualquier campo produce un ID de operación distinto. El salt permite distinguir acciones que, de otro modo, serían idénticas.
  3. El retraso mínimo empieza al programar. Una votación aprobada no necesariamente inicia el timelock. La programación registra una marca temporal de disponibilidad usando un retraso que debe ser, como mínimo, el retraso mínimo vigente del contrato. Las operaciones de OpenZeppelin pasan de Unset a Waiting, después a Ready y, por último, a Done tras ejecutarse correctamente.
  4. Las dependencias y los permisos se comprueban al ejecutar. Una operación predecesora debe estar ya en estado Done. La persona que llama debe cumplir la regla del ejecutor y la llamada al objetivo debe completarse correctamente. Un ejecutor no puede modificar la carga de datos programada. Conceder el rol de ejecutor a address(0) permite que cualquiera ejecute tras el vencimiento del retraso; esto mejora la disponibilidad, pero permite que cualquier cuenta elija el momento exacto de ejecución una vez que la operación sea apta.
  5. La cancelación devuelve una operación pendiente a su estado inicial. En los contratos actuales de OpenZeppelin, una cuenta con CANCELLER_ROLE puede cancelar una operación mientras esté pendiente, incluso si ya está lista pero todavía no se ha ejecutado. Volver a programarla inicia un temporizador nuevo. La configuración de roles importa: versiones anteriores y otros timelocks pueden asignar la cancelación al proponente o al administrador.
  6. El vencimiento depende de la implementación. El TimelockController de OpenZeppelin no incorpora un vencimiento por período de gracia; una operación lista permanece en ese estado hasta que se ejecuta o cancela. En cambio, el Timelock de Compound v2 exige ejecutar como máximo en eta + GRACE_PERIOD, y su código fuente fija GRACE_PERIOD en 14 days. Governor Bravo marca una propuesta programada como vencida una vez superado ese límite.
  7. La administración también debe estar sujeta al retraso. OpenZeppelin solo permite ejecutar updateDelay mediante una llamada del timelock a sí mismo. De forma similar, un despliegue autoadministrado obliga a que los cambios de roles pasen por operaciones programadas. Un administrador externo temporal utilizado durante la configuración debe renunciar al rol cuando esta termine; de lo contrario, seguirá siendo una vía de confianza independiente.

Para cada acción programada, reconstruye un registro de control a partir del estado y los eventos del contrato: ID de cadena, direcciones del timelock y del objetivo, ID de operación, carga de datos decodificada, proponente, transacción y marca temporal de programación, retraso mínimo, momento de disponibilidad, vencimiento si lo hay, predecesora, política del ejecutor, autoridad de cancelación y estado final de la transacción. No deduzcas estos campos solo a partir de un sitio web de gobernanza.

Ejemplo práctico

Supongamos que una propuesta reduce el umbral de liquidación de un mercado de préstamos del 75% al 60%. La votación termina el Monday 12:00 UTC, pero un proponente no programa la operación hasta el Tuesday 18:00 UTC. El retraso programado es de 48 hours, por lo que el momento de ejecución más temprano es el Thursday 18:00 UTC, no el Wednesday 12:00 UTC.

La operación contiene el contrato de gestión de riesgos como target, un value de cero tokens nativos, los data codificados del cambio de parámetro, ninguna operación predecesora y un salt divulgado. Volver a calcular el hash a partir de esos campos debe dar el mismo ID de operación emitido. Una dirección de mercado, un umbral o un salt diferentes constituyen otra operación, aunque la descripción de la interfaz parezca igual.

Por tanto, los usuarios disponen de 48 hours desde la programación, pero su tiempo de salida utilizable es menor. Si la alerta llega 6 hours después de programar y una cola de retiro o de desbloqueo de staking tarda 24 hours, solo quedan 18 hours de margen:

usable response time = ready time - detection time - exit settlement time

Si una multisig de emergencia puede pausar los retiros de inmediato, puede reducir las pérdidas durante un incidente, pero también impedir la salida antes de que se ejecute el cambio programado. Revisa esa autoridad por separado. Después de la ejecución, verifica el almacenamiento real del contrato objetivo y los eventos emitidos; una transacción de ejecución del timelock puede completarse correctamente aunque el resultado económico esperado siga siendo malinterpretado.

Riesgos y controles

  • Autoridad que permite eludir el retraso. Enumera propietarios, administradores de proxies, roles de control de acceso, beacons de actualización, consejos de emergencia, módulos y ejecutores entre cadenas. La vía privilegiada más corta determina el retraso efectivo.
  • Sustitución de la carga de datos o decodificación deficiente. Vuelve a calcular el ID de operación a partir de los campos sin procesar, identifica las implementaciones de los proxies, decodifica cada selector y argumento y simula el lote completo. El texto legible de una propuesta no es la carga de datos ejecutable.
  • Aviso insuficiente. Genera alertas a partir de los eventos on-chain de programación y cancelación, no solo de publicaciones en foros. Mide el aviso desde la programación confirmada hasta el primer bloque o marca temporal ejecutable, y luego resta el tiempo de detección y liquidación de la salida.
  • Fallo de cancelación. Confirma qué cuentas pueden cancelar, si están operativas, qué umbral exigen y si la cancelación sigue siendo posible cuando la operación ya está lista. Ensaya la transacción antes de un incidente.
  • Fallo del ejecutor o manipulación del momento. Los ejecutores restringidos pueden dejar de estar disponibles o retrasar intencionadamente la ejecución. La ejecución abierta mejora la disponibilidad, pero permite que terceros ejecuten justo al terminar el retraso, por lo que los precios relacionados, las actualizaciones de oráculos y las posiciones de los usuarios deben ser seguros en ese límite.
  • Acciones programadas obsoletas. Cuando no existe vencimiento, las operaciones antiguas que están listas pueden seguir siendo ejecutables indefinidamente. Haz seguimiento de ellas y cancela expresamente las operaciones abandonadas. Cuando exista un período de gracia, vigila su final exacto y exige un nuevo ciclo de gobernanza tras el vencimiento.
  • Riesgo de dependencias y lotes. Verifica el ID de la operación predecesora y el orden del lote atómico. Una sola llamada que revierta puede bloquear un lote atómico; una dependencia incorrecta puede bloquear permanentemente una operación que, por lo demás, sería válida.
  • Administración insegura. Haz que las reducciones del retraso, las concesiones de roles y la sustitución del timelock estén sometidas al propio timelock. Elimina los administradores de despliegue, conserva al menos un proponente y un ejecutor viables y evita una configuración que bloquee el control de forma permanente.
  • Ausencia de una salida viable. Compara el retraso con las colas de retiro, la finalidad de los puentes, la liquidez del mercado, las facultades de pausa y la congestión. Un retraso publicado no protege a los usuarios cuando los activos no pueden salir antes de la ejecución.

El estándar operativo es una cronología respaldada por pruebas, no una cuenta regresiva mostrada en pantalla. Archiva el evento de programación, las llamadas decodificadas, el resultado de la simulación, los titulares de roles, el plan de cancelación, los momentos de ejecución más temprano y más tardío, los canales de comunicación y la diferencia de estado posterior a la ejecución.

Errores comunes

  • «El retraso empieza cuando termina la votación». Normalmente empieza cuando se programa la acción aprobada, salvo que la implementación desplegada vincule explícitamente ambos momentos.
  • «Cualquiera puede ejecutar, así que cualquiera puede cambiar la propuesta». Un ejecutor abierto solo puede activar una carga de datos ya programada cuyo ID de operación y condiciones coincidan.
  • «Que esté lista significa que la acción debe ejecutarse de inmediato». Lista significa apta. La ejecución todavía requiere una transacción, permisos, dependencias satisfechas y una llamada correcta al objetivo.
  • «Todos los timelocks tienen una ventana de ejecución». El vencimiento varía según la implementación. Compound v2 utiliza un período de gracia; el TimelockController de OpenZeppelin no deja vencer por defecto las operaciones listas.
  • «Un timelock largo elimina el riesgo de gobernanza». El retraso solo ayuda cuando la supervisión, la comprensión, la cancelación o pausa, la comunicación y la salida son viables antes de la ejecución. Los administradores paralelos y los retiros bloqueados pueden anular esa ventaja.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...