O TAPROOT ESTÁ CHEGANDO AO BITCOIN: COMO FUNCIONA, SUA HISTÓRIA E IMPLICAÇÕES

O Taproot e as assinaturas de Schnorr estarão no ar no bloco 709.632. Aqui está o que você precisa saber sobre o que isso significa para o Bitcoin.

Esta é uma tradução do texto “TAPROOT IS COMING TO BITCOIN: HOW IT WORKS, ITS HISTORY AND IMPLICATIONS”, do Shinobi, publicado originalmente na Bitcoin Magazine no dia 11 de novembro de 2021.

Tradução por Leta.

Com a palavra, o autor:

O Taproot e as assinaturas de Schnorr estão entrando no ar no bloco 709.632. Essa será uma grande conquista fundamental para continuarmos construindo no futuro. Já se passaram quatro anos desde que o Segregated Witness (SegWit) foi ao ar na rede, nossa última grande atualização de protocolo. Isso é tão longo quanto um ciclo de halving!

Pense sobre isso. Quatro anos desde a ativação do SegWit até a ativação do Taproot. Paciência lenta e metódica, como deveria ser. Mas a história de Taproot / Schnorr é muito mais antiga do que isso.

A HISTÓRIA DA TAPROOT

Alguns que já estão aqui há algum tempo podem achar isso irônico, mas a primeira menção às assinaturas Schnorr de que estou ciente 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 dos nodes menos dispendiosa computacionalmente. Em última análise, o esquema que ele estava propondo dependia das assinaturas da Schnorr.

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

Desde o início do Bitcoin, a maioria dos desenvolvedores ativamente envolvidos no Bitcoin Core queriam assinaturas de Schnorr, e sempre houve um consenso bastante sólido sobre sua superioridade em relação às assinaturas ECDSA. Na verdade, pode-se argumentar que o ECDSA foi criado especificamente porque o esquema de assinatura de Schnorr foi patenteado, e havia uma enorme necessidade de um esquema de assinatura criptográfica de código aberto não sobrecarregado 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 os usuários com assinaturas válidas quando deveriam tê-las) do que ECDSA. Usar ECDSA era 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 do Taproot dessa próxima atualização tem uma história semelhante de longa data. Não consigo encontrar a citação, mas me lembro claramente de ter visto essa frase usada por gente como Peter Todd no Bitcointalk.org por volta de 2013 ou 2014.

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

O MAST meio que ficou no limbo no ano seguinte, até que Greg Maxwell teve a ideia inicial do Taproot e a publicou na 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” em que 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 de que Taproot se baseia, ou seja, ajustar a árvore MAST para uma chave de nível superior regular que pode ser gasta sem revelar se uma “árvore Merkle” (idem) de outras condições de gasto ainda existe.

A última parte desta lição de história começa com Pieter Wiulle anunciando projetos de BIPs para as assinaturas de Schnorr e Taproot em conjunto para a mailing list em 6 de maio de 2019. Em janeiro de 2020, isso foi formalmente finalizado nos BIPs 340, 341 e 342. Deste ponto em diante, era apenas um pequeno refinamento de detalhes no nível de implementação, algum período de revisão e, em seguida, a longa batalha sobre os mecanismos de ativação. Isso nos leva ao agora, com o Taproot a poucos dias da ativação.

A IMPORTÂNCIA DAS ASSINATURAS DE SCHNORR

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

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

Essa é 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 vez, como se juntassem e realizassem 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 para a rede escalar.

Outra grande melhoria que Schnorr traz é para scripts de multisignature. 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, a porta se abre para MuSig, um padrão de multissignatura. Você pode simplesmente adicionar chaves e terminar com uma única chave pública que todos os compartilhamentos de chaves privadas podem assinar usando novos protocolos de assinatura. Jonas Nick da Blockstream constatou que utilizando MuSig2 leva dois minutos para um milhão de participantes em um endereço multisig assinarem. A melhoria do dimensionamento para scripts com várias assinaturas não pode ser subestimada.

Este enorme salto em frente para scripts multisignature também tem uma grande implicação para o perfil de privacidade e custo de vários aplicativos construídos sobre Bitcoin. Canais Lightning baseados em MuSig agora podem se misturar a todo o conjunto de anonimato dos UTXOs Schnorr/Taproot na cadeia principal porque ninguém será capaz de distinguir o fato de que eles são uma saída multisig.

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

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, permitir que eles se misturem com todo o resto. Uma vitória importante, porém, é em relação à economia: o uso de multisignature agora requer o fornecimento de uma assinatura separada para cada chave envolvida em eventualmente gastar um UTXO. Com o 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 legal que as assinaturas Schnorr fazem é simplificar drasticamente a implementação das assinaturas adaptadas. Pense em uma assinatura adaptada que é “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 “decifre-a” com a “chave” que foi usada para manipulá-la. Isso é possível com o ECDSA, mas, como a matemática não é linear em comparação com o Schnorr, é relativamente complicado e há muitas questões de segurança a serem consideradas ao implementá-lo.

