1 Introdução

Para um algoritmo f, dois participantes mutuamente desconfiados, Alice e Bob, podem estabelecer confiança das seguintes maneiras:

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, resultando em y'. Se y = y', então Bob reconhece a entrada fornecida por Alice x e a saída y. Isso é um mecanismo especial de prova de validade comumente usado no consenso blockchain, onde Alice é o nó que empacota o bloco e Bob é o nó que participa do consenso.
2. Alice insere x, executa o programa zk.prove no algoritmo f e obtém o resultado y e a prova de prova. Bob executa o programa zk.verify com base em f, y e prova. Se o resultado for verdadeiro, então Bob reconhece o resultado y de Alice; se o resultado for falso, então Bob não reconhece o resultado y de Alice. Esta é uma prova de validade, onde Bob pode ser um contrato on-chain.
3. 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, resultando em y'. Se y = y', então nada é feito; se y ≠ y', então Bob desafia Alice, com o programa desafiado sendo f. O número de interações entre Alice e Bob pode ser único ou múltiplo. A arbitragem é alcançada através do processo de desafio-resposta. Esta é uma prova de fraude, onde Bob é o desafiante, ouvindo off-chain e desafiando on-chain.
4. Alice insere x, executa o programa zk.prove no algoritmo f e obtém o resultado y e a prova à prova de fraude. Bob executa o programa zk.verify com base em f, y e prova. Se o resultado for verdadeiro, nada é feito; se o resultado for falso, então Bob desafia Alice, sendo o programa desafiado o zk.verify. O número de interações entre Alice e Bob pode ser único ou múltiplo. A arbitragem é alcançada por meio do processo de desafio e resposta. Isso é uma prova de fraude, onde Bob é o desafiante, ouvindo off-chain e desafiando on-chain.

Para os acima 2, 3 e 4, deixe x ser transações Camada2 e o estado inicial, f ser o programa de consenso Camada2 e y ser o estado final da transação, correspondendo à solução de escalonamento da Camada2 da blockchain. Entre eles:

• Prova de validade: Com base em uma suposição pessimista, deve ser comprovada a validade antes da aceitação, e ela entra em vigor imediatamente. Em uma prova de validade, deve-se fornecer evidências de transições de estado corretas da L2, refletindo uma visão pessimista do mundo — somente quando um estado for comprovado como correto, será aceito.
• Prova de Fraude: Com base em uma suposição otimista, é aceita por padrão, a menos que alguém prove que está incorreta. Ela possui um período de janela de desafio, que só entra em vigor após o período de janela de desafio. Em uma prova de fraude, evidências de transições de estado L2 incorretas devem ser fornecidas, refletindo uma visão otimista do mundo - uma transição de estado é assumida como correta, a menos que seja provado o contrário.

Tabela 1: Formas de Estabelecer Confiança

Além disso, é importante observar:

• A chave para distinguir entre provas de fraude e provas de validade não é se são usados sistemas de prova ZK como SNARK/STARK. O sistema de prova ZK expressa o método de prova usado, enquanto fraude ou validade representa o conteúdo que está sendo comprovado. É por isso que o cenário 1 na Tabela 1 é dito representar uma prova de validade.
• As provas de validade têm melhor pontualidade, mas a complexidade da verificação on-chain é relativamente alta; As provas de fraude têm menor complexidade de verificação on-chain, mas sua pontualidade é relativamente pobre.
• Para os casos 2 e 4 na Tabela 1, usando técnicas de recursão ZK e combinação, múltiplos f podem ser calculados e comprimidos, reduzindo significativamente o custo de verificação da computação off-chain na chain.

Atualmente, beneficiando-se dos contratos inteligentes Turing-completos do Solidity, as tecnologias à prova de fraude e prova de validade são amplamente utilizadas na escalabilidade da Camada 2 do Ethereum. No entanto, sob o paradigma do Bitcoin, limitado pela funcionalidade limitada do opcode do Bitcoin, 1000 elementos de pilha e outras restrições, a aplicação dessas tecnologias ainda está em estágio exploratório. Este artigo resume as limitações e tecnologias inovadoras sob o paradigma do Bitcoin no contexto da escalabilidade da Camada 2 do Bitcoin, estuda as tecnologias de prova de validade e prova de fraude, e esboça a tecnologia de segmentação de script única sob o paradigma do Bitcoin.

2 Limitações e Avanços sob o Paradigma do Bitcoin

