Home » A grande actualização Taproot: mitos e verdades

A grande actualização Taproot: mitos e verdades

by Tim

Na semana passada, Taproot, uma das mais importantes actualizações na história da Bitcoin, foi activada. Mas o que realmente faz é difícil de compreender e não raramente deturpado. Por conseguinte, pedimos a um perito.

Na semana passada, Taproot foi activada, uma das maiores actualizações de Bitcoin de todos os tempos, que a comunidade tem estado ansiosamente à espera há anos. Mas o que é exactamente Taproot? E o que é que ele faz?

Qualquer pessoa que leia as notícias sobre Taproot com esta questão em mente, irá colher um pouco de confusão. Assim, este artigo começa com uma pequena visão geral do que os outros estão a escrever.

Quando as agências noticiosas já estão a relatar uma actualização do bitcoin …

Uma das características mais notáveis da Taproot é que é a primeira actualização Bitcoin que foi notícia para a agência de imprensa DPA. Isto explica porque de repente se encontra informação sobre Taproot em quase todos os meios, desde o Süddeutsche e FAZ até ao Wiener Standard e à Gazeta da pequena cidade. Ou melhor: desinformação.

Taproot, explica Finanzen.net, tem um “significado de longo alcance para a cadeia de bloqueio Bitcoin”. A actualização torna o Bitcoin “ainda mais ágil e flexível” e abre “o caminho para inovações tecnológicas importantes”. O FAZ e muitos outros jornais citam o relatório da DPA de que a actualização traz “mais privacidade, menos requisitos de armazenamento e custos em queda”.

Tudo isto permanece tão vago que não pode ser nem errado nem certo. Se se quiser saber mais concretamente, aprende-se muito menos, e se assim for, então de bom grado errado ou enganoso. Finanzen.net, por exemplo, diz que a Taproot “gera apenas uma chave pública para pagamentos em vez de várias chaves públicas […]”, o que, para além da confusão de termos, é, na melhor das hipóteses, apenas metade correcto. Além disso, a Taproot permite “contratos inteligentes mais complexos na cadeia de bloqueio Bitcoin”, razão pela qual a Bitcoin poderia em breve competir com o Ethereum.

Na FAZ, aprende-se que as assinaturas da Schnorr “proporcionam mais privacidade para a Bitcoin”. O jornal e a DPA pediram ao professor de cadeias de bloqueio Philipp Sandner uma declaração sobre este assunto, e ele deu a palestra de que “estas transacções Schnorr … libertam um pacote de transacções com uma única assinatura”. Mesmo um professor pode por vezes estar tão errado que não se sabe por onde começar.

A fonte de informação mais competente sobre a Taproot é a Heise. A revista IT explica que a actualização introduz o tipo de transacção “Pay-to-Taproot (P2TR)”, “que combina os conceitos de assinaturas Schnorr e ‘Merklized Alternative Script Trees'”. Mas mesmo a Heise solha quando a revista afirma que a Taproot aumenta a privacidade da transacção ou que a Schnorr lhe permite assinar uma transacção com uma assinatura agravada.

Na melhor das hipóteses, isto é meia verdade e, mais importante ainda, mostra como é difícil compreender – e explicar – uma actualização tecnicamente sofisticada como a Taproot.

Upgrade como um embrulho

Tentamos trazer um pouco de ordem ao caos Taproot. Para tal, entrámos em contacto com Mark Erhardt, também conhecido como Murch na Internet. Mark trabalha em Nova Iorque no Chaincode Labs, tendo anteriormente trabalhado para BitGo em Palo Alto. É difícil chegar mais perto dos centros de desenvolvimento de Bitcoin do que o nativo de Baden.

Mark ajudou-nos não só a compreender melhor a Taproot conceptualmente, mas também a compreender o que a actualização significa agora em termos concretos.

O que é que a Taproot está a mudar? Quais são os benefícios da actualização?

A raiz da torneira consiste, grosso modo, em dois componentes: Assinaturas Schnorr e uma árvore de guião. Ambos os componentes são independentes um do outro, mas trabalham em conjunto, e cada um deles não é fácil de compreender. Este é um dos obstáculos para compreender o que a Taproot realmente faz – e o que não faz.

Schnorr – o melhor ECDSA

As assinaturas de Schnorr são as mais fáceis de compreender. Estes, explica Mark, existiam antes do algoritmo de assinatura ECDSA utilizado pela Bitcoin.

