¿La próxima actualización importante a Bitcoin?Evaluación de OP_CAT y OP

Autor: Gabe Parker, Analista de Galaxy;

resumen

Bitcoin adopta una actitud conservadora hacia las actualizaciones del protocolo, lo que hace que los cambios de consenso raros.Pero como muestran las actualizaciones anteriores de Segwit y Taproot, los desarrolladores aún están dispuestos a optimizar el lenguaje de programación y los parámetros de red de Bitcoin.
Lenguaje de programación de bitcoin:Bitcoin script, la transacción no puede llevar al estado global y tiene la capacidad de introspectivamente, lo que limita su capacidad expresiva.
Actualmente hay dos propuestas principales,OP_CAT (BIP 347)yOP_CTV (BIP 119), Están diseñados para mejorar la programabilidad de las transacciones de Bitcoin y hacer que la salida de transacciones sea más condiciones de gasto.Estas propuestas pueden mejorar en gran medida las capacidades de Bitcoin Script y hacerlo más flexible.
Los escenarios de aplicación más prometedores de OP_CAT y OP_CTV incluyen:Establezca un puente de cadena transversal sin confianza entre la primera capa (L1) y la segunda capa (L2) de BitcoinMejorar las soluciones avanzadas de bóveda autohostadas yMejoras a la red Lightning.
El proceso de gobernanza de las actualizaciones de horquilla suave implica múltiples partes interesadas en bitcoin.Los influenciadores de los medios y los desarrolladores centrales tienen la mayor influencia en las primeras etapas de la concepción del protocolo y la revisión técnica.
Galaxy Research predice que los desarrolladores de Bitcoin Core llegarán a un consenso sobre OP_CAT u OP_CTV en 2025, pero debido al complejo proceso de activación, puede llevar 1-2 años implementarlo.

1. Introducción

Los cambios en el protocolo de Bitcoin requieren discusión y colaboración entre múltiples partes interesadas, incluidos, entre otros, desarrolladores de protocolos, nodos completos, usuarios finales y mineros.El proceso de consenso para lograr actualizaciones del protocolo es complejo y controvertido.Por ejemplo,La «batalla de tamaño de bloque» de 2015 a 2017Deje que la comunidad de Bitcoin se divida, una de las partes quiere ajustar el tamaño del bloque, los objetos de la otra parte.Años de debate finalmente llevaron a una bifurcación permanente de blockchain y al nacimiento de una nueva criptomoneda.Bitcoin en efectivo, es una versión bifurcada de Bitcoin.

Dada la dificultad de llegar a un acuerdo para cambiar el consenso, una actualización importante a Bitcoin es rara.Los desarrolladores del protocolo de Bitcoin rechazan las actualizaciones controvertidas, y ha sido una larga historia de tiempo para implementar aquellos que son respaldados por la comunidad más amplia de Bitcoin.Esto destaca el compromiso de los desarrolladores con las actitudes conservadoras hacia el desarrollo de Bitcoin para promover la previsibilidad, la fidelidad de la red y la compatibilidad atrasada.

Aunque los cambios de consenso de Bitcoin son raros, los desarrolladores de Bitcoin han mostrado una actitud abierta hacia los scripts de bitcoin y la optimización de parámetros de red.La actualización de Segwit, nacida en la batalla del tamaño del bloque, en realidad agrega límites de tamaño de bloque, lo que permite que se incluyan más transacciones en el bloque.SEGWIT también optimiza el formato de datos de transacciones cambiando la unidad de medición de datos de transacciones de bytes a bytes virtuales.Esta transición, junto con mover los datos de firma al campo de testigos, permite que un bloque de bitcoin contenga datos de transacción (aproximadamente 4MB) en unidades de peso de hasta 4 m.La última bifurcación suave de Bitcoin es la actualización de Taproot 2021, que presenta un lenguaje de secuencias de comandos actualizado llamado Tapscript.Esta nueva versión del script de bitcoin incluye un nuevo esquema de firma (Schnorr Signature), mejora la agregación de clave, fusionando múltiples claves públicas y firmas en una clave de firma.La agregación clave de las firmas de Schnorr reduce la cantidad de datos de transacciones que requiere múltiples firmas, al tiempo que mejora la privacidad de las transacciones en la red Lightning (la capa de pago P2P más grande de Bitcoin, construida sobre la capa base de Bitcoin).Una breve descripción de Segwit y Taproot sugiere que, aunque los desarrolladores de Bitcoin son cautelosos sobre los cambios de consenso de Bitcoin, esto no significa que las características técnicas de Bitcoin no cambiarán.

Después de Segwit y Taproot, los desarrolladores de Bitcoin ahora están explorando la mejora de la programabilidad de la transacción de Bitcoin para agregar una lógica de contrato inteligente adicional a la transacción.Los contratos inteligentes de Bitcoin implican el uso de condiciones de gasto, es decir, la capacidad de limitar y controlar cómo se gastarán las salidas de transacciones no asombrosas (UTXO) en el futuro.Este artículo revisará primero el script de Bitcoin y cómo funciona con el modelo de contabilidad UTXO de Bitcoin.Luego analizaremos los dos códigos OP_CTV y OP_CAT pendientes para resaltar cómo estos códigos OP tienen el potencial de mejorar el script de Bitcoin para incluir características potentes para permitir una programabilidad eficiente de transacciones.Finalmente, este artículo resalta la importancia de la programabilidad de la transacción para la infraestructura de Bitcoin, como el puente y la custodia, y espera la posibilidad de consenso entre OP_CAT y OP_CTV y la ruta para implementar estos códigos OPCO en la siguiente actualización de la bifurcación suave.

2. Bitcoin Script y Utxo Model

Bitcoin utiliza un lenguaje de secuencias de comandos nativo para construir transacciones llamadas «scripts de bitcoin».El script consiste en un conjunto de instrucciones que define cómo el destinatario de la transacción gasta el bitcoin que se está enviando, también conocido como la «condición de gasto».El script de bitcoin consta de 186 códigos de operación que se ejecutan como funciones de comando.Estos códigos de operación se utilizan para crear reglas oficiales sobre cómo se gastan y transfieren los activos de Bitcoin en la red.Por ejemplo, una transacción de hash de pago a paga contiene 4 códigos de operación que hacen cumplir las condiciones de gasto en las transacciones de bitcoin, donde se gastan bitcoin en una clave pública hash y solo se puede gastar utilizando las claves públicas y privadas correctas asociadas con el consumidor.

