El artículo "Resurrección" fue borrado por el Código de Operación de Satoshi Nakamoto?, léase OP_CATSoft Fork

Artículo original de Jaleel, BlockBeats

En la base de código de Bitcoin, un código de operación “OP _CAT” que ha sido eliminado por Satoshi Nakamoto y ha sido sellado por la historia durante mucho tiempo puede ser “resucitado”.

En torno al Código de Operación OP_CAT, el proyecto de tokens no fungibles de Bitcoin Taproot Wizards ha lanzado una nueva serie de tokens no fungibles Quantum Cats. Aunque el término OP_CAT no se refiere al conocido “gato”, Taproot Wizard ha utilizado la imagen de un gato para lanzar un nuevo token no fungible llamado Quantum Cats, utilizando la cultura de memes para ayudar a OP_CAT a generar impulso. Lectura relacionada: “Bitcoin “Quantum Cat”: Sin contrato inteligente, ¿cómo lograr un cambio dinámico de inscripciones?”

OP_CAT, el Código de Operación que una vez fue eliminado por Satoshi Nakamoto del lenguaje de scripting de Bitcoin, ahora ha vuelto a la mesa para su discusión, y algunos desarrolladores de Bitcoin quieren “resucitar” este Código de Operación y allanar el camino para que Bitcoin implemente el Contrato Inteligente a través de una bifurcación suave de 13 líneas de código. Impulsado por los desarrolladores de Bitcoin y creado en la imagen de un meme de gato, el calor y la discusión sobre OP_CAT ha alcanzado nuevas alturas.

El Código de Operación de “Resurrección” borrado por Satoshi Nakamoto

Los códigos de operación, también conocidos como instrucciones o funciones, son los componentes básicos del lenguaje de scripting de Bitcoin. Históricamente, algunos Operation Code se han eliminado de versiones anteriores de Bitcoin debido a preocupaciones sobre posibles vulnerabilidades en las implementaciones de los clientes, OP_CAT Operation Code es una de ellas.

OP_CAT fue originalmente parte del conjunto de comandos oficial de Bitcoin, lo que permite la unión de cadenas, empalmando dos elementos en uno. Sin embargo, debido a que una vulnerabilidad crítica encontrada en Operation Code, como OP_LSHIFT podría causar que cualquier BitcoinNode se bloquee, existe la preocupación de que OP_ CAT Operation Code pueda hacer que los elementos de la pila crezcan exponencialmente, lo que puede conducir a un aumento exponencial en el uso de memoria y el tamaño del script.

Por lo tanto, por precaución, Satoshi Nakamoto retiró el OP_CAT el 15 de agosto de 2010. Estos códigos de operación eliminados a menudo se denominan “deshabilitados”, pero esto no es exacto, ya que se eliminan por completo del protocolo, lo que hace que el código de operación no esté disponible para nadie que use Bitcoin.

En octubre de 2023, el desarrollador de Bitcoin Core, Ethan Heilman, y el ingeniero de software principal de Botanix Labs, Armin Sabouri, publicaron conjuntamente un borrador de Propuesta de Mejora de Bitcoin (BIP) titulado “OP_CAT” que llevó esta discusión a un nuevo nivel.

Este borrador, que consta de solo 13 líneas de código, tiene un carácter funcional claro e intuitivo, definiendo un nuevo código de operación de toma que permite concatenar dos valores en la pila. Esta implementación de código se inspiró claramente en el OP_CAT eliminado original.

Se han cumplido las condiciones para la “resurrección”

En cuanto a por qué un código de operación que fue eliminado por Satoshi Nakamoto ahora está siendo restaurado por los desarrolladores, la sección motivacional de este borrador de BIP lo explica con cierto detalle: esto se basa principalmente en consideraciones de uso de memoria, y OP_CAT hace que el uso de memoria de las construcciones de script aumente exponencialmente desde el tamaño del script en sí. En concreto, un script simple que simplemente inserta un valor de 1 byte en la pila y, a continuación, lo replica con OP_DUP código de operación y lo concatena 40 veces con OP_CAT código de operación puede hacer que el valor de la pila se amplíe a un tamaño masivo de más de 1 TB.

Sin embargo, con el avance del tiempo y el desarrollo de la tecnología, este problema ya no es un obstáculo. Bajo la arquitectura de TAP, existe una regla clara de que el tamaño máximo del elemento de pila está estrictamente limitado a 520 bytes. Este cambio resuelve de manera efectiva los problemas de uso de memoria que pueden ser causados por OP_CAT, brindando la posibilidad de su “resurrección” e integración.

De ello se deduce que OP_CAT está siendo una vez más sacado a la luz para su discusión y considerado para su reutilización, principalmente debido a su valor potencial en la construcción de scripts más complejos y potentes. Además, una serie de razones y cambios han cumplido las condiciones para la “resurrección”, entre ellos:

