Autor: Jeffrey Hu & amp;

Recientemente, una ola de discusiones ha comenzado en la comunidad de Bitcoin sobre el rehabilitación de códigos de operación como OP_CAT.Taproot Wizard también ha atraído mucha atención al lanzar Quantum Cats ‘NFT, afirmando haber obtenido el número BIP-420, etc.Los partidarios afirman que habilitar OP_CAT puede implementar «convenios», implementar contratos inteligentes para bitcoin o programabilidad.

Si nota el término «cláusula de restricción» y lo busca,Encontrarás que esta es otra gran madriguera de conejos.Los desarrolladores lo han estado discutiendo durante años,Además de OP_CAT, también hay tecnologías que implementan restricciones como OP_CTV, Apo, OP_Vault.

Entonces, ¿cuáles son exactamente los «términos restringidos» de Bitcoin?¿Por qué puede atraer a tantos desarrolladores para continuar su atención y discusión durante años?¿Qué programabilidad se puede lograr en Bitcoin?¿Cuál es el principio de diseño detrás de esto?Este artículo dará una introducción y discusión general.

¿Cuáles son los «términos restringidos»?

Los convenios, traducidos como «cláusulas restringidas» en chino, a veces traducidos como «contratos», es un mecanismo que puede establecer condiciones para futuras transacciones de bitcoin.

Los scripts actuales de bitcoin también contienen restricciones, como ingresar una firma legal al gastar, enviar un guión que cumple, etc.Pero mientras el usuario pueda desbloquearlo, puede gastar el utxo en cualquier lugar que quiera.

La cláusula de restricción es hacer más restricciones sobre cómo desbloquear esta restricción.Por ejemplo, limitar el costo después de UTXO es lograr un efecto similar a los «fondos especiales y propósitos especiales»;En el análisis final,La cláusula de restricción puede limitar directamente los costos de transacción en el script de bitcoin, logrando así reglas de transacción similares al efecto de los contratos inteligentes.

Más rigurosamente, los scripts actuales de bitcoin también tienen ciertas restricciones.

Entonces, ¿por qué los desarrolladores e investigadores diseñan estos controles límite?Porque la cláusula de restricción no solo está restringida en aras de la limitación, sino que también establece reglas para la ejecución de la transacción.De esta manera, el usuario solo puede ejecutar transacciones de acuerdo con las reglas preestablecidas para completar el proceso comercial predeterminado.

Por lo tanto, es más contradictorio que esto pueda desbloquear más escenarios de aplicación.

Escenarios de aplicación de los convenios

Asegurar el castigo de replanteo

Uno de los ejemplos más intuitivos de restricciones es la transacción de barbilla de Babilonia en el proceso de apuestas de bitcoin.

El proceso de apuestas de Bitbylon Bitcoin es que los usuarios envían sus activos BTC a la cadena principal a un script especial, con dos condiciones de gasto:

· FINALO feliz:Después de un cierto período de tiempo, el usuario puede desbloquearlo con su propia firma, es decir, se completa el proceso de desatación.

· Mal final: Si un usuario comete un comportamiento malvado, como la doble firma en una cadena POS que alquila Babilonia, luego a través de EOT (firmas extrañas de una sola vez, puede extraer firmas a la vez), puede desbloquear esta parte de los activos y obtener ellos de la red El rol de ejecución obliga a una parte de los activos a la dirección de quema (Slash)

(Fuente: Bitcoin Revestido: desbloqueo de 21 millones de bitcoins para asegurar la prueba económica de prueba)

Preste atención al «envío forzado» aquí, lo que significa que incluso si el UTXO se puede desbloquear, el activo no puede enviarse arbitrariamente a cualquier otro lugar y solo se puede quemar.Esto asegurará que el usuario malvado no pueda transferir los activos primero con su firma conocida para escapar del castigo.

Si esta función se implementa en las restricciones como OP_CTV, puede agregar códigos OP como OP_CTV a la rama «Bad Fining» del script de replanteo para implementar las restricciones.

Antes de que OP_CTV esté habilitado, Babilonia necesita simular la implementación de la aplicación de cláusulas restringidas a través de una solución, que es implementada conjuntamente por el Usuario + Comité.

Control de congestión

En términos generales,La congestión se refiere a cuando la tarifa de manejo en la red de bitcoin es muy alta, y hay más transacciones acumuladas en el grupo de transacciones esperando ser empaquetadas.Por lo tanto, si el usuario desea confirmar rápidamente la transacción, necesita aumentar la tarifa de manejo.

En este momento, si un usuario tiene que enviar múltiples transacciones a múltiples beneficiarios, tiene que aumentar la tarifa de manejo y tener costos relativamente altos.Al mismo tiempo, aumentará aún más la tasa de tarifas de manejo de toda la red.

Si hay restricciones, una solución es enviar al remitente.Primero puede comprometerse con una transacción de lote.Esta promesa puede hacer que todos los destinatarios crean que la transacción final se llevará a cabo, y puede esperar hasta que la tarifa de manejo sea baja antes de enviar la transacción específica.

Como se muestra en la figura a continuación, cuando la demanda de espacio en bloque es alta, las transacciones se vuelven muy caras.Al usar OP_CHECKTEMPLINIFY, un procesador de pagos masivos puede agregar todos sus pagos a una sola transacción de complejidad o (1) para confirmación.Luego, después de un tiempo, cuando la demanda de las personas de espacio en bloque disminuye, los pagos se pueden ampliar de 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 de OP_CTV.Hay más casos de aplicación disponibles en https://utxos.org/uses/. Piscinas mineras gratuitas, bóvedas, límites de contratos bloqueados de tiempo hash más seguro (HTLC), etc.

Bóveda

Vault es un escenario de aplicación ampliamente discutido en aplicaciones de bitcoin, especialmente en el campo de las cláusulas restringidas.Porque las operaciones diarias inevitablemente necesitan equilibrar las necesidades del almacenamiento de fondos y el uso de fondos,La gente espera que haya un tipo de solicitud de custodia de bóvedas: puede garantizar la seguridad de los fondos, e incluso si la cuenta está pirateada (la clave privada se filtra), puede limitar el uso de fondos.

Según la tecnología para implementar restricciones, las aplicaciones de bóveda se pueden construir con relativa facilidad.

Tome el plan de diseño de OP_Vault como ejemplo:Al gastar fondos en la bóveda, primero debe enviar una transacción al enlace.Esta transacción demuestra la intención de gastar la bóveda, es decir, «desencadenante», y establece las condiciones allí:

Si todo está bien, entonces la segunda transacción es el retiro final.Después de esperar los bloques N, puede gastar más los fondos en cualquier lugar.

Si encuentra que la transacción fue robada (o fue coaccionada cuando fue atacada por una «llave de llave»), puede enviarla inmediatamente a otra dirección segura antes de la transacción de retiro en bloques N (el usuario puede mantenerlo más seguro)

(Op_Vault Process, Fuente: BIP-345)

Cabe señalar queSin restricciones, también se puede construir una aplicación de bóveda, Una forma factible es usar la clave privada para preparar la firma que gasta en el futuro y luego destruir la clave privada.Pero todavía hay muchas restricciones.Por ejemplo, es necesario asegurarse de que esta clave privada haya sido destruida (similar al proceso de configuración de confianza en prueba de conocimiento cero), la cantidad y la tarifa de manejo se determinan de antemano (porque se firman previamente) y, por lo tanto, carecen de flexibilidad.

(Comparación de los procesos de bóveda OP_VAULT y preferente, Fuente: BIP-345)

Canales estatales más robustos y flexibles

En general, se puede considerar que los canales de estado, incluida la red Lightning tienen casi la misma seguridad que la cadena principal (al garantizar que los nodos puedan observar el último estado y puedan publicar el último estado en el enlace normalmente).Sin embargo, con las restricciones en su lugar, algunas nuevas ideas de diseño de canales de estado pueden ser más robustas o flexibles además de la red Lightning.Entre ellos, los más conocidos incluyen Eltoo, Ark, etc.

Eltoo (también conocido como LN-simetría) es uno de los ejemplos más típicos.Esta solución técnica toma el homónimo de «L2» y propone una capa de ejecución para la red Lightning, lo que permite que cualquier estado de canal posterior reemplace el estado anterior sin la necesidad de un mecanismo de castigo. Nodos de red de rayos.Para lograr el efecto anterior, Eltoo propuso el método de firma de sighash_noinput, a saber, 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 una forma de protocolo de unión.Similar a las bóvedas, el ARK también se puede implementar en la red actual de Bitcoin;

Descripción general de la tecnología de los convenios

De la aplicación anterior, podemos ver que la cláusula de restricción de convenios es más como un efecto que una determinada tecnología, por lo que hay muchas formas técnicas de implementarla.Si se clasifica, puede incluir:

tipo:Tipo general, tipo especial

Método de implementación:Basado en Opcode, basado en la firma

recursión:Recursivo, no recursivo

Entre ellos, la recursión se refiere a: hay algunas implementaciones de restricciones, y la salida de la próxima transacción puede limitarse limitando la siguiente transacción.

Algunos diseños de restricciones convencionales incluyen:

Diseño de convenios de convenios Restringidos

Como se puede ver en la introducción anterior, los scripts actuales de bitcoin limitan principalmente las condiciones para el desbloqueo y no limitan cómo se gastará más a fondo el UTXO.Para implementar la cláusula de restricción, debemos pensar en reversa:¿Por qué el script Bitcoin actual no puede implementar la cláusula de restricción de convenios?

La razón principal es que el script de bitcoin actual no puede leer el contenido de la transacción en sí, es decir, la «introspección» de la transacción.

Si podemos implementar la introspección de la transacción, verificando cualquier cosa sobre la transacción (incluida la salida), entonces podemos implementar la cláusula de restricción.

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

Basado en OpCode VS basado en la firma

