Antes de leer este artículo, debe tener una comprensión básica de MEV, el papel de Flashbot y el impacto de Flashbot en MEV.
También es necesario conocer los conocimientos básicos del mecanismo PoS y los cambios provocados por The Merge.
MEV
Primero, revisa qué es MEV.
El valor extraíble del minero se refiere literalmente al "valor que puede extraer un desarrollador de bloques".
Este valor no se refiere a la tarifa pagada por el usuario al desarrollador del bloque para empaquetar la transacción del usuario en el bloque. La acción de dar tarifas es acordada por el usuario, y el usuario puede ajustar la tarifa muy baja, de modo que su transacción se cobrará durante mucho tiempo, pero al menos el desarrollador del bloque no puede cobrar ninguna tarifa por la transacción.
*Consejo de lectura: MEV ahora pasa a llamarse Valor Máximo Extraíble, ya que el desarrollo actual de MEV ya no es exclusivo de los desarrolladores de bloques. *
"El valor que un desarrollador de bloques puede exprimir" se refiere al hecho de que un desarrollador de bloques obtiene ganancias cambiando el orden de las transacciones, insertando sus propias transacciones y antes (o después) de las transacciones que se explotan. Entonces, ¿qué tipo de beneficios pueden obtener los desarrolladores de bloques?
Por ejemplo, cuando un NFT caliente ofrece tragamonedas de acuñación, y solo las 100 personas más rápidas pueden acuñar con éxito, entonces Carol, que es amiga del desarrollador de bloques o ha llegado a algún tipo de acuerdo con el desarrollador de bloques fuera de la cadena, puede asegurarse de que el desarrollador de bloques pueda colocar su transacción de acuñación antes que la transacción de acuñación de otra persona organizando el orden de transacción.
△ Los desarrolladores de bloques priorizarán las transacciones de acuñación de Carol antes que las de otras personas.
Otro MEV común es una transacción AMM que pellizca a los usuarios, obligándolos a recibir el peor precio (dentro del rango aceptable), y la diferencia entre el precio esperado del usuario y el peor precio es la ganancia exprimida por el desarrollador del bloque.
En el siguiente ejemplo, Alice espera intercambiar 1 WBTC por 21,500 USDT, pero sabe que en el mundo descentralizado, su transacción puede no ser la primera en ejecutarse, y cuando otra persona también comercia con WBTC/USDT antes que ella, el precio de AMM cambiará y 1 WBTC no se puede intercambiar por 21,500 USDT, por lo que establece un peor precio de 20,500 USDT dentro del rango aceptable:
△Alice espera cambiar 1 WBTC por 21,500 USDT, pero en el peor de los casos puede aceptar 20,500 USDT.
En este momento, Eve descubrió la transacción de Alice y decidió vender WBTC antes de la transacción de Alice, lo que provocó que el precio de WBTC cayera a 20,500 USDT, y luego ejecutando la transacción de Alice, Alice se vio obligada a operar a un precio de 20,500 USDT.
Finalmente, Eve recompra WBTC con los USDT obtenidos de la venta de WBTC al principio, y el precio de WBTC será inferior a 20,500 USDT, lo que significa que Eve ha completado un mínimo de compra y un máximo de venta (< comprar a 20,500 y vender a 21,500) y ganar la diferencia de precio.
△ A la desarrolladora de bloques Eve le resultó rentable vender WBTC antes de la transacción de Alice, y luego volvió a comprar WBTC para ganar el spread después de que se ejecutara la transacción de Alice.
Los sistemas descentralizados deben tener MEV
En un sistema centralizado, puede optar por confiar en los roles responsables de secuenciar las transacciones (Operador, Secuenciador) y confiar en que no harán nada malo que perjudique al usuario por el bien de la reputación, o puede optar por abandonar el sistema. Esta es también la situación actual de L2, y es poco probable que las partes del proyecto L2 rompan sus propios letreros para extraer MEV.
Pero en un sistema descentralizado, cualquiera puede convertirse en un desarrollador de bloques, y no podemos demostrar simple y objetivamente que el comportamiento de un desarrollador de bloques es "malo", lo que significa que no podemos prohibir efectivamente que los desarrolladores de bloques exploten las ganancias.
No debemos esperar que los desarrolladores de bloques sean "buenas personas", pero debemos preocuparnos de que si un desarrollador de bloques gana más y más dinero debido a MEV e invierte en más equipos de desarrollo de bloques, se hará cada vez más grande, lo que hará que elimine a otros competidores, y el resultado será un dilema de solo un desarrollador de bloques en un sistema descentralizado, y eventualmente podrá imponer reglas de preferencia personal en las transacciones de los usuarios a voluntad. Y es por eso que nació Flashbot.
Flashbot
Con el fin de evitar que MEV afecte el grado de descentralización de los desarrolladores de bloques, Flashbot ha hecho de MEV un mercado abierto donde los desarrolladores de bloques y los buscadores profesionales de MEV cooperan y comparten MEV, y existe un alto grado de competencia entre los desarrolladores de bloques y los buscadores de MEV.
A través de esta competencia y asociaciones, los desarrolladores de bloques y los buscadores de MEV pueden centrarse en su propia especialidad, y los buscadores de MEV no tienen que preocuparse de que los desarrolladores de bloques puedan robar sus oportunidades de arbitraje o no aceptar deliberadamente sus propias transacciones.
△ El buscador encuentra transacciones del grupo de negociación abierto para arbitrar y puja por los derechos de ingresos de sus propios paquetes, que se entregan a Flashbot y luego son seleccionados por el desarrollador del bloque.
Riesgo de centralización
Sin embargo, Flashbot todavía tiene un inconveniente, todas las transacciones de arbitraje de buscadores MEV tienen que pasar por un servidor Flashbot centralizado, que puede robar oportunidades de arbitraje o revisar transacciones de arbitraje.
Además de Flashbot, también han aparecido en el mercado proyectos como Eden Network. Es básicamente la misma arquitectura que Flashbot, excepto por su propio staking innecesario, prioridad de transacción dentro del bloque y mecanismos de oferta adicionales. Pero al menos cuando Flashbot comienza a hacer el mal, los desarrolladores de bloques y los buscadores tienen otras opciones.
MEV es un hecho establecido que debe ser aceptado
Tanto los diseñadores de protocolos como los usuarios deben estar atentos a MEV. Si es posible, incorporar MEV en el diseño del protocolo y hacer de MEV una herramienta útil es algo en lo que los diseñadores de protocolos deben pensar al diseñar mecanismos en el futuro. En artículos posteriores también se tratará el diseño y las ideas para hacer un buen uso de MEV.
La Fusión
Ethereum ha cambiado al mecanismo PoS después de The Merge, y de ser un desarrollador de bloques que compite con la potencia de cálculo de las máquinas mineras a hacer staking de ETH, puede convertirse en un Validador para tener la oportunidad de proponer bloques, lo que significa que el umbral para obtener bloques en PoS es mucho más bajo. La reducción del umbral para obtener oportunidades de generación de bloques en realidad afecta la competencia y la cooperación entre los diferentes roles en Flashbot.
*Consejo de lectura: Proponer aquí se mantiene en inglés para evitar malinterpretar el chino de proponer bloque y construir bloque porque el significado es demasiado cercano. *
Cambio en la relación de confianza
Antes de PoS, Searcher necesitaba confiar en que el desarrollador del bloque no arrebataría el contenido de su paquete, e incluso si el desarrollador del bloque lo hiciera, Searcher solo podría contrarrestar a través de mecanismos fuera de la cadena, como presentar evidencia para pedirle a Flashbot que incluya al desarrollador del bloque en la lista negra o publicar una publicación en Twitter para cerrarlo.
Sin embargo, los desarrolladores de bloques son básicamente muy cooperativos, porque la relación entre el desarrollador de bloques y el Buscador es una cooperación a largo plazo, y si el desarrollador de bloques toma el Buscador para obtener un cierto beneficio de MEV hoy, y el desarrollador de bloques no recibirá ninguna oportunidad de MEV en el futuro, no valdrá la pena.
Sin embargo, después de PoS, puede tener la oportunidad de producir bloques haciendo staking de ETH, y el umbral para producir bloques se reduce. Como resultado, muchas personas comunes se unen como validadores, lo que resulta en la posibilidad de que los bloques se diluyan lentamente.
En comparación con los pocos grupos de minería que han invertido muchos costos en PoW y han estado operando durante mucho tiempo, el Validador en PoS solo ocasionalmente puede tener la oportunidad de generar bloques, y su recompensa de bloque más la tasa anualizada promedio de MEV se calcula incluso si es del 10%, el Validador todavía tiene un incentivo muy suficiente para obtener el MEV del Buscador.
Consejos de lectura: Puede consultar la tabla de clasificación de MEV de estadísticas de Flashbot, copie el enlace a continuación para saltar al navegador y ver contenido relacionado:*
△ Siempre que aproveches la oportunidad de obtener más de 3.2 ETH de MEV, superará el 10% anualizado.
Por lo tanto, la arquitectura de Flashbot debe ajustarse para que coincida con el cambio de relación de confianza y el mecanismo PoS, y se ha convertido en el mev-boost actual.
mev-boost
En mev-boost, el rol de Relay entre el Searcher y el desarrollador de bloques del Flashbot se ha dividido en dos, uno es el Builder y el otro se llama Relay pero con diferentes responsabilidades.
El Buscador entrega el paquete al Constructor, quien selecciona varios paquetes de varios paquetes para formar un bloque, y le entrega el bloque al Relé, quien a su vez selecciona uno de los bloques enviados por el Relé.
△ El Buscador compite con el Buscador, el Constructor compite con el Constructor y el Validador elige el bloque más ventajoso de él.
El Constructor es responsable de encontrar la combinación de paquetes más favorable en la capacidad limitada de un bloque, con la esperanza de que el Validador elija su propio bloque.
Entonces, ¿para qué sirve Relay? Como se mencionó anteriormente, la relación de confianza ha cambiado, por lo que el Buscador/Constructor no puede confiar en el Validador, por lo que el Validador en mev-boost debe hacer una promesa de "Propondré tu bloque" antes de recibir el contenido real del bloque.
Relay actúa como intermediario entre el Constructor y el Validador para ayudar a coordinar: Relay mantiene el contenido del bloque hasta que obtiene la promesa del Validador antes de entregar el bloque realizado por el Constructor al Validador.
En la terminología real de la cadena de balizas de Ethereum, el contenido del bloque creado por el constructor se denomina carga útil de ution, y el validador recibirá datos de Relay llamados encabezado de carga útil de ution, que puede considerarse como un compromiso de carga útil, y la firma del encabezado representa la carga útil de firma.
Cuando el Validador elige qué bloque proponer al Relé, colocará el encabezado de carga útil del bloque en el bloque de baliza y lo firmará, y luego entregará el contenido firmado al Relay como prueba, y finalmente el Relé puede estar seguro de que el contenido del bloque se entregará al Validador y le permitirá proponer el bloque.
△ El Constructor entrega el bloque al Relé, y el Relé entrega el Encabezado al Validador
△ Si el Validador selecciona el bloque, el Encabezado se colocará en el Bloque de Baliza, se firmará y se entregará al Relé.
△ A continuación, Relay entrega el fragmento completo al validador.
Si el Validador finalmente traiciona a Relay y elige proponer otro bloque, entonces Relay puede publicar la firma que el Validador le dio como evidencia de que el Validador propuso dos bloques diferentes, y entonces el Validador será penalizado por violar las reglas de la Ethereum Beacon Chain.
△ Eve fue recortado (parte del ETH prometido fue confiscado) porque propuso un bloque diferente.
Hipótesis de la confianza
En mev-boost, el Validador debe confiar en Relay, si el contenido del bloque finalmente revelado por Relay no es legal, o el dinero real recibido por el Validador no es el esperado, o incluso si el Relay directamente no publica el contenido del bloque, el Validador no puede proponer el bloque, entonces el Validador solo puede contrarrestar a través de un mecanismo fuera de la cadena, como informar a otros Validadores del comportamiento malicioso del Relay.
Disyuntor
Los validadores no pueden ser monitoreados e intervenidos las 24 horas del día, por lo que cuando el software del validador encuentra que (el mismo relé o más) está constantemente rompiendo la confianza, debe ser capaz de reaccionar para evitar perder ingresos todo el tiempo porque no hay bloques de propuestas.
Por ejemplo, cuando descubra que no ha propuesto un bloque para más de cinco ranuras, debe volver atrás y usar su propio nodo para crear el contenido del bloque.
Para ver los documentos pertinentes, consulte:
Monitor de relés
Con el fin de reducir el impacto de las fechorías del personaje de Relay, la comunidad de Flashbot también está pensando en diseñar un monitoreo del comportamiento de Relay.
Para ver los documentos pertinentes, consulte:
Disponibilidad de datos C****ommittee
Una forma de evitar que Relay no publique el contenido de un bloque es dar los datos del bloque a un comité de nodos que son responsables de mantener y garantizar que el contenido del bloque esté disponible, es decir, descentralizar la responsabilidad de mantener el contenido del bloque.
¿Qué constructores y relés están disponibles actualmente? **
Aquí puedes ver el Constructor y el Relé actuales:
MEV-Boost
Visite el sitio web:
Como puede ver, aunque es el equipo de desarrollo principal de mev-boost, Flashbot no tiene el estado de relé dominante, porque Flashbot ha desarrollado mev-boost desde el principio y no se ha establecido como el relé predeterminado en el software mev-boost.
Consejos de lectura: Más información, por favor vea
2023–04–02 Ataque contra el relé mev-boost
Un validador malintencionado descubrió una vulnerabilidad en Relay: Relay devolverá el contenido del paquete al validador siempre que tenga una firma válida para verificar (ya sea que el contenido sea legítimo o no).
Por lo tanto, el validador malintencionado firma un contenido no válido (los valores de algunos campos del encabezado no son válidos) y, después de que Relay devuelve el contenido del paquete, el validador roba la transacción de arbitraje en el paquete y, a continuación, propone otro bloque válido.
Relay intenta transmitir el encabezado firmado por el Validador, pero es rechazado por otros nodos porque el contenido no es válido, por lo que todos solo ven el bloque válido propuesto por el propio Validador. Posteriormente, el Validador fue Cortado y expulsado de la lista de Validadores por firmar dos encabezados diferentes (para Relay y Proposed), pero el daño ya estaba hecho.
El Relay actualizado ahora intentará transmitir primero el encabezado del Validador, si es recibido con éxito por otros nodos, significa que el contenido del signo del Validador es legítimo, y los otros nodos verán primero el bloque transmitido por Relay, si el Validador intenta robar el contenido del paquete y proponerlo él mismo, será más difícil ganar el bloque transmitido por Relay (porque ya hay muchos nodos que han visto el bloque transmitido por Relay).
Consejo de lectura 1: Explique el hilo de este ataque y las pruebas relacionadas y los parches de Relay, consulte este hilo, consulte este hilo para obtener más detalles:
*Consejo de lectura 2: Además de robar las transacciones de arbitraje de los paquetes, los validadores maliciosos también pueden atacar a los arbitrajistas que realizan huelgas sándwich: los arbitrajistas que realizan huelgas sándwich insertarán sus propias operaciones antes y después de la operación de la víctima: comprando preventivamente a la víctima y luego vendiendo después de que la víctima compre para ganar el spread, pero para que el clipper tenga éxito, ambas operaciones deben ejecutarse, de lo contrario, solo se ejecutará la transacción anterior, pero el arbitrajista no solo no ganará el spread, sino que también perderá sus propios fondos. *
Sin embargo, los parches realizados en respuesta a este ataque aumentarán el tiempo de retraso de la producción de bloques, por lo que el número de ocurrencias de reorganización de la cadena PoS ha aumentado significativamente en los días posteriores al ataque, y actualmente se están diseñando e implementando varias soluciones para evitar la inestabilidad de la red PoS causada por el retraso de MEV-Boost.
Consejo de lectura: Para obtener información detallada, puede copiar el siguiente enlace para verlo en su navegador
Impacto de Flashbot/mev-boost
Afecta a la eficiencia de la votación de los validadores
Debido a Flashbot/mev-boost, el proceso de un bloque desde la producción hasta la propuesta real ha pasado por más niveles, lo que conduce al retraso de tiempo del bloque propuesto por el validador, y otros validadores responsables de votar recibirán el bloque más tarde, por lo que su tiempo de votación se comprimirá, lo que afectará la seguridad de la red PoS en general.
Si bien no parece un gran impacto: una disminución estimada del 2% en la participación y una disminución del 1% en los validadores que votaron correctamente, esto es de octubre de 2022, cuando solo un tercio de los validadores estaban conectados a MEV Relay.
Consejo de lectura: Para obtener más información, consulte el artículo vinculado a continuación
Resumen y aspectos destacados
MEV es inevitable, y los desarrolladores de bloques tienen la mayor ventaja de minar MEV. Flashbot convierte la minería MEV en un mercado abierto, evitando que la centralización de los mineros afecte a la seguridad de toda la cadena.
mev-boost nació en respuesta a los cambios provocados por PoS, mev-boost invierte la relación de confianza entre el Buscador/Constructor y el Validador, y hace que la competencia sea más abierta: hay múltiples Constructores compitiendo entre sí, y múltiples Relay compitiendo entre sí, reduciendo aún más el riesgo de centralización de Flashbot.
En el próximo artículo, presentaremos Proposer-Builder Separation (PBS), que integra la arquitectura mev-boost directamente en el propio protocolo de Ethereum, en lugar de una colaboración privada entre Validator, Builder y Searcher, lo que hará que todo el ecosistema MEV sea más descentralizado y seguro.
Datos de referencia y recomendaciones para lecturas adicionales
*Estadística:
*Estadística:
*
Ver originales
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.
MEV después de la fusión de Ethereum
Autor: Nic @ imToken Labs
Consejos de lectura
MEV
Primero, revisa qué es MEV.
El valor extraíble del minero se refiere literalmente al "valor que puede extraer un desarrollador de bloques".
Este valor no se refiere a la tarifa pagada por el usuario al desarrollador del bloque para empaquetar la transacción del usuario en el bloque. La acción de dar tarifas es acordada por el usuario, y el usuario puede ajustar la tarifa muy baja, de modo que su transacción se cobrará durante mucho tiempo, pero al menos el desarrollador del bloque no puede cobrar ninguna tarifa por la transacción.
*Consejo de lectura: MEV ahora pasa a llamarse Valor Máximo Extraíble, ya que el desarrollo actual de MEV ya no es exclusivo de los desarrolladores de bloques. *
"El valor que un desarrollador de bloques puede exprimir" se refiere al hecho de que un desarrollador de bloques obtiene ganancias cambiando el orden de las transacciones, insertando sus propias transacciones y antes (o después) de las transacciones que se explotan. Entonces, ¿qué tipo de beneficios pueden obtener los desarrolladores de bloques?
Por ejemplo, cuando un NFT caliente ofrece tragamonedas de acuñación, y solo las 100 personas más rápidas pueden acuñar con éxito, entonces Carol, que es amiga del desarrollador de bloques o ha llegado a algún tipo de acuerdo con el desarrollador de bloques fuera de la cadena, puede asegurarse de que el desarrollador de bloques pueda colocar su transacción de acuñación antes que la transacción de acuñación de otra persona organizando el orden de transacción.
△ Los desarrolladores de bloques priorizarán las transacciones de acuñación de Carol antes que las de otras personas.
Otro MEV común es una transacción AMM que pellizca a los usuarios, obligándolos a recibir el peor precio (dentro del rango aceptable), y la diferencia entre el precio esperado del usuario y el peor precio es la ganancia exprimida por el desarrollador del bloque.
En el siguiente ejemplo, Alice espera intercambiar 1 WBTC por 21,500 USDT, pero sabe que en el mundo descentralizado, su transacción puede no ser la primera en ejecutarse, y cuando otra persona también comercia con WBTC/USDT antes que ella, el precio de AMM cambiará y 1 WBTC no se puede intercambiar por 21,500 USDT, por lo que establece un peor precio de 20,500 USDT dentro del rango aceptable:
△Alice espera cambiar 1 WBTC por 21,500 USDT, pero en el peor de los casos puede aceptar 20,500 USDT.
En este momento, Eve descubrió la transacción de Alice y decidió vender WBTC antes de la transacción de Alice, lo que provocó que el precio de WBTC cayera a 20,500 USDT, y luego ejecutando la transacción de Alice, Alice se vio obligada a operar a un precio de 20,500 USDT.
Finalmente, Eve recompra WBTC con los USDT obtenidos de la venta de WBTC al principio, y el precio de WBTC será inferior a 20,500 USDT, lo que significa que Eve ha completado un mínimo de compra y un máximo de venta (< comprar a 20,500 y vender a 21,500) y ganar la diferencia de precio.
△ A la desarrolladora de bloques Eve le resultó rentable vender WBTC antes de la transacción de Alice, y luego volvió a comprar WBTC para ganar el spread después de que se ejecutara la transacción de Alice.
Los sistemas descentralizados deben tener MEV
En un sistema centralizado, puede optar por confiar en los roles responsables de secuenciar las transacciones (Operador, Secuenciador) y confiar en que no harán nada malo que perjudique al usuario por el bien de la reputación, o puede optar por abandonar el sistema. Esta es también la situación actual de L2, y es poco probable que las partes del proyecto L2 rompan sus propios letreros para extraer MEV.
Pero en un sistema descentralizado, cualquiera puede convertirse en un desarrollador de bloques, y no podemos demostrar simple y objetivamente que el comportamiento de un desarrollador de bloques es "malo", lo que significa que no podemos prohibir efectivamente que los desarrolladores de bloques exploten las ganancias.
No debemos esperar que los desarrolladores de bloques sean "buenas personas", pero debemos preocuparnos de que si un desarrollador de bloques gana más y más dinero debido a MEV e invierte en más equipos de desarrollo de bloques, se hará cada vez más grande, lo que hará que elimine a otros competidores, y el resultado será un dilema de solo un desarrollador de bloques en un sistema descentralizado, y eventualmente podrá imponer reglas de preferencia personal en las transacciones de los usuarios a voluntad. Y es por eso que nació Flashbot.
Flashbot
Con el fin de evitar que MEV afecte el grado de descentralización de los desarrolladores de bloques, Flashbot ha hecho de MEV un mercado abierto donde los desarrolladores de bloques y los buscadores profesionales de MEV cooperan y comparten MEV, y existe un alto grado de competencia entre los desarrolladores de bloques y los buscadores de MEV.
A través de esta competencia y asociaciones, los desarrolladores de bloques y los buscadores de MEV pueden centrarse en su propia especialidad, y los buscadores de MEV no tienen que preocuparse de que los desarrolladores de bloques puedan robar sus oportunidades de arbitraje o no aceptar deliberadamente sus propias transacciones.
△ El buscador encuentra transacciones del grupo de negociación abierto para arbitrar y puja por los derechos de ingresos de sus propios paquetes, que se entregan a Flashbot y luego son seleccionados por el desarrollador del bloque.
Riesgo de centralización
Sin embargo, Flashbot todavía tiene un inconveniente, todas las transacciones de arbitraje de buscadores MEV tienen que pasar por un servidor Flashbot centralizado, que puede robar oportunidades de arbitraje o revisar transacciones de arbitraje.
Además de Flashbot, también han aparecido en el mercado proyectos como Eden Network. Es básicamente la misma arquitectura que Flashbot, excepto por su propio staking innecesario, prioridad de transacción dentro del bloque y mecanismos de oferta adicionales. Pero al menos cuando Flashbot comienza a hacer el mal, los desarrolladores de bloques y los buscadores tienen otras opciones.
MEV es un hecho establecido que debe ser aceptado
Tanto los diseñadores de protocolos como los usuarios deben estar atentos a MEV. Si es posible, incorporar MEV en el diseño del protocolo y hacer de MEV una herramienta útil es algo en lo que los diseñadores de protocolos deben pensar al diseñar mecanismos en el futuro. En artículos posteriores también se tratará el diseño y las ideas para hacer un buen uso de MEV.
La Fusión
Ethereum ha cambiado al mecanismo PoS después de The Merge, y de ser un desarrollador de bloques que compite con la potencia de cálculo de las máquinas mineras a hacer staking de ETH, puede convertirse en un Validador para tener la oportunidad de proponer bloques, lo que significa que el umbral para obtener bloques en PoS es mucho más bajo. La reducción del umbral para obtener oportunidades de generación de bloques en realidad afecta la competencia y la cooperación entre los diferentes roles en Flashbot.
*Consejo de lectura: Proponer aquí se mantiene en inglés para evitar malinterpretar el chino de proponer bloque y construir bloque porque el significado es demasiado cercano. *
Cambio en la relación de confianza
Antes de PoS, Searcher necesitaba confiar en que el desarrollador del bloque no arrebataría el contenido de su paquete, e incluso si el desarrollador del bloque lo hiciera, Searcher solo podría contrarrestar a través de mecanismos fuera de la cadena, como presentar evidencia para pedirle a Flashbot que incluya al desarrollador del bloque en la lista negra o publicar una publicación en Twitter para cerrarlo.
Sin embargo, los desarrolladores de bloques son básicamente muy cooperativos, porque la relación entre el desarrollador de bloques y el Buscador es una cooperación a largo plazo, y si el desarrollador de bloques toma el Buscador para obtener un cierto beneficio de MEV hoy, y el desarrollador de bloques no recibirá ninguna oportunidad de MEV en el futuro, no valdrá la pena.
Sin embargo, después de PoS, puede tener la oportunidad de producir bloques haciendo staking de ETH, y el umbral para producir bloques se reduce. Como resultado, muchas personas comunes se unen como validadores, lo que resulta en la posibilidad de que los bloques se diluyan lentamente.
En comparación con los pocos grupos de minería que han invertido muchos costos en PoW y han estado operando durante mucho tiempo, el Validador en PoS solo ocasionalmente puede tener la oportunidad de generar bloques, y su recompensa de bloque más la tasa anualizada promedio de MEV se calcula incluso si es del 10%, el Validador todavía tiene un incentivo muy suficiente para obtener el MEV del Buscador.
△ Siempre que aproveches la oportunidad de obtener más de 3.2 ETH de MEV, superará el 10% anualizado.
Por lo tanto, la arquitectura de Flashbot debe ajustarse para que coincida con el cambio de relación de confianza y el mecanismo PoS, y se ha convertido en el mev-boost actual.
mev-boost
En mev-boost, el rol de Relay entre el Searcher y el desarrollador de bloques del Flashbot se ha dividido en dos, uno es el Builder y el otro se llama Relay pero con diferentes responsabilidades.
El Buscador entrega el paquete al Constructor, quien selecciona varios paquetes de varios paquetes para formar un bloque, y le entrega el bloque al Relé, quien a su vez selecciona uno de los bloques enviados por el Relé.
△ El Buscador compite con el Buscador, el Constructor compite con el Constructor y el Validador elige el bloque más ventajoso de él.
El Constructor es responsable de encontrar la combinación de paquetes más favorable en la capacidad limitada de un bloque, con la esperanza de que el Validador elija su propio bloque.
Entonces, ¿para qué sirve Relay? Como se mencionó anteriormente, la relación de confianza ha cambiado, por lo que el Buscador/Constructor no puede confiar en el Validador, por lo que el Validador en mev-boost debe hacer una promesa de "Propondré tu bloque" antes de recibir el contenido real del bloque.
Relay actúa como intermediario entre el Constructor y el Validador para ayudar a coordinar: Relay mantiene el contenido del bloque hasta que obtiene la promesa del Validador antes de entregar el bloque realizado por el Constructor al Validador.
En la terminología real de la cadena de balizas de Ethereum, el contenido del bloque creado por el constructor se denomina carga útil de ution, y el validador recibirá datos de Relay llamados encabezado de carga útil de ution, que puede considerarse como un compromiso de carga útil, y la firma del encabezado representa la carga útil de firma.
Cuando el Validador elige qué bloque proponer al Relé, colocará el encabezado de carga útil del bloque en el bloque de baliza y lo firmará, y luego entregará el contenido firmado al Relay como prueba, y finalmente el Relé puede estar seguro de que el contenido del bloque se entregará al Validador y le permitirá proponer el bloque.
△ El Constructor entrega el bloque al Relé, y el Relé entrega el Encabezado al Validador
△ Si el Validador selecciona el bloque, el Encabezado se colocará en el Bloque de Baliza, se firmará y se entregará al Relé.
△ A continuación, Relay entrega el fragmento completo al validador.
Si el Validador finalmente traiciona a Relay y elige proponer otro bloque, entonces Relay puede publicar la firma que el Validador le dio como evidencia de que el Validador propuso dos bloques diferentes, y entonces el Validador será penalizado por violar las reglas de la Ethereum Beacon Chain.
△ Eve fue recortado (parte del ETH prometido fue confiscado) porque propuso un bloque diferente.
Hipótesis de la confianza
En mev-boost, el Validador debe confiar en Relay, si el contenido del bloque finalmente revelado por Relay no es legal, o el dinero real recibido por el Validador no es el esperado, o incluso si el Relay directamente no publica el contenido del bloque, el Validador no puede proponer el bloque, entonces el Validador solo puede contrarrestar a través de un mecanismo fuera de la cadena, como informar a otros Validadores del comportamiento malicioso del Relay.
Disyuntor
Los validadores no pueden ser monitoreados e intervenidos las 24 horas del día, por lo que cuando el software del validador encuentra que (el mismo relé o más) está constantemente rompiendo la confianza, debe ser capaz de reaccionar para evitar perder ingresos todo el tiempo porque no hay bloques de propuestas.
Por ejemplo, cuando descubra que no ha propuesto un bloque para más de cinco ranuras, debe volver atrás y usar su propio nodo para crear el contenido del bloque.
Para ver los documentos pertinentes, consulte:
Monitor de relés
Con el fin de reducir el impacto de las fechorías del personaje de Relay, la comunidad de Flashbot también está pensando en diseñar un monitoreo del comportamiento de Relay.
Para ver los documentos pertinentes, consulte:
Disponibilidad de datos C****ommittee
Una forma de evitar que Relay no publique el contenido de un bloque es dar los datos del bloque a un comité de nodos que son responsables de mantener y garantizar que el contenido del bloque esté disponible, es decir, descentralizar la responsabilidad de mantener el contenido del bloque.
¿Qué constructores y relés están disponibles actualmente? **
Aquí puedes ver el Constructor y el Relé actuales:
Visite el sitio web:
Como puede ver, aunque es el equipo de desarrollo principal de mev-boost, Flashbot no tiene el estado de relé dominante, porque Flashbot ha desarrollado mev-boost desde el principio y no se ha establecido como el relé predeterminado en el software mev-boost.
Consejos de lectura: Más información, por favor vea
2023–04–02 Ataque contra el relé mev-boost
Un validador malintencionado descubrió una vulnerabilidad en Relay: Relay devolverá el contenido del paquete al validador siempre que tenga una firma válida para verificar (ya sea que el contenido sea legítimo o no).
Por lo tanto, el validador malintencionado firma un contenido no válido (los valores de algunos campos del encabezado no son válidos) y, después de que Relay devuelve el contenido del paquete, el validador roba la transacción de arbitraje en el paquete y, a continuación, propone otro bloque válido.
Relay intenta transmitir el encabezado firmado por el Validador, pero es rechazado por otros nodos porque el contenido no es válido, por lo que todos solo ven el bloque válido propuesto por el propio Validador. Posteriormente, el Validador fue Cortado y expulsado de la lista de Validadores por firmar dos encabezados diferentes (para Relay y Proposed), pero el daño ya estaba hecho.
El Relay actualizado ahora intentará transmitir primero el encabezado del Validador, si es recibido con éxito por otros nodos, significa que el contenido del signo del Validador es legítimo, y los otros nodos verán primero el bloque transmitido por Relay, si el Validador intenta robar el contenido del paquete y proponerlo él mismo, será más difícil ganar el bloque transmitido por Relay (porque ya hay muchos nodos que han visto el bloque transmitido por Relay).
Consejo de lectura 1: Explique el hilo de este ataque y las pruebas relacionadas y los parches de Relay, consulte este hilo, consulte este hilo para obtener más detalles:
*Consejo de lectura 2: Además de robar las transacciones de arbitraje de los paquetes, los validadores maliciosos también pueden atacar a los arbitrajistas que realizan huelgas sándwich: los arbitrajistas que realizan huelgas sándwich insertarán sus propias operaciones antes y después de la operación de la víctima: comprando preventivamente a la víctima y luego vendiendo después de que la víctima compre para ganar el spread, pero para que el clipper tenga éxito, ambas operaciones deben ejecutarse, de lo contrario, solo se ejecutará la transacción anterior, pero el arbitrajista no solo no ganará el spread, sino que también perderá sus propios fondos. *
Sin embargo, los parches realizados en respuesta a este ataque aumentarán el tiempo de retraso de la producción de bloques, por lo que el número de ocurrencias de reorganización de la cadena PoS ha aumentado significativamente en los días posteriores al ataque, y actualmente se están diseñando e implementando varias soluciones para evitar la inestabilidad de la red PoS causada por el retraso de MEV-Boost.
Consejo de lectura: Para obtener información detallada, puede copiar el siguiente enlace para verlo en su navegador
Impacto de Flashbot/mev-boost
Afecta a la eficiencia de la votación de los validadores
Debido a Flashbot/mev-boost, el proceso de un bloque desde la producción hasta la propuesta real ha pasado por más niveles, lo que conduce al retraso de tiempo del bloque propuesto por el validador, y otros validadores responsables de votar recibirán el bloque más tarde, por lo que su tiempo de votación se comprimirá, lo que afectará la seguridad de la red PoS en general.
Si bien no parece un gran impacto: una disminución estimada del 2% en la participación y una disminución del 1% en los validadores que votaron correctamente, esto es de octubre de 2022, cuando solo un tercio de los validadores estaban conectados a MEV Relay.
Consejo de lectura: Para obtener más información, consulte el artículo vinculado a continuación
Resumen y aspectos destacados
En el próximo artículo, presentaremos Proposer-Builder Separation (PBS), que integra la arquitectura mev-boost directamente en el propio protocolo de Ethereum, en lugar de una colaboración privada entre Validator, Builder y Searcher, lo que hará que todo el ecosistema MEV sea más descentralizado y seguro.
Datos de referencia y recomendaciones para lecturas adicionales
*Estadística: *Estadística: *