1. Demanda de contratos y protocolos inteligentes avanzados: A medida que el ecosistema de Bitcoin ha crecido, ha aumentado la demanda de contratos y protocolos inteligentes más avanzados y complejos. OP_CAT aumenta la expresividad y la funcionalidad de los grifos al permitir que los objetos se combinen en la pila. Por ejemplo, se puede utilizar para crear y evaluar Merkle Tree y otras estructuras de datos hash, admitir firmas de árbol, firmas Lamport poscuánticas, contratos de no repudio, bóvedas y más.

2. Otras historias de éxito on-chain: Algunas bifurcaciones de Bitcoin, como Bitcoin Cash y Sidechain Liquid, han vuelto a habilitar OP_CAT y lo han utilizado para implementar la creación y gestión de tokens, los canales de pago y las formas de incrustar y recuperar datos en la cadena de bloques. Esto indica que el OP_CAT se puede utilizar de forma segura y eficaz en el entorno y las restricciones adecuadas.

3. Exploración de la seguridad cuántica: Algunos estudios han propuesto que si se pueden utilizar operaciones como OP_CAT, combinadas con tecnologías como las firmas de Lamport, se pueden construir transacciones y protocolos de Bitcoin cuánticamente seguros. Esta exploración tiene un valor potencial para mejorar la seguridad futura del sistema Bitcoin.

4. Desarrollo de la comunidad y la tecnología: El desarrollo continuo de la comunidad y la tecnología de Bitcoin ha llevado a las personas a reconsiderar y evaluar decisiones anteriores. A medida que surge una comprensión más profunda del protocolo Bitcoin y las nuevas tecnologías, las características que antes se consideraban problemáticas o inaplicables pueden encontrar casos de uso seguros y útiles en nuevos contextos.

Bifurcación suave, fácil de hablar

A nivel técnico, pocas otras propuestas de Bitcoin son tan fáciles de interpretar y entender como OP_CAT. Pero OP_CAT Código de Operación se activará redefiniendo el Soft Fork del Código de Operación OP_SUCCESS 126, lo que obviamente no es una tarea fácil.

Recordemos que el Soft Fork más reciente de Bitcoin se produjo hace tres años cuando se activó Taproot, lo que ayudó a allanar el camino para el nacimiento de Ordinals.

El consenso y la transparencia son muy valorados por la comunidad de Bitcoin, y cualquier cambio significativo en el código se discute y revisa ampliamente dentro de la comunidad, incluidas las bifurcaciones suaves. Para que un fragmento de código se fusione con la base de código de Bitcoin, debe pasar por un proceso riguroso y detallado que garantice la calidad de la propuesta y el consenso de la comunidad. Estos son los pasos principales de este proceso:

1. Escribe la propuesta y el código: En primer lugar, el desarrollador debe escribir un documento de propuesta detallado. Este documento debe describir claramente la motivación, los detalles técnicos, la evaluación de impacto y cualquier problema o desafío potencial de la propuesta.

2. Discusión de la comunidad: Una vez que se envía una propuesta de código a la comunidad de Bitcoin, es discutida y revisada por los miembros de la comunidad (incluidos desarrolladores, mineros, inversores y usuarios). Esta etapa es clave para garantizar la viabilidad de la propuesta y recopilar comentarios.

3. Modificaciones y mejoras: Con base en los comentarios de la comunidad, es posible que los autores del código deban realizar modificaciones y mejoras a la propuesta.

4. Votar, llegar a un consenso: Algunas mejoras importantes (especialmente las que involucran al propio protocolo Bitcoin) requieren un cierto nivel de consenso entre los miembros de la comunidad. Esto suele implicar el apoyo de los mineros, que deben mostrar su apoyo a la propuesta incluyendo una señal específica en el bloque que extraen.

5. Implementación del código: Una vez que se llegue a un consenso, el código será revisado por el equipo de desarrolladores de Bitcoin Core. Este paso requiere garantizar la calidad y la seguridad del código.

6. Fusionar en la base de código: Después de la aprobación, el código se fusionará con la base de código oficial de Bitcoin.

7. Despliegue y activación: Por último, el nuevo código debe ser desplegado en sus sistemas por los mineros y los operadores de nodos. En el caso de los cambios a nivel de protocolo, suele haber un umbral de activación que solo surtirá efecto cuando suficientes participantes de la red actualicen a la nueva versión.

Obviamente, la implementación del OP_ CAT Soft Fork todavía se encuentra en una etapa muy temprana, menos de cuatro meses después de que se escribió el borrador de BIP, el número de BIP aún no se ha determinado, y todavía se encuentra en la primera fase de escritura de la propuesta y el código y la segunda fase de discusiones de la comunidad que involucran a desarrolladores y usuarios.

Lo que dicen los desarrolladores de Bitcoin

