BitcoinCamada 2扩展Análise técnica：prova de validade与prova de fraude

1 Introdução

Para um Algoritmo f, dois participantes não confiáveis, Alice e Bob, podem estabelecer confiança da seguinte maneira:

1. Alice insere x, executa o algoritmo f e obtém o resultado y. Bob também executa o algoritmo f com a mesma entrada x e obtém y’. Se y e y’ forem iguais, Bob reconhece a entrada x e a saída y fornecidas por Alice. Este é um mecanismo comum de prova de validade, geralmente aplicado no consenso de cadeia de blocos, onde Alice é um nó que empacota blocos e Bob é um nó participante do consenso.
2. Alice insere x, executa o programa zk.prove e obtém o resultado y e a prova proof. Bob executa o programa zk.verify com base em f, y e proof. Se o resultado for verdadeiro, Bob aceita o resultado y de Alice; se o resultado for falso, Bob não aceita o resultado y de Alice. Isso é uma prova de validade, Bob pode ser um contrato na cadeia.
3. Alice introduz x, executa o algoritmo f e obtém o resultado y. Bob também introduz o mesmo x e executa o algoritmo f, obtendo y′. Se y e y′ forem iguais, nada acontece; se y e y′ forem diferentes, Bob desafia Alice, e o programa desafiado é f. A interação entre Alice e Bob pode ser de uma ou várias rodadas. A arbitragem é realizada através de um mecanismo de desafio-resposta. Este é um tipo de prova de fraude, com Bob desafiando, ouvindo offline e desafiando online.
4. Alice insere x, executa o programa zk.prove, obtém o resultado y e a prova proof. Bob executa o programa zk.verify com base em f, y e proof. Se o resultado for verdadeiro, nada é feito. Se o resultado for falso, Bob desafia Alice usando o programa zk.verify. A interação entre Alice e Bob pode ser de uma ou várias rodadas. A arbitragem é realizada por meio do mecanismo de desafio-resposta. Isso é uma prova de fraude, onde Bob é o desafiante, monitorando offline e lançando desafios online.

Para os itens 2, 3 e 4 acima, seja x a transação Layer2 e o estado inicial, f o programa de Consenso Layer2, y o estado final da transação, correspondendo à solução de escalabilidade Layer2 da blockchain.

• prova de validade: Com base na suposição pessimista, deve-se provar a sua validade antes de ser aceite e entrar em vigor imediatamente. Em prova de validade, é necessário fornecer provas corretas de transições de estado L2, refletindo uma visão pessimista do mundo - só será aceite quando o estado for comprovado como correto.
• prova de fraude: Com base na suposição otimista, é aceito por padrão, a menos que alguém prove que está incorreto. Ele tem um período de janela de desafio e só entra em vigor após o término desse período. Em prova de fraude, evidências de transições de estado L2 incorretas devem ser fornecidas, refletindo uma visão otimista do mundo - as transições de estado são consideradas corretas, a menos que haja evidências em contrário.

Tabela 1: Métodos para estabelecer confiança

Além disso, é importante notar que:

• A diferença chave entre prova de fraude e prova de validade não está em usar sistemas de prova de conhecimento nulo (ZK) como SNARK ou STARK. Os sistemas de prova de conhecimento nulo (ZK) apenas expressam o método de prova utilizado, enquanto fraude ou validade representa o conteúdo da prova. Portanto, o cenário 1 na Tabela 1 é chamado de prova de validade.
• A prova de validade tem melhor eficácia, mas a complexidade da validação na cadeia é maior; por outro lado, a prova de fraude tem menor complexidade na validação na cadeia, mas a eficácia é inferior.
• Para os casos 2 e 4 na Tabela 1, usando a técnica de recursão e combinação ZK, é possível calcular e compactar vários f, reduzindo significativamente o custo de verificação do cálculo na cadeia para fora da cadeia.

Atualmente, graças à capacidade Turing completa do SolidityContrato inteligente, a tecnologia prova de fraudee prova de validade está amplamente implementada na extensão Layer2 do Ethereum. No entanto, dentro do framework do BTC, devido às limitações das funcionalidades de operação do BTC, a quantidade limitada de elementos na pilha, que é apenas 1000, e outras restrições, a aplicação dessas tecnologias ainda está em fase exploratória. Este artigo resume as limitações e as tecnologias inovadoras dentro do framework do BTC, investiga as tecnologias prova de validade e prova de fraude e esboça a tecnologia exclusiva de segmentação de scripts dentro do framework do BTC.

