Où est l’avenir du développement d’Ethereum multi-chaîne, peut-être que Polkadot peut donner une réponse de référence

原文:《Séquenceurs partagés pour les chaînes d’applications Starknet et Madara》

Écrit par Apoorv Sadana

Compilé par: Odaily Planet Daily How to Husband

! [Où est l’avenir du développement d’Ethereum multi-chaîne, peut-être que Polkadot peut donner une réponse de référence] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d5ea1f805b-dd1a6f-69ad2a.webp)

Lorsque de plus en plus de chaînes d’applications L2 s’appuient sur Ethereum comme couche de règlement, l’interopérabilité entre plusieurs chaînes et le degré de décentralisation de chaque chaîne sont particulièrement importants.

Cet article traite du concept d’un donneur de commande partagé, qui permet à différentes chaînes d’applications de partager un ensemble de validateurs pour réaliser la décentralisation, et gère l’ordre et l’exécution des transactions via un moteur de commande et un moteur de cumul.

Cependant, le séquenceur partagé et l’architecture de conception multi-chaînes de Polkadot sont très similaires, la technologie prête à l’emploi de Polkadot peut-elle être introduite dans l’écosystème Ethereum, améliorant ainsi le processus de développement de la multi-chaîne Ethereum.

Ce qui suit est compilé par Odaily Planet Daily.

Qu’arrive-t-il à 100 chaînes d’applications ?

Disons que nous sommes dans un futur où il y a maintenant 100 chaînes d’applications différentes réglées sur Ethereum. Résolvons le problème que cela va soulever.

Fragmentation décentralisée

Chaque chaîne applicative doit résoudre elle-même le problème de la décentralisation. Aujourd’hui, la décentralisation de la chaîne applicative n’est pas aussi nécessaire que la L1, principalement parce que nous nous appuyons sur la L1 pour assurer la sécurité. Cependant, nous avons encore besoin de la décentralisation pour assurer la vitalité, résister à la censure et éviter les avantages monopolistiques (tels que les frais élevés). Cependant, si chaque chaîne d’application résout le problème de décentralisation à sa manière, cela conduira à une fragmentation des ensembles de validateurs. Chaque chaîne d’application doit développer des incitations économiques pour attirer de nouveaux validateurs. De plus, les validateurs doivent choisir les clients qu’ils sont prêts à exécuter. Cela crée une énorme barrière à l’entrée pour les développeurs qui souhaitent lancer leurs propres chaînes d’applications (ce qui n’est qu’une transaction par rapport au déploiement de contrats intelligents).

Composabilité

La composabilité signifie essentiellement une interaction inter-applications. Sur Ethereum ou Starknet, cela signifie simplement appeler un autre contrat intelligent, et tout le reste est géré par le protocole lui-même. Cependant, dans la chaîne d’application, cela devient plus difficile. Les différentes chaînes d’applications ont leurs propres mécanismes de blocage et de consensus. Chaque fois que vous essayez d’interagir avec une autre chaîne d’applications, vous devez examiner attentivement l’algorithme de consensus et les garanties de finalité, et configurer le pontage inter-chaînes en conséquence (directement sur la chaîne ou via L1). Si vous souhaitez interagir avec 10 chaînes d’applications avec des conceptions différentes, vous devez le faire 10 fois.

! [Où est l’avenir du développement d’Ethereum multi-chaîne, peut-être que Polkadot peut donner une réponse de référence] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-18c07cd8cf-dd1a6f-69ad2a.webp)

Expérience de développement

Il n’est pas facile de résoudre le problème de la décentralisation et de la transition. Si chaque chaîne d’applications doit résoudre ces problèmes, il deviendra très difficile pour le développeur moyen de contrats intelligents de créer sa propre chaîne d’applications. De plus, au fur et à mesure que chaque chaîne applicative tentera de résoudre ces problèmes à sa manière, nous verrons bientôt que les différentes chaînes suivent des normes différentes, ce qui rendra plus difficile l’intégration de nouveaux porteurs de projets dans l’écosystème.

Le partage du séquenceur résout ce problème

Si vous suivez l’espace de la chaîne d’applications, vous avez probablement entendu le terme « séquenceur partagé ». Il fait référence à l’idée de partager un ensemble commun de validateurs pour résoudre les problèmes ci-dessus. Cela fonctionne comme suit.

Décentralisation du partage

L’idée de base d’un séquenceur partagé est qu’il n’est pas nécessaire d’avoir un ensemble différent de validateurs pour chaque chaîne d’application ou L2. Mais il est possible d’avoir un ensemble très efficace et décentralisé de validateurs qui trient les blocs pour toutes les chaînes. **

Étant donné que presque tous les trieurs sont aujourd’hui centralisés, le donneur d’ordre est considéré comme une application unique qui collecte les transactions, les trie, les exécute et publie les résultats dans L1. Cependant, ces tâches peuvent être décomposées en plusieurs composants modulaires. Pour les besoins de l’explication, je l’ai divisé en deux parties.