Prestemos especial atención a la discusión de OP_CAT entre los desarrolladores de Bitcoin en los últimos años.

Aunque se eliminó OP_CAT Operation Code, la utilidad potencial de OP_CAT para facilitar contratos avanzados y mejorar los lenguajes de scripting de Bitcoin se ha discutido repetidamente entre los desarrolladores. Por ejemplo, su capacidad para conectar valores de pila se considera una barrera para el desarrollo de algunos protocolos de Bitcoin, como TumbleBit, cuyo tamaño de transacción puede reducirse considerablemente si se admite OP_CAT.

Ahora que hemos reunido el boletín informativo de Optech y una variedad de contenido relacionado, resolvamos algunas de las discusiones de los desarrolladores de Bitcoin sobre OP_CAT Operation Code en orden cronológico.

2019

Ethan Heilman, uno de los patrocinadores del borrador de la Propuesta de Mejora de Bitcoin (BIP) de OP_CAT, dijo en un correo electrónico en octubre de 2019 que entendía por qué se eliminó debido a la grave situación a la que se enfrentaban los scripts en ese momento, pero enfatizó el valor de OP_CAT como código de operación: "La mayoría de los protocolos que quieren construir sobre Bitcoin hoy en día tienen una limitación: los valores de la pila no se pueden conectar. Como investigador, si estoy experimentando esta limitación, es probable que también esté obstaculizando el progreso de los demás. Si pudiera agitar mi varita para volver a habilitar uno de los códigos de operación deshabilitados, elegiría OP_CAT. Por supuesto, esto irá acompañado de una condición: el tamaño de cada valor concatenado debe limitarse a 64 bytes o menos. 」

Cuando se trata de la discusión de OP_CAT, Andrew Poelstra es una persona que nunca puede moverse. El 30 de enero de 2021 escribió un artículo titulado “CAT y Schnorr Tricks I”, que provocó una ola de discusión sobre OP_CAT. Andrew Poelstra es el director de investigación de Blockstream y un veterano desarrollador de scripts de BitcoinCryptography con una fuerte presencia en la industria.

En el artículo, Andrew Poelstra explica: "OP_CAT ayuda a combinar dos elementos de la pila y a devolver el resultado combinado a la pila. Esta función se puede utilizar para ensamblar varios elementos pequeños en un elemento grande o para descomponer un elemento grande en varios elementos más pequeños. CHECKSIGFROMSTACK (CSFS) es un código de operación nunca antes visto en Bitcoin que permite a los usuarios realizar la verificación de firmas en datos arbitrarios, a diferencia del código de operación CHECKSIG, que solo verifica las firmas de transacciones. 」

Además, señala que el uso de OP_CAT junto con CHECKSIGFROMSTACK puede proporcionar un enfoque ingenioso para la introspección transaccional.

Nota: La introspección de transacciones se refiere a la capacidad de examinar y analizar los diversos componentes de una transacción en sí misma en Bitcoin Script. En pocas palabras, permite que el script “entienda” y procese los detalles de la transacción que está procesando, como verificar el resultado de la transacción, el monto o la firma específica. De esta manera, los scripts pueden responder de manera más inteligente y matizada al contenido específico de la transacción.

ESTO PERMITE AL USUARIO PROPORCIONAR LOS DATOS DE TODA LA TRANSACCIÓN EN LA PILA, Y EL SCRIPT USA OP_CAT PARA EMPAQUETAR LOS DATOS EN UN SINGLE ITEM, APLICARLE UN HASH Y, A CONTINUACIÓN, PASARLO A CHECKSIGFROMSTACK PARA COMPROBAR LA FIRMA DE LOS DATOS. A continuación, pasa la misma firma y clave secreta a CHECKSIG. Si se superan ambas verificaciones, indica que los datos de transacción proporcionados por el usuario son datos de transacción reales. De esta manera, el script puede utilizar directamente estos datos para realizar las comprobaciones requeridas por el contrato.

La influencia de Andrew Poelstra y la idea del artículo llamaron la atención de los desarrolladores de Bitcoin, y en la conferencia de esa semana, se discutió mucho sobre esta combinación de códigos de operación y cómo hacer pequeños cambios en el lenguaje de scripting después de la activación de la raíz podría mejorar la flexibilidad del contrato.

Unas dos semanas después del lanzamiento de CAT and Schnorr Tricks I, Andrew Poelstra publicó un segundo artículo, CAT and Schnorr Tricks II, en el que Andrew Poelstra relata más detalles y sus pensamientos:

En mayo de 2019, el desarrollador de Bitcoin, Jeremy Rubin, propuso el código de operación CHECKOUTPUTSHASHVERIFY de Bitcoin, con el objetivo de implementar un contrato inteligente básico y limitado que evite los riesgos técnicos y sociales de los diseños anteriores de contratos inteligentes. Este Código de Operación fue sustituido posteriormente por SECURETHEBAG y posteriormente por CHECKTEMPLATEVERIFY, que se convirtió oficialmente en la Propuesta de Mejora de Bitcoin BIP 0119 en enero de 2020.

