Ir para o conteúdo
Financial Context Wiki

Hard fork vs. soft fork: compatibilidade, ativação e divisão da rede

Hard fork e soft fork descrevem relações diferentes de compatibilidade entre regras de consenso antigas e novas. Analise separadamente conjuntos de blocos válidos, ativação, validação dos nós, produtores, preparo operacional, risco de replay e qualquer divisão da rede.

Atualizado

Análise educacional de protocolo; não constitui recomendação de investimento. Um fork proposto ou ativado pode afetar validação, depósitos, saques, custódia, contratos, preços, liquidez, tributação e segurança operacional, sem garantir um segundo ativo duradouro.

Resposta direta

Hard fork e soft fork classificam uma mudança nas regras de consenso conforme nós atualizados e desatualizados julgam os blocos. Seja V_old o conjunto aceito pelas regras antigas e V_new o aceito pelas novas. Um soft fork restringe a validade para que V_new subset V_old: todo bloco válido sob as novas regras também é válido sob as antigas, embora um nó antigo não aplique a restrição adicional. Um hard fork permite ao menos um bloco válido novo que o nó antigo rejeita: exists b: b in V_new and b not in V_old. Os conjuntos de um hard fork podem ser uma expansão ou incomparáveis; “hard” não significa apenas bloco maior ou recurso mais radical.

A compatibilidade é assimétrica. Num soft fork bem-sucedido, nós desatualizados podem ficar na mesma cadeia porque aceitam blocos de mineradores ou validadores atualizados, mas podem aceitar algo rejeitado pelos novos nós e oferecer garantia inferior. Num hard fork, quando um produtor atualizado cria um bloco fora do conjunto válido antigo, os nós antigos não conseguem acompanhá-lo. Se participantes economicamente relevantes mantiverem os dois conjuntos, duas redes duradouras podem surgir; sem apoio efetivo a um lado, não precisam existir dois ativos persistentes.

Os rótulos descrevem regras, não legitimidade de governança, segurança, apoio econômico nem método de ativação. Uma proposta pode ser chamada hard fork antes de ativar; uma mudança ativada pode não causar divisão duradoura; e uma incompatibilidade acidental pode dividir a rede sem votação. Sinais de mineradores ou validadores coordenam preparo, mas não tornam válido para um nó completo um bloco rejeitado por suas regras.

Não confunda fork de consenso com bifurcação temporária sob as mesmas regras, reorganização, fork de repositório ou atualização de aplicativo. A questão operacional é qual rede, conjunto de regras, condição de ativação e histórico cada nó, carteira, corretora, custodiante, oráculo e contrato reconhecerá.

Como analisar um fork de protocolo

  1. Fixe identidade e escopo. Registre chain, network, client version, proposta de ativação, gênese ou checkpoint finalizado, hash atual e camada afetada. O mesmo nome em testnet, mainnet, execução, consenso ou aplicação pode significar regras distintas.
  2. Compare a validade de consenso. Liste cada regra alterada de bloco, transação, assinatura, transição de estado, gas, timestamp, finalidade ou escolha de fork. Classifique objetos como valid, invalid ou unknown nas duas versões; não deduza compatibilidade apenas das notas de versão.
  3. Demonstre a relação entre conjuntos. Verifique se todo objeto válido novo continua válido sob as regras antigas. Se sim, a mudança pode ser compatível como soft fork; se um bloco válido novo for inválido para as regras antigas, esses nós exigem transição por hard fork. Teste também objetos antigos que se tornam inválidos.
  4. Reproduza a ativação. Confirme altura, época, tempo mediano, limiar de sinalização, atraso de lock-in, dificuldade total ou gatilho de governança na especificação e no código implantados. Sinalização, lock-in, ativação e aplicação são estados distintos.
  5. Mapeie os participantes. Meça o peso de produção atualizado e identifique nós completos, relays, carteiras, corretoras, custodiantes, pontes, emissores de stablecoins, oráculos e contratos de cada lado. Hashrate ou stake isolados não determinam aceitação econômica.
  6. Rastreie divisão e transações. Siga hashes pais e validade nos dois conjuntos. Verifique políticas de confirmação, divergência do mempool, proteção contra replay, formatos de endereço, identificadores de cadeia, domínios de assinatura, caminhos de saque e execução nas duas ramificações.
  7. Defina controles operacionais. Pause ou prolongue liquidação quando a ancestralidade for ambígua; atualize e faça backup deliberadamente; reconcilie saldos e passivos por ramo; teste assinatura e recuperação offline; retome só após critérios explícitos de cadeia, nó, contraparte e finalidade.

O método separa quatro eventos geralmente condensados em “fork”: proposta de regra, condição de ativação, divergência observada e sobrevivência econômica posterior de uma ou mais ramificações. Nenhum comprova automaticamente o seguinte.

Exemplos resolvidos

1. Compatibilidade dos conjuntos válidos

Suponha que as regras antigas aceitem 100 formas de bloco e as novas somente 80. Se essas 80 estiverem totalmente no conjunto antigo, há relação de soft fork; as 20 formas antigas restantes são rejeitadas por nós atualizados. Os números ilustram conjuntos, não probabilidades ou limiares de votação.

