Covenants, OP_CAT y OP_CTV: Todo lo que necesitas saber sobre la próxima actualización de Bitcoin

Dentro de la comunidad de criptomonedas, la blockchain de Bitcoin es conocida por ser una red lenta, costosa de usar, y con una baja capacidad de cálculo que hace que la creación de smart contracts sea más compleja que con otras blockchains.

Sin embargo, su lentitud, su pequeño espacio de bloque y su baja capacidad de cálculo son características que permiten que Bitcoin sea la red más segura, descentralizada y resistente a la censura que existe. Aumentar el tamaño de sus bloques, por ejemplo, haría crecer demasiado rápido el tamaño de la blockchain, lo que aumentaría los costos de mantenimiento de un nodo de manera demasiado acelerada.

La descentralización de una blockchain depende, ante todo, del número de nodos que comparten el historial de transacciones. Si este historial crece más rápido que las capacidades del hardware, la red corre el riesgo de centralizarse progresivamente, ya que el acceso a la validación se volverá cada vez más caro y menos accesible.

Es en esta ley, la Ley de Moore, donde se basa la descentralización de las blockchains. También explica el trilema de la blockchain, que afirma que una blockchain que quiere ser scalable debe hacer compromisos en su seguridad y descentralización.

En comparación, Ethereum es más scalable que Bitcoin, pero el tamaño de su blockchain crece muy rápidamente, un efecto que centraliza su red con el tiempo. De manera similar, la red Kaspa es más scalable que Bitcoin, también tiene el potencial de volverse más descentralizada, pero hace un compromiso en la seguridad al usar nodos "podados".

Para hacer Bitcoin más rápido, se han imaginado varios tipos de infraestructuras:

- Sidechains, cadenas alternativas que funcionan estrechamente con Bitcoin sin depender realmente de él ni beneficiarse de su seguridad, como la blockchain Liquid (L-BTC) o Stacks (STX);
- Layer 2, infraestructuras que realizan los cálculos fuera de la red principal para finalmente inscribir solo una huella en ella, como BitVM y RGB, que aún están en construcción;
- Lightning Network, una red de canales de liquidez que permite transferencias de BTC casi instantáneas y a bajos costos.

Entre todas las soluciones consideradas, también hay modificaciones de la blockchain de Bitcoin en sí misma, como las actualizaciones Segwit, realizada en 2017, y Taproot, implementada desde 2021.

Más recientemente, el tema de los "covenants" ha ganado visibilidad, generando numerosos debates sobre una posible actualización y un nuevo soft fork de Bitcoin.

Antes de entrar en el fondo del asunto, es necesario entender cómo funciona el lenguaje Script para comprender lo que implican los Covenants y los opcodes.

El mecanismo de transferencia de BTC en Bitcoin es muy diferente al que utilizan las blockchains que emplean la Ethereum Virtual Machine (EVM).

De hecho, mientras que esas blockchains mezclan los mismos tokens recibidos por una dirección, Bitcoin registra cada llegada de BTC a una dirección como una salida de transacción (output) y cada envío a una dirección externa como una entrada de transacción (input) distinta de la suma total que posee el monedero.

Así, las unidades de BTC que poseemos en nuestro monedero de Bitcoin se mantienen en realidad en forma de salidas no gastadas, conocidas como "Unspent Transaction Output" en inglés, abreviado comúnmente como "UTXO".

Estos UTXO funcionan de manera similar a un billete o una moneda, pero de forma digital. Por ejemplo, si recibes 1 Bitcoin, entonces tendrás en tu posesión 1 UTXO con un valor de 1 BTC. Una vez gastado, tu UTXO de 1 BTC se consume como input de la transacción, lo que permite crear un nuevo UTXO de 1 BTC en el monedero que recibe los fondos.

El lenguaje de programación Script es literalmente un script que especifica las condiciones bajo las cuales un UTXO puede ser gastado. Estos scripts son ejecutados durante la verificación de la validez de una transacción por los nodos de la red.