Mientras tanto, Russell O’Connor sugiere agregar CHECKSIGFROMSTACK y OP_CAT Operation Code directamente al Bitcoin para admitir contratos inteligentes que no estén limitados por la propuesta de Rubin. Aunque la propuesta fue recibida con cierta oposición y la discusión finalmente disminuyó, principalmente debido a las ineficiencias de los contratos inteligentes de tipo CAT+CHECKSIG y la impresión negativa a largo plazo de las tenencias completas de contratos inteligentes universales.

Andrew Poelstra también se mostró reacio a apoyar la llamada función BitcoinSmart Contract al principio. Sin embargo, en el otoño de 2019, un intercambio privado con Ethan Heilman lo hizo cambiar de opinión. Ethan Heilman señaló que, a pesar de las preocupaciones, en realidad es posible implementar contratos inteligentes que se consideran dañinos a través de CHECKMULTISIG y que en realidad no son aceptados por las billeteras y los usuarios debido a su falta de reconocimiento y disponibilidad. Para demostrarlo, Ethan Heilman ha desafiado a la gente en las redes sociales a idear contratos inteligentes “oscuros” viables, pero hasta ahora nadie lo ha logrado.

Así que Andrew Poelstra pasó a pensar que el miedo de todo el mundo a los contratos inteligentes podría ser exagerado. El artículo también argumenta que el Contrato Inteligente es inevitable en el desarrollo de Bitcoin, incluso si hay preocupaciones, y alienta la exploración continua de la posibilidad de crear un Contrato Inteligente utilizando el Código de Operación no dedicado OP_CAT.

En 2021

A esto le siguió un artículo de Jeremy Rubin el 6 de julio de 2021, explicando el OP_CAT desde la perspectiva de la seguridad cuántica de Bitcoin. Jeremy Rubin no solo es un desarrollador de Bitcoin, sino también el fundador de Judica, una organización de investigación y desarrollo de Bitcoin centrada en el desarrollo del lenguaje de programación de contratos inteligentes de Bitcoin, Sapio.

En correos electrónicos y publicaciones de blog, Jeremy Rubin analiza cómo verificar cuánticamente Bitcoin con OP_CAT Operation Code y las firmas de Lamport. El autor comienza revisando una publicación de blog anterior sobre cómo registrar valores de 5 bytes utilizando la aritmética del script de Bitcoin y las firmas de Lamport. Aunque este método es genial, tiene sus limitaciones. A Jeremy Rubin se le ocurrió una idea: ¿qué pasaría si pudiéramos firmar mensajes más largos, especialmente si pudiéramos firmar hasta 20 bytes, podríamos firmar un resumen HASH 160 potencialmente seguro para la cuántica?

Jeremy Rubin explora más a fondo las implicaciones de firmar un resumen HASH 160 en el artículo y explica la capacidad de revelar solo la clave privada sin alterar el contenido firmado real, incluso si Quantum Computer descifra ECDSA. Para ello, los autores consultaron al científico de criptografía Madars Virza y recibieron una respuesta afirmativa.

Jeremy Rubin señala que si requerimos que las firmas ECDSA se firmen utilizando un algoritmo de firma de prueba cuántica, podemos tener una prueba cuántica de Bitcoin. El esquema de firma de 5 bytes discutido anteriormente es en realidad una firma Lamport cuántica segura. Desafortunadamente, este método requiere al menos 20 bytes consecutivos.

Por lo tanto, Jeremy Rubin propuso que se necesitaba algún tipo de operación similar a la OP_CAT. El artículo explica que OP_CAT no se puede bifurcar directamente a Segwit v 0 porque modifica la pila. Por lo tanto, para simplificar, el autor muestra cómo usar un nuevo código de operación OP_SUBSTRINGEQUALVERIFY que el código de operación comprueba si alguna parte de una cadena es igual mediante la validación de la semántica.

El 5 de noviembre de 2021, en la Conferencia Bitcoin de Atlanta, Jeremy Rubin y Andrew Poelstra fueron algunos de los ponentes que debatieron la propuesta de volver a habilitar la Operación Código OP_CAT, argumentando que OP_CAT es importante en el contexto de Bitcoin y destacando su potencial, especialmente en términos de seguridad cuántica y de creación de contratos inteligentes complejos. Por ejemplo, en combinación con el código de operación de verificación de firmas de CAT y Schnorr, teóricamente se puede implementar un contrato inteligente no recursivo. Este contrato inteligente es capaz de poner el hash SHA 2 de los datos de la transacción directamente en la pila. Al hacerlo, se pueden imponer restricciones en varias partes de la transacción hasta cierto punto.