Los scripts de bitcoin están diseñados para la salida de transacciones no tendido de Bitcoin (modelo UTXO) que usan entrada y salida.Cada transacción de bitcoin incluye al menos 1 entrada y 1 salida, aunque la mayoría de las transacciones simples incluyen al menos 1 entrada y 2 salidas (una parte de BTC en la entrada se usa para financiar transacciones, de las cuales se envía al receptor, y el resto se devuelve al consumidor en la salida).Utxo es un bitcoin que aún no se ha gastado y puede enviarse en futuras transacciones.Una vez que los UTXO se usan como entradas para transacciones, ya no son salidas.Por lo tanto, cuando los usuarios gastan bitcoin, los utxos se crean y destruyen constantemente.Aquí hay un ejemplo de un modelo UTXO simplificado:

*Si Alice tuviera un UTXO que valía 1 BTC en su billetera y ella envió 0.5 BTC a Bob, la entrada de Alice sería 1 BTC.* Su salida será 0.49 BTC (devuelto a Alice) y 0.5 BTC (enviado a Bob).La diferencia de 0.01 BTC representa el BTC pagado a la tarifa de transacción (esta tarifa de transacción variará según la congestión de la red).*Al final de este acuerdo, Alice tendrá un nuevo conjunto UTXO que representa sus 0.49 BTC restantes.En el paso 1, Alice destruye el UTXO usando su valor de 1 BTC de UTXO como la primera entrada a la transacción.En el paso 2, Alice crea dos nuevos utxos por valor de 0.5 BTC y 0.49 BTC, uno regresó a ella como su cambio y el otro pagó a Bob.En el paso 3, Alice ahora tiene un nuevo UTXO por valor de 0.49 BTC.Cabe señalar que si Alice necesita pagar a Bob 0.5 BTC, Alice también puede usar múltiples UTXO en el Paso 1, con un total de 0.5 BTC;El modelo UTXO es una característica clave de la red de bitcoin y juega un papel crucial en el procesamiento y verificación de transacciones.

El ejemplo UTXO anterior se crea completamente utilizando scripts de bitcoin.Cada UTXO contiene un script de bloqueo que incluye un conjunto de condiciones que se gasta el UTXO.Cuando el usuario demuestra la propiedad de la entrada (gasto UTXO) al proporcionar la firma de clave privada correcta asociada con la clave pública correspondiente, se desbloquea el script de bloqueo UTXO.Esta información se llama «firma de script», y cuando la entrada contiene la firma de script correcta, se cumplen las condiciones de gasto y se puede gastar bitcoin.Volviendo al ejemplo Utxo de Alice y Bob, en el Paso 1, Alice debe proporcionar su firma de clave privada en su aportación para gastar su utxo.Bob tuvo que proporcionar la misma información antes de gastar su recién recibido 0.5 BTC.

El lenguaje de secuencias de comandos de Bitcoin puede incluir condiciones de gasto más complejas, como requerir múltiples firmas o desbloquear Bitcoin a una altura de bloque específica.Sin embargo, los scripts de bitcoin no son universales y carecen del poder expresivo de la solidez del lenguaje de programación nativo de Ethereum.Por lo tanto, es extremadamente difícil programar una lógica de contrato inteligente para unir y alojar soluciones utilizando scripts de bitcoin.

3. Obstáculos que enfrentan los guiones de Bitcoin a partir de 2025

Aunque los scripts de Bitcoin han demostrado su utilidad para los usuarios y su capacidad de recuperación para los ataques de doble gasto en los últimos 16 años, el lenguaje de secuencias de comandos carece de características comunes como la expresividad y la capacidad de almacenar el estado global.Los scripts de bitcoin no son expresivos porque son un lenguaje de programación basado en pila que no puede multiplicar y operaciones aritméticas en grandes números.Los scripts de bitcoin solo pueden realizar cálculos no triviales en valores de tamaño de 32 bits.Por lo tanto, el script de bitcoin aísla elementos de la pila de más de 32 bits entre sí.Esta restricción de 32 bits aísla comandos computacionalmente intensivos utilizando funciones de cifrado, multiplicación y división que requieren un tamaño de script más grande que el conjunto actual de códigos de operación.Si bien la aritmética y la multiplicación se pueden simular utilizando múltiples códigos de operación, esto requiere muchos elementos de pila, mientras que el tamaño de la pila de un script de bitcoin se limita a 1000 elementos.Por lo tanto, es difícil crear condiciones de gasto complejas en la salida de transacciones que excedan la operación actual.

La mayor limitación de los scripts de Bitcoin es que el idioma no puede leer/escribir y almacenar datos de transacción porque solo puede leer la entrada proporcionada por el consumidor.Si el lenguaje de programación no puede almacenar el estado global, el script no puede verificar independientemente el saldo de la cuenta en la aplicación o puente.La lógica de escritura de bitcoin no puede acceder a Global State porque cualquier estado de estado debe ser adecuado para una sola transacción.Por lo tanto, es casi imposible desarrollar funciones comunes o construir puentes sin confianza entre la red L2 y la capa base de Bitcoin.

Las medidas para superar las restricciones de script de bitcoin han estado en marcha desde 2020.A lo largo de los años, parece que la única forma de mejorar la expresividad de los scripts de Bitcoin es realizar actualizaciones de horquilla suave, implementar nuevos códigos de operación para implementar convenios.Si bien parte de la comunidad de Bitcoin cree que estas actualizaciones representan un riesgo para la red de Bitcoin, otro piensa que Bitcoin necesita más características de programabilidad para escalar el caso de uso de Bitcoin.Aunque no se ha logrado un progreso sustancial sobre qué OPCode es más adecuado para mejorar la programabilidad de las transacciones de bitcoins, los defensores de los convenios ahora están de acuerdo en que OP_CTV y OP_CAT son las principales propuestas de mejora de bitcoin (BIP) que mejoran la programabilidad de las transacciones de bitcoins.Hemos aprendido que hay más de dos soluciones para implementar convenios en Bitcoin, pero este artículo solo describe las dos propuestas más destacadas, OP_CTV y OP_CAT.