La idea más simple y cruda es agregar uno o más códigos de operación (es decir, un código de operación + parámetros múltiples, 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 el código de operación.

Otra idea es que, en lugar de leer y ver directamente el contenido de la transacción en sí en el script, puede usar el hash del contenido de la transacción: si este hash se ha firmado, solo modifique, por ejemplo, OP_CHECKSIG en el script implementando La inspección de esta firma, puede realizar indirectamente las cláusulas de introspección y restricción.Esta idea se basa en el diseño de la firma.Incluye principalmente Apo y OP_CSFS, etc.

Apo

Sighash_anyprevout (APO) es un método de firma de bitcoin propuesto.La forma más fácil de firmar es comprometerse con la entrada y la salida de la transacción, pero Bitcoin también tiene una forma más flexible, a saber, Sighash, que se compromete selectivamente con la entrada o salida de una transacción.

Actualmente, Sighash y sus combinaciones firman el rango de entrada y salida de transacción (fuente «Mastering Bitcoin, 2do»

Como se muestra en la figura anterior, a excepción de todo lo que se aplica a todos los datos, el método de firma de ninguno es aplicar solo a todas las entradas, no para salidas se basa en esto, solo se aplican las salidas que se aplican al mismo número de serie de entrada.Además, Sighash también se puede combinar, y solo se aplica a una entrada después de que el modificador AnyonecanPay se superponga.

El Sighash de Apo solo firma la salida, no la parte de entrada.Esto significa que las transacciones firmadas por APO se pueden adjuntar a cualquier UTXO que cumpla con las condiciones más adelante.

Esta flexibilidad es la base teórica para que la APO implementa restricciones:

Se pueden crear una o más transacciones por adelantado

A través de esta información de transacción, se puede construir una clave pública que solo puede obtener una firma.

De esta manera, cualquier activo enviado a la dirección de clave pública solo se puede gastar 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 asegura que estos activos solo se puedan gastar a través de transacciones pre-creadas.Luego, podemos especificar hacia dónde van los activos en estas transacciones pre-creadas, implementando así la cláusula de restricción.

Podemos entender más al comparar los contratos inteligentes de Ethereum:Lo que podemos lograr a través de contratos inteligentes es que podemos retirar dinero de la dirección del contrato solo a través de ciertas condiciones, en lugar de gastarlo a voluntad con una firma EOA.Desde este punto de vista, Bitcoin puede lograr este efecto a través de mejoras en el mecanismo de firma.

Pero el problema en el proceso anterior es que existe una dependencia circular durante el cálculo, porque necesita conocer el contenido de entrada para firmar y crear una transacción.

La importancia de Apo y Sighash_NoInput para implementar este método de firma es que puede resolver este problema de dependencia circular.

OP_CTV

OP_CHECKTEMPLINIFY (CTV), o BIP-119, adopta el método para mejorar el código de operación.Toma el hash de confirmación como un parámetro y requiere que cualquier transacción que ejecute el código de operación contenga un conjunto de salidas que coincidan con ese compromiso.A través de CTV, los usuarios de Bitcoin podrán limitar la forma en que usan Bitcoin.

La propuesta se lanzó originalmente bajo el nombre de OP_CheckoutputShashverify (Coshv)y al principio de centrarse en la capacidad de crear transacciones de control de congestión, las críticas a la propuesta también se centraron en los casos de uso de control de inconsistencia que no eran lo suficientemente universales y que eran demasiado específicas.

En el caso de uso de control de congestión mencionado anteriormente, el remitente Alice puede crear 10 salidas y hash las 10 salidas y usar el resumen generado para crear un script de Tapeleaf que contenga COSHV.Alice también puede usar las teclas públicas de los participantes para formar teclas internas de taproot para permitirles gastar juntas sin filtrar la ruta de script de taproot.

Alice luego le da a cada destinatario una copia de las 10 salidas para que cada una de ellas pueda verificar la transacción de configuración de Alice.Cuando quieran gastar este pago más tarde, cualquiera de ellos puede crear una transacción que contenga la salida prometida.

A lo largo del proceso, cuando Alice crea y envía transacciones establecidas, Alice puede enviar estas 10 copias de la salida a través de métodos de comunicación asíncronos existentes, como correo electrónico o unidades de nubes.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-outputcommits)

Similar a la APO, las direcciones también se pueden construir de acuerdo con las condiciones de gasto, y los «bloqueos» se pueden crear de diferentes maneras, que incluyen: agregar otras llaves, bloqueos de tiempo y lógica compuesta.

(Fuente: https://twitter.com/owenkemeys/status/1741575353716326835)

Sobre esta base, CTV propuso que puede verificar si la transacción de gasto después de hash coincide con la definición, es decir, usar los datos de la transacción como la clave para abrir el «bloqueo».

Podemos continuar extendiendo los 10 ejemplos de destinatario anteriores, y el receptor puede establecer su clave de dirección a un TX firmado pero no transmitido para enviarlo al siguiente lote de direcciones de destinatario, y así sucesivamente, formando una figura que se muestra en la figura a continuación -mike estructura.Alice puede construir un cambio de saldo de cuenta que involucre múltiples 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 otras rutas de pago?Luego, este árbol se expandirá de un árbol de gastos de una sola dimensión y múltiple a un árbol de gastos multidimensional y de múltiples capas, y los escenarios que puede soportar serán más ricos y flexibles.

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

Desde su introducción, CTV se ha sometido a un cambio de nombre de nombre de CoshV en 2019, asignado BIP-119 en 2020, y la aparición de SAPIO, un lenguaje de programación utilizado para crear un contrato de CTV, ha recibido muchas discusiones y actualizaciones en la comunidad en la comunidad en la comunidad 22 y 23 años, así como el debate sobre su plan de activación, sigue siendo una de las propuestas de actualización de horquilla suave que la comunidad ha discutido mucho.

OP_CAT

OP_CAT, como se introdujo al principio, también es una propuesta de actualización que actualmente está muy preocupada.Aunque parece simple, OP_CAT puede implementar muchas funciones en scripts con flexibilidad.

El ejemplo más directo es la operación relacionada con el árbol de Merkle.El árbol de Merkle puede entenderse ya que dos elementos se empalman primero y luego se hashan.Actualmente, hay códigos de operación hash como OP_SHA256 en el script de bitcoin, por lo que si puede usar OP_CAT para empalmar dos elementos, puede implementar la función de verificación del árbol de Merkle en el script, que tendrá una verificación del cliente de luz en cierta medida capacidad.

Otra base de implementación también incluye mejoras para las firmas de Schnorr: la condición de firma de gasto del script se puede establecer en la clave pública del usuario y el empalme público de no CE; ., Debes usar el mismo Nonce, lo que resulta en una fuga de clave privada.Es decir, el compromiso con Nonce se logra a través de OP_CAT, asegurando así la validez de las transacciones firmadas.

Otros escenarios de aplicación de OP_CAT incluyen: bistream, firmas de árboles, firmas de lamportes resistentes a la cantidad, bóvedas, etc.

OP_CAT no es una característica nueva, ha existido en las primeras versiones de Bitcoin, pero ha sido deshabilitado en 2010 debido al potencial de ser explotado por los ataques.Por ejemplo, la reutilización de OP_DUP y OP_CAT puede hacer que todo el nodo explote cuando procese dichos scripts, consulte esta demostración.

Pero, ¿se encontrará el problema de explosión de la pila mencionado antes si OP_CAT está habilitado ahora?Debido a que la propuesta OP_CAT actual solo implica habilitar Tapscript, que califica que cada elemento de pila no excede los 520 bytes, no habrá un problema previo de explosión de pila.Algunos desarrolladores también creen que la discapacidad directa de Satoshi Nakamoto puede ser demasiado estricta.Sin embargo, debido a la flexibilidad de OP_CAT, algunos escenarios de aplicación que pueden causar vulnerabilidades no pueden agotarse en la actualidad.

Por lo tanto, combinando escenarios de aplicación y riesgos potenciales, OP_CAT ha recibido mucha atención recientemente y también ha tenido una revisión de PR, que es una de las propuestas de actualización más populares en la actualidad.

Conclusión

«La autodisciplina trae libertad», como se muestra en la introducción anterior,La cláusula de restricción puede limitar directamente los costos de transacción en el script de bitcoin, logrando así reglas de transacción similares al efecto de los contratos inteligentes.En comparación con los métodos fuera de la cadena, como BITVM, este método de programación puede verificarse de manera más nativa en Bitcoin, 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 de la aplicación nueva. (Castigo de replanteo, etc.).

Si la tecnología de implementación de las cláusulas restringidas se puede combinar con algunas actualizaciones subyacentes, desatará aún más el potencial de programabilidad.Por ejemplo, la propuesta reciente para el operador de 64 bits en la revisión se puede combinar aún más con las restricciones OP_TLUV propuestas, y puede programarse en función del número de salidas de transacciones.

Pero las restricciones también pueden conducir a un abuso o lagunas no planificados, por lo que la comunidad es más cautelosa al respecto.Además, la actualización de la cláusula de restricción también requiere actualizaciones de horquilla suave que involucre reglas de consenso.Dada la situación cuando se actualiza Taproot, las actualizaciones relacionadas con las cláusulas de restricción también pueden tardar en completarse.