Limitations and Breakthroughs of the 2 BTC Paradigm

Dentro do quadro do Bitcoin, existem muitas limitações, mas essas limitações podem ser superadas por vários métodos ou tecnologias engenhosos. Por exemplo, o uso de Bit commitments pode quebrar as restrições de estado sem UTXO, o Taproot pode resolver as restrições do espaço de script, as saídas de conector podem superar as restrições do modo de consumo do UTXO, enquanto os contratos inteligentes podem superar as restrições de pré-assinatura.

2.1 Modelo UTXO e Restrições de Script

BTC adota o modelo UTXO, onde cada UTXO é bloqueado em um script de bloqueio que define as condições necessárias para gastar esse UTXO. Existem as seguintes restrições nos scripts BTC:

1. O script BTC é sem estado;
2. Para o tipo de saída P2TR, um único negócio pode conter cerca de 4 milhões de códigos de operação, preenchendo todo o Bloco, enquanto para outros tipos de saída, apenas 10.000 códigos de operação podem ser utilizados;
3. A forma de consumo de uma única UTXO é limitada, faltando a exploração de formas de consumo combinado;
4. Não suporta funcionalidades de contrato flexíveis;
5. O limite de tamanho da pilha é de até 1000 elementos (incluindo altstack e stack), com um tamanho máximo de 520 bytes por elemento;
6. As operações aritméticas (como adição e subtração) são limitadas a elementos de 4 bytes e não podem ser expandidas para elementos longos de 20 bytes ou mais, o que é necessário na operação de encriptação;
7. Opcodes como OPMUL e OPCAT foram desativados, e é extremamente caro emulá-los usando opcodes existentes, por exemplo, simulando um hash BLAKE3 uma vez, com um tamanho de script de cerca de 75K.

2.2 Promessa do Bit: ultrapassar as restrições de estado sem UTXO

Atualmente, o script BTC é completamente sem estado. Ao executar o script BTC, o ambiente de execução de cada script é redefinido após a conclusão. Isso impede que o script BTC suporte nativamente o compartilhamento do valor x entre os scripts de restrição 1 e 2. No entanto, esse problema pode ser resolvido usando alguns métodos, com a ideia central de assinar um valor de alguma forma. Se for possível gerar uma assinatura para um valor, é possível ter um script BTC com estado. Em outras palavras, verificando as assinaturas dos valores x nos scripts 1 e 2, é possível garantir o uso do mesmo valor x nesses dois scripts. Se houver uma assinatura em conflito, ou seja, assinaturas de valores diferentes para a mesma variável x, podem ser aplicadas penalidades. Esse método é chamado de compromisso Bit.

O princípio prometido pelo Bit é relativamente simples. Cada Bit corresponde a dois valores de hash diferentes, hash0 e hash1. Se o valor do Bit a ser assinado for 0, o prefixo de hash0 é revelado; se o valor do Bit for 1, o prefixo de hash1 é revelado.

Tomando uma única mensagem Bit m ∈ {0,1} como exemplo, o script de desbloqueio correspondente ao compromisso Bit é composto apenas por alguns preâmbulos: se o valor Bit for 0, o script de desbloqueio é preimage0 - “0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140”; se o valor Bit for 1, o script de desbloqueio é preimage1 - “0x47c31e611a3bd2f3a7a42207613046703fa27496”. Portanto, através do compromisso Bit, é possível contornar a restrição de estado não solicitada do UTXO, implementar scripts BTC com estado e tornar possíveis várias novas funcionalidades interessantes.

OP_HASH160

OP_DUP

0xf592e757267b7f307324f1e78b34472f8b6f46f3> // Este é o hash1

OP_EQUAL

OP_DUP

OP_ROT

0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // Este é o hash0

OP_EQUAL

OP_BOOLOR

OP_VERIFY

// O valor prometido da Bit está agora na pilha. Pode ser “0” ou “1”.

Atualmente, o Bit promete duas formas de implementação:

• Assinatura de Lamport de uso único: A assinatura de Lamport de uso único tem um princípio relativamente simples, usando apenas uma função hash, compatível com BTC. Para cada bit da mensagem, são necessários dois valores de hash, o que resulta em dados de assinatura relativamente grandes. Especificamente, para uma mensagem de comprimento v bits, o comprimento da Chave pública é de 2v bits, enquanto o comprimento da assinatura é de v bits.
• Assinatura de uma vez Winternitz: Em comparação com a assinatura de Lamport, a assinatura de Winternitz reduz significativamente o comprimento da chave pública e aumenta a complexidade da assinatura e verificação. Esse esquema permite ajustar flexivelmente o comprimento da cadeia de hash d de acordo com as necessidades, equilibrando o comprimento e a complexidade. Por exemplo, definir d = 15 pode reduzir o comprimento da chave pública e da assinatura em cerca de 4 vezes, mas aumenta a complexidade da verificação em 4 vezes. Isso é efetivamente um compromisso entre o espaço de pilha do BTC e o tamanho do script. Quando d = 1, a assinatura de Lamport pode ser considerada como um caso especial da assinatura de Winternitz.

Atualmente, a biblioteca BitVM2 implementa a assinatura de Winternitz baseada na função hash Blake3. O comprimento da assinatura correspondente a um único Bit é de cerca de 26 bytes. Portanto, podemos ver que há um custo para a introdução do estado através do Bit de compromisso. Portanto, na implementação do BitVM2, a mensagem é primeiro hash para obter um valor de hash de 256 bits e, em seguida, é feito o compromisso do Bit desse valor de hash, a fim de economizar custos, em vez de fazer o compromisso diretamente de cada Bit da mensagem original mais longa.

2.3 Taproot: Breakthrough in Script Space Limitation

A atualização de forquilha Taproot do BTC será ativada em novembro de 2021 e inclui três propostas: assinatura Schnorr (BIP 340), Taproot (BIP 341) e TapScript (BIP 342). Essa atualização introduz um novo tipo de transação chamado Pay-to-Taproot (P2TR). Ao combinar as vantagens do Taproot, MAST (Merkel Abstract Syntax Tree) e assinatura Schnorr, as transações P2TR podem criar um formato de transação mais privado, flexível e escalável.

P2TR suporta dois métodos de gasto: gasto através do caminho da Chave Secreta ou do caminho do script. De acordo com a especificação do Taproot (BIP 341), quando gastar pelo caminho do script, o comprimento do caminho Merkle correspondente não pode exceder 128. Isso significa que o número de folhas de toque no taptree não pode exceder 2^128. Desde a atualização do SegWit em 2017, a rede BTC mede o tamanho do Bloco em unidades de peso, com um máximo de 4 milhões de unidades de peso (cerca de 4 MB). Ao gastar a saída P2TR através do caminho do script, apenas um único script de folha de toque precisa ser revelado, o que significa que o Bloco contém apenas um único script de folha de toque. Portanto, para transações P2TR, o tamanho máximo do script correspondente a cada folha de toque pode ser de aproximadamente 4 MB. No entanto, de acordo com a política padrão do BTC, muitos nós só encaminham transações menores que 400K; transações maiores requerem cooperação com mineiros para serem empacotadas.

O prêmio do espaço de script trazido pelo Taproot torna mais valioso simular operações criptográficas como multiplicação e hash usando os códigos de operação existentes. Ao construir cálculos verificáveis baseados em P2TR, o tamanho do script não é mais limitado a 4 MB, mas pode ser dividido em várias subfunções distribuídas em várias folhas de toque, superando o limite de espaço de script de 4 MB. Na verdade, o verificador Groth16 Algoritmo implementado atualmente no BitVM2 tem um tamanho de até 2 GB. No entanto, ele pode ser dividido e distribuído em cerca de 1000 folhas de toque e combinado com o compromisso Bit para restringir a consistência entre as entradas e saídas de cada subfunção, garantindo assim a integridade e correção de todo o cálculo.

2.4 Saída do conector: ultrapassando as restrições do método de gasto UTXO

Atualmente, o BTC oferece duas formas nativas de gastos para uma única saída de transação não gasta (UTXO): através de um script ou Chave pública. Portanto, desde que seja cumprida a assinatura correta da Chave pública ou as condições do script, a UTXO pode ser gasta. Duas UTXOs podem ser gastas independentemente e não podem ser restritas juntas, o que significa que condições adicionais devem ser atendidas para gastá-las.

