Taproot está chegando ao Bitcoin: como funciona, sua história e implicações

As assinaturas Taproot e Schnorr serão lançadas no Bitcoin no bloco 709,632. Esta será uma enorme conquista fundamental para continuar a construir no futuro. Já se passaram quatro anos desde que o Segregated Witness foi lançado na rede, nossa última grande atualização de protocolo. Isso é tão longo quanto um ciclo de redução pela metade!

Pense sobre isso. Quatro anos desde o lançamento do SegWit até o lançamento do Taproot. Paciência lenta e metódica, como deveria ser. Mas a história da Taproot/Schnorr remonta muito mais longe do que isso.

A história da raiz principal

Alguns que estão aqui há algum tempo podem achar isso irônico, mas a primeira menção às assinaturas de Schnorr que eu conheço foi, na verdade, do ex-desenvolvedor do Bitcoin Core que se tornou construtor de blockchain corporativo, Mike Hearn. Em 2012, ele trouxe a ideia de uma nova curva criptográfica em relação à verificação em lote de assinaturas para tornar a validação de nós menos dispendiosa computacionalmente. Em última análise, o esquema que ele propunha dependia das assinaturas de Schnorr.

Adam Back estava discutindo ingenuidade esquemas para fazer endereços multisig que pareciam singlesig em 2014, utilizando assinaturas Schnorr. Até Gavin Andresen incluiu Schnorr em vez de ECDSA em sua lista de desejos de mudanças que ele faria no Bitcoin se pudesse agitar uma varinha mágica.

Desde o início do Bitcoin, a maioria dos desenvolvedores ativamente envolvidos no Bitcoin Core queriam assinaturas Schnorr, e sempre houve um consenso bastante sólido sobre sua superioridade em relação às assinaturas ECDSA. Na verdade, poderia argumentar-se que o ECDSA foi criado especificamente porque o esquema de assinatura Schnorr foi patenteado e havia uma enorme necessidade de um esquema de assinatura criptográfica de código aberto, não onerado por patentes.

Schnorr é muito mais eficiente e facilmente manipulável (coisas podem ser adicionadas, subtraídas, etc. das assinaturas e, se feito corretamente, ainda pode deixar aos usuários assinaturas válidas quando deveriam tê-las) do que o ECDSA. O uso do ECDSA foi uma questão de necessidade e não de desejo na maioria das aplicações criptográficas ao longo dos anos.

Merkelized Abstract Syntax Trees (MAST), a metade Taproot desta próxima atualização Taproot, tem uma história semelhante de longa data. Não consigo encontrar a citação, mas lembro-me claramente de ter visto essa frase divulgada por pessoas como Peter Todd no Bitcointalk.org por volta de 2013 ou 2014.

O original BIP para MAST foi proposta por Johnson Lau em 2016. Esta proposta também teve alguma atividade por volta de 2017, quando Mark Friedenbach, BTCDrak e Kalle Alm a dividiram em dois BIPs separados (116 e 117) e ampliou a proposta original de Lau.

O MAST ficou no limbo durante o ano seguinte até que Greg Maxwell surgiu com a ideia inicial do Taproot e publicado para a lista de discussão bitcoin-dev. Seu principal insight foi que, em qualquer caso de contrato entre vários participantes que ele pudesse imaginar, havia um “resultado ideal”, onde o contrato poderia ser resolvido por todos apenas assinando o resultado apropriado, em vez de impor o resultado com scripts e transações mais avançados. Esta é a afirmação fundamental em que o Taproot se baseia, ou seja, ajustar a árvore MAST para uma chave regular de nível superior que pode ser gasta sem revelar se existe uma árvore Merkle de outras condições de gasto.

