Briser les silos de liquidité des L2 : la logique fondamentale de la zone économique Ethereum (EEZ) et une nouvelle solution inter-chaînes
Dans l’architecture de la zone économique Ethereum (EEZ), l’objectif central du mécanisme inter-chaînes est de permettre la « composabilité synchrone » (Synchronous Composability). Pour bien comprendre son fonctionnement, nous pouvons décomposer le processus en deux questions essentielles : « Pourquoi avons-nous besoin d’un mécanisme inter-chaînes ? » et « Pourquoi faut-il que tout se déroule au sein d’un même bloc Ethereum ? ».
I. Comment fonctionne le mécanisme inter-chaînes ? (Les trois piliers de l’EEZ)
Dans les ponts inter-chaînes traditionnels, les chaînes A et B fonctionnent de manière asynchrone : vous devez verrouiller vos fonds sur la chaîne A, attendre la confirmation d’un portefeuille multisignature ou de validateurs, puis les frapper sur la chaîne B. Le processus est lent et peut facilement être interrompu. L’EEZ, quant à elle, utilise un mécanisme de « coordination synchrone fondée sur les preuves et les proxys », qui repose principalement sur trois composants :
Preuves en temps réel (Real-time proving) :
Auparavant, générer une preuve de validité pour un Rollup pouvait prendre plusieurs minutes, voire plusieurs heures.
L’EEZ s’appuie sur les dernières technologies matérielles et sur les preuves en temps réel pour ramener la génération d’une preuve à un seul slot Ethereum (12 secondes). Le réseau principal Ethereum n’a pas besoin de réexécuter le code du Rollup : il lui suffit de vérifier cette preuve générée en temps réel pour confirmer la validité de l’état du Rollup.
Compositeur (Composer) et table d’exécution (Execution Table) :
Le compositeur est un opérateur clé. Avant la production d’un bloc Ethereum, il exécute à l’avance la transaction sur les différentes chaînes concernées par les appels inter-chaînes et consigne le résultat de chaque appel dans une « table de réponses précalculées » (la table d’exécution).
Contrats proxy (Proxy) :
Chaque contrat d’un Rollup possède une adresse proxy connue à l’avance sur Ethereum L1 (et inversement).
Lorsqu’un appel inter-chaînes a lieu, le code s’écrit comme un appel de contrat local ordinaire, sans protocole complexe de transmission asynchrone de messages. Le proxy consulte le contrat EEZ pour vérifier le résultat d’exécution précalculé par le compositeur. Si le résultat correspond, l’opération est immédiatement autorisée.
II. Pourquoi faut-il que tout se déroule au sein d’un même bloc Ethereum ? (La raison fondamentale)
Le fait que tout se déroule « au sein d’un même bloc Ethereum » (c’est-à-dire lors d’appels synchrones) est au cœur de ce mécanisme. Il y a principalement trois raisons à cela :
Remédier à l’absence d’« atomicité (Atomicity) » et garantir un véritable « tout ou rien »
Dans les opérations financières et les opérations complexes impliquant des contrats intelligents, l’atomicité est essentielle : une transaction comportant plusieurs étapes doit soit réussir entièrement, soit échouer entièrement.
Le problème des opérations inter-chaînes asynchrones : si vous procédez par étapes (emprunt sur L1, transfert inter-chaînes, transaction sur L2), et que la deuxième étape se bloque en cours de route ou que le marché connaît de fortes fluctuations, vos actifs sont exposés à des risques importants. Par exemple, les fonds peuvent avoir quitté L1, mais la transaction échouer dans le pool cible sur L2 pour une raison quelconque, laissant les fonds bloqués entre les deux.
L’avantage de la synchronisation au sein d’un même bloc : si toutes les opérations sont regroupées dans un même bloc Ethereum, l’ensemble de la chaîne de transactions bénéficie d’une atomicité absolue. Lors de la simulation, si le compositeur détecte qu’une étape quelconque (par exemple, un glissement de prix trop important ou un solde insuffisant) va échouer, l’ensemble du lot de transactions est annulé avant la production du bloc. Si la transaction est incluse dans la chaîne, le moindre problème entraîne le retour arrière immédiat et sécurisé de toutes les opérations concernées sur Ethereum et le Rollup. Cela élimine complètement les risques intermédiaires liés aux opérations inter-chaînes.
Éliminer la fragmentation de la liquidité et permettre aux L2 d’accéder en temps réel à la profondeur des pools L1
Si les opérations inter-chaînes ne se déroulent pas au sein d’un même bloc, vous devez transférer à l’avance des fonds vers les pools de chaque L2, où ils restent immobilisés. Cela entraîne une grave inefficacité de l’utilisation des capitaux et une fragmentation de la liquidité.
Au sein d’un même bloc Ethereum, un Rollup peut « emprunter » directement, au moment même où l’appel est lancé, la liquidité abondante du réseau principal Ethereum L1 (par exemple, Uniswap ou Aave).
Exemple : vous déclenchez une transaction sur L2 ; au sein du même bloc Ethereum, elle appelle directement Uniswap sur L1 pour effectuer un échange, puis renvoie le résultat. Pour l’utilisateur, c’est comme s’il opérait sur une seule et même chaîne : il n’a pas besoin de transférer au préalable des fonds vers chaque chaîne.
Éviter les désynchronisations d’état et les attaques par « réorganisation (Reorg) »
Des réorganisations de blocs (Reorg) peuvent survenir à tout moment sur une blockchain. Si une opération inter-chaînes est asynchrone et s’étend sur plusieurs blocs, la chaîne A peut considérer une transaction comme réussie, puis une réorganisation du réseau principal Ethereum peut faire disparaître l’état dont dépendait la chaîne A. Cela peut provoquer un désordre comptable catastrophique.
Exiger que tout se déroule au sein d’un même bloc Ethereum signifie que toutes les transitions d’état, la vérification des preuves et les rappels des proxys sont rattachés au même point d’ancrage temporel (bloc de synchronisation).
Les chaînes qui rejoignent l’EEZ doivent respecter une règle absolue : en cas de réorganisation d’Ethereum, la chaîne doit effectuer un retour arrière synchronisé. Cette règle garantit, au niveau fondamental, que les états inter-chaînes ne seront jamais désynchronisés au fil du temps et ne donneront pas lieu à des incohérences comptables.
💡 En résumé :
Tout faire tenir dans un même bloc Ethereum permet de remplacer les ponts inter-chaînes fragiles et lents par la garantie la plus robuste des blockchains : l’« atomicité (Atomicity) ». Ainsi, les applications réparties sur différents L2 peuvent partager instantanément et en toute sécurité l’ensemble de la liquidité et des ressources de calcul du réseau principal Ethereum, comme si elles fonctionnaient sur un seul et même cœur de processeur.
Dans l’architecture de la zone économique Ethereum (EEZ), l’objectif central du mécanisme inter-chaînes est de permettre la « composabilité synchrone » (Synchronous Composability). Pour bien comprendre son fonctionnement, nous pouvons décomposer le processus en deux questions essentielles : « Pourquoi avons-nous besoin d’un mécanisme inter-chaînes ? » et « Pourquoi faut-il que tout se déroule au sein d’un même bloc Ethereum ? ».
I. Comment fonctionne le mécanisme inter-chaînes ? (Les trois piliers de l’EEZ)
Dans les ponts inter-chaînes traditionnels, les chaînes A et B fonctionnent de manière asynchrone : vous devez verrouiller vos fonds sur la chaîne A, attendre la confirmation d’un portefeuille multisignature ou de validateurs, puis les frapper sur la chaîne B. Le processus est lent et peut facilement être interrompu. L’EEZ, quant à elle, utilise un mécanisme de « coordination synchrone fondée sur les preuves et les proxys », qui repose principalement sur trois composants :
Preuves en temps réel (Real-time proving) :
Auparavant, générer une preuve de validité pour un Rollup pouvait prendre plusieurs minutes, voire plusieurs heures.
L’EEZ s’appuie sur les dernières technologies matérielles et sur les preuves en temps réel pour ramener la génération d’une preuve à un seul slot Ethereum (12 secondes). Le réseau principal Ethereum n’a pas besoin de réexécuter le code du Rollup : il lui suffit de vérifier cette preuve générée en temps réel pour confirmer la validité de l’état du Rollup.
Compositeur (Composer) et table d’exécution (Execution Table) :
Le compositeur est un opérateur clé. Avant la production d’un bloc Ethereum, il exécute à l’avance la transaction sur les différentes chaînes concernées par les appels inter-chaînes et consigne le résultat de chaque appel dans une « table de réponses précalculées » (la table d’exécution).
Contrats proxy (Proxy) :
Chaque contrat d’un Rollup possède une adresse proxy connue à l’avance sur Ethereum L1 (et inversement).
Lorsqu’un appel inter-chaînes a lieu, le code s’écrit comme un appel de contrat local ordinaire, sans protocole complexe de transmission asynchrone de messages. Le proxy consulte le contrat EEZ pour vérifier le résultat d’exécution précalculé par le compositeur. Si le résultat correspond, l’opération est immédiatement autorisée.
II. Pourquoi faut-il que tout se déroule au sein d’un même bloc Ethereum ? (La raison fondamentale)
Le fait que tout se déroule « au sein d’un même bloc Ethereum » (c’est-à-dire lors d’appels synchrones) est au cœur de ce mécanisme. Il y a principalement trois raisons à cela :
Remédier à l’absence d’« atomicité (Atomicity) » et garantir un véritable « tout ou rien »
Dans les opérations financières et les opérations complexes impliquant des contrats intelligents, l’atomicité est essentielle : une transaction comportant plusieurs étapes doit soit réussir entièrement, soit échouer entièrement.
Le problème des opérations inter-chaînes asynchrones : si vous procédez par étapes (emprunt sur L1, transfert inter-chaînes, transaction sur L2), et que la deuxième étape se bloque en cours de route ou que le marché connaît de fortes fluctuations, vos actifs sont exposés à des risques importants. Par exemple, les fonds peuvent avoir quitté L1, mais la transaction échouer dans le pool cible sur L2 pour une raison quelconque, laissant les fonds bloqués entre les deux.
L’avantage de la synchronisation au sein d’un même bloc : si toutes les opérations sont regroupées dans un même bloc Ethereum, l’ensemble de la chaîne de transactions bénéficie d’une atomicité absolue. Lors de la simulation, si le compositeur détecte qu’une étape quelconque (par exemple, un glissement de prix trop important ou un solde insuffisant) va échouer, l’ensemble du lot de transactions est annulé avant la production du bloc. Si la transaction est incluse dans la chaîne, le moindre problème entraîne le retour arrière immédiat et sécurisé de toutes les opérations concernées sur Ethereum et le Rollup. Cela élimine complètement les risques intermédiaires liés aux opérations inter-chaînes.
Éliminer la fragmentation de la liquidité et permettre aux L2 d’accéder en temps réel à la profondeur des pools L1
Si les opérations inter-chaînes ne se déroulent pas au sein d’un même bloc, vous devez transférer à l’avance des fonds vers les pools de chaque L2, où ils restent immobilisés. Cela entraîne une grave inefficacité de l’utilisation des capitaux et une fragmentation de la liquidité.
Au sein d’un même bloc Ethereum, un Rollup peut « emprunter » directement, au moment même où l’appel est lancé, la liquidité abondante du réseau principal Ethereum L1 (par exemple, Uniswap ou Aave).
Exemple : vous déclenchez une transaction sur L2 ; au sein du même bloc Ethereum, elle appelle directement Uniswap sur L1 pour effectuer un échange, puis renvoie le résultat. Pour l’utilisateur, c’est comme s’il opérait sur une seule et même chaîne : il n’a pas besoin de transférer au préalable des fonds vers chaque chaîne.
Éviter les désynchronisations d’état et les attaques par « réorganisation (Reorg) »
Des réorganisations de blocs (Reorg) peuvent survenir à tout moment sur une blockchain. Si une opération inter-chaînes est asynchrone et s’étend sur plusieurs blocs, la chaîne A peut considérer une transaction comme réussie, puis une réorganisation du réseau principal Ethereum peut faire disparaître l’état dont dépendait la chaîne A. Cela peut provoquer un désordre comptable catastrophique.
Exiger que tout se déroule au sein d’un même bloc Ethereum signifie que toutes les transitions d’état, la vérification des preuves et les rappels des proxys sont rattachés au même point d’ancrage temporel (bloc de synchronisation).
Les chaînes qui rejoignent l’EEZ doivent respecter une règle absolue : en cas de réorganisation d’Ethereum, la chaîne doit effectuer un retour arrière synchronisé. Cette règle garantit, au niveau fondamental, que les états inter-chaînes ne seront jamais désynchronisés au fil du temps et ne donneront pas lieu à des incohérences comptables.
💡 En résumé :
Tout faire tenir dans un même bloc Ethereum permet de remplacer les ponts inter-chaînes fragiles et lents par la garantie la plus robuste des blockchains : l’« atomicité (Atomicity) ». Ainsi, les applications réparties sur différents L2 peuvent partager instantanément et en toute sécurité l’ensemble de la liquidité et des ressources de calcul du réseau principal Ethereum, comme si elles fonctionnaient sur un seul et même cœur de processeur.