Tempo, slots e ordenação de eventos no atestação do Ethereum
No dia 2 de abril, um participante mal-intencionado da rede Ethereum explorou uma vulnerabilidade do mev-boost-relay para roubar 20 milhões de dólares de um pesquisador MEV. Os desenvolvedores subsequentemente lançaram cinco patches para corrigir essa vulnerabilidade, mas a interação com a latência da rede existente e as estratégias dos validadores levou a uma breve instabilidade na rede Ethereum no dia 6 de abril. A reorganização da rede reduz a taxa de produção de blocos e as garantias de liquidação, o que é prejudicial para a saúde da rede.
Este artigo tem como objetivo explorar a interação entre mev-boost e os mecanismos de consenso, revelar as sutilezas da atestação do Ethereum e discutir algumas possíveis direções de melhoria. A nossa inspiração vem de dois eventos: atacantes que afetam os buscadores e a instabilidade temporária da rede.
O papel do mev-boost
mev-boost é um protocolo destinado a mitigar o impacto negativo do Valor Máximo Extraível (MEV) na rede Ethereum.
Existem três papéis no mev-boost:
Relay - conecta o proponente a um intermediário confiável do construtor de blocos.
Construtor - Constrói blocos para maximizar a MEV complexa de si mesmo e do proponente.
Proponente - Validador de atestação do Ethereum.
A ordem aproximada dos eventos de cada bloco é:
Os construtores recebem blocos de criação de transações de usuários, buscadores ou outras fontes.
Os construtores submetem blocos ao retransmissor.
Validar a validade dos blocos de retransmissão e calcular as taxas a pagar aos proponentes.
O relé envia ao proponente do slot atual o cabeçalho do bloco "ofuscado" e o montante a ser pago.
O proponente avalia todas as ofertas recebidas e assina o cabeçalho do bloco ofuscado correspondente ao maior pagamento.
O proponente devolverá o cabeçalho do bloco assinado ao relé.
O relay publica blocos através de nós de beacon locais e os devolve ao proponente. Através das transações dentro do bloco e das recompensas do bloco, os construtores e os proponentes recebem recompensas.
O relay, como um terceiro confiável, promove a troca justa do espaço de bloco entre os proponentes e a ordenação de transações para a extração de MEV pelos construtores. O relay protege os construtores contra o roubo de MEV, e também protege os proponentes na verificação da validade dos blocos, no processamento de grandes volumes de blocos e na garantia de pagamentos precisos.
mev-boost é uma infraestrutura chave, pois permite que todos os proponentes obtenham MEV de forma justa sem a necessidade de estabelecer relações de confiança, ajudando na descentralização a longo prazo do Ethereum.
Regras de seleção de fork do Ethereum e mev-boost
Antes de aprofundarmos na discussão sobre ataques e respostas, vamos primeiro entender o mecanismo de atestação do Ethereum ( PoS ) e suas regras de seleção de fork. As regras de seleção de fork permitem que a rede chegue a um consenso sobre a cabeça da cadeia.
As regras de seleção de fork são funções avaliadas pelo cliente que usam blocos conhecidos e outras mensagens como entrada, e produzem como saída qual é a "cadeia padrão". A necessidade de regras de seleção de fork surge porque pode haver várias cadeias válidas disponíveis para escolha.
As regras de seleção de forks e sua relação com o tempo são pouco conhecidas, mas têm um impacto significativo na produção de blocos.
Ciclo de slots e subslots
Em Ethereum PoS, o tempo é dividido em slots de 12 segundos. O algoritmo PoS designa aleatoriamente um validador para propor o bloco do slot, e esse validador é chamado de proponente. No mesmo slot, outros validadores são designados para votar no bloco mais recente na posição do cabeçalho da cadeia em suas visões locais, aplicando regras de seleção de fork. O intervalo de 12 segundos é dividido em três fases de 4 segundos.
Os eventos no slot são os seguintes, t=0 indica o início do slot:
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á no cabeçalho previamente confirmado na cadeia. Quanto mais cedo a proposta do bloco, mais longo será o tempo de propagação e mais testemunhos acumulados haverá.
Do ponto de vista da saúde da rede, o melhor momento para a publicação de blocos é t=0. No entanto, como o valor dos blocos aumenta monotonicamente com o tempo, os proponentes têm o incentivo de atrasar a publicação para acumular mais MEV.
Na história, mesmo após o prazo de certificação, ou mesmo perto do final do slot, desde que o próximo validador observe o bloco antes de construir o bloco do slot subsequente, o proponente ainda pode publicar o bloco. Para promover comportamentos racionais ( atrasar a publicação do bloco ) em direção a comportamentos honestos ( publicar pontualmente ) desenvolvimento, a "reorganização honesta" foi introduzida.
Proposta de melhoria e reestruturação honesta
Dois novos conceitos foram introduzidos no cliente de consenso, tendo um impacto importante no prazo de certificação.
Aumento do proponente - Tentativa de minimizar ataques de reorganização de equilíbrio, oferecendo ao proponente uma "elevação" equivalente a 40% do peso de certificação completa na escolha de bifurcação. Este aumento dura apenas um slot.
Reorganização honesta - Adoção de proponentes de elevação, permitindo que proponentes honestos usem isso para forçar a reorganização de blocos com um peso de certificação inferior a 20%. Isso é implementado em alguns clientes. Esta alteração é opcional, pois é uma decisão local do proponente e não afeta o comportamento dos validadores.
Evitar reestruturações honestas em certas circunstâncias especiais:
Durante o período do bloco de fronteira da era
Se a cadeia não estiver concluída
Se o cabeçalho da cadeia não for obtido do slot anterior ao bloco de reorganização
Condição 3 Certifique-se de que a reorganização honesta remove apenas um único bloco da cadeia, servindo como um disjuntor para permitir que a cadeia continue a gerar blocos em caso de atrasos extremos na rede.
Correção de nós de retransmissão e de sinalização contra ataques de desvinculação
No ataque de desvinculação de 2 de abril, o proponente aproveitou uma vulnerabilidade do relé para enviar cabeçalhos de assinatura inválidos para realizar o ataque. Nos dias seguintes, a equipe de desenvolvimento do relé e do núcleo lançou vários patches de software para mitigar o risco de ataques repetidos. As cinco principais mudanças são as seguintes:
Alteração de retransmissão:
Verifique se existem proponentes maliciosos conhecidos na base de dados.
Verifique se o bloco completo foi transmitido para a rede P2P durante este período.
Introduzir um atraso aleatório uniforme na faixa de 0-500ms antes da publicação do bloco.
A alteração do nó da cadeia de beacon ( aplica-se apenas ao nó da cadeia de beacon de retransmissão ):
Verifique a validade do bloco de sinal de transmissão antes de o validar.
Verifique se há equivalentes na rede antes de publicar o bloco.
Essas combinações de mudanças levaram a uma instabilidade no consenso, enquanto a maioria dos validadores adotou uma estratégia de reagrupamento honesta, o que agravou ainda mais essa situação.
Consequências inesperadas
Cada uma das 5 alterações mencionadas aumentará o atraso no caminho quente de publicação de blocos intermediários, aumentando assim a probabilidade de que os blocos intermediários sejam transmitidos após o prazo de certificação.
Antes de realizar essas verificações, o cabeçalho da assinatura normalmente chegará em torno de t=3 sem problemas. O custo de retransmissão é muito baixo, e um bloco pode ser publicado antes de t=4.
No entanto, à medida que o atraso na introdução dos cinco patches aumenta, o relay pode ser parcialmente responsável pelo atraso na difusão. Em alguns casos, o proponente envia o cabeçalho assinado mais tarde, juntamente com o relay introduzindo um atraso adicional, o que pode resultar em perder o prazo de certificação. Sem reestruturação honesta, esses blocos provavelmente entrarão na cadeia. Mas com reestruturação honesta, perder o prazo de certificação significa que esse bloco será reestruturado pelo próximo proponente.
Portanto, nos dias após o ataque, o número de blocos bifurcados aumentou drasticamente. No pior cenário, 13 blocos ( foram reorganizados em uma hora, cerca de 5 vezes mais do que o normal. Com o lançamento de várias mudanças pelo relay, o aumento repentino no número de blocos bifurcados tornou-se evidente. Graças aos esforços da comunidade, muitas mudanças foram revertidas e a rede recuperou um estado saudável.
Atualmente, a alteração mais útil é a verificação de equivalência antes da validação e difusão de blocos pelos nós de beacon. Proponentes maliciosos não podem mais realizar ataques enviando cabeçalhos inválidos ao relay e garantindo que os nós de beacon do relay não vejam blocos equivalentes antes da publicação. No entanto, o relay ainda é vulnerável a ataques de equivalência mais gerais.
![Paradigm：Explorar 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
A comunidade de pesquisa deve avaliar o número de reestruturações "aceitáveis", considerando os riscos gerais trazidos por ataques equivalentes, para determinar se são necessárias medidas de mitigação.
Vários direções que estão sendo ativamente exploradas:
Implementar a proteção "headlock" para que o mev-boost esteja protegido contra ataques equivalentes. Isso requer mudanças no software do cliente de consenso e pode necessitar de uma extensão do prazo de certificação.
Aumentar o programa de recompensas por vulnerabilidades do software mev-boost.
Exploração do impacto do software de simulação expandida sobre a temporização dos subslots na estabilidade da rede.
Otimizar o caminho de publicação de blocos de retransmissão para reduzir atrasos desnecessários.
Incorporar o mev-boost no cliente de consenso, ou seja, enshrined-PBS###ePBS(.
Adicionar testes com base em questões de atraso e prazos de autenticação.
Incentivar a diversidade de clientes de retransmissão.
Considere ajustar as medidas de penalização equivalentes.
No geral, estamos entusiasmados com a nova vitalidade do ecossistema MEV e mev-boost. Através da desvinculação de ataques e medidas de mitigação, compreendemos a relação crítica entre latência, mev-boost e mecanismos de consenso; esperamos que o protocolo possa ser continuamente fortalecido.
![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údo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
14 Curtidas
Recompensa
14
6
Repostar
Compartilhar
Comentário
0/400
GasFeePhobia
· 08-13 08:57
Ah? 2000w foi assim que se perdeu?
Ver originalResponder0
GlueGuy
· 08-13 08:55
Bom Deus, 20 milhões de dólares desapareceram assim.
Ver originalResponder0
HalfBuddhaMoney
· 08-13 08:54
Eu sou um mestre em tirar proveito, então vou tirar uma parte. Mas sinto que estou a perder um pouco.
Ver originalResponder0
MetaverseVagabond
· 08-13 08:46
Fui surpreendido ao ser roubado de 20 milhões, uma tragédia total.
Ver originalResponder0
BrokenDAO
· 08-13 08:42
Mais um caso que prova que os atacantes são sempre mais inteligentes que os defensores... o design de mecanismos é difícil
A ordem temporal e de eventos na atestação do Ethereum: a interação sutil entre mev-boost e o mecanismo de consenso
Tempo, slots e ordenação de eventos no atestação do Ethereum
No dia 2 de abril, um participante mal-intencionado da rede Ethereum explorou uma vulnerabilidade do mev-boost-relay para roubar 20 milhões de dólares de um pesquisador MEV. Os desenvolvedores subsequentemente lançaram cinco patches para corrigir essa vulnerabilidade, mas a interação com a latência da rede existente e as estratégias dos validadores levou a uma breve instabilidade na rede Ethereum no dia 6 de abril. A reorganização da rede reduz a taxa de produção de blocos e as garantias de liquidação, o que é prejudicial para a saúde da rede.
Este artigo tem como objetivo explorar a interação entre mev-boost e os mecanismos de consenso, revelar as sutilezas da atestação do Ethereum e discutir algumas possíveis direções de melhoria. A nossa inspiração vem de dois eventos: atacantes que afetam os buscadores e a instabilidade temporária da rede.
O papel do mev-boost
mev-boost é um protocolo destinado a mitigar o impacto negativo do Valor Máximo Extraível (MEV) na rede Ethereum.
Existem três papéis no mev-boost:
A ordem aproximada dos eventos de cada bloco é:
Os construtores recebem blocos de criação de transações de usuários, buscadores ou outras fontes.
Os construtores submetem blocos ao retransmissor.
Validar a validade dos blocos de retransmissão e calcular as taxas a pagar aos proponentes.
O relé envia ao proponente do slot atual o cabeçalho do bloco "ofuscado" e o montante a ser pago.
O proponente avalia todas as ofertas recebidas e assina o cabeçalho do bloco ofuscado correspondente ao maior pagamento.
O proponente devolverá o cabeçalho do bloco assinado ao relé.
O relay publica blocos através de nós de beacon locais e os devolve ao proponente. Através das transações dentro do bloco e das recompensas do bloco, os construtores e os proponentes recebem recompensas.
O relay, como um terceiro confiável, promove a troca justa do espaço de bloco entre os proponentes e a ordenação de transações para a extração de MEV pelos construtores. O relay protege os construtores contra o roubo de MEV, e também protege os proponentes na verificação da validade dos blocos, no processamento de grandes volumes de blocos e na garantia de pagamentos precisos.
mev-boost é uma infraestrutura chave, pois permite que todos os proponentes obtenham MEV de forma justa sem a necessidade de estabelecer relações de confiança, ajudando na descentralização a longo prazo do Ethereum.
Regras de seleção de fork do Ethereum e mev-boost
Antes de aprofundarmos na discussão sobre ataques e respostas, vamos primeiro entender o mecanismo de atestação do Ethereum ( PoS ) e suas regras de seleção de fork. As regras de seleção de fork permitem que a rede chegue a um consenso sobre a cabeça da cadeia.
As regras de seleção de fork são funções avaliadas pelo cliente que usam blocos conhecidos e outras mensagens como entrada, e produzem como saída qual é a "cadeia padrão". A necessidade de regras de seleção de fork surge porque pode haver várias cadeias válidas disponíveis para escolha.
As regras de seleção de forks e sua relação com o tempo são pouco conhecidas, mas têm um impacto significativo na produção de blocos.
Ciclo de slots e subslots
Em Ethereum PoS, o tempo é dividido em slots de 12 segundos. O algoritmo PoS designa aleatoriamente um validador para propor o bloco do slot, e esse validador é chamado de proponente. No mesmo slot, outros validadores são designados para votar no bloco mais recente na posição do cabeçalho da cadeia em suas visões locais, aplicando regras de seleção de fork. O intervalo de 12 segundos é dividido em três fases de 4 segundos.
Os eventos no slot são os seguintes, t=0 indica o início do slot:
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á no cabeçalho previamente confirmado na cadeia. Quanto mais cedo a proposta do bloco, mais longo será o tempo de propagação e mais testemunhos acumulados haverá.
Do ponto de vista da saúde da rede, o melhor momento para a publicação de blocos é t=0. No entanto, como o valor dos blocos aumenta monotonicamente com o tempo, os proponentes têm o incentivo de atrasar a publicação para acumular mais MEV.
Na história, mesmo após o prazo de certificação, ou mesmo perto do final do slot, desde que o próximo validador observe o bloco antes de construir o bloco do slot subsequente, o proponente ainda pode publicar o bloco. Para promover comportamentos racionais ( atrasar a publicação do bloco ) em direção a comportamentos honestos ( publicar pontualmente ) desenvolvimento, a "reorganização honesta" foi introduzida.
Proposta de melhoria e reestruturação honesta
Dois novos conceitos foram introduzidos no cliente de consenso, tendo um impacto importante no prazo de certificação.
Aumento do proponente - Tentativa de minimizar ataques de reorganização de equilíbrio, oferecendo ao proponente uma "elevação" equivalente a 40% do peso de certificação completa na escolha de bifurcação. Este aumento dura apenas um slot.
Reorganização honesta - Adoção de proponentes de elevação, permitindo que proponentes honestos usem isso para forçar a reorganização de blocos com um peso de certificação inferior a 20%. Isso é implementado em alguns clientes. Esta alteração é opcional, pois é uma decisão local do proponente e não afeta o comportamento dos validadores.
Evitar reestruturações honestas em certas circunstâncias especiais:
Condição 3 Certifique-se de que a reorganização honesta remove apenas um único bloco da cadeia, servindo como um disjuntor para permitir que a cadeia continue a gerar blocos em caso de atrasos extremos na rede.
Correção de nós de retransmissão e de sinalização contra ataques de desvinculação
No ataque de desvinculação de 2 de abril, o proponente aproveitou uma vulnerabilidade do relé para enviar cabeçalhos de assinatura inválidos para realizar o ataque. Nos dias seguintes, a equipe de desenvolvimento do relé e do núcleo lançou vários patches de software para mitigar o risco de ataques repetidos. As cinco principais mudanças são as seguintes:
Verifique se existem proponentes maliciosos conhecidos na base de dados.
Verifique se o bloco completo foi transmitido para a rede P2P durante este período.
Introduzir um atraso aleatório uniforme na faixa de 0-500ms antes da publicação do bloco.
Verifique a validade do bloco de sinal de transmissão antes de o validar.
Verifique se há equivalentes na rede antes de publicar o bloco.
Essas combinações de mudanças levaram a uma instabilidade no consenso, enquanto a maioria dos validadores adotou uma estratégia de reagrupamento honesta, o que agravou ainda mais essa situação.
Consequências inesperadas
Cada uma das 5 alterações mencionadas aumentará o atraso no caminho quente de publicação de blocos intermediários, aumentando assim a probabilidade de que os blocos intermediários sejam transmitidos após o prazo de certificação.
Antes de realizar essas verificações, o cabeçalho da assinatura normalmente chegará em torno de t=3 sem problemas. O custo de retransmissão é muito baixo, e um bloco pode ser publicado antes de t=4.
No entanto, à medida que o atraso na introdução dos cinco patches aumenta, o relay pode ser parcialmente responsável pelo atraso na difusão. Em alguns casos, o proponente envia o cabeçalho assinado mais tarde, juntamente com o relay introduzindo um atraso adicional, o que pode resultar em perder o prazo de certificação. Sem reestruturação honesta, esses blocos provavelmente entrarão na cadeia. Mas com reestruturação honesta, perder o prazo de certificação significa que esse bloco será reestruturado pelo próximo proponente.
Portanto, nos dias após o ataque, o número de blocos bifurcados aumentou drasticamente. No pior cenário, 13 blocos ( foram reorganizados em uma hora, cerca de 5 vezes mais do que o normal. Com o lançamento de várias mudanças pelo relay, o aumento repentino no número de blocos bifurcados tornou-se evidente. Graças aos esforços da comunidade, muitas mudanças foram revertidas e a rede recuperou um estado saudável.
Atualmente, a alteração mais útil é a verificação de equivalência antes da validação e difusão de blocos pelos nós de beacon. Proponentes maliciosos não podem mais realizar ataques enviando cabeçalhos inválidos ao relay e garantindo que os nós de beacon do relay não vejam blocos equivalentes antes da publicação. No entanto, o relay ainda é vulnerável a ataques de equivalência mais gerais.
![Paradigm：Explorar 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
A comunidade de pesquisa deve avaliar o número de reestruturações "aceitáveis", considerando os riscos gerais trazidos por ataques equivalentes, para determinar se são necessárias medidas de mitigação.
Vários direções que estão sendo ativamente exploradas:
Implementar a proteção "headlock" para que o mev-boost esteja protegido contra ataques equivalentes. Isso requer mudanças no software do cliente de consenso e pode necessitar de uma extensão do prazo de certificação.
Aumentar o programa de recompensas por vulnerabilidades do software mev-boost.
Exploração do impacto do software de simulação expandida sobre a temporização dos subslots na estabilidade da rede.
Otimizar o caminho de publicação de blocos de retransmissão para reduzir atrasos desnecessários.
Incorporar o mev-boost no cliente de consenso, ou seja, enshrined-PBS###ePBS(.
Adicionar testes com base em questões de atraso e prazos de autenticação.
Incentivar a diversidade de clientes de retransmissão.
Considere ajustar as medidas de penalização equivalentes.
No geral, estamos entusiasmados com a nova vitalidade do ecossistema MEV e mev-boost. Através da desvinculação de ataques e medidas de mitigação, compreendemos a relação crítica entre latência, mev-boost e mecanismos de consenso; esperamos que o protocolo possa ser continuamente fortalecido.
![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(