El Santo Grial de la Red de Capa 2 de Bitcoin: Introspección y Pactos

En comparación con blockchains Turing-completas como Ethereum, el lenguaje de scripting de Bitcoin se considera significativamente limitado, capaz solo de operaciones básicas, e incluso carece de funciones de multiplicación y división. Y lo que es más importante, los propios datos de la cadena de bloques son prácticamente inaccesibles para los scripts, lo que limita enormemente su flexibilidad y programabilidad. En consecuencia, la gente lleva mucho tiempo buscando formas de habilitar la introspección para los scripts de Bitcoin.

Introspección se refiere a la capacidad de Bitcoin scripts para inspeccionar y restringir los datos de las transacciones. Esto permite a los scripts controlar el uso de fondos basándose en detalles específicos de la transacción, permitiendo funcionalidades más complejas. Actualmente, la mayoría de los opcodes de Bitcoin introducen datos proporcionados por el usuario en la pila o manipulan datos que ya están en la pila. Los opcodes de introspección, sin embargo, pueden introducir datos de transacciones actuales (como marcas de tiempo, cantidades e IDs de transacciones) en la pila, permitiendo un control más granular sobre el gasto UTXO.

Actualmente sólo hay tres opcodes principales en los scripts de Bitcoin que soportan introspección: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY, y CHECKSIG. CHECKSIG tiene varias variantes, incluyendo CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG, y CHECKMULTISIGVERIFY.

Pactos son restricciones sobre cómo pueden transferirse los tokens. Los usuarios pueden especificar cómo se distribuyen los UTXOs a través de pactos, muchos de los cuales se implementan utilizando opcodes de introspección. Actualmente, Bitcoin Optech categoriza la introspección bajo entradas de pacto.

Bitcoin tiene actualmente dos pactos: CSV (CheckSequenceVerify) y CLTV (CheckLockTimeVerify), ambos son pactos basados en el tiempo y forman la base de muchas soluciones de escalado, como la Lightning Network. Esto indica que las soluciones de escalado de Bitcoin dependen en gran medida de la introspección y los pactos.

Cómo añadir condiciones a las transferencias de tokens

En el mundo criptográfico, el método más común es el compromisos, a menudo implementado mediante hashes. Para demostrar que se cumplen las condiciones de transferencia, se utilizan mecanismos de firma para la verificación. Por lo tanto, los pactos implican numerosos ajustes de hashes y firmas.

Las siguientes son propuestas de código de convenio ampliamente debatidas:

CTV (CheckTemplateVerify) BIP-119

CTV (CheckTemplateVerify), incluido en BIP-119, es una actualización de Bitcoin muy debatida. CTV permite a los scripts de salida especificar plantillas para las transacciones de gasto, incluyendo campos como nVersion, nLockTime, hash de scriptSig, recuento de entradas, hash de secuencias, recuento de salidas, hash de salidas e índice de entradas. Estas restricciones de plantilla se implementan mediante un compromiso hash, y los futuros scripts de gasto comprobarán si los valores hash de los campos especificados en la transacción de gasto coinciden con los del script de entrada. Estas plantillas definen esencialmente la hora, el método y la cantidad de las futuras transacciones UTXO.

En particular, el TXID de entrada se excluye del compromiso hash. Esta exclusión es necesaria porque, ya sea en transacciones Legacy o Segwit, el TXID depende del valor scriptPubKey cuando se utiliza el tipo de firma SIGHASH_ALL por defecto. Incluir el TXID crearía una dependencia circular, haciendo que el compromiso hash fuera imposible de construir.

CTV consigue la introspección obteniendo directamente la información de la transacción especificada a través de un nuevo opcode, aplicándole un hash y comparándola con el compromiso en la pila. Este método consume menos espacio en la cadena, pero carece de cierta flexibilidad.