No entanto, o fundador do protocolo ARK, Burak, inteligentemente usou a sinalização SIGHASH para implementar saídas do conector. Mais especificamente, Alice pode criar uma assinatura para enviar seus BTC para Bob. Como a assinatura pode comprometer várias entradas, Alice pode condicionar sua assinatura para que seja válida apenas quando a segunda entrada for gasta. A segunda entrada é chamada de conector, que conecta UTXO A e UTXO B. Em outras palavras, a transação Taketx é válida apenas quando UTXO B não é gasto pela transação Challengetx. Portanto, destruindo a saída do conector, é possível impedir a validade da transação Taketx.

Figura 1: Esquema de saída do conector

No protocolo BitVM2, a saída do conector desempenha o papel de uma função if…else. Uma vez que a saída do conector tenha sido gasta por uma transação, não pode ser gasta novamente por outra transação, garantindo assim a sua exclusividade. Na implementação real, para permitir o ciclo de desafio-resposta, são introduzidos UTXOs adicionais com bloqueio de tempo. Além disso, a saída do conector pode ser configurada com diferentes estratégias de gastos, por exemplo, permitindo que qualquer parte gaste em transações de desafio, mas permitindo apenas que o operador gaste em transações de resposta, ou permitindo que qualquer pessoa gaste após o vencimento.

2.5 Contrato: Superar restrições de pré-assinatura

Atualmente, os scripts BTC limitam principalmente as condições de desbloqueio, não limitando como as saídas de transações não gastas (UTXO) podem ser gastos. Isso ocorre porque os scripts BTC não podem ler o conteúdo das transações em si, não conseguindo realizar introspeção nas transações. Se os scripts BTC pudessem verificar qualquer conteúdo da transação (incluindo as saídas), então poderiam implementar funcionalidades de contrato.

A implementação atual do contrato pode ser dividida em duas categorias:

• Pré-assinatura: Com base na capacidade existente do script BTC, constrói-se um contrato de reserva com funções limitadas através da pré-assinatura. Isso significa que os participantes precisam projetar e assinar antecipadamente todas as transações futuras possíveis, bloqueando-as em uma Chave privada específica e taxa de custódia. Alguns esquemas até exigem que os participantes gerem chaves privadas de curto prazo para todas as transações pré-assinadas. Uma vez concluída a pré-assinatura, essas chaves privadas de curto prazo são seguramente excluídas para evitar que atacantes obtenham e roubem os fundos. No entanto, esse processo precisa ser repetido sempre que um novo participante for adicionado ou uma operação for atualizada, resultando em altos custos de manutenção. Por exemplo, a Rede de iluminação implementa contratos bilaterais por meio de pré-assinatura e usa a tecnologia de Contrato de Bloqueio de Tempo com Hash (HTLC) para roteamento de vários contratos bilaterais, alcançando assim uma estratégia de escalonamento minimamente confiável. No entanto, a Rede de iluminação requer a pré-assinatura de várias transações e está limitada a dois participantes, o que torna seu uso tedioso; no BitVM1, a pré-assinatura de centenas de transações é necessária a cada inicialização, enquanto no BitVM2 otimizado, o número de transações a serem pré-assinadas a cada inicialização também chega a dezenas. No BitVM1 e no BitVM2, apenas os operadores envolvidos na pré-assinatura têm direito a reembolso. Se n participantes estiverem envolvidos na pré-assinatura, e cada participante precisar pré-assinar m transações, a complexidade de pré-assinatura de cada participante será n * m.
• Introdução de códigos de operação de contrato: A introdução de novos códigos de operação de funcionalidades de contrato pode reduzir significativamente a complexidade da comunicação entre os participantes do contrato Gota e os custos de manutenção, proporcionando assim ao Bitcoin uma forma mais flexível de implementação de contratos. Por exemplo, o código de operação OPCAT é utilizado para concatenar strings de bytes. Apesar da sua funcionalidade simples, é muito poderoso, capaz de reduzir significativamente a complexidade do BitVM da Gota; o código de operação OPTXHASH permite um controle mais detalhado das operações dentro do contrato. Se utilizado no BitVM, pode suportar uma gama maior de operações, melhorando significativamente a segurança do BitVM e minimizando a confiança. Além disso, o método de pré-assinatura implica essencialmente que os operadores no BitVM só podem seguir o processo de reembolso, o que resulta numa eficiência de utilização de capital mais baixa; e através de novos códigos de operação de contrato, é possível pagar diretamente aos utilizadores de output a partir do pool de fundos peg-in, melhorando ainda mais a eficiência de capital. Assim, o modelo flexível de contrato efetivamente ultrapassará as restrições tradicionais de pré-assinatura.

