1

Sidechains : Consensus découplé entre les chaînes

Alberto Garoffolo et Robert Viglione

Horizen - Fondation Zen BlockchainOctobre 2018

Traduit en français par Manon Boudoux et vérifié par Robin Guyard

Résumé

Nous proposons une nouvelle construction de sidechain adaptée pour être compatible avec la blockchain Horizen et conçue pour effectuer des transferts inter-chaînes sécurisés et décentralisés sans nécessiter l’intervention des noeuds de la chaîne principale pour suivre les sidechains et les vérifier. Le régime proposé peut également être adopté pour d’autres systèmes de blockchain similaires. Nous montrons que notre mécanisme de transfert entre les registres est sûr sous certaines conditions.

2

1 Introduction

Le phénomène des cryptomonnaies est apparu en 2008 avec Bitcoin [13], et a depuis gagné beaucoup d’intérêts parmi les experts de différents domaines. Bitcoin a été une première mise en œuvre réussie d’un système de paiement décentralisé basé sur un réseau peer-to-peer. La caractéristique clé de Bitcoin - l’absence d’un contrôle centralisé - est considérée comme une innovation révolutionnaire qui aidera à construire des systèmes financiers plus robustes, équitables et transparents.

Entièrement open-source, Bitcoin a inspiré de nombreux autres systèmes qui s’appuient sur le même principe de base de la décentralisation, mais introduisent beaucoup d’avancées supplémentaires comme les contrats intelligents [6], les paiements privés [21, 12], la gouvernance décentralisée [5], etc. Horizen [8, 19] est un exemple d’un tel système. Tout en conservant la fonctionnalité de base de la blockchain, il introduit une variété de nouvelles fonctionnalités telles que les paiements privés, la gouvernance décentralisée, un réseau robuste de nœuds (Secure Node), etc.

Comme Horizen est basé sur le code source de ZCash qui lui même est basé sur Bitcoin, il conserve toutes les contraintes présentes dans le protocole Bitcoin original comme un débit limité, une latence accrue, une capacité réduite à évoluer, etc. [1]. Ce qui est encore plus important, c’est que ces systèmes décentralisés sont très inertes au changement puisqu’il n’y a pas une seule entité pour décider des mises à jour. Même une infime modification du protocole nécessite un processus d’accord lourd entre les participants de la communauté, ce qui rend l’introduction de nouvelles fonctionnalités très difficile.

Ces problèmes ont forcé les chercheurs à chercher des solutions possibles qui permettraient d’atténuer ces contraintes. L’une des plus attrayantes, appelée sidechains, a été présentée par A. Back et al. en 2014 [2]. L’approche des sidechains permet d’améliorer un système de blockchain existant sans pour autant modifier le système lui-même. L’idée de base est simple mais puissante : construire une chaîne parallèle avec toutes les caractéristiques nécessaires et fournir un moyen de transférer de la valeur, ou des coins, entre ces chaînes (voir figure 1.1).

Graphique 1.1 : Concept de base d’une sidechain. Les utilisateurs sont autorisés à transférer des coins entre la chaîne principale et une sidechain pour obtenir les fonctionnalités nécessaires

Ainsi, par exemple, un système de blockchain comme Bitcoin, qui ne supporte pas nativement les smart-contracts (contrats intelligents), peut être étendu avec une telle fonctionnalité en utilisant l’approche de la sidechain [15]. En fait, n’importe quel nombre de sidechains peut être déployé avec différentes caractéristiques et propriétés, tandis que la chaîne principale reste intacte. La partie la plus cruciale et la plus controversée dans le design de la sidechain est le mécanisme de transfert de coin (2-way peg ou simplement

3

2WP). Les architectures de sidechain existantes offrent différentes façons de mettre en œuvre des 2-way peg avec des propriétés et des compromis différents. Dans cet article, nous proposons une nouvelle construction de sidechain conçue pour être compatible avec la blockchain Horizen (mais en fait, elle peut également être adoptée pour d’autres systèmes de blockchain) et conçue pour effectuer des transferts inter-chaînes sécurisés et décentralisés sans que les nœuds de la chaîne principale aient à suivre une sidechain pour les vérifier. La construction de la sidechain proposée nécessite des modifications au protocole de consensus de base de la chaîne principale pour permettre les transferts entre chaînes, mais une fois mise en œuvre, elle permettra de déployer de nombreuses sidechains de manière fiable. Le document est structuré de la manière suivante : La section 1.1 donne un aperçu des développements existants dans ce domaine. La section 2 fournit des informations plus détaillées sur la nécessité des sidechains dans Horizen et les exigences de base pour sa construction. La section 3 fournit des détails techniques détaillés sur la construction proposée.

1.1 Travaux connexes

Le concept de sidechains a été introduit pour la première fois par A.Back et al. en 2014 [2]. Cet article a introduit une notion générale de 2-way peg et décrit deux modes opérationnels - synchrone et asynchrone - pour mettre en œuvre les interactions entre les chaînes rattachées. Le mode synchrone implique que les chaînes principales et secondaires se connaissent et peuvent vérifier directement les transactions de transfert, tandis que le mode asynchrone repose sur des validateurs pour traiter les transferts. Une mise en œuvre remarquable du concept général a été présentée dans [17, 11] et appelée Drivechains. Il vise à déployer des sidechains sur le réseau Bitcoin. Alors que les transferts vers l’avant (de la chaîne principale à une sidechain) sont traités en fournissant des preuves SPV de la chaîne principale (comme le mode synchrone dans [2]), les transferts vers l’arrière reposent sur des validateurs. Les validateurs de la proposition Drivechain sont les mineurs de la chaîne principale qui doivent traquer la sidechain et approuver les transferts.

A. Kiayias et D. Zindros, dans leur présentation[9], ont proposé une mise en œuvre de l’initiative de la sidechain pour les blockchain en de preuve du travail en s’appuyant sur des contrats intelligents. Une autre construction de sidechain notable qui s’appuie sur les contrats intelligents est appelée Plasma et a été présentée dans [14] par J. Poon et V. Buterin. Au contraire, notre construction ne s’appuie pas sur la technologie des smart contracts pour fournir un 2-way peg. Il y a eu beaucoup d’autres tentatives pour construire des mécanismes de transfert inter-chaînes, y compris le projet Liquid [4], Polkadot [20], Interledger [18], Cosmos [3] et bien d’autres. Ils proposent différentes solutions pour mettre en place des 2-way peg différents de notre construction et qui s’adressent principalement aux blockchains privées et aux transferts fédérés.

2 Préliminaires

Le système de blockchain Horizen a une feuille de route étendue avec une variété de nouvelles fonctionnalités telles qu’un système de trésorerie pour la gouvernance décentralisée des ressources [22], un réseau de paiement décentralisé pour les nœuds sécurisés et les super nœuds (Secure Node & Super Node), etc. Certaines de ces fonctionnalités nécessitent d’importantes modifications du client principal, qui, si elles sont mises en œuvre directement dans la base de code existante, pourraient avoir de sérieux inconvénients :

1. Croissance continue de l’application monolithique qui gonfle l’architecture globale et complique l’introduction de nouvelles fonctionnalités.

2. La base de code C++ existante est assez complexe à modifier.

3. L’intégration d’une nouvelle fonctionnalité dans le client principal comporte des risques de sécurité.

4. Un hardfork ou un softfork est nécessaire pour changer le protocole de consensus qui ne peut pas être fait en raison d’un processus encombrant pour l’accord de la communauté.

5. Limites de débit et de latence du protocole de base consensuel.

4

6. Flexibilité limitée pour introduire de nouvelles fonctionnalités (par exemple, il est difficile de remplacer un protocole de consensus existant par un protocole basé sur DAG pour permettre des transactions rapides).

Pour ces raisons, il a été décidé d’opter pour une approche en sidechain pour l’intégration de nouvelles fonctionnalités. C’est l’une des approches les plus attrayantes car elle permet de surmonter au moins les contraintes suivantes :

1. Une implémentation de sidechain est complètement découplée de la chaîne principale, donc aucune modification du client principal n’est nécessaire (à l’exception de l’implémentation initiale du support des sidechains qui n’est faite qu’une fois). Une sidechain peut utiliser n’importe quelle technologie adaptée à l’implémentation de son grand livre distribué, la chaîne principale n’a pas besoin d’en connaître l’existence.

2. Les impacts possibles sur la sécurité en cas d’implémentation incorrecte des fonctionnalités de la sidechain sont limités à l’intérieur de la sidechain et sont limités à l’équilibre de la sidechain dans la chaîne principale.

3. Un seul hardfork du protocole de consensus de base est nécessaire (pour permettre les sidechains). La nouvelle sidechain peut être déployée de manière transparente sans changer le réseau principal. De plus, l’approche de la sidechain permet généralement beaucoup plus de flexibilité. Il peut ouvrir la voie à l’intégration fiable d’une variété de nouvelles fonctionnalités (par exemple, des contrats simples ou intelligents, des transactions rapides, etc...).

2.1 Exigences pour les sidechains Horizen

Compte tenu des contraintes susmentionnées, nous pouvons esquisser les principales exigences de l’architecture des sidechains Horizen :

La chaîne principale doit être agnostique par rapport aux sidechains. Les nœuds de la chaîne principale ne devraient pas être tenus de traquer une sidechain. Seuls les transferts inter-chaînes sont connus et vérifiés par la chaîne principale, mais pour les vérifier, il devrait suffire de traquer uniquement la chaîne principale.

Les transferts inter-chaînes unifiés. Tous les transferts transversaux doivent utiliser le même protocole unifié de transfert inter-chaînes (CCT: Cross Chain Transfer) que celui connu par la chaîne principale. Même si les participants au protocole du CCT seront différents pour les différentes sidechains, la procédure devrait être spécifiée par le protocole de consensus de la chaîne principale. Une telle unification permettra au système de déployer de nombreuses sidechains sans avoir besoin de modifier le protocole de consensus de la chaîne principale pour chacune d’entre elles séparément.

Flexibilité de choisir un protocole de consensus Sidechain. Tout protocole de consensus de la sidechain peut être différent de celui utilisé par la chaîne principale. En général, la chaîne principale ne devrait pas se fonder sur des hypothèses concernant le protocole de consensus de la sidechain ou sa structure. Le consensus sur les transferts inter-chaînes devrait être dissocié du protocole spécifique de consensus de la sidechain.

Sidechains parallèles. L’architecture des sidechains Horizen ne devrait pas limiter le nombre de sidechains déployées simultanément. Toutes les sidechains déployées doivent fonctionner en parallèle de manière totalement indépendante. Les transferts entre chaînes doivent également être totalement indépendants pour les différentes sidechains.

Tolérance aux défaillances. La chaîne principale doit être tolérante aux défaillances de la sidechain (y compris les comportements malveillants). Le risque doit être limité à l’équilibre de la sidechain. Il devrait être impossible de retirer plus de coins de la sidechain qu’auparavant, même dans le cas d’une corruption totale de la sidechain.

Changements mineurs dans le noyau. Les modifications requises dans le noyau Horizen ne devraient pas être trop envahissantes.

5

Il est prévu de développer les sidechains SDK de manière à ce qu’elles fournissent une implémentation prête à l’emploi de la sidechain modèle avec un protocole purement consensuel. Les interfaces doivent être conçues de manière à ce que les principaux composants puissent être facilement remplacés.

3 La construction sidechain

Cette section fournit des détails sur la construction de la sidechain proposée. Nous commençons par définir le modèle abstrait d’une sidechain, puis spécifions les détails des constituants de la structure proposée.

3.1 Vue d’ensemble

En analysant les tentatives existantes pour construire des sidechains [2, 17, 11, 9], nous pouvons esquisser deux composantes majeures de toute structure de sidechain :

1. Protocole de transfert Cross-Chain - CCT (2-way peg)2. Protocole de consensus Sidechain - SCP (Sidechain Consensus Protocol)

La définition de ces deux composants devient cruciale dans la spécification d’une construction exacte de la sidechain. Selon la mise en œuvre, ils peuvent être intégrés dans la chaîne principale ou complètement indépendants de la logique de la chaîne principale.

Dans notre construction, nous découplons ces composants. Le protocole CCT doit être unifié et fixé par la logique de la chaîne principale, de sorte que toutes les sidechains utilisent le même protocole CCT. Le protocole SCP sera complètement découplé de la logique CCT et de la chaîne principale en général, de sorte qu’un développeur de sidechain est libre de choisir le protocole SCP en fonction de ses besoins et préférences.

Même si le protocole SCP peut varier selon les différentes sidechains, nous allons fournir une construction de référence.

Protocole de transfert inter-chaînes. Le protocole CCT définit la structure 2-way peg, il se compose donc de deux sous-protocoles. La première définit une procédure de transfert vers l’avant et l’autre une procédure de transfert vers l’arrière. Un transfert vers l’avant transmet les coins de la chaîne principale (MC: MainChain) à la SideChain (SC). Un transfert vers l’arrière permet de retransmettre les coins de la SC à la MC.

Le protocole CCT est la partie la plus importante de la construction de la sidechain, car il définit la structure globale des communications entre la MC et la SC. Les transferts vers l’arrière sont particulièrement importants, car la MC ne suit généralement pas la sidechain et n’est donc pas en mesure de vérifier directement la validité d’un transfert de la SC vers la MC.

Dans notre construction, les transferts vers l’avant seront mis en œuvre au moyen d’une transaction MC spéciale qui brûle les coins dans la MC et fournit des métadonnées qui permettent à un utilisateur de réclamer un montant correspondant de coins dans la SC. Étant donné que le transfert est initié sur la MC et qu’il ne nécessite aucune information supplémentaire de la part de la SC, il peut être facilement validé à la fois par la MC et la SC. La structure des transferts vers l’avant est relativement simple dans ce cas.

Une procédure plus complexe est nécessaire pour les transferts vers l’arrière. Ils sont initiés dans la SC, puis propagés dans la chaîne principale tout en brûlant la quantité correspondante de coins sur la SC et en les recréant sur la MC. Étant donné que la MC ne suit pas la SC, elle ne peut pas vérifier directement la validité de ces transferts vers l’arrière. Afin de conserver la capacité de la MC à valider les transferts vers l’arrière, nous employons un ensemble d’acteurs spéciaux appelés certificateurs qui gèrent la certification de ces transferts. Les certificateurs s’enregistrent eux-mêmes dans la MC en mettant en jeu un nombre particulier de coins. Leur but principal est de suivre la SC, de rassembler tous les transferts vers l’avant dans des certificats, de

6

signer les certificats et de les propager dans la MC. Comme la liste des certificateurs est connue de la MC, les certificats peuvent être facilement vérifiés.

Protocole de consensus de la sidechain. Malgré le fait que le SCP puisse être mis en œuvre de manière indifférente, nous allons fournir une structure de référence. Il est basé sur le schéma proposé dans Ouroboros [10] et modifié pour fournir une liaison avec la blockchain de la chaîne principale. Il suggère également un algorithme de génération aléatoire différent de celui proposé dans Ouroboros.