La discusión también mencionó que si se reintroduce CAT, puede complicar Bitcoin de alguna manera, al tiempo que introduce nuevas características y posibilidades. Reiniciar el OP_CAT requiere una cuidadosa consideración para evitar problemas que se han producido en el pasado, como explosiones de memoria.

2022

En una discusión en la lista de correo de desarrolladores de Bitcoin del 18 de mayo de 2022 sobre la reintroducción del Código de Operación OP_CAT que se eliminó de Bitcoin en 2010, el desarrollador ZmnSCPxj sugirió que para lograr el inevitable Contrato Inteligente recursivo, OP_CAT tendría que combinarse con el Código de Operación propuesto, como OP_TX, OP_CHECKSIGFROMSTACK (CSFS), etc. Los contratos inteligentes recursivos hacen uso de las reglas de BitcoinConsensus para garantizar que todo el Bitcoin recibido de un contrato solo se pueda gastar en el mismo contrato.

Los contratos inteligentes recursivos se basan en técnicas de introspección de transacciones, es decir, un código de operación puede analizar una parte de la transacción en la que se ejecuta el código de operación. El Código de Operación existente proporciona una introspección limitada. Para crear un contrato inteligente recursivo, debe asegurarse de que la salida anterior y la siguiente sean las mismas. Por lo tanto, la salida anterior, o la siguiente, o ambas, deben construirse dinámicamente a partir de sus elementos constituyentes, por lo que se necesitan estructuras CAT o similares para implementar contratos inteligentes recursivos.

Nadav Ivgi señala que todavía se necesita CAT para resolver el problema del hash al crear contratos inteligentes recursivos, pero esto significa que características como CTV y APO, que se centran en la introspección de salida, también se pueden combinar con CAT para crear contratos inteligentes recursivos. Ivgi argumenta que, cuando se usa junto con la funcionalidad de taproot, validar la salida anterior con la siguiente salida hace que las secuencias de comandos de contratos inteligentes sean más fáciles de escribir y proporciona enlaces a dos ejemplos de contratos inteligentes recursivos.

ZmnSCPxj estuvo de acuerdo con el análisis de Ivgi y reiteró sus preocupaciones sobre los riesgos de habilitar contratos inteligentes recursivos en Bitcoin, aunque también señaló en una publicación de seguimiento que los contratos inteligentes recursivos pueden ser seguros porque en realidad no son Turing Complete. Russell O’Connor cita el artículo de Andrew Poelstra que describe cómo el propio CAT puede combinarse con la funcionalidad existente de Bitcoin lo suficiente como para crear contratos inteligentes no recursivos y, en teoría, si se vuelve a agregar a Bitcoin, también puede ser capaz de crear contratos inteligentes recursivos por sí solo.

En 2023

En enero, Anthony Towns lanzó Bitcoin Inquisition, una réplica de Bitcoin Core diseñada para ejecutarse en el sello predeterminado para probar las bifurcaciones suaves propuestas y otros cambios importantes en el protocolo. A finales de 2023, Bitcoin Inquisition ha apoyado una serie de propuestas y, además, se han presentado a su base de código PR (solicitudes de extracción) diseñadas para OP_CAT, OP_VAULT y limitar las transacciones de 64 bytes, lo que se espera que amplíe aún más las capacidades de este banco de pruebas.

El 23 de agosto de 2023, en la lista de correo de Lightning-Dev, a Thomas Voegtlin se le ocurrió la idea de una prueba de fraude sobre el estado de las copias de seguridad caducadas. Voegtlin señala que es posible utilizar esta prueba de fraude en la cadena si OP_CHECKSIGFROMSTACK (CSFS) y OP_ CAT Código de Operación se agregan al Bitcoin en forma de bifurcación suave. La propuesta provocó mucha discusión, con Peter Todd señalando que el mecanismo básico es genérico y no se limita a LN y puede ser útil en varios protocolos, pero también propuso un mecanismo más simple que no se discutirá aquí.

En octubre, Rusty Russell estaba trabajando en un contrato inteligente de propósito general para el lenguaje de scripting de Bitcoin con cambios mínimos. Al mismo tiempo, y de manera muy importante, Ethan Heilman y Armin Sabouri publicaron conjuntamente un borrador de BIP que proponía la adición de OP_CAT Operation Code, un código de operación para conectar dos elementos en la pila. Las discusiones sobre estos dos temas continuaron en noviembre.

En 2024

Es enero de 2024 y, de hecho, Quantum Cats ha logrado llevar la discusión sobre BIP y el proceso de Bitcoin para OP_CAT al siguiente nivel.

En una interacción con la comunidad, la desarrolladora de Bitcoin Core, Ava Chow, dijo: "No creo que CTV sea un consenso aproximado. Creo que otras propuestas de Smart Contract más generales están más cerca, como txhash o CAT. Sin embargo, no seguí de cerca la discusión. 」

