Em 25 de maio, às 5h55 (horário de Brasília), aconteceu uma reorganização de sete blocos na Beacon Chain do Ethereum. O objetivo deste artigo é fornecer um guia visual para entender como o protocolo proof of stake (ou PoS, na sigla em inglês) irá funcionar no Ethereum e por que a reorganização aconteceu.
Basicamente, a reorganização não é um comportamento previsto para a Beacon Chain. Aconteceu por conta de uma infeliz combinação de três causas distintas:
– visualizações divergentes por validadores de uma proposta atrasada de blocos devido a uma recente atualização à bifurcação alternativa chamada “proposer boost” (ou “impulsionador de proponentes”, em tradução livre);
– a atualização “proposer boost” foi lançada como uma bifurcação moderada (ou “soft fork”), considerada como uma mudança local que só poderá ser implementada à rede no futuro. Criou-se uma situação em que alguns validadores estavam usando o impulsionador e alguns não, divergindo as opiniões;
– uma implementação conhecida, mas incorreta de quando a bifurcação alternativa deve ser operada prevaleceu em alguns clientes, resultando na persistência da falha.
E o mais importante: a reorganização não resultou na perda de finalidade. A finalidade nem ficou atrasada. Então, é necessário mais precisão ao falar sobre o que foi exatamente reorganizado.
A seguir, vamos entender os conceitos básicos do proof of stake no Ethereum antes de compreender como a reorganização realmente aconteceu.
Proof of Stake no Ethereum
No Ethereum, o PoS possui dois mecanismos de consenso que operam em paralelo.
O primeiro, chamado de FFG Casper, é responsável por fornecer finalidade econômica à blockchain. A cada “epoch” — grupo de 30 mil blocos —, “votos-fonte” e “votos-alvo” por atestadores são somados. Quando um bloco do ponto de verificação (ou “checkpoint”) — o início de uma epoch — acumula votos-alvo suficientes, torna-se justificado.
Quando uma fonte recém-justificada é utilizada para justificar um ponto-alvo de verificação, este é justificado e a fonte é finalizada. A ideia é que nenhum bloco de ponto de verificação também possa ser finalizado sem que pelo menos ⅓ do staking ativo do validador sofra “slashing” (perda de ethers como punição por agir de má fé ao validar blocos).
Então não pode haver reorganização na blockchain finalizada sem que haja uma grande perda de ethers por alguma parte envolvida. Mas a atual reorganização não tinha relação com esta parte do consenso.
O segundo componente, chamado de LMD GHOST, visa fornecer um registro dinamicamente disponível, ou seja, expande a blockchain enquanto a finalização segue seu ritmo. Blocos nessa blockchain acumulam um peso aplicado a eles pelo “voto-líder” dos atestadores. Esse peso é usado para descobrir, caso haja uma bifurcação, qual ramificação o validador deve seguir.
Já que a expectativa é que o peso seja acumulado rapidamente após um bloco ser lançado, a previsão é que bifurcações sejam raras e um bloco pontual não seja reorganizado.
No PoS do Ethereum, o tempo é dividido em “slots” e cada slot possui uma duração de 12 segundos. Para cada slot, escolhe-se um proponente, que cria seu bloco sobre o que acreditam ser a blockchain principal, segundo a norma da bifurcação alternativa LMD GHOST (que será chamada apenas de “bifurcação alternativa” neste texto).
Espera-se que proponentes transmitam seu bloco no início do slot enquanto atestadores transmitem seu voto-fonte/alvo/líder quatro segundos após o slot ou após receberem o bloco de seu slot, havendo tempo suficiente para que o proponente faça seu bloco ser visto pelos atestadores de seu próprio slot.
Apesar da fila (“buffer”), descobriu-se recentemente que um proponente atrasado pode reorganizar prévia e maliciosamente o proponente do slot seguinte. Enquanto isso, o impulsionador foi sugerido para solucionar a possibilidade de haver visualizações divergentes com ataques de ponderação (ou “balancing attacks”) e também foi aplicado a reorganizações prévias.
Ao usar o impulsionador, atestadores evidenciam o peso ao proponente do slot atual que estão atestando, basicamente preferindo propostas pontuais. Vamos explicar como isso funciona na prática.
Então como a blockchain foi bifurcada?
Primeiro, veremos como a bifurcação aconteceu antes de entendermos o passo a passo. Os retângulos abaixo representam blocos enquanto os círculos representam as atestações (votos). Quanto maior o círculo, mais votos de atestação existem para um bloco específico. É possível ver o peso dos votos se acumulando ao longo do tempo à medida que blocos recebem cada vez mais atestações.
Os blocos 74 e 75 apareceram ao mesmo tempo, criando uma bifurcação. Uma série de proponentes criou blocos a partir do 75 enquanto a bifurcação do bloco 74 estava acumulando mais peso do que a ramificação adversária.
Na sequência, o proponente do bloco 82 o criou sobre o bloco 74, finalizando a bifurcação em detrimento da reorganização dos blocos 75 a 81. Abaixo, cada etapa é analisada em detalhes para entender como tudo aconteceu.
As etapas da bifurcação
No slot 73, atestadores desse slot votaram no bloco 73, transmitido na hora certa. Até aqui, tudo bem.
No slot 74, nenhum bloco apareceu, então atestadores do slot 74 estão votando no bloco do slot 74, dando mais destaque a ele.
Os blocos 74 e 75 apareceram ao mesmo tempo, no início do slot 75, pois o bloco 74 está atrasado. O impulsionador foi criado para dar mais peso ao 75, então atestadores do slot 75 preferem o bloco 75 em vez do bloco 74 pois, na opinião deles, o bloco 75 é o pontual. Porém, nem todos os atestadores estavam usando o impulsionador, então os votos ficaram divididos (quase que em 50/50):
– atestadores que operam um cliente sem o impulsionador ativado preferem o bloco 74;
– atestadores que operam um cliente com o impulsionador ativado preferem o bloco 75.
Leia Também
É possível ver a divisão exata à medida que votos são acumulados em ambos os lados da bifurcação, pois atestadores sem o impulsionador preferem o slot 74 e os atestadores com impulsionador preferem o slot 75. Acontece que uma quantidade maior de atestadores não tinham ativado o impulsionador, então a bifurcação superior tinha mais peso do que a bifurcação inferior.
Agora, a questão é: Dado que o bloco 74 tinha mais peso do que o bloco 75, por que o proponente 76 criou seu bloco sobre o bloco 75?
O motivo é sutil e tem a ver com um comportamento de clientes que já foi atualizado. A expectativa é que proponentes operem a bifurcação alternativa antes de fazer sua proposta, definida no momento de seu slot.
No entanto, o proponente do bloco 76 estava usando a computação da bifurcação alternativa que operava e estava definida no momento do slot anterior. O impulsionador se aplica ao proponente do atual slot da bifurcação de escolha.
Além disso, o proponente 76 estava impulsionando incorretamente o proponente 75 na sua visualização do cabeçalho atual e selecionou o bloco 75 como o “bloco-pai” de seu bloco. Do ponto de vista do proponente 76:
Atestadores do 75 + impulsionador do 75 > atestadores do 74
Enquanto isso, os atestadores do slot 76 continuaram dividindo seus votos entre o bloco mais pesado sem o impulsionador (com o bloco 74 como cabeçalho) e o blockchain mais pesado com o impulsionador (com o bloco 76 como cabeçalho).
O cenário se repete até o slot 81. Perceba que todos os atestadores dos slots 75 a 81 que não estão usando o impulsionador continuam votando no bloco 74, aumentando seu peso.
Por fim, surge um proponente que não aplica o impulsionador no slot anterior e decide onde criar seu próprio bloco. O proponente 82 vê o bloco 74 como um bloco mais pesado do que o bloco 81. Embora o bloco 81 possua o peso de todos os blocos anteriores, lembre-se que sempre existe um pouco mais de ponderação nos votos de atestação para o 74 do que para qualquer um dos blocos de 75 a 81…
Aqui, não existe confusão para atestadores no slot 82:
– aqueles que não usam o impulsionador claramente consideram o 82 como o bloco correto pelo mesmo motivo que o bloco 82 foi criado sobre o bloco 74: o bloco 74 é mais pesado do que o bloco 81;
– aqueles que usam o impulsionador consideram ainda mais o bloco 82 como o bloco correto. Os votos não estão mais divididos.
Por fim, a blockchain volta ao normal, pois o proponente 83 cria sobre o bloco 82. Neste momento, ficou evidente que os blocos de 75 a 81 foram devidamente reorganizados.
Conclusões sobre a reorganização
A reorganização destaca um caso de falha da blockchain dinamicamente disponível, uma falha que é teoricamente possível, mas praticamente impensável, assim como reorganizações em redes proof of work (ou PoW) são possíveis, mas raramente acontecem (barrando o comportamento adversário).
Então, é importante entender que os fatores que contribuíram à reorganização presente são puramente acidentais:
– Um bloco atrasado sempre pode acontecer — não há como evitar. A blockchain dinamicamente disponível foi criada, a princípio, para lidar com isso de forma justa para que mais proponentes vejam seus blocos serem aceitos na blockchain canônica.
– Mas ficou claro que até mudanças que parecem ser “apenas locais” (assim como a bifurcação de escolha) precisam ser consideradas no amplo contexto do consenso. Pesquisadores do protocolo Ethereum se familiarizaram com a ideia de “visualizações divergentes” entre validadores, em que um conjunto de validadores visualiza algo localmente e outro conjunto visualiza outra coisa, e a forma como essas visualizações divergentes podem contribuir no atraso do “liveness” — processo que exige que a operação de um sistema avance mesmo que partes do software possam não ser operadas simultaneamente por diversos processos. Deveria ter sido identificado que uma apresentação desigual do impulsionador teria o potencial de criar uma visualização divergente. Piorou ainda mais por uma falha de implementação que já era conhecida.
– Esse problema poderia não ter acontecido se todos os validadores estivessem operando a mesma configuração! Em particular, não teria acontecido após a fusão, pois todos os validadores devem fazer a bifurcação às atualizações da fusão antes que esta aconteça ou serão expulsos do consenso.
No Ethereum, o PoS é um consenso híbrido, criado para manter a robustez em ambientes atípicos. Uma série de tuítes recentes por Sreeram Kannan destaca bem os desafios a serem enfrentados.
Os limites conhecidos do consenso, também mencionados nos links contidos no fio do pesquisador Sreeram, são as principais mudanças ao protocolo.
Embora seja péssimo quando tais falhas acontecem, (na minha opinião) elas não invalidam a abordagem que o Ethereum está escolhendo. Mas nos alertam para seguirmos com cuidado e criar um protocolo que não seja apenas robusto na teoria, como também na prática.
Muito obrigado a todos os pesquisadores e desenvolvedores que ajudaram a fazer esse problema fazer sentido. Mais especificamente, a Paul Hauner, que detectou a reorganização em uma questão de minutos, fez a triagem e o diagnóstico do problema na hora seguinte em um chat de grupo com outros desenvolvedores de clientes do consenso. Obrigado a Martin Köppelmann por publicamente abordar a questão, a Jacek Sieka por me fornecer dados de apoio a esta análise, a Potuz por sua própria análise, a Terence Tsao por seu fio que rapidamente forneceu percepções à comunidade, a Michael Sproul por dados extras, e a Caspas e Francesco por suas habilidades de diagramação em uma tardia quarta-feira.
O código para a criação de diagramas está disponível aqui.
*Texto escrito por Barbané Monnot, que faz parte da equipe de pesquisa Robust Incentives Group da Ethereum Foundation, especialista em análises de incentivos para protocolos. Publicado originalmente no substack do autor.
**Traduzido por Daniela Pereira do Nascimento com autorização do autor.
