Términos de restricción de Bitcoin: una nueva dirección para la Programabilidad

La comunidad de Bitcoin ha estado discutiendo enérgicamente la reactivación de operaciones como OP_CAT. Taproot Wizard ha atraído mucha atención al lanzar Quantum Cats NFT y afirmar que ha obtenido el número BIP-420. Los partidarios dicen que habilitar OP_CAT puede lograr "términos restrictivos", lo que traería contratos inteligentes y programabilidad a Bitcoin.

"cláusulas limitativas"(covenants) Este concepto ha suscitado años de debate entre los desarrolladores. Además de OP_CAT, existen varias soluciones tecnológicas para implementar cláusulas limitativas, como OP_CTV, APO y OP_VAULT. Entonces, ¿qué son las "cláusulas limitativas" en Bitcoin? ¿Por qué han generado un interés tan amplio y duradero? ¿Qué Programabilidad pueden aportar a Bitcoin? ¿Cuál es el principio de diseño detrás de esto? Este artículo proporcionará una introducción y discusión general sobre estas cuestiones.

¿Qué es una "cláusula de limitación"?

"Cláusulas restrictivas" ( convenios ) es un mecanismo que permite establecer condiciones para futuras transacciones de Bitcoin. El script actual de Bitcoin ya incluye algunas condiciones restrictivas, como la necesidad de una firma válida y la provisión de un script que cumpla con los requisitos. Pero siempre que el usuario pueda desbloquearlo, puede gastar el UTXO en cualquier lugar.

Y las cláusulas restrictivas han añadido más limitaciones sobre esta base, como restringir el destino del gasto posterior de UTXO, logrando el efecto de "fondos específicos para fines específicos"; o restringir las condiciones de otros inputs en una transacción, etc.

Más precisamente, el script de Bitcoin actual también tiene ciertas funcionalidades de cláusulas restrictivas, como el bloqueo temporal basado en códigos de operación. Al verificar los campos nLock o nSequence de la transacción, se puede implementar una restricción temporal antes del gasto de la transacción. Sin embargo, actualmente se limita principalmente a restricciones de tiempo.

El propósito de los desarrolladores al diseñar estas comprobaciones de restricciones no es solo limitar, sino también establecer las reglas de ejecución de las transacciones. Los usuarios solo pueden ejecutar transacciones de acuerdo con las reglas preestablecidas, completando así el proceso comercial planificado.

Por lo tanto, las cláusulas restrictivas pueden desbloquear más escenarios de aplicación de manera contraria a la intuición.

Escenario de aplicación

Asegurar la penalización de Staking

Un ejemplo intuitivo de las cláusulas de restricción es la transacción de slash de Babylon en el staking de Bitcoin.

El proceso de staking de Bitcoin de Babylon es que los usuarios envían activos BTC a un script especial en la cadena principal, las condiciones de gasto incluyen dos tipos:

1. Finalización normal: Después de un cierto tiempo, el usuario puede desbloquear con su propia firma y completar el proceso de unstake.

2. Fin de la penalización: Si un usuario tiene comportamientos maliciosos como doble firma en la cadena PoS de seguridad de Babylon, entonces a través de EOTS( se puede extraer una firma única ) que puede desbloquear activos, y los roles de ejecución en la red enviarán forzosamente una parte de los activos a la dirección de quema (slash).

Aquí, "envío forzado" significa que incluso si se puede desbloquear el UTXO, ese activo no puede ser enviado a otro lugar a voluntad, solo puede ser quemado. Esto asegura que los usuarios maliciosos no puedan devolver los activos a sí mismos con una firma conocida, escapando de la penalización.

Después de que se implementen las cláusulas restrictivas como OP_CTV, se pueden agregar códigos de operación relevantes en la rama "fin de la penalización" del script de staking para implementar las restricciones.

Y antes de que se habilite OP_CTV, Babylon necesita simular la efectividad de la ejecución de las cláusulas restrictivas a través de un método alternativo que sea ejecutado conjuntamente por los usuarios y el comité.

control de congestión

Durante la congestión de la red, se acumulan muchas transacciones pendientes de empaquetar en el pool de transacciones, y los usuarios necesitan aumentar las tarifas de transacción para obtener una confirmación rápida. Si los usuarios deben enviar múltiples transacciones a varios receptores, tendrán que asumir costos más altos, lo que a su vez elevará aún más la tasa de tarifas en toda la red.

Con los términos de restricción, el remitente puede comprometerse a realizar una transacción de envío por lotes. Este compromiso permite a todos los receptores creer que la transacción final se llevará a cabo, y se puede esperar a que disminuya la tasa de tarifas antes de enviar la transacción específica.

