Principais explorações e conflitos da tecnologia original do Bitcoin

A tecnologia original do Bitcoin sempre enfrentou conflitos entre sua capacidade de adoção em massa e a funcionalidade que deve possuir. A escalabilidade e o volume de transações implicam comandos de transação mais complexos e maior espaço de transação? Significa que todas as funções devem ser implementadas em um único sistema Bitcoin? Nos primeiros dias, quando o desenvolvimento da tecnologia do ecossistema do Bitcoin estava incompleto, essas questões pareciam inerentes ao próprio Bitcoin. No entanto, à medida que a tecnologia avançou, muitas dessas questões se tornaram mais claras.

Este artigo lista algumas das questões relacionadas, juntamente com os processos através dos quais surgiram e foram abordadas. Através deste artigo, pode-se ver a conexão entre essas questões e a tecnologia, bem como as mudanças na cadeia principal do Bitcoin e nas “cadeias de testes” relacionadas. A tecnologia do Bitcoin tem sido continuamente explorada por vários projetos e equipes (incluindo o Ethereum, que é uma exploração das imperfeições do Bitcoin). No entanto, as mudanças na mainnet do Bitcoin não eram muito aparentes até o surgimento de tecnologias como Taproot, que impulsionou o desenvolvimento de protocolos como Ordinals, levando a uma nova alta repentina no desenvolvimento.

De uma perspectiva mais ampla, ao observar esses desenvolvimentos e as tecnologias que eles produziram, podemos ver suas conexões e inferir mais direções para o desenvolvimento e a arquitetura geral.

1.1 Linguagem de Script do Bitcoin e Diversas Reduções de Instruções

A linguagem de programação do Bitcoin é uma linguagem de script baseada em pilha que utiliza a Notação Polonesa Reversa, sem declarações de controle de loop e condicionais (expansões posteriores como Taproot & Taproot Script melhoraram essa capacidade). Portanto, frequentemente se diz que a linguagem de script do Bitcoin não é completa em Turing, limitando suas capacidades.

Devido a essas limitações, os hackers não podem usar esta linguagem de script para escrever loops infinitos (que poderiam paralisar a rede) ou código que poderia levar a ataques de negação de serviço (DOS), protegendo assim a rede Bitcoin de ataques DOS. Os desenvolvedores do Bitcoin também acreditam que o blockchain principal não deve ter completude de Turing para evitar certos ataques e congestionamentos de rede.

No entanto, essas limitações significam que a rede Bitcoin não pode executar outros programas complexos ou realizar algumas funções "úteis". Os sistemas de blockchain subsequentes desenvolvidos para resolver problemas específicos e atender às necessidades do usuário mudaram esse aspecto. Por exemplo, a linguagem usada pelo Ethereum é Turing-completa.

Tipos comuns de instruções de script Bitcoin incluem:

Palavras-chave:

1. Constantes. Por exemplo, OP_0, OP_FALSE

2. Controle de fluxo. por exemplo, OP_IF, OP_NOTIF, OP_ELSE, etc.

3. Operações de pilha. por exemplo, OP_TOALTSTACK (empurra a entrada para a pilha auxiliar, removendo-a da pilha principal), etc.

4. Operações de string. por exemplo, OP_CAT (concatena duas strings, desativado), OP_SIZE (empurra o comprimento da string do elemento superior da pilha para a pilha sem retirar o elemento)

5. Lógica bitwise. por exemplo, OP_AND, OP_OR, OP_XOR

6. Lógica aritmética. por exemplo, OP_1ADD (adiciona 1 à entrada), OP_1SUB (subtrai 1 da entrada)

7. Criptografia. por exemplo, OP_SHA1 (hashes input com algoritmo SHA-1), OP_CHECKSIG

8. Pseudo palavras-chave

9. Palavras-chave reservadas

Tipos comuns de script Bitcoin:

1. Transação padrão pagando para um endereço Bitcoin (pagamento para hash de chave pública)

2. Transação padrão de cunhagem de Bitcoin (pagamento para chave pública)

3. Saídas comprovadamente não gastáveis / removíveis

4. saídas Anyone-Can-Spend

5. Transação de quebra-cabeça

Os cinco tipos padrão de scripts de transação incluem: pagamentos para hash de chave pública (P2PKH), pagamentos para chave pública, multisig (limitado a 15 chaves no máximo), pagamentos para hash de script (P2SH) e saídas de dados (OP_RETURN).

Para obter informações mais detalhadas sobre a elaboração de Bitcoin, você pode visitar: Bitcoin Wiki - Script.

Redução de Instruções Suportadas no Bitcoin

Historicamente, o Bitcoin passou por várias reduções nas instruções suportadas. No gráfico a seguir, as partes vermelhas são instruções que foram removidas.

• Operações de string

（2）

(3) Operações aritméticas

Por que reduzir instruções? A segurança é apenas um aspecto a ser considerado. Se virmos a redução de instruções através da lente do design em camadas, podemos entender sua racionalidade, permitindo que o protocolo base seja mais fundamental e estável. Talvez Satoshi Nakamoto estivesse ciente desse problema desde o início, motivo pelo qual ele reduziu ativamente as instruções. O pensamento comum é construir um sistema pequeno que satisfaça diretamente as necessidades do usuário com comandos completos e recursos do sistema, em vez de um grande protocolo que exige colaboração.

Isso também leva a um fato: apenas o Bitcoin é adequado como uma rede de primeira camada. Analisei esse fenômeno no artigo “Altos Preços do Bitcoin Podem Fomentar o Surgimento de uma Nova Moeda Alternativa”, considerando perspectivas econômicas e técnicas, e a possibilidade do surgimento de uma moeda alternativa ao Bitcoin. No entanto, a partir das características fundamentais do Bitcoin e da perspectiva do design em camadas, quase apenas o Bitcoin pode servir como infraestrutura de rede de primeira camada; mesmo que existam moedas alternativas, elas seriam um produto de 1,5 camada. No nível de primeira camada, o verdadeiro artigo é apenas o Bitcoin, e no máximo, outras moedas podem servir como mercadorias alternativas de qualidade inferior.