Clasificada por número de confirmaciones, Ava Chow (@achow 101) ocupa actualmente el 5º lugar en el ranking de contribuyentes de código de Bitcoin Core con 1.292 confirmaciones de código y es una de las pocas que tiene derecho a fusionar código de Bitcoin. Como resultado, también es muy influyente en la comunidad de desarrollo.

"No estoy sugiriendo que activemos OP_CAT. Apoyo OP_CAT porque es el Código de Operación el que tiene más probabilidades de llegar a un consenso. Si no conoces OP_CAT, te resumo la situación en esta imagen. Eso dice Eric Wall (@ercwl), co-creador de Taproot Wizard.

Sin embargo, Ava Chow no parece estar absolutamente a favor de la implementación de OP_CAT: "Como ya he dicho, no creo que ninguna propuesta de contrato inteligente se acerque o tenga un consenso aproximado. No creo que debamos intentar activar ninguno de ellos. 」

Diez líneas de código para permitir que Bitcoin implemente un contrato inteligente

Como explica Eric Wall (@ercwl), cocreador de Taproot Wizard, "La gente no se da cuenta, pero OP_CAT es en realidad uno de los componentes básicos de zkrollup en Bitcoin. 」

La reintroducción de OP_CAT proporciona a Bitcoin una poderosa herramienta para respaldar proyectos como BitVM, un concepto recientemente introducido para validar el cálculo arbitrario en Bitcoin que se hará más fácil y eficiente gracias a OP_CAT. El ecosistema Bitcoin permite la creación de contratos inteligentes más versátiles y expresivos.

Lectura relacionada: ¿Qué piensan los desarrolladores veteranos de BitVM para calcular cualquier cosa en Bitcoin?

Con OP_CAT, se pueden implementar los llamados contratos inteligentes, es decir, se establecen condiciones preespecificadas para una salida específica de Bitcoin. Esto no solo abre la puerta a nuevos métodos de escalado, como Ark de Blockstream, sino que también es compatible con muchos otros enfoques innovadores que se basan en contratos inteligentes. Además, significa que Bitcoin no es solo una red de pago, sino también una plataforma informática versátil y escalable.

Si bien el cocreador de Taproot Wizard, Eric Wall, está entusiasmado con el concepto detrás de BitVM, cree que la propuesta podría ser un “callejón sin salida técnico” para Bitcoin debido a sus enormes gastos generales y su largo ciclo de implementación. Le preocupa que BitVM pueda distraer a la comunidad y obstaculizar el desarrollo real. A pesar de ello, la propuesta de BitVM sigue mostrando el espíritu activo de exploración e innovación en el campo de la tecnología Blockchain y Smart Contract.

De hecho, el propio equipo del proyecto Taproot Wizard está trabajando en la implementación de una solución de capa 2 en Bitcoin, y en un espacio anterior, también dijeron que la ronda de financiación completada de USD 7.5 millones se utilizará para estudiar las opciones de escalado de Bitcoin.

Por lo tanto, la bifurcación suave de OP_CAT también será un paso importante para ellos. Eric Wall, que solía ser miembro de la junta directiva de la Fundación StarkNet, tiene un gran interés en construir DeFi además de crear una capa de liquidación sin permisos, por lo que cuando Ethereum comenzó a surgir en 2019, se sintió naturalmente atraído por el espacio de las finanzas descentralizadas en Ethereum.

La exploración de Bitcoin de las finanzas descentralizadas se abandonó casi por completo cuando se hizo evidente en 2019 que Ethereum y otras cadenas de bloques podrían escalar mediante el uso de zk-rollups o pruebas de fraude optimistas. Con la investigación sobre la viabilidad del escalado zk-rollup aplicado a Bitcoin, Wall recurrió a apoyar las finanzas descentralizadas en Ethereum. Pero eventualmente, está tratando de llevar este sistema y estas ventajas tecnológicas a Bitcoin.

Además, en un hilo de discusión sobre OP_CAT en el foro bitcointalk, se le preguntó a Carter Feldman (@cmpeq), fundador del proyecto QED, cómo pretende aprovechar este Código de Operación en los scripts de Bitcoin, y si calcula los bytes promedio de la pila de testigos y las tarifas en las que se puede incurrir.

Carter Feldman dijo que reconoce que esto puede ser un poco caro, pero explica que la prueba de Merkel se utiliza principalmente en su proyecto para construir un script de bloqueo sin confianza o un sistema de clavijas como parte de la capa dos de zk en Bitcoin. Este sistema tiene como objetivo demostrar que se puede retirar una cierta cantidad de Bitcoin a una dirección específica dada la raíz del árbol de retiros (como una entrada pública a una prueba de conocimiento cero).

