Um soft fork é uma atualização retrocompatível das regras de consenso de um protocolo blockchain, na qual o conjunto de blocos válidos sob as novas regras é um subconjunto estrito dos blocos que eram válidos sob as regras antigas. Em termos práticos, isso significa que os nós que executam o software antigo ainda aceitarão blocos produzidos por nós atualizados, porque os novos blocos estão em conformidade com as regras antigas – eles são simplesmente mais restritivos. Ao contrário de um hard fork, que cria tipos de blocos totalmente novos que os nós antigos rejeitariam (potencialmente dividindo a cadeia), um soft fork realiza a evolução do protocolo sem exigir que todos os participantes atualizem simultaneamente.
A retrocompatibilidade dos soft forks é sua característica definidora e sua principal vantagem. Quando um soft fork é ativado, os mineradores ou validadores atualizados começam a aplicar as novas regras, mais rigorosas. Os nós não atualizados consideram esses blocos válidos porque eles ainda estão em conformidade com as regras originais, menos rigorosas. No entanto, se um minerador não atualizado produzir um bloco que viole as novas regras (mas esteja em conformidade com as antigas), os nós atualizados o rejeitarão. Isso cria uma assimetria: os nós atualizados aplicam um conjunto de regras mais rigoroso, enquanto os nós não atualizados são "enganados" e aceitam os blocos mais rigorosos porque eles não violam as regras antigas. Contanto que a maioria do poder de mineração (ou poder de staking, em sistemas de prova de participação ) aplique as novas regras, a cadeia convergirá para o conjunto de regras atualizado sem se dividir.
Desde os primórdios do Bitcoin, os soft forks têm sido o mecanismo preferido para atualizações do protocolo. Grandes melhorias no Bitcoin, incluindo Pay-to-Script-Hash (P2SH), Segregated Witness (SegWit) e Taproot, foram todas implementadas por meio de soft forks. Essa abordagem reflete uma filosofia conservadora na cultura de desenvolvimento do Bitcoin: as mudanças devem ser minimamente disruptivas, retrocompatíveis e viáveis sem forçar toda a rede a se atualizar simultaneamente. A contrapartida é que os soft forks são mais limitados quanto às mudanças que podem introduzir – eles podem restringir regras ou adicionar novos tipos de transação que os nós antigos interpretam como saídas de "qualquer um pode gastar", mas não podem flexibilizar regras existentes ou alterar fundamentalmente a estrutura dos blocos.
A mecânica de como um soft fork mantém a compatibilidade com versões anteriores geralmente envolve truques técnicos engenhosos. Por exemplo, o SegWit introduziu um formato de transação completamente novo com uma estrutura de dados de testemunha, mas os nós antigos simplesmente viam as transações SegWit como gastos de endereços que "qualquer um pode gastar" – válidos sob as regras antigas, mas com um novo significado sob as regras atualizadas. Esse padrão de codificar novas semânticas dentro de estruturas de regras existentes é uma característica marcante da engenharia de soft forks, exigindo considerável engenhosidade para implementar mudanças complexas dentro das restrições de compatibilidade com versões anteriores.
Origem e história
2010: O primeiro soft fork de facto no Bitcoin ocorreu quando Satoshi Nakamoto introduziu diversas alterações que tornaram as regras do código-fonte do Bitcoin mais rígidas, incluindo a adição dos opcodes OP_NOP e o limite de tamanho de bloco de 1 MB. Essas alterações invalidaram comportamentos anteriormente válidos, constituindo efetivamente um soft fork, embora o termo ainda não estivesse em uso.
2012: O BIP 16 introduziu o Pay-to-Script-Hash (P2SH), uma das primeiras atualizações de soft fork formalmente reconhecidas para o Bitcoin. Proposto por Gavin Andresen, o P2SH permitiu scripts de transação mais complexos, mantendo a compatibilidade com versões anteriores ao codificar o hash de um script em um endereço de aparência padrão. Essa atualização foi ativada em 1º de abril de 2012 e estabeleceu muitos dos precedentes para a forma como os soft forks do Bitcoin seriam coordenados.
2015: As BIPs 65 (OP_CHECKLOCKTIMEVERIFY) e 66 (codificação de assinatura DER rigorosa) foram ativadas como soft forks, introduzindo transações com bloqueio temporal e validação de assinatura mais rigorosa. Essas atualizações usaram a sinalização de minerador "IsSuperMajority" – exigindo que 950 dos últimos 1,000 blocos sinalizassem suporte antes da ativação.
2016: A comunidade Bitcoin iniciou um debate plurianual sobre escalabilidade que definiria a relação entre soft forks e hard forks. A proposta SegWit (BIP 141) foi apresentada como uma solução de soft fork para a maleabilidade das transações e um modesto aumento de capacidade, enquanto facções opostas defendiam um hard fork para aumentar diretamente o limite do tamanho do bloco. Esse debate cristalizou a distinção filosófica entre soft forks e hard forks na cultura das criptomoedas.
2017: O Segregated Witness (SegWit), o soft fork mais significativo da história do Bitcoin até então, foi implementado em 8 de agosto de 2017, após 100% dos mineradores em um período de sinalização atingirem o limite de 95%, e ativado em 24 de agosto de 2017, na altura do bloco 481,824. O SegWit separou os dados de assinatura dos dados de transação, corrigindo a maleabilidade das transações, viabilizando a Lightning Network e aumentando a capacidade efetiva dos blocos. Sua ativação foi catalisada pelo movimento User Activated Soft Fork (UASF), no qual os operadores de nós ameaçaram impor o SegWit independentemente da sinalização dos mineradores.
2021: Taproot, o próximo grande soft fork do Bitcoin, foi implementado em 12 de junho de 2021, no bloco 687,284, após atingir o limite de sinalização de 90% dos mineradores, e ativado em 14 de novembro de 2021, na altura do bloco 709,632. Proposto inicialmente por Greg Maxwell e formalizado por meio de BIPs (Propostas de Melhoria de Bitcoin) escritas por Pieter Wuille, Tim Ruffing, AJ Townes e Jonas Nick, o Taproot introduziu as assinaturas Schnorr e as Árvores de Script Alternativas Merkelizadas (MAST), aprimorando significativamente a privacidade, a eficiência e os recursos de contratos inteligentes do Bitcoin. O Taproot utilizou o mecanismo de ativação Speedy Trial (uma variante do BIP 8), atingindo o limite de sinalização de 90% dos mineradores dentro de uma única janela de sinalização.
2023–2026: A comunidade Bitcoin se envolveu em um debate acirrado sobre possíveis futuros soft forks, incluindo propostas para OP_VAULT (BIP 345) para segurança de custódia aprimorada, OP_CAT (BIP 347) para funcionalidade de covenants e CTV (OP_CHECKTEMPLATEVERIFY, BIP 119) para modelos de transação. Essas propostas destacaram a tensão contínua entre a filosofia conservadora de atualização do Bitcoin e o desejo por funcionalidades aprimoradas.
Em termos simples
Analogia da atualização do código de construção: imagine uma cidade que atualiza seu código de construção para exigir fundações mais robustas para novos edifícios. Todos os edifícios existentes continuam legais – foram construídos sob o código antigo. Mas qualquer novo edifício deve atender ao padrão mais rigoroso. Um soft fork funciona da mesma maneira: ele torna as regras mais rígidas daqui para frente, mantendo válido tudo o que foi construído sob as regras antigas.
Analogia da redução do limite de velocidade: Imagine uma rodovia onde o limite de velocidade cai de 70 km/h para 55 km/h. Os carros que já estão na estrada a 55 km/h ou menos estão dentro da lei, tanto pela regra antiga quanto pela nova. Mas alguém dirigindo a 65 km/h estaria infringindo a nova regra, mesmo que estivesse dentro da lei antes. Os nós atualizados aplicam o limite de 55 km/h; os nós não atualizados ainda consideram 70 km/h como permitido, mas só veem tráfego a 55 km/h ou menos.
Analogia com o código de vestimenta em restaurantes: um restaurante que antes não tinha código de vestimenta agora exige "traje esporte fino". Clientes que já usam terno (e atendem ao padrão mais rigoroso) ainda podem entrar. Clientes antigos, que só conhecem a regra de "não ter código de vestimenta", não veem problema algum nas pessoas bem vestidas. Mas qualquer pessoa que aparecer de chinelo será barrada pelo sistema atualizado (nós atualizados), mesmo que os clientes que seguiam a regra antiga não notassem a infração.
A analogia da atualização de software: É como quando o sistema operacional do seu telefone recebe uma atualização que restringe quais aplicativos podem acessar a câmera. Os aplicativos que já respeitam a privacidade da câmera funcionam perfeitamente. Os aplicativos que antes acessavam a câmera sem permissão agora são bloqueados. O telefone ainda executa todos os aplicativos antigos – ele apenas impõe permissões mais rigorosas daqui para frente.
Importante: Embora os soft forks sejam menos disruptivos que os hard forks, eles não estão isentos de riscos. Se os mineradores estiverem divididos entre softwares atualizados e não atualizados, podem ocorrer divisões temporárias na blockchain. Além disso, os truques de retrocompatibilidade usados em soft forks (como fazer com que novos tipos de transação pareçam "qualquer um pode gastar" para os nós antigos) podem criar problemas de segurança temporários para usuários que não atualizaram seus softwares. É sempre recomendável atualizar o software do seu nó para a versão mais recente após a ativação de um soft fork.
Principais recursos técnicos
Mecanismo de retrocompatibilidade
As novas regras são um subconjunto estrito das regras antigas: qualquer bloco válido sob as novas regras também é válido sob as regras antigas.
Nós não atualizados aceitam blocos de mineradores atualizados sem reconhecer a nova regra em vigor.
Os nós atualizados rejeitam blocos que violam as novas regras, mesmo que esses blocos fossem válidos sob as regras antigas.
Essa assimetria significa que apenas a maioria (e não a unanimidade) do poder de hash ou da participação é necessária para que o fork seja bem-sucedido.
O padrão "qualquer um pode gastar" permite codificar novas semânticas em transações que os nós antigos tratam como trivialmente válidas.
Mecanismos de Ativação
BIP 9 (Bits de Versão): Os mineradores sinalizam prontidão definindo bits específicos nos campos de versão do bloco; a ativação ocorre quando um limite (normalmente 95%) é atingido dentro de um período de sinalização.
BIP 8 (BIP 9 modificado com ativação forçada): Semelhante ao BIP 9, mas inclui uma opção de "bloqueio por tempo limite", onde o soft fork é ativado independentemente da sinalização do minerador após uma data especificada – projetado para impedir que os mineradores bloqueiem indefinidamente as atualizações.
Teste Rápido: Uma variante do BIP 8 usada para o Taproot, que dá aos mineradores um curto período (aproximadamente três meses) para sinalizar apoio com um limite de 90%, caso contrário a comunidade consideraria caminhos de ativação alternativos.
Soft Fork Ativado pelo Usuário (UASF): Operadores de nós e participantes econômicos impõem novas regras independentemente da sinalização do minerador, usando incentivos econômicos para forçar a conformidade do minerador – ameaça notória durante o período de ativação do SegWit (BIP 148).
Dia da Bandeira: Uma data/altura do bloco predeterminada em que novas regras entram em vigor, independentemente da sinalização – o mecanismo mais simples, mas que requer amplo consenso social.
Como funciona um garfo macio
Os desenvolvedores propõem uma alteração no protocolo e redigem uma Proposta de Melhoria do Bitcoin (BIP) especificando as novas regras de consenso.
A proposta passa por uma extensa revisão por pares, testes na testnet/signet e debate com a comunidade ao longo de meses ou anos.
O código que implementa as novas regras é integrado ao cliente de referência (Bitcoin Core) por meio de um mecanismo de ativação.
Os operadores de nós e mineradores atualizam seus softwares para incluir o novo código.
Os mineradores começam a sinalizar sua prontidão para ativação definindo bits específicos nos cabeçalhos dos blocos.
Quando o limiar de sinalização é atingido dentro de um período definido, o soft fork "trava" e ativa-se após um período de tolerância.
Após a ativação, os mineradores atualizados produzem blocos que atendem às novas regras mais rigorosas.
Os nós não atualizados aceitam esses blocos como válidos (compatibilidade com versões anteriores), mas os blocos que violam as novas regras são descartados pela maioria atualizada.
Incentivos econômicos encorajam os mineradores que ainda não atualizaram seus sistemas a fazê-lo, já que seus blocos não conformes seriam rejeitados pela cadeia majoritária.
SegWit: Anatomia de um garfo macio de referência
Dados de testemunha (assinatura) separados do identificador da transação, corrigindo o antigo bug de maleabilidade da transação.
Introduziu-se uma nova estrutura de dados "testemunha" anexada aos blocos, mas invisível para os nós antigos (que veem um bloco "removido" dentro do limite de 1 MB).
Aumento da capacidade efetiva de bloco de aproximadamente 1 MB para cerca de 2 a 4 MB, dependendo da combinação de transações (medida em "unidades de peso" – 4 milhões de unidades de peso por bloco).
Habilitou protocolos de segunda camada, como a Lightning Network, tornando os IDs de transação imutáveis.
Utilizou-se um sistema de "versão testemunha" que permite que futuras atualizações de soft fork adicionem novas versões de script (o Taproot usou a versão testemunha 1).
Taproot: Atualização para Privacidade e Eficiência
Substituímos as assinaturas ECDSA pelas assinaturas Schnorr (BIP 340), permitindo a agregação de assinaturas e a validação em lote.
Introduziu o MAST (Merkelized Alternative Script Trees) através do BIP 341, permitindo que condições de gastos complexas permaneçam ocultas, a menos que sejam invocadas.
Tornamos as transações com múltiplas assinaturas e contratos inteligentes indistinguíveis das transações simples com assinatura única na blockchain.
Redução do tamanho das transações e das taxas para scripts complexos, ao mesmo tempo que se expande a programabilidade do Bitcoin.
Bloqueado no bloco 687,284 (12 de junho de 2021) e ativado usando o mecanismo de Julgamento Rápido no bloco 709,632 (14 de novembro de 2021)
Junte-se à UEEx
Experimente a plataforma líder mundial em gestão de patrimônio digital
Sem divisão da cadeia – o blockchain permanece uma única cadeia contínua porque os nós não atualizados ainda aceitam novos blocos como válidos.
A exigência de retrocompatibilidade limita significativamente as alterações que podem ser introduzidas; atualizações verdadeiramente transformadoras podem exigir hard forks.
Flexibilidade de atualização
Os participantes podem atualizar no seu próprio ritmo; não há um prazo final ("dia da bandeira") em que os nós não atualizados sejam desconectados à força.
Nós não atualizados podem ter uma falsa sensação de segurança, validando blocos que não compreendem completamente (por exemplo, tratando as saídas do SegWit como "qualquer um pode gastar").
Coesão Comunitária
Os soft forks geralmente são menos controversos politicamente do que os hard forks, porque não impõem aos participantes uma decisão de atualização do tipo "tudo ou nada".
A percepção de menor urgência pode levar a uma adoção lenta – foram necessários aproximadamente cinco anos após a ativação do SegWit para que a adoção atingisse um patamar entre 80% e 90%.
Modelo de Segurança
A ativação requer apenas o poder de hash da maioria (não unanimidade), tornando-a viável mesmo com alguns participantes em oposição.
Caso o limite de poder de hash da maioria não seja atingido, uma divisão temporária da cadeia pode ocorrer, resultando em históricos de transações potencialmente diferentes nas cadeias atualizadas e não atualizadas.
Elegância Técnica
Truques inteligentes de codificação (versionamento de testemunhas, reaproveitamento de opcodes NOP) permitem novas funcionalidades substanciais dentro das estruturas de regras existentes.
Esses truques de codificação adicionam complexidade técnica e podem criar "dívida técnica" – camadas de gambiarras de retrocompatibilidade que tornam o código-fonte mais difícil de entender ao longo do tempo.
Experiência do desenvolvedor
Mecanismos de ativação bem estabelecidos (BIP 9, BIP 8, Teste Rápido) fornecem processos estruturados e testados para coordenar atualizações em toda a rede.
O próprio projeto do mecanismo de ativação é uma fonte de controvérsia – o debate sobre a ativação do SegWit durou mais de dois anos, em parte devido a divergências sobre o uso de mecanismos sinalizados pelo minerador ou ativados pelo usuário.
Sinal de Governança
A sinalização dos mineradores fornece um indicador mensurável da prontidão do ecossistema, permitindo decisões de ativação baseadas em dados.
A sinalização por parte dos mineradores pode ser manipulada ou retida estrategicamente – os mineradores podem bloquear atualizações que reduzam sua receita com taxas ou alterem a economia da mineração, mesmo quando a comunidade em geral apoia a mudança.
Reversibilidade
Em princípio, um soft fork pode ser "desfeito" por um soft fork subsequente que afrouxe novamente as regras (embora isso seja extremamente raro e complexo na prática).
A irreversibilidade prática das bifurcações de software (soft forks) implementadas significa que atualizações mal projetadas podem sobrecarregar permanentemente o protocolo com decisões de projeto subótimas.
Gestão de Risco
Risco de divisão de cadeia e bloco órfão
Se uma bifurcação suave (soft fork) for ativada sem suporte suficiente de poder de hash (por exemplo, apenas 60% dos mineradores atualizarem), a rede poderá temporariamente gerar duas cadeias concorrentes – uma seguindo as novas regras e outra seguindo as antigas. Os blocos da cadeia minoritária ficariam órfãos assim que a cadeia majoritária alcançasse as novas regras, o que poderia causar reversões de transações. Mitigação: Utilize limites de ativação elevados (sinalização de 90-95%), implemente implantações graduais com períodos de sinalização estendidos e assegure um amplo consenso do ecossistema antes da ativação. Os usuários devem aguardar confirmações adicionais durante os períodos de ativação.
Vulnerabilidade de nó não atualizado
Nós que não atualizarem após a ativação de um soft fork podem validar transações incorretamente. Por exemplo, um nó não atualizado pode aceitar uma transação que gaste uma saída SegWit sem verificar os dados da testemunha, tratando-a como uma saída que "qualquer um pode gastar". Embora isso não coloque a rede em risco como um todo (mineradores atualizados aplicam as regras reais), usuários individuais não atualizados podem ser enganados por transações que a rede atualizada rejeitaria. Mitigação: Atualize o software do nó imediatamente após a ativação do soft fork, monitore os canais oficiais para anúncios de atualização e use SPV (verificação simplificada de pagamento) com nós atualizados.
Disputas sobre o Mecanismo de Ativação
A escolha do mecanismo de ativação pode se tornar uma fonte de conflito na comunidade. A ativação sinalizada por mineradores (BIP 9) pode ser bloqueada por uma minoria de mineradores, enquanto os mecanismos ativados pelo usuário (UASF/BIP 148) acarretam o risco de divisões da blockchain caso o consenso econômico seja mal avaliado. A controvérsia da ativação do SegWit demonstrou que as disputas sobre o mecanismo de ativação podem dominar o debate por anos. Mitigação: Construir um amplo consenso social antes de propor a ativação, envolver todos os grupos de partes interessadas (mineradores, operadores de nós, exchanges, desenvolvedores de carteiras) desde o início e usar janelas de ativação com tempo limitado (modelo de Teste Rápido) para evitar atrasos indefinidos.
Complexidade técnica e erros de implementação
As restrições de retrocompatibilidade dos soft forks exigem técnicas de codificação complexas que podem introduzir bugs sutis. A interação entre as novas regras do soft fork e a lógica de consenso existente deve ser exaustivamente testada. Um bug na implementação do soft fork pode causar falhas de consenso, divisões da cadeia ou vulnerabilidades de segurança. Mitigação: Ampla revisão por pares (as propostas de soft fork do Bitcoin Core normalmente passam por 12 a 24 meses de revisão), conjuntos de testes detalhados, incluindo fuzzing, implantação na testnet e na signet antes da mainnet e ativação gradual com períodos de monitoramento.
Impacto Econômico e de Mercado
A ativação de soft forks pode gerar incerteza no mercado, principalmente quando há discordância na comunidade sobre a atualização. O debate sobre o SegWit em 2017 coincidiu com uma volatilidade significativa no preço do Bitcoin e, por fim, levou ao hard fork do Bitcoin Cash (pela facção oposta). Mesmo soft forks bem-sucedidos podem causar perturbações de curto prazo no mercado, enquanto os participantes avaliam as implicações. Mitigação: Comunicação clara sobre o propósito e o cronograma da atualização, coordenação entre exchanges e provedores de carteiras para transições tranquilas e evitar negociações baseadas unicamente em especulação relacionada ao fork.
Relevância cultural
Os soft forks ocupam um lugar especial na cultura e na filosofia de governança do Bitcoin. Eles representam a abordagem conservadora da rede em relação à evolução do protocolo – a ideia de que as mudanças devem ser minimamente disruptivas, retrocompatíveis e alcançáveis por meio de amplo consenso, em vez de decretos de cima para baixo. Essa filosofia reflete os valores fundamentais do Bitcoin de descentralização e soberania individual: nenhuma entidade deve ser capaz de forçar os participantes a atualizar, e a rede deve continuar funcionando para aqueles que optarem por não fazê-lo.
A saga da ativação do SegWit (2015-2017) foi um momento decisivo na história cultural do Bitcoin. Ela colocou em lados opostos os "pequenos bloqueadores", que favoreciam o soft fork SegWit, e os "grandes bloqueadores", que queriam um hard fork para aumentar o tamanho do bloco. O debate não foi meramente técnico – foi uma guerra por procuração sobre a identidade, a governança e o futuro do Bitcoin. A eventual ativação do SegWit, por meio de uma combinação de pressão da comunidade e do movimento UASF, estabeleceu o precedente de que os usuários e operadores de nós do Bitcoin, e não apenas os mineradores, têm influência significativa sobre as regras do protocolo. A narrativa de que "os operadores de nós são o verdadeiro poder" permanece um pilar da cultura de governança do Bitcoin.
O movimento UASF, simbolizado pela campanha BIP 148 e seus memes associados, demonstrou que a ativação de soft forks é tanto um problema de coordenação social quanto um problema técnico. O movimento está associado à frase "No2x" (opondo-se ao hard fork SegWit2x) e demonstrou que uma comunidade motivada de operadores de nós poderia pressionar os mineradores a ativar uma atualização, ameaçando invalidar os blocos que não sinalizassem a alteração.
A ativação relativamente tranquila do Taproot em 2021, utilizando o mecanismo Speedy Trial, foi vista por muitos na comunidade como um amadurecimento do processo de governança do Bitcoin. As lições das guerras do SegWit contribuíram para uma abordagem mais simplificada, embora os debates sobre futuras propostas de soft forks (OP_CTV, OP_CAT, OP_VAULT) continuem a testar a capacidade da comunidade de chegar a um consenso sobre mudanças no protocolo. O peso cultural dos soft forks no Bitcoin vai além de sua função técnica – eles são um mecanismo fundamental pelo qual a comunidade lida com a tensão entre inovação e estabilidade.
Junte-se à UEEx
Experimente a plataforma líder mundial em gestão de patrimônio digital
Exemplo 1: Ativação de Segregated Witness (SegWit) – Bitcoin
Cenário: O Bitcoin enfrentava um bug de maleabilidade de transações que impedia a construção confiável de canais de pagamento (necessários para a Lightning Network) e um crescente acúmulo de transações não confirmadas, já que os blocos atingiam consistentemente o limite de 1 MB. Um aumento de capacidade era urgentemente necessário sem a necessidade de dividir a rede.
Implementação: O SegWit (BIP 141) foi projetado como um soft fork que separou os dados de testemunha dos IDs de transação, corrigindo a maleabilidade e aumentando a capacidade efetiva do bloco por meio de uma nova métrica de "peso do bloco". Após um longo debate e a ameaça de um Soft Fork Ativado pelo Usuário (UASF via BIP 148), os mineradores atingiram o limite de sinalização de 95% em 8 de agosto de 2017, e o SegWit foi implementado. A ativação ocorreu no bloco 481,824 em 24 de agosto de 2017.
Resultado: O SegWit foi ativado com sucesso sem uma divisão da cadeia na rede Bitcoin (embora os oponentes tenham criado posteriormente o Bitcoin Cash por meio de um hard fork). A maleabilidade das transações foi corrigida, permitindo que a Lightning Network evoluísse de experimental para uma rede com um volume significativo de pagamentos. Em 2026, aproximadamente 85-90% das transações de Bitcoin utilizavam pelo menos uma entrada SegWit. A atualização demonstrou que soft forks controversos podiam ser resolvidos por meio de uma combinação de mérito técnico, pressão econômica e coordenação da comunidade.
Exemplo 2: Ativação do Taproot – Bitcoin
Cenário: As capacidades de programação do Bitcoin eram limitadas, transações complexas com múltiplas assinaturas e contratos inteligentes eram caras e comprometiam a privacidade (expondo todo o script na blockchain), e as assinaturas ECDSA não podiam ser agregadas de forma eficiente. Era necessária uma atualização para melhorar a privacidade, a eficiência e a programabilidade.
Implementação: O Taproot (BIPs 340, 341, 342) combinou assinaturas Schnorr, MAST e uma nova versão de script (witness v1) em um único soft fork. Usando o mecanismo de ativação Speedy Trial (uma janela de sinalização com tempo limitado), os mineradores atingiram o limite de sinalização de 90%, garantindo a atualização em 12 de junho de 2021, no bloco 687,284. O Taproot foi então ativado no bloco 709,632 em 14 de novembro de 2021, após um período de tolerância de aproximadamente cinco meses para a preparação do ecossistema.
Resultado: A ativação do Taproot foi notavelmente tranquila em comparação com o SegWit, sem interrupções significativas na rede. Ele possibilitou esquemas de múltiplas assinaturas baseados em Schnorr que são idênticos a transações de assinatura única na blockchain, melhorando a privacidade. O MAST permitiu que condições de gastos complexas permanecessem ocultas, a menos que fossem invocadas, reduzindo o tamanho das transações. A adoção do Taproot tem sido irregular – atingiu um pico acima de 40% das transações no início de 2024 devido à atividade com Ordinals e Runes, antes de se estabilizar em torno de 15-20% à medida que essa atividade especulativa diminuiu.
Exemplo 3: P2SH (Pay-to-Script-Hash) – Bitcoin
Cenário: Nos primeiros anos do Bitcoin, o envio de transações para scripts complexos (carteiras com múltiplas assinaturas, contratos com bloqueio temporal) exigia que o remetente incluísse o script completo na transação, o que era trabalhoso, caro e expunha publicamente as condições de gasto antes que os fundos fossem utilizados.
Implementação: A BIP 16 (proposta por Gavin Andresen em janeiro de 2012) introduziu o P2SH como um soft fork que permitia aos remetentes pagar ao hash de um script em vez do próprio script. O script completo só seria revelado quando os fundos fossem gastos. Os nós antigos reconheciam as saídas do P2SH como um tipo de transação padrão, mantendo a compatibilidade com versões anteriores. O soft fork foi ativado em 1º de abril de 2012.
Resultado: O P2SH simplificou drasticamente o uso de carteiras com múltiplas assinaturas e scripts complexos, tornando-se a base do ecossistema multi-assinatura do Bitcoin. Ele estabeleceu o padrão de codificação de novas funcionalidades em formatos de transação retrocompatíveis – um modelo que o SegWit e o Taproot seguiriam posteriormente. Os endereços P2SH (começando com “3”) tornaram-se onipresentes e continuam sendo amplamente utilizados até hoje. A atualização é considerada uma das bifurcações suaves mais limpas e bem-sucedidas da história do Bitcoin.
Exemplo 4: Fusão do Ethereum (Contexto para discussão sobre Soft Fork vs. Hard Fork)
Cenário: Embora a transição do Ethereum de prova de trabalho para prova de participação (The Merge, setembro de 2022) tenha sido tecnicamente um hard fork, o processo destacou a relação de troca entre soft fork e hard fork em um ecossistema blockchain diferente, onde os hard forks são o mecanismo de atualização padrão.
Implementação: A cultura de desenvolvimento do Ethereum historicamente favoreceu hard forks para atualizações de protocolo, com hard forks programados regularmente (Istambul, Berlim, Londres, etc.) aproximadamente a cada 6 a 12 meses. A própria fusão (Merge) exigiu que todos os nós fossem atualizados – um hard fork por definição. Isso contrasta com a preferência do Bitcoin por soft forks, refletindo filosofias de governança diferentes: o Ethereum prioriza a inovação rápida e aceita os custos de coordenação dos hard forks, enquanto o Bitcoin prioriza a estabilidade e a retrocompatibilidade por meio de soft forks.
Resultado: A execução bem-sucedida de hard forks regulares pelo Ethereum demonstra que essa abordagem pode funcionar quando há um forte consenso social e uma estrutura de liderança clara entre os desenvolvedores principais. No entanto, ela também produziu divisões da cadeia (Ethereum Classic em 2016) quando o consenso se rompe. O contraste entre a cultura de soft forks do Bitcoin e a normalização de hard forks do Ethereum ilustra como diferentes comunidades blockchain resolvem a tensão fundamental entre a velocidade da inovação e a estabilidade da rede.
Tabela de comparação
Característica
Soft Fork
Hard Fork
Garfo Contencioso (Divisão da Corrente)
Compatibilidade com versões anteriores
Sim – nós não atualizados aceitam novos blocos como válidos.
Não – os nós não atualizados rejeitam novos blocos, criando uma divisão.
Não – a rede se divide intencionalmente em duas cadeias incompatíveis.
Requisito de atualização
Opcional (mas recomendado) – os nós podem continuar operando sem atualização.
Obrigatório – todos os nós devem ser atualizados ou permanecerão em uma cadeia incompatível.
Os participantes devem escolher qual cadeia seguir; nenhuma melhoria é "neutra".
Continuidade da cadeia
Cadeia única contínua (assumindo que a maioria do poder de hash seja adotada)
Uma única cadeia de votação se adotada por unanimidade; duas cadeias se houver discordância.
Duas cadeias permanentes por definição (ex: Bitcoin vs. Bitcoin Cash)
Direção da mudança de regra
Só é possível restringir as regras (reduzindo o conjunto válido) ou adicionar novos tipos de transação por meio de truques de retrocompatibilidade.
Pode-se apertar ou afrouxar regras, alterar a estrutura dos blocos e modificar parâmetros fundamentais.
Representa uma discordância fundamental sobre quais regras a cadeia deve seguir.
Limite de ativação
Poder de hash majoritário (mínimo de ~51%; normalmente entre 90% e 95% por segurança)
Requer amplo consenso social; nenhum limiar formal de sinalização pode garantir o sucesso.
Sem limite mínimo – qualquer grupo pode bifurcar a cadeia a qualquer momento.
Geralmente causa menos transtornos; ainda pode ser polêmico (o debate sobre o SegWit durou mais de 2 anos).
Custo de coordenação mais elevado; pode causar divisões permanentes na comunidade se faltar consenso.
Extremamente divisivo; cria comunidades, marcas e ecossistemas econômicos concorrentes.
Termos relacionados
Hard ForkUma atualização de protocolo não compatível com versões anteriores que exige que todos os nós sejam atualizados, podendo dividir a cadeia – o equivalente a um soft fork.
SegWit (Segregated Witness): o importante soft fork do Bitcoin em 2017, que separou os dados de testemunha das transações para corrigir a maleabilidade e aumentar a capacidade do bloco.
Taproot: Uma bifurcação (soft fork) do Bitcoin de 2021 que introduziu as assinaturas Schnorr e o MAST para melhorar a privacidade, a eficiência e os recursos de contratos inteligentes.
BIP (Bitcoin Improvement Proposal): O processo formal pelo qual as propostas de soft fork são documentadas, revisadas e padronizadas para a rede Bitcoin.
Regras de ConsensoO conjunto de regras de validação que todos os participantes da rede devem concordar – os soft forks modificam essas regras de forma retrocompatível.
UASF (User Activated Soft Fork): Um mecanismo de ativação onde os operadores de nós impõem novas regras independentemente da sinalização do minerador, enfatizando a soberania do usuário sobre o controle do minerador.
Sinalização do minerador: O processo pelo qual os mineradores indicam estarem prontos para um soft fork, definindo bits específicos nos cabeçalhos dos blocos, usado na ativação do BIP 9 e do Speedy Trial.
Rede Lightning: Uma Camada 2 Rede de canais de pagamento que foi viabilizada pela correção do SegWit à maleabilidade das transações, demonstrando como os soft forks podem desbloquear a inovação do ecossistema.
Maleabilidade de transações: um bug no projeto original do Bitcoin que permitia a alteração dos IDs das transações sem invalidá-las – corrigido pelo soft fork SegWit.
Assinaturas Schnorr: Um esquema de assinatura digital introduzido no soft fork do Taproot que permite a agregação de assinaturas e a validação em lote para maior eficiência e privacidade.
Peso do bloco: Uma métrica introduzida pelo SegWit que substituiu o limite de tamanho de bloco simples, medindo os blocos em "unidades de peso" para incentivar a adoção do novo formato de transação.
Árvore MerkleUma estrutura de dados criptográfica usada em blocos de blockchain, na qual o MAST (Merkelized Alternative Script Trees) da Taproot se baseia para uma verificação eficiente de scripts.
Perguntas frequentes
Qual a diferença entre um soft fork e um hard fork? Um soft fork torna as regras de consenso mais rígidas, reduzindo o conjunto de blocos válidos – nós que não atualizaram ainda aceitam novos blocos porque estes estão em conformidade com as regras antigas, mais flexíveis. Um hard fork, por sua vez, flexibiliza ou altera as regras, de modo que novos blocos sejam rejeitados por nós antigos – exigindo que todos atualizem. Em resumo, soft forks são retrocompatíveis (o software antigo funciona), enquanto hard forks não são (o software antigo deixa de funcionar). O Bitcoin prefere soft forks para garantir estabilidade; o Ethereum utiliza hard forks regularmente para acelerar a inovação.
Uma bifurcação suave (soft fork) pode causar a divisão de uma blockchain em duas cadeias? Em teoria, uma bifurcação suave não deveria causar uma divisão permanente da cadeia, pois os nós não atualizados ainda aceitam os novos blocos. No entanto, uma divisão temporária pode ocorrer se uma minoria significativa de mineradores continuar produzindo blocos sob as regras antigas, que violam as novas regras. A maioria atualizada irá descartar esses blocos, e a cadeia convergirá para as novas regras. Uma divisão permanente só ocorreria se a comunidade discordasse fundamentalmente e a minoria se separasse intencionalmente – mas isso seria tecnicamente uma bifurcação rígida (hard fork) pela minoria, e não uma consequência da própria bifurcação suave.
Por que o Bitcoin prefere soft forks a hard forks? A cultura de desenvolvimento do Bitcoin prioriza a estabilidade, a retrocompatibilidade e a minimização da carga de coordenação sobre os participantes da rede. Soft forks permitem que a rede seja atualizada sem exigir que todos os nós atualizem simultaneamente, reduzindo o risco de divisões da cadeia. Essa abordagem conservadora reflete o princípio do Bitcoin como uma rede descentralizada e sem líder, onde nenhuma entidade individual pode impor atualizações. Hard forks, que exigem participação universal, são vistos por muitos na comunidade Bitcoin como mais disruptivos e propensos a divisões controversas (como demonstrado pelo Bitcoin Cash em 2017).
O que foi o SegWit e por que foi importante? O Segregated Witness (SegWit), ativado em agosto de 2017, foi um soft fork que separou os dados de assinatura (testemunha) da transação do ID da transação. Isso corrigiu a vulnerabilidade de maleabilidade da transação (que permitia que terceiros alterassem os IDs das transações), possibilitando soluções de segunda camada como a Lightning Network. Também aumentou a capacidade efetiva dos blocos ao introduzir uma métrica de "peso do bloco". O SegWit foi, sem dúvida, a atualização mais impactante e controversa da história do Bitcoin até então, com o debate sobre sua implementação durando mais de dois anos.
Como o Taproot aprimora o Bitcoin? O Taproot (ativado em novembro de 2021) introduziu três melhorias principais por meio de um soft fork: (1) Assinaturas Schnorr, que são mais eficientes que o ECDSA e permitem a agregação de assinaturas; (2) MAST (Merkelized Alternative Script Trees), que permite que condições complexas de contratos inteligentes permaneçam ocultas, a menos que sejam usadas, melhorando a privacidade e reduzindo as taxas; (3) um novo sistema de versões de scripts que faz com que transações complexas e com múltiplas assinaturas pareçam idênticas a pagamentos simples na blockchain. Juntas, essas mudanças tornam o Bitcoin mais privado, mais eficiente e mais programável.
O que significa, na prática, "compatibilidade com versões anteriores" no contexto de um soft fork? Compatibilidade com versões anteriores significa que os nós que executam o software antigo (anterior ao soft fork) ainda podem participar da rede e validar novos blocos. Eles não precisam atualizar para permanecer conectados. Isso é possível porque as novas regras são mais rigorosas do que as antigas – qualquer bloco válido sob as novas regras é automaticamente válido sob as regras antigas. No entanto, os nós não atualizados podem não compreender a semântica completa dos novos tipos de transação; eles podem tratá-los como trivialmente válidos em vez de realizar a validação completa. É por isso que a atualização ainda é recomendada, mesmo que não seja obrigatória.
O que é um Soft Fork Ativado pelo Usuário (UASF)? Um UASF é um método de ativação de soft fork no qual os operadores de nós (e não os mineradores) impõem as novas regras. Em vez de esperar que os mineradores sinalizem prontidão, os operadores de nós definem uma altura de bloco ou data específica após a qual rejeitarão os blocos que não estiverem em conformidade com as novas regras. Isso exerce pressão econômica sobre os mineradores para que cumpram as regras, já que os blocos rejeitados pelos operadores de nós não podem transportar transações válidas nem gerar taxas. A ameaça UASF mais famosa foi a BIP 148 durante a ativação do SegWit, amplamente considerada como um catalisador para a sinalização dos mineradores. Os UASFs representam o princípio de que, em sistemas de prova de trabalho, os nós econômicos – e não apenas os mineradores – exercem influência significativa sobre as regras de consenso.
Fontes
Documentação do Bitcoin Core: “Ativação de Soft Fork”
Repositório de Propostas de Melhoria do Bitcoin (BIPs)
