Los "Pactos" de Bitcoin son mecanismos que establecen condiciones para futuras transacciones de Bitcoin. El artículo describe los conceptos básicos, escenarios de aplicación y métodos de implementación técnica de cláusulas restrictivas, y analiza los principios de diseño detrás de ellos. Se presentan propuestas técnicas como OP_CAT, OP_CTV y APO, y cómo mejoran la programabilidad y las funciones de contratos inteligentes de Bitcoin. Al mismo tiempo, el artículo también aborda la aplicación de cláusulas restrictivas en la red Bitcoin, como el control de congestión, bóvedas, canales de estado, etc., y analiza las ideas de diseño para implementar cláusulas restrictivas y posibles disputas comunitarias.

Coescrito por Jeffrey HuyHarper Li

Ha habido una reciente ola de discusión en la comunidad de Bitcoin sobre la reactivación de opcodes como OP_CAT, y Taproot Wizard ha atraído mucha atención al lanzar NFT de Quantum Cats, afirmando haber obtenido asignado BIP-420. Los defensores afirman que habilitar OP_CAT realizará "pactos", y así traerá contratos inteligentes o programabilidad a Bitcoin.

Si notas la palabra "pactos" y haces un poco de búsqueda, verás que este es otro gran agujero de conejo. Los desarrolladores han estado hablando durante años sobre tecnologías que implementan pactos, como OP_CTV, APO, OP_VAULT y más, además de OP_CAT.

Más precisamente, los scripts actuales de Bitcoin también tienen algunos tipos de pactos, como los bloqueos temporales basados en opcodes, que se implementan mediante la introspección del campo nLock o nSequence de una transacción para limitar la cantidad de tiempo antes de que la transacción pueda ser gastada, pero siguen estando limitados solo a restricciones de tiempo.

Entonces, ¿qué son exactamente los "convenios" de Bitcoin? ¿Por qué ha atraído tanta atención y discusión de los desarrolladores durante años? ¿Qué programabilidad de Bitcoin se puede lograr? ¿Cuáles son los principios de diseño detrás de ello? Este artículo intenta proporcionar una visión general y discusión.

¿Qué son los “Convenios”?

El pacto es un mecanismo que puede establecer condiciones en futuras transacciones de Bitcoin.

De hecho, los scripts actuales de Bitcoin contienen restricciones, como tener que ingresar una firma legítima, enviar scripts compatibles al gastar. Siempre que el usuario pueda desbloquearlo, puede gastar ese UTXO donde desee.

El Pacto es imponer más restricciones además de esta limitación sobre cómo desbloquear, como limitar el gasto de UTXO después de que se gasta, lo que logra un efecto similar al de la asignación, u otras condiciones de entrada introducidas en una transacción, etc.

Entonces, ¿por qué los desarrolladores e investigadores diseñan estas comprobaciones de restricción? Esto se debe a que los convenios no son solo restricciones por nada, sino más bien para establecer las reglas para la ejecución del comercio. De esta manera, el usuario solo puede ejecutar transacciones de acuerdo con las reglas preestablecidas, completando así el proceso comercial previsto.

Por lo tanto, de manera contraintuitiva, esto trae más escenarios de aplicación.

Escenarios de Aplicación

Garantizando sanciones de participación

Uno de los ejemplos más intuitivos de un convenio es la transacción de reducción de Babilonia en el proceso de participación en Bitcoin.

El proceso de participación en Bitcoin de Babilonia implica que los usuarios envíen su BTC a un script especial en la cadena principal con dos condiciones de gasto:

• Final feliz: después de cierto tiempo, el usuario puede desbloquear con su propia firma, lo que significa que el proceso de desbloqueo está completo.
• Mal final: Si el usuario sufre un ataque de doble gasto en la cadena PoS, el usuario puede desbloquear los activos con su propia firma a través de EOTS (firmas extraíbles de un solo uso), y una parte de los activos puede ser forzada a ser enviada a la dirección de quemado (slash) por un actor ejecutor en la red.