La principal razón por la que no es posible crear aplicaciones tan complejas en Bitcoin como en Ethereum es que el lenguaje Script no es Turing-complete, al igual que Solidity.

Aunque Solidity a menudo se presenta como Turing-complete, en realidad, no lo es del todo. La ejecución de un smart contract en Ethereum depende principalmente de la disponibilidad de gas fees para pagar las transacciones. Sin fondos para cubrir estos fees, ni Ethereum ni Solidity pueden considerarse Turing-complete.

Para ser más preciso, el lenguaje Script de Bitcoin está construido como una pila, o stack en inglés. Los datos se colocan en la pila y los códigos operativos, llamados también opcodes, actúan sobre estos datos; pueden, entre otras cosas, sumar, restar, duplicar o intercambiar los datos de la pila.

Aunque se percibe como limitado en comparación con otros lenguajes, Script es en realidad muy rico y dispone de más de un centenar de opcodes, como OP_RETURN, OP_2DUP, OP_SWAP, OP_ADD, etc.

Además, los opcodes del lenguaje Script permiten hoy en día crear muchas funcionalidades para Bitcoin, como OP_CHECKMULTISIG, que permite direcciones gestionadas por varias claves privadas, o OP_CHECKSEQUENCEVERIFY, que impone una restricción de tiempo relativa, el timelock, permitiendo, entre otras cosas, la creación del Lightning Network y de depósitos fiduciarios (escrow).

Como habrás comprendido, el lenguaje Script no es muy flexible, principalmente porque sus opcodes son limitados. Sin embargo, numerosas propuestas para añadir opcodes a Script han sido consideradas durante varios años.

Los añadidos de opcodes propuestos por la comunidad podrían acercar a Bitcoin y su lenguaje de programación Script a la Turing-completeness de Ethereum, abriendo así la puerta a casos de uso más complejos.

Algunos opcodes incluso permitirían crear covenants, mecanismos que imponen condiciones de gasto más específicas para los UTXO.

La palabra inglesa "covenant" designa un acuerdo formal o un compromiso legal entre dos o más partes. En finanzas, puede tratarse de condiciones que los prestatarios deben respetar en un contrato de préstamo. En un contexto religioso o histórico, puede referirse a una alianza o pacto sagrado. Puede traducirse al español como "convención" o "alianza".

En el caso de Bitcoin, un covenant es un mecanismo que impone condiciones específicas sobre el scriptPubKey utilizado para bloquear un UTXO en la siguiente transacción, estas condiciones están específicamente definidas en el scriptPubKey de la transacción inicial.

En otras palabras, un covenant establece las reglas que debe seguir el script de bloqueo de los BTC, dictando cómo, cuándo y dónde se pueden gastar estos BTC.

Existen diferentes tipos de covenants:

- Covenants de hash de transacción: Este tipo de covenant permite condicionar el desbloqueo de los UTXO en función de la validez de un hash específico presente en la transacción inicial. Esto significa que los BTC solo pueden ser gastados si el hash de la transacción de gasto respeta el hash definido en la transacción inicial. Los covenants de hash de transacción permitirían asegurarse de que una transacción particular haya sido creada o firmada de una manera específica antes de permitir el desbloqueo de los BTC;
‍
- Covenants de introspección de transacción: Este tipo de covenant permite verificar ciertas propiedades internas de la transacción, como sus entradas, salidas o incluso los montos transferidos, antes de permitir el gasto de los UTXO. A diferencia de los covenants de hash de transacción, ofrecen un control sobre los componentes de la transacción misma. Los covenants de introspección de transacción permitirían imponer condiciones de gasto más complejas, pudiendo aplicarse sobre los fees o las salidas de la transacción, por ejemplo;

- Covenants de transformación del script: Este tipo de covenant modifica o impone condiciones sobre el script de desbloqueo de los siguientes UTXO. Permite transformar el script en una transacción posterior, condicionando no solo quién puede gastar los BTC, sino también cómo pueden ser gastados en el futuro. Los covenants de transformación del script permitirían crear cadenas de condiciones sobre varias transacciones, donde cada transacción podría cambiar las reglas de la siguiente;

