- Tema
25k Popularidade
56k Popularidade
7k Popularidade
16k Popularidade
30k Popularidade
2k Popularidade
95k Popularidade
26k Popularidade
26k Popularidade
7k Popularidade
- Marcar
25k Popularidade
56k Popularidade
7k Popularidade
16k Popularidade
30k Popularidade
2k Popularidade
95k Popularidade
26k Popularidade
26k Popularidade
7k Popularidade
A camada de consenso do Ethereum teve breves anomalias durante duas noites consecutivas. A auto-cura da rede demonstra a resiliência do PoS.
Análise de anomalias breves no Ethereum durante duas noites consecutivas
Nos dias 11 e 12 de maio, a camada de consenso do Ethereum apresentou anomalias temporárias durante duas noites consecutivas. A análise indica que isso se deve principalmente à alta carga de certos nós clientes da camada de consenso do Ethereum, levando à queda offline de nós validadores. Isso impactou diretamente a votação do Epoch, que não conseguiu alcançar o limite de 2/3, fazendo com que a camada de consenso não conseguisse confirmar a finalização. No entanto, a rede Ethereum se recuperou rapidamente, o que também reflete a resiliência e a capacidade de auto-reparo do algoritmo de consenso PoS do Ethereum.
Revisão de Eventos
Normalmente, o estado da rede de consenso PoS do Ethereum é finalizado em 2 Epochs. No entanto, na semana passada, ocorreram duas situações de atraso na finalização dos Epochs:
Durante este período, a rede Ethereum continuou a produzir blocos e a processar transações. No entanto, devido à baixa taxa de votação dos nós validadores, o Epoch não pôde ser finalizado, ou seja, não se obteve a garantia de segurança ao nível do consenso da rede Ethereum PoS. Isso significa que, em situações extremas, as transações dentro desse epoch podem ser revertidas.
Na verdade, durante este período, a rede Ethereum não teve bifurcações, e os nós validadores não realizaram votos maliciosos. A grande quantidade de nós validadores offline resultou numa taxa de votação insuficiente, que é a razão direta pela qual o Epoch não pôde ser confirmado. Observou-se que os nós validadores offline apresentaram uma situação anormal de sobrecarga da CPU.
No segundo evento, devido ao atraso na finalização que ultrapassou 4 Epochs, foi ativado o mecanismo de Inactivity leak do algoritmo de consenso Ethereum:
Análise de Causas
A causa direta deste evento foi a sobrecarga de certos nós clientes da camada de consenso do Ethereum, resultando na falha e desconexão dos nós validadores, impossibilitando a realização normal da votação de consenso. A análise específica é a seguinte:
Quando um nó recebe uma atestação ( que aponta para um bloco obsoleto, ele precisa recalcular o estado da cadeia de beacon para validar essas atestações, e esse processo consome uma grande quantidade de recursos de CPU e memória. Quando um grande número de atestações que apontam para blocos obsoletos é recebido simultaneamente, os recursos de CPU e memória do nó se esgotam, levando esses nós validadores a falhar e ficarem offline.
Teoricamente, esses problemas podem ser resolvidos através de um cache baseado em testemunhos que apontam para blocos. No entanto, devido ao aumento no número de validadores e à grande quantidade de atestações desse tipo, o cache da implementação do cliente que apresenta problemas foi comprometido, forçando os nós a consumirem muitos recursos para recalcular o estado da cadeia de beacon.
Os clientes da camada de consenso Teku e Prysm lançaram versões de patch para resolver o problema. A implementação do cliente da versão de patch filtrará esses testemunhos obsoletos, ou seja, ignorará o testemunho quando as seguintes condições forem atendidas:
![Ethereum por que ficou fora do ar brevemente por duas noites seguidas? Uma análise das causas do evento])https://img-cdn.gateio.im/webp-social/moments-93dc511107c2b8ba99b85fe1c242b76b.webp(
Vantagens do design do Ethereum
Neste evento, o Ethereum manteve a disponibilidade, continuando a produzir blocos e a processar transações, apenas adiando a confirmação do Epoch. Isso deve-se principalmente a dois pontos:
) Diversidade de clientes Ethereum
Embora os clientes Teku e Prysm tenham apresentado problemas, isso não afeta o funcionamento normal de outros clientes da camada de consenso. Por exemplo, o cliente Lighthouse não foi afetado desta vez. Devido a diferenças no design de implementação entre os diferentes clientes, ainda há nós validadores a funcionar normalmente.
A diversidade dos clientes Ethereum garante que: mesmo que alguns clientes apresentem problemas ### e até levem a que a Epoch não possa ser confirmada (, isso não afetará a geração de blocos e o processamento de transações pelos clientes normais, garantindo a disponibilidade do Ethereum.
) O algoritmo de consenso Gasper para o design de usabilidade
Garantir a disponibilidade do Ethereum é um dos pontos de partida do design do algoritmo Gasper, que separa a produção de blocos da finalização. Assim, mesmo que a finalização do bloco seja obstruída, a produção de blocos não para. Considerando que na maioria dos casos a finalização do bloco acabará por se recuperar, o impacto real para os usuários é muito pequeno.
Em comparação, outros algoritmos de consenso BFT, quando a confirmação do bloco falha, os nós de consenso param de produzir o próximo bloco, levando a um período em que toda a blockchain está indisponível.
Além disso, o segundo evento também ativou o mecanismo de Inactivity Leak, que visa garantir que o Ethereum consiga revalidar blocos mesmo com um grande número de validadores offline por longos períodos em situações extremas ###.
Experiência e Revelações
( Desafios dos múltiplos clientes do Ethereum
A diversidade dos clientes de Ethereum ainda precisa ser promovida e divulgada. Se os clientes forem suficientemente diversos, de modo que a participação da Prysm e da Teku seja inferior a 1/3, então este evento nem ocorreria )2/3 clientes funcionando normalmente é suficiente para definir o Epoch ###.
Além disso, como os nós validadores podem mudar de forma segura para uma implementação de cliente normal quando uma implementação de cliente apresenta problemas é uma questão que também precisa ser resolvida. Este processo envolve:
( Monitorização do consenso do Ethereum
É necessário um serviço semelhante ao Safe Head para monitorar continuamente o estado em tempo real da rede PoS do Ethereum, detectando e alertando sobre esses eventos com antecedência, em vez de esperar até que o Epoch não possa ser finalizado como esperado para perceber que o estado da rede está anômalo.
) Ciência do algoritmo de consenso do Ethereum
Este evento expôs a necessidade de popularizar o mecanismo de consenso PoS do Ethereum. Muitos usuários pensaram erroneamente que "o Ethereum tinha caído", causando pânico desnecessário. Na verdade, a rede Ethereum continuou a gerar blocos e processar transações. A educação sobre blockchain voltada para os usuários continua a ser uma área em que os profissionais precisam se esforçar continuamente.
sobre as aplicações do Ethereum
Embora a rede Ethereum seja suficientemente robusta, a instabilidade ocasional pode ter um certo impacto nas aplicações. As aplicações precisam lidar corretamente com esses cenários de instabilidade:
Resumo
Este evento demonstrou a resiliência e a capacidade de auto-reparo do algoritmo de consenso PoS do Ethereum, bem como a rápida resposta e a capacidade de correção de erros das equipes de clientes. Para o ecossistema Ethereum, é necessário continuar a investir nas seguintes áreas: aumentar a diversidade de clientes, otimizar o monitoramento e o alerta em tempo real do estado da rede, aprofundar a educação dos usuários e melhorar os planos de emergência dos participantes do ecossistema em caso de anomalias na rede.
![Ethereum: por que teve quedas breves durante duas noites consecutivas? Uma análise das causas do evento]###https://img-cdn.gateio.im/webp-social/moments-b286aa6918497b555cf460e5c4e5f0cb.webp###