4. BIP 119 (OP_CTV)

La propuesta de mejora de bitcoin 119 (BIP 119), también conocida como verificación de templado de cheque (CTV), es una propuesta propuesta en enero de 2020 por el desarrollador de Bitcoin Core Jeremy Rubin.La propuesta introduce un nuevo código OP_CTV que implementa condiciones generales de gasto, es decir, convenios, en la salida de transacciones de bitcoin.Demos una introducción de fondo simple a continuación.La parte de la plantilla en «check_template_verify» se refiere al formato de transacción que debe seguirse al escribir scripts de bitcoin.Check-Template-Verify es una nueva característica que permite que la salida del script de bloqueo por la transacción se comprometa con las condiciones de gasto almacenadas en el script de bloqueo como un hash, también conocido como un hash prometedor.Por lo tanto, la salida de la transacción solo se puede desbloquear si se cumplen las condiciones detalladas en el hash de la promesa.Una vez transmitido en la cadena, el hash prometedor asociado con la transacción es inmutable.La ventaja de OP_CTV es que el remitente de transacciones puede imponer condiciones de gasto en el receptor, lo cual es un cambio importante en las reglas actuales del script de bitcoin, y las reglas actuales solo pueden construir las condiciones de gasto del remitente.

Hay dos tipos principales de contratos de convenio.Se puede copiar y aplicar un contrato general a múltiples UTXO.Los convenios no caducarán después de que se gastan Utxo.Por otro lado, los contratos precalculados también se pueden copiar, pero solo se pueden usar dentro de un número limitado y predefinido de veces.La lógica del contrato precalculado debe especificarse por adelantado por el remitente, y la diferencia del contrato general es que las condiciones de gasto no se pueden copiar infinitamente.Los contratos generales, también conocidos como contratos recursivos, pueden representar riesgos para la sustituabilidad de UTXO, por lo que BIP 119 defensores generalmente se centra solo en los casos de uso OP_CTV que usan contratos precomputados y por qué BIP 119 no respalda los contratos generales.Por ejemplo, si se habilita un contrato general, el Custodio o el Intercambio de Bitcoin pueden manejar los retiros con condiciones de gasto permanente, que pueden nunca deshacerse de la posibilidad de ser examinado por el gobierno u otra autoridad.

5. Disgire de los convenios utilizando BIP 119

Tomar el plan de bóveda como ejemplo, lo siguiente es sobre cómo la función OP_CTV implementa los convenios:

Alice espera gastar 0.8 BTC de su 1 BTC UTXO a Bob y Charlie (0.4 BTC por persona) en los próximos 10 años.Alice también espera enviar su cambio de aproximadamente 0.2 BTC a una nueva bóveda que bloquea a BTC por otros 10 años.

Paso 1:Alice pasó su 1 BTC Utxo a Bob y Charlie, y detalló en el guión de bloqueo de que Bob y Charlie pueden gastar BTC después de 525k bloques, que son unos 10 años después.Alice también incluye instrucciones que detallan su salida de cambio de aproximadamente 0.2 BTC se enviarán a la dirección de la bóveda que posee, lo que bloqueará sus bloques UTXO 525K, es decir, unos 10 años después.

Paso 2:Bob y Charlie pasaron su respectivo UTXO por valor de 0.4 BTC después de 525k bloques.El script de bloqueo establecido por Alice verificará el hash Promise en función de la altura actual del bloque, y Bob y Charlie pueden gastar su nuevo utxo si se cumplen los criterios.

En el paso 2, después de que Bob y Charlie pasan su utxo, parte del guión de Bitcoin, también conocido como «Script de bloqueo», verificará el cumplimiento de las condiciones de gasto, asegurando que todas las condiciones se cumplan antes de que se libere BTC.Esta operación a menudo se llama «desbloquear» la salida de bitcoin con la firma de script correcta.Si no se cumple la condición, el script de bloqueo no iniciará la transferencia de BTC.

Paso 3:Después de que Charlie y Bob satisfacen el hash Promise en el script de bloqueo, el UTXO regresó a Alice como cambio (aproximadamente 0.2 BTC) se usa como entrada para tener la dirección de la clave pública de script de bóveda especificada.La clave pública del guión de bóveda incluye un hash que permite a Alice desbloquear la bóveda después de 525k bloques para gastar su utxo por valor de aproximadamente 0.2 BTC.El beneficio de usar el esquema de bóveda es que Alice puede agregar medidas de seguridad detalladas en el hash, como una dirección de recuperación secreta, en caso de que alguien robe su llave privada e intente desbloquear el UTXO antes del bloqueo de tiempo de bloque de 525k.

Sin convenios, en el ejemplo anterior, Alice necesita crear una transacción previa al firma para hacer cumplir las condiciones de gasto futuras en el BTC que gastó en Bob y Charlie.Una transacción previa firmada puede ser una transacción única o múltiple, firmada de antemano por la clave privada del remitente, pero en realidad no se transmite a la red para confirmación y ejecución.Las transacciones previamente firmadas no son escalables porque requieren que los usuarios almacenen datos para múltiples transacciones hasta que se ejecuten en la cadena.Además, las transacciones previas a la firma requieren interacción entre todas las partes signatorias cuando se pueden gastar fondos.Sin embargo, la implementación de convenios utilizando el hash prometedor a través de OP_CTV reduce la necesidad de que los usuarios almacenen datos de transacciones previamente firmados y dependan de la interacción entre todas las partes asociadas con la transacción.

En términos generales, esta característica se puede utilizar para crear un diseño complejo, altamente seguro y resistente y un diseño seguro que ayude a mejorar la configuración de autohospedaje o alojamiento, crear nuevos quórums innovadores o configuraciones de cuentas comerciales, o crear soluciones de ejecución más autónomas con mayor transparencia y confiabilidad.

