Suivant le titre original：Informations techniques sur ZetaChain : une infrastructure DAPP omniChain à guichet unique

ZetaChain est une chaîne publique de points de vente basée sur le SDK Cosmos, où ses blocs enregistrent les messages interchaînes et les données initiés par des « chaînes externes ». Les utilisateurs de chaînes externes comme BTC peuvent communiquer leurs intentions au réseau ZetaChain en publiant des messages dans un format spécifique, similaire au protocole Ordinals. Les nœuds ZetaChain utilisent un mécanisme de consensus pour déterminer les messages à traiter et leurs séquences, puis utilisent le Threshold Signature Scheme (TSS) pour générer une signature numérique sur la chaîne cible. Ce processus implique de libérer des actifs du compte public de la chaîne, puis de déclencher les étapes de transaction suivantes.

La liste actuelle des nœuds de validation de ZetaChain inclut de nombreuses parties prenantes au projet et institutions, telles qu'OKX, HashKey Cloud, Dora Factory, entre autres. En raison de la compatibilité EVM inhérente à ZetaChain, elle prend en charge le déploiement de la logique des contrats. Les développeurs d'applications DApp complètes peuvent écrire directement des programmes de traitement des messages inter-chaînes sur la ZetaChain, ce qui évite d'avoir à déployer des contrats d'actifs de transition sur plusieurs chaînes et permet ainsi de réduire les coûts de développement. Du point de vue de l'utilisateur, en théorie, l'interaction avec les contrats de ZetaChain est suffisante, ce qui élimine le besoin de multiples interactions avec les contrats passerelles entre les chaînes source et cible et réduit les frais de transaction. À l'instar de certains projets Intent qui ont un effet de « chaîne de conservation des actifs à guichet unique », ZetaChain prend en charge le déploiement de contrats d'actifs ou de protocoles DeFi. Les utilisateurs peuvent générer des messages spécifiques sur le frontend des dApps sur différentes chaînes pour appeler de manière asynchrone les contrats DeFi ou l'état des actifs de ZetaChain. Cette configuration prend également en charge les comptes de chaînes BTC. Cela revient à laisser ZetaChain héberger directement un compte d'actifs universellement unifié pour toutes les chaînes. Cependant, pour obtenir cet effet, il faut une interface DApp dédiée pour collaborer. À l'heure actuelle, la fonction principale de ZetaChain est de servir d'infrastructure sous-jacente à l'interopérabilité omnicain. Il peut analyser et traiter des messages inter-chaînes spécifiques et faire office de plateforme d'exécution de la logique métier pour les DApps multichaînes. Le modèle économique principal repose sur des scénarios B to B to C typiques.

Organe : Avec le développement continu de l'industrie de la blockchain, nous entrons dans une ère d'interconnexion multichaînes. À cette époque, différentes chaînes publiques aux caractéristiques distinctes ont donné lieu à des scénarios d'application diversifiés, créant ainsi des expériences variées pour les utilisateurs. Cependant, dans le même temps, l'isolement entre les chaînes s'est accentué. Souvent, les comptes des différentes chaînes ne peuvent pas communiquer, et les actifs des utilisateurs, quelles que soient les chaînes, restent fragmentés et non unifiés. Cela augmente le seuil d'utilisation et diminue considérablement l'expérience utilisateur.

On peut dire que le problème de fragmentation et d'incompatibilité entre des chaînes hétérogènes est l'un des principaux obstacles à l'augmentation des taux de conversion des utilisateurs. La popularité de l'écosystème BTC aujourd'hui met en évidence les problèmes d'interopérabilité entre des chaînes hétérogènes. Comme Vitalik Buterin l'a déclaré il y a de nombreuses années, « Multichain, c'est l'avenir ». Bien que la coexistence de plusieurs chaînes soit devenue une tendance irrésistible, établir des ponts entre des chaînes hétérogènes reste une tâche difficile.

Pour résoudre le problème de l'interopérabilité omnicaine, LayerZero, Polyhedra, Map Protocol, Bool Network et même Cosmos et Polkadot ont proposé différentes solutions pour la messagerie inter-chaînes. ZetaChain, récemment lancée et qui a introduit son jeton, joue un rôle essentiel dans le paysage de l'infrastructure omnicain.

Ci-dessous, nous présenterons un bref point de vue technique de la solution omnicaine de ZetaChain, en expliquant comment elle sert d'infrastructure sous-jacente aux dApps interopérables omnicains, permettant ainsi l'analyse et le traitement des messages entre chaînes.

Défis liés aux solutions inter-chaînes existantes

En réalité, le scénario le plus simple auquel un pont inter-chaînes doit faire face est le transfert d'actifs entre différentes chaînes. Par exemple, lorsque vous transférez des actifs d'ETH vers Polygon, vous devez d'abord transférer des actifs vers une adresse de dépôt désignée sur la chaîne ETH, puis recevoir un montant équivalent sur la chaîne Polygon. Le défi est dû au fait que les nœuds Polygon ne peuvent pas confirmer ce qui s'est passé sur la chaîne ETH et ne savent pas si vous avez effectivement déposé le montant spécifié. Si quelqu'un prétend faussement avoir déposé 100 USDT à l'adresse ETH désignée et lance une demande de retrait sur la chaîne Polygon pour débloquer ses 100 USDT, cela pose le problème du « retrait de nulle part ». La clé d'un pont inter-chaînes est de résoudre un tel problème en confirmant que toutes les demandes de retrait correspondent à des activités de dépôt réelles. Il s'agit essentiellement de prouver sur la chaîne B qu'il y a bien eu N transactions liées au pont inter-chaînes de la chaîne A.

Actuellement, les ponts inter-chaînes traditionnels ont tendance à adopter un mécanisme notarial, qui consiste à créer un groupe de nœuds notariaux qui parviennent à un « consensus » par le biais de signatures multiples ou de signatures MPC. Tant que la majorité des notaires sont d'accord pour dire que votre action inter-chaînes peut être approuvée, vos actifs peuvent se croiser sans problème. Certains ponts inter-chaînes utilisent un hash-lock plus sécurisé ou implémentent des nœuds légers d'autres chaînes par le biais de contrats en chaîne. Ces passerelles confirment la validité des activités inter-chaînes en recevant des preuves Merkle ou ZK. Cependant, le coût de ces ponts inter-chaînes est souvent plus élevé et est finalement transféré aux frais de transaction des utilisateurs. Par conséquent, la plupart des ponts inter-chaînes choisissent toujours le modèle de nœud notarial hors chaîne pour un consensus multi-signatures. Référence : Expliquer quels sont les facteurs importants à prendre en compte lors de la conception de ponts inter-chaînes ? Les ponts inter-chaînes basés sur des notaires sont notamment souvent confrontés à des risques importants, notamment en cas de piratage informatique ou de vol d'initiés. Selon les statistiques de SlowMist Hacked, 16 incidents de sécurité impliquant des ponts inter-chaînes se sont produits en 2022, soit une perte totale de 1,21 milliard de dollars. Cela représente 32 % du total des pertes liées à des attaques en chaîne cette année-là, ce qui met en lumière les dangers liés aux failles de sécurité des ponts inter-chaînes.

En outre, de nombreuses solutions de pont inter-chaînes existantes adoptent pour la plupart le modèle Lock-Mint, dans lequel les actifs sont bloqués sur la chaîne A et les actifs mappés correspondants sont émis sur la chaîne B pour permettre un transfert d'actifs entre chaînes. Cependant, le flux de traitement des dépôts et des retraits dans de telles solutions nécessite de multiples interactions avec le contrat d'actifs mappé, ce qui entraîne des frictions importantes et une perte potentielle de fonds. De plus, de nombreuses solutions de ponts inter-chaînes ne prennent en charge que les transferts d'actifs entre des chaînes compatibles EVM, ce qui pose des problèmes liés aux interactions entre chaînes hétérogènes telles que Solana et Bitcoin en raison de différences de normes techniques. Compte tenu des problèmes de sécurité et liés aux frais, les solutions classiques de bridge inter-chaînes ont souvent du mal à obtenir des résultats optimaux et ne peuvent pas garantir le transfert d'actifs « natif entre chaînes ». Dans l'écosystème Bitcoin actuel, on souhaite de plus en plus une expérience d'interaction inter-chaînes fluide et native, dans l'attente d'une solution plus efficace. ZetaChain relève ce défi grâce à son approche unique.

Fonctionnalités de ZetaChain : l'infrastructure sous-jacente des DApps interopérables entre chaînes

ZetaChain se positionne comme l'infrastructure de base des DApps interopérables omnicains, spécialisée dans la prise en charge de divers protocoles d'application pour les interactions entre chaînes, un exemple d'infrastructure sous-jacente B to B to C. Il utilise un mécanisme d'admission PoS, qui permet aux nœuds qui jalonnent des actifs d'entrer dans le réseau et de faire office de notaires. Tous les nœuds PoS, qui utilisent la technologie TSS, participent à la vérification et au traitement des messages inter-chaînes, dans le but de renforcer la sécurité autant que possible. Dans le même temps, ZetaChain facilite le déploiement de contrats intelligents, en intégrant la logique commerciale liée aux échanges d'actifs. Les utilisateurs peuvent envoyer des messages dans un format spécifique sur n'importe quelle chaîne, en appelant ZetaChain ou ses contrats DeFi pris en charge sur plusieurs chaînes. Par exemple, sur BTC, les utilisateurs peuvent appeler indirectement les fonctionnalités DeFi sur Polygon. Le résultat est de faciliter la transmission des messages entre les différentes blockchains, garantissant ainsi l'interopérabilité.

Les applications basées sur un scénario d'interopérabilité omnicaine peuvent déployer une logique commerciale d'échange d'actifs sur ZetaChain, facilitant ainsi la conversion automatique des jetons de gaz sur différentes chaînes pour les utilisateurs. Par exemple, en utilisant le frontend de certaines DApps omnicains, vous pouvez émettre un message au format spécifique sur BTC, similaire au protocole Ordinals, pour indiquer un appel à un contrat sur Solana. Les nœuds ZetaChain détecteront ce message, puis le contrat AMM sur ZetaChain peut calculer automatiquement le ratio de change entre BTC et SOL. Elle libère ensuite un montant équivalent de SOL sur la chaîne Solana, en effectuant les étapes suivantes, telles que la conclusion de contrats et, enfin, le transfert des actifs mérités sur votre adresse BTC ou Solana. Ce processus est appelé « interopérabilité omnicaine », où il suffit de publier un message sur une chaîne pour appeler à distance des DApps sur plusieurs chaînes. Dans ce contexte, ZetaChain peut être conceptualisée comme une « couche de règlement en chaîne ». Dans tous les scénarios d'interaction multi-chaînes, comme lancer un appel depuis la chaîne A vers une dApp de la chaîne B, cela revient à régler d'abord la chaîne A avec ZetaChain. ZetaChain synchronise ensuite les résultats de règlement prétraités avec le compte correspondant sur la chaîne B, en effectuant les étapes suivantes. Tout au long de ce processus, il n'y a pas d'interaction excessive avec la cartographie des contrats d'actifs ni de friction en matière de frais de transaction. La circulation des actifs est facilitée par les comptes publics de ZetaChain entre les différentes chaînes, ce qui élimine le besoin de déployer fréquemment des contrats d'actifs cartographiques sur les différentes chaînes, comme le montrent les applications inter-chaînes traditionnelles.

À l'heure actuelle, il semble que les applications omnicaines basées sur ZetaChain peuvent vous éviter bien des problèmes, en évitant d'avoir à concevoir minutieusement des contrats d'actifs cartographiques sur les différentes chaînes. Tous les détails concernant les entrées et les sorties d'actifs entre les chaînes source et cible sont gérés par ZetaChain. En d'autres termes, il vous suffit de déployer une logique métier liée aux transactions inter-chaînes sur ZetaChain. Cela permet à différentes applications complètes de prendre en charge des chaînes non EVM telles que Solana, Algorand, Bitcoin et DogeCoin sur le frontend sans avoir à mettre en œuvre de manière approfondie des contrats d'application inter-chaînes dédiés sur différentes chaînes. De plus, ZetaChain prend elle-même en charge le déploiement de contrats d'actifs ou de comptes AA (Autonomous Asset). Les utilisateurs de différentes chaînes peuvent envoyer des messages dans un format spécifique pour désigner ces contrats, comme s'ils géraient un compte unifié pour toutes les chaînes. Cette approche de conception, qui se reflète également dans Particle Chain de Particle Network, permet en fin de compte aux utilisateurs de centraliser les enregistrements de données de leurs actifs sur ZetaChain ou Particle Chain. Si nécessaire, les utilisateurs peuvent appeler leurs contrats d'actifs de manière asynchrone sur ZetaChain en envoyant des messages d'invocation via le frontend des DApps via des « chaînes externes ». Ensuite, ZetaChain, via le compte public de la chaîne externe, transfère un certain nombre d'actifs à l'adresse spécifiée par l'utilisateur ou interagit avec le protocole DeFi spécifié par l'utilisateur.

