Los validadores de Ethereumestán listos para asumir nuevos roles con la introducción de EIP-7732, la propuesta de separación entre proponentes y constructores consagrada.
Esta propuesta cambia fundamentalmente la forma en que se validan los bloques Ethereum al dividir la validación de ejecución de la validación de consenso tanto lógica como temporalmente.
Los validadores se revisan
Los validadores ahora tienen nuevas responsabilidades, incluida la opción de convertirse en constructores y el deber de presentar certificaciones de puntualidad de la carga útil.
El EIP aborda varios problemas clave del sistema actual. La mayoría de los proponentes de bloques de baliza subcontratan la construcción de la carga útil de ejecución a un tercero, conocido como constructor.
Solicitan la raíz del árbol hash (HTR) de una carga útil de ejecución prometida y envían un SignedBlindedBeaconBlock a una entidad de confianza. Esta entidad reemplaza el HTR con la carga útil de ejecución completa del constructor antes de la transmisión.
El EIP garantiza intercambios justos entre el proponente del bloque baliza y el constructor. Garantiza que el constructor pague al proponente honesto del bloque baliza y que su carga útil se convierta en la cabeza canónica de la cadena.
Actualmente, los validadores tienen una ventana corta para realizar transiciones de estado de consenso y ejecución, verificar la disponibilidad de datos de blobs y evaluar la nueva cabecera de la cadena de bloques.
Este EIP cambia eso al separar la ejecución y la validación de consenso, lo que permite a los validadores centrarse en la transición del estado de consenso antes de realizar la certificación.
Se difiere la ejecución y la validación de la disponibilidad de los datos, lo que permite que los validadores realicen estas tareas en el tiempo restante.
Motivación detrás de EIP-7732
Eliminar la carga útil de ejecución completa del bloque de consenso permite una propagación más rápida de la red. Reduce la probabilidad de reorganización al incluir transacciones de blobs debido al aumento de los plazos para las comprobaciones de disponibilidad de datos.
Los validadores ya no omiten las atestaciones, lo que refuerza las propiedades de elección de bifurcación cuando los constructores generan cargas útiles no válidas. El EIP también elimina la necesidad de middleware confiable para la delegación de la construcción de bloques.
El EIP no requiere cambios en la capa de ejecución. Sin embargo, la capa de consenso sufre varias modificaciones, detalladas en el repositorio de GitHub de especificaciones de consenso.
Estos incluyen cambios en la Beacon Chain, elección de bifurcación, protocolos P2P, guías de validación y la introducción de una nueva guía de construcción.
Los cambios en la cadena Beacon involucran constantes, ajustes preestablecidos y varias clases de contenedores para manejar las nuevas atestaciones de carga útil y los encabezados de carga útil de ejecución firmada.
El contenedor BeaconState se modifica para tracel último hash de bloque, la última ranura con una carga útil de ejecución y la última raíz de retiros.
El BeaconBlockBody ahora incluye un encabezado de carga útil de ejecución firmado y una lista de atestrías de carga útil. El ExecutionPayloadHeader se ha simplificado para tracinformación mínima sobre los compromisos de carga útil del constructor.
Los cambios en la lógica de transición de estado incluyen nuevas funciones para procesar atestaciones de carga útil, encabezados de carga útil de ejecución y solicitudes de retiro.
Los cambios en la selección de bifurcaciones implican nuevas constantes y clases contenedoras para gestionar nodos secundarios, mensajes recientes y modificaciones de la tienda. Se introducen nuevos controladores para mensajes de atestación de carga útil y sobres de carga útil de ejecución firmada.
Reportaje de Jai Hamid