3 BTC Layer2 Escalação: prova de validade e prova de fraude

Tanto prova de validade como prova de fraude podem ser usadas na camada 2 de BTC, com suas principais diferenças mostradas na tabela 2.

Tabela 2: prova de validade e prova de fraude

Com base no compromisso Bit, Taproot, pré-assinado e saída do conector, é possível construir provas de fraude baseadas em BTC. Ao mesmo tempo, introduzindo opcodes de contrato (como OP_CAT), também é possível construir a prova de validade do BTC com base no Taproot. Além disso, a prova de fraude também pode ser dividida em prova de fraude licenciada e prova de fraude não licenciada, dependendo se Bob tem um sistema de fraude ou não. Em uma prova de fraude licenciada, apenas um grupo específico de pessoas pode contestar como um Bob, enquanto em uma prova de fraude sem permissão, qualquer terceiro pode contestar como um Bob. A segurança de uma prova de fraude não licenciada é melhor do que a de uma prova de fraude licenciada porque elimina o risco de conluio entre os participantes.

De acordo com o número de interações de desafio-resposta entre Alice e Bob, a prova de fraude pode ser dividida em prova de fraude de uma única rodada e prova de fraude de várias rodadas, como mostrado na Figura 2.

Figura 2: prova de fraude de uma única rodada e prova de fraude de várias rodadas

Conforme mostrado na Tabela 3, prova de fraude pode ser realizada por meio de diferentes modelos de interação, incluindo o modelo de interação de uma única rodada e o modelo de interação de várias rodadas.

Tabela 3: Interação de uma única rodada e interação de várias rodadas

No paradigma de expansão Layer2 do BTC, o BitVM1 utiliza um mecanismo de prova de fraude de várias rodadas, enquanto o BitVM2 utiliza um mecanismo de prova de fraude de uma única rodada, e o bitcoin-circle stark utiliza prova de validade. Entre esses mecanismos, o BitVM1 e o BitVM2 podem ser implementados sem modificar o protocolo BTC, enquanto o bitcoin-circle stark requer a introdução do novo Código de operação OP_CAT.

Para a maioria das tarefas de computação, a signet, testnet e mainnet do BTC não suportam completamente scripts de 4MB, portanto, é necessário usar a técnica de divisão de script, ou seja, dividir o script de computação completo em blocos menores que 4MB e distribuí-los em diferentes Tapleafs.

3.1 Bitcoin prova de fraude em várias rodadas

Como mostrado na Tabela 3, o prova de fraude de várias rodadas é adequado para aqueles que desejam reduzir o cálculo de arbitragem na cadeia, ou para situações em que não é possível localizar o segmento de cálculo do problema em uma etapa. Como o próprio nome sugere, o prova de fraude de várias rodadas requer interações de várias rodadas entre os validadores e os provadores para encontrar o segmento de cálculo do problema e, em seguida, arbitrar com base nesses segmentos.

O White Paper BitVM inicial de Robin Linus (geralmente referido como BitVM1) adotou várias provas de fraude. Supondo que cada período de desafio dure uma semana e que o método de pesquisa binária seja utilizado para localizar o segmento de cálculo problemático, o período de resposta ao desafio do verificador Groth16 na cadeia pode se estender a 30 semanas, resultando em um baixo desempenho. Embora atualmente existam equipes pesquisando métodos de pesquisa n-ária mais eficientes do que a pesquisa binária, sua eficácia ainda é significativamente menor do que o ciclo de duas semanas de prova de fraude em um único round.

Atualmente, o prova de fraude multi-turn em BTC usa desafios de permissão, enquanto o prova de fraude de um único turno implementou um método sem desafio de permissão, reduzindo assim o risco de conluio entre os participantes e reforçando a segurança. Para isso, Robin Linus aproveitou ao máximo as vantagens do Taproot para otimizar o BitVM1, reduzindo não apenas o número de turnos de interação para um, mas também expandindo o método de desafio para uma abordagem sem permissão, embora isso aumente o custo do cálculo de arbitragem na cadeia.

3.2 Bitcoin的一轮prova de fraude

