Los antecedentes y la motivación de EIP-7732
Dado que los problemas de MEV son difíciles de resolver desde su raíz, tomar medidas para nivelar el campo de juego es la única forma de evitar riesgos de seguridad. Después de la fusión de Ethereum, para mantener la equidad y reducir el efecto de escala de los grandes grupos de promesas en la extracción de MEV, Flashbots lanzó MEV-Boost, que utiliza el mecanismo PBS (Proposer-Builder Separation) para reducir las oportunidades de participación directa de los validadores. en las actividades MEV y convertir la diversidad de partes interesadas de MEV. En la actualidad, la proporción de bloques MEV-Boost ha superado el 90%.
Con la adopción generalizada de MEV-Boost, la comunidad Ethereum comenzó a preocuparse por los riesgos de seguridad que pueden surgir al depender de este servicio de terceros, por lo que nació la idea de implementar PBS dentro del protocolo Ethereum, llamado ePBS (. Separación Proponente-Constructor Consagrado). Recientemente, a ePBS se le asignó un número EIP oficial: EIP-7732. EIP-7732 es un cambio en la capa de consenso sin requerir cambios en la capa de ejecución. El núcleo es separar lógica y temporalmente la verificación de ejecución de la verificación de consenso y posponer la verificación de ejecución hasta que se complete la verificación de consenso.
La propuesta de EIP-7732, además de resolver el problema de los verificadores que dependen de terceros (como MEV-Boost) para crear cargas útiles de ejecución, también tiene como objetivo optimizar la eficiencia del proceso de verificación. Los validadores actuales deben completar todos los consensos y realizar funciones de transición de estado en un tiempo muy corto (en 4 segundos), lo que impone exigencias extremadamente altas en los recursos informáticos y el ancho de banda de la red. Durante este período de ventana, los validadores deben verificar y confirmar una gran cantidad de información de transacciones y actualizar el estado de la cadena de bloques, lo que no solo aumenta la carga computacional de un solo nodo, sino que también aumenta la posibilidad de errores. Al separar la verificación de ejecución y la verificación de consenso, se garantiza que los nodos solo necesiten completar relativamente pocas tareas dentro de la ventana crítica de 4 segundos, lo que reduce la carga computacional y acelera la propagación de la red.
El contenido principal de EIP-7732
EIP-7732 crea un nuevo rol "Constructor", una nueva responsabilidad opcional para los validadores que puede ser utilizada por cualquier validador con fondos suficientes para apostar en la cadena de balizas y la capacidad de realizar tareas de construcción de bloques. Conviértase en constructor. El constructor es responsable de crear y enviar promesas para la ejecución de la carga útil. Los validadores ahora pueden subcontratar la ejecución de cargas útiles a los constructores, mientras se centran más en tareas a nivel de consenso.
La carga útil de ejecución es la parte central del bloque y contiene toda la información de cambios de estado y transacciones. El proceso de creación de una carga útil de ejecución incluye seleccionar transacciones del grupo de memoria, ordenar transacciones, ejecutar transacciones en secuencia y empaquetar toda la información para formar una carga útil de ejecución.
Para lograr esta separación, EIP-7732 elimina el campo ExecutionPayload, que contiene todos los datos relacionados con la ejecución de la transacción, como la lista de transacciones y los resultados de la transición de estado. Al eliminar este campo, la creación y verificación del contenido de ejecución se separa de la creación y verificación del bloque de baliza. Como alternativa, EIP-7732 introduce una nueva estructura de datos, SignedExecutionPayloadHeader, que incluye la promesa del constructor de una carga útil de ejecución que se revelará en el futuro.
proceso general
Tareas del constructor: el constructor es responsable de crear la carga útil de ejecución y generar una promesa que expondrá la carga útil de ejecución. La promesa está encapsulada en una estructura de datos SignedExecutionPayloadHeader, que incluye un hash de la carga útil de ejecución y una firma digital de este hash para garantizar la inmutabilidad de los datos y la verificación del origen. Esta promesa indica que el constructor expondrá la carga útil de ejecución completa en algún momento determinado en el futuro y especifica una cantidad que se pagará al proponente del bloque de baliza para incentivarlo a incluir esta promesa.
Las tareas del proponente del bloque de baliza: el proponente del bloque de baliza (validador) coopera con el constructor y no necesita tratar directamente con los detalles de ejecución de la transacción al crear un nuevo bloque de baliza, sino que incluye el compromiso proporcionado por el constructor. y luego transmitir todo el bloque de baliza a la red Ethereum para llegar a un consenso. Incluir solo compromisos reduce la carga sobre la red y acelera la propagación de bloques de balizas y el proceso de verificación de consenso. Una vez procesado el compromiso del constructor, la propina del compromiso se deduce del saldo de la cadena de baliza del constructor y se acredita al proponente del bloque de baliza. Después de que un proponente de bloque de baliza transmite con éxito un bloque de baliza con un compromiso, el constructor debe exponer la carga útil de ejecución completa dentro de un período de tiempo específico.
Verificación de PTC: para monitorear si los constructores ejecutan públicamente las cargas útiles de manera oportuna, un grupo de validadores seleccionados al azar por la red Beacon Chain forman el Comité de puntualidad de la carga útil (PTC). El PTC es responsable de verificar si el constructor ha expuesto una carga útil de ejecución que coincida con la promesa dentro del período de tiempo especificado. Si el constructor no informa de manera oportuna y correcta, PTC transmitirá un resultado negativo y el constructor enfrentará una multa de reducción de la apuesta. Si se aprueba la verificación de PTC, la verificación completa de la carga útil de ejecución se difiere para procesarse por separado durante el siguiente bloque de baliza, es decir, la verificación diferida.
Además, la propuesta también introduce normas regulatorias y un nuevo mecanismo de sanción para PTC para garantizar el rigor y la equidad de todo el proceso de verificación. Al mismo tiempo, debido a la separación de las cargas útiles de ejecución y los bloques de balizas, la lógica de selección de bifurcaciones también se ha ajustado para adaptarse al nuevo proceso de verificación. Se espera que estos cambios mejoren significativamente la seguridad y la eficiencia de la red. A través de una serie de diseños, EIP-7732 mejora la eficiencia de procesamiento de Ethereum y reduce la latencia de la red.
