原文作者: Jefe de investigación de inversiones de HashKey Capital, Jeffrey HU, Gerente de inversiones de HashKey Capital, Harper LI
Recientemente, ha habido una ola de discusión en la comunidad Bitcoin sobre la reactivación de códigos de operación como OP_CAT. Taproot Wizard también atrajo mucha atención al lanzar NFT de Quantum Cats y afirmar haber obtenido un número BIP-420. Sus defensores afirman que habilitar OP_CAT puede habilitar "convenios", contratos inteligentes o programabilidad de Bitcoin.
Si nota la palabra "restricciones" y busca un poco, encontrará que se trata de otra gran madriguera de conejo. Los desarrolladores han estado discutiendo durante años que, además de OP_CAT, también existen OP_CTV, APO, OP_VAULT y otras técnicas para implementar cláusulas restrictivas.
Entonces, ¿cuáles son exactamente las “restricciones” de Bitcoin? ¿Por qué ha atraído la atención y el debate de tantos desarrolladores durante varios años? ¿Qué tipo de programabilidad se puede lograr con Bitcoin? ¿Cuál es el principio de diseño detrás de esto? Este artículo intenta ofrecer una introducción y discusión general.
¿Qué son las "restricciones"?
Los convenios, traducidos como "restricciones" en chino y a veces traducidos como "contratos", son un mecanismo que puede establecer condiciones para futuras transacciones de Bitcoin.
El script actual de Bitcoin también contiene condiciones restrictivas, como ingresar una firma legal y enviar un script coincidente al gastar. Pero mientras el usuario pueda desbloquearlo, podrá gastar el UTXO donde quiera.
La cláusula de restricción es para imponer más restricciones según cómo desbloquear esta restricción, como limitar el gasto después de UTXO, que es para lograr un efecto similar a los "fondos dedicados" u otras condiciones de entrada enviadas en una transacción en espera;
Más estrictamente hablando, el script actual de Bitcoin también tiene ciertas restricciones. Por ejemplo, el bloqueo de tiempo basado en el código de operación es realizar una introspección del campo nLock o nSequence de la transacción para lograr el límite de tiempo antes de que se complete la transacción, pero es básicamente. limitado a limitaciones de tiempo.
Entonces, ¿por qué los desarrolladores e investigadores diseñan estas comprobaciones de límites? Porque las cláusulas restrictivas no son sólo restricciones por restringir, sino que también establecen reglas para la ejecución de transacciones. De esta manera, los usuarios sólo pueden ejecutar transacciones de acuerdo con reglas preestablecidas para completar el proceso comercial predeterminado.
De manera contraria a la intuición, esto puede desbloquear más escenarios de aplicaciones.
Escenarios de aplicación
Garantizar penalizaciones por apostar
Uno de los ejemplos más intuitivos de términos restrictivos es la transacción de reducción de Babylon en el proceso de participación de Bitcoin.
El proceso de participación de Bitcoin de Babylon consiste en que los usuarios envíen sus activos BTC a un script especial en la cadena principal. Las condiciones de gasto incluyen dos tipos:
Final feliz: después de un cierto período de tiempo, el usuario puede desbloquearlo con su firma, lo que completa el proceso de eliminación de la apuesta.
Mal final: si un usuario comete actos malvados, como firmar doblemente en una determinada cadena PoS alquilada por Babylon, entonces a través de EOTS (firmas únicas extraíbles, firmas extraíbles de un solo uso), esta parte de los activos se puede desbloquear. y Un actor ejecutivo en la red obliga a que una parte de los activos se envíe a una dirección de grabación (barra oblicua)
Tema: Staking de Bitcoin: Desbloqueo de 21 millones de Bitcoins para asegurar la economía de prueba de participación
Tenga en cuenta el "envío forzado" aquí, lo que significa que incluso si este UTXO se puede desbloquear, el activo no se puede enviar a ningún otro lugar arbitrariamente y solo se puede quemar. Esto garantizará que los usuarios malintencionados no puedan utilizar sus firmas conocidas para transferirse activos a sí mismos y escapar del castigo.
Si esta función se implementa después de implementar restricciones como OP_CTV, se pueden agregar códigos de operación como OP_CTV a la rama de "final malo" del script de replanteo para implementar restricciones.
Antes de activar OP_CTV, Babylon necesita utilizar un método flexible, implementado conjuntamente por usuarios + comités, para simular el efecto de hacer cumplir las cláusulas de restricción.
control de congestión
En términos generales, la congestión se refiere a cuando la tarifa de transacción en la red Bitcoin es muy alta y hay más transacciones acumuladas en el grupo de transacciones esperando ser empaquetadas. Por lo tanto, si los usuarios desean confirmar las transacciones rápidamente, deben aumentar la tarifa de transacción.
En este momento, si un usuario debe enviar múltiples transacciones a múltiples beneficiarios, tendrá que aumentar la tarifa de manejo y asumir costos más altos. Al mismo tiempo, también aumentará aún más las tasas de manipulación de toda la red.
Si existen restricciones, una solución es que el remitente se comprometa con una transacción de envío por lotes. Esta promesa puede hacer que todos los destinatarios crean que la transacción final se llevará a cabo y pueden esperar hasta que la tasa de procesamiento sea baja antes de enviar transacciones específicas.
Como se muestra en el cuadro siguiente, cuando la demanda de espacio en bloque es alta, realizar transacciones resulta muy costoso. Al utilizar OP_CHECKTEMPLATEVERIFY, los procesadores de pagos de gran volumen pueden agregar todos sus pagos en una única transacción O(1) para su confirmación. Luego, con el tiempo, cuando la demanda de espacio en bloque disminuya, los pagos se podrán ampliar desde ese UTXO.
Fuente: https://utxos.org/uses/scaling/
Este escenario es un caso de aplicación típico propuesto por la cláusula de restricción OP_CTV. Se pueden encontrar más casos de aplicaciones en https://utxos.org/uses/ Además del control de congestión anterior, la página enumera apuestas de bifurcación suave, opciones descentralizadas, cadenas de transmisión, canales por lotes, canales no interactivos y minería sin coordinación sin confianza. Grupos, bóvedas, límites de contratos bloqueados por tiempo hash más seguros (HTLCS), etc.
Bóveda
Vault es un escenario de aplicación ampliamente discutido en las aplicaciones de Bitcoin, especialmente en el campo de las cláusulas restrictivas. Debido a que las operaciones diarias inevitablemente requieren un equilibrio entre la custodia de los fondos y las necesidades de uso de los fondos, la gente espera tener un tipo de aplicación de bóveda que pueda garantizar la seguridad de los fondos e incluso limitar la seguridad de los fondos incluso si la cuenta es pirateada (la clave privada es filtrado). Uso de fondos.
Las aplicaciones de clase Vault se pueden crear con relativa facilidad basándose en técnicas para implementar restricciones.
Tomemos como ejemplo el diseño de OP_VAULT: cuando se gastan fondos en la bóveda, primero se debe enviar una transacción a la cadena. Esta transacción indica una intención de gastar la bóveda, un "desencadenante", y establece una condición dentro de ella:
Si todo está bien, entonces la segunda transacción es aquella en la que se realiza el 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 coaccionada durante un "ataque de llave inglesa"), se puede enviar inmediatamente a otra dirección segura (almacenamiento más seguro para el usuario) antes de que se envíe la transacción de retiro de N bloques.
Proceso OP_VAULT, fuente: BIP-345
Cabe señalar que también se puede crear una aplicación de bóveda sin restricciones. Un método factible es utilizar la clave privada para preparar firmas para gastos futuros y luego destruir la clave privada. Sin embargo, todavía existen muchas limitaciones, como la necesidad de garantizar que la clave privada haya sido destruida (similar al proceso de configuración confiable en la prueba de conocimiento cero), el monto y la tarifa de manejo se determinan por adelantado (debido a la necesidad de prefirma), y hay una falta de flexibilidad.
Comparación de OP_VAULT y procesos de bóveda prefirmados, fuente: BIP-345
Canales estatales más robustos y flexibles
En términos generales, se puede considerar que los canales estatales, incluida Lightning Network, tienen casi la misma seguridad que la cadena principal (siempre que los nodos puedan observar el estado más reciente y normalmente puedan publicar el estado más reciente en la cadena). Sin embargo, con las restricciones vigentes, algunas nuevas ideas de diseño de canales estatales pueden ser más sólidas o flexibles además de Lightning Network. Los más conocidos 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 es homofónica a "L2" y propone una capa de ejecución para Lightning Network que permite que cualquier estado de canal posterior reemplace el estado anterior sin la necesidad de un mecanismo de penalización. Por lo tanto, también puede evitar la necesidad de guardar de forma similar a Lightning. Nodos de red. Múltiples estados previos para evitar que tu oponente haga el mal. Para lograr el efecto anterior, Eltoo propuso el método de firma SIGHASH_NOINPUT, es decir, APO (BIP-118).
Ark tiene como objetivo reducir la dificultad de la liquidez entrante y la gestión de canales de Lightning Network. Es un protocolo estilo joinpool en el que varios usuarios pueden aceptar un proveedor de servicios como contraparte dentro de un cierto período de tiempo y realizar transacciones UTXO virtuales (vUTXO) fuera de la cadena, pero compartir un UTXO en la cadena para reducir costos. De manera similar a la bóveda, Ark también se puede implementar en la red Bitcoin actual; sin embargo, después de introducir restricciones, Ark puede reducir la cantidad de interacción requerida en función de las plantillas de transacciones y lograr una salida unilateral menos confiable.
Descripción técnica de las restricciones
Como se puede ver en las aplicaciones anteriores, las cláusulas restrictivas se parecen más a un efecto que a una determinada tecnología, por lo que existen muchas formas técnicas de implementarlas. Si se clasifica, esto podría incluir:
Tipo: tipo general, tipo especial
Método de implementación: basado en código de operación, basado en firma
Recursión: recursiva, no recursiva
Entre ellos, la recursividad se refiere a la realización de algunas cláusulas restrictivas. También puede limitar la siguiente salida limitando la siguiente salida. Las restricciones agregadas pueden exceder una transacción y alcanzar una mayor profundidad de transacción.
Algunos diseños de cláusulas restrictivas populares incluyen:
* Recursión: si se combina con OP_CAT
El diseño de restricciones.
Como se puede ver en la introducción anterior, el script actual de Bitcoin limita principalmente las condiciones de desbloqueo y no limita cómo se puede gastar más el UTXO. Para implementar las restricciones, tenemos que pensar a la inversa: ¿por qué el script actual de Bitcoin no puede implementar las restricciones?
La razón principal es que el script Bitcoin actual no puede leer el contenido de la transacción en sí, es decir, la "introspección" de la transacción.
Si pudiéramos implementar la introspección de transacciones (inspeccionar cualquier contenido de la transacción (incluidos los resultados), entonces podríamos implementar restricciones.
Por lo tanto, las ideas de diseño de cláusulas restrictivas se centran principalmente en cómo lograr la introspección.
Basado en código de operación versus basado en firma
La idea más simple y burda 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 con diferentes funciones) para leer directamente el contenido de la transacción. Esta es la idea basada en códigos de operación.
Otra idea es que no puede leer y verificar directamente el contenido de la transacción en el script, pero puede usar el hash del contenido de la transacción; si el hash ha sido firmado, simplemente modifíquelo en el script, como OP_CHECKSIG Después Al verificar esta firma, podemos implementar indirectamente introspección y restricciones de transacciones. Esta idea se basa en el diseño de la firma. Incluyendo principalmente APO y OP_CSFS, etc.
O
SIGHASH_ANYPREVOUT (APO) es un método de firma de Bitcoin propuesto. La forma más sencilla de firmar es comprometerse tanto con la entrada como con la salida de la transacción, pero Bitcoin también tiene una forma más flexible, llamada SIGHASH, que se compromete selectivamente con la entrada o salida de una transacción.
El rango de firmas actual de SIGHASH y sus combinaciones para la entrada y salida de transacciones (fuente "Mastering Bitcoin, 2nd"
Como se muestra en la figura anterior, además de TODO que se aplica a todos los datos, el método de firma NINGUNO solo se aplica a todas las entradas y no se usa para la salida; SINGLE se basa en esto y solo se aplica a las salidas con el mismo número de secuencia de entrada. Además, SIGHASH también se puede combinar. Después de superponer el modificador ANYONECANPAY, solo es aplicable a una entrada.
SIGHASH de APO solo firma la salida, no la parte de entrada. Esto significa que las transacciones firmadas con APO se pueden adjuntar posteriormente a cualquier UTXO que cumpla las condiciones.
Esta flexibilidad es la base teórica para que la APO implemente cláusulas restrictivas:
Se pueden crear una o más transacciones por adelantado
Utilizando la información de estas transacciones se construye una clave pública que sólo puede obtener una firma.
De esta manera, cualquier activo enviado a esa dirección de clave pública solo se puede gastar mediante transacciones creadas previamente.
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 puedan gastar mediante transacciones creadas previamente. Luego, podemos estipular el destino de los activos en estas transacciones creadas previamente para implementar términos restrictivos.
Podemos entenderlo mejor comparando los contratos inteligentes de Ethereum: lo que podemos lograr a través de los contratos inteligentes es que solo cumpliendo ciertas condiciones podemos retirar dinero de la dirección del contrato, en lugar de gastarlo 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 con el proceso anterior es que existen dependencias circulares en el cálculo, porque es necesario conocer la entrada para prefirmar y crear la transacción.
La importancia de APO y SIGHASH_NOINPUT al implementar este método de firma es que puede resolver este problema de dependencia circular. Al calcular, solo necesita conocer (especificar) todos los resultados de la transacción.
OP_CTV
OP_CHECKTEMPLATEVERIFY (CTV), BIP-119, adopta un enfoque de código de operación mejorado. Toma un hash de compromiso como parámetro y requiere que cualquier transacción que ejecute el código de operación contenga un conjunto de resultados que coincidan con ese compromiso. A través de CTV, los usuarios de Bitcoin podrán limitar el uso de sus Bitcoin.
La propuesta se lanzó originalmente con el nombre OP_CHECKOUTPUTSHASHVERIFY (COSHV) y al principio se centró en la capacidad de crear transacciones de control de congestión, por lo que las críticas a la propuesta también se centraron en que el esquema no era lo suficientemente general y demasiado específico para los casos de uso de control de congestión.
En el caso de uso de control de congestión mencionado anteriormente, la remitente Alice podría crear y codificar 10 salidas y usar el resumen resultante para crear un script tapleaf que contenga COSHV. Alice también puede usar las claves públicas de los participantes para formar una clave interna de Taproot, lo que les permitirá colaborar en el gasto sin revelar la ruta del script de Taproot.
Luego, Alice le da a cada destinatario una copia de los 10 resultados para que cada uno de ellos verifique la transacción de configuración de Alice. Cuando más tarde quieran gastar el pago, cualquiera de ellos puede crear una transacción que contenga el resultado prometido.
A lo largo del proceso, mientras Alice crea y envía la transacción de configuración, Alice puede enviar estas 10 copias del resultado a través de métodos de comunicación asincrónicos existentes, como correo electrónico o unidades en la nube. Esto significa que los destinatarios no necesitan estar en línea ni interactuar entre sí.
Fuente: https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-transaction-output-commitments
De manera similar a APO, las direcciones también se pueden construir en función de las condiciones de gasto y los "bloqueos" se pueden realizar de diferentes maneras, incluida la adición de otras claves, bloqueos de tiempo y lógica combinable.
Fuente: https://twitter.com/OwenKemeys/status/1741575353716326835
Sobre esta base, CTV propuso que puede verificar si la transacción de gasto hash coincide con la definida, es decir, los datos de la transacción pueden usarse como clave para abrir el "candado".
Podemos continuar ampliando el ejemplo anterior de 10 receptores. El receptor puede configurar aún más su clave de dirección en un tx firmado pero no transmitido y enviarlo al siguiente lote de direcciones de receptor, y así sucesivamente, formando un sistema como se muestra en la figura siguiente. estructura de árbol. Alice puede crear un cambio de saldo de cuenta que involucre a varios usuarios utilizando solo 1 espacio de bloque utxo en la cadena.
Fuente: https://twitter.com/OwenKemeys/status/1741575353716326835
¿Y qué pasa si una de las hojas es un canal de rayos, un almacenamiento en frío u otra vía de pago? Luego, este árbol se expandirá de un árbol de gastos unidimensional y multinivel a un árbol de gastos multidimensional y multinivel, y los escenarios que puede admitir serán más ricos y flexibles.
Fuente: https://twitter.com/OwenKemeys/status/1744181234417140076
Desde que se propuso CTV, sufrió un cambio de nombre de COSHV en 2019, se le asignó BIP-119 en 2020 y surgió como un lenguaje de programación Sapio para crear soporte para los contratos de CTV. En 22 y 23, recibió muchas discusiones. actualizaciones y actualizaciones de la comunidad. El debate sobre su plan de activación sigue siendo una de las propuestas de actualización de bifurcación suave más discutidas en la comunidad.
OP_CAT
Como se introdujo al principio, OP_CAT también es una propuesta de actualización que actualmente está llamando mucho la atención. La función que implementa es concatenar (concatenante) dos elementos en la pila. Aunque parezca simple, OP_CAT puede ser muy flexible para implementar muchas funciones en scripts.
El ejemplo más directo son las operaciones relacionadas con los árboles merkle. El árbol Merkle puede entenderse como dos elementos que se concatenan primero y luego se procesan. Actualmente, existen códigos de operación hash como OP_SHA 256 en el script de Bitcoin, por lo que si OP_CAT se puede usar para unir dos elementos, la función de verificación del árbol merkle se puede implementar en el script, que también tiene una verificación ligera del cliente hasta un cierto medida.
Los fundamentos de implementación adicionales también incluyen mejoras en las firmas de Schnorr: las condiciones de firma de gasto del script se pueden establecer para empalmar la clave pública del usuario y el nonce público; luego, si el firmante quiere firmar otra transacción, los fondos se gastarán en otra parte. utilizar el mismo nonce y provocar que se filtre la clave privada. Es decir, el compromiso con el nonce se realiza a través de OP_CAT, asegurando así la validez de la transacción firmada.
Otros escenarios de aplicación de OP_CAT incluyen: Bistream, firma de árbol, firma Lamport resistente a cuánticos, bóveda, etc.
OP_CAT en sí no es una característica nueva. Existía en las primeras versiones de Bitcoin, pero se deshabilitó en 2010 porque podía ser explotada por ataques. Por ejemplo, reutilizar OP_DUP y OP_CAT puede hacer que toda la pila de nodos explote fácilmente al procesar dichos scripts; consulte esta demostración.
Pero, ¿volver a habilitar OP_CAT ahora no causará el problema de explosión de pila mencionado anteriormente? Debido a que la propuesta OP_CAT actual solo implica habilitarlo en tapscript, lo que limita cada elemento de la pila a no más de 520 bytes, el problema anterior de explosión de la pila no surgirá. También hay algunos desarrolladores que creen que la prohibición directa de OP_CAT por parte de Satoshi puede ser demasiado severa. Sin embargo, debido a la flexibilidad de OP_CAT, actualmente no se pueden agotar algunos escenarios de aplicación que pueden generar vulnerabilidades.
Por lo tanto, teniendo en cuenta los escenarios de aplicación y los riesgos potenciales, OP_CAT ha recibido mucha atención recientemente y también ha recibido revisión de relaciones públicas. Es una de las propuestas de actualización más populares en la actualidad.
Conclusión
"La autodisciplina trae libertad". Como se puede ver en la introducción anterior, las cláusulas restrictivas se pueden implementar directamente en los scripts de Bitcoin para limitar el gasto adicional de las transacciones, logrando así reglas de transacción similares a los efectos de los contratos inteligentes. En comparación con métodos fuera de la cadena como BitVM, este método de programación se puede verificar de forma más nativa en Bitcoin y también puede mejorar las aplicaciones en la cadena principal (control de congestión), las aplicaciones fuera de la cadena (canales de estado) y otras nuevas direcciones de aplicaciones ( penalizaciones por apostar, etc.).
Si la tecnología de implementación de las cláusulas de restricción se puede combinar con algunas actualizaciones subyacentes, se liberará aún más el potencial de la programabilidad. Por ejemplo, la propuesta del operador de 64 bits que se está revisando recientemente podría combinarse aún más con la propuesta OP_TLUV u otras restricciones que se pueden programar en función de la cantidad de satoshis generados por la transacción.
Sin embargo, los términos restrictivos también pueden dar lugar a algunos abusos no planificados o lagunas jurídicas, por lo que la comunidad también es más cautelosa al respecto. Además, la actualización de las cláusulas de restricción también requiere una actualización suave de las reglas de consenso. Debido a la situación durante la actualización de la raíz principal, las actualizaciones relacionadas con restricciones también pueden tardar en completarse.
¡Gracias a Ajian, Fisher y Ben por su revisión y sugerencias sobre este artículo!
Materiales de referencia 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-final2 8.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/cat-and-schnorr-tricks-i-faf1b59bd298