La base de las soluciones de segunda capa como Lightning Network son las transacciones prefirmadas. Prefirmar suele significar generar y firmar transacciones por adelantado, pero no difundirlas hasta que se cumplan determinadas condiciones. Esencialmente, CTV implementa una función de prefirma más estricta, publicando el compromiso prefirmado directamente en la cadena, permitiendo transacciones solo según la plantilla predefinida.

La CTV se propuso inicialmente para aliviar la congestión de Bitcoin y también puede denominarse control de congestión. Durante periodos de alta congestión, CTV puede comprometer múltiples transacciones futuras a través de una única transacción, evitando la necesidad de emitir múltiples transacciones durante la congestión y completando las transacciones reales después de que la congestión disminuya. Esto podría ayudar significativamente durante las ejecuciones de intercambio. Además, las plantillas pueden utilizarse para implementar bóvedas, evitando ataques de hackers, ya que el destino de los fondos está predeterminado, haciendo imposible que los hackers envíen UTXOs utilizando el script CTV a sus direcciones.

La CTV puede mejorar significativamente las redes de segunda capa. Por ejemplo, en la red Lightning, la implementación de Timeout Trees y Channel Factories mediante CTV permite que un único UTXO se expanda en un árbol CTV, abriendo múltiples canales de estado con una sola transacción y confirmación en la cadena. Además, CTV admite transacciones atómicas (ATLC) en el protocolo Ark.

APO (SIGHASH_ANYPREVOUT) BIP-118

BIP-118 propone una nueva bandera hash de firma para tapscript, llamada SIGHASH_ANYPREVOUT, para facilitar la escritura de una lógica de gasto más flexible. APO y CTV son similares en muchos aspectos. Para abordar la dependencia circular entre scriptPubKeys y TXIDs, la solución de APO es excluir la información de entrada relevante y firmar sólo la salida, permitiendo que las transacciones se vinculen dinámicamente a diferentes UTXOs.

Lógicamente, la operación de verificación OP_CHECKSIG (y sus opcodes relacionados) tiene tres funciones:

1. Reúna las partes de la operación de gasto.
2. Hash estas partes.
3. Verifica si el hash está firmado por la clave dada.

El contenido específico de la firma puede ajustarse significativamente, y los campos de transacción que se firman vienen determinados por el indicador SIGHASH. Según la definición de los opcodes de firma BIP 342, las banderas SIGHASH incluyen SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE y SIGHASH_ANYONECANPAY, entre otras. SIGHASH_ANYONECANPAY controla la entrada, mientras que los otros controlan la salida.

SIGHASH_ALL es la bandera SIGHASH por defecto, firmando todas las salidas. SIGHASH_NONE no firma ninguna salida, y SIGHASH_SINGLE firma sólo una salida especificada. SIGHASH_ANYONECANPAY puede establecerse con los otros tres indicadores y, si se establece, sólo firma la entrada especificada; de lo contrario, se deben firmar todas las entradas.

Ninguna de estas banderas SIGHASH puede eliminar el impacto de las entradas. Incluso SIGHASH_ANYONECANPAY requiere un compromiso con una entrada.

Por lo tanto, BIP 118 introduce SIGHASH_ANYPREVOUT. Las firmas APO no necesitan comprometerse con el UTXO de entrada gastado (llamado PREVOUT), sólo firmando la salida, proporcionando una mayor flexibilidad en el control de Bitcoin. Preconstruyendo transacciones y creando las correspondientes firmas y claves públicas de un solo uso, los activos enviados a esa dirección de clave pública deben gastarse a través de la transacción preconstruida, logrando el pacto.

La flexibilidad de APO también puede utilizarse para reparar transacciones. Si una transacción se queda atascada en la cadena debido a las bajas comisiones, se puede crear fácilmente otra transacción para aumentar la comisión sin necesidad de nuevas firmas. Además, para los monederos multifirma, las firmas que no dependen de la entrada gastada simplifican las operaciones.

Al eliminar la dependencia circular entre scriptPubKeys y TXIDs de entrada, APO puede lograr la introspección añadiendo datos de salida en el testigo, aunque esto sigue requiriendo espacio de datos de testigo adicional.