Dans les sections suivantes, nous fournissons une description détaillée des protocoles mentionnés. Nous commencerons par la description du SCP, puis nous élaborerons le protocole du CCT à partir de cette description.

3.2 Protocole de consensus Sidechain

Pour le protocole de consensus de sidechain, nous avons adopté une version modifiée du protocole de preuve d’enjeu Ouroboros [10]. Son idée principale est que le temps est divisé en époques avec un nombre prédéfini d’intervalles. Chaque slot est attribué à un slot leader qui est autorisé à générer un bloc pendant ce slot. Les slots leaders d’une époque particulière sont choisis au hasard avant le début de l’époque parmi l’ensemble des intervenants de la sidechain (Fig. 3.1). Le protocole fonctionne dans un environnement synchrone où chaque slot prend un certain temps (par exemple 20 secondes).

Époque. Une époque est une séquence des intervalles k successifs à des positions particulières, Epi=(sl0i,sl1i,...slik-1) où k est la longueur prédéfinie de l’époque et i est le numéro de séquence de l’époque.

Slot. Un slot est une période spécifique dans le temps pendant laquelle un slot leader est autorisé à émettre un bloc. Chaque slot a un slot leader correspondant qui est choisi au hasard avant le début de l’époque. Un slot leader peut sauter la génération d’un bloc, et dans ce cas, le bloc suivant se référera au dernier bloc généré.

Figure 3.1 : Un schéma général d’une époque. Notez que même s’il y a un repère d’emplacement assigné pour chaque emplacement, le repère peut sauter la génération de blocs et l’emplacement

reste vide

Slot leader. Un slot leader du slot slji est une partie prenante qui a été autorisée par la procédure de sélection du slot leader à forger un bloc au slot slji.

Procédure de sélection du slot leader. Une procédure de sélection de slot leader Select(SDEpi, rand) est une procédure qui sélectionne tous les slot leaders de l’époque Epi en fonction de la distribution de mise d’enjeu fixe SDEpi et de certaines valeurs rand aléatoire. La distribution de mise d’enjeu SDEpi est fixée avant que l’époque Epi ne commence. Le rand aléatoire n’est révélé qu’une fois que la répartition des enjeux est fixée.

Dans notre construction, nous avons modifié le protocole pour introduire la liaison avec la chaîne principale. Cela signifie qu’un bloc de la sidechain peut contenir des références au(x) bloc(s) de la chaîne principale de sorte que l’historique des blocs de la chaîne principale soit stocké dans la sidechain. Par référence, nous entendons le hachage du bloc de la MC ou, dans le cas où le bloc de la MC contient des transactions liées à cette sidechain, l’en-tête du bloc entier ainsi que les transactions SC et leur chemin de Merkle.

7

Les forgeurs de blocs de la sidechain sont obligés de garder les références de la chaîne principale cohérentes et ordonnées lorsqu’elles sont incluses dans les blocs de la SC. Un bloc de sidechain SBj peut contenir une référence au bloc de chaîne principale Bi si et seulement si (1) le bloc Bi est un bloc de chaîne principale valide, et (2) les références à tous les blocs de chaîne principale précédents Bk, kЄ {η,η+ 1,...,i-1} sont déjà incluses dans les blocs de sidechain (y compris celui actuel car il peut contenir plusieurs références), η étant la référence de genèse (Figure 3.2).

Notez qu’il n’est pas obligatoire pour les forgeurs de blocs d’inclure des références à la chaîne principale, mais nous supposons que les forgeurs de blocs honnêtes le feront pour soutenir le transfert de coins entre la SC et la MC. Il est également possible de construire un mécanisme d’incitation pour les forgeurs de blocs qui incluent des références. Par exemple, les utilisateurs qui initient des transferts bidirectionnels peuvent payer des frais minimes pour chaque transaction. Le mécanisme d’incitation dépasse le cadre de la recherche actuelle, car nous ne fournissons qu’un exemple de protocole consensuel de la sidechain.

Figure 3.2 : Un exemple de sidechain qui a des liens avec la chaîne principale

Il y a deux raisons principales d’introduire le rattachement entre la SC et la MC:

1. Synchronisation déterministe entre la MC et la SC. Lorsqu’un bloc SBi de la sidechain fait référence au bloc Bj de la chaîne principale, il reconnaît explicitement toutes les transactions du bloc Bj et de tous les blocs précédents. Cela signifie que si Bj contient des transactions liées à cette sidechain (par exemple, le transfert de coin MC→SC ), ces transactions peuvent être immédiatement transférées vers la sidechain.

2. La finalité de la chaîne principale n’est pas garantie. Dans les considérations qui suivent, nous supposons que la chaîne principale est la blockchain Horizen qui utilise le consensus de Nakamoto modifié avec un mécanisme de pénalité de retard de bloc. On sait que le consensus de Nakamoto ne donne pas de caractère définitif à la blockchain [16]. Cela signifie qu’il y a toujours une probabilité non nulle que certaines sous-chaînes de blocs soient inversées et remplacées par une autre chaîne avec un travail plus cumulatif. Un tel comportement est normalement géré par la chaîne principale mais peut être désastreux pour la sidechain car les transactions qui sont déjà confirmées dans la sidechain peuvent être annulées dans la chaîne principale. La liaison élimine une telle situation, car dans le cas d’un fork de la MC, les blocs de la SC qui se réfèrent aux blocs bifurqués (issus d’un fork) de la MC seraient également inversés.

Référencement complet. Le référencement complet implique que les blocs de la sidechain contiennent la chaîne complète des références des blocs de la chaîne principale. Même si un forgeur de blocs a raté l’occasion d’inclure une référence au bloc MC nouvellement généré, certains des forgeurs de blocs suivants incluront la référence manquée de la chaîne principale (voir Fig. 3.3).

8

Figure 3.3 : Exemple de référence de bloc manquantes sur la MC

Figure 3.4 : Exemple de synchronisation tx entre la chaîne principale et la sidechain

La référence elle-même est un hachage d’un bloc de la MC ou d’un en-tête de bloc complet du bloc principal correspondant dans le cas où il contient des transactions inter-chaînes. De cette façon, il devient possible d’effectuer une vérification allégée des blocs de la chaîne principale, ce qui permet d’introduire des fonctionnalités supplémentaires dans la sidechain, comme la vérification allégée des transactions inter-chaînes. Par exemple, lorsqu’une transaction de transfert tx MC→SC se produit dans le bloc de la chaîne principale Bj, un slot leader de sidechain crée le bloc de sidechain correspondant, où il inclut, à côté de l’en-tête du Bj, la transaction tx MC→SC et le chemin Merkle de cette transaction. Dans ce cas, un tel transfert peut être vérifié par n’importe quel nœud de sidechain sans avoir à analyser la chaîne principale.

Synchronisation déterministe. Par synchronisation déterministe, nous entendons la règle selon laquelle un slot leader de sidechain est obligé d’inclure dans un bloc de sidechain généré toutes les transactions liées à cette sidechain qui apparaissaient dans les blocs de la chaîne principale auxquels il fait référence (Fig. 3.4).

De cette façon, les transactions inter-chaînes de la MC sont immédiatement synchronisées sur la sidechain. Si un slot leader enfreint la règle et ne synchronise pas les transactions à partir de la chaîne principale, un tel bloc sera considéré comme invalide et devra être bifurqué par les blocs successifs.

