A Noite em que o Bitcoin Teve Duas Histórias Válidas

O bloco 225 430 não foi criado com a intenção de dividir a rede. No entanto, continha mais entradas de transações do que os blocos anteriores, e assim sobrecarregou o banco de dados de uma maneira que revelou a diferença entre as versões. O Bitcoin 0.8 usava o LevelDB e processou o bloco. A versão 0.7, com o Berkeley DB, atingiu o número de bloqueios e terminou com um erro.

O resultado foi perigosamente sutil. Ambos os grupos de nós seguiram as regras como seu programa podia executá-las. A ramificação mais nova não era fraudulenta de acordo com as regras de consenso pretendidas, e os nós mais antigos não foram atacados. A rede se dividiu devido a um limite prático não documentado de uma tecnologia de banco de dados.

Os mineradores com a versão 0.8 construíram sobre o novo bloco. Os mineradores com as versões mais antigas continuaram a partir de seu antecessor. À medida que ambas as ramificações obtiveram blocos adicionais, um pagamento confirmado em uma não precisava existir na outra. Um usuário não podia confiar seguramente no número usual de confirmações até que ficasse claro qual história a maioria econômica aceitaria.

A ramificação mais nova inicialmente carregava aproximadamente sessenta por cento do poder de processamento. Em circunstâncias normais, a cadeia com o maior trabalho acumulado ganharia uma vantagem. Aqui, no entanto, os nós mais antigos não podiam aceitar o novo bloco sem considerar seu trabalho. A reorganização em si não pode superar um bloco que o software de validação local considera inválido.

O incidente assim revelou o limite da regra simples de 'a cadeia mais longa vence'. Mais precisamente, vence a cadeia com o maior trabalho entre aquelas que o nó aceita como válidas. Quando os nós discordam sobre a validade, o hashrate sozinho não é suficiente para a unificação imediata.

Os desenvolvedores notaram o problema quando as alturas e os hashes dos nós monitorados começaram a divergir. A comunicação se concentrou no canal IRC, onde era possível comparar logs, o desempenho das ramificações e as reações dos grandes pools. Gavin Andresen mais tarde, no BIP 50, registrou a cronologia e as decisões tomadas durante a noite.

Não havia escolha entre uma ramificação puramente correta e uma claramente errada. Apoiar a versão 0.8 manteria a cadeia com o maior trabalho, mas cortaria uma quantidade de nós mais antigos. Voltar à ramificação 0.7 significava convencer os novos mineradores a abandonar blocos que já haviam minerado legitimamente e para os quais esperavam recompensa.

O motivo prático para o retorno foi a compatibilidade. A versão 0.8 podia aceitar blocos menores criados para a ramificação mais antiga, enquanto os nós 0.7 não podiam aceitar o bloco problemático da nova ramificação. Se o poder de processamento se movesse para a ramificação aceitável para ambos os grupos, a rede poderia se reunificar sem um upgrade forçado imediato de todos os nós mais antigos.

A decisão não era uma ordem que Andresen pudesse transmitir pelo protocolo. Os desenvolvedores entraram em contato com os operadores dos pools e explicaram a situação. As corretoras receberam a recomendação de suspender os depósitos. O Bitcoin.org publicou um alerta e pediu aos grandes pools que voltassem à versão anterior do software, para reunir a rede em uma ramificação compatível.

Essa coordenação foi rápida justamente porque o círculo de participantes-chave ainda era relativamente pequeno e as pessoas se conheciam dos canais públicos. A velocidade ajudou a salvar a rede de uma divisão mais longa, mas também mostrou as ligações sociais sobre as quais o funcionamento inicial dependia. O Bitcoin não tinha um chefe; tinha pessoas cuja ligação ou mensagem podiam mover uma grande parte do poder de processamento.

A conversa no IRC não tinha força legal nem uma chave administrativa secreta. Seu significado residia no fato de que, em um único lugar, reunia pessoas com diferentes possibilidades de intervenção. Os desenvolvedores podiam explicar a causa, as pools podiam redirecionar o hashrate, as exchanges podiam suspender depósitos e os operadores de nós podiam mudar de versão. Cada passo tinha seu próprio risco e ninguém podia garantir que os outros obedeceriam. A decisão de apoiar o ramo compatível com a versão 0.7, portanto, não foi uma ordem técnica emanada do centro da rede, mas uma aposta coordenada de que esse caminho restauraria mais rapidamente o histórico comum com o menor impacto sobre os usuários. O sucesso não pode ser separado do pequeno tamanho da comunidade na época, nem apresentado como um procedimento universal de crise.