6. BIP 347 (OP_CAT)

BIP 347 es otra propuesta de mejora de bitcoin escrita por Ethan Heilman y Armin Sabouri en octubre de 2023, que también puede implementar condiciones de gasto precalculadas en la producción de transacciones de bitcoins.La propuesta sugiere agregar el código de operación OP_CAT al lenguaje de secuencias de comandos de Bitcoin, una característica que permite a los desarrolladores de Bitcoin «conectar» dos puntos de datos juntos en la pila y colocar estos valores en la parte superior de la pila.Echemos un vistazo a una breve introducción de fondo.La concatenación es el proceso de combinar dos o más cadenas de código en un byte o cadena de datos más grande.Los scripts de bitcoin son lenguajes de programación basados en pila que calculan cada cadena de código en orden.Para una pila que consta de 5 líneas de código, el script de bitcoin calculará primero la línea 1 y finalmente calculará la línea 5.Desafortunadamente, el lenguaje de secuencias de comandos de Bitcoin no contiene códigos de operación que permitan a los desarrolladores fusionar múltiples cadenas de código en toda la pila.Actualmente, los guiones de bitcoin carecen de capacidades aritméticas y de multiplicación, suprimiendo la capacidad de comprimir los scripts de bitcoin, lo que limita la interacción de scripts grandes (mayores de 32 bits) y pequeños scripts (más de 32 bits) en una sola pila.Las condiciones de gasto complejas en la salida de transacciones no son factibles sin la capacidad de comprimir los scripts a través de la «conexión» y permitir que grandes scripts se comuniquen con scripts pequeños.

De manera crucial, los elementos concatenados del script de bitcoin en la parte superior de la pila pueden simular funciones aritméticas y de multiplicación, permitiendo scripts complejos sin la necesidad de escribir scripts más largos e intensivos en datos que son más propensos a errores.Además, la función de conectividad de OP_CAT permite a los desarrolladores generar condiciones de gasto utilizando Merkle Tree y otras estructuras de datos hash en Tapscript, un lenguaje nativo de secuencias de comandos utilizado para habilitar nuevos tipos de transacciones como parte de la actualización de grifo activado en noviembre de 2021.

Vale la pena señalar que Satoshi Nakamoto deshabilita OP_CAT y otros códigos OP que permiten que los scripts de bitcoin realicen operaciones matemáticas complejas directamente dentro del script.Satoshi Nakamoto mismo eliminó OP_CAT porque el código de operación se limitaba a 2000 bytes cuando el script de bitcoin se limitaba a OP_DUP, los scripts intensivos en datos podrían construirse en combinación con OP_DUP.Los scripts de esta escala pueden aumentar la carga de recursos informáticos en los nodos de bitcoin y sobrecargarlos.Sin embargo, la actualización de Taproot introdujo un límite de tamaño (520 bytes) para scripts de taproot en 2021, por lo que OP_CAT ya no presenta una sobrecarga computacional excesiva para los operadores de nodos.

7. Implemente los convenios utilizando BIP 347 (OP_CAT)

La actualización de Taproot 2021 presenta firmas de Schnorr en el lenguaje de secuencias de comandos Bitcoin.Schnorr Signature admite la agregación de clave pública y privada, lo que permite a múltiples partes firmar una transacción juntas a través de una sola firma.La combinación del código de operación de verificación contenido en la firma Schnorr con OP_CAT puede crear un contrato no recursivo que genera un hash de transacción.A través de OP_CAT, los usuarios pueden restringir ciertas partes de una transacción, como enviar una dirección o el monto de envío, como un requisito para el script de desbloqueo, y el hash de la transacción sirve como la clave para desbloquear.

Tomando el esquema de bóveda como ejemplo, la siguiente es una descripción general de cómo la función OP_CAT implementa los convenios.Los detalles técnicos de este ejemplo están más allá del alcance de este artículo.

Alice quiere crear una bóveda que desbloquee su utxo después de 100 bloques:

*Paso 1:Alice gasta su utxo en una dirección de bóveda y contiene detalles de la condición de gasto del guión de desbloqueo de bóveda en el campo de los testigos, incluida la altura del bloque.

*Paso 2:Durante la transacción de Alice, OP_CAT conecta las instrucciones de desbloqueo de bóveda en el campo de los testigos y las hash dos veces para obtener el Sighash/Txhash.

*Paso 3:Después de confirmar 100 bloques, Alice inicia el proceso de gastar su bitco bitcoin transmitiendo las transacciones de gasto de Utxo.Para verificar que Alice cumpla con todas las condiciones de gastos, su billetera ejecuta el código de operación de SIG en segundo plano.Esta operación realiza dos validaciones clave: verifique que el hash de la transacción en la transacción de configuración inicial (Paso 1) y compárelo con la transacción de gasto actual (paso 3).La función CheckSIG reconstruye los componentes que configuran la transacción y verifican la firma clave pública de la transacción actual para garantizar que se cumplan todas las condiciones de gasto de bóveda.

*Paso 4:Después de que la clave pública de la transacción de Alice se verifica mediante CheckSig (CheckSig reconstruye las condiciones de gasto almacenadas en el campo de los testigos), Alice es libre de gastar su utxo.

El ejemplo anterior muestra que OP_CAT en sí no puede implementar condiciones de gasto en las transacciones, pero que OP_CAT combinado con otros códigos de operación en los scripts de Bitcoin puede simplificar las secuencias de comandos y, por lo tanto, implementar convenios.La única función de OP_CAT es conectar dos elementos en la parte superior de la pila.