Para los protocolos fuera de la cadena, como la Lightning Network y las bóvedas, APO reduce la necesidad de almacenamiento de estados intermedios, disminuyendo significativamente los requisitos de almacenamiento y la complejidad. El caso de uso más directo de APO es Eltoo, que simplifica las fábricas de canales, construye torres de vigilancia ligeras y baratas y permite salidas unilaterales sin dejar estados erróneos, mejorando el rendimiento de la Red Lightning. APO puede simular la funcionalidad de CTV, aunque requiere el almacenamiento personal de firmas y transacciones prefirmadas, lo que lo hace más costoso y menos eficiente que CTV.

La principal crítica de APO es la necesidad de una nueva versión de clave, lo que la hace incompatible con los sistemas existentes. Además, el nuevo tipo de hash de firma podría introducir riesgos potenciales de doble gasto. Tras amplios debates en la comunidad, APO requiere ahora una firma ordinaria además de la original, lo que alivia los problemas de seguridad y le hace merecedor de su número BIP-118.

OP_VAULT BIP-345

BIP-345 propone dos nuevos opcodes, OP_VAULT y OP_VAULT_RECOVER, para trabajar con CTV e implementar un pacto dedicado que impone un periodo de retraso en el gasto de tokens especificados, durante el cual el gasto puede ser «revocado» a través de una ruta de recuperación.

Los usuarios pueden crear una cámara acorazada configurando una dirección Taproot específica, incluyendo al menos dos scripts en el MAST: un script OP_VAULT para facilitar el proceso de retirada previsto y un script OP_VAULT_RECOVER para garantizar la recuperación de las monedas antes de la finalización de la retirada.

¿Cómo consigue OP_VAULT las retiradas interrumpibles con bloqueo temporal?

En términos sencillos, el opcode OP_VAULT sustituye la secuencia de comandos OP_VAULT gastada por una secuencia de comandos especificada, actualizando un único nodo de hoja en el MAST y manteniendo el resto sin cambios. Esto es similar a TLUV pero sin soportar actualizaciones de claves internas.

Introducir una plantilla durante las actualizaciones de script puede restringir los efectos de pago. El parámetro de bloqueo de tiempo se especifica mediante OP_VAULT, mientras que la plantilla que trae el opcode CTV restringe el conjunto de salidas gastadas a través de esa ruta de script.

El BIP-345 está diseñado para cámaras acorazadas, permitiendo a los usuarios disponer de una vía de recuperación altamente segura (monedero de papel, multifirma distribuida) al tiempo que configuran un retraso en el gasto para los pagos rutinarios. El dispositivo del usuario supervisa continuamente el gasto de la cámara acorazada, permitiendo la recuperación si se produce una transferencia no autorizada.

La implantación de cámaras acorazadas con BIP-345 requiere tener en cuenta cuestiones relacionadas con las tasas, especialmente para las transacciones de recuperación. Entre las posibles soluciones se incluyen CPFP (Child Pays for Parent), anclajes temporales y nuevos indicadores hash de firma como SIGHASH_GROUP.

TLUV (TapleafUpdateVerify)

El esquema TLUV se construye alrededor de Taproot y pretende resolver el problema de la salida eficiente de UTXOs compartidos. El principio rector es que cuando se gasta una salida de Taproot, podemos utilizar la estructura interna de la dirección de Taproot y transformaciones criptográficas para actualizar parcialmente la clave interna y MAST de acuerdo con los pasos de actualización descritos por el script TLUV, logrando así la funcionalidad del contrato.

La idea del esquema TLUV es crear una nueva dirección Taproot basada en la entrada de gasto actual a través de un nuevo opcode TAPLEAF_UPDATE_VERIFY, que puede realizar una o más de las siguientes operaciones:

• Actualizar la clave pública interna
• Recortar la ruta Merkle
• Eliminar el nodo hoja actualmente en ejecución
• Añade un nuevo nodo hoja al final de la ruta Merkle

