Introducción

Es posible que haya oído hablar de volver a habilitar OP_CAT como una posible actualización para el lenguaje de secuencias de comandos de bitcoin. Dependiendo de dónde obtenga sus noticias, OP_CAT ha sido llamado "solo 10 líneas de código", "la mejor manera de permitir la experimentación con convenios", "demasiado poderoso", "peligroso y que conduce a la centralización de los mineros" o "garantizado para conducir a un soft fork polémico”. Voy a argumentar que todas estas perspectivas están equivocadas. OP_CAT es muy útil, puede usarse como un pacto y no (por sí solo) es el mejor próximo paso para bitcoin. Nada más y nada menos.

Para justificarlo, voy a explorar varios temas (aparentemente inconexos), algunos de los cuales eran nuevos para mí hace unos meses. Voy a intentar organizar esto de manera que proporcione los antecedentes necesarios en un solo lugar.

Cómo y qué hace OP_CAT

Introspección con CAT

Abordemos la pregunta candente que muchos tienen cuando se exponen por primera vez a OP_CAT. ¿Cómo pueden unas pocas líneas de código que combinan dos elementos de la pila en uno (A B CAT -> AB) permitir algo interesante? Andrew Poelstra lo ha explicado elocuentemente en entrevistas recientes, y yo publiqué una explicación breve y tonta:

Bitcoin es un poco raro, por lo que también puede dividir cosas. Entonces SHA256 nos permite deshacer hashes. Luego, debido a que la criptografía es solo matemática y sabemos cómo trabajar, CAT nos permite extraer un hash de una verificación de firma. Y como resultado podemos inspeccionar cualquier cosa codificada dentro de una firma...

— Rearden 🍯🦡 🦢 | abrazar tenedores (@reardencode) 17 de mayo de 2024

Debido a que el script bitcoin es estrictamente un lenguaje de verificación, cada código de operación se puede usar hacia adelante o hacia atrás. A un script se le puede dar un hash y requerir una imagen previa, o se le puede dar una imagen previa y requerir un hash usando OP_SHA256. Esta idea nos brinda las dos primeras partes de cómo funcionan los convenios OP_CAT.

Si un script de bitcoin pudiera obtener acceso a un hash de la transacción que está verificando, podría requerir que la pila de gastos proporcione la preimagen del hash, la divida de la forma que requiera el script y luego valide cualquier parte particular de esa preimagen. Esto es exactamente lo que es un pacto: validar una parte de la transacción gastando algo de bitcoin.

Eso es genial, pero bitcoin no tiene un código de operación como OP_TXHASH para darle al script acceso al hash de la transacción. Aquí, aprovechamos la ecuación de verificación de firma BIP340 Schnorr para exigir que el usuario proporcione el hash. Si el usuario proporciona un valor que será un hash de transacción válido si el script concatena el byte 0x00 al final del mismo, ese valor también será parte de una firma BIP340 válida (con otros parámetros fijos) si el script concatena el byte 0x01.

La combinación de estas técnicas permite a OP_CAT verificar cualquier parte de su transacción de gasto que pueda firmarse, e incluso revisar sus transacciones principales de algunas maneras limitadas. Con un poco de programación cuidadosa, se pueden crear Purrfect Vaults, CatVM y más.

Otros usos del CAT

Pero no deberíamos hacerlo. Construir estas cosas con OP_CAT resulta en abominaciones difíciles de mantener. En su lugar, deberíamos usar OP_CAT para lo que sirve, y hay mucho de eso: habilita el equivalente de OP_CHECKSEPARATESIG, verifica pruebas de inclusión de Merkle, combina datos para verificación de firmas con OP_CHECKSIGFROMSTACK y más.

Problemas con TAO

Ahora que sabemos qué hace CAT, ¿cuál es el problema? ¿Por qué la gente (incluido yo mismo) ha dicho que es una bestia peligrosa? Utilizando la técnica de introspección descrita anteriormente, CAT permite dos construcciones específicas: depósitos en garantía de Hashrate y (supuestamente) creadores de mercado automatizados (AMM). Hasta hace poco, ambos se consideraban riesgos importantes al llevar la centralización de MEV a bitcoin.

Centralización MEV, MEVil y Miner

