Ethereum peut-il faire en sorte que les rollups fonctionnent comme un seul réseau ?

Lors d'une démonstration à Devcon, un trader a signé un ordre sur un rollup Ethereum, a acheté des jetons en utilisant la liquidité du mainnet et les a reçus en retour sur le rollup. Cette transaction montre comment les utilisateurs pourraient accéder à un marché plus profond sans déplacer eux-mêmes leurs fonds, une approche que Gnosis vise pour sa configuration par défaut au printemps 2027.

L'équipe Ethereum Economic Zone a démontré une transaction dans laquelle un utilisateur a signé un ordre sur le réseau expérimental Rollup X, un solveur CoW Swap l'a exécuté en utilisant la liquidité du mainnet Ethereum, et les jetons achetés sont revenus sur le rollup. La démonstration montre comment un trader pourrait accéder à un marché plus profond sur le mainnet sans d'abord y envoyer des fonds et attendre leur arrivée avant de passer l'ordre.

L'équipe a présenté la transaction à Devcon le 4 novembre, comme l'a rapporté crypto.news. La distinction est importante lorsque les prix évoluent rapidement, car une cotation disponible au moment où un trader commence à déplacer des fonds peut changer avant que les fonds ne soient prêts à être échangés.

Gnosis vise le printemps 2027 pour faire de cette conception sa configuration par défaut. Pour les traders, le test pratique consistera à savoir si leurs portefeuilles et applications de trading peuvent proposer cette route et si le prix disponible sur le mainnet reste intéressant après les coûts d'exécution.

Comment la transaction fonctionnerait à travers deux environnements d'exécution

L'équipe Ethereum Economic Zone a commencé avec une transaction d'octobre portant sur 0,001 ETH et une mise à jour de l'état du rollup. Le swap de Devcon a transposé le même problème de coordination dans un cadre que les traders reconnaissent. Il fallait exécuter un ordre contre la liquidité d'une autre chaîne et livrer l'actif résultant là où l'utilisateur avait commencé.

Pour un trader, l'ordre décrit un résultat. Un vendeur souhaite échanger un actif contre un autre, selon les termes de l'ordre, et recevoir le résultat sur le rollup. Le solveur assume la responsabilité de trouver un chemin d'exécution. La distinction est importante car l'utilisateur peut autoriser un résultat sans décider quel pool le solveur utilisera ni préparer une transaction séparée pour chaque opération.

Dans l'exemple de Devcon, ce chemin incluait le mainnet Ethereum. La liquidité de trading y restait, tandis que l'ordre de l'utilisateur provenait de Rollup X et que les actifs achetés y revenaient. La démonstration abordait ainsi un problème qui peut survenir même lorsque les applications de chaque réseau fonctionnent correctement de leur côté. Un trader peut avoir des fonds sur une chaîne où le marché est peu profond pour la paire souhaitée, alors que la meilleure exécution est disponible ailleurs.

Une route composée d'étapes séparées expose l'utilisateur à des décisions en cours de route. Le premier transfert peut se terminer alors que la cotation que l'utilisateur a vue a changé. À ce moment-là, l'utilisateur doit soit accepter le prix actuel, soit attendre, soit déplacer à nouveau les fonds. Une route coordonnée peut conditionner les mouvements d'actifs à l'achèvement de l'ordre entier, à condition que l'infrastructure participante puisse réaliser l'opération dans la fenêtre d'exécution convenue.

La distinction pratique se situe entre une route qui promet la livraison et une route qui lie les opérations composantes entre elles. Un service peut rendre une transaction inter-chaînes simple en assumant lui-même la responsabilité de la livraison. La conception présentée dans la démonstration donne à l'application un moyen de relier le résultat sur une chaîne à l'exécution sur une autre. L'approche qui offre la meilleure expérience dépend du prix, des actifs disponibles et des conditions dans lesquelles chaque service livre l'ordre.

Il reste encore du travail derrière la signature de l'utilisateur. Une application doit présenter les termes, le solveur doit trouver et évaluer la route, et les réseaux participants doivent s'accorder sur l'état pertinent. Un système en production doit gérer les défaillances à chacun de ces endroits. L'application peut simplifier l'interface sans faire disparaître ces tâches.

Pour un portefeuille, un test tout aussi pratique est le relevé de transactions qu'il peut afficher après l'expiration de l'ordre. Si un utilisateur signe une fois et qu'une transaction réussit, l'utilisateur devrait pouvoir voir l'actif reçu et quel compte l'a reçu. Si la route échoue, le portefeuille a toujours besoin d'un moyen de distinguer un ordre expiré d'une transaction en attente de règlement. Cela compte pendant un mouvement de marché, lorsqu'un trader pourrait passer un second ordre et doit savoir si le premier peut encore s'exécuter.

Ce sur quoi les réseaux doivent s'accorder avant de pouvoir s'exécuter ensemble

Une blockchain enregistre plus que des soldes. Son état inclut des informations utilisées par les applications, telles que les permissions de compte, les soldes de contrats et le statut des transactions. Un contrat qui veut s'appuyer sur un résultat provenant d'une autre chaîne a besoin de preuves concernant cet état. Les preuves doivent être disponibles lorsque le contrat a besoin d'utiliser le résultat.

Gnosis décrit deux conditions pour les réseaux rejoignant la conception EEZ. Ils doivent produire une preuve dans un slot Ethereum et suivre Ethereum en cas de réorganisation. Gnosis présente ces conditions comme des conditions sur un réseau connecté, laissant certains choix de mise en œuvre aux participants individuels.

Un slot donne aux ingénieurs une échéance. Si un réseau prend plus de temps que le temps disponible pour produire la preuve requise, l'autre partie ne peut pas s'y fier dans la même fenêtre. Un système de preuve qui performe bien sur des blocs typiques doit encore faire face à des charges de travail exceptionnellement exigeantes, à des interruptions et à la concurrence pour les ressources informatiques.

La seconde condition traite de ce qui se passe lorsque l'historique récent d'Ethereum change. Une transaction sur un autre réseau peut avoir reposé sur un événement dans un bloc récent du mainnet. Si un bloc concurrent le remplace, le système connecté a besoin de règles pour gérer la transaction dépendante. L'alignement limite la possibilité qu'un côté conserve un résultat basé sur un événement du mainnet qui n'appartient plus à la chaîne acceptée.

Cette relation est importante pour les utilisateurs car une transaction coordonnée et un règlement final décrivent des propriétés différentes. L'exécution coordonnée concerne la capacité des étapes à se compléter ensemble. Le règlement final concerne le moment où les participants peuvent considérer le résultat comme réglé selon les règles des réseaux impliqués. Un portefeuille peut offrir une vue de l'opération tout en distinguant une transaction incluse d'une transaction ayant atteint le statut de règlement qu'une entreprise exige.

Les travaux d'ingénierie antérieurs de Gnosis ont traité des engagements de racine de bloc, des limites de gaz et de la manière dont les mises à niveau seraient effectuées. Ces choix affectent la façon dont les réseaux peuvent reconnaître les résultats les uns des autres et la quantité de travail que les applications peuvent leur demander. Le jalon d'octobre a mis une opération simple sur le mainnet, tandis que les démonstrations de novembre ont donné aux développeurs des charges de travail plus variées à essayer.

Où la conception pourrait aller au-delà du trading

La démonstration Safe a appliqué la même approche à la propriété d'un portefeuille. Une trésorerie qui utilise des comptes séparés sur différentes chaînes peut faire face à un écart entre la suppression d'un signataire sur un réseau et la mise à jour des permissions ailleurs. L'exemple a montré comment un rollup pouvait vérifier un changement de propriété effectué sur le mainnet dans la même transaction.

Une troisième démo a vérifié une signature post-quantique Falcon sur le rollup et a utilisé le résultat pour autoriser un transfert sur le mainnet. L'équipe a rapporté une consommation de gaz inférieure de 91 % dans sa comparaison avec la vérification effectuée directement sur le mainnet. L'économie mesurée concernait cet exercice de vérification, et une application en production devrait tenir compte de ses coûts complets d'exécution et de règlement.

Une seule signature laisse encore un marché pour l'exécution

La route de swap déplace une partie du travail loin de la personne qui passe un ordre. Un solveur doit décider où l'exécuter, tenir compte des frais et soumettre les opérations nécessaires pour le compléter. Un utilisateur peut recevoir une seule cotation même si le solveur a intégré plusieurs étapes dans le montant offert.

Cet arrangement est surtout utile lorsque la liquidité disponible sur un autre réseau améliore suffisamment la transaction pour couvrir le coût de l'atteindre. Un petit ordre dans un marché local profond peut être moins cher à exécuter localement. Un ordre plus important dans un pool peu profond pourrait recevoir un meilleur prix de la liquidité du mainnet même après les coûts d'exécution supplémentaires.

Il importe aussi de savoir ce qui arrive aux tentatives échouées. L'annulation des mouvements d'actifs empêche le trader de se retrouver avec une seule branche de la transaction envisagée. Une application ou un solveur peut néanmoins encourir des coûts en organisant ou en tentant l'exécution, selon la manière dont la route est mise en œuvre. Dans un marché en production, ces coûts peuvent affecter les ordres que les solveurs sont prêts à exécuter et la façon dont ils fixent le prix de leurs cotations.

Une bonne comparaison pour les traders utiliserait la même taille d'ordre, la même paire de jetons et la même fenêtre temporelle. Le prix reçu après frais peut ensuite être comparé avec un échange local ou une route qui transfère les fonds en étapes séparées. Le nombre de clics mesure la commodité. Le montant net reçu mesure la transaction elle-même.

Comment le projet est passé d'une proposition à un devnet

Le projet a été présenté publiquement à l'EthCC au printemps par Gnosis et ZisK, avec le soutien de la Fondation Ethereum. La proposition initiale concernait la liquidité et les applications qui s'étaient réparties entre différents réseaux de couche 2. Rollup X offre aux développeurs un environnement dans lequel tester comment une transaction partagée peut utiliser ces applications.

Le choix de la démonstration a son importance. Déplacer une petite quantité d'ETH entre environnements teste une opération relativement directe. Un échange introduit la nécessité de satisfaire un ordre contre la liquidité du marché et de restituer un actif. Un changement de propriété d'un Safe implique des permissions. La vérification de signature exige qu'un environnement effectue un contrôle et qu'un autre agisse sur son résultat. Chacun sonde une dépendance différente.

Une route qui fonctionne pour l'une de ces opérations peut être impraticable pour une autre. Un échange doit composer avec des prix et une liquidité qui évoluent en continu. Un changement de propriété est moins sensible au prix du marché mais peut avoir des modes de défaillance plus lourds de conséquences. Une application de vérification peut bénéficier d'effectuer un travail computationnel ailleurs même lorsqu'il n'y a aucune raison économique de déplacer des fonds entre réseaux.

L'exigence commune est que le contrat destinataire puisse se fier à l'information au moment où il en a besoin. Cela met la pression sur le logiciel qui maintient les liens. Une application ne peut offrir une interface simple que si le chemin d'exécution gère l'état requis et renvoie le résultat attendu. Dans un produit en production, les développeurs devraient décider quelles opérations méritent d'être placées sur ce chemin et lesquelles peuvent fonctionner indépendamment.

L'argument de Gnosis pour faire de cette technologie le choix par défaut repose en partie sur ce que les applications pourraient éviter de dupliquer. Une équipe construisant sur un nouveau réseau pourrait autrement avoir besoin de financer une liquidité locale pour une longue liste de marchés. La capacité d'atteindre les pools du mainnet pourrait lui permettre d'offrir la négociation sur une paire avant qu'un pool local dédié ne devienne viable. Pour un fournisseur de liquidité local, le même choix crée une concurrence provenant d'une autre source d'exécution.

