Em outubro passado, Robin Linus do Zerosync lançou uma bomba na forma de BitVM. Uma das críticas mais antigas ao Bitcoin é que não é possível criar programas arbitrários para controlar como o dinheiro é gasto ou bloqueado. O Bitcoin tem apenas uma quantidade muito limitada de programabilidade em sua linguagem de script, e as primitivas disponíveis são extremamente restritas. Você pode verificar uma assinatura, adicionar um timelock a algo, manipular dados de algumas maneiras simples, mas é isso.
Você pode programar um Bitcoin UTXO para exigir uma verificação de assinatura, uma verificação de timelock, etc. Mas você não pode programá-lo para desbloquear com base em quaisquer condições arbitrárias. A visão de Robin com o BitVM foi que um único primitivo no campo da computação poderia ser aplicado no script Bitcoin: uma porta NAND, uma das primitivas básicas da computação no nível físico/elétrico. Toda computação possível pode ser construída a partir de portas NAND.
O script pode realmente verificar uma porta NAND devido a um truque interessante usando OP_BOOLAND e OP_NOT. OP_BOOLAND é uma operação AND, o oposto de NAND. OP_NOT pega um valor binário 1 ou 0 e o inverte. Juntos, isso permite que você aplique uma única operação NAND diretamente no script. Em combinação com hashlocks, um script de porta NAND pode ser feito onde cada campo de entrada e saída possui dois hashlocks possíveis para “desbloquear” aquele caminho de gastos, cada um empurrando 1 ou 0 para a pilha para realizar a operação NAND. Cada script também tem um caminho onde você pode revelar ambos pré-imagens para um único valor de bit, você pode reivindicar os fundos imediatamente. Isso ocorre para que, uma vez que alguém decida o que inserir no portão NAND, ele não possa mudar de ideia sem perder dinheiro.
Uma enorme quantidade de scripts de porta NAND podem ser compactados em uma árvore principal e, uma vez que alguém se compromete com os valores de bits fora da cadeia para inserir esse cálculo, a outra parte pode desafiá-los em qualquer etapa individual do cálculo para provar que é sendo executado corretamente na cadeia. Cada “desafio” permite que a parte desafiada prove que o portão individual foi calculado corretamente, caso contrário, a outra parte poderá reivindicar os fundos após um timelock. Indo e voltando assim, se um cálculo for contestado, é garantido que a parte trapaceira acabará sendo pega e perderá fundos.
As limitações
A principal limitação do BitVM é que apenas as pessoas envolvidas na criação de um contrato BitVM podem participar, e as funções são muito limitadas. Há o provador, a pessoa que afirma como o cálculo aconteceu fora da cadeia, e o verificador, a pessoa que pode desafiar o cálculo e forçá-lo a ser provado na cadeia se o provador não completar o cálculo fora da cadeia ou tentar mentir sobre os resultados.
Uma das razões para projetar o BitVM foi estabelecer ligações bidirecionais a sidechains ou outros sistemas. O esquema oferece uma primitiva muito poderosa nesse caso de uso, a capacidade de realmente impor que os fundos sejam dados a uma parte ou outra com base na correção de um cálculo arbitrário, ou seja, uma verificação de validade para saber se um pegout é válido de acordo com as regras de uma cadeia lateral. . O problema é que apenas as pessoas que possuem as chaves desse BitVM UTXO podem realmente dizer “Ei, você está trapaceando!” quando alguém estiver, e participe do protocolo de desafio. Em última análise, isso torna o sistema ainda confiável.
Outra limitação é que o protocolo de resposta ao desafio pode ser muito longo. Se alguém perceber que o resultado do cálculo resultará na perda de dinheiro e parará de responder, o verificador terá que essencialmente adivinhar onde está a porta NAND individual no cálculo em que o provador teria que mentir e revelar ambas as pré-imagens para um pouco que daria ao verificador os fundos. Até que esse portão específico seja desafiado na cadeia, o provador ainda pode responder corretamente a um desafio e arrastá-lo. Isso pode consumir muito tempo e ser ineficiente.
Algumas melhorias neste design foram feitas desde a proposta original para permitir a existência de múltiplos verificadores no sistema com o provador, para criar um modelo de confiança 1 de n onde apenas um único verificador é necessário para desafiar um provador desonesto. No entanto, isso requer a instanciação de múltiplas instâncias BitVM em paralelo para ser realizado e, portanto, aumenta as ineficiências com o design original de duas partes.
BitVM2
Robin propôs recentemente um esquema de design para o BitVM 2. Este esquema procura fazer algumas compensações em comparação com o design original para mitigar suas duas principais deficiências. O BitVM 2 reduz o comprimento do protocolo de desafio/resposta de uma série indeterminada de transações que poderia ser superior a dezenas no pior cenário, para duas rodadas no desafio/resposta. Além disso, com o uso de saídas de conector permite qualquer um para atuar como verificador. Não é necessário que alguém seja membro envolvido no estabelecimento do BitVM para desafiar um provador desonesto.
A mudança fundamental aqui é deixar de usar portas NAND de script diretamente para implementar o rastreamento computacional bruto diretamente e passar a usá-las para implementar um verificador geral de prova de conhecimento zero SNARK (uma das primitivas principais que Robin pretendia desde o início implementar usando BitVM ). Em vez de colocar a entrada bruta no rastreamento computacional bruto e executá-la porta a porta em seus próprios scripts tapleaf, a entrada da instância BitVM 2 seria simplesmente uma entrada de prova de conhecimento zero em combinação com uma saída declarada da computação.
Além de abstrair a implementação computacional com um ZKP, os scripts tapleaf estão sendo massivamente expandidos de uma única porta NAND por folha para uma subfunção inteira do verificador ZKP. Em vez de o protocolo de resposta ao desafio ser baseado no verificador adivinhando em qual porta NAND o provador tentou trapacear, desafiando seletivamente em uma única porta, o verificador pode provar que a saída de uma subfunção inteira é inválida de acordo com a entrada.
Assim como o BitVM 1, o contrato é pré-negociado usando transações pré-assinadas e scripts de ramificação. Os fundos vinculados ao BitVM são enviados para um multisig n-de-n que assina duas transações de execução possíveis, uma na qual não ocorre nenhum desafio e outra na qual ocorre um desafio. Para iniciar o processo de execução do contrato, o provador inicia uma transação inicial. Esta transação inicial é confirmada com o valor de saída 'y' que eles afirmam que a computação produz e inclui três saídas: uma saída com bloqueio de tempo que está incluída na transação de execução sem desafio, uma saída do conector A e uma saída do conector B, ambas as quais também são gastos na transação sem desafio.
É aqui que o design permite que qualquer pessoa participe como verificador. A saída do conector A possui uma segunda transação pré-assinada que pode gastá-la, a transação de desafio. Esta é uma transação pré-assinada que paga ao provador um título em bitcoin, mas a saída do conector A não é suficiente para financiá-la. Literalmente, qualquer um pode adicionar suas próprias entradas para financiar a transação e gastar a saída do conector A, o que invalida a transação de retirada sem desafio para o provador (existe uma das entradas que ele não precisa de desafio).
Isso força o caminho do desafio. A saída B do conector também pode ser gasta usando uma transação pré-assinada, a transação assert, para a saída de cada subfunção em todo o contrato BitVM 2. Isso requer uma grande transação com muitos dados, mas lembre-se, o resultado final 'y' o provador afirma que a computação produzida já foi comprometida na transação inicial. Isso cria duas saídas. Uma é uma saída com timelock, a outra é uma saída do conector C. Ambas as saídas, além da original indexada em fundos, são todas gastas na segunda transação de retirada bem-sucedida para o provador após o timelock.
A saída C do conector também pode ser gasta por qualquer pessoa que possa provar que qualquer saída de subfunção no contrato BitVM 2 produz uma saída inválida. Isso requer uma transação muito grande, porque o script necessário para provar que uma seção inteira do cálculo do BitVM está incorreta é enorme, mas nesta única transação um verificador pode reivindicar as moedas na saída do conector com uma prova válida. Isso invalida a segunda transação de retirada do provador e efetivamente queima as moedas. A única maneira de recuperá-los neste momento é se o provador e todos dos verificadores no multisig de financiamento n-de-n original cooperam para recuperá-los. A saída do conector B na transação inicial também pode ser gasta após um tempo limite muito mais longo do que a retirada sem desafio para invalidar tanto a transação sem desafio quanto a transação de afirmação, queimando as moedas indexadas.
Isso reduz o que poderia ser uma cadeia ridícula de transações na proposta original do BitVM para impor o resultado correto do contrato, para no máximo quatro transações (embora reconhecidamente muito massivas), enquanto no processo torna o conjunto de verificadores para a instância do BitVM 2 literalmente qualquer pessoa com bitcoin que financiará a transação do desafio.
O BitVM 2 pode acabar sendo um avanço significativo em relação à onda de rollups e outras camadas 2 que visam usar o BitVM como uma ligação bidirecional. O operador de um rollup (o provador no BitVM) pode usar seus próprios fundos para cobrir saques de usuários vinculados ao sistema e retirar periodicamente esses fundos do BitVM para se compensar. Qualquer o usuário ou parte interessada poderia então penalizá-los queimando seus fundos se conseguissem provar que a operadora não estava processando todos os saques corretamente.
É importante observar que, em última análise, a segurança de uma instância BitVM 2 é garantida pelo detentor de chaves n-de-n, mesmo que as pessoas que não participam dela ainda possam desafiar o provador como verificador. Mas como o provador tem uma saída eficiente no caso de não haver desafiantes, e qualquer um pode financiar a transação de desafio para atuar como verificador, o multisig de financiamento n-de-n poderia seguir uma cerimônia de configuração e exclusão de chave semelhante ao lançamento do Zcash para melhorar sua segurança.
O BitVM 2 provavelmente acabará sendo um avanço significativo em termos de melhoria da flexibilidade e do modelo de confiança dos pinos bidirecionais que fazem uso do BitVM. Mais uma vez, Robin provou ser um verdadeiro mago.
Fonte: bitcoinmagazine.com