J'aimerais faire deux déclarations :

1. Aucune chaîne, qu'elle soit de niveau 1 ou de niveau 2, ne peut prendre en charge le débit requis pour atteindre Internet.
2. La mise à l'échelle des blockchains signifie élargir l'accès à la liquidité et à l'État partagé. L'ajout de blockspace via plusieurs chaînes ne fonctionne pas si cela fragmente les liquidités.

Cela représente un défi à la fois pour la conception modulaire et monolithique de l'évolutivité de la blockchain. (1) remet en question la vision monolithique, selon laquelle une seule chaîne haut débit est le meilleur moyen d'évoluer. (2) représente un défi pour la vision modulaire, car cela signifie qu'un écosystème multi-chaînes ou multi-rollup n'est pas suffisant pour évoluer de manière significative : améliorer l'accès à un état et à des liquidités partagés.

Si (1) et (2) sont vrais, pour résoudre le problème d'évolutivité, il faut étendre l'accès à l'état partagé et à la liquidité sur de nombreuses chaînes. La solution de Polygon est la couche d'agrégation, ou « AgGLayer ». L'AGGLayer sécurise les transactions inter-chaînes quasi instantanées et permet d'unifier l'état et la liquidité entre les chaînes.

Ce billet explique ce qu'est l'AGGLayer, comment il fonctionne et en quoi il diffère d'un séquenceur ou d'un prouveur partagé.

Le problème

Il y a un problème avec les L2 : la liquidité et l'état sont fragmentés entre les cumuls et la L1.

C'est une mauvaise chose du point de vue de la facilité d'utilisation, car cela introduit de la complexité, mais c'est aussi cher. La fragmentation des liquidités se traduit par une augmentation des dérapages et une moins bonne exécution. Les rollups optimistes (OR) obligent les utilisateurs à payer des passerelles tierces onéreuses pour éviter le délai de retrait de sept jours. Même les ZK Rollups (ZKRS) obligent les utilisateurs à se rendre sur Ethereum depuis et vers Ethereum pour effectuer des transactions inter-chaînes en toute confiance.

Finalité et validité

Voici pourquoi les transactions inter-chaînes fiables et à faible latence ne sont pas possibles actuellement.

Supposons qu'il y ait deux cumuls, la chaîne A et la chaîne B, qui partagent un pont vers la L1. Alice sur la chaîne A aimerait payer Bob sur la chaîne B, alors Alice bloque ou brûle des jetons sur la chaîne A pour les transférer vers la chaîne B.

Deux choses sont requises pour que Chain B crédite ces jetons à Bob en toute sécurité.

1. Le lot contenant la transaction d'Alice doit être finalisé sur Ethereum L1.
2. La chaîne B doit être en mesure de vérifier que l'état obtenu de la chaîne A est valide après la transaction d'Alice.

Si le lot contenant les transactions d'Alice n'est pas finalisé sur Ethereum, la chaîne A pourrait passer à la chaîne B et dépenser deux fois en conservant les fonds d'Alice sur la chaîne A et en frappant les fonds de Bob sur la chaîne B. De même, si la chaîne B ne vérifie pas la preuve de validité de A, la chaîne A peut inclure une transaction non valide et voler des fonds à B.

(1) et (2) signifient que les transactions inter-chaînes fiables ne peuvent pas avoir une faible latence. (1) nécessite actuellement 12 minutes, tandis que (2) nécessite d'attendre la durée de la période de défi dans les OR et quelques minutes pour générer des preuves sur les ZKR.

Une bonne expérience utilisateur n'est pas compatible avec une latence de 20 minutes. La couche d'agrégation est conçue pour résoudre ce problème.

La couche d'agrégation

Polygon est un écosystème de L2 alimentés par ZK qui utilisent Ethereum. La couche d'agrégation est un protocole décentralisé géré par des nœuds jalonnés qui garantit la sécurité des transactions inter-chaînes à faible latence et un pont unifié [1].

Dans ce contexte, le terme « sécurité » signifie ce qui suit :

Il est impossible de finaliser/régler l'état d'un cumul sur Ethereum si cet état de chaîne repose sur un état non valide ou non finalisé provenant d'une autre chaîne, ou s'il inclut une transaction provenant d'un bundle atomique [2] qui ne s'est pas exécuté correctement sur toutes les autres chaînes.