Avec une transaction synchronisée, son chemin de Merkle doit être fourni à la racine qui est stockée dans l’en-tête du bloc de la chaîne principale.

Le hasard. L’élément crucial du protocole consensuel de preuve d’enjeu d’Ouroboros est la source vraiment aléatoire et impartiale du caractère aléatoire. La sécurité n’est garantie que si le hasard est présent. Dans l’Ouroboros original, le caractère aléatoire est obtenu grâce au protocole spécial de tirage au sort basé sur un partage secret vérifiable.

Dans la construction de notre sidechain, nous tirons parti de la présence d’une chaîne principale de preuve de travail et dérivons le caractère aléatoire des solutions de preuve de travail. Le protocole exact et sa sécurité seront décrits dans la section suivante.

9

Sécurité. La procédure standard de preuve de la sécurité d’un protocole de consensus de la blockchain exige de démontrer la capacité du protocole à satisfaire deux propriétés fondamentales d’un registre distribué : la vivacité (liveness) et la persistance [7]. La vivacité garantit que les transactions diffusées par les parties honnêtes seront finalement incluses dans le registre, et la persistance garantit qu’une fois qu’une transaction est confirmée par un nœud honnête, elle sera également confirmée par tous les autres nœuds honnêtes (afin qu’elle devienne définitive et immuable). De telles propriétés sont habituellement prouvées en vertu de certaines hypothèses comme la majorité honnête parmi les participants au protocole. Nous renvoyons les lecteurs intéressés à l’article original d’Ouroboros [10] pour la liste exhaustive des hypothèses avec leurs définitions strictes.

Étant donné que le protocole de consensus proposé incorpore également la liaison avec les blocs de la chaîne principale, il implique l’hypothèse supplémentaire de la majorité du pouvoir de hachage honnête dans la chaîne en question.

Nous supposons que, dans ces hypothèses, le protocole proposé dérive des garanties de sécurité fournies par les protocoles consensuels originaux d’Ouroboros et de Nakamoto.

Nous tenons à souligner que différentes sidechains peuvent adopter différents protocoles consensuels qui conviennent mieux à des cas d’utilisation spécifiques (p. ex. transfert rapide de coins). Le protocole consensuel d’une sidechain (y compris celui décrit dans cette section) n’est pas l’objet principal de cette recherche et nécessite une analyse de sécurité plus rigoureuse.

3.3 Protocole de transfert inter-chaîne

Cette section décrit le protocole de transfert inter-chaînes qui est la partie la plus cruciale de la construction des sidechains. Le protocole du CCT se compose essentiellement de deux éléments :

1. Le protocole de transfert. Définit les transferts de la chaîne principale vers la sidechain.

2. Le protocole sur les transferts vers l’arrière. Définit les transferts de la sidechain à la chaîne principale. Nous distinguons également le protocole de certification dans une section séparée. Logiquement, le protocole de certification fait partie du protocole des transferts vers l’arrière, puisqu’il est conçu pour vérifier les transferts d’une sidechain vers la chaîne principale, mais pour des raisons de clarté de l’architecture et pour faciliter l’analyse de sécurité, nous le décrivons séparément.

3.3.1 Protocole de transfert vers l’avant

La conception des opérations vers l’avant est simple et fondamentalement la même que dans de nombreuses architectures de sidechain existantes [2, 17, 11].

En général, il ressemble à ce qui suit : Le transfert MC vers SC (Fig. 3.5) est représenté par une paire de transactions, l’une sur la MC (émission de TX) et l’autre sur la SC (réception de TX). L’objectif de l’émission de TX est de verrouiller/brûler les jetons sur la MC. Le but de la réception de TX est de déverrouiller/créer le nombre correspondant de coins sur la sidechain. La TX réceptrice n’est valable que dans le cas où la TX émettrice est confirmée (en principe, une TX émettrice est une preuve de coins verrouillés).

Figure 3.5 : Approche standard de transfert MC à SC

10

Dans ce qui suit, nous définissons plus formellement le transfert vers l’avant en supposant que le protocole de consensus de la sidechain est celui décrit à la section 3.2.

Définition (transaction d’envoi). La transaction d’envoi est une transaction spécialement structurée qui déclenche un transfert de coins de la blockchain initiale A (la chaîne principale) vers la blockchain de destination B (la sidechain). La structure de base de la TX émettrice est définie comme suit :

TX éméttrice = {ledgerid, txid (sendAcc, receiveAcc), montant, sig},

Où

ledgerid est un identificateur unique de la sidechain précédemment déployée à laquelle les transactions sont destinées ; txid est un identificateur de transaction unique ; sendAcc est une adresse sur la blockchain A d’origine pour laquelle le solde (sendAcc)≥ montant ;receiveAcc est une adresse sur la blockchain de destination B ; montant est le nombre de coins à transférer ; sig est une signature qui correspond à sendAcc.

La TX émettrice brûle une quantité de coins sur la blockchain d’origine A à sa place, et réduit le solde sendAcc de ce montant.

Une TX réceptrice spéciale n’est pas nécessaire dans notre cas, car les informations sur le transfert qui ont été soumises avec la TX émettrice sont incluses dans la sidechain par un forgeur de bloc qui fait référence au bloc avec la TX émettrice (voir figure 3.6). Pour garantir la possibilité d’effectuer une vérification allégée de la transaction d’envoi dans le bloc sidechain (sans avoir à suivre la chaîne principale), le chemin de Merkle complet de la transaction d’envoi est également inclus. Puisque la racine de Merkle est présente dans l’en-tête du bloc de la chaîne principale (qui est également inclus dans le bloc SC), on pourrait facilement vérifier la transaction d’envoi dans la sidechain.

Après l’inclusion dans le bloc sidechain, le montant correspondant de coins est créé et le solde ReceiveAcc est augmenté de ce montant.

Figure 3.6 : Synchronisation des transactions de transfert de la chaîne principale à la sidechain

Notez que la structure de transaction fournie n’est pas exhaustive. Elle ne définit que les informations générales qui doivent être incluses dans la transaction. Le format spécifique peut varier en fonction du modèle de transaction des systèmes de la blockchain. Par exemple, pour le système Horizen - qui utilise le modèle de transaction Bitcoin - la TX émettrice peut être implémentée en introduisant un opcode spécial comme OP_SENDSIDECHAIN ou en introduisant un tout nouveau type de transaction. C’est à un développeur de décider du chemin le plus approprié.

11

Notez que la structure de transaction fournie n’est pas exhaustive. Elle ne définit que les informations générales qui doivent être incluses dans la transaction. Le format spécifique peut varier en fonction du modèle de transaction des systèmes de la blockchain. Par exemple, pour le système Horizen - qui utilise le modèle de transaction Bitcoin - la TX émettrice peut être implémentée en introduisant un opcode spécial comme OP_SENDSIDECHAIN ou en introduisant un tout nouveau type de transaction. C’est à un développeur de décider du chemin le plus approprié.

Sécurité. Pour analyser la sécurité du schéma décrit, nous introduirons une propriété appelée sécurité de transfert vers l’avant qui exige qu’aucun coin ne puisse être créé sur la sidechain à moins que la quantité correspondante de coins n’ait été brûlée avec la TX émettrice dans la chaîne principale.

Il est facile de voir que si le protocole de consensus de lien étroit est utilisé (tel que décrit à la section 3.2), le protocole de transfert vers l’avant satisfait entièrement la propriété de sécurité. Si la TX émettrice est annulée dans la chaîne principale, le bloc de sidechain correspondant devient invalide et est également annulé. De plus, seul le créateur de la TX émettrice peut spécifier l’adresse du destinataire. Pour falsifier un transfert, il faudrait falsifier la signature de sendAcc qui est supposée infaisable.