Existem muitas limitações sob o paradigma do Bitcoin, mas vários métodos ou técnicas inteligentes podem ser usados para superar essas limitações. Por exemplo, o compromisso de bit pode quebrar a limitação sem estado do UTXO, o taproot pode quebrar as limitações do espaço de script, a saída do conector pode quebrar as limitações do método de gasto do UTXO e os contratos podem quebrar as limitações pré-assinatura.

2.1 Modelo UTXO e Limitações de Script

O Bitcoin adota o modelo UTXO, onde cada UTXO é bloqueado em um script de bloqueio que define as condições que devem ser atendidas para gastar aquele UTXO. Os scripts do Bitcoin têm as seguintes limitações:

1. Os scripts do Bitcoin são sem estado;
2. Para os tipos de saída P2TR, o número máximo de opcodes que podem ser acomodados em uma única transação é de cerca de 4 milhões, preenchendo o bloco inteiro, enquanto para outros tipos de saída, há apenas 10.000 opcodes;
3. Os métodos de gastos de um único UTXO são limitados, carecendo de exploração de métodos de gastos combinados;
4. Funções de contrato flexíveis não são suportadas;
5. O tamanho da pilha é limitado a um máximo de 1000 elementos (altstack + stack), e o tamanho máximo de um único elemento é de 520 bytes;
6. As operações aritméticas (como adição e subtração) são limitadas a elementos de 4 bytes. Eles não podem ser modificados para elementos longos, como 20 bytes ou maiores, que são necessários para operações criptográficas;
7. Opcodes como OPMUL e OPCAT foram desativados, e simulá-los com opcodes existentes incorre em custos extremamente altos, como simular uma hash BLAKE3 de uma rodada, com um tamanho de script de cerca de 75K.

2.2 Compromisso de Bit: Superando a Limitação de Estado UTXO

Atualmente, os scripts do Bitcoin são completamente sem estado. Ao executar um script do Bitcoin, seu ambiente de execução é redefinido após cada script. Isso leva à incapacidade dos scripts do Bitcoin de suportar nativamente os scripts de restrição 1 e 2 com o mesmo valor x. No entanto, essa questão pode ser contornada por meio de alguns métodos, com a ideia principal sendo assinar um valor de alguma forma. Se uma assinatura puder ser criada para um valor, é possível alcançar scripts do Bitcoin com estado. Ou seja, verificando a assinatura do valor x nos scripts 1 e 2, é possível garantir que o mesmo valor x seja usado em ambos os scripts. Se houver uma assinatura conflitante, ou seja, dois valores diferentes são assinados para a mesma variável x, uma penalidade pode ser aplicada. Essa solução é conhecida como compromisso de bit.

O princípio do compromisso de bit é relativamente simples. Um bit refere-se a definir dois valores de hash diferentes, hash0 e hash1, para cada bit na mensagem a ser assinada. Se o valor do bit a ser assinado for 0, a pré-imagem0 do hash0 é revelada; se o valor do bit a ser assinado for 1, a pré-imagem1 do hash1 é revelada.

Tomando uma mensagem de bit única m ∈{0,1} como exemplo, o script de desbloqueio de compromisso de bit correspondente são apenas algumas pré-imagens: se o valor do bit for 0, o script de desbloqueio correspondente é preimage0—“0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140”; se o valor do bit for 1, o script de desbloqueio correspondente é preimage1—“0x47c31e611a3bd2f3a7a42207613046703fa27496”. Portanto, com o compromisso de bit, é possível superar a limitação de estado sem estado do UTXO e alcançar scripts de Bitcoin com estado, tornando 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

Agora o valor do compromisso de bit está na pilha. Ou "0" ou "1".

Atualmente, existem 2 implementações de compromisso de bit:

• Lamport One-Time Signature: O princípio é relativamente simples e requer apenas o uso de funções de hash, tornando-o amigável ao Bitcoin. Para cada bit na mensagem, dois valores de hash precisam ser confirmados, resultando em dados de assinatura relativamente grandes. Em outras palavras, para uma mensagem de comprimento v bits, o comprimento da chave pública é 2v bits, e o comprimento da assinatura é v bits.
• Assinatura de Uma Vez de Winternitz: Comparada às assinaturas de Lamport, ela reduz significativamente o comprimento das assinaturas e chaves públicas, mas aumenta a complexidade da assinatura e verificação. Este esquema permite a configuração flexível de diferentes comprimentos de cadeia de hash d, equilibrando assim o comprimento e a complexidade. Por exemplo, definir d = 15 resulta em um comprimento de chave pública e assinatura cerca de 4 vezes menor, mas a complexidade de verificação aumentará em 4 vezes. Isso é essencialmente uma compensação entre o espaço de pilha e o tamanho do script do Bitcoin. As assinaturas de Lamport podem ser vistas como um caso especial de assinaturas de Winternitz quando d = 1.

