EIP-7732: qué cambia ePBS en Ethereum

En Ethereum, proponer un bloque y construir su contenido son tareas que pueden realizar participantes distintos. La forma en que se coordinan influye en el trabajo de los validadores y en la entrega de las transacciones que formarán parte del bloque. EIP-7732 propone incorporar reglas para esa coordinación dentro del propio protocolo.

La propuesta afecta a validadores, constructores de bloques y clientes de Ethereum. Para entenderla conviene seguir qué recibe cada participante y qué debe comprobar antes de continuar. Se trata de un cambio de protocolo que debe evaluarse por su especificación e implementación, no de una función que una dApp pueda activar mediante una biblioteca.

Qué significa ePBS

PBS separa dos responsabilidades: seleccionar y proponer un bloque, y construir el conjunto ordenado de transacciones que contiene. La «e» de ePBS indica que parte de esa coordinación pasa a estar incorporada en las reglas del protocolo. El objetivo es reducir la dependencia de intermediación externa en el intercambio entre proponentes y constructores.

En la especificación EIP-7732, consultada el 11 de octubre de 2026, la propuesta figura en estado Last Call, con cierre previsto de esa fase el 1 de noviembre de 2026. Ese estado editorial no demuestra por sí solo una activación en mainnet. Para conocer una activación concreta hay que comprobar además el anuncio de la actualización y las versiones de los clientes.

Cómo reorganiza la validación

La propuesta separa en el tiempo la validación del consenso y la de la ejecución. El bloque de consenso incorpora un compromiso firmado del constructor; el payload de ejecución se revela después. Un comité de validadores informa de si ese contenido llegó a tiempo. Informar de puntualidad no equivale a certificar que cada transacción sea válida.

Este reparto pretende aliviar trabajo en el tramo crítico del slot. La ejecución sigue necesitando validación: se cambia su coordinación, no se elimina la comprobación de las reglas. La especificación también define cómo gestionar pagos y situaciones en las que un participante incumple.

Qué no se puede deducir de la propuesta

ePBS no promete por sí sola transacciones más baratas para cada usuario ni una cifra universal de rendimiento. El resultado depende de otras reglas del protocolo, de los clientes, de la demanda y de la estructura del mercado de construcción de bloques.

Tampoco demuestra que ese mercado vaya a quedar repartido entre muchos operadores. Conviene separar el cambio de un mecanismo de coordinación de sus posibles efectos económicos. Estos últimos requieren observar participación, concentración y comportamiento cuando exista una implementación evaluable.

Qué debe comprobar un operador

• La versión de la especificación y la actualización a la que se vincula.
• Los anuncios de sus clientes de consenso y ejecución, con requisitos y versiones compatibles.
• Las pruebas en redes de ensayo y el comportamiento de monitorización, alertas y recuperación.
• Los cambios en las dependencias externas que utilice para construir o proponer bloques.

Una fecha tentativa en una hoja de ruta no debe convertirse en una fecha de operación. El proceso de propuestas y sus estados está descrito en EIP-1; el despliegue necesita además coordinación e implementaciones concretas.

Qué ocurre si el contenido llega tarde

La separación obliga a distinguir el compromiso del constructor, la disponibilidad del payload y la validez de su ejecución. En una prueba de cliente, recibir el bloque de consenso no debería interpretarse como prueba de que todas esas condiciones ya se han cumplido. El comité de puntualidad aporta una observación específica, mientras el protocolo conserva las comprobaciones de ejecución.

Para un operador, esto se traduce en señales de monitorización diferentes. Un retraso de red, un payload ausente y una ejecución inválida no describen el mismo incidente. La evaluación en redes de ensayo debe comprobar cómo el cliente informa de cada caso y qué efecto tiene en las obligaciones del validador.

La fecha de cierre de Last Call pertenece al proceso editorial de la EIP. No debe utilizarse como fecha de activación ni como plazo para una migración de producto. La especificación y los anuncios operativos cumplen funciones distintas.

Qué significa para un equipo de producto

Para una aplicación, la tarea inmediata es identificar si el cambio afecta a los supuestos que utiliza: confirmaciones, datos del nodo, integraciones de infraestructura o gestión de transacciones. No corresponde reescribir contratos solo porque aparezca una nueva EIP.

Una evaluación útil vincula cada supuesto a una prueba y a un responsable. En Metlabs seguimos los cambios de protocolo dentro del desarrollo sobre Ethereum, distinguiendo especificación, implementación y comportamiento observado. Ese criterio permite actualizar una integración cuando corresponde y evita convertir una propuesta técnica en una promesa comercial.