1 Introdução

Para um algoritmo f, dois participantes mutuamente desconfiados, Alice e Bob, podem estabelecer confiança da seguinte forma:

1. Alice introduz 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 introduz x, executa o programa zk.prove no algoritmo f e obtém o resultado y e a prova 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 introduz 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. Este é um 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 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, com o programa desafiado sendo 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. Esta é uma prova de fraude, onde Bob é o desafiante, ouvindo off-chain e desafiando on-chain.

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

• Prova de validade: Com base numa suposição pessimista, deve ser comprovada a validade antes da aceitação e entra em vigor imediatamente. Numa prova de validade, deve ser fornecida evidência de transições de estado corretas da Camada 2, refletindo uma visão pessimista do mundo - apenas quando um estado for comprovado como correto é que será aceite.
• Prova de Fraude: Com base numa suposição otimista, é aceite por defeito a menos que alguém prove que está incorreta. Tem um período de janela de desafio, que só tem efeito após o período de janela de desafio. Numa prova de fraude, deve ser fornecida evidência de transições de estado L2 incorretas, 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 notar:

• 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 a ser provado. É por isso que o cenário 1 na Tabela 1 é considerado uma prova de validade.
• As provas de validade têm melhor pontualidade, mas a complexidade de verificação on-chain é relativamente alta; as provas de fraude têm uma complexidade de verificação on-chain mais baixa, mas a sua pontualidade é relativamente fraca.
• Para os casos 2 e 4 na Tabela 1, usando técnicas de recursão e combinação ZK, múltiplos f podem ser calculados e comprimidos, reduzindo significativamente o custo de verificação da computação off-chain on-chain.

Atualmente, beneficiando-se dos contratos inteligentes Turing-completos do Solidity, as tecnologias de prova de fraude e prova de validade são amplamente utilizadas na camada 2 do Ethereum para escalonamento. 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 de avanço 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 única de segmentação de script sob o paradigma do Bitcoin.

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

Existem muitas limitações no 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 bits pode superar a limitação estatal do UTXO, o taproot pode superar as limitações do espaço de script, a saída do conector pode superar as limitações do método de gasto do UTXO e os contratos podem superar 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 esse 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 numa única transação é cerca de 4 milhões, preenchendo o bloco inteiro, enquanto para outros tipos de saída, existem apenas 10.000 opcodes;
3. Os métodos de gastos de um único UTXO são limitados, faltando exploração de métodos de gastos combinados;
4. As 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 um hash BLAKE3 de uma rodada, com um tamanho de script de cerca de 75K.

2.2 Compromisso Bit: Rompendo com a Limitação Sem Estado UTXO

Atualmente, os scripts do Bitcoin são completamente sem estado. Ao executar um script do Bitcoin, seu ambiente de execução é reiniciado após cada script. Isso leva à incapacidade dos scripts do Bitcoin de suportar nativamente scripts de restrição 1 e 2 tendo o mesmo valor x. No entanto, esse problema pode ser contornado 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 forem 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 à definição de 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, é revelada a preimagem0 de hash0; se o valor do bit a ser assinado for 1, é revelada a preimagem1 de hash1.

Tomando uma mensagem de bit única m ∈{0,1} como exemplo, o script de desbloqueio de compromisso de bit correspondente são apenas algumas preimagens: 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 sem estado do UTXO e alcançar scripts Bitcoin com estado, tornando possíveis várias novas funcionalidades interessantes.

OP_HASH160

OP_DUP

0xf592e757267b7f307324f1e78b34472f8b6f46f3> // Isto é hash1

OP_EQUAL

OP_DUP

OP_ROT

0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // Este é o hash0

OP_EQUAL

OP_BOOLOR

OP_VERIFY

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

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

