---
id: 2
title: "Exécution parallèle multi-moteur de Bitroot : ordonnancement, sharding et surface de conflit"
slug: bitroot-evm
date: 2026/08/07
summary: Une plongée dans l'exécution parallèle multi-moteur — comment les moteurs se partagent les transactions, comment l'état est shardé pour l'accès, comment la concurrence optimiste et la détection de conflits en trois étapes limitent la réexécution — et comment lire l'accélération par rapport au taux de conflit dans des conditions de testnet.
keywords: parallélisme multi-moteur,EVM,sharding d'état,détection de conflits,Bitroot
heroImage: /cms-media/file/4In%20depth%20analysis%20of%20Bitroot.jpg
---

Le goulot d'étranglement de l'EVM monothread ne vient pas de « Solidity est lent » ; il tient à la sémantique d'exécution sérielle et à l'absence de mécanisme de contention de verrous sur l'état partagé. Le parallélisme multi-moteur est une question d'ingénierie : comment répartir les transactions d'un bloc entre plusieurs contextes d'exécution sans jeter tout le bloc en cas de conflit. Voies du secteur : [Trois voies vers l'exécution parallèle](/fr/blog/parallel-execution-approaches). Cet article se concentre sur la conception multi-moteur côté Bitroot. Squelette théorique : [Introduction à l'OCC](/fr/blog/optimistic-concurrency-control-intro) — cet article ne reprend pas l'histoire en quatre phases des bases de données.

## Objectif de conception : parallèle, mais rejouable

Les conceptions multi-moteur exigent généralement :

- des contextes d'exécution relativement indépendants par moteur, réduisant les verrous globaux ;
- un état partitionné par compte ou par emplacement de stockage, afin que les moteurs privilégient les shards locaux et réduisent la synchronisation inter-moteurs ;
- des ordonnanceurs qui pré-analysent et regroupent par lots, en gardant les transactions liées sur le même moteur ou dans le même lot pour réduire les allers-retours ;
- des validations finales équivalentes à une exécution sérielle selon l'ordre du consensus (relecture déterministe).

Comment le consensus émet rapidement l'ordre : [Pipeline BFT et découplage de l'exécution](/fr/blog/bitroot-pipeline-bft). Hypothèses optimistes et retour en arrière : [Parallélisation optimiste](/fr/blog/bitrootevm-). Carte d'architecture : [Vue d'ensemble de l'architecture EVM parallèle de Bitroot](/fr/blog/bitrootevm).

## Ordonnancement : pas une dispersion en tourniquet

Un tourniquet naïf répartit les transactions uniformément jusqu'à ce qu'un contrat chaud apparaisse et que les moteurs se disputent. De meilleurs ordonnanceurs estiment :

- la complexité et l'ordre de grandeur du gaz (grossièrement) ;
- les partitions d'état susceptibles d'être touchées ;
- la priorité et l'affinité de lot (regrouper les transactions liées pour réduire la synchronisation inter-moteurs).

L'ordonnancement a lui-même un coût : une pré-analyse trop grossière regroupe mal ; une analyse trop fine devient un goulot d'étranglement sériel. Un compromis courant est « heuristiques statiques + surveillance à l'exécution » : regrouper de façon optimiste, puis corriger avec la détection de conflits. Pourquoi les points chauds DeFi transpercent le parallélisme : [Points chauds de conflit et charges de travail](/fr/blog/parallel-evm-workload-hotspots).

## Sharding d'état : le mur suivant après l'exécution parallèle

Une fois l'exécution parallélisée, un arbre d'état unique et la mémoire d'une seule machine plafonnent encore le débit. Le sharding découpe l'espace d'état : parallélisme à l'intérieur d'un shard ; messages explicites ou validation asynchrone entre shards. Les objets volumineux trouvent leur place dans un stockage hors ligne avec des hachages on-chain pour alléger la pression sur les nœuds complets. Le sharding n'est pas gratuit — l'atomicité inter-shards et la charge mentale des développeurs augmentent ; écrivez ces règles dans le protocole, ne laissez pas les applications au hasard.

