Modifications extrêmes de la couche 2 : la fin du modularité est-elle une nouvelle porte d'entrée vers la « couche 1 » ?
TechFlow SélectionTechFlow Sélection
Modifications extrêmes de la couche 2 : la fin du modularité est-elle une nouvelle porte d'entrée vers la « couche 1 » ?
La couche 2 n'est plus simplement la couche 2 d'Ethereum.
Dédié à des analyses Web3 approfondiesRédaction : Haotian
Un nouveau récit émerge autour de l’« EVM parallèle », particulièrement intéressant dans le contexte des layer2, permettant d’envisager un nouveau paradigme de Rollup « finement optimisé », voire, de manière exagérée, transformant Solana en un nouveau layer2 d’Ethereum.
À mes yeux, l’EVM parallèle n’est qu’une manifestation évidente d’un haut degré de modularité des Rollups, une nouvelle défaite du niveau d’exécution VM après celle subie par la disponibilité des données (DA) face aux solutions tierces. À l’avenir, les layer2 seront redéfinis. Pourquoi ? Analysons cela sous un angle pédagogique :
Pour comprendre ce sujet, il faut d’abord clarifier le modèle d’exécution « mono-thread » de l’EVM.
Ce modèle impose que les transactions soient traitées et confirmées séquentiellement, l’une après l’autre, ce qui impacte directement la vitesse de traitement, le temps de création des blocs et le débit transactionnel. C’est précisément la raison principale pour laquelle le réseau principal d’Ethereum connaît des frais élevés (Gas) et des congestions. Ce choix de conception mono-thread résulte aussi de certaines limites historiques.
Étant donné que les transactions sur Ethereum sont validées et exécutées par des nœuds indépendants distribués, il est essentiel de garantir que toutes les adresses — soldes, codes de contrats intelligents, etc. — maintiennent un état cohérent entre tous les nœuds, tout en évitant toute possibilité de double dépense du même actif.
Cela oblige donc à traiter les transactions séquentiellement. En cas d’exécution parallèle, des erreurs de synchronisation des données entre nœuds pourraient survenir, entraînant notamment de graves problèmes de double dépense.
Explication simple : imaginez une banque avec un seul guichet, où chaque client doit attendre son tour pour effectuer un retrait, un dépôt ou un prêt. Une fois l’opération terminée pour un client, le suivant peut commencer. L’avantage ? Chaque opération du système bancaire est enregistrée avec précision. Mais l’inconvénient ? Les clients passent beaucoup de temps en file d’attente.
Si la banque ouvre plusieurs guichets, permettant aux clients de choisir selon leurs besoins, deux guichets pourraient simultanément tenter de prélever sur un même compte. Si les systèmes de comptabilité entre guichets ne se synchronisent pas instantanément, cela pourrait provoquer une double dépense. Bien que cela améliore nettement l’efficacité, la complexité accrue de la comptabilité mettrait alors sous pression le système financier global.
Dans un scénario de chaîne indépendante (layer1), le problème du traitement parallèle peut être résolu si la couche fondamentale de la blockchain le supporte. Par exemple, Solana sépare clairement calcul et état de stockage. Ainsi, lorsque sa machine virtuelle (VM) reçoit plusieurs transactions utilisateur, les nœuds les ordonnent puis utilisent un système de stockage indépendant pour détecter tout conflit d’état. S’il n’y a pas de conflit, les transactions sont regroupées dans un même bloc ; sinon, les transactions conflictuelles sont exclues de ce bloc.
En revanche, sur Ethereum, l’état de stockage est calculé en temps réel, chaque transaction devant attendre la finalisation de la précédente avant de mettre à jour l’état. Il devient donc impossible de filtrer ou trier les transactions en attente d’empaquetage, ce qui limite fortement toute possibilité de traitement parallèle.
Dans le contexte d’un Rollup layer2, la logique pour implémenter le traitement parallèle suit un raisonnement similaire. On peut assimiler le processus de calcul et de vérification d’état en attente du timestamp POH sur Solana au fonctionnement d’un Rollup, où le Séquenceur traite les transactions avant de les envoyer par lots (Batch) sur la chaîne principale.
Actuellement, avant le Batch sur layer2, le Séquenceur attribue aux transactions un nonce selon leur ordre temporel, puis les envoie séquentiellement sur la chaîne principale. Comment alors passer à un mode multi-thread ?
1) En s’appuyant sur le modèle de compte abstrait (AA), il devient possible, au niveau de l’état du compte, d’initier plusieurs transactions simultanément. Par exemple, si deux opérations de transfert sont exécutées en même temps, le contrat intelligent AA leur attribuera un nonce imposant un ordre d’exécution. En revanche, si l’une est un transfert et l’autre une autorisation (Approve), elles peuvent être traitées en parallèle sans contrainte de nonce, offrant ainsi plus de flexibilité. Dans le modèle AA, chaque compte peut personnaliser sa logique de traitement des transactions, combinée au mécanisme de nonce pour permettre une forte concurrence.
2) Le Séquenceur peut effectuer un traitement « finement ciblé » des transactions. Lorsqu’elles sont soumises au Séquenceur sur layer2, celui-ci peut rapidement analyser leur logique, puis les trier et filtrer avec précision. Par exemple, si un même compte lance deux transferts, le second sera exclu et reporté au prochain Batch. En revanche, si deux opérations différentes sont lancées par un même compte, elles peuvent être incluses ensemble dans un même bloc.
Cela semble simple ? En réalité, non. Prenons le cas des applications DeFi : pour assurer une gestion fine des transactions, le Séquenceur fait face à deux défis majeurs :
1) Il doit analyser en temps réel les données des transactions, comprendre les méthodes de contrat intelligent appelées ainsi que leurs paramètres. Prenons l’exemple typique du Staking en DeFi : une seule opération de mise en jeu implique un transfert de jeton, une mise à jour d’état, une durée de verrouillage et potentiellement un calcul de récompenses. Si de nombreux utilisateurs soumettent simultanément des transactions de staking, y compris des transferts post-staking, avec en plus des facteurs complexes comme les prix fournis par des oracles, une erreur de traitement par le Séquenceur pourrait entraîner un incident grave.
2) Le Séquenceur doit rester décentralisé. Actuellement, même si le rôle du Séquenceur se limite à empaqueter les transactions, son pouvoir est déjà considérable. Si le problème de décentralisation n’est pas résolu, ajouter une gestion « fine » des Rollups reviendrait à lui accorder encore plus de contrôle. Des risques apparaîtraient alors : insertion de fausses transactions, extraction agressive de MEV via des sandwich attacks, ou manipulation malveillante des oracles pour déclencher des liquidations.
Récemment, Metis a connu un regain d’intérêt. En surface, cela reflète simplement la décentralisation du Séquenceur. En profondeur, cela pose les bases consensuelles nécessaires pour permettre à l’avenir un Rollup « finement optimisé ».
Bien sûr, parvenir à un tel niveau de finesse dans la consolidation et le traitement des transactions via le Séquenceur reste aujourd’hui une vision hypothétique. Heureusement, l’abstraction des comptes (AA) et la philosophie générale de modularité et de composition ouverte des blockchains offrent les conditions préalables nécessaires à sa réalisation.
Voilà tout.
D’ailleurs, comme mentionné précédemment, les layer2 évoluent de plus en plus vers une architecture modulaire : intégration de la technologie ZK dans le cadre OP Stack pour l’extension de confidentialité ; remplacement de la DA d’Ethereum par des solutions tierces comme Celestia afin de réduire les coûts ; transformation progressive du modèle traditionnel utilisant ETH comme unique moyen de paiement des frais, en faveur d’une utilité accrue des jetons propres aux layer2 ; voire même, la possibilité pour un layer2 d’envoyer ses lots de transactions vers différents environnements d’exécution VM, comme Solana ou Ethereum.
Un nouveau paradigme émergerait alors : les layer2 ne seraient plus simplement des extensions d’Ethereum. Solana pourrait devenir un layer2 d’Ethereum, et même la définition de « layer2 » serait radicalement repensée.
Imaginons hardiment : les layer2 deviendraient des « layer1 » d’entrée, capables de gérer massivement des transactions concurrentes, tandis qu’Ethereum, Solana et autres anciennes « layer1 » se transformeraient en nouveaux « layer2 » spécialisés dans le règlement des actifs et la sécurité.
Le concept de layer2 n’a jamais été figé. Les plateformes layer2 ont toujours eu pour mission de résoudre le traitement massif des transactions concurrentes et d’attirer de nouveaux groupes d’utilisateurs.
Si cette mission est accomplie, dans une logique de modularité, non seulement l’autorité traditionnelle d’Ethereum en tant que layer1 serait remise en question, mais toute la chaîne — disponibilité des données (DA), couche d’exécution VM, voire interopérabilité et communication entre réseaux — deviendrait une infrastructure au service de l’adoption massive par les layer2.
Alors, les layer2 ne seraient plus simplement des compléments aux layer1, mais des plateformes puissantes et multifonctionnelles de consolidation et de routage des transactions. Et là, on pourrait légitimement se demander : qui est vraiment le layer2 de qui ?
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
Haotian | CryptoInsight