Para hacer frente al costo, mencionó que este sería el último recurso. Prevé que los usuarios habituales puedan comprar wrapped BTC en la segunda capa haciendo que el vendedor de wrapped BTC bloquee su Token en L2 durante un período de tiempo, durante el cual el comprador debe demostrar que ha pagado al vendedor en Bitcoin L1. Saben que siempre pueden intercambiar Bitcoin sin confianza si así lo desean. Al mismo tiempo, varios grandes proveedores de liquidez se convertirían en entidades que realmente intercambian entre wBTC y BTC y pueden cobrar pequeñas tarifas a los usuarios más pequeños que quieran comprarles wBTC o devolverlo a Bitcoin.

Entonces, en general, la propuesta BIP de OP_CAT puede ayudar a construir contratos inteligentes en Bitcoin con solo 13 líneas de código, pero aún habrá muchas soluciones de discusión y prueba para los detalles específicos de cada proyecto.

La cultura memética genera impulso y hace avanzar la tecnología

El miembro del equipo de TaprootWizards, Rijndael (@rot 13 maxi) recurrió a las redes sociales para compartir las diversas mecánicas complejas que utilizan para crear obras de arte. Para lograr esto, se basan en una variedad de técnicas, incluida la recursividad ordinal, las transacciones prefirmadas, la criptografía simétrica y la administración de carga del lado del cliente. En el proceso de creación del arte, eligieron específicamente utilizar transacciones pre-firmadas para realizar operaciones, mostrando cómo pre-enviar el hash de una transacción utilizando un contrato inteligente como OP_CAT o CTV.

Pero Armin Sabouri comentó sarcásticamente: "El código y el esfuerzo técnico necesarios para crear una colección evolutiva de tokens no fungibles pueden ser 100 veces la cantidad de trabajo necesario para volver a habilitar un código de operación. 」

OP_CAT se considera un código de operación simple y fácil de entender, y se ha argumentado que puede hacer que Bitcoin sea “seguro cuántico” mediante la firma de firmas ECDSA. Esta idea fue apoyada por algunos e inspiró al Mago Taproot a lanzar la campaña de tokens no fungibles Quantum Cats para crear conciencia sobre OP_CAT.

Sin embargo, no es solo OP_CAT que utiliza la cultura memética para generar impulso para el avance tecnológico.

Inspirados por Quantum Cats y su precio de venta de 0,1 BTC, y tal vez en parte insatisfechos con su alto precio de venta, la comunidad OP_CTV también ha lanzado un meme de sándwich llamado #rubinsreubens para promover la tecnología de OP_CTV.

Este meme de sándwich fue originalmente pensado como una respuesta humorística al gato cuántico y sus memes. Sin embargo, en realidad es muy efectivo porque, al igual que CTV, agrega jerarquía y puedes hacer tantas capas en el “sammich” como quieras.

Este meme de sándwich ha atraído la atención de muchas personas. Los memes son divertidos y se pueden usar para mostrar apoyo a algo, pero también es importante comprender el significado detrás de ellos. El propósito de la #rubinsreubens es mejorar la comprensión de las propuestas de OP_ctv, LNHANCE y Soft Fork para el nuevo Código de Operación de BTC y la habilitación de Contratos Inteligentes.

Posibles causas de los fallos de OP_CAT

Volviendo a OP_CAT, la gente puede oponerse a la introducción de características como OP_CAT por varias razones. En primer lugar, agregar nuevos códigos de operación o características como OP_CAT podría aumentar la complejidad de Bitcoin, haciéndolo más difícil de entender y seguro de usar, lo que aumenta el riesgo. En segundo lugar, no se deben pasar por alto los problemas de seguridad al introducir nuevas funciones, y las características que no se han probado completamente pueden albergar vulnerabilidades que comprometen la seguridad general de Bitcoin. Además, si la actualización de la bifurcación suave no es adoptada por todos los nodos, puede hacer que la red se divida, haciendo que coexistan diferentes versiones de la red Bitcoin, lo que hace que llegar a un consenso sea más complicado.

Las nuevas características pueden plantear problemas de compatibilidad, especialmente si no son compatibles con los nodos más antiguos, lo que podría excluir algunos nodos de la red, lo que afectaría negativamente al ecosistema de Bitcoin. Especialmente para aquellos usuarios que no se han actualizado, es posible que no puedan seguir participando en la red. Además, algunos pueden ver la introducción de nuevas características como una decisión apresurada sin priorizar abordar problemas urgentes en el protocolo central de Bitcoin. Los cambios apresurados pueden introducir riesgos e inestabilidad innecesarios.

Además de las consideraciones de seguridad y riesgo, las dos principales razones por las que OP_CAT fracasarán son: el miedo a los contratos inteligentes en la comunidad de Bitcoin y la falta de “legitimidad” en los contratos inteligentes de Bitcoin.

Miedo a los contratos inteligentes