En d'autres termes, l'état de la chaîne B ne peut pas être finalisé sur Ethereum s'il dépend d'un état non valide ou non finalisé de la chaîne A.

Cette garantie est importante. Cela permet à la chaîne B d'interagir en toute sécurité avec la chaîne A avec une latence très faible, avant que l'état de la chaîne A ne soit finalisé sur Ethereum ou qu'une preuve ne soit générée.

Comment fonctionne la couche d'agrégation

La couche d'agrégation fonctionne en trois phases. Supposons que la chaîne A soit une chaîne alimentée par ZK qui fonctionne dans l'écosystème Polygon.

1. Préconfirmation : la chaîne A soumet l'en-tête d'un nouveau bloc/lot A1 au
2. AgGLayer et une preuve client légère. L'en-tête inclut les engagements envers tous
3. autres blocs et lots dont dépend Ar (B1, C1, etc.). Quand le nouveau lot sera
4. acceptée sans preuve de validité, elle est considérée comme « préconfirmée » par l'AGGLayer.
5. Confirmation : La chaîne A, ou n'importe quel nœud complet de A, génère une preuve pour A1 et la soumet à l'AgGLayer. Une fois la preuve vérifiée par l'AgGLayer, A1 est confirmé si tous les lots dont elle dépend sont également confirmés.
6. Finalisation : Une fois A1 confirmé, sa preuve est agrégée avec les lots provenant d'autres cumuls en une seule preuve publiée sur Ethereum. La preuve agrégée confirme que les états de chaîne dépendants et les bundles sont cohérents.

Les chaînes peuvent trouver le compromis entre latence et garantie de vivacité. Une chaîne peut choisir d'interagir avec une autre chaîne après l'étape de pré-confirmation pour les transactions inter-chaînes à très faible latence, mais fondamentalement, ce modèle est compatible avec les chaînes en attente de confirmation, voire de finalisation.

La garantie de sécurité pour les transactions inter-chaînes est appliquée à la troisième étape. Voyons plus en détail comment ce design permet une interaction sécurisée entre les chaînes.

Interopérabilité asynchrone

Prenons le premier exemple de transfert inter-chaînes. Alice on Chain A veut verrouiller ou graver des jetons dans le bloc A1 afin de créer et de transférer des jetons à Bob on Chain B. Si la chaîne B n'attend pas que le A1 soit finalisé sur Ethereum avec une preuve valide, alors la chaîne A pourrait équivoquer ou invalider la chaîne B.

La couche d'agrégation résout ce problème de manière simple. La chaîne B peut temporairement partir du principe que A1 est valide et qu'il sera finalisé sur Ethereum, sans même attendre de preuve. Le séquenceur de la chaîne B passe à la racine d'état A1 revendiquée de la chaîne A en tant que dépendance dans l'en-tête de B1 (en tant que B1A1) avant de le soumettre à la couche d'agrégation. La latence requise pour que la chaîne B génère B1 passe de 20 minutes à quelques secondes tout au plus.

À l'étape de confirmation, la couche d'agrégation crée un graphique de dépendance pour chaque bloc/lot soumis. Par exemple, si A1 dépend de B1, qui dépend à son tour de B1, C1 est confirmé dès qu'une preuve πC1 est soumise. Mais, même si π A1 est reçu, π A1 n'est confirmé qu'à la fois par π C1 et π B1. L'aspect essentiel de cette conception est que le circuit d'agrégation des preuves assure la cohérence entre les dépendances. Si B1A1 n'est pas cohérent avec le bloc A1 soumis par la chaîne A, ou s'il manque une preuve pour A1, alors B1 ne peut pas être inclus dans le lot agrégé finalisé sur Ethereum.

Ce mécanisme garantit que si la chaîne A crée une équivoque ou soumet un bloc non valide, disons A1, aucun lot qui dépend d'une racine d'état invalide ou équivoque pour la chaîne A ne pourra pas être finalisé/réglé sur Ethereum. Même si l'AggLayer lui-même est équivoque, les chaînes ont la garantie cryptographique que tout bloc dépendant d'un bloc invalide ou équivoque ne peut pas être finalisé, car deux preuves d'états de chaîne incohérents ou non valides ne peuvent pas être agrégées ensemble dans le circuit d'agrégation de preuves. Cela garantit la préservation des propriétés de sécurité décrites ci-dessus.

Interopérabilité atomique

Le mécanisme de sécurité peut être étendu au boîtier atomique. Supposons qu'un utilisateur soumette un ensemble atomique de transactions à plusieurs chaînes. Ce bundle est ordonné, donc le résultat de l'exécution de la transaction sur la chaîne A est transmis à la chaîne B, et de même, l'état mis à jour de la chaîne B est transmis à la chaîne C, etc. Si toutes les transactions sont exécutées avec succès, toutes chaînes confondues, le bundle est inclus ; sinon, il est rejeté.

L'idéal serait de permettre d'inclure les transactions atomiques sans :

1. Exiger de l'opérateur de la chaîne B qu'il gère un nœud complet pour toutes les autres chaînes incluses dans un bundle ; ou
2. Accepter le risque que le bundle soit partiellement inclus sur Ethereum (ce qui nuirait aux chaînes participantes).

Cela pose un problème de sécurité similaire à celui du cas asynchrone : la chaîne A peut créer une équivoque et soumettre un lot qui n'inclut pas réellement le faisceau atomique, ou envoyer un résultat non valide à la chaîne B.

Heureusement, le même mécanisme que celui du boîtier asynchrone peut être réutilisé pour le boîtier atomique. La chaîne B s'engage à proposer des offres groupées et a reçu les résultats de transactions d'autres chaînes. La couche d'agrégation (et le circuit d'agrégation des preuves) vérifie la cohérence des bundles d'une chaîne à l'autre. Un lot contenant un bundle de la chaîne B ne peut être finalisé/réglé sur Ethereum que si toutes les transactions du bundle sont exécutées avec succès.

Composabilité inter-chaînes

La couche d'agrégation permet une composabilité inter-chaînes à très faible latence grâce à des appels inter-chaînes asynchrones. C'est une primitive incroyablement puissante : les contrats peuvent appeler en toute sécurité des contrats d'autres chaînes avec une latence très faible, sans attendre la finalité d'Ethereum. Un utilisateur pouvait accéder à la chaîne OKX sur Polygon et effectuer un dépôt immédiat sur un marché de prêt très liquide sur Aave sur une autre chaîne en un clic, sans avoir à quitter un actif synthétique encapsulé.

Infrastructure de coordination émergente

L'AggregationLayer garantit la sécurité des interactions inter-chaînes quasi instantanées [3]. Mais ce n'est que la moitié de la bataille. Comment les opérateurs de chaînes partagent-ils les états de la chaîne les uns des autres et se font-ils confiance ? Comment coordonnent-ils la production de faisceaux atomiques ?

L'un des objectifs de conception de l'AGGLayer est qu'il soit minimal. Son objectif est de garantir la sécurité et de fournir une base permettant à chacun de créer une infrastructure de coordination dynamique dans des environnements différents.

Les opérateurs de chaînes peuvent choisir librement entre des mécanismes de coordination émergents en fonction de leurs hypothèses de confiance. Il peut s'agir de relais, d'une infrastructure de test partagée ou de clusters de séquenceurs de validité partagés [4]. Ils protègent les chaînes contre les problèmes de vivacité lorsqu'elles dépendent de l'état de la chaîne ou de l'offre groupée.

L'écosystème Polygon donne la priorité au choix et à la souveraineté des chaînes. Les chaînes peuvent gérer leurs propres environnements d'exécution modifiés, utiliser leurs propres jetons pour le jalonnement et les frais de gaz, choisir leurs propres mécanismes de disponibilité des données, etc. De même, les chaînes devraient décider de la manière de gérer les compromis entre l'interopérabilité et le risque de défauts de vivacité. Il existe plusieurs options :