En concreto, TLUV toma tres entradas:

1. Una especificación sobre cómo actualizar la clave pública interna
2. Un nuevo nodo hoja para la ruta Merkle
3. Una especificación sobre si eliminar el nodo hoja actual y/o cuántos nodos hoja de la ruta Merkle eliminar.

El opcode TLUV calcula la scriptPubKey actualizada y verifica si la salida correspondiente a la entrada actual se pasa a esa scriptPubKey.

La inspiración para TLUV son los fondos comunes de monedas. Hoy en día, los fondos comunes pueden crearse utilizando transacciones pre-firmadas, pero si quieres conseguir salidas sin permiso, necesitas crear un número exponencialmente creciente de firmas. TLUV permite salidas sin permiso y sin transacciones pre-firmadas. Por ejemplo, un grupo de socios utiliza Taproot para construir un UTXO compartido, poniendo en común sus fondos. Pueden mover fondos internamente utilizando la clave de Taproot o firmar conjuntamente para realizar pagos externos. Los individuos pueden salir del fondo común compartido en cualquier momento, eliminando su ruta de pago, mientras que otros pueden seguir completando los pagos a través de la ruta original sin exponer información adicional sobre los miembros restantes. Este método es más eficiente y privado en comparación con las transacciones no mancomunadas.

El opcode TLUV consigue restricciones parciales de gasto actualizando el MAST original. Sin embargo, no logra la introspección de los importes de salida. Por lo tanto, se necesita un nuevo opcode IN_OUT_AMOUNT, que introduce dos datos en la pila: el importe del UTXO de esta entrada y el importe de salida correspondiente. A continuación, se espera que la persona que utilice TLUV utilice operadores matemáticos para verificar si los fondos se conservan correctamente en el scriptPubKey actualizado.

La introspección de las cantidades de salida añade otra complejidad porque las cantidades de Bitcoin se representan en satoshis y requieren hasta 51 bits, pero los scripts sólo permiten operaciones matemáticas de 32 bits. Esto requiere actualizar los operadores del script redefiniendo el comportamiento del opcode o utilizando SIGHASH_GROUP para sustituir a IN_OUT_AMOUNT.

Se espera que TLUV proporcione soluciones para los grupos de monedas descentralizados de nivel 2, aunque la fiabilidad en términos de ajuste de las claves públicas de Taproot necesita más confirmación.

MATT

MATT (Merkleize All The Things) pretende alcanzar tres objetivos: Merkleizar el estado, Merkleizar los scripts y Merkleizar la ejecución, logrando así contratos inteligentes generales.

• Estado Merkleizante: Construir un Merkle Trie donde cada nodo hoja es un hash del estado, y la raíz Merkle representa todo el estado del contrato.
• Scripts de merkleización: Un MAST construido de Tapscript donde cada nodo hoja es una posible ruta de transición de estado.
• Ejecución Merkleizing: Se consigue mediante compromisos criptográficos y mecanismos de impugnación de fraudes. Para cualquier función computacional, los participantes pueden calcular fuera de la cadena y publicar compromisos, f(x)=y. Si otros participantes encuentran el resultado f(x)=z, pueden impugnarlo, y el arbitraje se realiza mediante una búsqueda binaria, similar al principio Optimistic Rollup.

Para conseguir MATT, los scripts de programación de Bitcoin deben tener las siguientes funcionalidades:

1. Aplicar una secuencia de comandos específica a una salida (y sus importes)
2. Adjuntar datos a una salida
3. Leer datos de la entrada actual (u otras entradas)

El segundo punto es crucial, ya que los datos dinámicos permiten calcular el estado a través de los datos de entrada proporcionados por el emisor, simulando una máquina de estados y decidiendo el siguiente estado y los datos adjuntos. MATT propone el opcode OP_CHECKCONTRACTVERIFY (OP_CCV), una combinación de los opcodes OP_CHECKOUTPUTCONTRACTVERIFY y OP_CHECKINPUTCONTRACTVERIFY propuestos anteriormente, con un parámetro flags adicional para especificar el objetivo de la operación.