El miedo a BitcoinSmart Contract puede ser otro obstáculo importante para lograr OP_CAT. Como componente central de la tecnología Blockchain, los contratos inteligentes juegan un papel vital en muchos proyectos de Blockchain, especialmente en plataformas como Ethereum.

Sin embargo, en la comunidad de Bitcoin, la aceptación de los contratos inteligentes es relativamente baja, en parte debido a las preocupaciones sobre los riesgos y desafíos que pueden plantear los contratos inteligentes. Los contratos inteligentes pueden afectar a los valores fundamentales de Bitcoin, como el peer-to-peer, la descentralización y la seguridad. La comunidad de Bitcoin se toma muy en serio el mantenimiento de estos valores fundamentales, y es probable que se oponga a cualquier cambio que se considere que amenaza estos valores.

Una de las principales preocupaciones de los contratos inteligentes es que pueden aumentar la complejidad y los riesgos de seguridad en toda la red. Los contratos inteligentes a menudo involucran lógica y código complejos, y cualquier pequeño error o vulnerabilidad puede conducir a graves problemas de seguridad e incluso a una pérdida masiva de fondos, como ha sucedido en algunos proyectos de Blockchain en el pasado. Además, la introducción de contratos inteligentes puede hacer que todo el sistema sea más difícil de entender y auditar, lo que aumenta la probabilidad de errores.

Además, la comunidad Bitcoin siempre ha puesto gran énfasis en mantener la estabilidad y seguridad de la red. La filosofía de diseño de Bitcoin se inclina hacia la simplicidad y el conservadurismo, priorizando la seguridad y la descentralización de la red. Como resultado, cualquier cambio significativo que pueda suponer una amenaza para la estabilidad cibernética está sujeto a un intenso escrutinio y a un amplio debate. La introducción de OP_CAT y los contratos inteligentes, si bien puede aportar nuevas características y posibilidades a Bitcoin, también puede verse como contraria a la visión y filosofía de diseño originales de Bitcoin.

¿Satoshi Nakamoto estaba “equivocado”?

La restauración de OP_CAT Operation Code ha provocado un profundo debate en la comunidad, en parte porque toca un tema delicado: ¿Significa esto que Satoshi Nakamoto está equivocado?

Como fundador de Bitcoin, las decisiones y el diseño original de Satoshi Nakamoto son considerados como biblia por muchos, y su visión original se considera una guía central para el desarrollo de Bitcoin. Por lo tanto, cualquier tipo de impugnación o modificación de la decisión de Satoshi Nakamoto puede considerarse una falta de respeto a su legado o una desviación de los principios fundamentales de Bitcoin. Después de todo, en la industria de Blockchain, la legitimidad siempre ha sido un tema inevitable.

Por lo tanto, la propuesta de restaurar el OP_CAT también toca una cuestión más amplia: ¿debe Bitcoin ser una entidad estática o debe adaptarse al entorno tecnológico cambiante y a las necesidades de los usuarios?

Sin embargo, el campo técnico siempre está progresando y cambiando, y Bitcoin, como innovación tecnológica, no puede deshacerse por completo de esta ley, y aparentemente el equipo de Taproot Wizard que apoya la restauración de OP_CAT así lo cree. Después de todo, diseñaron deliberadamente el BitcoinBlock más grande de la historia, justo por debajo del límite de 4 MB de Bitcoin, para lanzar Non-fungible Token Taproot Wizards.

Udi Wertheimer, fundador de Taproot Wizard, dijo que entiende que muchas personas creen que Bitcoin no debería cambiar. Cree que los cambios en Bitcoin deben ser lentos, cautelosos y deliberados. Argumenta que Bitcoin es demasiado joven para solidificarse por completo, señalando que el proceso de gobernanza está roto de alguna manera. Aunque la comunidad técnica generalmente está de acuerdo en que habrá más actualizaciones de Bitcoin, es realmente difícil determinar exactamente cuáles serán las actualizaciones. Aún así, Wertheimer enfatizó que el cambio es necesario porque el Bitcoin actual aún no puede servir a miles de millones de personas.

Por supuesto, estos cambios también conllevan riesgos y desafíos, como problemas de seguridad, riesgos de fragmentación de la red, problemas de compatibilidad, etc., que deben considerarse y abordarse cuidadosamente.

Como era de esperar, en el futuro, para garantizar que las mejoras propuestas sean seguras y efectivas, la implementación de OP_CAT en un entorno de red de prueba es un paso crítico que permite a los desarrolladores identificar y resolver problemas sin afectar a la red principal.

Al mismo tiempo, para realizar realmente el “reinicio” de OP_CAT, todo el proceso durará mucho tiempo, incluso años, porque implica muchas consideraciones y equilibrios, incluidos los detalles técnicos, el consenso de la comunidad y las consideraciones para la seguridad y estabilidad de la red Bitcoin y, lo que es más importante, un amplio apoyo y reconocimiento de la comunidad.