Autor: Fu Shaoqing, SatoshiLab, Estúdio BTC Ilha Universal
1 Introdução
Durante o estudo da tecnologia Bitcoin, o autor percebeu que compreender SegWit, Taproot e TaprootAssets sob a perspetiva da evolução da testemunha segregada facilita o entendimento e domínio do seu desenvolvimento. Isto também permite uma melhor compreensão do protocolo Taproot Assets do Lightning Network Lab, do papel do Universe, das funcionalidades que o protocolo TaprootAssets pode realizar e do seu potencial futuro. Com este conhecimento, é possível desenhar produtos mais adequados para os utilizadores.
A leitura deste artigo requer dois ângulos de reflexão importantes: a expansão de capacidade do Bitcoin e a expansão de funcionalidades do Bitcoin.
A expansão de capacidade refere-se ao aumento do volume de dados que o Bitcoin pode utilizar e gerir, inicialmente limitado ao tamanho do Bloco, posteriormente à capacidade total de dados geridos pelo Bitcoin. O limite máximo de expansão de capacidade é a gestão de um espaço de dados infinito;
A expansão de funcionalidades refere-se ao aumento da capacidade de execução de instruções de script do Bitcoin, sendo o limite máximo a obtenção de uma capacidade de programação Turing-completa.
Toda a história de desenvolvimento do Bitcoin é a história da expansão de capacidade e de funcionalidades, incluindo várias forquilhas do Bitcoin, bem como explorações no OP_RETURN e as três grandes atualizações de versão da testemunha segregada.
Os diagramas detalhados das três versões podem ser ignorados pela maioria dos leitores; foram incluídos pelo autor para um entendimento mais profundo da tecnologia, mas a sua omissão não prejudica a leitura.
Os protocolos BIP mencionados no artigo estão assinalados com datas, para que o leitor possa perceber o ciclo temporal desde a conceção até à implementação em ambiente de produção, e assim avaliar a dificuldade de realização da tecnologia. Mais importante ainda, as datas de criação e ativação dos três grandes protocolos de testemunha segregada permitem observar o padrão de desenvolvimento, facilitando a previsão do futuro. Para equipas que desenvolvem produtos baseados nestas tecnologias e protocolos, isto serve de referência para escolher o momento certo de participação. Participar demasiado cedo pode resultar em insucesso devido à imaturidade tecnológica, tornando-se “pioneiros sacrificados”; participar demasiado tarde pode significar perder oportunidades, tornando-se “espectadores”. O autor considera que o melhor momento é pouco antes de entrar na fase de disponibilidade. Este juízo é frequentemente baseado em critérios temporais e técnicos.
# 1.1 Negociações iniciais (sem testemunha segregada)
Negociação definida no White Paper (modelo de negociação mais simples)
![] ( https://img-cdn.gateio.im/social/moments-b 1 d 1 e 13125 aa 4168 cb 4 b 94759 c 9 f 4386)
A negociação Bitcoin mais básica permite múltiplas entradas e dois outputs. Um dos outputs é o troco para si próprio, o outro é a transferência para terceiros. (Nota: a diferença entre o total das entradas e o total dos outputs é a Taxa de negociação)
A maioria das negociações tem 2 outputs, mas há cenários com apenas um output, resumidos abaixo:
![] ( https://img-cdn.gateio.im/social/moments-eb 2838590 b 599622064 e 59 c 7164 e 4672)
Para ilustrar melhor a diferença, utilizamos um exemplo com 2 entradas e 2 outputs. (Outro motivo é que as fontes consultadas pelo autor fornecem este tipo de imagem, evitando redesenhar. Preguiça ^_^)
Este tipo de comparação visual facilita a compreensão?
![] ( https://img-cdn.gateio.im/social/moments- 3 bd 23 e 4224 babcd 8 d 070 dea 206 e 8 b 1 e 8)
Comparação entre o exemplo de negociação tradicional e o diagrama de negociação Segwit
# 1.2 Exploração no OP_RETURN
Porque abordar o OP_RETURN ao falar de testemunha segregada? Porque é uma exploração anterior à testemunha segregada, ajudando a entender a sua origem.
OP_RETURN é um Código de operação usado para terminar o script e devolver o valor do topo da pilha. Este Código de operação é semelhante à função de retorno nas linguagens de programação. Na história do Bitcoin, a funcionalidade do OP_RETURN foi modificada várias vezes, sendo atualmente usada principalmente para armazenar dados no registo. O OP_RETURN tornou-se um mecanismo importante para armazenar dados arbitrários na cadeia.
Inicialmente, o OP_RETURN servia para terminar antecipadamente a execução do script, apresentando o resultado como o item do topo da pilha. Este Código de operação tinha uma vulnerabilidade facilmente explorável, rapidamente corrigida por Satoshi Nakamoto.
Alterações adicionais à funcionalidade do OP_RETURN
Na atualização v0.9.0 do Bitcoin Core, o script “OP_RETURN output” tornou-se um tipo de output padrão, permitindo aos utilizadores anexar dados a “outputs de negociação não gastáveis”. O limite inicial de dados era de 40 bytes, posteriormente aumentado para 80 bytes.
Armazenar dados na blockchain
Alterar o OP_RETURN para devolver sempre falso teve um efeito interessante. Como nenhum Código de operação ou dado é avaliado após o OP_RETURN, os utilizadores começaram a usar este Código de operação para armazenar dados de qualquer formato.
Durante o período do Bitcoin Cash (BCH), de 1 de agosto de 2017 a 15 de novembro de 2018, o comprimento dos dados anexados ao output OP_RETURN foi expandido para 220 bytes, permitindo aplicações inovadoras na blockchain, como publicação de conteúdos em redes sociais descentralizadas.
No BSV, o limite de 220 bytes foi mantido por algum tempo. Em janeiro de 2019, como o OP_RETURN termina o script sem validação de Códigos de operação subsequentes, os nós não verificam se o script está dentro do limite máximo de 520 bytes. Assim, os operadores de nós decidiram aumentar o volume máximo de negociação para 100 KB, dando aos programadores mais liberdade para inovar e armazenar dados maiores e mais complexos no registo Bitcoin. Houve até quem armazenasse um site inteiro no registo BSV.
Apesar das melhorias, o OP_RETURN continua limitado. As alterações feitas não permitiram uma evolução técnica significativa na arquitetura (continuando limitado ao Bloco de 1M), levando ao desenvolvimento da testemunha segregada. As três atualizações de versão ilustram a eficácia da testemunha segregada na expansão de capacidade e funcionalidades.
# 1.3 Diagrama comparativo das negociações iniciais e das três versões da testemunha segregada
Para facilitar a compreensão da história da testemunha segregada no Bitcoin, apresentamos no início do artigo um diagrama comparativo dos quatro estágios.
![] ( https://img-cdn.gateio.im/social/moments-c 2 d 61 a 4507 ac 2 e 8 aa 7 c 743 d 6 e 938650 e )
2 Primeiro versão da testemunha segregada: Segwit
# 2.1 Introdução e protocolos relacionados
Testemunha segregada, ou Segregated Witness (SegWit), foi proposta por Pieter Wuile (programador principal do Bitcoin, cofundador da Blockstream) em dezembro de 2015, originando o BIP 141. SegWit resolve três problemas principais (ver explicação abaixo), sendo os dois primeiros focados em segurança e desempenho, e o terceiro, que mais impacta novas tecnologias, aumenta indiretamente a capacidade do Bloco (ver conceito de Block weight abaixo), preparando o terreno para a expansão de capacidade do Bitcoin e para o reforço subsequente com Taproot (segunda versão da testemunha segregada).
Protocolos relacionados:
BIP-141: Segregated Witness ( Camada de consenso ) / 2015-12-21
BIP-143: Verificação de Assinatura de Negociação para o Programa Witness versão 0 / 2016-01-03
BIP-144: Segregated Witness ( Serviços Peer ) / 2016-01-08
# 2.2 Origem e função
Principais problemas resolvidos pela testemunha segregada:
-
Problema de maleabilidade de negociação (transaction malleability).
-
No SPV, a transmissão da Assinatura da negociação torna-se opcional, reduzindo o volume de dados transmitidos na prova de Merkle.
-
Aumento indireto da capacidade do Bloco.
Os dois primeiros focam-se em segurança e desempenho, sendo o terceiro o mais relevante para novas tecnologias, ao aumentar a capacidade do Bloco e preparar o terreno para o reforço subsequente com Taproot.
Apesar do aumento indireto da capacidade, a testemunha segregada continua sujeita ao limite de tamanho do Bloco. O limite do Bloco Bitcoin é de 1 MB; como os dados witness não estão incluídos neste limite, para evitar abusos, foi introduzido o conceito de peso do Bloco (Block weight):
Block weight = Tamanho base * 3 + Tamanho total
Tamanho base: tamanho do Bloco sem dados witness
Tamanho total: tamanho do Bloco serializado conforme BIP 144 (em bytes), incluindo dados base e witness.
A testemunha segregada limita Block weight <= 4 MB.
A testemunha segregada também permite a expansão de capacidade do Bitcoin via Lightning Network, não detalhada aqui.
# 2.3 Análise detalhada dos princípios
A tecnologia SegWit trouxe três mudanças importantes ao Bitcoin:
- Alteração da estrutura da negociação;
- Aumento do tamanho do Bloco;
- Novo formato de Endereço Bitcoin.
(1) Estrutura da negociação conforme o diagrama:
![] ( https://img-cdn.gateio.im/social/moments- 656 dc 57 a 1 fc 9 d 42 b 81 e 3 e 9 f 2381 e 397 f )
Comparando com o diagrama original da negociação Bitcoin, foi adicionada a parte Witness, que contém o código de desbloqueio. Os dados Witness são armazenados fora do Bloco de 1 MB, numa área de dados expandida.
Diagrama mais detalhado dos dados de negociação Segwit:
![] ( https://img-cdn.gateio.im/social/moments- 1411673 aa 66 cdf 278 e 69966820 f 6 d 862)
Diagrama detalhado da negociação SegWit
(2) Tamanho da negociação
![] ( https://img-cdn.gateio.im/social/moments- 17 aada 02 e 03 d 03 cf 6029 fe 22336 f 410 c ) Aumento do tamanho do Bloco
![] ( https://img-cdn.gateio.im/social/moments- 30 d 5482 c 73883 e 5 a 2 e 13 b 4 fb 03 ed 4 c 5 a )
Com a alteração da estrutura da negociação e o conteúdo do BIP-141, vemos que o Bloco Bitcoin pode ser expandido até 4 MB, sendo 1 MB para dados de negociação base e 3 MB para dados Witness.
(3) Formato de Endereço da testemunha segregada
SegWit utiliza dois novos scripts de bloqueio, P2WPKH e P2WSH, originando novos Endereços codificados em Bech32.
Formato de codificação Bech32:
![] ( https://img-cdn.gateio.im/social/moments- 3 ec 5 d 37 f 2 e 39 d 77658 c 7 b 9512 ba 50803)
Explicação dos scripts de bloqueio P2WPKH e P2WSH, incluindo exemplos de Endereço Taproot (segunda versão da testemunha segregada):
![] ( https://img-cdn.gateio.im/social/moments-c 354 bfe 70 bd 53 cd 2 ab 07357 bbc 01 d 9 b 5)
Script de bloqueio
P2WPKH
![] ( https://img-cdn.gateio.im/social/moments-d 65 edd 35659 bfd 5 a 1 ea 10211 c 40 c 0474)
Os 20 bytes de hash da Chave pública correspondem ao formato original do Endereço Bitcoin.
P2WSH
![] ( https://img-cdn.gateio.im/social/moments- 621 e 4 c 57 b 92388 a 80 e 0 db 1 c 804 f 739 b 5)
wTXID Commitment
![] ( https://img-cdn.gateio.im/social/moments-c 9954 be 7248 a 41 edd 627 bae 7 d 2 f 27 cb 4)
Todos os IDs de negociação (wTXID) na área witness formam uma raiz hash via Árvore de Merkle, submetida ao coinbase, conforme ilustrado.
Diagrama do princípio de formação do wTXID de uma negociação witness individual
wTXID
![] ( https://img-cdn.gateio.im/social/moments-ae 0 cb 158016248243 aed 51 bc 02 c 6 e 4 eb )
# 2.4 Situação de desenvolvimento e resumo
A tecnologia SegWit foi proposta em dezembro de 2015 e ativada em 2017, no Bloco 481824.
Link para consulta do Bloco:
Introdução detalhada e análise:
A tecnologia SegWit representa uma das maiores mudanças na história do Bitcoin, inaugurando uma era de expansão de capacidade e funcionalidades. Sob esta perspetiva, SegWit realizou principalmente a expansão de capacidade, sendo natural que a próxima versão se foque na expansão de funcionalidades.
![] ( https://img-cdn.gateio.im/social/moments- 3667342 ba 93 c 72 df 5621 d 9 abb 4 bd 9868)
3 Segunda versão da testemunha segregada: Taproot
Sob a perspetiva de expansão de capacidade e funcionalidades, é possível prever as funções da segunda versão da testemunha segregada.
# 3.1 Introdução e protocolos relacionados
Se mencionarmos apenas o termo Taproot, muitos pensam tratar-se de um conceito novo, mas ao referir que é a segunda versão da testemunha segregada SegWit, a maioria percebe a ligação. Os BIP relacionados são 340, 341, 342: BIP 340 (Assinaturas Schnorr para secp256k1), BIP 341 (Taproot: regras de gasto SegWit versão 1), BIP 342 (Validação de Scripts Taproot).
Protocolos relacionados:
BIP-341: Taproot: regras de gasto SegWit versão 1 / 2020-1-9
BIP-342: Validação de Scripts Taproot / 2020-1-19
BIP-340: Assinaturas Schnorr para secp256k1 / 2020-1-19
Em novembro de 2021, Taproot entrou em vigor via soft fork. Esta atualização, composta por BIP 340, BIP 341 e BIP 342, introduziu as Assinaturas Schnorr (BIP 340), substituindo o Algoritmo de Assinatura Digital de Curva Elíptica (ECDSA), expandindo a capacidade da rede e acelerando o processamento de negociações em lote, possibilitando contratos inteligentes complexos; BIP 341 implementou a Árvore de Sintaxe Abstrata Merkle (MAST) para otimizar o armazenamento de dados de negociação na blockchain; BIP 342 (Tapscript) expandiu as capacidades nativas de script do Bitcoin.
A expansão de espaço proporcionada por SegWit e Taproot levou ao surgimento de Schnorr, MAST e Taproot Scripts, cuja missão é ampliar as funcionalidades da Rede principal do Bitcoin.
# 3.2 Origem e função
Com a tecnologia SegWit, a capacidade do Bloco Bitcoin aumentou. No entanto, SegWit deixou alguns problemas:
(1) O Algoritmo de encriptação subjacente continuava a ser o ECDSA. (Novos desenvolvimentos exigem um Algoritmo de encriptação assimétrico mais avançado, levando à adoção das Assinaturas Schnorr)
(2) O espaço aumentou, mas o script de desbloqueio mantinha uma estrutura simples de um para um. (Surgiu então a MAST, uma estrutura de condições complexas)
(3) SegWit não reforçou as capacidades do script Bitcoin. (Surgiu então o Tapscript)
A segunda versão da testemunha segregada, Taproot, resolveu eficazmente estes problemas, permitindo um desenvolvimento mais avançado. BIP 340 resolveu o problema (1); BIP 341 implementou a MAST para resolver o problema (2); BIP 342 (Tapscript) expandiu as capacidades nativas de script do Bitcoin, resolvendo o problema (3).
# 3.3 Análise detalhada dos princípios
Principais novidades da tecnologia Taproot:
l Introdução das Assinaturas Schnorr
l Dois scripts de bloqueio P2TR: Key Path Spend (semelhante ao P2WPKH); Script Path Spend (semelhante ao P2WSH)
l Árvore de scripts (MAST - Árvore de Sintaxe Abstrata Merkle)
l Taproot Script
1 Assinaturas Schnorr
O desenvolvimento do Taproot, ao expandir funcionalidades, exigiu um novo Algoritmo de Assinatura, levando à adoção das Assinaturas Schnorr, em substituição ao ECDSA. Schnorr é um esquema de Assinatura digital eficiente e seguro para negociações e mensagens, descrito por Claus Schnorr em 1991. É valorizado pela sua simplicidade, segurança comprovada e linearidade.
Vantagens das Assinaturas Schnorr:
As Assinaturas Schnorr oferecem eficiência, maior privacidade, mantendo todas as funcionalidades e garantias de segurança do ECDSA. Permitem Assinaturas menores, validação mais rápida e melhor resistência a certos ataques.
A principal vantagem é a agregação de Chaves, permitindo que várias Assinaturas sejam agregadas numa só, válida para a soma das Chaves públicas. Ou seja, vários participantes podem gerar uma Assinatura válida para a soma das suas Chaves públicas. A agregação de Assinaturas reduz taxas de negociação e melhora a escalabilidade, pois as Assinaturas de configurações multi-assinatura ocupam o mesmo espaço que as de negociações individuais. Esta característica é útil para pagamentos multi-assinatura e negociações relacionadas, como canais da Lightning Network.
Outra vantagem importante é a não maleabilidade.
Schnorr também oferece benefícios de privacidade. Permite que esquemas multi-assinatura sejam indistinguíveis de Chaves públicas únicas, dificultando a distinção entre gastos multi-assinatura e gastos de Assinatura única. Em configurações n-of-m, Schnorr dificulta a identificação dos participantes que assinaram a negociação.
As Assinaturas Schnorr foram implementadas no BIP-340, como parte da atualização Taproot via soft fork, ativada em 14 de novembro de 2021 no Bloco 709,632. Schnorr tornou as Assinaturas digitais do BTC mais rápidas, seguras e fáceis de processar. Importa referir que são compatíveis com os Algoritmos criptográficos do BTC, permitindo a sua introdução via soft fork.
2 Diagrama de princípios básicos e Key Path Spend, Script Path Spend
![] ( https://img-cdn.gateio.im/social/moments- 0 eaaa 87 a 0 cb 8 da 7 ebdc 33600 d 49 f 61 f 8)
3 MAST - Árvore de Sintaxe Abstrata Merkle
Compreendendo Key Path Spend e Script Path Spend, o mais importante é que estes scripts podem ser organizados numa estrutura em árvore.
Esta árvore integra a AST e a Árvore de Merkle, conforme ilustrado:
Árvore AST
![] ( https://img-cdn.gateio.im/social/moments- 093 eed 4 d 3754 b 7 bf 9029 abc 37 af 0569 c ) ![] ( https://img-cdn.gateio.im/social/moments- 5 d 3 c 25 d 5 c 0 b 9621 a 12 c 71 d 0 ce 66541 ed )
Construindo a árvore semântica acima numa Árvore de Merkle:
![] ( https://img-cdn.gateio.im/social/moments-c 03 ec 3788 c 9 a 3 ee 1 d 7 e 207 ac 9 a 937460)
4 Taproot Scripts
No protocolo BIP 342, foi introduzido o script Tapscript, uma versão melhorada do script original do Bitcoin, podendo ser considerado uma linguagem, mas na prática é um conjunto de Códigos de operação com comandos que suportam os outros dois BIP. O Tapscript elimina o limite de tamanho de script de 10.000 bytes, criando um ambiente mais favorável à criação de contratos inteligentes na rede Bitcoin. (Esta atualização também preparou o terreno para o surgimento dos Ordinals, pois o protocolo Ordinals utiliza scripts de gasto via script-path spend do Taproot para adicionar dados). Para mais detalhes, consultar o site oficial:
Atualmente, o potencial do TaprootScript ainda não foi totalmente explorado, mas futuras evoluções mostrarão o seu poder. Por exemplo, a ligação entre a rede de camada 1 e camada 2 do Bitcoin deverá utilizar mais Taproot, MAST e TaprootScripts.
Nota: Na camada 1 do Taproot, o potencial do TaprootScript ainda é limitado, pois depende do suporte da Máquina virtual do Bitcoin. Na terceira versão da testemunha segregada, o protocolo TaprootAssets inclui uma Máquina virtual dedicada (TAP-VM), tornando a expansão de funcionalidades mais poderosa e melhor isolada do ambiente da Rede principal do Bitcoin.
# 3.4 Situação de desenvolvimento e resumo
A tecnologia Taproot foi proposta em janeiro de 2020 e entrou em vigor em novembro de 2021 via soft fork. Com Taproot, novas aplicações começaram a surgir, inicialmente leves e simples.
Aplicações típicas incluem:
(1) Protocolo Ordinals, inscrições, BRC20
(2) Outros protocolos - Atomicals, ARC20
(3) Outros protocolos - Rune
SegWit e Taproot realizaram a primeira exploração de expansão de capacidade e funcionalidades, mas limitadas pela estrutura existente.
A primeira expansão de capacidade do Bitcoin aumentou o Bloco de 1 MB para 4 MB; se esta abordagem continuar, mesmo com suporte técnico, poderá resultar em Blocos excessivamente grandes, tal como noutras forquilhas do Bitcoin, levando à centralização e comprometendo a segurança da blockchain. Por isso, a próxima expansão de capacidade requer um princípio técnico diferente.
Embora Taproot tenha realizado a primeira expansão de funcionalidades, esta também tem limitações. Na Rede principal do Bitcoin, a Máquina virtual que executa BTCScript e TapScript é a mesma (pilha de cálculo do Bitcoin), o que limita a expansão e pode afetar a estabilidade e segurança da Rede principal. Isolar a Máquina virtual de expansão de funcionalidades, criando uma Máquina virtual independente que trabalhe em conjunto com a Máquina virtual da Rede principal, é uma abordagem mais racional. Esta Máquina virtual isolada pode evoluir de não Turing-completa para Turing-completa.
![] ( https://img-cdn.gateio.im/social/moments- 21 f 0 bc 002 d 952 b 8 cd 84 e 2 dc 4 dd 8 af 0 b 3)
4 Terceira versão da testemunha segregada: protocolo TaprootAssets
Com a primeira expansão de capacidade e funcionalidades na Rede principal do Bitcoin, surgiram referências técnicas e ideias para futuras expansões. É previsível que o próximo desenvolvimento do Bitcoin se foque principalmente na expansão de capacidade. Claro que, se possível, expandir capacidade e funcionalidades simultaneamente seria ideal, mas tal implica riscos e dificuldades técnicas elevadas. Assim, surgiu uma nova tecnologia de expansão de capacidade (com algumas pequenas melhorias de funcionalidades).
# 4.1 Origem e função
O desenvolvimento do Taproot trouxe novas possibilidades ao ecossistema Bitcoin, nomeadamente:
(1) Será possível não ocupar espaço no Bloco Bitcoin, realizando uma testemunha segregada mais avançada, ou seja, armazenar dados da área witness fora do Bloco Bitcoin, mantendo apenas a prova na Rede principal?
(2) Os dados da área witness podem ter uma estrutura mais rica, suportando mais funcionalidades de negócio?
(3) Expandir ainda mais as capacidades do TaprootScript, utilizando uma Máquina virtual dedicada para cálculos relacionados.
Se estes objetivos forem alcançados, mantendo as características da Rede principal do Bitcoin, será possível realizar funcionalidades muito avançadas.
Será que a segunda versão da testemunha segregada, Taproot, já satisfaz o desenvolvimento tecnológico do Bitcoin? Haverá espaço para mais atualizações e expansão?
# 4.2 Introdução e protocolos relacionados
O Lightning Network Lab, por estas razões e contexto, criou no final de 2021 o protocolo Taproot Assets (anteriormente chamado “Taro”). O protocolo Taproot Assets é mais poderoso que Taproot, com uma estrutura de design muito sofisticada. (Agradecimento especial ao designer do protocolo, CTO do Lightning Network Lab, Olaoluwa Osuntokun)
O protocolo Taproot Assets é composto por 7 BIP importantes (ainda sem numeração BIP):
BIP-TAP-ADDR: Taproot Asset On Chain Addresses Draft / 2021-12-10
BIP-TAP-MS-SMT: Merkle Sum Sparse Merkle Trees Draft / 2021-12-10
BIP-TAP-PROOF: Taproot Asset Flat File Proof Format Draft / 2021-12-10
BIP-TAP-PSBT: Taproot Assets PSBT Draft / 2023-02-24
BIP-TAP-UNIVERSE: Taproot Asset Universes Draft / 2021-12-10
BIP-TAP-VM: Taproot Asset Script v1 Draft / 2021-12-10
BIP-TAP: TAP: Taproot Assets Protocol Draft / 2021-12-10
O protocolo TaprootAssets leva a expansão de capacidade e funcionalidades do Bitcoin ao extremo. O espaço, graças ao Universe, é praticamente ilimitado (teoricamente infinito); o limite de funcionalidades depende do potencial do TaprootScript e da sua Máquina virtual. (Atualmente, a TAP-VM ainda não é Turing-completa)
# 4.3 Análise detalhada dos princípios
Principais novidades do protocolo Taproot Assets:
- Os dados existem totalmente fora da Rede principal do Bitcoin, com provas de dados fora da cadeia armazenadas nos Blocos da Rede principal;
- Os dados fora da cadeia têm uma estrutura mais completa e sofisticada, permitindo melhor escalabilidade;
- Os dados fora da cadeia têm suporte de uma Máquina virtual mais poderosa, separando-se da Máquina virtual da Rede principal do Bitcoin, permitindo funcionalidades superiores;
1 Armazenamento de dados fora da cadeia e prova na cadeia
O protocolo Taproot Assets utiliza o Universe para armazenar dados fora da cadeia, permitindo tanto o acesso público como a preservação privada dos dados.
Atualmente, o protocolo Taproot Assets utiliza a Árvore de Merkle Sum Sparse (MS-SMT) para satisfazer requisitos relacionados com Ativos.
![] ( https://img-cdn.gateio.im/social/moments- 20 cff 3175 ce 1 c 38197 a 830762864 d 3 f 3)
Diagrama ilustrativo da emissão de múltiplos Ativos via MS-SMT
![] ( https://img-cdn.gateio.im/social/moments-fcf 5 b 332 c 34 dc 2596 fa 22 f 833002 dc 42)
Diagrama ilustrativo da transferência e posse de Ativos via TaprootAssets.
2 Estrutura de dados completa - MS-SMT (Árvore de Merkle Sum Sparse)
O protocolo Taproot Assets utiliza o mesmo modelo UTXO da Rede principal do Bitcoin para emissão de Ativos, denominado vUTXO. O controlo do total de vUTXO, divisão, fusão e transferência utilizam a MS-SMT. A soma garante a invariância do total, e a Árvore de Merkle Sparse regista todos os estados dos vUTXO.
( Do Virtual Byte do SegWit ao Virtual UTXO do TA, que percurso evolutivo tão semelhante! )
A “Árvore de Merkle Sum Sparse” (MS-SMT) é uma variante da Árvore de Merkle, definida pelo bip-tap-ms-smt. Como a chave é de 256 bits, tem 2^256 folhas, a maioria vazias.
Cada folha contém uma quantidade, e cada nó de ramificação compromete-se com a soma das quantidades das folhas da sua subárvore. Mesmo sem conhecer o conteúdo de uma subárvore, basta verificar o nó de ramificação para saber o total. A raiz compromete-se com o total de todas as folhas.
Tal como numa Árvore de Merkle comum, basta uma árvore podada contendo a folha alvo para provar a sua existência (prova de Merkle). Mas a MS-SMT também suporta provas de não existência, através de uma restrição: folhas que representam chaves inexistentes devem ter explicitamente um valor “None”, provando a inexistência. Por isso, a MS-SMT padrão tem 2^256 folhas “None”.
Folha de Ativo (UTXO de Ativo)
A MS-MST de nível inferior da árvore de Ativos utiliza asset_script_key como chave e folha de Ativo como valor. Cada folha representa um UTXO de Ativo (para simplificar, referimo-nos como “UTXO” - não é o UTXO do Bitcoin), e os seguintes atributos (incluindo um opcional) são serializados em formato “tipo-tamanho-valor”.
taproot_asset_version
asset_genesis
asset_id
asset_type
amt
lock_time
relative_lock_time
prev_asset_witnesses
-
prev_asset_id
-
asset_witness
-
split_commitment_proof
split_commitment
asset_script_version
asset_script_key
asset_group_key
canonical_universe
asset_genesis é o original do asset_id.
asset_script_key é tanto a chave da folha de Ativo como uma Chave pública em formato Taproot (definida por uma TAP-VM independente do Bitcoin), sendo a condição para gastar o UTXO representado pela folha.
Para gastar um UTXO, é necessário satisfazer primeiro a condição de gasto do Bitcoin (externa), depois a condição TAP (interna), especificada por asset_script_key, que deve ser satisfeita por prev_asset_id e asset_witness. Por exemplo, asset_witness é a Assinatura da asset_script_key do UTXO gasto.
![] ( https://img-cdn.gateio.im/social/moments- 4 bbc 1 d 2 e 0 de 7 f 871 ff 1 aa 4440933 bc 0 d )
Se um UTXO for dividido numa transferência de Ativos, são necessários split_commitment e split_commitment_proof. split_commitment é uma MS-SMT que representa todos os UTXO após a divisão (a árvore de Ativos tem assim três camadas), e a soma na raiz é o total transferido.
split_commitment_proof é uma prova de Merkle do split_commitment, provando a existência da divisão.
Em todas as divisões, apenas uma terá prev_asset_id, asset_witness e split_commitment. As restantes terão apenas split_commitment_proof. Todas as divisões partilham prev_asset_id e asset_witness.
3 Máquina virtual TAP-VM do protocolo Taproot Assets
No BIP-TAP-VM: Taproot Asset Script v1, foi definida uma Máquina virtual dedicada ao protocolo. Inicialmente, baseia-se em pequenas adaptações dos BIP-341 e BIP-342 (principais BIP do Taproot), sendo uma extensão leve do BTCScript e TaprootScript.
O autor acredita que, com esta estrutura, o ambiente de execução da TAP-VM já está separado da Rede principal do Bitcoin, podendo evoluir via a aplicação tapd do Lightning Network Lab para uma Máquina virtual mais poderosa, embora o processo seja lento por razões de segurança e estabilidade, em linha com as características das aplicações do ecossistema Bitcoin.
TrustlessSwap é uma funcionalidade inicial importante do protocolo TaprootAssets, já permitindo o desenvolvimento de aplicações Bitcoin nativas relativamente complexas.
![] ( https://img-cdn.gateio.im/social/moments- 55 dabd 37240 b 415487 a 51 a 4 f 01121 de 5)
Na experiência da equipa de projeto, já se sentem algumas funcionalidades poderosas. Por exemplo, TrustlessSwap já permite desenhar funcionalidades complexas entre Bitcoin e Ativos emitidos sobre ele.
Durante bastante tempo, após a estabilização da emissão de Ativos, o foco do protocolo TaprootAssets será o desenvolvimento das funcionalidades da TAP-VM.
Nota lateral: Uma dúvida - será que, com o tempo, a TAP-VM pode tornar-se uma Máquina virtual Turing-completa? O autor acredita que, com tempo suficiente, isso será possível. Surge então uma segunda questão: a longo prazo, será necessário uma Máquina virtual Turing-completa sob o protocolo TaprootAssets?
# 4.4 Situação de desenvolvimento e resumo
O protocolo Taproot Assets surgiu no final de 2021 com o ficheiro inicial, e em 2023 foi lançada a versão Taro, concluindo a fase inicial de exploração. Contudo, a versão Taro tinha várias imperfeições de design, dificultando o suporte a aplicações superiores, levando a um período de estagnação. Só com o lançamento da versão tapd 0.3.0 em 2024, o protocolo Taproot Assets ganhou novo impulso, e com a versão tapd 0.6.0 em junho de 2025, atingiu um estado estável e utilizável. O desenvolvimento de aplicações mais ricas baseadas no protocolo Taproot Assets tornou-se então viável.
Comparando com os protocolos Ordinals, inscrições, BRC20, ARC, etc., surgidos após Taproot, as aplicações baseadas no protocolo TaprootAssets serão mais ricas, estáveis e utilizáveis.
A emissão de Ativos TA, carteiras de novos Ativos TA, aplicações como TrustlessSwap, Stablecoin e aplicações BTCFi mais complexas já são possíveis e serão gradualmente implementadas.
Na fase inicial, o protocolo TaprootAssets realizou principalmente a expansão de capacidade do Bitcoin, expandindo teoricamente o espaço utilizável para infinito via Universe. A TAP-VM (Taproot Asset Script v1) já tem um modelo inicial, sendo importante a criação de uma Máquina virtual isolada e independente. No futuro previsível, o desenvolvimento do Bitcoin focar-se-á na expansão de funcionalidades.
![] ( https://img-cdn.gateio.im/social/moments-f 38320008 c 754 b 15 ef 64 b 53 a 16 a 738 e 0)
5. Resumo
As três grandes atualizações da tecnologia de testemunha segregada na história do Bitcoin proporcionaram enormes avanços em capacidade e funcionalidades na Rede principal. Em termos de capacidade, o Universe permite teoricamente espaço infinito; combinando com a Lightning Network, o TPS pode ser expandido para infinito. Em termos de funcionalidades, se a TAP-VM evoluir para Turing-completa, a expansão será máxima. A maturação destas infraestruturas levará tempo.
As três grandes atualizações da testemunha segregada formaram uma base sólida de protocolos e tecnologia para o desenvolvimento do ecossistema Bitcoin. De SegWit a Taproot, ao protocolo TaprootAsset, quase toda a infraestrutura necessária para aplicações está pronta. O autor acredita que TaprootAssets desencadeará uma explosão de ecossistema de produtos.
Importa notar: após as três atualizações da testemunha segregada, a linguagem de script continua não Turing-completa.
Estas três atualizações mudaram radicalmente a estrutura do Bitcoin. Qual será o próximo estágio? O protocolo TaprootAsset assemelha-se ao Layer 2, mas não cumpre totalmente os padrões Layer 2. Partilha muitas características e mecanismos da camada 1 do Bitcoin, mas não é um desenvolvimento direto da camada 1. O autor acredita que o Bitcoin evoluirá para a fase BTC 2.0, esperando poder discutir ideias com mais especialistas. Se conseguir organizar as ideias, descreverá futuramente as possibilidades e fundamentos teóricos do desenvolvimento BTC 2.0.
Se for BTC 2.0, não seria melhor nomear os 7 BIP do protocolo TaprootAsset com o prefixo BIP 2? Os critérios de revisão e princípios de design dos protocolos BTC 1.0 e 2.0 poderiam ser mais claros? E os recursos de desenvolvimento poderiam ser melhor distribuídos e colaborados? A equipa original do BitcoinCore, além de manter a Rede principal BTC 1.0, poderia contribuir para o desenvolvimento do BTC 2.0? Assim, o BTC 2.0 poderia ser construído mais rapidamente e melhor?..
Agradecimentos especiais ao YY da Lightning Network pelo feedback e orientação neste artigo.
Referências