Control de las cantidades de salida: La forma más directa es a través de la introspección directa. Sin embargo, los importes de salida son números de 64 bits que requieren operaciones de 64 bits, lo que añade complejidad a la implementación del script Bitcoin. CCV adopta una comprobación retardada similar a OP_VAULT, sumando las cantidades de entrada para todas las entradas a la misma salida con CCV como el límite inferior de esa cantidad de salida. La comprobación se retrasa al proceso de transacción en lugar de durante la evaluación del script de entrada.

Dada la generalidad de las pruebas de fraude, algunas variantes de contratos MATT deberían alcanzar todos los tipos de contratos inteligentes o construcciones de Capa 2, aunque los requisitos adicionales (como el bloqueo de capital y los retrasos del periodo de desafío) necesitan una evaluación precisa. Se requiere más investigación para evaluar qué aplicaciones son transacciones aceptables. Por ejemplo, usando compromisos criptográficos y mecanismos de desafío de fraude para simular funciones OP_ZK_VERIFY, logrando Rollups sin confianza en Bitcoin.

En la práctica, las cosas ya están sucediendo. Johan Torås Halseth implementó elftrace utilizando el opcode OP_CHECKCONTRACTVERIFY de la propuesta de bifurcación suave MATT, permitiendo que todos los programas soportados por la compilación RISC-V sean verificados en la cadena Bitcoin, habilitando puentes de verificación Bitcoin nativos para protocolos de contratos.

CSFS (OP_CHECKSIGFROMSTACK)

Desde la introducción del opcode APO, sabemos que OP_CHECKSIG (y operaciones relacionadas) es responsable de ensamblar transacciones, hashing y verificación de firmas. Sin embargo, el mensaje que verifica se deriva de la serialización de la transacción utilizando este opcode, no permitiendo especificar otros mensajes. En términos simples, OP_CHECKSIG (y operaciones relacionadas) sirve para verificar que el UTXO como entrada de transacción está autorizado a ser gastado por el titular de la firma, protegiendo así la seguridad de Bitcoin.

CSFS, como su nombre indica, comprueba las firmas de la pila. El opcode CSFS toma tres parámetros de la pila: una firma, un mensaje y una clave pública, y verifica la validez de la firma. Esto significa que cualquier mensaje puede ser pasado a la pila a través de datos de testigos y verificado por CSFS, permitiendo algunas innovaciones en Bitcoin.

La flexibilidad del CSFS le permite aplicar diversos mecanismos, como las firmas de pago, la delegación de autoridad, los contratos de oráculo y los bonos de protección contra el doble gasto y, lo que es más importante, la introspección de transacciones. El principio de la introspección de transacciones mediante CSFS es muy sencillo. Si el contenido de la transacción utilizado por OP_CHECKSIG se introduce en la pila a través del testigo y se utilizan la misma clave pública y la misma firma para verificar tanto con CSFS como con OP_CHECKSIG, si ambas pasan, entonces el contenido de cualquier mensaje pasado a CSFS es el mismo que la transacción de gasto serializada (y otros datos) utilizada implícitamente por OP_CHECKSIG. Obtenemos entonces datos de transacción verificados en la pila, que pueden utilizarse para aplicar restricciones a la transacción de gasto con otros opcodes.

CSFS aparece a menudo con OP_CAT porque OP_CAT puede concatenar diferentes campos de la transacción para completar la serialización, permitiendo una selección más precisa de los campos de la transacción para la introspección. Sin OP_CAT, el script no puede volver a calcular hashes a partir de datos comprobables individualmente, por lo que solo puede comprobar si un hash coincide con un valor específico, lo que significa que las monedas solo pueden gastarse a través de una única transacción específica.