Porém, devido às propriedades lineares de Schnorr, uma assinatura adaptada é tão simples quanto pegar um único número (digamos, o número 9.300.030) e subtrair um valor dele (digamos 30). Uma vez que a parte que está segurando a assinatura adaptada aprende o valor subtraído, eles podem simplesmente adicioná-lo de volta e pronto, eles têm uma assinatura válida novamente.

AS IMPLICAÇÕES DO TAPROOT

Como discutido um pouco acima, Taproot na realidade é essencialmente só o 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 do script), você “ajusta” uma chave pública Schnorr pela raiz da árvore Merkle.

O ajuste funciona 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. Isso oculta a existência de uma árvore MAST, a menos que um ramo dela seja usado, mas fundamentalmente ainda é apenas uma árvore MAST, só que uma mais eficiente e privada.

A capacidade de comprometer-se com diferentes scripts de gastos em uma árvore Merkle e apenas revelar o script usado é uma grande vitória de escalabilidade em termos de complexidade de contrato inteligente que é possível construir em 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 minerar uma transação maior do que 100 kilobytes, mas, por padrão, nenhum node de ninguém na rede retransmitirá uma transação maior do que isso para o minerador em primeiro lugar.

Isso limita inerentemente o tamanho do script usado para bloquear um Bitcoin UTXO. Mesmo com P2SH, onde o UTXO está bloqueado em um hash do script que não é revelado até que você gaste, você ainda terá que revelar o script completo na hora do gasto. O Taproot aumenta o 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 formas de gastar o UTXO ficar restrito ao limite do tamanho da transação, você só precisa se certificar de que qualquer forma de gastar um UTXO que utilize o Taproot respeita essa limitação.

Existem também muitos benefícios de privacidade que vêm junto com o Taproot. Um dos grandes benefícios de uma árvore MAST é a capacidade de criar todos os tipos de situações condicionais em que as moedas podem ser gastas por outras partes.

Imagine coisas como esquemas de herança onde depois de um ano ou mais seus filhos podem gastar suas moedas, ou no caso de você se recusar a assinar, sua esposa e um advogado têm um caminho potencial para recuperar moedas. Nada sobre essas condições de gastos é 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 envolvimento deles naquele UTXO, bem como os protege de um ladrão ou invasor que saiba que eles têm algum grau de controle sobre seus UTXOs.

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

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

Na verdade, é assim que o Taproot / Schnorr foi implementado. As transações SegWit usam a versão zero da testemunha. Quando o Taproot / Schnorr for ao ar em breve, eles usarão a nova versão de testemunha um para distingui-los das transações SegWit mais antigas. Da mesma forma que o SegWit introduziu versões testemunhas, Taproot apresenta a “versão tapleaf” para os tapscripts usados ​​nas árvores MAST para UTXOs que utilizam o Taproot. Isso não apenas permite que os scripts enterrados no MAST sejam atualizados sem usar novos OP_CODEs na camada de base, mas também sem ter que atualizar as 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.

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

Os esquemas de herança são melhorados. 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 porta-chaves, imagine que depois dos seis meses extras, sua esposa, um filho e os pais podem assinar , ou seus dois filhos e pais podem assinar sem sua esposa, e assim por diante).

Então, seis meses depois disso, todo mundo menos duas pessoas pode gastá-lo. Eventualmente, 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 ainda, e se você usar o multisig para proteger seu armazenamento em cold wallet, mas tiver apenas um lugar que considera seguro e previsível a longo prazo? Você poderia criar um MAST onde, eventualmente, após alguns anos, a chave naquele local seguro pode 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 uma chave foi comprometida.

Esta é uma atualização incrível e abrangente para o Bitcoin que está em andamento (pelo menos intelectualmente) desde quase 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 de tantas maneiras para a escalabilidade e utilidade do protocolo Bitcoin que é difícil de transmitir por conta que alguns deles são sutis e “não atraentes”. Mas isso não diminui a vitória. Assim, todos se acomodem e se preparem para brincar com os novos brinquedos que teremos que usar em breve, porque o Taproot está chegando!