Atualmente, a biblioteca BitVM2 implementa assinaturas Winternitz baseadas na função de hash Blake3. O comprimento da assinatura correspondente a um único bit é de cerca de 26 bytes. Portanto, pode-se ver que a introdução de estado por meio de compromisso de bit é custosa. Assim, na implementação do BitVM2, a mensagem é primeiro hashada para obter um valor de hash de 256 bits, e então o compromisso de bits é realizado no valor de hash para economizar custos, em vez de se comprometer com cada bit da mensagem original mais longa diretamente.

2.3 Taproot: Rompendo as limitações de espaço de script

O upgrade da bifurcação suave do Bitcoin Taproot, ativado em novembro de 2021, inclui três propostas: assinaturas Schnorr (BIP 340), Taproot (BIP 341) e TapScript (BIP 342). Ele introduz um novo tipo de transação - transações Pay-to-Taproot (P2TR). As transações P2TR podem criar um formato de transação mais privado, flexível e escalável, combinando as vantagens do Taproot, MAST (Merkel Abstract Syntax Tree) e assinaturas Schnorr.

O P2TR suporta dois métodos de gastos: gastos de acordo com o caminho chave ou o caminho do script.

De acordo com as disposições do Taproot (BIP 341), ao gastar através do caminho do script, o caminho Merkle correspondente não pode exceder um comprimento máximo de 128. Isto significa que o número de folhas de torneira na torneira não pode exceder 2^128. Desde a atualização do SegWit em 2017, a rede Bitcoin mede o tamanho do bloco em unidades de peso, com um suporte máximo de 4 milhões de unidades de peso (aproximadamente 4MB). Quando uma saída P2TR é gasta através do caminho do script, ela só precisa revelar um único script tapleaf, o que significa que o bloco é embalado com um único script tapleaf. Isso implica que, para transações P2TR, o tamanho do script correspondente a cada tapleaf pode ser de no máximo cerca de 4MB. No entanto, sob a política padrão do Bitcoin, muitos nós apenas encaminham transações menores que 400K; Transações maiores precisam colaborar com mineradores para serem empacotadas.

O prêmio de espaço de script trazido pelo Taproot torna mais valioso simular operações criptográficas como multiplicação e hash usando os opcodes existentes.

Ao construir computação verificável baseada em P2TR, o tamanho do script correspondente não está mais limitado à restrição de 4MB, mas pode ser dividido em várias subfunções distribuídas em vários tapleafs, assim quebrando a limitação de espaço de script de 4MB. Na verdade, o algoritmo verificador Groth16 implementado no BitVM2 atual tem um tamanho de até 2GB. No entanto, ele pode ser dividido e distribuído em cerca de 1000 tapleafs, e combinando-o com o comprometimento de bits, a consistência entre as entradas e saídas de cada subfunção pode ser restrita, garantindo a integridade e correção de toda a computação.

2.4 Conector de Saída: Superando as Limitações do Método de Gasto UTXO

Atualmente, o Bitcoin fornece dois métodos nativos de gasto para um único UTXO: gasto por script ou por chave pública. Portanto, desde que a assinatura correta da chave pública ou as condições do script sejam atendidas, o UTXO pode ser gasto. Dois UTXOs podem ser gastos independentemente, e nenhuma restrição pode ser adicionada para restringir os dois UTXOs, o que significa que condições adicionais devem ser atendidas para que sejam gastos.

No entanto, Burak, o fundador do protocolo Ark, utilizou habilmente a bandeira SIGHASH para alcançar a saída do conector. Especificamente, Alice pode criar uma assinatura para enviar seus BTC para Bob. No entanto, como a assinatura pode se comprometer com várias entradas, Alice pode definir sua assinatura como condicional: a assinatura é válida para a transação Taketx se e somente se essa transação consumir a segunda entrada. A segunda entrada é chamada de conector, vinculando UTXO A e UTXO B. Em outras palavras, a transação Taketx é válida se e somente se UTXO B não tiver sido gasto pela transação Challengetx. Portanto, destruindo a saída do conector, a eficácia da transação Taketx pode ser bloqueada.

