Un EVM monothread achète le déterminisme à relativement bon compte : ordre fixe, relecture simple. Dès que l'objectif devient « élargir la largeur d'exécution sans briser la correction vérifiable », les concepteurs rencontrent la même bifurcation : qui décide si deux transactions peuvent s'exécuter ensemble — le développeur en amont, ou l'exécution ensuite ?
Ce choix façonne le modèle de programmation, le coût de migration et le débit réel sous forte contention. L'industrie a tracé trois voies relativement claires : le parallélisme déterministe illustré par Sealevel de Solana ; le contrôle de concurrence optimiste (OCC) illustré par Block-STM d'Aptos et plusieurs EVM parallèles ; et un modèle à objets illustré par Sui. Toutes trois « parallélisent », avec des hypothèses et des coûts très différents.
Parallélisme déterministe : les dépendances écrites sur la transaction
La voie déterministe exige que chaque transaction porte une liste complète des comptes (ou ressources) qu'elle lira et écrira, marqués en lecture seule ou en écriture. Avant l'exécution, l'environnement d'exécution peut construire un graphe : l'absence de conflit d'écriture implique une sécurité en parallèle ; les lectures partagées peuvent être co-ordonnancées ; les écritures partagées sont sérialisées. L'ordonnanceur n'a pas besoin de deviner les dépendances en cours de route ; la structure des conflits est approximativement connue au moment de la mise en file. Sealevel de Solana est l'exemple d'ingénierie le plus cité, étroitement couplé à son modèle de comptes et à son stockage d'exécution.
L'avantage est la prévisibilité : une fois accepté, un chemin d'exécution gaspille moins de travail à « découvrir un conflit à mi-parcours et abandonner toute la tentative ». Le coût retombe sur les développeurs et l'outillage. Des virements simples sont peu coûteux à déclarer ; les programmes aux branches complexes dont les chemins d'accès dépendent de conditions à l'exécution doivent soit sur-déclarer (ce qui réduit le parallélisme), soit sous-déclarer (ce qui fait échouer la transaction). Dans l'EVM classique, l'accès aux emplacements de stockage est souvent décidé par des conditions internes au contrat ; le bytecode ne porte pas de liste de comptes à la Sealevel. Imposer la pré-déclaration rompt immédiatement la compatibilité au niveau du bytecode — contrats et hypothèses d'audit doivent être réécrits.
La pré-déclaration n'efface pas non plus les points chauds applicatifs. Les pools de DEX, les liquidations et les mints très demandés concentrent toujours les écritures sur quelques comptes ; les chaînes de conflits s'allongent ; le parallélisme est conditionné par la conception de l'état, non par l'ordonnanceur. Le déterminisme résout « sait-on les dépendances au moment de l'ordonnancement », et non « l'état a-t-il été réparti ». La manière dont les charges créent des points chauds appartient à un autre article ; notons ici qu'aucun moteur ne sauve une structure de contrat où tout le monde se dispute le même emplacement.
Contrôle de concurrence optimiste : supposer le parallélisme, converger en cas d'erreur
L'OCC inverse le pari : la plupart des transactions n'entrent pas en conflit, alors exécutez-les d'abord en parallèle, puis validez si les ensembles de lecture sont toujours valides ; en cas de conflit, avortez et réexécutez dans l'ordre canonique jusqu'à ce que le résultat soit équivalent à un certain ordre sériel. La mémoire transactionnelle logicielle (STM) et l'OCC des bases de données fournissent le squelette théorique ; Block-STM d'Aptos est une instance de chaîne de blocs largement citée — exécution optimiste sous un ordre prédéfini, avec un ordonnancement collaboratif qui découvre les dépendances pendant l'exécution et relance le travail, en visant à ne revenir en arrière que sur les transactions réellement affectées.
Les chiffres de TPS élevés dans les documents publics proviennent généralement de benchmarks, de matériels et de mélanges de transactions spécifiques (par exemple des transactions Move non triviales en laboratoire ou en environnement de test). Ils ne sont pas interchangeables avec l'expérience utilisateur d'une charge mixte sur le mainnet. Ce qui compte, c'est la forme du mécanisme : la correction dépend de « finalement équivalent à un ordre donné » ; la performance dépend de « taux de conflit assez faibles ou réexécution assez bon marché ».
Plusieurs chaînes compatibles EVM choisissent l'OCC pour une raison cohérente : au moment de la réception, on ne peut pas connaître statiquement tous les accès au stockage — seule l'exécution les révèle. L'environnement d'exécution enregistre les ensembles lecture/écriture réels ; les sous-ensembles en conflit convergent de façon sérielle ; le reste conserve les gains du parallélisme. Monad, Sei et d'autres diffèrent par les instantanés, l'ordre de validation et le découplage éventuel du consensus et de l'exécution, mais partagent l'« absence de pré-déclaration par le développeur » comme prémisse de compatibilité.
Le risque central de l'OCC est tout aussi public : quand les taux de conflit s'envolent, la réexécution mange le surplus du parallélisme et, à l'extrême, le débit peut approcher ou tomber en dessous d'une stratégie naïve sérielle avec verrous. Le retour en arrière sélectif, la détection en cours d'exécution, le traitement par lots et la granularité des ensembles lecture/écriture décident du coût de queue lorsque le pari optimiste échoue. L'article suivant explique les phases lecture–validation–écriture de l'OCC du point de vue des bases de données.
Modèles à objets : changer la forme du registre pour changer les frontières du parallélisme
La troisième voie ne corrige pas le modèle de comptes ; elle change la structure du registre. Sui modélise les actifs comme des objets à identifiants uniques, répartis entre objets possédés et objets partagés. Les objets possédés n'ont qu'un seul écrivain, de sorte que les transactions liées peuvent emprunter un chemin moins latent avec des besoins d'ordonnancement global plus faibles. Les objets partagés admettent de nombreux accédants et doivent être ordonnés via le consensus. Le parallélisme devient un problème de propriété : les flux naturellement mono-propriétaire passent à l'échelle ; l'état réellement partagé entre plusieurs parties paie l'ordonnancement global.
Le modèle est adapté aux NFT et aux transferts d'actifs pair-à-pair ; les pools d'AMM, les enchères globales et les autres applications riches en objets partagés rencontrent toujours une forte contention — à la granularité de l'objet plutôt qu'à celle de l'emplacement de compte. Le coût est un changement de paradigme et de langage : Move et la propriété d'objets diffèrent du modèle de comptes de Solidity. Les contrats Ethereum existants et les flux de travail Foundry/Hardhat ne se transposent pas tels quels ; les écosystèmes paient des coûts d'apprentissage et d'audit pour le parallélisme.
Les modèles à objets prouvent que le parallélisme d'exécution ne se réduit pas à un ordonnancement « à déclaration » ou « optimiste » — la topologie de l'état est un autre levier. Ils rappellent aussi aux voies compatibles EVM que conserver des comptes et un état global signifie renoncer à une partie du parallélisme structurel qu'apporte le modèle à objets : l'ordonnancement à l'exécution doit donc porter davantage de la charge.
Comparaison des trois voies
| Dimension | Déterministe (type Sealevel) | OCC optimiste (type Block-STM) | Modèle à objets (type Sui) |
|---|---|---|---|
| Quand les dépendances sont connues | Déclarées avant soumission | Découvertes pendant/après l'exécution | Déduites de la propriété des objets |
| Charge pour le développeur | Élevée (listes d'accès) | Faible (style de contrat familier) | Élevée (nouveau modèle/langage) |
| Adéquation à l'EVM classique | Difficile (conflit sémantique) | Relativement réalisable | Nécessite une migration |
| Principal mode de défaillance | Sur-/sous-déclaration ; les points chauds sérialisent quand même | Tempêtes de réexécution à fort conflit | Points chauds d'objets partagés ; migration de l'écosystème |
Le schéma est clair : si la contrainte produit dure est la compatibilité au niveau du bytecode avec les contrats et outils Ethereum existants, la pré-déclaration déterministe et les modèles à objets imposent tous deux une réécriture ou un changement de pile, de sorte que les options réelles convergent souvent vers l'OCC. Ce n'est pas affirmer que l'OCC est théoriquement le meilleur sous toute charge — les voies déterministe et à objets ont montré de solides débits dans leurs écosystèmes — c'est admettre que la compatibilité comprime l'espace de conception.
Pour un L1 positionné comme un EVM parallèle optimiste, choisir l'OCC est une convergence sous contrainte, non un slogan. Les vraies questions d'ingénierie deviennent : comment définir les ensembles lecture/écriture, à quel point détecter tôt les conflits et comment borner la réexécution sous charge chaude. Elles reposent sur l'intuition des bases de données de l'OCC et sur une évaluation honnête des points chauds de charge.
Pour aller plus loin
- Précédent : « Cartographier la scalabilité des chaînes de blocs : ce que résolvent respectivement le parallélisme L1, les L2, le sharding et la DA »
- Suivant : « Introduction au contrôle de concurrence optimiste (OCC) : des bases de données à l'exécution on-chain »
- Associés : « La technologie EVM parallélisée de Bitroot expliquée : la parallélisation optimiste », « Points chauds de conflit et charges de travail : quand l'EVM parallèle aide vraiment »