Fuente: Bitcoin Staking: Desbloqueando 21M Bitcoins para Asegurar la Economía de Prueba de Participación

Tenga en cuenta la palabra “forzada”, lo que significa que incluso si se puede desbloquear el UTXO, el activo no se puede enviar a ningún otro lugar, solo se puede quemar. Esto asegura que un usuario malintencionado no pueda transferir el activo de vuelta a él mismo con su propia firma conocida.

Esta característica, después de implementar convenios como OP_CTV, puede ser implementada agregando opcodes al “mal final” del script de staking.

Antes de que se habilite OP_CTV, Babilonia necesitará una solución alternativa para emular el efecto de hacer cumplir los convenios al hacer que el usuario + el comité trabajen juntos.

Control de congestión/Escalabilidad

En general, la congestión ocurre cuando la comisión es alta en Bitcoin con un número relativamente grande de transacciones acumuladas en la piscina de transacciones esperando ser empaquetadas, por lo que si un usuario quiere confirmar una transacción rápidamente, necesita aumentar la comisión.

En ese momento, si un usuario tiene que enviar múltiples transacciones a múltiples direcciones, tendrá que aumentar sus tarifas y incurrir en costos más altos. En consecuencia, esto elevará aún más la tarifa de transacción de toda la red.

Si hay un convenio, entonces hay una solución: una sola transacción comprometida con múltiples salidas. Este compromiso puede convencer a todos los destinatarios de que la transacción final tendrá lugar y todos pueden esperar hasta que la tarifa sea baja antes de enviar la transacción específica.

Como se muestra a continuación, cuando la demanda de espacio de bloque es alta, se vuelve muy caro realizar transacciones. Al utilizar OP_CHECKTEMPLATEVERIFY, un procesador de pagos de alto volumen puede agregar todos sus pagos en una sola transacción O(1) para su confirmación. Luego, después de un período de tiempo, cuando la demanda de espacio de bloque disminuye, los pagos pueden expandirse fuera de ese UTXO

Fuente: https://utxos.org/uses/scaling/

Este escenario es uno de los casos de uso más típicos presentados por esta restricción OP_CTV. Se pueden encontrar muchos más casos de uso en https://utxos.org/uses.Además del control de congestión mencionado anteriormente, la página enumera Apuestas Soft Fork, opciones descentralizadas, cadenas de unidades, canales de lotes, canales no interactivos, piscinas mineras sin coordinación ni confianza, bóvedas, límites de contratos con tiempo bloqueado seguro (HTLCS) y más.

Bóvedas

Las bóvedas son uno de los casos de uso de las aplicaciones de Bitcoin más ampliamente discutidos, especialmente en el ámbito de los convenios. Debido a que las operaciones diarias involucran inevitablemente el equilibrio entre la necesidad de mantener seguros los fondos y la necesidad de usarlos, a uno le gustaría tener una bóveda que pueda mantener seguros los fondos, o incluso restringir su uso cuando la cuenta es hackeada (por ejemplo, comprometiendo la clave privada).

Basado en las técnicas utilizadas para implementar cláusulas de restricción, este tipo de bóveda custodia puede construirse relativamente fácilmente.

Tomemos el esquema de diseño de OP_VAULT como ejemplo: al gastar fondos en la bóveda, primero se debe enviar una transacción a la cadena. Esta transacción indica la intención de gastar la bóveda, que es un "desencadenante", y se establecen condiciones en ella:

• Si todo está bien, entonces la segunda transacción finalmente retirará los fondos. Después de esperar N bloques, los fondos se pueden gastar en cualquier lugar.
• Si resulta que la transacción fue robada (o coaccionada en un "ataque de activación"), los activos pueden ser enviados inmediatamente a otra dirección segura (más segura para el usuario) inmediatamente antes de que la transacción de retiro sea enviada después de N bloques.

Proceso de OP_VAULT ，fuente：BIP-345