La DeFi composable inter-shards est souvent le test de résistance : les routes qui touchent de nombreux pools cumulent les conflits d'écriture et la latence du protocole inter-shards. Comment le produit reconnaît cette frontière : [Positionnement de Bitroot](/fr/blog/bitroot-positioning).

## Détection de conflits : réduire le rayon d'impact

Le prix du parallélisme optimiste est le conflit. Les documents Bitroot insistent sur une détection en trois étapes :

1. **Avant l'exécution** : des heuristiques de dépendance / lecture-écriture pour garder les conflits évidents hors de la même fenêtre parallèle.
2. **Pendant l'exécution** : une surveillance des versions ou des ensembles lecture/écriture pour interrompre tôt les chemins invalides.
3. **Après l'exécution** : des vérifications de cohérence de la racine d'état pour rattraper les oublis et les bogues d'implémentation.

L'objectif n'est pas zéro conflit, mais une réexécution sélective lorsque des conflits surviennent. L'ordonnancement collaboratif de style Block-STM d'Aptos appartient à la même famille optimiste avec des détails d'implémentation différents — ne comparez pas directement les TPS bruts de test entre projets.

## Comment lire les courbes « nombre de moteurs ↔ TPS »

Dans les tests, l'ajout de moteurs accélère souvent de façon quasi linéaire au début, puis la courbe s'infléchit à mesure que le taux de conflit augmente. Les chiffres publics de testnet ont cité des milliers de TPS avec moins de moteurs et des pics de dizaines de milliers avec davantage, plus une confirmation inférieure à la seconde dans les configurations indiquées — tout dépend du matériel, du mélange de contrats et des hypothèses de conflit. Ce sont des observations d'ingénierie, non des SLA de mainnet, et non des promesses de rendement. Préférez lire ensemble le parallélisme effectif, le taux de conflit, la part de réexécution et les centiles de latence — glossaire : [Glossaire des métriques de performance](/fr/blog/performance-metrics-glossary).

Que le multi-moteur reste transparent pour les contrats existants dépend de la compatibilité EVM (bytecode, précompilations, outillage) — voir [Ce que signifie la compatibilité EVM](/fr/blog/evm-compatibility-explained). Comment le matériel et la géographie des validateurs peuvent rogner les gains du parallélisme : [Compromis décentralisation–performance](/fr/blog/decentralization-performance-tradeoff).

## Tenir le rythme du consensus

Aussi rapide que soit le multi-moteur, il consomme l'ordre du consensus. Si l'exécution retarde chroniquement la production de blocs, les vues d'état non confirmées s'accumulent et les applications ressentent que « les blocs sont rapides mais les transactions et requêtes dépendantes restent lentes ». Les divulgations doivent montrer le retard d'exécution et les centiles de confirmation, pas seulement les pics des moteurs. Côté pipeline : [Pipeline BFT et découplage de l'exécution](/fr/blog/bitroot-pipeline-bft) ; positionnement : [Positionnement de Bitroot](/fr/blog/bitroot-positioning).