O passo decisivo veio do BTCGuild, dirigido por Michael Marsee, conhecido como Eleuthria, e do Slush Pool, de Marek Palatinus. Os dois operadores voltaram da versão 0.8 para a 0.7 e direcionaram sua potência de mineração à ramificação antiga. Isso ajudou a mudar a relação entre o trabalho acumulado nas duas cadeias.

Não se tratou de um gesto gratuito na tabela. Os blocos minerados na ramificação abandonada pararam de fazer parte da cadeia principal durante a reorganização, então suas recompensas não podiam mais ser gastas. O BIP 50 explicitamente lembra que os pools abandonaram uma quantia significativa de dinheiro para que a rede voltasse à ramificação comum.

Assim que a ramificação mais antiga assumiu a liderança, os nós atualizados 0.8 puderam aceitá-la e reorganizar sua história. Os nós mais antigos já estavam nela. A divisão foi encerrada não porque uma versão remotamente reescreveu a outra, mas porque os mineradores criaram mais trabalho acima do ponto que ambos podiam verificar.

Durante o incidente, houve pelo menos um grande gasto duplo, descrito como um experimento, não um ataque planejado. O evento ainda mostrou o risco real: uma transação podia ser confirmada na ramificação que mais tarde seria abandonada. A recomendação de parar os depósitos não foi pânico; protegeu os serviços de saldos contábeis baseados em uma história temporária.

Os pools, naquele momento, não possuíam a rede. Podiam influenciar a ordem dos blocos com o poder de processamento que os mineradores lhes confiaram, mas não podiam forçar cada nó completo a aceitar regras arbitrárias. Seu sucesso dependia de um objetivo estreito: criar uma ramificação que os nós antigos e novos considerassem válida e fornecer-lhe o máximo de trabalho.

Gavin Andresen descreveu o incidente mais tarde no BIP 50. O documento não afirma que a rede funcionou sem falhas. Explica a causa, o desenrolar dos acontecimentos, os blocos perdidos, o gasto duplo e as medidas para detectar divergências semelhantes mais cedo. Com a publicação dessa análise, a experiência da noite de crise deixou de depender apenas da memória dos participantes. Outros desenvolvedores também puderam aprender com ela.

Uma lição foi que o consenso não inclui apenas regras escritas em comentários ou documentação. O comportamento prático de um programa amplamente implantado pode se tornar uma limitação da rede, mesmo que ninguém tenha pretendido que tivesse significado monetário. A migração do banco de dados, portanto, não deve ser considerada uma mudança puramente interna se puder alterar a aceitação de um bloco.

Outra lição foi a necessidade de coordenar upgrades mais cuidadosamente e testar blocos próximos aos limites operacionais. A versão 0.8 trouxe melhorias de desempenho, mas a diferença se manifestou apenas na cadeia real. Após o incidente, os desenvolvedores implementaram limites temporários e prepararam um caminho que permitiria às dependências mais antigas serem abandonadas com segurança mais tarde.

A história é às vezes usada como prova de que o Bitcoin é controlado por alguns desenvolvedores, outras vezes como prova de que é automaticamente indestrutível. Nenhuma das versões abreviadas é precisa. As pessoas conseguiram coordenar urgentemente a correção, mas precisaram da cooperação dos pools, bolsas e operadores de nós. O software decidia em cada computador separadamente, e o resultado comum surgiu apenas de sua combinação.

A noite de 11 para 12 de março terminou com uma única cadeia principal, mas as divergências não desapareceram sozinhas. Alguns participantes identificaram o problema, outros suspenderam serviços, e os mineradores abriram mão do trabalho já realizado para recuperar um histórico compatível. O Bitcoin superou seus dois passados concorrentes graças às regras, aos custos econômicos assumidos e às pessoas dispostas a admitir que, dessa vez, o software mais novo precisava ceder.

O valor do BIP 50 está em não encerrar o incidente com uma declaração de vitória da descentralização. Ele registra a causa concreta, a cronologia, o trabalho perdido e os passos previstos para evitar outra surpresa semelhante. Uma falha incômoda torna-se, assim, base para novos testes. Fica também uma pergunta: quantas suposições não escritas separam duas versões de um programa que consideramos compatíveis? O consenso vai além de uma lista de regras no papel. Implementações e nós independentes precisam chegar ao mesmo resultado até nos casos extremos. A importância desse acordo fica mais clara quando ele se desfaz.