Qu'est-ce que BAL (EIP-7928), et pourquoi est-il considéré comme une condition préalable à l'exécution parallèle

BAL (EIP-7928) est couramment qualifié de « condition préalable à l’exécution parallèle » dans les échanges sur Glamsterdam. Ce terme n’indique pas que toutes les transactions seront exécutées instantanément en parallèle, mais signifie que les relations d’accès à l’état passent d’hypothèses implicites à des contraintes explicites et vérifiables. La planification stable n’est possible que lorsque ces contraintes sont précisément définies.

Cette couche de contraintes est directement liée aux objectifs de mise à niveau exposés dans la vue d’ensemble de la mise à niveau Glamsterdam et complète le mécanisme ePBS (EIP-7732) : ePBS fixe les limites de collaboration pour la production de blocs, tandis que BAL définit le périmètre des contraintes d’exécution. L’impact de Glamsterdam sur les DApps illustre comment les modifications de cette couche de contraintes influent à la fois sur la performance attendue des applications et sur le rythme des mises en production.

Qu’est-ce que BAL (EIP-7928) ?

BAL désigne les Block-Level Access Lists, c’est-à-dire des listes d’accès au niveau du bloc qui recensent les comptes et emplacements de stockage sollicités lors de l’exécution du bloc, et peuvent également inclure les résultats d’état post-exécution. L’objectif n’est pas de remplacer le moteur d’exécution, mais de lui fournir plus tôt des informations claires pour la détection des conflits et la préparation des données.

L’exécution sérielle traditionnelle garantit la cohérence, mais atteint rapidement ses limites en matière d’efficacité sous forte sollicitation. Pour permettre l’exécution parallèle, il faut d’abord répondre à la question : « Quelles transactions entrent en conflit ? » L’intérêt de BAL réside dans le fait de déplacer la détection des conflits du temps d’exécution vers une phase de planification en amont. Selon la feuille de route Ethereum.org et EIP-7928, BAL constitue une proposition centrale pour la mise à niveau Glamsterdam.

Pourquoi Ethereum a-t-il besoin des Block-Level Access Lists ?

Avec la complexification des blocs, si les relations de lecture/écriture d’état ne sont révélées qu’à l’exécution, les clients ne peuvent pas anticiper les chemins d’exécution. Même avec un matériel puissant, l’efficacité peut chuter à cause des conflits de retour arrière et d’une planification répétée.

Les listes d’accès au niveau du bloc réduisent le risque de « découverte des conflits uniquement à l’exécution ». En définissant les contraintes en amont, les clients préparent les données, répartissent les tâches et isolent les conflits, ce qui limite les fluctuations aléatoires de performance. Pour des rôles tels que les services d’indexation ou les nœuds d’archive, qui lisent massivement l’état, la connaissance préalable des accès optimise aussi la planification des E/S.

Ce tableau montre que BAL modifie la « disponibilité de l’information » plutôt que de dicter uniquement le débit final.

Comment BAL aide-t-il les clients à identifier les conflits et optimiser la planification ?

Les clients utilisent la liste d’accès pour prendre deux décisions majeures : diviser les transactions en « ensembles parallélisables » et conserver les « chemins qui doivent rester sériels ». Même si le parallélisme total n’est pas atteignable, les segments à faible conflit peuvent être optimisés en priorité, élargissant progressivement le champ du parallélisme.

D’un point de vue technique, BAL n’apporte pas un pic de performance ponctuel, mais améliore la prévisibilité du comportement d’exécution. Pour les équipes d’exploitation des nœuds, la prévisibilité est souvent plus précieuse que des pointes de performance à court terme, car elle influe directement sur les SLA et la gestion des incidents. Les variations de taux de conflit et de retours arrière sur les testnets sont des métriques clés pour évaluer l’efficacité de BAL.

Figure 1. Illustration du mécanisme BAL : comment les listes d’accès au niveau du bloc soutiennent la détection des conflits et la planification de l’exécution parallèle.

Quel est le lien entre BAL et l’exécution parallèle ?

BAL n’est pas un « substitut » à l’exécution parallèle, mais sa « couche préalable ». Pour atteindre l’exécution parallèle, il faut également une implémentation client, des stratégies de planification et une gestion de l’état coordonnées. Sans contraintes fondamentales, le parallélisme forcé accroît souvent l’incertitude.

En d’autres termes, BAL transforme l’exécution parallèle d’un concept théorique en un objectif d’ingénierie. Il répond à la question « les prérequis sont-ils réunis ? », et non « la performance maximale est-elle atteinte ? » Même avec l’introduction de stratégies de parallélisme plus poussées, les contraintes d’accès de BAL restent essentielles pour la gestion des conflits.

