Hard Fork
Uma mudança incompatível com o software antigo
-
Greg Walker - Atualizado em
Um hard fork acontece quando é feita uma atualização no software do Bitcoin que é incompatível com versões anteriores do software.
É quando mudanças são feitas nas regras de modo que blocos/transações antes inválidos passem a ser considerados válidos na nova versão do software.
Como resultado, a menos que todos atualizem para o novo software, a blockchain se dividirá em duas direções:
- Uma cadeia formada por blocos que seguem as regras antigas.
- Uma cadeia formada por blocos que seguem as regras novas.
Os nós antigos não conseguem aceitar esses novos blocos, então duas blockchains paralelas vão existir. Isso é conhecido como um "hard fork" na cadeia.
Portanto, se você quer que uma mudança via hard fork no software seja bem-sucedida, precisa que todos os nós da rede concordem com as mudanças e atualizem seu software. É a única forma de todos se manterem na mesma versão da blockchain após a atualização.
Um "hard fork" pode se referir a uma mudança feita no software do Bitcoin ou ao estado da blockchain depois que a mudança foi feita. Neste artigo vou usar os seguintes termos:
- mudança via hard fork – A atualização do software.
- hard fork – O que acontece com a blockchain quando novos blocos incompatíveis são minerados.
Cenário
Como você cria um hard fork?
Para criar um hard fork, você precisa mudar as regras do software para permitir que blocos/transações antes inválidos sejam considerados válidos.
Para dar um exemplo simples, digamos que o limite de tamanho do bloco seja 1 MB (a capacidade do bloco agora é medida em peso, mas não se preocupe com isso por enquanto) e que atualizemos o software para aceitar blocos de até 10 MB.
A mudança via hard fork começa quando os mineradores atualizam para a nova versão. O hard fork de fato na blockchain acontece quando o primeiro bloco de 10 MB é minerado.
- Novos mineradores começam a construir uma cadeia com blocos de 10 MB.
- Mineradores antigos continuam construindo uma cadeia só com blocos de 1 MB e rejeitam os novos blocos de 10 MB.
Esse hard fork persistirá enquanto a nova cadeia (contendo blocos incompatíveis de 10 MB) permanecer como a cadeia mais longa da rede.
Se os mineradores antigos forem a maioria e construírem a cadeia mais longa com blocos de 1 MB, os nós atualizados vão aceitar isso como a sua versão da blockchain (porque eles ainda aceitam os blocos antigos), e o hard fork será anulado.
Causas
O que pode causar um hard fork?
Qualquer coisa que quebre as regras de consenso existentes resultará em um hard fork.
Por exemplo:
- Mudanças na estrutura do bloco.
- ex.: Um aumento direto do tamanho máximo do bloco.
- Mudanças na estrutura da transação.
- ex.: Mudar a criptografia usada nas assinaturas de transações existentes.
- Mudanças em outras regras de consenso.
- ex.: Aumentar o fornecimento máximo de bitcoin.
- ex.: Ajustar manualmente o alvo para tornar mais fácil minerar blocos.
Então, embora nem toda atualização do Bitcoin exija um hard fork, qualquer coisa que mude a forma como o Bitcoin opera fundamentalmente só pode ser alcançada via hard fork.
Motivação
Por que você criaria um hard fork?
Uma mudança via hard fork é a única forma de fazer atualizações que quebram o consenso no software do Bitcoin.
Então, se você quer fazer uma atualização no bitcoin, mas a única maneira de realizá-la é quebrar as regras que todos os nós da rede seguem atualmente, então um hard fork é sua única opção.
Você pode fazer mudanças nas regras usando o que se conhece como soft fork. Porém, dependendo da complexidade da atualização, um hard fork normalmente seria a opção mais simples para fazer mudanças no software do Bitcoin.
Problemas
Por que você não iria querer criar um hard fork?
Há dois problemas principais com um hard fork:
1. Todos precisam atualizar.
Quem não atualizar fica para trás. Não receberá os novos blocos incompatíveis e, portanto, ficará no escuro sobre as transações mais recentes da rede.
Em outras palavras, quem rodar o software antigo vai ficar para trás e não saberá de novos pagamentos que possa ter recebido. Essas pessoas não perdem seus bitcoins, mas não conseguem mais participar do sistema normalmente.
Não é uma forma amigável de atualizar uma rede peer-to-peer.
2. Uma discordância dividirá a rede.
O pior cenário seria um "hard fork contencioso". É quando alguns mineradores da rede concordam com a atualização, mas uma parte significativa não.
Isso resultaria na blockchain se ramificando em duas blockchains paralelas, efetivamente dividindo a moeda em duas direções.
Isso causaria confusão entre usuários e comerciantes: quem aceita qual ramo da moeda? Como você garante que está transacionando no ramo correto da cadeia?
Essa confusão minaria a confiança geral no sistema e provavelmente causaria um colapso no valor do bitcoin do qual ele poderia não se recuperar. Não é um resultado ideal se o objetivo é criar uma moeda digital estável.
O incentivo para o consenso é enorme, pois a discordância significa, na prática, conceder a cada moeda antiga existente o direito de ser gasta uma vez em cada lado.
Uma divisão entre mineradores também dividiria o poder de mineração entre as duas cadeias. Cada cadeia ficaria, portanto, menos segura, com menos poder para se proteger de um ataque de 51%.
Os mineradores antigos poderiam anular a atualização continuando a construir a cadeia disponível mais longa de blocos antigos. A menos, claro, que a atualização também tornasse os blocos antigos inválidos a partir dela por algum motivo, caso em que haveria uma divisão permanente da cadeia.
Benefícios
Quando você iria querer criar uma mudança via hard fork no Bitcoin?
Devido ao risco de dividir a blockchain em duas, uma mudança via hard fork é evitada para fazer melhorias gerais no software do Bitcoin.
Por exemplo, há alguns bugs menores que poderiam ser facilmente corrigidos com um hard fork:
- Corrigir o opcode
OP_CHECKMULTISIGdo Script. Esse opcode retira um item a mais da pilha do que deveria (veja P2MS). - Aumentar o tamanho do campo nonce no cabeçalho do bloco. O campo nonce é pequeno demais, o que significa que os mineradores precisam recorrer à modificação da transação coinbase (veja ExtraNonce) para continuar minerando o bloco depois que todos os números possíveis do campo nonce se esgotam.
- Consistência com a ordem dos bytes. O hash do bloco é exibido em ordem de bytes invertida ao buscar um bloco em um explorador, mas os hashes de bloco usados dentro dos dados brutos do bloco estão em ordem de bytes natural. Seria mais fácil para os desenvolvedores se todos os hashes de bloco estivessem em ordem de bytes invertida internamente.
Porém, os benefícios menores dessas mudanças não compensariam os riscos de fazer todos atualizarem em uma mudança via hard fork no software.
Como resultado, atualizações via hard fork são reservadas para correções urgentes de eventos potencialmente catastróficos. Isso poderia ser algo como:
- Abandonar a função de hash SHA-256. Seria necessário se fosse encontrada uma fraqueza que minasse o esforço exigido para minerar blocos.
- Aumentar manualmente o valor do alvo (ou seja, reduzir a dificuldade). Seria necessário se houvesse uma perda irrecuperável de poder de mineração na rede, o que resultaria em intervalos de bloco dolorosamente lentos. Sem um hard fork, poderia levar meses até o próximo ajuste do alvo e até que as transações fossem mineradas em tempo hábil novamente.
É por isso que todas as atualizações do Bitcoin até agora foram implementadas como soft forks; um hard fork só deve acontecer no caso de um problema fundamental no funcionamento do sistema.
Exemplos
Houve algum hard fork na história do Bitcoin?
Não houve nenhuma mudança intencional via hard fork proposta pelos desenvolvedores do Bitcoin Core.
Porém, houve duas atualizações de software que causaram (ou poderiam ter causado) um hard fork acidental:
1. Atualização de BerkeleyDB para LevelDB
O Bitcoin usa um banco de dados de chainstate separado para rastrear todas as UTXOs. Versões anteriores à v0.8.0 usavam o banco de dados BerkeleyDB.
Devido à forma como o BerkeleyDB funciona, ele impunha um limite no número de entradas que poderiam ser incluídas em um bloco. Isso criou uma regra de consenso de rede inesperada e não intencional sobre o que torna um bloco válido.
Quando o BerkeleyDB foi substituído pelo LevelDB na v0.8.0, essa limitação desconhecida foi removida. Em , um bloco foi minerado contendo mais entradas do que um nó pré-v0.8.0 aceitaria, criando um hard fork não intencional entre nós na v0.7.0 e nós na v0.8.0.
Isso foi inicialmente remediado pedindo aos mineradores que fizessem downgrade para a v0.7.0, o que fez com que a maioria do poder de mineração voltasse para a antiga cadeia v0.7.0. Isso levou a cadeia v0.7.0 a se tornar a cadeia mais longa novamente, e todos os nós na v0.8.0 reorganizaram de volta para essa cadeia, resolvendo temporariamente o problema e forçando todos os nós de volta à cadeia v0.7.0.
Ao longo dos dois meses seguintes, todos os nós na v0.7.0 foram instados a atualizar para a versão mais recente, a v0.8.1. Um bloco de hard fork permanente foi então minerado em , na altura 252.451, removendo o limite no número de entradas que poderiam ser incluídas em um bloco.
2. Vulnerabilidade de gasto duplo (CVE-2018-17144)
As versões de software entre 0.15.0 e 0.16.2 poderiam ter causado um possível hard fork, mas a vulnerabilidade foi corrigida antes de poder ser explorada, então nenhum hard fork de fato ocorreu.
Em resumo, as versões 0.15.0 a 0.16.2 permitiriam a um minerador gastar duas vezes a mesma UTXO se ela fosse incluída como entrada múltiplas vezes na mesma transação. Apenas mineradores conseguiriam realizar esse ataque, pois os nós só aceitariam essa transação se ela já estivesse minerada em um bloco (caso contrário, rejeitariam a transação por si só).
Essa vulnerabilidade de gasto duplo foi corrigida na 0.16.3, e nenhum hard fork de fato ocorreu.
Resumo
Um hard fork é quando você faz uma atualização no software do Bitcoin que produzirá novos blocos/transações incompatíveis com a versão antiga do software.
Para fazer um hard fork bem-sucedido, você quer que todos que rodam o Bitcoin (ou seja, nós e mineradores) atualizem para a nova versão do software. Isso é para que todos recebam esses novos blocos e concordem com a mesma versão atualizada da blockchain.
Se os mineradores discordarem da atualização e continuarem minerando blocos com ambas as versões (antiga e nova) do software, a blockchain se ramificará em duas blockchains paralelas. Isso dividiria o bitcoin em duas moedas separadas e minaria a integridade do sistema, o que seria ruim para o Bitcoin.
Ainda não houve nenhuma mudança intencional via hard fork no Bitcoin. Em vez disso, prefere-se fazer atualizações gerais do software usando soft forks.