Aunque OP_CAT se puede usar junto con CheckSig para crear convenios, agregar OP_CAT solo no aporta la funcionalidad similar a la solidez a los scripts de Bitcoin.Esta limitación también se aplica a agregar solo OP_CTV.Incluso con OP_CAT, las transacciones de Bitcoin solo pueden realizar una introspección mínima, lo que significa que las transacciones no pueden acceder completamente a los elementos o estados de transacciones anteriores.Por lo tanto, OP_CAT solo puede admitir convenios de grano fino de la salida de la transacción Taproot.OP_CAT no puede fijar la salida de nodos de hoja por taproot o verificar las teclas internas utilizadas.Un nodo de hoja de taproot es una condición o script de gasto único enviado a la salida Taproot.Pueden considerarse como diferentes «caminos» o formas de gastar bitcoin; cada nodo de hoja representa una posible forma de gastar.La clave interna en una transacción Bitcoin Taproot es la clave pública principal utilizada para la ruta de gasto más eficiente.Al gastar UTXO con una clave interna, solo necesita proporcionar la firma en la cadena sin revelar ningún scripts o rutas de merkle.

Cabe señalar que estas limitaciones pueden resolverse mediante otras propuestas de código de operaciones como OP_TWEAK_VERIFY y OP_INTERNALKEY.En general, OP_CAT se puede ver como el principal bloque de construcción que genera condiciones de gasto complejas en las salidas de transacciones, sin embargo, otros bloques de construcción, incluido el chequeo, son cruciales para avanzar en la programabilidad de las transacciones de bitcoins.

8. Características clave que los convenios pueden traer a Bitcoin

(1) Puente sin confianza y salida unilateral

Starkware (Creador de Starknet ZK-Rollup en Ethereum) lanzó un informe que destaca cómo OP_CAT admite la creación de validadores y validadores de Merkle para puentes de bitcoin sin confianza.El puente sin confianza se construye con un sistema de contrato recursivo que mantiene el estado de puente al registrar una cadena de transacciones en el árbol de Merkle.El núcleo de este mecanismo es el estado de persistencia del puente almacenado en la salida OP_return que no gastan, que contiene el hash raíz del árbol de Merkle que representa el saldo de la cuenta.El pacto OP_CAT requiere que cada nueva transacción de depósito o retiro contenga una transición de estado válida que refleje el estado puente actual.Los usuarios interactúan con puentes a través de convenios dedicados de depósito y retiro que usan Merkle Tree para agregar transacciones múltiples en lotes para una verificación eficiente.Las raíces del árbol de Merkle se fusionan en el contrato del puente principal, que verifica y procesa cada depósito o retiro.Durante el retiro, la escritura verifica la propiedad al garantizar que la dirección de retiro coincida con la dirección ingresada en la primera entrada en la transacción de la hoja.El diseño utiliza la prueba de Merkle para actualizaciones estatales eficientes en los scripts de Bitcoin para crear un sistema sin confianza donde el estado y las reglas del puente se aplican por completo a través de la lógica de contrato en la cadena creada por OP_CAT sin la necesidad de una confianza de terceros.De manera crucial, para el puente de Bitcoin sin confianza de las transiciones de estado del sistema en el lado de la verificación, el script de bitcoin necesita prueba de verificación.OP_CAT habilita el script de bloqueo UTXO para verificar la transición de estado de estado a prueba de ZK (prueba de conocimiento cero) de estado conectando datos hash.

El equipo de Wizard Taproot ha innovado un nuevo marco de puente de confianza que combina OP_CAT con BITVM.BITVM logra las capacidades de expresión completa de Turing al permitir la segmentación y ejecución de la computación arbitraria en Bitcoin.BITVM divide el tiempo de ejecución de los cálculos arbitrarios en múltiples transacciones en bitcoin utilizando el tiempo de ejecución de la computación arbitraria del script bitcoin.Sin convenios, los puentes BITVM que bloquean Bitcoin requieren transacciones previas firmadas para configurar el puente.La capacidad de OP_CAT para transportar datos de transacciones anteriores permite que el puente BITVM bloquee y desbloquee bitcoin sin transacciones previas al firmado.OP_CAT puede transportar datos de transacciones anteriores a través de una técnica llamada «CAT en la pila».Este truco implica concatenar los datos de hash en la pila para construir una raíz de árbol de Merkle, que OP_CAT puede verificar.Por lo tanto, el puente CATVM asegura que los datos de transacciones específicos de transacciones, depósitos y retiros anteriores deben incluirse en la próxima transacción para garantizar que la raíz de Merkle continúe después de un retiro exitoso.El gato en los consejos de la pila también asegura que después de que un usuario se retire, cualquier usuario elegible puede retirar los bitcoins puentes restantes.

(2) Fideicomiso de bóveda avanzada

Bitcoin Vault es una nueva solución de custodia que incluye características de seguridad como rutas de recuperación que permiten a los usuarios retirar sus bitcoins a una dirección secreta en caso de filtraciones de clave privada.BIP 345, oficialmente llamado OP_Vault, es una propuesta pendiente de mejora de Bitcoin que utiliza OP_CTV para mejorar los parámetros de seguridad de la custodia de Bitcoin.Cabe señalar que OP_CAT también se puede usar para crear una bóveda de bitcoin para las condiciones de gasto sin transacciones previas a la firma.El desarrollador de Bitcoin Core, James O’Beirne, propuso OP_Vault en enero de 2023 para reducir el alcance de los casos de uso de OP_CTV.OP_Vault se basa en OP_CTV para crear condiciones de gasto para Bitcoin de bóveda sin que el depositante firme múltiples transacciones por adelantado.Los convenios permiten que las bóvedas tengan retrasos en el tiempo, y cuando alguien intente gastar bitcoins de bóveda antes del bloqueo de tiempo original, se activará el retraso de tiempo, generalmente es un atacante que intenta robar fondos.

(3) Contrato de no equivalencia

El contrato de no equivalente se introdujo en la red de bitcoin en 2015 y es la salida de las transacciones de bitcoin.En la práctica, los usuarios bloquean Bitcoin nativos como un depósito que puede ser confiscado.Este margen permite al usuario ejecutar 0 transacciones de confirmación en la capa base, que luego se excavan en el bloque.0 Las transacciones de confirmación son transacciones instantáneas de bitcoin verificadas y protegidas por las reglas de consenso de Bitcoin.Si el remitente del 0 confirma que la transacción gasta la entrada antes de extraer la transacción, la contraparte puede confiscar su margen de bitcoin de la clave de firma filtrada.

(4) Mejora de la red Lightning

OP_CAT puede habilitar el canal de fábrica, lo que permite a los usuarios abrir un canal de rayos sin abrir las transacciones primero en la capa base BTC.Por ejemplo, si Alice quiere crear 2 canales de rayos (uno con Bob y el otro con Charlie), Alice transmitirá las transacciones abiertas del canal con Bob y Charlie (2 transacciones).La transacción de apertura del canal requiere que ambas partes depositen Bitcoin en 2/2 de la dirección de firma múltiple.A través de la fábrica de canales, Bob y Charlie pueden abrir canales separados entre sí sin transmitir nuevos canales para abrir transacciones.Por lo tanto, todos los participantes en la transacción abierta del canal original pueden crear canales independientes entre sí.

OP_CTV puede crear UTXOS compartidos, donde un UTXO representa múltiples usuarios.UTXO compartido usando CTV permite a varios usuarios abrir múltiples canales de rayos a través de una transacción en la cadena.Por lo general, cada canal de rayos requiere una transacción en la cadena.Por lo tanto, si muchos usuarios encienden el canal Lightning, esto puede llenar el grupo de memoria con transacciones pendientes y aumentar las tarifas de transacción.Si bien esto no es un problema en este momento, la apertura del canal debe ampliarse para admitir la red Lightning para atraer a millones de usuarios activos.

9. Riesgos relacionados con OP_CAT y OP_CTV

Todas las horquillas blandas de Bitcoin contienen riesgos técnicos, como errores en nuevos códigos de operación o casos de uso imprevistos.Aunque el primero es raro, el segundo está expuesto en la creación de inscripciones.La inscripción implica ingresar datos arbitrarios en el campo de testigos de la transacción, que se ha utilizado para crear nuevas tokens y colecciones NFT en Bitcoin.Las actualizaciones de SEGWIT y Taproot permiten conjuntamente que los usuarios ingresen datos de imagen y texto como datos de cadena en el campo Testigo.Si bien el arte digital y la creación de tokens alternativos no son el foco de activar Segwit o Taproot, años después, los desarrolladores inteligentes han descubierto cómo estas actualizaciones pueden usarse para otros fines.Galaxy Research destacó este punto en nuestro informe de Ordinales, señalando que las inscripciones creadas inesperadamente a través de Segwit y Taproot podrían tener un impacto negativo en las futuras actualizaciones de Bitcoin, ya que la sorpresa de la comunidad en estos nuevos casos de uso podría hacer que sea aún más vacilante apoyar nuevos horquillas suaves.

A pesar de la existencia del sentimiento bajista en la capacidad de Bitcoin para actualizar, OP_CAT y OP_CTV han sido probados y estudiados ampliamente.La crítica inicial de los convenios fue que el gobierno podría obligar a las solicitudes a hacer cumplir las condiciones de gasto que permitirían solo un conjunto de direcciones aprobadas para gastar bitcoin.Esta crítica no es válida porque las condiciones para el gasto están determinadas por los usuarios que poseen los fondos.Los usuarios pueden crear transacciones que limitan el gasto futuro a una dirección específica, pero estas restricciones no pueden ser aplicadas externamente por terceros y no pueden extenderse permanentemente después de que se gastan fondos bloqueados.Por lo tanto, el gobierno no puede hacer cumplir las aplicaciones de bóveda autocustodial o cómo el puente gasta dinero.Si bien los intercambios de custodios y bitcoin aún pueden limitar cómo los usuarios gastan dinero, no pueden agregar condiciones de gasto permanentes para retirar fondos sin la capacidad de ejecutar el contrato general, y OP_CTV no permite contratos generales.

En general, OP_CAT y OP_CTV son códigos de operación simples, cada uno realizando bien una función.OP_CAT se une a dos elementos en la parte superior de la pila, mientras que OP_CTV puede hash las condiciones de gasto en el script de bloqueo.Algunos casos de uso de estos códigos de operación (como el desarrollo de puentes sin confianza) todavía requieren más investigaciones y pruebas prácticas, ya que los puentes son extremadamente vulnerables a los errores y los ataques de piratería.

10. La siguiente ruta de implementación de los convenios de actualización de horquilla suave

Determinar el consenso de las partes interesadas de Bitcoin sobre futuras actualizaciones de protocolo es un proceso complejo que evoluciona con el ciclo de vida de la propuesta, también conocido como el proceso BIP (propuesta de mejora de bitcoin).El informe BCAP sobre el historial de actualización de Bitcoin describe los roles de estas partes interesadas en detalle de la siguiente manera:

*Nodo económico:Intercambios, custodios, comerciantes, proveedores de pagos

*inversor:Ballena gigante, microstrategia, proveedor de ETF, galaxia

*Celebración de los medios:Coindesk, Bitcoin Magazine, x celebridades, podcasts

*Guardaespaldas:Bitmain, Microbt, Riot, Marathon, grandes mineros privados

*Desarrollador de protocolo:Desarrollador de núcleo de bitcoin

*Desarrollador de aplicaciones:Proyecto L2

A lo largo del ciclo de vida de la propuesta de mejora de bitcoin (BIP), los diferentes interesados ejercen diversos grados de influencia, y su influencia relativa cambia durante la implementación de la construcción de consenso de horquillas blandas.Las siguientes son divisiones detalladas de cada nivel de influencia de las partes interesadas, clasificación por 1-10.A partir de marzo de 2024, OP_CAT y OP_CTV están en la etapa de concepción de protocolo.Las figuras de los medios están en la etapa más influyente porque pueden influir en la opinión pública y crear narrativas.Por ejemplo, Taproot Wizards es un equipo de conocidas celebridades de Bitcoin que usan su enorme base de fanáticos de las redes sociales para promover los beneficios de OP_CAT a la comunidad de Bitcoin.El equipo de Taproot Wizards ha estado produciendo contenido educativo e investigación sobre OP_CAT para impulsar una narración en la que los guiones de bitcoin requieren nuevos códigos de operación para mejorar la programabilidad de las transacciones.Como resultado, Taproot Wizards ha desarrollado una gran cantidad de seguidores para OP_CAT, que están presionando a los desarrolladores principales para que revisen el borrador de BIP OP_CAT.

