SOFT / HARDCOMPARAÇÕES BASEADAS EM FONTES
Soft Fork vs. Hard Fork
Examine mudanças nas regras de validade, compatibilidade de nós não atualizados e riscos de ativação ou divisão da rede.
Soft Fork torna as regras mais restritivas, de modo que blocos válidos sob as novas regras também passem nas verificações antigas. Hard Fork também permite alguns blocos antes rejeitados. A distinção descreve compatibilidade, não o tamanho nem o apoio político à mudança.
02As diferenças que importam
As regras novas excluem alguns blocos antes permitidos. Um bloco que as atende continua compatível com as antigas.
As regras novas admitem pelo menos alguns blocos antes inválidos. Um nó antigo os rejeita mesmo com grande trabalho acumulado.
Pode acompanhar uma cadeia compatível, mas não verifica as novas restrições. Em SegWit, por exemplo, não valida dados witness.
Sem alterar suas regras, não pode validar e aceitar blocos recém-permitidos que antes eram proibidos; pode permanecer em outro ramo ou parar de avançar.
Aplica regras adicionais quando as condições de ativação são atendidas. Sinalização não substitui validação real.
Aplica o novo conjunto de regras conforme sua ativação. Atualizar um nó não muda as regras dos demais participantes.
Discordâncias sobre ativação ou aplicação podem produzir ramos diferentes. Compatibilidade retroativa, sozinha, não garante transição tranquila.
Uma divisão duradoura ocorre se grupos diferentes continuarem mantendo cadeias incompatíveis. O nome da mudança não garante duas redes viáveis.
Um BIP descreve uma proposta, não aprovação automática. BIP9 distingue, por exemplo, sinalização, fixação da ativação e regras ativas.
Publicar um BIP também não ativa nada aqui. Operadores precisam conhecer as regras específicas de transição e as consequências da incompatibilidade.
Soft Fork não garante ausência de divisão da cadeia, e Hard Fork não cria automaticamente uma nova moeda. O resultado depende da ativação, aplicação e continuidade de históricos incompatíveis por grupos diferentes.
Comparamos mudanças de consenso, não atualizações comuns de interface ou políticas da mempool. BIP9, BIP16 e BIP141 são exemplos específicos; suas condições de ativação não são universais para toda proposta.