3.3.2 Protocole de transfert vers l’arrière

Le protocole de transfert vers l’arrière est le point le plus complexe de toute construction de sidechain. C’est l’élément qui différencie cette recherche de nombreuses autres constructions existantes. La complexité découle de l’hypothèse que la chaîne principale ne sait rien d’une sidechain spécifique, il est donc impossible de vérifier directement le transfert qui a été initié dans la sidechain.

Il existe différentes approches pour mettre en œuvre des transferts vers l’arrière. Par exemple, A.Back et al. dans leur construction [2] s’appuient sur la fédération des entités autorisées pour vérifier les transferts, l’approche Drivechain [17, 11] implique les mineurs de la chaîne principale pour voter (et donc vérifier) l’exactitude des transferts vers l’arrière.

Dans notre construction, nous nous appuyons sur l’idée d’une vérification par lots des transferts vers l’arrière (dans un sens identique à [11]), mais le processus de vérification est différent des constructions existantes. Au lieu de compter sur les mineurs (forgeurs de blocs), nous introduisons des entités indépendantes appelées certificateurs, qui sont responsables de la vérification de l’exactitude des transferts vers l’arrière. Les certificateurs sont inscrits par blocage de leur participation pour la période d’exploitation.

Le reste de cette section fournit des détails sur la façon dont les transferts vers l’arrière sont organisés, vérifiés et transférés à la chaîne principale. La section 3.3.3 fournira des détails sur le protocole de sélection des certificateurs.

Toute la durée de vie de la blockchain MC (et donc de la chaîne SC) est divisée en périodes de retrait (à ne pas confondre avec les époques de consensus SC - elles sont différentes) qui ont un nombre déterminé de blocs epoch_len (par ex. epoch_len= 720). Définissons un bloc Bi qui appartient à une époque spécifique ep_id comme Bj

ep_id, où jЄ0... epoch_len. Dans la sidechain, l’époque de retrait (et toute autre sous-étape) est définie par les références des blocs MC, de sorte que epochep_id commence à partir du bloc SC qui se rapporte à B0

et se termine par le bloc qui se rapporte à Bep_id (Fig. 3.7).

Figure 3.7 : Epoques de retrait (a)

epoch_len-1ep_id

12

L’objectif principal d’avoir des époques est de fournir un mécanisme efficace pour envoyer des données authentifiées d’une sidechain à la chaîne principale. Comme la chaîne principale elle-même n’est pas en mesure de vérifier l’authenticité et la validité des données, des entités spéciales appelées certificateurs sont habilitées à certifier les données transmises. La certification de chaque message séparément semble inefficace avec l’infrastructure existante, de sorte que l’approche de certification en masse est adoptée, ce qui implique que les données sont d’abord cumulées pendant cette période, regroupées dans les structures appelées certificats inter-chaîne, validées et signées par des certificateurs et seulement ensuite transmises vers la chaîne principale. Un tel cycle de signature prend une époque de retrait.

Définition (certificat inter-chaînes). Cross-Chain Certificate (CCCert) est un conteneur générique qui est utilisé pour transmettre des données d’une sidechain à la chaîne principale. Il est défini par les règles de la chaîne principale et se compose de trois parties principales : liste des transferts vers l’arrière, liste des retraits des certificateurs et liste des rapports de fraude. Pour être accepté par la chaîne principale, un CCCert doit être signé par la majorité des membres autorisés du groupe de certification. Plus précisément, un CCCert contient les renseignements suivants :

1. Identifiant Sidechain.2. Numéro de l’époque.3. Numéro du certificat de l’époque.4. Liste de transferts vers l’arrière.5. Liste des certificats de retrait.6. Liste des rapports de fraude.

Figure 3.9 : Structure de base du certificat inter-chaînes

13

Les certificateurs sont enregistrés dans la chaîne principale, de sorte que la signature agrégée peut être vérifiée par la chaîne principale. La section 3.3.3 fournira des détails sur l’inscription et la sélection des certificateurs. Notez que chaque période de retrait peut générer jusqu’à k certificats inter-chaînes, où k dépend du nombre de certificateurs.

Avant de passer au flux de transfert vers l’arrière de base, nous définirons les notions de liste de transfert vers l’arrière et de transfert vers l’arrière, qui fait partie de CCCert.

Définition (transfert vers l’arrière). Le Backward Transfer (BT) est une structure abstraite qui spécifie les détails d’un transfert unique de coins d’une sidechain à la chaîne principale. La structure est définie par les règles de la chaîne principale. En général, il doit spécifier au moins un montant de coin transférés et des informations sur le récepteur : BT (montant, récepteur).

Plus précisément, un transfert vers l’arrière contient des informations sur le destinataire des coins dans la chaîne principale. Par exemple, dans le cas du système Horizen Blockchain, il peut contenir un script de sortie qui définit la propriété des coins transférés dans la chaîne principale Horizen.

Les transferts vers l’arrière pour une époque donnée sont dérivés de la sidechain. Le cas le plus courant pour initier un transfert vers l’arrière est une transaction de retrait créée par un utilisateur de sidechain qui veut transférer ses coins sur la chaîne principale. Toutefois, elle ne se limite pas aux seules transactions de retrait des utilisateurs. Par exemple, il peut s’agir d’un paiement du fond de trésorerie ou de tout autre paiement défini par les règles de la sidechain.

Définition (liste des transfert vers l’arrière). La liste des transferts vers l’arrière (BTList) est une structure définie par les règles de la chaîne principale qui contient un ensemble de transferts vers l’arrière pour le montant total ∑|BT|

amountBTi≤MAX_CERT_AMOUNT, où MAX_CERT_AMOUNT est le montant maximum autorisé pour un seul CCCert. L’ensemble de ces listes est défini de manière déterministe à partir de l’ensemble ordonné des transferts vers l’arrière.

Chaque époque de retrait comprend deux étapes : l’étape de préparation et l’étape de signature. Pendant la phase de préparation, les utilisateurs peuvent soumettre des demandes de retrait qui seront traitées à cette époque. Si un utilisateur soumet des demandes de retrait après l’étape de préparation, elles ne seront traitées qu’à l’époque suivante. Le débit de retrait de base est indiqué sur la Fig. 3.10.

i=0

Figure 3.10 : Débit de retrait de base

14

La certification des transferts vers l’arrière pour l’époque i commence immédiatement après le bloc SBep_id. À ce stade, l’ensemble des transferts vers l’arrière actuels est fixé, la liste des certificats inter-chaînes est dressée et chaque CCCert se voit attribuer un groupe de certificateurs qui doit le signer.

La liste de tous les transferts vers l’arrière au cours de l’époque est recueillie et triée par ordre chronologique. Ensuite, tous les transferts vers l’arrière sont regroupés dans des listes de transferts vers l’arrière selon l’algorithme 1.

p

Algorithme 1: Le regroupement des transferts vers l’arrière dans des listes

1. BTList0 prend le premier transfert vers l’arrière k0 de la liste jusqu’à ce que ∑i=1 amount BTi >

MAX_CERT_AMOUNT ou que la liste des transferts vers l’arrière soit épuisée.

2. BTList1 prend le transfert vers l’arrière k1 suivant de la liste jusqu’à ce que ∑i=k0+1 amount BTi >

