Introduction

Aujourd'hui, nous voyons déjà des projets qui commencent à expérimenter Madara pour leurs chaînes d'applications. Pragma, Kakarot, Mangata Finance et Dojo en sont quelques exemples. Tant que nous croirons en l'avenir des chaînes multiples et en la puissance de la mise à l'échelle de zk, nous verrons de nombreux autres projets de ce type à l'avenir. Cependant, le nombre croissant de chaînes d'applications soulève également des questions sur les points suivants

1. Décentralisation
2. Composabilité
3. Expérience en matière de développement

Dans ce billet, j'essaierai d'expliquer les problèmes qui se posent en raison du grand nombre de chaînes d'applications et je proposerai également une solution possible au problème que je considère comme élégante et optimale pour Madara et Starknet. Si vous êtes déjà familiarisé avec les chaînes d'applications et le séquençage partagé, n'hésitez pas à passer à la section "Attendez, c'est juste Polkadot encore une fois".

Que se passe-t-il à 100 chaînes d'applications ?

Supposons que nous nous trouvions dans un avenir où 100 chaînes d'applications différentes s'installent sur Ethereum. Abordons tous les problèmes que cela va engendrer.

Décentralisation fragmentée

Chaque chaîne d'applications devra résoudre le problème de la décentralisation par ses propres moyens. Aujourd'hui, la décentralisation des chaînes d'applications n'est pas aussi nécessaire que celle des L1, principalement parce que nous comptons sur les L1 pour la sécurité. Cependant, nous avons encore besoin de décentralisation pour garantir l'animation, la résistance à la censure et éviter les avantages monopolistiques (redevances élevées, par exemple). Toutefois, il est également important de noter que si chaque chaîne d'applications cherche à résoudre le problème de la décentralisation à sa manière, cela entraînera très rapidement une fragmentation des ensembles de validateurs. Chaque chaîne d'applications devrait mettre en place des incitations économiques pour intégrer de nouveaux validateurs. En outre, les validateurs devraient sélectionner les clients qu'ils sont prêts à utiliser. Sans parler de l'énorme barrière à l'entrée que cela crée pour les développeurs qui veulent lancer leurs propres chaînes d'applications (par rapport au déploiement d'un contrat intelligent qui n'est qu'une transaction).

Composabilité

La composabilité signifie essentiellement l'interaction entre les applications. Sur Ethereum ou Starknet, il suffit d'appeler un autre contrat et tout le reste est géré par le protocole lui-même. Toutefois, avec les chaînes d'applications, cela devient beaucoup plus difficile. Les différentes chaînes d'applications ont leurs propres blocs et mécanismes 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, en conséquence, mettre en place un pont inter-chaînes (directement vers la chaîne ou via la L1). Si vous souhaitez interagir avec 10 chaînes d'applications de conception différente, vous devez le faire 10 fois.

Expérience en matière de développement

Il n'est pas facile de résoudre les problèmes de décentralisation et de passerelle. Si cette exigence s'applique à chaque chaîne d'application, il sera très difficile pour le développeur habituel de contrats intelligents de créer sa propre chaîne d'application. De plus, comme chaque chaîne d'applications tente de résoudre ces problèmes à sa manière, nous verrons bientôt des normes différentes suivies par les différentes chaînes, ce qui rendra encore plus difficile l'adhésion à l'écosystème.

Les séquenceurs partagés peuvent résoudre ce problème

Si vous suivez l'évolution de la chaîne d'applications, vous avez peut-être entendu parler des "séquenceurs partagés". C'est l'idée d'avoir un ensemble commun de validateurs pour toutes les chaînes qui vise à résoudre les problèmes mentionnés ci-dessus. Voici comment cela fonctionne.

Décentralisation partagée

L'essence même des séquenceurs partagés est qu'il n'est pas nécessaire d'avoir un ensemble différent de validateurs pour chaque chaîne d'applications ou L2. Au lieu de cela, vous pouvez disposer d'un ensemble de validateurs vraiment efficaces et décentralisés qui séquencent les blocs pour toutes les chaînes ! Imaginez des blocs contenant des transactions provenant de 100 chaînes d'applications différentes. Vous pensez peut-être que cela va vraiment alourdir le séquenceur car vous devez être capable de gérer des moteurs d'exécution pour chaque chaîne d'applications.

Eh bien, ce n'est pas le cas !

Étant donné qu'aujourd'hui presque tous les séquenceurs sont centralisés, le séquenceur est considéré comme une application unique qui collecte les transactions, les ordonne, les exécute et affiche les résultats sur le site L1. Toutefois, ces emplois peuvent être séparés en plusieurs éléments modulaires. Pour les besoins de cette explication, je les diviserai en deux.

