Todos estão a falar sobre o Bitcoin Core v30 a levantar a restrição do OP_RETURN, mas a maioria das pessoas tem a ideia errada. Isto não é o Core a render-se ao hype dos Ordinals—é o Core a abrir caminho para o futuro do BitVM. Aqui está o que realmente aconteceu.
O Problema Real de que Ninguém Estava a Falar
Em abril de 2024, quando a Citrea lançou a Clementine (o primeiro zkRollup baseado em BitVM), eles encontraram uma parede. Precisavam de armazenar 144 bytes de dados críticos na cadeia—128 bytes para provas de conhecimento zero e 16 bytes para prova de trabalho total. Estes dados são referenciados mais tarde quando torres de vigilância desafiam operadores e precisam de verificar a cadeia do Bitcoin.
Mas aqui está o problema: o OP_RETURN só permite 83 bytes. Não é suficiente.
Por que Não Usar Apenas Dados de Testemunha Como os Ordinals?
É aqui que a nuance técnica importa. Os Ordinals podem usar dados de testemunha porque só se preocupam em provar a validade de uma transação. Mas a verificação do BitVM requer referência encadeada—transações subsequentes precisam de ler esses dados. O Script do Bitcoin tem uma regra rígida: não se pode ler os dados de testemunha de transações anteriores. Ponto final.
Os dados devem estar no scriptPubKey. Não é uma escolha; é uma exigência técnica. Pense assim: os dados de testemunha estão selados numa encomenda (apenas prova a transação atual), enquanto os dados do scriptPubKey estão num local público onde futuras transações podem realmente vê-los e usá-los.
A Solução Complicada que fez o Core Mover-se
Forçados pelo limite de 83 bytes, a Citrea teve que ser criativa—e feio. Criaram outputs Taproot “não gastáveis”, disfarçando dados como chaves públicas falsas. Parece inteligente, mas tem um efeito colateral terrível: cada desafio de torre de vigilância cria dois UTXOs que nunca podem ser limpos. Nós, nós completos, temos que armazenar permanentemente essas chaves públicas falsas.
Este é exatamente o cenário de pesadelo que os desenvolvedores do Core têm tentado evitar há anos. Inchaço de UTXO. lixo permanente na cadeia.
A Estratégia de Redução de Dano
O Core viu a situação claramente: a Citrea já usa UTXOs falsos (mau), e se o BitVM pegar, mais projetos seguirão o exemplo ou recorrerão a multisig simples como o protocolo Stamp. Abordagens ainda piores.
Por isso, o Core tomou uma decisão—relaxar o OP_RETURN e oferecer o caminho “menos prejudicial”. Pode chamá-lo de pragmatismo ou pensamento estratégico, mas é basicamente uma redução de dano: se os projetos de BitVM devem ancorar dados, que o façam sem inflar o conjunto de UTXOs.
Porque Isto Realmente Importa para o Futuro do Bitcoin
O BitVM não é apenas mais uma inovação cripto—é uma infraestrutura L1 real. Adam Back, CEO da Blockstream, chamou o mecanismo de ancoragem do BitVM de “uma direção importante para o L1”. Se pegar (e os sinais apontam nesse sentido), estamos a falar de um ecossistema de zkRollups, pontes entre cadeias, e sistemas complexos de verificação na cadeia. Todos precisando de soluções de ancoragem semelhantes.
Ao relaxar o OP_RETURN agora, o Core está a abrir caminho para que esta camada de infraestrutura se desenvolva de forma limpa. É uma visão de futuro, não reativa. A escalabilidade do Bitcoin pode depender de decisões como esta mais do que as pessoas percebem.
Da próxima vez que alguém disser que o Core está a comprometer-se, pergunte se o inchaço permanente de UTXO ou um limite de OP_RETURN ligeiramente maior é o melhor compromisso.
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
Por que a alteração do OP_RETURN no Bitcoin Core v30 é na verdade um movimento estratégico (Não uma concessão)
Todos estão a falar sobre o Bitcoin Core v30 a levantar a restrição do OP_RETURN, mas a maioria das pessoas tem a ideia errada. Isto não é o Core a render-se ao hype dos Ordinals—é o Core a abrir caminho para o futuro do BitVM. Aqui está o que realmente aconteceu.
O Problema Real de que Ninguém Estava a Falar
Em abril de 2024, quando a Citrea lançou a Clementine (o primeiro zkRollup baseado em BitVM), eles encontraram uma parede. Precisavam de armazenar 144 bytes de dados críticos na cadeia—128 bytes para provas de conhecimento zero e 16 bytes para prova de trabalho total. Estes dados são referenciados mais tarde quando torres de vigilância desafiam operadores e precisam de verificar a cadeia do Bitcoin.
Mas aqui está o problema: o OP_RETURN só permite 83 bytes. Não é suficiente.
Por que Não Usar Apenas Dados de Testemunha Como os Ordinals?
É aqui que a nuance técnica importa. Os Ordinals podem usar dados de testemunha porque só se preocupam em provar a validade de uma transação. Mas a verificação do BitVM requer referência encadeada—transações subsequentes precisam de ler esses dados. O Script do Bitcoin tem uma regra rígida: não se pode ler os dados de testemunha de transações anteriores. Ponto final.
Os dados devem estar no scriptPubKey. Não é uma escolha; é uma exigência técnica. Pense assim: os dados de testemunha estão selados numa encomenda (apenas prova a transação atual), enquanto os dados do scriptPubKey estão num local público onde futuras transações podem realmente vê-los e usá-los.
A Solução Complicada que fez o Core Mover-se
Forçados pelo limite de 83 bytes, a Citrea teve que ser criativa—e feio. Criaram outputs Taproot “não gastáveis”, disfarçando dados como chaves públicas falsas. Parece inteligente, mas tem um efeito colateral terrível: cada desafio de torre de vigilância cria dois UTXOs que nunca podem ser limpos. Nós, nós completos, temos que armazenar permanentemente essas chaves públicas falsas.
Este é exatamente o cenário de pesadelo que os desenvolvedores do Core têm tentado evitar há anos. Inchaço de UTXO. lixo permanente na cadeia.
A Estratégia de Redução de Dano
O Core viu a situação claramente: a Citrea já usa UTXOs falsos (mau), e se o BitVM pegar, mais projetos seguirão o exemplo ou recorrerão a multisig simples como o protocolo Stamp. Abordagens ainda piores.
Por isso, o Core tomou uma decisão—relaxar o OP_RETURN e oferecer o caminho “menos prejudicial”. Pode chamá-lo de pragmatismo ou pensamento estratégico, mas é basicamente uma redução de dano: se os projetos de BitVM devem ancorar dados, que o façam sem inflar o conjunto de UTXOs.
Porque Isto Realmente Importa para o Futuro do Bitcoin
O BitVM não é apenas mais uma inovação cripto—é uma infraestrutura L1 real. Adam Back, CEO da Blockstream, chamou o mecanismo de ancoragem do BitVM de “uma direção importante para o L1”. Se pegar (e os sinais apontam nesse sentido), estamos a falar de um ecossistema de zkRollups, pontes entre cadeias, e sistemas complexos de verificação na cadeia. Todos precisando de soluções de ancoragem semelhantes.
Ao relaxar o OP_RETURN agora, o Core está a abrir caminho para que esta camada de infraestrutura se desenvolva de forma limpa. É uma visão de futuro, não reativa. A escalabilidade do Bitcoin pode depender de decisões como esta mais do que as pessoas percebem.
Da próxima vez que alguém disser que o Core está a comprometer-se, pergunte se o inchaço permanente de UTXO ou um limite de OP_RETURN ligeiramente maior é o melhor compromisso.