MAX_CERT_AMOUNT ou que la liste des transferts vers l’arrière soit épuisée.

3. Le processus est répété jusqu’à ce que la liste des transferts vers l’arrière soit épuisée.

k0+1

k0+k1+1

Pour limiter l’impact dans le bloc MC en terme de nombre de transactions connexes aux transferts vers l’arrière, nous introduisons un montant minimum de transfert

amountBTi ≥ AMOUNT_MIN_TRANSFERT

De cette façon, le nombre maximum de transferts par certificat devrait être

MAX_CERTIFICATE_AMOUNT m = AMOUNT_TRANSFERT_MIN

Simplement dit, tous les transferts vers l’arrière sont regroupés dans les BTList par ordre chronologique afin que le montant total de chaque BTListi ne dépasse pas le seuil MAX_CERT_AMOUNT, puis le BTListi est inclus dans le CCCerti correspondant. Le nombre de certificats à une époque de retrait donnée dépend du nombre de transferts vers l’arrière et du nombre de certificateurs. Si tous les transferts vers l’arrière peuvent être traités dans un seul certificat, alors un seul certificat sera créé à l’époque. Mais seulement jusqu’à [ n ] certificats peuvent être délivrés, où n est le nombre de certificateurs disponibles à l’époque et N est la taille du groupe de certificateurs.

Notez qu’une époque de retrait particulière peut ne pas avoir assez de CCCert pour traiter toutes les BTList. Dans ce cas, les transferts vers l’arrière non traités seront transmis à l’époque de retrait suivante.

Toutes les opérations sont effectuées de manière déterministe sans aucune transaction supplémentaire sur chaîne, de sorte que chaque certificateur sait exactement ce qu’il doit signer, et chaque vérificateur sait plus tard comment le certificat doit être construit exactement et qui doit le signer. Pendant la phase de signature, les certificateurs soumettent leurs signatures à la sidechain. Une fois l’époque terminée, toutes les signatures sont agrégées et les certificats avec des signatures agrégées sont poussés vers la chaîne principale.

La valeur MAX_CERT_AMOUNT est égale à 2 , où N est la taille du groupe qui signe le certificat et le dépôt (Ci) est le montant du dépôt du certificateur Ci. En termes simples, le montant du retrait par certificat représente au maximum la moitié du montant total des dépôts des certificateurs éligibles pour signer ce certificat. Puisque tous les dépôts des certificateurs sont égaux (voir plus loin) et que la taille du groupe des certificateurs est également constante, le MAX_CERT_AMOUNT aura une valeur constante pour tous les certificats inter-chaînes jamais émis dans la sidechain.

La règle ci-dessus implique également que la limite maximale de retrait par époque est égale à la moitié de la mise totale déposée par les certificateurs.

N

i=1∑ N deposit(Ci)

15

3.3.3 Les certificateurs

Pour devenir un certificateur, une partie prenante de la MC doit créer une transaction spéciale Certifier Reg (SCID ,pubKey) sur la chaîne principale qui verrouillera son dépôt indéfiniment jusqu’à ce qu’une autre transaction spéciale Certifier Withdraw (regtxid, sig(pubKey)) soit créée. Un seul enregistrement donnera au certificateur le droit d’être éligible à la signature de certificat uniquement pour un SCID de sidechain spécifique. La clé pub est utilisée pour signer les certificats inter-chaînes et les transactions de retrait du certificateur.

Pour être éligible à une certaine époque i, un certificateur doit créer une transaction d’enregistrement avant que cette époque ne commence.

