Une application de sidechain Horizen : le bridge

par

Après quelques parties un peu techniques, un article plus pratique sur une utilisation possible d’une sidechain Horizen.

Le plan du dossier : Les Sidechains Horizen

  1. Zend_oo, le node de la MainChain Horizen
  2. Création de ma première sidechain
  3. Sidechains : Transférer du ZEN
  4. Un exemple de sidechain : le bridge : Tu es ici 🙂
  5. Bonus : Gagner des ZEN : Le Faucet en détail
  6. Bonus : Monter un secure node ZEN en 20 minutes

Horizen, c’est quoi ?

Horizen est une blockchain. Voyons ce qui la rend spécifique.

  • A l’origine le projet est un fork de ZCash, le ZenCash.
  • Sa monnaie est le ZEN.
  • Le nombre de ZEN maximum est de 21millions de ZEN (Comme Bitcoin).
  • Elle combine la preuve de travail (PoW) et la preuve d’enjeu (PoS).
  • C’est la blockchain qui comporte le plus grand nombre de nodes.
  • Il existe plusieurs « tiers » de nodes HoriZen. Les full nodes simples, qui conservent et s’échangent l’intégralité des données de la blockchain et deux niveaux de masternodes, les Secure Nodes avec un collatéral de 42 ZEN et les Super Nodes avec un collatéral de 500 ZEN.
  • Outre le respect de la vie privée et les technologies qui l’accompagnent (zk-Proof/zk-Snark), le développement principal pour Horizen est la technologie des sidechains.

Plus de lecture au sujet des zk-Proof/zk-Snark :

Les sidechains

Les Sidechains sont l’énorme plus de la blockchain Horizen. On doit même parler d’ecosystème Horizen dès lors que l’on évoque les sidechains. On parle parfois de Layer 0, comme pour Cosmos ou Polkadot par exemple.

Les sidechains sont des blockchains à part entière, à ceci près qu’elles peuvent interagir avec la Mainchain Horizen (on peut faire un parallèle avec les Parachains Polkadot/Kusama si c’est plus clair).

En dehors de cet aspect, elles peuvent être n’importe quoi, servir à n’importe quoi. Gérer de nouveaux tokens, utiliser des consensus différents, apporter des logiques totalement différentes de la blockchain principale.

Dans le Zendoo SDK, Horizen a développé un modèle de sidechain de base qui intègre un processus de consensus (The Sidechain Consensus Protocol – SCP). Libre à chacun de l’utiliser ou pas.

Au dela du SCP, les sidechains doivent implémenter le protocole de transfert cross-chain (The Cross-Chain Transfer Protocol – CCTP).

L’implémentation de sidechain fournie par le Zendoo SDK intègre bien évidemment aussi le CCTP.

Plus de détails sur les sidechains, le SCP et les CCTP ici :

Pour s’immerger dans le code des Sidechains, c’est ici :

Utilité des sidechains

Bien, une fois cela compris, à quoi peuvent servir les sidechains ?

  • A apporter de la scalabilité en divisant les opérations de plusieurs types sur plusieurs sidechains différentes.
  • A apporter des fonctionnalités supplémentaires. Chaque sidechain est libre d’implémenter la logique de son choix. Horizen prévoit d’en créer une pour la tokenisation, une pour la gestion de la trésorerie, une pour les transferts rapides, etc. Il existe également une sidechain en collaboration avec Celsius pour l’audit des opérations réalisées avec les fonds des utilisateurs, une autre avec le Bored Apes Yacht Club pour la préparation de l’émission de leur token propre et le lancement de leur jeu P2E.

Et ce ne sont que quelques exemples. Concrètement, l’idée est de déployer une sidechain par application qui le nécessite.

Un autre projet serait par exemple de créer une sidechain hébergeant une VM (machine virtuelle, comme sur Ethereum par exemple). Cette VM pourrait alors exécuter des smart contracts et permettrait aux développeurs de sortir de nouvelles application sur l’écosystème Horizen sans toutefois devoir créer une sidechain.

Une Sidechain : Le bridge

Je vais prendre un exemple concret d’application et voir comment cela pourrait se mettre en place sous forme de sidechain.

L’utilisation des ZEN est limitée à la blockchain Horizen et prochainement, aux sidechains. Mais on ne peut pas utiliser ses ZEN sur Ethereum par exemple.

Comment serait-il possible de fournir cette possibilité via l’usage d’une sidechain dédiée de façon autonome, rapide et efficace ? En utilisant une sidechain Bridge !

Sidechain bridge : Fonctionnement général

Interface utilisateur

Les utilisateurs un minimum avancés des différentes blockchains sont désormais habitués à utiliser les bridges.
Quelques exemples ci-dessous :

Idéalement, un bridge Horizen devrait être intégré dans Sphere, mais on peut imaginer une extension navigateur permettant de bridger via une page web également.

Toutefois, une intégration propre dans Sphere permettrait notamment aux utilisateurs d’enregistrer leurs addresses de destination pour limiter les erreurs de saisies ultérieures et faciliter la procédure de retour des fonds depuis les autres blockchains.

Fonctionnement de la sidechain bridge

En pratique, comment, cela se passerait-t-il dans un sens ? Puis dans l’autre ?