Que signifie BAL pour les développeurs et les équipes applicatives ?

Les développeurs doivent porter une attention accrue aux schémas d’accès à l’état. Les conceptions impliquant des écritures fréquentes sur le même état, des dépendances complexes entre contrats ou des traitements groupés de transactions peuvent présenter de nouveaux comportements d’exécution sous ces contraintes. Les applications doivent être testées sur leurs chemins d’exécution avant lancement, et pas uniquement sur le plan fonctionnel.

Les équipes produit doivent également ajuster leur communication sur la performance. Après la mise à niveau, les gains d’expérience utilisateur peuvent ne pas être linéaires, surtout pendant la phase d’adaptation de l’écosystème. L’approche prudente consiste à utiliser des métriques progressives : valider la stabilité, les taux d’échec et les percentiles de latence, et non seulement les moyennes. Les réinitialisations de métriques et les déploiements progressifs doivent s’aligner sur le cadre d’adaptation des applications.

Quelles sont les limites de mise en œuvre et les défis potentiels de BAL ?

Le premier défi est d’assurer la cohérence inter-clients. Différents clients d’exécution peuvent interpréter les listes d’accès et les stratégies de planification de façon différente, ce qui nécessite une convergence continue via des comparaisons sur testnet et des régressions inter-clients, avec des snapshots de métriques datés.

Le deuxième défi concerne le coût d’apprentissage pour l’écosystème. Si les équipes de développement négligent la structure d’accès à l’état, des écarts de performance peuvent apparaître après la mise à niveau ; les contrats existants n’ont pas forcément été écrits selon des schémas d’accès adaptés, ce qui nécessite outils et temps de migration.

Le troisième défi est la mise à jour des systèmes de monitoring. Les équipes d’exploitation doivent disposer de nouveaux indicateurs liés aux contraintes d’accès pour déterminer si les problèmes proviennent de la préparation des données, des conflits de planification ou de goulots d’étranglement du moteur d’exécution. Sans évolution du monitoring, la valeur du mécanisme ne peut être pleinement exploitée. Pour la checklist de préparation à la mise à niveau des nœuds, les logs liés à BAL et les taux de rollback de conflit doivent faire partie des critères d’acceptation. Dans le contexte de la comparaison Glamsterdam vs. Dencun/Fusaka, ces défis sont des risques structurels spécifiques qui ne peuvent être résolus par une simple montée en capacité.

Résumé

BAL (EIP-7928) traite l’ordre d’exécution en rendant explicites les relations d’accès à l’état, en structurant la détection des conflits et en passant d’une planification réactive à une planification vérifiable. S’il ne garantit pas à lui seul le succès de la mise à niveau, il est essentiel à une exécution parallèle stable et constitue un mécanisme de contrainte fondamental dans la couche d’exécution Glamsterdam.

FAQ

BAL (EIP-7928) est-il l’exécution parallèle elle-même ?

Non. BAL est la couche de contrainte préalable à l’exécution parallèle, servant de socle à la détection des conflits. L’exécution parallèle dépend également de l’implémentation client et des stratégies de planification.

Pourquoi BAL influe-t-il sur la performance réelle ?

En rendant explicites à l’avance les relations d’accès à l’état, les clients peuvent préparer les données et regrouper les tâches en amont, ce qui réduit les retours arrière de conflit à l’exécution et améliore la stabilité des traitements.

Quelle est la répartition des responsabilités entre BAL et ePBS (EIP-7732) ?

ePBS concerne les limites de collaboration pour la production de blocs, tandis que BAL s’attache aux frontières des contraintes d’exécution. Chacun agit à un niveau distinct et ils sont complémentaires dans Glamsterdam.

Comment les équipes DApp doivent-elles s’adapter à l’introduction de BAL ?

Analyser les schémas d’accès à l’état et les chemins de transactions à haute fréquence, compléter les tests de comportement d’exécution avant et après la mise à niveau, et ajuster le monitoring ainsi que les seuils d’alerte pour ne plus se baser sur d’anciennes hypothèses d’exécution.

BAL garantit-il que toutes les transactions sont traitées en parallèle ?

Non. BAL fournit la détection des conflits et les informations pour la planification, mais les transactions à fort conflit doivent toujours être traitées de façon sérielle. Le degré de parallélisme dépend des schémas d’accès, de l’implémentation client et des caractéristiques de charge du réseau.