A ordem de tempo, slot e eventos na atestação do Ethereum
No dia 2 de abril, um participante malicioso explorou uma vulnerabilidade em uma plataforma de retransmissão para roubar 20 milhões de dólares. Nos dias seguintes, os desenvolvedores resolveram o problema lançando 5 patches, mas, combinados com a latência da rede existente e a política de validadores, causaram uma breve instabilidade na rede Ethereum no dia 6 de abril. A reorganização é prejudicial à saúde da rede, pois reduz a taxa de criação de blocos e diminui as garantias de liquidação.
Este artigo tem como objetivo explorar a interação entre certos protocolos e consensos, revelando as sutilezas do mecanismo de atestação do Ethereum e enumerando algumas possíveis direções futuras. Fomos inspirados pelos ataques sofridos pelos buscadores e por eventos de instabilidade temporária da rede.
A importância de um certo protocolo
Um determinado protocolo foi projetado pela comunidade, visando mitigar o impacto negativo do valor máximo extraível ( MEV ) na rede Ethereum.
Existem três papéis neste protocolo:
Relay - conecta o proponente ao leiloeiro de confiança do construtor de blocos.
Construtor - Constrói blocos para maximizar a complexidade do MEV para si mesmo e para o proponente.
Proponente - Validador de atestação do Ethereum.
A sequência aproximada de eventos de cada bloco é: o construtor cria o bloco e o submete ao relé; o relé valida a validade do bloco e calcula a taxa a ser paga ao proponente; o relé envia ao proponente do slot atual o cabeçalho de "assinatura cega" e o valor do pagamento; o proponente avalia todas as ofertas recebidas e assina o cabeçalho de assinatura cega relacionado ao maior pagamento; o proponente envia o cabeçalho assinado de volta ao relé; o relé publica o bloco usando o nó de sinal local e retorna ao proponente.
Este protocolo é uma infraestrutura chave, pois permite que todos os proponentes acessem o MEV de forma justa, sem a necessidade de estabelecer uma relação de confiança com construtores ou buscadores, contribuindo para a descentralização a longo prazo do Ethereum.
Regras de seleção de fork do Ethereum e algum protocolo
Antes de aprofundarmos nos ataques e nas respostas, vamos dar uma olhada no mecanismo de atestação do Ethereum ( PoS ) e nas suas regras de seleção de fork relacionadas. As regras de seleção de fork permitem que a rede chegue a um consenso sobre a cabeça da cadeia.
A regra de seleção de fork é uma função avaliada pelo cliente, que usa blocos e mensagens já vistos como entrada e produz a "cadeia oficial" como saída. A regra de seleção de fork é necessária porque pode haver várias cadeias válidas disponíveis para escolha.
Um aspecto pouco conhecido das regras de seleção de fork é a sua relação com o tempo, o que tem um impacto significativo na criação de blocos.
Ciclo de slots e subslots
No PoS do Ethereum, o tempo é dividido em slots de 12 segundos. O algoritmo PoS designa aleatoriamente um validador para propor um bloco nesse slot; esse validador é chamado de proponente. No mesmo slot, outros validadores são designados para votar em apoio ao bloco mais recente localizado na posição da cabeça da cadeia em suas visões locais, aplicando regras de seleção de fork. O intervalo de 12 segundos é dividido em três fases, cada fase com 4 segundos.
O momento mais crítico no slot é o prazo de certificação t=4. Se o validador de certificação não vir o bloco antes do prazo, votará na cabeça da cadeia anterior. Quanto mais cedo o bloco for proposto, mais tempo ele terá para se espalhar e acumular mais testemunhas.
Do ponto de vista da saúde da rede, o melhor tempo de criação de blocos é t=0. No entanto, como o valor do bloco aumenta com o tempo, os proponentes têm o incentivo de atrasar a publicação para acumular mais MEV.
Historicamente, mesmo após o prazo de certificação e até perto do fim do slot, os proponentes ainda podiam publicar blocos, desde que o próximo validador os observasse antes de construir o bloco do slot subsequente. Para promover o comportamento racional ( atrasar a publicação ) para o comportamento honesto ( publicar a tempo ) transformação, foi implementada a "reestruturação honesta".
Proposta de Elevação e Reestruturação Honesta
Dois novos conceitos foram introduzidos no cliente de consenso, que têm um impacto crucial na data limite de autenticação:
Aumento do proponente - Minimizar ataques de reequilíbrio de reorganização através da concessão ao proponente da escolha de "aumento" equivalente a 40% do peso de certificação completo. Este aumento dura apenas um slot.
Reorganização Honesta - Permite que o proponente melhore e use isso para forçar a reorganização de blocos com menos de 20% de peso de certificação. Isso é implementado em certos clientes. Essa alteração é opcional, pois é uma decisão local do proponente e não afeta o comportamento dos validadores.
Evitar a reestruturação honesta em certas situações especiais:
Durante o bloco de fronteira da era
Se a cadeia não estiver completa
Se a cabeça da cadeia não for obtida do intervalo de tempo anterior ao bloco de reorganização
A condição 3 garante que a reestruturação honesta remove apenas um único bloco da cadeia, servindo como um disjuntor para permitir que a cadeia continue a produzir blocos durante períodos de latência extrema na rede. Isso também reflete a diminuição da confiança do proponente em sua visão da rede.
Correção de nós de retransmissão e sinalizadores contra ataques de desassociação
Na ataque de 2 de abril, os proponentes exploraram uma vulnerabilidade do relay enviando cabeçalhos de assinatura inválidos para realizar o ataque. Nos dias seguintes, as equipas de desenvolvimento do relay e do núcleo lançaram vários patches para reduzir o risco de ataques repetidos. As principais mudanças são as seguintes:
Alteração do relé:
Verifique se a base de dados contém proponentes maliciosos conhecidos
Verifique se um bloco completo foi transmitido para a rede P2P durante esse período.
Introduzir um atraso aleatório antes de publicar o bloco
A alteração do nó da cadeia de beacon ( aplica-se apenas ao nó de beacon de retransmissão ):
Verificar a validade do bloco de sinal antes de o transmitir
Verifique se há equivalentes na rede antes de publicar o bloco
Essas mudanças levaram a uma instabilidade do consenso, e a maioria dos validadores agora utiliza estratégias de reagrupamento honesto, o que agrava ainda mais a situação.
Consequências inesperadas
Cada uma das 5 alterações mencionadas aumentou a latência no caminho quente de publicação de blocos de retransmissão, aumentando assim a probabilidade de os blocos de retransmissão ultrapassarem o prazo de certificação.
Antes da implementação dessas verificações, o tempo de chegada do cabeçalho da assinatura é significativamente mais tarde do que t=0(, como t=3), o que geralmente não apresenta problemas. O custo de retransmissão é muito baixo, portanto, o bloco será publicado antes de t=4.
No entanto, à medida que aumenta o atraso na introdução de patches, o retransmissor pode agora causar atrasos na difusão. Em alguns casos, o proponente envia cabeçalhos assinados tarde e a introdução de atrasos adicionais pelo retransmissor resulta em perder o prazo de certificação. Se não houver reestruturação honesta, esses blocos provavelmente entrarão na cadeia. Mas com reestruturação honesta, perder o prazo de certificação significa que o bloco será reorganizado pelo próximo proponente.
Portanto, nos dias após o ataque, o número de blocos de fork aumentou drasticamente. No pior cenário, 13 blocos ( foram reorganizados em uma hora, o que é cerca de 5 vezes mais do que o normal. Com o lançamento de várias mudanças de relé, o aumento acentuado no número de blocos de fork tornou-se evidente. Graças aos esforços da comunidade, muitas alterações foram revertidas e a rede recuperou um estado saudável.
A alteração mais útil atualmente é a verificação de equivalência antes da validação e transmissão de blocos pelos nós de beacon. Proponentes maliciosos não podem mais realizar ataques enviando cabeçalhos inválidos para o relé e garantindo que os nós de beacon do relé não vejam blocos equivalentes antes da publicação. No entanto, o relé ainda é vulnerável a ataques de equivalência mais gerais.
![Paradigma: discutir a relação entre MEV-Boost e o mecanismo de consenso do Ethereum])https://img-cdn.gateio.im/webp-social/moments-00fb5ee47056beb2efc3ca4ac271a69c.webp(
) Direção futura
Dado isso, a comunidade de pesquisa deve avaliar o que é um número de reestruturações "aceitável" e considerar os riscos associados a ataques de equivalência, para determinar se são necessárias medidas de mitigação.
Atualmente, estamos explorando ativamente várias direções futuras:
Implementar "headlock" para prevenir ataques de equivalência
Aumentar o programa de recompensas por vulnerabilidades para o software relacionado
Expandir o software de simulação para estudar o impacto do temporizador de sub-slot na estabilidade da rede
Otimizar o caminho de publicação de blocos no relay para reduzir a latência
Incorporar um determinado protocolo no cliente de consenso
Adicionar mais testes baseados em problemas de atraso e prazos de certificação
Incentivar a diversidade de clientes de retransmissão
Considerar ajustar medidas de penalização equivalentes
De uma forma geral, estamos entusiasmados com a energia reavivada em torno do MEV e do ecossistema relacionado. Através deste evento, aprendemos sobre a relação crucial entre a latência, determinados protocolos e mecanismos de consenso; esperamos que os protocolos possam continuar a se fortalecer.
![Paradigm: discutir a relação entre MEV-Boost e o mecanismo de consenso do Ethereum]###https://img-cdn.gateio.im/webp-social/moments-9db8f9a0944e1eff6bde4db0c8343fbe.webp(
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
20 gostos
Recompensa
20
6
Republicar
Partilhar
Comentar
0/400
NFTFreezer
· 08-17 04:05
eth foi atacado por um Hacker, e agora?
Ver originalResponder0
MevHunter
· 08-17 03:03
Já começou a dar-nos dor de cabeça novamente, não é?
Ver originalResponder0
Deconstructionist
· 08-14 17:13
Tô tonto, esse mecanismo de pos tá muito complicado.
Ver originalResponder0
GasWaster
· 08-14 17:08
acabei de gastar 5 eth em txs falhadas... pos já não é seguro, smh
Análise do mecanismo de consenso PoS do Ethereum: tempo, slots e ordenação de eventos
A ordem de tempo, slot e eventos na atestação do Ethereum
No dia 2 de abril, um participante malicioso explorou uma vulnerabilidade em uma plataforma de retransmissão para roubar 20 milhões de dólares. Nos dias seguintes, os desenvolvedores resolveram o problema lançando 5 patches, mas, combinados com a latência da rede existente e a política de validadores, causaram uma breve instabilidade na rede Ethereum no dia 6 de abril. A reorganização é prejudicial à saúde da rede, pois reduz a taxa de criação de blocos e diminui as garantias de liquidação.
Este artigo tem como objetivo explorar a interação entre certos protocolos e consensos, revelando as sutilezas do mecanismo de atestação do Ethereum e enumerando algumas possíveis direções futuras. Fomos inspirados pelos ataques sofridos pelos buscadores e por eventos de instabilidade temporária da rede.
A importância de um certo protocolo
Um determinado protocolo foi projetado pela comunidade, visando mitigar o impacto negativo do valor máximo extraível ( MEV ) na rede Ethereum.
Existem três papéis neste protocolo:
A sequência aproximada de eventos de cada bloco é: o construtor cria o bloco e o submete ao relé; o relé valida a validade do bloco e calcula a taxa a ser paga ao proponente; o relé envia ao proponente do slot atual o cabeçalho de "assinatura cega" e o valor do pagamento; o proponente avalia todas as ofertas recebidas e assina o cabeçalho de assinatura cega relacionado ao maior pagamento; o proponente envia o cabeçalho assinado de volta ao relé; o relé publica o bloco usando o nó de sinal local e retorna ao proponente.
Este protocolo é uma infraestrutura chave, pois permite que todos os proponentes acessem o MEV de forma justa, sem a necessidade de estabelecer uma relação de confiança com construtores ou buscadores, contribuindo para a descentralização a longo prazo do Ethereum.
Regras de seleção de fork do Ethereum e algum protocolo
Antes de aprofundarmos nos ataques e nas respostas, vamos dar uma olhada no mecanismo de atestação do Ethereum ( PoS ) e nas suas regras de seleção de fork relacionadas. As regras de seleção de fork permitem que a rede chegue a um consenso sobre a cabeça da cadeia.
A regra de seleção de fork é uma função avaliada pelo cliente, que usa blocos e mensagens já vistos como entrada e produz a "cadeia oficial" como saída. A regra de seleção de fork é necessária porque pode haver várias cadeias válidas disponíveis para escolha.
Um aspecto pouco conhecido das regras de seleção de fork é a sua relação com o tempo, o que tem um impacto significativo na criação de blocos.
Ciclo de slots e subslots
No PoS do Ethereum, o tempo é dividido em slots de 12 segundos. O algoritmo PoS designa aleatoriamente um validador para propor um bloco nesse slot; esse validador é chamado de proponente. No mesmo slot, outros validadores são designados para votar em apoio ao bloco mais recente localizado na posição da cabeça da cadeia em suas visões locais, aplicando regras de seleção de fork. O intervalo de 12 segundos é dividido em três fases, cada fase com 4 segundos.
O momento mais crítico no slot é o prazo de certificação t=4. Se o validador de certificação não vir o bloco antes do prazo, votará na cabeça da cadeia anterior. Quanto mais cedo o bloco for proposto, mais tempo ele terá para se espalhar e acumular mais testemunhas.
Do ponto de vista da saúde da rede, o melhor tempo de criação de blocos é t=0. No entanto, como o valor do bloco aumenta com o tempo, os proponentes têm o incentivo de atrasar a publicação para acumular mais MEV.
Historicamente, mesmo após o prazo de certificação e até perto do fim do slot, os proponentes ainda podiam publicar blocos, desde que o próximo validador os observasse antes de construir o bloco do slot subsequente. Para promover o comportamento racional ( atrasar a publicação ) para o comportamento honesto ( publicar a tempo ) transformação, foi implementada a "reestruturação honesta".
Proposta de Elevação e Reestruturação Honesta
Dois novos conceitos foram introduzidos no cliente de consenso, que têm um impacto crucial na data limite de autenticação:
Aumento do proponente - Minimizar ataques de reequilíbrio de reorganização através da concessão ao proponente da escolha de "aumento" equivalente a 40% do peso de certificação completo. Este aumento dura apenas um slot.
Reorganização Honesta - Permite que o proponente melhore e use isso para forçar a reorganização de blocos com menos de 20% de peso de certificação. Isso é implementado em certos clientes. Essa alteração é opcional, pois é uma decisão local do proponente e não afeta o comportamento dos validadores.
Evitar a reestruturação honesta em certas situações especiais:
A condição 3 garante que a reestruturação honesta remove apenas um único bloco da cadeia, servindo como um disjuntor para permitir que a cadeia continue a produzir blocos durante períodos de latência extrema na rede. Isso também reflete a diminuição da confiança do proponente em sua visão da rede.
Correção de nós de retransmissão e sinalizadores contra ataques de desassociação
Na ataque de 2 de abril, os proponentes exploraram uma vulnerabilidade do relay enviando cabeçalhos de assinatura inválidos para realizar o ataque. Nos dias seguintes, as equipas de desenvolvimento do relay e do núcleo lançaram vários patches para reduzir o risco de ataques repetidos. As principais mudanças são as seguintes:
Essas mudanças levaram a uma instabilidade do consenso, e a maioria dos validadores agora utiliza estratégias de reagrupamento honesto, o que agrava ainda mais a situação.
Consequências inesperadas
Cada uma das 5 alterações mencionadas aumentou a latência no caminho quente de publicação de blocos de retransmissão, aumentando assim a probabilidade de os blocos de retransmissão ultrapassarem o prazo de certificação.
Antes da implementação dessas verificações, o tempo de chegada do cabeçalho da assinatura é significativamente mais tarde do que t=0(, como t=3), o que geralmente não apresenta problemas. O custo de retransmissão é muito baixo, portanto, o bloco será publicado antes de t=4.
No entanto, à medida que aumenta o atraso na introdução de patches, o retransmissor pode agora causar atrasos na difusão. Em alguns casos, o proponente envia cabeçalhos assinados tarde e a introdução de atrasos adicionais pelo retransmissor resulta em perder o prazo de certificação. Se não houver reestruturação honesta, esses blocos provavelmente entrarão na cadeia. Mas com reestruturação honesta, perder o prazo de certificação significa que o bloco será reorganizado pelo próximo proponente.
Portanto, nos dias após o ataque, o número de blocos de fork aumentou drasticamente. No pior cenário, 13 blocos ( foram reorganizados em uma hora, o que é cerca de 5 vezes mais do que o normal. Com o lançamento de várias mudanças de relé, o aumento acentuado no número de blocos de fork tornou-se evidente. Graças aos esforços da comunidade, muitas alterações foram revertidas e a rede recuperou um estado saudável.
A alteração mais útil atualmente é a verificação de equivalência antes da validação e transmissão de blocos pelos nós de beacon. Proponentes maliciosos não podem mais realizar ataques enviando cabeçalhos inválidos para o relé e garantindo que os nós de beacon do relé não vejam blocos equivalentes antes da publicação. No entanto, o relé ainda é vulnerável a ataques de equivalência mais gerais.
![Paradigma: discutir a relação entre MEV-Boost e o mecanismo de consenso do Ethereum])https://img-cdn.gateio.im/webp-social/moments-00fb5ee47056beb2efc3ca4ac271a69c.webp(
) Direção futura
Dado isso, a comunidade de pesquisa deve avaliar o que é um número de reestruturações "aceitável" e considerar os riscos associados a ataques de equivalência, para determinar se são necessárias medidas de mitigação.
Atualmente, estamos explorando ativamente várias direções futuras:
De uma forma geral, estamos entusiasmados com a energia reavivada em torno do MEV e do ecossistema relacionado. Através deste evento, aprendemos sobre a relação crucial entre a latência, determinados protocolos e mecanismos de consenso; esperamos que os protocolos possam continuar a se fortalecer.
![Paradigm: discutir a relação entre MEV-Boost e o mecanismo de consenso do Ethereum]###https://img-cdn.gateio.im/webp-social/moments-9db8f9a0944e1eff6bde4db0c8343fbe.webp(