1 Introducción

Para un algoritmo f, dos partes no confiables, Alice y Bob, pueden establecer confianza de la siguiente manera:

1. Alice ingresa x, ejecuta el Algoritmo f y obtiene el resultado y. Bob también usa la misma entrada x, ejecuta el Algoritmo f y obtiene y'. Si y e y' son iguales, Bob acepta la entrada x y la salida y proporcionadas por Alice. Este es un mecanismo común de prueba de validez, que se aplica generalmente en el Consenso de la Cadena de Bloques, donde Alice es un Nodo que empaqueta Bloques y Bob es un Nodo que participa en el Consenso.
2. Alice introduce x, ejecuta el programa zk.prove, obtiene el resultado y y la prueba de prueba. Bob ejecuta el programa zk.verify basado en f, y y prueba. Si el resultado es verdadero, Bob aceptará el resultado y de Alice; si es falso, Bob no aceptará el resultado y de Alice. Esto es una prueba de validez, Bob puede ser un contrato on-chain.
3. Alice introduce x, ejecuta el algoritmo f, y obtiene el resultado y. Bob también ejecuta el algoritmo f con la misma entrada x y obtiene y'. Si y y y' son iguales, no se hace nada; si y y y' no son iguales, Bob desafiará a Alice con el programa f. La interacción entre Alice y Bob puede ser de una o varias rondas. Se logra la arbitraje a través de un mecanismo de desafío-respuesta. Esto es una prueba de fraude, donde Bob es el desafiante, escuchando en línea y lanzando desafíos en línea.
4. Alice introduce x, ejecuta el programa zk.prove, obtiene el resultado y y la prueba de prueba. Bob ejecuta el programa zk.verify basado en f, y y prueba. Si el resultado es verdadero, no hace nada; si el resultado es falso, Bob desafiará a Alice con el programa de desafío. La interacción entre Alice y Bob puede ser de una o varias rondas. Arbitraje a través del mecanismo de desafío-respuesta. Este es un prueba de fraude, Bob es el desafiante, escuchando fuera de línea y desafiando en línea.

Para los puntos 2, 3 y 4 anteriores, sea x el estado inicial y las transacciones de Layer2, f el programa de consenso de Layer2, y el estado final de las transacciones, que corresponde a la solución de escalado de Layer2 en blockchain.

• prueba de validez: Bajo la hipótesis pesimista, se debe demostrar su validez antes de ser aceptado y entra en vigor inmediatamente. En la prueba de validez, se debe proporcionar evidencia de la transición de estado L2 correcta, lo que refleja una visión pesimista del mundo: solo se aceptará cuando se demuestre que el estado es correcto.
• prueba de fraude: Basado en la suposición optimista, se acepta por defecto a menos que alguien demuestre lo contrario. Tiene una ventana de desafío que solo se activa una vez que finaliza. En la prueba de fraude, se debe proporcionar evidencia de una transición de estado L2 incorrecta, reflejando una visión optimista del mundo: la transición de estado se considera correcta a menos que se demuestre lo contrario.

Tabla 1: Métodos para establecer la confianza

Además, es importante tener en cuenta:

• La clave para distinguir entre la prueba de fraude y la prueba de validez no radica en si se utiliza un sistema de prueba ZK como SNARK o STARK. El sistema de prueba ZK solo expresa el método de prueba utilizado, mientras que el fraude o la validez representan el contenido de la prueba. Por lo tanto, el escenario 1 en la tabla 1 se llama prueba de validez.
• La prueba de validez tiene una mejor vigencia, pero una mayor complejidad en la verificación on-chain; mientras que la prueba de fraude tiene una menor complejidad en la verificación on-chain, pero una peor vigencia.
• Para los casos 2 y 4 en la tabla 1, mediante el uso de la técnica ZK recursiva y combinada, se puede calcular y comprimir múltiples f, lo que reduce significativamente el costo de verificación on-chain en comparación con el cálculo off-chain.

Actualmente, los contratos inteligentes Turing completo, la prueba de fraude y la prueba de validez, gracias a Solidity, se aplican ampliamente en la capa 2 de Ethereum. Sin embargo, en el marco de BTC, debido a las limitaciones de la funcionalidad de los códigos de operación de BTC, la limitada cantidad de elementos de la pila (solo 1000) y otras restricciones, la aplicación de estas tecnologías aún está en una etapa exploratoria. Este artículo resume las limitaciones y las tecnologías innovadoras en el marco de BTC, investiga las tecnologías de prueba de validez y prueba de fraude, y describe la técnica única de segmentación de scripts en el marco de BTC.

Limitations and Breakthroughs Under the 2 BTC Paradigm

Dentro del marco de BTC existen muchas limitaciones, pero estas limitaciones pueden superarse mediante varios métodos o tecnologías ingeniosas. Por ejemplo, el uso de compromisos Bit puede romper la restricción de estado sin usar de UTXO, Taproot puede resolver la limitación del espacio de script, las salidas de enlace pueden superar la limitación del método de consumo de UTXO, mientras que los contratos inteligentes pueden romper la limitación de pre-firma.

2.1 Modelo UTXO y restricciones de script

BTC utiliza el modelo UTXO, donde cada UTXO está bloqueado en un script de bloqueo que define las condiciones que deben cumplirse para gastar ese UTXO. Hay algunas limitaciones en el script BTC:

1. El script de BTC es sin estado;
2. Para el tipo de salida P2TR, una sola transacción puede contener hasta aproximadamente 4 millones de códigos de operación, llenando todo el Bloquear, mientras que para otros tipos de salida, solo se pueden usar 10,000 códigos de operación;
3. La forma de gastar UTXO individuales es limitada y carece de exploración de formas de gasto combinadas;
4. No admite funciones de contrato flexibles;
5. El límite de tamaño del stack es de hasta 1000 elementos (incluyendo altstack y stack), y el tamaño máximo de un solo elemento es de 520 bytes;
6. Las operaciones aritméticas (como la suma y la resta) están limitadas a elementos de 4 bytes y no se pueden ampliar a elementos largos de 20 bytes o más, lo cual es necesario en la operación de encriptación;
7. Los códigos de operación como OPMUL y OPCAT han sido deshabilitados. El costo de simularlos con códigos de operación existentes es extremadamente alto, por ejemplo, simular un hash BLAKE3 costaría aproximadamente 75K de tamaño de script.

2.2 Promesa de Bit: Superar la limitación de estado sin UTXO

Actualmente, el script de BTC es completamente sin estado. Al ejecutar el script de BTC, el entorno de ejecución de cada script se restablecerá una vez completado. Esto hace que el script de BTC no pueda admitir nativamente que los scripts 1 y 2 compartan el mismo valor x. Sin embargo, este problema se puede resolver mediante algunos métodos, cuya idea principal es firmar de alguna manera un valor. Si se puede generar una firma para un valor, se puede lograr un script de BTC con estado. En otras palabras, al verificar las firmas de los valores de x en los scripts 1 y 2, se puede garantizar que se utilice el mismo valor x en estos dos scripts. Si hay conflictos de firmas, es decir, se firman dos valores diferentes para la misma variable x, se puede imponer una penalización. Este método se conoce como compromiso Bit.

El principio prometido por Bit es relativamente simple. Cada Bit corresponde a dos valores hash diferentes, hash0 y hash1. Si el valor de Bit a firmar es 0, se revela el preimagen de hash0; si el valor de Bit es 1, se revela el preimagen de hash1.

Tomando como ejemplo un mensaje de un solo bit m ∈ {0,1}, el script de desbloqueo de la promesa de bits correspondiente consta solo de algunos antecedentes: si el valor de bit es 0, el script de desbloqueo es preimage0 - "0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140"; Si el valor de bit es 1, el script de desbloqueo es preimage1 - "0x47c31e611a3bd2f3a7a42207613046703fa27496". Por lo tanto, a través de la promesa de Bit, es posible romper las limitaciones sin estado de los UTXO e implementar scripts BTC con estado, lo que a su vez hace posible todo tipo de nuevas características interesantes.

