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 deveria possuir. O escalonamento e o volume de transações implicam comandos de transação mais complexos e um maior espaço de transação? Isso 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 abordados. Através deste artigo, pode-se ver a ligação entre essas questões e a tecnologia, bem como as mudanças na cadeia principal do Bitcoin e as “cadeias de teste” 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 evidentes até o surgimento de tecnologias como o Taproot, que impulsionaram o desenvolvimento de protocolos como os Ordinais, levando a uma nova alta repentina no desenvolvimento.

Num sentido mais amplo, olhando para estes desenvolvimentos e as tecnologias que produziram, podemos ver as suas conexões e inferir mais direções para o desenvolvimento e a arquitetura global.

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, faltando-lhe instruções de controle de loop e condicionais (expansões posteriores como Taproot & Taproot Script aprimoraram essa capacidade). Portanto, frequentemente se afirma que a linguagem de script do Bitcoin não é Turing-completa, o que limita suas capacidades.

Devido a essas limitações, os hackers não podem usar esta linguagem de script para escrever loops infinitos (o que paralisaria a rede) ou código que poderia levar a ataques de DOS, protegendo assim a rede Bitcoin desses ataques. 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 dos usuários mudaram esse aspecto. Por exemplo, a linguagem usada pelo Ethereum é Turing-completa.

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

Palavras-chave:

1. Constantes. por exemplo, OP_0, OP_FALSE

2. Controlo 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 remover 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 provavelmente não gastáveis / eliminá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 scriptação do Bitcoin, visite: Bitcoin Wiki - Script.

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

Historicamente, o Bitcoin passou por várias reduções nas instruções suportadas. No gráfico seguinte, as partes a vermelho 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 considerar. Se virmos a redução de instruções através da lente do design em camadas, podemos entender a sua racionalidade, permitindo que o protocolo base seja mais fundamental e estável. Talvez Satoshi Nakamoto estivesse ciente deste problema desde o início, o que é por que 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 rede de primeira camada. Analisei esse fenômeno no artigo 'Altas de Preços do Bitcoin Podem Fomentar o Surgimento de uma Nova Cadeia Alternativa', considerando perspectivas econômicas e técnicas, e a possibilidade do surgimento de uma cadeia alternativa de Bitcoin. No entanto, a partir das características fundamentais do Bitcoin e da perspectiva de design em camadas, quase apenas o Bitcoin pode servir como infraestrutura de rede de primeira camada; mesmo que existam cadeias alternativas, elas seriam um produto de 1,5 camada. No nível de primeira camada, o verdadeiro produto é apenas o Bitcoin, e no máximo, outras cadeias podem servir como bens alternativos de qualidade inferior.

1.2. História do Fork do Bitcoin, Razões 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 no mesmo período de tempo. No entanto, quando os preços iniciais do BTC eram muito baixos, o custo das 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 pudessem exceder 1 MB de tamanho. Satoshi observou que essa restrição era temporária e que, no futuro, o limite de 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 iriam implementar 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 opuseram-se a isso, argumentando que isso aumentaria a barreira para executar um nó completo e poderia ter impactos incontroláveis. Este debate acabou por se expandir tanto em escopo como em participação.

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

Mais tarde, o conteúdo mostrará que na rede principal do Bitcoin, Segwit e Taproot também aumentaram o espaço do bloco de 1 MB para 4 MB até certo ponto.

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 internas, incluindo as necessidades de usuários, mineradores, investidores, desenvolvedores e muito mais.

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

Depois de 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) Moedas Coloridas (染色币)

Yoni Assia, CEO da eToro, propôs pela primeira vez o conceito de moedas coloridas num artigo publicado a 27 de março de 2012. Esta ideia continuou a evoluir e começou a ganhar forma e atenção em fóruns como o Bitcointalk. Eventualmente, Meni Rosenfeld publicou um white paper detalhado sobre as moedas coloridas a 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 Open Assets, que utiliza o 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 as “colorações” e transações são concluídas por leitura externa (Este modelo é semelhante aos Ordinais, que dependem de um índice externo para determinar a legalidade dos ativos).

