Saltar al contenido
Financial Context Wiki

Bloqueos temporales: transacciones y acciones de gobernanza diferidas

Un bloqueo temporal obliga a una transacción o acción contractual a esperar hasta un bloque, una marca de tiempo o un intervalo. Conoce cómo se impone y qué rutas pueden eludirlo.

Actualizado

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

Respuesta directa

Un bloqueo temporal es una regla que una cadena de bloques o un contrato inteligente impone para impedir que una transacción, un gasto o una acción administrativa sean válidos o ejecutables hasta alcanzar una altura de bloque, una marca de tiempo o un intervalo determinado. Cambia cuándo puede ocurrir una acción; no determina si la acción es correcta.

El término abarca mecanismos distintos. Un bloqueo a nivel de transacción puede impedir el gasto de una moneda o mantener una transacción sin finalidad hasta que se cumpla una condición de la cadena. Un bloqueo de gobernanza pone en cola una llamada contractual ya autorizada y exige una demora mínima antes de que un ejecutor pueda enviarla. Sus relojes, transiciones de estado y modos de fallo son diferentes.

El valor de seguridad proviene de una demora exigible. En gobernanza, puede dar tiempo a monitores y usuarios para revisar la carga en cola, alertar, cancelar o pausar mediante una vía autorizada, o salir si existe una ruta real de salida. La ventaja desaparece ante cualquier vía privilegiada capaz de modificar el mismo sistema sin pasar por el bloqueo.

Cómo funciona

  1. El mecanismo define un reloj. El umbral puede usar altura de bloque, una marca de tiempo derivada de la cadena o tiempo medido desde un evento anterior en cadena. Son valores del protocolo, no promesas de hora civil exacta.
  2. La acción bloqueada se vincula a una condición. Un bloqueo absoluto fija una altura u hora futura. Uno relativo mide un intervalo desde un evento, como la confirmación de la salida que se gastará. Un controlador de gobernanza registra una operación programada y su momento de disponibilidad.
  3. La capa correspondiente impone la espera. Las reglas de consenso pueden rechazar una transacción o gasto de script prematuros. Un contrato inteligente puede rechazar una llamada anticipada. Una cuenta atrás en un sitio web no es un bloqueo porque la interfaz puede eludirse.
  4. El vencimiento cambia la elegibilidad, no la intención. Al cumplirse la condición, la acción puede ser válida o estar lista, pero no necesariamente se difunde o ejecuta de forma automática. Alguien debe enviarla y siguen aplicándose las demás comprobaciones de autorización y validez.
  5. La cobertura depende de la autoridad. En gobernanza, el bloqueo debe poseer el contrato objetivo o sus roles necesarios, y toda vía privilegiada equivalente también debe estar demorada. Los permisos de proponente, cancelador, ejecutor y administrador determinan quién puede programar, detener, ejecutar o reconfigurar operaciones.

Bitcoin muestra la diferencia transaccional. BIP 65 especifica CHECKLOCKTIMEVERIFY, que puede impedir gastar una salida hasta alcanzar una condición absoluta de altura o tiempo. BIP 68 da a los números de secuencia de entradas aptas un significado de bloqueo relativo impuesto por consenso, medido desde la antigüedad de la salida gastada. Estas reglas no son la cola de un contrato de gobernanza.

TimelockController de OpenZeppelin ejemplifica la demora de gobernanza. Un proponente programa una operación identificada con una demora al menos igual a la mínima. Tras vencer el temporizador pasa de espera a lista; después debe ejecutarla un ejecutor. La cancelación y los roles siguen las reglas del contrato, y cambiar la demora mínima debe pasar por el propio bloqueo.

Ejemplos

Actualización de protocolo en cola

Una DAO aprueba una actualización y su gobernador programa en el bloqueo la dirección objetivo, el valor, los datos de llamada, la dependencia y la sal exactos. Durante la demora, las herramientas de vigilancia pueden comparar la carga con la propuesta y simular sus efectos. Cuando la operación está lista, la envía un ejecutor autorizado.

La protección solo existe si el bloqueo controla la autoridad de actualización. Si otro propietario, administrador de proxy, consejo de seguridad o módulo puede instalar de inmediato la misma actualización, esa vía de elusión debe evaluarse aparte. La demora también es útil solo si la vigilancia llega a tiempo y el retiro o la migración pueden terminar antes de la ejecución.

Ruta de transacción demorada

Un script puede ofrecer una ruta de gasto antes de un plazo y otra de reembolso después. La cadena impone la condición al validar el gasto. Alcanzar el umbral no mueve los fondos: la parte habilitada debe construir y difundir una transacción válida, cuya confirmación sigue dependiendo de las comisiones y la inclusión en un bloque.

Riesgos y lista de revisión

  • Autoridad de elusión: otro propietario, rol, módulo, clave de actualización o vía de emergencia puede ejecutar la acción protegida sin esperar.
  • Reloj o límite equivocados: altura, tiempo de cadena y tiempo transcurrido no son intercambiables; un error de una unidad puede habilitar el gasto antes o después de lo previsto.
  • Demora insuficiente: la espera puede ser menor que el tiempo necesario para detectar, analizar, comunicar y responder a una acción.
  • Sin salida práctica: retiros pausados, demoras de puentes, iliquidez, desvinculación o congestión pueden impedir actuar durante la ventana nominal.
  • Rol comprometido o bloqueo operativo: un proponente o administrador malicioso puede poner llamadas dañinas en cola; ejecutores perdidos o derechos de cancelación demasiado amplios pueden bloquear operaciones legítimas.
  • Carga no coincidente: un título legible no demuestra que el objetivo, valor, datos, dependencia y sal programados implementen lo aprobado.
  • Diferencias de implementación: vencimiento, cancelación, lotes, dependencias, ejecución abierta y cambios de demora varían por contrato y versión.
  • Error de bloqueo: una marca, altura, secuencia, rama de script o clave incorrecta puede dejar los activos inaccesibles más tiempo del esperado.

Errores comunes

¿Un bloqueo temporal se ejecuta automáticamente al vencer?

Por lo general, no. El vencimiento normalmente solo habilita la acción. La transacción debe difundirse o un ejecutor debe llamar al contrato de gobernanza.

¿Un bloqueo temporal hace segura la gobernanza?

No. Crea tiempo de reacción, pero no valida la carga, protege claves privilegiadas, garantiza la cancelación ni asegura que los usuarios puedan salir. Una autoridad paralela sin demora puede anular el control.

¿Todos los bloqueos usan la hora civil?

No. Algunos usan altura de bloque, otros marcas de tiempo de la cadena y otros una antigüedad relativa. Los intervalos de bloque esperados y las marcas no son calendarios exactos.

¿Son intercambiables los bloqueos de transacción y gobernanza?

No. Comparten la idea de elegibilidad demorada, pero las reglas de consenso, las condiciones de script y las colas de gobernanza protegen acciones distintas y deben revisarse según sus propias especificaciones.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...