L'effet sur les utilisateurs se mesure le plus facilement dans les produits qui divulguent les deux routes. Un portefeuille pourrait comparer une exécution locale avec une exécution sur le mainnet pour le même ordre et afficher le montant net sur la même chaîne de destination. Un outil de trésorerie pourrait documenter combien de transactions séparées sont nécessaires pour appliquer un changement d'autorité. Ces tests montreraient où l'approche modifie les coûts d'exécution réels ou le travail opérationnel.

Le calendrier compte parce qu'une démonstration réussie peut être bien plus facile à exploiter qu'un service avec de nombreux utilisateurs et applications. Un système en production doit gérer des requêtes simultanées, des conditions de marché variables et des changements logiciels. Faire passer les applications existantes de Gnosis Chain par cette transition testerait davantage de ces dépendances que les seuls exemples de la Devcon.

Ce que le prix d'un échange inter-chaînes devrait couvrir

Un trader compare le montant de l'actif acheté qui arrive après les coûts. Un pool local a ses propres frais de négociation et impact sur le prix. Une route via le mainnet peut offrir une liquidité plus profonde, mais elle peut nécessiter plus de travail d'exécution et entraîner des coûts pour l'utiliser. Un solveur décidant entre les routes doit peser le meilleur prix du pool contre ces coûts.

Imaginez qu'un pool local livrerait 9 900 $ d'un actif après tous les frais sur un ordre d'une valeur de référence de 10 000 $. Une route inter-chaînes qui peut exécuter la transaction pour 9 980 $ avant les coûts d'exécution dispose de jusqu'à 80 $ de marge avant que le devis local ne devienne meilleur. Si atteindre le meilleur pool coûte 30 $, la route inter-chaînes livre 9 950 $. À 100 $ de coût supplémentaire, la route locale offre davantage. Les chiffres illustrent la comparaison et ne décrivent aucun devis réel.

La taille de l'ordre modifie ce calcul. Une transaction plus importante peut faire bouger le prix davantage dans un pool peu profond, donnant au solveur plus de raisons d'atteindre un marché plus profond. Une petite transaction peut avoir peu d'impact sur le prix local et laisser trop peu d'économies pour couvrir la route inter-chaînes. Même pour une même paire de jetons, la route utile peut changer au cours d'une journée à mesure que la liquidité et les coûts réseau évoluent.

Les solveurs doivent aussi évaluer le prix des tentatives échouées et le temps qu'ils passent à trouver des routes. Une opération échouée peut laisser les mouvements d'actifs de l'utilisateur annulés, tandis que les parties qui organisent l'ordre peuvent tout de même faire face à des frais liés à la tentative d'exécution. L'effet du design sur le spread qu'un trader voit dépend de la manière dont une implémentation en production répartit ces coûts et du degré de concurrence entre les entreprises proposant des devis.

Pour un portefeuille intégrant ce design, l'information importante est ce que l'utilisateur peut comparer. Un devis qui indique le montant minimum livré et le réseau sur lequel il arrivera donne au trader un moyen d'évaluer le résultat. Une interface qui met en avant un clic ou une signature montre quelque chose sur la commodité, tandis que le prix et les conditions de livraison montrent si la route sert l'ordre.

Une plateforme de trading envisageant ce design devrait décider ce qu'elle montre aux clients au sujet des dépendances d'un devis. Une route pourrait être entièrement exécutée là où l'utilisateur détient des fonds. Une autre pourrait invoquer la liquidité du mainnet et dépendre d'une preuve prête dans un slot. Même si les deux devis affichent le même jeton et le même montant, ils peuvent avoir des règles d'expiration différentes et des raisons d'échouer différentes. L'interface devrait communiquer le montant minimum que le client accepte et ce qui se passe si le solveur ne peut pas le livrer.

Les applications doivent aussi déterminer comment elles collecteraient suffisamment de données comparables pour identifier pourquoi une route coûte plus cher. Une série utile inclurait la même paire et les mêmes tailles de transaction sur les mêmes réseaux, avec les devis capturés à des moments proches. Une seule transaction sur une paire inhabituellement peu liquide pourrait faire paraître la capacité d'atteindre un autre marché plus précieuse qu'elle ne l'est pour les ordres quotidiens. Le problème inverse peut survenir avec une paire majeure déjà échangée à bas prix sur le rollup de l'utilisateur. Le prix d'exécution, les frais inclus et les conditions d'expiration doivent être comparés ensemble.