2)Com base no 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 Bitcoin, e a categoria e legalidade de cada ativo EPOBC devem ser rastreadas até a transação genesis para determinar.

(2) MasterCoin (OMNI)

JR Willett lançou o conceito de MasterCoin em 6 de janeiro de 2012, nomeando-o "o segundo white paper do Bitcoin", e lançou oficialmente o projeto através de um ICO em julho de 2013, arrecadando eventualmente 5120 BTC (avaliados em $500,000 na época). A distinção entre MasterCoin e Colored Coins reside no fato de que estabeleceu uma camada de nó completa, que mantém um banco de dados de modelo de estado escaneando blocos do 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 de feedback de preço automatizados. Em 2014, a Tether também lançou a stablecoin conhecida como Tether USD (OMNI) no Bitcoin através do protocolo Mastercoin.

(3) CounterParty

A Counterparty foi oficialmente lançada em 2014. Assim como as Moedas Coloridas, a Counterparty também usa o 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 sim, 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ção e uma plataforma compatível com contratos inteligentes Ethereum.

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

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 da 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 utiliza o modelo UTXO, enquanto o Ethereum, EOS e outros utilizam o modelo de conta/saldo.

Numa carteira Bitcoin, normalmente podemos ver o saldo da conta; no entanto, no design original do sistema Bitcoin de Satoshi Nakamoto, não existia o conceito de um “saldo.” O “saldo de Bitcoin” é derivado das aplicações de carteira Bitcoin. UTXO (Outputs de Transações Não Gastas) representa os outputs de transações não gastos, e é um conceito fundamental na geração e verificação de transações Bitcoin. As transações formam uma estrutura em forma de cadeia onde todas as transações legítimas de Bitcoin podem ser rastreadas até outputs de uma ou mais transações anteriores. Essas cadeias começam com recompensas de mineração e terminam com os outputs de transações não gastas atuais.

Portanto, no mundo real, não existem bitcoins, apenas UTXOs. As transações de Bitcoin consistem em inputs e outputs de transações; cada transação gasta um input para produzir um output, que então se torna o "output de transação não gasto," ou UTXO.

A implementação de contratos inteligentes apresenta desafios significativos com o modelo UTXO. Gavin Wood, o designer do Livro Amarelo Ethereum, tem uma compreensão profunda do UTXO. A característica mais significativa do Ethereum é os contratos inteligentes. Devido aos contratos inteligentes, é difícil para Gavin Wood implementar contratos inteligentes completos de Turing baseados em UTXO. O modelo de conta, que é inerentemente orientado a objetos, regista 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 subsequentes blockchains públicas são geralmente baseadas em vários tipos de sistemas de contas.

Outra falha grave do UTXO é a sua incapacidade de fornecer um controle fino sobre os limites de levantamento da conta, o que é discutido no livro branco do Ethereum.

1. Linguagem de script do Bitcoin, Não é Turing-Complete

Embora a linguagem de script do Bitcoin possa suportar vários cálculos, não pode suportar todos os cálculos. A principal omissão é que a linguagem de script do Bitcoin carece de 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ódigo malicioso que poderia levar a ataques de negação de serviço (DOS), 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 evitar ataques e congestionamentos na rede. No entanto, o motivo pelo qual uma linguagem não completa em Turing é mais segura é insuficiente, e tal linguagem só pode realizar 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 mineiros 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 inferior ao 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 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 capital substancial para uma participação eficaz. Segundo, a maioria dos mineiros de Bitcoin não valida mais 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 Bitcoin processasse 2000 transações por segundo como o Visa, ela 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 controvérsia dentro da comunidade Bitcoin, pois blockchains maiores podem melhorar o desempenho, mas com o risco de centralização.