1.2. História do Fork do Bitcoin, Motivos e Significado

Na história do desenvolvimento do Bitcoin, além da questão da redução de instruções, outro aspecto é o debate sobre o tamanho do bloco, que muitas vezes leva a bifurcações do Bitcoin.

Quando o BTC foi estabelecido, não havia limite de tamanho de bloco para permitir um certo número de transações a serem processadas dentro do mesmo período de tempo. No entanto, quando os preços iniciais do BTC eram muito baixos, o custo de transações maliciosas também era muito baixo. Para resolver esse problema, Satoshi Nakamoto liderou um soft fork em 12 de setembro de 2010, introduzindo um limite de que os blocos não poderiam exceder 1 MB de tamanho. Satoshi observou que essa restrição era temporária e que, no futuro, o limite do bloco poderia ser aumentado de maneira controlada e gradual para atender às necessidades de expansão.

Com a popularidade do Bitcoin, o problema da congestão da transação em rede e do aumento dos tempos de confirmação tornou-se cada vez mais sério. Em 2015, Gavin Andresen e Mike Hearn anunciaram que implementariam a proposta BIP-101 na nova versão do BitcoinXT, esperando aumentar o limite do tamanho do bloco para 8 MB. No entanto, desenvolvedores principais como Greg Maxell, Luke Jr e Pieter Wuille se opuseram a isso, argumentando que isso elevaria a barreira para executar um nó completo e poderia ter impactos incontroláveis. Esse debate eventualmente se expandiu em termos de escopo e participação.

A partir do conteúdo acima, vemos que Satoshi Nakamoto também expressou que “o limite de tamanho do bloco é uma restrição temporária que pode ser aumentada de maneira controlada e gradual no futuro para atender às necessidades de expansão.” Mas quando um fork vai suportar blocos maiores, e dividir uma cadeia separada para suportar blocos grandes pode resolver o problema? Em meio a controvérsias em curso, inúmeros casos surgiram. Por exemplo, o tamanho do bloco BCH é de 8 MB, posteriormente aumentado para 32 MB. BSV tem um tamanho de bloco de 128 MB. Além do BCH (e posteriormente BSV), este período também viu muitos outros forks de BTC; de acordo com a BitMEXResearch, pelo menos 50 novas moedas forkadas apareceram no ano seguinte ao fork do BCH sozinho.

O conteúdo posterior mostrará que na mainnet do Bitcoin, Segwit e Taproot também aumentaram o espaço de bloco de 1 MB para 4 MB em certa medida.

Os forks do Bitcoin são uma forma de exploração de desenvolvimento, tentando atender a uma gama mais ampla de necessidades por meio de mudanças dentro de si, incluindo as necessidades de usuários, mineradores, investidores, desenvolvedores e outros.

1.3. Várias Explorações Típicas no Desenvolvimento do Bitcoin

Após Satoshi Nakamoto sair, seu sucessor Gavin Andresen assumiu a liderança na criação do Bitcoin Core e da Fundação Bitcoin. Durante este período, as explorações sobre a escalabilidade do BTC, particularmente na área de emissão de ativos, persistiram.

(1) Colored Coins (染色币)

Yoni Assia, CEO da eToro, primeiro propôs o conceito de moedas coloridas em um artigo publicado em 27 de março de 2012. Essa ideia continuou a evoluir e começou a tomar forma e ganhar atenção em fóruns como o Bitcointalk. Eventualmente, Meni Rosenfeld lançou um white paper detalhado sobre moedas coloridas em 4 de dezembro de 2012.

A ideia por trás das moedas coloridas é representar uma gama mais ampla de ativos e valores adicionando marcações especiais (ou seja, colorindo) a partes específicas do Bitcoin. Na implementação, as moedas coloridas surgiram em várias entidades, amplamente divididas em duas categorias:

1) Com base no OP_RETURN: Conforme proposto por Flavien Charlon em 2013, utilizando Ativos Abertos, que utiliza OP_RETURN (introduzido no Bitcoin v0.9.0 para armazenar uma pequena quantidade de dados no Bitcoin, originalmente limitado a 40 bytes, posteriormente aumentado para 80 bytes). O opcode é armazenado no script e a 'coloração' e transações são completadas por leitura externa (Esse modelo é semelhante aos Ordinais, que dependem de um índice externo para determinar a legalidade dos ativos).

2) Com base em OP_RETURN: Um exemplo típico é o Protocolo EPOBC proposto pela ChromaWay em 2014, onde informações adicionais dos ativos EPOBC são armazenadas no campo nSequence das transações do Bitcoin, e a categoria e legalidade de cada ativo EPOBC devem ser rastreadas até a transação de gênese para determinar.

(2) MasterCoin (OMNI)

JR Willett lançou o conceito de MasterCoin em 6 de janeiro de 2012, nomeando-o de “o segundo white paper do Bitcoin”, e lançou oficialmente o projeto através de um ICO em julho de 2013, eventualmente arrecadando 5120 BTC (avaliados em $500,000 na época). A distinção entre MasterCoin e Colored Coins está no fato de que estabeleceu uma camada de nó completa, que mantém um banco de dados de modelo de estado escaneando blocos de Bitcoin, residindo em nós fora da blockchain. Este design fornece funcionalidades mais complexas do que Colored Coins, como criar novos ativos, exchanges descentralizadas e mecanismos automatizados de feedback de preço. Em 2014, a Tether também lançou a stablecoin conhecida como Tether USD (OMNI) no Bitcoin através do protocolo Mastercoin.

(3) CounterParty

Counterparty foi oficialmente lançado em 2014. Assim como Colored Coins, Counterparty também usa OP_RETURN para armazenar dados na rede BTC. No entanto, ao contrário das moedas coloridas, os ativos na Counterparty não existem na forma de UTXOs, mas, em vez disso, as informações são carregadas através do OP_RETURN para indicar transferências de ativos. Quando um detentor de ativos assina uma transação contendo dados especiais usando o endereço de detenção, o ativo é transferido. Através deste método, a Counterparty pode implementar a emissão de ativos, negociações e uma plataforma compatível com contratos inteligentes do Ethereum.

