1 Introducción

Para un algoritmo f, dos participantes mutuamente desconfiados, Alice y Bob, pueden establecer confianza de las siguientes formas:

1. Alice introduce x, ejecuta el algoritmo f y obtiene el resultado y. Bob también ejecuta el algoritmo f con la misma entrada x, obteniendo y′. Si y = y′, entonces Bob reconoce la entrada x proporcionada por Alice y la salida y. Este es un mecanismo especial de prueba de validez comúnmente utilizado en el consenso de blockchain, donde Alice es el nodo que empaqueta el bloque y Bob es el nodo que participa en el consenso.
2. Alice ingresa x, ejecuta el programa zk.prove en el algoritmo f y obtiene el resultado y y la prueba proof. Bob ejecuta el programa zk.verify basado en f, y y proof. Si el resultado es verdadero, entonces Bob reconoce el resultado y de Alice; si el resultado es falso, entonces Bob no reconoce el resultado y de Alice. Esto es una prueba de validez, donde Bob puede ser un contrato en la cadena.
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, obteniendo y′. Si y = y′, entonces no se hace nada; si y ≠ y′, entonces Bob desafía a Alice, con el programa desafiado siendo f. El número de interacciones entre Alice y Bob puede ser uno o múltiple. La arbitraje se logra a través del proceso de desafío-respuesta. Esto es una prueba de fraude, donde Bob es el desafiante, escuchando fuera de la cadena y desafiando en la cadena.
4. Alice ingresa x, ejecuta el programa zk.prove en el algoritmo f y obtiene el resultado y y la prueba proof. Bob ejecuta el programa zk.verify basado en f, y y proof. Si el resultado es verdadero, no se hace nada; si el resultado es falso, Bob desafía a Alice, siendo el programa desafiado zk.verify. El número de interacciones entre Alice y Bob puede ser único o múltiple. La arbitraje se logra a través del proceso de desafío-respuesta. Esta es una prueba de fraude, donde Bob es el desafiante, escuchando fuera de la cadena y desafiando en la cadena.

Para los anteriores 2, 3 y 4, sea x una transacción de Capa2 y el estado inicial, f sea el programa de consenso de Capa2 y y sea el estado final de la transacción, correspondiente a la solución de escalado de Capa2 de la cadena de bloques. Entre ellos:

• Prueba de Validez: Basado en una suposición pesimista, debe demostrarse válido antes de ser aceptado, y tiene efecto inmediato. En una prueba de validez, se debe proporcionar evidencia de transiciones de estado L2 correctas, reflejando una visión pesimista del mundo; solo cuando se demuestre que un estado es correcto, será aceptado.
• Prueba de Fraude: Basado en una suposición optimista, se acepta por defecto a menos que alguien demuestre que es incorrecto. Tiene un período de ventana de desafío, que solo tiene efecto después del período de ventana de desafío. En una prueba de fraude, se debe proporcionar evidencia de transiciones de estado L2 incorrectas, reflejando una visión optimista del mundo: se asume que una transición de estado es correcta a menos que se demuestre lo contrario.

Tabla 1: Formas de establecer confianza

Además, es importante tener en cuenta:

• La clave para distinguir entre pruebas de fraude y pruebas de validez no es si se utilizan sistemas de prueba ZK como SNARK/STARK. El sistema de prueba ZK expresa el método de prueba utilizado, mientras que el fraude o la validez representa el contenido que se está probando. Es por eso que se dice que el escenario 1 en la Tabla 1 representa una prueba de validez.
• Las pruebas de validez tienen mejor puntualidad, pero la complejidad de la verificación en cadena es relativamente alta; las pruebas de fraude tienen una complejidad de verificación en cadena más baja, pero su puntualidad es relativamente pobre.
• Para los casos 2 y 4 en la Tabla 1, utilizando técnicas de recursión ZK y combinación, se pueden calcular y comprimir múltiples f, lo que reduce significativamente el costo de verificación del cálculo fuera de la cadena en la cadena.