De uma perspetiva de ciclo de vida do produto, algumas das imperfeições menores do Bitcoin podem ser melhoradas dentro do seu 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 estiver sendo desenvolvido, então essas pequenas melhorias funcionais 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 extenso, 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 protocolos em "Uma Visão Geral da Construção do Sistema de Conhecimento Básico da Camada 2 do Bitcoin V1.5."

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

Na secção anterior, explorámos os principais conflitos da tecnologia original Bitcoin e alguns casos exploratórios, muitos dos quais levaram a hard forks ou à criação de cadeias heterogéneas inteiramente novas. No entanto, dentro da própria blockchain do Bitcoin, estas explorações também produziram muitos resultados, fundamentalmente sob a forma de expansão de blocos e melhoria de capacidades. Estas manifestam-se principalmente nos seguintes aspetos:

2.1. OP_RETURN

Os desenvolvedores do Bitcoin sempre procuraram 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 superior 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 principalmente usado como um método para armazenar dados no livro-razão. A funcionalidade do opcode OP_RETURN sofreu mudanças significativas no passado e é agora um mecanismo importante para armazenar dados arbitrários na cadeia.

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. Este opcode inicialmente tinha uma vulnerabilidade que era facilmente explorada, mas Satoshi Nakamoto rapidamente a corrigiu.

Mais Alterações à 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 a "saídas de transação não gastáveis". O volume de dados disponível nesses scripts foi inicialmente limitado a 40 bytes, depois aumentado para 80 bytes.

Armazenar Dados na Blockchain:

Alterar o OP_RETURN para sempre retornar falso teve resultados interessantes. Como nenhum outro código de operação ou dados são avaliados após o OP_RETURN, os usuários da rede começaram a usar este código de operação 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 que dados mais significativos promovam aplicações inovadoras na blockchain, como publicar conteúdo nas redes sociais da blockchain.

No BSV, o limite de 220 bytes ainda foi retido por um curto período. Mais tarde, em janeiro de 2019, porque o opcode OP_RETURN termina o script de uma forma que os nós não verificam quaisquer opcodes subsequentes, os nós também não verificaram se o script estava dentro do limite máximo de tamanho de script de 520 bytes. Consequentemente, os operadores de nós de rede decidiram aumentar o volume máximo da transação para 100 KB, concedendo assim aos desenvolvedores mais liberdade para a 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 aplicação em que alguém colocou um site inteiro no livro-razão do 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)

Segregated Witness, ou SegWit, foi proposto pela primeira vez por Pieter Wuille (desenvolvedor principal do Bitcoin e co-fundador da Blockstream) em dezembro de 2015 e mais tarde tornou-se 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 da transação.

2) Em provas SPV, a transferência de assinaturas de transações torna-se 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, tendo o maior impacto nas novas tecnologias 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 mais aprimoramentos no Taproot (a segunda versão do Segregated Witness).

Embora a implementação tenha aumentado a capacidade de 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, uma vez que os dados de testemunho não estão incluídos nesse limite, ainda há uma restrição no tamanho total do bloco para evitar abusos 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 das testemunhas

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, que não é detalhada aqui.

(3) Taproot (Testemunha segregada V2)

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

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

Em novembro de 2021, o Taproot foi oficialmente ativado como um soft fork. Este upgrade 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), mais uma vez expandindo a capacidade da rede e acelerando o processamento de transações em lote, fornecendo possibilidades para implantar contratos inteligentes complexos; o BIP 341 implementa Árvores de Sintaxe Abstrata Merkleizadas (MAST) para otimizar o armazenamento de dados de transações na blockchain; o BIP 342 (Tapscript) utiliza 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 Secção 2.1, observamos a exploração contínua do Bitcoin na escalabilidade e no aprimoramento da 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, ao expandir capacidades, exigiu demandas específicas do algoritmo de assinatura, introduzindo assim as assinaturas de Schnorr para substituir o Algoritmo de Assinatura Digital de Curva Elíptica (ECDSA). As assinaturas de Schnorr são um esquema de assinatura digital que pode assinar transações e mensagens de forma eficiente e segura. Foram descritas pela primeira vez por Claus Schnorr num artigo de 1991. Schnorr é aclamado pela 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 melhorada, mantendo todas as funcionalidades e pressupostos de segurança do ECDSA. Permitem tamanhos de assinatura menores, tempos de verificação mais rápidos e resistência melhorada 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 as assinaturas eletrónicas de configurações multisig ocupam o mesmo espaço num bloco que as de transações de uma única parte. Esta funcionalidade do Schnorr pode ser utilizada para reduzir o tamanho de pagamentos multisig e outras transações relacionadas com multisig, como transações de canais da Lightning Network.

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