Définition (Groupe certificateur). Pour un ensemble déterminé de certifications éligibles ECepid = {c0,...,c|ECepid-1| } dans l’époque epid, un groupe certificateur CGi , où i Є {0,..., [ }, consistera à choisir N certificateurs aléatoirement dans ECepid d’après l’Agorithme 2.

L’ensemble des certificateurs éligibles ECepid consiste à ECepid Є RG\PC, où RG est l’ensemble de tous les certificateurs certifiés, et PC l’ensemble des certificateurs qui ont participé au groupe certificateur k précédent (k est la longueur de la période de litige potentiel).

N

ECepid

N

|ECepid|

Algorithme 2: Construction du groupe de certificateurs

1. Pour chaque certificateur cj Є ECepid calcule son propre ticket de loterie ticketcj = H(rand || epid || pubKeycj), où H (.) est une fonction de hachage cryptographiquement forte.

2. Trie tous les tickets de loterie dans l’ordre croissant.

3. Prend les tickets (i . N, i. N+1, …, i.N+ N-1) et inclut leurs propriétaires dans le groupe certificateur CGi.

Compte tenu des règles ci-dessus jusqu’à g= , des groupes de certificateurs peuvent être définis de manière déterministe pour une époque spécifique avec un rand de caractère aléatoire. On peut constater qu’un certain certificateur ne peut pas être assigné à des groupes différents à la même époque et qu’il n’est pas non plus éligible pendant la période de litige qui suit la participation.

Pour déterminer l’ensemble des certificateurs d’un CCCert spécifique, une règle simple est suivie : un CCCert avec index i doit être signé par le groupe certificateur avec le même index. Il existe donc un mappage individuel entre les certificats et les groupes de certificateurs : CCCerti→CGi En suivant ces règles, il est facile d’identifier ce qui doit être signé et par qui. Un certificateur ne peut appartenir à plus d’un groupe de certificateurs par période de retrait.

Les étapes du processus de transfert vers l’arrière sont résumées à la figure 3.11 :

Figure 3.11 : Etape de processus de certification

16

On peut voir qu’une fois l’étape de préparation terminée, le processus de signature est lancé et dure jusqu’à la fin de l’époque. Pendant l’époque de la signature, chaque certificateur élu doit créer et soumettre sa signature pour le CCCert correspondant. Les signatures doivent être soumises strictement avant la fin de l’époque. Après la fin de l’époque, les signatures de chaque CCCert (il devrait y avoir au moins s =[N2]+ 1 signatures, où N est la taille du groupe certificateur) devraient être rassemblées en une seule signature agrégée et soumises avec le CCCert correspondant dans la chaîne principale.

Le hasard. Pour la procédure de sélection des certificateurs, le caractère aléatoire est exigé. Pour fournir une source fiable de hasard, nous supposons utiliser un mécanisme simple mais efficace qui tire parti de l’algorithme de preuve du travail de la chaîne principale. Le caractère aléatoire pour une époque particulière Eid est égal au plus petit hash de la preuve des blocs de la chaîne principale pendant l’étape de préparation de l’époque Eid. Dans ce cas, il peut être démontré que pour manipuler avec succès le hasard, un adversaire devra posséder une puissance de hachage importante. Une tentative de modification du caractère aléatoire coûtera à peu près le même prix que le minage de la totalité de l’étape de préparation. Nous soutenons qu’une telle attaque est irréalisable et économiquement non rentable dans des hypothèses raisonnables concernant le rapport de puissance de hachage honnête.

L’analyse formelle d’une telle approche est prévue dans le cadre de travaux de recherche distincts.

Notez qu’il est crucial de fixer l’ensemble des certificateurs éligibles avant le début de la période de génération aléatoire. Une fois les clés publiques des certificateurs fixées, la seule façon de manipuler la procédure de sélection est de manipuler le caractère aléatoire lui-même, ce qui, comme nous l’avons mentionné précédemment, est infaisable sous certaines hypothèses.

Incitatifs. Tous les certificateurs sélectionnés du groupe de certificateurs CGi sont récompensés avec k % (par exemple k = 1) du montant du retrait de CCCerti réparti également entre les certificateurs. Seuls les certificateurs signataires seront récompensés. Les récompenses seront incluses par le forgeur dans le bloc SC au début de l’époque suivante après que le CCCerti ait été soumis à la chaîne principale.

Le solde des récompenses des certificateurs sera géré par la SC (la MC ne sera pas au courant du mécanisme de récompense des certificateurs).

La Fig. 3.12 montre la liste des transferts vers l’arrière avec tous les transferts. Pour chaque transfert vers l’arrière, des frais sont facturés qui seront redistribués ultérieurement aux certificateurs qui ont signé le certificat.

Figure 3.12 : Un exemple de la liste des transferts vers l’arrière qui contient 5 transferts vers l’arrière. Les montants des transferts sont spécifiés avec les récompenses des certificateurs

déjà soustraites

17

Donc, naturellement, la récompense pour les certificateurs est une rémunération payée par ceux qui effectuent le transfert. La récompense elle-même est payée au début de l’époque suivante au même bloc de la sidechain où le CCCert de la chaîne principale était synchronisé, comme le montre la Fig. 3.13

Figure 3.13 : Les récompenses aux certificateurs

Le montant de la récompense est égal pour tous les certificateurs. Si certains d’entre eux ont omis de fournir une signature, leur part de la récompense sera brûlée. La récompense n’est versée que dans le cas de l’inclusion d’un certificat valide qui a d’abord été soumis à la chaîne principale.

Signature agrégée. Le certificat inter-chaînes soumis à la chaîne principale est accompagné de la signature agrégée construite à partir des signatures personnelles des certificateurs. Il existe différents schémas qui peuvent être utilisés, par exemple, sous la forme la plus simple, il peut s’agir simplement d’une concaténation de signatures personnelles. Des schémas plus avancés sont également possibles, par exemple des signatures de seuil BLS. Le choix du régime approprié fait l’objet de recherches plus approfondies.

Révocation de la certification. Pour révoquer les droits du certificateur et débloquer le dépôt, le certificateur doit créer une transaction spéciale intitulée CertifierWithdraw(reg_txid,sig) (Retrait du certificateur). Le dépôt sera débloqué après la fin de la période de contestation, et seulement dans le cas où aucune fraude n’est signalée au certificateur (les rapports de fraude et les litiges sont abordés à la section 3.3.4).

Si la transaction CertifierWithdraw(reg_txid,sig) a été soumise avant l’étape de la signature, la période de contestation pour le certificateur commence à l’époque actuelle. S’il a été soumis après le début de l’étape de signature, alors le certificateur est toujours éligible pendant cette période, et le processus de révocation ne sera lancé que pendant la période de retrait suivante.

3.3.4 Garantie de retrait

La garantie est une caractéristique spéciale introduite pour empêcher les retraits illimités d’une sidechain vers la mainchain dans le cas d’une corruption totale des certificateurs. L’essence de la fonction de garantie est de maintenir l’équilibre d’une sidechain et de limiter les retraits pour des montants plus importants que ceux qui étaient précédemment transférés à une sidechain. La mise en œuvre de la fonction de sauvegarde est simple : pour chaque sidechain déployée, une variable d’équilibre spéciale est maintenue par la chaîne principale. Chaque opération vers l’avant augmente le solde du nombre de coins transférés. Chaque certificat de retrait réduit le solde du montant retiré. Le certificat inter-chaîne ne peut pas retirer plus de coins que ce qui est stocké dans la balance de la sidechain. Une fonctionnalité aussi simple empêche toute implication possible d’une corruption de la sidechain pour la chaîne principale. Il garantit que seul le nombre de coins transféré peut être retiré de la chaîne principale. Même dans le cas d’une corruption totale, un adversaire ne peut pas imprimer de coins sur la chaîne principale à partir de rien.

18

3.3.5 Litiges

Afin de sécuriser davantage le système, un mécanisme spécial de litiges est mis en place pour empêcher la signature d’un certificat Cross-Chain malveillant. Nous appellerons ce certificat un certificat frauduleux. Un certificat frauduleux est un certificat qui est confirmé dans la chaîne principale mais qui ne correspond pas au certificat signé précédemment dans la sidechain. Étant donné que la MC ne surveille pas la sidechain et n’est pas en mesure de vérifier directement la cohérence et la validité du certificat, un algorithme spécial de contestation est utilisé pour définir si un certificat inter-chaîne particulier est frauduleux. La procédure de litige est la suivante : les certificats consécutifs k suivants (à partir de l’époque de retrait suivante) peuvent inclure un rapport de fraude signalant un certificat frauduleux. Si au moins un tel rapport est inclus dans le CCCert pendant la période de litige, alors le certificat considéré est perçu comme frauduleux, et tous les signataires de ce certificat sont punis en détruisant leurs dépôts. k est un paramètre de sécurité et peut être réglé à la création de la sidechain.

Le certificateur ne peut pas retirer son dépôt si certains de ses certificats (qui ont été signés par lui-même) sont considérés comme frauduleux. À condition qu’une époque particulière puisse contenir plusieurs certificats inter-chaînes, tous participent à la détection de la fraude.

L’algorithme 3 permet de modéliser le flux de base du rapport de fraude (voir aussi Fig. 3.14) : Comme la détection des fraudes est un processus complètement déterministe du point de vue de la sidechain, les parties honnêtes sont tenues d’inclure un rapport de fraude si le ou les certificats des périodes de retrait k précédentes étaient frauduleux. Dans le cas contraire, il devient lui-même frauduleux et doit être sanctionné par le certificat suivant.

3.3.6 Sécurité

Il peut être démontré que, dans l’hypothèse d’un comportement rationnel, le protocole de transfert vers l’arrière est protégé contre la tricherie par les certificateurs. En trichant, nous impliquons qu’un groupe de certificateurs de connivence signe un certificat malveillant en retirant des coins à leurs propres adresses au lieu de celles définies

Algorithme 3: Flux de signalement des fraudes

1 : Certificat de Cross-Chain CCCerti est correctement signé en SC par le groupe certificateur CGi.

2 : Certificat frauduleux CCCertifraud est créé de manière privée, signé par la majorité des certificateurs de

CGi et ensuite envoyé à la MC.

3 : CCCertifraud est inclus dans un bloc Bi

0 dans MC. Elle est valable dans la chaîne principale parce qu’elle contient une signature agrégée valable. La chaîne principale ne vérifie pas la cohérence du certificat dans une sidechain.

4 : CCCertifraud est de nouveau synchronisé dans le bloc Bi

0 de la sidechain.

5 : Les certificateurs de l’époque i+1 comparent CCCertifraud avec CCCerti

, détectent la différence et incluent un rapport de fraude dans le CCCerti+1 se référant au certificat frauduleux CCCerti

fraud

6 : Création du certificat inter-chaînes CCCerti+1 , y compris le rapport de fraude pour CCCertifraud.

7 : Le certificat CCerti+1 est signé en SC par le groupe de certificateurs CGi+1.

8 : Le certificat inter-chaînes CCerti+1 est inclus dans le bloc Bi+1 du MC.

9 : La MC ne permettra pas de débloquer les retraits pour tous les certificateurs qui ont déjà signé CCCerti

fraud.

0

19

Figure 3.14 : Un exemple de certificat frauduleux et rapport de fraude

par les demandes de retrait dans la sidechain. Le système de punition rend une telle attaque non rentable car les certificateurs qui trichent perdraient leurs dépôts. Étant donné que le montant du retrait par certificat est limité et qu’un adversaire a besoin d’au moins la moitié du groupe de certification pour être impliqué dans la tricherie, il est facile de voir que plus de coins seraient confisqués que récupérés. Il peut également être démontré que la punition des certificateurs tricheurs est pratiquement inévitable si l’on suppose que la majorité de tous les certificateurs enregistrés sont honnêtes. L’analyse mathématique rigoureuse des propriétés de sécurité mentionnées doit être publiée dans un document séparé.

3.4 Sidechain de démarrage

Il peut y avoir plusieurs sidechains déployées et opérationnelles simultanément. Pour simplifier et standardiser une procédure de déploiement d’une sidechain, une transaction spéciale de création de sidechain doit être introduite dans la chaîne principale. Une telle transaction notifie la chaîne principale de la création de la sidechain, définit l’identifiant de la sidechain et ses différents paramètres. La transaction de création a la structure suivante :

CreateSidechainTx = {ledgerid,start_block,epoch_len, prep_len,cert_depo, cert_group_size,cert_fee,min_transfer_amount,dispute_len}

Où

ledgerid est un identificateur unique de la sidechain qui n’a pas encore été enregistrée ;

start_block est le numéro du bloc de la chaîne principale à partir duquel commence la première période de retrait ;

epoch_len est la durée de l’époque de retrait en blocs ;

prep_len est la durée de l’étape de préparation de l’époque de retrait ;

cert_depo est le montant nécessaire du dépôt bloqué pour devenir certificateur ;

cert_group_size est la taille du groupe certificateur qui certifie un seul certificat transversal ;

cert_fee est le pourcentage des frais du montant transféré qui sera payé aux certificateurs ;

min_transfer_amount est le montant minimum de transfert autorisé pour un seul transfert vers l’arrière ;

20

dispute_len est le nombre de certificats croisés qui peuvent rendre compte de la fraude d’un CCCerti particulier (à partir de l’époque de retrait suivante après l’époque où CCCerti s’est produite).

Les paramètres personnalisables offrent une flexibilité dans le choix des paramètres appropriés pour une sidechain particulière. Différentes combinaisons des paramètres fournis donnent des compromis différents entre la vitesse, l’efficacité et la sécurité.

Grâce à ce protocole, n’importe qui peut créer une sidechain Horizen. Des frais de déploiement (sous forme de coins brûlés) devraient être appliqués par le créateur de la sidechain.

Une fois qu’une sidechain est créée, les périodes de retrait sont définies de manière déterministe et les transferts avant/arrière peuvent être traités. Notez que même si certaines époques de retrait n’ont pas de certificats inter-chaînes (en raison de l’absence de certificateurs ou pour toute autre raison), cela ne perturbe pas le flux de traitement de la chaîne principale et l’interaction avec une sidechain peut encore se produire dans le futur. Même si la sidechain a été suspendue pour quelque raison que ce soit, le retrait peut encore avoir lieu à l’avenir selon le calendrier défini.

4 Conclusion

Dans ce papier, nous avons présenté la construction de la sidechain basée sur les principes de la preuve d’enjeu (PoS). Notre principale contribution est la construction du nouveau protocole de transferts vers l’arrière qui ne repose ni sur une fédération centralisée de validateurs, ni sur des mineurs, ni sur des forgeurs de blocs. Elle s’appuie plutôt sur un nouvel ensemble d’acteurs du système appelés “certificateurs”. Nous avons également fourni une description du protocole de consensus qui peut être utilisé dans la sidechain et qui convient bien à sa structure. Notre construction nécessite une modification du protocole de consensus de la chaîne principale pour intégrer le support de base de la sidechain. Une fois intégrées, de nombreuses sidechains peuvent être déployées. La chaîne principale n’a besoin de suivre que l’équilibre et l’ensemble des certificateurs actuels pour une sidechain particulière. En général, la construction proposée fournit un protocole ouvert décentralisé pour un support de sidechain. Il peut être intégré à la fois dans les chaînes de preuve du travail (PoW) et dans les chaînes de preuve d’enjeu (PoS).

21

Réferences

[1] On Scaling Decentralized Blockchains. In: Clark J., Meiklejohn S., Ryan P., Wallach D.,

Brenner M., Rohloff K. (eds). Financial Cryptography and Data Security.

Vol. 9604. Lecture Notes in Computer Science, Springer, July 2016.

[2] A. Back et al. Enabling blockchain innovations with pegged sidechains.

https://blockstream.com/sidechains.pdf. 2014.

[3] Cosmos network: https://cosmos.network/docs/. 2018.

[4] J. Dilley et al. Strong federations: An interoperable blockchain solution to centralized third

party risks. https://blockstream.com/strong-federations.pdf. 2016.

[5] E. Duffield and D. Diaz. Dash: A Payments-Focused Cryptocurrency. https://github.com/dashpay/dash/wiki/Whitepaper. 2018.

[6] Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform.

https://github.com/ethereum/wiki/wiki/White-Paper. 2018.

[7] Juan Garay, Aggelos Kiayias, and Nikos Leonardos. The Bitcoin Backbone Protocol: Analysis and Applications. Cryptology ePrint Archive, Report 2014/765. https://eprint.iacr.org/2014/765. 2014.

[8] Horizen: https://horizen.global/. 2018.

[9] A. Kiayias and D. Zindros. A Sidechain Protocol for Proof-of-Work Blockchains.

Presentation at Crypto.Sec. https://docs.google.com/presentation/d/1u_UhfDBV31DCFmnU-

kcyUd47eZGNfrDJVQVQNlI4iwE/edit#slide=id.p. 25 July, 2018.

[10] Aggelos Kiayias et al.Ouroboros: A provably secure proof-of-stake blockchain protocol. Advances in Cryptology - CRYPTO 2017 - 37th Annual International Cryptology Conference.

Part I, volume 10401 of LNCS, Springer. 2017.

[11] S. Lerner. Drivechains, sidechains and hybrid 2-way peg designs. https://bravenewcoin.com/assets/ Whitepapers/Drivechains-Sidechains-and-Hybrid-2-way-peg-Designs. 2016.

[12] Monero: https://monero.org. 2018.

[13] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. https://bitcoin.org/bitcoin.pdf. 2008.

[14] J. Poon and V. Buterin. Plasma: Scalable Autonomous Smart Contracts. http://plasma.io/.

[15] Rootstock: smart contracts on Bitcoin network. https://www.rsk.co/. 2018.

[16] Nicholas Stifter et al. Agreement with Satoshi – On the Formalization of Nakamoto Consensus. Cryptology ePrint Archive, Report 2018/400.

https://eprint.iacr.org/2018/400. 2018.

[17] P. Sztorc. Drivechain - the simple two way peg, November 2015.

http://www.truthcoin.info/blog/drivechain/. 2015.

[18] S. Thomas and E. Schwartz. A protocol for interledger payments. https://interledger.org/interledger.pdf. 2018.

[19] Robert Viglione, Rolf Versluis, and Jane Lippencott. Zen White Paper.

https://horizen.global/assets/files/Zen-White-Paper.pdf. 2018.

[20] Gavin Wood.Polkadot: Vision for a heterogeneous multi-chain framework.

https://polkadot.network/Polkadot-lightpaper.pdf. 2016.

[21] ZCash: https://z.cash/. 2018.

[22] Bingsheng Zhang, Roman Oliynykov, and Hamed Balogun. A Treasury System for Cryptocurrencies: Enabling Better Collaborative Intelligence. Cryptology ePrint Archive, Report

2018/435. https://eprint.iacr.org/2018/435. 2018