Tenga en cuenta que también es posible construir una bóveda sin convenios, y una forma posible de hacerlo es usar una clave privada para preparar una firma para un gasto posterior y luego destruir esta clave privada. Sin embargo, todavía existen más limitaciones, como la necesidad de asegurarse de que la clave privada haya sido destruida (similar al proceso de configuración confiable en pruebas de conocimiento cero) y la falta de flexibilidad para determinar la cantidad y la tarifa por adelantado (debido a la pre-firma).

Bóvedas precalculadas y OP_VAULT, fuente: BIP-345

Canales de estado más robustos y flexibles

Generalmente se puede asumir que los canales de estado, incluida la Lightning Network, tienen casi la misma seguridad que la cadena principal (en términos de asegurar que los nodos puedan observar el estado más reciente y puedan publicar correctamente el estado más reciente en la cadena). Sin embargo, con los convenios, se puede diseñar algunos nuevos estados de canal de manera más sólida o flexible sobre la Lightning Network. Algunos de los más conocidos incluyen Eltoo, Ark.

Eltoo (también conocido como LN-Symmetry) es un ejemplo típico. Tomando el acrónimo de “L2”, esta tecnología propone una capa de ejecución para la Red Lightning que permite que cualquier estado posterior del canal reemplace el estado anterior sin un mecanismo de penalización, evitando así la necesidad de que los nodos de la Red Lightning guarden múltiples estados anteriores para evitar que sus adversarios cometan actos maliciosos. Para lograr el efecto anterior, Eltoo propone la firma SIGHASH_NOINPUT, APO (BIP-118).

Ark tiene como objetivo reducir la dificultad de la liquidez entrante y la gestión de canales de la red lightning. Es un protocolo en forma de joinpool, donde varios usuarios pueden aceptar a un proveedor de servicios como contraparte por un cierto período de tiempo, y negociar vUTXOs (UTXOs virtuales) fuera de la cadena, pero comparten un UTXO en la cadena para reducir costos. Similar a las bóvedas, Ark se puede implementar en la red Bitcoin actual; sin embargo, con la introducción de covenants, Ark puede reducir la cantidad de interacción requerida basada en plantillas de transacciones, lo que permite una salida unilateral más confiable.

Visión general de los Pactos

Como se puede ver en las aplicaciones anteriores, los convenios son más como un efecto que una tecnología específica, y como tal, hay muchas formas técnicas de implementarlos. Se pueden categorizar como:

• Tipo: genérico, restrictivo
• Implementación: basada en códigos de operación, basada en firmas
• Recursividad: recursivo, no recursivo

Aquí recursivo significa: hay algunas implementaciones de convenios que también pueden limitar la salida de la próxima transacción al limitar la salida de esta transacción, lo que significa que cada transacción en la cadena de transacciones está restringida por la anterior.

Algunos de los diseños de convenios populares incluyen:

Diseños de Pactos

Como se puede ver en la introducción anterior, los scripts actuales de Bitcoin principalmente restringen las condiciones para desbloquear y no restringen cómo se puede gastar ese UTXO. Para implementar pactos, necesitamos pensar de manera opuesta: ¿por qué los scripts actuales de Bitcoin no pueden implementar pactos?

La razón principal es que los scripts actuales de Bitcoin no pueden leer la transacción en sí misma, lo que significa la introspección de la transacción.

Si pudiéramos implementar la introspección, inspeccionando cualquier cosa en la transacción (incluida la salida), entonces podríamos implementar convenios.

Entonces el diseño de los convenios también se centra en cómo implementar la introspección.

Basado en códigos de operación vs Basado en firmas

La idea más simple y rudimentaria es agregar uno o más opcodes (un opcode + múltiples parámetros, o múltiples opcodes con diferentes funciones) y leer el contenido de la transacción directamente. Esto también se conoce como la idea basada en opcodes.

Otra forma de pensar es que en lugar de leer y verificar el contenido de la transacción directamente en el script, se puede utilizar el hash del contenido de la transacción, lo que significa que si este hash ha sido firmado, entonces al transformar opcodes como OP_CHECKSIG en el script para verificar esta firma, es posible implementar indirectamente la introspección de la transacción y los convenios. Esta idea se basa en el enfoque de diseño de la firma. Incluye principalmente APO y OP_CSFS.