4) Schnorr também oferece numerosas vantagens de privacidade. Torna os esquemas multisig indistinguíveis dos esquemas de chave única tradicionais para observadores externos, tornando mais difícil diferenciar os gastos multisig dos gastos de assinatura única na cadeia. Além disso, em configurações de multisig de n-of-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 manusear. Notavelmente, as assinaturas Schnorr são compatíveis com versões anteriores dos algoritmos criptográficos do BTC, permitindo que sejam introduzidas através de uma atualização do soft fork.

(2) Árvores de Sintaxe Abstrata MAST

Existe uma ligeira ambiguidade na abreviatura de MAST em Chinês e Inglês. Oficialmente, BIP (BIP 114) e alguns artigos usam a abreviatura MAST para: Árvore de Sintaxe Abstrata Merklizada. Outras fontes traduzem Árvores de Script Alternativas Merklizadas (MAST) para Chinês como Árvores de Script de Substituição Merklizadas (MAST). No livro “Dominando o Bitcoin” e num artigo, essa abreviatura é usada: https://cointelegraph.com/learn/a-beginners-guide-to-the-Bitcoin-Taproot-upgrade.

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

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

As Árvores de Sintaxe Abstrata (AST) pertencem ao domínio dos princípios do compilador 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. 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 a 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 do Bitcoin (carteiras SPV) usam árvores de Merkle para verificar se uma transação existe dentro de um bloco, poupando 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; este processo é repetido até que reste apenas um identificador, conhecido como a “raiz de Merkle,” que é um identificador conciso que representa todo o conjunto.

Ao verificar se um elemento pertence a um conjunto, o proprietário do conjunto pode fornecer-lhe todos os identificadores desse elemento até à raiz de Merkle. Isso prova que o elemento faz parte do conjunto.

Em resumo, a tecnologia por trás do AST permite dividir um programa em vários blocos pequenos, enquanto uma árvore de Merkle nos permite verificar se 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 substituir 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 com 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 de Taproot.

(3) Scripts de 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 de script de 10.000 bytes, proporcionando um ambiente melhor para a criação de contratos inteligentes na rede Bitcoin. Esta atualização também lançou as bases para o desenvolvimento posterior dos Ordinals, que utilizam scripts de gasto do 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 o seu potencial, especialmente na ligaçã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 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 Ordinais está altamente associada ao conceito de satoshis. O protocolo introduz os conceitos de ordinais e inscrições. Os 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 ORD de Rodarmor podem rastrear esses satoshis numerados, fornecendo um mecanismo preciso para as pessoas rastrearem cada satoshi e verificá-los independentemente.

As inscrições envolvem gravar informações nos satoshis. Ao aproveitar o SegWit e o Taproot, o protocolo Ordinais permite a gravação de arquivos menores que 4 MB em cada satoshi num bloco de Bitcoin - estas 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 a esses 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, os Ordinais são como um protocolo NFT, mas ao contrário do ETH ou de outras blockchains públicas onde os metadados NFT são geralmente armazenados no IPFS ou em servidores centralizados, os Ordinais incorporam metadados nos dados testemunhais da transação, como se estivessem “gravados” em um satoshi específico.

