Pendant des années, presque chaque chaîne publique et projet modulaire a employé le mot « scalabilité », rarement pour la même couche. Les équipes de rollups entendent généralement déplacer l'exécution hors du mainnet Ethereum. Les équipes de disponibilité des données entendent publier et échantillonner plus de données à moindre coût. Les L1 à exécution parallèle entendent répartir le moteur d'exécution d'une seule chaîne sur de nombreux cœurs. Un seul mot ; des hypothèses de sécurité, des plafonds et des modes de défaillance différents.
Cet article découpe la scalabilité en couches non chevauchantes, marque où se situent respectivement les L2, la feuille de route de sharding d'Ethereum, la DA autonome et le parallélisme L1, et répond à une question pratique : que cible réellement l'EVM parallèle sur cette carte — un substitut aux rollups, ou un complément ?
Quatre missions d'abord : consensus, DA, exécution, règlement
Une chaîne qui offre un registre fiable doit faire au moins quatre choses.
Premièrement, le consensus : s'accorder sur l'ordre des transactions et le contenu des blocs, et garantir — sous des hypothèses de sécurité énoncées — que le registre n'est pas réécrit à la légère. Deuxièmement, la disponibilité des données (DA) : publier les données nécessaires à la vérification des transitions d'état dans un endroit assez public pour que quiconque puisse les télécharger et les revérifier. Troisièmement, l'exécution : exécuter réellement la logique des transactions et calculer le nouvel état mondial. Quatrièmement, le règlement : ancrer l'état final ou les preuves comme un fait sur lequel des systèmes externes peuvent s'appuyer — les ponts, les messages inter-chaînes et les conversions fiat y prennent souvent appui.
Ethereum en 2015 regroupait les quatre dans une seule pile de nœuds — ce qu'on a ensuite appelé une architecture monolithique. L'avantage est un récit de sécurité unifié et un modèle mental simple ; l'inconvénient est qu'un goulot d'étranglement dans une couche ralentit toute la chaîne. L'exécution a été le premier mur largement ressenti : le débit du mainnet est longtemps resté entre quelques unités et une dizaine de TPS, et les frais explosaient dès qu'une application devenait populaire. La feuille de route d'Ethereum s'est alors orientée « centrée rollups » : le mainnet se concentre davantage sur la DA et l'arbitrage du règlement, laissant l'exécution de masse aux L2. Ce pivot est le point de départ de toutes les branches qui suivent.
Rollups L2 : sortir l'exécution, garder la sécurité ancrée au mainnet
Le geste central d'un rollup est d'exécuter les transactions dans un environnement d'exécution séparé et de renvoyer les données et les preuves (ou des engagements contestables) vers Ethereum. Les rollups ZK reposent sur des preuves de validité ; les rollups optimistes sur des fenêtres de preuve de fraude. Le mainnet n'a pas besoin de rejouer chaque transaction — seulement de vérifier les preuves ou de traiter les litiges. Le calcul d'exécution se déplace vers les séquenceurs et les systèmes de preuve ; la sécurité du règlement vise toujours à s'ancrer au jeu de validateurs d'Ethereum.
Cette voie résout le « on peut ajouter horizontalement des instances d'exécution » : de nombreux rollups servent de nombreuses applications en parallèle. Elle ne résout pas automatiquement la question « chaque instance reste-t-elle monothread à l'intérieur ». Beaucoup de rollups optimistes restent proches de la sémantique sérielle de l'EVM classique ; les gains de débit viennent de matériel dédié, de blocs plus courts et du déplacement de la congestion du marché des frais du L1 vers le marché propre du L2 — pas nécessairement du parallélisme intra-bloc.
Les rollups héritent aussi de deux contraintes. Les données doivent toujours être publiées quelque part — calldata, blobs ou DA externe — et le coût de la DA revient dans les frais utilisateur. Les utilisateurs héritent aussi d'un saut de confiance et de latence L2→L1 (périodes de contestation des retraits, risque de pont, disponibilité du séquenceur). Un rollup n'est jamais autonome ; il repose sur une DA suffisamment bon marché et crédible.
Les chiffres de TVL et de débit des L2 sur les tableaux de bord publics évoluent rapidement ; citez-les comme des instantanés. La structure compte davantage : la concentration du capital reflète souvent des préférences en matière de coût de preuve, de conception des contestations et de maturité opérationnelle — et non l'affirmation qu'une voie théorique serait éternellement supérieure.
Sharding : du discours de sharding d'exécution au sharding de données
Le « sharding » a changé de sens dans l'histoire d'Ethereum. Les premières feuilles de route insistaient sur le sharding d'exécution : diviser l'état, exécuter par shard, puis se débattre avec la messagerie inter-shards. La complexité était élevée ; la composabilité inter-shards difficile. À mesure que les rollups mûrissaient, le récit du mainnet s'est déplacé vers moins d'exécution et plus de capacité de données — la direction Danksharding, avec le Proto-Danksharding (EIP-4844) déjà en production.
L'EIP-4844 a introduit les blobs : un espace de données éphémère qui ne gonfle pas durablement l'état de la couche d'exécution, réduisant le coût pour les L2 de publier des données sur le mainnet. Le Danksharding complet envisage l'échantillonnage de disponibilité des données afin que les nœuds n'aient pas à tout télécharger pour acquérir une confiance probabiliste que les données sont disponibles. La correction clé : dans le vocabulaire actuel d'Ethereum, le « sharding » élargit surtout la capacité de DA — il ne réintroduit pas un EVM multithread sur le mainnet. Le confondre avec le « parallélisme d'exécution » de Solana, Sui ou des L1 à EVM parallèle brouille la carte.
DA autonome : le troisième pilier de la modularité
Tous les rollups ne veulent pas une DA verrouillée au marché des blobs d'Ethereum. Celestia, EigenDA, Avail et des projets similaires fournissent une autre voie : se spécialiser dans la publication et l'échantillonnage, laisser l'exécution et le règlement à d'autres. Les combinaisons modulaires deviennent concrètes — exécution sur un rollup, DA sur une couche dédiée, règlement encore éventuellement ancré à Ethereum ou à un autre L1.
La DA autonome traite la bande passante et le coût de publication des données. Elle n'augmente pas directement le parallélisme intra-bloc d'une chaîne donnée. Elle peut indirectement rendre plus de transactions de rollup bon marché et augmenter le débit de tout l'écosystème ; sur la question « un moteur d'exécution unique peut-il tourner en parallèle », la couche DA reste largement muette. Pour évaluer un projet, demandez s'il vend de l'exécution, du règlement ou un tuyau de données.
Exécution parallèle L1 : élargir l'exécution sur place
À l'opposé de « sortir l'exécution » se trouve une autre voie : garder exécution et règlement sur le L1, mais changer le moteur pour que les transactions sans conflit s'exécutent en parallèle. L'ordonnancement par déclaration de comptes de Solana, le parallélisme optimiste de style Block-STM d'Aptos, le modèle à objets de Sui et plusieurs tentatives d'EVM parallèle occupent cette case.
Le parallélisme L1 cible le plafond d'exécution monothread évoqué précédemment. Il implique généralement de bâtir son propre jeu de validateurs et son propre consensus — on ne peut pas simplement « hériter » de la sécurité d'Ethereum — en échange d'une liquidité et d'une composabilité dans un même domaine de règlement et d'un saut de pont par défaut en moins. Le coût : les chiffres de performance doivent être lus selon les hypothèses de sécurité de la chaîne elle-même, et la croissance de l'état, les seuils matériels et la tension de décentralisation incombent à la gouvernance locale.
L'EVM parallèle en est une sous-classe : conserver la compatibilité du bytecode et de l'outillage tout en introduisant du parallélisme à l'exécution. Il partage la coordonnée « scalabilité de la couche d'exécution » avec les L1 qui changent la VM et le modèle de comptes, mais pas la même courbe de coût de migration des développeurs. Les détails des trois voies parallèles appartiennent à l'article suivant ; ici, le placement suffit : l'EVM parallèle vend de la largeur d'exécution — pas de l'échantillonnage de DA, et pas « lancez plus de rollups ».
Un tableau comparatif
| Voie | Goulot principalement visé | Geste typique | Contresens fréquent |
|---|---|---|---|
| Rollup L2 | Capacité d'exécution du mainnet | Externaliser l'exécution ; prouver/contester en retour | « Le parallélisme intra-bloc est résolu » |
| Sharding de données / blobs d'Ethereum | Coût de publication des données du L2 | Élargir la capacité de DA | « Ethereum a livré le sharding d'exécution » |
| DA autonome | Bande passante de données modulaire | Publication et échantillonnage spécialisés | « Cela suffit à une expérience de chaîne complète » |
| Exécution parallèle L1 | Exécution sérielle d'une instance unique | Ordonnancement multicœur / OCC / parallélisme à objets | « La même métrique qu'un comparatif de rollups » |
Un complément plutôt qu'une exclusion mutuelle
Deux axes valent mieux que des slogans. Un axe est le lieu de l'exécution : de nombreuses instances hors ligne, ou une instance on-chain rendue plus large. L'autre est le fournisseur de DA : blobs d'Ethereum, DA autonome, ou publication propre à un L1. Les combinaisons réelles sont plus riches que le ou bien/ou bien — un rollup peut publier sur Celestia ; un L1 parallèle peut ensuite coordonner des stratégies d'objets volumineux ou d'historique avec un stockage externe.
Qualifier l'EVM parallèle simplement d'« anti-Ethereum » ou de « remplacement du sharding » est imprécis. Il corrige la largeur d'exécution : lorsqu'un environnement unique devient dense et que les contrats se complexifient, le modèle sériel cède en premier. Les rollups augmentent le nombre d'environnements d'exécution ; ils n'optimisent pas automatiquement l'ordonnancement à l'intérieur de chacun. Les deux peuvent servir des produits différents tout en se connectant sur les chemins d'actifs.
Lorsque vous lirez les articles techniques suivants, demandez quelle couche mesure un chiffre. Comparer le débit parallèle d'une chaîne unique en testnet au TPS perçu par l'utilisateur d'un rollup sous un coût de DA particulier — sans énoncer les prémisses — est une comparaison sans contenu informatif.
Pour aller plus loin
- Précédent : « Pourquoi un EVM monothread plafonne le TPS : histoire de la congestion et modèle d'exécution »
- Suivant : « Trois voies vers l'exécution parallèle : ordonnancement déterministe, OCC optimiste et modèles à objets »
- Associés : « Positionner Bitroot : les frontières d'un Layer 1 à EVM parallèle optimiste », « La tension entre décentralisation et performance : exigences des validateurs, matériel et répartition géographique »