El 2 de abril, actores maliciosos de la red Ethereum explotaron una vulnerabilidad en el relé MEV-Boost para robar USD 20 millones de un solo buscador de MEV (consulte el informe Flashbots). Durante los días siguientes, los desarrolladores abordaron la vulnerabilidad lanzando cinco parches. Estos parches, combinados con retrasos en la red y políticas de validación, provocaron una breve fluctuación en la red Ethereum el 6 de abril. La reorganización de bloques puede ser perjudicial para la salud de la red, ya que ralentiza la tasa de producción de bloques y reduce las garantías de liquidación.
En esta publicación, con los buscadores bajo ataque y la red temporalmente inestable, exploramos la interacción entre MEV-Boost y el consenso, analizamos las sutilezas del mecanismo de prueba de participación de Ethereum y enumeramos algunas posibles formas de avanzar.
MEV-Boost y por qué es importante
MEV-Boost es un protocolo diseñado por Flashbots y la comunidad para mitigar el impacto negativo del valor máximo extraíble (MEV) en la red Ethereum.
Hay 3 actores en MEV-Boost:
Relevo: subastadores que confían entre sí, conectando a los productores de bloques y los constructores de bloques.
Constructores: entidades complejas que construyen bloques para maximizar MEV para ellos mismos y los creadores de bloques
Productores de bloques: verificadores de prueba de participación de Ethereum
La secuencia aproximada de eventos para cada bloque es:
Los constructores crean un bloque al recibir transacciones de usuarios, buscadores u otros flujos de pedidos (públicos o privados)
El constructor envía el bloque al relé.
El relé verifica la validez del bloque y calcula la cantidad que paga al productor del bloque.
El repetidor envía un título en blanco y un valor de pago al productor del bloque del espacio actual
Los Productores de Bloque evalúan todas las ofertas que han recibido y firman el encabezado en blanco asociado con el pago más alto
El productor del bloque devuelve este encabezado firmado al relé.
Los repetidores publican bloques utilizando sus nodos de baliza nativos y los devuelven al proveedor de bloques. Las recompensas se distribuyen a los constructores y proponentes a través de transacciones dentro de bloques y recompensas de bloques.
Un relé es un tercero de confianza que facilita un intercambio justo de espacio de bloques por parte de los productores de bloques y el pedido de transacciones por parte de los constructores para la extracción de MEV. Los relés protegen a los constructores protegiéndolos del robo de MEV, evitando que los productores de bloques copien las transacciones de los constructores para llevarse MEV sin distribuirlo a los buscadores/constructores que lo encontraron. Los relés protegen a los productores de bloques al confirmar la validez de sus bloques, procesar cientos de bloques por ranura en su nombre y garantizar la precisión de los pagos de los productores de bloques.
MEV-Boost es una infraestructura de protocolo clave, ya que permite que todos los productores de bloques accedan democráticamente a MEV sin necesidad de una relación de confianza con los constructores o buscadores, lo que contribuye a la descentralización a largo plazo de Ethereum.
Reglas de selección de bifurcaciones de Ethereum y MEV-Boost
Antes de discutir el ataque y la respuesta, echemos un vistazo al mecanismo de prueba de participación de Ethereum y las reglas de selección de bifurcaciones relacionadas. La regla de elección de bifurcación permite que la red llegue a un consenso sobre la cabeza de la cadena, como se define en el artículo "Reorganización posterior a la fusión de Ethereum":
“La regla de elección de bifurcación es una función evaluada por el cliente, que toma como entrada los bloques vistos y otra información, y envía la “cadena canónica” al cliente. La regla de elección de bifurcación es importante porque puede haber múltiples cadenas válidas para elegir (por ejemplo, si se publican al mismo tiempo dos bloques que compiten con el mismo bloque principal). "
Las reglas de selección de bifurcaciones también dependen del tiempo, lo que tiene un impacto significativo en la generación de bloques.
ciclo de intervalos y subintervalos
En el mecanismo de prueba de participación de Ethereum, el tiempo se divide en espacios cada 12 segundos. El algoritmo de prueba de participación asigna aleatoriamente a un validador una licencia para proponer un bloque dentro de ese espacio; este validador se denomina productor de bloques. Dentro del mismo espacio, a otros validadores se les asigna la tarea de validar (votar) por el cabeza de cadena aplicando las reglas de elección de horquilla de acuerdo con sus puntos de vista locales. Este intervalo de 12 segundos se subdivide en tres fases, cada una de las cuales cuesta 4 segundos.
Los eventos que ocurren en la ranura son los siguientes, donde t=0 indica el comienzo de la ranura.
Durante el intervalo, el momento más crítico es la fecha límite de autenticación en t=4. Si los validadores que certifican no ven el bloque antes de la fecha límite de certificación, votarán por el encabezado de la cadena previamente aceptado (de acuerdo con la regla de elección de la bifurcación). Cuanto antes se proponga un bloque, más tiempo tiene para propagarse y, por lo tanto, acumular más aprobaciones (porque más validadores lo ven antes de la fecha límite de aprobación).
Desde la perspectiva del estado de la red, el momento óptimo para la liberación de un bloque es t=0 (según la especificación). Sin embargo, dado que el valor del bloque aumenta de manera monótona con el tiempo, los productores de bloques tienen un incentivo para retrasar el lanzamiento de sus bloques para que se puedan acumular más MEV. Consulte Juegos de sincronización en Prueba de participación y esta discusión para obtener más detalles.
Anteriormente, un productor de bloques podía publicar un bloque después de la fecha límite de certificación (incluso cerca del final del espacio), siempre que el siguiente validador observara el bloque antes de construir el bloque para su espacio posterior. Esto se debe a que el bloque secundario hereda el peso del bloque principal y la regla de selección de bifurcación termina en el nodo hoja. Por lo tanto, posponer los lanzamientos de bloques no tiene efectos secundarios. Para ayudar a cambiar el comportamiento racional (posponer lanzamientos de bloques) a un comportamiento honesto (publicar a tiempo), se implementó una "reorganización honesta".
Mecanismo de recompensa del productor de bloques y reorganización honesta
Se introducen dos nuevos conceptos en el cliente de consenso que tienen un impacto crítico en la fecha límite de autenticación.
Mecanismo de recompensa del productor de bloques: tiene como objetivo minimizar los ataques de reequilibrio otorgando a los productores de bloques una "recompensa" de selección de bifurcación equivalente al 40% del peso total de autenticación. Es importante destacar que esta recompensa solo dura todo el espacio.
Reorganización honesta: aproveche la aceleración del productor de bloques, lo que permite a los productores de bloques honestos forzar la reorganización de bloques con pesos de autenticación inferiores al 20 %. Esto ya está implementado en Lighthouse y Prysm (a partir de v4.0 - versión Capella). Este cambio es opcional porque es una decisión que toman los productores de bloques y no afecta el comportamiento de los validadores de autenticación. Por lo tanto, no lo aplicamos a todos los clientes al mismo tiempo, ni está vinculado a ningún hard fork en particular.
Cabe señalar que la reorganización honesta se evita en algunos casos especiales:
Durante los bloques de límites de época
Si la cadena no está finalizada
Si la cabeza de la cadena no es la cabeza de la ranura antes de la reorganización
El caso 3 garantiza que las reorganizaciones honestas solo eliminen un bloque de la cadena, que actúa como un interruptor de circuito, lo que permite que la cadena continúe produciendo bloques durante los períodos de latencia extrema de la red. También refleja que los proponentes tienen menos confianza en la percepción de la red, ya que no pueden estar seguros de si sus bloques mejorados propuestos se considerarán la norma.
La siguiente figura muestra cómo se puede cambiar el comportamiento honesto para implementar una estrategia de reestructuración.
En este caso, sea b1 un bloque tardío. Debido al retraso, b1 solo tiene el 19 % del peso de prueba de la ranura n. El 81 % restante del peso de prueba se asigna al bloque principal HEAD porque muchos probadores no vieron b1 antes de la fecha límite de prueba.
Si no hay una reorganización honesta, el proponente del slot n+1 considerará a b1 como la cabeza de la cadena y construirá el subbloque b2. El proponente no hizo ningún esfuerzo por reorganizar b1, a pesar de que solo tiene un peso de prueba del 19%. En el intervalo n+1, b2 tiene la mejora del proponente, suponiendo que se entregue a tiempo, b2 se convertirá en la norma al acumular la mayoría de las pruebas para ese intervalo.
Con Honest Reorganization, las cosas son muy diferentes. Ahora, el proponente de la ranura n+1 ve que el 19% de los pesos de prueba de b1 están por debajo del umbral de reorganización, por lo que construyen un bloque con HEAD como padre y obligan a b1 a reorganizarse. Cuando alcancemos la fecha límite de prueba para el espacio n+1, el probador honesto comparará los pesos relativos de b1 (19 %) con b2 (40 % del impulso del proponente). Todos los clientes implementan la mejora del proponente, por lo que b2 se considerará la cabeza de la cadena y acumulará pruebas para el slot n+1.
Correcciones de nodos de retransmisión y baliza para ataques de desagregación
En el ataque de desagregación del 2 de abril, el proponente aprovechó una vulnerabilidad de retransmisión para enviar un encabezado de firma no válido al retransmisor. Durante los días siguientes, los equipos de desarrollo central y de retransmisión lanzaron numerosos parches de software para mitigar el riesgo de ataques repetidos. Los cinco cambios principales son los siguientes:
Cambios de retransmisión: verifique la base de datos en busca de proponentes maliciosos conocidos (utilizados en producción solo por Ultrasonic Relay y se han eliminado). Comprueba si el relé ha entregado el bloque completo a una ranura en la red P2P. Introduce un retraso aleatorio uniforme en el rango de 0 a 500 ms antes de que se publique un bloque (eliminado de todos los relés).
Cambio de nodo de baliza (solo nodos de baliza de retransmisión): valide los bloques de baliza antes de transmitir. Verifique la red en busca de falsas confirmaciones antes de publicar un bloque. La combinación de estos cambios condujo a la inestabilidad del consenso, un problema exacerbado por el hecho de que la mayoría de los validadores ahora usan la estrategia de reorganización honesta descrita anteriormente.
CONSECUENCIAS NO DESEADAS
Los cinco cambios sobre todo introducen retrasos en la ruta activa de la emisión de bloques de retransmisión, lo que aumenta la probabilidad de que los bloques de retransmisión se transmitan después de la fecha límite de confirmación. El siguiente diagrama muestra la secuencia de estas cinco comprobaciones y cómo el retraso introducido hace que la publicación del bloque supere el plazo de confirmación.
Una gran cantidad de encabezados firmados con un retraso de t = 0 (por ejemplo, t = 3) generalmente no causa problemas hasta que se implementan estas comprobaciones. Dado que el relé tiene una sobrecarga muy baja, publicará el bloque antes de t = 4 sin esperar la fecha límite de confirmación.
Sin embargo, debido a la introducción retrasada de estos cinco parches, el repetidor ahora puede ser parcialmente responsable de la transmisión retrasada. Veamos el hipotético proceso de publicación de bloques a continuación.
El relé recibe el encabezado firmado del productor del bloque en t = 3. Para t = 4, el relé aún está realizando comprobaciones, por lo que la transmisión se realizará después de la fecha límite de confirmación. En este caso, la combinación de la cabecera firmada retrasada enviada por el productor del bloque y algún retraso adicional introducido por el repetidor hizo que no se emitiera antes de la fecha límite de confirmación. Si no hubiera habido una reorganización honesta, estos bloques probablemente habrían llegado a la cadena. Como se muestra en la Figura 2, los productores de bloques honestos del siguiente espacio no se reorganizarán deliberadamente porque estos bloques lleguen tarde. Sin embargo, si no se cumple el plazo de confirmación, los bloques serán reorganizados por el siguiente productor de bloques.
En consecuencia, la cantidad de bloques bifurcados aumentó drásticamente en los días posteriores al ataque.
Dos semanas de datos de Metrika mostraron que, en el peor de los casos, se podrían reorganizar 13 bloques (4,3 %) en una hora, que es aproximadamente 5 veces la tasa normal. El aumento dramático en la cantidad de bloques bifurcados se hizo evidente a medida que los repetidores implementaron varios cambios. Gracias a los grandes esfuerzos de la comunidad de los operadores de retransmisión y los desarrolladores principales, una vez que se conoció el impacto, se revirtieron muchos cambios y la red se restauró a un estado saludable.
A partir de hoy, los cambios más útiles son la validación del bloque del nodo de baliza y las comprobaciones de repudio antes de la emisión. Los productores de bloques maliciosos ya no pueden realizar ataques enviando encabezados no válidos a los repetidores y asegurándose de que los nodos de baliza de repetidores no vean los bloques repudiados antes de publicarlos. No obstante, los repetidores aún se enfrentan a los ataques de negación de ataques más generales propuestos en MEV-Boost y ePBS.
Proxima accion
En esta publicación, destacamos cómo funciona MEV-Boost y cuán crítico es para el consenso de Ethereum. También proporcionamos un análisis detallado de algunos aspectos menos conocidos de las reglas de elección de horquillas de Ethereum relacionadas con el tiempo. Usando el ataque de "desagregación" y las respuestas de los desarrolladores como un caso de estudio, destacamos la vulnerabilidad potencial de los aspectos relacionados con el tiempo de la regla de elección de bifurcación y su impacto en la estabilidad de la red.
Con esto en mente, la comunidad de investigación debe evaluar cuál es un número "aceptable" de reorganizaciones, teniendo en cuenta la exposición más general de los ataques de negación, para determinar si se deben implementar mitigaciones.
Además, actualmente se están explorando activamente varias direcciones futuras:
Implementar un mecanismo de bloqueo de cabeza para proteger MEV-boost de ataques de error de equivalencia. Esto también requeriría cambios en el software del cliente de consenso y posiblemente cambios en las especificaciones para ampliar el plazo de presentación de pruebas.
Aumentar el número y la distribución de programas de recompensas por errores para el software MEV-Boost.
Ampliar el software de simulación para explorar cómo la temporización de subintervalos afecta la estabilidad de la red, lo que se puede utilizar para evaluar cómo ajustar los plazos de presentación de pruebas para reducir la reorganización.
Optimice la ruta de liberación del bloque en el relé para reducir demoras innecesarias; esto ya se está explorando.
Reconocer MEV-boost como una característica central del protocolo e incorporarlo en el cliente de consenso, es decir, "PBS consagrado (ePBS)". El ePBS de dos ranuras es vulnerable a ataques obvios, por lo que implementar un "mecanismo de bloqueo de cabeza" sigue siendo una opción.
Al agregar más pruebas de hive y/o especificaciones sobre problemas relacionados con la latencia y los plazos de certificación.
Fomentar la diversidad de clientes de retransmisión creando implementaciones adicionales de la especificación de retransmisión.
Considere ajustar las penalizaciones por ataques obvios, pero tenga en cuenta que incluso una penalización completa de 32 ETH puede no disuadir el comportamiento malicioso cuando existe la oportunidad extrema de MEV.
Revisar el tiempo de los subintervalos y considerar ajustar la fase de propagación del bloque (por ejemplo, ajustar la fecha límite de certificación de t=4 a t=6).
En general, estamos entusiasmados con el resurgimiento de MEV y el ecosistema mev-boost. A través de la desagregación de ataques y mitigaciones, hemos aprendido acerca de la relación crítica entre la latencia, el refuerzo de MEV y los mecanismos de consenso; esperamos que el protocolo continúe fortaleciéndose para manejar esto.
Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Explicación detallada del principio de funcionamiento de MEV-Boost y las reglas de selección de horquillas de Ethereum
Autor: Georgios Konstantopoulos, Mike Neuder
Compilación: Kxp, BlockBeats
Introducción
El 2 de abril, actores maliciosos de la red Ethereum explotaron una vulnerabilidad en el relé MEV-Boost para robar USD 20 millones de un solo buscador de MEV (consulte el informe Flashbots). Durante los días siguientes, los desarrolladores abordaron la vulnerabilidad lanzando cinco parches. Estos parches, combinados con retrasos en la red y políticas de validación, provocaron una breve fluctuación en la red Ethereum el 6 de abril. La reorganización de bloques puede ser perjudicial para la salud de la red, ya que ralentiza la tasa de producción de bloques y reduce las garantías de liquidación.
En esta publicación, con los buscadores bajo ataque y la red temporalmente inestable, exploramos la interacción entre MEV-Boost y el consenso, analizamos las sutilezas del mecanismo de prueba de participación de Ethereum y enumeramos algunas posibles formas de avanzar.
MEV-Boost y por qué es importante
MEV-Boost es un protocolo diseñado por Flashbots y la comunidad para mitigar el impacto negativo del valor máximo extraíble (MEV) en la red Ethereum.
Hay 3 actores en MEV-Boost:
Relevo: subastadores que confían entre sí, conectando a los productores de bloques y los constructores de bloques.
Constructores: entidades complejas que construyen bloques para maximizar MEV para ellos mismos y los creadores de bloques
Productores de bloques: verificadores de prueba de participación de Ethereum
La secuencia aproximada de eventos para cada bloque es:
Los constructores crean un bloque al recibir transacciones de usuarios, buscadores u otros flujos de pedidos (públicos o privados)
El constructor envía el bloque al relé.
El relé verifica la validez del bloque y calcula la cantidad que paga al productor del bloque.
El repetidor envía un título en blanco y un valor de pago al productor del bloque del espacio actual
Los Productores de Bloque evalúan todas las ofertas que han recibido y firman el encabezado en blanco asociado con el pago más alto
El productor del bloque devuelve este encabezado firmado al relé.
Los repetidores publican bloques utilizando sus nodos de baliza nativos y los devuelven al proveedor de bloques. Las recompensas se distribuyen a los constructores y proponentes a través de transacciones dentro de bloques y recompensas de bloques.
Un relé es un tercero de confianza que facilita un intercambio justo de espacio de bloques por parte de los productores de bloques y el pedido de transacciones por parte de los constructores para la extracción de MEV. Los relés protegen a los constructores protegiéndolos del robo de MEV, evitando que los productores de bloques copien las transacciones de los constructores para llevarse MEV sin distribuirlo a los buscadores/constructores que lo encontraron. Los relés protegen a los productores de bloques al confirmar la validez de sus bloques, procesar cientos de bloques por ranura en su nombre y garantizar la precisión de los pagos de los productores de bloques.
MEV-Boost es una infraestructura de protocolo clave, ya que permite que todos los productores de bloques accedan democráticamente a MEV sin necesidad de una relación de confianza con los constructores o buscadores, lo que contribuye a la descentralización a largo plazo de Ethereum.
Reglas de selección de bifurcaciones de Ethereum y MEV-Boost
Antes de discutir el ataque y la respuesta, echemos un vistazo al mecanismo de prueba de participación de Ethereum y las reglas de selección de bifurcaciones relacionadas. La regla de elección de bifurcación permite que la red llegue a un consenso sobre la cabeza de la cadena, como se define en el artículo "Reorganización posterior a la fusión de Ethereum":
“La regla de elección de bifurcación es una función evaluada por el cliente, que toma como entrada los bloques vistos y otra información, y envía la “cadena canónica” al cliente. La regla de elección de bifurcación es importante porque puede haber múltiples cadenas válidas para elegir (por ejemplo, si se publican al mismo tiempo dos bloques que compiten con el mismo bloque principal). "
Las reglas de selección de bifurcaciones también dependen del tiempo, lo que tiene un impacto significativo en la generación de bloques.
ciclo de intervalos y subintervalos
En el mecanismo de prueba de participación de Ethereum, el tiempo se divide en espacios cada 12 segundos. El algoritmo de prueba de participación asigna aleatoriamente a un validador una licencia para proponer un bloque dentro de ese espacio; este validador se denomina productor de bloques. Dentro del mismo espacio, a otros validadores se les asigna la tarea de validar (votar) por el cabeza de cadena aplicando las reglas de elección de horquilla de acuerdo con sus puntos de vista locales. Este intervalo de 12 segundos se subdivide en tres fases, cada una de las cuales cuesta 4 segundos.
Los eventos que ocurren en la ranura son los siguientes, donde t=0 indica el comienzo de la ranura.
Durante el intervalo, el momento más crítico es la fecha límite de autenticación en t=4. Si los validadores que certifican no ven el bloque antes de la fecha límite de certificación, votarán por el encabezado de la cadena previamente aceptado (de acuerdo con la regla de elección de la bifurcación). Cuanto antes se proponga un bloque, más tiempo tiene para propagarse y, por lo tanto, acumular más aprobaciones (porque más validadores lo ven antes de la fecha límite de aprobación).
Desde la perspectiva del estado de la red, el momento óptimo para la liberación de un bloque es t=0 (según la especificación). Sin embargo, dado que el valor del bloque aumenta de manera monótona con el tiempo, los productores de bloques tienen un incentivo para retrasar el lanzamiento de sus bloques para que se puedan acumular más MEV. Consulte Juegos de sincronización en Prueba de participación y esta discusión para obtener más detalles.
Anteriormente, un productor de bloques podía publicar un bloque después de la fecha límite de certificación (incluso cerca del final del espacio), siempre que el siguiente validador observara el bloque antes de construir el bloque para su espacio posterior. Esto se debe a que el bloque secundario hereda el peso del bloque principal y la regla de selección de bifurcación termina en el nodo hoja. Por lo tanto, posponer los lanzamientos de bloques no tiene efectos secundarios. Para ayudar a cambiar el comportamiento racional (posponer lanzamientos de bloques) a un comportamiento honesto (publicar a tiempo), se implementó una "reorganización honesta".
Mecanismo de recompensa del productor de bloques y reorganización honesta
Se introducen dos nuevos conceptos en el cliente de consenso que tienen un impacto crítico en la fecha límite de autenticación.
Mecanismo de recompensa del productor de bloques: tiene como objetivo minimizar los ataques de reequilibrio otorgando a los productores de bloques una "recompensa" de selección de bifurcación equivalente al 40% del peso total de autenticación. Es importante destacar que esta recompensa solo dura todo el espacio.
Reorganización honesta: aproveche la aceleración del productor de bloques, lo que permite a los productores de bloques honestos forzar la reorganización de bloques con pesos de autenticación inferiores al 20 %. Esto ya está implementado en Lighthouse y Prysm (a partir de v4.0 - versión Capella). Este cambio es opcional porque es una decisión que toman los productores de bloques y no afecta el comportamiento de los validadores de autenticación. Por lo tanto, no lo aplicamos a todos los clientes al mismo tiempo, ni está vinculado a ningún hard fork en particular.
Cabe señalar que la reorganización honesta se evita en algunos casos especiales:
Durante los bloques de límites de época
Si la cadena no está finalizada
Si la cabeza de la cadena no es la cabeza de la ranura antes de la reorganización
El caso 3 garantiza que las reorganizaciones honestas solo eliminen un bloque de la cadena, que actúa como un interruptor de circuito, lo que permite que la cadena continúe produciendo bloques durante los períodos de latencia extrema de la red. También refleja que los proponentes tienen menos confianza en la percepción de la red, ya que no pueden estar seguros de si sus bloques mejorados propuestos se considerarán la norma.
La siguiente figura muestra cómo se puede cambiar el comportamiento honesto para implementar una estrategia de reestructuración.
En este caso, sea b1 un bloque tardío. Debido al retraso, b1 solo tiene el 19 % del peso de prueba de la ranura n. El 81 % restante del peso de prueba se asigna al bloque principal HEAD porque muchos probadores no vieron b1 antes de la fecha límite de prueba.
Si no hay una reorganización honesta, el proponente del slot n+1 considerará a b1 como la cabeza de la cadena y construirá el subbloque b2. El proponente no hizo ningún esfuerzo por reorganizar b1, a pesar de que solo tiene un peso de prueba del 19%. En el intervalo n+1, b2 tiene la mejora del proponente, suponiendo que se entregue a tiempo, b2 se convertirá en la norma al acumular la mayoría de las pruebas para ese intervalo.
Con Honest Reorganization, las cosas son muy diferentes. Ahora, el proponente de la ranura n+1 ve que el 19% de los pesos de prueba de b1 están por debajo del umbral de reorganización, por lo que construyen un bloque con HEAD como padre y obligan a b1 a reorganizarse. Cuando alcancemos la fecha límite de prueba para el espacio n+1, el probador honesto comparará los pesos relativos de b1 (19 %) con b2 (40 % del impulso del proponente). Todos los clientes implementan la mejora del proponente, por lo que b2 se considerará la cabeza de la cadena y acumulará pruebas para el slot n+1.
Correcciones de nodos de retransmisión y baliza para ataques de desagregación
En el ataque de desagregación del 2 de abril, el proponente aprovechó una vulnerabilidad de retransmisión para enviar un encabezado de firma no válido al retransmisor. Durante los días siguientes, los equipos de desarrollo central y de retransmisión lanzaron numerosos parches de software para mitigar el riesgo de ataques repetidos. Los cinco cambios principales son los siguientes:
Cambios de retransmisión: verifique la base de datos en busca de proponentes maliciosos conocidos (utilizados en producción solo por Ultrasonic Relay y se han eliminado). Comprueba si el relé ha entregado el bloque completo a una ranura en la red P2P. Introduce un retraso aleatorio uniforme en el rango de 0 a 500 ms antes de que se publique un bloque (eliminado de todos los relés).
Cambio de nodo de baliza (solo nodos de baliza de retransmisión): valide los bloques de baliza antes de transmitir. Verifique la red en busca de falsas confirmaciones antes de publicar un bloque. La combinación de estos cambios condujo a la inestabilidad del consenso, un problema exacerbado por el hecho de que la mayoría de los validadores ahora usan la estrategia de reorganización honesta descrita anteriormente.
CONSECUENCIAS NO DESEADAS
Los cinco cambios sobre todo introducen retrasos en la ruta activa de la emisión de bloques de retransmisión, lo que aumenta la probabilidad de que los bloques de retransmisión se transmitan después de la fecha límite de confirmación. El siguiente diagrama muestra la secuencia de estas cinco comprobaciones y cómo el retraso introducido hace que la publicación del bloque supere el plazo de confirmación.
Una gran cantidad de encabezados firmados con un retraso de t = 0 (por ejemplo, t = 3) generalmente no causa problemas hasta que se implementan estas comprobaciones. Dado que el relé tiene una sobrecarga muy baja, publicará el bloque antes de t = 4 sin esperar la fecha límite de confirmación.
Sin embargo, debido a la introducción retrasada de estos cinco parches, el repetidor ahora puede ser parcialmente responsable de la transmisión retrasada. Veamos el hipotético proceso de publicación de bloques a continuación.
El relé recibe el encabezado firmado del productor del bloque en t = 3. Para t = 4, el relé aún está realizando comprobaciones, por lo que la transmisión se realizará después de la fecha límite de confirmación. En este caso, la combinación de la cabecera firmada retrasada enviada por el productor del bloque y algún retraso adicional introducido por el repetidor hizo que no se emitiera antes de la fecha límite de confirmación. Si no hubiera habido una reorganización honesta, estos bloques probablemente habrían llegado a la cadena. Como se muestra en la Figura 2, los productores de bloques honestos del siguiente espacio no se reorganizarán deliberadamente porque estos bloques lleguen tarde. Sin embargo, si no se cumple el plazo de confirmación, los bloques serán reorganizados por el siguiente productor de bloques.
En consecuencia, la cantidad de bloques bifurcados aumentó drásticamente en los días posteriores al ataque.
Dos semanas de datos de Metrika mostraron que, en el peor de los casos, se podrían reorganizar 13 bloques (4,3 %) en una hora, que es aproximadamente 5 veces la tasa normal. El aumento dramático en la cantidad de bloques bifurcados se hizo evidente a medida que los repetidores implementaron varios cambios. Gracias a los grandes esfuerzos de la comunidad de los operadores de retransmisión y los desarrolladores principales, una vez que se conoció el impacto, se revirtieron muchos cambios y la red se restauró a un estado saludable.
A partir de hoy, los cambios más útiles son la validación del bloque del nodo de baliza y las comprobaciones de repudio antes de la emisión. Los productores de bloques maliciosos ya no pueden realizar ataques enviando encabezados no válidos a los repetidores y asegurándose de que los nodos de baliza de repetidores no vean los bloques repudiados antes de publicarlos. No obstante, los repetidores aún se enfrentan a los ataques de negación de ataques más generales propuestos en MEV-Boost y ePBS.
Proxima accion
En esta publicación, destacamos cómo funciona MEV-Boost y cuán crítico es para el consenso de Ethereum. También proporcionamos un análisis detallado de algunos aspectos menos conocidos de las reglas de elección de horquillas de Ethereum relacionadas con el tiempo. Usando el ataque de "desagregación" y las respuestas de los desarrolladores como un caso de estudio, destacamos la vulnerabilidad potencial de los aspectos relacionados con el tiempo de la regla de elección de bifurcación y su impacto en la estabilidad de la red.
Con esto en mente, la comunidad de investigación debe evaluar cuál es un número "aceptable" de reorganizaciones, teniendo en cuenta la exposición más general de los ataques de negación, para determinar si se deben implementar mitigaciones.
Además, actualmente se están explorando activamente varias direcciones futuras:
Implementar un mecanismo de bloqueo de cabeza para proteger MEV-boost de ataques de error de equivalencia. Esto también requeriría cambios en el software del cliente de consenso y posiblemente cambios en las especificaciones para ampliar el plazo de presentación de pruebas.
Aumentar el número y la distribución de programas de recompensas por errores para el software MEV-Boost.
Ampliar el software de simulación para explorar cómo la temporización de subintervalos afecta la estabilidad de la red, lo que se puede utilizar para evaluar cómo ajustar los plazos de presentación de pruebas para reducir la reorganización.
Optimice la ruta de liberación del bloque en el relé para reducir demoras innecesarias; esto ya se está explorando.
Reconocer MEV-boost como una característica central del protocolo e incorporarlo en el cliente de consenso, es decir, "PBS consagrado (ePBS)". El ePBS de dos ranuras es vulnerable a ataques obvios, por lo que implementar un "mecanismo de bloqueo de cabeza" sigue siendo una opción.
Al agregar más pruebas de hive y/o especificaciones sobre problemas relacionados con la latencia y los plazos de certificación.
Fomentar la diversidad de clientes de retransmisión creando implementaciones adicionales de la especificación de retransmisión.
Considere ajustar las penalizaciones por ataques obvios, pero tenga en cuenta que incluso una penalización completa de 32 ETH puede no disuadir el comportamiento malicioso cuando existe la oportunidad extrema de MEV.
Revisar el tiempo de los subintervalos y considerar ajustar la fase de propagación del bloque (por ejemplo, ajustar la fecha límite de certificación de t=4 a t=6).
En general, estamos entusiasmados con el resurgimiento de MEV y el ecosistema mev-boost. A través de la desagregación de ataques y mitigaciones, hemos aprendido acerca de la relación crítica entre la latencia, el refuerzo de MEV y los mecanismos de consenso; esperamos que el protocolo continúe fortaleciéndose para manejar esto.