Auteur : Lisa A., Taiko Labs ; traduction : Jinse Finance xiaozou
Cet article abordera différentes méthodes de messagerie inter-chaînes L2 du point de vue du cumul, en se concentrant sur la communication inter-chaînes sans confiance. Nous examinerons brièvement l'approche de lecture d'état directe, l'approche client léger et la preuve de stockage. Nous couvrirons également le mécanisme d'agrégation de preuves, la transmission de messages inter-chaînes tiers de confiance et les solutions inter-chaînes ZK de base. Enfin, regardons comment différents L2 implémentent aujourd'hui la messagerie inter-chaînes.
1. Introduction à la messagerie inter-chaînes
Pour la communication inter-chaînes, toutes les parties (L2, L3, etc.) doivent avoir un accès direct à la dernière racine d'état Ethereum.
Toutes les couches de dépôt ont un mécanisme inter-chaîne "intégré" qui peut être utilisé pour accéder à la racine d'état L1, qui sera transmise à L2 en tant que message de dépôt.
1**.1** Deux types d'accès à la racine d'état
Type 1 : Lire directement la racine de l'état - peut être effectué via un opcode ou précompilé. Cependant, il n'a pas été mis en œuvre jusqu'à présent, donc aucune preuve n'est requise.
Brecht Devos décrit une méthode possible de lecture directe de l'état dans un document de recherche : "... nous pouvons exposer un contrat précompilé qui peut appeler directement un contrat intelligent sur la chaîne cible. Ce précompilé directement dans la chaîne source insère et exécute le code de contrat intelligent d'une autre chaîne. Cela garantit que les contrats intelligents ont toujours accès au dernier état disponible de manière efficace et facilement vérifiable.
· Également décrit dans l'appel d'offres d'Optimism "Remote Static Invocation Proof of Concept".
Type 2 : Proof Generation - c'est-à-dire prouver une affirmation concernant une blockchain sur une autre blockchain.
La "messagerie inter-chaînes avec preuves" a deux approches :
· Communication inter-chaînes sans confiance, c'est-à-dire sans tiers de confiance (par exemple, en utilisant des clients légers ou une preuve de stockage). L'approche sans confiance peut être utilisée à la fois pour la génération de preuves par des tiers et pour que les participants à la communication inter-chaînes génèrent eux-mêmes des preuves.
Les preuves sont partagées entre différents rollups pour assurer les opérations inter-chaînes. Cette approche, peu abordée dans cet article, est actuellement en phase de recherche et d'exploration et n'est pas considérée comme une solution potentiellement applicable à grande échelle.
1**.2** Méthode « Messagerie inter-chaînes avec preuve »
1.2.1Messagerie cross-chain client léger
Prouver les données sur la chaîne B
Obtenir les données de preuve Merkle du nœud complet de la chaîne B (nœud d'archivage d'archives si une preuve de stockage pour certains états historiques est requise) ;
Envoyez l'en-tête de bloc et les données de preuve correspondant au bloc de la chaîne B contenant l'état que nous voulons vérifier au contrat de preuve sur la chaîne A en tant que données d'appel ;
Le contrat de preuve calcule la valeur de hachage de bloc en fonction des données d'en-tête de bloc, interroge le contrat intelligent du client léger sur la chaîne A (suit la valeur de hachage de bloc de la chaîne B) et vérifie si la valeur de hachage est valide ;
Les données de preuve sont vérifiées par rapport à la racine d'état bytes32 dans l'en-tête de bloc.
1**.2.2** Preuve de stockage
La preuve de stockage a deux options de « workflow » :
· Générer une preuve de stockage → utiliser en chaîne
· Générer une preuve de stockage → générer une preuve zk → utiliser sur la chaîne
Il est également possible pour une entité de regrouper plusieurs collections de preuves en une seule preuve (à la fois la preuve de stockage et la preuve de zk). Il s'agit d'une étape d'optimisation facultative et n'est pas encore abordée.
Examinons les trois étapes principales du "workflow" de la preuve de stockage : générer la preuve de stockage, générer la preuve zk et l'utiliser sur la chaîne.
(1) Générer une preuve de stockage
· La preuve de stockage nous permet d'utiliser un engagement confidentiel pour prouver que certaines informations existent sur la blockchain et sont vraies ;
La preuve de stockage fait partie de l'espace cryptographique depuis l'avènement des arbres Merkle en 1979. Cependant, les preuves de stockage à la vanille sont généralement assez volumineuses. L'innovation moderne consiste à combiner la preuve de stockage avec un calcul prouvable pour créer des preuves succinctes qui peuvent être vérifiées en chaîne.
Pour générer une preuve de stockage, un bloc de données spécifique et son chemin Merkle ou Verkle associé dans une arborescence Merkle doivent être fournis. Le chemin se compose des hachages frères nécessaires pour reconstruire le hachage racine en utilisant le même algorithme de hachage.
Pour vérifier une preuve de stockage, le destinataire peut utiliser les données fournies et le chemin Merkle ou Verkle pour recalculer le hachage racine. Si le hachage racine recalculé correspond à un hachage racine connu, le destinataire peut être sûr que les données sont authentiques et font partie de l'ensemble de données soumis.
(2) Générer ZKP (preuve sans connaissance)
Cependant, une preuve de stockage de type Ethereum est d'environ 4 Ko - plutôt grande pour publier l'intégralité de la preuve de stockage sur la chaîne cible, car la vérification de la preuve serait très coûteuse. Par conséquent, il est raisonnable d'utiliser ZKP (par exemple, ZK-SNARK) pour la compression, ce qui peut rendre la preuve plus petite et moins chère à vérifier.
（3）A****rouleauZKP
Après avoir gagné des ZKP, les utilisateurs de la chaîne cible peuvent dérouler leurs preuves gagnées (par exemple, accéder à l'état historique via des en-têtes de bloc ou des hachages de bloc).
Le déroulage peut se faire comme suit :
** Accumulation en chaîne : ** L'ensemble du processus de reconstruction des en-têtes de bloc à partir des preuves est effectué directement sur la blockchain. Inconvénients : frais de gaz élevés, consomme des ressources informatiques ; avantages : pas de temps de preuve supplémentaire, faible latence, car il n'est pas nécessaire de générer des preuves en dehors de la blockchain.
Compression en chaîne : Supprimez les informations redondantes ou inutiles des données, ou utilisez des structures de données optimisées pour l'efficacité de l'espace. Les données compressées sont envoyées à la blockchain et peuvent être décompressées si nécessaire. Inconvénients : la compression et la décompression des données peuvent entraîner des calculs supplémentaires, mais cette latence peut être négligeable. L'algorithme de compression utilisé peut avoir un impact négatif sur la sécurité des données ; avantage : réduire les coûts de données.
Stockage hors chaîne : stockez les données hors chaîne et placez des blocs de données spécifiques en chaîne à la demande. Ceci est pertinent pour les solutions qui doivent stocker de grandes quantités de données pour une raison quelconque (par exemple, les nœuds d'archives Ethereum du bloc de genèse). Inconvénients : Identique à la compression en chaîne ; Avantages : Réduit davantage les coûts de données.
1**.2.3** Tiers de confiance
Une solution inter-chaînes complète devrait également impliquer des solutions de messagerie croisée avec des tiers de confiance (tels que des oracles, des ponts centralisés, etc.).
1**.2.4** Système de preuve "universel"
Dans le cas d'un mécanisme de plate-forme partagée de preuve d'agrégation, la messagerie peut être accélérée en recevant des hachages de bloc qui sont réglés au sein de la plate-forme d'agrégation, et le règlement ici gérera également la messagerie (mais s'il y a un problème avec la plate-forme d'agrégation ce qu'il faut faire?).
1**.2.5 Certains problèmes inconnus de la messagerie inter-chaînes ZK******
La messagerie inter-chaînes est-elle réalisable sans un tiers de confiance (qui peut être une seule entité ou plusieurs entités) ? Qu'est-ce qu'un mécanisme efficace pour la transmission de messages inter-chaînes ? En général, pour Ethereum L2 (avec accès direct aux hachages de bloc de L1) et Ethereum lui-même, si une chaîne peut exécuter un client léger, etc., ce qui est suffisant pour la messagerie inter-chaînes sans confiance.
Le circuit ZK utilisé pour la génération de preuve de chaîne croisée est-il correctement mis à l'échelle ? Dans certains cas, en particulier lorsque la couche de consensus (qui doit être vérifiée pour les opérations inter-chaînes) est très grande, le circuit utilisé pour le passage des messages inter-chaînes ZK peut être d'un ordre de grandeur plus grand que le cumul et le stockage en chaîne, et la surcharge de calcul est également très importante. Vraisemblablement, ce problème peut être surmonté avec une approche plus centralisée.
2**、Exemple de solution de messagerie inter-chaînes**
· Su****ccinct Labs utilise un client léger pour vérifier le consensus de la chaîne source à la couche de consensus de la chaîne cible. L'idée est qu'il existe un protocole client léger pour s'assurer que les nœuds peuvent synchroniser les en-têtes de bloc de l'état final de la blockchain. ZKP est utilisé pour générer des preuves de consensus.
· La****grange Labs construit une preuve d'état inter-chaîne non interactive. Lagrange prouve que le réseau est responsable de la création de la racine d'état. Chaque nœud Lagrange contient une partie de la clé privée d'un fragment, qui atteste de l'état d'une chaîne particulière. Chaque racine d'état est un seuil signé racine Verkle qui peut être utilisé pour attester de l'état d'une chaîne particulière à un moment donné. La racine d'état est complètement générale et peut être utilisée dans une preuve d'état pour prouver l'état actuel de n'importe quel contrat ou portefeuille de la chaîne.
· He****rodotus utilise la preuve de stockage ZKP pour fournir des contrats intelligents et accéder aux données sur la chaîne des autres couches Ethereum de manière synchrone. Pour la validation, il utilise la messagerie native L1<>L2 pour synchroniser les hachages de bloc entre les cumuls Ethereum.
=nil ; Foundation (Mina, L1) permet aux contrats intelligents sur Ethereum de vérifier la validité de l'état Mina. Générer des preuves d'état à usage spécial, peu coûteuses à vérifier sur Ethereum (les preuves Mina locales sur Ethereum sont chères). Hypothétiquement (dans le futur), les applications peuvent utiliser directement l'outil de génération de preuves de Mina pour vérifier la validité des transactions inter-chaînes. = néant ; Foundation dispose également d'un Proof Market où les utilisateurs/projets peuvent principalement acheter/vendre des preuves SNARK qui permettent un accès aux données sans confiance.
Axiom : Si Axiom a généré un ZKP pour le registre jusqu'à présent - il n'a pas besoin de générer un ZKP pour un bloc spécifique - il peut transmettre ce ZKP à la chaîne (en tant que relais), ou même Fournit l'accès à ce ZKP.
3. Messagerie inter-chaînes L2
*Avis de non-responsabilité : la messagerie inter-chaînes continue d'évoluer pour la majeure partie de la L2. Toutes les analyses ci-dessous sont basées sur des informations open source. Cela dit, les solutions mentionnées dans l'article peuvent être en phase d'exploration et de test, et le cumul peut éventuellement adopter d'autres méthodes. *
**（1）**Taiko
Taiko stocke les hachages de bloc pour chaque chaîne. Pour chaque paire de chaînes, il déploie deux contrats intelligents qui stockent les hachages de l'autre. Dans l'exemple de L2←→L1, chaque fois qu'un bloc L2 est créé sur Taiko, les valeurs de hachage des blocs périphériques sur L1 sont stockées dans le contrat TaikoL2. Également dans le cas de L1←→L2, le mode de fonctionnement est le même.
La dernière racine Merkle connue stockée sur la chaîne cible peut être obtenue en appelant getCrossChainBlockHash(0) sur le contrat TaikoL1/TaikoL2 et obtenir la valeur/le message à vérifier. Le hachage frère de la dernière racine Merkle connue peut être obtenu en appelant la requête eth_getProof à l'aide d'un RPC standard sur la "chaîne source".
Ensuite, envoyez-les simplement pour qu'ils soient vérifiés par rapport aux derniers hachages de blocs connus stockés dans une liste sur la "chaîne cible". Le validateur prendra une valeur (une feuille sur l'arbre Merkle) et des hachages frères pour recalculer la racine Merkle et vérifier qu'elle correspond à la racine stockée dans la liste des hachages de bloc de la chaîne cible.
**（2）**Starknet
Starknet utilise la preuve de stockage pour la messagerie inter-chaînes sans confiance.
Protocole de messagerie L2→L1
· Lors de l'exécution d'une transaction Starknet, un contrat sur Starknet envoie un message L2→L1.
Les paramètres du message (contenant le contrat du récepteur et les données associées sur L1) sont ensuite ajoutés à la mise à jour d'état pertinente (arbre de stockage principal).
· Les messages L2 sont stockés sur L1 du contrat intelligent.
· Émettre un événement sur L1 (stocker les paramètres du message).
Les adresses de destinataire sur L1 peuvent accéder au message et l'utiliser dans le cadre d'une transaction L1 en fournissant à nouveau des paramètres de message.
· Les messages inter-chaînes sont stockés dans l'arborescence du tronc.
L2 → L1
L1 → L2
**（3）**Optimisme
La communication entre L1 et L2 est mise en œuvre par deux contrats intelligents spéciaux appelés "messagers".
· Pour les transactions Optimism (L2) vers Ethereum (L1), il est nécessaire de fournir une preuve Merkle du message sur L1 après l'écriture de la racine d'état. Une fois que cette transaction de preuve fait partie de la chaîne L1, la période de défi d'erreur commence. Après cette période d'attente, tout utilisateur peut "finaliser" la transaction en déclenchant une deuxième transaction sur Ethereum, en envoyant un message au contrat L1 cible.
· Les messages inter-chaînes sont stockés dans l'arborescence du tronc.
（4）Ar****bitrum
Les tickets réessayables sont la méthode canonique utilisée par Arbitrum pour créer la messagerie L1 à L2, c'est-à-dire les transactions L1 qui initialisent les messages à exécuter sur L2. Un réessayable peut être soumis sur L1 moyennant des frais fixes (en fonction uniquement de la taille de ses données d'appel). L'arbre d'état principal est utilisé pour la communication inter-chaînes des formats de données personnalisés dans les contrats intelligents. La soumission d'un ticket réessayable sur L1 est séparable/asynchrone de l'exécution sur L2. Les réessayables fournissent l'atomicité entre les opérations inter-chaînes. Si la demande de transaction L1 est soumise avec succès (c'est-à-dire sans restauration), l'exécution réessayable sur L2 a une forte garantie qu'elle finira par réussir.
Arbitrum a deux troncs : La chaîne Nitro est maintenue dans le format d'arbre d'état d'Ethereum, un arbre Merkle. L'Assertion Tree stocke l'état de la chaîne Arbitrum confirmé sur Ethereum via "assertion". Les règles qui font avancer la chaîne Arbitrum sont déterministes. Cela signifie qu'étant donné l'état d'une chaîne et certaines nouvelles valeurs d'entrée, il n'y a qu'une seule sortie valide. Par conséquent, si l'arbre de preuve contient plusieurs feuilles, au plus une feuille peut représenter un état de chaîne valide.
Le système de boîte d'envoi d'Arbitrum autorise tout appel de contrat de L2 à L1, c'est-à-dire qu'un message est initié à partir de L2 et finalement exécuté sur L1. Les messages L2 à L1 (alias "messages sortants") ont beaucoup en commun avec les messages L1 à L2 d'Arbitrum (Réessayable), bien qu'il existe quelques différences notables. Une partie de l'état L2 d'une chaîne Arbitrum, c'est-à-dire la partie attestée dans chaque RBlock, est la racine Merkle de tous les messages L2 à L1 dans l'historique de la chaîne. Une fois le RBlock éprouvé confirmé (généralement environ une semaine après la preuve), la racine Merkle est incluse dans le contrat Outbox et publiée sur L1. Le contrat Boîte d'envoi permet ensuite aux utilisateurs d'exécuter leurs messages.
**（5）**Polygone zkEVM
· Le Bridge SC de ce zkEVM utilise un arbre Merkle spécial appelé Exit Tree pour chaque réseau participant à la communication ou à la transaction d'actifs.
Il utilise les racines Merkle (dans un arbre d'état séparé), un diagramme d'architecture de pont peut être trouvé sur github.
Le déploiement de zkEVM Bridge SC a apporté plusieurs modifications basées sur le contrat de dépôt Ethereum 2.0. Par exemple, il utilise un arbre Merkle spécialement conçu pour l'ajout uniquement, mais utilise la même logique que le contrat de dépôt Ethereum 2.0. D'autres différences concernent les hachages de base et les nœuds feuilles.
La principale caractéristique du contrat intelligent Polygon zkEVM Bridge est l'utilisation de l'arbre de sortie et de l'arbre de sortie global, où la racine de l'arbre de sortie global est la principale source de l'état de vérité. Par conséquent, L1 et L2 ont deux gestionnaires racine de sortie globaux différents et Bridge SC a une logique distincte.
（6）S****défilement
· Les contrats de pont déployés sur Ethereum et Scroll permettent aux utilisateurs de transmettre des messages arbitraires entre L1 et L2. En plus de ce protocole de messagerie, nous avons également construit un protocole de pontage sans confiance pour permettre aux utilisateurs de relier les actifs ERC-20 entre L1 et L2. Pour envoyer un message ou des fonds d'Ethereum à Scroll, un utilisateur appelle la transaction sendMessage sur le contrat Bridge. Les relais indexeront cette transaction sur L1 et l'enverront au donneur d'ordre pour inclusion dans les blocs L2. Sur le contrat de pont L2, le processus d'envoi d'un message de Scroll vers Ethereum est similaire.
· Les messages inter-chaînes sont stockés dans des files d'attente de messages ordinaires. Le trieur ingère les messages inter-chaînes de cette file d'attente et les ajoute à la chaîne en tant que transactions régulières.
**（7）**ère zksync
Avis de non-responsabilité : le contenu de cette section concerne uniquement zksync Era, qui peut être différent de la messagerie inter-chaînes sur ZK Stack, qui est un cadre modulaire pour la construction d'une superchaîne ZK souveraine. *
· Chaque paquet de transaction a un seul message L2->L1.
· Il n'est pas possible d'envoyer des transactions directement de L2 à L1. Cependant, vous pouvez envoyer des messages de n'importe quelle longueur de zkSync Era à Ethereum, puis traiter les messages reçus sur Ethereum à l'aide du contrat intelligent L1. zkSync Era a une fonction de preuve de demande qui renverra un paramètre booléen indiquant si le message a été envoyé avec succès à L1. Récupérez la preuve Merkle contenue dans le message en observant Ethereum ou en utilisant la méthode zks_getL2ToL1LogProof de l'API zksync-web3.
· Pour L1→L2, le contrat intelligent zkSync Era permet à l'expéditeur de demander une transaction sur Ethereum L1 et de transmettre les données à zkSync Era L2.
· Contrat relais :
4. Conclusion
La communication inter-chaînes fait partie intégrante des applications "indispensables" pour l'adoption massive de la blockchain (par exemple, le portefeuille de récupération sociale inter-chaînes décrit dans l'article Vitalik). La plupart des solutions inter-chaînes actuellement utilisées sont conçues pour L1←→L2 pour couvrir la fonction de retrait. Ces solutions peuvent être étendues à davantage de blockchains. Mais en même temps, des solutions de communication inter-chaînes plus avancées peuvent être mises en œuvre, telles que "l'état de lecture directe" sans preuve du tout ou "la preuve de stockage" sans confiance. Pour la plupart des L2, il y a encore place à l'amélioration de la communication inter-chaînes.
Voir l'original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Explorer la communication inter-chaînes du point de vue du cumul
Auteur : Lisa A., Taiko Labs ; traduction : Jinse Finance xiaozou
Cet article abordera différentes méthodes de messagerie inter-chaînes L2 du point de vue du cumul, en se concentrant sur la communication inter-chaînes sans confiance. Nous examinerons brièvement l'approche de lecture d'état directe, l'approche client léger et la preuve de stockage. Nous couvrirons également le mécanisme d'agrégation de preuves, la transmission de messages inter-chaînes tiers de confiance et les solutions inter-chaînes ZK de base. Enfin, regardons comment différents L2 implémentent aujourd'hui la messagerie inter-chaînes.
1. Introduction à la messagerie inter-chaînes
Pour la communication inter-chaînes, toutes les parties (L2, L3, etc.) doivent avoir un accès direct à la dernière racine d'état Ethereum.
Toutes les couches de dépôt ont un mécanisme inter-chaîne "intégré" qui peut être utilisé pour accéder à la racine d'état L1, qui sera transmise à L2 en tant que message de dépôt.
1**.1** Deux types d'accès à la racine d'état
Type 1 : Lire directement la racine de l'état - peut être effectué via un opcode ou précompilé. Cependant, il n'a pas été mis en œuvre jusqu'à présent, donc aucune preuve n'est requise.
Brecht Devos décrit une méthode possible de lecture directe de l'état dans un document de recherche : "... nous pouvons exposer un contrat précompilé qui peut appeler directement un contrat intelligent sur la chaîne cible. Ce précompilé directement dans la chaîne source insère et exécute le code de contrat intelligent d'une autre chaîne. Cela garantit que les contrats intelligents ont toujours accès au dernier état disponible de manière efficace et facilement vérifiable.
· Également décrit dans l'appel d'offres d'Optimism "Remote Static Invocation Proof of Concept".
Type 2 : Proof Generation - c'est-à-dire prouver une affirmation concernant une blockchain sur une autre blockchain.
La "messagerie inter-chaînes avec preuves" a deux approches :
· Communication inter-chaînes sans confiance, c'est-à-dire sans tiers de confiance (par exemple, en utilisant des clients légers ou une preuve de stockage). L'approche sans confiance peut être utilisée à la fois pour la génération de preuves par des tiers et pour que les participants à la communication inter-chaînes génèrent eux-mêmes des preuves.
Les preuves sont partagées entre différents rollups pour assurer les opérations inter-chaînes. Cette approche, peu abordée dans cet article, est actuellement en phase de recherche et d'exploration et n'est pas considérée comme une solution potentiellement applicable à grande échelle.
1**.2** Méthode « Messagerie inter-chaînes avec preuve »
1.2.1 Messagerie cross-chain client léger
Prouver les données sur la chaîne B
Obtenir les données de preuve Merkle du nœud complet de la chaîne B (nœud d'archivage d'archives si une preuve de stockage pour certains états historiques est requise) ;
Envoyez l'en-tête de bloc et les données de preuve correspondant au bloc de la chaîne B contenant l'état que nous voulons vérifier au contrat de preuve sur la chaîne A en tant que données d'appel ;
Le contrat de preuve calcule la valeur de hachage de bloc en fonction des données d'en-tête de bloc, interroge le contrat intelligent du client léger sur la chaîne A (suit la valeur de hachage de bloc de la chaîne B) et vérifie si la valeur de hachage est valide ;
Les données de preuve sont vérifiées par rapport à la racine d'état bytes32 dans l'en-tête de bloc.
1**.2.2** Preuve de stockage
La preuve de stockage a deux options de « workflow » :
· Générer une preuve de stockage → utiliser en chaîne
· Générer une preuve de stockage → générer une preuve zk → utiliser sur la chaîne
Il est également possible pour une entité de regrouper plusieurs collections de preuves en une seule preuve (à la fois la preuve de stockage et la preuve de zk). Il s'agit d'une étape d'optimisation facultative et n'est pas encore abordée.
Examinons les trois étapes principales du "workflow" de la preuve de stockage : générer la preuve de stockage, générer la preuve zk et l'utiliser sur la chaîne.
(1) Générer une preuve de stockage
· La preuve de stockage nous permet d'utiliser un engagement confidentiel pour prouver que certaines informations existent sur la blockchain et sont vraies ;
La preuve de stockage fait partie de l'espace cryptographique depuis l'avènement des arbres Merkle en 1979. Cependant, les preuves de stockage à la vanille sont généralement assez volumineuses. L'innovation moderne consiste à combiner la preuve de stockage avec un calcul prouvable pour créer des preuves succinctes qui peuvent être vérifiées en chaîne.
Pour générer une preuve de stockage, un bloc de données spécifique et son chemin Merkle ou Verkle associé dans une arborescence Merkle doivent être fournis. Le chemin se compose des hachages frères nécessaires pour reconstruire le hachage racine en utilisant le même algorithme de hachage.
Pour vérifier une preuve de stockage, le destinataire peut utiliser les données fournies et le chemin Merkle ou Verkle pour recalculer le hachage racine. Si le hachage racine recalculé correspond à un hachage racine connu, le destinataire peut être sûr que les données sont authentiques et font partie de l'ensemble de données soumis.
(2) Générer ZKP (preuve sans connaissance)
Cependant, une preuve de stockage de type Ethereum est d'environ 4 Ko - plutôt grande pour publier l'intégralité de la preuve de stockage sur la chaîne cible, car la vérification de la preuve serait très coûteuse. Par conséquent, il est raisonnable d'utiliser ZKP (par exemple, ZK-SNARK) pour la compression, ce qui peut rendre la preuve plus petite et moins chère à vérifier.
（3）A****rouleau ZKP
Après avoir gagné des ZKP, les utilisateurs de la chaîne cible peuvent dérouler leurs preuves gagnées (par exemple, accéder à l'état historique via des en-têtes de bloc ou des hachages de bloc).
Le déroulage peut se faire comme suit :
** Accumulation en chaîne : ** L'ensemble du processus de reconstruction des en-têtes de bloc à partir des preuves est effectué directement sur la blockchain. Inconvénients : frais de gaz élevés, consomme des ressources informatiques ; avantages : pas de temps de preuve supplémentaire, faible latence, car il n'est pas nécessaire de générer des preuves en dehors de la blockchain.
Compression en chaîne : Supprimez les informations redondantes ou inutiles des données, ou utilisez des structures de données optimisées pour l'efficacité de l'espace. Les données compressées sont envoyées à la blockchain et peuvent être décompressées si nécessaire. Inconvénients : la compression et la décompression des données peuvent entraîner des calculs supplémentaires, mais cette latence peut être négligeable. L'algorithme de compression utilisé peut avoir un impact négatif sur la sécurité des données ; avantage : réduire les coûts de données.
Stockage hors chaîne : stockez les données hors chaîne et placez des blocs de données spécifiques en chaîne à la demande. Ceci est pertinent pour les solutions qui doivent stocker de grandes quantités de données pour une raison quelconque (par exemple, les nœuds d'archives Ethereum du bloc de genèse). Inconvénients : Identique à la compression en chaîne ; Avantages : Réduit davantage les coûts de données.
1**.2.3** Tiers de confiance
Une solution inter-chaînes complète devrait également impliquer des solutions de messagerie croisée avec des tiers de confiance (tels que des oracles, des ponts centralisés, etc.).
1**.2.4** Système de preuve "universel"
Dans le cas d'un mécanisme de plate-forme partagée de preuve d'agrégation, la messagerie peut être accélérée en recevant des hachages de bloc qui sont réglés au sein de la plate-forme d'agrégation, et le règlement ici gérera également la messagerie (mais s'il y a un problème avec la plate-forme d'agrégation ce qu'il faut faire?).
1**.2.5 Certains problèmes inconnus de la messagerie inter-chaînes ZK******
La messagerie inter-chaînes est-elle réalisable sans un tiers de confiance (qui peut être une seule entité ou plusieurs entités) ? Qu'est-ce qu'un mécanisme efficace pour la transmission de messages inter-chaînes ? En général, pour Ethereum L2 (avec accès direct aux hachages de bloc de L1) et Ethereum lui-même, si une chaîne peut exécuter un client léger, etc., ce qui est suffisant pour la messagerie inter-chaînes sans confiance.
Le circuit ZK utilisé pour la génération de preuve de chaîne croisée est-il correctement mis à l'échelle ? Dans certains cas, en particulier lorsque la couche de consensus (qui doit être vérifiée pour les opérations inter-chaînes) est très grande, le circuit utilisé pour le passage des messages inter-chaînes ZK peut être d'un ordre de grandeur plus grand que le cumul et le stockage en chaîne, et la surcharge de calcul est également très importante. Vraisemblablement, ce problème peut être surmonté avec une approche plus centralisée.
2**、Exemple de solution de messagerie inter-chaînes**
· Su****ccinct Labs utilise un client léger pour vérifier le consensus de la chaîne source à la couche de consensus de la chaîne cible. L'idée est qu'il existe un protocole client léger pour s'assurer que les nœuds peuvent synchroniser les en-têtes de bloc de l'état final de la blockchain. ZKP est utilisé pour générer des preuves de consensus.
· La****grange Labs construit une preuve d'état inter-chaîne non interactive. Lagrange prouve que le réseau est responsable de la création de la racine d'état. Chaque nœud Lagrange contient une partie de la clé privée d'un fragment, qui atteste de l'état d'une chaîne particulière. Chaque racine d'état est un seuil signé racine Verkle qui peut être utilisé pour attester de l'état d'une chaîne particulière à un moment donné. La racine d'état est complètement générale et peut être utilisée dans une preuve d'état pour prouver l'état actuel de n'importe quel contrat ou portefeuille de la chaîne.
· He****rodotus utilise la preuve de stockage ZKP pour fournir des contrats intelligents et accéder aux données sur la chaîne des autres couches Ethereum de manière synchrone. Pour la validation, il utilise la messagerie native L1<>L2 pour synchroniser les hachages de bloc entre les cumuls Ethereum.
=nil ; Foundation (Mina, L1) permet aux contrats intelligents sur Ethereum de vérifier la validité de l'état Mina. Générer des preuves d'état à usage spécial, peu coûteuses à vérifier sur Ethereum (les preuves Mina locales sur Ethereum sont chères). Hypothétiquement (dans le futur), les applications peuvent utiliser directement l'outil de génération de preuves de Mina pour vérifier la validité des transactions inter-chaînes. = néant ; Foundation dispose également d'un Proof Market où les utilisateurs/projets peuvent principalement acheter/vendre des preuves SNARK qui permettent un accès aux données sans confiance.
Axiom : Si Axiom a généré un ZKP pour le registre jusqu'à présent - il n'a pas besoin de générer un ZKP pour un bloc spécifique - il peut transmettre ce ZKP à la chaîne (en tant que relais), ou même Fournit l'accès à ce ZKP.
3. Messagerie inter-chaînes L2
*Avis de non-responsabilité : la messagerie inter-chaînes continue d'évoluer pour la majeure partie de la L2. Toutes les analyses ci-dessous sont basées sur des informations open source. Cela dit, les solutions mentionnées dans l'article peuvent être en phase d'exploration et de test, et le cumul peut éventuellement adopter d'autres méthodes. *
**（1）**Taiko
Taiko stocke les hachages de bloc pour chaque chaîne. Pour chaque paire de chaînes, il déploie deux contrats intelligents qui stockent les hachages de l'autre. Dans l'exemple de L2←→L1, chaque fois qu'un bloc L2 est créé sur Taiko, les valeurs de hachage des blocs périphériques sur L1 sont stockées dans le contrat TaikoL2. Également dans le cas de L1←→L2, le mode de fonctionnement est le même.
La dernière racine Merkle connue stockée sur la chaîne cible peut être obtenue en appelant getCrossChainBlockHash(0) sur le contrat TaikoL1/TaikoL2 et obtenir la valeur/le message à vérifier. Le hachage frère de la dernière racine Merkle connue peut être obtenu en appelant la requête eth_getProof à l'aide d'un RPC standard sur la "chaîne source".
Ensuite, envoyez-les simplement pour qu'ils soient vérifiés par rapport aux derniers hachages de blocs connus stockés dans une liste sur la "chaîne cible". Le validateur prendra une valeur (une feuille sur l'arbre Merkle) et des hachages frères pour recalculer la racine Merkle et vérifier qu'elle correspond à la racine stockée dans la liste des hachages de bloc de la chaîne cible.
**（2）**Starknet
Starknet utilise la preuve de stockage pour la messagerie inter-chaînes sans confiance.
Protocole de messagerie L2→L1
· Lors de l'exécution d'une transaction Starknet, un contrat sur Starknet envoie un message L2→L1.
Les paramètres du message (contenant le contrat du récepteur et les données associées sur L1) sont ensuite ajoutés à la mise à jour d'état pertinente (arbre de stockage principal).
· Les messages L2 sont stockés sur L1 du contrat intelligent.
· Émettre un événement sur L1 (stocker les paramètres du message).
Les adresses de destinataire sur L1 peuvent accéder au message et l'utiliser dans le cadre d'une transaction L1 en fournissant à nouveau des paramètres de message.
· Les messages inter-chaînes sont stockés dans l'arborescence du tronc.
L2 → L1
L1 → L2
**（3）**Optimisme
La communication entre L1 et L2 est mise en œuvre par deux contrats intelligents spéciaux appelés "messagers".
· Pour les transactions Optimism (L2) vers Ethereum (L1), il est nécessaire de fournir une preuve Merkle du message sur L1 après l'écriture de la racine d'état. Une fois que cette transaction de preuve fait partie de la chaîne L1, la période de défi d'erreur commence. Après cette période d'attente, tout utilisateur peut "finaliser" la transaction en déclenchant une deuxième transaction sur Ethereum, en envoyant un message au contrat L1 cible.
· Les messages inter-chaînes sont stockés dans l'arborescence du tronc.
（4）Ar****bitrum
Les tickets réessayables sont la méthode canonique utilisée par Arbitrum pour créer la messagerie L1 à L2, c'est-à-dire les transactions L1 qui initialisent les messages à exécuter sur L2. Un réessayable peut être soumis sur L1 moyennant des frais fixes (en fonction uniquement de la taille de ses données d'appel). L'arbre d'état principal est utilisé pour la communication inter-chaînes des formats de données personnalisés dans les contrats intelligents. La soumission d'un ticket réessayable sur L1 est séparable/asynchrone de l'exécution sur L2. Les réessayables fournissent l'atomicité entre les opérations inter-chaînes. Si la demande de transaction L1 est soumise avec succès (c'est-à-dire sans restauration), l'exécution réessayable sur L2 a une forte garantie qu'elle finira par réussir.
Arbitrum a deux troncs : La chaîne Nitro est maintenue dans le format d'arbre d'état d'Ethereum, un arbre Merkle. L'Assertion Tree stocke l'état de la chaîne Arbitrum confirmé sur Ethereum via "assertion". Les règles qui font avancer la chaîne Arbitrum sont déterministes. Cela signifie qu'étant donné l'état d'une chaîne et certaines nouvelles valeurs d'entrée, il n'y a qu'une seule sortie valide. Par conséquent, si l'arbre de preuve contient plusieurs feuilles, au plus une feuille peut représenter un état de chaîne valide.
Le système de boîte d'envoi d'Arbitrum autorise tout appel de contrat de L2 à L1, c'est-à-dire qu'un message est initié à partir de L2 et finalement exécuté sur L1. Les messages L2 à L1 (alias "messages sortants") ont beaucoup en commun avec les messages L1 à L2 d'Arbitrum (Réessayable), bien qu'il existe quelques différences notables. Une partie de l'état L2 d'une chaîne Arbitrum, c'est-à-dire la partie attestée dans chaque RBlock, est la racine Merkle de tous les messages L2 à L1 dans l'historique de la chaîne. Une fois le RBlock éprouvé confirmé (généralement environ une semaine après la preuve), la racine Merkle est incluse dans le contrat Outbox et publiée sur L1. Le contrat Boîte d'envoi permet ensuite aux utilisateurs d'exécuter leurs messages.
**（5）**Polygone zkEVM
· Le Bridge SC de ce zkEVM utilise un arbre Merkle spécial appelé Exit Tree pour chaque réseau participant à la communication ou à la transaction d'actifs.
Il utilise les racines Merkle (dans un arbre d'état séparé), un diagramme d'architecture de pont peut être trouvé sur github.
Le déploiement de zkEVM Bridge SC a apporté plusieurs modifications basées sur le contrat de dépôt Ethereum 2.0. Par exemple, il utilise un arbre Merkle spécialement conçu pour l'ajout uniquement, mais utilise la même logique que le contrat de dépôt Ethereum 2.0. D'autres différences concernent les hachages de base et les nœuds feuilles.
La principale caractéristique du contrat intelligent Polygon zkEVM Bridge est l'utilisation de l'arbre de sortie et de l'arbre de sortie global, où la racine de l'arbre de sortie global est la principale source de l'état de vérité. Par conséquent, L1 et L2 ont deux gestionnaires racine de sortie globaux différents et Bridge SC a une logique distincte.
（6）S****défilement
· Les contrats de pont déployés sur Ethereum et Scroll permettent aux utilisateurs de transmettre des messages arbitraires entre L1 et L2. En plus de ce protocole de messagerie, nous avons également construit un protocole de pontage sans confiance pour permettre aux utilisateurs de relier les actifs ERC-20 entre L1 et L2. Pour envoyer un message ou des fonds d'Ethereum à Scroll, un utilisateur appelle la transaction sendMessage sur le contrat Bridge. Les relais indexeront cette transaction sur L1 et l'enverront au donneur d'ordre pour inclusion dans les blocs L2. Sur le contrat de pont L2, le processus d'envoi d'un message de Scroll vers Ethereum est similaire.
· Les messages inter-chaînes sont stockés dans des files d'attente de messages ordinaires. Le trieur ingère les messages inter-chaînes de cette file d'attente et les ajoute à la chaîne en tant que transactions régulières.
**（7）**ère zksync
· Chaque paquet de transaction a un seul message L2->L1.
· Il n'est pas possible d'envoyer des transactions directement de L2 à L1. Cependant, vous pouvez envoyer des messages de n'importe quelle longueur de zkSync Era à Ethereum, puis traiter les messages reçus sur Ethereum à l'aide du contrat intelligent L1. zkSync Era a une fonction de preuve de demande qui renverra un paramètre booléen indiquant si le message a été envoyé avec succès à L1. Récupérez la preuve Merkle contenue dans le message en observant Ethereum ou en utilisant la méthode zks_getL2ToL1LogProof de l'API zksync-web3.
· Pour L1→L2, le contrat intelligent zkSync Era permet à l'expéditeur de demander une transaction sur Ethereum L1 et de transmettre les données à zkSync Era L2.
· Contrat relais :
4. Conclusion
La communication inter-chaînes fait partie intégrante des applications "indispensables" pour l'adoption massive de la blockchain (par exemple, le portefeuille de récupération sociale inter-chaînes décrit dans l'article Vitalik). La plupart des solutions inter-chaînes actuellement utilisées sont conçues pour L1←→L2 pour couvrir la fonction de retrait. Ces solutions peuvent être étendues à davantage de blockchains. Mais en même temps, des solutions de communication inter-chaînes plus avancées peuvent être mises en œuvre, telles que "l'état de lecture directe" sans preuve du tout ou "la preuve de stockage" sans confiance. Pour la plupart des L2, il y a encore place à l'amélioration de la communication inter-chaînes.