Récemment, Optimism, dirigé par ETH Layer 2, et zkSync, Polygon, Arbitrum et StarkNet ont tous lancé leurs propres solutions Stack, toutes visant à construire un ensemble de codes modulaires open source permettant aux développeurs de personnaliser leur propre couche 2.
Comme nous le savons tous, l'Ethereum actuel est connu pour ses faibles performances et son niveau élevé de gaz. L'émergence de couches 2 telles que OP et zkSync Era a résolu ces problèmes. Cependant, qu'il soit déployé sur une machine virtuelle EVM ou sur la couche 2, il existe essentiellement un problème de « compatibilité ». Ce n'est pas seulement le code sous-jacent du Dapp qui doit être compatible avec l'EVM, mais aussi la souveraineté du Dapp.
La première partie est le niveau du code. Comme EVM doit prendre en charge différents types d'applications déployées dessus, il a été optimisé sur le cas d'utilisateur moyen pour prendre en compte tous les types d'utilisateurs. Mais il n'est pas aussi convivial pour les Dapps déployés dessus. Par exemple, les applications Gamefi accorderont plus d'attention à la vitesse et aux performances ; les utilisateurs de Socialfi peuvent accorder plus d'attention à la confidentialité et à la sécurité. Cependant, en raison de la nature unique de l'EVM, Dapp doit renoncer à quelque chose, à savoir la compatibilité au niveau du code.
La deuxième partie est le niveau de souveraineté. Puisque tous les Dapps partagent l'infrastructure, deux concepts ont émergé : la gouvernance des applications et la gouvernance sous-jacente. La gouvernance des applications est sans aucun doute soumise à la gouvernance sous-jacente. Les besoins spécifiques de certains Dapps nécessitent une mise à niveau via l'EVM sous-jacent. donc Dapp manque de souveraineté. Par exemple, les nouvelles fonctionnalités d'Uniswap V4 nécessitent que l'EVM sous-jacent prenne en charge le stockage transitoire et s'appuient sur l'EIP-1153 pour être ajouté à la mise à niveau de Cancun.
Afin de résoudre les problèmes mentionnés ci-dessus concernant les faibles performances de traitement et les problèmes de souveraineté d'Ethereum L1, Cosmos (2019) et Polkadot (2020) ont vu le jour. Tous deux espèrent aider à développer et à construire leurs propres chaînes personnalisées, permettant aux Dapps blockchain de maîtriser l'autonomie souveraine, d'atteindre une interopérabilité inter-chaînes haute performance et de réaliser un réseau d'interopérabilité de chaîne complète.
Aujourd'hui, 4 ans plus tard, les L2 ont également lancé leurs propres solutions de réseaux hyperliens, d'OP Stack, à ZK Stack, en passant par Polygon 2.0, Arbitrum Orbit et enfin StarkNet, pour ne pas être en reste, a lancé le concept Stack.
Quels types de collisions et d'étincelles se produiront entre le pionnier du réseau complet CP (Cosmos Polkadot) et les L2 ? Afin de vous fournir une perspective complète et approfondie, nous explorerons ce sujet en profondeur à travers une série de trois articles. **Cet article, en tant que premier chapitre de cette série, triera les solutions techniques de chaque entreprise. Le deuxième chapitre triera le modèle économique et l'écologie de chaque solution, et résumera les différences entre la couche 1 et la couche 1. 2 Stack sélectionne les caractéristiques à prendre en compte. Dans le dernier chapitre, nous discutons de la façon dont la couche 2 développe sa propre super chaîne et résumons toute la série d'articles. **
1. Cosmos
Cosmos est un réseau décentralisé de blockchains parallèles indépendantes. En fournissant un SDK de cadre de développement commun, les développeurs peuvent facilement créer leurs propres blockchains, et plusieurs blockchains indépendantes et différentes spécifiques à des applications peuvent interagir les unes avec les autres. Les liens communiquent entre eux, formant un réseau interopérable. et un réseau complet évolutif.
1. Cadre structurel
Comme mentionné précédemment, lorsqu'il existe des chaînes d'applications à grande échelle dans l'écosystème et que chaque chaîne utilise le protocole IBC pour communiquer et transmettre des jetons, l'ensemble du réseau sera aussi encombrant et difficile à trier qu'une toile d'araignée.
Ainsi, afin de résoudre ce problème, Cosmos a proposé une architecture en couches, qui contient deux types de blockchains : Hubs (chaîne de hub centrale) et Zones (chaîne régionale).
**Les zones sont des chaînes d'applications conventionnelles et les hubs sont des blockchains spécialement conçues pour connecter les zones entre elles, servant principalement à la communication entre les zones. **Lorsqu'une zone crée une connexion IBC avec le Hub, le Hub peut accéder automatiquement (c'est-à-dire envoyer et recevoir) toutes les zones qui lui sont connectées. Cette structure réduit considérablement la complexité de la communication.
De plus, il convient de noter que Cosmos et Cosmos Hub sont deux choses complètement différentes. Cosmos Hub n'est qu'une des chaînes existant dans l'écosystème Cosmos et servant principalement d'émetteur et de centre de communication de $ATOM. **Vous pouvez comprendre Hub comme le centre de l'écosystème, mais en fait, n'importe quelle chaîne peut devenir un Hub. Si le Hub devient le centre de l’écosystème, cela est en réalité contraire à l’intention initiale du Cosmos. **Parce que Cosmos est essentiellement attaché à l'autonomie de chaque chaîne et dispose d'une souveraineté absolue. Si le Hub est utilisé comme centre de pouvoir, alors la souveraineté ne s'appelle plus souveraineté. Ainsi, lorsque vous comprenez Hub, vous devez accorder une attention particulière à ce point.
2. Technologies clés
2.1 GRV
IBC (Inter-Blockchain Communication), qui est une communication inter-chaînes, permet à des chaînes hétérogènes de se transférer des jetons et des données entre elles. Dans l'écosystème Cosmos, le cadre sous-jacent du SDK est le même et le moteur de consensus Tendermint doit être utilisé. Cependant, l'hétérogénéité existe toujours, car les chaînes peuvent avoir des fonctionnalités, des cas d'utilisation et des détails de mise en œuvre différents au sein du cadre.
Alors comment assurer la communication entre des chaînes hétérogènes ?
Cela nécessite seulement une finalité au niveau du consensus. La finalité instantanée signifie que tant que plus d'un tiers des validateurs sont corrects, le bloc ne sera pas bifurqué, garantissant que la transaction est définitive une fois le bloc produit. Indépendamment des différences dans les cas d'application et du consensus entre les chaînes hétérogènes, tant que leurs niveaux de consensus sont garantis comme définitifs, l'interopérabilité entre les chaînes sera déterminée par des règles unifiées.
Ce qui suit est un processus de base de communication entre chaînes. Supposons que vous souhaitiez transférer 10 $ATOM de la chaîne A à la chaîne B :
Traçage : chaque chaîne exécute un nœud léger d'autres chaînes, afin que chaque chaîne puisse vérifier les autres chaînes.
Bonding : verrouillez d'abord 10 $ATOM sur la chaîne A afin que les utilisateurs ne puissent pas les utiliser, et envoyez un certificat de verrouillage
Preuve de verrouillage (relais) : il y a un relais entre les chaînes AB pour envoyer une preuve de verrouillage
Validation : Vérifiez les blocs de la chaîne A sur la chaîne B. S'ils sont corrects, 10 $ATOM seront créés sur la chaîne B.
Pour le moment, le $ATOM sur la chaîne B n'est pas le vrai $ATOM, mais juste un certificat. Le $ATOM verrouillé sur la chaîne A ne peut pas être utilisé, mais celui sur la chaîne B peut être utilisé normalement. Lorsque l'utilisateur consomme les informations d'identification sur B, le $ATOM verrouillé sur la chaîne A sera également détruit.
Cependant, le plus grand défi auquel est confrontée la communication entre chaînes n'est pas de savoir comment représenter les données d'une chaîne sur une autre chaîne, mais comment gérer des situations telles que les fourches de chaîne et les réorganisations de chaîne.
Parce que chaque chaîne dans Cosmos est une chaîne individuelle indépendante et autonome avec son propre vérificateur dédié. Par conséquent, il est très probable qu'il y ait des partitions qui font le mal.Par exemple, si la chaîne A transmet des messages à la chaîne B, vous devez alors vérifier les validateurs de la chaîne B à l'avance avant de décider de faire confiance à la chaîne.
Par exemple, supposons que le petit point rouge sur l'image représente un jeton ETM et que les utilisateurs des trois partitions d'ABC souhaitent tous utiliser EVMOS pour exécuter des Dapps dans les partitions, car les transferts d'actifs sont effectués via une communication inter-chaînes. ETM.
Si la partition Ethermint lance une attaque à double dépense à ce moment-là, la partition ABC sera sans aucun doute affectée, mais elle ne se limitera qu'à cela. Les autres réseaux non liés à ETM ne subiront aucune attaque, ce qui est également garanti par Cosmos : même si une telle transmission d'informations malveillantes se produit, elle n'affectera toujours pas l'ensemble du réseau.
2.2 BFT à la menthe tendre
Cosmos utilise Tendermint BFT comme algorithme de consensus sous-jacent et moteur de consensus de Cosmos. Il combine et regroupe l'infrastructure sous-jacente et la couche de consensus de la blockchain dans une solution de moteur universelle et utilise la technologie ABCI pour prendre en charge l'encapsulation de tout langage de programmation. la couche de consensus et le réseau sous-jacents. ** Les développeurs sont donc libres de choisir la langue de leur choix.
2.3 SDK Cosmos
Cosmos SDK est un framework modulaire lancé par Cosmos qui simplifie l'opération de création de Dapps sur la couche consensus. Les développeurs peuvent facilement créer des applications/chaînes spécifiques sans avoir à réécrire le code de chaque module, ce qui réduit considérablement la pression du développement et permet désormais aux développeurs de porter les applications déployées sur l'EVM vers Cosmos.
Source:
De plus, les blockchains construites à l'aide de Tendermint et Cosmos SDK créent également de nouveaux écosystèmes et de nouvelles technologies qui mènent le développement de l'industrie, comme Nym, la chaîne de confidentialité, Celestia, qui assure la disponibilité des données, etc. C'est précisément grâce à la flexibilité et à la facilité d'utilisation offertes par Cosmos que les développeurs peuvent se concentrer sur l'innovation des projets sans avoir à envisager la duplication du travail.
2.4 Compte de sécurité interchaîne
1) Sécurité inter-chaînes
Parce que Cosmos est différent de l'écosystème Ethereum, il comporte L1 et L2. Chaque chaîne d'applications de l'écosystème Cosmos est égale l'une à l'autre et il n'y a pas de relation progressive ou supérieure-inférieure. Cependant, pour cette raison, la sécurité inter-chaînes n’est pas aussi complète qu’Ethereum. Dans Ethereum, le caractère définitif de toutes les transactions est confirmé par Ethereum, héritant du titre sous-jacent. Mais pour une blockchain unique qui construit sa propre sécurité, comment la sécurité doit-elle être maintenue ?
Cosmos a lancé Interchain Security, qui permet essentiellement une sécurité partagée en partageant un grand nombre de nœuds existants. Par exemple, la chaîne monolithique peut partager un ensemble de nœuds de vérification avec le Cosmos Hub pour générer de nouveaux blocs pour la chaîne monolithique. Étant donné que les nœuds desservent à la fois le Cosmos Hub et la chaîne unique, ils peuvent recevoir des frais et des récompenses des deux chaînes.
Source :/tokenomics-dao/token-use-cases-part-1-atom-of-true-staking-token-5 fd 21 j 41161 e
Comme le montre la figure, les transactions initialement générées au sein de la chaîne X sont générées par les nœuds de X pour vérification. Si vous partagez un nœud avec Cosmos Hub ($ATOM), les transactions initialement générées sur la chaîne X seront vérifiées et calculées par les nœuds de la chaîne Hub pour générer de nouveaux blocs pour X.
Logiquement, choisir une chaîne relativement mature avec un grand nombre de nœuds, comme la chaîne Hub, est le premier choix pour une sécurité partagée. Parce que s’ils veulent attaquer une telle chaîne, les attaquants doivent disposer d’une grande quantité de jetons $ATOM comme gage, ce qui augmente la difficulté de l’attaque.
De plus, le mécanisme de sécurité inter-chaînes réduit également considérablement les obstacles à la création de nouvelles chaînes. D'une manière générale, si une nouvelle chaîne ne dispose pas de ressources particulièrement excellentes, elle devra peut-être passer beaucoup de temps à attirer des validateurs et à cultiver l'écosystème. Mais dans Cosmos, comme les validateurs peuvent être partagés avec la chaîne Hub, cela réduit considérablement la pression sur la nouvelle chaîne et accélère le processus de développement.
2) Compte interchaîne
Dans l’écosystème Cosmos, chaque chaîne d’applications étant régie par elle-même, les applications ne peuvent pas accéder les unes aux autres. Par conséquent, Cosmos fournit un compte inter-chaînes qui permet aux utilisateurs d'accéder directement à toutes les chaînes Cosmos prenant en charge IBC à partir du Cosmos Hub, afin que les utilisateurs puissent accéder aux applications de la chaîne B dans la chaîne A pour obtenir une interaction avec la chaîne complète.
2.À pois
Comme Cosmos, Polkadot s'engage à construire une infrastructure qui permet aux développeurs de déployer librement de nouvelles chaînes et de parvenir à l'interopérabilité entre les chaînes.
1. Cadre structurel
1.1 Chaîne de relais :
La chaîne de relais peut également être appelée chaîne principale, qui peut être comprise comme le soleil dans le système solaire. En tant que partie centrale de l'ensemble du réseau, toutes les chaînes secondaires tournent autour d'elle. Comme le montre la figure, une chaîne de relais (Relay Chain) est liée à de nombreuses chaînes avec différentes fonctions, telles que la chaîne de transactions, la chaîne de stockage de fichiers, la chaîne de l'Internet des objets, etc.
Source :/polkadot-network/polkadot-the-foundation-of-a-new-internet-e 8800 ec 81 c 7
Il s'agit de la solution d'expansion hiérarchique de Polkadot. Une chaîne de relais est connectée à une autre chaîne de relais pour obtenir une évolutivité illimitée. (Remarque : fin juin de cette année, le fondateur de Polkadot, Gavin, a proposé Polkadot 2.0, ce qui pourrait changer une nouvelle perspective sur la compréhension de Polkadot.)
1.2 Parachaîne :
La chaîne de relais dispose de plusieurs emplacements Para-Chain, et la parachain est connectée à la chaîne de relais via ces emplacements, comme le montre la figure :
Source : om/cn/learn/slot-auction-cn
Cependant, afin d'obtenir un créneau, les parachains participants doivent miser leur $DOT. Une fois un emplacement obtenu, la parachain peut interagir avec le réseau principal Polkadot via cet emplacement et partager la sécurité. Il convient de mentionner que le nombre de slots est limité et augmentera progressivement.Il est initialement prévu de prendre en charge 100 slots, et les slots seront périodiquement remaniés et attribués selon le mécanisme de gouvernance pour maintenir l'activité de l'écologie parachain.
Les parachains qui obtiennent des emplacements peuvent bénéficier de la sécurité partagée et de la liquidité inter-chaînes de l'écosystème Polkadot. Dans le même temps, la chaîne parallèle doit également fournir en retour certains avantages et contributions au réseau principal de Polkadot, par exemple en prenant en charge la majeure partie du traitement des transactions du réseau.
1.3 Fils parallèles :
Les parathreads sont un autre mécanisme de traitement similaire aux parachains. La différence est que les parachains ont des emplacements un par un et ont des emplacements dédiés qui peuvent fonctionner en continu sans interruption. Mais les threads parallèles font référence au partage d'un emplacement entre des threads parallèles et à l'utilisation à tour de rôle de cet emplacement pour s'exécuter. **
Lorsqu'un thread parallèle obtient le droit d'utiliser le slot, il peut temporairement fonctionner comme une parachain, traitant des transactions, générant des blocs, etc. Mais une fois cette période écoulée, le slot doit être libéré pour être utilisé par d'autres threads parallèles.
Par conséquent, les threads parallèles n'ont pas besoin d'hypothéquer les actifs pendant une longue période, ils n'ont besoin que de payer certains frais lors de l'acquisition de chaque période, on peut donc dire qu'il s'agit d'une méthode de paiement à l'utilisation pour utiliser le créneau. Bien sûr, si un parathread reçoit suffisamment de soutien et de votes, il peut être mis à niveau vers une parachain et obtenir un emplacement fixe.
Par rapport aux parachains, les threads parallèles ont des coûts inférieurs et abaissent le seuil d'entrée pour Polkadot. Cependant, il n'y a aucune garantie quand vous pourrez obtenir le droit d'utiliser le slot, qui n'est pas stable. Par conséquent, lesquelles sont les plus adaptées à une utilisation temporaire ou au test de nouvelles chaînes ? Les chaînes qui espèrent fonctionner de manière stable doivent encore être mises à niveau vers des parachaines.
1.4 Pont adaptateur :
La communication entre les parachains ne peut être réalisée que via XCMP (qui sera présenté plus tard), et elles partagent la sécurité et le même consensus. Et s’il s’agissait d’une chaîne hétérogène ?
Une chose à noter ici est que bien que le cadre fourni par Substrate rende toutes les chaînes connectées à l'écosystème Polkadot isomorphes, avec le développement de l'écosystème, il y aura inévitablement des chaînes publiques matures avec de grands systèmes qui voudront participer. ... dans l'écologie. Si vous leur demandez de se redéployer en utilisant uniquement le substrat, c'est fondamentalement impossible. Alors comment mettre en œuvre la transmission de messages entre chaînes hétérogènes ?
**Prenons un exemple concret. Si vous souhaitez transférer des fichiers d'un téléphone Apple vers un téléphone Android via une connexion, les prises sont différentes, vous avez donc besoin d'un convertisseur pour vous connecter. C'est le rôle réel du pont de transfert. **C'est une parachain qui est un intermédiaire entre la chaîne relais et la chaîne hétérogène (chaîne externe). Des contrats intelligents sont déployés sur la chaîne parallèle et la chaîne hétérogène, permettant à la chaîne relais d'interagir avec la chaîne externe et de réaliser des cross- Fonction de chaîne.
2. Technologies clés
2.1 BÉBÉGrand-père
BABE (Blind Assignment for Blockchain Extension) est le mécanisme de génération de blocs de Polkadot. En termes simples, il sélectionne au hasard les validateurs pour produire de nouveaux blocs, et chaque validateur est attribué à un créneau horaire différent. Au sein de ce créneau horaire, seuls les validateurs affectés à ce créneau peuvent produire des blocs.
Instructions additionnelles:
Le créneau horaire est une méthode utilisée pour diviser les séries temporelles dans le mécanisme de génération de blocs de la blockchain. La blockchain sera divisée en créneaux horaires qui apparaissent à intervalles fixes. Chaque créneau horaire représente un temps de bloc fixe.
Dans chaque intervalle de créneau horaire, seuls les nœuds affectés à ce créneau horaire peuvent produire des blocs.
**En d'autres termes, il s'agit d'une période exclusive. Dans la période 1, le validateur 1 affecté à cette période 1 est chargé de produire les blocs. Chaque validateur a une période de temps et ne peut pas produire de blocs à plusieurs reprises. **
L’avantage est que l’attribution aléatoire maximise l’équité car chacun a la chance d’être attribué. Et comme la plage horaire est connue, chacun peut se préparer à l’avance et il n’y aura pas de génération de bloc inattendue.
Grâce à cette méthode de génération de blocs alloués aléatoirement, le fonctionnement ordonné et équitable de l'écosystème Polkadot est assuré. Alors comment s'assurer que tous les blocs adoptent le même consensus ? Ensuite, nous présenterons un autre mécanisme de Polkadot : Grand-père
Grandpa est un mécanisme de finalisation des blocs, qui peut résoudre le problème de fork qui peut survenir en raison de différents consensus lorsque BABE produit des blocs. Par exemple, les nœuds BABE 1 et 2 ont produit des blocs différents en même temps, ce qui a abouti à un fork. À ce moment-là, grand-père entrera en jeu. Il demandera à tous les validateurs : selon vous, quelle chaîne est la meilleure ?
Les validateurs examineront les deux chaînes et voteront pour celle qu'ils jugent la meilleure. La chaîne avec le plus de votes sera finalement confirmée par Papy et deviendra la chaîne finale. La chaîne rejetée sera abandonnée.
Par conséquent, grand-père est comme le « grand-père » de tous les validateurs, jouant le rôle de décideur final, éliminant ainsi le risque de forks que BABE peut apporter. Il permet à Blockchain de finaliser une chaîne sur laquelle tout le monde s’accorde.
Pour résumer, BABE est responsable de la production aléatoire des blocs, et Grand-père est responsable de la sélection de la chaîne finale. Les deux travaillent ensemble pour permettre à l'écosystème Polkadot de fonctionner en toute sécurité.
2.2 Substrat
Substrate est un framework de développement écrit dans le langage Rust, avec des composants extensibles sous-jacents fournis par FRAME, permettant à Substrate de prendre en charge une variété de cas d'utilisation différents. Toute blockchain construite à l'aide de Substrate est non seulement nativement compatible avec Polkadot, mais peut partager la sécurité et fonctionner simultanément avec d'autres chaînes parallèles. Elle aide également les développeurs à créer leurs propres mécanismes de consensus exclusifs, modèles de gouvernance, etc., et change constamment en fonction des besoins. de développeurs.
De plus, Substrate offre une grande commodité lors de la mise à niveau automatique, car il s'agit d'un module indépendant au moment de l'exécution et peut être séparé des autres composants. Par conséquent, ce module en cours d'exécution peut être directement remplacé lors de la mise à jour des fonctions. En tant que parachain partageant le consensus, tant que le réseau et le consensus sont synchronisés avec la chaîne de relais, la logique de fonctionnement peut être directement mise à jour sans avoir besoin d'un hard fork.
2,3 XCM
Si vous pouviez expliquer XCM en une phrase, ce serait : **Un format de communication inter-chaînes qui permet à différentes blockchains d'interagir. **
Par exemple, Polkadot possède de nombreuses parachaines. Si la parachain A veut communiquer avec la parachain B, elle doit regrouper les informations au format XCM. **XCM est comme un protocole linguistique. Si tout le monde utilise ce protocole pour communiquer, il peut communiquer sans barrières. **
Le format XCM (Cross-Consensus Message Format) est le format de message standard utilisé pour la communication inter-chaînes dans l'écosystème Polkadot, et trois méthodes différentes de livraison de messages en dérivent :
XCMP (Cross-chain Messaging) : En cours de développement. Les messages peuvent être transmis directement ou transmis via une chaîne de relais, la transmission directe étant plus rapide et la transmission via une chaîne de relais étant plus évolutive mais augmentant la latence.
HRMP/XCMP-lite (messagerie de routage de relais horizontal) : en cours d'utilisation. Il s'agit d'une alternative simplifiée à XCMP. Tous les messages sont stockés sur la chaîne de relais et effectue actuellement le principal travail de messagerie inter-chaîne.
VMP (Vertical Messaging) : En cours de développement. Il s'agit d'un protocole de transmission verticale de messages entre chaînes relais et chaînes parallèles. Les messages sont stockés sur la chaîne relais et analysés par la chaîne relais avant d'être transmis.
Par exemple, puisque le format XCM contient diverses informations, telles que le montant des actifs à transférer, le compte destinataire, etc. Lors de l'envoi d'un message, le canal HRMP ou la chaîne de relais délivrera ce message au format XCM. Une fois que l'autre chaîne parallèle aura reçu le message, elle vérifiera si le format est correct, puis analysera le contenu du message, puis exécutera selon les instructions du message, comme le transfert d'actifs vers un compte désigné. l'interaction de la chaîne est réalisée et les deux chaînes réussissent.
Les ponts de communication comme XCM sont très importants pour les écosystèmes multi-chaînes comme Polkadot.
Après avoir compris Cosmos et Polkadot, je crois avoir compris leur vision et leur cadre. Nous expliquerons donc ensuite en détail quelles sont les solutions Stack lancées par ETH L2 ?
三. Pile OP
1. Cadre structurel
Selon la documentation officielle, OP Stack est composé d'une série de composants et est maintenu par OP Collective. Il apparaît d'abord sous la forme d'un logiciel derrière le réseau principal, et apparaît enfin sous la forme de la super chaîne Optimism et de sa gouvernance. L2 développé à l'aide d'OP Stack peut partager la sécurité, les couches de communication et la pile de développement commune. Et les développeurs sont libres de personnaliser la chaîne pour répondre à tout cas d’utilisation spécifique de la blockchain.
À partir de la figure, nous pouvons comprendre que toutes les hyperchaînes d'OP Stack communiqueront via le super pont de chaîne OP Bridge et utiliseront Ethereum comme consensus de sécurité sous-jacent pour construire une super chaîne L2 et diviser la structure interne de chaque hyperchaîne.
**1) Couche de disponibilité des données : **Les chaînes utilisant OP Stack peuvent utiliser ce module de disponibilité des données pour obtenir leurs données d'entrée. Étant donné que toutes les chaînes reçoivent des données de cette couche, cette couche a un impact significatif sur la sécurité. Si certaines données ne peuvent pas être récupérées, il se peut qu'il n'y ait aucun moyen de synchroniser la chaîne.
Comme vous pouvez le voir sur cette figure, OP Stack utilise Ethereum et EIP-4844. En d’autres termes, il utilise essentiellement la blockchain Ethereum pour accéder aux données.
**2) Couche de séquençage : **Le séquenceur détermine comment collecter les transactions des utilisateurs et les publier sur la couche de disponibilité des données, qui est traitée à l'aide d'un seul séquenceur dédié dans la pile OP. Cependant, cela peut empêcher le trieur de conserver les transactions trop longtemps. À l'avenir, OP Stack modularisera le trieur afin que la chaîne puisse facilement modifier le mécanisme de tri.
Sur la figure, vous pouvez voir un séquenceur unique et un multi-séquenceur. Le séquenceur unique permet à n'importe qui d'agir comme séquenceur à tout moment (risque plus élevé). Le multi-séquenceur est tiré d'un ensemble prédéfini de participants possibles. Choisissez. Ensuite, si vous choisissez plusieurs séquenceurs, chaque chaîne développée sur la base d'OP Stack peut être explicitement sélectionnée.
3) Couche de dérivation : Cette couche détermine comment traiter l'entrée traitée des données brutes pour la disponibilité des données et la transmet à la couche d'exécution via l'API d'Ethereum. Comme le montre l'image, OP Stack est composé de Rollup et d'Indexer.
**4) Couche d'exécution : **Cette couche définit la structure d'état au sein du système OP Stack. Lorsque l'API du moteur reçoit les entrées de la dérivation, la transition d'état sera déclenchée. On peut voir sur la figure que sous OP Stack, la couche d'exécution est EVM. Cependant, avec une version légèrement modifiée, il peut également prendre en charge d'autres types de VM. Par exemple, Pontem Network prévoit d'utiliser OP Stack pour développer une Move VM L2.
**5) Couche de règlement : **Comme son nom l'indique, elle est utilisée pour gérer le retrait d'actifs de la blockchain, mais un tel retrait nécessite de prouver le statut de la chaîne cible à une chaîne tierce, puis de traiter le actifs selon leur statut. L'essentiel est de permettre à la chaîne tierce de comprendre l'état de la chaîne cible.
Une fois qu'une transaction est publiée et finalisée sur la couche de disponibilité des données correspondante, la transaction est également finalisée sur la chaîne OP Stack. Il ne peut plus être modifié ou supprimé sans détruire la couche de disponibilité des données sous-jacente. Il se peut que la transaction n'ait pas encore été acceptée par la couche de règlement, car la couche de règlement doit être en mesure de vérifier le résultat de la transaction, mais la transaction elle-même est déjà immuable.
Il s'agit également d'un mécanisme pour les chaînes hétérogènes. Les chaînes hétérogènes ont des mécanismes de règlement différents. Par conséquent, dans OP Stack, la couche de règlement est en lecture seule, permettant aux chaînes hétérogènes de prendre des décisions en fonction de l'état de OP Stack.
À cette couche, nous voyons qu'OP Stack utilise la preuve de panne dans OP Rollup. Les proposants peuvent proposer un statut valide qu'ils contestent, et s'il n'est pas prouvé qu'il est erroné dans un délai donné, il sera automatiquement considéré comme correct.
**6) Couche de gouvernance : **Comme vous pouvez le voir sur l'image, les jetons multi-signature + $OP sont utilisés pour la gouvernance dans la pile OP. Habituellement, la multi-signature est utilisée pour gérer la mise à niveau des composants du système Stack. Les opérations seront effectuées lorsque tous les participants participeront à la signature. Les détenteurs de jetons $OP peuvent voter sur le DAO communautaire pour participer à la gouvernance.
**OP Stack est comme une combinaison de Cosmos et Polkadot. Il peut personnaliser librement des chaînes exclusives comme Cosmos et peut également partager la sécurité et le consensus comme Polkadot. **
2. Technologies clés
2.1 Cumul OP
OP Rollup garantit la sécurité malgré les problèmes de disponibilité des données et permet l'exécution parallèle de transactions. Voici les étapes de mise en œuvre spécifiques :
L'utilisateur initie une transaction sur L2
Le séquenceur regroupera et traitera par lots, puis synchronisera les données de transaction traitées et la nouvelle racine d'état avec le contrat intelligent déployé sur L1 pour la vérification de sécurité. Il convient de noter que lorsque Sequencer traite une transaction, il génère également sa propre racine d'état et la synchronise avec L1.
Après vérification, L1 renvoie les données et la racine du statut à L2, et le statut de la transaction de l'utilisateur est vérifié et traité en toute sécurité.
À l'heure actuelle, OP Rollup considère la racine d'état générée par Sequencer comme optimiste et correcte. Et une fenêtre de temps sera ouverte pour que le vérificateur puisse contester et vérifier si la racine d'état générée par le séquenceur correspond à la racine d'état de la transaction.
S'il n'y a pas de validateur à vérifier pendant la fenêtre horaire, la transaction sera automatiquement considérée comme correcte. Si une fraude malveillante est vérifiée, le Séquenceur qui traite la transaction sera sanctionné en conséquence.
2.2 Pontage entre chaînes
a) Identique à la messagerie L2
Étant donné que OP Rollup utilise la preuve des erreurs, la transaction doit attendre que le défi soit terminé. Ce processus prend beaucoup de temps et l'expérience utilisateur est faible. Cependant, le ZKP (preuve à connaissance nulle) est coûteux et sujet aux erreurs, et la mise en œuvre du ZKP par lots prendra un certain temps.
**Par conséquent, afin de résoudre le problème de communication entre les hyperchaînes OP L2, OP Stack a proposé une preuve modulaire : en utilisant deux systèmes de preuve pour la même chaîne, les développeurs construisant des piles L2 peuvent choisir librement n'importe quel type de pont. **
Actuellement, le PO fournit :
Haute sécurité, retard élevé et prévention des pannes (pont standard de haute sécurité)
Faible sécurité, protection contre les erreurs à faible latence (courte période de test pour obtenir une faible latence)
Preuve de validité à faible sécurité et à faible latence (utilisez un prouveur de chaîne de confiance au lieu de ZKP)
Preuve de validité haute sécurité et faible latence (lorsque ZKP est prêt)
Les développeurs peuvent choisir l'orientation du pontage en fonction des besoins de leurs propres chaînes. Par exemple, pour les actifs de grande valeur, ils peuvent choisir un pontage de haute sécurité... Des technologies de pontage diversifiées permettent un mouvement efficace des actifs et des données entre différentes chaînes.
b) Transactions inter-chaînes
Les transactions inter-chaînes traditionnelles sont effectuées de manière asynchrone, ce qui signifie que la transaction peut ne pas être entièrement exécutée.
OP Stack a proposé l'idée d'un trieur partagé pour ce type de problème. Par exemple, si un utilisateur souhaite effectuer un arbitrage entre chaînes, alors en partageant le séquenceur sur la chaîne A et la chaîne B, il peut parvenir à un consensus sur le moment de la transaction. Les frais ne seront payés qu'après le téléchargement des transactions sur le chaîne, et les séquenceurs des deux côtés partagent le risque.
c)Transaction par lien hypertexte
Étant donné que la disponibilité des données d'Ethereum L1 n'est pas suffisamment évolutive (la capacité est limitée), il n'est pas évolutif pour publier des transactions sur la super chaîne.
Par conséquent, dans OP Stack, il est proposé d'utiliser le protocole Plasma pour augmenter la quantité de données auxquelles la chaîne OP peut accéder, ce qui peut remplacer DA (disponibilité des données) pour compléter davantage de données L1. La disponibilité des données de transaction est transférée sur la chaîne Plasma et les engagements de données ne sont enregistrés que sur L1, ce qui améliore considérablement l'évolutivité.
4. Pile ZK
1. Cadre structurel
ZK Stack est un ensemble de codes modulaires open source, composables, construits sur la même technologie sous-jacente (ZK Rollup) que zkSync Era, permettant aux développeurs de personnaliser leurs propres hyperliens L2 et L3 pilotés par ZK.
Puisque ZK Stack est gratuit et open source, les développeurs sont libres de personnaliser les hyperliens en fonction de leurs besoins spécifiques. Que vous choisissiez un réseau de couche 2 fonctionnant en parallèle avec zkSync Era, ou un réseau de couche 3 fonctionnant par-dessus, les possibilités de personnalisation seront étendues.
Selon Matter Labs, les créateurs bénéficient d'une autonomie totale pour personnaliser et façonner chaque aspect de la chaîne, du choix d'un modèle de disponibilité des données à l'utilisation du propre système de commande décentralisé de jetons du projet.
Bien entendu, ces hyperchaînes ZK Rollup fonctionnent de manière indépendante, mais s’appuieront uniquement sur Ethereum L1 pour la sécurité et la vérification.
Source : Document zkSync
Comme le montre la figure, chaque lien hypertexte doit utiliser le moteur zkEVM de zkSync L2 pour partager la sécurité. Plusieurs chaînes ZKP fonctionnent simultanément et les preuves de bloc sont regroupées dans la couche de règlement de L1. Comme l'empilement de blocs, elle peut être continuellement étendue pour construire plus de L3, L4...
2. Technologies clés
1）ZK Cumul
La couche inférieure de ZK Stack utilise ZK Rollup comme technologie de base. Voici le processus utilisateur principal :
Les utilisateurs soumettent leurs propres transactions et Sequencer collecte les transactions en lots ordonnés, génère lui-même des certificats de validité (STARK/SNARK) et met à jour le statut. Le statut mis à jour sera soumis au contrat intelligent déployé sur L1 et vérifié. Si la vérification réussit, l'état des actifs de la couche L1 sera également mis à jour. L'avantage de ZK Rollup est qu'il a la capacité d'effectuer une vérification mathématique grâce à une preuve sans connaissance, ce qui est supérieur en termes de technologie et de sécurité.
2) Pont de lien hypertexte
Comme le montre le cadre structurel ci-dessus, ZK Stack peut réaliser une expansion sans fil et générer en continu L3, L 4, etc. Alors, comment parvenir à l’interopérabilité entre les hyperliens ?
**ZK Stack introduit le pont hyperchain. En déployant le contrat intelligent du pont partagé sur L1, il vérifie la preuve Merkle des transactions se produisant sur l'hyperchain. C'est essentiellement la même chose que ZK Rollup, sauf qu'il change par rapport au L2 d'origine. -L1. Devenu de L3-L2. **
ZK Stack prend en charge les contrats intelligents sur chaque hyperchaîne et s'appelle de manière asynchrone entre les chaînes. Les utilisateurs peuvent transférer rapidement leurs actifs de manière sans confiance en quelques minutes sans encourir de coûts supplémentaires. Par exemple, pour traiter un message sur l'hyperlien récepteur B, l'hyperlien expéditeur A doit finaliser son statut jusqu'au premier hyperlien sur lequel A et B sont communs. Ainsi, en pratique, la latence de communication d'Hyperbridge n'est qu'une question de secondes, Hyperchain peut compléter des blocs par seconde et être moins cher.
Non seulement cela, mais comme L3 peut tirer parti de la technologie de compression, la preuve est emballée. L2 élargira encore l'emballage, formant ainsi un facteur de compression plus considérable et un coût inférieur (compression récursive), ce qui permettra d'obtenir des transactions transfrontalières sans confiance, rapides (en quelques minutes) et bon marché (coût de transaction unique).
5. Polygone 2.0
Polygon est une solution spéciale L2, techniquement L1, en tant que chaîne latérale d'Ethereum. L'équipe Polygon a récemment annoncé le plan Polygon 2.0, qui aidera les développeurs à créer leurs propres chaînes ZK L2 à l'aide de ZK et à les unifier via un nouveau protocole de coordination inter-chaînes, donnant aux utilisateurs l'impression que l'ensemble du réseau utilise une seule chaîne.
Polygon 2.0 s'engage à prendre en charge un nombre illimité de chaînes, et les interactions entre chaînes peuvent se produire de manière sécurisée et instantanée sans hypothèses de sécurité ou de confiance supplémentaires, permettant une évolutivité illimitée et une liquidité unifiée.
1. Cadre structurel
Source : Blog Polygone
Polygon 2.0 se compose de 4 couches de protocole :
1) Couche de promesse
La couche de gage est un protocole basé sur PoS (Proof of Stake), qui utilise le gage $MATIC pour parvenir à une gouvernance décentralisée afin de gérer efficacement les validateurs et d'améliorer l'efficacité des mineurs.
Comme le montre la figure, Polygon 2.0 propose un gestionnaire de validateur et un gestionnaire de chaîne au niveau de la couche d'engagement.
Validator Manager : Il s'agit d'un pool de validateurs public qui gère toutes les chaînes Polygon 2.0. Y compris l'enregistrement des vérificateurs, les demandes de gage, les demandes de libération de gage... il peut être imaginé comme le service administratif des vérificateurs.
Chain Manager : Il est utilisé pour gérer l'ensemble des validateurs de chaque chaîne Polygon 2.0. Par rapport au premier, il est plus axé sur la gestion de la vérification de la chaîne, car chaque chaîne Polygon a son contrat Chain Manager, contrairement au gestionnaire de validateur. Service publique. Il se concentre principalement sur le nombre de validateurs par chaîne correspondante (liée au niveau de décentralisation), les exigences supplémentaires pour les validateurs, d'autres conditions, etc.
La couche de jalonnement a déjà formulé la structure sous-jacente des règles correspondantes pour chaque chaîne, et les développeurs n'ont qu'à se concentrer sur le développement de leurs propres chaînes.
Source : Blog Polygone
2) Couche d'interopérabilité
Les protocoles inter-chaînes sont essentiels à l'interopérabilité de l'ensemble du réseau. La manière d'effectuer des messages inter-chaînes en toute sécurité et de manière transparente est quelque chose que chaque solution d'hyperlien devrait continuer à améliorer.
Actuellement, Polygon utilise deux contrats, l'agrégateur et la file d'attente de messages, pour la prise en charge.
File d'attente de messages : principalement modifiée et mise à niveau pour le protocole Polygon zkEVM existant. Chaque chaîne Polygon maintient une file d'attente de messages locale dans un format fixe, et ces messages sont inclus dans la preuve ZK générée par la chaîne. Une fois qu'une preuve ZK est vérifiée sur Ethereum, tout message de cette file d'attente peut être consommé en toute sécurité par sa chaîne de réception et son adresse.
Agrégateur : L'agrégateur existe dans l'espoir de fournir des services plus efficaces entre la chaîne Polygon et Ethereum. Par exemple, plusieurs preuves ZK sont regroupées en une seule preuve ZK et soumises à Ethereum pour vérification afin de réduire les coûts de stockage et d'améliorer les performances.
Une fois que la preuve ZK est acceptée par l'agrégateur, la chaîne de réception peut commencer à accepter les messages de manière optimiste, car la chaîne de réception croit toutes à la preuve ZK, permettant ainsi une livraison transparente des messages, etc.
3) Couche d'exécution
La couche d'exécution permet à n'importe quelle chaîne Polygon de générer des lots de transactions ordonnées, également appelées blocs. La plupart des réseaux blockchain (Ethereum, Bitcoin, etc.) l'utilisent dans un format similaire.
La couche d'exécution comporte plusieurs composants, tels que :
Consensus : Un consensus qui permet aux validateurs de parvenir à un consensus
Mempool : collectez les transactions soumises par les utilisateurs et synchronisez-les entre les validateurs. Les utilisateurs peuvent également consulter l'état de leurs transactions dans Mempool.
P2P : permet aux validateurs et aux nœuds complets de se découvrir et d'échanger des messages ;
*...
Étant donné que cette couche est banalisée mais relativement complexe à mettre en œuvre, les implémentations hautes performances existantes (telles qu'Erigon) doivent être réutilisées lorsque cela est possible.
4) Couche de preuve
La couche de preuve génère des preuves pour chaque polygone. Il s'agit d'un protocole de preuve ZK flexible et performant qui comprend généralement les composants suivants :
Common Prover : un prouveur ZK hautes performances qui fournit une interface claire et est conçu pour prendre en charge tout type de transaction, c'est-à-dire un format de machine à états.
Constructeur de machine à états : un cadre pour définir des machines à état et utilisé pour construire le Polygon zkEVM initial. Le framework résume la complexité du mécanisme de preuve et le simplifie en une interface modulaire facile à utiliser, permettant aux développeurs de personnaliser les paramètres et de créer leurs propres machines à états à grande échelle.
Machine à états : une simulation de l'environnement d'exécution et du format de transaction que le prouveur prouve. La machine à états peut être implémentée à l'aide du constructeur décrit ci-dessus, ou elle peut être entièrement personnalisée, par exemple à l'aide de Rust.
2. Technologies clés
Source : Blog Polygone
1) Validium zkEVM
Dans la mise à jour Polygon 2.0, l'équipe l'a mis à niveau vers zkEVM validium tout en conservant le Polygon POS d'origine.
Source : Blog Polygone
D'après la simple science populaire, Validium et Rollup sont tous deux des solutions de couche 2, et leur objectif est d'étendre la capacité de transaction d'Ethereum et de raccourcir le temps de transaction. Comparez les deux :
Rollup regroupe de nombreuses transactions, puis les soumet à la chaîne principale Ethereum par lots, en utilisant Ethereum pour publier les données de transaction et vérifier la preuve, héritant ainsi pleinement de sa sécurité et de sa décentralisation sans précédent. Cependant, la publication des données de transaction sur Ethereum coûte cher et limite le débit.
Validium n'a pas besoin de soumettre toutes les données de transaction à la chaîne principale. Il utilise des preuves sans connaissance (ZKP) pour prouver que les transactions sont valides, avec des données de transaction fournies hors chaîne. tout en protégeant la vie privée des utilisateurs. Cependant, Validium nécessite une confiance dans l'environnement d'exécution, qui est relativement centralisé.
On peut comprendre que Validium est un Rollup avec un coût inférieur et une plus grande évolutivité. Cependant, le principe de fonctionnement de Polygon zkEVM (mécanisme Polygon POS) avant la mise à niveau était (ZK) Rollup, et il a également obtenu des résultats considérables. En seulement 4 mois depuis son lancement, sa TVL a grimpé à 33 millions de dollars.
Source : Défilama
À long terme, le coût de génération de preuves pour zkEVM basées sur Polygon PoS pourrait devenir un obstacle à une expansion future. Bien que l'équipe de Polygon ait travaillé dur pour réduire le coût de Batch, celui-ci a été réduit à un chiffre extrêmement impressionnant : prouvant que le coût de 10 millions de transactions n'est que de 0,0259 $. Mais le Vailidium coûte moins cher, alors pourquoi ne pas l’utiliser ?
Polygon a officiellement publié des documents. Dans les versions futures, ** Validium prendra en charge le travail précédent du point de vente tout en conservant également le point de vente. Le rôle principal de son vérificateur de point de vente est d'assurer la disponibilité des données et de trier les transactions. **
Le zkEVM Validium mis à niveau offrira une très grande évolutivité et un coût très faible. Parce qu'il est très adapté aux applications avec un volume de transactions important et de faibles frais de transaction, telles que Gamefi, Socialfi et DeFi, etc. Pour les développeurs, aucune opération n'est requise, il leur suffit de mettre à jour avec le réseau principal pour terminer la mise à jour de Validium.
2) Cumul zkEVM
Actuellement, Polygon PoS (bientôt mis à niveau vers Polygon Validium) et Polygon zkEVM Rollup sont les deux réseaux publics de l'écosystème Polygon. Cela reste le cas après la mise à niveau, avec l'avantage supplémentaire que les deux réseaux utilisent la technologie de pointe zkEVM, l'un comme agrégation et l'autre comme vérification.
Polygon zkEVM Rollup offre déjà le plus haut niveau de sécurité, mais au prix d'un coût légèrement plus élevé et d'un débit limité. Cependant, il est bien adapté aux applications qui gèrent des transactions de grande valeur et donnent la priorité à la sécurité, telles que les DeFi Dapps de grande valeur.
六. Décision d'orbite
Arbitrum est actuellement la chaîne publique L2 la plus importante. Depuis son lancement en août 2021, sa TVL a dépassé les 5,1 milliards de dollars et, en tant que première L2, elle occupe près de 54 % de part de marché.
Arbitrum a sorti la version Orbit en mars de cette année. Avant cela, Arbitrum avait lancé une série de produits écologiques :
Arbitrum One : le premier et principal rollup du réseau principal de l'écosystème Arbitrum.
Arbitrum Nova : il s'agit du deuxième déploiement du réseau principal d'Arbitrum, ciblant les projets sensibles aux coûts et nécessitant un volume de transactions élevé.
Arbitrum Nitro : il s'agit de la pile logicielle technologique qui alimente Arbitrum L2, rendant Rollup plus rapide, moins cher et plus compatible EVM.
Arbitrum Orbit : un cadre de développement pour créer et déployer L3 sur le réseau principal Arbitrum.
Aujourd'hui, nous nous concentrerons sur Arbitrum Orbit.
1. Cadre structurel
À l'origine, si les développeurs voulaient utiliser Arbitrum Orbit pour créer un réseau L2, ils publieraient d'abord une proposition, qui serait votée par l'Arbitrum DAO. Si elle était adoptée, une nouvelle chaîne L2 serait créée. Cependant, aucune autorisation n'est requise pour développer L3, 4, 5... sur L2. N'importe qui peut fournir un framework sans autorisation pour déployer des chaînes personnalisées sur Arbitrum L2.
Source : Livre blanc
Comme vous pouvez le constater, Arbitrum Orbit s'efforce également de permettre aux développeurs de personnaliser leur propre chaîne Oribit L3 basée sur la couche 2, comme Arbitrum One, Arbitrum Nova ou Arbitrum Goerli. Les développeurs peuvent personnaliser l'accord de confidentialité, la licence, le modèle économique des jetons, la gestion de la communauté, etc. de cette chaîne, donnant ainsi la plus grande autonomie aux développeurs.
Parmi eux, il convient de noter qu'Oribit permet à la chaîne L3 d'utiliser le jeton de cette chaîne comme unité de règlement des frais, développant ainsi efficacement son propre réseau.
2. Technologies clés
1）Regrouper AnyTrust
Ces deux protocoles prennent respectivement en charge Arbitrum One et Arbitrum Nova. Comme présenté précédemment, Arbitrum One est un cumul de réseau principal principal ; Arbitrum Nova est le deuxième cumul de réseau principal, mais il est connecté au protocole AnyTrust. Il peut être introduit en introduisant "la sécurité hypothèses » ( Trust Assumption) pour accélérer le règlement et réduire les coûts.
Parmi eux, Arbitrum Rollup est un OP Rollup, donc sans autre explication, nous procéderons à une analyse détaillée du protocole AnyTrust.
Le protocole AnyTrust gère principalement la disponibilité des données et est approuvé par une série d'organismes tiers tels que le DAC (Data Availability Committee). Et en introduisant des « hypothèses de sécurité », les coûts de transaction sont considérablement réduits. La chaîne AnyTrust fonctionne sur Arbitrum One en tant que sidechain, avec des coûts inférieurs et des vitesses de transaction plus rapides.
Alors, qu’est-ce qu’une « hypothèse de confiance » ? Pourquoi son existence réduit-elle les coûts de transaction et nécessite-t-elle moins de confiance ?
Selon la documentation officielle d'Arbitrum, la chaîne AnyTrust est gérée par un comité de nœuds et utilise des hypothèses minimales pour déterminer combien de membres du comité sont honnêtes. Par exemple, disons que le comité est composé de 20 personnes et que l'on suppose qu'au moins 2 membres sont honnêtes. Comparé à BFT qui exige que les ⅔ membres soient honnêtes, AnyTrust abaisse le seuil de confiance au minimum.
Dans une transaction, puisque le comité promet de fournir les données de transaction, le nœud n'a pas besoin d'enregistrer toutes les données de la transaction L2 sur L1, mais doit seulement enregistrer la valeur de hachage du lot de transactions, ce qui peut considérablement réduire les coûts. du cumul. . C'est pourquoi la chaîne AnyTrust peut réduire les coûts de transaction.
Concernant la question de la confiance, comme mentionné précédemment, on suppose que seuls 2 des 20 membres sont honnêtes, et cette hypothèse est vraie. Tant que 19 des 20 membres du comité s’engagent à garantir l’exactitude de l’accord, il peut être exécuté en toute sécurité. Alors même si le membre qui n’a pas signé est honnête, l’un des 19 membres qui ont signé doit être honnête.
Que devons-nous faire si les membres ne signent pas ou si un grand nombre de membres refusent de coopérer, ce qui entraîne un dysfonctionnement du système ? La chaîne AnyTrust peut toujours fonctionner, mais elle reviendra au protocole Rollup d'origine et les données sont toujours publiées sur Ethereum L1. Lorsque le comité fonctionnera correctement, la chaîne reviendra à un mode moins cher et plus rapide.
Aribtrum a lancé ce protocole dans l'espoir de répondre aux besoins d'applications nécessitant une vitesse de traitement élevée et un faible coût, comme le domaine Gamefi.
2）Nitro
Nitro est la dernière version de la technologie Arbitrum. Son élément principal est le Prover, qui effectue une preuve interactive traditionnelle de fraude sur Arbitrum via le code WASM. Et tous ses composants sont complets. Arbitrum a terminé la mise à niveau fin août 2022, migrant/mettant à niveau de manière transparente l'Arbitrum One existant vers Aribitrum Nitro.
Nitro a les fonctionnalités suivantes :
Traitement des transactions en deux étapes : les transactions de l'utilisateur sont d'abord intégrées dans une seule séquence ordonnée, puis Nitro soumet la séquence, traite les transactions en séquence et réalise des transitions d'état déterministes.
Geth : Nitro utilise le client Ethereum Geth (go-ethereum) actuellement le plus pris en charge pour prendre en charge la structure de données, le format et la machine virtuelle d'Ethereum, le rendant ainsi mieux compatible avec Ethereum.
Exécution et preuve séparées : Nitro prend le même code source et le compile deux fois, une fois en code natif pour exécuter des transactions dans les nœuds Nitro, et de nouveau en WASM pour preuve.
OP Rollup avec preuves de fraude interactives : Nitro utilise OP Rollup, y compris les premières preuves de fraude interactives d'Arbitrum pour régler les transactions sur la chaîne Ethereum de couche 1.
Ces fonctionnalités d'Oribit fournissent un support technique pour les cas d'utilisation d'Arbitrum L3 et L 4. Arbitrum peut attirer les développeurs qui recherchent une personnalisation pour créer leurs propres chaînes personnalisées.
七. Pile Starknet
Le cofondateur de StarkWare, Eli Ben-Sasson, a déclaré lors de la conférence EthCC à Paris que Starknet lancerait bientôt Starknet Stack, permettant à toute application de déployer sa propre chaîne d'applications Starknet sans autorisation.
Des technologies clés telles que la preuve STARK dans Starknet, le langage de programmation Cairo et l'abstraction de compte natif offrent une garantie de puissance pour le développement rapide de Starknet. Lorsque les développeurs utilisent Stack pour personnaliser leur propre chaîne d'applications Starknet, celle-ci est évolutive et librement configurable, ce qui peut considérablement augmenter le débit du réseau et atténuer la congestion du réseau principal.
Bien que Starknet ne soit pour l’instant qu’une idée préliminaire, les documents techniques officiels n’ont pas encore été publiés. Cependant, Madara Sequencer et LambdaClass sont développés respectivement en tant que composants Sequencer et Stack compatibles Starknet pour mieux s'adapter à Starknet. Les responsables travaillent également dur sur la prochaine pile Starknet, notamment en développant des nœuds/moteurs d'exécution/vérification complets et d'autres composants.
Il convient de noter qu'il n'y a pas si longtemps, StarkNet a soumis une proposition de « protocole décentralisé simple », dans l'espoir de changer le statut actuel du séquenceur d'opération monopoint actuel de L2. Ethereum est décentralisé, mais pas L2, et ses revenus MEV rendent Sequencer mauvais.
StarkNet a répertorié certaines solutions dans la proposition telles que :
Staking L1 et élection du leader : les membres de la communauté peuvent miser sur Ethereum sans autorisation pour rejoindre la collection Staker. Ensuite, sur la base de la répartition des actifs collectifs et du nombre aléatoire sur la chaîne L1, un groupe de Staker est sélectionné au hasard comme leader responsable de la production d'un bloc Epoch. Cela abaisse non seulement le seuil pour les utilisateurs de Staker, mais son caractère aléatoire peut également empêcher efficacement les revenus gris MEV.
Mécanisme de consensus L2 : basé sur Tendermint, le mécanisme de consensus byzantin de preuve de consensus auquel Leader participe en tant que nœud. Une fois le consensus confirmé, il est exécuté par Voter et Proposer appelle Prover pour générer ZKP.
En outre, il existe des plans pour la certification ZK, les mises à jour du statut L1, etc., combinées à l'initiative majeure précédente visant à aider la communauté à exploiter le code Prover sans autorisation, la proposition de StarkNet cherche à résoudre le manque de décentralisation de L2 et à essayer d'équilibrer les incohérence de la blockchain. Peut-être que le problème triangulaire est vraiment perceptible.
Dans ce chapitre, à travers l'explication technique du CP et des principales piles de couche 2, nous pouvons effectivement constater que la solution actuelle de pile de couche 2 peut résoudre efficacement le problème d'expansion d'Ethereum, mais elle apporte également une série de défis et de problèmes, notamment en termes de compatibilité.Sexuellement. La technologie de la solution Stack des L2 n'est pas aussi mature que celle du CP. Même le concept technique du CP il y a trois ou quatre ans mérite encore d'être appris des L2 actuels. Donc au niveau technique, le CP actuel est encore bien supérieur à la couche 2. Cependant, la technologie avancée à elle seule ne suffit pas. Dans le deuxième article suivant, nous discuterons des avantages, des inconvénients et des caractéristiques respectifs des piles CP et L2 du point de vue de la valeur symbolique et du développement écologique afin d'améliorer les perspectives des lecteurs.
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.
Cosmos, chapitre Polkadot VS Layer2 Stacks (1)
Introduction
Récemment, Optimism, dirigé par ETH Layer 2, et zkSync, Polygon, Arbitrum et StarkNet ont tous lancé leurs propres solutions Stack, toutes visant à construire un ensemble de codes modulaires open source permettant aux développeurs de personnaliser leur propre couche 2.
Comme nous le savons tous, l'Ethereum actuel est connu pour ses faibles performances et son niveau élevé de gaz. L'émergence de couches 2 telles que OP et zkSync Era a résolu ces problèmes. Cependant, qu'il soit déployé sur une machine virtuelle EVM ou sur la couche 2, il existe essentiellement un problème de « compatibilité ». Ce n'est pas seulement le code sous-jacent du Dapp qui doit être compatible avec l'EVM, mais aussi la souveraineté du Dapp.
La première partie est le niveau du code. Comme EVM doit prendre en charge différents types d'applications déployées dessus, il a été optimisé sur le cas d'utilisateur moyen pour prendre en compte tous les types d'utilisateurs. Mais il n'est pas aussi convivial pour les Dapps déployés dessus. Par exemple, les applications Gamefi accorderont plus d'attention à la vitesse et aux performances ; les utilisateurs de Socialfi peuvent accorder plus d'attention à la confidentialité et à la sécurité. Cependant, en raison de la nature unique de l'EVM, Dapp doit renoncer à quelque chose, à savoir la compatibilité au niveau du code.
La deuxième partie est le niveau de souveraineté. Puisque tous les Dapps partagent l'infrastructure, deux concepts ont émergé : la gouvernance des applications et la gouvernance sous-jacente. La gouvernance des applications est sans aucun doute soumise à la gouvernance sous-jacente. Les besoins spécifiques de certains Dapps nécessitent une mise à niveau via l'EVM sous-jacent. donc Dapp manque de souveraineté. Par exemple, les nouvelles fonctionnalités d'Uniswap V4 nécessitent que l'EVM sous-jacent prenne en charge le stockage transitoire et s'appuient sur l'EIP-1153 pour être ajouté à la mise à niveau de Cancun.
Afin de résoudre les problèmes mentionnés ci-dessus concernant les faibles performances de traitement et les problèmes de souveraineté d'Ethereum L1, Cosmos (2019) et Polkadot (2020) ont vu le jour. Tous deux espèrent aider à développer et à construire leurs propres chaînes personnalisées, permettant aux Dapps blockchain de maîtriser l'autonomie souveraine, d'atteindre une interopérabilité inter-chaînes haute performance et de réaliser un réseau d'interopérabilité de chaîne complète.
Aujourd'hui, 4 ans plus tard, les L2 ont également lancé leurs propres solutions de réseaux hyperliens, d'OP Stack, à ZK Stack, en passant par Polygon 2.0, Arbitrum Orbit et enfin StarkNet, pour ne pas être en reste, a lancé le concept Stack.
Quels types de collisions et d'étincelles se produiront entre le pionnier du réseau complet CP (Cosmos Polkadot) et les L2 ? Afin de vous fournir une perspective complète et approfondie, nous explorerons ce sujet en profondeur à travers une série de trois articles. **Cet article, en tant que premier chapitre de cette série, triera les solutions techniques de chaque entreprise. Le deuxième chapitre triera le modèle économique et l'écologie de chaque solution, et résumera les différences entre la couche 1 et la couche 1. 2 Stack sélectionne les caractéristiques à prendre en compte. Dans le dernier chapitre, nous discutons de la façon dont la couche 2 développe sa propre super chaîne et résumons toute la série d'articles. **
1. Cosmos
Cosmos est un réseau décentralisé de blockchains parallèles indépendantes. En fournissant un SDK de cadre de développement commun, les développeurs peuvent facilement créer leurs propres blockchains, et plusieurs blockchains indépendantes et différentes spécifiques à des applications peuvent interagir les unes avec les autres. Les liens communiquent entre eux, formant un réseau interopérable. et un réseau complet évolutif.
1. Cadre structurel
Comme mentionné précédemment, lorsqu'il existe des chaînes d'applications à grande échelle dans l'écosystème et que chaque chaîne utilise le protocole IBC pour communiquer et transmettre des jetons, l'ensemble du réseau sera aussi encombrant et difficile à trier qu'une toile d'araignée.
Ainsi, afin de résoudre ce problème, Cosmos a proposé une architecture en couches, qui contient deux types de blockchains : Hubs (chaîne de hub centrale) et Zones (chaîne régionale).
**Les zones sont des chaînes d'applications conventionnelles et les hubs sont des blockchains spécialement conçues pour connecter les zones entre elles, servant principalement à la communication entre les zones. **Lorsqu'une zone crée une connexion IBC avec le Hub, le Hub peut accéder automatiquement (c'est-à-dire envoyer et recevoir) toutes les zones qui lui sont connectées. Cette structure réduit considérablement la complexité de la communication.
De plus, il convient de noter que Cosmos et Cosmos Hub sont deux choses complètement différentes. Cosmos Hub n'est qu'une des chaînes existant dans l'écosystème Cosmos et servant principalement d'émetteur et de centre de communication de $ATOM. **Vous pouvez comprendre Hub comme le centre de l'écosystème, mais en fait, n'importe quelle chaîne peut devenir un Hub. Si le Hub devient le centre de l’écosystème, cela est en réalité contraire à l’intention initiale du Cosmos. **Parce que Cosmos est essentiellement attaché à l'autonomie de chaque chaîne et dispose d'une souveraineté absolue. Si le Hub est utilisé comme centre de pouvoir, alors la souveraineté ne s'appelle plus souveraineté. Ainsi, lorsque vous comprenez Hub, vous devez accorder une attention particulière à ce point.
2. Technologies clés
2.1 GRV
IBC (Inter-Blockchain Communication), qui est une communication inter-chaînes, permet à des chaînes hétérogènes de se transférer des jetons et des données entre elles. Dans l'écosystème Cosmos, le cadre sous-jacent du SDK est le même et le moteur de consensus Tendermint doit être utilisé. Cependant, l'hétérogénéité existe toujours, car les chaînes peuvent avoir des fonctionnalités, des cas d'utilisation et des détails de mise en œuvre différents au sein du cadre.
Alors comment assurer la communication entre des chaînes hétérogènes ?
Cela nécessite seulement une finalité au niveau du consensus. La finalité instantanée signifie que tant que plus d'un tiers des validateurs sont corrects, le bloc ne sera pas bifurqué, garantissant que la transaction est définitive une fois le bloc produit. Indépendamment des différences dans les cas d'application et du consensus entre les chaînes hétérogènes, tant que leurs niveaux de consensus sont garantis comme définitifs, l'interopérabilité entre les chaînes sera déterminée par des règles unifiées.
Ce qui suit est un processus de base de communication entre chaînes. Supposons que vous souhaitiez transférer 10 $ATOM de la chaîne A à la chaîne B :
Pour le moment, le $ATOM sur la chaîne B n'est pas le vrai $ATOM, mais juste un certificat. Le $ATOM verrouillé sur la chaîne A ne peut pas être utilisé, mais celui sur la chaîne B peut être utilisé normalement. Lorsque l'utilisateur consomme les informations d'identification sur B, le $ATOM verrouillé sur la chaîne A sera également détruit.
Cependant, le plus grand défi auquel est confrontée la communication entre chaînes n'est pas de savoir comment représenter les données d'une chaîne sur une autre chaîne, mais comment gérer des situations telles que les fourches de chaîne et les réorganisations de chaîne.
Parce que chaque chaîne dans Cosmos est une chaîne individuelle indépendante et autonome avec son propre vérificateur dédié. Par conséquent, il est très probable qu'il y ait des partitions qui font le mal.Par exemple, si la chaîne A transmet des messages à la chaîne B, vous devez alors vérifier les validateurs de la chaîne B à l'avance avant de décider de faire confiance à la chaîne.
Par exemple, supposons que le petit point rouge sur l'image représente un jeton ETM et que les utilisateurs des trois partitions d'ABC souhaitent tous utiliser EVMOS pour exécuter des Dapps dans les partitions, car les transferts d'actifs sont effectués via une communication inter-chaînes. ETM.
Si la partition Ethermint lance une attaque à double dépense à ce moment-là, la partition ABC sera sans aucun doute affectée, mais elle ne se limitera qu'à cela. Les autres réseaux non liés à ETM ne subiront aucune attaque, ce qui est également garanti par Cosmos : même si une telle transmission d'informations malveillantes se produit, elle n'affectera toujours pas l'ensemble du réseau.
2.2 BFT à la menthe tendre
Cosmos utilise Tendermint BFT comme algorithme de consensus sous-jacent et moteur de consensus de Cosmos. Il combine et regroupe l'infrastructure sous-jacente et la couche de consensus de la blockchain dans une solution de moteur universelle et utilise la technologie ABCI pour prendre en charge l'encapsulation de tout langage de programmation. la couche de consensus et le réseau sous-jacents. ** Les développeurs sont donc libres de choisir la langue de leur choix.
2.3 SDK Cosmos
Cosmos SDK est un framework modulaire lancé par Cosmos qui simplifie l'opération de création de Dapps sur la couche consensus. Les développeurs peuvent facilement créer des applications/chaînes spécifiques sans avoir à réécrire le code de chaque module, ce qui réduit considérablement la pression du développement et permet désormais aux développeurs de porter les applications déployées sur l'EVM vers Cosmos.
Source:
De plus, les blockchains construites à l'aide de Tendermint et Cosmos SDK créent également de nouveaux écosystèmes et de nouvelles technologies qui mènent le développement de l'industrie, comme Nym, la chaîne de confidentialité, Celestia, qui assure la disponibilité des données, etc. C'est précisément grâce à la flexibilité et à la facilité d'utilisation offertes par Cosmos que les développeurs peuvent se concentrer sur l'innovation des projets sans avoir à envisager la duplication du travail.
2.4 Compte de sécurité interchaîne
1) Sécurité inter-chaînes
Parce que Cosmos est différent de l'écosystème Ethereum, il comporte L1 et L2. Chaque chaîne d'applications de l'écosystème Cosmos est égale l'une à l'autre et il n'y a pas de relation progressive ou supérieure-inférieure. Cependant, pour cette raison, la sécurité inter-chaînes n’est pas aussi complète qu’Ethereum. Dans Ethereum, le caractère définitif de toutes les transactions est confirmé par Ethereum, héritant du titre sous-jacent. Mais pour une blockchain unique qui construit sa propre sécurité, comment la sécurité doit-elle être maintenue ?
Cosmos a lancé Interchain Security, qui permet essentiellement une sécurité partagée en partageant un grand nombre de nœuds existants. Par exemple, la chaîne monolithique peut partager un ensemble de nœuds de vérification avec le Cosmos Hub pour générer de nouveaux blocs pour la chaîne monolithique. Étant donné que les nœuds desservent à la fois le Cosmos Hub et la chaîne unique, ils peuvent recevoir des frais et des récompenses des deux chaînes.
Source :/tokenomics-dao/token-use-cases-part-1-atom-of-true-staking-token-5 fd 21 j 41161 e
Comme le montre la figure, les transactions initialement générées au sein de la chaîne X sont générées par les nœuds de X pour vérification. Si vous partagez un nœud avec Cosmos Hub ($ATOM), les transactions initialement générées sur la chaîne X seront vérifiées et calculées par les nœuds de la chaîne Hub pour générer de nouveaux blocs pour X.
Logiquement, choisir une chaîne relativement mature avec un grand nombre de nœuds, comme la chaîne Hub, est le premier choix pour une sécurité partagée. Parce que s’ils veulent attaquer une telle chaîne, les attaquants doivent disposer d’une grande quantité de jetons $ATOM comme gage, ce qui augmente la difficulté de l’attaque.
De plus, le mécanisme de sécurité inter-chaînes réduit également considérablement les obstacles à la création de nouvelles chaînes. D'une manière générale, si une nouvelle chaîne ne dispose pas de ressources particulièrement excellentes, elle devra peut-être passer beaucoup de temps à attirer des validateurs et à cultiver l'écosystème. Mais dans Cosmos, comme les validateurs peuvent être partagés avec la chaîne Hub, cela réduit considérablement la pression sur la nouvelle chaîne et accélère le processus de développement.
2) Compte interchaîne
Dans l’écosystème Cosmos, chaque chaîne d’applications étant régie par elle-même, les applications ne peuvent pas accéder les unes aux autres. Par conséquent, Cosmos fournit un compte inter-chaînes qui permet aux utilisateurs d'accéder directement à toutes les chaînes Cosmos prenant en charge IBC à partir du Cosmos Hub, afin que les utilisateurs puissent accéder aux applications de la chaîne B dans la chaîne A pour obtenir une interaction avec la chaîne complète.
2.À pois
Comme Cosmos, Polkadot s'engage à construire une infrastructure qui permet aux développeurs de déployer librement de nouvelles chaînes et de parvenir à l'interopérabilité entre les chaînes.
1. Cadre structurel
1.1 Chaîne de relais :
La chaîne de relais peut également être appelée chaîne principale, qui peut être comprise comme le soleil dans le système solaire. En tant que partie centrale de l'ensemble du réseau, toutes les chaînes secondaires tournent autour d'elle. Comme le montre la figure, une chaîne de relais (Relay Chain) est liée à de nombreuses chaînes avec différentes fonctions, telles que la chaîne de transactions, la chaîne de stockage de fichiers, la chaîne de l'Internet des objets, etc.
Source :/polkadot-network/polkadot-the-foundation-of-a-new-internet-e 8800 ec 81 c 7
Il s'agit de la solution d'expansion hiérarchique de Polkadot. Une chaîne de relais est connectée à une autre chaîne de relais pour obtenir une évolutivité illimitée. (Remarque : fin juin de cette année, le fondateur de Polkadot, Gavin, a proposé Polkadot 2.0, ce qui pourrait changer une nouvelle perspective sur la compréhension de Polkadot.)
1.2 Parachaîne :
La chaîne de relais dispose de plusieurs emplacements Para-Chain, et la parachain est connectée à la chaîne de relais via ces emplacements, comme le montre la figure :
Source : om/cn/learn/slot-auction-cn
Cependant, afin d'obtenir un créneau, les parachains participants doivent miser leur $DOT. Une fois un emplacement obtenu, la parachain peut interagir avec le réseau principal Polkadot via cet emplacement et partager la sécurité. Il convient de mentionner que le nombre de slots est limité et augmentera progressivement.Il est initialement prévu de prendre en charge 100 slots, et les slots seront périodiquement remaniés et attribués selon le mécanisme de gouvernance pour maintenir l'activité de l'écologie parachain.
Les parachains qui obtiennent des emplacements peuvent bénéficier de la sécurité partagée et de la liquidité inter-chaînes de l'écosystème Polkadot. Dans le même temps, la chaîne parallèle doit également fournir en retour certains avantages et contributions au réseau principal de Polkadot, par exemple en prenant en charge la majeure partie du traitement des transactions du réseau.
1.3 Fils parallèles :
Les parathreads sont un autre mécanisme de traitement similaire aux parachains. La différence est que les parachains ont des emplacements un par un et ont des emplacements dédiés qui peuvent fonctionner en continu sans interruption. Mais les threads parallèles font référence au partage d'un emplacement entre des threads parallèles et à l'utilisation à tour de rôle de cet emplacement pour s'exécuter. **
Lorsqu'un thread parallèle obtient le droit d'utiliser le slot, il peut temporairement fonctionner comme une parachain, traitant des transactions, générant des blocs, etc. Mais une fois cette période écoulée, le slot doit être libéré pour être utilisé par d'autres threads parallèles.
Par conséquent, les threads parallèles n'ont pas besoin d'hypothéquer les actifs pendant une longue période, ils n'ont besoin que de payer certains frais lors de l'acquisition de chaque période, on peut donc dire qu'il s'agit d'une méthode de paiement à l'utilisation pour utiliser le créneau. Bien sûr, si un parathread reçoit suffisamment de soutien et de votes, il peut être mis à niveau vers une parachain et obtenir un emplacement fixe.
Par rapport aux parachains, les threads parallèles ont des coûts inférieurs et abaissent le seuil d'entrée pour Polkadot. Cependant, il n'y a aucune garantie quand vous pourrez obtenir le droit d'utiliser le slot, qui n'est pas stable. Par conséquent, lesquelles sont les plus adaptées à une utilisation temporaire ou au test de nouvelles chaînes ? Les chaînes qui espèrent fonctionner de manière stable doivent encore être mises à niveau vers des parachaines.
1.4 Pont adaptateur :
La communication entre les parachains ne peut être réalisée que via XCMP (qui sera présenté plus tard), et elles partagent la sécurité et le même consensus. Et s’il s’agissait d’une chaîne hétérogène ?
Une chose à noter ici est que bien que le cadre fourni par Substrate rende toutes les chaînes connectées à l'écosystème Polkadot isomorphes, avec le développement de l'écosystème, il y aura inévitablement des chaînes publiques matures avec de grands systèmes qui voudront participer. ... dans l'écologie. Si vous leur demandez de se redéployer en utilisant uniquement le substrat, c'est fondamentalement impossible. Alors comment mettre en œuvre la transmission de messages entre chaînes hétérogènes ?
**Prenons un exemple concret. Si vous souhaitez transférer des fichiers d'un téléphone Apple vers un téléphone Android via une connexion, les prises sont différentes, vous avez donc besoin d'un convertisseur pour vous connecter. C'est le rôle réel du pont de transfert. **C'est une parachain qui est un intermédiaire entre la chaîne relais et la chaîne hétérogène (chaîne externe). Des contrats intelligents sont déployés sur la chaîne parallèle et la chaîne hétérogène, permettant à la chaîne relais d'interagir avec la chaîne externe et de réaliser des cross- Fonction de chaîne.
2. Technologies clés
2.1 BÉBÉGrand-père
BABE (Blind Assignment for Blockchain Extension) est le mécanisme de génération de blocs de Polkadot. En termes simples, il sélectionne au hasard les validateurs pour produire de nouveaux blocs, et chaque validateur est attribué à un créneau horaire différent. Au sein de ce créneau horaire, seuls les validateurs affectés à ce créneau peuvent produire des blocs.
Instructions additionnelles:
**En d'autres termes, il s'agit d'une période exclusive. Dans la période 1, le validateur 1 affecté à cette période 1 est chargé de produire les blocs. Chaque validateur a une période de temps et ne peut pas produire de blocs à plusieurs reprises. **
L’avantage est que l’attribution aléatoire maximise l’équité car chacun a la chance d’être attribué. Et comme la plage horaire est connue, chacun peut se préparer à l’avance et il n’y aura pas de génération de bloc inattendue.
Grâce à cette méthode de génération de blocs alloués aléatoirement, le fonctionnement ordonné et équitable de l'écosystème Polkadot est assuré. Alors comment s'assurer que tous les blocs adoptent le même consensus ? Ensuite, nous présenterons un autre mécanisme de Polkadot : Grand-père
Grandpa est un mécanisme de finalisation des blocs, qui peut résoudre le problème de fork qui peut survenir en raison de différents consensus lorsque BABE produit des blocs. Par exemple, les nœuds BABE 1 et 2 ont produit des blocs différents en même temps, ce qui a abouti à un fork. À ce moment-là, grand-père entrera en jeu. Il demandera à tous les validateurs : selon vous, quelle chaîne est la meilleure ?
Les validateurs examineront les deux chaînes et voteront pour celle qu'ils jugent la meilleure. La chaîne avec le plus de votes sera finalement confirmée par Papy et deviendra la chaîne finale. La chaîne rejetée sera abandonnée.
Par conséquent, grand-père est comme le « grand-père » de tous les validateurs, jouant le rôle de décideur final, éliminant ainsi le risque de forks que BABE peut apporter. Il permet à Blockchain de finaliser une chaîne sur laquelle tout le monde s’accorde.
Pour résumer, BABE est responsable de la production aléatoire des blocs, et Grand-père est responsable de la sélection de la chaîne finale. Les deux travaillent ensemble pour permettre à l'écosystème Polkadot de fonctionner en toute sécurité.
2.2 Substrat
Substrate est un framework de développement écrit dans le langage Rust, avec des composants extensibles sous-jacents fournis par FRAME, permettant à Substrate de prendre en charge une variété de cas d'utilisation différents. Toute blockchain construite à l'aide de Substrate est non seulement nativement compatible avec Polkadot, mais peut partager la sécurité et fonctionner simultanément avec d'autres chaînes parallèles. Elle aide également les développeurs à créer leurs propres mécanismes de consensus exclusifs, modèles de gouvernance, etc., et change constamment en fonction des besoins. de développeurs.
De plus, Substrate offre une grande commodité lors de la mise à niveau automatique, car il s'agit d'un module indépendant au moment de l'exécution et peut être séparé des autres composants. Par conséquent, ce module en cours d'exécution peut être directement remplacé lors de la mise à jour des fonctions. En tant que parachain partageant le consensus, tant que le réseau et le consensus sont synchronisés avec la chaîne de relais, la logique de fonctionnement peut être directement mise à jour sans avoir besoin d'un hard fork.
2,3 XCM
Si vous pouviez expliquer XCM en une phrase, ce serait : **Un format de communication inter-chaînes qui permet à différentes blockchains d'interagir. **
Par exemple, Polkadot possède de nombreuses parachaines. Si la parachain A veut communiquer avec la parachain B, elle doit regrouper les informations au format XCM. **XCM est comme un protocole linguistique. Si tout le monde utilise ce protocole pour communiquer, il peut communiquer sans barrières. **
Le format XCM (Cross-Consensus Message Format) est le format de message standard utilisé pour la communication inter-chaînes dans l'écosystème Polkadot, et trois méthodes différentes de livraison de messages en dérivent :
Par exemple, puisque le format XCM contient diverses informations, telles que le montant des actifs à transférer, le compte destinataire, etc. Lors de l'envoi d'un message, le canal HRMP ou la chaîne de relais délivrera ce message au format XCM. Une fois que l'autre chaîne parallèle aura reçu le message, elle vérifiera si le format est correct, puis analysera le contenu du message, puis exécutera selon les instructions du message, comme le transfert d'actifs vers un compte désigné. l'interaction de la chaîne est réalisée et les deux chaînes réussissent.
Les ponts de communication comme XCM sont très importants pour les écosystèmes multi-chaînes comme Polkadot.
Après avoir compris Cosmos et Polkadot, je crois avoir compris leur vision et leur cadre. Nous expliquerons donc ensuite en détail quelles sont les solutions Stack lancées par ETH L2 ?
三. Pile OP
1. Cadre structurel
Selon la documentation officielle, OP Stack est composé d'une série de composants et est maintenu par OP Collective. Il apparaît d'abord sous la forme d'un logiciel derrière le réseau principal, et apparaît enfin sous la forme de la super chaîne Optimism et de sa gouvernance. L2 développé à l'aide d'OP Stack peut partager la sécurité, les couches de communication et la pile de développement commune. Et les développeurs sont libres de personnaliser la chaîne pour répondre à tout cas d’utilisation spécifique de la blockchain.
À partir de la figure, nous pouvons comprendre que toutes les hyperchaînes d'OP Stack communiqueront via le super pont de chaîne OP Bridge et utiliseront Ethereum comme consensus de sécurité sous-jacent pour construire une super chaîne L2 et diviser la structure interne de chaque hyperchaîne.
**1) Couche de disponibilité des données : **Les chaînes utilisant OP Stack peuvent utiliser ce module de disponibilité des données pour obtenir leurs données d'entrée. Étant donné que toutes les chaînes reçoivent des données de cette couche, cette couche a un impact significatif sur la sécurité. Si certaines données ne peuvent pas être récupérées, il se peut qu'il n'y ait aucun moyen de synchroniser la chaîne.
Comme vous pouvez le voir sur cette figure, OP Stack utilise Ethereum et EIP-4844. En d’autres termes, il utilise essentiellement la blockchain Ethereum pour accéder aux données.
**2) Couche de séquençage : **Le séquenceur détermine comment collecter les transactions des utilisateurs et les publier sur la couche de disponibilité des données, qui est traitée à l'aide d'un seul séquenceur dédié dans la pile OP. Cependant, cela peut empêcher le trieur de conserver les transactions trop longtemps. À l'avenir, OP Stack modularisera le trieur afin que la chaîne puisse facilement modifier le mécanisme de tri.
Sur la figure, vous pouvez voir un séquenceur unique et un multi-séquenceur. Le séquenceur unique permet à n'importe qui d'agir comme séquenceur à tout moment (risque plus élevé). Le multi-séquenceur est tiré d'un ensemble prédéfini de participants possibles. Choisissez. Ensuite, si vous choisissez plusieurs séquenceurs, chaque chaîne développée sur la base d'OP Stack peut être explicitement sélectionnée.
3) Couche de dérivation : Cette couche détermine comment traiter l'entrée traitée des données brutes pour la disponibilité des données et la transmet à la couche d'exécution via l'API d'Ethereum. Comme le montre l'image, OP Stack est composé de Rollup et d'Indexer.
**4) Couche d'exécution : **Cette couche définit la structure d'état au sein du système OP Stack. Lorsque l'API du moteur reçoit les entrées de la dérivation, la transition d'état sera déclenchée. On peut voir sur la figure que sous OP Stack, la couche d'exécution est EVM. Cependant, avec une version légèrement modifiée, il peut également prendre en charge d'autres types de VM. Par exemple, Pontem Network prévoit d'utiliser OP Stack pour développer une Move VM L2.
**5) Couche de règlement : **Comme son nom l'indique, elle est utilisée pour gérer le retrait d'actifs de la blockchain, mais un tel retrait nécessite de prouver le statut de la chaîne cible à une chaîne tierce, puis de traiter le actifs selon leur statut. L'essentiel est de permettre à la chaîne tierce de comprendre l'état de la chaîne cible.
Une fois qu'une transaction est publiée et finalisée sur la couche de disponibilité des données correspondante, la transaction est également finalisée sur la chaîne OP Stack. Il ne peut plus être modifié ou supprimé sans détruire la couche de disponibilité des données sous-jacente. Il se peut que la transaction n'ait pas encore été acceptée par la couche de règlement, car la couche de règlement doit être en mesure de vérifier le résultat de la transaction, mais la transaction elle-même est déjà immuable.
Il s'agit également d'un mécanisme pour les chaînes hétérogènes. Les chaînes hétérogènes ont des mécanismes de règlement différents. Par conséquent, dans OP Stack, la couche de règlement est en lecture seule, permettant aux chaînes hétérogènes de prendre des décisions en fonction de l'état de OP Stack.
À cette couche, nous voyons qu'OP Stack utilise la preuve de panne dans OP Rollup. Les proposants peuvent proposer un statut valide qu'ils contestent, et s'il n'est pas prouvé qu'il est erroné dans un délai donné, il sera automatiquement considéré comme correct.
**6) Couche de gouvernance : **Comme vous pouvez le voir sur l'image, les jetons multi-signature + $OP sont utilisés pour la gouvernance dans la pile OP. Habituellement, la multi-signature est utilisée pour gérer la mise à niveau des composants du système Stack. Les opérations seront effectuées lorsque tous les participants participeront à la signature. Les détenteurs de jetons $OP peuvent voter sur le DAO communautaire pour participer à la gouvernance.
**OP Stack est comme une combinaison de Cosmos et Polkadot. Il peut personnaliser librement des chaînes exclusives comme Cosmos et peut également partager la sécurité et le consensus comme Polkadot. **
2. Technologies clés
2.1 Cumul OP
OP Rollup garantit la sécurité malgré les problèmes de disponibilité des données et permet l'exécution parallèle de transactions. Voici les étapes de mise en œuvre spécifiques :
L'utilisateur initie une transaction sur L2
Le séquenceur regroupera et traitera par lots, puis synchronisera les données de transaction traitées et la nouvelle racine d'état avec le contrat intelligent déployé sur L1 pour la vérification de sécurité. Il convient de noter que lorsque Sequencer traite une transaction, il génère également sa propre racine d'état et la synchronise avec L1.
Après vérification, L1 renvoie les données et la racine du statut à L2, et le statut de la transaction de l'utilisateur est vérifié et traité en toute sécurité.
À l'heure actuelle, OP Rollup considère la racine d'état générée par Sequencer comme optimiste et correcte. Et une fenêtre de temps sera ouverte pour que le vérificateur puisse contester et vérifier si la racine d'état générée par le séquenceur correspond à la racine d'état de la transaction.
S'il n'y a pas de validateur à vérifier pendant la fenêtre horaire, la transaction sera automatiquement considérée comme correcte. Si une fraude malveillante est vérifiée, le Séquenceur qui traite la transaction sera sanctionné en conséquence.
2.2 Pontage entre chaînes
a) Identique à la messagerie L2
Étant donné que OP Rollup utilise la preuve des erreurs, la transaction doit attendre que le défi soit terminé. Ce processus prend beaucoup de temps et l'expérience utilisateur est faible. Cependant, le ZKP (preuve à connaissance nulle) est coûteux et sujet aux erreurs, et la mise en œuvre du ZKP par lots prendra un certain temps.
**Par conséquent, afin de résoudre le problème de communication entre les hyperchaînes OP L2, OP Stack a proposé une preuve modulaire : en utilisant deux systèmes de preuve pour la même chaîne, les développeurs construisant des piles L2 peuvent choisir librement n'importe quel type de pont. **
Actuellement, le PO fournit :
Les développeurs peuvent choisir l'orientation du pontage en fonction des besoins de leurs propres chaînes. Par exemple, pour les actifs de grande valeur, ils peuvent choisir un pontage de haute sécurité... Des technologies de pontage diversifiées permettent un mouvement efficace des actifs et des données entre différentes chaînes.
b) Transactions inter-chaînes
Les transactions inter-chaînes traditionnelles sont effectuées de manière asynchrone, ce qui signifie que la transaction peut ne pas être entièrement exécutée.
OP Stack a proposé l'idée d'un trieur partagé pour ce type de problème. Par exemple, si un utilisateur souhaite effectuer un arbitrage entre chaînes, alors en partageant le séquenceur sur la chaîne A et la chaîne B, il peut parvenir à un consensus sur le moment de la transaction. Les frais ne seront payés qu'après le téléchargement des transactions sur le chaîne, et les séquenceurs des deux côtés partagent le risque.
c)Transaction par lien hypertexte
Étant donné que la disponibilité des données d'Ethereum L1 n'est pas suffisamment évolutive (la capacité est limitée), il n'est pas évolutif pour publier des transactions sur la super chaîne.
Par conséquent, dans OP Stack, il est proposé d'utiliser le protocole Plasma pour augmenter la quantité de données auxquelles la chaîne OP peut accéder, ce qui peut remplacer DA (disponibilité des données) pour compléter davantage de données L1. La disponibilité des données de transaction est transférée sur la chaîne Plasma et les engagements de données ne sont enregistrés que sur L1, ce qui améliore considérablement l'évolutivité.
4. Pile ZK
1. Cadre structurel
ZK Stack est un ensemble de codes modulaires open source, composables, construits sur la même technologie sous-jacente (ZK Rollup) que zkSync Era, permettant aux développeurs de personnaliser leurs propres hyperliens L2 et L3 pilotés par ZK.
Puisque ZK Stack est gratuit et open source, les développeurs sont libres de personnaliser les hyperliens en fonction de leurs besoins spécifiques. Que vous choisissiez un réseau de couche 2 fonctionnant en parallèle avec zkSync Era, ou un réseau de couche 3 fonctionnant par-dessus, les possibilités de personnalisation seront étendues.
Selon Matter Labs, les créateurs bénéficient d'une autonomie totale pour personnaliser et façonner chaque aspect de la chaîne, du choix d'un modèle de disponibilité des données à l'utilisation du propre système de commande décentralisé de jetons du projet.
Bien entendu, ces hyperchaînes ZK Rollup fonctionnent de manière indépendante, mais s’appuieront uniquement sur Ethereum L1 pour la sécurité et la vérification.
Source : Document zkSync
Comme le montre la figure, chaque lien hypertexte doit utiliser le moteur zkEVM de zkSync L2 pour partager la sécurité. Plusieurs chaînes ZKP fonctionnent simultanément et les preuves de bloc sont regroupées dans la couche de règlement de L1. Comme l'empilement de blocs, elle peut être continuellement étendue pour construire plus de L3, L4...
2. Technologies clés
1）ZK Cumul
La couche inférieure de ZK Stack utilise ZK Rollup comme technologie de base. Voici le processus utilisateur principal :
Les utilisateurs soumettent leurs propres transactions et Sequencer collecte les transactions en lots ordonnés, génère lui-même des certificats de validité (STARK/SNARK) et met à jour le statut. Le statut mis à jour sera soumis au contrat intelligent déployé sur L1 et vérifié. Si la vérification réussit, l'état des actifs de la couche L1 sera également mis à jour. L'avantage de ZK Rollup est qu'il a la capacité d'effectuer une vérification mathématique grâce à une preuve sans connaissance, ce qui est supérieur en termes de technologie et de sécurité.
2) Pont de lien hypertexte
Comme le montre le cadre structurel ci-dessus, ZK Stack peut réaliser une expansion sans fil et générer en continu L3, L 4, etc. Alors, comment parvenir à l’interopérabilité entre les hyperliens ?
**ZK Stack introduit le pont hyperchain. En déployant le contrat intelligent du pont partagé sur L1, il vérifie la preuve Merkle des transactions se produisant sur l'hyperchain. C'est essentiellement la même chose que ZK Rollup, sauf qu'il change par rapport au L2 d'origine. -L1. Devenu de L3-L2. **
ZK Stack prend en charge les contrats intelligents sur chaque hyperchaîne et s'appelle de manière asynchrone entre les chaînes. Les utilisateurs peuvent transférer rapidement leurs actifs de manière sans confiance en quelques minutes sans encourir de coûts supplémentaires. Par exemple, pour traiter un message sur l'hyperlien récepteur B, l'hyperlien expéditeur A doit finaliser son statut jusqu'au premier hyperlien sur lequel A et B sont communs. Ainsi, en pratique, la latence de communication d'Hyperbridge n'est qu'une question de secondes, Hyperchain peut compléter des blocs par seconde et être moins cher.
Source : ocs/reference/concepts/hyperscaling.html#l3s
Non seulement cela, mais comme L3 peut tirer parti de la technologie de compression, la preuve est emballée. L2 élargira encore l'emballage, formant ainsi un facteur de compression plus considérable et un coût inférieur (compression récursive), ce qui permettra d'obtenir des transactions transfrontalières sans confiance, rapides (en quelques minutes) et bon marché (coût de transaction unique).
5. Polygone 2.0
Polygon est une solution spéciale L2, techniquement L1, en tant que chaîne latérale d'Ethereum. L'équipe Polygon a récemment annoncé le plan Polygon 2.0, qui aidera les développeurs à créer leurs propres chaînes ZK L2 à l'aide de ZK et à les unifier via un nouveau protocole de coordination inter-chaînes, donnant aux utilisateurs l'impression que l'ensemble du réseau utilise une seule chaîne.
Polygon 2.0 s'engage à prendre en charge un nombre illimité de chaînes, et les interactions entre chaînes peuvent se produire de manière sécurisée et instantanée sans hypothèses de sécurité ou de confiance supplémentaires, permettant une évolutivité illimitée et une liquidité unifiée.
1. Cadre structurel
Source : Blog Polygone
Polygon 2.0 se compose de 4 couches de protocole :
1) Couche de promesse
La couche de gage est un protocole basé sur PoS (Proof of Stake), qui utilise le gage $MATIC pour parvenir à une gouvernance décentralisée afin de gérer efficacement les validateurs et d'améliorer l'efficacité des mineurs.
Comme le montre la figure, Polygon 2.0 propose un gestionnaire de validateur et un gestionnaire de chaîne au niveau de la couche d'engagement.
La couche de jalonnement a déjà formulé la structure sous-jacente des règles correspondantes pour chaque chaîne, et les développeurs n'ont qu'à se concentrer sur le développement de leurs propres chaînes.
Source : Blog Polygone
2) Couche d'interopérabilité
Les protocoles inter-chaînes sont essentiels à l'interopérabilité de l'ensemble du réseau. La manière d'effectuer des messages inter-chaînes en toute sécurité et de manière transparente est quelque chose que chaque solution d'hyperlien devrait continuer à améliorer.
Actuellement, Polygon utilise deux contrats, l'agrégateur et la file d'attente de messages, pour la prise en charge.
Une fois que la preuve ZK est acceptée par l'agrégateur, la chaîne de réception peut commencer à accepter les messages de manière optimiste, car la chaîne de réception croit toutes à la preuve ZK, permettant ainsi une livraison transparente des messages, etc.
3) Couche d'exécution
La couche d'exécution permet à n'importe quelle chaîne Polygon de générer des lots de transactions ordonnées, également appelées blocs. La plupart des réseaux blockchain (Ethereum, Bitcoin, etc.) l'utilisent dans un format similaire.
La couche d'exécution comporte plusieurs composants, tels que :
Étant donné que cette couche est banalisée mais relativement complexe à mettre en œuvre, les implémentations hautes performances existantes (telles qu'Erigon) doivent être réutilisées lorsque cela est possible.
4) Couche de preuve
La couche de preuve génère des preuves pour chaque polygone. Il s'agit d'un protocole de preuve ZK flexible et performant qui comprend généralement les composants suivants :
2. Technologies clés
Source : Blog Polygone
1) Validium zkEVM
Dans la mise à jour Polygon 2.0, l'équipe l'a mis à niveau vers zkEVM validium tout en conservant le Polygon POS d'origine.
Source : Blog Polygone
D'après la simple science populaire, Validium et Rollup sont tous deux des solutions de couche 2, et leur objectif est d'étendre la capacité de transaction d'Ethereum et de raccourcir le temps de transaction. Comparez les deux :
On peut comprendre que Validium est un Rollup avec un coût inférieur et une plus grande évolutivité. Cependant, le principe de fonctionnement de Polygon zkEVM (mécanisme Polygon POS) avant la mise à niveau était (ZK) Rollup, et il a également obtenu des résultats considérables. En seulement 4 mois depuis son lancement, sa TVL a grimpé à 33 millions de dollars.
Source : Défilama
À long terme, le coût de génération de preuves pour zkEVM basées sur Polygon PoS pourrait devenir un obstacle à une expansion future. Bien que l'équipe de Polygon ait travaillé dur pour réduire le coût de Batch, celui-ci a été réduit à un chiffre extrêmement impressionnant : prouvant que le coût de 10 millions de transactions n'est que de 0,0259 $. Mais le Vailidium coûte moins cher, alors pourquoi ne pas l’utiliser ?
Polygon a officiellement publié des documents. Dans les versions futures, ** Validium prendra en charge le travail précédent du point de vente tout en conservant également le point de vente. Le rôle principal de son vérificateur de point de vente est d'assurer la disponibilité des données et de trier les transactions. **
Le zkEVM Validium mis à niveau offrira une très grande évolutivité et un coût très faible. Parce qu'il est très adapté aux applications avec un volume de transactions important et de faibles frais de transaction, telles que Gamefi, Socialfi et DeFi, etc. Pour les développeurs, aucune opération n'est requise, il leur suffit de mettre à jour avec le réseau principal pour terminer la mise à jour de Validium.
2) Cumul zkEVM
Actuellement, Polygon PoS (bientôt mis à niveau vers Polygon Validium) et Polygon zkEVM Rollup sont les deux réseaux publics de l'écosystème Polygon. Cela reste le cas après la mise à niveau, avec l'avantage supplémentaire que les deux réseaux utilisent la technologie de pointe zkEVM, l'un comme agrégation et l'autre comme vérification.
Polygon zkEVM Rollup offre déjà le plus haut niveau de sécurité, mais au prix d'un coût légèrement plus élevé et d'un débit limité. Cependant, il est bien adapté aux applications qui gèrent des transactions de grande valeur et donnent la priorité à la sécurité, telles que les DeFi Dapps de grande valeur.
六. Décision d'orbite
Arbitrum est actuellement la chaîne publique L2 la plus importante. Depuis son lancement en août 2021, sa TVL a dépassé les 5,1 milliards de dollars et, en tant que première L2, elle occupe près de 54 % de part de marché.
Arbitrum a sorti la version Orbit en mars de cette année. Avant cela, Arbitrum avait lancé une série de produits écologiques :
Aujourd'hui, nous nous concentrerons sur Arbitrum Orbit.
1. Cadre structurel
À l'origine, si les développeurs voulaient utiliser Arbitrum Orbit pour créer un réseau L2, ils publieraient d'abord une proposition, qui serait votée par l'Arbitrum DAO. Si elle était adoptée, une nouvelle chaîne L2 serait créée. Cependant, aucune autorisation n'est requise pour développer L3, 4, 5... sur L2. N'importe qui peut fournir un framework sans autorisation pour déployer des chaînes personnalisées sur Arbitrum L2.
Source : Livre blanc
Comme vous pouvez le constater, Arbitrum Orbit s'efforce également de permettre aux développeurs de personnaliser leur propre chaîne Oribit L3 basée sur la couche 2, comme Arbitrum One, Arbitrum Nova ou Arbitrum Goerli. Les développeurs peuvent personnaliser l'accord de confidentialité, la licence, le modèle économique des jetons, la gestion de la communauté, etc. de cette chaîne, donnant ainsi la plus grande autonomie aux développeurs.
Parmi eux, il convient de noter qu'Oribit permet à la chaîne L3 d'utiliser le jeton de cette chaîne comme unité de règlement des frais, développant ainsi efficacement son propre réseau.
2. Technologies clés
1）Regrouper AnyTrust
Ces deux protocoles prennent respectivement en charge Arbitrum One et Arbitrum Nova. Comme présenté précédemment, Arbitrum One est un cumul de réseau principal principal ; Arbitrum Nova est le deuxième cumul de réseau principal, mais il est connecté au protocole AnyTrust. Il peut être introduit en introduisant "la sécurité hypothèses » ( Trust Assumption) pour accélérer le règlement et réduire les coûts.
Parmi eux, Arbitrum Rollup est un OP Rollup, donc sans autre explication, nous procéderons à une analyse détaillée du protocole AnyTrust.
Le protocole AnyTrust gère principalement la disponibilité des données et est approuvé par une série d'organismes tiers tels que le DAC (Data Availability Committee). Et en introduisant des « hypothèses de sécurité », les coûts de transaction sont considérablement réduits. La chaîne AnyTrust fonctionne sur Arbitrum One en tant que sidechain, avec des coûts inférieurs et des vitesses de transaction plus rapides.
Alors, qu’est-ce qu’une « hypothèse de confiance » ? Pourquoi son existence réduit-elle les coûts de transaction et nécessite-t-elle moins de confiance ?
Selon la documentation officielle d'Arbitrum, la chaîne AnyTrust est gérée par un comité de nœuds et utilise des hypothèses minimales pour déterminer combien de membres du comité sont honnêtes. Par exemple, disons que le comité est composé de 20 personnes et que l'on suppose qu'au moins 2 membres sont honnêtes. Comparé à BFT qui exige que les ⅔ membres soient honnêtes, AnyTrust abaisse le seuil de confiance au minimum.
Dans une transaction, puisque le comité promet de fournir les données de transaction, le nœud n'a pas besoin d'enregistrer toutes les données de la transaction L2 sur L1, mais doit seulement enregistrer la valeur de hachage du lot de transactions, ce qui peut considérablement réduire les coûts. du cumul. . C'est pourquoi la chaîne AnyTrust peut réduire les coûts de transaction.
Concernant la question de la confiance, comme mentionné précédemment, on suppose que seuls 2 des 20 membres sont honnêtes, et cette hypothèse est vraie. Tant que 19 des 20 membres du comité s’engagent à garantir l’exactitude de l’accord, il peut être exécuté en toute sécurité. Alors même si le membre qui n’a pas signé est honnête, l’un des 19 membres qui ont signé doit être honnête.
Que devons-nous faire si les membres ne signent pas ou si un grand nombre de membres refusent de coopérer, ce qui entraîne un dysfonctionnement du système ? La chaîne AnyTrust peut toujours fonctionner, mais elle reviendra au protocole Rollup d'origine et les données sont toujours publiées sur Ethereum L1. Lorsque le comité fonctionnera correctement, la chaîne reviendra à un mode moins cher et plus rapide.
Aribtrum a lancé ce protocole dans l'espoir de répondre aux besoins d'applications nécessitant une vitesse de traitement élevée et un faible coût, comme le domaine Gamefi.
2）Nitro
Nitro est la dernière version de la technologie Arbitrum. Son élément principal est le Prover, qui effectue une preuve interactive traditionnelle de fraude sur Arbitrum via le code WASM. Et tous ses composants sont complets. Arbitrum a terminé la mise à niveau fin août 2022, migrant/mettant à niveau de manière transparente l'Arbitrum One existant vers Aribitrum Nitro.
Nitro a les fonctionnalités suivantes :
Ces fonctionnalités d'Oribit fournissent un support technique pour les cas d'utilisation d'Arbitrum L3 et L 4. Arbitrum peut attirer les développeurs qui recherchent une personnalisation pour créer leurs propres chaînes personnalisées.
七. Pile Starknet
Le cofondateur de StarkWare, Eli Ben-Sasson, a déclaré lors de la conférence EthCC à Paris que Starknet lancerait bientôt Starknet Stack, permettant à toute application de déployer sa propre chaîne d'applications Starknet sans autorisation.
Des technologies clés telles que la preuve STARK dans Starknet, le langage de programmation Cairo et l'abstraction de compte natif offrent une garantie de puissance pour le développement rapide de Starknet. Lorsque les développeurs utilisent Stack pour personnaliser leur propre chaîne d'applications Starknet, celle-ci est évolutive et librement configurable, ce qui peut considérablement augmenter le débit du réseau et atténuer la congestion du réseau principal.
Bien que Starknet ne soit pour l’instant qu’une idée préliminaire, les documents techniques officiels n’ont pas encore été publiés. Cependant, Madara Sequencer et LambdaClass sont développés respectivement en tant que composants Sequencer et Stack compatibles Starknet pour mieux s'adapter à Starknet. Les responsables travaillent également dur sur la prochaine pile Starknet, notamment en développant des nœuds/moteurs d'exécution/vérification complets et d'autres composants.
Il convient de noter qu'il n'y a pas si longtemps, StarkNet a soumis une proposition de « protocole décentralisé simple », dans l'espoir de changer le statut actuel du séquenceur d'opération monopoint actuel de L2. Ethereum est décentralisé, mais pas L2, et ses revenus MEV rendent Sequencer mauvais.
StarkNet a répertorié certaines solutions dans la proposition telles que :
En outre, il existe des plans pour la certification ZK, les mises à jour du statut L1, etc., combinées à l'initiative majeure précédente visant à aider la communauté à exploiter le code Prover sans autorisation, la proposition de StarkNet cherche à résoudre le manque de décentralisation de L2 et à essayer d'équilibrer les incohérence de la blockchain. Peut-être que le problème triangulaire est vraiment perceptible.
Source : ressource/the-starknet-stacks-growth-spurt/
8. Conclusion
Dans ce chapitre, à travers l'explication technique du CP et des principales piles de couche 2, nous pouvons effectivement constater que la solution actuelle de pile de couche 2 peut résoudre efficacement le problème d'expansion d'Ethereum, mais elle apporte également une série de défis et de problèmes, notamment en termes de compatibilité.Sexuellement. La technologie de la solution Stack des L2 n'est pas aussi mature que celle du CP. Même le concept technique du CP il y a trois ou quatre ans mérite encore d'être appris des L2 actuels. Donc au niveau technique, le CP actuel est encore bien supérieur à la couche 2. Cependant, la technologie avancée à elle seule ne suffit pas. Dans le deuxième article suivant, nous discuterons des avantages, des inconvénients et des caractéristiques respectifs des piles CP et L2 du point de vue de la valeur symbolique et du développement écologique afin d'améliorer les perspectives des lecteurs.
Les références:
/@éternel1 997 L
/réseau-polkadot/un-bref-résumé-de-tout-le-substrat-et-polkadot-f1f21071499d
ocs/reference/concepts/hyperscaling.html#what-are-hyperchains
/offchainlabs