Além disso, algumas visões também consideram Ethereum, Ripple e BitShares como parte de um "Bitcoin 2.0" mais amplo.

1,4 Imperfeições do Bitcoin e Protocolos em Camadas

As imperfeições do Bitcoin (ou limitações) são principalmente manifestadas em vários aspectos (as imperfeições mencionadas neste artigo são baseadas no resumo no whitepaper do Ethereum e não são necessariamente falhas verdadeiras).

1. Sistema de Conta UTXO do Bitcoin

Nos projetos atuais de blockchain, existem principalmente dois tipos de métodos de registro: o modelo de conta/saldo e o modelo UTXO. O Bitcoin usa o modelo UTXO, enquanto o Ethereum, EOS e outros usam o modelo de conta/saldo.

Em uma carteira Bitcoin, geralmente podemos ver o saldo da conta; no entanto, no design original do sistema Bitcoin de Satoshi Nakamoto, não havia o conceito de um “saldo”. O “saldo de Bitcoin” é um derivado das aplicações de carteira Bitcoin. UTXO (Unspent Transaction Outputs) representa as saídas de transações não gastas e é um conceito central na geração e verificação de transações de Bitcoin. As transações formam uma estrutura em forma de corrente onde todas as transações legítimas de Bitcoin podem ser rastreadas até as saídas de uma ou mais transações anteriores. Essas correntes começam com recompensas de mineração e terminam com as saídas de transações não gastas atuais.

Portanto, no mundo real, não existem bitcoins, apenas UTXOs. As transações de Bitcoin consistem em entradas e saídas de transações; cada transação gasta uma entrada para produzir uma saída, que então se torna a "saída de transação não gasta" ou UTXO.

A implementação de contratos inteligentes apresenta desafios significativos com o modelo UTXO. Gavin Wood, o designer do Livro Amarelo do Ethereum, possui um profundo entendimento de UTXO. A característica mais significativa do Ethereum são os contratos inteligentes. Devido aos contratos inteligentes, é difícil para Gavin Wood implementar contratos inteligentes completos baseados em UTXO. O modelo de conta, que é inerentemente orientado a objetos, registra cada transação na conta correspondente (nonce++). Para facilitar a gestão de contas, é introduzido um estado global onde cada transação altera este estado global, de forma análoga a como cada pequena mudança afeta o mundo real. Assim, o Ethereum e as blockchains públicas subsequentes são geralmente baseadas em diversos tipos de sistemas de contas.

Outra falha grave do UTXO é a sua incapacidade de fornecer um controle fino sobre os limites de saque da conta, que é discutido no white paper do Ethereum.

1. Linguagem de Script do Bitcoin, Não Completa de Turing

Embora a linguagem de script do Bitcoin possa suportar várias computações, ela não pode suportar todas as computações. A principal omissão é que a linguagem de script do Bitcoin não possui declarações de loop e declarações de controle condicional. Portanto, a linguagem de script do Bitcoin não é completa em Turing, limitando suas capacidades. No entanto, essas limitações impedem que hackers use essa linguagem de script para criar loops infinitos (que poderiam paralisar a rede) ou códigos maliciosos que poderiam levar a ataques de negação de serviço, protegendo assim a rede Bitcoin de ataques de negação de serviço. Os desenvolvedores do Bitcoin também acreditam que o blockchain principal não deve ser completo em Turing para prevenir ataques e congestionamentos de rede. No entanto, o motivo pelo qual uma linguagem não completa em Turing é mais segura é insuficiente, e tal linguagem só pode executar funções limitadas.

1. Outras Imperfeições do Bitcoin: Segurança, Escalabilidade

A centralização da mineração é um problema, onde o algoritmo de mineração do Bitcoin essencialmente permite que os mineradores façam modificações mínimas no cabeçalho do bloco milhões de vezes até que o hash da versão modificada de um nó seja menor que o valor alvo. Este algoritmo de mineração é suscetível a dois tipos de ataques de centralização. Primeiro, o ecossistema de mineração é controlado por ASICs (Circuitos Integrados Específicos de Aplicações) e chips de computador projetados especificamente para a mineração de Bitcoin, que são milhares de vezes mais eficientes nessa tarefa. Isso significa que a mineração de Bitcoin não é mais altamente descentralizada e igualitária, mas requer um capital substancial para uma participação eficaz. Em segundo lugar, a maioria dos mineradores de Bitcoin não valida mais os blocos localmente; em vez disso, eles dependem de pools de mineração centralizados para fornecer os cabeçalhos dos blocos. Este problema é significativo: atualmente, os três principais pools de mineração controlam indiretamente cerca de 50% do poder de processamento na rede Bitcoin.

A escalabilidade é uma questão importante para o Bitcoin. Usando o Bitcoin, os dados crescem cerca de 1 MB por hora. Se a rede do Bitcoin processasse 2000 transações por segundo, como a Visa, cresceria 1 MB a cada três segundos (1 GB por hora, 8 TB por ano). Números de transações mais baixos também têm gerado polêmica dentro da comunidade do Bitcoin, já que blockchains maiores podem melhorar o desempenho, mas com o risco de centralização.

Do ponto de vista do ciclo de vida do produto, algumas das imperfeições menores do Bitcoin podem ser melhoradas dentro do próprio sistema, limitadas pelo sistema atual. No entanto, esses problemas podem ser resolvidos sem considerar as restrições do sistema antigo se forem abordados em um novo sistema. Se um novo sistema blockchain está sendo desenvolvido, então essas melhorias funcionais menores também devem ser projetadas e atualizadas.

Design em camadas

O design em camadas é uma metodologia e abordagem usada por humanos para lidar com sistemas complexos, dividindo um sistema em múltiplas estruturas hierárquicas e definindo as relações e funções entre essas camadas para alcançar modularidade, manutenção e escalabilidade do sistema, melhorando assim a eficiência e confiabilidade do design do sistema.

Para um sistema de protocolo amplo e extensivo, o uso de camadas tem benefícios claros. Esta abordagem torna mais fácil para as pessoas entenderem

