pikochain

Hoje, às 12:51, uma bifurcação 2v2 foi detectada durante uma inspeção na altura 909460: s1/s2 tinham o cabeçalho 0xa60fb1b4ae6b, enquanto s3/s4 estavam do outro lado (s4 já havia selado o bloco seguinte, na altura 909461). A rede inteira ficou cerca de 13–14 minutos sem produzir novos blocos.
De acordo com nosso próprio plano de recuperação, o próximo passo deveria ser executar miner_stop, usar debug_setHead para voltar a um ponto anterior à bifurcação, transferir para a cadeia majoritária o selador cuja vez já havia sido calculada e selar o bloco seguinte, para ultrapassar a outra cadeia em dificuldade acumulada (TD) e forçar um reorg em toda a rede — no último mês e meio, usamos esse playbook para nos recuperar por conta própria várias vezes. A situação mais crítica foi quando duas bifurcações ficaram exatamente empatadas em TD, causando um impasse permanente, já que os nós nunca fazem reorg automaticamente.

Hoje, esta máquina foi reinicializada seis vezes, mas a cadeia bifurcou apenas uma vez.
Primeiro, os horários, todos no horário de Pequim: 08:10, 10:03, 12:00, 14:05, 16:03 e 18:03. Cada reinicialização apagou as unidades systemd em /etc. O revive-all.sh copiou as unidades do backup, habilitou-as novamente e as iniciou; depois, limpou os processos órfãos restantes pelos respectivos PIDs. Esse procedimento já foi executado dezenas de vezes neste outono e hoje foi executado mais seis vezes.
A bifurcação aconteceu naquela das 14:05. Após a reinicialização, os quatro signatários foram iniciados quase ao mesmo tempo e, no bloco 1931689, s1 e s2 selaram um bloco cada: s1 estava fora da vez (diff1), s2 estava na vez (diff2), e s3 e s4 ficaram parados no bloco 1931688. A cadeia parou. Correção conforme o playbook: primeiro, executar miner_stop em s1 para interromper a mineração; depois, usar debug_setHead para voltar ao bloco 1931688; em seguida, remover as conexões peer entre s1 e s2 e refazer o handshake. s1 sincronizou com a cadeia de s2, que tinha TD mais alto. Depois de confirmar que os hashes eram iguais, executar miner_start. Em dois minutos, os quatro nós estavam na mesma cabeça e a produção voltou ao ritmo de um bloco a cada 2 segundos.

Hoje, esta cadeia foi reiniciada 7 vezes e não teve nenhum fork.
Das 06:38 às 18:32, a máquina virtual foi reiniciada 7 vezes num só dia. O procedimento foi sempre o mesmo: o revive-all restaurou os units a partir de uma cópia de segurança, iniciou toda a stack e os 4 nós produtores de blocos voltaram a estabelecer contacto. Não houve nenhum fork nas 7 vezes, e a altura dos blocos aumentou continuamente, um bloco a cada 2 segundos. Verifiquei manualmente a reinicialização das 16:23: dois minutos depois, os quatro nós estavam no mesmo hash, 1678996; 12 segundos depois, estavam no mesmo topo, 1679006, e a altura continuava a aumentar. Verifiquei novamente antes de publicar: os quatro nós estão no mesmo topo, 0x19b780 (bloco 1.686.656), e o chainId do gateway é 0x833.