Figura 1: Ilustração da Saída do Conector

No protocolo BitVM2, a saída do conector atua como um se... outra função. Uma vez que a saída do conector é gasta por uma transação, ela não pode ser gasta por outra transação para garantir seus gastos exclusivos. Na implantação prática, para permitir um período de desafio-resposta, UTXOs adicionais com bloqueio de tempo são introduzidos. Além disso, a saída do conector correspondente também pode ser definida com diferentes estratégias de gastos, conforme necessário, como permitir que qualquer parte gaste no caso de transações de desafio, permitindo que apenas o operador gaste ou permitindo que qualquer pessoa gaste após um tempo limite para transações de resposta.

2.5 Contratos: Superando as Limitações Pré-Assinatura

Atualmente, os scripts do Bitcoin limitam principalmente as condições para desbloqueio, sem restringir como o UTXO pode ser gasto posteriormente. Isso ocorre porque os scripts do Bitcoin não podem ler o conteúdo da transação em si, ou seja, eles não podem realizar a introspecção da transação. Se os scripts do Bitcoin pudessem verificar qualquer conteúdo da transação (incluindo as saídas), a funcionalidade do contrato poderia ser realizada.

As implementações de contrato atuais podem ser divididas em duas categorias:

• Pré-assinatura: Com base nos recursos de script Bitcoin existentes, os contratos pré-determinados de funcionalidade limitada são construídos por meio da pré-assinatura. Isso significa projetar e assinar todas as transações futuras possíveis com antecedência, prendendo os participantes em chaves privadas específicas e taxas de taxa. 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 excluídas com segurança, impedindo que invasores as obtenham e roubem fundos. No entanto, cada vez que um novo participante é adicionado ou uma operação é atualizada, o processo acima precisa ser repetido, levando a altos custos de manutenção. Por exemplo, a Lightning Network obtém contratos de duas partes por meio de pré-assinatura e usa a tecnologia HTLC (Hash Time-Locked Contracts) para implementar funções de roteamento para vários contratos de duas partes, alcançando assim uma estratégia de dimensionamento minimizada pela confiança. No entanto, a Lightning Network requer a pré-assinatura de várias transações e é limitada a duas partes, tornando-a um pouco complicada; no BitVM1, centenas de transações precisam ser pré-assinadas a cada inicialização, enquanto no BitVM2 otimizado, o número de transações que precisam ser pré-assinadas a cada inicialização também chega a dezenas. Tanto no BitVM1 quanto no BitVM2, apenas os operadores que participam da pré-assinatura são elegíveis para reembolso. Se n participantes estiverem envolvidos na pré-assinatura, e cada participante precisar pré-assinar m transações, a complexidade da pré-assinatura para cada participante será n * m.
• Apresentando Códigos de Operação de Contrato: A introdução de novos códigos de função de contrato pode reduzir significativamente a complexidade da comunicação e os custos de manutenção entre os participantes do contrato, introduzindo assim um método de implementação de contrato mais flexível para o Bitcoin. Por exemplo, OPCAT: usado para concatenar cadeias de bytes. Embora sua função seja muito simples, é muito poderoso e pode reduzir significativamente a complexidade do BitVM; OPTXHASH: permite um melhor controle granular de ações dentro do contrato. Se usado no BitVM, pode suportar um conjunto maior de operadores, melhorando assim as suposições de segurança do BitVM e minimizando a confiança. Além disso, o método de pré-assinatura significa que os operadores no BitVM só podem adotar um processo de reembolso, levando a uma menor eficiência de utilização de capital; enquanto através de novos códigos de contrato, pode ser possível pagar diretamente do pool de fundos peg-in para os usuários de saída, melhorando ainda mais a eficiência de capital. Portanto, um modelo de contrato flexível quebrará efetivamente as limitações tradicionais de pré-assinatura.

3 Bitcoin Camada 2 Scaling: Provas de Validade e Provas de Fraude

Tanto as provas de validade quanto as provas de fraude podem ser usadas para escala de Bitcoin L2, com as principais diferenças mostradas na Tabela 2.

Tabela 2: Provas de Validade vs. Provas de Fraude

