Análise da anomalia breve da camada de consenso do Ethereum durante duas noites consecutivas

Recentemente, a camada de consenso do Ethereum sofreu uma breve anomalia, gerando ampla atenção na indústria. Este artigo irá analisar profundamente o evento.

Resumo do Evento

Nos dias 11 e 12 de maio, houve anomalias temporárias na camada de consenso do Ethereum durante duas noites consecutivas. A análise mostra que isso se deve principalmente à sobrecarga de alguns nós clientes da camada de consenso do Ethereum, resultando na falha e desconexão do nó validador (Validator). Isso afetou diretamente a votação do Epoch, impedindo que atingisse o limiar necessário de 2/3, resultando na incapacidade da camada de consenso de confirmar a finalização.

É importante notar que, apesar das anomalias, a rede Ethereum se recuperou para a normalidade em um curto espaço de tempo. Isso reflete a resiliência e a capacidade de auto-reparação do algoritmo de consenso PoS do Ethereum.

Detalhes do Evento

Normalmente, o estado da rede de consenso PoS do Ethereum é finalizado em 2 Epochs (Finalizado). No entanto, nas duas ocorrências da semana passada, houve um atraso na finalização do Epoch:

• 11 de maio: O Epoch foi adiado por 3 Epochs, cerca de 20 minutos.
• 12 de maio: O Epoch foi adiado em 8 Epochs, cerca de 51 minutos.

Apesar de o Epoch não ter conseguido ser finalizado a tempo, a rede Ethereum continua a gerar blocos e processar transações. No entanto, devido à insuficiência da taxa de votação dos nós de validação, o Epoch não consegue obter a garantia de segurança ao nível de consenso da rede PoS da Ethereum.

Vale a pena mencionar que, no segundo evento, devido ao atraso na confirmação que ultrapassou o limite pré-definido, foi acionado o mecanismo Inactivity leak do algoritmo de consenso Ethereum. Isso resultou na apreensão de cerca de 28 ETH e cerca de 50 ETH não emitidos.

Análise de Causas

A causa direta destes dois eventos foi a sobrecarga de alguns nós clientes da camada de consenso do Ethereum, levando à falha e desconexão dos nós de validação, impossibilitando a realização normal da votação de consenso. Especificamente, a seguir:

1. Quando um nó recebe um atestado de um bloco obsoleto ( Attestation ), é necessário recalcular o estado da cadeia de beacon para validar esses atestados, e este processo requer muitos recursos de CPU e memória.

2. Quando muitos testemunhos apontando para blocos obsoletos são recebidos ao mesmo tempo, os recursos do nó são esgotados, levando o nó de validação a falhar e ficar offline.

3. Embora esses problemas possam ser resolvidos através do cache baseado em testemunhos que apontam para blocos, o crescimento da escala dos nós de validação e a grande quantidade de atestações desse tipo resultaram na quebra do cache da implementação do cliente problemático.

Atualmente, os clientes da camada de consenso Teku e Prysm lançaram versões de patch para resolver esse problema. As versões de patch filtram esses testemunhos antigos, ignorando-os quando o testemunho aponta para um Slot antigo ou um Checkpoint que o nó nunca viu.

Vantagens do design do Ethereum

Neste evento, o Ethereum demonstrou suas vantagens de design:

1. Diversidade de clientes: as diferentes implementações de clientes têm designs distintos, mesmo que alguns clientes apresentem problemas, isso não afetará o funcionamento normal de outros clientes.

2. Design do algoritmo Gasper: separa a produção de blocos da finalização, ou seja, mesmo que a finalização dos blocos seja bloqueada, a produção de blocos não para, garantindo a disponibilidade da rede.

Experiência e Inspiração

1. A diversidade de clientes ainda precisa ser fortalecida: atualmente, a diversidade de clientes Ethereum ainda tem espaço para melhorias, especialmente porque os clientes da camada de execução estão concentrados no Geth, que representa 61%, o que apresenta riscos potenciais.

2. O mecanismo de troca de cliente precisa ser aprimorado: quando um determinado cliente apresenta problemas, como fazer a transição de forma segura para uma implementação de cliente normal continua a ser um desafio.

3. A monitorização do consenso deve ser reforçada: é necessário um serviço semelhante ao Safe Head para monitorizar continuamente o estado em tempo real da rede PoS do Ethereum, detectando e alertando anomalias de forma oportuna.

4. Reforçar a educação dos usuários: informar sobre o mecanismo de consenso PoS do Ethereum, evitando que os usuários gerem pânico desnecessário.

5. A camada de aplicação deve estar preparada para enfrentar: aplicações como Layer2, exchanges, Oráculos, etc. precisam lidar corretamente com cenários de instabilidade da rede, como prolongar adequadamente o tempo de confirmação ou suspender serviços.

Resumo

Este evento demonstrou a resiliência e a capacidade de auto-reparo do algoritmo de consenso PoS do Ethereum, ao mesmo tempo que expôs algumas áreas que precisam de melhorias. No futuro, o ecossistema Ethereum precisa continuar a investir em diversidade de clientes, monitoramento da rede, educação dos usuários e outras áreas, para melhorar a estabilidade e a confiabilidade de toda a rede.