Moteur de tri : Responsable du tri des transactions dans un ordre spécifique. Une fois que le moteur de tri a déterminé cet ordre, il doit être suivi. Ceci est mis en œuvre en soumettant cet ordre sur L1 et en forçant les validateurs L1 à vérifier si les transactions sont exécutées dans l’ordre souhaité.

Moteur de cumul : le moteur de cumul comprend essentiellement tout ce que fait le cumul : collecte des transactions auprès des utilisateurs, exécution des transactions, création de preuves et mise à jour de l’état sur L1. Idéalement, cela pourrait être décomposé en plusieurs composants, mais nous éviterons de le faire dans cet article. Ici, le moteur de tri est le séquenceur partagé, et le moteur de cumul est essentiellement toute la logique de cumul.

Par conséquent, le cycle de vie d’une transaction est le suivant.

! [Où est l’avenir du développement d’Ethereum multi-chaîne, peut-être que Polkadot peut donner une réponse de référence] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-fc5a1b83cf-dd1a6f-69ad2a.webp)

En gros, le donneur d’ordre partagé trie les transactions dans Rollup et les soumet à L1. En décentralisant une collection de donneurs d’ordre partagée, une collection de donneurs d’ordre partagés décentralise tous les cumuls connectés à cette collection de donneurs d’ordres.

Composabilité

L’un des principaux problèmes liés à la composabilité est de comprendre quand une transaction est finalement terminée sur d’autres chaînes d’applications et d’agir en conséquence sur la chaîne. Mais un orderer partagé permet aux cumuls composables de partager des morceaux entre eux. Par conséquent, si une annulation de transaction se produit sur le cumul B, l’ensemble du bloc est annulé, ce qui entraîne également l’annulation de la transaction sur le cumul A.

Maintenant, cela semble certainement plus facile que cela ne l’est en réalité. Pour cela, la communication entre les Rollups doit être efficace et évolutive. Les séquenceurs partagés doivent développer des normes appropriées sur la façon dont les cumuls communiquent, à quoi doivent ressembler les messages inter-chaînes, comment gérer les mises à niveau de cumul, etc. Bien que ces problèmes puissent être résolus, ils ne sont pas faciles à résoudre.

Expérience développeur

Bien que les donneurs d’ordre partagés fassent abstraction de l’aspect décentralisé pour faciliter la messagerie inter-chaînes, il existe encore certaines normes que chaque chaîne doit suivre pour être compatible avec les donneurs d’ordre partagés. Par exemple, toutes les transactions de cumul doivent être converties dans un format commun que le trieur comprend. De même, les blocs du trieur doivent être filtrés pour obtenir les transactions pertinentes. Pour résoudre ce problème, je pense que le séquenceur partagé lancera un framework de cumul ou un SDK qui abstrait le code standard et n’expose que la partie de la logique métier au développeur de la chaîne d’applications. **

Vous trouverez ci-dessous un diagramme schématique de la chaîne d’applications utilisant le séquenceur partagé.

! [Où est l’avenir du développement d’Ethereum multi-chaîne, peut-être que Polkadot peut donner une réponse de référence] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-849b693227-dd1a6f-69ad2a.webp)

La multichaîne Ethereum peut-elle apprendre de l’architecture de conception de Polkadot ?

Polkadot a commencé à travailler sur l’avenir du multi-chain avant Ethereum. En fait, ils y travaillent depuis plus de 5 ans. Si vous êtes familier avec Polkadot, vous avez probablement remarqué que le design ci-dessus réinvente fondamentalement beaucoup de choses que Polkadot a déjà accomplies.

Chaîne de relais (décentralisation partagée)

La chaîne de relais est essentiellement le moteur de commande + L1 dans le diagramme de séquence ci-dessus. Les caractéristiques de la chaîne de relais comprennent:

Séquencez toutes les transactions de cumul pour vérifier que la transaction a été exécutée correctement (elle n’utilise pas la vérification à divulgation nulle de connaissance, mais réexécute le code d’exécution du cumul pour vérifier les différences d’état).

! [Où est l’avenir du développement d’Ethereum multi-chaîne, peut-être que Polkadot peut donner une réponse de référence] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-a5377511f0-dd1a6f-69ad2a.webp)

Comme vous l’avez peut-être constaté, une chaîne de relais est essentiellement un donneur d’ordre partagé dont nous avons parlé ci-dessus. La différence est que la chaîne de relais doit également vérifier l’exécution, et nous laissons cela à Ethereum.

XCM et XCMP