Neste modelo, a validação da prova de fraude requer apenas uma interação entre o provador e os validadores. Os validadores só precisam lançar um desafio, enquanto o provador só precisa responder uma vez. Na resposta, o provador deve fornecer evidências de que o seu cálculo está correto. Se os validadores encontrarem alguma inconsistência nas evidências, o desafio é bem-sucedido; caso contrário, é falhado. As características da interação única da prova de fraude são mostradas na Tabela 3.

Figura 3: prova de fraude em uma única rodada

Em 15 de agosto de 2024, Robin Linus publicou o White Paper técnico ‘BitVM2: Conectando o BTC à Camada 2’, que implementa um método de prova de fraude de uma única rodada semelhante ao mostrado na Figura 3, usando pontes de cadeia cruzada.

3.3 Usando OP_CAT do BTCprova de validade

OP_CAT é parte da linguagem de script do BTC quando foi lançado, mas foi desativado em 2010 devido a uma vulnerabilidade de segurança. No entanto, a comunidade BTC tem discutido a possibilidade de reativar o OP_CAT ao longo dos anos. Atualmente, o OP_CAT foi designado como o número 347 e foi ativado na rede signet do BTC.

A função principal do OP_CAT é combinar dois elementos na pilha e empurrar o resultado de volta para a pilha. Isso abre novas possibilidades para contratos no BTC e validadores STARK.

• Contrato: Andrew Poelstra propôs CAT e Schnorr Tricks I, usando OP_CAT e a tecnologia Schnorr para implementar contratos em BTC. O Algoritmo Schnorr é uma Assinatura digital adequada para o tipo de saída P2TR; para outros tipos de saída, pode ser usado uma tecnologia semelhante ECDSA, como mostrado no contrato usando CAT e ECDSA. Com o contrato OP_CAT, o verificador de STARK Algoritmo pode ser decomposto em várias transações, verificando gradualmente toda a prova STARK.
• Verificador STARK: A principal função do verificador STARK é conectar os dados e fazer o hash deles. Ao contrário das operações algebraicas, o hash é uma operação nativa no script do BTC que pode reduzir significativamente os custos. Por exemplo, OPHSA256 é um opcode separado na forma nativa, enquanto na versão simulada requer centenas de opcodes. As principais operações de hash no STARK incluem a verificação de caminhos de Merkle e a transformação Fiat-Shamir. Portanto, OP_CAT é muito amigável para o verificador STARK Algoritmo.

3.4 BTC Splitting Script Technology

Apesar de a carga computacional necessária para prova de validação ser muito menor do que a carga de executar diretamente o cálculo original f após a prova SNARK/STARK, a quantidade de script necessária para implementar o Algoritmo verificador em scripts de BTC ainda é significativa. Atualmente, com base nos códigos de operação BTC existentes, o tamanho dos scripts otimizados de verificadores Groth16 e Fflonk ultrapassa os 2GB, enquanto o tamanho de um único Bloco BTC é apenas 4MB, portanto não é possível executar o script completo do verificador em um único Bloco. No entanto, desde a atualização do Taproot, o BTC suporta a execução de scripts através do tapleaf, permitindo que o script do verificador seja dividido em vários blocos, com cada bloco construindo uma taptree como um tapleaf. A consistência entre os blocos pode ser garantida por meio de compromissos de bits.

No caso do contrato OP_CAT, o validador STARK pode ser dividido em várias transações padrão menores que 400KB, permitindo que a verificação completa da prova de validade STARK seja concluída sem a necessidade de colaborar com mineiros.

Esta seção irá focar na técnica de divisão do script BTC sob condições existentes, sem introduzir ou ativar quaisquer novos códigos de operação.

Ao dividir scripts, é necessário equilibrar as informações dos seguintes aspectos:

• O tamanho do script de um único bloco não deve exceder 4MB e deve incluir scripts de compromisso de bits de entrada, assinaturas de transações e outros conteúdos.
• O tamanho máximo da pilha de um bloco único não deve exceder 1000. Portanto, a pilha de cada bloco deve reter apenas os elementos necessários para garantir que haja espaço suficiente na pilha para otimização do tamanho do script, porque a Lavagem de dinheiro do BTC não está relacionada ao tamanho da pilha.
• No BTC, o custo de compromisso é alto. Portanto, é melhor reduzir o número de bits de entrada e saída entre dois blocos adjacentes, atualmente 1 bit corresponde a 26 bytes.
• Para facilitar a auditoria, a funcionalidade de cada bloco deve ser o mais clara possível.

Atualmente, os métodos de divisão de script podem ser divididos nas seguintes três categorias:

• Auto-Split: This method seeks a way to split the script into a size of about 3MB, minimizing the stack size based on the stack size and script size, regardless of the specific validator algorithm. Its advantages include: (1) The entire logic block must be marked separately, such as code blocks OP_IF that cannot be split; otherwise, the execution result of the split script may be incorrect; (2) The execution result of the block may correspond to multiple elements on the stack, and the number of stack elements that need to apply the bit commitment needs to be marked according to the actual calculation logic; (3) The logical functionality of each block script is poor in readability and difficult to audit; (4) The stack may contain elements that are not needed for the next block, wasting stack space.
• Desagregação de Funcionalidades: Este método divide as funções do cálculo em subfunções funcionais, clarificando as entradas e saídas de cada subfunção. Simultaneamente à divisão do script, o script de compromisso de bits necessário é implementado para cada bloco, assegurando um tamanho total de script final de menos de 4 MB e uma pilha de menos de 1000. As vantagens são uma clareza de funcionalidade, lógica clara, legibilidade e facilidade de auditoria. Desvantagens incluem uma lógica de cálculo original que pode não corresponder à lógica de nível de script; que as subfunções originais podem ser as melhores, porém não necessariamente as melhores em termos de nível de script.
• Divisão manual: O ponto de divisão deste método não é baseado em subfunções de funcionalidade, mas configurado manualmente. Este método é especialmente adequado para situações em que o tamanho de uma única subfunção excede 4 MB. A vantagem é permitir a divisão manual de grandes subfunções de script, como as relacionadas ao cálculo Fq12; cada bloco tem lógica clara, alta legibilidade e é fácil de auditar. A desvantagem é que está limitado pela capacidade de ajuste manual e, após a otimização geral do script, os pontos de divisão manual previamente definidos podem não ser mais ideais e precisarão ser ajustados novamente.

Por exemplo, após várias otimizações, o tamanho do script do validador Groth16 foi reduzido de cerca de 7GB Gota para cerca de 1.26GB. Além da otimização geral de cálculos, cada bloco também pode ser otimizado individualmente para aproveitar ao máximo o espaço da pilha. Por exemplo, é possível reduzir ainda mais o tamanho do script de cada bloco introduzindo um algoritmo de tabela de pesquisa mais eficiente e carregando e descarregando a tabela de pesquisa dinamicamente.

Devido ao custo de computação e ambiente de execução das linguagens de programação Web2 serem completamente diferentes do script BTC, simplesmente converter a implementação existente do Algoritmo para o script BTC não é viável. Portanto, é necessário considerar otimizações específicas para o cenário BTC:

• Procurando por um Algoritmo que possa otimizar a localidade da memória, mesmo que isso possa aumentar a carga computacional, para reduzir o número de bits de entrada/saída entre os blocos, a fim de Gota BitVM2, o volume de dados necessário para comprometer a transação assertTx.
• Usar a comutatividade das operações relacionais (por exemplo, operações lógicas), como x&y = y&x, para economizar quase metade do espaço da tabela de pesquisa.
• Atualmente, o tamanho do script operado por Fq12 é grande; considerar a utilização dos esquemas Fiat-Shamir, Schwartz-Zipple e compromissos polinomiais para aumentar significativamente a complexidade computacional das operações Fq12 Gota.

4 Resumo

Este artigo discute as limitações do script BTC e discute várias soluções: usar promessas BTC para superar a restrição de estado sem UTXO, usar Taproot para superar a restrição de espaço de script, contornar a restrição do método de gastos UTXO conectando saídas, e solucionar a restrição de pré-assinatura por contrato. Em seguida, o artigo faz uma visão geral abrangente das características da prova de fraude e prova de validade, incluindo as características de prova de fraude com e sem licença, as diferenças entre prova de fraude de uma rodada e de várias rodadas, e o conteúdo relacionado à técnica de divisão de script BTC.

Declaração:

1. Este artigo é reproduzido a partir de [aicoin]，著作权归属原作者[mutourend & lynndell, Bitlayer Labs]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
2. Isenção de responsabilidade: As opiniões expressas neste artigo são apenas a opinião pessoal do autor e não constituem qualquer conselho de investimento.
3. As outras versões do artigo em idiomas diferentes são traduzidas pela equipe do Gate Learn. Não é permitido copiar, divulgar ou plagiar artigos traduzidos sem mencionar o Gate.io.