Com base no compromisso de bits, taproot, pré-assinatura e saída do conector, podem ser construídas provas de fraude baseadas no Bitcoin. Com base no taproot, também podem ser construídas provas de validade baseadas no Bitcoin, introduzindo opcodes de contrato, como OP_CAT. Além disso, dependendo se Bob possui um sistema de admissão, as provas de fraude podem ser divididas em provas de fraude com permissão e provas de fraude sem permissão. Nas provas de fraude com permissão, apenas grupos específicos podem agir como Bob para iniciar desafios, enquanto nas provas de fraude sem permissão, qualquer terceiro pode agir como Bob para iniciar desafios. A segurança das provas de fraude sem permissão é superior à das provas com permissão, reduzindo o risco de conluio entre os participantes permitidos.

De acordo com o número de interações de desafio-resposta entre Alice e Bob, as provas de fraude podem ser divididas em provas de fraude de uma rodada e provas de fraude de várias rodadas, como mostrado na Figura 2.

Figura 2: Provas de fraude de uma rodada versus provas de fraude de várias rodadas

Conforme mostrado na Tabela 3, provas de fraude podem ser implementadas por meio de diferentes modelos de interação, incluindo modelos de interação de uma rodada e modelos de interação de várias rodadas.

Tabela 3: Interação de Uma Rodada vs. Interação de Múltiplas Rodadas

No paradigma de escala Layer2 do Bitcoin, o BitVM1 adota um mecanismo de prova de fraude de várias rodadas, enquanto o BitVM2 emprega um mecanismo de prova de fraude de uma rodada, e o bitcoin-circle stark utiliza provas de validade. Entre eles, o BitVM1 e o BitVM2 podem ser implementados sem fazer quaisquer modificações no protocolo Bitcoin, enquanto o bitcoin-circle stark requer a introdução de um novo opcode OP_CAT.

Para a maioria das tarefas computacionais, o signet, testnet e mainnet do Bitcoin não podem representar totalmente um script de 4MB, exigindo o uso da tecnologia de divisão de script - ou seja, dividir o script de cálculo completo em pedaços menores que 4MB, distribuídos em vários tapleafs.

3.1 Provas de Fraude de Múltiplas Rodadas no Bitcoin

Conforme mostrado na Tabela 3, as provas de fraude de várias rodadas são adequadas para cenários onde há o desejo de reduzir o cálculo de arbitragem on-chain e/ou onde não é possível identificar segmentos problemáticos de cálculo em um único passo. As provas de fraude de várias rodadas, como o nome sugere, requerem múltiplas rodadas de interação entre o comprovante e o verificador para localizar os segmentos problemáticos de cálculo, seguidos de arbitragem com base nos segmentos identificados.

O white paper inicial do BitVM de Robin Linus (comumente referido como BitVM1) utilizou provas de fraude com várias rodadas. Supondo que cada período de desafio dure uma semana e empregando um método de busca binária para localizar os segmentos problemáticos de computação, o período de resposta ao desafio na cadeia para o Verificador Groth16 poderia se estender até 30 semanas, resultando em baixa pontualidade. Embora atualmente existam equipes pesquisando métodos de busca n-ária mais eficientes do que a busca binária, sua pontualidade ainda é significativamente menor em comparação com o ciclo de 2 semanas em provas de fraude de uma rodada.

Atualmente, as provas de fraude de várias rodadas no paradigma do Bitcoin empregam desafios permitidos, enquanto as provas de fraude de uma rodada alcançaram um método de desafio sem permissão, reduzindo o risco de colusão entre os participantes e, assim, melhorando a segurança. Para isso, Robin Linus aproveitou totalmente as vantagens do Taproot para otimizar o BitVM1. Não apenas o número de rodadas de interação foi reduzido para uma, mas o método de desafio também foi expandido para uma abordagem sem permissão, embora ao custo de aumento na computação de arbitragem on-chain.

3.2 Provando Fraude em Uma Rodada no Bitcoin

Nesse modelo, a verificação de provas de fraude pode ser concluída por meio de uma única interação entre o provador e o verificador. O verificador só precisa iniciar um desafio, e o provador só precisa responder uma vez. Nessa resposta, o provador deve fornecer evidências que comprovem que seu cálculo está correto. Se o verificador encontrar inconsistências nessa evidência, o desafio é bem-sucedido; caso contrário, falha. As características das provas de fraude interativas de uma rodada são mostradas na Tabela 3.

Figura 3: Prova de Fraude de Uma Rodada

