Forks, ou a ameaça deles, parecem ser uma característica estabelecida no cenário da criptomoeda. Mas o que são eles? Por que eles são tão importantes? E qual é a diferença entre um hard fork e um soft fork?
Um “fork” (ou “garfo”), em termos de programação, é uma modificação de código do código aberto. Normalmente, o código bifurcado é semelhante ao original, mas com modificações importantes, e os dois “dentes do garfo” coexistem confortavelmente. Às vezes, uma bifurcação é usada para testar um processo, mas, com criptomoedas, ela é usada com mais frequência para implementar uma alteração fundamental ou para criar um novo recurso com características semelhantes (mas não iguais) à original.
Nem todos os forks são intencionais. Com uma base de código de software livre amplamente distribuída, um fork pode acontecer acidentalmente quando nem todos os nós estão replicando as mesmas informações. Normalmente, esses forks são identificados e resolvidos, no entanto, e a maioria deles nas criptomoedas são devidos as discordâncias sobre características incorporadas.
Uma coisa a ter em mente com forks é que eles têm uma “história compartilhada”. O registro de transações em cada uma das cadeias (antiga e nova) é idêntico antes da divisão.
Hard Forks
Existem dois tipos principais de bifurcação de programação: hard e soft.
Um hard fork é uma alteração em um protocolo que torna as versões mais antigas inválidas. Se as versões mais antigas continuarem em execução, elas acabarão com um protocolo diferente e com dados diferentes da versão mais recente. Isso pode levar a uma confusão significativa e a possíveis erros.
Com o bitcoin, seria necessário um hard fork para alterar parâmetros definidores, como o tamanho do bloco, a dificuldade do quebra-cabeça criptográfico que precisa ser resolvido, limites para informações adicionais que podem ser adicionadas, etc. Uma alteração em qualquer dessas regras levaria os blocos serem aceitos pelo novo protocolo, mas rejeitados por versões mais antigas e pode levar a sérios problemas – possivelmente até mesmo uma perda de fundos.
Por exemplo, se o limite de tamanho de bloco fosse aumentado de 1MB para 4MB, um bloco de 2MB seria aceito pelos nós executando a nova versão, mas rejeitado pelos nós que executavam a versão mais antiga.
Digamos que esse bloco de 2MB seja validado por um nó atualizado e adicionado ao blockchain. E se o próximo bloco for validado por um nó executando uma versão mais antiga do protocolo? Ele tentará adicionar seu bloco ao blockchain, mas detectará que o bloco mais recente não é válido. Então, ele irá ignorar esse bloco e irá anexar sua nova validação à anterior. De repente você tem dois blockchains, um com blocos de versões mais antigas e mais novas, e outro com blocos de versões mais antigas. A cadeia que cresce mais rapidamente dependerá de quais nós obterão os próximos blocos validados e poderá haver divisões adicionais. É possível que as duas (ou mais) cadeias possam crescer em paralelo indefinidamente.
Este é um hard fork, e é potencialmente confuso. Também é arriscado, pois é possível que os bitcoins gastos em um novo bloco possam ser gastos novamente em um bloco antigo (uma vez que os comerciantes, carteiras e usuários que executam o código anterior não detectariam os gastos com o novo código, que consideram inválidos).
A única solução é que um ramo seja abandonado em favor do outro, o que envolve a perda de algumas mineradoras (as transações em si não seriam perdidas, seriam apenas realocadas). Ou, todos os nós precisariam mudar para a versão mais nova ao mesmo tempo, o que é difícil de conseguir em um sistema amplamente distribuído e descentralizado.
Ou o bitcoin se divide, o que aconteceu (olá, bitcoin cash).
Soft Fork
Um soft fork ainda pode funcionar com versões mais antigas.
Se, por exemplo, um protocolo for alterado de forma a apertar as regras, implementar uma mudança estética ou adicionar uma função que não afete a estrutura de alguma forma, os novos blocos de versão serão aceitos pelos nós da versão antiga. Não o contrário, porém: a versão mais nova e mais “apertada” rejeitaria os blocos de versões antigas.
Em bitcoin, idealmente os mineiros da versão antiga perceberiam que seus blocos foram rejeitados e seriam atualizados. À medida que mais mineiros se atualizam, a cadeia com blocos predominantemente novos torna-se a mais longa, o que tornaria ainda mais obsoletos os blocos de versões antigas, o que levaria a uma maior atualização de mineiros, e o sistema se auto-corrige. Como os novos blocos de versão são aceitos pelos nós antigos e atualizados, os blocos da nova versão acabam vencendo.
Por exemplo, digamos que a comunidade decidiu reduzir o tamanho do bloco para 0,5 MB do limite atual de 1MB. Os nós da nova versão rejeitariam blocos de 1MB e seriam construídos no bloco anterior (se ele fosse extraído com uma versão atualizada do código), o que causaria uma bifurcação temporária.
Este é um soft fork e já aconteceu várias vezes. Inicialmente, o Bitcoin não tinha um limite de tamanho de bloco. Introduzir o limite de 1MB foi feito através de um soft fork, uma vez que a nova regra era “mais rigorosa” do que a antiga. A função pay-to-script-hash, que aprimora o código sem alterar a estrutura, também foi adicionada com sucesso por meio de um soft fork. Este tipo de emenda geralmente requer apenas que a maioria dos mineradores faça o upgrade, o que torna mais viável e menos perturbador.
Os soft forks não carregam o risco de gastar duas vezes assim como ocorre com hard forks, já que os comerciantes e usuários que executam nós antigos lerão blocos de versões novas e antigas.
Para exemplos de mudanças que requerem um soft fork, veja a “lista de desejos do softfork“.