Explicación detallada de las cláusulas restrictivas: lograr la Programabilidad de Bitcoin
Recientemente, la comunidad de Bitcoin ha generado una ola de discusiones sobre la reactivación de los códigos de operación como OP_CAT. Taproot Wizard ha atraído la atención de muchas personas al lanzar Quantum Cats NFT y afirmar que obtuvo el número BIP-420. Los partidarios afirman que habilitar OP_CAT puede lograr "términos restrictivos", lo que permitiría la implementación de contratos inteligentes o programabilidad en Bitcoin.
Si prestas atención a la palabra "cláusulas restrictivas" y haces una búsqueda, descubrirás que es otro gran agujero de conejo. Los desarrolladores han estado discutiendo durante años, además de OP_CAT, sobre otras tecnologías para implementar cláusulas restrictivas como OP_CTV, APO, OP_VAULT, etc.
Entonces, ¿qué es exactamente la "cláusula de limitación" de Bitcoin? ¿Por qué ha atraído la atención y discusión de tantos desarrolladores durante años? ¿Qué programabilidad puede lograr Bitcoin? ¿Cuál es el principio de diseño detrás de esto? Este artículo intenta hacer una introducción y discusión general.
¿Qué es una "cláusula de limitación"?
Los términos restrictivos (Covenants) son un mecanismo que permite establecer condiciones para futuras transacciones de Bitcoin.
El script de Bitcoin actual también contiene condiciones restrictivas, como la necesidad de ingresar una firma válida al gastar, y presentar un script correspondiente. Sin embargo, siempre que el usuario pueda desbloquearlo, puede gastar ese UTXO en cualquier lugar que desee.
Y las cláusulas restrictivas son, sobre la base de cómo se desbloquea esto, imponer más restricciones, como limitar el gasto después de UTXO, es decir, lograr un efecto similar a "fondos específicos para fines específicos"; o las condiciones de otros inputs que se envían en una transacción, etc.
De manera más rigurosa, el script de Bitcoin actual también tiene ciertas cláusulas restrictivas, como el bloqueo por tiempo basado en códigos de operación, que se implementa a través de los campos nLock o nSequence de una transacción interna para establecer un límite de tiempo antes de gastar la transacción, pero también se limita principalmente a restricciones temporales.
Entonces, ¿por qué los desarrolladores e investigadores diseñan estas verificaciones de límites? Porque las cláusulas de límite no son solo para limitar por limitar, sino que establecen las reglas para la ejecución de transacciones. De esta manera, los usuarios solo pueden ejecutar transacciones de acuerdo con las reglas preestablecidas, completando así el proceso de negocio previsto.
Así que, en un sentido contrario a la intuición, esto puede desbloquear más casos de uso.
Escenario de aplicación
Asegurar la penalización de Staking
Un ejemplo más intuitivo de las cláusulas restrictivas es la transacción de slash de Babylon en el proceso de staking de Bitcoin.
El proceso de staking de Bitcoin de Babylon consiste en que los usuarios envían sus activos BTC a un script especial en la cadena principal, y las condiciones de gasto incluyen dos tipos:
En condiciones normales: después de un tiempo determinado, el usuario puede desbloquear con su propia firma, completando así el proceso de unstake.
Situaciones excepcionales: Si un usuario tiene comportamientos maliciosos como doble firma en una cadena PoS arrendada por Babylon, entonces a través de EOTS( extractable one-time signatures, una vez extraíbles firmas ), se puede desbloquear esta parte de los activos, y los roles ejecutivos en la red enviarán forzosamente una parte de los activos a la dirección de quema ( slash ).
Atención a aquí el "envío forzado", esto significa que incluso si se puede desbloquear este UTXO, el activo no puede ser enviado a cualquier otro lugar, solo se puede quemar. Así se garantiza que los usuarios malintencionados no puedan aprovecharse de su firma conocida para devolver el activo a sí mismos y así evadir el castigo.
Esta función, si se implementa después de la realización de términos restrictivos como OP_CTV, puede agregar opcodes como OP_CTV en la rama de "situaciones excepcionales" del script de staking para implementar restricciones.
Y antes de que se active OP_CTV, Babylon necesita simular la implementación del efecto de ejecución forzosa de las cláusulas restrictivas mediante un método alternativo, que es ejecutado conjuntamente por el usuario y el comité.
control de congestión
En general, la congestión se refiere a cuando la tasa de tarifas en la red de Bitcoin es muy alta, y hay una acumulación considerable de transacciones en el pool de transacciones esperando ser empaquetadas, por lo que si un usuario desea confirmar rápidamente una transacción, necesita aumentar la tarifa.
En este momento, si un usuario necesita enviar múltiples transacciones a varios beneficiarios, se verá obligado a aumentar las tarifas de transacción, asumiendo costos relativamente altos. Al mismo tiempo, esto también incrementará aún más la tasa de tarifas de toda la red.
Si hay cláusulas restrictivas, una solución es que el remitente puede comprometerse primero a una transacción de envío masivo. Este compromiso puede hacer que todos los receptores crean que la transacción final se llevará a cabo, y se puede esperar a que las tarifas de transacción sean bajas para enviar la transacción específica.
Cuando la demanda de espacio en bloques es alta, realizar transacciones se vuelve muy caro. Al usar OP_CHECKTEMPLATEVERIFY, los procesadores de pagos a gran escala pueden agregar todos sus pagos en una sola transacción O(1) para su confirmación. Luego, después de un tiempo, cuando la demanda de espacio en bloques disminuye, los pagos se pueden extender desde ese UTXO.
Este escenario es un caso de aplicación bastante típico propuesto por la cláusula restrictiva OP_CTV.
Bóveda
El vault( es un escenario de aplicación ampliamente discutido en las aplicaciones de Bitcoin, especialmente en el ámbito de los términos restrictivos. Debido a que las operaciones diarias inevitablemente deben equilibrar la custodia de fondos con la necesidad de uso de fondos, las personas desean tener una aplicación de bóveda que garantice la seguridad de los fondos, y que incluso si la cuenta es hackeada) y se filtra la clave privada(, se pueda restringir el uso de los fondos.
Basado en la tecnología para implementar cláusulas de restricción, las aplicaciones del tipo de custodia se pueden construir relativamente fácilmente.
Tomando como ejemplo el diseño de OP_VAULT: al gastar fondos en la bóveda, primero es necesario enviar una transacción a la cadena. Esta transacción indica la intención de gastar la bóveda, es decir, "trigger", y establece condiciones en su interior:
Si todo está bien, la segunda transacción es la transacción de retiro final. Después de esperar N bloques, los fondos se pueden gastar en cualquier lugar.
Si se descubre que esta transacción fue robada ) o fue amenazada por un "ataque de llave inglesa" (, se puede enviar inmediatamente a otra dirección segura ) antes de que se envíen las transacciones de retiro en N bloques, para que el usuario pueda almacenar ( de manera más segura.
Es importante tener en cuenta que, sin cláusulas restrictivas, también se puede construir una aplicación de custodia; una forma viable es preparar la firma para el gasto futuro con la clave privada y luego destruir esa clave privada. Sin embargo, todavía hay muchas restricciones, como la necesidad de asegurar que esta clave privada ya ha sido destruida ), similar al proceso de configuración de confianza en las pruebas de conocimiento cero (, cantidad y tarifas determinadas de antemano ) debido a la necesidad de pre-firmar (, lo que resulta en falta de flexibilidad, etc.
![Explicación detallada de los Covenants: ¿Cómo lograr la Programabilidad de Bitcoin?])https://img-cdn.gateio.im/webp-social/moments-163ceda005acef4c7986cd940c4f0945.webp(
) un canal de estado más robusto y flexible
Generalmente se puede considerar que los canales de estado, incluidos los de la red Lightning, tienen una seguridad casi equivalente a la de la cadena principal ###, siempre que los nodos puedan observar el estado más reciente y sean capaces de publicar correctamente el estado más reciente en la cadena (. Sin embargo, con la incorporación de cláusulas restrictivas, algunas nuevas ideas de diseño de canales de estado pueden ser más robustas o flexibles sobre la red Lightning. Entre las más conocidas se incluyen Eltoo, Ark, etc.
Eltoo ), también conocido como LN-Symmetry(, es uno de los ejemplos más típicos. Esta solución técnica toma la homofonía de "L2" y propone una capa de ejecución para la red Lightning, permitiendo que cualquier estado de canal posterior reemplace el estado anterior sin necesidad de un mecanismo de penalización, evitando así también la necesidad de que nodos de la red Lightning mantengan múltiples estados anteriores para prevenir el comportamiento malicioso de los oponentes. Para lograr el efecto mencionado, Eltoo propuso el método de firma SIGHASH_NOINPUT, es decir, APO)BIP-118(.
Ark tiene como objetivo reducir la dificultad del flujo de liquidez entrante 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 cierto período, realizando transacciones de UTXO)vUTXO( fuera de la cadena, pero compartiendo un UTXO en la cadena para reducir costos. Al igual que una bóveda, Ark también se puede implementar en la red de Bitcoin actual; sin embargo, después de introducir cláusulas restrictivas, Ark puede reducir la cantidad de interacciones necesarias basándose en plantillas de transacción, logrando así una salida unilateral más descentralizada.
![Explicación detallada de los Covenants: ¿Cómo lograr la Programabilidad de Bitcoin?])https://img-cdn.gateio.im/webp-social/moments-bf8295d231f632f2f6303d826e3e450b.webp(
Resumen técnico de los términos restrictivos
A partir de las aplicaciones mencionadas, se puede ver que las cláusulas restrictivas son más un efecto que una técnica en sí, por lo que hay muchas formas técnicas de implementación. Si se clasifican, pueden incluir:
Tipo: General, Especial
Forma de implementación: basada en Opcode, basada en firma
Recursivo: recursivo, no recursivo
Y entre ellos, la recursión se refiere a: la implementación de ciertas cláusulas restrictivas, que también puede limitar la salida de la siguiente transacción para restringir la salida de la transacción subsiguiente, lo que permite que las restricciones añadidas superen una transacción, alcanzando una mayor profundidad de transacción.
Algunos diseños de cláusulas restrictivas comunes incluyen:
OP_CTV: de tipo general, basado en Opcode, no recursivo
OP_VAULT: tipo especializado, basado en Opcode, no recursivo
APO: tipo general, basado en firma, no recursivo
OP_CAT: tipo general, basado en Opcode, recursivo*
OP_CSFS: tipo general, basado en firma, recursivo
*si se combina OP_CAT
![Explicación detallada de los Covenants: ¿Cómo lograr la Programabilidad de Bitcoin?])https://img-cdn.gateio.im/webp-social/moments-1344dbfaff294b02ebc0017e31d2a81d.webp(
Diseño de cláusulas restrictivas
A partir de la introducción anterior, se puede ver que el script de Bitcoin actual principalmente limita las condiciones de desbloqueo, sin restringir cómo se puede gastar posteriormente ese UTXO. Para implementar cláusulas restrictivas, debemos pensar al revés: ¿por qué el script de Bitcoin actual no puede implementar cláusulas restrictivas?
La razón principal radica en que el script de Bitcoin actual no puede leer el contenido de la transacción en sí, es decir, la "introspección" ).
Si podemos lograr la introspección de las transacciones — verificar cualquier contenido de la transacción (, incluidos los saldos ), entonces se pueden implementar las cláusulas restrictivas.
Por lo tanto, el enfoque de diseño de las cláusulas restrictivas se centra principalmente en cómo lograr la introspección.
( Basado en código de operación vs Basado en firma
La idea más simple y directa es agregar uno o más códigos de operación ), es decir, 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.
Y otra forma de pensar es que no es necesario leer y verificar directamente el contenido de la transacción en el script, sino que se puede utilizar el hash del contenido de la transacción: si este hash ya ha sido firmado, entonces se puede modificar el script, por ejemplo, utilizando OP_CHECKSIG, para realizar la verificación de esta firma, lo que permite implementar indirectamente la introspección de la transacción y las cláusulas restrictivas. Esta idea se basa en un diseño basado en la firma. Incluye principalmente APO y OP_CSFS.
( APO
SIGHASH_ANYPREVOUT)APO### es un tipo propuesto de firma de Bitcoin. La forma más sencilla de firmar es comprometerse a todas las entradas y salidas de una transacción, pero Bitcoin también tiene una forma más flexible, que es SIGHASH, comprometiéndose selectivamente a las entradas o salidas de una transacción.
y el SIGHASH de APO solo firma las salidas, sin firmar la parte de entrada. Esto significa que, después de firmar la transacción de la manera APO, se puede en
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Análisis detallado de las cláusulas restrictivas de Bitcoin: Abriendo una nueva era de Programabilidad
Explicación detallada de las cláusulas restrictivas: lograr la Programabilidad de Bitcoin
Recientemente, la comunidad de Bitcoin ha generado una ola de discusiones sobre la reactivación de los códigos de operación como OP_CAT. Taproot Wizard ha atraído la atención de muchas personas al lanzar Quantum Cats NFT y afirmar que obtuvo el número BIP-420. Los partidarios afirman que habilitar OP_CAT puede lograr "términos restrictivos", lo que permitiría la implementación de contratos inteligentes o programabilidad en Bitcoin.
Si prestas atención a la palabra "cláusulas restrictivas" y haces una búsqueda, descubrirás que es otro gran agujero de conejo. Los desarrolladores han estado discutiendo durante años, además de OP_CAT, sobre otras tecnologías para implementar cláusulas restrictivas como OP_CTV, APO, OP_VAULT, etc.
Entonces, ¿qué es exactamente la "cláusula de limitación" de Bitcoin? ¿Por qué ha atraído la atención y discusión de tantos desarrolladores durante años? ¿Qué programabilidad puede lograr Bitcoin? ¿Cuál es el principio de diseño detrás de esto? Este artículo intenta hacer una introducción y discusión general.
¿Qué es una "cláusula de limitación"?
Los términos restrictivos (Covenants) son un mecanismo que permite establecer condiciones para futuras transacciones de Bitcoin.
El script de Bitcoin actual también contiene condiciones restrictivas, como la necesidad de ingresar una firma válida al gastar, y presentar un script correspondiente. Sin embargo, siempre que el usuario pueda desbloquearlo, puede gastar ese UTXO en cualquier lugar que desee.
Y las cláusulas restrictivas son, sobre la base de cómo se desbloquea esto, imponer más restricciones, como limitar el gasto después de UTXO, es decir, lograr un efecto similar a "fondos específicos para fines específicos"; o las condiciones de otros inputs que se envían en una transacción, etc.
De manera más rigurosa, el script de Bitcoin actual también tiene ciertas cláusulas restrictivas, como el bloqueo por tiempo basado en códigos de operación, que se implementa a través de los campos nLock o nSequence de una transacción interna para establecer un límite de tiempo antes de gastar la transacción, pero también se limita principalmente a restricciones temporales.
Entonces, ¿por qué los desarrolladores e investigadores diseñan estas verificaciones de límites? Porque las cláusulas de límite no son solo para limitar por limitar, sino que establecen las reglas para la ejecución de transacciones. De esta manera, los usuarios solo pueden ejecutar transacciones de acuerdo con las reglas preestablecidas, completando así el proceso de negocio previsto.
Así que, en un sentido contrario a la intuición, esto puede desbloquear más casos de uso.
Escenario de aplicación
Asegurar la penalización de Staking
Un ejemplo más intuitivo de las cláusulas restrictivas es la transacción de slash de Babylon en el proceso de staking de Bitcoin.
El proceso de staking de Bitcoin de Babylon consiste en que los usuarios envían sus activos BTC a un script especial en la cadena principal, y las condiciones de gasto incluyen dos tipos:
Atención a aquí el "envío forzado", esto significa que incluso si se puede desbloquear este UTXO, el activo no puede ser enviado a cualquier otro lugar, solo se puede quemar. Así se garantiza que los usuarios malintencionados no puedan aprovecharse de su firma conocida para devolver el activo a sí mismos y así evadir el castigo.
Esta función, si se implementa después de la realización de términos restrictivos como OP_CTV, puede agregar opcodes como OP_CTV en la rama de "situaciones excepcionales" del script de staking para implementar restricciones.
Y antes de que se active OP_CTV, Babylon necesita simular la implementación del efecto de ejecución forzosa de las cláusulas restrictivas mediante un método alternativo, que es ejecutado conjuntamente por el usuario y el comité.
control de congestión
En general, la congestión se refiere a cuando la tasa de tarifas en la red de Bitcoin es muy alta, y hay una acumulación considerable de transacciones en el pool de transacciones esperando ser empaquetadas, por lo que si un usuario desea confirmar rápidamente una transacción, necesita aumentar la tarifa.
En este momento, si un usuario necesita enviar múltiples transacciones a varios beneficiarios, se verá obligado a aumentar las tarifas de transacción, asumiendo costos relativamente altos. Al mismo tiempo, esto también incrementará aún más la tasa de tarifas de toda la red.
Si hay cláusulas restrictivas, una solución es que el remitente puede comprometerse primero a una transacción de envío masivo. Este compromiso puede hacer que todos los receptores crean que la transacción final se llevará a cabo, y se puede esperar a que las tarifas de transacción sean bajas para enviar la transacción específica.
Cuando la demanda de espacio en bloques es alta, realizar transacciones se vuelve muy caro. Al usar OP_CHECKTEMPLATEVERIFY, los procesadores de pagos a gran escala pueden agregar todos sus pagos en una sola transacción O(1) para su confirmación. Luego, después de un tiempo, cuando la demanda de espacio en bloques disminuye, los pagos se pueden extender desde ese UTXO.
Este escenario es un caso de aplicación bastante típico propuesto por la cláusula restrictiva OP_CTV.
Bóveda
El vault( es un escenario de aplicación ampliamente discutido en las aplicaciones de Bitcoin, especialmente en el ámbito de los términos restrictivos. Debido a que las operaciones diarias inevitablemente deben equilibrar la custodia de fondos con la necesidad de uso de fondos, las personas desean tener una aplicación de bóveda que garantice la seguridad de los fondos, y que incluso si la cuenta es hackeada) y se filtra la clave privada(, se pueda restringir el uso de los fondos.
Basado en la tecnología para implementar cláusulas de restricción, las aplicaciones del tipo de custodia se pueden construir relativamente fácilmente.
Tomando como ejemplo el diseño de OP_VAULT: al gastar fondos en la bóveda, primero es necesario enviar una transacción a la cadena. Esta transacción indica la intención de gastar la bóveda, es decir, "trigger", y establece condiciones en su interior:
Es importante tener en cuenta que, sin cláusulas restrictivas, también se puede construir una aplicación de custodia; una forma viable es preparar la firma para el gasto futuro con la clave privada y luego destruir esa clave privada. Sin embargo, todavía hay muchas restricciones, como la necesidad de asegurar que esta clave privada ya ha sido destruida ), similar al proceso de configuración de confianza en las pruebas de conocimiento cero (, cantidad y tarifas determinadas de antemano ) debido a la necesidad de pre-firmar (, lo que resulta en falta de flexibilidad, etc.
![Explicación detallada de los Covenants: ¿Cómo lograr la Programabilidad de Bitcoin?])https://img-cdn.gateio.im/webp-social/moments-163ceda005acef4c7986cd940c4f0945.webp(
) un canal de estado más robusto y flexible
Generalmente se puede considerar que los canales de estado, incluidos los de la red Lightning, tienen una seguridad casi equivalente a la de la cadena principal ###, siempre que los nodos puedan observar el estado más reciente y sean capaces de publicar correctamente el estado más reciente en la cadena (. Sin embargo, con la incorporación de cláusulas restrictivas, algunas nuevas ideas de diseño de canales de estado pueden ser más robustas o flexibles sobre la red Lightning. Entre las más conocidas se incluyen Eltoo, Ark, etc.
Eltoo ), también conocido como LN-Symmetry(, es uno de los ejemplos más típicos. Esta solución técnica toma la homofonía de "L2" y propone una capa de ejecución para la red Lightning, permitiendo que cualquier estado de canal posterior reemplace el estado anterior sin necesidad de un mecanismo de penalización, evitando así también la necesidad de que nodos de la red Lightning mantengan múltiples estados anteriores para prevenir el comportamiento malicioso de los oponentes. Para lograr el efecto mencionado, Eltoo propuso el método de firma SIGHASH_NOINPUT, es decir, APO)BIP-118(.
Ark tiene como objetivo reducir la dificultad del flujo de liquidez entrante 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 cierto período, realizando transacciones de UTXO)vUTXO( fuera de la cadena, pero compartiendo un UTXO en la cadena para reducir costos. Al igual que una bóveda, Ark también se puede implementar en la red de Bitcoin actual; sin embargo, después de introducir cláusulas restrictivas, Ark puede reducir la cantidad de interacciones necesarias basándose en plantillas de transacción, logrando así una salida unilateral más descentralizada.
![Explicación detallada de los Covenants: ¿Cómo lograr la Programabilidad de Bitcoin?])https://img-cdn.gateio.im/webp-social/moments-bf8295d231f632f2f6303d826e3e450b.webp(
Resumen técnico de los términos restrictivos
A partir de las aplicaciones mencionadas, se puede ver que las cláusulas restrictivas son más un efecto que una técnica en sí, por lo que hay muchas formas técnicas de implementación. Si se clasifican, pueden incluir:
Y entre ellos, la recursión se refiere a: la implementación de ciertas cláusulas restrictivas, que también puede limitar la salida de la siguiente transacción para restringir la salida de la transacción subsiguiente, lo que permite que las restricciones añadidas superen una transacción, alcanzando una mayor profundidad de transacción.
Algunos diseños de cláusulas restrictivas comunes incluyen:
*si se combina OP_CAT
![Explicación detallada de los Covenants: ¿Cómo lograr la Programabilidad de Bitcoin?])https://img-cdn.gateio.im/webp-social/moments-1344dbfaff294b02ebc0017e31d2a81d.webp(
Diseño de cláusulas restrictivas
A partir de la introducción anterior, se puede ver que el script de Bitcoin actual principalmente limita las condiciones de desbloqueo, sin restringir cómo se puede gastar posteriormente ese UTXO. Para implementar cláusulas restrictivas, debemos pensar al revés: ¿por qué el script de Bitcoin actual no puede implementar cláusulas restrictivas?
La razón principal radica en que el script de Bitcoin actual no puede leer el contenido de la transacción en sí, es decir, la "introspección" ).
Si podemos lograr la introspección de las transacciones — verificar cualquier contenido de la transacción (, incluidos los saldos ), entonces se pueden implementar las cláusulas restrictivas.
Por lo tanto, el enfoque de diseño de las cláusulas restrictivas se centra principalmente en cómo lograr la introspección.
( Basado en código de operación vs Basado en firma
La idea más simple y directa es agregar uno o más códigos de operación ), es decir, 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.
Y otra forma de pensar es que no es necesario leer y verificar directamente el contenido de la transacción en el script, sino que se puede utilizar el hash del contenido de la transacción: si este hash ya ha sido firmado, entonces se puede modificar el script, por ejemplo, utilizando OP_CHECKSIG, para realizar la verificación de esta firma, lo que permite implementar indirectamente la introspección de la transacción y las cláusulas restrictivas. Esta idea se basa en un diseño basado en la firma. Incluye principalmente APO y OP_CSFS.
( APO
SIGHASH_ANYPREVOUT)APO### es un tipo propuesto de firma de Bitcoin. La forma más sencilla de firmar es comprometerse a todas las entradas y salidas de una transacción, pero Bitcoin también tiene una forma más flexible, que es SIGHASH, comprometiéndose selectivamente a las entradas o salidas de una transacción.
y el SIGHASH de APO solo firma las salidas, sin firmar la parte de entrada. Esto significa que, después de firmar la transacción de la manera APO, se puede en