Safe fait de l'autorité inter-chaînes une partie du problème

Une trésorerie peut utiliser un compte pour les paiements réguliers et un autre pour détenir des actifs sur un réseau différent. Si elle modifie les personnes autorisées à approuver les dépenses, quelqu'un doit s'assurer que le changement est reflété là où les actifs sont conservés. Des mises à jour séparées créent des occasions pour qu'une liste de signataires obsolète reste active sur un compte moins fréquemment utilisé.

La démonstration Safe a montré comment une application pouvait utiliser un changement de propriété sur le mainnet dans le cadre d'une transaction coordonnée impliquant un rollup. Son bénéfice dépend de la manière dont la trésorerie a choisi d'attribuer l'autorité. Une organisation pourrait vouloir que le mainnet détermine un ensemble partagé de signataires, tout en conservant une politique distincte pour un compte de dépenses local servant une équipe particulière.

Une structure d'autorité partagée peut réduire le travail en double. Elle rend aussi la gestion des erreurs plus importante, car un seul changement peut avoir des conséquences sur plusieurs emplacements. Une trésorerie devrait comprendre comment ses comptes se rétablissent si une mise à jour est erronée, qui peut autoriser une correction et comment une chaîne connectée se comporte si elle ne peut pas obtenir un résultat actuel.

Une organisation évaluant le design demanderait donc quelle opération elle souhaite coordonner. Lire une liste de signataires, mettre à jour la propriété et déplacer des actifs de trésorerie ont des conséquences différentes. La valeur d'en effectuer une dans une transaction partagée n'établit pas qu'une organisation devrait déléguer chaque décision au même compte.

L'intérêt institutionnel dépasse la scène du Devcon. Consensys a annoncé un système d'interopérabilité pour les banques et a déclaré qu'elle prévoit de soutenir la norme EEZ. Pour une banque, la compatibilité s'accompagnerait de questions sur qui peut utiliser le système, quels contrôles s'appliquent à chaque opération et comment elle enregistre le résultat dans les systèmes existants.

Le cas Safe suggère un ensemble différent de tests produit. Une équipe pourrait vouloir que des signataires sur un réseau approuvent une opération qui n'affecte que des actifs sur un autre. Cela soulève la question de savoir si un signataire supprimé localement peut encore autoriser une opération inter-réseaux soumise plus tôt. La réponse dépend de la manière dont l'application lit l'état du compte et de ce qu'elle considère comme le moment de l'autorisation. Ce sont des points qu'une application doit préciser même lorsque le protocole sous-jacent est capable de transporter le message.

Ce que la démonstration Falcon dit sur l'exécution des calculs ailleurs

La démonstration emblématique utilisait un rollup pour vérifier une signature Falcon et fournissait ce résultat à une action sur le réseau principal. L'équipe a rapporté une réduction de 91 % de la consommation de gaz dans sa comparaison avec la vérification sur le réseau principal. L'exemple a une portée plus étroite qu'une affirmation sur le coût de chaque transaction qui pourrait utiliser la conception. Il compare une opération spécifiée à travers deux chemins d'exécution.

L'opportunité est d'exécuter une vérification coûteuse en calcul dans un environnement adapté, tout en laissant un autre contrat s'appuyer sur la réponse. Une application qui effectue une vérification rarement peut valoriser les économies différemment d'une qui la répète à chaque ordre. La décision dépend aussi de la manière dont l'application valide le résultat et des autres étapes qu'elle doit accomplir pour l'utiliser.

La vérification post-quantique est une application de ce modèle. Un contrat pourrait avoir besoin d'autres informations provenant d'un environnement connecté avant de pouvoir continuer, comme de savoir si un compte a le droit d'effectuer une opération. Le problème commun est de rendre un résultat disponible dans la même fenêtre d'exécution. Différentes vérifications peuvent avoir des exigences de calcul et de preuve très différentes.

