Taproot Wizards lançou ontem um desenho animado chamado CatVM. Não vou me referir a isso como um white paper, são verdadeiros documentos acadêmicos para adultos. No cartoon, intercalados entre as absurdas narrativas infantis, estavam alguns insights técnicos valiosos sobre diferentes propostas de escala no ecossistema Bitcoin. Claro, no verdadeiro estilo cartoon, enterrado entre o exagero selvagem e o embelezamento.
O objetivo final do cartoon era propor um novo mecanismo para entrar e sair das camadas de escala construídas sobre o Bitcoin. Para separar essa proposta real do desenho animado, teremos que decompor as duas peças envolvidas.
Índice
Os blocos de construção
O primeiro experimento OP_CAT de Rijndael foi a construção de um cofre, um esquema que permite ao usuário criar uma transação intermediária de “teste” para retirar seus fundos do cofre. Isso inicia um timelock, durante o qual eles podem, a qualquer momento, enviar seus fundos de volta para o cofre ou para uma carteira segura de armazenamento refrigerado, e após o timelock o usuário pode retirar livremente os fundos para o destino que escolheu ao iniciar o processo de retirada. Estes são os apenas duas maneiras pelas quais o bitcoin enviado para o script do cofre pode ser gasto.
Explicar toda a mecânica de como isso é feito é essencialmente um artigo em si, então vou fazer algo que normalmente não faço e descartar isso como “mágica”. (Explicado aqui por Andrew Poelstra) O que essa “mágica” permite que você faça, ao criar assinaturas Schnorr não padrão e com a ajuda de OP_CAT, é construir a transação contra a qual a verificação de assinatura se destina na pilha de scripts. Isso permite que você garanta que certas partes da transação sejam exatamente como definidas antecipadamente. Ele também permite que você coloque a saída de uma transação anterior na pilha no processo de construção da transação que a gasta, o que significa que você pode comparar os resultados da transação de gastos com os resultados da transação anterior. Isso permite garantir, comparando-os, que certas partes das saídas da transação anterior correspondem a certas partes das novas saídas. Ou seja, o script, ou uma quantia. Assim, você pode “transferir” partes dos resultados antigos para os novos e aplicá-los.
Outra coisa que você pode fazer com OP_CAT, que não precisou de ajustes e experiências de Rijndael para provar, é verificar os galhos das árvores merkle. Como você pode empilhar itens CAT juntos, e o Bitcoin já suporta hash de dados na pilha, você pode construir lentamente uma raiz de árvore merkle a partir de um nó folha com os nós internos. Misture duas peças para obter um hash, misture-o com o hash do par e assim por diante. Eventualmente você obtém o hash raiz na pilha. Você pode então compará-lo com OP_EQUAL com um hash raiz predefinido no script de bloqueio.
Retirada Unilateral
Esses dois blocos de construção são suficientes para facilitar um mecanismo de retirada unilateral de um UTXO compartilhado em grupo. Uma raiz merkle pode ser incorporada em uma transação usando OP_RETURN ou outro mecanismo que seja confirmado em um nó folha para cada usuário. O script UTXO pode ser estruturado para que qualquer usuário com saldo possa tentar retirá-lo. Para fazer isso, eles forneceriam à filial merkle que se compromete com o valor a que têm direito, a prova de autorização, como uma chave pública para verificar uma assinatura, e construiriam a transação na pilha para verificar se as condições apropriadas foram atendidas.
Semelhante ao cofre OP_CAT de Rijndael, esta transação de retirada funcionaria como um ponto de partida. Os fundos dos usuários seriam restringidos por um timelock e eles não seriam capazes de concluir a retirada até que ela expirasse. A qualquer momento antes que o timelock expire, qualquer outro usuário pode criar uma prova de fraude para interromper a retirada e devolver os fundos ao script UTXO do grupo. Eles podem fazer isso devido à capacidade do OP_CAT de verificar árvores merkle. Se alguém já usou uma agência merkle específica para sacar fundos do UTXO antes, isso foi incluído em um bloco em algum lugar. Ao construir uma transação contendo a prova SPV dessa transação dentro de um bloco real, que pode usar OP_LESSTHANOREQUAL para verificar se o cabeçalho do bloco atende a alguma dificuldade mínima, eles podem provar na pilha que o ramo Merkle foi usado antes. Isso permite que saques duplicados sejam evitados.
Além disso, como você pode usar o truque “CAT na pilha” para garantir que partes específicas de uma transação anterior sejam incluídas na próxima, você pode garantir que a raiz merkle atual seja transportada para a próxima transação após uma transação bem-sucedida. cancelamento. Você também pode garantir que a alteração da retirada retornará ao script de compartilhamento do grupo. Isso garante que após um usuário retirar seus fundos, a alteração UTXO seja bloqueada com um script que permite a retirada de qualquer usuário restante, e assim por diante. Qualquer utilizador pode levantar unilateralmente os seus fundos a qualquer momento e em qualquer ordem, com a garantia de que o restante dos fundos ainda estará acessível aos restantes utilizadores.
A parte VM
Os leitores devem estar familiarizados com a ideia básica do BitVM. Você pode pegar um cálculo arbitrário e dividi-lo em cada uma de suas partes constituintes e incorporá-las em uma grande árvore principal, transformando esse cálculo em um jogo de desafio/resposta de vaivém. Isso permite bloquear bitcoin com condições mais complicadas do que as suportadas diretamente pelo próprio script bitcoin. A única deficiência real é a necessidade de elaborar uma enorme quantidade de transações pré-assinadas para facilitar isso.
O requisito para usar transações pré-assinadas é para que, na dinâmica de desafio/resposta, você possa garantir que as moedas sejam gastas de volta na grande árvore principal que as codifica, a menos que uma condição de saída seja alcançada de uma forma ou de outra. OP_CAT e a capacidade de “transportar” dados de transações anteriores permitem garantir isso sem a necessidade de transações pré-assinadas.
Portanto, esse esquema não apenas permite que qualquer usuário saia unilateralmente por conta própria, mas também permite que condições de bloqueio suportadas por uma segunda camada que não são suportadas pelo script Bitcoin sejam realmente aplicadas no processo de retirada. Ou seja, se algumas moedas fossem oneradas por um contrato inteligente que a camada base não entende e depois fossem retiradas da segunda camada, essas condições mais complicadas ainda poderiam ser resolvidas corretamente na camada base à medida que as moedas fossem retiradas.
A peça que faltava
Uma coisa que OP_CAT não permite é atualizar uma raiz de árvore merkle que representa os saldos do usuário fora da cadeia de forma verificável. Pode permitir que um Estado já empenhado facilite retiradas unilaterais, mas isso ocorre porque uma secção inteira da árvore é, na verdade, colocada em cadeia e verificada. Atualizar essa raiz fora da cadeia, por definição, significa que você não está colocando os dados na cadeia. Isto representa um problema. Não há como apenas o CAT verificar com eficiência se todas as alterações na árvore merkle foram autorizadas adequadamente pelos usuários relevantes.
É preciso confiar em alguém, e pela natureza das coisas, capaz de gastar o UTXO como e onde quiser, para substituir eficientemente uma raiz de estado antiga por uma nova para representar todas as mudanças de equilíbrio fora da cadeia. Um novo opcode além do OP_CAT, como OP_ZKVERIFY, seria necessário para fazer isso de maneira confiável.
Este não seria o fim do mundo sem OP_ZKVERIFY. A entidade que atualiza a raiz merkle para transferências fora da cadeia pode ser uma multisig n-de-n, com 100% dos participantes obrigados a assinar quaisquer alterações na raiz. Isso se resume ao mesmo modelo de confiança das indexações baseadas em BitVM, onde, enquanto existir um único participante honesto, os fundos de ninguém podem ser roubados. No entanto, é uma melhoria drástica em relação aos designs BitVM existentes no que diz respeito ao processo de retirada.
Nas pegs BitVM, os usuários não possuem um mecanismo de retirada unilateral. Os operadores de Peg devem ser confiáveis para realizar as retiradas dos usuários, sabendo que eles podem reivindicar de volta os fundos que gastaram fazendo isso de forma relativamente confiável a partir do Peg BitVM. Embora os incentivos para isso sejam muito sólidos, ainda exige que os usuários obtenham essencialmente permissão de outra pessoa para sair do sistema; eles não podem fazer isso por conta própria. Com CatVM, os usuários podem reivindicar a devolução de seus fundos unilateralmente, e uma operadora não é obrigada a arcar com sua própria liquidez para processar saques.
Empacotando
No geral, o projeto está incompleto em termos de construção. Isso não é algo que eu chamaria de Camada 2 por si só. É o núcleo de um deles, o mecanismo e a estrutura de como os fundos são bloqueados na Camada 2 e o processo de como os usuários podem sacar seus fundos. Definitivamente tem muita flexibilidade e utilidade.
Na pior das hipóteses, os usuários não precisam da permissão de ninguém para reivindicar seus fundos de volta na rede com segurança. Permite também uma programabilidade mais flexível dos fundos, ao mesmo tempo que transporta a aplicação dessas condições para a camada de base no caso de saídas unilaterais no pior dos casos. Se um dia conseguirmos algo como OP_ZKVERIFY, a progressão do estado fora da cadeia pode se tornar um processo realmente confiável.
Não espero nenhuma demonstração concreta no futuro próximo, mas definitivamente é uma boa ideia na minha opinião e algo que vale a pena considerar. Também mostra que os assistentes estão fazendo um pouco mais do que apenas bombear jpegs estúpidos.
Fonte: bitcoinmagazine.com