- Covenants diferidos: Este tipo de covenant impone una restricción que no se aplica inmediatamente, sino que lo será en una transacción futura. Permiten al validador observar todo el script en su conjunto en lugar de ir paso a paso desde la parte superior de la pila. Este tipo de covenant permite diferir la aplicación de una condición hasta un momento específico, probablemente por razones de privacidad o complejidad. Los covenants diferidos permitirían condicionar el acceso a los BTC en función de eventos o criterios futuros, manteniendo las condiciones ocultas o en suspenso hasta que sean necesarias.

Los diferentes opcodes y covenants considerados podrían hacer que Bitcoin sea más scalable, no solo en términos de rapidez en la confirmación de transacciones, sino también en términos de capacidad y flexibilidad de cálculo.

Los covenants podrían aportar numerosas mejoras a Bitcoin y abrir el camino al desarrollo de nuevas aplicaciones, tales como:
‍
- La creación de mecanismos avanzados para asegurar los BTC;
- La mejora del rendimiento de Lightning Network gracias a la implementación de Eltoo;El desarrollo de nuevas infraestructuras de layer 2 como Ark o los rollups;
- La implementación de Payment Pools, estructuras similares a los mezcladores, para reforzar la privacidad;
- La integración directa de protocolos en la cadena principal, permitiendo aplicaciones comparables a las de Ethereum en Bitcoin;
- La mejora de los Discreet Log Contracts (DLC), facilitando en particular la creación de mercados derivados en Bitcoin;
- La creación de pools de minería más descentralizados.

Sin embargo, los covenants no son una solución infalible. De hecho, la implementación de nuevos opcodes no solo podría aumentar las superficies de ataque y las posibilidades de errores debido a la complejidad de los scripts, sino también permitir la creación de covenants que limiten la libertad de los usuarios en el uso de sus BTC.

Esto se debe principalmente a la naturaleza recursiva de algunos covenants.

Un covenant recursivo es un tipo de smart contract que impone reglas no solo al scriptPubKey inicial, sino también a todos los que lo siguen. Si un covenant no se aplica a todos los scriptPubKey siguientes o solo a algunos, no se considera recursivo.

En otras palabras, un covenant recursivo es un smart contract que impone condiciones de gasto a un UTXO, así como a todas las transacciones siguientes, creando una cadena donde cada transacción está sujeta a las reglas establecidas en la transacción inicial.

Un covenant recursivo demasiado restrictivo podría causar pérdidas al propietario de los BTC, perjudicar a toda la red al crear diferentes versiones de la criptomoneda BTC, que no podrían gastarse de la misma manera, afectando así la fungibilidad de los BTC y reduciendo la oferta total disponible.

Tales restricciones podrían imponerse de diversas maneras: por error al crear un smart contract, por obligación si una regulación estricta impidiera el gasto de BTC provenientes de empresas reguladas hacia direcciones blacklistadas, o por elección deliberada del usuario.

A modo de ejemplo, prohibir el gasto de Bitcoins hacia direcciones blacklistadas, por ejemplo, desde su salida de plataformas de intercambio, ya es posible con una regulación estricta mediante la creación de un multisig, donde una plataforma regulada conservaría al menos una clave, como en un monedero multisig 2/2, y tendría prohibido confirmar una transacción que transfiera los BTC a una dirección no conforme a las regulaciones.
‍
De manera similar a los que han adoptado la jerarquía de satoshis de la teoría Ordinals (que no existe en la red de Bitcoin como tal), estos usuarios podrían crear un covenant Ordinals que haga imposible mezclar los satoshis raros con otros.

Sin embargo, es importante recordar que, en la mayoría de los casos, el usuario ordinario mantiene el control sobre sus BTC, y solo el propietario puede decidir usar un covenant recursivo y así potencialmente comprometer la fungibilidad de sus BTC.

Varios desarrolladores de Bitcoin señalan que la censura, como la impuesta por gobiernos, ya es posible y que los covenants no necesariamente facilitarían su implementación.