OP_HASH160

OP_DUP

0xf592e757267b7f307324f1e78b34472f8b6f46f3> // 这是hash1

OP_EQUAL

OP_DUP

OP_ROT

0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // 这是hash0

OP_EQUAL

OP_BOOLOR

OP_VERIFY

// El valor prometido de Bit ahora está en la pila. Puede ser "0" o "1".

Actualmente, Bit promete dos formas de implementación:

• Firma única de Lamport: El principio de la firma única de Lamport es relativamente simple, solo requiere el uso de funciones hash, y es adecuado para ser compatible con BTC. Para cada bit en el mensaje, se requiere comprometer dos valores hash, lo que hace que los datos de la firma sean relativamente grandes. Específicamente, para un mensaje de longitud v bits, la longitud de la llave pública es de 2v bits, mientras que la longitud de la firma es de v bits.
• Firma única de Winternitz: en comparación con la firma de Lamport, la firma de Winternitz reduce significativamente la longitud de la firma y la clave pública, pero aumenta la complejidad de la firma y la verificación. Este esquema permite establecer la longitud de la cadena hash d de manera flexible según sea necesario para equilibrar la longitud y la complejidad. Por ejemplo, establecer d = 15 puede reducir la longitud de la clave pública y la firma en aproximadamente 4 veces, pero aumenta la complejidad de la verificación en 4 veces. Esto es en realidad un compromiso entre el espacio de la pila y el tamaño del script de BTC. Cuando d = 1, la firma de Lamport se puede considerar como un caso especial de la firma de Winternitz.

Actualmente, la biblioteca BitVM2 implementa la firma de Winternitz basada en la función hash Blake3. La longitud de la firma correspondiente a un solo Bit es de aproximadamente 26 bytes. Por lo tanto, se puede observar que introducir un estado a través del compromiso de Bit tiene un costo. Por lo tanto, en la implementación de BitVM2, el mensaje primero se hashea para obtener un valor hash de 256 bits, y luego se compromete a Bit con ese valor hash para ahorrar gastos, en lugar de comprometer directamente cada Bit del mensaje original más largo.

2.3 Taproot：突破脚本空间限制

La actualización de la bifurcación suave Taproot de BTC se activó en noviembre de 2021 e incluye tres propuestas: firma Schnorr (BIP 340), Taproot (BIP 341) y TapScript (BIP 342). Esta actualización introduce un nuevo tipo de transacción: transacciones Pay-to-Taproot (P2TR). Al combinar las ventajas de Taproot, MAST (Merkle Abstract Syntax Tree) y la firma Schnorr, las transacciones P2TR pueden crear formatos de transacción más privados, flexibles y escalables.

P2TR admite dos formas de gasto: a través de la ruta de Llave secreta o la ruta de script. Según la especificación de Taproot (BIP 341), cuando se gasta a través de la ruta de script, la longitud de la ruta de Merkle correspondiente no puede superar los 128. Esto significa que la cantidad de tapleaf en el taptree no puede superar los 2^128. Desde la actualización de SegWit en 2017, la red BTC mide el tamaño del Bloquear en unidades de peso, con un máximo de 4 millones de unidades de peso (aproximadamente 4MB). Cuando se gasta la salida de P2TR a través de la ruta de script, solo se revela un único script de tapleaf, lo que significa que el Bloquear solo contiene un script de tapleaf. Por lo tanto, para las transacciones de P2TR, el tamaño máximo del script correspondiente a cada tapleaf puede alcanzar aproximadamente 4MB. Sin embargo, según la política predeterminada de BTC, muchos Nodos solo retransmiten transacciones de menos de 400K; las transacciones más grandes requieren la colaboración de Minero para ser empaquetadas.

