Ethereum: las listas de acceso por bloque llegan a su plazo de última consulta

Una consulta sobre el trabajo de los nodos

El documento oficial de la EIP-7928 señala el 1 de noviembre de 2026 como plazo de última consulta. La propuesta de Ethereum, creada el 31 de marzo de 2025 y desarrollada por varios colaboradores, sigue mostrando Last Call al verificarse. Describe listas de acceso a escala de bloque, o BAL, que identifican las partes del estado utilizadas. La fecha es un hito de revisión, no una prueba de adopción definitiva ni de una aceleración ya disponible en la red principal.

El problema es práctico. Para procesar operaciones en paralelo, un nodo necesita saber previamente qué cuentas y posiciones de almacenamiento se leerán o modificarán. Las listas opcionales adjuntas a algunas transacciones no ofrecen una garantía suficiente. El proyecto propone un inventario obligatorio por bloque con los accesos efectivos y los valores resultantes de los cambios. Los beneficios esperados afectan a las lecturas de disco, la validación y el cálculo de la raíz del estado.

Un inventario que debe coincidir con la ejecución

El mecanismo añadiría a la cabecera del bloque una huella criptográfica de la lista. Los datos detallados se codificarían por separado y viajarían entre las capas de consenso y ejecución mediante Engine API. El nodo comprobaría después que el inventario coincide exactamente con los accesos producidos al ejecutar. Las entradas ausentes, incorrectas o injustificadas podrían invalidar el bloque. El inventario no es una indicación que el validador deba creer sin comprobar.

La lista cubre direcciones consultadas aunque no cambien, posiciones de almacenamiento y modificaciones de saldos, código o contadores. Distingue también las operaciones previas a las transacciones, las propias transacciones y las posteriores a la ejecución. Las reglas imponen un orden determinista e impiden duplicados. Esta precisión busca que distintos programas calculen la misma representación, necesaria para comparar sus huellas sin ambigüedad.

Mejoras previstas con costes adicionales

El texto contempla lecturas paralelas y reconstrucción del estado desde los cambios registrados, sin volver a ejecutar cada transacción para esa reconstrucción. Esto no elimina la obligación de validar los bloques. Cita un análisis de mil bloques de octubre de 2026, en un marco de 60 millones de gas, con listas comprimidas de unos 92,1 kibibytes de media. La muestra ilustra un coste de datos adicional, no garantiza el rendimiento en todos los usos.

La propuesta reconoce el riesgo de lecturas de almacenamiento artificiales que impongan trabajo de entrada y salida innecesario antes de detectarse. Un límite vinculado al gas del bloque acota el número de elementos y los clientes deben evitar rechazar listas válidas. Cambiar la estructura del bloque y Engine API requeriría un hard fork. Para los operadores, sigue siendo un equilibrio entre paralelización, transmisión y verificación. El paso del 1 de noviembre no convierte este trabajo de normalización en un despliegue concluido.