APO

SIGHASH_ANYPREVOUT (APO) es una propuesta para un hash de firma. La forma más sencilla de firmar es comprometerse tanto con las entradas como con las salidas de una transacción, pero hay una forma más flexible para que Bitcoin se comprometa selectivamente a las entradas o salidas de una transacción, conocida como SIGHASH.

El rango actual de SIGHASH y sus combinaciones de firmas para las entradas y salidas de transacciones (fuente: Mastering Bitcoin, 2nd)

Como se muestra arriba, además de TODO, que se aplica a todos los datos, NINGUNO está firmado de tal manera que se aplica solo a todas las entradas y no a las salidas, y ÚNICO se basa en esto al aplicarlo solo a las salidas con el mismo número de índice de entrada. Además, SIGHASH se puede combinar, con el modificador CUALQUIERAPUEDEPAGAR superpuesto, para aplicarse solo a una entrada.

El SIGHASH de APO, por otro lado, solo firma la salida, no la entrada. Esto significa que una transacción firmada con APO puede adjuntarse más tarde a cualquier UTXO que cumpla con las condiciones.

Esta flexibilidad es la razón detrás de la implementación de convenios de APO:

• Se pueden crear una o más transacciones con antelación
• La información de estas transacciones se utiliza para construir una clave pública de la que solo se puede derivar/comprobar la firma de gasto
• para que cualquier activo enviado a esta dirección de clave pública solo pueda gastarse a través de transacciones pre-creadas.

Vale la pena señalar que debido a que esta clave pública no tiene una clave privada correspondiente, se garantiza que estos activos solo se pueden gastar a través de transacciones pre-creadas. Luego, podemos implementar un convenio especificando a dónde van los activos en estas transacciones pre-creadas.

Esto se puede entender mejor comparándolo con los contratos inteligentes de Ethereum: lo que podemos lograr con los contratos inteligentes es que solo podemos retirar dinero de una dirección contratada si se cumplen ciertas condiciones, en lugar de gastarlo arbitrariamente con una firma EOA. Desde este punto de vista, Bitcoin puede lograr este efecto a través de mejoras en el mecanismo de firma.

El problema con el proceso anterior, sin embargo, es que hay un dev@lists.linuxfoundation.org/msg08075.html">dependencia circular en el cálculo, ya que se necesita conocer la entrada para pre-firmar y crear la transacción.

La importancia de las implementaciones de APO y SIGHASH_NOINPUT de este método de firma es que resuelve este problema de dependencia circular al solo necesitar conocer (especificar) la salida completa de la transacción en el momento del cálculo.

OP_CTV

OP_CHECKTEMPLATEVERIFY (CTV), o BIP-119, utiliza una mejora de Opcode. Toma el hash de compromiso como argumento y requiere que cualquier transacción que ejecute un opcode contenga un conjunto de salidas que coincidan con ese compromiso. Con CTV, permitiría a los usuarios de Bitcoin limitar cómo usan Bitcoin.

Originalmente introducido como OP_CHECKOUTPUTSHASHVERIFY (COSHV) y con un enfoque inicial en la capacidad de crear transacciones de control de congestión, las críticas a la propuesta también se han centrado en el hecho de que no es lo suficientemente genérica y es demasiado específica para el caso de uso del control de congestión.

En el caso de uso del control de congestión mencionado anteriormente, Alice, el remitente, podría crear 10 salidas y hashear esas 10 salidas, y usar el resumen resultante para crear un script de tapleaf que contenga COSHV. Alice también podría usar las claves públicas de los participantes para formar una clave interna de Taproot que les permitiría colaborar en el gasto del dinero sin revelar la ruta del script de Taproot.

Alice luego le da a cada destinatario una copia de los 10 resultados para que cada uno de ellos pueda verificar la transacción de configuración de Alice. Cuando quieran gastar el pago más tarde, cualquiera de ellos puede crear una transacción con los resultados comprometidos.

A lo largo del proceso, mientras Alice crea y envía la transacción de configuración, Alice puede enviar estas 10 copias de las salidas a través de métodos de comunicación asincrónica existentes, como correo electrónico o unidades en la nube. Esto significa que los destinatarios no necesitan estar en línea o interactuar entre sí.

Fuente: https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-transaction-output-commitments

Similar a los APOs, las direcciones pueden construirse en función de las condiciones de gasto, y se pueden hacer "bloqueos" de diferentes maneras, incluidas claves adicionales, bloqueos temporales relativos o fijos, y otras lógicas para combinarlos.

Origen: https://twitter.com/OwenKemeys/status/1741575353716326835

Basado en esto, CTV propone verificar si la transacción gastada después del hash coincide con la definida, lo que significa que los datos de la transacción se utilizan como clave para desbloquear el “lock”.

Podemos extender el ejemplo anterior de 10 receptores, donde un receptor puede hacer que su clave de dirección sea una TX firmada pero no transmitida que envíe al siguiente lote de receptores, y así sucesivamente, formando una estructura de árbol como se muestra en la figura a continuación. Alice puede construir un cambio en los saldos de cuenta que involucre a múltiples usuarios en la cadena usando solo 1 UTXO de espacio de bloque.

Fuente:https://twitter.com/OwenKemeys/status/1741575353716326835

¿Y si una de las hojas es un canal de rayos, o almacenamiento en frío, o algún otro camino de pago? Entonces el árbol se expandirá de un árbol de pagos multi-capa unidimensional a un árbol de pagos multi-dimensional multi-capa, y los escenarios que se pueden soportar serán más ricos y flexibles.

Fuente: https://twitter.com/OwenKemeys/status/1744181234417140076

Desde su propuesta, CTV ha pasado por un cambio de nombre de COSHV en 2019, siendo asignado BIP-119 en 2020, y la aparición de Sapio, el lenguaje de programación utilizado para crear el contrato que respalda CTV, y ha recibido mucha discusión comunitaria, actualizaciones y debate sobre sus opciones de activación en 2022 y 2023, y sigue siendo una de las propuestas de actualización de soft fork más discutidas en la comunidad.

OP_CAT

OP_CAT, como se describe en el párrafo de apertura, también es una propuesta de actualización que actualmente está recibiendo mucha atención e implementa una función que concatena dos elementos o dos conjuntos de datos de la pila. Aunque parece sencillo, OP_CAT es muy flexible y se puede implementar en scripts de muchas maneras.

El ejemplo más directo es la operación del Árbol de Merkle, que puede interpretarse como dos elementos que se concatenan y luego se hashean. Actualmente, en el script de Bitcoin existen OP_SHA256 y otros códigos de operación de hash, por lo que si puedes concatenar dos elementos usando OP_CAT, puedes implementar la función de verificación del Árbol de Merkle en el script, lo que también proporciona la capacidad de verificación del cliente ligero hasta cierto punto.

Otra base para la implementación es la mejora de las firmas de Schnorr: puedes establecer la condición de firma de gasto de un script como una concatenación de la clave pública del usuario y un nonce público; luego, si el firmante desea firmar otra transacción para gastar los fondos en otro lugar, debe usar el mismo nonce, lo que puede filtrar la clave privada. Es decir, OP_CAT logra el compromiso con el nonce y asegura la validez de la transacción firmada.

Otras aplicaciones de OP_CAT incluyen Bistream,firmas de árbol, firmas Lamport resistentes a la computación cuántica, bóvedas y más.

OP_CAT en sí no es una característica nueva, ya que existía en las primeras versiones de Bitcoin, pero era deshabilitado en 2010 debido a su potencial para ser explotado por atacantes. Por ejemplo, el uso repetido de OP_DUP y OP_CAT podría causar fácilmente que la pila de nodos completa explote al procesar dichos scripts, como se ve en esto demo.