La prima de espacio de script introducida por Taproot hace que sea más valioso simular operaciones criptográficas como la multiplicación y hash con códigos de operación existentes. Al construir cálculos verificables basados en P2TR, el tamaño del script ya no está limitado a 4MB, sino que puede dividirse en múltiples subfunciones distribuidas en múltiples tapleaves, superando así la limitación de espacio de script de 4MB. De hecho, el tamaño del verificador Groth16 implementado actualmente en BitVM2 es de hasta 2GB. Sin embargo, puede dividirse y distribuirse en aproximadamente 1000 tapleaves, y combinarse con compromisos Bit para garantizar la consistencia entre las entradas y salidas de cada subfunción, asegurando así la integridad y corrección de todo el cálculo.

2.4 Conector de salida: superar las restricciones de gasto UTXO

Actualmente, BTC ofrece dos formas nativas de gasto para una única salida de transacción no gastada (UTXO): gasto a través de un script o una llave pública. Por lo tanto, siempre que se cumpla la firma correcta de la llave pública o las condiciones del script, se puede gastar el UTXO. Dos UTXO pueden ser gastados de forma independiente, y no se pueden agregar restricciones para restringir estos dos UTXO, lo que significa que se deben cumplir condiciones adicionales para gastarlos.

Sin embargo, el fundador de ARK, Burak, inteligentemente utilizó la marca SIGHASH para lograr una salida de conector. En concreto, Alice puede crear una firma que envíe sus BTC a Bob. Dado que la firma puede comprometer varios insumos, Alice puede condicionar su firma a que solo sea válida cuando se consume el segundo insumo, que se conoce como conector y que conecta UTXO A y UTXO B. En otras palabras, la transacción Taketx solo es válida si UTXO B no ha sido consumida por Challengetx. Por lo tanto, al destruir la salida del conector, se puede evitar la validez de la transacción Taketx.

Figura 1: Diagrama de salida del conector

En BitVM2, la salida del conector actúa como una función if...else. Una vez que la salida del conector es gastada por una transacción, no puede ser gastada de nuevo por otra transacción, lo que garantiza su exclusividad. En la implementación real, se introducen UTXO adicionales con bloqueo temporal para permitir el ciclo de desafío-respuesta. Además, la salida del conector también puede establecer diferentes estrategias de gasto según sea necesario, por ejemplo, permitir que cualquiera gaste en caso de transacciones de desafío, pero solo permitir que el operador gaste en caso de transacciones de respuesta o permitir que cualquiera gaste después de un tiempo de espera.

2.5 Contrato: romper las restricciones de pre-firma

Actualmente, el script de BTC limita principalmente las condiciones de desbloqueo, pero no limita cómo se gasta la salida de transacción no gastada (UTXO) más adelante. Esto se debe a que el script de BTC no puede leer el contenido de la transacción en sí, por lo que no puede lograr la introspección de la transacción. Si el script de BTC pudiera verificar cualquier contenido de la transacción (incluida la salida), entonces podría lograr funciones de contrato.

La implementación actual del contrato se puede dividir en dos categorías:

• Pre-firma: Basado en la capacidad actual de secuencias de comandos de BTC, se construye un contrato de reserva con funcionalidad limitada a través de la pre-firma. Esto significa que los participantes deben diseñar y firmar todas las posibles transacciones futuras de antemano, lo que las bloquea en una Llave privada y una tasa de tarifa específica. Algunos esquemas incluso requieren que los participantes generen Llaves privadas a corto plazo para todas las transacciones prefirmadas. Una vez que se completa la pre-firma, estas Llaves privadas a corto plazo se eliminan de manera segura para evitar que los atacantes las obtengan y roben los fondos. Sin embargo, este proceso debe repetirse cada vez que se agregue un nuevo participante o se actualice una operación, lo que resulta en un alto costo de mantenimiento. Por ejemplo, Lighting Network logra contratos bilaterales mediante pre-firma y utiliza la técnica de contrato de tiempo de bloqueo hash (HTLC) para permitir la enrutación de múltiples contratos bilaterales, lo que resulta en una estrategia de escalado mínima de confianza. Sin embargo, Lighting Network requiere la pre-firma de múltiples transacciones y se limita a dos partes, lo que lo hace tedioso de usar; en BitVM1, se requiere la pre-firma de cientos de transacciones en cada inicialización, y en BitVM2 optimizado, el número de transacciones que se deben pre-firmar en cada inicialización también llega a decenas. En BitVM1 y BitVM2, solo los operadores involucrados en la pre-firma son elegibles para el reembolso. Si hay n participantes involucrados en la pre-firma y cada participante debe pre-firmar m transacciones, la complejidad de pre-firma de cada participante será n * m.
• Introducción de códigos de operación de contrato: La introducción de nuevos códigos de operación de contrato puede reducir significativamente la complejidad de la comunicación y los costos de mantenimiento entre los participantes del contrato, lo que proporciona una forma más flexible de implementar contratos en BTC. Por ejemplo, el código de operación OPCAT se utiliza para concatenar cadenas de bytes. Aunque su funcionalidad es simple, es muy potente y puede reducir significativamente la complejidad de BitVM. El código de operación OPTXHASH permite un control más preciso de las operaciones dentro del contrato. Si se utiliza en BitVM, puede admitir un rango más amplio de operadores, lo que mejora significativamente la seguridad de BitVM y minimiza la confianza. Además, el método de prefirmado implica fundamentalmente que los operadores en BitVM solo pueden seguir el proceso de reembolso, lo que resulta en una eficiencia de utilización de capital más baja. Sin embargo, mediante nuevos códigos de operación de contrato, es posible pagar directamente a los usuarios de salida desde el pool de fondos de peg-in, lo que mejora aún más la eficiencia de capital. Por lo tanto, un modelo de contrato flexible romperá efectivamente las limitaciones tradicionales de prefirmado.

3 BTC Layer2 Expansión: prueba de validez y prueba de fraude

tanto la prueba de validez como la prueba de fraude pueden ser utilizadas en la extensión Layer2 de BTC, sus principales diferencias se muestran en la tabla 2.

表 2：prueba de validez与prueba de fraude

Basado en las promesas de Bit, Taproot, pre-firmas y salidas de conector, se puede construir una prueba de fraude basada en BTC. Además, mediante la introducción de códigos de operación de contrato (por ejemplo, OP_CAT), también se puede construir una prueba de validez de BTC basada en Taproot. Además, la prueba de fraude se puede dividir en prueba de fraude con licencia y prueba de fraude sin licencia según si Bob tiene acceso al sistema sumar. En la prueba de fraude con licencia, solo un grupo específico puede desafiar a Bob, mientras que en la prueba de fraude sin licencia, cualquier tercero puede desafiar a Bob. La seguridad de la prueba de fraude sin licencia es mayor que la de la prueba de fraude con licencia, ya que Soltar el riesgo de colusión entre los participantes.

Según el número de interacciones de desafío-respuesta entre Alice y Bob, la prueba de fraude puede dividirse en prueba de fraude de una sola ronda y prueba de fraude de múltiples rondas, como se muestra en la figura 2.

Figura 2: prueba de fraude en una sola rueda vs prueba de fraude en varias ruedas

Como se muestra en la tabla 3, la prueba de fraude puede lograrse a través de diferentes modelos de interacción, incluyendo el modelo de interacción de una sola ronda y el modelo de interacción de múltiples rondas.

Tabla 3: Interacción de una sola ronda y de múltiples rondas

En el paradigma de expansión Layer2 de BTC, BitVM1 utiliza un mecanismo de prueba de fraude de múltiples rondas, mientras que BitVM2 utiliza un mecanismo de prueba de fraude de una sola ronda y bitcoin-circle stark utiliza una prueba de validez. Entre estos mecanismos, BitVM1 y BitVM2 pueden lograrlo sin modificar el protocolo BTC, mientras que bitcoin-circle stark requiere la introducción de un nuevo código de operación OP_CAT.