, implementar e melhorar módulos. Por exemplo, em redes de computadores, o modelo ISO/OSI é um design de sete camadas, mas na prática, algumas camadas podem ser combinadas, como o protocolo TCP/IP de quatro camadas. As vantagens específicas da estratificação de protocolos incluem a independência e flexibilidade de cada camada, divisibilidade estrutural, facilidade de implementação e manutenção, e facilitação dos esforços de padronização.

Do ponto de vista dos protocolos em camadas, a posição do Bitcoin como camada fundamental significa que suas características como UTXO, não completude de Turing, tempos longos de bloco, capacidade de bloco pequena e o desaparecimento de seu fundador não são falhas, mas sim traços que uma camada de rede base deve ter.

Nota: O autor fornece explicações mais detalhadas sobre a estratificação de protocolo em 'Uma Visão Geral do Sistema de Conhecimento Básico de Construção da Camada 2 do Bitcoin V1.5.'

2. Novas Tecnologias Importantes no Desenvolvimento do Bitcoin (Expansão de Bloco e Melhoria de Capacidade)

Na seção anterior, exploramos os principais conflitos da tecnologia original do Bitcoin e alguns casos exploratórios, muitos dos quais levaram a bifurcações difíceis ou à criação de cadeias heterogêneas inteiramente novas. No entanto, dentro da própria blockchain do Bitcoin, essas explorações também resultaram em muitos resultados, fundamentalmente na forma de expansão de bloco e aprimoramento de capacidade. Isso é principalmente manifestado nos seguintes aspectos:

2.1. OP_RETURN

Os desenvolvedores do Bitcoin sempre buscaram expandir as capacidades do Bitcoin, manifestadas de várias maneiras:

(1) Uso de OP_RETURN

OP_RETURN é um opcode de script usado para terminar um script e retornar o valor do topo da pilha. Este opcode é semelhante à função de retorno em linguagens de programação. Ao longo da história do Bitcoin, a funcionalidade do opcode OP_RETURN foi modificada várias vezes e agora é usado principalmente como um método para armazenar dados no registro. A funcionalidade do opcode OP_RETURN sofreu mudanças significativas no passado e agora é um mecanismo importante para armazenar dados arbitrários on-chain.

Inicialmente, o OP_RETURN era usado para encerrar prematuramente a execução do script, com o resultado da execução apresentado como o item superior da pilha. Essa operação inicialmente tinha uma vulnerabilidade que era facilmente explorada, mas Satoshi Nakamoto a corrigiu rapidamente.

Mais mudanças na funcionalidade OP_RETURN

Na atualização para o Bitcoin Core v 0.9.0, os scripts de "saída OP_RETURN" foram transformados em um tipo de saída padrão, permitindo que os usuários anexassem dados às "saídas de transação não gastáveis". O volume de dados disponível em tais scripts foi inicialmente limitado a 40 bytes e depois aumentado para 80 bytes.

Armazenando Dados na Blockchain:

Alterar o OP_RETURN para sempre retornar falso teve resultados interessantes. Como nenhum outro opcode ou dados são avaliados após o OP_RETURN, os usuários da rede começaram a usar esse opcode para armazenar dados em formatos arbitrários.

Durante a era do Bitcoin Cash (BCH), de 1 de agosto de 2017 a 15 de novembro de 2018, o comprimento dos dados que poderiam ser anexados às saídas OP_RETURN foi estendido para 220 bytes, permitindo dados mais significativos para fomentar aplicações inovadoras na blockchain, como postar conteúdo nas mídias sociais da blockchain.

No BSV, o limite de 220 bytes ainda foi mantido por um curto período. Mais tarde, em janeiro de 2019, porque o opcode OP_RETURN termina o script de uma maneira que os nós não verificam nenhum opcode subsequente, os nós também não verificaram se o script estava dentro do limite máximo de 520 bytes. Consequentemente, os operadores de nós de rede decidiram aumentar o volume máximo de transações para 100 KB, concedendo assim aos desenvolvedores mais liberdade para inovação de aplicativos, permitindo que novas aplicações coloquem dados maiores e mais complexos no livro-razão do Bitcoin. Naquela época, houve um exemplo de aplicativo onde alguém colocou um site inteiro no livro-razão BSV.

Embora o OP_RETURN tenha algumas expansões funcionais, suas capacidades gerais ainda são limitadas. Isso levou à tecnologia do Segregated Witness.

(2) SegWit (Testemunha Segregada)

Testemunha Segregada, ou SegWit, foi proposta pela primeira vez por Pieter Wuille (desenvolvedor principal do Bitcoin e co-fundador da Blockstream) em dezembro de 2015 e mais tarde tornou-se o Bitcoin BIP 141. SegWit modifica ligeiramente a estrutura de dados das transações nos blocos de Bitcoin para resolver os seguintes problemas:

1) Problema de maleabilidade de transação.

2) Em provas SPV, a transferência de assinaturas de transações se torna opcional, reduzindo o volume de dados das provas de Merkle.

3) Aumentando indiretamente a capacidade do bloco.

Os dois primeiros itens aumentam principalmente a segurança e o desempenho, com o impacto mais significativo nas novas tecnologias sendo o terceiro item, que aumentou indiretamente a capacidade de bloco (consulte o conceito de Peso do Bloco abaixo), lançando as bases para o aprimoramento da capacidade do Bitcoin e levando a aprimoramentos adicionais no Taproot (a segunda versão do Testemunho Segregado).

Embora a implementação tenha aumentado a capacidade do bloco, o SegWit ainda está sujeito a limites de tamanho de bloco. O limite de tamanho de bloco do Bitcoin é de 1 M bytes e, como os dados de testemunho não estão incluídos nesse limite, ainda há uma restrição no tamanho total do bloco para evitar o abuso dos dados de testemunho. Um novo conceito chamado Peso do Bloco foi introduzido:

Peso do bloco = Tamanho base * 3 + Tamanho total

O tamanho base é o tamanho do bloco excluindo os dados de testemunha

O tamanho total é o tamanho total do bloco serializado de acordo com o BIP 144, incluindo os dados base e os dados de testemunha.

SegWit restringe o peso do bloco <= 4 M.

