Démo PIECHAIN : Explorer un cadre pratique d'interopérabilité de la blockchain

Auteurs: (1) Daniel Reijsbergen, Université technologique de Nanyang, Singapour, Singapour ; (2) Aung Maw, Université de technologie et de design de Singapour, Singapour, Singapour ; (3) Jingchi Zhang, Université technologique de Nanyang, Singapour, Singapour ; (4) Tien Tuan Anh Dinh, Université Deakin, Melbourne, Australie ; (5) Anwitaman Datta, Université technologique de Nanyang, Singapour, Singapour. Aperçu du contenu Résumé et introduction Présentation de PIEChain Implémentation de PIEChain Plan de démonstration Rallonges Les références Abstrait Une multitude de plateformes blockchain différentes ont vu le jour ces dernières années, mais nombre d’entre elles fonctionnent en silos. En tant que tel, une communication inter-chaînes fiable est nécessaire pour permettre l’interopérabilité de la blockchain. L'interopérabilité de la blockchain est un défi car les transactions ne peuvent généralement pas être annulées. Ainsi, si une transaction est validée, le protocole doit garantir que toutes les transactions associées le sont également. Les approches d'interopérabilité existantes, par exemple Cosmos et Polkadot, sont limitées dans le sens où elles ne prennent en charge l'interopérabilité qu'entre leurs propres sous-chaînes ou nécessitent des modifications intrusives des blockchains existantes. Pour surmonter cette limitation, nous proposons PIECHAIN, un cadre de communication inter-chaînes général basé sur Kafka. Nous utilisons PIECHAIN pour une étude de cas pratique : une vente aux enchères inter-chaînes dans laquelle les utilisateurs détenant des jetons sur plusieurs chaînes enchérissent pour un billet vendu sur une autre chaîne. PIECHAIN est la première mise en œuvre pratique et accessible au public d'un cadre général pour la communication inter-chaînes. INTRODUCTION Une blockchain est une base de données répliquée et inviolable conçue pour les environnements hostiles. Il se compose d'un certain nombre de nœuds, dont certains peuvent être malveillants, qui maintiennent un registre en annexe uniquement. Le grand livre stocke les transactions qui modifient certains états globaux. Dans l'exemple canonique, c'est-à-dire les crypto-monnaies [7], les états globaux sont les comptes d'utilisateurs et les jetons natifs (fongibles), et le grand livre contient les transactions transférant les jetons d'un compte à un autre. Dans une autre application émergente, les blockchains stockent des jetons non fongibles (NFT) représentant de manière unique des actifs, par exemple des œuvres d'art numériques ou des billets de concert. De nombreuses blockchains prennent également en charge les contrats intelligents permettant aux utilisateurs de définir leurs propres états et codes qui modifient les états. Les contrats intelligents sont stockés dans le grand livre et sont répliqués et maintenus cohérents par tous les nœuds de la blockchain. Ces dernières années, de nombreuses plateformes indépendantes de blockchain ont vu le jour, donnant naissance à un écosystème à longue traîne. D’une part, il existe un petit nombre de plateformes blockchain à usage général extrêmement populaires, telles qu’Ethereum et Hyperledger. D’un autre côté, il existe des milliers de blockchains plus petites conçues pour des applications spécifiques, dont la plupart n’en sont qu’aux premiers stades de développement. Cela comprend plus de 10 000 crypto-monnaies [3] début 2023, ainsi que des blockchains pour les soins de santé, la gestion des identités et l’IoT. En général, ces blockchains n’interagissent pas, c’est-à-dire qu’elles existent en silos. Ainsi, l’interopérabilité des blockchains, c’est-à-dire la possibilité pour les utilisateurs d’échanger des informations ou des actifs sur différentes blockchains, est un sujet qui suscite un intérêt croissant de la part de la communauté des chercheurs [6], [10], [4], [1], [ 11]. L’un des principaux défis dans la conception d’un cadre d’interopérabilité sécurisé de la blockchain est de garantir l’atomicité, c’est-à-dire que soit toutes les étapes d’un ensemble convenu de transactions se terminent avec succès, soit aucune ne se termine. C’est plus compliqué dans les blockchains que dans les bases de données traditionnelles car les transactions blockchain sont (en principe) irréversibles. Par exemple, si un paiement pour un NFT sur la chaîne A a déjà été effectué sur la chaîne B, alors l'atomicité exige que la transaction sur la chaîne A se poursuive car la transaction sur la chaîne B ne peut pas être annulée. Une approche courante pour garantir l'atomicité consiste à déposer tous les jetons impliqués dans la transaction dans des contrats intelligents et à les libérer uniquement via un message de validation signé par toutes les parties [6]. Un autre défi important de l’interopérabilité de la blockchain est de garantir la vivacité, de sorte que les jetons déposés ne puissent pas être gelés pour toujours. Pour garantir la vivacité, les nœuds doivent pouvoir envoyer un message d'abandon permettant à toutes les parties de retirer leurs actifs du séquestre. Pour garantir à la fois l’atomicité et la vivacité, un cadre d’interopérabilité doit être capable de tolérer des nœuds contradictoires qui envoient un message de validation à une blockchain et un message d’abandon à une autre. Il est connu que pour les réseaux asynchrones (c'est-à-dire où il n'y a pas de limite sur les délais de message), cela est impossible à réaliser sans un tiers de confiance (TTP) [10]. Il existe deux approches principales pour surmonter ce défi [6]. La première approche consiste à combiner une hypothèse de synchronisation avec une période de refroidissement pour les abandons – c'est-à-dire en supposant qu'un vote de validation, une fois généré, peut être ajouté à toutes les blockchains concernées avant la fin de toute période de refroidissement pour les abandons. Cette approche est adoptée, par exemple, dans les contrats hachés et verrouillés [5]. La deuxième approche consiste à remplacer le TTP par une autre blockchain pour garantir qu'un message de validation ou d'abandon valide puisse être créé, mais pas les deux [6], [9]. Bien que des approches des deux types aient été proposées dans la littérature scientifique, soit elles n'ont pas de mise en œuvre accessible au public [5], [6], [9], ou sont limitées dans leur champ d'application, par exemple la création d'actifs adossés sur une autre blockchain. [11] ou des échanges de jetons [8]. Dans un développement distinct, plusieurs plates-formes blockchain ont émergé qui permettent l'interopérabilité par défaut, par exemple Cosmos et Polkadot. Cependant, ces plates-formes ne prennent en charge l’interopérabilité qu’entre leurs propres sous-chaînes ou nécessitent des modifications intrusives des blockchains existantes. Cela justifie la nécessité d’un cadre d’interopérabilité général et pratique pouvant être interfacé aux plateformes blockchain existantes sans les modifier. Notre objectif est de fournir un tel cadre. : Nous présentons PIECHAIN pour atteindre cet objectif. La synchronisation étant difficile à assumer en pratique, PIECHAIN utilise des services cross-chain pour remplacer le TTP. Les services inter-chaînes communiquent à l'aide d'un journal d'événements qui utilise le protocole Kafka d'Apache pour plus d'efficacité. Pour démontrer la pertinence pratique de PIECHAIN, nous avons mis en place un service cross-chain pour une étude de cas réaliste : une enchère cross-chain. Nous avons interfacé PIECHAIN avec certaines des plateformes blockchain les plus populaires prenant en charge les contrats intelligents : Ethereum, Hyperledger Fabric et Quorum. Enfin, nous avons développé une interface graphique pour notre étude de cas. L'étude de cas d'enchères est l'une des trois études de cas (deux enchères et un prêt flash [6]) dont le code peut être trouvé dans le référentiel de codes PIEChain sur GitHub. Apports & Nouveauté II. APERÇU DE PIECHAIN A. Entités Les principales entités de PIECHAIN sont les suivantes (voir aussi Figure 1) : Les blockchains, qui stockent les actifs (par exemple, les jetons, les clés) détenus par les utilisateurs. Un utilisateur peut détenir des actifs sur plusieurs blockchains. Chaque blockchain a son propre protocole pour déterminer qui a un accès en lecture et en écriture – les blockchains sont généralement soit autorisées, c'est-à-dire qu'un ensemble fixe de nœuds a un accès en lecture et en écriture, soit sans autorisation, c'est-à-dire que tout le monde a un accès en lecture et peut créer des transactions, et des nœuds. avec suffisamment de puissance (par exemple, vitesse de traitement) peut ajouter des transactions à la blockchain. Services inter-chaînes (CC-SVC), qui permettent aux utilisateurs d'échanger des actifs sur différentes blockchains. Chaque CC-SVC se compose d'un serveur qui interagit avec les clients utilisateurs pour faciliter la communication inter-chaînes. En pratique, le CC-SVC facture la participation des utilisateurs et peut interagir avec n'importe quel nombre de blockchains. Dans ce qui suit, chaque CC-SVC correspond à un ensemble d'événements impliqués dans un échange atomique d'actifs qui sont envoyés par un serveur au grand livre Kafka. En pratique, un seul serveur peut exploiter plusieurs CC-SVC. Le réseau Kafka, qui sert de journal en annexe uniquement des événements générés par les CC-SVC. Les événements correspondent aux transactions effectuées sur les blockchains sous-jacentes. Le réseau Kafka est exploité par un ensemble fixe de nœuds qui facturent aux CCSVC le téléchargement d'événements. Dans PIECHAIN, nous supposons que les CC-SVC sont semi-fiables et qu'ils sont motivés à se comporter honnêtement en ayant une réputation à défendre, à l'instar des prestataires de services commerciaux externalisés. Les opérateurs du réseau Kafka ne sont pas fiables mais ne sont pas incités à se comporter mal car ils n'interagissent pas avec les blockchains sous-jacentes. Cela nous permet d'exécuter un protocole (Kafka) qui donne la priorité à l'efficacité plutôt qu'à la sécurité. Une conception alternative consiste à rendre les CC-SVC non fiables et le réseau Kafka fiable. Dans ce cas, chaque nœud Kafka exécute un client (léger) pour chacune des blockchains sous-jacentes afin de valider l'inclusion des transactions sur ces chaînes. Dans ce cas, le journal des événements devrait utiliser un protocole plus sécurisé tel que PBFT [2]. Nous laissons une telle conception comme travail futur. B. Flux de processus Compte tenu des entités de la section II-A, le flux de processus dans PIECHAIN a la même structure que les transactions inter-chaînes proposées par Herlihy et al. [6]. Les transactions inter-chaînes sont des accords conclus par plusieurs utilisateurs pour échanger des actifs sur différentes blockchains et se composent de cinq phases (voir également la figure 2) : Phase de compensation : le CC-SVC crée les contrats intelligents sur les différentes blockchains qui sont utilisés pour déposer et transférer les actifs impliqués dans la transaction. Phase Escrow : les utilisateurs séquestrent leurs actifs sortants en les transférant vers les contrats intelligents. Phase de transfert : les actifs sont provisoirement échangés, c'est-à-dire que la logique d'exécution des contrats intelligents est précisée. Phase de validation : chaque utilisateur vérifie si le résultat de la logique d'exécution lui conviendrait. Phase d'engagement : l'accord est conclu par engagement si toutes les parties sont satisfaites, ou par avortement dans le cas contraire. L'engagement signifie que la logique d'exécution des contrats intelligents est exécutée et que les actifs sont échangés comme spécifié par la transaction. L'avortement signifie que les actifs de chaque contrat intelligent sont restitués à leurs propriétaires d'origine. Pour valider, les utilisateurs construisent de manière interactive un vote de validation, qui est envoyé par le CC-SVC au grand livre Kafka. Pour abandonner, un seul utilisateur envoie un message d'abandon au CC-SVC. Pour chaque CC-SVC, un message de validation ou d'abandon peut être ajouté au grand livre Kafka, mais pas les deux. Une preuve d'inclusion d'un vote de validation sur le grand livre Kafka est acceptée par tous les contrats intelligents sur les différentes blockchains – cela garantit qu'une fois le vote de validation construit, soit tous les transferts d'actifs peuvent être exécutés, soit aucun. III. MISE EN ŒUVRE DE PIECHAIN Pour illustrer l'applicabilité pratique de PIECHAIN, nous l'avons interfacé à plusieurs plateformes blockchain couramment utilisées et l'avons utilisé pour mettre en œuvre une application issue de la littérature scientifique [6] : une enchère cross-chain pour un actif numérique. La prise en charge de la blockchain s'étend à d'autres études de cas, comme nous l'expliquons dans la section V. A. Prise en charge de la blockchain Pour interfacer une blockchain sous-jacente avec PIECHAIN, les CC-SVC doivent être capables de valider les transactions sur ces chaînes. Notre implémentation prend en charge les plates-formes blockchain suivantes : Ethereum (les versions Proof-of-Work et Proof-ofAuthority d'Ethereum privé), Hyperledger Fabric et Quorum. Ces deux derniers prennent en charge les blockchains autorisées, tandis qu'Ethereum possède une chaîne principale sans autorisation mais prend également en charge les chaînes privées avec les mêmes fonctionnalités. B. Vente aux enchères Dans notre étude de cas, un commissaire-priseur vend un actif sur une blockchain et reçoit un paiement sous forme d’actifs sur une autre blockchain. Comme dans [6], nous prenons l’exemple d’un vendeur de billets. Le ticket est un NFT sur une blockchain dédiée, tandis que l'autre blockchain prend en charge les jetons fongibles les plus couramment utilisés (par exemple, Ether). La première blockchain est appelée blockchain de tickets et la seconde blockchain de pièces de monnaie. Ceci est facilement généralisable aux paramètres comportant plusieurs blockchains de pièces. Dans ce qui suit, nous considérons une vente aux enchères au premier prix (c'est-à-dire que l'enchérisseur ayant l'offre la plus élevée paie son offre et reçoit l'actif). Les cinq phases du protocole sont alors les suivantes : Le commissaire-priseur fait appel à un CC-SVC qui crée des contrats intelligents sur la blockchain de tickets et les blockchains de pièces. Le commissaire-priseur transfère son actif (le NFT du billet) vers le contrat de billet, et les enchérisseurs transfèrent leurs offres vers le contrat sur leur blockchain de pièces. La logique d'exécution est déterminée : le commissaire-priseur met à jour chacun des contrats de billets et de pièces en précisant quelle partie reçoit le billet et quelle enchère est transférée au commissaire-priseur. (Notez que cette logique ne peut pas être spécifiée a priori dans le contrat de ticket car le contrat sur la chaîne de tickets ne peut pas lire les données des blockchains de pièces.) Chaque utilisateur (c'est-à-dire le commissaire-priseur et les enchérisseurs) détermine si le résultat du protocole de transfert lui convient, c'est-à-dire si le billet est effectivement transféré à la bonne partie. Tous les utilisateurs construisent un vote de validation – une fois celui-ci construit, il est envoyé à chaque contrat pour effectuer les transferts spécifiés dans la phase de transfert. Dans PIECHAIN, l'enchère nécessite deux types (logiques) de CC-SVC : le relais et le signataire. Le relais écoute les événements (offres) sur les chaînes de pièces et les relaie vers la blockchain de tickets. Le signataire aide à créer le vote de validation. IV. PLAN DE DÉMONSTRATION Pour notre démonstration, nous avons développé une interface utilisateur graphique (GUI) utilisant le framework React pour illustrer une enchère inter-chaînes. L'interface graphique se compose de trois pages principales : une page de tableau de bord qui affiche une liste des enchères connues comme illustré dans la figure 3, une vue détaillée des enchères individuelles comme illustré dans la figure 5 et une page pour la création de nouvelles enchères (non affichée). Le point de vue est le même pour un commissaire-priseur et pour les enchérisseurs. Sur la vue du tableau de bord, les commissaires-priseurs potentiels peuvent cliquer sur le bouton « Créer une nouvelle vente aux enchères » pour lancer une vente aux enchères : le commissaire-priseur sélectionne un CC-SVC, l'actif à mettre aux enchères, les autres blockchains à partir desquelles accepter les offres, le taux de change des jetons entre les différentes blockchains (qui doivent être fixées à l'avance) et l'heure à laquelle l'enchère est conclue. Ensuite, le relais CC-SVC crée les contrats concernés, et envoie l'adresse du contrat sur la chaîne d'actifs au commissaire-priseur. Le commissaire-priseur peut ensuite ajouter l'enchère sur son tableau de bord en ajoutant l'adresse du contrat et en cliquant sur le bouton « Ajouter une enchère existante ». Pendant ce temps, il annonce l’adresse du contrat aux soumissionnaires potentiels. Lorsque les soumissionnaires prennent connaissance de l'adresse du contrat d'actif, ils peuvent également l'ajouter à leurs tableaux de bord. Une fois que l'enchérisseur a ajouté l'enchère, il peut la visualiser plus en détail en appuyant sur le bouton « Afficher » dans le panneau de l'enchère, ce qui l'amène à la page de vue détaillée. Sur cette page, l'enchérisseur peut consulter des informations cruciales sur l'enchère telles que ses heures de création et de conclusion, ainsi qu'une liste des offres. L'enchère la plus élevée est marquée d'un astérisque. Si l'enchère est toujours en cours, l'enchérisseur peut ajouter une offre en spécifiant la blockchain. sur lequel l'enchère est faite et le nombre de jetons sur lesquels enchérir. Une transaction est ensuite effectuée vers le contrat de pièces concerné et les informations sont envoyées au relais CC-SVC. Un utilisateur peut également abandonner toute offre qu'il a faite via le CC-SVC. Une fois l'enchère terminée, le relais CC-SVC informe tous les participants et précise la tentative de transfert de marchandises dans les contrats intelligents. Le CC-SVC demande ensuite à tous les clients des participants de participer à la création d'un vote de validation. (Le défaut de participation devrait entraîner une pénalité [4].) Une fois le vote de validation créé, il est envoyé à tous les contrats pour initier le transfert final des actifs. À ce stade, l'interface graphique indiquera que l'enchère est terminée. Le déroulement exact de la démo sera le suivant : Un utilisateur – le commissaire-priseur – ouvre une interface graphique basée sur un navigateur Web et l'utilise pour lancer une vente aux enchères pour un actif sélectionné. Dans ce processus, toutes les fonctionnalités de la page de création d'enchères sont démontrées. L'actif existe sur une chaîne de tickets dédiée s'exécutant dans Hyperledger Fabric. Les contrats sont créés sur toutes les blockchains impliquées (étape 1 de la figure 2. Au moins deux autres utilisateurs, qui utilisent des fenêtres de navigateur sur des machines différentes, accèdent à la page de détails de l'enchère nouvellement créée et soumettent leurs offres individuelles pour l'actif (étape 2 de la figure 2). Au moins un enchérisseur utilise Ethereum (privé) et l’autre utilise Quorum. Après un certain temps, l'enchère est conclue et l'offre gagnante est déterminée (étape 3 de la figure 2). Cela entraînera l'envoi d'un événement de « fin d'enchère » au relais CCSVC par le commissaire-priseur. Les signataires, qui écoutent ce type d'événement, remarqueront l'événement et construiront un vote de validation (étape 4 de la figure 2). Le vote de validation est ensuite envoyé à Kafka et transmis par le nœud relais au contrat d'enchère et aux contrats de chaîne de pièces. À ce stade, l'actif est transféré à l'enchérisseur gagnant et l'offre gagnante au commissaire-priseur (étape 5 de la figure 2). Tout au long de la démo, nous utiliserons une fenêtre de terminal pour interroger les états des blockchains sous-jacentes après chaque étape, comme illustré dans la figure 4. Cela permettra au public d'observer les changements qui se produisent en arrière-plan et d'interagir avec le flux du processus. démonstration : par exemple, en demandant de nouvelles actions pour voir comment les états d'arrière-plan changent. Pour illustrer le déroulement de la démonstration, une vidéo peut être trouvée en ligne 2 qui représente les diapositives de la démonstration provisoire et l'écran si le commissaire-priseur et les enchérisseurs devaient effectuer leurs actions à l'aide d'un seul ordinateur. (Ce n'est pas une limitation de PIECHAIN, mais cela facilite l'enregistrement vidéo.) V. PROLONGATIONS Le framework CC-SVC et l'interface pour les blockchains prises en charge peuvent être utilisés pour étendre facilement PIECHAIN à d'autres cas d'utilisation. L'un d'eux est un prêt flash inter-chaînes comme décrit dans [6]. Une interface graphique pour les prêts flash aurait une pertinence pratique limitée, car les opportunités d'arbitrage sont généralement résolues rapidement, de sorte que les interactions avec le CC-SVC seraient normalement effectuées par des robots de trading. Cependant, si le temps le permet, nous afficherons une visualisation de l'impact des étapes d'un prêt flash sur l'état des différents contrats impliqués. LES RÉFÉRENCES [1] Rafael Belchior, André Vasconcelos, S'ergio Guerreiro et Miguel' Correia. Une enquête sur l'interopérabilité de la blockchain : tendances passées, présentes et futures. Enquêtes informatiques ACM (CSUR), 2021. [2] Miguel Castro et Barbara Liskov. Tolérance aux pannes byzantine pratique. Dans OsDI, volume 99, pages 173-186, 1999. [3] CoinLore. https://www.coinlore.com/all coins, 2023. [4] Daniel Engel, Maurice Herlihy et Yingjie Xue. L’échec est (littéralement) une option : engagement atomique contre optionnalité dans la finance décentralisée. Dans SSS 2021, 2021. [5] Maurice Herlihy. Échanges atomiques entre chaînes. Dans ACM PODC, pages 245 à 254, 2018. [6] Maurice Herlihy, Barbara Liskov et Liuba Shrira. Accords inter-chaînes et commerce contradictoire. Le Journal VLDB, 2021. [7] Satoshi Nakamoto. Bitcoin : un système de paiement électronique peer-to-peer, 2008. [8] Sri Aravinda Krishnan Thyagarajan, Giulio Malavolta et Pedro Moreno-Sanchez. Swaps atomiques universels : échange sécurisé de pièces sur toutes les blockchains. Dans IEEE S&P, 2022. [9] Victor Zakhary, Divyakant Agrawal et Amr El Abbadi. Engagement atomique à travers les blockchains. Actes de la Dotation VLDB, 13(9), 2021. [10] Alexei Zamyatin, Mustafa Al-Bassam, Dionysis Zindros, Eleftherios Kokoris-Kogias, Pedro Moreno-Sanchez, Aggelos Kiayias et William J Knottenbelt. SoK : communication entre les grands livres distribués. Dans Crypto financière, 2021. [11] Alexei Zamyatin, Dominik Harz, Joshua Lind, Panayiotis Panayiotou, Arthur Gervais et William Knottenbelt. Xclaim : actifs sans confiance, interopérables et adossés à des cryptomonnaies. Dans IEEE S&P, 2019. Cet article est sous licence CC 4.0. disponible sur arxiv