Tout d’abord 2 points importants à bien garder en mémoire :

  • Les ZEN ne sont jamais détruits. Ils sont bloqués ou débloqués sur la sidechain selon la demande. On ne doit jamais créer ou supprimer des ZEN. Leur nombre est prédéfini par le code de la blockchain Horizen.
  • les eZEN, tokens de la chaîne cible, eux, sont créés ou détruits pour correspondre au montant de ZEN natifs bloqués ou débloqués sur la sidechain tenant le registre du bridge correspondant.

Bridge de ZEN natif vers une chain autre :

ZEN –> eZEN

De quelles données a-t-on besoin en entrée ?
– Une adresse Horizen Mainnet : Elle contient les fonds à migrer en $ZEN sur la mainchain Horizen.
– L’adresse destination sur la blockchain ciblée : l’adresse du wallet de l’utilisateur sur la blockchain cible
– Le montant de $ZEN à transférer entre les chaînes.

Le système doit ici valider la propriété de l’adresse source et le fait que le montant à transférer y est bien disponible.

Vient ensuite le transfert des $ZEN sur la sidechain bridge. Les $ZEN bridgés y resteront bloqués (jamais détruits) jusqu’à leur retour total ou partiel sur la blockchain Horizen principale.

Une fois les $ZEN à transférer bloqués dans la sidechain, le système fait appel à un smartcontract permettant de créer (mint) les assets correspondants sur la chaîne cible et les transfère sur le compte destination fourni.

Suite à cela, l’utilisateur ayant déposé les $ZEN dans la sidechain pour les transférer reçoit en retour :
– un identifiant de transaction attestant du dépôt des $ZEN depuis l’adresse source
– un identifiant de transaction attestant de la création et du transfert des tokens créés sur la chaîne ciblée vers l’adresse de destination
– Le montant des fees

Bridge de chain autre vers ZEN natif :

eZEN –> ZEN

De la même façon que pour le transfert aller, on doit fournir des informations pour rappatrier des $ZEN depuis une blockchain autre vers la mainchain Horizen
– L’adresse contenant les assets sur la blockchain source
– L’adresse de retour des $ZEN sur la Mainchain Horizen
– Le montant de $ZEN à rappatrier.

Il est intéressant ici de noter que l’on peut rappatrier un nombre quelconque de $ZEN sur la mainchain, du moment qu’il est disponible sur l’adresse source de la blockchain source.
Si Pierre et Paul transfèrent chacun 10 $ZEN et que, suite à leurs activités respectives sur la blockchain cible, tout finit dans le wallet de Jacques, rien n’empêche ce dernier de rapatrier 15 $ZEN sur son wallet mainchain et de conserver 5 $ZEN sur une blockchain cible pour les placer en farming par exemple. Il n’y a pas eu création ou destruction de $ZEN, juste un transfert de propriété des tokens. Et le fait que cela se soit passé sur une sidechain importe peu. L’important est le nombre global de $ZEN transférés dans un sens ou dans l’autre, pas les utilisateurs à l’origine de chaque transfert.

Lors de cette transaction retour, l’utilisateur doit pouvoir retrouver :
– un identifiant de transaction attestant du burn des $ZEN sur la chaîne source
– un identifiant de transaction attestant le déblocage sur la sidechain des $ZEN et leur transfert sur la mainchain Horizen vers l’adresse de l’utilisateur sur la mainchain Horizen
– Le montant des fees

Mais pourquoi ?

Entre temps, les eZEN ou ZEN bridgés ont pu être utilisés sur la chaîne cible sur toutes les applications qui y sont disponibles :

  • Swap
  • Farm LP
  • Lending
  • Borrowing

Ces applications ne sont pas disponibles sur la mainchain Horizen et les utilisateurs peuvent avoir leurs habitudes sur d’autres blockchains proposant des applications auxquelles ils sont habitués mais dans lesquelles ils souhaiteraient pouvoir utiliser aussi leurs tokens ZEN.

Les eZEN peuvent également faire l’objet de transferts entre utilisateurs ou être utilisés pour le règlement de services sur la blockchain cible.

Intérêt de la sidechain comme Bridge

Il existe d’autres solutions pour bridger des ZEN, sur Ethereum notamment, par le biais des stZEN par exemple.

Mais l’utilisation d’un système basé sur une sidechain et géré directement par Horizen présente quelques avantages :

  • Système autonome, pas de tiers de confiance
  • Pas de minimum imposé par un prestataire
  • Stockage et Audit possible de tous les transferts entre chains
  • Une application de plus pour les sidechains

A propos des fees

Il y a des frais à payer à plusieurs étapes et sur plusieurs chaînes :

  • Le fonctionnement même de la sidechain implique des frais en $ZEN pour la création de la sidechain ainsi que pour les opérations de transferts, blocage et déblocage de fonds.
  • Le minting, le burn et les transferts des assets sur les chaînes cibles dans la monnaie utilisée pour payer les frais de gas de la chaîne cible.

Il y aurait bien évidemment une réflexion a mener pour déterminer la gestion de ces frais.

  • Une prise en charge totale ou partielle pour encourager le « bridging » des assets, au moins dans un premier temps.
  • Un prélèvement sur le wallet Horizen source.
  • Une déduction du montant des $ZEN bridgés après estimation de la valeur en ZEN.