SegWit também tecnicamente permite a expansão do Bitcoin para usar a Lightning Network, o que não está detalhado aqui.

(3) Taproot (Testemunha Segregada V2)

Se você usar diretamente a palavra Taproot, muitas pessoas podem pensar que é um novo conceito, mas se você entender que é a segunda versão do Segregated Witness, a maioria vai entender a conexão. Taproot está associado aos BIPs 340, 341 e 342, nomeados: BIP 340 (Assinaturas Schnorr para secp256k1), BIP 341 (Taproot: regras de gasto da versão 1 do SegWit),

BIP 342 (Validação de Scripts de Taproot).

Em novembro de 2021, o Taproot foi oficialmente ativado como uma soft fork. Esta atualização combina o BIP 340, BIP 341 e BIP 342. Entre eles, o BIP 340 introduz assinaturas Schnorr que podem validar simultaneamente várias transações, substituindo o Algoritmo de Assinatura Digital de Curva Elíptica (ECDSA), expandindo mais uma vez a capacidade da rede e acelerando o processamento de transações em lote, proporcionando possibilidades para a implementação de contratos inteligentes complexos; o BIP 341 implementa Árvores de Sintaxe Abstrata Merklizadas (MAST) para otimizar o armazenamento de dados de transação na blockchain; o BIP 342 (Tapscript) usa a linguagem de codificação de script do Bitcoin para aprimorar as capacidades de script nativas do Bitcoin.

A expansão do espaço causada por Segwit e Taproot levou à criação de assinaturas Schnorr, árvores MAST e Scripts Taproot, cuja missão é expandir as funcionalidades da rede principal do Bitcoin.

2.2 Assinaturas Schnorr, MAST e Scripts Taproot

Da Seção 2.1, observamos a contínua exploração do Bitcoin em escalabilidade e aprimoramento de capacidade, culminando no desenvolvimento da tecnologia Taproot, juntamente com várias tecnologias cruciais como Schnorr, MAST e Scripts Taproot, que verdadeiramente expandiram as capacidades do Bitcoin.

(1) Assinaturas Schnorr

A evolução do Taproot, enquanto expande capacidades, exigiu demandas específicas do algoritmo de assinatura, introduzindo assim assinaturas Schnorr para substituir o Algoritmo de Assinatura Digital de Curva Elíptica (ECDSA). As assinaturas Schnorr são um esquema de assinatura digital que pode assinar transações e mensagens de forma eficiente e segura. Elas foram descritas pela primeira vez por Claus Schnorr em um artigo de 1991. Schnorr é aclamado por sua simplicidade, segurança comprovável e linearidade.

Vantagens das Assinaturas Schnorr:

1) As assinaturas Schnorr oferecem vários benefícios, incluindo eficiência e privacidade aprimorada, mantendo todas as funcionalidades e suposições de segurança do ECDSA. Elas permitem tamanhos de assinatura menores, tempos de verificação mais rápidos e resistência aprimorada a certos tipos de ataques.

2) Uma vantagem notável das assinaturas de Schnorr é a agregação de chaves, que agrega várias assinaturas em uma única que é válida para a soma de suas chaves. Em outras palavras, Schnorr permite que várias partes cooperantes gerem uma única assinatura que é válida para o total de suas chaves públicas. A agregação de assinaturas permite que as assinaturas de vários signatários sejam combinadas em uma única assinatura.

A agregação de chaves pode reduzir as taxas de transação e melhorar a escalabilidade subjacente, uma vez que assinaturas eletrônicas de configurações multisig ocupam o mesmo espaço em um bloco que aquelas de transações de parte única. Essa característica do Schnorr pode ser usada para reduzir o tamanho de pagamentos multisig e outras transações relacionadas a multisig, como transações de canal da Lightning Network.

3) Outra característica importante das assinaturas de Schnorr é a sua não maleabilidade.

4) Schnorr também oferece inúmeras vantagens de privacidade. Ele torna os esquemas multisig indistinguíveis dos esquemas tradicionais de chave única para observadores externos, tornando mais difícil diferenciar gastos multisig de gastos de assinatura única na cadeia. Além disso, em configurações multisig de n-de-m, Schnorr torna mais difícil para observadores externos determinar quais participantes assinaram em uma transação e quais não assinaram.

As assinaturas Schnorr são implementadas no BIP-340 como parte da atualização do soft fork Taproot e foram ativadas em 14 de novembro de 2021, na altura do bloco 709.632. Schnorr torna as assinaturas digitais do BTC mais rápidas, seguras e fáceis de lidar. Notavelmente, as assinaturas Schnorr são compatíveis com versões anteriores dos algoritmos criptográficos do BTC, permitindo que sejam introduzidas por meio de uma atualização do soft fork.

(2) Árvores de Sintaxe Abstrata MAST

Há uma ligeira ambiguidade na abreviação de MAST em chinês e inglês. Oficialmente, BIP (BIP 114) e alguns artigos usam a abreviação MAST para: Merklized Abstract Syntax Tree. Outras fontes traduzem Merklized Alternative Script Trees (MAST) para o chinês como Merklized Replacement Script Trees (MAST). No livro “Mastering Bitcoin” e em um artigo, é usada essa abreviação: https://cointelegraph.com/learn/a-beginners-guide-to-the-Bitcoin-Taproot-upgrade.

Árvores de Sintaxe Abstrata Merklizadas e Árvores de Script Alternativo Merklizadas (MAST) parecem ter a mesma função. Do ponto de vista da tradução, pessoalmente acho melhor manter o uso encontrado no protocolo oficial do Bitcoin BIP.

O conceito por trás do MAST vem de duas ideias: Árvores de Sintaxe Abstrata e Árvores de Merkle.