El término MEV (valor extraíble minero) es un poco confuso. En la interpretación más sencilla, incluiría tarifas de transacción, que por supuesto queremos que se paguen a los mineros para ayudar a garantizar la seguridad de bitcoin en el futuro. MEV se utiliza generalmente para referirse al valor adicional que los mineros pueden extraer de sus bloques más allá de las tarifas visibles en la red pública de retransmisión. Esto podría venir en forma de pagos fuera de banda, mineros participando en contratos y reordenando transacciones de maneras que los favorezcan, o incluso robo directo de bienes y servicios por parte de mineros que extraen bloques que reorganizan y gastan dos veces un pago confirmado a un comerciante. Todas estas formas de MEV pueden considerarse generalmente malas para los participantes de la red, ya que los mineros utilizan su posición en la red para su propio beneficio a expensas de otros participantes de la red. Sin embargo, MEV por sí solo no presenta un problema sistémico al impulsar la centralización minera, solo un problema local para los participantes específicamente afectados.

MEVil es un término que a veces se usa para MEV que impulsa la centralización minera; prefiero el término centralizar MEV y lo usaré en el futuro. Son necesarias varias cosas para convertir MEV en MEV centralizado:

  1. Debe ser lo suficientemente difícil de extraer como para que un creador de plantillas de bloques de código abierto no pueda extraerlo razonablemente.

  2. El valor total extraíble debe crecer con la tasa de hash de bitcoin de un minero

  3. El valor extraíble debe justificar el coste de extracción.

Si se cumplen todos estos requisitos, sólo un minero suficientemente grande tendrá el incentivo para comenzar a extraer el MEV. Una vez que lo hagan, podrán superar el crecimiento de sus pares más pequeños gracias a los ingresos adicionales extraídos. Cuanto más costosa es extraer el MEV (hasta el punto en que no vale la pena para ningún minero), peor es la presión centralizadora que crea.

Entonces, evitar centralizar MEV es (en cierto sentido) simple: garantizar que cualquier oportunidad para MEV que exista en bitcoin sea tan fácil de extraer que todos lo hagan o que cueste más extraerlo de lo que vale (ya sea porque son muy pequeños o porque son muy costosos).

Para obtener más información, consulte la publicación reciente de @TheBlueMatt.

Hashrate Escrows (de soltera Drivechains)

Hace muchos años (antes de Lightning Network o ideas como Ark, Timeout Trees, roll-ups, BitVM o CatVM) las cadenas laterales se consideraban la solución de escalamiento definitiva para bitcoin. La idea era conceptualmente simple: los bloques de bitcoin deben tener un tamaño limitado por todas las razones habituales de descentralización, pero podemos adjuntar cadenas laterales a bitcoin y éstas pueden tener bloques más rápidos, bloques más grandes, más computación o lo que sea. Sin embargo, en la práctica, implementar cadenas laterales no fue tan fácil. La liquidación final de Bitcoin está fundamentalmente ligada a la prueba de trabajo, un costo infalsificable para reordenar las transacciones, ¿cómo hereda eso una cadena lateral? Además, ¿cómo se pueden transferir bitcoins hacia y desde la cadena lateral? La propuesta más conocida para responder a estas dos preguntas se llama Drivechains (BIP 300 y 301). No los aburriré con los detalles de Drivechains, pero basta decir que solo hay dos resultados de estos sistemas de cadenas laterales: o están relativamente sin uso (y por lo tanto inútiles) o se usan ampliamente y se convierten en un tamaño de bloque de facto. aumento para bitcoin. Un aumento de facto en el tamaño del bloque de este tipo es una forma de centralizar MEV donde solo los mineros más grandes podrán participar de manera rentable en las oportunidades de ingresos adicionales que ofrecen los bloques de cadena lateral potencialmente grandes y complejos.

Los depósitos en garantía de Hashrate, que se pueden crear con OP_CAT, son una pequeña parte de las propuestas de Drivechains. Este es un sistema para restringir los retiros de las cadenas laterales mediante el uso de un contador cuyo valor solo puede ser cambiado por los mineros, comienza en un valor alto y debe llegar a cero antes de que se pueda procesar un retiro de la cadena lateral. Se afirma que se trata de una transferencia "sin confianza" desde una cadena lateral, pero en realidad crea una federación de mineros con control de todos los bitcoins contenidos en las cadenas laterales.

