couche exécution

Au cours des deux dernières années, il est devenu évident que l’augmentation du TPS à elle seule ne suffit plus à résoudre le problème de la scalabilité des blockchains. Le principal goulot d’étranglement se déplace progressivement de la couche de consensus vers la couche d’exécution, où les transactions entrent en concurrence pour un état partagé et génèrent des conflits dans un contexte d’ exécution parallèle.

Les recherches de 2025 confirment ce basculement. L’étude NEMO montre que même les réseaux à haut débit subissent une dégradation des performances due aux conflits d’écriture, et que le parallélisme sans mécanismes de gestion des conflits ne se traduit pas par une véritable scalabilité. Dans Efficient Parallel Execution of Blockchain Transactions Leveraging Conflict Specifications (2025), il est démontré que des gains de performance significatifs ne sont obtenus que lorsque les ensembles de lecture/écriture sont explicitement définis et contrôlés au niveau des transactions.

En pratique, cela signifie que la scalabilité des réseaux blockchain dépend désormais bien moins du mécanisme de consensus que de l’architecture d’exécution — de la conception de l’état et de l’optimisation des accès jusqu’à l’ordonnancement des charges et à la résolution des conflits en conditions de forte charge. Ces tendances et approches d’ingénierie ont été commentées par Alexander Kalankhodzhaev, Core Engineer Lead chez Raiku, dans une interview accordée à The Crypto Updates.

Déplacement du focus : du réseau vers l’exécution

La haute capacité de transmission du réseau est depuis longtemps un prérequis, et bénéficiant des avancées dans de nombreux secteurs. Les blockchains tirent parti de ces progrès, mais les tentatives d’amélioration radicale de la couche réseau, comme DoubleZero, restent coûteuses et difficiles à déployer à l’échelle mondiale. Par ailleurs, la couche applicative du réseau — algorithmes de consensus et communication P2P — est déjà relativement mature et évolue principalement par optimisations incrémentales. Des initiatives comme Alpenglow de Solana illustrent ces progrès, sans pour autant transformer fondamentalement les limites de la scalabilité.

À l’inverse, la couche d’exécution demeure un domaine relativement jeune. Les premières blockchains reposaient sur un traitement strictement séquentiel des transactions, tandis que des systèmes plus récents intègrent le parallélisme dès leur conception. En pratique, nombre de ces approches ont dû être repensées. Le parallélisme introduit également de nouvelles contraintes : contention sur l’état, comptes « chauds », conflits, complexité de planification et surcoûts de synchronisation.

A lire aussi :   White-Label Cartes : leurs coûts et les alternatives possibles

Ainsi, c’est désormais l’architecture d’exécution — organisation de l’état, schémas d’accès et gestion des conflits — qui détermine de plus en plus la scalabilité.

Expérience utilisateur : la prédictibilité avant la vitesse

L’expérience utilisateur est influencée par la latence, les frais et la prédictibilité, mais en situation de forte charge, c’est cette dernière qui devient déterminante. Il est essentiel de savoir si une transaction sera incluse dans un délai raisonnable ou rejetée selon des règles claires. L’incertitude est perçue comme plus problématique que des frais modérément élevés.

La latence moyenne, prise isolément, est peu représentative. La latence de queue (tail latency) est beaucoup plus critique : en période de congestion, une fraction des transactions subit des retards importants, ce qui dégrade fortement l’expérience globale.

Les frais restent le coût le plus visible, mais les utilisateurs acceptent souvent de payer davantage lorsque l’inclusion des transactions est fiable et que les résultats d’exécution sont stables. Ce sont les conflits et la contention au niveau de l’exécution qui transforment une blockchain « rapide en laboratoire » en système instable sous charge réelle.

Nouvelle compétition : non plus le TPS, mais l’architecture d’exécution

Le TPS reste en grande partie une métrique marketing. Dans des environnements contrôlés, il est possible d’atteindre presque n’importe quel niveau de débit, ce qui rend ces chiffres peu représentatifs des performances réelles.

L’attention se déplace vers des indicateurs plus pertinents, tels que le débit effectif en présence de contention et le comportement du système sous charge maximale. Ces métriques reflètent mieux les conditions de production.

La compétition entre blockchains se joue désormais sur l’architecture de la couche d’exécution, notamment :

  • la capacité à maintenir le parallélisme après résolution des conflits ;
  • la manière dont le système se dégrade face à l’augmentation de la contention ;
  • les garanties offertes aux utilisateurs et aux développeurs — équité, déterminisme et transparence des règles d’inclusion.

C’est à ce niveau que la scalabilité réelle devient visible.

prochaine génération blockchains

Architecture de l’état : maintenir performance et stabilité

Plusieurs choix architecturaux permettent d’améliorer à la fois les performances et la stabilité :

  • le sharding et le partitionnement de l’état pour réduire les points chauds ;
  • la minimisation de l’état global partagé ;
  • une gestion déterministe des conflits ;
  • un ordonnancement tenant compte de la charge (par exemple, prioriser les transactions qui débloquent d’autres opérations) ;
  • des mécanismes de limitation d’exécution et de backpressure pour éviter les défaillances en cascade.

La conception de la couche d’exécution reste un domaine en évolution rapide, riche en nouvelles approches.

A lire aussi :   BITVAVO : fonctionnement des marchés boursiers hors des heures d’ouverture

Responsabilité partagée : protocole et applications

La responsabilité de la scalabilité est de plus en plus partagée entre le protocole et les développeurs d’applications. Les protocoles modernes fournissent des primitives pour une exécution sûre et scalable, mais leur utilisation efficace exige une compréhension approfondie du système.

Les développeurs doivent prendre en compte les modalités d’accès à l’état, les garanties d’exécution et les mécanismes de gestion des conflits. Un mauvais design de l’état ne peut pas être compensé par le parallélisme : il devient un goulot d’étranglement, même sur des infrastructures avancées.

Vers de nouveaux modèles d’exécution

L’exécution parallèle n’est plus une option, mais une nécessité imposée par l’évolution du matériel. Parmi les approches émergentes, les modèles fondés sur la définition explicite des ensembles de lecture/écriture ou des spécifications de conflits apparaissent comme les plus prometteurs.

Ils permettent d’anticiper les dépendances entre transactions, de planifier l’exécution de manière déterministe, d’éviter les calculs inutiles et de maintenir un débit stable, même en cas de forte contention. En contrepartie, la responsabilité des développeurs augmente, ce qui devrait favoriser l’émergence de nouveaux outils et abstractions.

Une nouvelle économie portée par l’exécution

Les évolutions de la couche d’exécution commencent déjà à transformer l’économie des blockchains. Grâce à une meilleure visibilité sur les conflits et l’impact des transactions, les validateurs peuvent aller au-delà d’une simple priorisation par les frais et privilégier celles qui réduisent la contention ou maximisent le parallélisme.

Du côté des utilisateurs, les frais reflètent de plus en plus non seulement le coût computationnel, mais aussi l’accès à un état rare ou fortement sollicité. L’architecture d’exécution devient ainsi un véritable primitif économique, influençant les règles d’inclusion, la formation des frais et la perception de l’équité au sein du système.

 

LAISSER UN COMMENTAIRE

Please enter your comment!
Please enter your name here