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 aos Ordinals, mas sim uma orientação ativa 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 em L1. Depois, eles encontraram um desafio técnico: precisavam publicar 144 bytes de dados de ancoragem na blockchain. 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. Surge o problema: o OP_RETURN só permite 83 bytes. Não é suficiente. Alguém pode perguntar por que não colocar no witness? Como os Ordinals? A diferença crucial é que as transações de verificação subsequentes da Citrea precisam ler esses dados. E o Bitcoin Script não pode referenciar os dados de witness da transação anterior. Portanto, os dados precisam estar na posição scriptPubKey, isso não é opcional. Simplificando: os dados do Witness só podem provar que a transação atual é válida, mas não podem ser lidos por transações subsequentes. Os dados do scriptPubKey podem ser referenciados pelo Script de transações futuras. A lógica de verificação do BitVM requer 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 muito ruim: criar outputs Taproot "não gastáveis", disfarçando os dados como chaves públicas. O problema desse método é a inflação permanente do conjunto UTXO. Cada transação WatchtowerChallenge cria dois UTXOs que nunca poderão ser limpos. Todos os nós completos devem armazenar essas chaves públicas falsas para sempre. Este é exatamente o pior cenário que os desenvolvedores do Core sempre quiseram evitar. A cadeia 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 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.