Árvores de Sintaxe Abstrata (AST) pertencem ao domínio dos princípios de compiladores e da linguística formal em ciência da computação. Uma árvore de sintaxe abstrata é uma representação intermediária durante o processo de compilação, usada para representar a estrutura semântica do código fonte. Ela transforma o código fonte em uma estrutura de árvore, onde cada nó representa uma unidade semântica, e as arestas representam as relações entre eles. As árvores de sintaxe abstrata desempenham um papel crucial nas fases de análise léxica e sintática do compilador, ajudando a entender o significado do código fonte e realizar os processos subsequentes de otimização e geração de código-alvo. Em termos simples, uma árvore de sintaxe abstrata (AST) é um método de descrever um programa dividindo-o em blocos independentes, tornando o programa mais fácil de analisar e otimizar. Para gerar uma AST, todas as equações e suas premissas devem ser conectadas com setas até que todas as premissas sejam identificadas. A imagem abaixo é uma AST de um script.

Por outro lado, uma árvore de Merkle pode ser usada para verificar se um elemento pertence a um conjunto sem precisar conhecer o conjunto inteiro. Por exemplo, as carteiras de Verificação de Pagamento Simplificada (carteiras SPV) do Bitcoin usam árvores de Merkle para verificar se uma transação existe dentro de um bloco, economizando largura de banda ao não baixar o bloco completo.

Para gerar uma árvore de Merkle, cada elemento é hash individualmente para criar um identificador único; esses identificadores são então emparelhados e hash novamente para criar um identificador para esse par; esse processo é repetido até que reste apenas um identificador, conhecido como a “raiz de Merkle”, que é um identificador conciso que representa o conjunto inteiro.

Ao verificar se um elemento pertence a um conjunto, o proprietário do conjunto pode fornecer a você todos os identificadores desse elemento para a raiz de Merkle. Isso prova que o elemento realmente faz parte do conjunto.

Em resumo, a tecnologia por trás do AST permite que você divida um programa em vários blocos pequenos, enquanto uma árvore de Merkle nos permite verificar que esses blocos são de fato partes de um programa completo, sem expor todo o programa. Este é o princípio básico do MAST, que permite aos gastadores substituírem condições não utilizadas em uma única transação por uma prova de Merkle, com os benefícios de reduzir o tamanho da transação, aumentar a privacidade e suportar contratos maiores.

Existem muitos exemplos de árvores MAST online, e aqueles familiarizados com o desenvolvimento de programas podem compreender claramente a lógica relacionada a um processo MAST.

Com o surgimento das árvores de sintaxe abstrata MAST, torna-se necessário estender as capacidades de sintaxe nativa do Bitcoin, levando à criação de Scripts Taproot.

(3) Scripts Taproot

Introduzido sob o protocolo BIP 342, o Taprootscript é uma versão atualizada do script original do Bitcoin, essencialmente uma coleção de códigos de operação com comandos que suportam a implementação de outros BIPs. O Taprootscript também elimina o limite de tamanho do script de 10.000 bytes, fornecendo um ambiente melhor para a criação de contratos inteligentes na rede Bitcoin. Essa atualização também lançou as bases para o desenvolvimento posterior dos Ordinais, que utilizam scripts de gastos de caminho de script do Taproot para anexar dados adicionais. Mais detalhes podem ser encontrados no site oficial:

https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki

As capacidades do TaprootScript ainda não foram totalmente utilizadas, e mais desenvolvimentos no futuro demonstrarão seu potencial, especialmente na conexão da rede de primeira camada do Bitcoin com tecnologias de segunda camada, onde o Taproot, MAST e TaprootScripts provavelmente serão usados de forma mais extensiva.

2.3 Ordinais, Inscrições, BRC 20 e Outros Protocolos

Com ferramentas fundamentais como Segwit, Taproot, Schnorr, MAST e Scripts de Taproot no ecossistema do Bitcoin, novas aplicações começaram a surgir. Inicialmente, essas aplicações eram leves e simples.

(1) Protocolo de Ordinais, Inscrições e BRC 20

A criação do protocolo Ordinals está altamente associada ao conceito de satoshis. O protocolo introduz os conceitos de ordinais e inscrições. Ordinais são um esquema de numeração que atribui um número único a cada satoshi na rede Bitcoin de acordo com a ordem em que foram minerados. No protocolo, o identificador ordinal permanece inalterado, independentemente de como o satoshi é transferido entre diferentes carteiras. Nós completos de Bitcoin que executam o software de código aberto de Rodarmor, ORD, podem rastrear esses satoshis numerados, fornecendo um mecanismo preciso para as pessoas rastrearem cada satoshi e verificá-los independentemente.

Inscrições envolvem gravar informações nos satoshis. Ao alavancar SegWit e Taproot, o protocolo Ordinals permite a gravação de arquivos menores que 4 MB em cada satoshi em um bloco de Bitcoin—essas são as inscrições, que podem conter vários tipos de informações como texto, imagens ou vídeos.

Em termos simples, o esquema de numeração ordinal fornece a cada satoshi um identificador único e rastreável, conferindo-lhe características não fungíveis. As inscrições permitem a adição de dados indivisíveis nesses ordinais, semelhante à criação de arte em uma tela em branco. Em conjunto, eles permitem que o Bitcoin hospede um novo padrão para NFTs. Essencialmente, Ordinals é como um protocolo NFT, mas ao contrário do ETH ou de outras blockchains públicas onde os metadados NFT geralmente são armazenados no IPFS ou em servidores centralizados, Ordinals incorpora metadados nos dados de testemunho da transação, como se estivessem “gravados” em um satoshi específico.

BRC-20: Inspirado no protocolo Ordinals, usuário do Twitter @domodatacriou o padrão de token fungível experimental BRC-20 no Bitcoin em 8 de março de 2023. Ao atribuir diferentes 'atributos' a cada satoshi, o protocolo Ordinals cria NFTs da rede BTC, enquanto o BRC-20 faz isso fornecendo um 'formato' e 'atributos' uniformes para tokens fungíveis (FTs) baseados em BTC. O BRC-20 emprega o protocolo Ordinals para escrever um texto JSON em uma inscrição BTC para implantar contratos de token, cunhar e transferir tokens. Aspectos-chave de implantação incluem o nome do token, fornecimento total e cunhagem máxima por ocasião. Para transações envolvendo transferências ou compra/venda, um NFT adicional rastreia saldos off-chain. Um mecanismo de cunhagem 'por ordem de chegada' fornece emissão justa e oportunidades de participação. No entanto, a infraestrutura relativamente subdesenvolvida do ecossistema BTC e sua íngreme curva de aprendizado, juntamente com baixa liquidez, tornam fácil para tokens BRC-20 como ordi, sats e rats subirem repentinamente, criando um mito de criação de riqueza.

