Le futur de l’écosystème “blockchain” ne se limitera pas à une seule blockchain. Dans le cas de Cosmos, sa blockchain et sa communauté ont reconnu, dès le début, le potentiel et la nécessité d'un écosystème blockchain davantage connecté. S'appuyant sur le SDK Cosmos, un écosystème florissant de blockchains “souveraines” continue d'émerger (dYdX v4, Osmosis, Juno, EVMOS, THORChain, etc.). D'autres projets comparables existent également, notamment Polkadot et son système de relais- chaînes/para-chaînes. Une différence importante entre les deux réside dans le modèle de “sécurité partagée” de Polkadot par rapport au modèle de “concentrateur-routeur” de Cosmos.
De notre point de vue, nous estimons que Cosmos offre une conception plus avant-gardiste, qui a largement inspiré ZetaChain, une blockchain L1 décentralisée et transparente. ZetaChain s'efforce de parvenir à une interopérabilité totale grâce à sa plate-forme intelligente de contrats inter-chaînes intégrée et à sa programmabilité flexible. Dans cet article, nous examinerons brièvement l'approche de Cosmos en matière d'interopérabilité des blockchains, en particulier son protocole de communication inter-blockchain (IBC). Nous verrons ensuite comment ZetaChain fait évoluer Cosmos IBC pour favoriser une interopérabilité omni-chaîne totale avec n'importe quelle chaîne existante.
Examinons comment les informations circulent à travers les blockchains tout en mettant en évidence l'approche de Cosmos. Supposons que quelqu'un transmette des événements sur la blockchain “A” vers la blockchain “B”, et que la blockchain “B” est censée agir en conséquence. La question fondamentale est de savoir comment la blockchain “B” saura que cette information est vraie sur la blockchain “A”. Face à cela, trois options se présentent :
La première approche est dite « trustless », ce qui signifie qu'aucune entité de confiance supplémentaire n'est nécessaire en dehors des deux chaînes impliquées, c’est-à-dire les blockchains “A” et “B”. C'est la situation idéale, mais ce n'est pas toujours le cas. Par exemple, il semble que l'échange atomique soit jusqu'à présent la seule technique qui fonctionne de la sorte, et elle est loin de prendre en charge une logique inter-chaînes arbitraire.
La deuxième approche est également « trustless » et est plutôt répandue. C'est l'approche adoptée par Cosmos IBC. La solution IBC est bien intégrée à Cosmos SDK en tant que module, et deux chaînes utilisant le moteur de consensus Tendermint et mettant en œuvre la fonctionnalité IBC sont en mesure de vérifier les transactions de l'autre tout comme un logiciel client. Il convient de noter qu'un logiciel client ne stocke que des données minimales sur une blockchain, en s'appuyant sur la disponibilité des données complètes de la blockchain sur d'autres nœuds complets. S'agissant de Cosmos IBC, vous pouvez le considérer comme un logiciel client intégré aux règles de consensus. L'inconvénient évident est que pour utiliser IBC, les blockchains doivent utiliser son moteur de consensus particulier (Tendermint) et mettre en œuvre IBC dans son noyau. Cela signifie qu'en pratique, seules les chaînes Cosmos ou les nouvelles blockchains peuvent être intégrées.
La troisième approche fondée sur la confiance est encore plus généralisée. Elle ne nécessite pas de modification ou d'adaptation de la blockchain “A” ou “B”. Elle a juste besoin d'un tiers de confiance. Il peut s'agir d'une entité centralisée (comme un échange centralisé, ou Quant OverLedger), ou d'une entité décentralisée (une blockchain dans le cas de THORChain, ou un ensemble de validateurs comme Wormhole).
ZetaChain combine l'approche de la Vérification du logiciel client et du Tiers de confiance pour fournir une programmabilité inter-chaînes décentralisée, sécurisée et polyvalente. En clair :
Nous pensons que l'approche de ZetaChain combine le meilleur de toutes les approches - décentralisée, « trustless », indépendante de la chaîne et généralement programmable. Par exemple, les votes/la tenue du registre PoS sont résistants aux attaques extrinsèques lancées contre les logiciels clients, mais vulnérables aux attaques intrinsèques (1/3 ou 2/3 des attaques contre les enjeux du validateur ZETA). Il est en général un peu plus facile de s'attaquer aux logiciels clients plutôt qu'aux nœuds complets. En revanche, le logiciel client est résistant aux attaques intrinsèques, mais vulnérable aux attaques extrinsèques visant à tromper les logiciels clients des blockchains connectées (Ethereum, Binance Smart Chain, Bitcoin, etc.). La combinaison de la tenue de registre (notarization) et des logiciels clients permet d'obtenir une sécurité maximale. En raison de la complexité des logiciels clients dans la machine à états, ZetaChain reposera initialement sur la tenue de registre (notarization) PoS. Puis, au fil du temps, il intégrera progressivement les logiciels clients « trustless » dans sa machine à états.