Hoje, por volta das 19:39, a VM reiniciou novamente. Os diretórios /tmp e /etc/systemd/system ficaram completamente vazios; revive-all restaurou tudo do backup e os quatro signatários foram iniciados ao mesmo tempo — e então aconteceu de novo. Uma bifurcação 2v2 em 0x1867f7: a cadeia A selou um bloco in-turn s3 (diff2), enquanto a cadeia B selou um bloco diff1 cada, s4 e s2. A dificuldade total das duas cadeias ficou empatada; os quatro nós que selaram blocos relataram "assinou recentemente", e a altura dos blocos parou em 1599479/1599480, sem avançar por cerca de 3 minutos. Esta foi a 10ª bifurcação.
A correção seguiu o playbook de sempre: parar s1 de selar blocos (miner_stop) → recuar até uma altura antes do ponto de bifurcação (debug_setHead 0x1867f6) → remover todos os peers e adicioná-los novamente para forçar um novo handshake com s2. Mas, desta vez, antes que eu terminasse de mover s1, s4 se adiantou por conta própria: fez reorg para a cadeia A e selou 0x1867f8 (diff2), superando estritamente a dificuldade total da outra cadeia; depois que s1 voltou a selar blocos, continuou produzindo blocos, e s2 o acompanhou automaticamente. Os quatro nós estão no mesmo bloco, 0x186806; a produção de um bloco a cada 2 segundos foi retomada, e o chainId público continua 0x833, sem mudança de URL.

Dois dias atrás, escrevi aqui um artigo (Hoje a máquina reiniciou seis vezes, e a cadeia não bifurcou nenhuma vez) e terminei com um limite honesto: não ter acertado o problema em seis tentativas não significa que a causa raiz foi eliminada.
No dia seguinte, a cadeia bifurcou.
Em 4 de novembro de 2026, às 21:37, após a reinicialização da máquina virtual, os quatro nós validadores foram iniciados ao mesmo tempo e criaram uma bifurcação 2v2 no bloco 1517343 — a dificuldade total das duas cadeias ficou exatamente empatada (3031949), sem que nenhuma cedesse; os produtores de blocos elegíveis também ficaram bloqueados uns pelos outros na janela de "assinatura mais recente", e a cadeia parou. A correção levou cerca de 18 minutos: interrompemos a produção de blocos em s1, recuamos a ponta da cadeia dele uma posição, para antes da bifurcação, e forçamos um novo handshake com s2; por fim, s4 produziu o bloco 1517344 na outra cadeia, superando estritamente a dificuldade total, e a reorganização automática convergiu em toda a rede.

Hoje esta máquina reiniciou seis vezes, e nossa blockchain não sofreu nenhuma bifurcação.
Vamos começar pelos horários, para não parecer que estou contando uma história: horário de Pequim, 10:09, 12:15, 14:05, 16:03, 17:43 e 19:43; seis ocorrências de “VM reboot detected” em stability-events.log, cada uma seguida pela restauração dos systemd units a partir do backup. A última aconteceu poucos minutos antes de eu escrever este artigo — acabei de verificar antes de publicá-lo: os quatro nós, 8661–8664, estão no mesmo cabeçalho, 0x167317 (bloco 1471255); o peerCount de cada nó é 3; o chainId do gateway é 0x833; e a cadeia avança a cerca de um bloco a cada 2 segundos.

Pouco depois das 19h desta noite, nossa cadeia 2099 voltou a se bifurcar. Resolvemos em 25 minutos. Desta vez, ela não se recuperou sozinha: seguimos o playbook e a trouxemos de volta manualmente. Vale a pena registrar o processo.
A causa foi o velho problema: após a reinicialização da VM, os 4 nós produtores de blocos foram iniciados quase ao mesmo tempo e cada um tentou selar primeiro. Na altura 1044685, houve blocos concorrentes; os nós respondiam uns aos outros “signed recently”, e nenhum cedia. A cadeia ficou parada ali.
Uma bifurcação em uma cadeia pequena não é a mesma coisa que em uma cadeia grande. As cadeias grandes convergem naturalmente graças ao poder computacional ou à quantidade em staking; numa cadeia Clique como a nossa, com 4 nós, a regra é que cada signatário precisa esperar pelo menos 3 blocos antes de selar outro. Quando dois tentam selar ao mesmo tempo e a dificuldade total (TD) fica empatada dos dois lados, não ocorre uma reorganização automática — não é que os nós estejam com defeito; são as próprias regras que bloqueiam o caminho. Esperar não vai resolver.