• Assinatura de Uma Vez Lamport: O princípio é relativamente simples e requer apenas o uso de funções de hash, tornando-o adequado ao Bitcoin. Para cada bit na mensagem, são necessários dois valores de hash a serem comprometidos, resultando em dados de assinatura relativamente grandes. Em outras palavras, para uma mensagem de comprimento v bits, o comprimento da chave pública é de 2v bits e o comprimento da assinatura é de v bits.
• Assinatura de uma só vez Winternitz: Em comparação com as assinaturas Lamport, 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 tanto no comprimento da chave pública quanto no comprimento da assinatura sendo cerca de 4 vezes mais curto, mas a complexidade de verificação aumentará 4 vezes. Isso é essencialmente uma compensação entre o espaço de pilha e o tamanho do script do Bitcoin. As assinaturas Lamport podem ser vistas como um caso especial das assinaturas Winternitz quando d = 1.

Atualmente, a biblioteca BitVM2 implementa assinaturas Winternitz baseadas na função 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 hasheada para obter um valor de hash de 256 bits e, em seguida, o compromisso de bit é realizado no valor de hash para economizar overhead, em vez de se comprometer com cada bit da mensagem original mais longa diretamente.

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

A atualização do soft fork Bitcoin Taproot, ativada 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 das assinaturas Taproot, MAST (Merkel Abstract Syntax Tree) e Schnorr.

P2TR suporta dois métodos de gastos: gastar de acordo com o caminho da 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 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, ele 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 no máximo de cerca de 4MB. No entanto, sob a política padrão do Bitcoin, muitos nós só 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 hashing usando 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, quebrando assim 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 ao combiná-lo com o compromisso de bits, a consistência entre as entradas e saídas de cada subfunção pode ser limitada, garantindo a integridade e correção de toda a computação.

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

Atualmente, o Bitcoin fornece dois métodos nativos de gasto para uma única 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, a UTXO pode ser gasta. Duas UTXOs podem ser gastas independentemente e não há restrições que possam ser adicionadas para restringir as duas UTXOs, ou seja, condições adicionais devem ser atendidas para que elas sejam gastas.

