Orden de tiempo, ranura y eventos en la atestación de Ethereum
El 2 de abril, un participante malicioso aprovechó una vulnerabilidad de una plataforma de retransmisión para robar 20 millones de dólares. En los días siguientes, los desarrolladores publicaron 5 parches para resolver el problema, pero combinado con la latencia de la red existente y la política de validadores, causó 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 generación de bloques y reduce las garantías de liquidación.
Este artículo tiene como objetivo explorar la interacción entre ciertos protocolos y consensos, revelar los matices del mecanismo de atestación de Ethereum y enumerar algunas posibles direcciones futuras. Nos inspiramos en los ataques sufridos por los buscadores y en los eventos de inestabilidad temporal de la red.
La importancia de cierto protocolo
Un protocolo diseñado por la comunidad, con el objetivo de mitigar el impacto negativo del máximo valor extraíble (MEV) en la red Ethereum.
Hay tres roles en este protocolo:
Relé - Conectar al proponente con un comerciante de subasta confiable para constructores de bloques.
Constructores - Construir bloques para maximizar las entidades complejas del MEV propio y del proponente.
Proponente - validador de atestación de Ethereum.
La secuencia de eventos aproximada de cada bloque es la siguiente: el constructor crea un bloque y lo envía al relé; el relé verifica la validez del bloque y calcula la tarifa a pagar al proponente; el relé envía al proponente del intervalo actual el encabezado de "firma ciega" y el valor de pago; el proponente evalúa todas las ofertas recibidas y firma el encabezado de firma ciega relacionado con el pago más alto; el proponente devuelve el encabezado firmado al relé; el relé publica el bloque utilizando nodos de referencia locales y lo devuelve al proponente.
Este protocolo es una infraestructura clave, ya que permite a todos los proponentes acceder de manera justa al MEV, sin necesidad de establecer relaciones de confianza con constructores o buscadores, lo que contribuye a la descentralización a largo plazo de Ethereum.
Reglas de selección de bifurcación de Ethereum y cierto protocolo
Antes de profundizar en el ataque y la respuesta, primero echemos un vistazo al mecanismo de atestación de Ethereum ( PoS ) y sus reglas de selección de bifurcación relacionadas. Las reglas de selección de bifurcación permiten que la red alcance un consenso sobre el encabezado de la cadena.
Las reglas de selección de bifurcación son funciones evaluadas por el cliente, que toman como entrada bloques y mensajes ya vistos, y producen como salida la "cadena oficial". Se necesitan reglas de selección de bifurcación porque puede haber múltiples cadenas válidas disponibles para elegir.
Un aspecto poco conocido de las reglas de selección de bifurcaciones es su relación con el tiempo, lo que tiene un impacto significativo en la creación de bloques.
Período de ranuras y subranuras
En Ethereum PoS, el tiempo se divide en intervalos de 12 segundos. El algoritmo PoS designa aleatoriamente a un validador para proponer bloques en ese intervalo; este validador se llama proponente. En el mismo intervalo, otros validadores son designados para votar a favor del último bloque en la ubicación de la cabeza de cadena en su vista local, aplicando las reglas de selección de bifurcaciones. El intervalo de 12 segundos se divide en tres fases, cada fase de 4 segundos.
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 la cabeza de cadena anterior. Cuanto antes se proponga un bloque, más tiempo tendrá para propagarse y acumular más testigos.
Desde la perspectiva de la salud de la red, el mejor tiempo de creación de bloques es t=0. Sin embargo, dado que el valor del bloque aumenta con el tiempo, los proponentes tienen incentivos para retrasar la publicación y acumular más MEV.
Históricamente, incluso después del plazo de certificación o incluso cerca del final del slot, el proponente aún podía publicar bloques, siempre que el siguiente validador los observara antes de construir el bloque del siguiente slot. Para fomentar el comportamiento racional (, se implementó un "reestructuración honesta" para retrasar la publicación ) hacia el comportamiento honesto ( y publicar a tiempo ).
Mejora de los proponentes y reestructuración honesta
Se introducen dos nuevos conceptos en el cliente de consenso, que tienen un impacto clave en la fecha límite de autorización:
Elevación del proponente - Minimizar el ataque de reequilibrio de reorganización mediante la concesión al proponente de una selección de bifurcación "elevada" equivalente al 40% del peso completo de certificación. Esta mejora solo dura un intervalo de tiempo.
Reorganización honesta - Permite a los proponentes mejorar y permitir que los proponentes honestos lo utilicen para forzar la reorganización de bloques con un peso de certificación inferior al 20%. Esto se implementa en algunos 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 bloque de frontera de la era
Si la cadena no está completa
Si la cabeza de la cadena no se obtiene del intervalo de tiempo anterior al bloque de reorganización
La condición 3 asegura que la reestructuración honesta elimine solo un bloque de la cadena, actuando como un cortacircuito para que la cadena pueda continuar produciendo bloques durante períodos de latencia extrema en la red. Esto también refleja una disminución de la confianza del proponente en su visión de la red.
Reparación de nodos de retransmisión y de baliza contra ataques de desvinculación
En el ataque del 2 de abril, los proponentes aprovecharon una vulnerabilidad de retransmisión al 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 varios parches para reducir el riesgo de ataques repetidos. Los principales cambios son los siguientes:
Cambio de retransmisión:
Verificar si existe un proponente malicioso conocido en la base de datos
Verifica si se ha transmitido el bloque completo a la red P2P durante este período.
Introducir un retraso aleatorio antes de publicar el bloque
El cambio del nodo de la cadena de balizas ( solo se aplica a los nodos de baliza de retransmisión ):
Verificar la validez del bloque de señal antes de la difusión
Verificar si hay equivalentes en la red antes de publicar el bloque
Estos cambios han llevado a una inestabilidad en el consenso, y la mayoría de los validadores ahora utilizan estrategias de reconfiguración honesta, lo que agrava aún más esta situación.
Consecuencias imprevistas
Los cinco cambios mencionados aumentan la latencia en la ruta caliente de publicación de bloques de retransmisión, lo que incrementa la probabilidad de que los bloques de retransmisión superen el plazo de certificación.
Antes de llevar a cabo estas verificaciones, el tiempo de llegada del encabezado de firma es significativamente posterior a t=0(, como t=3), lo que normalmente no presenta problemas. Los gastos de retransmisión son bajos, por lo que se publicará el bloque antes de t=4.
Sin embargo, a medida que aumenta la demora en la introducción de parches, el relé ahora puede causar demoras en la transmisión. En algunos casos, el proponente envía el encabezado firmado tarde y la introducción del relé, combinada con la demora adicional, provoca la pérdida del plazo de certificación. Si no hay reestructuración honesta, es muy probable que estos bloques entren en la cadena. Pero cuando hay reestructuración honesta, perder el plazo de certificación significa que el 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, 13 bloques ( se reorganizaron en una hora, lo que es aproximadamente 5 veces más de lo normal. Con el lanzamiento de varias modificaciones por parte de los retransmisores, se hizo evidente el aumento drástico en el número de bloques bifurcados. Gracias a los esfuerzos de la comunidad, muchos cambios fueron revertidos y la red recuperó su estado saludable.
El cambio más útil en este momento es la verificación de equivalencia antes de la validación y transmisión de bloques de nodos de referencia. Los proponentes maliciosos ya no pueden llevar a cabo ataques enviando encabezados inválidos al intermediario y asegurándose de que los nodos de referencia del intermediario no vean bloques equivalentes antes de su publicación. Sin embargo, el intermediario sigue siendo susceptible a ataques de equivalencia más generales.
![Paradigm: Explorando la relación entre MEV-Boost y el mecanismo de consenso de Ethereum])https://img-cdn.gateio.im/webp-social/moments-00fb5ee47056beb2efc3ca4ac271a69c.webp(
) dirección futura
Dado esto, la comunidad de investigación debería evaluar qué cantidad de reestructuraciones es "aceptable" y considerar los riesgos derivados de un ataque equivalente para determinar si se necesitan medidas de mitigación.
Actualmente se están explorando activamente múltiples direcciones futuras:
Implementar "headlock" para prevenir ataques de equivalencia
Aumentar el programa de recompensas por vulnerabilidades para el software relacionado
Ampliar el software de simulación para estudiar el impacto del temporizador de subintervalos en la estabilidad de la red
Optimizar la ruta de publicación de bloques en el intermediario para reducir la latencia
Integrar un protocolo en el cliente de consenso
Aumentar más pruebas basadas en problemas de retraso y plazos de certificación.
Fomentar la diversidad de clientes de retransmisión
Considerar ajustar las medidas de penalización equivalentes
En general, estamos emocionados por la energía reavivada en torno al MEV y el ecosistema relacionado. A través de este evento, entendimos la relación clave entre la latencia, ciertos protocolos y los mecanismos de consenso; esperamos que los protocolos puedan seguir fortaleciéndose.
![Paradigm: Explorando la relación entre MEV-Boost y el mecanismo de consenso de Ethereum]###https://img-cdn.gateio.im/webp-social/moments-9db8f9a0944e1eff6bde4db0c8343fbe.webp(
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.
20 me gusta
Recompensa
20
6
Republicar
Compartir
Comentar
0/400
NFTFreezer
· 08-17 04:05
¿Qué pasa con eth que fue hackeado?
Ver originalesResponder0
MevHunter
· 08-17 03:03
¿Otra vez te está haciendo pensar demasiado?
Ver originalesResponder0
Deconstructionist
· 08-14 17:13
Estoy mareado, este mecanismo POS es demasiado complejo.
Ver originalesResponder0
GasWaster
· 08-14 17:08
acabo de gastar 5 eth en transacciones fallidas... pos ya no es seguro smh
Ver originalesResponder0
Degen4Breakfast
· 08-14 16:58
Otra día en el mundo Cripto con un compañero de comida.
Análisis del mecanismo de consenso PoS de Ethereum: tiempo, ranuras y ordenación de eventos
Orden de tiempo, ranura y eventos en la atestación de Ethereum
El 2 de abril, un participante malicioso aprovechó una vulnerabilidad de una plataforma de retransmisión para robar 20 millones de dólares. En los días siguientes, los desarrolladores publicaron 5 parches para resolver el problema, pero combinado con la latencia de la red existente y la política de validadores, causó 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 generación de bloques y reduce las garantías de liquidación.
Este artículo tiene como objetivo explorar la interacción entre ciertos protocolos y consensos, revelar los matices del mecanismo de atestación de Ethereum y enumerar algunas posibles direcciones futuras. Nos inspiramos en los ataques sufridos por los buscadores y en los eventos de inestabilidad temporal de la red.
La importancia de cierto protocolo
Un protocolo diseñado por la comunidad, con el objetivo de mitigar el impacto negativo del máximo valor extraíble (MEV) en la red Ethereum.
Hay tres roles en este protocolo:
La secuencia de eventos aproximada de cada bloque es la siguiente: el constructor crea un bloque y lo envía al relé; el relé verifica la validez del bloque y calcula la tarifa a pagar al proponente; el relé envía al proponente del intervalo actual el encabezado de "firma ciega" y el valor de pago; el proponente evalúa todas las ofertas recibidas y firma el encabezado de firma ciega relacionado con el pago más alto; el proponente devuelve el encabezado firmado al relé; el relé publica el bloque utilizando nodos de referencia locales y lo devuelve al proponente.
Este protocolo es una infraestructura clave, ya que permite a todos los proponentes acceder de manera justa al MEV, sin necesidad de establecer relaciones de confianza con constructores o buscadores, lo que contribuye a la descentralización a largo plazo de Ethereum.
Reglas de selección de bifurcación de Ethereum y cierto protocolo
Antes de profundizar en el ataque y la respuesta, primero echemos un vistazo al mecanismo de atestación de Ethereum ( PoS ) y sus reglas de selección de bifurcación relacionadas. Las reglas de selección de bifurcación permiten que la red alcance un consenso sobre el encabezado de la cadena.
Las reglas de selección de bifurcación son funciones evaluadas por el cliente, que toman como entrada bloques y mensajes ya vistos, y producen como salida la "cadena oficial". Se necesitan reglas de selección de bifurcación porque puede haber múltiples cadenas válidas disponibles para elegir.
Un aspecto poco conocido de las reglas de selección de bifurcaciones es su relación con el tiempo, lo que tiene un impacto significativo en la creación de bloques.
Período de ranuras y subranuras
En Ethereum PoS, el tiempo se divide en intervalos de 12 segundos. El algoritmo PoS designa aleatoriamente a un validador para proponer bloques en ese intervalo; este validador se llama proponente. En el mismo intervalo, otros validadores son designados para votar a favor del último bloque en la ubicación de la cabeza de cadena en su vista local, aplicando las reglas de selección de bifurcaciones. El intervalo de 12 segundos se divide en tres fases, cada fase de 4 segundos.
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 la cabeza de cadena anterior. Cuanto antes se proponga un bloque, más tiempo tendrá para propagarse y acumular más testigos.
Desde la perspectiva de la salud de la red, el mejor tiempo de creación de bloques es t=0. Sin embargo, dado que el valor del bloque aumenta con el tiempo, los proponentes tienen incentivos para retrasar la publicación y acumular más MEV.
Históricamente, incluso después del plazo de certificación o incluso cerca del final del slot, el proponente aún podía publicar bloques, siempre que el siguiente validador los observara antes de construir el bloque del siguiente slot. Para fomentar el comportamiento racional (, se implementó un "reestructuración honesta" para retrasar la publicación ) hacia el comportamiento honesto ( y publicar a tiempo ).
Mejora de los proponentes y reestructuración honesta
Se introducen dos nuevos conceptos en el cliente de consenso, que tienen un impacto clave en la fecha límite de autorización:
Elevación del proponente - Minimizar el ataque de reequilibrio de reorganización mediante la concesión al proponente de una selección de bifurcación "elevada" equivalente al 40% del peso completo de certificación. Esta mejora solo dura un intervalo de tiempo.
Reorganización honesta - Permite a los proponentes mejorar y permitir que los proponentes honestos lo utilicen para forzar la reorganización de bloques con un peso de certificación inferior al 20%. Esto se implementa en algunos 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:
La condición 3 asegura que la reestructuración honesta elimine solo un bloque de la cadena, actuando como un cortacircuito para que la cadena pueda continuar produciendo bloques durante períodos de latencia extrema en la red. Esto también refleja una disminución de la confianza del proponente en su visión de la red.
Reparación de nodos de retransmisión y de baliza contra ataques de desvinculación
En el ataque del 2 de abril, los proponentes aprovecharon una vulnerabilidad de retransmisión al 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 varios parches para reducir el riesgo de ataques repetidos. Los principales cambios son los siguientes:
Estos cambios han llevado a una inestabilidad en el consenso, y la mayoría de los validadores ahora utilizan estrategias de reconfiguración honesta, lo que agrava aún más esta situación.
Consecuencias imprevistas
Los cinco cambios mencionados aumentan la latencia en la ruta caliente de publicación de bloques de retransmisión, lo que incrementa la probabilidad de que los bloques de retransmisión superen el plazo de certificación.
Antes de llevar a cabo estas verificaciones, el tiempo de llegada del encabezado de firma es significativamente posterior a t=0(, como t=3), lo que normalmente no presenta problemas. Los gastos de retransmisión son bajos, por lo que se publicará el bloque antes de t=4.
Sin embargo, a medida que aumenta la demora en la introducción de parches, el relé ahora puede causar demoras en la transmisión. En algunos casos, el proponente envía el encabezado firmado tarde y la introducción del relé, combinada con la demora adicional, provoca la pérdida del plazo de certificación. Si no hay reestructuración honesta, es muy probable que estos bloques entren en la cadena. Pero cuando hay reestructuración honesta, perder el plazo de certificación significa que el 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, 13 bloques ( se reorganizaron en una hora, lo que es aproximadamente 5 veces más de lo normal. Con el lanzamiento de varias modificaciones por parte de los retransmisores, se hizo evidente el aumento drástico en el número de bloques bifurcados. Gracias a los esfuerzos de la comunidad, muchos cambios fueron revertidos y la red recuperó su estado saludable.
El cambio más útil en este momento es la verificación de equivalencia antes de la validación y transmisión de bloques de nodos de referencia. Los proponentes maliciosos ya no pueden llevar a cabo ataques enviando encabezados inválidos al intermediario y asegurándose de que los nodos de referencia del intermediario no vean bloques equivalentes antes de su publicación. Sin embargo, el intermediario sigue siendo susceptible a ataques de equivalencia más generales.
![Paradigm: Explorando la relación entre MEV-Boost y el mecanismo de consenso de Ethereum])https://img-cdn.gateio.im/webp-social/moments-00fb5ee47056beb2efc3ca4ac271a69c.webp(
) dirección futura
Dado esto, la comunidad de investigación debería evaluar qué cantidad de reestructuraciones es "aceptable" y considerar los riesgos derivados de un ataque equivalente para determinar si se necesitan medidas de mitigación.
Actualmente se están explorando activamente múltiples direcciones futuras:
En general, estamos emocionados por la energía reavivada en torno al MEV y el ecosistema relacionado. A través de este evento, entendimos la relación clave entre la latencia, ciertos protocolos y los mecanismos de consenso; esperamos que los protocolos puedan seguir fortaleciéndose.
![Paradigm: Explorando la relación entre MEV-Boost y el mecanismo de consenso de Ethereum]###https://img-cdn.gateio.im/webp-social/moments-9db8f9a0944e1eff6bde4db0c8343fbe.webp(