(2) Outros Protocolos - Atomicals, ARC 20

O desenvolvimento do protocolo Atomicals foi bastante dramático. Seu fundador, Arthur, inicialmente queria desenvolver um projeto DID em cima do recém-lançado protocolo Ordinals, mas percebeu que Ordinals tinha muitas limitações que eram desfavoráveis para apoiar algumas das funcionalidades que ele queria implementar. Como resultado, em 29 de maio de 2023, Arthur twittou sobre seu conceito para o protocolo Atomicals, que foi lançado posteriormente em 17 de setembro de 2023, após meses de desenvolvimento. Posteriormente, o protocolo Atomicals gerou conceitos como Dmint, Bitwork, ARC-20 e RNS, com planos futuros de introduzir AVM e soluções de divisão. Assim como Ordinals e BRC-20, a implantação de tokens fungíveis em Atomicals resulta na criação de ARC-20. Leitores interessados em ARC-20 podem ler mais aqui: Tokens ARC-20.

(3) Outros Protocolos - Rune

Conforme o ecossistema evoluiu, Casey Rodarmor, o criador dos Ordinais, destacou que os tokens BRC-20 têm a 'consequência infeliz da expansão de UTXO' e sugeriu Runas como uma solução alternativa baseada em UTXO. Os protocolos existentes geralmente sofrem com implementações complexas, experiências de usuário ruins, produção de saídas de transações não gastas (UTXOs) inúteis e operações que exigem tokens nativos.

A transferência de Runes usa OP_RETURN, e o primeiro dado de saída na mensagem do protocolo é decodificado em uma sequência de inteiros, interpretada como uma série de tuplas (ID, SAÍDA, MONTANTE). Se o número de inteiros decodificados não for um múltiplo de três, a mensagem do protocolo é inválida. ID refere-se ao ID do Token a ser transferido, SAÍDA é o índice de saída atribuído (ou seja, a qual saída está atribuída) e MONTANTE é a quantidade alocada. Após o processamento de todas as alocações de tuplas, quaisquer Tokens de Runes não alocados são atribuídos à primeira saída não-OP_RETURN, sendo o restante potencialmente inscrito com Tokens de Runes na saída OP_RETURN contendo a mensagem do protocolo.

A emissão de Runes é baseada no rastreamento de UTXO de tokens homogêneos. Se a mensagem do protocolo incluir um segundo envio de dados, representa uma transação de emissão. O segundo envio de dados é decodificado em dois inteiros, SÍMBOLO e DECIMAIS. Se houver inteiros adicionais, a mensagem do protocolo é inválida. SÍMBOLO é um símbolo básico legível de 26 caracteres, semelhante aos usados nos nomes Ordinais, com os únicos caracteres válidos sendo de A a Z. DECIMAIS indicam as casas decimais a serem usadas ao emitir Runes. Se o SÍMBOLO ainda não foi atribuído, o Token de Runes é atribuído um valor de ID (começando de 1). Se o SÍMBOLO já foi atribuído ou é um dos BITCOIN, BTC ou XBT, não serão criados novos Runes. Esta é uma característica especial do protocolo de Runes - não vincula registros de saldo aos endereços da carteira, mas sim os armazena dentro do próprio UTXO. Novos Tokens de Runes começam a partir da transação de emissão, especificando o fornecimento, símbolo e casas decimais, e esse fornecimento é alocado para UTXOs específicos. UTXOs podem conter qualquer número de Tokens de Runes, independentemente do seu tamanho, e são usados apenas para rastrear saldos. Em seguida, a função de transferência usa esse UTXO, dividindo-o em vários novos UTXOs de tamanhos arbitrariamente diferentes contendo quantidades diferentes de Runes, enviando os registros para outros. Em comparação com o BRC-20, o Runes simplifica a camada de consenso, tornando-se mais simples sem depender de dados off-chain e sem possuir tokens nativos, tornando-o altamente adequado para o modelo nativo de UTXO do Bitcoin.

(4) Outros Protocolos - Carimbos BTC, SRC 20, SRC 721

O sistema de selos Bitcoin foi lançado por Mike In Space em março de 2023, inicialmente como um projeto de prova de conceito no Counterparty, uma camada 2 do Bitcoin que existe desde 2014. Devido a atualizações em seus protocolos subjacentes, os selos fizeram a transição completa para o Bitcoin, tornando-se conhecidos como SRC-20 no verão passado. Inicialmente, Mike imaginou os selos como um método para cunhar NFTs permanentes de Bitcoin. No entanto, o protocolo se expandiu para replicar o BRC-20, um tipo de token substituível em lote que prosperou no Bitcoin devido à loucura pela inscrição desencadeada pelo lançamento dos Ordinais de Casey Rodarmor em janeiro de 2023.

A principal diferença entre Selos e Ordinais está em sua arquitetura. O Stamps armazena seus metadados em saídas de transações não gastas de várias assinaturas (UTXOs), enquanto o Ordinals armazena seus metadados na parte "testemunha" das transações de Bitcoin. Essa diferença arquitetônica destaca as compensações feitas pelos desenvolvedores. Por exemplo, o método UTXO dos Stamps os torna imprunáveis, parecendo assim permanentes, embora seu custo de fabricação seja maior do que o dos ordinais. Por outro lado, o uso de dados de testemunhas pelos Ordinais acaba por torná-los prunáveis, e seu custo de fabricação é menor do que o dos Selos.

Assim, enquanto os Ordinais podem oferecer a melhor relação durabilidade-custo para os NFTs de cripto de hoje (que também podem ser obtidos no Ethereum, mas a um custo de construção mais alto), os Selos parecem atualmente fornecer a melhor garantia de permanência direta.