Agora suponha que as regras novas aceitem uma forma que todo nó antigo rejeita. Mesmo que a maioria dos demais blocos seja válida nas duas regras, esse contraexemplo rompe a aceitação retrocompatível e torna a transição incompatível como hard fork. A permanência da divisão depende de produtores, usuários e infraestrutura depois desse bloco.

2. A ativação da BIP 34 não é a definição

A BIP 34 exigiu a altura na transação coinbase e usou um mecanismo móvel de prontidão. Com 750 of 1,000 blocos anteriores em versão 2 ou superior, nós rejeitavam blocos inválidos de versão 2; após 950 of 1,000, rejeitavam versão 1. A BIP registra o bloco 227,835 como o último de versão 1.

Esses limiares coordenaram a implantação; não definiram a mudança como soft fork. A compatibilidade veio da restrição dos nós atualizados enquanto clientes antigos ainda aceitavam blocos conformes. Depois, a BIP 9 definiu estados de implantação e bits de versão separados, mostrando que relação entre regras e mecanismo de ativação são questões distintas.

3. Segregated Witness como soft fork

A BIP 141 introduziu dados witness e comprometeu sua árvore pela transação coinbase na estrutura de compromisso existente. Nós antigos puderam aceitar blocos conformes sem entender ou validar as novas regras de witness, enquanto nós atualizados as aplicavam.

Isso é aceitação retrocompatível, não verificação equivalente. Um nó antigo pode enxergar saídas regidas pelas novas regras como menos restritas; quem depende das novas propriedades de segurança precisa de validação atualizada. “O software antigo continua funcionando” não conclui a análise de risco.

4. DAO Fork do Ethereum

A EIP-779 documenta o DAO Fork no bloco 1,920,000 da mainnet. Foi uma mudança irregular de estado que transferiu saldos de uma lista L para o contrato WithdrawDAO, mantendo opcodes da EVM, formato de transação e estrutura de bloco.

Nós que aplicaram a transição e nós que a recusaram calcularam estados diferentes após o limite. O caso mostra que hard fork não exige bloco maior nem novo opcode: uma regra pontual de transição pode criar incompatibilidade, e apoio continuado aos dois históricos pode preservar redes separadas.

Riscos e falhas de revisão

Erros de classificação e especificação

  • Chamar toda ponta concorrente temporária de hard fork, embora todos usem as mesmas regras e a escolha normal a resolva.
  • Definir toda flexibilização como hard fork e toda restrição como soft fork sem testar os conjuntos válidos reais.
  • Igualar aceitação retrocompatível a segurança retrocompatível completa; nós antigos não aplicam as novas restrições.
  • Inferir consenso de marca, roadmap, nota de versão ou ramo de repositório, e não do código e parâmetros implantados.
  • Misturar atualizações de mainnet, testnet, execução, consenso, pontes, rollups e aplicações.
  • Supor que proposta, versão do cliente, sinalização, lock-in e ativação sejam o mesmo evento.
  • Tratar sinal de produtores como voto vinculante de usuários, corretoras, custodiantes ou nós completos.

Riscos de divisão e transação

  • Supor que ativação garanta divisão ou que divisão garanta dois ativos líquidos e duradouros.
  • Usar só altura quando ramos podem ter blocos diferentes na mesma altura; confira hashes e ancestralidade.
  • Enviar durante a divisão sem verificar replay, identificadores, domínios de assinatura e construção por ramo.
  • Creditar depósitos num ramo e liquidar passivos ou saques em outro.
  • Depender de um explorador, RPC ou rótulo de custódia quando provedores podem seguir regras diferentes ou atrasar.
  • Ignorar reorganizações, finalidade parada, pares isolados, mineração minoritária, equivocação ou dados indisponíveis.
  • Supor igual respaldo a símbolo, contrato, saldo de stablecoin, preço de oráculo ou crédito de ponte nos dois ramos.

Riscos de governança e operação

  • Descrever compatibilidade como prova de legitimidade, descentralização, segurança ou apoio econômico.
  • Atualizar nós de produção sem binários reproduzíveis, backups, limites de reversão, testes de migração e hashes independentes.
  • Supor downgrade sempre seguro após novos dados de estado, formatos de carteira ou condições de slashing.
  • Mover chaves ou “reivindicar moedas do fork” com software não verificado que pode expor segredos ou repetir assinaturas.
  • Tratar saldo de snapshot como disponível sem conferir maturidade, bloqueios, estado de contrato e política de custódia.
  • Concluir sobre tributos, contabilidade ou valor antes de estabelecer propriedade, controle, liquidez e regras locais.

Equívocos comuns

  • Hard fork sempre cria uma moeda nova. Um segundo ativo exige produção contínua, usuários, infraestrutura e mercado; muitas atualizações convergem para um histórico aceito.
  • Soft fork não tem risco porque nós antigos funcionam. Eles podem seguir a cadeia, mas não aplicam a regra nova e oferecem validação mais fraca.
  • Maioria de hash ou stake muda qualquer regra sozinha. Nós completos rejeitam blocos inválidos para suas regras; peso só atua entre blocos aceitos.
  • Hard significa controverso e soft, unanimidade. Os termos classificam compatibilidade, não consenso social, qualidade da governança ou controvérsia.
  • Todo fork no explorador é atualização de protocolo. Blocos concorrentes sob as mesmas regras e reorganizações ocorrem sem mudança de consenso.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...