Pero ¿no ocurrirá hoy en día el problema de la explosión de la pila mencionado una vez que se haya vuelto a habilitar OP_CAT? Debido a que la propuesta actual de OP_CAT solo implica habilitarlo en tapscript, que tiene un límite de 520 bytes por elemento de pila, no causará el problema de explosión de la pila anterior. También hay algunos desarrolladores que piensan que Satoshi Nakamoto puede ser demasiado estricto al deshabilitar por completo OP_CAT. Sin embargo, debido a la flexibilidad de OP_CAT, puede ser cierto que existirán algunos escenarios de aplicación que podrían conducir a vulnerabilidades.

Por lo tanto, combinando los escenarios de aplicación y los riesgos potenciales, OP_CAT ha recibido mucha atención recientemente, y también ha tenido Revisión de PR y actualmente es una de las propuestas de actualización más candentes.

Conclusión

“La auto-regulación trae libertad”, como se puede ver en la introducción anterior, los convenios pueden implementarse directamente en los scripts de Bitcoin para calificar más gastos en transacciones, lo que permite reglas de transacción similares al efecto de contratos inteligentes. Este enfoque de programación se puede verificar de manera más nativa en Bitcoin que los enfoques fuera de la cadena como BitVM, y también puede mejorar las aplicaciones en la cadena principal (control de congestión), aplicaciones fuera de la cadena (canales de estado) y otras nuevas direcciones de aplicaciones (staking slashing, etc.).

Las técnicas de implementación de los convenios, si se combinan con algunas otras mejoras, podrían desbloquear aún más el potencial de la programabilidad. Por ejemplo, la propuesta reciente para aritmética de 64 bits

en el revisiónpodría combinarse aún más con el propuestoOP_TLUVu otros convenios que podrían programarse según la cantidad de satoshis generados por una transacción.

Sin embargo, los convenios también pueden llevar a abusos o vulnerabilidades no planificadas, por lo que la comunidad también es cautelosa al respecto. Además, una actualización de los convenios requeriría una actualización de bifurcación suave de las reglas de consenso. Dadas las circunstancias que rodean la actualización de taproot, es probable que la actualización relacionada con los convenios también lleve tiempo para completarse.

Agradecimiento especial

Gracias Ajian, Fisher y Benpara revisión y sugerencias!

Referencias

• https://utxos.org/
• https://bitcoincovenants.com/
• Una colección de recursos relacionados con los convenios: https://gist.github.com/RobinLinus/c96fb7c81430ec6dc92f048687bd3068
• https://anyprevout.xyz/
• BIP 345: propuesta OP_VAULT: https://www.btcstudy.org/2023/04/13/bitcoin-improvement-proposals-345-op-vault-commit-0b0674c546/
• https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
• https://maltemoeser.de/paper/covenants.pdf
• https://bitcoinops.org/es/topics/op_cat/
• OP_CAT: https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0001.md
• Trucos de CAT y Schnorr: https://medium.com/blockstream/trucos-de-gato-y-schnorr-i-faf1b59bd298

Descargo de responsabilidad: Este material es solo para fines de información general y no constituye, ni debe interpretarse como, ninguna forma de asesoramiento de inversión, solicitud o oferta de inversiones, y HashKey Capital no acepta ninguna responsabilidad en relación con el uso o la dependencia de dicha información.

Mantente actualizado con las últimas noticias de HashKey Capital -

Sitio web — https://hashkey.capital/

Twitter — https://twitter.com/HashKey_Capital

LinkedIn — https://www.linkedin.com/company/hashkeycapital/

declaración:

1. Este artículo es reproducido de [medio], the copyright belongs to the original author [Jeffrey HuyHarper Li], si tienes alguna objeción a la reimpresión, por favor contacta al Gate Learnequipo , y el equipo lo manejará lo más pronto posible de acuerdo con los procedimientos relevantes.

2. Descargo de responsabilidad: Las opiniones expresadas en este artículo representan solo las opiniones personales del autor y no constituyen ningún consejo de inversión.

3. Otras versiones del artículo en otros idiomas son traducidas por el equipo de Gate Learn y no se mencionan en Gate.io, el artículo traducido no puede ser reproducido, distribuido o plagiado.