Após o surgimento dos BTC Stamps, o SRC 20 e o SRC 721 foram desenvolvidos, operando de forma semelhante ao BRC-20. O BRC-20 é construído sobre o protocolo Ordinals, enquanto o SRC-20 é construído sobre os BTC STAMPS. Os leitores interessados podem ler mais sobre a documentação do SRC 20 e do SRC 721 aqui:

Protocolo SRC 20

Protocolo SRC 721

Isso conclui a introdução às novas tecnologias significativas na rede da Camada 1 do Bitcoin. Para uma maior escalabilidade e aprimoramento, o foco será deslocado para a infraestrutura da camada superior do Bitcoin, como a Camada 2 do Bitcoin ou soluções que aproveitam a Lightning Network. Para mais informações sobre este tópico, os leitores são sugeridos a ler “Um Guia Abrangente para a Infraestrutura da Camada 2 do Bitcoin, Versão 1.5” e “Da Perspectiva das Máquinas de Estado: Observando a Arquitetura e o Caminho de Construção de Futuras Aplicações Web3.0”, ou outros artigos relacionados à construção ou design arquitetônico da Camada 2 do Bitcoin.

3. Uso de Nova Tecnologia e Necessidades de Desenvolvimento Futuro

Com base no conteúdo da Seção 2, observamos que a evolução tecnológica dentro do ecossistema do Bitcoin estabeleceu uma base para aplicações mais amplas. No entanto, como o desenvolvimento é um processo e algumas tecnologias relacionadas ainda estão imaturas, há uma diferença significativa entre as aplicações populares atuais e os usos comuns futuros.

3.1 Métodos de Utilização de Nova Tecnologia

Das seções anteriores, vemos que a essência do desenvolvimento tecnológico do Bitcoin está em expandir a capacidade e as capacidades do bloco.

Expansão de Bloco:O Segregated Witness (SegWit) expandiu efetivamente a capacidade do bloco, embora existam várias propostas para reduzir os dados da testemunha, tais eventos são improváveis, especialmente depois que os dados da testemunha ganharam mais importância.

Expansão de Capacidade:Tecnologias como Taproot, Schnorr, MAST e Taproot Scripts melhoraram as capacidades do Bitcoin. Em particular, a combinação de MAST e Taproot Scripts expande as habilidades da linguagem de script nativa do Bitcoin, permitindo o manuseio de cenários mais complexos. No entanto, expandir essas capacidades também aumenta a complexidade do desenvolvimento e compreensão do Bitcoin, uma vez que o desenvolvimento de script não é realizado em uma linguagem de alto nível. Além disso, a expansão dessas capacidades fica aquém da compreensão e do ritmo de aprendizado dos usuários em relação à expansão da capacidade de bloco.

A simplicidade de usar a expansão de blocos versus a complexidade da expansão de capacidade explica por que os usuários armazenam inicialmente pequenas imagens NFT na mainnet do Bitcoin, levando ao surgimento de aplicativos como BRC 20. A maioria dos aplicativos atualmente na mainnet do Bitcoin está explorando usos pós-expansão de blocos. Uma pequena parte dos aplicativos está começando a explorar a expansão de capacidade, como a conexão entre as camadas primeira e segunda no BEVM, que utiliza de forma proeminente os elementos básicos mencionados anteriormente. A combinação de assinaturas Schnorr, contratos MAST e a rede de nós leves do Bitcoin (BTC L2) é um caso representativo de aprendizado de como conectar as camadas primeira e segunda. São esperados casos mais extensos de expansão de capacidade no futuro.

Onde devem estar os limites da expansão de capacidade? Podemos julgar a partir da perspectiva do design em camadas. Se essas capacidades forem principalmente destinadas como conexões entre a primeira e a segunda camadas do Bitcoin, então elas não devem se tornar excessivamente complicadas. No entanto, impulsionados pela criatividade humana e pelo forte apelo da emissão e gestão de ativos, algumas equipes ou indivíduos explorarão mais cenários para a expansão de capacidades.

3.2 Necessidades de Desenvolvimento Futuro

A razão mais direta para o surgimento da tecnologia blockchain é a moeda digital, portanto, emitir e gerenciar ativos são necessidades diretas dentro do domínio do Bitcoin ou da blockchain. Desde a exploração das moedas coloridas até aplicações como BRC 20 e ARC 20, bem como ICOs e IDOs no Ethereum, todas essas são explorações de emissão de ativos. Aplicações como Uniswap, Empréstimos e AMMs são sobre gerenciamento de ativos. Esses tipos de aplicações amadureceram em redes como o Ethereum e, à medida que a tecnologia do ecossistema do Bitcoin evolui, essas aplicações de gerenciamento de ativos provavelmente migrarão para o ecossistema do Bitcoin, especialmente para a segunda camada do Bitcoin.

Somente após atender às necessidades de emissão e gerenciamento de ativos, haverá capacidade e tempo para desenvolver aplicativos em grande escala para a era Web3.0 (também conhecida como Era de Valor). A arquitetura do sistema para futuras aplicações em grande escala da Web3.0 é discutida em “Do ponto de vista das Máquinas de Estado Visualizando a Segunda Camada do Bitcoin, Observando a Arquitetura e Caminho de Construção das Futuras Aplicações da Web3.0.”

O caminho para a construção é um processo de atender continuamente às necessidades, que pode ser dividido em estágios de curto prazo, médio prazo e longo prazo. O curto prazo envolve novas aplicações de tecnologia na mainnet do Bitcoin e estágios simples de construção de segunda camada baseada em blockchain para cumprir grandes expansões de capacidade para várias aplicações financeiras. O médio prazo envolve estágios mais avançados de construções de segunda camada baseadas em blockchain e sistemas distribuídos de segunda camada, atendendo a várias aplicações financeiras e de confiança. O longo prazo envolve a construção completa do ecossistema Bitcoin em grande escala, construindo verdadeiramente a era Web3.0.

Aviso Legal：

1. Este artigo foi reproduzido a partir de [Foresightnews] Todos os direitos autorais pertencem ao autor original [付少庆、SatoshiLab、万物岛 BTC 工作室]. Se houver objeções a esta reimpressão, entre em contato com o Gate Aprenderequipe e eles vão lidar com isso prontamente.
2. Aviso de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.