Durante la fase de concepción de protocolo, los desarrolladores de Bitcoin Core ocuparon el segundo lugar en la influencia porque los editores de BIP fueron responsables de revisar el borrador del BIP pendiente y, lo más importante, fueron las únicas entidades que podían fusionar BIP en el apositorio de Bitcoin Core Github.Sin el apoyo de los desarrolladores de Bitcoin Core, BIP inevitablemente se suspenderá y finalmente se rechazará.Los desarrolladores de Bitcoin Core también son responsables de mantener la base del código de Bitcoin y garantizar que no contenga ningún error.Un consenso entre los desarrolladores centrales de Bitcoin es un proceso difícil, ya que las perspectivas ideológicas pueden variar entre los desarrolladores centrales, y la influencia de cada desarrollador central en el proceso de toma de decisiones varía según la contribución y el contexto.

OP_CAT y OP_CTV BIP se encuentran en la etapa donde las celebridades de los medios, los usuarios y los desarrolladores de aplicaciones usan su influencia para convencer a los desarrolladores centrales de Bitcoin de que estos cambios de consenso mejorarán la programabilidad de las transacciones de Bitcoin.La siguiente fase del viaje de consenso requerirá una investigación específica de celebridades tecnológicas, desarrolladores de aplicaciones y desarrolladores centrales, que detalla todos los riesgos potenciales de OP_CAT y OP_CTV.Sin una investigación específica y un diálogo abierto con desarrolladores centrales, no habrá una comunidad de desarrolladores centrales más amplia que haya formado una visión colectiva de OP_CAT y OP_CTV.

Una vez que se alcanza un consenso entre los desarrolladores centrales, OP_CAT y OP_CTV deberán designar a un mantenedor primario para facilitar el paso final de implementar BIP en el repositorio del núcleo de Bitcoin.Después de que el BIP de OP_CAT y OP_CTV se fusionan en el repositorio de núcleo de Bitcoin, es necesario decidir sobre el método de activación.Una vez que se selecciona el método de activación, comienza el período de señal, y los mineros, los inversores y los nodos económicos tienen la mayor influencia.A partir de marzo de 2024, los grandes inversores como los mineros, el microstrategio y los nodos económicos como Coinbase aún no han expresado opiniones públicas sobre OP_CAT y OP_CTV.Antes de la implementación de BIP, estos interesados deben comprender más sobre los riesgos y beneficios de OP_CAT y OP_CTV.

11. Método de activación de BIP

Si los desarrolladores de Bitcoin Core acuerdan incluir OP_CAT u OP_CTV en la próxima actualización de horquillas suaves, la comunidad debe acordar cómo activar BIP.El método de activación permite a los mineros indicar su preparación para la actualización.

En términos generales, hay dos formas de realizar cambios de código en Bitcoin.Primero, puedesBifurcadoRealizar cambios en el código.Las horquillas blandas son actualizaciones compatibles hacia atrás que permiten a los operadores de nodo Bitcoin se ejecutarán de manera segura en la red de bitcoin incluso sin actualizar su software de cliente.Otro beneficio de la compatibilidad hacia atrás de las horquillas suaves es que cualquiera que no esté de acuerdo con la dirección de Bitcoin Core (el cliente principal de Bitcoin) puede optar por ejecutar una versión anterior del software del cliente que excluye nuevas activaciones de BIP, pero aún puede conectarse a la cadena de bloques canónica de Bitcoin.Las horquillas suaves agregan funcionalidad creando nuevas condiciones que son más limitadas que los conjuntos de reglas existentes, por lo que se ajusta a las reglas existentes.

Cuando un usuario activa una bifurcación suave (no un minero), se llama una horquilla suave activada por el usuario (UASF).El ejemplo de UASF más famoso en Bitcoin ocurrió casi durante la «batalla de tamaño de bloque» el 1 de agosto de 2017 para ayudar a acelerar la adopción de la actualización de Segwit.Durante la batalla del tamaño del bloque, los usuarios de Bitcoin actualizaron sus nodos para admitir actualizaciones de SEGWIT y posteriormente amenazaron con rechazar bloques de nodos nocalados.Al hacerlo, se alienta a los mineros que no han actualizado su software de clientes de Bitcoin a adoptar SEGWIT para que sus bloques se propagen más y aumenten sus posibilidades de recibir recompensas de bloque.Aunque el UASF nunca ocurrió durante la guerra del tamaño del bloque, la amenaza de la adopción de los mineros potenciales de UASF afectó a SEGWIT.

La segunda forma de implementar cambios en el código es a través deHorquilla dura, Esta es una actualización incompatible hacia atrás que dividirá permanentemente el consenso entre los nodos actualizados y no superados.Los desarrolladores centrales de Bitcoin nunca han implementado una horquilla dura porque la comunidad valora la solidificación y la compatibilidad atrasada del código de protocolo.Si un pequeño número de usuarios realizan actualizaciones de horquillas duras (como cambiar el tamaño del bloque), puede ocurrir una división de cadena en Bitcoin.Así es como se creó Bitcoin Cash en 2017, cuando parte de la comunidad de Bitcoin no estuvo de acuerdo con la actualización de Segwit, con la esperanza de aumentar simplemente el tamaño del bloque activando los cambios de código incompatibles hacia atrás para salir del protocolo de Bitcoin.

Además de la diferencia entre la horquilla dura y la activación de la horquilla blanda, hay diferentes formas de medir el sentimiento de la comunidad sobre la escalada antes de que ocurra la bifurcación.Aquí hay una descripción general de varios tipos de procesos BIP propuestos por la comunidad de Bitcoin para apoyar mejor la activación de actualizaciones de horquilla suave:

*BIP 9:BIP 9 proporciona un marco para que los mineros indiquen su soporte para actualizaciones de horquilla suave modificando la versión bitfield en el encabezado del bloque bitcoin.Una vez que termina el período de señal, la comunidad de Bitcoin puede evaluar el porcentaje de mineros que apoyan actualizaciones y votos ponderados por el poder informático de los mineros.Si se excede un cierto umbral de soporte, la actualización puede continuar siendo activada en el «día de la bandera», que es solo una altura de bloque especificada para la activación de la actualización.