BRC-20: Inspirado no protocolo Ordinals, utilizador do Twitter @domodatacriou o padrão de token fungível experimental BRC-20 na 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 o faz 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, oferta 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 'primeiro a chegar, primeiro a ser servido' oferece oportunidades justas de emissão e participação. No entanto, a infraestrutura relativamente subdesenvolvida do ecossistema BTC e sua curva de aprendizado acentuada, combinadas com baixa liquidez, tornam fácil para tokens BRC-20 como ordi, sats e rats, alta repentina, 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 o Ordinals tinha muitas limitações que eram desfavoráveis para suportar algumas das funcionalidades que ele queria implementar. Consequentemente, 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, implantar tokens fungíveis no Atomicals resulta na criação de ARC-20. Os leitores interessados em ARC-20 podem ler mais aqui: Tokens ARC-20.

(3) Outros Protocolos - Rune

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

A transferência de Runes usa OP_RETURN, e o primeiro output de dados na mensagem de protocolo é decodificado numa sequência de inteiros, interpretada como uma série de tuplos (ID, OUTPUT, AMOUNT). Se o número de inteiros decodificados não for um múltiplo de três, a mensagem de protocolo é inválida. ID refere-se ao ID do Token a ser transferido, OUTPUT é o índice de output atribuído (ou seja, a que output está atribuído), e AMOUNT é a quantidade alocada. Após processar todas as alocações de tuplos, quaisquer Runes Tokens não alocados são atribuídos ao primeiro output não-OP_RETURN, podendo o restante ser inscrito com Runes Tokens no output OP_RETURN que contém a mensagem de protocolo.

A emissão de runas é baseada no rastreamento UTXO de tokens homogêneos. Se a mensagem de protocolo incluir um segundo envio de dados, ela representará uma transação de emissão. O segundo envio de dados é decodificado em dois inteiros, SYMBOL e DECIMALS. Se permanecerem números inteiros adicionais, a mensagem de protocolo será inválida. SYMBOL é um símbolo básico legível de 26 caracteres, semelhante aos usados em nomes ordinais, com os únicos caracteres válidos sendo de A a Z. DECIMALs indicam as casas decimais a serem usadas ao emitir Runas. Se SYMBOL ainda não tiver sido atribuído, o Token de Runas receberá um valor de ID (a partir de 1). Se SYMBOL já tiver sido atribuído ou for um dos BITCOIN, BTC ou XBT, nenhuma nova Runa será criada. Esta é uma característica especial do protocolo Runes — ele não vincula registros de saldo a endereços de carteira, mas os armazena dentro do próprio UTXO. Novos Tokens de Runas 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 Runes Tokens, independentemente de seu tamanho, e são usados apenas para rastrear saldos. Em seguida, a função de transferência usa essa UTXO, dividindo-a em várias UTXOs novas de tamanho arbitrário contendo diferentes quantidades de runas, 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 tokens nativos, tornando-o altamente adequado para o modelo UTXO nativo 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 na Counterparty, uma camada 2 do Bitcoin que existe desde 2014. Devido a atualizações em seus protocolos subjacentes, os selos fizeram uma 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 de Bitcoin permanentes. No entanto, o protocolo expandiu-se desde então para replicar o BRC-20, um tipo de token substituível em lote que prosperou no Bitcoin devido à febre de inscrições desencadeada pelo lançamento dos Ordinais por Casey Rodarmor em janeiro de 2023.

A principal diferença entre Stamps e Ordinais reside na sua arquitetura. Stamps armazena os seus metadados em outputs de transações não gastas de multi-assinaturas (UTXOs), enquanto os Ordinais armazenam os seus metadados na parte de “testemunha” das transações Bitcoin. Esta diferença arquitetónica destaca os compromissos feitos pelos programadores. Por exemplo, o método UTXO do Stamps torna-os não podáveis, aparentando assim ser permanentes, embora o seu custo de fabrico seja mais elevado do que o dos Ordinais. Por outro lado, o uso de dados de testemunha dos Ordinais acaba por torná-los podáveis, e o seu custo de fabrico é inferior ao dos Stamps.

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

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

Protocolo SRC 20

Protocolo SRC 721

