¿Está sucediendo OP_CAT? A la propuesta de convenios se le acaba de asignar el número BIP #347. Pero antes de profundizar más, exploremos qué son los convenios y por qué los Bitcoiners pueden quererlos.
¿Es Bitcoin un estado ideal de efectivo electrónico digital o queremos más de nuestras monedas en cadena?
Arañando la superficie: limitaciones de los scripts de Bitcoin
Para comprender propuestas de pactos como OP_CAT, es crucial asimilar las limitaciones fundamentales de Bitcoin Script tal como es hoy. En el fondo, Bitcoin permite la creación de contratos inteligentes básicos a través de códigos que definen las reglas para bloquear y desbloquear fondos. Sin embargo, Bitcoin Script, como lenguaje de programación, está bastante limitado a la lógica básica que entra en juego sólo cuando se mueven monedas en una nueva transacción.
Hoy en día, en Bitcoin no hay forma de preconfigurar o dictar las rutas de transacción de sus monedas, o qué tan rápido pueden moverse las monedas en el momento en que están bloqueadas (aparte de los flujos de trabajo hackers que usan PSBT, transacciones de bitcoin parcialmente firmadas, que no pueden funcionar correctamente). incluir tarifas de transacción, demostrar la eliminación si no se utiliza o evitar la transmisión posterior).
Esta simplicidad, si bien es fundamental para el modelo de seguridad de Bitcoin, introduce limitaciones significativas en la capacidad del lenguaje de programación para admitir incluso contratos inteligentes básicos.
Modelo de ejecución lineal
Una limitación de Bitcoin Script es su modelo operativo en el que los códigos de operación se ejecutan secuencialmente sin bucles.
En este ejemplo de una transacción P2PKH, puede ver cómo el script se ejecuta linealmente: duplicar la clave pública, convertirla en una dirección, verificar el hash con el script de bloqueo y, finalmente, verificar la firma con la clave pública.
La ausencia de bucles significa que los scripts no están completos en Turing y se garantiza que terminarán, evitando problemas como bucles infinitos que podrían detener o ralentizar significativamente la red. Si bien esta elección de diseño permite que el uso de recursos esté limitado estáticamente, también limita la capacidad de Script para gestionar flujos de trabajo complejos.
Falta de aritmética básica
Bitcoin Script tiene poco menos de 100 códigos de operación no triviales y, sorprendentemente, no hay capacidad para multiplicar, dividir o combinar objetos en la pila. Como sabrán muchos usuarios interesados en OP_CAT, Satoshi deshabilitó varios códigos de operación en Bitcoin en 2010, incluidos OP_OR, OP_MUL (multiplicar), OP_DIV (dividir) y OP_CAT (concatenar), entre otros. Los códigos de operación deshabilitados se eliminaron porque sus implementaciones originales tenían vulnerabilidades explotables que podrían comprometer la seguridad de la red. Pero la ausencia de estos códigos de operación dificulta la realización de cálculos básicos, que podrían resultar útiles en escenarios simples como calcular las tarifas de transacción en un contrato.
Falta de visibilidad de los datos de las transacciones
Superficialmente, creo que la mayoría de la gente asume que los contratos inteligentes de Bitcoin pueden ver los montos de valor y cualquier otra parte de los datos de las transacciones, ya que esta información ya es visible públicamente en la cadena de bloques. Pero contrariamente a esta suposición, los contratos de Bitcoin no pueden establecer condiciones de gasto basadas en los datos de las transacciones, porque Bitcoin Script tiene una capacidad muy limitada para ver los datos de las transacciones.
Si el script tuviera la capacidad de interpretar más detalles dentro de los datos de las transacciones, podríamos crear contratos mucho más sólidos que pudieran hacer todas las cosas divertidas, como imponer condiciones de gasto específicas, crear transacciones de varias etapas y habilitar funciones de seguridad más avanzadas, como bóvedas.
¿Qué hacemos al respecto?
Sabemos que Bitcoin tiene estas limitaciones y, a lo largo de los años, se han discutido muchas propuestas diferentes para introducir (o en algunos casos reintroducir) esta funcionalidad. Experimentos más amplios con Bitcoin Script, como Simplicity y otros, tienen como objetivo proporcionar una alternativa a las restricciones basadas en pilas. Los códigos de operación como OP_MULTISHA256, OP_LESS y OP_LE32TOLE64 tienen como objetivo mejorar las capacidades aritméticas de Bitcoin. Propuestas como OP_CTV y OP_CAT que tratan con códigos de operación de introspección se agrupan bajo el término convenios.
Entonces, ¿cuál es exactamente la diferencia entre contratos inteligentes y convenios de nuevos plazos?
Contratos inteligentes versus convenios
Los contratos inteligentes son transacciones autoejecutables que transfieren fondos sin intermediarios. Hoy en día, en Bitcoin, los contratos inteligentes se limitan al acto de bloquear y desbloquear bitcoin con Bitcoin Script. Los convenios tienen como objetivo mejorar la funcionalidad de los contratos inteligentes de Bitcoin al permitir a los usuarios controlar cómo se gastan sus fondos en transacciones futuras.
Al permitir que Script interprete los datos de las transacciones, creamos efectivamente una manera de utilizar esos datos en la lógica del contrato.
Estos son sólo algunos de los códigos de operación de introspección más interesantes para la funcionalidad de convenios:
OP_TXHASH: proporciona el hash de las entradas (o salidas) de una transacción y le brinda a Script la capacidad de verificar y hacer cumplir las condiciones basadas en los datos de la transacción.
OP_CSFS + OP_CAT: los dos juntos permiten que los scripts verifiquen las firmas con cualquier dato, no solo con la transacción en sí. Esto significa que Script puede verificar condiciones basadas en datos de transacciones o información externa, ampliando las posibilidades de validación dentro de los scripts de Bitcoin.
Estos dos códigos de operación son intencionalmente amplios y permiten procesos de validación complejos y capacidades de introspección. Otros tienen un alcance más limitado y están diseñados para ser una forma más limitada de convenios.
OP_CHECKTEMPLATEVERIFY (CTV): permite que la salida de una transacción incorpore una plantilla de una transacción de gasto futura, lo que permite convenios de una manera más restringida.
OP_VAULT: habilita una forma específica de convenio utilizada para "bóveda", que permite a los usuarios especificar un destino de transacción pero no mover monedas excepto después de un retraso.
Luego está el OP_CAT por sí solo, que no es directamente un código de operación de introspección...
OP_CAT: permite que el script concatene dos elementos en la pila, lo cual es útil para combinar diferentes piezas de información dentro de un script.
OP_CAT no parece tener ninguna capacidad de introspección, entonces, ¿qué está pasando aquí?
OP_CAT: Desentrañando todas las posibilidades
Introspección de transacciones
En 2021, Andrew Poelstra escribió sobre los trucos de introspección OP_CAT en una publicación de blog. Proporcionó ejemplos específicos, pero supuso que los lectores tenían conocimientos previos de técnicas similares. Aquí, intentaré simplificar esa explicación para una mejor comprensión.
En Bitcoin Script, solo hay tres códigos de operación principales que le permiten realizar una introspección de los datos de la transacción: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY y CHECKSIG. Además, existen variantes como CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG y CHECKMULTISIGVERIFY, que son esencialmente variaciones menores de CHECKSIG. Los dos primeros sólo le permiten ver si la verificación está verificada, lo que proporciona una funcionalidad bastante limitada. CHECKSIG es similar, pero la diferencia aquí es que le permite obtener la firma y la clave pública en la pila. Interesante.
Tradicionalmente, pensamos en la concatenación como una función que une dos elementos, pero también podemos usarla para separar o dividir un elemento, en este caso, la firma en un par (r, s).
¿Cómo derivamos la funcionalidad OP_SPLIT de OP_CAT?
“Si tienes un objeto grande, puedes dividirlo en dos pidiéndole al usuario que dedique tiempo a proporcionar las dos piezas. Los CAT juntos y verificas la igualdad básicamente. Siempre puedes invertir cada operación de esta manera. Con CAT por sí solo puedes separar firmas”. — Andrew Poelstra, TABConf 2021
¿Que está sucediendo aquí?
Al solicitar al usuario que proporcione la firma, la clave pública y la transacción, puede dividir la firma en sus partes componentes y luego comparar cada parte de forma independiente con los datos de la transacción. Esta técnica puede verse como una forma de división o combinación, ya que valida que la firma y la clave pública son de hecho los componentes de una transacción válida.
¿Cómo nos lleva todo esto a la introspección?
“En Taproot, donde tenemos firmas Schnorr usando OP_CAT y el código de operación de verificación de firmas Schnorr, resulta que es posible obtener una forma de pacto no recursivo en el que literalmente se obtiene un hash de transacción. Ni siquiera como un divertido hash de transacción mutilado, sino un hash SHA2 literal de todos los datos de la transacción en la pila”. — Andrew Poelstra, TABConf 2021
Poelstra continúa demostrando cómo se puede obtener un hash SHA2 para las entradas o salidas de transacciones que quedan en la pila. Nos saltaremos las matemáticas lunares aquí, pero la implicación es que con OP_CAT podemos restringir partes de una transacción como requisito del script de desbloqueo. Podemos restringir la dirección de envío o el valor que se envía de esa transacción, donde el hash de la transacción sirve como clave para desbloquearla.
Bóvedas
El uso de las mismas técnicas nos brinda introspección de transacciones y rápidamente nos brinda una versión básica de las bóvedas. Siguiendo la lógica descrita en el blog de Poelstra, un desarrollador llamado Rijndael demostró que podemos hacer esto solo con OP_CAT en su implementación de Purrfect Vaults.
"Reconstruir un TXID en la pila para realizar una introspección de transacciones anteriores fue en realidad más fácil de lo que esperaba". —Rijndael
Con las bóvedas, los usuarios especifican la siguiente dirección a la que deben ir sus fondos, proporcionando mecanismos para la recuperación de fondos en caso de que la clave se vea comprometida y reduciendo el incentivo para el robo de claves privadas.
Árboles Merkle para script
En Bitcoin hoy en día, los Merkle Trees son la estructura de datos utilizada para la verificación y sincronización de datos y, más o menos, "encadenar" las transacciones y los bloques de la cadena de bloques. El código de operación OP_CAT, que permite la concatenación de dos variables de pila, cuando se usa junto con hashes SHA256 de claves públicas, facilita un proceso sencillo de verificación del árbol Merkle para scripts. Este enfoque, propuesto inicialmente por Pieter Wuille en 2015, se implementó con éxito en la red Liquid.
Imagine una estructura de árbol repleta de diversas condiciones de gasto, como preimágenes hash, bloqueos de tiempo y claves públicas, conocidas como firmas de árbol.
Firmas de árboles
OP_CAT permite la creación de Firmas de Árbol que:
“…Proporcione un script de firmas múltiples cuyo tamaño pueda ser logarítmico en el número de claves públicas y pueda codificar condiciones de gasto más allá de n-de-m. Por ejemplo, una transacción de menos de 1 KB de tamaño podría admitir firmas de árboles con mil claves públicas. Esto también permite condiciones de gasto lógicas generalizadas”. — Ethan Heilman, autor de BIP, en la lista de correo de desarrolladores de bitcoin
Esto permitiría la validación de cualquier contenido hash dentro del árbol, manteniendo la integridad y confiabilidad de los datos sin agregar volumen o hinchazón innecesarios a la cadena de bloques.
¿Qué tiene de interesante todo esto?
Pactos recursivos
Si tiene la capacidad de examinar una transacción y aplicar restricciones a ciertas partes de ella, puede configurar condiciones que se trasladen a múltiples transacciones, creando efectivamente una cadena de restricciones continuas. Este concepto se llama pacto recursivo. OP_CAT es una propuesta única porque nos brinda mucho poder con solo 10 nuevas líneas de código. Tiene la capacidad de abordar las tres limitaciones iniciales que cubrimos al comienzo de la publicación: visibilidad de los datos de las transacciones, mejor funcionalidad matemática y su modelo de ejecución lineal.
Si bien OP_CAT puede parecer sencillo al principio, abre un potencial significativo cuando se aprovecha de forma creativa. Sirve como bloque de construcción para aún más funcionalidades que van más allá del alcance de esta discusión, como las firmas Post-Quantum Lamport.
¿Es esto seguro?
Antes de que OP_CAT se eliminara inicialmente, cuando se combinaba con OP_DUP (duplicado) y se usaba repetidamente para duplicar un valor inicial de 1 byte en la pila, el uso de memoria podía explotar. Esto podría haberse utilizado como un ataque de denegación de servicio (DoS) como resultado de un mayor consumo de memoria. La nueva propuesta evita trivialmente este ataque al imponer un límite de 520 bytes a los elementos de la pila.
¿Existe el peligro de que un contrato dure para siempre?
Si con esto queremos decir, ¿OP_CAT cambia el modelo de ejecución de Script para que ya no limite estáticamente su uso de recursos (como una función lineal del tamaño de Script)? No.
¿Los convenios crearían un mercado para otras monedas además de Bitcoin?
Si tiene un pacto recursivo, sí, técnicamente puede crear aplicaciones complejas de capa 2, incluidas NFT, intercambios descentralizados y gatos cuánticos. Sin embargo, hacerlo no es trivial. Es difícil ver que algún mercado serio lo haga.
¿Se pueden “contaminar” permanentemente las monedas mediante el uso de CAT?
En el caso de monedas de colores y NFT, al emitir estos activos, el usuario efectivamente "quema" un satoshi, marcándolo de una manera que indica la propiedad del activo de "capa 2". Este proceso se conoce como monedas "contaminadas". Pero sólo el propietario de una moneda puede marcar su moneda, y las carteras de Bitcoin ya no la reconocerán (a menos que sus autores agreguen explícitamente un código para habilitarlo). Las monedas resultantes no serían aceptadas por las billeteras bitcoin. Probablemente serían aceptados por billeteras cryptocat o algo así, pero esto es irrelevante para la mayoría de los usuarios de bitcoin.
¿Crearía esto un problema MEV en Bitcoin?
Un punto clave de distinción entre Bitcoin y Ethereum es la visibilidad de las transacciones. A diferencia de Ethereum, no todos los aspectos del contrato son necesariamente transparentes, lo que significa que los mineros de Bitcoin no tienen la misma capacidad para ver el estado interno del contrato y ejecutarlo.
La principal preocupación de OP_CAT por parte de los Bitcoiners con mentalidad económica es el potencial de valor extraíble minero (MEV). Como se discutió más extensamente en mi publicación anterior sobre el tema. A muchos usuarios les preocupa que si hacemos técnicamente posibles los contratos de capa 2, MEV se volverá inevitable. ¿Pero es esto cierto? Específicamente, ¿la viabilidad técnica de las monedas de capa 2 en Bitcoin implica su creación y adopción inevitables?
Se podría imaginar la creación de contratos de intercambio simples o NFT comparativamente ineficientes, pero construir algo tan complejo como DEX con creadores de mercado automáticos parece extremadamente improbable y nunca es algo que hayamos visto en Liquid a pesar de la "posibilidad técnica" para ello.
Entonces, ¿OP_CAT es realmente perfecto?
Difícilmente, ni mucho menos. A algunas personas les encantaría ver convenios recursivos, mientras que otras simplemente no quieren que Bitcoin cambie en absoluto.
Una facción de Bitcoiners, los “osificacionistas”, aboga por preservar Bitcoin en su estado actual y ve con escepticismo cualquier actualización del protocolo. Les preocupa especialmente que cambios significativos, como la introducción de convenios, puedan socavar la descentralización de la red. Su argumento se basa en la creencia de que es mejor atenerse estrechamente a la visión original de Bitcoin. La ironía es que OP_CAT era inicialmente parte de Bitcoin, lo que alimenta un contraargumento. Algunos creen que recuperar OP_CAT podría en realidad realinear Bitcoin con la visión inicial de Satoshi.
Si desea ver algunas de las características de seguridad que los convenios recursivos podrían hacer posibles, OP_CAT sería bueno, pero definitivamente no tan bueno como un lenguaje de scripting estilo Lisp en toda regla. El problema aquí es que esto sería un cambio masivo para Bitcoin, que no es probable que encuentre su lugar en el corto plazo.
O tal vez esté en el otro extremo y prefiera la simplicidad de recursos no recursivos como OP_CTV u OP_VAULT. Los pactos no recursivos son más simples y fáciles de razonar, sin el riesgo de crear una cadena incontrolada de restricciones.
¿Qué pasaría si alguna versión de convenios recursivos fuera inevitable?
A lo largo de los años, los desarrolladores han notado que casi cualquier extensión de la lógica de validación de transacciones podría usarse para emular la funcionalidad de OP_CAT.
En el universo Script, hay dos ámbitos, según el tamaño de los elementos de la pila. Para elementos de pila de más de 4 bytes, puede comparar la igualdad, interpretar como clave una firma o aplicar hash. Para elementos de pila menores o iguales a 4 bytes, puede tratarlos como objetos para realizar operaciones aritméticas o bifurcaciones. Con un procesador RISC-V ejecutándose en un BitVM, puedes hacer literalmente cualquier cosa. Cualquier cosa que le permita emular OP_CAT, dividir elementos de la pila o concatenarlos reúne estos dos ámbitos, de modo que pueda "hacer cualquier cosa" con Script.
Investigadores como Andrew Poelstra esperan que podamos hacer convenios recursivos con prácticamente cualquier código de operación nuevo. De ser cierto, eso sería una justificación para trabajar en pos de una manera de hacerlos bien.
¿Es OP_CAT el camino probable a seguir para los convenios?
Si los convenios no sólo son interesantes, sino inevitables, ¿cómo podemos asegurarnos de que se implementen de tal manera que consigan que más usuarios de Bitcoin envíen sin confianza, como Satoshi imaginó originalmente? Si bien los osificacionistas siguen divididos, OP_CAT continúa ascendiendo como un fuerte contendiente en el debate sobre los pactos.
OP_CAT no es el cincel más elegante, pero sí uno con la mejor relación entre potencia y complejidad, lo que permitiría a los desarrolladores crear algunas características nuevas e increíbles.
Esta es una publicación invitada de Kiara Bickers. Las opiniones expresadas son enteramente propias y no reflejan necesariamente las de BTC Inc o Bitcoin Magazine.
Fuente: Revista Bitcoin
La publicación OP_CAT: ¿La solución perfecta para los convenios? apareció por primera vez en Crypto Breaking News.
