Pela primeira vez em quatro anos, o Bitcoin pode ter uma "forquilha suave liderada pelos usuários"?

A comunidade básica do Bitcoin começou a promover mudanças no software subjacente do Bitcoin, algo raro em mais de quatro anos.

Escrito por: GaryMa Wu disse Blockchain

Segundo a Blockspace, a comunidade básica do Bitcoin começou a promover mudanças no software subjacente do Bitcoin, algo raro nos últimos quatro anos (as alterações significativas no subjacente foram anteriormente lideradas pelo grupo de desenvolvedores principais).

Os dois propostas de melhoria do Bitcoin (BIP) que estão a receber apoio nas bases são o BIP-119 (CTV) e o BIP-348 (CSFS). Estas duas propostas introduzem uma nova forma de escrever scripts para Bitcoin, permitindo que o Bitcoin implemente a funcionalidade de “contratos” (Covenants). Estas duas propostas poderão ser implementadas na próxima bifurcação suave do Bitcoin.

Para evitar que alguns leitores não consigam entender temporariamente os Covenants do Bitcoin e a relação com esses específicos esquemas BIP, aqui vamos esclarecer:

De forma simples, Covenants é um conceito funcional na rede Bitcoin, e os dois BIP mencionados no texto são diferentes soluções de implementação para realizar este conceito funcional.

O que são os Covenants do Bitcoin?

Definição:

Covenants é um mecanismo proposto no protocolo Bitcoin que permite estabelecer condições ou restrições nas transações, especificando como a moeda deve ser gasta ou transferida. Essas condições podem abranger várias transações, limitando as formas de gasto futuro, o que aumenta as funcionalidades de script do Bitcoin.

Função:

• Aumentar a capacidade dos contratos inteligentes do Bitcoin, suportando aplicações mais complexas (como empréstimos, exchanges descentralizadas, cofres).
• Aumentar a segurança, prevenir o roubo ou uso indevido de fundos.
• Otimizar o desempenho da rede, como reduzir taxas de transação ou aumentar a privacidade.

Aqui podemos entender claramente que Covenants é um conceito, enquanto o BIP-119 (CTV) e o BIP-348 (CSFS) mencionados neste artigo são implementações concretas do conceito funcional de Covenants.

Estado atual:

A mainnet do Bitcoin atualmente não integrou formalmente nenhuma funcionalidade relacionada a Covenants, embora discussões e propostas relacionadas (como BIP-119) tenham avançado por anos.

BIP 119：OP_CHECKTEMPLATEVERIFY (CTV)

Uma proposta de opcode Bitcoin que permite que a saída de uma transação especifique um “template”, exigindo que as saídas das transações de gasto subsequentes correspondam a esse template.

Proposto pelo ex-contribuidor do núcleo do Bitcoin, Jeremy Rubin, existe há mais de cinco anos. Ele implementa a funcionalidade de “carregamento de estado” ao limitar os fundos a serem gastos apenas de maneira predefinida.

Cenários de aplicação incluem:

• Criar pagamentos em lote (Batch Payments), reduzindo as taxas de transação. Construir uma exchange descentralizada (DEX) ou um protocolo de empréstimo.
• Implementar Vaults (cofres), protegendo os fundos contra roubo.
• CTV é uma implementação leve de Covenants, focada em restrições de formato de saída, sem envolver lógica complexa.

BIP 348：OP_CHECKSIGFROMSTACK (CSFS)

Uma proposta de opcode Bitcoin que permite verificar se uma assinatura é válida para qualquer mensagem (Message), e não apenas para o hash da transação atual. Ele obtém a assinatura, a chave pública e a mensagem da pilha de dados e verifica se a assinatura corresponde.

Proposto oficialmente por Jeremy Rubin e Brandon Black em novembro de 2024.

OP_CSFS é uma poderosa ferramenta para implementar Covenants mais flexíveis, pois permite a “auto-reflexão” (Introspection) sobre as entradas da transação, ou seja, verificar o conteúdo ou estado completo da transação assinada.

Aplicações específicas:

• Realização de Covenants: OP_CSFS pode ser usado para criar lógicas de condições complexas, garantindo que os fundos só possam ser gastos de acordo com regras específicas. Por exemplo, os validadores podem verificar se as entradas da transação atendem a modelos ou restrições predefinidos.
• Melhoria de segurança: suporte a Vaults e protocolos descentralizados, prevenindo roubos ou gastos não autorizados através da verificação de assinatura.
• Escalabilidade: combinada com outros códigos de operação (como OP_CAT), pode construir contratos inteligentes mais complexos.

E ao mencionar os Covenants do Bitcoin e as duas propostas BIP-119 (CTV) e BIP-348 (CSFS), não pode faltar o OP_CAT.

BIP 347：OP_CAT

História:

Existência inicial: OP_CAT é parte da linguagem de script original do Bitcoin, incluída por Satoshi Nakamoto quando o Bitcoin foi lançado em 2009. Foi projetado inicialmente para aumentar a flexibilidade do script, suportando lógica mais complexa.

Razão para remoção (2010):

• OP_CAT foi removido (desativado) em 2010, devido a potenciais vulnerabilidades de segurança e abuso de recursos.
• Questão específica: Se não houver restrições, o OP_CAT pode ser utilizado por usuários mal-intencionados para gerar dados de comprimento infinito (através de chamadas recursivas), levando a um “ataque de negação de serviço” (DoS Attack), uma vez que os nós Bitcoin precisam processar esses dados, aumentando o custo de computação e armazenamento.
• Naquela altura, a linguagem de script do Bitcoin foi simplificada, mantendo as funções mais básicas, garantindo a leveza, segurança e descentralização do protocolo.

Definição e função:

OP_CAT é um código de operação (Opcode) da linguagem de script do Bitcoin (Script), não sendo uma implementação direta de Covenant, mas sim uma ferramenta potencial para construir lógicas complexas de Covenant. Comparado aos dois códigos de operação mencionados, OP_CAT é mais geral, adequado para operações de dados, mas precisa ser combinado com outros códigos de operação para realizar funções complexas.

Situação atual:

A comunidade Bitcoin tem discutido recentemente o retorno do OP_CAT, que anteriormente apareceu sob a forma da proposta BIP-420, considerada mais uma brincadeira da comunidade, mas que agora está oficialmente integrada ao repositório bitcoin/bips sob o número BIP-347.

Como está o progresso

De acordo com a Coindesk, nas últimas semanas, muitos desenvolvedores de Bitcoin ocidentais expressaram no Twitter seu apoio ao CTV e ao CSFS — — isso é, sem dúvida, um forte sinal de que, pelo menos no círculo das redes sociais, parte da comunidade do Bitcoin está avançando na direção de aceitar essas mudanças.

Além disso, os desenvolvedores geralmente acreditam que a definição dessas duas propostas é “estreita”. Em termos simples, isso significa que, uma vez ativadas, a probabilidade de serem mal utilizadas inadvertidamente pelos usuários é baixa. A comunidade de desenvolvedores do Bitcoin sempre teve uma atitude cautelosa em relação às mudanças no Bitcoin. Por exemplo, embora o BIP 119 tenha estado em espera por quase cinco anos, recentemente, o CTV foi considerado demasiado radical para ser ativado.

Os co-fundadores dessas duas propostas, Jeremy Rubin, enfrentaram forte oposição anteriormente por suas atividades para promover o CTV — especialmente as críticas de alguns influenciadores de Bitcoin com muitos seguidores, como Adam Back e Jimmy Song. Essas críticas acabaram se transformando em um amplo descontentamento na comunidade Bitcoin, forçando Rubin a se afastar do espaço Bitcoin.

Então, o que exatamente contribuiu para essa mudança? A recente defesa do opcode OP_CAT parece ter ampliado o escopo das propostas de Bitcoin consideradas “aceitáveis”, delimitando CTV e CSFS como opções relativamente “conservadoras”. Vale ressaltar que a maioria dos apoiadores do OP_CAT também apoia o BIP 119 e o BIP 348 (bem como a maioria das outras propostas).

O que podemos esperar a seguir? Primeiro, a discussão continuará. Espera-se que os desenvolvedores explorem ainda mais essas propostas em várias conferências técnicas, como a OPNEXT prevista para abril, a BTC++ em julho e a TABConf em outubro. Uma vez que os desenvolvedores cheguem a um consenso preliminar, a ativação real do soft fork será entregue aos mineradores, à comunidade e aos investidores para a confirmação final.

Como acompanhar o progresso das discussões sobre os BIPs na comunidade / o processo de fork suave?

A resposta é muito difícil!

A comunidade técnica do Bitcoin geralmente discute essas propostas em profundidade. Mas este é um processo de discussão que parece obscuro e cíclico.

De forma simples, o processo de soft fork do Bitcoin requer uma estimativa do nível de apoio de todas as partes interessadas do Bitcoin, incluindo desenvolvedores, custodiante, investidores e mineradores. O indicador de apoio mais direto geralmente vem dos mineradores, pois eles podem sinalizar sua aprovação às alterações no repositório de código ao emitir sinais nos blocos que mineram. Normalmente, o Bitcoin Core exige que 95% dos blocos emitam sinais de apoio durante um determinado período, antes que a atualização seja bloqueada para ativação.

No entanto, ainda não há um consenso sobre como definir o que significa “ampla aceitação”; o consenso sobre Bitcoin continua a evoluir. Os mineradores tornam-se fornecedores de sinais importantes apenas porque são entidades “contáveis” na rede Bitcoin. Em outras palavras, devido à estrutura descentralizada do Bitcoin, é difícil medir o consenso geral a partir de uma perspectiva “visível a olho nu”.