1. La chaîne B peut refuser l'interopérabilité rapide et complètement la couche d'agrégation. Elle peut simplement envoyer des lots et des preuves directement à Ethereum et la finalisation n'est jamais retardée.
2. La chaîne B peut accepter l'état de la chaîne A uniquement lorsque l'état de la chaîne A est confirmé par l'AgGLayer. La chaîne B ne sera retardée que si l'AgGLayer est équivoque.
3. La chaîne B peut accepter l'état de la chaîne A lorsque la chaîne A est préconfirmée par l'AgGLayer. La chaîne B sera retardée si l'AGGLayer crée une ambiguïté ou si la chaîne A ne produit pas de preuve.
4. La chaîne B peut accepter l'état de la chaîne A dans un environnement peer-to-peer, sans vérifier que la chaîne A est préconfirmée sur l'AggLayer. La chaîne B sera retardée si la chaîne A est ambiguë ou ne produit pas de preuve.

Il est important de noter que les utilisateurs ne peuvent pas être à l'origine de problèmes de vivacité, mais uniquement de mauvais comportements ou de dysfonctionnements des chaînes. L'équivoque et la soumission d'un bloc non valide peuvent être lourdement sanctionnées, soit par des barres obliques, soit en éjectant des chaînes de l'AggLayer, les empêchant ainsi d'interagir de manière fluide. Par conséquent, un défaut de vivacité devrait être extrêmement rare.

Les chaînes peuvent prendre des précautions supplémentaires pour minimiser les risques de problèmes de vivacité, en tenant à jour des listes blanches ou noires des autres chaînes avec lesquelles elles interagissent et en limitant le nombre de chaînes pouvant être impliquées collectivement dans un lot. Ils peuvent compter sur des tiers qui gèrent des nœuds complets pour s'assurer que si une chaîne se déconnecte avant de pouvoir produire une preuve, elle dispose d'un prouveur de sauvegarde.

Le mécanisme par lequel les chaînes se coordonnent pour accepter les faisceaux atomiques est également flexible. Par exemple, un sous-ensemble de chaînes peut interagir au sein d'un cluster de séquençage à validité partagé pour une latence extrêmement faible, ou s'appuyer sur des relais.

Un relais sécurisé sur le plan cryptoéconomique pourrait permettre l'interopérabilité entre les chaînes A et B en faisant fonctionner un nœud complet pour les deux chaînes et en attestant la validité des états de chaque chaîne. Même si la chaîne A ou B préconfirme un nouveau lot puis se déconnecte, une infrastructure de test partagée peut intervenir pour générer une preuve.

Vous pouvez imaginer une nouvelle infrastructure de coordination émergeant des bases de sécurité fournies par l'AgGLayer, permettant de nouvelles et meilleures formes d'interopérabilité et de partage des liquidités. Surtout, l'ensemble de l'écosystème Polygon n'a pas besoin de partager la même infrastructure ni de faire confiance à des hypothèses. Il n'a pas besoin de fonctionner sous un seul séquenceur ou un seul prouveur à validité partagée. C'est un avantage extrêmement important par rapport aux RUP.

closing

La couche d'agrégation nous permet fondamentalement de créer un écosystème multi-chaînes qui ressemble à une seule chaîne. C'est la synthèse des thèses monolithiques et modulaires : état unifié, liquidité et composabilité, avec l'évolutivité illimitée d'un écosystème multi-chaînes.

Agrégation entre ZK et Optimistic Systems

Cette vision n'est fondamentalement accessible qu'aux systèmes basés sur ZK. J'aborderai ce point dans un prochain billet, mais les écosystèmes optimistes qui souhaitent permettre une interopérabilité rapide doivent s'appuyer sur des séquenceurs à validité partagée. C'est une mauvaise affaire pour les chaînes : cela les empêche de redistribuer les frais de séquenceur et le MEV, les séquenceurs à validité partagée obligent les chaînes à accepter des restrictions sur leurs environnements d'exécution, et l'interopérabilité des systèmes basés sur le mode opératoire oblige les chaînes à accepter des hypothèses de confiance supplémentaires en échange d'une faible latence.

De plus, l'interopérabilité entre les chaînes enfreint une propriété importante pour les chambres opérationnelles. Avec les OR à chaîne unique, n'importe qui peut gérer un nœud complet pour un OR et confirmer immédiatement que les transactions sont valides et finalisées dès qu'elles sont publiées sur les L1. Ce n'est plus vrai dans le cas des chaînes multiples. Il est désormais nécessaire de gérer un nœud complet pour chaque chaîne avec laquelle le bloc opératoire interagit.