El desarrollador Andrew Poelstra, en una entrevista con Nik Bhatia para The Bitcoin Layer, destacó que tales proyectos enfrentarían una fuerte oposición social, ya que los usuarios tendrían que actualizar sus monederos para reconocer estos BTC restringidos.

También mencionó obstáculos económicos, ya que la adición de opcodes para crear estos covenants haría que las transacciones de BTC fueran más voluminosas y, por lo tanto, más costosas en términos de fees de transacción, además de los desafíos técnicos relacionados con la complejidad de crear tales covenants.

Entre los muchos opcodes propuestos, dos se destacan particularmente por su simplicidad y sus capacidades técnicas: OP_CAT y OP_CHECKTEMPLATEVERIFY.

OP_CAT es un opcode que podría permitir que Script, el lenguaje de programación de Bitcoin, se vuelva mucho más flexible y abra el camino a numerosos nuevos casos de uso.

Técnicamente, OP_CAT está diseñado para concatenar 2 elementos ubicados en la parte superior de la pila del script. La concatenación consiste en ensamblar 2 datos conectándolos, formando así una única secuencia de datos en lugar de 2 distintas, lo que reduce la complejidad del script.

Aunque esta operación parece simple, aumenta considerablemente la expresividad del lenguaje Script, permitiendo crear estructuras de datos más complejas directamente dentro de las transacciones de Bitcoin.

Por ejemplo, permitiría realizar operaciones como la multiplicación (3 x 4), que de otro modo requerirían una serie de sumas sucesivas (3 + 3 + 3 + 3) sin OP_CAT.

De este modo, OP_CAT hace posible la creación de scripts más sofisticados, como covenants de hash de transacción y de introspección de transacción. Por ejemplo, podría permitir:
‍
- la creación de Vaults, sistemas que aumentan la seguridad de los BTC;
- la creación de smart contracts tan Turing-complete como en Ethereum;
- la implementación de Eltoo para mejorar Lightning Network;
- la creación de Ark, un layer 2 de Bitcoin dedicado a la transferencia de BTC;
- la optimización de BitVM, un paradigma de cálculo que permite la creación de rollups;
- o incluso la creación de numerosos layer 2 que realmente se beneficien de la seguridad de Bitcoin.

OP_CAT formaba parte originalmente del script de Bitcoin en el momento de su creación, pero fue desactivado rápidamente en 2010 por el mismo Satoshi Nakamoto. La principal razón de esta eliminación fue el riesgo de spam en la red, lo que podría haber comprometido su seguridad.

De hecho, OP_CAT no tenía un límite de tamaño, lo que podía potencialmente sobrecargar los nodos congestionando la mempool y aumentar el tamaño de la blockchain de manera exponencial. Ethereum intentó resolver un problema similar con su lenguaje Solidity, sin mucho éxito, ya que la adopción de Ethereum ahora depende de sus layer 2.

Entonces, ¿por qué reintroducir OP_CAT en el lenguaje Script si corre el riesgo de sobrecargar los nodos de Bitcoin y reducir su descentralización a largo plazo?

Simplemente porque la introducción de Tapscript en 2021, durante la actualización de Taproot, permitió mitigar este riesgo al imponer un límite de 520 bytes al tamaño de los elementos de la pila. De este modo, OP_CAT puede ser reintroducido en el lenguaje Script sin comprometer la descentralización de Bitcoin.

La reactivación de OP_CAT está motivada por el deseo de añadir funcionalidades más potentes y flexibles al script de Bitcoin, sin alterar los fundamentos de la red ni afectar a los usuarios que no están interesados.

Sin embargo, la integración de OP_CAT permitiría crear varios covenants, incluidos los covenants recursivos, lo que aumentaría las superficies de ataque.

Aunque este opcode podría transformar potencialmente la forma en que se redactan y utilizan los scripts, presenta riesgos significativos para Bitcoin que deben ser evaluados cuidadosamente. Varios desarrolladores de Bitcoin creen, no obstante, que estos riesgos están sobreestimados.

Si OP_CAT fuera reintroducido, podría suceder dentro de un plazo de 1 a 5 años, tras discusiones profundas, pruebas rigurosas y un voto de la comunidad.