No entanto, Burak, o fundador do protocolo Ark, utilizou de forma inteligente a flag 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, ligando UTXO A e UTXO B. Em outras palavras, a transação Taketx é válida se e somente se UTXO B não foi gasto pelo 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 if... 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 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 própria transação, o que significa que eles não podem realizar introspecção de transações. Se os scripts do Bitcoin pudessem verificar qualquer conteúdo da transação (incluindo 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, contratos pré-determinados de funcionalidade limitada são construídos por meio de pré-assinatura. Isso significa projetar e assinar todas as possíveis transações futuras com antecedência, bloqueando os participantes em chaves privadas e taxas específicas. Alguns esquemas até exigem que os participantes gerem chaves privadas de curto prazo para todas as transações pré-assinadas. Quando a pré-assinatura estiver concluída, 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 alcança contratos de duas partes por meio de pré-assinatura e usa a tecnologia Hash Time-Locked Contracts (HTLC) para implementar funções de roteamento para vários contratos de duas partes, alcançando assim uma estratégia de escalonamento 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 em cada inicialização, enquanto no BitVM2 otimizado, o número de transações que precisam ser pré-assinadas em cada inicialização também atinge dezenas. Tanto no BitVM1 como no BitVM2, apenas os operadores que participam na pré-assinatura são elegíveis para reembolso. Se n participantes estiverem envolvidos na pré-assinatura e cada participante precisar pré-assinar transações m, a complexidade da pré-assinatura para cada participante será n * m.
• Introdução de Opcodes de Contrato: A introdução de novos opcodes de função de contrato pode reduzir significativamente a complexidade de 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 Bitcoin. Por exemplo, OPCAT: usado para concatenar cadeias de caracteres de byte. Embora sua função seja muito simples, é muito poderoso e pode reduzir significativamente a complexidade do BitVM; OPTXHASH: permite um melhor controle granular das ações dentro do contrato. Se usado no BitVM, ele pode suportar um conjunto maior de operadores, melhorando assim muito as suposições de segurança do BitVM e minimizando a confiança. Além disso, o método de pré-assinatura significa inerentemente que os operadores no BitVM só podem adotar um processo de reembolso, levando a uma menor eficiência de utilização de capital; ao passo que, através de novos opcodes contratuais, poderá ser possível pagar diretamente a partir do fundo de indexação aos utilizadores de resultados, melhorando ainda mais a eficiência do capital. Portanto, um modelo de contrato flexível romperá 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 como as provas de fraude podem ser usadas para a escalabilidade da Camada 2 do Bitcoin, com as principais diferenças mostradas na Tabela 2.

Tabela 2: Provas de Validade vs. Provas de Fraude

Com base no compromisso de bit, taproot, pré-assinatura e saída do conector, podem ser construídas provas de fraude baseadas em Bitcoin. Com base no taproot, também podem ser construídas provas de validade baseadas em Bitcoin ao introduzir códigos de operação de contrato, como o OP_CAT. Além disso, dependendo se Bob tem 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. Em provas de fraude com permissão, apenas grupos específicos podem atuar como Bob para iniciar desafios, enquanto em provas de fraude sem permissão, qualquer terceiro pode atuar como Bob para iniciar desafios. A segurança das provas de fraude sem permissão é superior à das com permissão, reduzindo o risco de colusão 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 vs. Provas de Fraude de Múltiplas Rodadas

Como mostrado na Tabela 3, as provas de fraude podem ser implementadas através 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: Interacção de uma ronda vs. Interacção de várias rondas

No paradigma de escalonamento da Camada 2 do Bitcoin, o BitVM1 adota um mecanismo de prova de fraude de várias etapas, enquanto o BitVM2 utiliza um mecanismo de prova de fraude de uma etapa, e o bitcoin-circle stark utiliza provas de validade. Entre esses, o BitVM1 e o BitVM2 podem ser implementados sem fazer quaisquer modificações no protocolo do 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 completamente um script de 4MB, o que torna necessário o uso da tecnologia de divisão de script - ou seja, dividir o script de computação completo em partes menores que 4MB, distribuídas em vários tapleafs.

3.1 Provas de Fraude de Várias Etapas no Bitcoin

Como mostrado na Tabela 3, as provas de fraude em várias rodadas são adequadas para cenários em que há um desejo de reduzir o cálculo de arbitragem on-chain e/ou onde não é possível identificar segmentos de computação problemáticos em uma etapa. As provas de fraude multiround, como o nome sugere, exigem várias rodadas de interação entre o provador e o verificador para localizar os segmentos de computação problemáticos, seguidas de arbitragem com base nos segmentos identificados.

O white paper BitVM inicial de Robin Linus (comumente referido como BitVM1) utilizou provas de fraude de várias rodadas. Supondo que cada período de desafio dure uma semana e usando um método de busca binária para localizar os segmentos de computação problemáticos, o período de resposta ao desafio on-chain para o Verificador Groth16 pode se estender por até 30 semanas, resultando em baixa pontualidade. Embora atualmente haja equipes pesquisando métodos de busca n-ários 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 com permissão, 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, aumentando 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 uma maior computação de arbitragem on-chain.

3.2 Provas de Fraude de Uma Rodada no Bitcoin

Neste modelo, a verificação de provas de fraude pode ser concluída através 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 afirmando que sua computação está correta. Se o verificador encontrar inconsistências nessas evidências, o desafio é bem-sucedido; caso contrário, falhará. 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 Secundárias, 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 no 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 Bitcoin tem discutido sua reativação há anos. OPCAT agora foi atribuído o número 347 e foi ativado no signet do Bitcoin.

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

• Contratos: Andrew Poelstra propôs CAT e Schnorr Tricks I, utilizando 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 Verificador STARK essencialmente conecta os dados e os hash. Ao contrário das operações algébricas, o hash é 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 opcodes K. As principais operações de hash em STARK envolvem a verificação de caminhos de Merkle e transformações Fiat-Shamir. Portanto, OPCAT é muito amigável para o algoritmo Verificador STARK.

3.4 Tecnologia de Divisão do 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 em um único bloco. No entanto, desde a atualização do Taproot, o Bitcoin suporta a execução de scripts por meio do tapleaf, permitindo que o script verificador seja dividido em vários chunks, sendo cada chunk um tapleaf para construir uma taptree. A consistência dos valores entre os chunks pode ser garantida por meio do compromisso de bits.

Na presença de contratos OP_CAT, o Verificador 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 colaboração com os mineradores.

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

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

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

• Divisão Automática: Este método procura uma abordagem de divisão onde 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 é independente de algoritmos verificadores específicos e pode ser estendido para divisão de script para qualquer cálculo. As desvantagens são: (1) o bloco lógico inteiro deve ser marcado separadamente, como blocos de código OP_IF que não podem ser divididos; caso contrário, o resultado da execução do script dividido será incorreto; (2) o resultado da execução de um fragmento pode corresponder a vários elementos na pilha, exigindo marcação do número de elementos da pilha que precisam aplicar compromisso de bits com base na lógica de cálculo real; (3) a legibilidade da funcionalidade lógica implementada por cada script de fragmento é baixa, dificultando a auditoria; (4) a pilha pode conter elementos desnecessários para o próximo fragmento, desperdiçando espaço na pilha.
• Divisão Funcional: Este método divide com base em várias subfunções funcionais na computação, com valores claros de entrada e saída 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 4 MB 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 de computação original pode não corresponder à lógica de nível de script e as subfunções de computação originais podem ser ótimas, mas não representar a otimização de nível de 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. Isto é especialmente adequado para casos em que um único tamanho de subfunção excede 4MB. As vantagens são: permite a divisão manual de subfunções de tamanho de script pesado, como as relacionadas aos cálculos Fq12; lógica clara para cada parte, boa legibilidade e facilidade de auditoria. As desvantagens são: limitadas pelas capacidades de ajuste manual, quando o script geral foi otimizado, os pontos de divisão manuais previamente definidos podem não ser ideais 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 bloco também pode ser otimizado individualmente para utilizar totalmente o espaço de pilha. Por exemplo, introduzindo algoritmos baseados em tabelas de pesquisa melhores e carregando e descarregando dinamicamente a tabela de pesquisa, o tamanho do script de cada bloco 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 dos das scripts Bitcoin, por isso, simplesmente traduzir as implementações existentes para vários algoritmos em scripts Bitcoin não é viável. Portanto, as otimizações específicas para o cenário Bitcoin precisam ser consideradas:

• Procure algoritmos que otimizem a localidade da memória, mesmo que isso aumente a carga computacional, para reduzir o número de bits de entrada/saída entre os blocos, diminuindo assim a quantidade de dados necessários para os compromissos no design de transação assertTx do BitVM2.
• Utilize a comutatividade de operações relacionadas (por exemplo, operações lógicas), como x&y = y&x, para salvar quase metade da tabela de pesquisa.
• Atualmente, o tamanho do script correspondente às operações Fq12 é grande; considere utilizar 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 Bitcoin e discute o uso de compromissos Bitcoin para superar a limitação sem estado UTXO, usando Taproot para quebrar as limitações de espaço de script, usando saídas de conector para contornar as restrições do método de gastos UTXO e usando contratos para superar limitações de pré-assinatura. Em seguida, fornece uma visão geral abrangente e um resumo das características das provas de fraude e provas de validade, as características das provas de fraude permitidas e sem permissão, as distinções entre provas de fraude de uma rodada e várias rodadas e a tecnologia de divisão de script 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 reimpressão, contacte o Gate Learnequipa e eles tratarão disso prontamente.
2. Aviso de responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipa Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.