Hard Fork

Anna e Pavel operam, cada um, um Full Node: um computador que verifica as regras do Bitcoin de forma independente. Anna instala software que permite blocos maiores; Pavel mantém o limite original. Chega um bloco que cumpre as condições novas, mas ultrapassa o limite antigo. Anna aceita-o e Pavel rejeita-o. Não é uma falha de ligação: os programas discordam sobre o que pode fazer parte do histórico comum. É esse o significado prático de Hard Fork. Chamar-lhe «atualização» não convence o computador de Pavel a ignorar a sua regra. Dois ramos podem continuar se alguém produzir blocos para cada um e as pessoas os utilizarem. Se os participantes passarem para um só conjunto de regras, não têm de permanecer duas redes ativas. [1]

O nó antigo rejeita o bloco incompatível e o ramo construído sobre ele. Isso não significa que fique parado para sempre. Se os mineradores continuarem outro ramo segundo as regras originais, pode continuar a aceitar esses blocos. Sem essa continuação, fica no último bloco que considera válido. Contam as regras do seu software, não o número de apoiantes da mudança. Para seguir o ramo incompatível, o operador tem de mudar essas regras deliberadamente. [1]

O Bitcoin Cash separou-se do Bitcoin à altura de bloco 478 559, em 1 de agosto de 2017. Adotou regras que permitiam blocos maiores do que os nós de Bitcoin aceitavam na altura e criou a sua própria cadeia, que continuou a funcionar. Os nós de Bitcoin rejeitaram os blocos válidos apenas em BCH, enquanto os nós de BCH seguiram o seu próprio histórico válido. É um exemplo de Hard Fork que criou uma rede separada, em vez de substituir o Bitcoin através de uma atualização na própria rede. [3] [4]

Pense no registo de uma quantia recebida e ainda não gasta: o Bitcoin chama UTXO a essa saída de transação por gastar. Ramos com um passado comum herdam esse registo e depois passam a geri-lo separadamente. Se controlar as chaves necessárias e ambas as redes continuarem a reconhecer a saída, em geral poderá gastar as moedas correspondentes em ambas. Isso não duplica o valor: são ativos diferentes com procura própria. Para fundos numa plataforma de negociação, receber as moedas da outra rede depende também da política de atribuição da plataforma. [4] [6]

Se tiver moedas nos dois ramos, pode querer pagar apenas num deles. Sem proteção, alguém poderá copiar a transação assinada e transmiti-la também no outro, onde poderá ser válida. Esse é o risco de replay. Verifique a proteção da rede concreta e o suporte da carteira. Alterar sighash, as regras dos dados abrangidos pela assinatura, pode por exemplo ligar a transação a uma cadeia específica. Um aspeto diferente dos endereços ajuda a distinguir redes, mas não fornece, por si só, proteção criptográfica contra replay. [3]

A ativação é o momento definido para começar a aplicar as novas regras. A altura indica a posição do bloco na cadeia. Uma data fixa, uma altura de bloco ou a sinalização dos mineradores podem coordenar quem adotou a atualização, mas não podem alterar o software de um nó que não a adotou. Se continuarem a existir participantes economicamente relevantes em cada um dos dois conjuntos de regras, ambas as cadeias podem prosseguir. O plano de ativação de um Hard Fork é, por isso, um plano de migração com risco de divisão. [1]

Governança significa aqui como os participantes decidem sobre mudanças. Um ticker é o símbolo de negociação de um ativo, como BTC ou BCH. Os programadores podem publicar código, os mineradores deslocar hash rate, as empresas escolher um símbolo de negociação e regras de depósito, e os utilizadores escolher software. Nenhuma destas ações altera, por si só, as regras usadas pelos outros nós para verificar os blocos. Uma divisão duradoura pode persistir se um número suficiente de participantes independentes mantiver e valorizar voluntariamente ambos os conjuntos de regras; nem toda a alteração incompatível tem de criar duas redes permanentemente ativas. Chamar «atualização» a um dos ramos é uma designação social, não uma regra de consenso. [1]

Uma rede pode dividir-se sem que ninguém pretenda criar uma nova moeda. Em março de 2013, alguns nós antigos não conseguiram processar um bloco com um número invulgarmente elevado de entradas de transações. Atingiram um limite de bloqueios da base de dados, que impedem operações simultâneas de alterar os mesmos dados. A versão mais recente, a 0.8, usava outra base de dados e aceitou o bloco. Os pools de mineração BTC Guild e Slush regressaram à versão 0.7 e passaram a minerar no ramo também aceite pelos nós antigos. Quando esse ramo acumulou mais trabalho, os nós novos passaram igualmente a segui-lo. Tratou-se de corrigir uma divergência involuntária do software, e não de manter uma rede separada como o Bitcoin Cash. [2]

Um Soft Fork torna as regras existentes mais restritas. Por isso, um bloco que cumpre as novas restrições também cumpre as regras antigas. Um nó antigo pode aceitá-lo sem verificar por si próprio as restrições acrescentadas. Um Hard Fork não oferece essa compatibilidade: um bloco aceite pelo software novo pode violar as regras antigas. Para o aceitar, o operador de um nó antigo tem de alterar as regras do seu software. Um Soft Fork também não garante que a rede permaneça unida: se os mineradores produzirem um bloco que viole uma nova restrição, os nós antigos e novos podem avaliá-lo de forma diferente. [1]

Designemos por V(antiga) o conjunto de todos os blocos aceites pelas regras originais. Um Hard Fork ocorre quando o novo software aceita pelo menos um bloco fora desse conjunto, pelo que V(nova) não é um subconjunto de V(antiga). Muitas vezes trata-se de uma ampliação do conjunto de validade, mas o fator decisivo é a compatibilidade: se um bloco válido para um nó novo pode ser inválido para um nó antigo, o validador antigo não consegue seguir a nova cadeia sem alterar as suas regras. [1]

Chainwork mede o trabalho acumulado demonstrado pela mineração dos blocos de um ramo inteiro. Hashrate, pelo contrário, é a velocidade dos cálculos de mineração. Um nó escolhe o ramo com mais trabalho acumulado apenas entre as cadeias que cumprem as suas regras. Se um bloco as violar, acumular mais trabalho não o torna aceitável. Por isso, Pavel, no exemplo inicial, não aceitará um bloco demasiado grande só porque a maioria dos mineradores está a construir sobre ele. Proof of Work pode decidir entre ramos válidos, mas não pode escolher as regras pelo operador do nó. [1]

Comece por verificar a rede, a carteira suportada e a proteção contra replay. Um nome conhecido ou um endereço semelhante não chegam. Não introduza a sua Seed Phrase, as palavras de recuperação da carteira, num serviço desconhecido que prometa reclamar moedas do fork. Num nó próprio, pode ainda verificar a versão do software, os nós ligados, o último bloco aceite e a impressão digital do bloco no ponto da divisão. Essa impressão chama-se hash. Compare os dados com a documentação da rede; um explorador web não substitui a verificação das regras pelo próprio nó. [5] [6]