CSFS puede conseguir opcodes como CLTV, CSV, CTV, APO, y es un opcode de introspección general, por lo que también ayuda a las soluciones de escalado de Capa 2 para Bitcoin. Su inconveniente es que requiere añadir una copia completa de la transacción firmada a la pila, lo que puede aumentar significativamente el tamaño de las transacciones que quieran utilizar CSFS para la introspección. Por el contrario, los opcodes de introspección de propósito único como CLTV y CSV tienen la menor sobrecarga, pero añadir cada nuevo opcode de introspección especial requiere cambios en el consenso.

TXHASH (OP_TXHASH)

OP_TXHASH es un opcode de introspección muy sencillo que permite al operador seleccionar el hash de un campo e introducirlo en la pila. Específicamente, OP_TXHASH saca una bandera txhash de la pila, calcula un txhash (marcado) basado en la bandera, y empuja el hash resultante en la pila.

Debido a la similitud entre TXHASH y CTV, ha habido un amplio debate en la comunidad sobre los dos.

TXHASH puede considerarse una mejora general de CTV, ya que proporciona una plantilla de transacción más avanzada que permite a los usuarios especificar partes de la transacción de gasto, lo que resuelve muchos problemas relacionados con los gastos de transacción. A diferencia de otros opcodes de contrato, TXHASH no requiere proporcionar una copia de los datos necesarios en el testigo, reduciendo aún más las necesidades de almacenamiento. A diferencia de CTV, TXHASH no es compatible con NOP y sólo puede implementarse en tapscript. La combinación de TXHASH y CSFS puede considerarse una alternativa a CTV y APO.

En términos de construcción de contratos, TXHASH es más fácil de lograr «contratos aditivos» empujando todas las partes de los datos de la transacción que desea fijar a la pila, hash juntos, y verificar si el resultado coincide con un valor fijo. CTV es más fácil de lograr «contratos sustractivos» empujando todas las partes de los datos de la transacción que desea mantener libre a la pila. Entonces, usando OP_SHA256 rodante, comenzando desde un estado intermedio fijo, ese estado intermedio compromete el prefijo de datos hash de la transacción. Las partes libres se convierten en hash en ese estado intermedio.

Se espera que el campo TxFieldSelector definido en la especificación TXHASH se amplíe a otros opcodes, como OP_TX.

El BIP relacionado con TXHASH se encuentra actualmente en estado de borrador en Github y aún no se le ha asignado un número.

OP_CAT

OP_CAT es un opcode un tanto misterioso que fue obsoleto por Satoshi Nakamoto debido a problemas de seguridad. Sin embargo, recientemente ha suscitado un amplio debate entre los desarrolladores del núcleo de Bitcoin, convirtiéndose incluso en un meme en la comunidad online. Finalmente, OP_CAT fue aprobado como BIP-347, y muchos lo consideran la propuesta BIP con más probabilidades de ser aprobada en un futuro próximo.

En realidad, el comportamiento de OP_CAT es muy sencillo: concatena dos elementos de la pila en uno solo. Pero, ¿cómo permite esto la funcionalidad de contrato?

La función de concatenar dos elementos corresponde a una potente estructura de datos criptográfica conocida como Merkle Trie. La construcción de un Merkle Trie sólo requiere operaciones de concatenación y hashing, ambas disponibles en los scripts de Bitcoin. Por lo tanto, con OP_CAT, teóricamente podemos verificar Merkle Proofs en scripts de Bitcoin, que es el método de verificación ligero más común en blockchains.

Como ya se ha mencionado, CSFS puede utilizar OP_CAT para lograr un esquema general de contratos. De hecho, incluso sin CSFS, la estructura de las firmas Schnorr permite al propio OP_CAT lograr la introspección de transacciones.

En una firma Schnorr, el mensaje a firmar se compone de los siguientes campos:

• Versión
• Hora de cierre
• Recuento de entradas
• Recuento de salidas
• Lista de entradas (cada una incluye el hash de la transacción anterior, el índice, la longitud del script, el script, la secuencia)
• Lista de salidas (cada una incluye el valor, la longitud de la secuencia de comandos y la secuencia de comandos)

Estos campos contienen los elementos principales de una transacción. Colocándolos en scriptPubKey o witness, y usando OP_CAT y OP_SHA256, podemos construir una firma Schnorr y verificarla con OP_CHECKSIG. Si la verificación pasa, la pila retiene los datos de la transacción verificada, permitiendo la introspección de la transacción. Esto nos permite extraer e «inspeccionar» varias partes de la transacción, como sus entradas, salidas, direcciones de destino o cantidades de Bitcoin involucradas.

Para principios criptográficos más detallados, consulte el artículo de Andrew Poelstra «CAT y trucos de Schnorr».

En resumen, la flexibilidad de OP_CAT lo hace capaz de imitar casi cualquier opcode de contrato, y muchos opcodes de contrato dependen de su funcionalidad. Esto avanza significativamente su posición en la lista merge. Teóricamente, con sólo OP_CAT y los opcodes Bitcoin existentes, podríamos construir un BTC ZK Rollup de confianza minimizada. Starknet, Chakra y otros socios del ecosistema están trabajando activamente para que esto suceda.

Conclusión

A medida que exploramos varias estrategias para expandir Bitcoin y mejorar su programabilidad, se hace evidente que el camino a seguir pasa por una combinación de mejoras nativas, computación fuera de la cadena y funcionalidades de script complejas.

Sin una capa base flexible, es imposible construir una segunda capa más flexible.

La escalabilidad computacional fuera de la cadena es el futuro, pero la programabilidad de Bitcoin debe abrirse paso para soportar mejor el escalado y convertirse en una verdadera moneda mundial.

Sin embargo, la computación de Bitcoin difiere fundamentalmente de la de Ethereum. Bitcoin sólo admite la «verificación» como forma de computación, mientras que Ethereum es fundamentalmente computacional, con la verificación como subproducto. Esta diferencia es evidente en el hecho de que Ethereum cobra tasas de gas por transacciones fallidas, mientras que Bitcoin no lo hace.

Los contratos logran una forma de contratos inteligentes basados en la verificación más que en la computación. En cuanto a los contratos, aparte de unos pocos fundamentalistas estrictos de Satoshi, la mayoría de la gente cree que los contratos son una buena opción para mejorar Bitcoin. Sin embargo, la comunidad debate constantemente qué esquema utilizar para implementar los contratos.

APO, OP_VAULT y TLUV se inclinan por las aplicaciones directas. Eligiéndolos se pueden implementar aplicaciones específicas de forma más barata y eficiente. Los entusiastas de Lightning Network prefieren APO porque consigue LN-Symmetry; si quieres crear una bóveda, es mejor usar OP_VAULT; para construir un CoinPool, TLUV es más privado y eficiente. OP_CAT y TXHASH son más generales, con menos vulnerabilidades de seguridad, y pueden lograr más casos de uso a través de combinaciones con otros opcodes, aunque potencialmente a costa de la complejidad del script. CTV y CSFS han ajustado el enfoque de procesamiento del blockchain: CTV implementa salidas retardadas, y CSFS implementa firmas retardadas. MATT es relativamente único, ya que utiliza la ejecución optimista y las pruebas de fraude, y se basa en la estructura Merkle Trie para lograr contratos inteligentes generales, aunque todavía requiere nuevos opcodes para proporcionar capacidades de introspección.

Vemos que la comunidad Bitcoin ya está debatiendo intensamente la posibilidad de introducir contratos a través de una bifurcación suave. Starknet ha anunciado oficialmente su entrada en el ecosistema Bitcoin, planeando implementar la liquidación en la red Bitcoin en los seis meses siguientes a la fusión OP_CAT. Chakra continuará monitorizando los últimos desarrollos en el ecosistema Bitcoin, promoviendo la fusión de la bifurcación suave OP_CAT, y utilizando la programabilidad aportada por la introspección y los contratos para construir una capa de liquidación Bitcoin más segura y eficiente.