Actualmente, gracias a los contratos inteligentes Turing completos de Solidity, las pruebas de fraude y las pruebas de validez son ampliamente utilizadas en la escalabilidad de Capa 2 de Ethereum. Sin embargo, bajo el paradigma de Bitcoin, limitado por la funcionalidad limitada de los opcodes de Bitcoin, los 1000 elementos de pila y otras restricciones, la aplicación de estas tecnologías aún se encuentra en etapa exploratoria. Este artículo resume las limitaciones y las tecnologías innovadoras bajo el paradigma de Bitcoin en el contexto de la escalabilidad de Capa 2 de Bitcoin, estudia las tecnologías de prueba de validez y prueba de fraude, y describe la tecnología de segmentación de scripts única bajo el paradigma de Bitcoin.

2 Limitaciones y Avances bajo el Paradigma de Bitcoin

Bajo el paradigma de Bitcoin, existen muchas limitaciones, pero se pueden utilizar varios métodos o técnicas ingeniosas para superar estas limitaciones. Por ejemplo, el compromiso de bits puede superar la limitación estatal de UTXO, taproot puede superar las limitaciones del espacio de script, la salida del conector puede superar las limitaciones del método de gasto de UTXO, y los contratos pueden superar las limitaciones de pre-firma.

2.1 Modelo UTXO y Limitaciones del Script

Bitcoin adopta el modelo UTXO, donde cada UTXO está bloqueado en un script de bloqueo que define las condiciones que deben cumplirse para gastar ese UTXO. Los scripts de Bitcoin tienen las siguientes limitaciones:

1. Los scripts de Bitcoin son sin estado;
2. Para los tipos de salida P2TR, el número máximo de opcodes que se pueden acomodar en una sola transacción es aproximadamente 4 millones, llenando todo el bloque, mientras que para otros tipos de salida, solo hay 10,000 opcodes;
3. Los métodos de gasto de un solo UTXO son limitados, careciendo de exploración de métodos de gasto combinados;
4. No se admiten funciones de contrato flexibles;
5. El tamaño de la pila está limitado a un máximo de 1000 elementos (altstack + 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. No se pueden modificar a elementos largos, como 20 bytes o más grandes, que son necesarios para operaciones criptográficas;
7. Los opcodes como OPMUL y OPCAT han sido deshabilitados, y simularlos con opcodes existentes conlleva costos extremadamente altos, como simular un hash BLAKE3 de una sola ronda, con un tamaño de script de alrededor de 75K.

2.2 Compromiso de bits: superando la limitación estatal de UTXO

Actualmente, los scripts de Bitcoin son completamente sin estado. Al ejecutar un script de Bitcoin, su entorno de ejecución se restablece después de cada script. Esto conduce a la incapacidad de los scripts de Bitcoin para admitir nativamente los scripts de restricción 1 y 2 que tienen el mismo valor x. Sin embargo, este problema se puede evitar mediante algunos métodos, siendo la idea principal firmar un valor de alguna manera. Si se puede crear una firma para un valor, es posible lograr scripts de Bitcoin con estado. Es decir, al verificar la firma del valor x en los scripts 1 y 2, se puede garantizar que se utilice el mismo valor x en ambos scripts. Si hay una firma conflictiva, lo que significa que se firman dos valores diferentes para la misma variable x, se puede aplicar una penalización. Esta solución se conoce como compromiso de bit.

El principio del compromiso de bit es relativamente simple. Un bit se refiere a establecer dos valores hash diferentes, hash0 y hash1, para cada bit en el mensaje que se va a firmar. Si el valor del bit a firmar es 0, se revela la preimagen0 de hash0; si el valor del bit a firmar es 1, se revela la preimagen1 de hash1.

Tomando un mensaje de un solo bit m ∈{0,1} como ejemplo, el script de desbloqueo de compromiso de bit correspondiente son solo algunas preimágenes: si el valor del bit es 0, el script de desbloqueo correspondiente es preimage0 - “0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140”; si el valor del bit es 1, el script de desbloqueo correspondiente es preimage1 - “0x47c31e611a3bd2f3a7a42207613046703fa27496”. Por lo tanto, con el compromiso de bit, es posible superar la limitación sin estado de UTXO y lograr scripts de Bitcoin con estado, lo que hace posible diversas características nuevas interesantes.

OP_HASH160

OP_DUP

0xf592e757267b7f307324f1e78b34472f8b6f46f3> // Este es hash1

OP_EQUAL

OP_DUP

OP_ROT

0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // This is hash0

OP_EQUAL

OP_BOOLOR

OP_VERIFY

// Ahora el valor del compromiso de bits está en la pila. Ya sea "0" o "1".

Actualmente, existen 2 implementaciones de compromiso de bits:

• Firma de un solo uso de Lamport: el principio es relativamente simple y solo requiere el uso de funciones hash, lo que lo hace compatible con Bitcoin. Para cada bit en el mensaje, se deben comprometer dos valores hash, lo que resulta en datos de firma relativamente grandes. En otras palabras, para un mensaje de longitud v bits, la longitud de la clave pública es de 2v bits y la longitud de la firma es de v bits.
• Firma de un solo uso de Winternitz: En comparación con las firmas de Lamport, reduce significativamente las longitudes de las firmas y claves públicas, pero aumenta la complejidad de la firma y verificación. Este esquema permite la configuración flexible de diferentes longitudes de cadenas hash d, equilibrando así longitud y complejidad. Por ejemplo, establecer d = 15 resulta en que tanto la longitud de la clave pública como la longitud de la firma sean aproximadamente 4 veces más cortas, pero la complejidad de la verificación aumentará 4 veces. Esto es esencialmente un compromiso entre el espacio de la pila de Bitcoin y el tamaño del script. Las firmas de Lamport pueden considerarse como un caso especial de las firmas de Winternitz cuando d = 1.

Actualmente, la biblioteca BitVM2 implementa firmas de Winternitz basadas 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 el estado a través del compromiso de bits es costoso. Por lo tanto, en la implementación de BitVM2, el mensaje se hashea primero para obtener un valor hash de 256 bits, y luego se realiza el compromiso de bits en el valor hash para ahorrar recursos, en lugar de comprometer cada bit del mensaje original más largo directamente.

2.3 Taproot: Superando las Limitaciones del Espacio de Script

La actualización del soft fork de Bitcoin Taproot, activada en noviembre de 2021, incluye tres propuestas: firmas Schnorr (BIP 340), Taproot (BIP 341) y TapScript (BIP 342). Introduce un nuevo tipo de transacción: transacciones Pay-to-Taproot (P2TR). Las transacciones P2TR pueden crear un formato de transacción más privado, flexible y escalable al combinar las ventajas de Taproot, MAST (Árbol de Sintaxis Abstracta de Merkel) y firmas Schnorr.

P2TR admite dos métodos de gasto: gastar según la ruta de la clave o la ruta del script.

De acuerdo con las disposiciones en Taproot (BIP 341), al gastar a través del camino del script, el camino Merkle correspondiente no puede exceder una longitud máxima de 128. Esto significa que el número de tapleafs en el taptree no puede exceder 2^128. Desde la actualización SegWit en 2017, la red de Bitcoin mide el tamaño de bloque en unidades de peso, con un máximo de soporte de 4 millones de unidades de peso (aproximadamente 4MB). Cuando se gasta una salida P2TR a través del camino del script, solo necesita revelar un solo script de tapleaf, lo que significa que el bloque está empaquetado con un solo script de tapleaf. Esto implica que para las transacciones P2TR, el tamaño de script correspondiente a cada tapleaf puede ser un máximo de alrededor de 4MB. Sin embargo, según la política predeterminada de Bitcoin, muchos nodos solo reenvían transacciones más pequeñas que 400K; las transacciones más grandes deben colaborar con los mineros para ser empacadas.

El espacio de script premium aportado por Taproot hace que sea más valioso simular operaciones criptográficas como la multiplicación y el hashing utilizando los opcodes existentes.

Al construir una computación verificable basada en P2TR, el tamaño del script correspondiente ya no está limitado a la restricción de 4MB, sino que se puede dividir en múltiples subfunciones distribuidas en múltiples tapleafs, rompiendo así la limitación de espacio de script de 4MB. De hecho, el algoritmo verificador Groth16 implementado en el actual BitVM2 tiene un tamaño de hasta 2GB. Sin embargo, se puede dividir y distribuir en alrededor de 1000 tapleafs, y al combinarlo con el compromiso de bits, se puede restringir la coherencia entre las entradas y salidas de cada subfunción, asegurando la integridad y la corrección de toda la computación.

2.4 Conector de salida: superando las limitaciones del método de gasto UTXO

Actualmente, Bitcoin proporciona dos métodos de gasto nativos para un solo UTXO: gasto por script o por clave pública. Por lo tanto, siempre y cuando se cumplan la firma de clave pública o las condiciones de script correctas, se puede gastar el UTXO. Dos UTXOs se pueden gastar de forma independiente, y no se pueden agregar restricciones para limitar los dos UTXOs, lo que significa que deben cumplirse condiciones adicionales para gastarlos.

Sin embargo, Burak, el fundador del protocolo Ark, utilizó inteligentemente la bandera SIGHASH para lograr la salida del conector. Específicamente, Alice puede crear una firma para enviar sus BTC a Bob. Sin embargo, como la firma puede comprometer a múltiples entradas, Alice puede establecer su firma para que sea condicional: la firma es válida para la transacción Taketx si y solo si esa transacción consume la segunda entrada. La segunda entrada se llama el conector, que vincula UTXO A y UTXO B. En otras palabras, la transacción Taketx es válida si y solo si UTXO B no ha sido gastado por la Challengetx. Por lo tanto, al destruir la salida del conector, se puede bloquear la efectividad de la transacción Taketx.

Figura 1: Ilustración de salida del conector

En el protocolo 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 por otra transacción para garantizar su gasto exclusivo. En la implementación práctica, se introducen UTXOs adicionales con bloqueo de tiempo para permitir un período de desafío-respuesta. Además, la salida del conector correspondiente también puede configurarse con diferentes estrategias de gasto según sea necesario, como permitir que cualquier parte gaste en el caso de transacciones de desafío, mientras que solo se permite que el operador gaste o permitir que cualquiera gaste después de un tiempo de espera para las transacciones de respuesta.

2.5 Contratos: Superando las limitaciones de la firma previa

Actualmente, los scripts de Bitcoin principalmente limitan las condiciones para desbloquear, sin restringir cómo se puede gastar aún más el UTXO. Esto se debe a que los scripts de Bitcoin no pueden leer el contenido de la transacción en sí, lo que significa que no pueden lograr la introspección de la transacción. Si los scripts de Bitcoin pudieran verificar cualquier contenido de la transacción (incluidas las salidas), la funcionalidad del contrato podría realizarse.

Las implementaciones de contratos actuales se pueden dividir en dos categorías:

• Firma previa: Sobre la base de las capacidades de script de Bitcoin existentes, los contratos predeterminados de funcionalidad limitada se construyen a través de la firma previa. Esto significa diseñar y firmar todas las posibles transacciones futuras por adelantado, encerrando a los participantes en claves privadas específicas y tarifas de tarifas. Algunos esquemas incluso requieren que los participantes generen claves privadas a corto plazo para todas las transacciones pre-firmadas. Una vez que se completa la firma previa, estas claves privadas a corto plazo se eliminan de forma segura, lo que evita que los atacantes las obtengan y roben fondos. Sin embargo, cada vez que se agrega un nuevo participante o se actualiza una operación, es necesario repetir el proceso anterior, lo que genera altos costos de mantenimiento. Por ejemplo, Lightning Network logra contratos bipartitos a través de la firma previa y utiliza la tecnología Hash Time-Locked Contracts (HTLC) para implementar funciones de enrutamiento para múltiples contratos bipartitos, logrando así una estrategia de escalado con confianza minimizada. Sin embargo, Lightning Network requiere la firma previa de múltiples transacciones y está limitada a dos partes, lo que la hace algo engorrosa; en BitVM1, cientos de transacciones deben firmarse previamente en cada inicialización, mientras que en BitVM2 optimizado, el número de transacciones que deben firmarse previamente en cada inicialización también alcanza docenas. Tanto en BitVM1 como en BitVM2, solo los operadores que participan en la firma previa son elegibles para el reembolso. Si n participantes participan en la firma previa y cada participante necesita firmar previamente m transacciones, la complejidad de la firma previa para cada participante será n * m.
• Introducción de códigos de contrato: La introducción de nuevas operaciones de función de contrato puede reducir significativamente la complejidad de la comunicación y los costos de mantenimiento entre los participantes del contrato, lo que permite una implementación de contrato más flexible para Bitcoin. Por ejemplo, OPCAT: utilizado para concatenar cadenas de bytes. Aunque su función es muy simple, es muy potente y puede reducir significativamente la complejidad de BitVM; OPTXHASH: permite un mejor control granular de acciones dentro del contrato. Si se utiliza en BitVM, puede admitir un conjunto más amplio de operadores, mejorando así significativamente las suposiciones de seguridad de BitVM y minimizando la confianza. Además, el método de pre-firma implica inherentemente que los operadores en BitVM solo pueden adoptar un proceso de reembolso, lo que conduce a una menor eficiencia de utilización de capital; mientras que a través de nuevos códigos de contrato, puede ser posible pagar directamente desde el fondo de pool de peg-in a los usuarios de salida, mejorando aún más la eficiencia de capital. Por lo tanto, un modelo de contrato flexible romperá eficazmente las limitaciones tradicionales de pre-firma.

3 Bitcoin Capa 2 de Escalabilidad: Pruebas de Validez y Pruebas de Fraude

Tanto las pruebas de validez como las pruebas de fraude se pueden utilizar para la escalabilidad de Bitcoin L2, con las principales diferencias mostradas en la Tabla 2.

Tabla 2: Pruebas de Validez vs. Pruebas de Fraude

Basándose en el compromiso de bits, taproot, pre-firmado y salida de conector, se pueden construir pruebas de fraude basadas en Bitcoin. Basándose en taproot, también se pueden construir pruebas de validez basadas en Bitcoin mediante la introducción de opcodes de contrato, como OP_CAT. Además, según si Bob tiene un sistema de admisión, las pruebas de fraude se pueden dividir en pruebas de fraude con permiso y pruebas de fraude sin permiso. En las pruebas de fraude con permiso, solo grupos específicos pueden actuar como Bob para iniciar desafíos, mientras que en las pruebas de fraude sin permiso, cualquier tercero puede actuar como Bob para iniciar desafíos. La seguridad de las pruebas de fraude sin permiso es superior a la de las pruebas con permiso, lo que reduce el riesgo de colusión entre los participantes permitidos.

Según el número de interacciones de desafío-respuesta entre Alice y Bob, las pruebas de fraude se pueden dividir en pruebas de fraude de una sola ronda y pruebas de fraude de múltiples rondas, como se muestra en la Figura 2.

Figura 2: Pruebas de Fraude de Una Ronda vs. Pruebas de Fraude de Múltiples Rondas

Como se muestra en la Tabla 3, las pruebas de fraude pueden implementarse a través de diferentes modelos de interacción, incluidos modelos de interacción de una ronda y modelos de interacción de varias rondas.

Tabla 3: Interacción de una sola ronda vs. Interacción de varias rondas

En el paradigma de escalado de Capa 2 de Bitcoin, BitVM1 adopta un mecanismo de prueba de fraude de múltiples rondas, mientras que BitVM2 emplea un mecanismo de prueba de fraude de una sola ronda, y bitcoin-circle stark utiliza pruebas de validez. Entre estos, BitVM1 y BitVM2 se pueden implementar sin realizar ninguna modificación en el protocolo Bitcoin, mientras que bitcoin-circle stark requiere la introducción de un nuevo opcode OP_CAT.

Para la mayoría de las tareas computacionales, el signet, testnet y mainnet de Bitcoin no pueden representar completamente un script de 4MB, lo que hace necesario el uso de la tecnología de división de scripts, es decir, dividir el script de cálculo completo en fragmentos más pequeños que 4MB, distribuidos en varios tapleafs.

3.1 Prueba de Fraude de Varios Rounds en Bitcoin

Como se muestra en la Tabla 3, las pruebas de fraude de varias rondas son adecuadas para escenarios en los que hay un deseo de reducir la computación de arbitraje en cadena y/o donde no es posible señalar segmentos de computación problemáticos en un solo paso. Como su nombre indica, las pruebas de fraude de varias rondas requieren múltiples rondas de interacción entre el demostrador y el verificador para localizar los segmentos de computación problemáticos, seguidos por el arbitraje basado en los segmentos identificados.

El libro blanco temprano de BitVM de Robin Linus (comúnmente conocido como BitVM1) utilizó pruebas de fraude de múltiples rondas. Suponiendo que cada período de desafío dure una semana y empleando un método de búsqueda binaria para localizar los segmentos de cálculo problemáticos, el período de respuesta al desafío en cadena para el Verificador Groth16 podría extenderse hasta 30 semanas, lo que resulta en una mala puntualidad. Aunque actualmente hay equipos investigando métodos de búsqueda n-arios más eficientes que la búsqueda binaria, su puntualidad sigue siendo significativamente menor en comparación con el ciclo de 2 semanas en pruebas de fraude de una sola ronda.

Actualmente, las pruebas de fraude de varias rondas en el paradigma de Bitcoin emplean desafíos con permiso, mientras que las pruebas de fraude de una sola ronda han logrado un método de desafío sin permiso, reduciendo el riesgo de colusión entre los participantes y, por lo tanto, mejorando la seguridad. Con este fin, Robin Linus aprovechó al máximo las ventajas de Taproot para optimizar BitVM1. No solo se redujo el número de rondas de interacción a una, sino que el método de desafío también se amplió a un enfoque sin permiso, aunque a costa de aumentar el cálculo de arbitraje en cadena.

3.2 Pruebas de fraude de una ronda en Bitcoin

En este modelo, la verificación de pruebas de fraude puede completarse a través de una sola interacción entre el probador y el verificador. El verificador solo necesita iniciar un desafío, y el probador solo necesita responder una vez. En esta respuesta, el probador debe proporcionar pruebas que afirmen que su cálculo es correcto. Si el verificador encuentra inconsistencias en esa evidencia, el desafío tiene éxito; de lo contrario, falla. Las características de las pruebas de fraude interactivas de una sola ronda se muestran en la Tabla 3.

Figura 3: Prueba de Fraude de Una Ronda

El 15 de agosto de 2024, Robin Linus publicó el Libro Blanco Técnico BitVM2: Puenteando Bitcoin a Capa 2, que implementó un puente entre cadenas utilizando un método de prueba de fraude de una sola ronda similar al mostrado en la Figura 3.

3.3 Prueba de validez en Bitcoin con OP_CAT

OPCAT formaba parte del lenguaje de script original cuando se lanzó Bitcoin, pero se deshabilitó en 2010 debido a vulnerabilidades de seguridad. Sin embargo, la comunidad de Bitcoin ha estado discutiendo su reactivación durante años. OPCAT ahora ha sido asignado el número 347 y se ha habilitado en el signet de Bitcoin.

La función principal de OP_CAT es combinar dos elementos en la pila y empujar el resultado combinado de nuevo a la pila. Esta funcionalidad abre la posibilidad para contratos y Verificadores STARK en Bitcoin:

• Contratos: Andrew Poelstra propuso CAT y Schnorr Tricks I, utilizando técnicas OPCAT y Schnorr para implementar contratos en Bitcoin. El algoritmo Schnorr es una firma digital para tipos de salida P2TR; para otros tipos de salida, se pueden utilizar técnicas ECDSA similares, como se ve en los convenios con CAT y ECDSA. Con la ayuda de los contratos OPCAT, el algoritmo Verificador STARK se puede dividir en múltiples transacciones, verificando gradualmente la prueba STARK completa.
• Verificador STARK: El Verificador STARK básicamente conecta los datos y los hashea. A diferencia de las operaciones algebraicas, el hasheo es una operación nativa de script Bitcoin que puede ahorrar una cantidad significativa de gastos generales. Por ejemplo, OPSHA256 es un solo opcode en su forma nativa, mientras que una versión simulada requiere cientos de opcodes K. Las operaciones de hasheo principales en STARK implican verificar rutas de Merkle y transformaciones Fiat-Shamir. Por lo tanto, OPCAT es muy amigable con el algoritmo Verificador STARK.

3.4 Tecnología de división de scripts de Bitcoin

Aunque la carga computacional requerida para ejecutar el algoritmo verificador correspondiente para verificar la prueba después de la prueba SNARK/STARK es mucho menor que la requerida para ejecutar directamente el cálculo original f, la cantidad de script necesario al convertirlo para implementar el algoritmo verificador en el script de Bitcoin sigue siendo enorme. Actualmente, según los códigos de operación existentes de Bitcoin, el tamaño optimizado del script del verificador Groth16 y el tamaño del script del verificador Fflonk siguen siendo superiores a 2 GB. Sin embargo, el tamaño de un solo bloque de Bitcoin es de solo 4 MB, lo que hace imposible ejecutar todo el script del verificador dentro de un solo bloque. Sin embargo, desde la actualización de Taproot, Bitcoin admite la ejecución de scripts mediante tapleaf, lo que permite que el script del verificador se divida en varios fragmentos, y cada fragmento sirve como una hoja tap para construir un taptree. La coherencia de los valores entre los fragmentos se puede garantizar mediante el compromiso de bits.

En presencia de contratos OP_CAT, el Verificador STARK se puede dividir en múltiples transacciones estándar más pequeñas que 400KB, lo que permite completar la verificación de la prueba de validez STARK sin necesidad de colaborar con los mineros.

Esta sección se centra en la tecnología de división relevante de los scripts de Bitcoin bajo las condiciones existentes sin introducir o activar nuevos opcodes.

Al realizar la división de secuencias de comandos, se deben equilibrar las siguientes dimensiones de información:

• El tamaño de un único script de fragmento no debe exceder los 4MB y debe incluir los scripts de compromiso de bits de entrada, las firmas de transacción y otros espacios.
• El tamaño máximo de pila de un solo fragmento no debe superar los 1000. Por lo tanto, la pila de cada fragmento solo debe retener los elementos necesarios para reservar suficiente espacio de pila para la optimización del tamaño del script, ya que las tarifas de transacción de Bitcoin no dependen del tamaño de la pila utilizada.
• El compromiso de bits en Bitcoin es costoso. Por lo tanto, el número de bits en la entrada y salida entre dos fragmentos adyacentes debe minimizarse, ya que actualmente, 1 bit corresponde a 26 bytes.
• Para facilitar la auditoría, la funcionalidad de cada fragmento debe ser lo más clara posible.

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

• División automática: Este método busca un enfoque de división donde el tamaño del script sea de aproximadamente 3MB y el tamaño de la pila se minimice en función del tamaño de la pila y del tamaño del script. Las ventajas de este método son que es independiente de algoritmos verificadores específicos y se puede extender a la división de scripts para cualquier cálculo. Las desventajas son: (1) el bloque lógico completo debe ser marcado por separado, como los bloques de código OP_IF que no se pueden dividir; de lo contrario, el resultado de la ejecución del script dividido será incorrecto; (2) el resultado de la ejecución de un fragmento puede corresponder a múltiples elementos en la pila, lo que requiere marcar el número de elementos de la pila que necesitan aplicar un compromiso de bits basado en la lógica de cálculo real; (3) la legibilidad de la funcionalidad lógica implementada por cada script de fragmento es pobre, lo que dificulta la auditoría; (4) la pila puede contener elementos que no son necesarios para el siguiente fragmento, desperdiciando espacio en la pila.
• División funcional: Este método se divide en varias subfunciones funcionales en la computación, con valores de entrada y salida claros para las subfunciones. Al dividir el script, también implementa los scripts de compromiso de bits necesarios para cada fragmento, asegurando que el tamaño total del script de los fragmentos finales sea inferior a 4 MB y que el tamaño de la pila sea inferior a 1000. Las ventajas son: funcionalidad clara, lógica clara para cada fragmento, buena legibilidad y facilidad de auditoría. Las desventajas son: la expresión de la lógica de cálculo original puede no coincidir con la lógica a nivel de script, y las subfunciones de cálculo originales pueden ser óptimas pero no representar la optimalidad a nivel de script.
• División manual: En este método, los puntos de división no se basan en subfunciones funcionales, sino que se establecen manualmente. Esto es especialmente adecuado para casos en los que el tamaño de una sola subfunción supera los 4 MB. Las ventajas son: permite la división manual de subfunciones de tamaño de script pesado, como las relacionadas con cálculos de Fq12; lógica clara para cada fragmento, buena legibilidad y facilidad de auditoría. Las desventajas son: limitadas por las capacidades de ajuste manual, cuando el script general ha sido optimizado, los puntos de división previamente establecidos manualmente pueden no ser óptimos y necesitan ser readjustados.

Por ejemplo, después de múltiples rondas de optimización, el tamaño del script del verificador Groth16 se redujo de aproximadamente 7GB a aproximadamente 1.26GB. Además de esta optimización computacional general, cada fragmento también se puede optimizar individualmente para aprovechar al máximo el espacio de la pila. Por ejemplo, al introducir algoritmos basados en tablas de búsqueda mejoradas y cargar y descargar dinámicamente la tabla de búsqueda, el tamaño del script de cada fragmento se puede reducir aún más.

Los costos computacionales y los entornos de tiempo de ejecución de los lenguajes de programación web2 son completamente diferentes de los de los scripts de Bitcoin, por lo que simplemente traducir las implementaciones existentes de varios algoritmos en scripts de Bitcoin no es factible. Por lo tanto, es necesario considerar las optimizaciones específicas para el escenario de Bitcoin:

• Busque algoritmos que optimicen la localidad de la memoria, incluso a costa de una carga computacional adicional, para reducir el número de bits de entrada/salida entre los fragmentos, disminuyendo así la cantidad de datos requeridos para los compromisos en el diseño de transacción assertTx de BitVM2.
• Utilice la conmutatividad de las operaciones relacionadas (por ejemplo, operaciones lógicas), como x&y = y&x, para guardar casi la mitad de la tabla de búsqueda.
• Actualmente, el tamaño del script correspondiente a las operaciones Fq12 es grande; considere la posibilidad de aprovechar Fiat-Shamir, Schwartz-Zipple y los esquemas de compromiso polinómico para reducir significativamente la complejidad computacional de las operaciones de extensión Fq12.

4 Resumen

Este artículo primero presenta las limitaciones de los scripts de Bitcoin y discute el uso de compromisos de Bitcoin para superar la limitación sin estado de UTXO, el uso de Taproot para superar las limitaciones del espacio de script, el uso de salidas de conector para evitar las restricciones del método de gasto de UTXO y el uso de contratos para superar las limitaciones de pre-firma. Luego proporciona una descripción general y un resumen completo de las características de las pruebas de fraudes y las pruebas de validez, las características de las pruebas de fraude con permisos y sin permisos, las diferencias entre pruebas de fraude de una sola ronda y de múltiples rondas, y la tecnología de división de scripts de Bitcoin.

Descargo de responsabilidad:

1. Este artículo es una reimpresión de [aicoin]. Todos los derechos de autor pertenecen al autor original [mutourend & lynndell, Bitlayer Labs]. Si hay objeciones a esta reimpresión, por favor contáctese con el Gate Aprendeequipo y ellos lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones y puntos de vista expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.