En revanche, la vision de Polygon est celle où les chaînes sont souveraines. Ils peuvent utiliser n'importe quel environnement d'exécution, s'appuyer sur n'importe quel séquenceur centralisé ou décentralisé et trouver eux-mêmes un compromis entre latence entre chaînes et vivacité.

C'est une vision qui reflète l'Internet existant. Internet est un environnement évolutif, unifié et sans autorisation. De même, l'AgGLayer est évolutif et ne nécessite aucune autorisation. Il n'impose aucune restriction aux chaînes participantes, et permet aux utilisateurs de déplacer des actifs et des états de manière fluide au sein de l'écosystème, grâce à une interface unifiée pour la couche de valeur d'Internet.

C'est l'avenir de Polygon : il n'est ni monolithique, ni totalement modulaire, mais agrégé.

[1] Pour garantir une liquidité unifiée, il faut notamment se débarrasser de la terrible expérience utilisateur des jetons synthétiques encapsulés sur les ponts. Les utilisateurs du pont LxLY de Polygon peuvent transférer facilement des actifs d'une chaîne à l'autre tout en préservant la fongibilité. Cependant, pour le faire en toute sécurité, nous devons nous protéger contre le maillon le plus faible, c'est-à-dire contre un attaquant corrompant une chaîne et drainant tous les fonds de toutes les chaînes du pont. J'expliquerai comment procéder dans un prochain billet, mais l'AgGLayer peut tirer parti de l'étape d'agrégation des preuves pour appliquer la comptabilité au niveau de la chaîne, en évitant la sécurité du maillon faible.

[2] Quand je fais référence à des transactions atomiques entre chaînes, je veux dire la possibilité pour un utilisateur de soumettre un « bundle » ou un ensemble de transactions sur plusieurs chaînes. Le bundle atomique a la propriété d'inclure ses transactions dans chaque chaîne concernée si et seulement si toutes les transactions sont exécutées avec succès. Si une seule transaction échoue, le forfait ne peut être inclus dans aucune chaîne.

L'exemple le plus simple est encore une fois notre transfert inter-chaînes. Supposons qu'Alice veuille envoyer 1 ETH à Bob, mais Alice est sur la chaîne A et Bob sur la chaîne B. En supposant un bridge natif partagé pour les deux cumuls, Alice peut graver son ETH sur la chaîne A et frapper de l'ETH sur la chaîne B, qui est transféré à Bob. Mais il est essentiel de s'assurer qu'elle ne peut pas émettre d'ETH sans les brûler ou vice versa. Elle risque de perdre son ETH ou de sous-garantir le bridge.

C'est pourquoi les transactions atomiques sont si importantes. Afin de permettre des interactions à faible latence entre les chaînes et de faire en sorte que l'utilisation de l'écosystème Polygon ressemble à une chaîne unique, des garanties atomiques sont nécessaires.

[3] C'est un point subtil, mais du point de vue de l'écosystème, l'AgGLayer assure la sécurité, mais du point de vue d'une chaîne unique, ce design donne la priorité à la vivacité plutôt qu'à la sécurité, car la chaîne B peut dépendre d'un état de chaîne non valide provenant de la chaîne A. Dans ce cas, la chaîne B ne sera pas acceptée par l'AgGLayer (appliquée par le circuit d'agrégation de preuves) et devra créer un nouveau bloc sans dépendre de A.

[4] Notre approche dans son ensemble doit beaucoup au design de séquençage à validité partagée d'Umbra Research.

09/02/24 - Mise à jour de ce projet pour clarifier certaines comparaisons entre l'agrégation et le séquençage partagé. La thèse agrégée dépend de mécanismes tels que des séquenceurs partagés, des relais et des constructeurs pour faciliter la coordination entre les chaînes. La couche d'âge garantit à son tour la sécurité.

Avertissement：

1. Cet article est repris de [[Brendan Farmer]. Tous les droits d'auteur appartiennent à l'auteur original [Brendan Farmer]. En cas d'objection à cette réimpression, contactez l'équipe de Gate Learn, elle s'en occupera rapidement.
2. Avertissement en matière de responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent en aucun cas un conseil d'investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.