A verdade ignorada: o verdadeiro motivo por trás da liberação do OP_RETURN no Bitcoin Core v30

Chainfeeds Guia de Leitura:

A mudança de política do OP_RETURN no Bitcoin Core v30: não é uma rendição ao Ordinals, mas sim uma orientação proativa para o ecossistema BitVM. Não é uma resposta passiva à especulação, mas sim um preparo antecipado para a inovação tecnológica. Esta é uma reflexão prospectiva dos desenvolvedores do Core.

Fonte do artigo:

Autor do artigo:

Aaron Zhang

Opinião:

Aaron Zhang: Em abril de 2024, a Citrea lançou a primeira bridge BitVM completa — Clementine. É o primeiro zkRollup no Bitcoin, utilizando BitVM para validação no L1. Então, eles encontraram um desafio técnico: precisavam publicar 144 bytes de dados de ancoragem on-chain. Esses 144 bytes incluem 128 bytes: prova de conhecimento zero Groth16, e 16 bytes: total accumulated work (prova de trabalho acumulada). Esses dados são usados quando o Watchtower desafia o Operator, para provar que eles possuem a cadeia correta do Bitcoin. Eis o problema: o OP_RETURN permite apenas 83 bytes. Não é suficiente. Alguém pode perguntar por que não colocar no witness? Como o Ordinals faz? A diferença crucial é que as transações de validação subsequentes da Citrea precisam ler esses dados. E o Bitcoin Script não pode referenciar os dados witness da transação anterior. Portanto, os dados precisam estar na posição scriptPubKey, isso não é opcional. Simplificando: os dados witness só podem provar que a transação atual é válida, mas não podem ser lidos por transações futuras. Os dados scriptPubKey podem ser referenciados pelo Script de transações futuras. A lógica de validação do BitVM precisa de referência em cadeia, então deve usar scriptPubKey. 83 bytes não são suficientes, então a Citrea foi forçada a usar um método ruim: criar outputs Taproot "não gastáveis", disfarçando os dados como chaves públicas. O problema dessa solução é o aumento permanente do conjunto UTXO. Cada transação WatchtowerChallenge cria dois UTXOs que nunca poderão ser limpos. Todos os nós completos precisam armazenar permanentemente essas chaves públicas falsas. Este é exatamente o pior cenário que os desenvolvedores do Core sempre quiseram evitar. A linha de raciocínio dos desenvolvedores do Core: a situação atual é que a Citrea usa UTXOs falsos (ruim), no futuro mais projetos BitVM podem imitar ou usar multisig nu (como o protocolo Stamp). A conclusão é que seria melhor liberar o OP_RETURN, fornecendo um caminho de "menor dano". Esta é uma estratégia de harm reduction (redução de danos). Por que o Core está disposto a abrir caminho para o BitVM? Porque BitVM é uma direção importante de inovação no L1 do Bitcoin. O CEO da Blockstream, Adam Back, já disse: "O mecanismo de ancoragem do BitVM é uma direção importante para o L1". Se o ecossistema BitVM se desenvolver: vários zkRollups, bridges cross-chain e validações on-chain complexas terão necessidades semelhantes de ancoragem.