*BIP 8:El desarrollador de Bitcoin Core a largo plazo, Luke Dashjr (que ha estado trabajando en el desarrollo de Bitcoin desde 2011) propuso BIP 8 como sucesor de BIP 9 en febrero de 2017.BIP 8 recomienda usar la altura del bloque en lugar de la potencia informática para determinar la duración del período de señal para una propuesta de aprobación.BIP 8 también presenta un nuevo parámetro Soft Fork de activación en la cadena llamado «Lote».Si este parámetro se establece en «verdadero», se debe emitir una señal durante el período final para garantizar que la bifurcación suave esté bloqueada a la altura del tiempo de espera.A partir de aquí, las actualizaciones en los días de bandera predefinidos se activan por nodos, independientemente de si el minero señala o no.BIP 8 intenta reducir la interferencia de los mineros en la activación de la propuesta deseada de la comunidad y obliga a los mineros a considerar las consecuencias de los ingresos perdidos debido a no recibir bloques de nodos mejorados con el parámetro de lote actualizado establecido en verdadero.

*Prueba rápida:Los desarrolladores de Bitcoin Core AJ Townes y Andrew Chow presentaron una versión de BIP 8 llamada Speedy Trial en abril de 2021.Prueba rápida intenta acelerar el horario del minero para emitir señales de preparación de activación.Este enfoque significa que la propuesta se activará una vez que la mayoría de los bloques mineros envíen una señal preparada dentro de un período específico.La prueba rápida aparece similares a las implementaciones de activación de BIP 9, pero con una ventana de activación más corta.Recientemente, la actualización de taproot se ha activado en Bitcoin a través de una prueba rápida.La prueba requiere que el 90% de los bloques mineros envíen una señal preparada dentro de las dos semanas antes de que Taproot se pueda activar en la red.El juicio terminó el 12 de junio de 2021.Después de alcanzar el umbral del 90% de soporte minero, la red ingresa a un período de espera de cinco meses para dejar tiempo de mineros y nodos para actualizar su software.Taproot se activó oficialmente en Bitcoin el 15 de noviembre de 2021.

*Activación moderna de horquilla suave:Este es un método para actualizar la activación que combina diferentes atributos de BIP 9 y BIP 8.Fue propuesto en enero de 2020 por Matt Corallo, uno de los contribuyentes más prolíficos de Bitcoin Core.El método incluye tres pasos.El primer paso es la horquilla suave de activación del minero descrito en BIP 9.Si los mineros no pueden activar la actualización, el proceso moderno de activación de la horquilla suave descrita por Corallo valerá el segundo paso, el período de espera de seis meses para los desarrolladores y la comunidad más amplia de Bitcoin reconsideran los cambios de código.Seis meses después, si los desarrolladores y usuarios desean continuar actualizando, pueden comenzar el Paso 3, que es esencialmente equivalente a BIP 8 con el parámetro LOT establecido en True.

12. Conclusión

Aunque OP_CAT (BIP 347) y OP_CTV (BIP 119) han recibido el apoyo de muchos desarrolladores de Bitcoin conocidos, estas propuestas aún requieren un largo proceso de diligencia debida antes de la implementación.Esto se debe a que OP_CAT y OP_CTV requieren cambios en la capa de consenso de Bitcoin, y el proceso de gobernanza de BIP para tales cambios es muy extenso.Aunque el cronograma de activación para BIP 119 y BIP 347 no está claro e impredecible, el largo período de revisión puede beneficiar a la propuesta, ya que proporciona a la comunidad mucho tiempo para comprender los beneficios y los impactos de OP_CTV y OP_CAT.Además, los contribuyentes de BIP tendrán más tiempo para probar OP_CTV y OP_CAT, así como su impacto potencial en los errores futuros en los scripts de Bitcoin.

Aunque aún se está explorando todo el potencial de OP_CAT y OP_CTV, su impacto más directo es la implementación de puentes sin confianza y bóvedas de seguridad de seguridad avanzadas para Bitcoin L2.La importancia del puente sin confianza para Bitcoin L2 compatible con EVM es evidente, especialmente en el contexto del creciente entorno de crecimiento de Bitcoin Defi.Estas soluciones sin confianza representan avances significativos sobre las alternativas actuales como WBTC y CBBTC, que se basan en intermediarios de confianza y debilitan la naturaleza sin permiso de la tecnología blockchain.Si bien las bóvedas de bitcoin de autocustodial pueden ofrecer el valor más práctico en soluciones de custodia, el potencial de los puentes L2 sin confianza demuestra las posibilidades más amplias que la programabilidad de transacciones mejorada aporta a Bitcoin.

La comunidad de desarrolladores ha logrado un progreso significativo en la promoción de estas propuestas en 2024, y este buen impulso puede continuar en 2025.Como la actividad comercial de bitcoin tiende a disminuir y las tarifas de transacción tan bajas como 1 SAT/VB, el enfoque actual está cambiando a cómo restaurar la actividad de transacción en la red de bitcoin.Aunque nuestro informe de pronóstico de Galaxy Research 2025 cree que los desarrolladores de Bitcoin Core alcanzarán un consenso entre OP_CAT u OP_CTV, el proceso final de implementación y activación puede llevar 1-2 años.Sin embargo, la adopción final de estas propuestas será un hito importante en la evolución de los scripts de bitcoin, estableciendo las bases para aplicaciones de bitcoin más complejas y seguras en el futuro.

Al mejorar la programabilidad de las transacciones, Bitcoin podrá apoyar casos de uso más innovadores, como puentes transversales de confianza y soluciones de custodia avanzada, impulsando aún más el ecosistema de bitcoin.La introducción de estas tecnologías no solo mejorará la funcionalidad de Bitcoin, sino que también proporcionará a los desarrolladores y usuarios más herramientas para construir aplicaciones descentralizadas más seguras y eficientes.Si bien lograr estos objetivos requiere esfuerzos de tiempo y comunidad, su impacto potencial sin duda inyectará una nueva vitalidad en el futuro de Bitcoin.