Bitcoin é um ativo digital descentralizado, seguro e confiável. No entanto, possui limitações significativas que a impedem de se tornar uma rede escalável para pagamentos e outras aplicações. A questão da escala do Bitcoin tem sido uma preocupação desde o seu início. O modelo Bitcoin UTXO trata cada transação como um evento independente, resultando em um sistema sem estado que não possui a capacidade de realizar cálculos complexos e dependentes do estado. Portanto, embora o Bitcoin possa executar scripts simples e transações com múltiplas assinaturas, ele tem dificuldade em facilitar as interações contratuais complexas e dinâmicas comuns em plataformas de blockchain com estado. Esta questão limita significativamente o âmbito de aplicações descentralizadas (dApps) e instrumentos financeiros complexos que podem ser construídos em Bitcoin, enquanto as plataformas de modelo estatal fornecem um ambiente mais diversificado para a implementação e execução de contratos inteligentes ricos em funcionalidades.
Para a expansão do Bitcoin, existem principalmente tecnologias como canais estaduais, cadeias laterais e verificação de clientes. Entre eles, os canais estatais fornecem soluções de pagamento seguras e diversas, mas são limitados na sua capacidade de verificar cálculos arbitrariamente complexos. Essa limitação reduz seu uso em uma variedade de cenários que exigem lógica e interações complexas e condicionais. Sidechains, embora suportem uma ampla gama de aplicações e forneçam uma diversidade de funcionalidades além do Bitcoin, têm menor segurança. Esta diferença na segurança decorre do facto de as cadeias laterais utilizarem mecanismos de consenso independentes, que são muito menos robustos do que o mecanismo de consenso do Bitcoin. A verificação do lado do cliente, usando o modelo Bitcoin UTXO, pode lidar com transações mais complexas, mas não possui a capacidade de restrição de soma de verificação bidirecional com o Bitcoin, tornando sua segurança inferior à do Bitcoin. O design off-chain dos protocolos de verificação de cliente depende de infraestrutura de servidor ou nuvem, o que pode levar à centralização ou potencial censura por meio de servidores comprometidos. O design fora da cadeia de validação do lado do cliente também introduz mais complexidade na infraestrutura blockchain, potencialmente levando a problemas de escalabilidade.
Em dezembro de 2023, o líder do projeto ZeroSync, Robin Linus, publicou um white paper chamado "BitVM: Compute Anything On Bitcoin", que desencadeou o pensamento de todos sobre como melhorar a programabilidade do Bitcoin. Este artigo propõe uma solução de contrato Bitcoin que pode atingir a completude de Turing sem alterar o consenso da rede Bitcoin, de modo que qualquer cálculo complexo possa ser verificado no Bitcoin sem alterar as regras básicas do Bitcoin. BitVM faz uso total de Bitcoin Script e Taproot para obter um rollup otimista. Com base na assinatura Lamport (também conhecida como compromisso de bit), uma conexão é estabelecida entre dois Bitcoin UTXOs para implementar scripts Bitcoin com estado. Ao se comprometerem com um grande programa em um endereço Taproot, os operadores e validadores se envolvem em extensas interações fora da cadeia, resultando em uma pequena presença na cadeia. Se ambas as partes cooperarem, cálculos off-chain arbitrariamente complexos e com estado podem ser realizados sem deixar qualquer rastro na cadeia. Se ambas as partes não cooperarem, quando ocorrer uma disputa, será necessária a execução em cadeia. Como resultado, o BitVM amplia enormemente os casos de uso potenciais do Bitcoin, permitindo que o Bitcoin sirva não apenas como moeda, mas também como plataforma de verificação para uma variedade de aplicações descentralizadas e tarefas computacionais complexas.
Porém, embora a tecnologia BitVM tenha grandes vantagens na expansão do Bitcoin, ela ainda está em seus estágios iniciais e ainda existem alguns problemas em termos de eficiência e segurança. Por exemplo: (1) Desafios e respostas exigem múltiplas interações, resultando em taxas de manuseio caras e longos ciclos de desafio; (2) Os dados de assinatura única de Lamport são longos e o comprimento dos dados precisa ser reduzido; (3) A função hash é complexo e requer função hash compatível com Bitcoin para reduzir custos; (4) O contrato BitVM existente é enorme e a capacidade de bloco Bitcoin é limitada. Menos s podem ser usados para implementar menos s BitVM, economizando espaço de bloco Bitcoin e melhorando a eficiência do BitVM; (5 ) O BitVM existente adota um modelo de permissão. Somente os membros da aliança podem iniciar desafios e é limitado a apenas duas partes. Deve ser estendido a um modelo de desafio multipartidário sem permissão para reduzir ainda mais a suposição de confiança. Para tanto, este artigo propõe algumas ideias de otimização para melhorar ainda mais a eficiência e segurança do BitVM.
2.Princípio BitVM
BitVM está posicionado como um contrato off-chain de Bitcoin e está comprometido em promover as funções de contrato de Bitcoin. Atualmente os scripts Bitcoin são completamente sem estado, portanto, quando um script Bitcoin é executado, seu ambiente de execução é redefinido após cada script. Não existe uma maneira nativa de o script 1 e o script 2 terem o mesmo valor x, e o Bitcoin Script não oferece suporte nativo para isso. No entanto, você ainda pode usar opcodes existentes para tornar o script Bitcoin com estado por meio da assinatura única de Lamport. Por exemplo, você pode forçar x em 1 e 2 a ter o mesmo valor. Os participantes podem ser penalizados se assinarem valores x conflitantes. Os cálculos do programa BitVM ocorrem fora da cadeia, enquanto a verificação dos resultados dos cálculos ocorre na cadeia. O bloco Bitcoin atual tem um limite de 1 MB. Quando o cálculo de verificação é muito complexo, a tecnologia OP pode ser usada para adotar o modo de resposta ao desafio para suportar verificação de cálculo de maior complexidade.
Semelhante ao Optimistic Rollup e à proposta MATT (Merkelize All The Things), o sistema BitVM é baseado em protocolos à prova de fraude e resposta a desafios, mas não requer modificação das regras de consenso do Bitcoin. As primitivas subjacentes do BitVM são simples, baseadas principalmente em bloqueios de hash, bloqueios de tempo e grandes árvores Taproot.
O provador confirma byte por byte, mas verificar todos os cálculos na cadeia seria muito caro. Assim, o verificador realiza uma série de desafios cuidadosamente elaborados para refutar sucintamente as falsas afirmações do provador. Provadores e validadores pré-assinam conjuntamente uma série de transações de desafio e resposta que são usadas para resolver disputas, permitindo a verificação computacional universal no Bitcoin.
Os principais componentes do BitVM são:
Compromissos de circuito: Provadores e verificadores compilam programas em grandes circuitos binários. O provador confirma o circuito em um endereço Taproot, e cada script folha sob esse endereço corresponde a cada porta lógica no circuito. O núcleo é baseado no comprometimento de bits para implementar o comprometimento da porta lógica e do circuito.
Desafio e Resposta: Provadores e verificadores pré-assinam uma série de transações para implementar o jogo de desafio-resposta. Idealmente, esta interação é realizada fora da cadeia, mas também pode ser realizada na cadeia quando o provador não coopera.
Penalidade Ambígua: Se o provador fizer qualquer declaração incorreta, o verificador pode retirar o depósito do provador após desafiá-lo com sucesso para impedir o mau comportamento do provador.
3.Otimização BitVM
3.1 Reduza o número de interações de OP com base em ZK
Existem atualmente 2 Rollups principais: ZK Rollups e OP Rollups. Dentre eles, o ZK Rollups conta com a verificação de validade do ZK Proof, ou seja, a prova criptográfica de execução correta, e sua segurança depende da suposição de complexidade computacional; o OP Rollups conta com o Fraud Proof, assumindo que os estados submetidos estão corretos, configurando O período de contestação é geralmente de 7 dias e sua segurança pressupõe que pelo menos uma parte honesta no sistema possa detectar o estado incorreto e enviar uma prova de fraude. Suponha que o número máximo de etapas do programa de desafio BitVM seja 2 ^{ 32 } e a memória necessária seja 2 ^{ 32 }* 4 bytes, o que equivale a cerca de 17 GB. Na pior das hipóteses, são necessárias cerca de 40 rodadas de desafio e resposta, cerca de meio ano, e o script total é de cerca de 150 KB. Há uma grave falta de incentivos nesta situação, mas isso quase nunca acontece na prática.
Considere o uso de provas de conhecimento zero para reduzir o número de desafios do BitVM, melhorando assim a eficiência do BitVM. De acordo com a teoria da prova de conhecimento zero, se os dados Data satisfazem o algoritmo F, fica provado que a prova satisfaz o algoritmo de verificação Verify, ou seja, o algoritmo de verificação gera True; se os dados Data não satisfazem o algoritmo F, fica provado que a prova não satisfaz o algoritmo de verificação Verify, ou seja, o algoritmo de verificação gera False . No sistema BitVM, caso o desafiante não reconheça os dados enviados pelo provador, um desafio é iniciado.
Para o algoritmo F, use o método de dicotomia para dividi-lo. Suponha que leva 2 ^ n vezes para encontrar o ponto de erro; se a complexidade do algoritmo for muito alta, n será grande e levará muito tempo para ser concluído. No entanto, a complexidade do algoritmo de verificação Verify da prova de conhecimento zero é fixa. Todo o processo de prova e algoritmo de verificação Verify é público e a saída é considerada falsa. A vantagem da prova de conhecimento zero é que a complexidade computacional necessária para abrir o algoritmo de verificação Verify é muito menor do que o método binário para abrir o algoritmo original F. Portanto, com a ajuda da prova de conhecimento zero, o BitVM não está mais desafiando o algoritmo F original, mas o algoritmo de verificação Verify, reduzindo o número de rodadas de desafio e encurtando o ciclo de desafio.
Finalmente, embora a eficácia da prova de conhecimento zero e da prova de fraude dependa de diferentes premissas de segurança, elas podem ser combinadas para construir a Prova de Fraude ZK e realizar a Prova ZK sob Demanda. Ao contrário do ZK Rollup completo, que não precisa mais gerar prova ZK para cada transição de estado, o modelo sob demanda torna a prova ZK necessária apenas quando há desafios, enquanto todo o design do Rollup ainda é otimista. Portanto, o estado resultante ainda é válido por padrão até que alguém o conteste. Se não houver desafio em um determinado estado, não há necessidade de gerar nenhuma Prova ZK. No entanto, se um participante iniciar um desafio, a Prova ZK precisa ser gerada para a exatidão de todas as transações no bloco de desafio. No futuro, podemos explorar a geração de ZK Fraud Proof para uma única instrução controversa para evitar o custo computacional de gerar ZK Proof o tempo todo.
3.2 Assinatura única compatível com Bitcoin
Na rede Bitcoin, as transações que seguem regras de consenso são transações válidas, mas além das regras de consenso, também são introduzidas regras de padronização. Os nós Bitcoin encaminham apenas transações padrão de transmissão, a única maneira de empacotar transações válidas, mas não padrão, é trabalhar diretamente com mineradores.
De acordo com as regras de consenso, o tamanho máximo das transações legadas (não Segwit) é de 1 MB, que ocupa todo o bloco. Mas o limite de padronização para transações legadas é de 100 KB. De acordo com as regras de consenso, o tamanho máximo de uma transação Segwit é de 4 MB, que é o limite de peso. No entanto, o limite de padronização das transações Segwit é de 400 KB.
A assinatura Lamport é um componente básico do BitVM, que reduz o comprimento da assinatura e da chave pública, o que ajuda a reduzir os dados da transação e, assim, reduzir as taxas de manuseio. A assinatura única de Lamport requer o uso de uma função hash (como a função de permutação unilateral f). No esquema de assinatura única de Lamport, o comprimento da mensagem é de v bits, o comprimento da chave pública é de 2 v bits e o comprimento da assinatura também é de 2 v bits. A assinatura e a chave pública são longas e requerem uma grande quantidade de gás de armazenamento. Portanto, há uma necessidade de encontrar esquemas de assinatura com funções semelhantes para reduzir o comprimento da assinatura e da chave pública. Em comparação com a assinatura única de Lamport, a assinatura única de Winternitz reduziu significativamente o comprimento da assinatura e da chave pública, mas aumenta a complexidade computacional da assinatura e da verificação de assinatura.
No esquema de assinatura única de Winternitz, uma função especial P é usada para mapear uma mensagem de v bits em um vetor s de comprimento n. O valor de cada elemento em s é {0,..., d}. O esquema de assinatura única de Lamport é o esquema de assinatura única de Winternitz no caso especial de d = 1. No esquema de assinatura única de Winternitz, a relação entre n, d, v satisfaz: n≈v/log 2(d+ 1). Quando d= 15, existe n≈(v/4)+ 1. Para uma assinatura de Winternitz contendo n elementos, o comprimento da chave pública e o comprimento da assinatura são 4 vezes menores do que no esquema de assinatura única de Lamport. No entanto, a complexidade da verificação de assinaturas aumenta 4 vezes. Usar d= 15, v= 160, f=ripemd 160(x) no BitVM para implementar a assinatura única de Winternitz pode reduzir o tamanho do compromisso de bit em 50%, reduzindo assim as taxas de transação do BitVM em pelo menos 50%. No futuro, ao mesmo tempo que otimiza a implementação existente do Winternitz Bitcoin Script, esquemas de assinatura única mais compactos expressos em Bitcoin Script podem ser explorados.
3.3 Funções hash compatíveis com Bitcoin
De acordo com as regras de consenso, o tamanho máximo do P 2 TR é 10 kB, e o tamanho máximo da testemunha P 2 TR é igual ao tamanho máximo da transação Segwit, que é 4 MB. Contudo, o limite superior de standradness da testemunha P 2 TR é de 400 kB.
Atualmente, a rede Bitcoin não suporta OP_CAT, e as strings não podem ser unidas para verificação do caminho Merkle. Portanto, é necessário usar scripts Bitcoin existentes para implementar uma função hash compatível com Bitcoin com tamanho ideal e tamanho de testemunha para apoiar a função de verificação de prova de inclusão merkle.
BLAKE 3 é uma versão otimizada da função hash BLAKE 2 e introduz o modo árvore Bao. Comparado com o BLAKE 2 baseado em s, o número de rodadas de sua função de compressão foi reduzido de 10 para 7. A função hash BLAKE 3 dividirá sua entrada em pedaços consecutivos de 1024 bytes de tamanho, o último pedaço pode ser mais curto, mas não vazio. Quando há apenas um pedaço, o pedaço é o nó raiz e o único nó da árvore. Organize esses pedaços como nós folha de uma árvore binária e, em seguida, compacte cada pedaço de forma independente.
Quando o BitVM é utilizado para verificar o cenário de prova de inclusão Merkle, a entrada da operação hash é composta por dois valores hash de 256 bits, ou seja, a entrada da operação hash é de 64 bytes. Ao usar a função hash BLAKE 3, esses 64 bytes podem ser alocados em um único bloco, e toda a operação hash BLAKE 3 só precisa aplicar a função de compactação uma vez ao único bloco. Na função de compressão do BLAKE 3 é necessário executar a função de arredondamento 7 vezes e a função de permutação 6 vezes.
Atualmente, operações básicas como XOR, adição modular e deslocamento de bit para a direita com base em valores de u 32 foram concluídas no BitVM, e a função hash BLAKE 3 implementada pelo script Bitcoin pode ser facilmente montada. Use 4 bytes separados na pilha para representar u 32 palavras para implementar u 32 adição, u 32 XOR bit a bit e u 32 rotações bit a bit exigidas pelo BLAKE 3. O atual script Bitcoin da função hash BLAKE 3 totaliza cerca de 100 kB, o que é suficiente para construir uma versão de brinquedo do BitVM.
Além disso, esses códigos BLAKE 3 podem ser divididos, permitindo que o Verifier e o Prover reduzam significativamente os dados on-chain necessários, dividindo a execução no jogo de desafio-resposta pela metade, em vez de executá-lo inteiramente. Por fim, use o script Bitcoin para implementar funções hash como Keccak-256 e Grøstl, selecione a função hash mais compatível com Bitcoin e explore outras novas funções hash compatíveis com Bitcoin.
3,4 menos BitVM
less s é um método de execução de contratos inteligentes fora da cadeia usando assinaturas Schnorr. O conceito de Scripless nasceu do Mimblewimble, que não armazena dados permanentes exceto o kernel e sua assinatura.
As vantagens do less são funcionalidade, privacidade e eficiência.
**Recursos: **menos s podem aumentar o escopo e a complexidade dos contratos inteligentes. Os recursos de script do Bitcoin são limitados pelo número de OP_CODES habilitados na rede, e menos s movem a especificação e execução de contratos inteligentes da cadeia para discussões apenas entre os participantes do contrato de design, sem esperar por uma bifurcação da rede Bitcoin para permitir Novo código de operação.
**Privacidade:**Mover a especificação e execução de contratos inteligentes de dentro da rede para fora da rede aumenta a privacidade. Na rede, muitos detalhes do contrato serão compartilhados com toda a rede, incluindo o número e endereços dos participantes e o valor da transferência. Ao mover os contratos inteligentes para fora da cadeia, a rede só sabe que os participantes concordam que os termos dos seus contratos foram cumpridos e as transações subjacentes são válidas.
**Eficiência: **menos s minimiza a quantidade de dados verificados e armazenados na cadeia. Ao mover os contratos inteligentes para fora da cadeia, as taxas de gestão para nós completos serão reduzidas e as taxas de transação para os utilizadores também serão reduzidas.
less s é uma abordagem para projetar protocolos criptográficos em Bitcoin que evita a necessidade de executar contratos inteligentes explícitos. A ideia central é usar algoritmos criptográficos para alcançar a funcionalidade desejada, em vez de usar scripts para alcançar a funcionalidade. Assinaturas do adaptador e assinaturas múltiplas são os blocos de construção originais do less s. Usando menos s, você pode realizar transações menores do que as transações normais e reduzir as taxas de transação.
Com a ajuda de less s, a multi-assinatura Schnorr e a assinatura do adaptador podem ser usadas, que não fornece mais valores de hash e pré-imagens de hash como a solução BitVM, e também pode realizar o compromisso da porta lógica no circuito BitVM, economizando assim BitVM espaço de script e melhorando a eficiência do BitVM. Embora o esquema less s existente possa reduzir o espaço de script BitVM, ele requer uma grande interação entre o provador e o desafiante para combinar a chave pública. No futuro, melhoraremos esta solução e tentaremos introduzir Scripless s em módulos de função específicos do BitVM.
3.5 Desafio multipartidário sem permissão
A razão pela qual os desafios atuais do BitVM exigem permissão por padrão é que o UTXO do Bitcoin só pode ser executado uma vez, permitindo que um verificador malicioso “desperdice” o contrato desafiando um provador honesto. Atualmente, o BitVM está limitado ao modo de desafio de duas partes. Um provador que tenta fazer o mal pode lançar simultaneamente um desafio com um verificador que ele controla, "desperdiçando" assim o contrato, tornando o ato maligno bem-sucedido, e outros verificadores não podem impedir o comportamento. Portanto, com base no Bitcoin, um protocolo de desafio OP multipartidário sem permissão precisa ser estudado, que pode estender o modelo de confiança 1 de n existente do BitVM para 1 de N. Entre eles, N é muito maior que n. Além disso, é necessário estudar e resolver o problema dos desafiantes que conspiram com os provadores ou desafiam maliciosamente contratos “desperdiçados”. Em última análise, implementando o protocolo BitVM com menos confiança.
Desafios multipartidários sem permissão, permitindo que qualquer pessoa participe sem uma lista de permissões. Isso significa que os usuários podem retirar moedas do L2 sem o envolvimento de terceiros de confiança. Além disso, qualquer usuário que queira participar do protocolo de desafio OP pode contestar e excluir saques inválidos.
Estender o BitVM para um modelo de desafio multipartidário sem permissão requer a solução dos seguintes ataques:
Ataque Sybil: Mesmo que um invasor forje múltiplas identidades para participar de uma disputa, uma única parte honesta ainda poderá vencer a disputa. Se o custo para uma parte honesta de defender o resultado correcto estiver linearmente relacionado com o número de atacantes, então, quando um grande número de atacantes estiver envolvido, o custo de vencer uma disputa torna-se irrealista e vulnerável ao ataque das Bruxas. No artigo Permissionless Refered Tournaments, é proposto um algoritmo de resolução de disputas que muda o jogo. O custo de um único participante honesto vencer uma disputa aumenta logaritmicamente com o número de oponentes, em vez de linearmente.
Ataque de atraso: Uma parte mal-intencionada ou um grupo de partes mal-intencionadas segue uma determinada estratégia para impedir ou atrasar a confirmação de resultados corretos (como a retirada de ativos para L1) em L1 e forçar os provadores honestos a gastar taxas de L1. Este problema pode ser atenuado exigindo que os desafiantes apostem antecipadamente. Se um desafiante lançar um ataque retardado, a sua aposta será perdida. No entanto, se um atacante estiver disposto a sacrificar a aposta dentro de certos limites para prosseguir um ataque retardado, deverão existir contramedidas para reduzir o impacto do ataque retardado. O algoritmo proposto no artigo BoLD: Bounded Liquidity Delay in a Rollup Challenge Protocol faz com que não importa quanto compromisso o invasor esteja disposto a perder, o ataque de pior caso só pode causar um certo limite superior de atraso.
No futuro, exploraremos o modelo de desafio multipartidário sem permissão BitVM que é adequado às características do Bitcoin e pode resistir aos problemas de ataque acima.
4. Conclusão
A exploração da tecnologia BitVM está apenas começando, no futuro, mais direções de otimização serão exploradas e implementadas para alcançar a expansão do Bitcoin e prosperar o ecossistema Bitcoin.
referências
BitVM: calcule qualquer coisa em Bitcoin
BitVM: Contratos de Bitcoin fora da cadeia
3.Robin Linus no BitVM
[bitcoin-dev] BitVM: calcule qualquer coisa em Bitcoin
O casal estranho: ZK e rollups otimistas em uma data de escalabilidade
Quais são as transações e limites do Bitcoin?
BIP-342: Validação de Taproot s
_linus/status/1765337186222686347
Curso de Pós-Graduação em Criptografia Aplicada
BLAKE 3: uma função, rápida em qualquer lugar
[bitcoin-dev] Implementando Blake 3 em Bitcoin
Introdução ao menos
BitVM usando menos s
Soluções para atrasar ataques em rollups
Apresentando DAVE. À prova de falhas sem permissão da Cartesi.
Atrasar ataques em rollups
Soluções para atrasar ataques em rollups – Arbitrum Research
Notas sobre jogos de computação interativos multijogador
BoLD: Atraso de Liquidez Limitada em um Protocolo de Desafio Rollup
Torneios Arbitrados Sem Permissão
Link original
Ver original
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Análise do princípio BitVM e considerações de otimização
Fonte original: Grupo de Pesquisa Bitlayer
Autor original: Lynndell, mutourend.
1. Introdução
Bitcoin é um ativo digital descentralizado, seguro e confiável. No entanto, possui limitações significativas que a impedem de se tornar uma rede escalável para pagamentos e outras aplicações. A questão da escala do Bitcoin tem sido uma preocupação desde o seu início. O modelo Bitcoin UTXO trata cada transação como um evento independente, resultando em um sistema sem estado que não possui a capacidade de realizar cálculos complexos e dependentes do estado. Portanto, embora o Bitcoin possa executar scripts simples e transações com múltiplas assinaturas, ele tem dificuldade em facilitar as interações contratuais complexas e dinâmicas comuns em plataformas de blockchain com estado. Esta questão limita significativamente o âmbito de aplicações descentralizadas (dApps) e instrumentos financeiros complexos que podem ser construídos em Bitcoin, enquanto as plataformas de modelo estatal fornecem um ambiente mais diversificado para a implementação e execução de contratos inteligentes ricos em funcionalidades.
Para a expansão do Bitcoin, existem principalmente tecnologias como canais estaduais, cadeias laterais e verificação de clientes. Entre eles, os canais estatais fornecem soluções de pagamento seguras e diversas, mas são limitados na sua capacidade de verificar cálculos arbitrariamente complexos. Essa limitação reduz seu uso em uma variedade de cenários que exigem lógica e interações complexas e condicionais. Sidechains, embora suportem uma ampla gama de aplicações e forneçam uma diversidade de funcionalidades além do Bitcoin, têm menor segurança. Esta diferença na segurança decorre do facto de as cadeias laterais utilizarem mecanismos de consenso independentes, que são muito menos robustos do que o mecanismo de consenso do Bitcoin. A verificação do lado do cliente, usando o modelo Bitcoin UTXO, pode lidar com transações mais complexas, mas não possui a capacidade de restrição de soma de verificação bidirecional com o Bitcoin, tornando sua segurança inferior à do Bitcoin. O design off-chain dos protocolos de verificação de cliente depende de infraestrutura de servidor ou nuvem, o que pode levar à centralização ou potencial censura por meio de servidores comprometidos. O design fora da cadeia de validação do lado do cliente também introduz mais complexidade na infraestrutura blockchain, potencialmente levando a problemas de escalabilidade.
Em dezembro de 2023, o líder do projeto ZeroSync, Robin Linus, publicou um white paper chamado "BitVM: Compute Anything On Bitcoin", que desencadeou o pensamento de todos sobre como melhorar a programabilidade do Bitcoin. Este artigo propõe uma solução de contrato Bitcoin que pode atingir a completude de Turing sem alterar o consenso da rede Bitcoin, de modo que qualquer cálculo complexo possa ser verificado no Bitcoin sem alterar as regras básicas do Bitcoin. BitVM faz uso total de Bitcoin Script e Taproot para obter um rollup otimista. Com base na assinatura Lamport (também conhecida como compromisso de bit), uma conexão é estabelecida entre dois Bitcoin UTXOs para implementar scripts Bitcoin com estado. Ao se comprometerem com um grande programa em um endereço Taproot, os operadores e validadores se envolvem em extensas interações fora da cadeia, resultando em uma pequena presença na cadeia. Se ambas as partes cooperarem, cálculos off-chain arbitrariamente complexos e com estado podem ser realizados sem deixar qualquer rastro na cadeia. Se ambas as partes não cooperarem, quando ocorrer uma disputa, será necessária a execução em cadeia. Como resultado, o BitVM amplia enormemente os casos de uso potenciais do Bitcoin, permitindo que o Bitcoin sirva não apenas como moeda, mas também como plataforma de verificação para uma variedade de aplicações descentralizadas e tarefas computacionais complexas.
Porém, embora a tecnologia BitVM tenha grandes vantagens na expansão do Bitcoin, ela ainda está em seus estágios iniciais e ainda existem alguns problemas em termos de eficiência e segurança. Por exemplo: (1) Desafios e respostas exigem múltiplas interações, resultando em taxas de manuseio caras e longos ciclos de desafio; (2) Os dados de assinatura única de Lamport são longos e o comprimento dos dados precisa ser reduzido; (3) A função hash é complexo e requer função hash compatível com Bitcoin para reduzir custos; (4) O contrato BitVM existente é enorme e a capacidade de bloco Bitcoin é limitada. Menos s podem ser usados para implementar menos s BitVM, economizando espaço de bloco Bitcoin e melhorando a eficiência do BitVM; (5 ) O BitVM existente adota um modelo de permissão. Somente os membros da aliança podem iniciar desafios e é limitado a apenas duas partes. Deve ser estendido a um modelo de desafio multipartidário sem permissão para reduzir ainda mais a suposição de confiança. Para tanto, este artigo propõe algumas ideias de otimização para melhorar ainda mais a eficiência e segurança do BitVM.
2.Princípio BitVM
BitVM está posicionado como um contrato off-chain de Bitcoin e está comprometido em promover as funções de contrato de Bitcoin. Atualmente os scripts Bitcoin são completamente sem estado, portanto, quando um script Bitcoin é executado, seu ambiente de execução é redefinido após cada script. Não existe uma maneira nativa de o script 1 e o script 2 terem o mesmo valor x, e o Bitcoin Script não oferece suporte nativo para isso. No entanto, você ainda pode usar opcodes existentes para tornar o script Bitcoin com estado por meio da assinatura única de Lamport. Por exemplo, você pode forçar x em 1 e 2 a ter o mesmo valor. Os participantes podem ser penalizados se assinarem valores x conflitantes. Os cálculos do programa BitVM ocorrem fora da cadeia, enquanto a verificação dos resultados dos cálculos ocorre na cadeia. O bloco Bitcoin atual tem um limite de 1 MB. Quando o cálculo de verificação é muito complexo, a tecnologia OP pode ser usada para adotar o modo de resposta ao desafio para suportar verificação de cálculo de maior complexidade.
Semelhante ao Optimistic Rollup e à proposta MATT (Merkelize All The Things), o sistema BitVM é baseado em protocolos à prova de fraude e resposta a desafios, mas não requer modificação das regras de consenso do Bitcoin. As primitivas subjacentes do BitVM são simples, baseadas principalmente em bloqueios de hash, bloqueios de tempo e grandes árvores Taproot.
O provador confirma byte por byte, mas verificar todos os cálculos na cadeia seria muito caro. Assim, o verificador realiza uma série de desafios cuidadosamente elaborados para refutar sucintamente as falsas afirmações do provador. Provadores e validadores pré-assinam conjuntamente uma série de transações de desafio e resposta que são usadas para resolver disputas, permitindo a verificação computacional universal no Bitcoin.
Os principais componentes do BitVM são:
3.Otimização BitVM
3.1 Reduza o número de interações de OP com base em ZK
Existem atualmente 2 Rollups principais: ZK Rollups e OP Rollups. Dentre eles, o ZK Rollups conta com a verificação de validade do ZK Proof, ou seja, a prova criptográfica de execução correta, e sua segurança depende da suposição de complexidade computacional; o OP Rollups conta com o Fraud Proof, assumindo que os estados submetidos estão corretos, configurando O período de contestação é geralmente de 7 dias e sua segurança pressupõe que pelo menos uma parte honesta no sistema possa detectar o estado incorreto e enviar uma prova de fraude. Suponha que o número máximo de etapas do programa de desafio BitVM seja 2 ^{ 32 } e a memória necessária seja 2 ^{ 32 }* 4 bytes, o que equivale a cerca de 17 GB. Na pior das hipóteses, são necessárias cerca de 40 rodadas de desafio e resposta, cerca de meio ano, e o script total é de cerca de 150 KB. Há uma grave falta de incentivos nesta situação, mas isso quase nunca acontece na prática.
Considere o uso de provas de conhecimento zero para reduzir o número de desafios do BitVM, melhorando assim a eficiência do BitVM. De acordo com a teoria da prova de conhecimento zero, se os dados Data satisfazem o algoritmo F, fica provado que a prova satisfaz o algoritmo de verificação Verify, ou seja, o algoritmo de verificação gera True; se os dados Data não satisfazem o algoritmo F, fica provado que a prova não satisfaz o algoritmo de verificação Verify, ou seja, o algoritmo de verificação gera False . No sistema BitVM, caso o desafiante não reconheça os dados enviados pelo provador, um desafio é iniciado.
Para o algoritmo F, use o método de dicotomia para dividi-lo. Suponha que leva 2 ^ n vezes para encontrar o ponto de erro; se a complexidade do algoritmo for muito alta, n será grande e levará muito tempo para ser concluído. No entanto, a complexidade do algoritmo de verificação Verify da prova de conhecimento zero é fixa. Todo o processo de prova e algoritmo de verificação Verify é público e a saída é considerada falsa. A vantagem da prova de conhecimento zero é que a complexidade computacional necessária para abrir o algoritmo de verificação Verify é muito menor do que o método binário para abrir o algoritmo original F. Portanto, com a ajuda da prova de conhecimento zero, o BitVM não está mais desafiando o algoritmo F original, mas o algoritmo de verificação Verify, reduzindo o número de rodadas de desafio e encurtando o ciclo de desafio.
Finalmente, embora a eficácia da prova de conhecimento zero e da prova de fraude dependa de diferentes premissas de segurança, elas podem ser combinadas para construir a Prova de Fraude ZK e realizar a Prova ZK sob Demanda. Ao contrário do ZK Rollup completo, que não precisa mais gerar prova ZK para cada transição de estado, o modelo sob demanda torna a prova ZK necessária apenas quando há desafios, enquanto todo o design do Rollup ainda é otimista. Portanto, o estado resultante ainda é válido por padrão até que alguém o conteste. Se não houver desafio em um determinado estado, não há necessidade de gerar nenhuma Prova ZK. No entanto, se um participante iniciar um desafio, a Prova ZK precisa ser gerada para a exatidão de todas as transações no bloco de desafio. No futuro, podemos explorar a geração de ZK Fraud Proof para uma única instrução controversa para evitar o custo computacional de gerar ZK Proof o tempo todo.
3.2 Assinatura única compatível com Bitcoin
Na rede Bitcoin, as transações que seguem regras de consenso são transações válidas, mas além das regras de consenso, também são introduzidas regras de padronização. Os nós Bitcoin encaminham apenas transações padrão de transmissão, a única maneira de empacotar transações válidas, mas não padrão, é trabalhar diretamente com mineradores.
De acordo com as regras de consenso, o tamanho máximo das transações legadas (não Segwit) é de 1 MB, que ocupa todo o bloco. Mas o limite de padronização para transações legadas é de 100 KB. De acordo com as regras de consenso, o tamanho máximo de uma transação Segwit é de 4 MB, que é o limite de peso. No entanto, o limite de padronização das transações Segwit é de 400 KB.
A assinatura Lamport é um componente básico do BitVM, que reduz o comprimento da assinatura e da chave pública, o que ajuda a reduzir os dados da transação e, assim, reduzir as taxas de manuseio. A assinatura única de Lamport requer o uso de uma função hash (como a função de permutação unilateral f). No esquema de assinatura única de Lamport, o comprimento da mensagem é de v bits, o comprimento da chave pública é de 2 v bits e o comprimento da assinatura também é de 2 v bits. A assinatura e a chave pública são longas e requerem uma grande quantidade de gás de armazenamento. Portanto, há uma necessidade de encontrar esquemas de assinatura com funções semelhantes para reduzir o comprimento da assinatura e da chave pública. Em comparação com a assinatura única de Lamport, a assinatura única de Winternitz reduziu significativamente o comprimento da assinatura e da chave pública, mas aumenta a complexidade computacional da assinatura e da verificação de assinatura.
No esquema de assinatura única de Winternitz, uma função especial P é usada para mapear uma mensagem de v bits em um vetor s de comprimento n. O valor de cada elemento em s é {0,..., d}. O esquema de assinatura única de Lamport é o esquema de assinatura única de Winternitz no caso especial de d = 1. No esquema de assinatura única de Winternitz, a relação entre n, d, v satisfaz: n≈v/log 2(d+ 1). Quando d= 15, existe n≈(v/4)+ 1. Para uma assinatura de Winternitz contendo n elementos, o comprimento da chave pública e o comprimento da assinatura são 4 vezes menores do que no esquema de assinatura única de Lamport. No entanto, a complexidade da verificação de assinaturas aumenta 4 vezes. Usar d= 15, v= 160, f=ripemd 160(x) no BitVM para implementar a assinatura única de Winternitz pode reduzir o tamanho do compromisso de bit em 50%, reduzindo assim as taxas de transação do BitVM em pelo menos 50%. No futuro, ao mesmo tempo que otimiza a implementação existente do Winternitz Bitcoin Script, esquemas de assinatura única mais compactos expressos em Bitcoin Script podem ser explorados.
3.3 Funções hash compatíveis com Bitcoin
De acordo com as regras de consenso, o tamanho máximo do P 2 TR é 10 kB, e o tamanho máximo da testemunha P 2 TR é igual ao tamanho máximo da transação Segwit, que é 4 MB. Contudo, o limite superior de standradness da testemunha P 2 TR é de 400 kB.
Atualmente, a rede Bitcoin não suporta OP_CAT, e as strings não podem ser unidas para verificação do caminho Merkle. Portanto, é necessário usar scripts Bitcoin existentes para implementar uma função hash compatível com Bitcoin com tamanho ideal e tamanho de testemunha para apoiar a função de verificação de prova de inclusão merkle.
BLAKE 3 é uma versão otimizada da função hash BLAKE 2 e introduz o modo árvore Bao. Comparado com o BLAKE 2 baseado em s, o número de rodadas de sua função de compressão foi reduzido de 10 para 7. A função hash BLAKE 3 dividirá sua entrada em pedaços consecutivos de 1024 bytes de tamanho, o último pedaço pode ser mais curto, mas não vazio. Quando há apenas um pedaço, o pedaço é o nó raiz e o único nó da árvore. Organize esses pedaços como nós folha de uma árvore binária e, em seguida, compacte cada pedaço de forma independente.
Quando o BitVM é utilizado para verificar o cenário de prova de inclusão Merkle, a entrada da operação hash é composta por dois valores hash de 256 bits, ou seja, a entrada da operação hash é de 64 bytes. Ao usar a função hash BLAKE 3, esses 64 bytes podem ser alocados em um único bloco, e toda a operação hash BLAKE 3 só precisa aplicar a função de compactação uma vez ao único bloco. Na função de compressão do BLAKE 3 é necessário executar a função de arredondamento 7 vezes e a função de permutação 6 vezes.
Atualmente, operações básicas como XOR, adição modular e deslocamento de bit para a direita com base em valores de u 32 foram concluídas no BitVM, e a função hash BLAKE 3 implementada pelo script Bitcoin pode ser facilmente montada. Use 4 bytes separados na pilha para representar u 32 palavras para implementar u 32 adição, u 32 XOR bit a bit e u 32 rotações bit a bit exigidas pelo BLAKE 3. O atual script Bitcoin da função hash BLAKE 3 totaliza cerca de 100 kB, o que é suficiente para construir uma versão de brinquedo do BitVM.
Além disso, esses códigos BLAKE 3 podem ser divididos, permitindo que o Verifier e o Prover reduzam significativamente os dados on-chain necessários, dividindo a execução no jogo de desafio-resposta pela metade, em vez de executá-lo inteiramente. Por fim, use o script Bitcoin para implementar funções hash como Keccak-256 e Grøstl, selecione a função hash mais compatível com Bitcoin e explore outras novas funções hash compatíveis com Bitcoin.
3,4 menos BitVM
less s é um método de execução de contratos inteligentes fora da cadeia usando assinaturas Schnorr. O conceito de Scripless nasceu do Mimblewimble, que não armazena dados permanentes exceto o kernel e sua assinatura.
As vantagens do less são funcionalidade, privacidade e eficiência.
less s é uma abordagem para projetar protocolos criptográficos em Bitcoin que evita a necessidade de executar contratos inteligentes explícitos. A ideia central é usar algoritmos criptográficos para alcançar a funcionalidade desejada, em vez de usar scripts para alcançar a funcionalidade. Assinaturas do adaptador e assinaturas múltiplas são os blocos de construção originais do less s. Usando menos s, você pode realizar transações menores do que as transações normais e reduzir as taxas de transação.
Com a ajuda de less s, a multi-assinatura Schnorr e a assinatura do adaptador podem ser usadas, que não fornece mais valores de hash e pré-imagens de hash como a solução BitVM, e também pode realizar o compromisso da porta lógica no circuito BitVM, economizando assim BitVM espaço de script e melhorando a eficiência do BitVM. Embora o esquema less s existente possa reduzir o espaço de script BitVM, ele requer uma grande interação entre o provador e o desafiante para combinar a chave pública. No futuro, melhoraremos esta solução e tentaremos introduzir Scripless s em módulos de função específicos do BitVM.
3.5 Desafio multipartidário sem permissão
A razão pela qual os desafios atuais do BitVM exigem permissão por padrão é que o UTXO do Bitcoin só pode ser executado uma vez, permitindo que um verificador malicioso “desperdice” o contrato desafiando um provador honesto. Atualmente, o BitVM está limitado ao modo de desafio de duas partes. Um provador que tenta fazer o mal pode lançar simultaneamente um desafio com um verificador que ele controla, "desperdiçando" assim o contrato, tornando o ato maligno bem-sucedido, e outros verificadores não podem impedir o comportamento. Portanto, com base no Bitcoin, um protocolo de desafio OP multipartidário sem permissão precisa ser estudado, que pode estender o modelo de confiança 1 de n existente do BitVM para 1 de N. Entre eles, N é muito maior que n. Além disso, é necessário estudar e resolver o problema dos desafiantes que conspiram com os provadores ou desafiam maliciosamente contratos “desperdiçados”. Em última análise, implementando o protocolo BitVM com menos confiança.
Desafios multipartidários sem permissão, permitindo que qualquer pessoa participe sem uma lista de permissões. Isso significa que os usuários podem retirar moedas do L2 sem o envolvimento de terceiros de confiança. Além disso, qualquer usuário que queira participar do protocolo de desafio OP pode contestar e excluir saques inválidos.
Estender o BitVM para um modelo de desafio multipartidário sem permissão requer a solução dos seguintes ataques:
No futuro, exploraremos o modelo de desafio multipartidário sem permissão BitVM que é adequado às características do Bitcoin e pode resistir aos problemas de ataque acima.
4. Conclusão
A exploração da tecnologia BitVM está apenas começando, no futuro, mais direções de otimização serão exploradas e implementadas para alcançar a expansão do Bitcoin e prosperar o ecossistema Bitcoin.
referências
Link original