1. Moteur de commande : il est chargé de séquencer les transactions dans un ordre spécifique. Une fois que cet ordre a été décidé par le moteur de commande, il DOIT être respecté. Cette règle est appliquée en engageant cet ordre sur la L1 et en obligeant les vérificateurs de la L1 à vérifier si les transactions ont été exécutées dans l'ordre requis.
2. Moteur du rollup : le moteur du rollup est en fait tout ce que fait le rollup : il collecte les transactions des utilisateurs, les exécute, crée des preuves et met à jour l'état de la L1. Dans l'idéal, il est possible de décomposer cette question en plusieurs éléments, mais nous éviterons de le faire dans le cadre de cet article.

Ici, le moteur de commande est le séquenceur partagé et le moteur de rollup est essentiellement la logique de rollup. Le cycle de vie de la transaction se présente donc comme suit

Les séquenceurs partagés ordonnent essentiellement les transactions sur les rollups et les engagent sur le L1. Par conséquent, en décentralisant le jeu de séquenceurs partagé, vous décentralisez en fait tous les rollups liés à ce jeu de séquenceurs ! Pour avoir une idée plus détaillée du fonctionnement des séquenceurs partagés, vous pouvez également vous référer à cet incroyable <a href="https://hackmd.io/@EspressoSystems/EspressoSequencer"> article 17 d'Espresso.

Composabilité

L'un des principaux problèmes de la composabilité est de comprendre quand la transaction est finalisée sur la chaîne de l'autre application et d'agir en conséquence sur votre chaîne. Mais avec les séquenceurs partagés, les deux rollups composables partagent des blocs entre eux. Ainsi, si une transaction est annulée sur le rollup B, le bloc entier est annulé, ce qui entraîne l'annulation de la transaction sur le rollup A.

Cela semble plus facile à dire qu'à faire. Pour cela, la communication entre les rollups doit être efficace et évolutive. Les séquenceurs partagés doivent définir des normes appropriées sur la manière dont les rollups peuvent communiquer, sur la forme des messages inter-chaînes, sur la manière de traiter les mises à niveau des rollups, etc. Bien que ces problèmes puissent être résolus, ils sont compliqués et ne sont pas faciles à résoudre.

Expérience des développeurs

Si les séquenceurs partagés font abstraction de l'aspect décentralisation et facilitent la messagerie entre les chaînes, il existe encore certaines normes que chaque chaîne doit respecter pour être compatible avec le séquenceur partagé. Par exemple, toutes les transactions de rollup doivent être transformées dans un format général que le séquenceur comprend. De même, les blocs provenant du séquenceur doivent être filtrés pour récupérer les transactions pertinentes. Pour résoudre ce problème, je suppose que les séquenceurs partagés proposeront des frameworks de rollup ou des SDK qui feront abstraction du code de base et n'exposeront que la partie logique de l'entreprise aux développeurs de la chaîne d'applications.

Voici un diagramme de l'aspect des chaînes d'applications avec des séquenceurs partagés

Attendez, c'est encore une fois Polkadot.

Polkadot a commencé à travailler sur l'avenir multi-chaîne bien avant Ethereum. En fait, ils y travaillent depuis plus de 5 ans maintenant et si vous êtes familier avec Polkadot, vous avez peut-être remarqué que le design ci-dessus réinvente en fait beaucoup de choses que Polkadot a déjà faites !

La 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. La chaîne de relais

1. Ordres de transactions sur l'ensemble des parachains (rollups)
2. Il vérifie que les transactions ont été exécutées correctement (au lieu de la vérification zk, il réexécute le code d'exécution du rollup pour vérifier les différences d'état).

Vous avez peut-être réalisé que le relais est essentiellement le séquenceur partagé dont nous avons parlé plus haut. À l'exception du fait que la chaîne de relais doit également vérifier l'exécution (car Polkadot est une L1), alors que nous laissons cette tâche à Ethereum.

XCM et XCMP

Nous avons mentionné dans la section précédente que si chaque chaîne élaborait ses propres méthodes d'interopérabilité avec d'autres chaînes, nous serions bientôt submergés de normes et de formats différents pour toutes les chaînes. Vous devrez tenir compte de tous ces formats pour chaque chaîne avec laquelle vous interagissez. En outre, vous devrez également répondre à des questions telles que : que se passe-t-il en cas de mise à niveau d'une chaîne ? Toutefois, ces problèmes peuvent être résolus de manière élégante en introduisant des normes que toutes les chaînes doivent respecter.

Comme vous l'avez peut-être deviné, Polkadot l'a déjà fait. XCM est le format de messagerie et XCMP est le protocole de messagerie que toutes les chaînes de substrats peuvent utiliser pour communiquer entre elles. Je n'entrerai pas dans les détails, mais vous pouvez en prendre connaissance ici 5.

Substrat et Cumulus

Substrate est un cadre développé par Parity qui peut être utilisé pour construire des blockchains. Alors que tous les parachains sur Polkadot utilisent le substrat, le substrat est en fait construit d'une manière agnostique à la chaîne. Le cadre fait abstraction de tous les aspects communs d'une blockchain afin que vous puissiez vous concentrer sur la logique de votre application. Comme nous le savons, Madara est construit sur Substrate, tout comme Polkadot, Polygon Avail et bien d'autres projets. De plus, Cumulus est un logiciel intermédiaire au-dessus de Substrate qui vous permet de connecter votre chaîne à Polkadot.