Finalmente, OP_CAT se considera el medio más simple y completo para añadir flexibilidad a Bitcoin, pero si su reintroducción no se materializa, podrían añadirse otros opcodes que ofrezcan menos flexibilidad individualmente, o OP_CAT podría ser reintroducido junto con otros opcodes.

OP_CHECKTEMPLATEVERIFY, también llamado OP_CTV, es un opcode propuesto por Jeremy Rubin en 2019 dentro del BIP 119.

Este opcode permite crear covenants basados en el hash de una transacción, introduciendo covenants no recursivos en Bitcoin, capaces de definir de antemano la manera exacta en que se debe construir la siguiente transacción.

La idea de OP_CTV nació de la necesidad de crear transacciones más seguras y eficientes para Bitcoin, especialmente para aplicaciones como Vaults, canales de pago de Lightning Network, el control de congestión de transacciones, así como la mejora de los DLC y la creación del layer 2 Ark.

En la práctica, una transacción que usa OP_CHECKTEMPLATEVERIFY debe incluir un hash de 32 bytes en la pila, llamado commitment hash en inglés, que representa el hash de la siguiente transacción. Este hash compromete la estructura futura de la transacción, incluyendo la distribución de fondos entre 2 o más partes.

Si las partes deciden modificar esta distribución, se genera un nuevo commitment hash para reflejar la nueva distribución. OP_CTV permite actualizar este hash en el script, pero solo si todas las partes involucradas están de acuerdo con las nuevas condiciones.

Esta actualización garantiza que el gasto del UTXO respete las condiciones predefinidas y validadas por todos los participantes, asegurando un control estricto sobre la evolución de las transacciones y permitiendo modificaciones seguras y consensuadas de la distribución de los BTC, incluso si estas condiciones cambian.

El código de OP_CHECKTEMPLATEVERIFY es particularmente simple comparado con OP_CAT, y está listo desde hace varios años.

Estas son las principales diferencias entre OP_CTV y OP_CAT:

- Flexibilidad: OP_CTV es menos flexible, pero también más predecible que OP_CAT, lo que reduce los riesgos de fallos en su uso;
- Aplicaciones potenciales: OP_CTV es ideal para el desarrollo de varias aplicaciones, pero OP_CAT permite crear aplicaciones más sofisticadas, como la creación de scripts complejos y de layer 2 como los rollups;
- Riesgos de sobrecarga: OP_CTV ha sido diseñado para minimizar el impacto en la red de Bitcoin manteniéndose limitado en sus funciones, mientras que OP_CAT requiere precauciones adicionales para evitar la sobrecarga de la red;
- Adopción e implementación: OP_CTV cuenta con un gran apoyo de la comunidad de Bitcoin, lo que permite una adopción potencial más rápida debido a su simplicidad;
- Evolución futura: OP_CTV puede satisfacer la mayoría de las necesidades actuales de los desarrolladores de Bitcoin sin complicar demasiado el sistema, mientras que OP_CAT ofrecería un mayor potencial de evolución.

OP_CTV presenta sin embargo una limitación importante, señalada por Peter Todd hace algunos meses. Subraya que la implementación de CheckTemplateVerify (CTV) no resuelve realmente los problemas de escalabilidad de Bitcoin, ya que exige que cada usuario disponga de un UTXO para pagar los fees, lo que anula las ventajas del reparto de UTXO.

De hecho, aunque CTV permite compartir un UTXO entre diferentes personas, su uso requiere la posesión de un UTXO adicional para pagar los fees de transacción, lo que no resuelve el problema de escalabilidad al que se enfrenta Lightning Network para ampliarse.

Sin embargo, el hecho de que OP_CHECKTEMPLATEVERIFY no sea recursivo le ofrece un potencial de adopción importante en comparación con OP_CAT. Como se explicó anteriormente, la recursividad permitiría a entidades maliciosas o a bugs de desarrollo afectar la fungibilidad de los BTC, lo que incluso podría servir para la censura.

