Un article complet sur l'exécution parallèle de Layer1 : comment Aptos, Sui, Linera et Fuel le mettent en œuvre ?
TechFlow SélectionTechFlow Sélection
Un article complet sur l'exécution parallèle de Layer1 : comment Aptos, Sui, Linera et Fuel le mettent en œuvre ?
En repensant à l'évolution de la technologie blockchain, on observe clairement une tendance forte : les nouvelles blockchains de niveau 1 accordent une attention croissante à l'exécution parallèle.
Dédié à des analyses Web3 approfondies
Par Mohamed Fouda
Traduit par TechFlow
En repensant à l'évolution de la technologie blockchain, une tendance forte émerge : les nouvelles blockchains de niveau 1 (L1) mettent désormais l'accent sur l'exécution parallèle.
Il ne s'agit pas d'une technologie nouvelle. Solana l'utilise déjà dans son environnement d'exécution Sealevel.
Cependant, lors du dernier marché haussier, le succès impressionnant des applications DeFi et NFT a mis en lumière la nécessité urgente d'améliorer la technologie sous-jacente.
Lors du prochain cycle du marché, plusieurs projets célèbres adoptant l'exécution parallèle feront leur apparition : Aptos, Sui, Linera et Fuel.
Cet article examine les similitudes et différences entre ces projets ainsi que les défis auxquels ils sont confrontés.
Problème
Les plateformes de contrats intelligents permettent de créer un large éventail d'applications décentralisées. Pour exécuter ces applications, un moteur de calcul partagé est nécessaire. Chaque nœud du réseau exécute ce moteur, traite les applications et les interactions des utilisateurs avec celles-ci. Lorsque tous les nœuds obtiennent les mêmes résultats après exécution, ils atteignent un consensus et font avancer la chaîne.
La Machine Virtuelle Ethereum (EVM) est le moteur principal d'exécution des contrats intelligents, avec environ 20 implémentations différentes.
Depuis son invention, l'EVM a atteint une masse critique d'adoption parmi les développeurs.
Outre Ethereum et ses solutions de niveau 2 (L2), plusieurs autres chaînes comme Polygon, BNB Smart Chain et Avalanche C-Chain utilisent également l'EVM comme moteur d'exécution, tout en se concentrant sur la modification du mécanisme de consensus pour améliorer le débit du réseau.
L'une des limitations majeures de l'EVM est l'exécution séquentielle des transactions. L'EVM exécute fondamentalement une transaction à la fois, mettant toutes les autres en attente jusqu'à la fin de l'exécution et la mise à jour de l'état de la blockchain. Même si deux transactions sont indépendantes — par exemple, un transfert d'Alice à Bob et un autre de Carol à Dave — l'EVM ne peut pas les exécuter en parallèle. Bien que ce modèle autorise des cas d'usage intéressants comme les prêts flash, il manque d'efficacité et de scalabilité.
Cette exécution séquentielle constitue l'un des principaux goulets d'étranglement du débit du réseau :
- Premièrement, elle prolonge le temps d'exécution des transactions dans un bloc, limitant ainsi le temps de bloc ;
- Deuxièmement, elle limite le nombre de transactions pouvant être ajoutées à un bloc afin que les nœuds puissent les exécuter et confirmer le bloc.
Le débit moyen d'Ethereum est d'environ 17 tx/s. Ce faible débit signifie qu'en période d'activité intense, par exemple lors du minting d'un NFT, les mineurs/validateurs du réseau ne peuvent pas traiter toutes les transactions. Une course aux frais s'ensuit, où chacun surenchérit pour garantir une exécution prioritaire, entraînant une hausse des frais de transaction. À certains moments, les frais moyens sur Ethereum ont dépassé 0,2 ETH (environ 800 dollars), dissuadant de nombreux utilisateurs.
L'exécution parallèle peut-elle résoudre ce problème ?
Les limitations structurelles de l'EVM ont ouvert la voie à un nouveau domaine de L1 axé sur l'exécution parallèle (PE). Le parallélisme permet de répartir le traitement des transactions entre plusieurs cœurs de processeur, améliorant ainsi l'utilisation du matériel et offrant une meilleure scalabilité. Sur les chaînes à haut débit, augmenter les ressources matérielles se traduit directement par une augmentation du nombre de transactions exécutables.
En période d'activité élevée, les nœuds validateurs peuvent allouer davantage de cœurs pour gérer la charge supplémentaire. Cette extension dynamique des ressources computationnelles permet au réseau d'atteindre un débit plus élevé en période de forte demande, améliorant considérablement l'expérience utilisateur.
Un autre avantage de cette approche est la réduction de la latence de confirmation des transactions. L'extension dynamique des ressources des nœuds rend possible une confirmation rapide même sous charge maximale.
Les transactions n'ont plus besoin d'attendre des dizaines, voire des centaines de blocs, ni de payer des frais excessifs pour une confirmation prioritaire. Des délais de confirmation améliorés renforcent la finalité des transactions et ouvrent la porte à des blockchains à très faible latence. Garantir une exécution à faible latence rend possibles plusieurs cas d'usage auparavant inaccessibles.
Modifier le mode d'exécution de la chaîne pour permettre l'exécution parallèle n'est pas une idée neuve, et certains projets l'ont déjà explorée. Une approche consiste à remplacer le modèle comptable basé sur les comptes utilisé par l'EVM par un modèle UTXO (Unspent Transaction Output). Ce modèle, utilisé par Bitcoin, permet le traitement parallèle des transactions, ce qui en fait un choix idéal pour les paiements.
Mais en raison des fonctionnalités limitées du modèle UTXO, des extensions sont nécessaires pour supporter les interactions complexes requises par les contrats intelligents. Par exemple, Cardano utilise un modèle UTXO étendu à cet effet, tandis que Findora opte pour un modèle hybride combinant les deux approches comptables et permettant aux utilisateurs de changer dynamiquement le type d'actif.
Une autre approche de la PE ne modifie pas le modèle de compte, mais se concentre plutôt sur l'amélioration de l'architecture de l'état de la chaîne et de ses modifications. C’est le cas par exemple du framework Sealevel de Solana.
Comment fonctionne l’exécution parallèle ?
L’exécution parallèle consiste à identifier les transactions indépendantes et à les exécuter simultanément. Deux transactions sont liées si l’exécution de l’une affecte celle de l’autre. Par exemple, les transactions AMM (Market Maker Automatisé) sur le même pool sont interdépendantes et doivent donc s’exécuter séquentiellement.
Bien que le concept d’exécution parallèle paraisse simple, la difficulté réside dans les détails, notamment dans la manière d’identifier efficacement les transactions « indépendantes ». Cette classification nécessite de comprendre comment chaque transaction modifie la mémoire blockchain ou l’état de la chaîne. Les transactions interagissant avec le même contrat intelligent (comme un pool AMM) peuvent modifier simultanément l’état du contrat, et ne peuvent donc pas être exécutées en parallèle.
Étant donné le haut niveau de composable aujourd’hui entre applications, identifier les dépendances devient une tâche complexe. Imaginez une transaction AMM échangeant UNI contre USDC, dont le chemin le plus efficace passe par UNI → ETH → DAI → AAVE → USDC. Tous les pools impliqués ne peuvent traiter aucune autre transaction tant que cette opération n’est pas entièrement terminée, et leurs états respectifs ne seront mis à jour qu’ensuite.
Identifier les transactions indépendantes
Dans cette section, nous comparons les méthodes utilisées par différents moteurs d’exécution parallèle, en particulier celles concernant le contrôle de l’accès à l’état (mémoire). L’état de la blockchain peut être vu comme une mémoire RAM, chaque compte ou contrat intelligent possédant une série d’emplacements mémoire modifiables. Les transactions liées sont celles qui tentent de modifier les mêmes emplacements mémoire dans un même bloc. Différentes blockchains utilisent des architectures mémoires et mécanismes variés pour détecter ces conflits.
Plusieurs chaînes de ce type reposent sur la technologie développée par Diem, le projet blockchain abandonné de Facebook. L’équipe Diem a créé Move, un langage de contrats intelligents conçu spécifiquement pour améliorer l’exécution des SC. Aptos, Sui et Linera sont trois projets importants issus de ce groupe. En dehors de celui-ci, Fuel est un autre projet notable centré sur l’exécution parallèle, utilisant son propre langage de contrats intelligents.
Aptos
Aptos s’appuie sur le langage Move et la MoveVM de Diem pour construire une chaîne à haut débit intégrant l’exécution parallèle.
L’approche d’Aptos consiste à détecter automatiquement les dépendances, de façon transparente pour les utilisateurs et les développeurs, sans exiger que les transactions déclarent explicitement quelles parties de l’état (emplacements mémoire) elles utilisent.
Aptos utilise une version modifiée de la mémoire transactionnelle logicielle (Software Transactional Memory), appelée Block-STM.
Dans Block-STM, les transactions sont préordonnées dans un bloc et réparties entre plusieurs threads processeurs pour exécution.
Pendant le processus, on suppose initialement qu’il n’y a pas de dépendances. Les emplacements mémoire modifiés par chaque transaction sont enregistrés. Après exécution, les résultats sont validés. Si une transaction accède à un emplacement modifié par une transaction précédente, elle est invalidée, son résultat est annulé, puis elle est réexécutée.
Ce processus se répète jusqu’à ce que toutes les transactions du bloc soient correctement exécutées.
Lorsqu’on utilise plusieurs cœurs de processeur, Block-STM accélère l’exécution, avec un gain proportionnel au degré d’indépendance entre les transactions.
Les tests menés par l’équipe Aptos montrent qu’avec 32 cœurs, les performances augmentent de 8 fois pour des transactions fortement dépendantes, et de 16 fois pour des transactions peu dépendantes. Si toutes les transactions d’un bloc sont interdépendantes, Block-STM entraîne une légère perte par rapport à l’exécution séquentielle. Aptos affirme que cette méthode permet d’atteindre un débit de 160 000 TPS.
Sui
Une autre approche de l’exécution parallèle exige que les transactions déclarent explicitement les parties de l’état de la chaîne qu’elles modifient — une méthode actuellement utilisée par Solana et Sui.
Solana appelle ces unités mémoire des « comptes », et chaque transaction doit indiquer quels comptes elle modifie. Sui adopte une approche similaire.
Sui s’appuie également sur la technologie Diem via MoveVM. Toutefois, Sui utilise une version différente du langage Move.
L’implémentation de Sui Move modifie le modèle de stockage central et les permissions d’actifs de Diem, marquant une différence majeure avec Aptos, qui utilise la version originale de Move.
Sui Move définit un modèle de stockage d’état facilitant l’identification des transactions indépendantes.
Dans Sui, l’état est structuré en objets (Objects), représentant généralement des actifs pouvant être partagés — c’est-à-dire modifiés par plusieurs utilisateurs.Chaque objet dispose d’un ID unique dans l’environnement d’exécution de Sui, ainsi que d’un pointeur interne vers l’adresse du propriétaire. Grâce à ces concepts, il est facile d’identifier les dépendances en vérifiant si deux transactions utilisent les mêmes objets.
En déléguant la responsabilité de déclarer les dépendances aux développeurs, la conception du moteur d’exécution devient plus simple, ce qui théoriquement permet de meilleures performances et une meilleure scalabilité. Cependant, cela se fait au détriment d’une expérience développeur moins agréable.
Sui n’a pas encore été lancé, mais vient de sortir son réseau de test.
Les fondateurs de Sui affirment que l’implémentation de l’exécution parallèle, combinée au mécanisme de consensus Narwhal et Tusk, permettrait un débit supérieur à 100 000 tx/s. Si cela se confirme, cela représenterait une amélioration significative par rapport aux environ 2400 tx/s actuels de Solana, dépassant même les débits de Visa et Mastercard.
Linera
Linera est le dernier arrivé dans le domaine du traitement parallèle, ayant récemment annoncé son premier tour de financement mené par a16z. Peu de détails sont disponibles sur sa mise en œuvre. Toutefois, selon leur annonce de levée de fonds, Linera s’appuie sur le protocole FastPay, également développé chez Facebook.
FastPay repose sur une technologie appelée « Byzantine Consistent Broadcast », conçue pour accélérer les paiements indépendants, comme ceux effectués dans un réseau de points de vente. Elle permet à un groupe de validateurs de garantir l’intégrité des paiements dès lors que plus des deux tiers sont honnêtes. FastPay est une variante des systèmes de règlement brut en temps réel (RTGS), utilisés entre banques et institutions financières.
Sur la base de FastPay, Linera souhaite construire une blockchain capable de traiter en parallèle les transactions de paiement, en privilégiant la rapidité de règlement et la faible latence. Notons que Sui utilise aussi « Byzantine Consistent Broadcast » pour les paiements simples. Pour les autres types de transactions, Sui utilise son propre mécanisme de consensus Narwhal et Tusk, optimisé pour traiter efficacement des opérations plus complexes et interdépendantes comme celles de la DeFi.
Fuel
Fuel se concentre sur le rôle de couche d’exécution dans une architecture modulaire, ce qui signifie que Fuel n’implémente ni consensus ni stockage de données sur sa propre chaîne. Pour former une blockchain fonctionnelle, Fuel interagit avec d’autres chaînes pour le consensus et la disponibilité des données, telles qu’Ethereum ou Celestia.
Fuel utilise le modèle UTXO pour créer des listes d'accès strictes, contrôlant via une liste l'accès aux mêmes portions d'état. Ce modèle repose sur le principe de l'ordre canonique des transactions. Dans ce schéma, l'ordre des transactions dans un bloc simplifie considérablement la détection des dépendances. Pour mettre en œuvre cette architecture, l'équipe Fuel a développé une nouvelle machine virtuelle, FuelVM, et un nouveau langage, Sway.
FuelVM est une version simplifiée et compatible avec l’EVM, facilitant l’adoption par les développeurs existants.
De plus, en tant que solution modulaire, l’exécution des contrats intelligents sur Fuel peut être finalisée sur le réseau principal d’Ethereum. Cette approche s’aligne sur la vision post-fusion d’Ethereum : devenir une couche de règlement et de disponibilité des données centrée sur les rollups. Dans cette architecture, Fuel peut offrir une exécution à haut débit, avec batch et règlement sur Ethereum.
Pour valider ce concept, l’équipe Fuel a développé SwaySwap, un AMM similaire à Uniswap, opérationnel sur le réseau de test. L’objectif est de démontrer que FuelVM offre de meilleures performances que l’EVM.
Défis des approches d’exécution parallèle
Les approches d’exécution parallèle semblent logiques et directes, mais elles posent encore plusieurs défis. Le premier concerne l’estimation du pourcentage réel de transactions pouvant bénéficier de ce type d’exécution. Le second touche à la décentralisation du réseau : si les validateurs peuvent facilement augmenter leur puissance de calcul pour améliorer le débit, comment les nœuds complets peuvent-ils suivre pour garantir la correction de la chaîne ?
Pourcentage de transactions parallélisables
Estimer précisément le pourcentage de transactions enchaînées pouvant s’exécuter en parallèle sur n’importe quelle blockchain reste difficile. En outre, ce pourcentage varie fortement d’un bloc à l’autre selon le type d’activité du réseau.
Par exemple, un événement de minting NFT peut provoquer un pic de transactions fortement dépendantes. Cela dit, on peut faire certaines hypothèses pour obtenir une estimation approximative du pourcentage moyen de transactions parallélisables.
On peut supposer que la majorité des transferts d’ETH et d’ERC20 sont indépendants, c’est-à-dire initiés et reçus depuis des adresses différentes. On peut donc estimer qu’environ 25 % des transferts d’ETH et d’ERC20 sont interdépendants — par exemple les dépôts vers des contrats ou l’agrégation d’actifs depuis des portefeuilles chauds d’échanges vers des portefeuilles froids.
En revanche, toutes les transactions AMM sur le même pool sont liées. Étant donné que la plupart des AMM sont dominés par quelques pools seulement, et que les transactions AMM sont hautement composites et interagissent souvent avec plusieurs pools, on peut raisonnablement supposer qu’au moins 50 % des transactions AMM sont interdépendantes.
En analysant les catégories de transactions sur Ethereum, on observe que sur environ 1,2 million de transactions quotidiennes : 20-30 % sont des transferts ETH, 10-20 % des transferts de stablecoins, 10-15 % des transactions DEX, 4-6 % des transactions NFT, 8-10 % des validations ERC20, et 12-15 % d'autres transferts ERC20.
À partir de ces chiffres et hypothèses, on peut estimer que l’exécution parallèle pourrait accélérer environ 70 à 80 % des transactions sur une plateforme de contrats intelligents.
Cela signifie que l’exécution séquentielle des transactions liées représente environ 20 à 30 % du total. Autrement dit, avec une limite de gaz identique, l’utilisation de l’exécution parallèle pourrait multiplier le débit par 3 à 5.
Des expériences visant à construire un EVM parallèle montrent des estimations similaires, avec des gains de débit constants de 3 à 5 fois.
En pratique, les chaînes à haut débit utilisent des limites de gaz plus élevées et des temps de bloc plus courts, obtenant ainsi des débits supérieurs à 100 fois celui d’Ethereum. Ce débit accru nécessite des nœuds validateurs puissants, ce qui conduit au second défi : la centralisation du réseau.
Centralisation du réseau
Dans les réseaux à haut débit, des dizaines de milliers de transactions peuvent être traitées chaque seconde.
Les nœuds validateurs, motivés par les frais et les récompenses, investissent dans des serveurs dédiés ou des infrastructures cloud évolutives pour traiter ces volumes. Mais pour les entreprises ou particuliers souhaitant utiliser la chaîne et exécuter un nœud complet, la situation est différente. Ces acteurs ne peuvent pas se permettre des serveurs sophistiqués capables de gérer de tels volumes. Cela les pousse à dépendre de fournisseurs RPC spécialisés comme Infura, accentuant la centralisation.
Sans possibilité d’exécuter un nœud complet sur du matériel grand public, les chaînes à haut débit risquent de devenir des systèmes fermés, où une poignée d’entités détiennent un pouvoir absolu sur le réseau. Dans ce cas, elles pourraient coordonner des censures de transactions, d’utilisateurs ou d’applications (comme Tornado Cash), transformant ces chaînes en systèmes permis, peu différents du Web 2.
Actuellement, les exigences pour exécuter un nœud complet sur le testnet Sui sont inférieures à celles d’Aptos. Toutefois, nous prévoyons que ces exigences évolueront fortement au lancement du mainnet et à mesure que les applications se développeront.
Les défenseurs de la décentralisation proposent des solutions comme l’utilisation de nœuds légers, ou la validation de la justesse des blocs via des preuves de validité ZK ou des preuves de fraude.
L’équipe Fuel est particulièrement active sur ce front, en phase avec l’esprit de la communauté Ethereum sur l’importance de la décentralisation. On ignore si les équipes d’Aptos et Sui accordent une priorité similaire à ces méthodes. L’équipe Linera a brièvement abordé ces questions dans son article introductif, mais l’implémentation du protocole n’a pas encore confirmé cet engagement.
Conclusion
Les moteurs d’exécution parallèle constituent une solution prometteuse pour améliorer le débit des plateformes de contrats intelligents.
Combinés à des innovations dans les mécanismes de consensus, l’exécution parallèle des transactions peut permettre à certaines blockchains d’atteindre ou de dépasser les 100 000 TPS. De telles performances rivalisent avec Visa et Mastercard, et rendent possibles des cas d’usage exigeants comme les jeux entièrement sur chaîne ou les micro-paiements décentralisés.
Ces améliorations impressionnantes ne vont pas sans défis, notamment en matière de préservation de la décentralisation. Nous espérons que les fondateurs continueront à innover pour relever ces défis.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@MohamedFFouda
