Orden de tiempo, ranura y eventos en la atestación de Ethereum
El 2 de abril, un participante malicioso aprovechó una vulnerabilidad en mev-boost-relay para robar 20 millones de dólares. En los días siguientes, los desarrolladores publicaron cinco parches para reparar esta vulnerabilidad, lo que, combinado con la latencia de la red existente y las estrategias de los validadores, provocó una breve inestabilidad en la red Ethereum el 6 de abril. La reorganización es perjudicial para la salud de la red, ya que disminuye la tasa de producción de bloques y las garantías de liquidación.
Este artículo explora la interacción entre mev-boost y el consenso, revela las sutilezas del mecanismo PoS de Ethereum y sugiere algunas posibles direcciones de mejora.
introducción a mev-boost
mev-boost es un protocolo diseñado para mitigar el impacto negativo del valor máximo extraíble (MEV) en la red Ethereum. Contiene tres roles:
Relé: un tercero confiable que conecta a los proponentes y constructores de bloques.
Constructores: entidades complejas que construyen bloques para maximizar el MEV.
Proponente: validador de Ethereum PoS.
mev-boost permite a todos los proponentes obtener MEV de manera justa, sin necesidad de establecer una relación de confianza con los constructores, lo que ayuda a la descentralización a largo plazo de Ethereum.
Reglas de selección de bifurcaciones de Ethereum
En PoS de Ethereum, el tiempo se divide en intervalos de 12 segundos. En cada intervalo, se designa aleatoriamente un validador como proponente para presentar un bloque. Los otros validadores votan para apoyar la cabeza de la cadena aplicando las reglas de selección de bifurcación.
El momento más crítico en el slot es el plazo de certificación t=4. Si el validador no ve el bloque antes del plazo, votará por la cabeza de cadena anterior. Cuanto antes se publique el bloque, más certificación se obtendrá.
Desde el punto de vista de la salud de la red, el mejor momento para publicar es t=0. Sin embargo, dado que el valor del bloque aumenta con el tiempo, los proponentes tienen el incentivo de retrasar la publicación para acumular más MEV.
Para promover la publicación oportuna de acciones, se ha introducido el mecanismo de "reestructuración honesta".
Mejora del proponente y reestructuración honesta
Mejora del proponente: se otorga al proponente una opción de bifurcación "mejora" que equivale al 40% del peso de certificación, que dura solo un intervalo.
Reorganización honesta: permite a los proponentes honestos reorganizar bloques con un peso de certificación inferior al 20%. Esta es una función opcional, que el proponente decide si utilizar o no.
La reestructuración honesta se evitará en ciertas circunstancias, como durante el bloque de frontera de la época.
Corrección de ataques de desvinculación
Después del ataque de desvinculación del 2 de abril, el equipo de desarrollo del núcleo y el equipo de retransmisión publicaron múltiples parches:
Cambio de relevador:
Revisar proponentes maliciosos conocidos
Verifica si la ranura ha publicado un bloque completo
Introducir un retraso aleatorio
Cambio de nodo de la cadena de señal:
Verificación de la validez de los bloques
Verificar si hay bloques equivalentes en la red
Estos cambios han llevado a una inestabilidad en el consenso, y la estrategia de reorganización honesta ha agravado aún más esta situación.
consecuencias imprevistas
El parche aumentó el retraso en la publicación de bloques de relé, lo que puede hacer que los bloques superen el plazo de certificación. En una reestructuración honesta, estos bloques serán reestructurados por el siguiente proponente.
El resultado fue un aumento drástico en la cantidad de bloques bifurcados, alcanzando un máximo de un 4.3% de bloques reorganizados por hora. Con la implementación de los cambios en el relé, la situación comenzó a normalizarse.
Actualmente, la reparación más efectiva es la verificación de bloques y la comprobación de equivalencia del nodo de referencia. Pero el intermediario sigue siendo susceptible a ataques de equivalencia más generales.
dirección futura
Es necesario evaluar la cantidad de reestructuraciones "aceptables" y considerar el riesgo de ataques equivalentes. Algunas posibles direcciones de mejora:
Implementar protección "headlock" mev-boost
Aumentar el programa de recompensas por vulnerabilidades
Ampliar la investigación del software de simulación en los subslots de temporización
Optimización de la ruta de publicación de relés
Incluir mev-boost en el cliente de consenso (ePBS)
Añadir más pruebas
Fomentar la diversidad de clientes de retransmisión
Ajustar las medidas de penalización equivalentes
En resumen, el ataque de desvinculación nos ha hecho reconocer la relación clave entre la latencia, mev-boost y el mecanismo de consenso. Esperamos que el protocolo pueda seguir fortaleciéndose para enfrentar los desafíos futuros.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
23 me gusta
Recompensa
23
4
Republicar
Compartir
Comentar
0/400
probably_nothing_anon
· 08-14 12:43
Otro día, otro fallo, no se puede mantener más.
Ver originalesResponder0
GmGmNoGn
· 08-12 06:06
¿De verdad PoS también tiene vulnerabilidades?!
Ver originalesResponder0
DogeBachelor
· 08-12 05:55
Otra vez se ha oscurecido Ethereum, nuestro DOGE está muy seguro.
Discusión sobre la vulnerabilidad de mev-boost y la estabilidad de la red bajo el mecanismo PoS de Ethereum
Orden de tiempo, ranura y eventos en la atestación de Ethereum
El 2 de abril, un participante malicioso aprovechó una vulnerabilidad en mev-boost-relay para robar 20 millones de dólares. En los días siguientes, los desarrolladores publicaron cinco parches para reparar esta vulnerabilidad, lo que, combinado con la latencia de la red existente y las estrategias de los validadores, provocó una breve inestabilidad en la red Ethereum el 6 de abril. La reorganización es perjudicial para la salud de la red, ya que disminuye la tasa de producción de bloques y las garantías de liquidación.
Este artículo explora la interacción entre mev-boost y el consenso, revela las sutilezas del mecanismo PoS de Ethereum y sugiere algunas posibles direcciones de mejora.
introducción a mev-boost
mev-boost es un protocolo diseñado para mitigar el impacto negativo del valor máximo extraíble (MEV) en la red Ethereum. Contiene tres roles:
mev-boost permite a todos los proponentes obtener MEV de manera justa, sin necesidad de establecer una relación de confianza con los constructores, lo que ayuda a la descentralización a largo plazo de Ethereum.
Reglas de selección de bifurcaciones de Ethereum
En PoS de Ethereum, el tiempo se divide en intervalos de 12 segundos. En cada intervalo, se designa aleatoriamente un validador como proponente para presentar un bloque. Los otros validadores votan para apoyar la cabeza de la cadena aplicando las reglas de selección de bifurcación.
El momento más crítico en el slot es el plazo de certificación t=4. Si el validador no ve el bloque antes del plazo, votará por la cabeza de cadena anterior. Cuanto antes se publique el bloque, más certificación se obtendrá.
Desde el punto de vista de la salud de la red, el mejor momento para publicar es t=0. Sin embargo, dado que el valor del bloque aumenta con el tiempo, los proponentes tienen el incentivo de retrasar la publicación para acumular más MEV.
Para promover la publicación oportuna de acciones, se ha introducido el mecanismo de "reestructuración honesta".
Mejora del proponente y reestructuración honesta
Mejora del proponente: se otorga al proponente una opción de bifurcación "mejora" que equivale al 40% del peso de certificación, que dura solo un intervalo.
Reorganización honesta: permite a los proponentes honestos reorganizar bloques con un peso de certificación inferior al 20%. Esta es una función opcional, que el proponente decide si utilizar o no.
La reestructuración honesta se evitará en ciertas circunstancias, como durante el bloque de frontera de la época.
Corrección de ataques de desvinculación
Después del ataque de desvinculación del 2 de abril, el equipo de desarrollo del núcleo y el equipo de retransmisión publicaron múltiples parches:
Cambio de relevador:
Cambio de nodo de la cadena de señal:
Estos cambios han llevado a una inestabilidad en el consenso, y la estrategia de reorganización honesta ha agravado aún más esta situación.
consecuencias imprevistas
El parche aumentó el retraso en la publicación de bloques de relé, lo que puede hacer que los bloques superen el plazo de certificación. En una reestructuración honesta, estos bloques serán reestructurados por el siguiente proponente.
El resultado fue un aumento drástico en la cantidad de bloques bifurcados, alcanzando un máximo de un 4.3% de bloques reorganizados por hora. Con la implementación de los cambios en el relé, la situación comenzó a normalizarse.
Actualmente, la reparación más efectiva es la verificación de bloques y la comprobación de equivalencia del nodo de referencia. Pero el intermediario sigue siendo susceptible a ataques de equivalencia más generales.
dirección futura
Es necesario evaluar la cantidad de reestructuraciones "aceptables" y considerar el riesgo de ataques equivalentes. Algunas posibles direcciones de mejora:
En resumen, el ataque de desvinculación nos ha hecho reconocer la relación clave entre la latencia, mev-boost y el mecanismo de consenso. Esperamos que el protocolo pueda seguir fortaleciéndose para enfrentar los desafíos futuros.