Pour un utilisateur, la prise en charge d'un schéma de signature dans une application ne détermine pas la sécurité de chaque portefeuille ou transaction sur la chaîne. La démonstration portait sur la vérification et l'autorisation du transfert spécifique. Changer les règles selon lesquelles les portefeuilles signent généralement les transactions impliquerait d'autres décisions concernant les logiciels, la compatibilité et les comptes qui adoptent les changements.

Il existe une distinction similaire pour les développeurs qui évaluent la démonstration Falcon. Le gaz dépensé par le contrat lisant un résultat de vérification et le coût de production de ce résultat ailleurs appartiennent à des environnements d'exécution différents. Mesurer le premier capture une contrainte réelle pour une application qui, autrement, doit exécuter la vérification sur le réseau principal. Un service qui décide s'il peut offrir la fonctionnalité doit aussi tenir compte du second. Il doit également savoir si la vérification peut s'achever sous charge, lorsque de nombreuses requêtes peuvent se disputer la même capacité.

Gnosis devra accompagner les applications existantes à travers la transition

GnosisDAO a autorisé le passage d'un réseau autonome à un rollup EEZ via le GIP 153 en août. La migration compte parce que les utilisateurs et applications existants ont des soldes, des adresses et des dépendances liés à la chaîne en activité. Pour eux, adopter un nouvel arrangement d'exécution et de règlement constitue un changement d'infrastructure qu'ils utilisent déjà.

Les questions auxquelles une application en activité doit répondre diffèrent de celles d'un réseau de développement. Ses utilisateurs doivent savoir comment les soldes sont transférés, quels portefeuilles et fournisseurs d'infrastructure soutiennent la migration et où obtenir un registre fiable de l'activité pendant que la transition est en cours. Les plateformes de trading doivent tenir compte de la possibilité que les intégrations deviennent disponibles à des moments différents.

Un rollup capable d'accéder aux marchés du réseau principal pourrait être en mesure d'offrir des routes avant de constituer des pools profonds qui lui soient propres pour chaque paire de jetons. Une chaîne disposant d'une liquidité établie a une décision différente. Ses applications peuvent choisir entre l'exécution locale et une route partagée, et les fournisseurs de liquidité déjà présents sur la chaîne peuvent voir comment ces choix affectent l'activité dans leurs pools.

La migration testera également la différence entre lancer un réseau et faire d'une fonctionnalité le choix par défaut pour les utilisateurs. Un premier bloc peut démontrer que la nouvelle chaîne fonctionne. Une route utilisateur par défaut exige que les portefeuilles, les applications et les autres fournisseurs utilisent le nouveau chemin dans l'activité ordinaire. Des reportages antérieurs décrivaient un objectif autour du changement d'année pour un déploiement initial. La mise à jour de novembre de Gnosis indique le printemps 2027 comme objectif pour le fonctionnement par défaut.

Gnosis donne aux développeurs un endroit pour poser ces questions face à un déploiement avec des applications existantes. La migration placerait l'exécution, la prise en charge des portefeuilles et les procédures opérationnelles sous le même calendrier, permettant de suivre comment l'équipe gère les retards ou les intégrations partielles. Sa mise à jour de novembre identifie le printemps 2027 comme objectif pour faire de la conception le choix par défaut. Les opérations du Devcon ont eu lieu sur Rollup X.

Ce qu'il faut surveiller

• Routes prises en charge. Portefeuilles et applications publiant les réseaux sur lesquels la même opération est disponible.
• Devis d'exécution. Rendement net et taux d'ordres échoués comparables pour les échanges locaux et inter-réseaux.
• Performance des slots. Tests répétés montrant la disponibilité des preuves et la récupération lorsque Ethereum se réorganise.
• Autorisations de trésorerie. Périmètre publié, expiration et règles de révocation pour les intégrations Safe.
• Jalons Gnosis. Tests de migration publics et progrès vers l'objectif du printemps 2027.

FAQ