BAL (EIP-7928) suele considerarse la "precondición para la ejecución en paralelo" en los debates sobre Glamsterdam. Este término no significa que todas las transacciones se ejecuten en paralelo de forma inmediata; implica que las relaciones de acceso al estado dejan de ser supuestos implícitos y pasan a ser restricciones explícitas y verificables. Solo cuando estas restricciones están claramente establecidas es posible lograr una programación estable.
Esta capa de restricciones está directamente relacionada con los objetivos de actualización descritos en la Descripción general de la actualización Glamsterdam y complementa el mecanismo ePBS (EIP-7732): ePBS define los límites para la colaboración en la producción de bloques, mientras que BAL delimita los límites de las restricciones de ejecución. El artículo El impacto de Glamsterdam en las DApp muestra cómo los cambios en la capa de restricciones afectan tanto a las expectativas de rendimiento de las aplicaciones como al ritmo de liberación.
¿Qué es BAL (EIP-7928)?
BAL significa Block-Level Access Lists, que registran las cuentas y slots de almacenamiento accedidos durante la ejecución de un bloque y pueden incluir los resultados del estado tras la ejecución. El objetivo no es sustituir el motor de ejecución, sino facilitarle una detección de conflictos más temprana y precisa, así como datos para la preparación previa.
La ejecución secuencial tradicional garantiza la consistencia de forma sencilla, pero pronto alcanza sus límites de eficiencia bajo cargas intensas. Para conseguir ejecución en paralelo, primero hay que responder: "¿Qué transacciones entran en conflicto entre sí?" El valor de BAL reside en trasladar la detección de conflictos del tiempo de ejecución a una fase previa y planificable. Según la hoja de ruta de Ethereum.org y EIP-7928, BAL es una propuesta clave para la actualización Glamsterdam.
¿Por qué Ethereum necesita Block-Level Access Lists?
A medida que los bloques ganan complejidad, si las relaciones de lectura/escritura del estado solo se revelan dinámicamente en tiempo de ejecución, los clientes no pueden planificar rutas de ejecución con antelación. Incluso con hardware suficiente, la eficiencia se resiente por conflictos de retroceso y reprogramaciones.
Las listas de acceso a nivel de bloque reducen la probabilidad de "descubrir conflictos solo durante la ejecución". Con restricciones claras desde el principio, los clientes pueden preparar los datos, dividir tareas y aislar conflictos, minimizando las fluctuaciones aleatorias en el rendimiento. Para servicios como la indexación y los nodos archivo, que realizan lecturas intensivas del estado, conocer de antemano las relaciones de acceso también ayuda a optimizar la planificación de I/O.
| Etapa de ejecución |
Sin restricciones previas |
Con restricciones BAL |
| Detección de conflictos |
Retroceso durante la ejecución |
Predicción previa a la ejecución |
| Preparación de datos |
Carga dinámica |
Agrupación previa posible |
| Estrategia de programación |
Basada en experiencia |
Basada en reglas |
Esta tabla muestra que BAL transforma la "disponibilidad de la información" más que imponer un rendimiento final concreto.
¿Cómo ayuda BAL a los clientes a identificar conflictos y optimizar la programación?
Los clientes pueden usar la lista de acceso para tomar dos decisiones clave: dividir las transacciones en "conjuntos paralelizables" y mantener "rutas que deben ser secuenciales". Aunque el paralelismo total no sea posible, los segmentos con pocos conflictos pueden optimizarse primero, ampliando progresivamente el alcance del paralelismo.
Desde la ingeniería, BAL no genera un pico de rendimiento puntual, sino que mejora la previsibilidad del comportamiento de ejecución. Para los equipos de operaciones de nodos, la previsibilidad es a menudo más valiosa que los picos a corto plazo, ya que repercute directamente en los SLA y la respuesta ante incidentes. Las variaciones en las tasas de conflicto y retroceso en las redes de prueba son métricas clave para evaluar la eficacia de BAL.
| Etapa de programación |
Sin restricciones previas |
Con restricciones BAL |
| Preparación previa a la ejecución |
Basada en estimaciones |
Agrupación previa por lista de acceso |
| Gestión de conflictos |
Retrocesos frecuentes en ejecución |
Aislamiento temprano de conflictos |
| Estabilidad de resultados |
Muy variable |
Resultados más previsibles |
| Monitoreo de operaciones |
Difícil establecer umbrales |
Métricas estructuradas posibles |
Figura 1. Ilustración del mecanismo BAL: cómo las listas de acceso a nivel de bloque apoyan la detección de conflictos y la programación de la ejecución en paralelo.
¿Cuál es la relación entre BAL y la ejecución en paralelo?
BAL no es un "sustituto" de la ejecución en paralelo, sino su "capa previa indispensable". Para lograr ejecución en paralelo, también es necesario que la implementación del cliente, las estrategias de programación y la gestión del estado trabajen coordinadamente. Sin restricciones fundamentales, forzar el paralelismo suele aumentar la incertidumbre.
En resumen, BAL convierte la ejecución en paralelo de un concepto teórico en un objetivo técnico alcanzable. Responde a la pregunta "¿están los requisitos previos listos?", no a "¿se ha logrado el máximo rendimiento?". Incluso cuando se implementen estrategias de paralelismo más agresivas, las restricciones de acceso de BAL seguirán siendo esenciales para la gestión de conflictos.
¿Qué implica BAL para desarrolladores y equipos de aplicaciones?
Los desarrolladores deben vigilar más de cerca los patrones de acceso al estado. Los diseños con escrituras frecuentes en el mismo estado, dependencias complejas entre contratos o agrupaciones de transacciones pueden mostrar nuevos comportamientos de ejecución bajo estas restricciones. Las aplicaciones deben someterse a pruebas de rutas de ejecución antes de lanzarse, no solo a verificaciones funcionales.
Los equipos de producto también deben ajustar la comunicación sobre el rendimiento. Las mejoras en la experiencia del usuario tras la actualización pueden no ser lineales, especialmente mientras el ecosistema se adapta. La estrategia prudente es usar métricas por fases: confirmar estabilidad, tasas de fallo y percentiles de latencia, no solo promedios. Los restablecimientos de métricas y los lanzamientos por etapas deben estar alineados con el framework de adaptación de la aplicación.
¿Cuáles son los límites de implementación y los desafíos potenciales de BAL?
El primer reto es lograr la coherencia entre clientes. Distintos clientes de ejecución pueden interpretar de forma diferente las listas de acceso y las estrategias de programación, lo que exige una convergencia continua mediante pruebas en testnets y regresión cruzada, con instantáneas métricas con sello temporal.
El segundo reto es el coste de aprendizaje para el ecosistema. Si los equipos de desarrollo ignoran las estructuras de acceso al estado, pueden aparecer desviaciones de rendimiento tras la actualización; los contratos heredados pueden no haberse diseñado para un acceso eficiente, lo que requiere herramientas y tiempo para la migración.
El tercer reto es actualizar los sistemas de monitoreo. Los equipos de operaciones necesitan nuevas métricas relacionadas con las restricciones de acceso para identificar si los problemas provienen de la preparación de datos, los conflictos de programación o los cuellos de botella del motor de ejecución. Sin monitoreo actualizado, el mecanismo no puede desplegar todo su valor. Para la Lista de verificación para la actualización de nodos, los registros relacionados con BAL y las tasas de retroceso por conflicto deben incluirse en los criterios de aceptación. En la Comparación Glamsterdam vs. Dencun/Fusaka, estos retos son riesgos estructurales propios y no pueden resolverse solo con experiencia en ampliaciones de capacidad.
Resumen
BAL (EIP-7928) aborda el orden de ejecución al hacer explícitas las relaciones de acceso al estado, estructurar la detección de conflictos y trasladar la programación de un enfoque reactivo a una planificación verificable. Aunque no determina por sí solo el éxito de la actualización, es esencial para una ejecución en paralelo estable y constituye un mecanismo de restricción central en la capa de ejecución de Glamsterdam.
Preguntas frecuentes
¿BAL (EIP-7928) es la ejecución en paralelo en sí misma?
No. BAL es la capa de restricciones previa para la ejecución en paralelo, y proporciona la base para la detección de conflictos. La ejecución en paralelo también depende de la implementación del cliente y de las estrategias de programación.
¿Por qué BAL afecta al rendimiento real?
Al hacer explícitas las relaciones de acceso al estado por adelantado, los clientes pueden preparar datos y agrupar tareas antes, lo que reduce los retrocesos por conflictos en tiempo de ejecución y mejora la estabilidad de la ejecución.
¿Cómo se dividen las responsabilidades entre BAL y ePBS (EIP-7732)?
ePBS se ocupa de los límites de colaboración en la producción de bloques y BAL de los límites de las restricciones de ejecución. Cada uno opera en una capa distinta y ambos son complementarios en Glamsterdam.
¿Cómo deben responder los equipos de DApp ante la introducción de BAL?
Revisar los patrones de acceso al estado y las rutas de transacciones de alta frecuencia, complementar las pruebas de comportamiento de ejecución antes y después de la actualización, y actualizar el monitoreo del rendimiento y los umbrales de alerta para no basarse en supuestos de ejecución obsoletos.
¿Puede BAL garantizar que todas las transacciones se procesen en paralelo?
No. BAL proporciona detección de conflictos y datos para la programación, pero las transacciones con muchos conflictos deben seguir procesándose de forma secuencial. El alcance del paralelismo depende de los patrones de acceso, la implementación del cliente y las características de carga de la red.
