Prenons Zetachain comme exemple pour comprendre comment Omnichain parvient à réaliser l'abstraction des chaînes.
TechFlow SélectionTechFlow Sélection
Prenons Zetachain comme exemple pour comprendre comment Omnichain parvient à réaliser l'abstraction des chaînes.
Un pont inter-chaînes est une solution relativement courante, mais Omnichain emprunte une voie totalement différente.
Dédié à des analyses Web3 approfondiesAuteur : CaptainZ, ancien chercheur chez Injective
Omnichain signifie inscrire les règles de cross-chain directement dans des contrats intelligents.
À mesure que le nombre de blockchains publiques et de chaînes Layer2 augmente, la demande de transfert d'actifs et d'interactions entre chaînes pour les Dapp croît également. Les ponts cross-chain sont une solution courante, mais Zetachain incarne une approche radicalement différente avec son architecture Omnichain.
Cet article utilise Zetachain comme exemple pour expliquer comment Omnichain intègre les règles de cross-chain dans des contrats intelligents afin de décentraliser l'interopérabilité entre chaînes.
A. Différentes solutions techniques pour le cross-chain
L'objectif principal de la technologie cross-chain est d’assurer l’interopérabilité (Interoperability) entre différentes blockchains. L’interopérabilité désigne la capacité de systèmes blockchain distincts à se comprendre mutuellement, à utiliser les actifs (comme jetons ou cryptomonnaies) et les données de l’autre, ou encore à permettre aux applications tournant sur différentes plateformes blockchain d’interagir et de coopérer. Réaliser cet objectif renforce considérablement la flexibilité et l’extensibilité de l’écosystème blockchain, brise l’effet d’îlot entre plateformes, et favorise ainsi des développements plus larges.
Selon la manière dont les messages cross-chain sont traités et selon les méthodes de signature et d'autorisation des actifs associés, on distingue plusieurs solutions techniques :
1. Ponts cross-chain (Cross-Chain Bridges) :
Un pont cross-chain permet le transfert d’actifs d’une blockchain vers une autre. Il fonctionne en verrouillant les actifs sur la chaîne source, puis en émettant des actifs représentatifs (ou équivalents) sur la chaîne cible. Cette méthode supporte le transfert et l’utilisation d’actifs entre chaînes, mais nécessite que le processus de verrouillage et de libération soit sécurisé et fiable. Lorsque deux chaînes indépendantes utilisent un pont pour interagir, l’une est considérée comme une sidechain de l’autre chaîne principale.
2. Système de notaires (Notary) :
Ce modèle repose sur un groupe de nœuds (ou institutions) de confiance chargés de valider la validité des transactions cross-chain. Ces nœuds notaires surveillent les événements sur une chaîne et créent des transactions correspondantes sur une autre chaîne pour attester et enregistrer ces événements. Bien que cette approche permette l’interopérabilité, sa sécurité et son niveau de décentralisation dépendent fortement de la fiabilité des notaires.
3. Contrats de blocage temporel par hachage (Hash Timelock Contracts, HTLCs) :
Les HTLC sont une technologie de contrat intelligent basée sur le blocage temporel, permettant à deux parties d’échanger des actifs entre chaînes sans tiers de confiance. Cela s’effectue via un contrat qui ne libère les fonds qu’après fourniture du secret correct (pré-image du hachage). Les fonds ne sont débloqués et transférés que si les deux parties respectent leurs obligations contractuelles. Cette méthode permet des échanges d’actifs décentralisés, mais exige une certaine coordination entre les participants.
4. BoB (Blockchain on Blockchain, par exemple IBC de Cosmos) :
Cette solution consiste à créer de nouvelles blockchains (ou couches) au-dessus d'une blockchain existante pour assurer l’interopérabilité, comme le protocole IBC (Inter-Blockchain Communication) dans le réseau Cosmos. IBC permet à différentes blockchains de conserver leur gouvernance autonome tout en assurant un transfert sécurisé d’actifs et de données. Cette approche vise à construire un internet décentralisé de blockchains, où chaque chaîne peut librement échanger informations et valeurs.
Ces solutions présentent chacune des avantages et inconvénients, adaptés à différents cas d’usage. Le choix et la mise en œuvre d’une technologie cross-chain doivent prendre en compte les caractéristiques des blockchains cibles, les exigences de sécurité, le degré de décentralisation et la complexité technique.
B. Transmission des messages cross-chain
La transmission des messages cross-chain (Cross-Chain Message Passing, CCMP) est la technologie clé permettant l’interopérabilité entre chaînes, garantissant que les interactions peuvent se dérouler de façon sûre et efficace. Son objectif fondamental est de transmettre et vérifier des messages entre différentes blockchains afin d’assurer l’échange d’actifs et de données. Son fonctionnement repose sur plusieurs étapes clés :
1. Génération et envoi du message :
- Le message contient généralement toutes les informations nécessaires au transfert d’actifs : quantité, adresse source, adresse cible, etc.
- Une fois généré, le message est envoyé via un contrat intelligent sur la chaîne source, qui enregistre les détails de la transaction et déclenche le verrouillage des actifs.
2. Transmission du message :
- Deux méthodes principales existent : transmission directe et transmission par relais.
- La transmission directe suppose un chemin de communication direct entre la chaîne source et la chaîne cible, mais elle est rare en pratique car la plupart des blockchains fonctionnent indépendamment.
- La transmission par relais implique des relais (qui peuvent être des services centralisés ou un réseau de nœuds décentralisés), qui surveillent des événements spécifiques sur la chaîne source, capturent les informations pertinentes, puis les transmettent à la chaîne cible.
3. Vérification du message :
- Sur la chaîne cible, le message reçu doit être vérifié pour confirmer sa légitimité et son intégrité.
- Ce processus nécessite souvent une preuve de données depuis la chaîne source (par exemple, une preuve Merkle), attestant que le message provient bien de la chaîne source et n’a pas été altéré.
- Une fois validé, le contrat intelligent sur la chaîne cible exécute les actions appropriées (ex. : frapper un jeton ou mettre à jour l’état).
4. Traitement et réponse :
- Après vérification, la chaîne cible effectue les opérations requises, comme libérer des actifs ou créer une instance de jeton.
- Une fois cette étape terminée, l’interaction cross-chain est essentiellement achevée, et l’utilisateur peut utiliser ou gérer ses actifs sur la chaîne cible. En réalité, les différentes solutions cross-chain mentionnées ci-dessus diffèrent précisément par leurs méthodes de transmission de messages.
1. Ponts cross-chain
Les ponts cross-chain créent une couche intermédiaire facilitant le transfert d’actifs et d’informations entre blockchains. Cette couche intermédiaire peut être : - Un serveur centralisé, contrôlé par une entité de confiance, chargé de surveiller les événements sur une chaîne et de les reproduire sur l’autre. - Un réseau décentralisé composé de nœuds indépendants, qui valident et relaient les messages via un mécanisme de consensus. Dans un pont cross-chain, les actifs sont généralement verrouillés sur la chaîne source et des actifs équivalents sont frappés sur la chaîne cible. Ce processus doit garantir que le message n’est ni falsifié ni modifié avant validation et exécution.
2. Notaires
Le système de notaires repose généralement sur un ensemble de notaires pré-sélectionnés (personnes, organisations ou nœuds automatisés) chargés de surveiller les événements sur une chaîne et de les valider sur une autre. Les notaires offrent un mécanisme de validation centralisé ou semi-centralisé, dont la sécurité et la fiabilité dépendent entièrement de la confiance accordée à ces entités.
3. Contrats de blocage temporel par hachage (HTLC)
Un HTLC est un contrat reposant sur la cryptographie, utilisé pour des échanges conditionnels d’actifs entre deux chaînes. Il utilise des fonctions de hachage cryptographiques et des blocages temporels pour contrôler les conditions de libération des actifs : - Hachage par mot de passe : les actifs ne peuvent être libérés du contrat que si le destinataire fournit la bonne pré-image (données originales correspondant au hachage). - Blocage temporel : si la bonne pré-image n’est pas fournie dans le délai imparti, les actifs retournent à leur propriétaire initial. Cette méthode ne dépend pas d’un validateur centralisé, mais assure la sécurité de l’échange via la logique même du contrat.
4. BoB
Cette technologie crée de nouvelles chaînes ou sous-chaînes sur la base d’un protocole de communication inter-chaînes. Par exemple, Cosmos utilise le protocole IBC pour permettre une communication directe entre blockchains, chaque chaîne conservant son autonomie tout en échangeant en toute sécurité messages et actifs. IBC et XCMP sont fondamentalement des protocoles de communication inter-chaînes.
La technologie CCMP fait face à plusieurs défis majeurs :
Sécurité : les nœuds relais ou le réseau doivent être dignes de confiance, sinon il existe un risque de falsification des messages. De plus, les contrats intelligents sur la chaîne source et cible doivent être suffisamment sécurisés pour éviter les vulnérabilités.
Efficacité et latence : les opérations cross-chain impliquent souvent plusieurs confirmations de blocs, pouvant entraîner des délais importants.
Décentralisation et problèmes de confiance : dépendre de nœuds relais ou de services tiers va à l’encontre de l’esprit de décentralisation de la blockchain. Concevoir un mécanisme CCMP à la fois décentralisé et sécurisé constitue donc un défi technique.
En raison de ces défis techniques et sécuritaires, la mise en œuvre et l’optimisation du CCMP restent un domaine actif de recherche et de développement. Diverses solutions tentent de trouver le meilleur compromis entre décentralisation, sécurité et efficacité.
C. Signature et autorisation des actifs cross-chain
La technologie cross-chain et l’interopérabilité ne reposent pas uniquement sur la transmission des messages (CCMP), mais aussi sur la manière dont la signature et l’autorisation sont effectuées sur la chaîne source et la chaîne cible, afin d’assurer un traitement sécurisé des actifs et la légalité des transactions. Différentes solutions adoptent divers mécanismes de signature et d’autorisation, centrés sur la manière de valider la légitimité des transactions et de garantir le transfert sécurisé des actifs. Voici quelques exemples communs :
1. Ponts cross-chain
Les ponts peuvent utiliser des signatures multi-signatures (Multisignature) ou des signatures par proxy (Proxy Signature). Dans ce cas, l’opération de transfert nécessite l’autorisation d’un certain nombre de nœuds validateurs ou d’un service proxy spécifique, chargés de valider la requête de transaction et de signer celle-ci. Cette approche améliore la sécurité, mais introduit un problème de confiance, car elle dépend d’entités centralisées ou semi-centralisées.
2. Notaires
Dans un système de notaires, les nœuds notaires surveillent et valident les demandes de transaction cross-chain, puis exécutent les opérations correspondantes sur la chaîne cible. Ils doivent signer et autoriser les opérations sur la chaîne cible pour prouver que la transaction sur la chaîne source est autorisée. Ce modèle dépend fortement de la fiabilité et de la sécurité des notaires.
3. Contrats de blocage temporel par hachage (HTLC)
Dans un HTLC, la signature et l’autorisation ne dépendent pas de validateurs externes ou d’intermédiaires. La légitimité et l’exécution de la transaction reposent sur la logique du contrat et l’interaction directe entre les parties. La fourniture de la bonne pré-image (clé) par les participants agit comme une forme d’autorisation. En outre, le contrat inclut un mécanisme de blocage temporel, garantissant que la transaction ne peut être finalisée qu’à l’intérieur d’une fenêtre temporelle définie.
4. BoB
Par exemple, dans le protocole IBC de Cosmos, le processus de signature et d’autorisation s’appuie sur des protocoles inter-chaînes et des contrats locaux. Chaque chaîne gère indépendamment sa propre sécurité et ses mécanismes d’autorisation, tout en garantissant via le protocole la sécurité et la validité des messages cross-chain. Cette approche met l’accent sur la décentralisation et l’autonomie, réduisant la dépendance vis-à-vis d’une entité unique.
En résumé, les mécanismes de signature et d’autorisation varient selon les solutions cross-chain, en fonction de leur structure et de leurs besoins en sécurité. Le choix et la conception de ces mécanismes reposent sur l’équilibre entre sécurité, confiance, décentralisation et efficacité. Dans toute mise en œuvre cross-chain, garantir la légalité et la sécurité de toutes les chaînes participantes est indispensable.
D. Architecture de Zetachain
Si la DeFi consiste à inscrire les règles financières dans des contrats intelligents, et les jeux blockchain à y coder les règles de jeu, alors Omnichain revient à y intégrer les règles cross-chain — y compris celles de transmission des messages et de signature/autorisation des actifs. Examinons en détail comment Zetachain y parvient.
ZetaChain est une blockchain PoS construite sur Cosmos SDK et le moteur de consensus Tendermint PBFT. Grâce à Tendermint PBFT, ZetaChain atteint un temps de génération de bloc d’environ 5 secondes et une finalité instantanée (pas besoin de confirmation de bloc, pas de réorganisation). Dans des conditions réseau idéales, son débit peut atteindre plus de 4000 transactions par seconde, bien que le débit cross-chain puisse être limité par la latence des chaînes externes et d’autres facteurs (comme la vitesse RPC des nœuds externes).
L’architecture de ZetaChain repose sur un réseau distribué de nœuds appelés validateurs. Chaque validateur de ZetaChain contient deux composants : ZetaCore et ZetaClient. ZetaCore génère la blockchain et maintient la machine d’état répliquée, tandis que ZetaClient observe les événements sur les chaînes externes et signe les transactions sortantes. ZetaCore et ZetaClient sont packagés ensemble et exécutés par les opérateurs de nœuds. Toute personne disposant d’un montant suffisant de jetons ZETA peut devenir opérateur de nœud et participer à la validation.
Ainsi, si un validateur de ZetaChain n’exécute que ZetaCore, il devient un séquenceur (sequencer). S’il n’exécute que ZetaClient et surveille uniquement les événements externes, il devient un observateur (observer). S’il n’exécute que ZetaClient et ne fait que signer les transactions sortantes, il devient un signataire (signer).
ZetaChain détient collectivement des clés ECDSA/EdDSA standards pour interagir de façon authentifiée avec les chaînes externes. Ces clés sont distribuées entre plusieurs signataires, et seul un super-majorité de signataires peut représenter ZetaChain pour signer extérieurement. ZetaChain utilise un mécanisme de mise en gage liée et d’incitations positives/négatives pour assurer la sécurité économique.
E. Deux mécanismes d’interopérabilité cross-chain de Zetachain
Zetachain prend en charge deux mécanismes d’interopérabilité cross-chain : le mécanisme classique de pont cross-chain, et le mécanisme de contrat intelligent Omnichain.
E.1 Mécanisme de pont cross-chain
Examinons d’abord le fonctionnement du pont cross-chain, qui suit principalement les étapes suivantes :
1. Interaction utilisateur-contrat : l’utilisateur effectue une opération sur le contrat C1 de la chaîne A, générant un événement ou un mémo contenant [chainID, contractAddress, message]. Ce message est des données applicatives encodées en binaire.
2. Capture par les observateurs : les observateurs de ZetaChain (dans zetaclient) détectent cet événement ou mémo et le rapportent à zetacore, qui valide la transaction entrante.
3. Construction de la transaction sortante : zetacore met à jour les variables d’état CCTX (transaction cross-chain) et OutboundTxParams, guidant les signataires TSS (dans zetaclient) pour construire, signer et diffuser la transaction externe.
4. Signature et diffusion : les signataires TSS de zetaclient construisent la transaction sortante selon les paramètres OutboundTxParams du CCTX, réalisent la cérémonie de signature TSS, puis diffusent la transaction signée vers la blockchain externe.
5. Mise à jour et suivi de l’état : la structure CCTX suit également les différentes étapes/états de la transaction cross-chain.
6. Confirmation de transaction : une fois la transaction diffusée incluse dans une blockchain (« minée » ou « confirmée »), zetaclient en informe zetacore, qui met à jour l’état du CCTX.
7. Gestion du succès et de l’échec :
- Si la transaction externe réussit, l’état du CCTX devient OutboundMined, le traitement est terminé, état terminal.
- Si la transaction échoue (ex. annulée sur Ethereum), l’état du CCTX passe à PendingRevert (si possible) ou Aborted (si impossible de revenir en arrière). En cas d’Aborted, le traitement du CCTX est terminé.
8. Gestion de la restauration :
- Si le nouvel état est « PendingRevert », le CCTX contient déjà un deuxième OutboundTxParams, guidant les zetaclients à créer une transaction sortante de « Revert » vers la chaîne et le contrat d’entrée, permettant au contrat d’entrée d’implémenter une fonction de restauration au niveau applicatif pour nettoyer l’état.
- Les zetaclients construisent la transaction de restauration, effectuent la cérémonie de signature TSS, et diffusent la transaction vers la chaîne d’entrée (la chaîne A ici).
9. Confirmation de restauration :
- Une fois la transaction de restauration « confirmée » sur la chaîne A, les zetaclients en informent zetacore.
- Si la restauration réussit, l’état du CCTX devient Reverted, traitement terminé.
- Si elle échoue, l’état devient Aborted, traitement terminé.
Grâce à ces étapes, on voit que la transmission des messages cross-chain s’effectue principalement par communication interne entre ZetaCore et ZetaClient, selon une approche plutôt centralisée, sans utiliser de contrat intelligent de Zetachain lui-même, mais uniquement des contrats intelligents de la chaîne cible. Cette méthode ne fonctionne que si la chaîne cible est une plateforme de contrats intelligents comme Ethereum, et nécessite de déployer au moins un contrat par chaîne pour assurer l’interopérabilité. Elle est donc incompatible avec des chaînes non compatibles contrats intelligents comme Bitcoin. De plus, l’état et la logique applicative sont dispersés de façon distribuée entre tous ces contrats, rendant la synchronisation d’état entre chaînes coûteuse, lente, et compliquant la gestion des restaurations. Pour résoudre ces problèmes, Zetachain introduit le mécanisme de contrat intelligent Omnichain.
E.2 Mécanisme de contrat intelligent Omnichain
Le contrat intelligent Omnichain est une méthode proposée par ZetaChain pour simplifier le traitement de l’interopérabilité cross-chain. Il traite les messages cross-chain et réalise l’interopérabilité selon les étapes suivantes :
1. Réception des actifs : l’utilisateur envoie des actifs locaux (ex. jetons ERC20) vers l’adresse TSS sur la chaîne A, accompagnés d’un message spécifiant [zEVMContractAddress, message]. L’adresse TSS peut être un contrat dédié à la conservation de jetons ERC20.
2. Observation et rapport : les observateurs de ZetaChain (zetaclients) détectent cet appel cross-chain imminent et le signalent à zetacore.
3. Appel et exécution : zetacore appelle la fonction `depositAndCall()` du SystemContract, qui appelle ensuite la fonction `onCrossChainCall()` du zEVMContractAddress spécifié. Pendant cet appel : - Le paramètre `zrc20` est rempli avec l’adresse du contrat ZRC20 gérant les jetons étrangers envoyés par l’utilisateur à l’étape 1. - Le paramètre `amount` est rempli avec la quantité de jetons envoyée. - Le paramètre `message` contient le message inclus par l’utilisateur dans le mémo de transaction.
4. Exécution de la logique du contrat : le contrat intelligent omnichain est invoqué via `zContract(zEVMContractAddress).onCrossChainCall(zrc20, amount, message)`. Le contrat applicatif doit implémenter sa logique métier dans la fonction `onCrossChainCall()`.
5. Traitement du résultat d’exécution :
- Si l’exécution réussit sans sortie d’actifs externes, l’interaction est terminée.
- Si le contrat zEVM échoue (rollback), un CCTX est créé pour annuler la transaction entrante, remboursant à l’utilisateur la même quantité de jetons étrangers (frais déduits).
- Si `onCrossChainCall()` produit une sortie (ex. déclenche un retrait ZRC20), un nouveau CCTX est créé pour guider et suivre le transfert des actifs étrangers vers l’adresse spécifiée sur la chaîne externe. Ces retraits sont généralement de simples transferts de jetons.
Les caractéristiques marquantes du contrat intelligent Omnichain sont :
- Il est déployé uniquement sur zEVM, concentrant toute la logique et l’état en un seul endroit, simplifiant grandement le développement et la maintenance.
- Il ne nécessite aucun déploiement de contrat intelligent sur les chaînes externes, permettant ainsi de supporter des chaînes non compatibles contrats intelligents comme Bitcoin.
- Comme toutes les opérations de restauration sont gérées par le protocole ZetaChain, le contrat applicatif n’a pas à implémenter de logique de restauration.
En résumé, à l’exception de quelques informations minimales échangées entre ZetaCore et ZetaClient, toutes les règles de traitement des informations cross-chain sont écrites dans les contrats intelligents de Zetachain lui-même. Dès lors qu’un utilisateur envoie un transfert avec message attaché vers une adresse désignée sur la chaîne cible, cela déclenche automatiquement une opération cross-chain dans un contrat intelligent de Zetachain.
Les dApps plus complexes peuvent préférer les contrats intelligents Omnichain, car la logique et l’état sont centralisés, contrairement aux méthodes classiques où les messages et l’état doivent être diffusés entre chaînes, augmentant les surfaces d’attaque et les frais de gaz (chaque message coûtant du gaz supplémentaire, et le nombre de messages augmentant pour maintenir une synchronisation complète). Autrement dit, pour les développeurs, le comportement du contrat intelligent Omnichain est comme si tous les actifs étaient sur une seule chaîne (voir image ci-dessous).
F. Mécanisme de signature et d’autorisation de Zetachain
Le mécanisme de signature et d’autorisation de ZetaChain repose sur un schéma avancé de signature de seuil (Threshold Signature Scheme, TSS), qui résout efficacement le problème du point de défaillance unique et renforce la sécurité globale du système.
1. Schéma de signature de seuil : ZetaChain utilise un TSS basé sur le calcul multipartite (Multi-Party Computation, MPC), permettant à plusieurs validateurs de gérer conjointement une clé privée ECDSA/EdDSA unique, sans qu’aucune entité individuelle ou petit groupe ne la possède entièrement. Cette approche combine commodité d’un portef
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@hiCaptainZ