Pour les développeurs d'applications, le multi-moteur doit rester transparent : aucune syntaxe Solidity n'est requise pour « déclarer du parallélisme ». Ce qui doit changer, c'est la disposition de l'état et les schémas d'interaction — moins de compteurs singleton globaux, moins d'utilisateurs écrivant dans un même emplacement partagé. Sinon, les moteurs supplémentaires ne font que tourner à vide sur la réexécution. Compatibilité : [Ce que signifie la compatibilité EVM](/fr/blog/evm-compatibility-explained) ; public : [Qui devrait lire sur l'EVM parallèle](/fr/blog/who-should-read-parallel-evm).

## Caches, préchargement et taxe de communication inter-moteurs

Au-delà du nombre de moteurs, les caches en couches et le préchargement d'état décident si les moteurs travaillent réellement. Des taux de succès élevés sur le shard local permettent au parallélisme d'approcher la largeur du CPU ; des récupérations fréquentes d'emplacements distants aplatissent les accélérations sous la taxe de communication. Les ordonnanceurs qui ne regardent que le gaz — et non l'affinité de partition — créent systématiquement du trafic inter-moteurs.

Surveillez la part de lectures/écritures inter-moteurs, le nombre de conflits de version et la profondeur des files inter-shards. Ces métriques suivent mieux la capacité réelle que le seul nombre de moteurs. Après le découplage du consensus, un rattrapage lent de l'exécution se traduit par un écart plus long entre la confirmation et la racine d'état — les utilisateurs ressentent toujours que « la chaîne a ralenti ». Vue d'ensemble : [Vue d'ensemble de l'architecture EVM parallèle de Bitroot](/fr/blog/bitrootevm).

## Effets visibles pour les auteurs de contrats

Le multi-moteur doit généralement rester transparent pour les auteurs Solidity : déployer sans réécrire. Des effets indirects subsistent : les hypothèses sur le timing exact intra-bloc ou sur le fait que « les transactions ultérieures d'un même bloc voient toujours les écritures antérieures » sont plus fragiles dans des fenêtres spéculatives ; appuyez-vous sur des frontières de transaction explicites et des événements, et non sur des coïncidences non documentées de l'ordonnanceur.

L'outillage doit expliquer les chemins de réexécution dans les traces, les profils de gaz et les débogueurs, sinon les incidents ne peuvent pas être reconstitués. Parcours de lecture : [Qui devrait lire sur l'EVM parallèle](/fr/blog/who-should-read-parallel-evm). Compatibilité : [Ce que signifie la compatibilité EVM](/fr/blog/evm-compatibility-explained).

Jugez une conception multi-moteur à trois critères : si les accélérations sont explicables étant donné une courbe de taux de conflit, si la réexécution est observable, et si la sémantique des contrats existants reste compatible. Ces trois éléments font un EVM parallèle d'ingénierie — et non un interpréteur multithread de démonstration.

## Observabilité : pas de métriques, pas de parallélisme

Le multi-moteur en production a besoin du taux d'utilisation par moteur, des débits de messages inter-shards, des occurrences de conflit par étape, de la part de réexécution et du temps entre l'ordre du consensus et la racine d'état. Sans ces courbes, l'exploitation ne voit que « le TPS a chuté » et ne peut distinguer l'ordonnancement, les contrats chauds ou les E/S d'état. Traitez l'observabilité comme partie intégrante de la fonctionnalité — non comme une décoration de tableau de bord après lancement.

Ordonnancement, sharding et détection de conflits doivent être lus ensemble : plus de moteurs sans observabilité ne font que répéter les mêmes défaillances plus vite. Publier les courbes de taux de conflit est le minimum d'honnêteté envers les développeurs et les validateurs.

Lors de la publication de chiffres de testnet, indiquez le nombre de moteurs, le mélange de charge et le taux de conflit — et précisez qu'il ne s'agit ni de promesses de mainnet ni de conseils en investissement.

## À retenir

Le parallélisme multi-moteur transforme « peut-on exécuter l'EVM sur plusieurs cœurs » en ordonnancement, sharding et maîtrise des conflits. Il amplifie le débit sur des charges partitionnables et peu conflictuelles ; sur les points chauds de pools partagés d'un AMM, davantage de moteurs s'effondrent encore vers le sériel — c'est un problème de charge de travail, que n'efface pas une phrase marketing de plus.

## Pour aller plus loin

- [Parallélisation optimiste](/fr/blog/bitrootevm-)
- [Pipeline BFT et découplage de l'exécution](/fr/blog/bitroot-pipeline-bft)
- [Points chauds de conflit et charges de travail](/fr/blog/parallel-evm-workload-hotspots)