Garfo rígido vs. garfo suave

Forks, ou a ameaça deles, parecem ser uma característica estabelecida do cenário das Criptomoeda . Mas o que são? Por que são tão importantes? E qual é a diferença entre um hard fork e um soft fork?

Um “fork”, em termos de programação, é uma modificação de código de fonte aberta. Normalmente, o código bifurcado é semelhante ao original, mas com modificações importantes, e os dois “pinos” coexistem confortavelmente. Às vezes, um fork é usado para testar um processo, mas comcriptomoedas, é mais frequentemente usado para implementar uma mudança fundamental ou para criar um novo ativo com características semelhantes (mas não iguais) ao original.

Nem todos os forks são intencionais. Com uma base de código de código aberto amplamente distribuída, um fork pode acontecer acidentalmente quando nem todos os nós estão replicando as mesmas informações. Normalmente, esses tipos de forks acidentais são identificados e resolvidos. A maioria dos forks de Criptomoeda ocorre devido a desacordos sobre características incorporadas, como exploraremos abaixo.

Uma coisa a ter em mente sobre 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.

Garfos rígidos

Existem dois tipos principais de fork de programação:

• Garfo rígido.
• Garfo macio.

Um hard fork é uma mudança em umcadeia de blocosprotocolo que torna versões mais antigas inválidas. Se versões mais antigas continuarem em execução, elas acabarão com um protocolo diferente e com dados diferentes da versão mais nova. Isso pode levar a uma confusão significativa e possíveis erros.

Com Bitcoin, um hard fork seria necessário para alterar parâmetros de definição como o tamanho do bloco, o algoritmo de dificuldade de mineração, limites para informações adicionais que podem ser adicionadas, ETC Uma alteração em qualquer uma dessas regras faria com que os blocos fossem aceitos pelo novo protocolo, mas rejeitados por versões mais antigas e poderia levar a problemas sérios – possivelmente até mesmo uma perda de fundos.

Por exemplo, se olimite de tamanho de blocofossem aumentados de 1 MB para 4 MB, um bloco de 2 MB seria aceito pelos nós que executavam a nova versão, mas rejeitado pelos nós que executavam a versão mais antiga.

Digamos que esse bloco de 2 MB 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 ignorará esse bloco e anexará sua nova validação ao ONE.

De repente, você tem dois blockchains, um com blocos de versões mais antigas e mais novas, e outro com apenas blocos de versões mais antigas. Qual cadeia cresce mais rápido dependerá de quais nós terão os próximos blocos validados, e pode acabar havendo 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 bitcoins gastos em um novo bloco possam ser gastos novamente em um bloco antigo (já que comerciantes, carteiras e usuários executando o código anterior não detectariam os gastos no novo código, que eles consideram inválido).

A única solução é que um ramo seja abandonado em favor do outro, o que envolve alguns mineradores perdendo (as transações em si não seriam perdidas, elas 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 descentralizado e amplamente espalhado.

Ou, divisões de Bitcoin , o que aconteceu (olá, Bitcoin Cash).

Garfo macio

Um soft fork é essencialmente o oposto de um hard fork, em que as alterações recentemente implementadas permanecem compatíveis com versões mais antigas.

Por exemplo, se um protocolo for alterado de tal forma que aperte as regras, implemente uma mudança cosmética ou adicione uma função que não afete a estrutura do blockchain de forma alguma, então os blocos de nova versão serão aceitos pelos nós de versão antiga. Não o contrário, no entanto: a versão mais nova, “mais apertada”, rejeitaria os blocos de versão antiga.

Em Bitcoin, versão antiga mineiros perceberiam que seus blocos estavam sendo rejeitados e seriam forçados a atualizar. À medida que mais mineradores atualizam para a versão mais recente, a cadeia com blocos predominantemente novos se torna a mais longa, o que, por sua vez, aumenta a quantidade de blocos órfãos de versões antigas que são criados e faz com que mais mineradores atualizem. Esse processo garante que o sistema se autocorrija. Como os blocos de novas versões são aceitos pelos nós antigos e atualizados, os blocos de novas versões eventualmente WIN.

Por exemplo, digamos que a comunidade decidiu reduzir o tamanho do bloco para 0,5 MB do seu limite teórico atual de 4 MB (comBlocos SegWit.) Os novos nós de versão rejeitariam blocos com o limite antigo e construiriam sobre o bloco anterior (se ele fosse minerado 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 T tinha um limite de tamanho de bloco. A introdução do limite de 1MB foi feita por meio de um soft fork, já que a nova regra era “mais rigorosa” do que a ONE.

O função hash de pagamento para script, que aprimora o código sem alterar a estrutura, também foi adicionado com sucesso por meio de um soft fork. Esse tipo de emenda geralmente requer que apenas a maioria dos mineradores atualizem, o que o torna mais viável e menos disruptivo.

Os soft forks não carregam o risco de gasto duplo que assola os hard forks, já que comerciantes e usuários que executam nós antigos lerão blocos de versões novas e antigas.

Para exemplos de mudanças que exigiriam um soft fork, veja o “lista de desejos do softfork”.