Por que a Taproot é importante para o futuro da Bitcoin e da Ledger?
Suporte de raiz axial na Stack da Ledger
A Bitcoin está evoluindo e a Ledger sempre apoiou essa evolução desde o primeiro dia. O protocolo Bitcoin é muito estável e não evolui significativamente ao longo do tempo, o que faz parte da proposta de valor da Bitcoin. No entanto, isso não significa que o protocolo Bitcoin esteja congelado para sempre.
Desde sua primeira implementação em 2009, a Bitcoin passou por várias mudanças, o que a tornou mais eficiente e escalável.
Uma das primeiras mudanças foi o limite de 1MB por bloco em outubro de 2010, pelo próprio Satoshi. Após este período, a Bitcoin começou a se organizar com o famoso Bitcoin Improvement Protocol (BIP). O BIP possibilitou muitas evoluções até a atualização do SegWit, que foi a última atualização do protocolo Bitcoin em 2017.
A atualização do protocolo SegWit trouxe várias inovações importantes, incluindo transações menores (portanto mais baratas), e resolveu os famosos problemas de maleabilidade nas assinaturas de transações.
No domingo, 14 de novembro de 2021, a partir do bloco 709.632, a Bitcoin foi atualizada para ativar a atualização da Taproot.
A Taproot aborda os desafios da Bitcoin em termos de escalabilidade, privacidade e transparência; todos os fatores que poderiam impulsionar a evolução da rede Bitcoin. Isto é incrivelmente importante, mas é preciso lembrar que não é tão simples quanto uma solução uniforme para todos os desafios da Bitcoin. Ao contrário, a atualização da Taproot é composta de vários componentes que trabalharão em uníssono para levar a rede Bitcoin a novas alturas, o que é um momento significativo para toda a comunidade da blockchain. Vamos examinar cada um dos componentes críticos da Taproot para obter o quadro completo.
A atualização da Taproot inclui 3 melhorias principais:
- Assinaturas Schnorr
- Árvores de Script Alternativo Merkleizadas (MAST)
- Pay 2 Taproot
1. Assinaturas Schnorr
Esta evolução é bastante importante, pois introduz um novo esquema de assinatura para Transações com Bitcoin. Se você não está familiarizado com estes termos, deixe-me dar-lhe uma pequena introdução à criptografia assimétrica. A criptografia assimétrica é um processo que utiliza um par de chaves: chave pública e privada. Sua aplicação mais interessante é a Assinatura Digital. É um processo onde você pode provar que conhece sua chave privada sem revelar a chave privada, enquanto qualquer pessoa com sua chave pública pode verificar a prova. Veja esta imagem abaixo:
Processo de assinatura digital
Vamos voltar um pouco na história por um momento. A criptografia assimétrica foi descoberta publicamente pelo famoso Diffie, Hellman, e depois Merkle, nos anos 70. Então, no final dos anos 70, Rivest Shamir e Adleman (RSA) inventaram o famoso sistema criptográfico RSA que ainda é amplamente utilizado hoje. Na década de 1980, a Criptografia Curva Elíptica (ECC) foi descoberta por Koblitz e Miller. O ECC tem muitas vantagens sobre a RSA, tais como cálculos e transferências de dados que são mais eficientes para o mesmo nível de segurança. O ECC, ao contrário do RSA, está cheio de variações: campo base, curvas e algoritmos de assinatura…
Agora, vamos nos concentrar nos algoritmos de Assinatura. A assinatura Schnorr foi inventada por Claus-Peter Schnorr nos anos 80. Seu algoritmo de assinatura é muito mais simples do que qualquer outro, dá uma melhor propriedade de segurança e é linear. Isso significa que é possível aproveitar essa propriedade para implementar o Threshold ou criptografia multi-assinatura de forma bastante fácil e segura (cf. Musig2). Ao contrário das carteiras multi-assinatura tradicionais (PSBT), onde cada uma das partes tem que adicionar uma assinatura separada à mesma mensagem, isto lhes permitirá participar de um protocolo interativo para produzir conjuntamente uma única assinatura, tornando a carteira multi-assinatura tão barata e eficiente quanto as carteiras de assinatura única, e melhorando a privacidade ao mesmo tempo.
A assinatura Schnorr é linear
Então aconteceu o impensável com a Bitcoin. Schnorr fez a pior coisa que você pode fazer (isto, e alegando a quebra da RSA sem nenhuma prova): PATENTEOU sua invenção.
Assim, as assinaturas Schnorr não foram utilizadas e o ECDSA (Algoritmo de Assinatura Digital de Curva Elíptica) foi especificamente projetado para contornar a patente. ECDSA é o padrão que é usado atualmente na Bitcoin e na maioria das outras moedas criptográficas.
Quando você olha para as equações de ECDSA, ele realmente se parece com um hack em torno da equação de Schnorr. Em 2008, mais de 20 anos após a invenção, a patente expirou. Em 2008, o misterioso Satoshi estava terminando o projeto da #bitcoin. Mas por causa da patente, a assinatura de Schnorr não foi padronizada. Assim, a ECDSA foi escolhida para #bitcoin como um algoritmo padronizado e amplamente utilizado. Entretanto, o EdDSA foi inventado, e pode ser visto como uma variação da assinatura Schnorr, como é usada atualmente em Polkadot, Cardano e Stellar sobre Curva25519. 30 anos após a criação desta patente, a assinatura de Schnorr pode agora ser utilizada em uma das aplicações de maior escala: Bitcoin. É uma grande notícia, mas perdemos 30 anos de uso por causa de uma patente tola.
2. MAST (Árvore de Script Alternativo Merklizada)
A atualização Taproot integra outra melhoria aos scripts chamados: Árvore de Script Alternativo Merklizada ou MASTs, que já foi proposto a partir de 2013, mas nunca chegou ao protocolo Bitcoin. Cada quantidade disponível de Bitcoin vem com um script que especifica quais condições precisam ser atendidas para que se possa gastar essas moedas. No caso mais simples, a condição é parecida: "Alice é dona dessas moedas", que é o tipo de declaração que as assinaturas criptográficas podem provar. Entre os scripts mais simples, temos o pay-to-pubkey-hash. No entanto, condições mais complexas são possíveis, por exemplo: "Dois dentre Alice, Bob e Charlie devem assinar", chamado de duas de três assinaturas múltiplas, ou "Bob assina, mas duas semanas devem passar primeiro", chamado de "timelock", ou "um certo dado secreto com hash H deve ser revelado", chamado de hashlocks.
Contratos mais complexos podem ser compostos pela combinação de várias dessas condições simples; por exemplo, a própria rede lightning utiliza contratos que combinam duas de duas assinaturas múltiplas, bloqueios de tempo e hashlocks! O problema com o uso de contratos com um grande número de condições de gastos alternativas é que o tamanho do script continua crescendo mais, uma vez que tais condições são adicionadas! Na verdade, mesmo que apenas uma dessas condições seja utilizada, a totalidade do script deve ser revelada. Que desperdício! tambores, por favor... finalmente aí vêm os MASTs! Utilizando uma construção criptográfica bem conhecida chamada Merkle trees, é possível codificar todas as condições de gastos possíveis em um único resumo breve (um hash, normalmente de 32 bytes), de tal forma que é possível revelar apenas uma dessas condições de gastos.
Isso traz uma enorme economia em relação à quantidade de espaço utilizado por esses contratos complexos, que agora poderiam ter dezenas ou centenas de condições de gastos, com pouco custo adicional! Além disso, somente as partes envolvidas no contrato conhecerão todas as condições de gastos possíveis e um observador externo só conhecerá a condição de gastos única que foi realmente utilizada, o que também é uma grande vitória para a privacidade.
3. Pay-2-Taproot (P2TR)
Finalmente, a atualização da Taproot traz um novo tipo de script de transação, chamado Pay-2-Taproot. Isto permite a combinação da assinatura Schnorr e MAST em uma única transação. Os tipos de transação anteriores facilitavam para um observador externo distinguir se algumas bitcoins eram bloqueados usando uma única chave, ou através de um script mais complexo. Ao explorar as propriedades das assinaturas Schnorr, os endereços P2TR permitem a combinação de assinaturas e scripts juntos, escondendo o MAST dos scripts dentro de uma chave pública. Portanto, as mesmas moedas poderiam ser gastas com uma assinatura simples correspondente a essa chave pública, chamada Key Path Spend, ou com um dos scripts no MAST, se houver algum. Ninguém jamais saberá que os scripts estavam lá, se eles não forem usados ao gastar as moedas!
Suporte de Bitcoin na stack do Ledger
Nos últimos meses temos trabalhado duro para preparar o apoio a esta atualização do protocolo. Aproveitamos esta oportunidade para re-fatorar uma grande parte da nossa stack técnica aqui na Ledger.
Quando você interage com o protocolo Bitcoin dentro do Ledger Live, vários componentes estão envolvidos.
Sincronizando sua conta Bitcoin na Ledger
A carteira física da Ledger precisa ter o aplicativo Bitcoin instalado. Este aplicativo deriva sua chave privada Bitcoin, chave pública e endereços a partir de sua semente. Ela compartilha sua chave pública estendida Bitcoin para a Ledger Live. A Ledger Live inclui uma biblioteca nativa que é responsável por derivar seus endereços do xpub, para sincronizar seu histórico de transações com a API do Ledger Explorer. Esta API é um enorme indexador da blockchain Bitcoin e permite que você tenha sua conta Bitcoin sincronizada rapidamente. É intensamente utilizada pelos usuários do Ledger com várias centenas de milhões de solicitações por dia.
Envio de Bitcoin
Quando você quer enviar um Bitcoin para alguém como Alice de nosso exemplo anterior, a Ledger Live garante que você esteja em sincronia com a blockchain, então ela cria a carga útil que contém o script de seus gastos. Em seguida, ela envia essa carga para sua carteira física através de USB ou Bluetooth. O aplicativo Bitcoin analisa a carga útil, verifica se está correta, se o endereço de alteração é seu e então exibe ao usuário as informações importantes de forma legível. Assim que você consentir, o aplicativo Bitcoin solicitará a assinatura do SO da carteira física da Ledger. Esta assinatura é uma assinatura ECDSA para contas Segwit e assinatura Schnorr para contas Taproot. A assinatura é enviada à Ledger Live e ao Libcore que a encaminhará ao Ledger Explorer API encarregado de colocá-la no mempool. O TX está então pronto para ser minerado.
Reformulação completa do nosso suporte Bitcoin
Ao longo de 2021, reformulamos todos esses componentes-chave:
Os exploradores foram atualizados para lidar com a carga sempre crescente que encontram
Nós reformulamos nossa implementação de uma stack de C++ para JavaScript para confiar mais no ecossistema. Você pode revisar nosso GitHub aqui
O Aplicativo Bitcoin foi reformulado a fim de apoiar novos processos de uso, incluindo o Taproot. Um post dedicado será feito no blog em breve.
Agora na Ledger Live, é possível fazer:
- Enviar para um endereço Taproot
- Criar uma conta Taproot
- Receber em uma conta Taproot
- Enviar Bitcoin do endereço Taproot
Para ser mais preciso, o suporte inicial da Ledger permite o envio para qualquer endereço Taproot enquanto a implementação da conta está focada em contas de uma chave única BIP-86 em conformidade com o BIP-86. Seguirá um suporte mais reforçado
Com as novidades do Ledger
Este é um momento emocionante para a Bitcoin e sua atualização Taproot é significativa para a comunidade e para a indústria de criptografia como um todo. Embora esta atualização não permita que NFTs ou outros tipos de tokens prosperem no ecossistema Bitcoin (não era seu objetivo em primeiro lugar), ela permitirá uma melhor utilização das propostas de valor do núcleo Bitcoin: armazenar valor e gastá-lo.
Estão ocorrendo algumas discussões iniciais sobre a ampliação das capacidades do script Bitcoin e poderiam trazer mais processos padrão de uso de DeFi para os portadores de Bitcoin. Isto aumentará seu apelo geral para milhares de desenvolvedores cuja missão é preparar o caminho para a inovação contínua, segurança de alto nível e tempos de processamento mais rápidos. Estamos entusiasmados em anunciar o apoio da Taproot na Ledger e continuaremos a apoiar a Bitcoin e sua adoção, fornecendo o mais alto nível de segurança para você holdar e usar seu Bitcoin.
Leia nossos artigos da Ledger Academy sobre a Taproot.
Chefe de Tecnologia
Engenheiro da Bitcoin
Artigo escrito por Ledger e traduzido para o português por Rafael Ojeda
Você pode encontrar o texto original aqui
Top comments (0)