BRC-20 e os metaprotocolos

Curiosidade

1. O que acontece quando um padrão de token depende de servidores de terceiros para rastrear saldos, em vez do próprio consenso do Bitcoin?
2. Como uma pressa para cunhar tokens pequenos entupiu o mempool na primavera de 2023?
3. Por que a criação de milhões de saídas minúsculas representa uma ameaça específica à saúde a longo prazo do conjunto de UTXO?

Explorar

Parte ITokens BRC-20

1. O protocolo do Bitcoin ignora o significado dos dados embutidos nas transações; ele verifica apenas se os gastos são válidos. As inscrições (na lição anterior) mostraram que qualquer pessoa podia inserir conteúdo arbitrário nos dados de testemunho do Taproot sem alterar as regras de consenso. O BRC-20 deu o próximo passo: usando esse mesmo canal para implementar um sistema de tokens fungíveis sobre o qual o próprio Bitcoin não sabe nada.
2. O BRC-20 surgiu em março de 2023 como um padrão de token experimental desenvolvido diretamente com base no mecanismo de inscrição Ordinals. Criado pelo desenvolvedor pseudônimo Domo, ele utiliza objetos JSON simples para gerenciar tokens fungíveis. Uma inscrição “deploy” define um novo token com uma oferta máxima e um limite por emissão; inscrições subsequentes do tipo “mint” aumentam os saldos individuais, enquanto as inscrições “transfer” movem esses tokens entre carteiras. Como os nós do Bitcoin não validam esses dados para fins de consenso, o BRC-20 funciona como um aplicativo auxiliar que existe apenas na camada de interpretação.
3. A diferença arquitetônica crítica em relação aos ativos nativos é que o próprio Bitcoin não rastreia os saldos BRC-20. Os indexadores off-chain precisam analisar todo o histórico da blockchain para catalogar cada inscrição de deploy, mint e transfer a fim de calcular as posições dos usuários. Essa separação significa que um 'saldo' é um cálculo realizado por um serviço externo, e não um fato verificado pelo consenso proof-of-work do Bitcoin. Diferentes indexadores podem divergir sobre o estado se processarem as transações de maneira diferente ou sofrerem interrupções, introduzindo uma camada de dependência que o bitcoin nativo não possui.
4. Na primavera de 2023, o interesse especulativo por tokens BRC-20 causou um aumento histórico nas taxas de transação na rede Bitcoin. Milhares de usuários tentaram executar transações de “mint” simultaneamente para reivindicar sua cota antes que o limite global de oferta fosse atingido. Essa competição pelo espaço nos blocos elevou as taxas (em satoshis por byte virtual) ao nível mais alto em dois anos, e as taxas totais em alguns blocos ultrapassaram o subsídio do bloco pela primeira vez desde 2017, congestionando o mempool e atrasando os pagamentos padrão. Esse evento demonstrou como uma camada de aplicação externa pode afetar significativamente a dinâmica econômica da camada básica.
5. Os críticos argumentam que o BRC-20 representa um uso extremamente ineficiente do espaço limitado dos blocos do Bitcoin em comparação com outros protocolos de ativos. Ao armazenar strings JSON simples nos dados de testemunho, ele consome capacidade que poderia ser utilizada para transferências padrão, taxando efetivamente todos os usuários da rede por meio de taxas mais altas. Além disso, as muitas saídas pequenas criadas pelas ações frequentes de mint e transfer aumentam significativamente o conjunto de UTXO (Unspent Transaction Output), elevando as necessidades de armazenamento para os nós completos. Os defensores, por sua vez, afirmam que essa atividade representa uma demanda legítima pelo espaço nos blocos do bitcoin, gerando novas fontes de receita para os mineradores à medida que o halving da recompensa se aproxima.
6. Abra um explorador de blocos e inspecione uma transação de criação de tokens BRC-20 de maio de 2023. Os dados JSON brutos estão embutidos no “witness” da entrada que utiliza a saída Taproot. Ao consultar uma carteira padrão de Bitcoin para obter o “saldo BRC-20”, o resultado é zero, a menos que ela esteja conectada a um indexador externo como Unisat ou Magic Eden, o que mostra que o token existe apenas na camada de interpretação. Essa desconexão entre os dados on-chain e a contabilidade off-chain é a característica definidora do experimento BRC-20.