Para la mayoría de las tareas de cálculo, las signet, testnet y mainnet de BTC no pueden admitir completamente scripts de 4MB, por lo que se requiere la técnica de división de scripts, es decir, dividir el script de cálculo completo en bloques de menos de 4MB y distribuirlo en diferentes Tapleaf.

3.1 prueba de fraude de varias rondas de Bitcoin

Como se muestra en la tabla 3, las rondas múltiples de prueba de fraude son adecuadas para aquellos que desean reducir los cálculos de arbitraje on-chain, o para situaciones en las que no se puede localizar el segmento de cálculo del problema de una vez. Como su nombre lo indica, las rondas múltiples de prueba de fraude requieren interacciones múltiples entre los probadores y los validadores para encontrar el segmento de cálculo del problema, y luego arbitrar en función de estos segmentos.

El White Paper temprano de BitVM de Robin Linus (comúnmente conocido como BitVM1) utilizó múltiples rondas de prueba de fraude. Suponiendo que cada período de desafío dure una semana y utilizando el método de búsqueda binaria para localizar el segmento de cálculo con problemas, el período de respuesta al desafío on-chain del verificador Groth16 podría extenderse hasta 30 semanas, lo que resulta en una baja eficiencia en términos de tiempo. Aunque actualmente hay equipos investigando métodos de búsqueda n-arios más eficientes que la búsqueda binaria, su eficiencia en términos de tiempo sigue siendo significativamente inferior al ciclo de 2 semanas de una sola ronda de prueba de fraude.

Actualmente, en BTC, el uso de pruebas de fraude de múltiples rondas implica un desafío con licencia, mientras que las pruebas de fraude de una sola ronda implementan un método sin desafío con licencia, lo que reduce el riesgo de conspiración entre los participantes y mejora la seguridad. Para lograr esto, Robin Linus aprovechó al máximo las ventajas de Taproot para optimizar BitVM1, reduciendo la cantidad de rondas de interacción a una sola y expandiendo el método de desafío a uno sin licencia, aunque esto aumenta el costo del cálculo de arbitraje en la cadena.

3.2 Bitcoin的一轮prueba de fraude

En este modelo, la validación de la prueba de fraude solo requiere una interacción entre el probador y los validadores. Los validadores solo necesitan lanzar un desafío una vez, mientras que el probador solo necesita responder una vez. En la respuesta, el probador debe proporcionar evidencia para demostrar que sus cálculos son correctos. Si los validadores encuentran alguna inconsistencia en la evidencia, el desafío tiene éxito; de lo contrario, falla. Las características de la interacción de una sola ronda de la prueba de fraude se muestran en la tabla 3.

Figura 3: Ronda única prueba de fraude

El 15 de agosto de 2024, Robin Linus publicó el White Paper técnico 'BitVM2: Conectando BTC a la Capa 2', que implementa un puente cross-chain que utiliza un método de prueba de fraude de una sola ronda similar al mostrado en la figura 3.

3.3 Uso de OP_CAT de Bitcoin prueba de validez

OP_CAT es parte del lenguaje de script cuando BTC fue lanzado, pero fue desactivado en 2010 debido a vulnerabilidades de seguridad. Sin embargo, la comunidad de BTC ha estado discutiendo la posibilidad de volver a habilitar OP_CAT durante muchos años. Actualmente, OP_CAT se ha asignado el número 347 y se ha activado en la red signet de BTC.

La función principal de OP_CAT es combinar dos elementos en la pila y empujar el resultado de vuelta a la pila. Esta función abre nuevas posibilidades para los contratos y los validadores STARK en BTC:

• Contrato: Andrew Poelstra propuso CAT y Schnorr Tricks I, que utilizan OP_CAT y la tecnología Schnorr para implementar contratos en BTC. Schnorr Algoritmo es una Firma digital que se aplica a los tipos de salida P2TR; para otros tipos de salida, se puede utilizar tecnología similar ECDSA, como se muestra en el contrato que utiliza CAT y ECDSA. Con el contrato OP_CAT, el validador STARK Algoritmo puede descomponerse en múltiples transacciones para verificar gradualmente toda la prueba STARK.
• Validador STARK: La función principal del validador STARK es conectar datos y realizar un hash. A diferencia de las operaciones algebraicas, el hash es una operación nativa en el script de BTC que puede reducir significativamente los costos. Por ejemplo, OPSHA256 es un único código de operación en su forma nativa, mientras que en su versión simulada requiere cientos de códigos de operación. Las operaciones hash principales en STARK incluyen la validación de rutas de Merkle y la transformación Fiat-Shamir. Por lo tanto, OP_CAT es muy compatible con el validador STARK Algoritmo.

3.4 Técnica de división de scripts BTC

A pesar de que la carga computacional necesaria para la prueba de validación después de las pruebas SNARK/STARK es mucho menor que la carga de ejecutar directamente el cálculo original f, la cantidad de scripts necesarios para convertirlo en un script de validador Bitcoin sigue siendo grande. Actualmente, con base en los códigos de operación de Bitcoin existentes, el tamaño de los scripts de validador Groth16 y Fflonk optimizados supera los 2 GB, mientras que el tamaño de un solo bloque Bitcoin es solo de 4 MB, por lo que no es posible ejecutar todo el script del validador en un solo bloque. Sin embargo, desde la actualización de Taproot, Bitcoin admite la ejecución de scripts a través de tapleaf, lo que permite que el script del validador se divida en varios bloques, cada uno de los cuales se construye como un tapleaf para formar un taptree. La consistencia entre bloques se puede garantizar mediante compromisos de bits.

En el caso del contrato OP_CAT, el verificador STARK puede dividirse en varias transacciones estándar de menos de 400KB, lo que permite que la validación completa de STARK prueba de validez se realice sin la necesidad de colaborar con el Minero.

Esta sección se centra en la técnica de división de scripts BTC en condiciones existentes sin introducir o activar ningún nuevo código de operación.

Al realizar la fragmentación de scripts, es necesario equilibrar la información de los siguientes aspectos:

• El tamaño del script de un solo bloque no debe superar los 4MB e incluirá el script de compromiso de entrada, la firma de la transacción y otros contenidos.
• El tamaño máximo de pila de un solo bloque no puede exceder los 1000. Por lo tanto, la pila de cada bloque debe contener solo los elementos necesarios para garantizar suficiente espacio de pila para la optimización del tamaño de script, ya que el blanqueo de capitales de BTC no está relacionado con el tamaño de la pila.
• En BTC, los costos de compromiso son altos. Por lo tanto, se debe reducir al mínimo el número de bits de entrada y salida entre dos bloques adyacentes, actualmente 1 bit corresponde a 26 bytes.
• Para facilitar la auditoría, la funcionalidad de cada bloque debe ser lo más clara posible.

Actualmente, los métodos de división de scripts se pueden clasificar en las siguientes tres categorías:

• Split automático: Este método busca una forma de dividir el tamaño del script a alrededor de 3MB, minimizando el tamaño de la pila en función del tamaño del script. Sus ventajas son que es independiente del Algoritmo validador específico y puede ser escalado para cualquier script de cálculo. Las desventajas incluyen: (1) Se debe marcar individualmente cada bloque lógico, por ejemplo, bloques de código OP_IF que no se pueden dividir; de lo contrario, el resultado de la ejecución del script dividido puede ser incorrecto; (2) El resultado de la ejecución del bloque puede corresponder a varios elementos en la pila, y se debe marcar la cantidad correcta de elementos de la pila que se requieren para aplicar el compromiso de bits según la lógica de cálculo real; (3) La funcionalidad lógica de cada bloque de script tiene baja legibilidad y es difícil de auditar; (4) La pila puede contener elementos que no se necesitan para el próximo bloque, lo que desperdicia espacio en la pila.
• Descomposición de funciones: este método descompone la funcionalidad en subfunciones claras, con entradas y salidas definidas. Al descomponer el script, se implementa un script de compromiso de bits necesario para cada bloque, asegurando que el tamaño total del script del bloque sea inferior a 4 MB y el tamaño de la pila sea inferior a 1000. Las ventajas son una funcionalidad clara, una lógica clara, una buena legibilidad y facilidad de auditoría. La desventaja es que la lógica de cálculo original puede no coincidir con la lógica a nivel de script, y las subfunciones originales pueden ser las mejores, pero no necesariamente las óptimas a nivel de script.
• División manual: este método no se basa en las subfunciones funcionales, sino que se establece manualmente. Este método es especialmente adecuado cuando el tamaño de una sola subfunción supera los 4MB. La ventaja es que permite la división manual de subfunciones de scripts grandes, como las relacionadas con el cálculo Fq12; cada bloque tiene una lógica clara y una alta legibilidad, lo que facilita la auditoría. La desventaja es que está limitado por la capacidad de optimización manual, después de optimizar el script en general, los puntos de división manual establecidos anteriormente pueden dejar de ser óptimos y deben ajustarse de nuevo.

Por ejemplo, después de múltiples rondas de optimización, el tamaño del script del verificador Groth16 ha disminuido de alrededor de 7GB a aproximadamente 1.26GB. Además de la optimización general de cálculos, cada bloque también puede ser optimizado individualmente para aprovechar al máximo el espacio de la pila. Por ejemplo, mediante la introducción de algoritmos de tabla de búsqueda más eficientes, y la carga y descarga dinámica de tablas de búsqueda, se puede reducir aún más el tamaño del script de cada bloque.

Debido a que el costo de cálculo y el entorno de ejecución del lenguaje de programación Web2 son completamente diferentes de los del script BTC, simplemente convertir la implementación existente de Algoritmo en un script BTC no es viable. Por lo tanto, es necesario considerar una optimización específica para el escenario BTC:

• Buscar un Algoritmo que pueda optimizar la localidad de la memoria, a pesar de que esto pueda aumentar la carga computacional, para reducir el número de bits de entrada/salida entre bloques, y así Soltar la cantidad de datos necesaria para comprometer en el diseño de transacciones assertTx de BitVM2.
• El intercambio de operaciones relacionadas (por ejemplo, operaciones lógicas), como x&y = y&x, ahorra casi la mitad del espacio de la tabla de búsqueda.
• Actualmente, el tamaño del script operado por Fq12 es grande; se puede considerar el uso de los esquemas Fiat-Shamir, Schwartz-Zipple y de compromiso polinomial para Soltar significativamente la complejidad computacional de la operación de expansión de Fq12.

4 Conclusion

Este artículo discute primero las limitaciones del script BTC y discute varias soluciones: superar las limitaciones sin estado de UTXO utilizando compromisos BTC, superar las limitaciones del espacio de script mediante el uso de Taproot, superar las limitaciones del método de gasto de UTXO mediante la conexión de salidas, y superar las limitaciones de la pre-firma mediante contratos. Luego, el artículo ofrece una descripción completa de las características de prueba de fraude y prueba de validez, incluidas las características de prueba de fraude con y sin licencia, las diferencias entre prueba de fraude de una ronda y prueba de fraude de múltiples rondas, y la tecnología de división de scripts BTC relacionada.

Declaración:

1. Este artículo es una reproducción de[aicoin], los derechos de autor pertenecen al autor original [mutourend & lynndell, Bitlayer Labs]. Si tiene alguna objeción a la reproducción, por favor contacte al equipo de Gate Learn (https://www.gate.io/questionnaire/3967), el equipo procesará lo antes posible de acuerdo con los procedimientos correspondientes.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ninguna recomendación de inversión.
3. Las versiones en otros idiomas de los artículos son traducidas por el equipo de Gate Learn. No se permite copiar, difundir o plagiar los artículos traducidos sin mencionar a Gate.io.