1. Introducción
El modelo de Salida de Transacción No Gastada (UTXO) de Bitcoin, aunque elegante para la transferencia concurrente de moneda, presenta limitaciones significativas para implementar contratos inteligentes complejos y con estado debido a su falta de estado mutable compartido. Los covenants emergen como una primitiva lingüística crítica propuesta para extender Bitcoin Script, permitiendo que una transacción imponga restricciones en los scripts de las transacciones de canje futuras. Este artículo aborda la brecha en modelos formales y abstractos para los covenants, que se han descrito principalmente desde una perspectiva de bajo nivel y centrada en la implementación desde su concepción alrededor de 2013. Al proporcionar una base formal, el trabajo pretende simplificar el razonamiento sobre las propiedades de los contratos, permitir la especificación de casos de uso avanzados más allá de las capacidades actuales de Bitcoin y facilitar el diseño de abstracciones de programación de mayor nivel.
2. El Modelo Bitcoin Puro
El artículo adapta una formalización del modelo central de transacciones de Bitcoin. En el modelo UTXO, el estado de la cadena de bloques se define por un conjunto de salidas de transacción no gastadas. Cada salida contiene un valor (cantidad de bitcoin) y un scriptPubKey (script de bloqueo) que especifica las condiciones requeridas para gastarlo. Una transacción de gasto proporciona un scriptSig (script de desbloqueo) y hace referencia al UTXO que desea consumir. La validación implica ejecutar los scripts concatenados. Crucialmente, el Bitcoin Script estándar es limitado: no puede introspeccionar o restringir la estructura de la transacción de gasto más allá de la verificación de firmas y la aritmética/lógica básica, impidiendo la creación de contratos que hagan cumplir protocolos de múltiples pasos.
3. Modelo Formal de los Covenants
La contribución central es un modelo formal que abstrae los opcodes de covenant propuestos (como OP_CHECKTEMPLATEVERIFY).
3.1. Primitivas y Sintaxis de los Covenants
El modelo introduce predicados de covenant como extensiones de Bitcoin Script. Un covenant es esencialmente una restricción $C(T_x, T_{next})$ que se evalúa como verdadera o falsa, donde $T_x$ es la transacción actual que se está gastando y $T_{next}$ es la transacción de gasto propuesta. El predicado puede inspeccionar campos de $T_{next}$, como sus scripts de salida, cantidades o tiempos de bloqueo (locktimes).
3.2. Semántica Operacional
La regla de validación se extiende: Para un UTXO con un covenant, la validación de una transacción de gasto $T_{next}$ requiere no solo que su scriptSig satisfaga el scriptPubKey original, sino también que el predicado del covenant $C$ se cumpla para el par $(T_x, T_{next})$. Esto se define formalmente usando reglas de semántica operacional que integran la verificación del covenant en la lógica de validación existente de Bitcoin.
3.3. Covenants Recursivos y Máquinas de Estado
Una variante poderosa es el covenant recursivo, donde $C$ puede hacer cumplir que la salida de $T_{next}$ contenga el mismo (o un relacionado) covenant $C'$. Esto permite la implementación de máquinas de estado en Bitcoin: cada transacción representa una transición de estado, con el covenant asegurando que se sigan las reglas de la máquina de estado a través de una cadena de transacciones. El artículo formaliza esto como una secuencia de transacciones $T_1, T_2, ..., T_n$ donde para cada $i$, $C(T_i, T_{i+1})$ se cumple.
4. Especificación de Contratos Bitcoin Complejos
El modelo formal se aplica para especificar contratos actualmente inexpresables o engorrosos en Bitcoin puro.
4.1. Bóvedas y Retiros con Bloqueo Temporal
Los covenants pueden crear "bóvedas" donde los fondos robados pueden recuperarse. Una transacción puede requerir que cualquier retiro grande deba ir primero a una salida con bloqueo temporal, permitiendo al propietario cancelarlo si no fue autorizado. Esto se especifica mediante un covenant que verifica el campo nLockTime y la estructura de salida de $T_{next}$.
4.2. Canales de Pago y Lightning Network
Aunque Lightning Network existe, los covenants pueden simplificar y asegurar su construcción subyacente. Pueden hacer cumplir que la transacción de cierre de un canal debe ser el estado más reciente, previniendo la difusión de estados antiguos, al restringir la transacción de gasto para que coincida con una actualización previamente firmada.
4.3. Primitivas de Finanzas Descentralizadas (DeFi)
Se vuelven posibles construcciones simples de DeFi como deuda colateralizada o intercambios no custodiales. Un covenant puede bloquear fondos en una transacción que solo puede gastarse mediante una transacción que presente una prueba criptográfica válida de pago de una contraparte o de liquidación.
5. Primitivas de Lenguaje de Alto Nivel
El artículo discute cómo los covenants pueden servir como objetivo de compilación para lenguajes de contrato de alto nivel. Primitivas como "retirar después del tiempo T", "gastar solo si la contraparte firma" o "transicionar el estado de A a B" pueden mapearse directamente a restricciones específicas de covenant, elevando el nivel de abstracción para los desarrolladores de contratos Bitcoin.
6. Perspectiva Central y del Analista
Perspectiva Central: Bartoletti et al. no solo están proponiendo otro opcode de covenant; están entregando la teoría formal faltante que convierte un truco ingenioso en un paradigma de programación legítimo y analizable para Bitcoin. Esta es la clave que desbloquea la ingeniería sistemática de contratos complejos y seguros en blockchains UTXO, yendo más allá de la programación ad-hoc.
Flujo Lógico: El argumento es convincentemente simple: 1) El modelo UTXO de Bitcoin carece de estado, limitando los contratos. 2) Los covenants propuestos como solución son poco comprendidos formalmente. 3) Por lo tanto, construimos un modelo formal. 4) Usando este modelo, demostramos que puede expresar casos de uso valiosos y complejos (bóvedas, canales, DeFi). 5) Este formalismo luego habilita naturalmente el diseño de lenguajes de alto nivel. Es un clásico pipeline de "la teoría habilita la práctica" ejecutado con precisión.
Fortalezas y Debilidades: La mayor fortaleza es cerrar la brecha entre la teoría de criptografía/lenguajes de programación y la ingeniería de Bitcoin—una brecha que ha llevado a errores costosos en el modelo basado en cuentas de Ethereum. La semántica formal permite la verificación de propiedades, una gran ventaja. La debilidad, reconocida implícitamente, es la economía política de Bitcoin. Como señala el artículo, el "enfoque extremadamente cauteloso" de Bitcoin hace que implementar nuevos opcodes como los covenants sea una tarea hercúlea, independientemente de su elegancia formal. El éxito de las soluciones de Capa 2 como Lightning sin covenants nativos también plantea preguntas sobre la necesidad versus la conveniencia. Además, la seguridad del modelo descansa en la suposición de que los campos restringidos (como los hashes de script) son suficientes; podrían permanecer efectos de interacción imprevistos con otros opcodes.
Conclusiones Accionables: Para investigadores, este artículo es un plano: usar métodos formales para reducir riesgos y clarificar actualizaciones de blockchain. Para desarrolladores, comiencen a diseñar marcos de contrato ahora asumiendo que existirán covenants (como se ve en Liquid o Stacks). Para los desarrolladores del protocolo Bitcoin, el artículo proporciona la base rigurosa necesaria para argumentar a favor de BIP 119 (OP_CTV) o propuestas similares—transforma una solicitud de característica en una especificación de ingeniería. La conclusión más importante: el futuro de los contratos inteligentes de Bitcoin no se trata de imitar a Ethereum, sino de aprovechar el paradigma único UTXO+covenants para crear una nueva clase de aplicaciones descentralizadas, potencialmente más seguras y escalables.
7. Detalles Técnicos y Formalización
El modelo formal define transacciones, scripts y validación contextualmente. Un detalle técnico clave es la representación de la restricción del covenant. Sea $\texttt{tx}$ una transacción. Un covenant puede verse como una función:
$\text{Covenant}_{\text{cond}} : \texttt{tx}_{\text{current}} \times \texttt{tx}_{\text{next}} \times \sigma \rightarrow \{\text{True}, \text{False}\}$
donde $\sigma$ representa el contexto de validación (altura del bloque, etc.). El predicado $\text{cond}$ puede ser una conjunción de verificaciones en los campos de $\texttt{tx}_{\text{next}}$:
$\text{cond} \equiv (\texttt{hashOutputs}(\texttt{tx}_{\text{next}}) = H) \land (\texttt{nLockTime}(\texttt{tx}_{\text{next}}) > T) \land ...$
Esto se alinea con propuestas como OP_CHECKTEMPLATEVERIFY, que coloca un hash de partes especificadas de la transacción de gasto en la pila para comparación. La propiedad recursiva se formaliza asegurando que una salida de $\texttt{tx}_{\text{next}}$ contiene un script $S'$ que a su vez hace cumplir un covenant $\text{Covenant}_{\text{cond}'}$.
8. Marco de Análisis y Caso de Ejemplo
Ejemplo: Un Contrato Simple de Bóveda
Objetivo: Crear un UTXO que pueda gastarse de dos maneras: 1) Instantáneamente, pero solo a una dirección específica de "almacenamiento en frío". 2) A cualquier dirección, pero solo después de un retraso de 30 días (permitiendo la cancelación en caso de robo).
Aplicación del Marco usando el Modelo Formal:
1. Script de Bloqueo Inicial (scriptPubKey): Contiene una condición de covenant $C_1$.
2. Covenant $C_1(T_{vault}, T_{spend})$: Debe evaluarse como Verdadero. Verifica:
a) Ruta A (Instantánea): $\texttt{hashOutputs}(T_{spend}) = H_{cold}$ // La salida debe tener un hash que coincida con la dirección de almacenamiento en frío precomprometida.
b) Ruta B (Retrasada): $\texttt{nLockTime}(T_{spend}) \geq \text{currentBlock} + 4320$ (30 días en bloques) Y $\texttt{hashOutputs}(T_{spend})$ puede ser cualquier cosa.
3. Validación: Al gastar el UTXO de la bóveda con $T_{spend}$, el nodo Bitcoin ejecuta el script. Requiere una firma del propietario de la bóveda y verifica que $C_1$ se cumple para el par de transacciones.
Este ejemplo demuestra cómo el predicado $C(T_x, T_{next})$ del modelo formal se instancia con verificaciones concretas en los campos de la siguiente transacción, permitiendo una propiedad de seguridad (recuperación ante robo) imposible en Bitcoin base.
9. Aplicaciones Futuras y Direcciones
La formalización abre varias vías futuras:
- Compiladores Verificados: Construir compiladores desde lenguajes de alto nivel (como extensiones de Simplicity o Miniscript) a Bitcoin Script con covenants integrados, con pruebas formales de corrección.
- Covenants Inter-Cadena: Explorar covenants que condicionen gastos a eventos de otras blockchains u oráculos, usando pruebas criptográficas como SPV, como sugiere trabajos anteriores sobre "puentes" e investigaciones recientes sobre rollups.
- Covenants que Preservan la Privacidad: Integrar verificaciones de covenant con pruebas de conocimiento cero (por ejemplo, usando firmas Taproot/Schnorr) para ocultar la lógica del contrato mientras aún se hace cumplir, una dirección explorada en proyectos como Ark.
- Análisis Formal de Seguridad: Usar el modelo para analizar sistemáticamente la seguridad de las construcciones de covenant propuestas contra ataques económicos y criptográficos, similar al trabajo realizado en los contratos inteligentes de Ethereum por la comunidad del IEEE Symposium on Security and Privacy.
- Simplificación de Protocolos de Capa 2: Rediseñar protocolos como Lightning Network o sidechains (Liquid) para que sean más eficientes y minimicen la confianza aprovechando covenants nativos, reduciendo la necesidad de torres de vigilancia complejas o federaciones.
10. Referencias
- M. Bartoletti, S. Lande, R. Zunino. Bitcoin covenants unchained. arXiv:2006.03918v2 [cs.PL]. 2020.
- S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008.
- J. Poon, T. Dryja. The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments. 2016.
- M. Moser, I. Eyal, E. G. Sirer. Bitcoin Covenants. Financial Cryptography 2016 Workshops.
- Bitcoin Improvement Proposal 119 (BIP 119). OP_CHECKTEMPLATEVERIFY.
- G. Wood. Ethereum: A Secure Decentralised Generalised Transaction Ledger. Ethereum Yellow Paper. 2014.
- A. Miller, et al. Hashed Timelock Contracts (HTLCs). 2017.
- R. O'Connor. Simplicity: A New Language for Blockchains. Proceedings of the 2017 Workshop on Programming Languages and Analysis for Security.
- Blockstream. Liquid Network. https://blockstream.com/liquid/
- IEEE Symposium on Security and Privacy. Multiple papers on smart contract security analysis. Various years.