Esta conclusão abrange 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 de camada superior do Bitcoin, como a Camada 2 do Bitcoin ou soluções que utilizam a Lightning Network. Para mais informações sobre este tema, os leitores são sugeridos a ler “Um Guia Abrangente para a Infraestrutura da Camada 2 do Bitcoin, Versão 1.5” e “Da Perspetiva das Máquinas de Estado: Observando a Arquitetura e o Caminho de Construção de Futuras Aplicações Web3.0,” ou outros artigos relacionados com a construção ou design arquitetônico da Camada 2 do Bitcoin.

3. Utilização de Nova Tecnologia e Necessidades de Desenvolvimento Futuro

Com base no conteúdo da Secção 2, observamos que a evolução tecnológica dentro do ecossistema Bitcoin lançou as bases para aplicações mais abrangentes. No entanto, como o desenvolvimento é um processo e algumas tecnologias relacionadas ainda estão imaturas, existe 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 secções anteriores, vemos que a essência do desenvolvimento tecnológico do Bitcoin consiste em expandir a capacidade e as capacidades do bloco.

Expansão do Bloco:Testemunha segregada (SegWit) expandiu eficazmente a capacidade do bloco, embora existam várias propostas para cortar os dados da testemunha, tais eventos são improváveis, especialmente depois de os dados da testemunha terem ganho mais importância.

Expansão de Capacidades:Tecnologias como Taproot, Schnorr, MAST e Scripts de Taproot melhoraram as capacidades do Bitcoin. Em particular, a combinação de MAST e Scripts de Taproot expande as habilidades da linguagem de script nativa do Bitcoin, permitindo o manuseio de cenários mais complexos. No entanto, a expansão dessas capacidades também aumenta a complexidade do desenvolvimento e da compreensão do Bitcoin, uma vez que o desenvolvimento de scripts 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 ritmo de aprendizagem dos usuários em relação à expansão da capacidade do bloco.

A simplicidade de usar a expansão de bloco versus a complexidade de expansão de capacidade explica por que os usuários armazenam inicialmente pequenas NFTs de imagens na mainnet do Bitcoin, levando ao surgimento de aplicações como BRC 20. A maioria das aplicações atualmente na mainnet do Bitcoin está explorando usos pós-expansão de bloco. Uma pequena parte das aplicações está começando a explorar a expansão de capacidade, como a conexão entre as primeiras e segundas camadas no BEVM, que utiliza proeminente os elementos básicos mencionados. A combinação de assinaturas Schnorr, contratos MAST e a rede de nós leve do Bitcoin (BTC L2) é um caso representativo de aprendizado de como conectar as primeiras e segundas camadas. São esperados mais casos de expansão de capacidade extensiva 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 são principalmente destinadas como conexões entre a primeira e segunda camadas do Bitcoin, então não devem se tornar excessivamente complicadas. No entanto, impulsionados pela criatividade humana e pelo forte atrativo da emissão e gestão de ativos, algumas equipas ou indivíduos irão explorar 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, então a emissão e gestão de ativos são necessidades diretas no domínio do Bitcoin ou blockchain. Desde a exploração de moedas coloridas até aplicações como BRC 20 e ARC 20, assim como ICOs e IDOs na Ethereum, estas são todas explorações de emissão de ativos. Aplicações como Uniswap, Empréstimos e AMMs são sobre gestão de ativos. Estes tipos de aplicações amadureceram em redes como Ethereum e, à medida que a tecnologia do ecossistema do Bitcoin evolui, é provável que estas aplicações de gestão de ativos se desloquem para o ecossistema do Bitcoin, particularmente para a segunda camada do Bitcoin.

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

O caminho para a construção é um processo de atender continuamente às necessidades, que pode ser dividido em fases de curto prazo, médio prazo e longo prazo. O curto prazo envolve novas aplicações de tecnologia na rede principal do Bitcoin e simples estágios 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, 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.

Disclaimer：

1. Este artigo é 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 Learnequipa e eles tratarão disso prontamente.
2. Isenção de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.