“O processo de assinatura é super interessante, mas o inventor, Klaus-Peter Schnorr, patenteou-o. Como a taxa de patente era demasiado cara, outros criptógrafos inventaram a ECDSA para também assinarem com base em curvas elípticas. Entretanto, porém, a protecção da patente expirou”.

O ECDSA é bom, muito bom de facto, razão pela qual a Satoshi escolheu o algoritmo para Bitcoin. Mas não é tão bom como o Schnorr, e sem a protecção de patentes, provavelmente não haveria razão para alguém utilizar o ECDSA em vez do Schnorr.

A diferença mais importante reside num pequeno mas em parte crucial detalhe: “As assinaturas não são lineares no ECDSA, são em Schnorr”, explica Mark. “Se um esquema de assinatura for linear, pode agregar múltiplas assinaturas para que o agregado lhe permita verificar. Não se pode fazer isso com esquemas não lineares, como o ECDSA”.

Assim, teoricamente, o que a FAZ e a Heise afirmam é verdade: pode-se agregar todas as assinaturas de uma transacção numa só através da Schnorr. Actualmente, se uma transacção tem muitos inputs – por isso combina muitas moedas – tem de assinar cada input e escrever cada assinatura na cadeia de bloqueio. Isso é responsável por muitos dos dados da transacção. A Schnorr poderia de facto mudar isto.

Poderia! Porque “infelizmente, esta agregação não chegou à actualização da Taproot”, Mark esclarece. “Isso teria exigido definições e discussões adicionais, por isso decidiram fazê-lo mais tarde”

Assinaturas secretamente agregadas

No entanto, agregar as assinaturas Schnorr com Taproot já é possível agora. Mas apenas não para transacções normais, apenas para transacções de vários dígitos. Multisig significa que duas ou mais partes têm de assinar uma transacção para que as moedas possam ser emitidas a partir de um endereço especial (endereço multisig).

“Digamos que criamos juntos uma carteira onde só podemos gastar dinheiro se ambos assinarmos. Isso seria um “2 por 2 multisig”. Graças à Taproot, podemos agregar as nossas chaves públicas: Dá-me a sua chave pública, eu combino-a com a minha, e o resultado é indistinguível de um endereço normal. Portanto, não se pode dizer que é uma carteira partilhada”.

Este “não poder dizer” é a razão definitiva pela qual se diz que Taproot melhora a privacidade.

Anteriormente, os endereços multisigentes podiam ser facilmente reconhecidos. Começaram com um três, em vez de um como os endereços tradicionais. O SegWit suavizou um pouco esta situação, uma vez que um formato de endereço SegWit também começa com um 3. Ainda assim, os diferentes tipos de endereços criam diferenças que minam parcialmente a privacidade da Bitcoin.

Com a Taproot, tais diferenças podem ser completamente niveladas. Independentemente das condições de saída que um endereço encarna – uma assinatura, múltiplas assinaturas, timelocks, contratos inteligentes – todos têm o mesmo aspecto.

Mas as assinaturas da Schnorr por si só não são suficientes para isto. Para estes só são eficazes para construções multisiguais simples: “2 de 2”, “3 de 3”, e assim por diante. Na prática, contudo, outros modelos são mais populares, nomeadamente as chamadas assinaturas de limiar, tais como “2 de 3”: Um terceiro tem uma chave de reserva e entra se outra chave for perdida, ou arbitra se os outros dois discordarem.

Em tais modelos, a agregação por assinaturas da Schnorr não funciona. Portanto, nesta altura, precisamos de falar sobre a segunda parte de Taproot: a árvore de guiões.

Uma árvore de scripts para os outros casos

O antigo empregador da Mark, fornecedor de carteiras BitGo, oferece um clássico “2 de 3″ construção: há três chaves. Uma é detida pelo cliente, outra pela BitGo, e a terceira é uma cópia de segurança bem segura, armazenada a frio. Destas três chaves, duas são necessárias para enviar uma transacção, que são normalmente as do cliente e BitGo.

“Há uma expectativa quanto às duas chaves que serão utilizadas. Isto pode agora ser servido com assinaturas agregadas da Schnorr. Assim, formamos uma saída P2TR com as chaves de si e de BitGo, e quando o caso normal ocorre, podemos assinar com uma assinatura agregada”.

Esta forma de assinar transacções por duas partes é a forma mais elegante, simples e bonita de o fazer. Em comparação, o método actual usando endereços “P2SH” (pay-to-script hash) é monstruosamente complexo.

Mas e se se tratar do caso de apoio? Se eu perder a minha chave e o BitGo assinar com a chave de reserva? Ou se o BitGo falhar e eu tiver de trazer a chave de segurança em jogo?

“Estes outros caminhos, não previstos, são tecidos como folhas na árvore de guião que a Taproot introduziu”, explica Mark. E, claro, esta explicação grita para ser ela própria explicada.

Das folhas à raiz

Uma árvore de scripts é basicamente “apenas” uma árvore Merkle ou hash de scripts. Mas o que é uma árvore de haxixe?

Uma árvore de haxixe é um arranjo especial de um grande número de hashes. Por exemplo, digamos que temos transacções de quatro bitcoin e as temos de as ter. Então teríamos quatro hashes. Numa árvore de haxixe, são chamadas as “folhas”.

O objectivo do exercício é avançar das folhas para os ramos até à raiz da árvore de haxixe. Para o fazer, primeiro juntamos o primeiro e o segundo hash juntos e hash isso. Fazemos o mesmo com o terceiro e o quarto. Os dois hashes que temos como resultado – os ramos – também temos hash. Isto dá-nos a raiz: um hash que representa uma multidão de hashes.

Esta árvore de hash parece uma árvore de cabeça para baixo: A coroa está na parte inferior, a raiz na parte superior. Imagem de wikipedia.org, licença: Creative Commons

Esta árvore de hash parece uma árvore de cabeça para baixo: A coroa está na parte inferior, a raiz na parte superior. Imagem de wikipedia.org, licença: Creative Commons


O que faz uma tal raiz? Permite um único haxixe para provar uma variedade de dados. Um exemplo é um bloco Bitcoin: os mineiros tiram uma grande quantidade de transacções – geralmente alguns milhares – e formam a raiz da árvore de haxixe a partir deles. Esta raiz é a base da mineração, e permite a qualquer pessoa verificar se um bloco é válido.

No scriptbaim introduzido por Taproot, cada “folha” é uma forma de gastar as Bitcoins – um guião. O endereço multisig mencionado acima contém não só o agregado de duas chaves públicas, mas também a raiz da árvore de scripts.

Agora, se o caso não esperado acontecer de eu assinar com a minha chave e com a chave de segurança porque BitGo falha, o seguinte acontece, Mark explica: “Eu revelo o guião correspondente, que é armazenado numa folha da árvore do guião. Para provar que o endereço original codifica estas condições de saída, revelo os hashes de outras folhas e ramos para que a raiz possa ser reconstituída. Depois satisfaço o guião contido na folha com as assinaturas das duas chaves”.

Assim, temos um procedimento em que as transacções de multisigrações são normalmente – quando o caso esperado ocorre – mais elegantes, mais simples e também mais privadas. Só nos casos não previstos é que a árvore do guião entra em acção. O resultado é igualmente complexo como o método P2SH – mas é um pouco mais privado.

Porque com P2SH, todo o guião é precipitado, o qual contém todas as possibilidades de como as moedas devem ser gastas. Para poder escrever uma transacção válida, tenho de mostrar o texto puro do guião. Assim, tenho de tornar públicas as chaves públicas que estão envolvidas, mesmo que não sejam de todo utilizadas.

Com P2TR, por outro lado, é suficiente se eu escrever a opção que realmente ocorre em texto simples na transacção. Todas as outras opções permanecem ofuscadas.

O avanço para multisig

Não há necessidade de debater se Taproot é elegante. E é. A árvore de scripts é uma adição útil às assinaturas da Schnorr. É compreensível que um programador como Mark esteja entusiasmado com a Taproot e não possa esperar que a actualização chegue em todas as carteiras.

Mas aqueles para quem a elegância técnica não é um fim em si, mas um meio, são agora susceptíveis de perguntar: qual é o sentido em termos reais? Então, o que pode a Bitcoin fazer melhor agora com a Taproot do que antes?

“Multisig é um padrão muito mais seguro para gerir dinheiro”, diz Mark. “Pode-se criar backups, e tornar mais difícil gastar dinheiro. Torna-o menos vulnerável”.

Até agora, no entanto, os métodos multisig tinham inconvenientes significativos: eram frequentemente complexos, tanto para o utilizador como para o promotor, limitavam a privacidade e custavam mais em taxas. Todas estas desvantagens desaparecem com a Taproot. “Você dá menos informação privada, revela menos sobre a sua configuração, e pode fazer mais com menos dados sobre a cadeia de bloqueio”.

Mark espera que a Taproot ajude a Multisig a ultrapassar. Que mais carteiras irão adoptar Multisig, haverá melhores padrões e que a experiência do utilizador, que actualmente ainda é muitas vezes grotty, irá melhorar.

O que a Taproot não faz

Apesar de todo o entusiasmo, Mark adverte contra expectativas exageradas e falsas. O que nos leva de volta ao ponto de partida. Sobre o relatório da DPA e a sua interpretação nas salas de imprensa.

“Por vezes diz-se que a Taproot traz a DeFi para Bitcoin porque permite contratos inteligentes. Isto está errado. Os contratos inteligentes já existem, e tudo o que a Taproot pode fazer era possível antes – era apenas mais complicado, mais caro e menos privado”.

Há também alguns conceitos errados que circulam sobre privacidade com a Taproot. “Ontem li num grande jornal alemão que Bitcoin está a tornar-se mais anónimo por causa do Taproot. Isso também não é verdade. É verdade que já não se pode ver se uma ou mais partes estão a assinar. Mas o endereço continua a ser pseudónimo e ainda se pode ver que moedas estão a ser emitidas. “

Os analistas de cadeias de bloqueio não terão problemas em analisar e agrupar carteiras e endereços como antes, mesmo depois de Taproot. “Aprende-se um pouco menos sobre a configuração sob o capô. Quer se trate de um endereço normal, de um canal Relâmpago ou de uma configuração multisig, já não se consegue vê-lo. Mas a rastreabilidade geral do fluxo monetário permanece a mesma: “

Agora é a vez do ecossistema

Como é tão frequentemente o caso com Bitcoin, leva algum tempo para que uma actualização chegue às carteiras e aos utilizadores. Basta pensar no SegWit. A actualização demorou muito tempo a ser implementada numa grande proporção de transacções, e ainda mais tempo para que o apoio a endereços bech32 fosse amplamente implementado.

Murch espera que seja mais rápido para Taproot. “As carteiras BitGo já podem receber moedas com Taproot. Isto mostra que, desta vez, pode ser mais rápido”.

Para compreender do que se trata, e porque não é simples, é necessário conhecer mais alguns detalhes técnicos. Com o risco de o sobrecarregar, precisamos de falar sobre os formatos de endereço envolvidos.

  • Os endereços padrão são chamados “Pay-to-Public-Key-Hash” (P2PKH) e começam com um 1.
  • Os endereços “Pay-to-Script-Hash” (P2SH) de que já falámos começam com um 3. Estes foram utilizados para contratos multisig e outros contratos inteligentes como os time-locks.
  • SegWit foi também inicialmente construído sobre endereços que começaram com um 3: Os “Endereços de SegWit Aninhados” ou – desculpem: “Pagar ao Roteiro Hash Pagar ao Testemunho Hash de Chave Pública” (P2SH-P2WPKH). Aqui, mais ou menos o guião para o SegWit foi hashed e transferido para um endereço P2SH. Isto permitiu que o SegWit fosse introduzido de uma forma menos disruptiva.
  • Os endereços nativos SegWit-v0, ou Pay to Witness Public Key Hash (P2WPKH) endereços, que tecnicamente funcionam de forma mais eficiente, utilizam o formato bech32. Esta norma recentemente desenvolvida parece completamente diferente, os endereços são mais longos, consistem apenas em letras minúsculas e começam com “bc1”.

Pay-to-Taproot (P2TR) também usa o padrão bech32. Contudo, existe uma ligeira diferença na geração dos endereços, razão pela qual os endereços v0 utilizados até à data não são compatíveis. Isto é intencional para evitar que alguém perca dinheiro.

“Em preparação para Taproot, descobrimos que algumas carteiras estavam a ignorar a versão Witness em bech32 endereços e sempre a definir as saídas como Native-Segwit-v0”, explica Mark. “Se uma destas carteiras tivesse enviado dinheiro para um endereço P2TR, o script P2TR teria sido codificado na saída, mas teria sido necessário o preenchimento de um script P2WPKH para gastar por causa do erro de versão. O destinatário não teria podido gastar o dinheiro”.

Para Mark, é portanto importante que o maior número possível de carteiras permita primeiro o envio de dinheiro para os endereços Taproot. Porque até isto ser amplamente possível, será sempre desvantajoso para os utilizadores utilizar estes endereços.

Os principais criadores fizeram o seu trabalho. Mas o trabalho para o ecossistema está apenas a começar neste ponto.

Related Posts

Leave a Comment