No entanto, uma empresa de desenvolvimento famosa por seus NFTs de Bitcoin, Taproot Wizards, utiliza o OP_CAT como exemplo para revelar, através de um diagrama de fluxo, o longo e complexo processo do soft fork do Bitcoin. Leitores interessados podem consultar por conta própria; aqui tentamos resumir um pouco:

Ciclo de Vida das Propostas BIPs | O longo e complexo processo de fork suave do Bitcoin

1. A proposta foi inicialmente apresentada e discutida na lista de correio dos desenvolvedores de Bitcoin.

2. Entrar em discussões de uma comunidade maior, entrou na armadilha da discussão de longo prazo sobre os prós e contras da funcionalidade de proposta; se não for possível avançar mais, ficará por aqui.

3. As comunidades de base escrevem rascunhos de BIP para propostas no Github.

4. Os desenvolvedores começam a implementar o código relevante, devendo não haver bugs de auditoria a longo prazo para poderem continuar.

5. Após a revisão dos editores do repositório Bitcoin BIP e a aprovação preliminar da comunidade, é atribuído um número BIP oficial.

6. Aceda à rede de testes Signet. Signet é uma rede de testes do Bitcoin que permite aos desenvolvedores experimentar novas funcionalidades ou alterações de código sem afetar a rede principal. (A maioria das novas funcionalidades pode ficar permanentemente suspensa nesta etapa)

7. Possivelmente entrar na sidechain Liquid para experimentação.

8. Submeter PR ao Bitcoin Core.

9. Entrar no processo de revisão do código-fonte do Bitcoin e fusão de propostas é altamente incerto. As propostas só têm a chance de entrar na fase de fusão depois de evitar a maioria das objeções e atender aos requisitos técnicos (sem bugs graves); a opinião de desenvolvedores-chave (como Pieter Wuille) é muitas vezes crucial, sendo a aceitação ou rejeição capaz de impactar significativamente o destino da proposta.

10. Se a auditoria do código estiver em ordem, aguarde que o mantenedor do repositório Bitcoin mescle o PR no projeto principal. Atualmente, há cinco mantenedores: Michael Ford (fanquake), Hennadii Stepanov (hebasto), Andrew Chow (achow101), Gloria Zhao (glozow), Ryan Ofsky (ryanofsky).

11. Continua a haver potenciais controvérsias e discussões entre diferentes grupos, como desenvolvedores de Bitcoin e mineradores.

12. Escolher o mecanismo de ativação:

a. Fork suave liderado por mineradores (MASF): ativado por mineradores através de sinalização (geralmente um limiar de 95%), como o modo padrão do BIP-9 ou BIP-8. Mais estável, mas requer coordenação de consenso amplo e testes, portanto leva mais tempo;

b. Soft Fork liderado pelo usuário (UASF): ativação forçada de novas regras (como “Lockinontimeout: True” do BIP-8) pelos operadores de nós (usuários), contornando a resistência dos mineradores, com risco potencial de bifurcação da cadeia e divergência na comunidade.

Conclusão

Wu disse anteriormente que o mantenedor do domínio Bitcoin.org, Cobra, alertou que a rede Bitcoin pode enfrentar um fork suave liderado por usuários (UASF) iniciado por desenvolvedores anônimos fora do núcleo do Bitcoin em 2025, referindo-se na verdade às possíveis mudanças do BIP 119 mencionadas neste artigo. Cobra acredita que essas melhorias podem causar uma divergência entre os “conservadores” e os “reformistas”, liderada pela comunidade de base e impulsionada por desenvolvedores que não pertencem ao núcleo do Bitcoin.

Entende-se que UASF (user-led soft fork) é uma atualização de protocolo iniciada por usuários de Bitcoin, atualizando o software do nó para impor atualizações de protocolo, mesmo que os mineradores ou outras partes não o suportem, então isso também significa o risco de fork em cadeia. É claro que não há necessidade de se preocupar com isso no momento, afinal, muitos ainda estão sem solução. Por exemplo, os futuros soft forks conterão apenas CTVs e CSFS? O OP_CAT, que é frequentemente discutido com este conjunto de opcodes, será tido em conta? Como se desenrolará o processo real de ativação do soft fork? Será que outras partes interessadas, como os mineradores de Bitcoin, prestarão atenção suficiente?

Afinal, desde que o consenso dos BIPs seja suficientemente grande, propostas impulsionadas pela comunidade de base também podem ser realizadas na forma de um fork suave liderado por mineradores (MASF). E mesmo o UASF teve casos de sucesso na história. O UASF desempenhou um papel crucial na atualização do SegWit em 2017, onde os usuários conseguiram impulsionar um fork suave, evitando um fork duro e promovendo a expansão do Bitcoin.

Link de referência: