Tiempo, ranuras y orden de eventos en la atestación de Ethereum
El 2 de abril, un participante malintencionado de la red Ethereum aprovechó una vulnerabilidad en mev-boost-relay para robar 20 millones de dólares a un buscador de MEV. Los desarrolladores publicaron posteriormente cinco parches para corregir esta vulnerabilidad, pero la interacción 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 de la red reduce la tasa de producción de bloques y las garantías de liquidación, lo cual es perjudicial para la salud de la red.
Este artículo tiene como objetivo explorar la interacción entre mev-boost y los mecanismos de consenso, revelar las sutilezas dentro de la atestación de Ethereum y discutir algunas posibles direcciones de mejora. Nos inspiramos en dos eventos: los ataques sufridos por los buscadores y la inestabilidad temporal de la red.
la función de mev-boost
mev-boost es un protocolo diseñado para mitigar el impacto negativo del valor máximo extraíble (MEV) en la red de Ethereum.
mev-boost tiene tres roles:
Relé - Conectar al proponente con un intermediario confiable del constructor de bloques.
Constructores - Construir bloques para maximizar la entidad compleja de su propio MEV y el del proponente.
Proponente - validador de atestación de Ether.
El orden aproximado de los eventos en cada bloque es:
Los constructores reciben bloques de transacciones de usuarios, buscadores u otras fuentes.
Los constructores envían bloques al intermediario.
Verificar la validez de los bloques de retransmisión y calcular los pagos a los proponentes.
El relé envía al proponente del intervalo actual el encabezado del bloque "enmascarado" y el monto del pago.
El proponente evalúa todas las ofertas recibidas y firma el encabezado de bloque enmascarado correspondiente al pago más alto.
El proponente devolverá el encabezado del bloque firmado al relé.
El relé publica bloques a través de nodos de baliza locales y los devuelve al proponente. A través de las transacciones dentro del bloque y las recompensas del bloque, los constructores y los proponentes reciben recompensas.
El relé, como un tercero de confianza, facilita el intercambio justo del espacio de bloques para los proponentes, así como el ordenamiento de transacciones para la extracción de MEV por parte de los constructores. El relé protege a los constructores de que el MEV sea robado, y también protege a los proponentes al verificar la validez de los bloques, procesar grandes cantidades de bloques y asegurar pagos precisos.
mev-boost es una infraestructura clave, porque permite a todos los proponentes obtener MEV de manera justa sin necesidad de establecer relaciones de confianza, lo que ayuda a la descentralización a largo plazo de Ethereum.
Reglas de selección de bifurcación de Ethereum y mev-boost
Antes de profundizar en los ataques y las respuestas, primero entendamos el mecanismo de atestación de Ethereum ( PoS ) y sus reglas de selección de bifurcación. Las reglas de selección de bifurcación permiten que la red llegue a un consenso sobre la cabeza de la cadena.
La regla de selección de bifurcación es una función evaluada por el cliente que toma bloques conocidos y otros mensajes como entrada, y produce como salida cuál es la "cadena canónica". Se necesita una regla de selección de bifurcación porque puede haber múltiples cadenas válidas disponibles para elegir.
Las reglas de selección de bifurcaciones y su relación con el tiempo son poco conocidas, pero tienen un impacto significativo en la producción de bloques.
ciclos de ranura y subranura
En Ethereum PoS, el tiempo se divide en ranuras de 12 segundos. El algoritmo PoS designa aleatoriamente a un validador para proponer el bloque de esa ranura, y este validador se llama proponente. En la misma ranura, otros validadores son asignados para votar sobre el bloque más reciente en la posición de la cabeza de la cadena en su vista local, aplicando las reglas de selección de bifurcaciones. El intervalo de 12 segundos se divide en tres fases de 4 segundos.
Los eventos en el slot son los siguientes, t=0 indica el inicio del slot:
El momento más crítico en la ranura es la fecha límite de certificación t=4. Si el validador de certificación no ve el bloque antes de la fecha límite, votará por el encabezado previamente confirmado en la cadena. Cuanto más temprano se proponga el bloque, más largo será el tiempo de propagación y más testigos acumulados habrá.
Desde la perspectiva de la salud de la red, el mejor momento para publicar un bloque es t=0. Sin embargo, dado que el valor del bloque aumenta monótonamente con el tiempo, los proponentes tienen el incentivo de retrasar la publicación para acumular más MEV.
Históricamente, incluso después del período de certificación y cerca del final del slot, siempre que el siguiente validador observe el bloque antes de construir el bloque del siguiente slot, el proponente aún puede publicar el bloque. Para fomentar un comportamiento racional ( retrasar la publicación del bloque ) hacia un comportamiento honesto ( publicar a tiempo ) desarrollo, se introdujo la "reestructuración honesta".
Mejora del proponente y reestructuración honesta
Se introducen dos nuevos conceptos en el cliente de consenso, que tienen un impacto importante en el plazo de autenticación.
Mejora del proponente - Intenta minimizar el ataque de reequilibrio de reorganización al ofrecer al proponente una "mejora" de la opción de bifurcación equivalente al 40% del peso de la certificación completa. Esta mejora dura solo un slot.
Reorganización Honesta - Se adopta la mejora del proponente, permitiendo a los proponentes honestos usarla para forzar la reorganización de bloques cuya ponderación de certificación sea inferior al 20%. Esto se implementa en ciertos clientes. Este cambio es opcional, ya que es una decisión local del proponente y no afecta el comportamiento de los validadores.
Evitar la reestructuración honesta en ciertas circunstancias especiales:
Durante el período del bloque de frontera de la era
Si la cadena no está completa
Si el encabezado de la cadena no se obtiene del slot anterior al bloque de reestructuración
Condición 3 Asegurarse de que la reorganización honesta elimine solo un bloque de la cadena, actuando como un disyuntor para que la cadena pueda seguir generando bloques en caso de retrasos extremos en la red.
Reparación de nodos de retransmisión y de referencia contra ataques de desvinculación
En el ataque de desvinculación del 2 de abril, el proponente aprovechó una vulnerabilidad de retransmisión para enviar encabezados de firma inválidos para llevar a cabo el ataque. En los días siguientes, el equipo de desarrollo de retransmisión y el equipo central publicaron múltiples parches de software para mitigar el riesgo de ataques repetidos. Los cinco cambios principales son los siguientes:
Cambio de retransmisión:
Verificar si hay proponentes maliciosos conocidos en la base de datos.
Verifique si se ha transmitido el bloque completo a la red P2P durante este período.
Introducir un retraso aleatorio uniforme en el rango de 0-500 ms antes de publicar el bloque.
El cambio de nodo de la cadena de referencia ( solo se aplica a los nodos de la cadena de referencia de retransmisión ):
Verifica la validez del bloque de señal de transmisión antes de su difusión.
Verifica si hay equivalentes en la red antes de publicar el bloque.
Estos cambios combinados han llevado a una inestabilidad en el consenso, y la mayoría de los validadores han adoptado estrategias de reestructuración honesta, lo que ha agravado aún más esta situación.
consecuencias inesperadas
Cada uno de los 5 cambios mencionados aumentará la latencia en la ruta crítica de publicación de bloques de retransmisión, lo que aumentará la probabilidad de que los bloques de retransmisión se transmitan después de superar el plazo de certificación.
Antes de implementar estas verificaciones, la cabecera de la firma generalmente no tendrá problemas al llegar alrededor de t=3. Los costos de retransmisión son bajos, y se puede publicar un bloque antes de t=4.
Sin embargo, a medida que aumenta la demora por la introducción de cinco parches, el relé puede ser parcialmente responsable de la demora en la difusión. En algunos casos, si el proponente envía el encabezado firmado con retraso y el relé introduce una demora adicional, puede resultar en perder el plazo de certificación. Sin una reestructuración honesta, es muy probable que estos bloques entren en la cadena. Pero con una reestructuración honesta, perder el plazo de certificación significa que ese bloque será reestructurado por el siguiente proponente.
Por lo tanto, en los días posteriores al ataque, el número de bloques bifurcados aumentó drásticamente. En el peor de los casos, se reorganizaron 13 bloques en una hora (4.3%), aproximadamente 5 veces más que lo normal. Con el lanzamiento de diversas variaciones de los relés, el aumento repentino en el número de bloques bifurcados se volvió evidente. Gracias al esfuerzo de la comunidad, muchos cambios fueron revertidos y la red volvió a un estado saludable.
El cambio más útil actualmente es la verificación de equivalencia antes de la validación y difusión de bloques de nodos de beacon. Los proponentes maliciosos ya no pueden llevar a cabo ataques enviando encabezados inválidos al relé y asegurándose de que el nodo de beacon del relé no vea bloques equivalentes antes de publicar. Sin embargo, el relé sigue siendo vulnerable a ataques de equivalencia más generales.
dirección futura
La comunidad de investigación debe evaluar la cantidad de reorganizaciones "aceptables", considerando los riesgos generales que conlleva un ataque equivalente, y determinar si se necesitan medidas de mitigación.
Direcciones que se están explorando activamente:
Implementar la protección "headlock" para que mev-boost esté a salvo de ataques equivalentes. Esto requiere cambios en el software del cliente de consenso y puede ser necesario extender el plazo de certificación.
Aumentar el programa de recompensas por errores del software mev-boost.
Explorar el impacto del temporizador de subranura en la estabilidad de la red en el software de simulación de expansión.
Optimizar la ruta de publicación de bloques de retransmisión para reducir retrasos innecesarios.
Incluir mev-boost en el cliente de consenso, es decir, enshrined-PBS(ePBS).
Aumentar las pruebas basadas en la demora y los problemas de fecha límite de autenticación.
Fomentar la diversidad de clientes de retransmisión.
Considerar ajustar las medidas de penalización equivalentes.
En general, estamos emocionados por el renovado impulso del ecosistema de MEV y mev-boost. A través de la desvinculación de ataques y medidas de mitigación, comprendimos la relación clave entre la latencia, mev-boost y el mecanismo de consenso; esperamos que el protocolo pueda fortalecerse continuamente.
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.
14 me gusta
Recompensa
14
6
Republicar
Compartir
Comentar
0/400
GasFeePhobia
· 08-13 08:57
¿Ah? ¿Así que 20 millones se perdieron así de fácil?
Ver originalesResponder0
GlueGuy
· 08-13 08:55
Vaya, 20 millones de dólares desaparecieron de la nada.
Ver originalesResponder0
HalfBuddhaMoney
· 08-13 08:54
Soy un maestro de aprovechamiento, así que primero voy a aprovecharlo un poco. Aunque siento que estoy perdiendo un poco.
Ver originalesResponder0
MetaverseVagabond
· 08-13 08:46
¡Me robaron 20 millones! ¡Es una tragedia!
Ver originalesResponder0
BrokenDAO
· 08-13 08:42
Otro caso que demuestra que los atacantes siempre son más Satoshi que los defensores... el diseño de mecanismos es difícil.
Ordenación de tiempo y eventos en la atestación de Ethereum: la sutil interacción entre mev-boost y el Mecanismo de consenso
Tiempo, ranuras y orden de eventos en la atestación de Ethereum
El 2 de abril, un participante malintencionado de la red Ethereum aprovechó una vulnerabilidad en mev-boost-relay para robar 20 millones de dólares a un buscador de MEV. Los desarrolladores publicaron posteriormente cinco parches para corregir esta vulnerabilidad, pero la interacción 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 de la red reduce la tasa de producción de bloques y las garantías de liquidación, lo cual es perjudicial para la salud de la red.
Este artículo tiene como objetivo explorar la interacción entre mev-boost y los mecanismos de consenso, revelar las sutilezas dentro de la atestación de Ethereum y discutir algunas posibles direcciones de mejora. Nos inspiramos en dos eventos: los ataques sufridos por los buscadores y la inestabilidad temporal de la red.
la función de mev-boost
mev-boost es un protocolo diseñado para mitigar el impacto negativo del valor máximo extraíble (MEV) en la red de Ethereum.
mev-boost tiene tres roles:
El orden aproximado de los eventos en cada bloque es:
Los constructores reciben bloques de transacciones de usuarios, buscadores u otras fuentes.
Los constructores envían bloques al intermediario.
Verificar la validez de los bloques de retransmisión y calcular los pagos a los proponentes.
El relé envía al proponente del intervalo actual el encabezado del bloque "enmascarado" y el monto del pago.
El proponente evalúa todas las ofertas recibidas y firma el encabezado de bloque enmascarado correspondiente al pago más alto.
El proponente devolverá el encabezado del bloque firmado al relé.
El relé publica bloques a través de nodos de baliza locales y los devuelve al proponente. A través de las transacciones dentro del bloque y las recompensas del bloque, los constructores y los proponentes reciben recompensas.
El relé, como un tercero de confianza, facilita el intercambio justo del espacio de bloques para los proponentes, así como el ordenamiento de transacciones para la extracción de MEV por parte de los constructores. El relé protege a los constructores de que el MEV sea robado, y también protege a los proponentes al verificar la validez de los bloques, procesar grandes cantidades de bloques y asegurar pagos precisos.
mev-boost es una infraestructura clave, porque permite a todos los proponentes obtener MEV de manera justa sin necesidad de establecer relaciones de confianza, lo que ayuda a la descentralización a largo plazo de Ethereum.
Reglas de selección de bifurcación de Ethereum y mev-boost
Antes de profundizar en los ataques y las respuestas, primero entendamos el mecanismo de atestación de Ethereum ( PoS ) y sus reglas de selección de bifurcación. Las reglas de selección de bifurcación permiten que la red llegue a un consenso sobre la cabeza de la cadena.
La regla de selección de bifurcación es una función evaluada por el cliente que toma bloques conocidos y otros mensajes como entrada, y produce como salida cuál es la "cadena canónica". Se necesita una regla de selección de bifurcación porque puede haber múltiples cadenas válidas disponibles para elegir.
Las reglas de selección de bifurcaciones y su relación con el tiempo son poco conocidas, pero tienen un impacto significativo en la producción de bloques.
ciclos de ranura y subranura
En Ethereum PoS, el tiempo se divide en ranuras de 12 segundos. El algoritmo PoS designa aleatoriamente a un validador para proponer el bloque de esa ranura, y este validador se llama proponente. En la misma ranura, otros validadores son asignados para votar sobre el bloque más reciente en la posición de la cabeza de la cadena en su vista local, aplicando las reglas de selección de bifurcaciones. El intervalo de 12 segundos se divide en tres fases de 4 segundos.
Los eventos en el slot son los siguientes, t=0 indica el inicio del slot:
El momento más crítico en la ranura es la fecha límite de certificación t=4. Si el validador de certificación no ve el bloque antes de la fecha límite, votará por el encabezado previamente confirmado en la cadena. Cuanto más temprano se proponga el bloque, más largo será el tiempo de propagación y más testigos acumulados habrá.
Desde la perspectiva de la salud de la red, el mejor momento para publicar un bloque es t=0. Sin embargo, dado que el valor del bloque aumenta monótonamente con el tiempo, los proponentes tienen el incentivo de retrasar la publicación para acumular más MEV.
Históricamente, incluso después del período de certificación y cerca del final del slot, siempre que el siguiente validador observe el bloque antes de construir el bloque del siguiente slot, el proponente aún puede publicar el bloque. Para fomentar un comportamiento racional ( retrasar la publicación del bloque ) hacia un comportamiento honesto ( publicar a tiempo ) desarrollo, se introdujo la "reestructuración honesta".
Mejora del proponente y reestructuración honesta
Se introducen dos nuevos conceptos en el cliente de consenso, que tienen un impacto importante en el plazo de autenticación.
Mejora del proponente - Intenta minimizar el ataque de reequilibrio de reorganización al ofrecer al proponente una "mejora" de la opción de bifurcación equivalente al 40% del peso de la certificación completa. Esta mejora dura solo un slot.
Reorganización Honesta - Se adopta la mejora del proponente, permitiendo a los proponentes honestos usarla para forzar la reorganización de bloques cuya ponderación de certificación sea inferior al 20%. Esto se implementa en ciertos clientes. Este cambio es opcional, ya que es una decisión local del proponente y no afecta el comportamiento de los validadores.
Evitar la reestructuración honesta en ciertas circunstancias especiales:
Condición 3 Asegurarse de que la reorganización honesta elimine solo un bloque de la cadena, actuando como un disyuntor para que la cadena pueda seguir generando bloques en caso de retrasos extremos en la red.
Reparación de nodos de retransmisión y de referencia contra ataques de desvinculación
En el ataque de desvinculación del 2 de abril, el proponente aprovechó una vulnerabilidad de retransmisión para enviar encabezados de firma inválidos para llevar a cabo el ataque. En los días siguientes, el equipo de desarrollo de retransmisión y el equipo central publicaron múltiples parches de software para mitigar el riesgo de ataques repetidos. Los cinco cambios principales son los siguientes:
Verificar si hay proponentes maliciosos conocidos en la base de datos.
Verifique si se ha transmitido el bloque completo a la red P2P durante este período.
Introducir un retraso aleatorio uniforme en el rango de 0-500 ms antes de publicar el bloque.
Verifica la validez del bloque de señal de transmisión antes de su difusión.
Verifica si hay equivalentes en la red antes de publicar el bloque.
Estos cambios combinados han llevado a una inestabilidad en el consenso, y la mayoría de los validadores han adoptado estrategias de reestructuración honesta, lo que ha agravado aún más esta situación.
consecuencias inesperadas
Cada uno de los 5 cambios mencionados aumentará la latencia en la ruta crítica de publicación de bloques de retransmisión, lo que aumentará la probabilidad de que los bloques de retransmisión se transmitan después de superar el plazo de certificación.
Antes de implementar estas verificaciones, la cabecera de la firma generalmente no tendrá problemas al llegar alrededor de t=3. Los costos de retransmisión son bajos, y se puede publicar un bloque antes de t=4.
Sin embargo, a medida que aumenta la demora por la introducción de cinco parches, el relé puede ser parcialmente responsable de la demora en la difusión. En algunos casos, si el proponente envía el encabezado firmado con retraso y el relé introduce una demora adicional, puede resultar en perder el plazo de certificación. Sin una reestructuración honesta, es muy probable que estos bloques entren en la cadena. Pero con una reestructuración honesta, perder el plazo de certificación significa que ese bloque será reestructurado por el siguiente proponente.
Por lo tanto, en los días posteriores al ataque, el número de bloques bifurcados aumentó drásticamente. En el peor de los casos, se reorganizaron 13 bloques en una hora (4.3%), aproximadamente 5 veces más que lo normal. Con el lanzamiento de diversas variaciones de los relés, el aumento repentino en el número de bloques bifurcados se volvió evidente. Gracias al esfuerzo de la comunidad, muchos cambios fueron revertidos y la red volvió a un estado saludable.
El cambio más útil actualmente es la verificación de equivalencia antes de la validación y difusión de bloques de nodos de beacon. Los proponentes maliciosos ya no pueden llevar a cabo ataques enviando encabezados inválidos al relé y asegurándose de que el nodo de beacon del relé no vea bloques equivalentes antes de publicar. Sin embargo, el relé sigue siendo vulnerable a ataques de equivalencia más generales.
dirección futura
La comunidad de investigación debe evaluar la cantidad de reorganizaciones "aceptables", considerando los riesgos generales que conlleva un ataque equivalente, y determinar si se necesitan medidas de mitigación.
Direcciones que se están explorando activamente:
Implementar la protección "headlock" para que mev-boost esté a salvo de ataques equivalentes. Esto requiere cambios en el software del cliente de consenso y puede ser necesario extender el plazo de certificación.
Aumentar el programa de recompensas por errores del software mev-boost.
Explorar el impacto del temporizador de subranura en la estabilidad de la red en el software de simulación de expansión.
Optimizar la ruta de publicación de bloques de retransmisión para reducir retrasos innecesarios.
Incluir mev-boost en el cliente de consenso, es decir, enshrined-PBS(ePBS).
Aumentar las pruebas basadas en la demora y los problemas de fecha límite de autenticación.
Fomentar la diversidad de clientes de retransmisión.
Considerar ajustar las medidas de penalización equivalentes.
En general, estamos emocionados por el renovado impulso del ecosistema de MEV y mev-boost. A través de la desvinculación de ataques y medidas de mitigación, comprendimos la relación clave entre la latencia, mev-boost y el mecanismo de consenso; esperamos que el protocolo pueda fortalecerse continuamente.