Nous avons mentionné dans la section précédente que si chaque chaîne construit sa propre méthode pour interagir avec les autres, nous verrons bientôt des normes et des formats différents sur toutes les chaînes. Vous devez garder une trace de tous ces formats qui interagissent avec chaque chaîne. De plus, vous devez répondre à des questions telles que ce qui se passe si une chaîne est mise à niveau. Cependant, ces problèmes peuvent être résolus en introduisant des normes que toutes les chaînes doivent suivre.

Comme vous l’avez peut-être deviné, c’est exactement ce qu’a fait Polkadot. XCM est le format de message, XCMP est le protocole de message, et toutes les chaînes enfants peuvent les utiliser pour communiquer entre elles.

Substrat et cumulus

Substrate est un framework développé par Parity pour la construction de blockchains. Alors que toutes les parachains sur Polkadot utilisent Substrate, Substrate est en fait construit de manière indépendante de la chaîne. Le cadre fait abstraction de tous les aspects courants de la blockchain, en se concentrant sur la logique d’application. Comme nous le savons, Madara est construit sur Substrate, tout comme Polkadot, Polygon Avail et de nombreux autres projets. De plus, Cumulus est un middleware au-dessus de Substrate qui connecte votre chaîne à Polkadot.

Ainsi, en poursuivant l’analogie précédente, Substrate et Cumulus peuvent être considérés comme des alternatives au framework Rollup, qui permettent de construire des chaînes d’applications et de les connecter à des séquenceurs partagés.

Séquenceur → chaîne de relais partagés

Composabilité → XCM et XCMP

Rollup Framework/Stack → Substrat et Cumulus

! [Où est l’avenir du développement d’Ethereum multi-chaîne, peut-être que Polkadot peut donner une réponse de référence] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-e786adbea4-dd1a6f-69ad2a.webp)

En plus du fait qu’il s’agit essentiellement d’une copie de Polkadot, Polkadot et Parity ont des équipes expérimentées et bien financées qui continuent d’améliorer Substrate et Polkadot, en ajoutant plus de fonctionnalités et en augmentant l’évolutivité. Cette technologie a été testée sur le terrain pendant de nombreuses années et dispose d’une multitude d’outils de développement.

Régler Polkadot sur Ethereum ?

S’il est vrai que Polkadot a commencé à construire un avenir multi-chaînes avant Ethereum, il est indéniable qu’à ce jour, Ethereum est la blockchain la plus décentralisée et où résident la plupart des applications et des liquidités. Cependant, que se passerait-il s’il existait un moyen d’apporter toute la technologie Polkadot à l’écosystème Ethereum ?

En fait, nous avons déjà commencé à le faire, et Madara en est un exemple. Madara utilise le framework Substrate pour permettre à quiconque de créer sa propre solution L2/L3 basée sur zk sur Ethereum. La prochaine chose dont nous avons besoin est une chaîne de relais Polkadot sous la forme d’un séquenceur partagé. Si nous pouvons réutiliser la chaîne de relais Polkadot, mais supprimer la partie validation, car la vérification se fait par zk proof sur L1 Soumettre l’ordre des transactions à L1 Optimiser les nœuds et les algorithmes de consensus pour prendre en charge Tendermint/HotStuff, nous pouvons obtenir le donneur partagé mentionné précédemment.

Évidemment, c’est plus facile à dire qu’à faire. Cependant, je pense que cette voie est plus pragmatique que de reconstruire le séquenceur, les standards et le framework à partir de zéro. Polkadot a résolu de nombreux problèmes d’une manière indépendante de la chaîne que nous pouvons emprunter pour Ethereum. En tant que produit secondaire, nous obtenons également :

● Une communauté de développeurs active qui continue de construire et d’éduquer le monde pour Substrate.

● Un ensemble d’outils de développement actif et une communauté solide.

De nombreuses parachains actives peuvent également choisir de s’installer sur Ethereum si elles le souhaitent (récemment, nous avons vu Astar faire de même avec Polygon CDK).

En conclusion

Mon objectif principal en écrivant cet article est de susciter une discussion au sein de l’écosystème plus large de Starknet et d’Ethereum. Je pense que le modèle de classement partagé jouera un rôle important dans la décentralisation de Starknet et la décentralisation de toutes les chaînes d’applications envisagées pour s’en inspirer. Tant que nous sommes confiants dans l’argument de la chaîne d’application et l’extensibilité ZK, une analyse approfondie du modèle de commande partagé est inévitable. De plus, Starknet a déjà commencé à travailler sur la décentralisation alors que Madara passe en production, et je pense qu’il est temps de s’y attaquer. Par conséquent, je demande à tous ceux qui lisent ceci de nous faire part de leurs commentaires/suggestions sur ce sujet. Au plaisir de lire vos pensées.

Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
  • Récompense
  • Commentaire
  • Reposter
  • Partager
Commentaire
0/400
Aucun commentaire
  • Épingler
Trader les cryptos partout et à tout moment
qrCode
Scan pour télécharger Gate app
Communauté
Français (Afrique)
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)