Em 15 de agosto de 2024, Robin Linus lançou o BitVM2: Documento técnico de ponte entre Bitcoin e Camadas 2, que implementou uma ponte cross-chain usando um método de prova de fraude de uma rodada semelhante ao mostrado na Figura 3.

3.3 Provas de validade em Bitcoin com OP_CAT

OPCAT fazia parte da linguagem de script original quando o Bitcoin foi lançado, mas foi desativado em 2010 devido a vulnerabilidades de segurança. No entanto, a comunidade do Bitcoin tem discutido sua reativação há anos. OPCAT agora foi atribuído o número 347 e foi habilitado no signet do Bitcoin.

A principal função do OP_CAT é combinar dois elementos na pilha e empurrar o resultado mesclado de volta para a pilha. Essa funcionalidade abre a possibilidade para contratos e verificadores STARK no Bitcoin:

• Contratos: Andrew Poelstra propôs o CAT e as técnicas Schnorr I, usando técnicas OPCAT e Schnorr para implementar contratos no Bitcoin. O algoritmo Schnorr é uma assinatura digital para tipos de saída P2TR; para outros tipos de saída, técnicas ECDSA semelhantes podem ser usadas, como visto em Convênios com CAT e ECDSA. Com a ajuda de contratos OPCAT, o algoritmo Verificador STARK pode ser dividido em várias transações, verificando gradualmente toda a prova STARK.
• STARK Verifier: O STARK Verifier essencialmente conecta dados e os hashes. Ao contrário das operações algébricas, o hashing é uma operação de script Bitcoin nativa que pode economizar uma quantidade significativa de sobrecarga. Por exemplo, OPSHA256 é um único opcode em sua forma nativa, enquanto uma versão simulada requer centenas de K opcodes. As principais operações de hashing no STARK envolvem a verificação de caminhos Merkle e transformações Fiat-Shamir. Portanto, o OPCAT é muito amigável ao algoritmo STARK Verifier.

3.4 Tecnologia de Divisão de Script Bitcoin

Embora a carga computacional necessária para executar o algoritmo verificador correspondente para verificar a prova após a prova SNARK/STARK seja muito menor do que a necessária para executar diretamente o cálculo original f, a quantidade de script necessária ao convertê-lo para implementar o algoritmo verificador no script do Bitcoin ainda é enorme. Atualmente, com base nos opcodes existentes do Bitcoin, o tamanho do script verificador otimizado Groth16 e o tamanho do script verificador Fflonk ainda são ambos maiores que 2GB. No entanto, o tamanho de um único bloco do Bitcoin é apenas 4MB, tornando impossível executar todo o script verificador dentro de um único bloco. No entanto, desde a atualização Taproot, o Bitcoin suporta a execução de scripts por meio de tapleaf, permitindo que o script verificador seja dividido em vários fragmentos, sendo que cada fragmento serve como um tapleaf para construir uma taptree. A consistência dos valores entre os fragmentos pode ser garantida por meio de comprometimento de bits.

Na presença de OP_CAT contratos, o STARK Verifier pode ser dividido em várias transações padrão menores que 400KB, permitindo que toda a verificação da prova de validade STARK seja concluída sem a necessidade de colaborar com mineradores.

Esta seção se concentra na tecnologia de divisão relevante de scripts Bitcoin sob as condições existentes, sem introduzir ou ativar novos opcodes.

Ao realizar a divisão de script, as seguintes dimensões de informação devem ser equilibradas:

• O tamanho de um único script de bloco não deve exceder 4 MB e deve incluir scripts de compromisso de bit de entrada, assinaturas de transação e outro espaço.
• O tamanho máximo da pilha de um único fragmento não deve exceder 1000. Portanto, a pilha de cada fragmento deve reter apenas os elementos necessários para reservar espaço suficiente na pilha para otimização do tamanho do script, pois as taxas de transação do Bitcoin não dependem do tamanho da pilha usada.
• O compromisso de bits no Bitcoin é caro. Portanto, o número de bits na entrada e saída entre dois chunks adjacentes deve ser minimizado, pois 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 scripts podem ser divididos nas seguintes três categorias principais:

• Divisão automática: Este método busca uma abordagem de divisão em que o tamanho do script é de cerca de 3MB e o tamanho da pilha é minimizado com base no tamanho da pilha e no tamanho do script. As vantagens deste método são que ele é independente de algoritmos verificadores específicos e pode ser estendido para divisão de scripts para qualquer computação. As desvantagens são: (1) todo o bloco lógico deve ser marcado separadamente, como OP_IF blocos de código que não podem ser divididos; caso contrário, o resultado da execução do script dividido será incorreto; (2) o resultado de execução de um bloco pode corresponder a vários elementos na pilha, exigindo a marcação do número de elementos da pilha que precisam aplicar o compromisso de bits com base na lógica de computação real; (3) a legibilidade da funcionalidade lógica implementada por cada script de bloco é pobre, dificultando a auditoria; (4) A pilha pode conter elementos não necessários para o próximo bloco, desperdiçando espaço na pilha.
• Divisão Funcional: Este método se divide com base em várias subfunções funcionais no cálculo, com valores de entrada e saída claros para as subfunções. Ao dividir o script, também implementa os scripts de compromisso de bits necessários para cada pedaço, garantindo que o tamanho total do script dos pedaços finais seja inferior a 4MB e o tamanho da pilha seja inferior a 1000. As vantagens são: funcionalidade clara, lógica clara para cada pedaço, boa legibilidade e facilidade de auditoria. As desvantagens são: a expressão da lógica original do cálculo pode não corresponder à lógica do nível do script, e as subfunções originais do cálculo podem ser ótimas, mas não representam a otimalidade do nível do script.
• Divisão Manual: Neste método, os pontos de divisão não são baseados em subfunções funcionais, mas são definidos manualmente. Isso é especialmente adequado para casos em que o tamanho de uma única subfunção excede 4MB. As vantagens são: permite a divisão manual de subfunções pesadas de tamanho de script, como aquelas relacionadas aos cálculos Fq12; lógica clara para cada parte, boa legibilidade e facilidade de auditoria. As desvantagens são: limitado pelas capacidades de ajuste manual, quando o script geral foi otimizado, os pontos de divisão manual previamente definidos podem não ser ótimos e precisam ser reajustados.

Por exemplo, após várias rodadas de otimização, o tamanho do script do verificador Groth16 foi reduzido de cerca de 7GB para aproximadamente 1.26GB. Além dessa otimização computacional geral, cada fragmento também pode ser otimizado individualmente para aproveitar totalmente o espaço de pilha. Por exemplo, ao introduzir algoritmos baseados em tabelas de pesquisa melhores e carregar e descarregar dinamicamente a tabela de pesquisa, o tamanho do script de cada fragmento pode ser ainda mais reduzido.

Os custos computacionais e os ambientes de tempo de execução das linguagens de programação web2 são completamente diferentes daqueles dos scripts do Bitcoin, portanto, simplesmente traduzir implementações existentes para vários algoritmos em scripts do Bitcoin não é viável. Portanto, otimizações específicas para o cenário do Bitcoin precisam ser consideradas:

• Procure algoritmos que otimizem a localidade da memória, mesmo que isso custe algum carga computacional, para reduzir o número de bits de entrada/saída entre os blocos, diminuindo assim a quantidade de dados necessária para os compromissos no design da transação assertTx do BitVM2.
• Utilize a comutatividade das operações relacionadas (por exemplo, operações lógicas), como x&y = y&x, para economizar quase metade da tabela de pesquisa.
• Atualmente, o tamanho do script correspondente às operações Fq12 é grande; considere alavancar os esquemas Fiat-Shamir, Schwartz-Zipple e de compromisso polinomial para reduzir significativamente a complexidade computacional das operações de extensão Fq12.

4 Resumo

Este artigo primeiro apresenta as limitações dos scripts do Bitcoin e discute o uso de compromissos do Bitcoin para superar a limitação do estado sem UTXO, usar o Taproot para superar as limitações do espaço do script, usar saídas do conector para contornar as restrições do método de gasto do UTXO e usar contratos para superar as limitações de pré-assinatura. Em seguida, fornece uma visão geral abrangente e um resumo das características das provas de fraude e das provas de validade, as características das provas de fraude com permissão e sem permissão, as distinções entre provas de fraude de uma rodada e multirodadas, e a tecnologia de divisão de script do Bitcoin.

Aviso Legal:

1. Este artigo é reproduzido a partir de [AICOIN]. Todos os direitos autorais pertencem ao autor original [ mutourend & lynndell, Bitlayer Labs]. Se houver objeções a esta reprodução, entre em contato com oGate Learnequipe, e eles lidarão com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.