Cuando la demanda de espacio en la cadena de bloques es alta, las transacciones se vuelven costosas. Usando OP_CHECKTEMPLATEVERIFY, los procesadores de pagos a gran escala pueden agregar todos los pagos en una sola transacción O(1) para su confirmación. Luego, cuando la demanda de espacio en la cadena de bloques disminuye, se pueden extender los pagos desde ese UTXO.

Este es uno de los casos de uso típicos propuestos por la cláusula restrictiva OP_CTV.

Bóveda

El vault( es un escenario ampliamente discutido en las aplicaciones de Bitcoin, especialmente en el ámbito de los términos restrictivos. Las operaciones diarias requieren un equilibrio entre la custodia de fondos y las necesidades de uso, y la gente espera un tipo de aplicación de custodia: que pueda garantizar la seguridad de los fondos, incluso si la cuenta es hackeada) y la clave privada se filtra(, también pueda limitar el uso de los fondos.

Basado en la tecnología de cláusulas restrictivas, se pueden construir fácilmente aplicaciones de custodia.

Tomando como ejemplo el esquema OP_VAULT: al gastar fondos de la bóveda, primero se necesita enviar una transacción a la cadena que indique la intención )"trigger"(, y establecer condiciones:

• Situación normal: la segunda transacción es la transacción de retiro final. Después de esperar N bloques, los fondos se pueden gastar adicionalmente a cualquier dirección.

• Situaciones anormales: si se descubre que es una transacción robada ) o bajo coerción (, antes de enviar la transacción de retiro en N bloques, se puede enviar inmediatamente los fondos a una dirección más segura.

Es importante tener en cuenta que, incluso sin cláusulas restrictivas, se puede construir una aplicación de custodia. Una forma es preparar la firma del gasto futuro con la clave privada y luego destruir la clave privada. Sin embargo, este método aún tiene limitaciones, como la necesidad de asegurar que la clave privada ha sido destruida, y que el monto y las tarifas deben ser determinados de antemano, lo que carece de flexibilidad.

![Detalles sobre los Covenants: ¿Cómo lograr la Programabilidad de Bitcoin?])https://img-cdn.gateio.im/webp-social/moments-bf8295d231f632f2f6303d826e3e450b.webp(

) canales de estado más robustos y flexibles

El canal de estado ### incluye la red Lightning (, donde los nodos pueden observar el estado más reciente y pueden publicar el estado más reciente en la cadena de manera normal, lo que se puede considerar que tiene una seguridad casi idéntica a la de la cadena principal. Con la inclusión de cláusulas restrictivas, algunos nuevos diseños de canales de estado pueden ser más robustos o flexibles sobre la base de la red Lightning, siendo algunos de los más conocidos Eltoo, Ark, entre otros.

Eltoo), también conocido como LN-Symmetry(, es un ejemplo típico. Propone una capa de ejecución para la red Lightning que permite que cualquier estado de canal posterior reemplace un estado anterior sin necesidad de un mecanismo de penalización, evitando así que los nodos de la red Lightning deban conservar múltiples estados anteriores para prevenir el comportamiento malicioso de los oponentes. Eltoo propone el método de firma SIGHASH_NOINPUT, es decir, APO)BIP-118( para lograr este efecto.

Ark tiene como objetivo reducir la dificultad de la liquidez de entrada y la gestión de canales en la red Lightning. Es un protocolo en forma de joinpool, donde múltiples usuarios pueden aceptar a un proveedor de servicios como contraparte durante un tiempo determinado, realizando transacciones virtuales UTXO)vUTXO( fuera de la cadena, pero compartiendo un UTXO en la cadena para reducir costos. Similar a un custodio, Ark también puede implementarse en la actual red Bitcoin; sin embargo, tras la introducción de cláusulas restrictivas, Ark puede reducir la cantidad de interacciones necesarias basándose en plantillas de transacción, logrando una salida unilateral más descentralizada.

![Explicación detallada de Covenants: ¿Cómo lograr la Programabilidad de Bitcoin?])https://img-cdn.gateio.im/webp-social/moments-1344dbfaff294b02ebc0017e31d2a81d.webp(

Visión general de los términos restrictivos

A partir de las aplicaciones anteriores, se puede ver que las cláusulas restrictivas son más bien un efecto que una técnica específica, por lo que hay múltiples formas de implementación. Se pueden clasificar desde las siguientes dimensiones:

• Tipo: General, Específico
• Modo de implementación: basado en código de operación, basado en firma
• Recursividad: recursiva, no recursiva

En este caso, la recursión se refiere a que la implementación de algunas cláusulas restrictivas puede limitar la salida de la siguiente transacción para restringir la salida de la transacción posterior, logrando así restricciones que abarcan múltiples transacciones.

El diseño de cláusulas restrictivas principales incluye:

• OP_CTV: tipo general, basado en código de operación, no recursivo
• APO: Tipo genérico, basado en firma, no recursivo
• OP_VAULT: tipo especializado, basado en código de operación, no recursivo
• OP_CAT: tipo general, basado en códigos de operación, recursivo ) si se combina con OP_CAT (

![Detalles sobre Covenants: ¿cómo lograr la Programabilidad de Bitcoin?])https://img-cdn.gateio.im/webp-social/moments-a077d9a30293ef68ccb8482bfc57aeea.webp(

Diseño de las cláusulas restrictivas

Actualmente, el script de Bitcoin tiene principalmente limitaciones en las condiciones de desbloqueo, sin restricciones sobre cómo se pueden gastar los UTXO. Para implementar cláusulas restrictivas, es necesario reflexionar sobre por qué el script actual no puede lograr esta funcionalidad.

La principal razón es que actualmente el script de Bitcoin no puede leer el contenido de la transacción en sí, es decir, la "introspección" )introspection(.

Si se puede lograr la introspección de transacciones — revisar cualquier contenido de la transacción ) incluyendo la salida (, se pueden implementar términos restrictivos.

Por lo tanto, el diseño de las cláusulas de limitación se centra principalmente en cómo lograr la introspección.

![Explicación detallada de los Covenants: ¿Cómo lograr la Programabilidad de Bitcoin?])https://img-cdn.gateio.im/webp-social/moments-07087bfb6a80b962d13965a8a89b6c6d.webp(

) basado en código de operación vs basado en firma

La idea más directa es agregar uno o más códigos de operación ###, un código de operación + múltiples parámetros, o múltiples códigos de operación de diferentes funciones (, para leer directamente el contenido de la transacción. Esta es la idea basada en códigos de operación.

Otra forma de pensar es no leer y verificar directamente el contenido de la transacción en el script, sino utilizar el hash del contenido de la transacción: si este hash ha sido firmado, entonces se puede modificar en el script cosas como OP_CHECKSIG para verificar esta firma, lo que permite lograr indirectamente la introspección de la transacción y las cláusulas restrictivas. Este es un diseño basado en la firma, que incluye principalmente APO y OP_CSFS.

![Explicación detallada de Covenants: ¿Cómo lograr la Programabilidad de Bitcoin?])https://img-cdn.gateio.im/webp-social/moments-5eacb98269f8d7e5b02fe936ac208702.webp(

) APO

SIGHASH_ANYPREVOUT###APO( es un método de firma de Bitcoin propuesto. La forma más simple de firmar es comprometer tanto las entradas como las salidas de la transacción, pero Bitcoin también tiene una forma más flexible, que es SIGHASH, que permite comprometer selectivamente las entradas o salidas en la transacción.

El SIGHASH de APO solo firma las salidas, no la parte de entrada. Esto significa que las transacciones firmadas de esta manera con APO pueden ser añadidas posteriormente a cualquier UTXO que cumpla con las condiciones.

Esta flexibilidad es la base teórica de las cláusulas de limitación implementadas por APO:

• Se pueden crear una o más transacciones por adelantado
• Construir una clave pública que solo puede generar una firma a través de esta información de transacciones.
• De esta manera, cualquier activo enviado a esa dirección de clave pública solo se puede gastar a través de transacciones previamente creadas.

Es importante señalar que, debido a que esta clave pública no tiene una clave privada correspondiente, se puede garantizar que estos activos solo se pueden gastar a través de transacciones predefinidas. Podemos especificar la dirección de los activos en estas transacciones predefinidas, logrando así los términos de restricción.

Podemos entender a través de los contratos inteligentes de Ethereum: a través de contratos inteligentes, lo que podemos lograr también es que solo se pueda retirar del dirección del contrato bajo ciertas condiciones, y no simplemente gastando arbitrariamente con una firma EOA. Desde este punto de vista, Bitcoin puede lograr este efecto mediante la mejora del mecanismo de firma.

Pero el problema en el proceso mencionado es que hay dependencias cíclicas en los cálculos, ya que se necesita conocer el contenido de entrada para pre-firmar y crear la transacción.

El significado de implementar este tipo de firma con APO y SIGHASH_NOINPUT es que puede resolver este problema de dependencia cíclica; durante el cálculo, solo es necesario conocer todas las salidas de la transacción ) especificada por (.

![Explicación detallada de los Covenants: ¿cómo lograr la Programabilidad de Bitcoin?])https://img-cdn.gateio.im/webp-social/moments-302ac02874352e52cf0e80c7ddb193ec.webp(

) OP_CTV

OP_CHECKTEMPLATEVERIFY###CTV(, es BIP-119, que utiliza un código de operación mejorado.