Em 2 de abril, atores maliciosos da rede Ethereum exploraram uma vulnerabilidade no relé MEV-Boost para roubar US$ 20 milhões de um buscador de MEV (consulte o relatório do Flashbots). Nos dias seguintes, os desenvolvedores resolveram a vulnerabilidade lançando cinco patches. Esses patches, combinados com atrasos na rede e políticas do validador, causaram uma breve flutuação na rede Ethereum em 6 de abril. A reorganização de blocos pode prejudicar a integridade da rede, pois diminui a taxa de produção de blocos e reduz as garantias de liquidação.
Neste post, com os Seekers sob ataque e a rede temporariamente instável, exploramos a interação entre o MEV-Boost e o consenso, analisamos as sutilezas do mecanismo de proof-of-stake do Ethereum e listamos alguns possíveis passos a seguir.
MEV-Boost e por que é importante
MEV-Boost é um protocolo desenvolvido por Flashbots e pela comunidade para mitigar o impacto negativo do Maximum Extractable Value (MEV) na rede Ethereum.
Existem 3 atores no MEV-Boost:
Relay - Leiloeiros que confiam uns nos outros, conectando produtores de blocos e construtores de blocos
Construtores - entidades complexas que constroem blocos para maximizar o MEV para si e para os criadores do bloco
Produtores de blocos - verificadores de proof-of-stake da Ethereum
A sequência aproximada de eventos para cada bloco é:
Os construtores criam um bloco recebendo transações de usuários, pesquisadores ou outros fluxos de pedidos (privados ou públicos)
O construtor envia o bloco ao relé
O relé verifica a validade do bloco e calcula o valor que paga ao produtor do bloco
O retransmissor envia um título em branco e um valor de pagamento para o produtor do bloco do slot atual
Os produtores de bloco avaliam todos os lances que receberam e assinam o cabeçalho em branco associado ao pagamento mais alto
O produtor do bloco envia este cabeçalho assinado de volta ao relé
Os relés publicam blocos usando seus nós beacon nativos e os devolvem ao doador de blocos. As recompensas são distribuídas aos construtores e proponentes por meio de transações dentro de blocos e recompensas de bloco.
Um retransmissor é um terceiro confiável que facilita uma troca justa de espaço de bloco por produtores de bloco e ordenação de transações por construtores para extração de MEV. Os relés protegem os construtores protegendo os construtores do roubo de MEV, evitando que os produtores de blocos copiem as transações do construtor para retirar o MEV sem distribuí-lo aos buscadores/construtores que o encontraram. Os relés protegem os produtores de blocos confirmando a validade de seus blocos, processando centenas de blocos por slot em seu nome e garantindo a precisão dos pagamentos dos produtores de blocos.
O MEV-Boost é a principal infraestrutura de protocolo, pois permite que todos os produtores de blocos acessem democraticamente o MEV sem exigir uma relação de confiança com construtores ou buscadores, o que contribui para a descentralização de longo prazo do Ethereum.
Regras de seleção de fork do Ethereum e MEV-Boost
Antes de discutir o ataque e a resposta, vamos dar uma olhada no mecanismo de proof-of-stake do Ethereum e nas regras de seleção de fork relacionadas. A regra de escolha da bifurcação permite que a rede chegue a um consenso sobre a cabeça da cadeia, conforme definido no artigo "Reorganização pós-fusão da Ethereum":
"A regra de escolha da bifurcação é uma função avaliada pelo cliente, que recebe como entrada os blocos vistos e outras informações e gera a "cadeia canônica" para o cliente. A regra de escolha da bifurcação é importante porque pode haver várias cadeias válidas para escolher (por exemplo, se dois blocos concorrentes com o mesmo bloco pai forem publicados ao mesmo tempo). "
As regras de seleção de bifurcação também dependem do tempo, o que tem um impacto significativo na geração de blocos.
ciclo de slot e sub-slot
No mecanismo de proof-of-stake da Ethereum, o tempo é dividido em slots a cada 12 segundos. O algoritmo proof-of-stake atribui aleatoriamente a um validador uma licença para propor um bloco dentro desse slot; esse validador é chamado de produtor de bloco. Dentro do mesmo slot, outros validadores recebem a tarefa de validar (votar) para o chain-head aplicando as regras de escolha do fork de acordo com suas visões locais. Este slot de 12 segundos é subdividido em três fases, cada uma custando 4 segundos.
Os eventos que ocorrem no slot são os seguintes, onde t=0 indica o início do slot.
Durante o slot, o momento mais crítico é o deadline de autenticação em t=4. Se os validadores de atestado não virem o bloco dentro do prazo de atestado, eles votarão no cabeçalho da cadeia previamente aceito (de acordo com a regra de escolha da bifurcação). Quanto mais cedo um bloco for proposto, mais tempo ele terá para se propagar e, assim, acumular mais aprovações (porque mais validadores o veem antes do prazo de aprovação).
Do ponto de vista da integridade da rede, o tempo ideal para a liberação de um bloco é t=0 (de acordo com a especificação). No entanto, como o valor do bloco aumenta monotonicamente ao longo do tempo, os produtores de blocos têm um incentivo para atrasar a liberação de seus blocos para que mais MEV possam ser acumulados. Consulte Cronometrar jogos em Proof-of-Stake e esta discussão para obter detalhes.
Anteriormente, um produtor de bloco poderia publicar um bloco após o prazo de certificação (mesmo próximo ao final do slot), desde que o próximo validador observasse o bloco antes de construir o bloco para seu slot subsequente. Isso ocorre porque o bloco filho herda o peso do bloco pai e a regra de seleção da bifurcação termina no nó folha. Portanto, adiar a liberação do bloco não tem efeitos colaterais. Para ajudar a mudar o comportamento racional (adiar lançamentos de blocos) para um comportamento honesto (publicar no prazo), uma "reorganização honesta" foi implementada.
Mecanismo de Recompensa do Produtor de Bloqueio e Reorganização Honesta
Dois novos conceitos são introduzidos no cliente de consenso que têm um impacto crítico no prazo de autenticação.
Mecanismo de Recompensa do Produtor de Bloco - Visa minimizar os ataques de reequilíbrio concedendo aos produtores de bloco uma "recompensa" de seleção de bifurcação igual a 40% do peso total da autenticação. É importante ressaltar que essa recompensa dura apenas o slot inteiro.
Reorganização honesta - aproveite a aceleração do produtor de blocos, permitindo que produtores de blocos honestos forcem a reorganização de blocos com pesos de autenticação abaixo de 20%. Isso já está implementado no Lighthouse e no Prysm (começando com a versão v4.0 - Capella). Essa alteração é opcional porque é uma decisão dos produtores de blocos e não afeta o comportamento dos validadores autenticadores. Portanto, não o aplicamos a todos os clientes ao mesmo tempo, nem está vinculado a nenhum hard fork específico.
Deve-se notar que a reorganização honesta é evitada em alguns casos especiais:
Durante os blocos de limite de época
Se a cadeia não for finalizada
Se a cabeça da cadeia não for a cabeça do slot antes da reorganização
O caso 3 garante que reorganizações honestas removam apenas um bloco da cadeia, que atua como um disjuntor, permitindo que a cadeia continue produzindo blocos durante períodos de extrema latência da rede. Também reflete que os proponentes têm menos confiança na percepção da rede, pois não podem ter certeza se seus blocos aprimorados propostos serão considerados a norma.
A figura abaixo mostra como o comportamento honesto pode ser mudado para implementar uma estratégia de reestruturação.
Nesse caso, deixe b1 representar um bloco tardio. Devido ao atraso, b1 tem apenas 19% do peso de prova do enésimo slot. Os 81% restantes do peso da prova são atribuídos ao bloco pai HEAD porque muitos provadores não viram b1 antes do prazo final da prova.
Se não houver uma reorganização honesta, o proponente do slot n+1 considerará b1 como cabeça da cadeia e construirá o sub-bloco b2. O proponente não fez nenhum esforço para reorganizar b1, embora tenha apenas 19% de peso de prova. No slot n+1, b2 tem o aprimoramento do proponente, supondo que seja entregue no prazo, b2 se tornará a norma acumulando a maioria das provas para aquele slot.
Com a Honest Reorganization, as coisas são muito diferentes. Agora, o proponente do slot n+1 vê que 19% dos pesos de prova de b1 estão abaixo do limite de reorganização, então eles constroem um bloco com HEAD como pai e forçam b1 a se reorganizar. Quando atingirmos o prazo de prova para o slot n+1, o provador honesto comparará os pesos relativos de b1 (19%) a b2 (40% do impulso do proponente). Todos os clientes implementam o aprimoramento do proponente, portanto b2 será considerado o chefe da cadeia e acumulará provas para o slot n+1.
Relay and Beacon node correções para desagregar ataques
No ataque de desagregação em 2 de abril, o proponente explorou uma vulnerabilidade de retransmissão para enviar um cabeçalho de assinatura inválido para a retransmissão. Nos dias seguintes, as equipes de retransmissão e desenvolvimento principal lançaram vários patches de software para mitigar o risco de ataques repetidos. As cinco principais mudanças são as seguintes:
Mudanças no Relay: verifique o banco de dados em busca de proponentes mal-intencionados conhecidos (usados na produção apenas pelo Ultrasonic Relay e foram removidos). Verifica se o relé entregou o bloco completo para um slot na rede P2P. Introduz um atraso aleatório uniforme na faixa de 0-500 ms antes de um bloco ser publicado (removido de todos os relés).
Alteração do nó beacon (somente nós beacon de retransmissão): Valide os blocos beacon antes da transmissão. Verifique a rede em busca de falsas confirmações antes de publicar um bloco. A combinação dessas mudanças levou à instabilidade do consenso, um problema exacerbado pelo fato de que a maioria dos validadores agora usa a estratégia de reorganização honesta descrita acima.
CONSEQUÊNCIAS NÃO-INTENCIONAIS
As cinco mudanças acima introduzem atrasos no hot path da emissão do bloco de retransmissão, o que aumenta a probabilidade de que os blocos de retransmissão sejam transmitidos após o prazo de confirmação. O diagrama abaixo mostra a sequência dessas cinco verificações e como o atraso introduzido faz com que a publicação do bloco ultrapasse o prazo de confirmação.
Um grande número de cabeçalhos assinados com um atraso de t = 0 (por exemplo, t = 3) geralmente não causa problemas até que essas verificações sejam implementadas. Como o relé tem um overhead muito baixo, ele publicará o bloco antes de t = 4 sem aguardar o prazo de confirmação.
No entanto, devido à introdução atrasada desses cinco patches, o retransmissor pode agora ser parcialmente responsável pela transmissão atrasada. Vejamos o hipotético processo de publicação de blocos abaixo.
O relé recebe o cabeçalho assinado do produtor do bloco em t = 3. Por t = 4, o relé ainda está realizando verificações, portanto o broadcast ocorrerá após o prazo de confirmação. Nesse caso, a combinação do cabeçalho assinado com atraso enviado pelo produtor do bloco e algum atraso adicional introduzido pelo retransmissor causou a falha na transmissão antes do prazo de confirmação. Se não tivesse havido uma reorganização honesta, esses blocos provavelmente teriam entrado na cadeia. Conforme mostrado na Figura 2, os produtores de blocos honestos do próximo slot não se reorganizarão deliberadamente porque esses blocos estão atrasados. No entanto, se o prazo de confirmação for perdido, os blocos serão reorganizados pelo próximo produtor de bloco.
Consequentemente, o número de blocos bifurcados aumentou dramaticamente nos dias seguintes ao ataque.
Duas semanas de dados do Metrika mostraram que, no pior cenário, 13 blocos (4,3%) poderiam ser reorganizados em uma hora, o que é cerca de 5 vezes a taxa normal. O aumento dramático no número de blocos bifurcados tornou-se aparente quando os retransmissores lançaram várias mudanças. Graças aos grandes esforços da comunidade dos operadores de retransmissão e desenvolvedores principais, uma vez que o impacto foi conhecido, muitas mudanças foram revertidas e a rede foi restaurada para um estado saudável.
A partir de hoje, as mudanças mais úteis são validação de bloco de nó beacon e verificações de repúdio antes da emissão. Os produtores de blocos maliciosos não podem mais realizar ataques enviando cabeçalhos inválidos para retransmissões e garantindo que os nós de beacon de retransmissão não vejam os blocos repudiados antes de publicá-los. No entanto, os revezamentos ainda enfrentam os ataques de negação de ataque mais gerais propostos no MEV-Boost e no ePBS.
Próxima ação
Neste post, destacamos como o MEV-Boost funciona e como ele é crítico para o consenso Ethereum. Também fornecemos uma análise detalhada de alguns aspectos menos conhecidos das regras de escolha de fork Ethereum relacionadas ao tempo. Usando o ataque de "unbundling" e as respostas do desenvolvedor como um estudo de caso, destacamos a vulnerabilidade potencial dos aspectos relacionados ao tempo da regra de escolha da bifurcação e seu impacto na estabilidade da rede.
Com isso em mente, a comunidade de pesquisa deve avaliar o que é um número "aceitável" de reorganizações, levando em conta a exposição mais geral de ataques de negação, para determinar se as atenuações devem ser implementadas.
Além disso, várias direções futuras estão sendo exploradas ativamente:
Implemente um mecanismo de headlock para proteger o MEV-boost de ataques de erro de equivalência. Isso também exigiria alterações no software cliente de consenso e possivelmente alterações nas especificações para estender o prazo de envio da prova.
Aumentar o número e a distribuição de programas de recompensa de bugs para o software MEV-Boost.
Estenda o software de simulação para explorar como o tempo do subslot afeta a estabilidade da rede, que pode ser usado para avaliar como ajustar os prazos de envio de provas para reduzir a reorganização.
Otimize o caminho de liberação do bloco no relé para reduzir atrasos desnecessários - isso já está sendo explorado.
Reconhecer o MEV-boost como um recurso de protocolo central e incorporá-lo ao cliente de consenso, ou seja, "PBS consagrado (ePBS)". O ePBS de dois slots é vulnerável a ataques óbvios, portanto, implementar um "mecanismo de bloqueio" ainda é uma opção.
Adicionando mais testes de hive e/ou especificações sobre problemas relacionados à latência e prazos de certificação.
Incentive a diversidade de clientes de retransmissão construindo implementações adicionais da especificação de retransmissão.
Considere ajustar as penalidades para ataques óbvios, mas lembre-se de que mesmo uma penalidade total de 32 ETH pode não impedir o comportamento malicioso quando existe a oportunidade extrema de MEV.
Revise o tempo do sub-slot e considere ajustar a fase de propagação do bloco (por exemplo, ajustando o prazo de certificação de t=4 para t=6).
No geral, estamos entusiasmados com o ressurgimento do MEV e do ecossistema mev-boost. Por meio da separação de ataques e mitigações, aprendemos sobre a relação crítica entre latência, MEV-boost e mecanismos de consenso; esperamos que o protocolo continue a ser reforçado para lidar com isso.
Ver original
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Explicação detalhada do princípio de funcionamento do MEV-Boost e das regras de seleção do garfo Ethereum
Autor: Georgios Konstantopoulos, Mike Neuder
Compilação: Kxp, BlockBeats
Introdução
Em 2 de abril, atores maliciosos da rede Ethereum exploraram uma vulnerabilidade no relé MEV-Boost para roubar US$ 20 milhões de um buscador de MEV (consulte o relatório do Flashbots). Nos dias seguintes, os desenvolvedores resolveram a vulnerabilidade lançando cinco patches. Esses patches, combinados com atrasos na rede e políticas do validador, causaram uma breve flutuação na rede Ethereum em 6 de abril. A reorganização de blocos pode prejudicar a integridade da rede, pois diminui a taxa de produção de blocos e reduz as garantias de liquidação.
Neste post, com os Seekers sob ataque e a rede temporariamente instável, exploramos a interação entre o MEV-Boost e o consenso, analisamos as sutilezas do mecanismo de proof-of-stake do Ethereum e listamos alguns possíveis passos a seguir.
MEV-Boost e por que é importante
MEV-Boost é um protocolo desenvolvido por Flashbots e pela comunidade para mitigar o impacto negativo do Maximum Extractable Value (MEV) na rede Ethereum.
Existem 3 atores no MEV-Boost:
Relay - Leiloeiros que confiam uns nos outros, conectando produtores de blocos e construtores de blocos
Construtores - entidades complexas que constroem blocos para maximizar o MEV para si e para os criadores do bloco
Produtores de blocos - verificadores de proof-of-stake da Ethereum
A sequência aproximada de eventos para cada bloco é:
Os construtores criam um bloco recebendo transações de usuários, pesquisadores ou outros fluxos de pedidos (privados ou públicos)
O construtor envia o bloco ao relé
O relé verifica a validade do bloco e calcula o valor que paga ao produtor do bloco
O retransmissor envia um título em branco e um valor de pagamento para o produtor do bloco do slot atual
Os produtores de bloco avaliam todos os lances que receberam e assinam o cabeçalho em branco associado ao pagamento mais alto
O produtor do bloco envia este cabeçalho assinado de volta ao relé
Os relés publicam blocos usando seus nós beacon nativos e os devolvem ao doador de blocos. As recompensas são distribuídas aos construtores e proponentes por meio de transações dentro de blocos e recompensas de bloco.
Um retransmissor é um terceiro confiável que facilita uma troca justa de espaço de bloco por produtores de bloco e ordenação de transações por construtores para extração de MEV. Os relés protegem os construtores protegendo os construtores do roubo de MEV, evitando que os produtores de blocos copiem as transações do construtor para retirar o MEV sem distribuí-lo aos buscadores/construtores que o encontraram. Os relés protegem os produtores de blocos confirmando a validade de seus blocos, processando centenas de blocos por slot em seu nome e garantindo a precisão dos pagamentos dos produtores de blocos.
O MEV-Boost é a principal infraestrutura de protocolo, pois permite que todos os produtores de blocos acessem democraticamente o MEV sem exigir uma relação de confiança com construtores ou buscadores, o que contribui para a descentralização de longo prazo do Ethereum.
Regras de seleção de fork do Ethereum e MEV-Boost
Antes de discutir o ataque e a resposta, vamos dar uma olhada no mecanismo de proof-of-stake do Ethereum e nas regras de seleção de fork relacionadas. A regra de escolha da bifurcação permite que a rede chegue a um consenso sobre a cabeça da cadeia, conforme definido no artigo "Reorganização pós-fusão da Ethereum":
"A regra de escolha da bifurcação é uma função avaliada pelo cliente, que recebe como entrada os blocos vistos e outras informações e gera a "cadeia canônica" para o cliente. A regra de escolha da bifurcação é importante porque pode haver várias cadeias válidas para escolher (por exemplo, se dois blocos concorrentes com o mesmo bloco pai forem publicados ao mesmo tempo). "
As regras de seleção de bifurcação também dependem do tempo, o que tem um impacto significativo na geração de blocos.
ciclo de slot e sub-slot
No mecanismo de proof-of-stake da Ethereum, o tempo é dividido em slots a cada 12 segundos. O algoritmo proof-of-stake atribui aleatoriamente a um validador uma licença para propor um bloco dentro desse slot; esse validador é chamado de produtor de bloco. Dentro do mesmo slot, outros validadores recebem a tarefa de validar (votar) para o chain-head aplicando as regras de escolha do fork de acordo com suas visões locais. Este slot de 12 segundos é subdividido em três fases, cada uma custando 4 segundos.
Os eventos que ocorrem no slot são os seguintes, onde t=0 indica o início do slot.
Durante o slot, o momento mais crítico é o deadline de autenticação em t=4. Se os validadores de atestado não virem o bloco dentro do prazo de atestado, eles votarão no cabeçalho da cadeia previamente aceito (de acordo com a regra de escolha da bifurcação). Quanto mais cedo um bloco for proposto, mais tempo ele terá para se propagar e, assim, acumular mais aprovações (porque mais validadores o veem antes do prazo de aprovação).
Do ponto de vista da integridade da rede, o tempo ideal para a liberação de um bloco é t=0 (de acordo com a especificação). No entanto, como o valor do bloco aumenta monotonicamente ao longo do tempo, os produtores de blocos têm um incentivo para atrasar a liberação de seus blocos para que mais MEV possam ser acumulados. Consulte Cronometrar jogos em Proof-of-Stake e esta discussão para obter detalhes.
Anteriormente, um produtor de bloco poderia publicar um bloco após o prazo de certificação (mesmo próximo ao final do slot), desde que o próximo validador observasse o bloco antes de construir o bloco para seu slot subsequente. Isso ocorre porque o bloco filho herda o peso do bloco pai e a regra de seleção da bifurcação termina no nó folha. Portanto, adiar a liberação do bloco não tem efeitos colaterais. Para ajudar a mudar o comportamento racional (adiar lançamentos de blocos) para um comportamento honesto (publicar no prazo), uma "reorganização honesta" foi implementada.
Mecanismo de Recompensa do Produtor de Bloqueio e Reorganização Honesta
Dois novos conceitos são introduzidos no cliente de consenso que têm um impacto crítico no prazo de autenticação.
Mecanismo de Recompensa do Produtor de Bloco - Visa minimizar os ataques de reequilíbrio concedendo aos produtores de bloco uma "recompensa" de seleção de bifurcação igual a 40% do peso total da autenticação. É importante ressaltar que essa recompensa dura apenas o slot inteiro.
Reorganização honesta - aproveite a aceleração do produtor de blocos, permitindo que produtores de blocos honestos forcem a reorganização de blocos com pesos de autenticação abaixo de 20%. Isso já está implementado no Lighthouse e no Prysm (começando com a versão v4.0 - Capella). Essa alteração é opcional porque é uma decisão dos produtores de blocos e não afeta o comportamento dos validadores autenticadores. Portanto, não o aplicamos a todos os clientes ao mesmo tempo, nem está vinculado a nenhum hard fork específico.
Deve-se notar que a reorganização honesta é evitada em alguns casos especiais:
Durante os blocos de limite de época
Se a cadeia não for finalizada
Se a cabeça da cadeia não for a cabeça do slot antes da reorganização
O caso 3 garante que reorganizações honestas removam apenas um bloco da cadeia, que atua como um disjuntor, permitindo que a cadeia continue produzindo blocos durante períodos de extrema latência da rede. Também reflete que os proponentes têm menos confiança na percepção da rede, pois não podem ter certeza se seus blocos aprimorados propostos serão considerados a norma.
A figura abaixo mostra como o comportamento honesto pode ser mudado para implementar uma estratégia de reestruturação.
Nesse caso, deixe b1 representar um bloco tardio. Devido ao atraso, b1 tem apenas 19% do peso de prova do enésimo slot. Os 81% restantes do peso da prova são atribuídos ao bloco pai HEAD porque muitos provadores não viram b1 antes do prazo final da prova.
Se não houver uma reorganização honesta, o proponente do slot n+1 considerará b1 como cabeça da cadeia e construirá o sub-bloco b2. O proponente não fez nenhum esforço para reorganizar b1, embora tenha apenas 19% de peso de prova. No slot n+1, b2 tem o aprimoramento do proponente, supondo que seja entregue no prazo, b2 se tornará a norma acumulando a maioria das provas para aquele slot.
Com a Honest Reorganization, as coisas são muito diferentes. Agora, o proponente do slot n+1 vê que 19% dos pesos de prova de b1 estão abaixo do limite de reorganização, então eles constroem um bloco com HEAD como pai e forçam b1 a se reorganizar. Quando atingirmos o prazo de prova para o slot n+1, o provador honesto comparará os pesos relativos de b1 (19%) a b2 (40% do impulso do proponente). Todos os clientes implementam o aprimoramento do proponente, portanto b2 será considerado o chefe da cadeia e acumulará provas para o slot n+1.
Relay and Beacon node correções para desagregar ataques
No ataque de desagregação em 2 de abril, o proponente explorou uma vulnerabilidade de retransmissão para enviar um cabeçalho de assinatura inválido para a retransmissão. Nos dias seguintes, as equipes de retransmissão e desenvolvimento principal lançaram vários patches de software para mitigar o risco de ataques repetidos. As cinco principais mudanças são as seguintes:
Mudanças no Relay: verifique o banco de dados em busca de proponentes mal-intencionados conhecidos (usados na produção apenas pelo Ultrasonic Relay e foram removidos). Verifica se o relé entregou o bloco completo para um slot na rede P2P. Introduz um atraso aleatório uniforme na faixa de 0-500 ms antes de um bloco ser publicado (removido de todos os relés).
Alteração do nó beacon (somente nós beacon de retransmissão): Valide os blocos beacon antes da transmissão. Verifique a rede em busca de falsas confirmações antes de publicar um bloco. A combinação dessas mudanças levou à instabilidade do consenso, um problema exacerbado pelo fato de que a maioria dos validadores agora usa a estratégia de reorganização honesta descrita acima.
CONSEQUÊNCIAS NÃO-INTENCIONAIS
As cinco mudanças acima introduzem atrasos no hot path da emissão do bloco de retransmissão, o que aumenta a probabilidade de que os blocos de retransmissão sejam transmitidos após o prazo de confirmação. O diagrama abaixo mostra a sequência dessas cinco verificações e como o atraso introduzido faz com que a publicação do bloco ultrapasse o prazo de confirmação.
Um grande número de cabeçalhos assinados com um atraso de t = 0 (por exemplo, t = 3) geralmente não causa problemas até que essas verificações sejam implementadas. Como o relé tem um overhead muito baixo, ele publicará o bloco antes de t = 4 sem aguardar o prazo de confirmação.
No entanto, devido à introdução atrasada desses cinco patches, o retransmissor pode agora ser parcialmente responsável pela transmissão atrasada. Vejamos o hipotético processo de publicação de blocos abaixo.
O relé recebe o cabeçalho assinado do produtor do bloco em t = 3. Por t = 4, o relé ainda está realizando verificações, portanto o broadcast ocorrerá após o prazo de confirmação. Nesse caso, a combinação do cabeçalho assinado com atraso enviado pelo produtor do bloco e algum atraso adicional introduzido pelo retransmissor causou a falha na transmissão antes do prazo de confirmação. Se não tivesse havido uma reorganização honesta, esses blocos provavelmente teriam entrado na cadeia. Conforme mostrado na Figura 2, os produtores de blocos honestos do próximo slot não se reorganizarão deliberadamente porque esses blocos estão atrasados. No entanto, se o prazo de confirmação for perdido, os blocos serão reorganizados pelo próximo produtor de bloco.
Consequentemente, o número de blocos bifurcados aumentou dramaticamente nos dias seguintes ao ataque.
Duas semanas de dados do Metrika mostraram que, no pior cenário, 13 blocos (4,3%) poderiam ser reorganizados em uma hora, o que é cerca de 5 vezes a taxa normal. O aumento dramático no número de blocos bifurcados tornou-se aparente quando os retransmissores lançaram várias mudanças. Graças aos grandes esforços da comunidade dos operadores de retransmissão e desenvolvedores principais, uma vez que o impacto foi conhecido, muitas mudanças foram revertidas e a rede foi restaurada para um estado saudável.
A partir de hoje, as mudanças mais úteis são validação de bloco de nó beacon e verificações de repúdio antes da emissão. Os produtores de blocos maliciosos não podem mais realizar ataques enviando cabeçalhos inválidos para retransmissões e garantindo que os nós de beacon de retransmissão não vejam os blocos repudiados antes de publicá-los. No entanto, os revezamentos ainda enfrentam os ataques de negação de ataque mais gerais propostos no MEV-Boost e no ePBS.
Próxima ação
Neste post, destacamos como o MEV-Boost funciona e como ele é crítico para o consenso Ethereum. Também fornecemos uma análise detalhada de alguns aspectos menos conhecidos das regras de escolha de fork Ethereum relacionadas ao tempo. Usando o ataque de "unbundling" e as respostas do desenvolvedor como um estudo de caso, destacamos a vulnerabilidade potencial dos aspectos relacionados ao tempo da regra de escolha da bifurcação e seu impacto na estabilidade da rede.
Com isso em mente, a comunidade de pesquisa deve avaliar o que é um número "aceitável" de reorganizações, levando em conta a exposição mais geral de ataques de negação, para determinar se as atenuações devem ser implementadas.
Além disso, várias direções futuras estão sendo exploradas ativamente:
Implemente um mecanismo de headlock para proteger o MEV-boost de ataques de erro de equivalência. Isso também exigiria alterações no software cliente de consenso e possivelmente alterações nas especificações para estender o prazo de envio da prova.
Aumentar o número e a distribuição de programas de recompensa de bugs para o software MEV-Boost.
Estenda o software de simulação para explorar como o tempo do subslot afeta a estabilidade da rede, que pode ser usado para avaliar como ajustar os prazos de envio de provas para reduzir a reorganização.
Otimize o caminho de liberação do bloco no relé para reduzir atrasos desnecessários - isso já está sendo explorado.
Reconhecer o MEV-boost como um recurso de protocolo central e incorporá-lo ao cliente de consenso, ou seja, "PBS consagrado (ePBS)". O ePBS de dois slots é vulnerável a ataques óbvios, portanto, implementar um "mecanismo de bloqueio" ainda é uma opção.
Adicionando mais testes de hive e/ou especificações sobre problemas relacionados à latência e prazos de certificação.
Incentive a diversidade de clientes de retransmissão construindo implementações adicionais da especificação de retransmissão.
Considere ajustar as penalidades para ataques óbvios, mas lembre-se de que mesmo uma penalidade total de 32 ETH pode não impedir o comportamento malicioso quando existe a oportunidade extrema de MEV.
Revise o tempo do sub-slot e considere ajustar a fase de propagação do bloco (por exemplo, ajustando o prazo de certificação de t=4 para t=6).
No geral, estamos entusiasmados com o ressurgimento do MEV e do ecossistema mev-boost. Por meio da separação de ataques e mitigações, aprendemos sobre a relação crítica entre latência, MEV-boost e mecanismos de consenso; esperamos que o protocolo continue a ser reforçado para lidar com isso.