Parte IITokens em Bitcoin: Ordinais, BRC-20, Runas e metaprotocolos programáveis

7. Casey Rodarmor lançou o Ordinals em janeiro de 2023, atribuindo um número de série a cada satoshi com base em sua posição na cadeia. Isso permitiu que dados fossem inscritos em satoshis específicos por meio de caminhos de script Taproot. O protocolo tratava cada unidade como única, de forma semelhante aos tokens não fungíveis em outras cadeias. Os nodes do Bitcoin registravam a transação, mas não validavam o conteúdo da inscrição nem aplicavam nenhuma lógica específica dos tokens além das regras padrão UTXO.
8. Em março de 2023, a Domo introduziu o BRC-20, utilizando inscrições em JSON dentro dos Ordinals para criar tokens fungíveis por meio das funções deploy, mint e transfer. Essa abordagem era pouco eficiente; dependia inteiramente de indexadores off-chain para analisar o JSON e manter os saldos. Diferentes indexadores podiam chegar a conclusões distintas sobre o estado dos tokens caso perdessem transações ou interpretassem as regras de maneira diferente. O padrão consumia uma quantidade significativa de espaço nos blocos, sem adicionar segurança ao nível do consenso para os próprios tokens.
9. Rodarmor lançou os Runes no bloco 840.000, em 20 de abril de 2024, coincidindo com o halving para 3,125 BTC. As transferências de Runes são descritas por mensagens de protocolo chamadas runestones, nas saídas OP_RETURN; os saldos em si ficam em UTXOs comuns. Diferentemente do JSON dos BRC-20, os Runes utilizam um formato binário compacto interpretado por indexadores. Uma transação pode conter saldos de múltiplos runes em suas saídas. O protocolo é baseado em UTXO, o que significa que os saldos de runes estão associados a saídas específicas e se movem de entradas para saídas.
10. Todos esses protocolos são metaprotocolos: o Bitcoin registra os dados na cadeia, mas softwares fora da cadeia interpretam as regras. Os nós de consenso não rastreiam os saldos dos tokens nem impõem limites de criação; os indexadores fazem isso. Isso cria um modelo de confiança no qual a camada de liquidação (Bitcoin) é segura, mas a lógica do aplicativo depende do acordo entre os indexadores. Se um indexador falhar ou agir de forma maliciosa, os usuários podem perder acesso ao saldo que consideram ter, mesmo que os satoshis subjacentes permaneçam intactos.
11. Metaprotocolos mais recentes, como os Alcanos, ampliam isso ao executar contratos em WebAssembly dentro dos indexadores, adicionando capacidades de programação além das simples transferências de tokens. Isso aumenta a complexidade e intensifica a dependência da computação off-chain. O trade-off permanece o mesmo: os usuários ganham recursos mais expressivos às custas do deslocamento da aplicação das regras para fora da camada de consenso do Bitcoin. A liquidação é definitiva no nível do Bitcoin, mas a consistência do estado depende inteiramente do ecossistema dos indexadores.
12. Para verificar isso, abra um explorador de blocos que suporte Runes e inspecione qualquer transação que contenha uma saída OP_RETURN com dados de runestone. O runestone codifica os IDs das runas (no formato BLOCK:TX) e os valores. Em seguida, verifique um nó padrão do Bitcoin; ele validará a assinatura e a estrutura UTXO, mas não exibirá informações sobre o saldo do token, confirmando que o estado do token existe apenas no banco de dados do indexador.

Fatos-chave

Exercício nove, seis, três, um

Verificação de fatos

Datas, números e afirmações verificados com as fontes publicadas listadas abaixo.

• Domo, 'BRC-20' documentation (March 2023)
• Bitcoin Optech newsletter coverage (2023)
• mempool.space fee history data (Spring 2023)
• C. Rodarmor, Ordinals documentation (docs.ordinals.com, 2023)
• domo, BRC-20 experiment documentation (March 2023)
• C. Rodarmor, Runes documentation (April 2024)
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023)
• Alkanes protocol documentation