En poursuivant notre analogie, Substrate et Cumulus peuvent être considérés comme des substituts aux cadres de rollup qui vous permettent de construire des chaînes d'applications et de les connecter aux séquenceurs partagés.

Séquenceurs partagés → Chaînes de relais
Composabilité → XCM et XCMP
Cadres d'enroulement/piles → Substrate et Cumulus

Alors oui, c'est un peu le Polkadot à nouveau ! Par ailleurs, Polkadot et Parity disposent d'équipes parmi les plus expérimentées et les mieux financées qui continuent à développer Substrate et Polkadot afin d'ajouter de nouvelles fonctionnalités et de les rendre plus évolutives. La technologie est déjà éprouvée depuis des années et dispose d'un grand nombre d'outils de développement.

Régler Polkadot sur Ethereum ?

S'il est vrai que Polkadot a commencé à construire l'avenir multi-chaîne bien avant Ethereum, il est indéniable qu'à ce jour, Ethereum est la blockchain la plus décentralisée et l'endroit où se trouvent la plupart des applications et des liquidités. Et s'il existait un moyen d'intégrer toute la technologie Polkadot dans l'écosystème Ethereum ?

C'est le cas ! En fait, nous avons déjà commencé avec Madara. Madara utilise le cadre Substrate pour permettre à quiconque de construire sa propre solution L2/L3 alimentée par zk au-dessus d'Ethereum. Nous avons ensuite besoin de la chaîne de relais Polkadot sous la forme d'un séquenceur partagé. Ainsi, si nous pouvons réutiliser la chaîne de relais Polkadot mais

1. Supprimez la partie vérification car elle se fait sur le L1 via les preuves zk.
2. Enregistrer l'ordre des transactions dans la base de données L1
3. Optimiser les nœuds et les algorithmes de consensus pour supporter Tendermint/HotStuff

Nous pouvons obtenir des séquenceurs partagés, comme indiqué précédemment. Évidemment, c'est plus facile à dire qu'à faire. Cependant, je pense que cette voie est plus pragmatique que de reconstruire les séquenceurs, les normes et les cadres à partir de zéro. Polkadot a déjà résolu de nombreux problèmes d'une manière agnostique à la chaîne que nous pouvons emprunter pour Ethereum. Comme produit secondaire, nous obtenons

1. Un ensemble actif de développeurs qui continuent à construire et à éduquer le monde à propos de Substrate
2. Un ensemble d'outils de développement actif et une communauté solide
3. De nombreuses parachaines actives peuvent également choisir de régler sur Ethereum si elles le souhaitent (nous avons vu Astar faire la même chose récemment avec le CDK Polygon).

Conclusion

L'idée principale de ce billet est d'ouvrir la discussion au sein de l'écosystème élargi de Starknet et d'Ethereum. Je pense que le modèle de séquençage partagé jouera un rôle important dans la décentralisation non seulement de Starknet, mais aussi de toutes les chaînes d'applications qui envisagent de s'appuyer sur lui. Tant que nous sommes convaincus de la thèse de la chaîne d'application et de la mise à l'échelle de zk, une analyse approfondie du modèle de séquençage partagé est inévitable. De plus, alors que Madara s'achemine vers la production et que Starknet a commencé son travail sur la décentralisation, je pense qu'il est maintenant important d'aborder ce sujet. C'est pourquoi je demande à tous ceux qui lisent ces lignes de me faire part de leurs commentaires et suggestions sur le sujet. J'ai hâte de lire vos réflexions !

Annexe

Polkadot vs Cosmos

Cosmos, à l'instar de Polkadot, se prépare depuis de nombreuses années à un avenir multichaîne. En conséquence, elle a beaucoup développé le SDK Cosmos et l'IBC, et nous voyons également de nombreuses chaînes d'applications s'appuyer sur l'écosystème Cosmos. Il n'est donc que juste de considérer Cosmos également pour cette approche. Mon opinion personnelle sur ce sujet est que Polkadot est plus pertinent car il résout le problème des séquenceurs partagés alors que Cosmos exige que chaque chaîne d'applications construise son propre ensemble de validateurs. En outre, Substrate a toujours été conçu de manière agnostique pour permettre aux développeurs de créer des blockchains sans présumer des algorithmes de consensus ou de l'écosystème Polkadot. C'est également la raison pour laquelle nous avons choisi Substrate pour Madara. Cela dit, mon expérience de Cosmos est limitée et j'aimerais que les plus expérimentés m'en disent plus à ce sujet ! Pour en savoir plus sur la comparaison des deux réseaux , cliquez ici.

Clause de non-responsabilité：

1. Cet article est repris de[starknet]. Tous les droits d'auteur appartiennent à l'auteur original[apoorvsadana]. Si vous avez des objections à cette réimpression, veuillez contacter l'équipe de Gate Learn, qui s'en chargera rapidement.
2. Clause de non-responsabilité : Les points de vue et les opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en 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, distribuer ou plagier les articles traduits.