Desde el desarrollo de las propuestas de Drivechains, se ha vuelto común (para nuestro perjuicio) referirse a cualquier propuesta que pueda usarse para crear un retiro basado en un contador controlado por mineros como "Drivechains". Esperemos que en este punto quede claro por qué esta taquigrafía inapropiada no es útil: las cadenas de transmisión no tienen valor o son peligrosas, pero los depósitos en garantía de hashrate son simplemente una forma de transferir el control del resultado de alguna transacción a la federación implícita de mineros.

Tokens y AMM

Fichas

Por razones que nunca me quedarán del todo claras, a los humanos les encantan las fichas buenas (o las fichas malas o, en realidad, simplemente las fichas). Casi desde el comienzo de Bitcoin se ha hablado de cómo integrar otros tokens en el protocolo, desde Colored Coins y Counterparty, hasta los más recientes Taproot Assets y Runes. Todos estos protocolos tienen una cosa en común: requieren un índice externo de transacciones de bitcoin que tenga conocimiento de datos externos o procese datos de la secuencia de transacciones de bitcoin para determinar las transformaciones de los tokens dentro del protocolo. El punto más destacado de este artículo es que los scripts de bloqueo de bitcoin desconocen por completo la existencia de los tokens, e incluso los nodos de bitcoin que validan las transacciones desconocen los tokens (es decir, incluso si un script de bloqueo de bitcoin tuviera acceso completo al conjunto completo de UTXO de bitcoin). , no pudo descubrir el estado de ninguno de estos tokens).

Creadores de mercado automatizados (AMM)

En otros sistemas blockchain, es común que los contratos conocidos como AMM se utilicen para (por ejemplo) fijar la relación entre dos tokens mediante la compra y venta a un precio fijo. Las reglas que se pueden codificar en una AMM están fuera del alcance de este artículo. Baste decir que las AMM crean enormes oportunidades para MEV y, debido a las relaciones de intercambio privado necesarias para maximizar los rendimientos de ese MEV, también centralizan MEV. Esto se ha utilizado a menudo como argumento en contra de la creación de scripts bitcoin más expresivos; realmente queremos evitar exponer la red bitcoin a los caprichos de centralizar MEV. Sin embargo, como he descrito anteriormente, simplemente no existe una forma práctica para que los scripts de bitcoin, sin importar cuán expresivos sean, evalúen el estado de cualquier token que no sea bitcoin. Los scripts de Bitcoin no pueden localizar un sat raro. No pueden encontrar un equilibrio de runas. No pueden identificar un activo Taproot.

Sin acceso a ninguna información sobre la disposición de activos que no son bitcoins, todo el concepto de un AMM basado en scripts de bitcoin deja de tener sentido. Las ubicaciones de los tokens pueden ser certificadas mediante una firma de un Oracle, pero las certificaciones de Oracle no constituyen un AMM. Se pueden utilizar para facilitar operaciones manuales específicas, pero no como un sistema automatizado duradero. Además, un sistema basado en Oracle podría construirse hoy sin cambios en Bitcoin.

Conclusión

Como puedes ver, CAT no es una bestia tan espantosa. En realidad no es una gran bestia. No tiene capacidad infinita ni poderes mágicos. Es sólo un pequeño código de operación que puede resultar muy útil. Lo único que probablemente queramos evitar es activar OP_CAT sin otra forma de realizar la introspección de transacciones, como OP_TXHASH, OP_TX o ambos. Incluso habilitarlo con LNHANCE es una mejora solo con respecto a OP_CAT porque reduce el tamaño y la complejidad de los scripts necesarios para lograr muchos protocolos de introspección OP_CAT.

Creo que en este punto, el "CAT introduce todo infinito" se ha reducido a ~nada.

Introduce una introspección útil de una manera de mierda que nadie debería usar. Para ayudar a que la gente no lo use, debemos habilitar CAT junto con TXHASH o similar. https://t.co/nvnxYn66Um https://t.co/1Ag5TwjuUw

— Rearden 🍯🦡 🦢 | abrazar tenedores (@reardencode) 17 de mayo de 2024

Esta es una publicación invitada de Brandon Black. 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 y Infinite Nothing apareció por primera vez en Crypto Breaking News.