FR 3093259 A1 20200828 FR 1901885 A 20190225 Description Titre de l'invention : Sidechain sécurisé et décentralisé réalisant des consensus pour des blockchains publique ou privée Domaine technique [0001] L'invention se rapporte au domaine de blockchain ou chaine de bloc. Plus particu- lièrement, l'invention concerne un système de sidechains sécurisés et décentralisé permettant de la réalisation de consensus pour une blockchain publique ou privée. L'invention concerne en outre un procédé de réalisation de consensus selon un protocole et l'utilisation du système de sidechain dans des applications utilisant la technologie de blockchain. Technique antérieure [0002] La technologie blockchain apporte une solution décentralisée de stockage des données. Une des propriétés de la technologie blockchain est sa "re-jouabilité". C'est à dire qu'à tout moment, n'importe qui peut reprendre l'ensemble des transactions qui se sont déroulées sur la chaîne, les jouer dans le bon ordre et revenir à un état identique à l'état actuel. [0003] Cela implique que la technologie blockchain ne peut compter sur aucune source ex- térieure pour se construire. Par conséquent, si une source venait à disparaître, la blockchain ne serait plus "re-jouable" et donc perdrait son intégrité. L'ensemble des transactions est ainsi inscrite dans une suite de blocs inter-liés (une "chaîne de blocs" d'où le nom de cette technologie de "blockchain"). [0004] Le procédé permettant de rajouter de nouveaux blocs à cette chaîne d'une blockchain est également appelé le "consensus" et il revêt une importance capitale pour chacune des blockchains. Les différents procédés de consensus utilisés par les blockchains sont d'ailleurs l'objet de beaucoup d'attention (la consommation énergétique par exemple pour le procédé dit de "proof of work" de la blockchain bitcoin) et génèrent des difficultés de fonctionnement liés à leur coût ou à leur lenteur; c'est notamment le cas de la blockchain sur laquelle se développe aujourd'hui les applications grand public les plus prometteuses, la blockchain "Ethereum". Cette blockchain requiert en effet qu'à chaque opération de consensus effectuée en son sein, une redevance (le "gas") soit payée ; par ailleurs le délai moyen de validation de ce consensus est en moyenne de 14 secondes, ce qui est trop long pour les besoins fonctionnels de nombreuses applications de cette blockchain Ethereum et ainsi le coût de l'opération sera trop élevé. [0005] Par ailleurs, sur le long terme, l'augmentation du nombre de transactions dans une blockchain classique poserait des problèmes d'engorgement qui bloquerait ce développement. Dans un tel cas de figure, seuls les utilisateurs consentant à payer des frais 2 de transaction prohibitifs pourraient encore utiliser le système. Plusieurs solutions sont proposées afin de résoudre le problème de l'augmentation du nombre de transactions ainsi que la lenteur et le coût de l'opération. [0006] Une solution consiste en la création des altchains, une solution radicale qui postule que la blockchain classique n'y parviendra pas et qu'il faut donc un ou plusieurs autres réseaux dédiés pour y parvenir. Or cette solution pose des problèmes de fragmentation de l'infrastructure ce qui induit un gaspillage d'énergie et des risques lies à la sécurité. [0007] Une autre solution proposée consiste à augmenter la taille des blocs et donc d'augmenter le nombre de transactions pouvant être validées dans un bloc. C'est le moyen le plus évident et le plus simple pour augmenter la capacité de validation des transactions. A court terme, cette solution est efficace, mais on ne peut pas augmenter indéfiniment la taille des blocs sans que cela n'ait de conséquence sur le protocole et l'efficacité de la blockchain. L'augmentation de la taille des blocs veut dire qu'il faut tout de même plus de puissance de calcul pour valider un bloc. Bien entendu, on ne peut pas indéfiniment augmenter la puissance de calcul nécessaire au fonctionnement d'une blockchain sans que cela ne se répercute sur la rentabilité. Le premier risque encouru est donc que le minage de cette blockchain ne devienne très peu rentable, voire, pas du tout. [0008] Enfin, une dernière solution proposée consiste en la création des Sidechains. En effet, des nombreuses applications ont -delocalisées" certaines opérations de consensus sur des blockchains privés en lien avec une blockchain publique (ethereum, bitcoin,...) appelées "Sidechains" ou chaines collatérales. En effet, les Sidechains offrent une solution bien moins couteuse que l'utilisation d'une blockchain publique. Autrement dit, l'utilisateur ne paye que lors de la validation du résultat d'une suite d'opérations réalisées sur cette Sidechain. De plus, la rapidité est bien supérieure et permet donc plus de transactions. [0009] Cependant, les Sidechains, malgré leurs avantages en terme de coût et de rapidité, sont très controversées dans l'écosystème blockchain puisqu'elles "re-centralisent" en leur sein des opérations alors que l'essence même des blockchains est de décentraliser l'intégralité des opérations. Sur ce constat, on peut légitimement émettre des doutes sur l'intégrité et la transparence de ces sidechains. D'autres acteurs du système de blockchain vont même jusqu'à bannir le référencement d'applications utilisant ce procédé. [0010] Pour exemple, la technologie développée par la société Domraider (Demandeur de la présente invention) pour son application décentralisée d'enchères, comme de nombreuses autres applications, utilise une Sidechain. Il s'agit en l'occurrence d'y faire réaliser la validation des offres faites lors des ventes aux enchères (les "bids"). L'utilisation de cette Sidechain permet d'éviter de payer une redevance à la blockchain 3 publique Ethereum (le "gus") pour chaque offre, et, d'avoir un délai de validation de celle-ci inférieur à une seconde. [0011] Or malgré les avantages économiques et fonctionnels, en ce qui concerne le délai de validation ainsi que le coût qui sont bien avérés, il n'en demeure pas moins que cette solution apporte, là aussi, une part de centralisation qui ne lui permet pas d'apporter une pleine satisfaction aux besoins du marché. Le but est donc de trouver une solution qui vise à marier le meilleur des deux mondes, c'est-à-dire le coût modique et la vitesse d'une Sidechain avec le caractère décentralisé d'une blockchain publique. Exposé de l'invention [0012] L'invention vise à remédier aux inconvénients de l'état de la technique et notamment à proposer un système de sidcchain I permettant la réalisation d'un ou plusieurs consensus pour des actifs numériques caractérisé en cc qu'il est sécurisé et décentralisé et communique avec une blockchain principale 20, publique ou privée, en utilisant un protocole, nommé Meerkat, permettant de réaliser un ou plusieurs consensus, et en cc qu'il comprend une entité nommée Banque 10 comprenant une ou plusieurs banques BI, B2,.. assurant le stockage des actifs numériques AI, A2,. et des utilisateurs Ul, U2,...auxquels ils appartiennent, uns entité nommée Exécuteur 11, comprenant un ou plusieurs proccssors pl, p2,.chacun desdits proccssor assurant la réalisation de proccss métier PM I. PM2,.. et notamment, le comportement effectué à la fin d'un contrat pouvant être exercé par un utilisateur, une entité nommée val idatcur 12 comprenant un ou plusieurs val idatcurs VI, V2,.. qui valident et vérifient les preuves prl, pr2,. que chaque action d'un utilisateur a bien été effectuée par ledit utilisateur, ledit système s'assurant de l'authentification de chaque utilisateur au travers d'un système de signatures partagées entre les réseaux partis prenant, le système comprend en outre un ou plusieurs containers Cl, C2,.. permettant de rnutualiscr les signatures. Lesdits containers étant signé par l'utilisateur et pouvant contenir un ou plusieurs bons bl, b2,.. lesdits bons contenant les adresses, les données et les paramètres des banques BI. B2, des processors pl, p2, .ct des validatcurs VI, V2,.. afin d'exécuter un ou plusieurs contrats sur les actifs numériques de l'utilisateur, et en cc que le protocole Meerkat permet de valider le déroulement dc l'échange d'actifs numériques Al, A2, sur la blockchain principale 20. [0013] Selon des caractéristiques particulières, chaque banque Bl, B2,.stocke des actifs Al, A2, ..et des utilisateurs Ul, U2, . chaque actif étant lié à un utilisateur, et en ce que lesdits actifs peuvent être fongibles ou non fongibles. [0014] Selon des caractéristiques particulières, chaque processor pl, p2, .est défini à la création d'un contrat et il est immutable, de telle sorte que chaque contrat a son process métier PM1, PM2,... lié. [0015] Selon des caractéristiques particulières, le container Cl, C2, .regroupe les bons, bl, . lesdits bons pouvant être prédictifs, et la signature d'un utilisateur pour un container Cl, C2, .permet de signer l'ensemble des bons dudit container. [0016] Selon des caractéristiques particulières, la structure des données dans chaque bons 111,112, .est telle qu'un utilisateur signataire est associé à une clé privée et à une signature ECDSA ou à un contrat vérifiant un format de signature personnalisé. [0017] On note que L'ECDSA est un protocole de signature utilisant la cryptographie sur les courbes elliptique, et est une variante spécifique de la cryptographie asymétrique. Cette cryptographie est utilisée dans la technologie des blockchains car, elle est plus performante que d'autres protocoles tout en utilisant des clés plus courtes pour le même niveau de sécurité. [0018] Selon des caractéristiques particulières, les bons 1,1,1,2, contiennent également des données spécifiques à la transaction utilisées par le protocole pour exécuter sa logique, et chaque bon hi, h2, .peut être lié aux bons précédents dont ils dépendent, les bons sont signés au travers des containers Cl, C2, .qui stockent leurs messages et leurs signatures, plusieurs bons peuvent appartenir à une multitude de containers Cl, C2, permettant une signature unique ou une composition à plusieurs signature, le message signé étant une fonction de hachage appartenant de la structure du bon et comprenant un préfixe de protection. [0019] L'invention concerne également le procédé de réalisation de consensus selon le protocole Meerkat mis en oeuvre dans le système de sidechain 1 ci-dessus, ledit système comprenant une entité Banque 10 comprend une ou plusieurs banques, Bi ,B2 assurant le stockage des actifs numériques Al, A2, ..et des utilisateurs Ul, U2, . auxquels ils appartiennent, une entité Exécuteur 11 comprenant un ou plusieurs processors pl, p2 , .. chacun (lesdits processors assurant la réalisation de process métier PMI, PM2, . et notamment, le comportement effectué à latin d'un contrat pouvant être exercé par un utilisateur, une entité validateur 12 comprenant un ou plusieurs validateurs VI, V2, .. qui vérifient et valident les preuves prl. pr2, ..que chaque action d'un utilisateur a bien été effectuée par ledit utilisateur, le système comprenant en outre un ou plusieurs containers Cl, C2, ..permettant la mutualisation des signatures, ledit container étant signé par l'utilisateur et pouvant contenir un ou plusieurs bons bl, b2,.. lesdits bons contenant les adresses, les données et les paramètres des banques BI, B2... des processors pl, p2, ..et des validateurs VI, V2,.. afin d'exécuter un ou plusieurs contrat sur les actifs numériques de l'utilisateur caractérisé en ce qu'il comprend des étapes suivantes : récupération du nombre de bons bl, b2 , ..dans un container ; création d'une zone mémoire pour intégrer les identifiants (lesdits bons ; vérifications des process métiers liés aux contrats dans les processors pl, p2; - vérification des validateurs VI, V2,..; - vérification des banques Bi, B2,..; - vérification des parents des bons hl, b2, . dans le container Cl, C2 ; - vérification des containersCi, C2,. ; - envoie des données aux validateurs VI, V2,. ; - envoie des données aux processors pl, p2,' ; - envoie des données, retournées par les processors pi, p2,.., aux banques Bi, B2,..;. - synchronisation et échange du ou des actifs numériques Al, A2,..d'un ou plusieurs utilisateurs Ul, U2,'avec la blockchain principale 20. [0020] L'invention concerne également, l'utilisation du système de sidechain 1 ci-dessus, dans une application dc vente aux enchères ou dans des applications utilisant la technologie de blockchain. Brève description des dessins [0021] D'autres caractéristiques, détails et avantages de l'invention ressortiront à la lecture de la description qui suit, en référence aux figures annexées, qui illustrent : [fig.1] représente le schéma des différentes entités du système de sidechain selon la présente invention. Description des modes de réalisation [0022] La figure 1 est une représentation simplifiée du système de sidechain I dans le cadre d'une utilisation de l'invention pour un système de vente aux enchères. Ce système de sidechainl permet la réalisation de consensus en mettant en place un protocole nommé Meerkat. Ledit protocole découpe la responsabilité entre trois entités qui sont les entités Banque 10, Exécuteur 11 et Validateur 12. 100231 L'entité Banque 10 comprenant un ou plusieurs banques BI, B2, .. qui stockent des actifs numériques Al, A2, .., lesdits actifs peuvent être fongibles ou non fongibles. Les banques Bl, B2, .. stockent les informations sur les utilisateurs Ul, U2,... et les actifs Al, A2. . notamment quel utilisateur possède quel actif. Un contrat est crée dès qu'un utilisateur souhaite interagir avec le système. L'entité Exécuteur 11 comprend un ou plusieurs processors pl, p2,... Dès la création d'un contrat, un processor est défini et il est immutable, les processors pl, p2, .. assurant chacun la réalisation d'un process métier PM1, PM2,..., et notamment, ils assurent le comportement effectué à la fin d'un contrat exercé, par un utilisateur. Chaque utilisateur Ul, U2, ..qui utilise le contrat le fait en pleine connaissance du process métier lié PM1, PM2,..à ce contrat. L'entité Validateur 12 contient plusieurs validateurs VI, V2,.. qui valident et vérifient les preuves prl, pr2. Les preuves prl, pr2,., déterminent que chaque action d'un utilisateur a bien été entreprise par ledit utilisateur. 6 [0024] Par ailleurs, le protocole Meerkat s'assure de l'authentification de chaque utilisateur au travers d'un système de signatures partagées entre les réseaux partis prenant. Le protocole permet à l'utilisateur de signer une ou plusieurs actions au travers d'un système de bon hi, b2, ... pouvant être regroupés dans un container Cl, C2. Le protocole est tel que seul le container est signé. Le container contient un ou plusieurs bons hl, b2,.. Chaque bon, contient l'adresse de la ou les banques Bl, B2,.., du ou des processors pi, p2,..., du ou des Validatcurs vl, v2,.., de l'opération ainsi que de leurs paramètres. Le container Cl, C2, .est signé par un ou plusieurs utilisateurs Ul, U2, .afin de satisfaire les validatcurs V1, V2,... Le protocole Meerkat défini précisément la structure de donnée à utiliser pour persister une transaction d'un réseau à un autre. [0025] La structure de chaque bon H ,b2, ..cst la suivante : un nombre aléatoire, pour permettre à des bons identiques d'avoir des hachages distincts, un identifiant réseau pour la protection contre le rejeu (blockchain principale le 20 et la sidcchain 1), adresses des signataires, index des signataires obligatoires parmi les signataires ; index des signataires facultatifs parmi les signataires ; nombre de signatures facultatives requises ; liste des parents haches ; adresse du responsable de la transaction sur la blockchain principale 20; adresse du responsable de la transaction sur la sidcchain 1; données spécifiques à la transaction ; adresse de la banque de ressources sur la blockchain principale 20 ; adresse de la banque de ressources sur la sidcchain 1 ; et les données de ressources. Les signataires peuvent être associés à une clé privée (et à une signature (v, r, s) ou une signature ECDSA) ou à un contrat vérifiant un format de signature personnalisé. [0026] Chaque container Cl, C2, .comprend les données suivantes : Une racine de l'arbre de hachage ; la liste des signatures, le format des signatures, le type d'adresse (pour une clé privée ou pour un contrat) ; l'adresse du signataire ou du contrat de vérification, l'adresse correspondant à une clé privée ou l'adresse correspondant à un contrat de vérification ; les données à vérifier par contrat. Le message signé est une fonction de hachage qui appartient au bon et comprend un préfixe de protection. [0027] Le process core ou le dispatcher qui met en place le protocole Meerkat dans le système effectue les étapes suivantes : clans le container Cl, C2, ..on récupère le nombre de bon bl, b2, .et on créée une zone de mémoire pour intégrer les identifiants des bons. Puis on vérifie les process métier liés PMI, PM2, .aux contrats dans le ou les processors pl, p2, ..pour l'ensemble des bons bl, b2,.. On vérifie ensuite les validateurs VI, V2,... Pour ce, on récupère et on stocke le nombre de validateur, puis on parcoure la liste des bons bl, b2, Enfin, on vérifie les banques BI, B2, ..pour l'ensemble des bons bl, b2, . Ensuite les parents des bons sont vérifiés dans le container Cl, C2, et on envoie les données aux validateurs VI, V2, ..et aux processors pl, p2,... Les données retournées du ou des processors sont envoyés à la ou les banques 7 Bi, B2, ... La dernière étape est la synchronisation et l'échange du ou des actifs Al, A2, ..d'un ou plusieurs utilisateurs Ul, U2, ..avec la blockchain principale 20. [0028] Exemple de smart contrat 'preuve de concept'. [0029] Un smart contract est un logiciel. Au vu de leur appellation, on a tendance à les assimiler à des contrats, mais ils n'ont pas en eux-mêmes d'autorité juridique. Lorsqu'un contrat juridique existe, le smart contract n'est qu'une application technique de cc contrat. [0030] Dans l'exemple, des actifs tels que ETH, les jetons fongibles ERC20, les jetons non fongiles ERC721 sont stockés dans des banques et liés à leurs propriétaires respectifs. Ils ne peuvent être déplacés à l'intérieur ou à l'extérieur de la banque qu'en utilisant un bon signé par le propriétaire et en suivant un protocole spécifié. Les bons contiennent aussi des données spécifiques à la transaction utilisées par le processor pour exécuter sa logique. Des bons peuvent être liés à des bons précédents dont ils dépendent. Ils sont signés au travers des containers stockant leurs messages et signatures. Plusieurs bons peuvent faire partie de plusieurs containers, permettant ainsi une signature pour plusieurs bons ou bien une composition multi-signature. [0031] Les arbres de hachage (Merkle trcc) sont utilisés pour omettre certaines données tout en vérifiant l'intégrité globale avec la racine de l'arbre de hachage. Chaque hachage a son premier octet remplacé par sa profondeur dans l'arbre. Par exemple : [0032] [Arbre 1] ABCD AB CD A BCD [0033] Dans l'arbre ci-dessus, pour fournir A et B, le tableau contiendra : 2A, 2B et 1CD. Pour fournir toutes les valeurs, le tableau contiendra : 2A, 2B, 2C et 2D. Aucun espace n'est perdu par rapport à une liste plate de hachages. [0034] Chaque processor hérite du contrat, ledit contrat, à l'aide d'une fonction, effectue des signatures et des vérifications de hachage Il appelle ensuite la fonction de proccss métier à réaliser. La fonction, à laide de laquelle le contrat effectue des signatures et des vérifications de hachage, comprend des données selon l'encodage RLP (RLP est la principale méthode de codage utilisée pour sérialiser des objets dans Ethereum) . [0035] Une fois les transactions effectuées, après réalisation des process métier, il est né- cessaire d'effectuer l'enregistrement des échanges auprès de la banque. Après avoir effectué sa vérification, le processor appelle chaque banque de bon avec les paramètres suivants : bon à dépenser, les containers utilisés, les containers non utilisés étant 8 remplacés par des valeurs vides, l'indice des bons dans les containers, et, pour chaque mouvement interne, la destination, à savoir, le nouveau propriétaire de l'actif ainsi que les données sur cet actif et enfin, pour chaque mouvement externe, le nouveau propriétaire de l'actif et les données dudit actif. [0036] La banque procédera à la vérification de la signature et de l'exactitude des montants avant d'appliquer les modifications, et stockera la valeur de hachage du bon dans sa mémoire afin qu'elle ne puisse plus être utilisée. [0037] A noter que pour chaque bon associé à une banque, le responsable de la transaction n'a pas besoin de vérifier la signature grâce à la banque. Le responsable de la transaction doit toutefois vérifier les signatures des bons non bancaires et stocker leurs hachages pour éviter leur réutilisation si nécessaire. [0038] Le système de sidechain objet de la présente invention, n'est pas une allocation de sidccoin destiné à gérer un équivalent à une blockchain principale. Il n'y a pas de circulation de monnaie interne sur ce système de sidechain, uniquement du proccss métier. La présente invention permet de verrouiller de l'argent sur la chainc principale, niais permet également de verrouiller tout type de token, notamment des tokcns non fongibles (NET). Afin d'accélérer les traitements et les consensus, les utilisations sur la sidechain sont limitées aux utilisations métier voulues. Un token déposé non utilisé peut être récupéré à tout moment. Il n'y a donc aucune période de latence d'un ou deux jours avant de pouvoir utiliser un token d'une chainc à l'autre. L'invention permet donc de s'affranchir de la conteste période. [0039] Le protocole Meerkat mise en place dans le système de sidechain de la présente invention permet de valider le déroulement de l'échange sur la blockchain principale sans que toutes les étapes de l'échange soient stockées sur la blockchain principale. Le protocole permet d'apporter la certitude que les étapes se sont déroulées avec toutes les autorisations nécessaires sans besoin du contenu complet de toutes les transactions. Chaque transaction sur la blockchain principale prend donc moins d'espace de stockage, de coût en redevance (gas) et de temps. [0040] L'invention concerne également, l'utilisation du système de sidechain ci-dessus dans une application de vente aux enchères ou dans des applications utilisant la technologie de blockchain. 9 [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4]