Aunque esta censura puede imponerse por otros medios de manera casi igual de simple, y aunque varios desarrolladores de Bitcoin consideran que la explotación de esta herramienta está sobreestimada, OP_CAT aún introduciría una nueva superficie de ataque contra la soberanía de los usuarios.

La flexibilidad y el menor impacto en la blockchain de Bitcoin otorgan a OP_CTV una ventaja considerable en los debates dentro de la comunidad. Recordemos que estos dos opcodes pueden añadirse a Script al mismo tiempo.

Existen muchas propuestas para añadir opcodes con el fin de crear diferentes covenants. A continuación, una breve descripción de las propuestas más seguidas por la comunidad de Bitcoin.

SIGHASH_ANYPREVOUT (APO), propuesto en el BIP-118, es una actualización del concepto SIGHASH_NOINPUT que permite firmar una transacción sin hacer referencia a un UTXO específico en el input. Esta flexibilidad permite que una transacción pre-firmada sea financiada posteriormente por diferentes UTXO, siempre que los scripts sean compatibles.

APO es particularmente útil para aplicaciones como Eltoo, que mejora la gestión de los canales de Lightning Network, y también puede ser utilizado para mecanismos como Statechains y Spacechains. Sin embargo, APO presenta desafíos en términos de seguridad y complejidad, lo que requiere una gestión cuidadosa durante su implementación.

OP_VAULT es una propuesta que introduce 2 nuevos opcodes en Tapscript, OP_VAULT y OP_VAULT_RECOVER, especificados en el BIP-345.

Estos opcodes, en combinación con OP_CHECKTEMPLATEVERIFY (CTV), permiten imponer un retraso antes de que los BTC puedan ser gastados hacia un destino arbitrario, a menos que se envíen a través de una ruta de recuperación preespecificada.

Antes del gasto final, los BTC aún pueden ser dirigidos hacia esta ruta de recuperación. OP_VAULT tiene como objetivo fortalecer la seguridad de los BTC al ofrecer una protección adicional contra robos, permitiendo al usuario intervenir en caso de intento de robo.

Los opcodes TXHASH y CHECKSIGFROMSTACKVERIFY han sido propuestos para descomponer y reproducir las funcionalidades de CTV y ANYPREVOUT de manera más flexible y modular. En resumen, juntos podrían reemplazar todas las demás propuestas de covenants.

Más específicamente, TXHASH permite generar hashes de transacciones basados en parámetros específicos, mientras que CHECKSIGFROMSTACKVERIFY verifica las firmas a partir de estos hashes.

Aunque ANYPREVOUT puede simular CTV, lo hace a un costo más alto. TXHASH y CHECKSIGFROMSTACKVERIFY ofrecen una alternativa que permite construir covenants y otras aplicaciones con un conjunto de opcodes más simple y adaptable, aunque consumen más espacio.

Los desarrolladores y la comunidad de Bitcoin son conocidos por tomarse varios años para implementar actualizaciones. A lo largo de su historia, Bitcoin solo ha experimentado 2 actualizaciones importantes: SegWit y Taproot, a diferencia de otras blockchains que hacen evolucionar las reglas de consenso más regularmente.

Algunos consideran que esta lentitud es un defecto, ya que impide que Bitcoin escale más rápido. Otros, en cambio, consideran que esta lentitud es beneficiosa, permitiendo que toda la comunidad tenga tiempo para formarse una opinión informada y proteger la red contra posibles ataques.

Por ejemplo, si una persona lograra persuadir a miembros influyentes de la comunidad para aumentar el límite total de BTC en circulación de 21 millones a 42 millones, y las actualizaciones se realizaran rápidamente, los desarrolladores, influencers y miembros de la comunidad podrían aceptar este cambio sin haber tenido tiempo para realizar pruebas técnicas en un testnet ni para medir las implicaciones de tal modificación.

Por lo tanto, la implementación de un opcode presentado previamente podría tomar aún varios años. Por ello, es crucial profundizar en el tema e informarse lo máximo posible sobre los riesgos y complicaciones potenciales relacionados con tales cambios.