La mise en
œuvre de cette série d'opérations nécessite la mise en œuvre de dApps frontales spécialisées. En d'autres termes, ZetaChain fournit elle-même des services en tant qu'infrastructure sous-jacente à l'omnicain, et il doit y avoir une entrée frontale dédiée au niveau de l'application pour générer des messages dans un format spécifique.

Le modèle de sécurité de ZetaChain : un vaste réseau de nœuds notariaux basé sur le jalonnement des points de vente

En fin de compte, ZetaChain est essentiellement un réseau de nœuds de validation conçus pour le traitement des messages entre chaînes. Construit sur le SDK Cosmos, il comprend de nombreux nœuds de validation et utilise le POS comme mécanisme d'admission, ce qui lui permet de résister aux attaques de Sybil et de garantir une sécurité sous-jacente.

Au sein du réseau ZetaChain, les nœuds Validator, qui font office de notaires décentralisés, confirment quelles demandes inter-chaînes en attente ont été déclenchées sur d'autres chaînes. Par consensus, ils enregistrent ces comportements inter-chaînes et passent aux étapes suivantes. À l'aide des signatures de clés distribuées TSS, ZetaChain peut générer des instructions de transaction sur d'autres chaînes. On peut dire que le mode de fonctionnement des validateurs ressemble au mode notaire des ponts inter-chaînes, mais avec le jalonnement des points de vente, les nœuds des validateurs sont plus fiables, ce qui résout le problème de Sybil.

(La liste actuelle des nœuds de validation de Zetachain inclut de nombreuses parties prenantes au projet ou institutions) Le client Zetachian's Validator comprend deux modules, ZetaCore et ZetaClient. Le module ZetaCore participe à la génération de blocs ZetaChain et au processus de consensus, tandis que le module ZetaClient observe les événements sur les chaînes externes et signe les transactions sortantes. Ici, le terme « sortant » peut être simplement compris comme l'enregistrement du journal des transactions sur ZetaChain et son envoi à des « chaînes externes » (en référence à des chaînes extérieures à ZetaChain). Cela déclenche les actions correspondantes sur la chaîne cible, le contenu incluant principalement l'adresse du contrat, l'identifiant de la chaîne et le contenu du message déclaré par l'utilisateur dans le message, comme dans la section Journal des transactions Ethereum.

À l'inverse, le terme « entrant » peut être compris comme l'enregistrement de messages/transactions pertinents sur des chaînes externes extérieures à ZetaChain, comme des requêtes inter-chaînes, des appels de contrats intelligents sur ZevM, etc., sur ZetaChain. Il est important de noter que lorsque vous exécutez des nœuds Validator pour ZetaChain, le code client inclut trois modules : Validator, Observer et TSS Signer. Ces trois modules ont des fonctionnalités différentes mais appartiennent tous au client ZetaChain.

Modules Observer et TSS Signer

Tout d'abord, tous les nœuds ZetaChain disposent d'un module « validateur », doté de fonctionnalités similaires à celles des nœuds de validation des chaînes publiques PoS, qui participent à la génération de blocs et aux processus de consensus. De plus, les nœuds peuvent voter sur les propositions en chaîne en fonction du ratio de jetons mis en jeu (ZETA). Les blocs de ZetaChain contiennent tous les enregistrements inter-chaînes traités et les interactions avec les contrats intelligents omnicains, qui font office de journal.

Le module « observateur » du client ZetaChain gère d'autres nœuds complets ou légers de chaînes publiques, en surveillant des formats spécifiques de transactions/messages interchaînes. Le module Observer fonctionne en deux modes : actif et passif. Les différents nœuds de ZetaChain peuvent choisir de passer du module Observer à l'un de ces modes. Le module Observer surveille en permanence la présence de messages/événements inter-chaînes liés à ZetaChain sur d'autres chaînes. Si c'est le cas, le module Observer du nœud ZetaChain signale la situation au module Validator. Ces messages inter-chaînes observés sont ensuite soumis au bloc de ZetaChain et confirmés collectivement par consensus.

Il existe deux modes d'observation : le mode actif et le mode passif. En mode actif, les nœuds analysent en permanence les transactions/événements/états d'autres blockchains en dehors de ZetaChain en exécutant les nœuds complets de ces chaînes. En mode passif, les nœuds ne synchronisent pas les blocs complets des autres blockchains ; au lieu de cela, ils reçoivent passivement des messages inter-chaînes analysés en provenance d'autres nœuds ZetaChain. Cependant, bien que les nœuds en mode passif ne synchronisent pas l'intégralité des blocs de chaînes externes, ils synchronisent les en-têtes des blocs et confirment via Merkle Proof que ces messages/données de transaction inter-chaînes existent réellement sur la chaîne externe.

L'avantage du mode actif est que la plupart des nœuds ZetaChain synchronisent les données provenant de chaînes externes, ce qui offre une forte résistance à la censure. Dans ce mode, toute interaction de l'utilisateur avec ZetaChain peut avoir lieu dès qu'un nœud détecte une demande initiée sur une chaîne externe. Cependant, en mode actif, faire fonctionner des nœuds coûte plus cher. Outre le client ZetaChain, les nœuds doivent également exécuter des nœuds complets de chaînes externes, synchroniser les données et effectuer des scans en continu. D'autre part, le mode passif permet de réduire considérablement les coûts d'exploitation des nœuds d'observation classiques. Seuls des nœuds spécifiques exécutent le client complet des chaînes externes, tandis que d'autres nœuds exécutent des clients légers sans synchroniser des blocs de chaînes externes complets. Cela se traduit par une baisse des coûts et une évolutivité plus facile du nombre de nœuds en mode passif, facilitant ainsi l'intégration à de multiples chaînes externes. Cependant, l'inconvénient du mode passif est que l'activité d'observation des données sur les chaînes externes dépend de quelques nœuds, ce qui affaiblit la résistance à la censure. Pour remédier à cette situation, ZetaChain incite les nœuds à exécuter le mode actif du module Observer.