O último trecho desta lição de história começa com Pieter Wiulle anunciando projetos de PIF para Schnorr e Taproot em conjunto com a lista de discussão em 6 de maio de 2019. Em janeiro de 2020, isso foi formalmente finalizado em PIF 340, 341 e 342. Desse ponto em diante, foram apenas alguns pequenos detalhes refinados no nível de implementação, algum período de revisão e, em seguida, o longo e prolongado batalha pelos mecanismos de ativação. Isso nos leva ao agora, pouco antes da ativação.

A importância das assinaturas Schnorr

Então, qual é o problema das assinaturas de Schnorr? Bem, para começar, eles tornam as transações menores. Uma assinatura ECDSA geralmente tem cerca de 72 bytes de tamanho para uma única assinatura em uma transação. As assinaturas Schnorr têm no máximo 64 bytes por assinatura. Isso representa uma economia de aproximadamente 12% em comparação com o ECDSA para cada assinatura Schnorr. Este é um benefício direto para a pessoa que usa o Schnorr, que pagará menos taxas do que um usuário ECDSA, mas também é um benefício direto para as pessoas que não usam o Schnorr, exigindo um pouco menos de dados armazenados no blockchain para processar e validar o Schnorr de outra pessoa. assinaturas.

Armazenar menos dados é sempre bom, mas o que é ainda melhor é aumentar a eficiência da validação dos dados que você precisa armazenar. Uma das propriedades interessantes do Schnorr, a linearidade da matemática por trás dele, também permite uma propriedade interessante que você deseja nos dados do Bitcoin: validação em lote. Quando seu nó recebe um bloco da rede, ele analisa cada transação individual e valida cada assinatura, uma por uma.

Esta é uma grande parte da razão pela qual a validação de blocos consome muita energia da CPU. As assinaturas de Schnorr podem ser agrupadas e validadas matematicamente de uma só vez, como se fossem juntá-las e fazer uma operação matemática em vez de várias operações individuais. Portanto, quanto mais assinaturas de Schnorr houver, maior será a economia computacional. Esta é uma grande vitória de escala para a rede.

Outra grande melhoria que Schnorr traz são os scripts com múltiplas assinaturas. Cada endereço multisig deve revelar explicitamente todas as chaves públicas individuais envolvidas em um script multisig no momento do gasto, e uma assinatura deve ser fornecida para cada chave envolvida no processo de gasto. Com as propriedades matemáticas de Schnorr, abre-se a porta para o MuSig, um padrão multiassinatura. Você pode simplesmente adicionar chaves e acabar com uma única chave pública que as chaves privadas compartilhadas por todos podem assinar usando novos protocolos de assinatura. Jonas Nick da Blockstream aferido MuSig2 leva dois minutos para um milhão participantes em um endereço multisig para assinar. A melhoria de escala para scripts de múltiplas assinaturas não pode ser subestimada.

Esse enorme avanço para scripts de múltiplas assinaturas também tem uma enorme implicação no perfil de privacidade e no custo de vários aplicativos desenvolvidos com base no Bitcoin. Os canais Lightning baseados em MuSig agora podem se misturar a todo o conjunto de anonimato de UTXOs Schnorr/Taproot em cadeia porque ninguém será mais capaz de distinguir o fato de que eles são uma saída multisig dois de dois.

Eles se misturarão e parecerão um único script de assinatura. A mesma coisa vale para qualquer UTXO multisig em geral. Isso terá muitas implicações para as pessoas que usam scripts de múltiplas assinaturas para proteger melhor seu armazenamento frio com um modelo de segurança e recuperação mais robusto do que um script de assinatura única.

Em primeiro lugar, não será óbvio que eles estão usando uma configuração multisig observando o blockchain, então isso irá, como no caso do Lightning, fazer com que eles se misturem com todo o resto. Uma vitória importante, porém, é em relação à economia: o uso de múltiplas assinaturas agora requer o fornecimento de uma assinatura separada para cada chave envolvida no eventual gasto de um UTXO. Com Schnorr/MuSig, as coisas serão compactadas em uma única assinatura para a única chave pública combinada, o que significa que gastar UTXOs multisig usando MuSig se tornará muito mais barato, pois enviará menos dados para o blockchain.

Uma última coisa interessante que as assinaturas Schnorr fazem é simplificar drasticamente a implementação das assinaturas do adaptador. Pense em uma assinatura de adaptador “criptografada” por um valor que foi adicionado ou subtraído de uma assinatura válida. Não é válido até que você reverta essa operação matemática ou “descriptografe-a” com a “chave” que foi usada para manipulá-la. Isto é possível com o ECDSA, mas como a matemática não é linear em comparação com Schnorr, é relativamente complicado e há muitas preocupações de segurança a considerar na sua implementação.

Porém, devido às propriedades lineares de Schnorr, uma assinatura de adaptador é tão simples quanto pegar um único (digamos, o número 9,300,030) e subtrair um valor dele (digamos 30). Uma vez que a parte que detém a assinatura do adaptador aprenda o valor subtraído, ela pode simplesmente adicioná-lo de volta e voila, eles terão uma assinatura válida novamente.

As implicações da raiz principal

Conforme discutido um pouco acima, Taproot na realidade é essencialmente apenas MAST, exceto que em vez de funcionar como P2SH (onde você faz o hash do script, ou no caso do MAST, a raiz Merkle do topo da árvore de script), você “ajusta” um Chave pública Schnorr pela raiz da árvore Merkle.

Os ajustes funcionam por causa das propriedades lineares de Schnorr - quando você “ajusta” uma chave pública com uma raiz Merkle (adiciona essa raiz Merkle à chave pública), então você pode simplesmente adicionar a raiz Merkle à chave privada original e gerar a chave de gastos para a nova chave pública ajustada. Ou seja, você adiciona a mesma coisa às chaves pública e privada e elas ainda são um par de chaves válido. Isto esconde a existência de uma árvore MAST, a menos que um ramo dela seja usado, mas fundamentalmente ainda é apenas uma árvore MAST, apenas uma árvore comprometida de uma forma mais eficiente e privada.

A capacidade de se comprometer com diferentes scripts de gastos em uma árvore Merkle e revelar apenas o script usado é uma enorme vitória de escalabilidade em termos de complexidade de contrato inteligente que é possível construir no Bitcoin.

Assim como o tamanho do bloco limita o número de transações por bloco, há um limite de restrição de tamanho de transação de 100 kilobytes. A única diferença é que em vez de ser uma regra de consenso, é uma regra política. Isso significa que um minerador pode extrair uma transação maior que 100 kilobytes, mas, por padrão, nenhum nó na rede retransmitirá uma transação maior do que isso para o minerador.

Isso limita inerentemente o tamanho do script usado para bloquear um Bitcoin UTXO. Mesmo com P2SH, onde o UTXO está bloqueado para um hash do script que não é revelado até que você o gaste, você ainda terá que revelar o script completo na hora certa. Taproot aumenta esse limite de escalabilidade do script, não exigindo que você revele o script inteiro ao usá-lo. Em vez de o tamanho total de todas as maneiras pelas quais você pode gastar o UTXO ser restrito ao limite de tamanho da transação, você só precisa ter certeza de que qualquer maneira de gastar um Taproot UTXO respeita essa limitação.

Também há muitos benefícios de privacidade que acompanham o Taproot. Um dos grandes benefícios de uma árvore MAST é a capacidade de criar todos os tipos de situações condicionais onde as moedas podem ser gastas por outras partes.

Imagine coisas como esquemas de herança em que, após cerca de um ano, seus filhos possam gastar suas moedas ou, no caso de você se recusar a assinar, sua esposa e um advogado tenham um caminho potencial para recuperar as moedas. Nada sobre estas condições de despesa é revelado ao público, a menos que sejam realmente utilizadas. Este processo duplo fornece negação plausível para outras partes envolvidas em diferentes ramos de gastos que você constrói quanto ao seu envolvimento naquele UTXO, bem como os protege de um ladrão ou invasor que os ataca preventivamente, sabendo que eles têm algum grau de controle sobre seus UTXOs do alvo.

No nível técnico, o Taproot também foi relativamente bem projetado. Qualquer pessoa que esteja familiarizada com Segregated Witness em qualquer nível profundo deve estar familiarizada com a versão da testemunha.

Quando o Segregated Witness foi implementado, ele criou a nova seção “testemunha” de uma transação para onde os dados da assinatura foram movidos. Os dados testemunhas tinham um sinalizador de versão para que pudessem ser atualizados para novas funcionalidades sem a necessidade de usar OP_CODEs indefinidos na camada base para novos recursos.

Na verdade, é assim que o Taproot/Schnorr foi implementado. As transações segregadas de testemunha usam a versão zero da testemunha. Quando Taproot/Schnorr for lançado em breve, eles usarão a nova versão de testemunha um para distingui-los das transações mais antigas de Segregated Witness. Da mesma forma que o SegWit introduziu versões testemunhas, o Taproot introduz a “versão tapleaf” para os tapscripts usados ​​nas árvores MAST para UTXOs usando Taproot. Isso não apenas permite que os scripts enterrados no MAST sejam atualizados sem usar novos OP_CODEs na camada base, mas também sem ter que atualizar versões testemunhas! Portanto, o Taproot foi projetado para ser o mais eficiente possível para atualização no futuro, sem limitar outras atualizações não relacionadas ao protocolo.

Taproot trará muitos casos de uso variados. Para começar, todas as cláusulas não cooperativas em um canal Lightning, como chaves de penalidade ou timelocks para permitir seu uso, podem ser enterradas em um MAST com Taproot. Ninguém jamais saberá que eles existem, a menos que precisem ser usados, obscurecendo ainda mais quais UTXOs são realmente canais Lightning ou não.

Os esquemas de herança são outro caso de uso. Imagine uma árvore Taproot estruturada de forma que depois de seis meses sem movimentar seu dinheiro, toda a sua família possa se reunir e gastar o UTXO como quiser. Então, seis meses depois, todos menos uma pessoa podem gastá-lo (então imagine se você tivesse sua esposa, dois filhos e pais como detentores das chaves, então imagine que depois dos seis meses extras, sua esposa, um filho e seus pais podem assinar , ou seus dois filhos e pais podem assinar sem sua esposa e assim por diante).

Então, seis meses depois, todos menos duas pessoas poderão gastá-lo. Eventualmente, tudo poderia se resumir a apenas uma pessoa com a ajuda de um advogado (para garantir que nenhuma travessura ocorresse) sendo capaz de gastar o UTXO.

Ou, e se você usar multisig para proteger seu armazenamento refrigerado, mas tiver apenas um local que considera seguro e previsível a longo prazo? Você poderia criar um MAST onde, eventualmente, depois de alguns anos, a chave naquele local seguro pudesse gastar essas moedas sozinha, apenas no caso de outras chaves serem perdidas ou destruídas, mas sem colocar suas moedas imediatamente em risco de roubo no presente, se isso uma chave foi comprometida.

Esta é uma atualização incrível e abrangente para o Bitcoin que está em andamento quase desde o nascimento do próprio Bitcoin, não apenas nos últimos anos em que os detalhes reais de implementação foram elaborados e implementados.

É realmente uma vitória em tantos aspectos para a escalabilidade e utilidade do protocolo Bitcoin que é difícil transmitir devido ao quão sutis e “pouco sexy” alguns deles são. Mas isso não prejudica a vitória. Então, todos apertem os cintos e se preparem para brincar com os novos brinquedos que teremos que usar em breve, porque o Taproot está chegando!

Este é um post convidado por Shinobi. As opiniões expressas são inteiramente próprias e não refletem necessariamente as da BTC Inc ou Bitcoin Magazine.

Fonte: https://bitcoinmagazine.com/technical/bitcoin-taproot-explainer