(En mode actif, les nœuds doivent exécuter le client complet des chaînes externes. En mode passif, seuls les clients légers de chaînes externes sont gérés. Ils reçoivent des messages inter-chaînes et des preuves Merkle (des nœuds ZetaChain en mode actif pour confirmer la validité des messages)

Signature TSS

Tous les messages inter-chaînes observés et vérifiés par les nœuds ZetaChain déclencheront en fin de compte une transaction sur la chaîne cible via l'adresse du compte public de ZetaChain, ce qui donnera lieu à des opérations ultérieures. Dans ce processus, il est nécessaire de générer une signature numérique pour cette transaction inter-chaînes sur la chaîne cible. Pour des raisons de sécurité et de fiabilité, la génération de signatures est effectuée par tous les nœuds ZetaChain, qui stockent collectivement des fragments de clé pour la génération de signatures. Ces fragments de clé sont distribués à plusieurs signataires, et ce n'est que lorsque la majorité des signataires apposent leur signature que la signature numérique de la transaction peut être générée sur la chaîne externe. À tout moment, une seule entité ou un petit sous-ensemble de nœuds ne peut pas représenter ZetaChain lorsqu'il s'agit de déclencher des transactions ou de signer des messages sur des chaînes externes.

Dans le modèle inter-chaînes de ZetaChain, il suffit d'avoir une adresse de compte commune sur différentes chaînes sans avoir à déployer des contrats intelligents complexes. L'algorithme multisignature de ZetaChain utilise le TSS, le Threshold Signature Scheme. Alors que les signatures numériques des transactions visibles de l'extérieur correspondent à une clé privée, à une clé publique et à une adresse uniques, en réalité, cette clé privée est générée par de nombreux fragments distribués sur tous les appareils du nœud ZetaChain, générés sans l'intervention d'intermédiaires. À tout moment, une seule entité ou quelques validateurs ne peuvent pas représenter l'ensemble du réseau pour reconstituer des fragments de clé privée et signer des messages. Le processus de génération et de signature des clés du TSS est effectué par le biais du calcul multipartite (MPC), qui garantit qu'aucun secret sur les nœuds participants n'est divulgué. Les nœuds ZetaChain peuvent générer des signatures de transactions sur différentes chaînes. En plus d'être compatible avec différentes chaînes EVM, ZetaChain permet d'appeler à distance des contrats intelligents pour des bitcoins ou des chaînes de contrats non intelligents. L'expérience utilisateur est similaire à celle des utilisateurs de Bitcoin qui appellent directement certaines fonctionnalités de la DeFi.

Ce scénario est particulièrement adapté à l'hébergement d'applications DeFi multichaînes au sein de l'écosystème BTC. Comme la blockchain BTC ne peut pas implémenter une logique commerciale trop complexe, elle s'appuie sur une infrastructure externe pour appeler à distance certains contrats DeFi. Les fonctionnalités de ZetaChain sont parfaitement adaptées aux utilisateurs de l'écosystème BTC qui souhaitent appeler des contrats DeFi de manière asynchrone.

ZeVM : plateforme de contrats DAPP multichaînes à guichet unique

Contrairement aux solutions inter-chaînes traditionnelles qui nécessitent le déploiement de contrats d'actifs cartographiques sur chaque chaîne, ZetaChain propose des fonctionnalités inter-chaînes en ne déployant un contrat intelligent qu'une seule fois sur sa propre chaîne. Dans ZetaChain, il existe une couche d'exécution compatible avec EVM appelée ZeVM, qui permet de déployer directement des contrats intelligents inter-chaînes. ZeVM prend en charge les fonctionnalités suivantes : n'importe qui peut envoyer des données de transaction dans un format spécifique sur la chaîne externe et créer un contrat sur ZeVM ; la logique contractuelle de ZeVM peut contrôler les données de transactions sortantes générées sur la chaîne externe. Ces deux fonctionnalités supplémentaires permettent à ZeVM de prendre en charge la programmation générale, de déployer une logique métier spécifique et de modifier l'état des différentes chaînes de manière atomique. Si une opération inter-chaînes a lieu et que ZetaChain détecte que les étapes suivantes de cette opération n'aboutissent pas sur la chaîne cible, les données modifiées par la transaction inter-chaînes dans le contrat ZetaChain peuvent être annulées, comme si de rien n'était. De plus, l'application omnicaine DAPP n'a pas besoin de déployer des contrats d'actifs cartographiques sur différentes chaînes. Il lui suffit d'utiliser le contrat de la chaîne ZetaChain pour configurer de manière centralisée la logique de traitement des messages inter-chaînes en un seul endroit, sans avoir à déployer fréquemment des contrats inter-chaînes sur un réseau multichaînes. Cela peut permettre de réduire de manière significative les coûts de développement de la chaîne DAPP complète. Au niveau de l'utilisateur, comme il n'est pas nécessaire d'interagir fréquemment avec des contrats d'actifs mappés sur plusieurs chaînes, le coût est inférieur à celui des ponts interchaînes classiques qui nécessitent le déploiement de contrats d'actifs mappés sur différentes chaînes. En outre, des contrats DeFi spéciaux et des actifs ZRC-20 ou même NFT peuvent également être déployés sur ZetaChain pour synchroniser les données relatives à l'état des actifs ou déployer des comptes AA. Cela lui confère des fonctionnalités de plateforme de gestion unifiée des actifs (enregistrement du statut). Comme nous n'avons plus besoin de travailler dur pour détenir des actifs sur plusieurs chaînes, ce scénario de comptes d'actifs unifiés sur l'ensemble de la chaîne peut générer plus de potentiel à l'avenir.

Conclusion

D'après ce dont nous avons parlé dans cet article, nous avons mieux compris « l'infrastructure d'interopérabilité omnicain » de ZetaChain. Grâce au module observateur du client de validation, ZetaChain surveille des messages/transactions spécifiques sur des chaînes externes, les signale au module de validation, parvient à un consensus sur les messages au sein du réseau ZetaChain, analyse les données contenues dans les messages, génère des signatures numériques à l'aide de TSS et déclenche des processus de transaction ultérieurs sur les chaînes cibles correspondantes, réalisant ainsi des interactions interchaînes sur l'ensemble du réseau. Dans le même temps, les contrats intelligents omnicains basés sur ZetaChain nous permettent d'interagir étroitement avec différentes blockchains sans avoir à utiliser des contrats d'actifs cartographiques sur les différentes chaînes. Cela élimine le recours à une logique contractuelle redondante, ce qui permet de réduire les coûts de transaction. De plus, comme ZetaChain est compatible EVM, tout développeur de DApp, ou même un utilisateur individuel, peut déployer une logique de traitement des messages inter-chaînes personnalisée. En théorie, il est possible de déployer l'intégralité du contrat DApp d'une manière unique. Les développeurs d'applications inter-chaînes n'ont pas besoin de déploier/mettre à jour fréquemment la logique des contrats d'actifs cartographiques sur les différentes chaînes, ce qui élimine le coût d'un développement redondant.

Avertissement：

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