FR3093259A1 - Sidechain sécurisé et décentralisé réalisant des consensus pour des blockchains publique ou privée - Google Patents

Sidechain sécurisé et décentralisé réalisant des consensus pour des blockchains publique ou privée Download PDF

Info

Publication number
FR3093259A1
FR3093259A1 FR1901885A FR1901885A FR3093259A1 FR 3093259 A1 FR3093259 A1 FR 3093259A1 FR 1901885 A FR1901885 A FR 1901885A FR 1901885 A FR1901885 A FR 1901885A FR 3093259 A1 FR3093259 A1 FR 3093259A1
Authority
FR
France
Prior art keywords
user
vouchers
sidechain
processors
entity
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1901885A
Other languages
English (en)
Other versions
FR3093259B1 (fr
Inventor
Mike NOPERE
Jérémy PICOT
Daniela PIZZUTI
Etienne ROUDEIX
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Domraider
Original Assignee
Domraider
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Domraider filed Critical Domraider
Priority to FR1901885A priority Critical patent/FR3093259B1/fr
Publication of FR3093259A1 publication Critical patent/FR3093259A1/fr
Application granted granted Critical
Publication of FR3093259B1 publication Critical patent/FR3093259B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3255—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using group based signatures, e.g. ring or threshold signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Sidechain sécurise et décentralisé réalisant des consensus pour des blockchains publique ou privée . L’invention a trait à un système de sidechain permettant la réalisation d’un ou plusieurs consensus pour des actifs numérique caractérisé en ce qu’il est sécurisé et décentralisé et communique avec une blockchain principale, publique ou privée, en utilisant un protocole, nommé Meerkat, permettant de réaliser un ou plusieurs consensus, et en ce qu’il comprend une entité Banque comprenant une ou plusieurs banques, assurant le stockage des actifs numériques et des utilisateurs, une entité Exécuteur, comprenant un ou plusieurs processors, chacun processor assurant la réalisation de process métier, une entité validateur comprenant des validateurs qui valident les preuves que chaque action d’un utilisateur a bien été effectuée par lui, 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, permettant de mutualiser les signatures, lesdits containers étant signé par l’utilisateur et contient un ou plusieurs bons, lesdits bons contenant les adresses, les données et les paramètres des banques, des processors et des validateurs, afin d’exécuter un ou plusieurs contrats sur les actifs numériques de l’utilisateur. Protocole Meerkat permet de valider le déroulement de l'échange d’actifs numériques sur la blockchain principale. L’invention concerne en outre le procédé mise en œuvre dans le système ainsi que l’utilisation du système de sidechain dans une vente aux enchères et dans les systèmes utilisant la technologie de blockchain. Figure à publier avec l’abrégé : Fig. 1

Description

Sidechain sécurisé et décentralisé réalisant des consensus pour des blockchains publique ou privée
L’invention se rapporte au domaine de blockchain ou chaine de bloc. Plus particuliè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.
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.
Cela implique que la technologie blockchain ne peut compter sur aucune source exté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”).
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é.
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 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.
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 liés à la sécurité.
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.
Enfin, une dernière solution proposée consiste en la création des Sidechains. En effet, des nombreuses applications ont “délocalisé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.
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é.
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 publique Ethereum (le “gas”) pour chaque offre, et, d’avoir un délai de validation de celle-ci inférieur à une seconde.
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.
L’invention vise à remédier aux inconvénients de l’état de la technique et notamment à proposer un système de sidechain 1 permettant la réalisation d’un ou plusieurs consensus pour des actifs numériques caractérisé en ce 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 ce qu’il comprend une entité nommée Banque 10 comprenant une ou plusieurs banques B1, B2,.. assurant le stockage des actifs numériques A1, A2,. et des utilisateurs U1, U2,…auxquels ils appartiennent, uns entité nommée Exécuteur 11, comprenant un ou plusieurs processors p1, p2,.chacun desdits processor assurant la réalisation de process métier PM1, PM2,.. et notamment, le comportement effectué à la fin d’un contrat pouvant être exercé par un utilisateur, une entité nommée validateur 12 comprenant un ou plusieurs validateurs V1, V2,.. qui valident et vérifient les preuves pr1, 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 C1, C2,.. permettant de mutualiser les signatures. Lesdits containers étant signé par l’utilisateur et pouvant contenir un ou plusieurs bons b1, b2,.. lesdits bons contenant les adresses, les données et les paramètres des banques B1, B2, des processors p1, p2, .et des validateurs V1, V2,.. afin d’exécuter un ou plusieurs contrats sur les actifs numériques de l’utilisateur, et en ce que le protocole Meerkat permet de valider le déroulement de l'échange d’actifs numériques A1, A2, . sur la blockchain principale 20.
Selon des caractéristiques particulières, chaque banque B1, B2,.stocke des actifs A1, A2, ..et des utilisateurs U1, U2, . chaque actif étant lié à un utilisateur, et en ce que lesdits actifs peuvent être fongibles ou non fongibles.
Selon des caractéristiques particulières, chaque processor p1, 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é.
Selon des caractéristiques particulières, le container C1, C2, .regroupe les bons, b1, b2, . lesdits bons pouvant être prédictifs, et la signature d’un utilisateur pour un container C1, C2, .permet de signer l’ensemble des bons dudit container.
Selon des caractéristiques particulières, la structure des données dans chaque bons b1, b2, .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é.
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é.
Selon des caractéristiques particulières, les bons b1, b2, contiennent également des données spécifiques à la transaction utilisées par le protocole pour exécuter sa logique, et chaque bon b1, b2, .peut être lié aux bons précédents dont ils dépendent, les bons sont signés au travers des containers C1, C2, .qui stockent leurs messages et leurs signatures, plusieurs bons peuvent appartenir à une multitude de containers C1, 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.
L’invention concerne également le procédé de réalisation de consensus selon le protocole Meerkat mis en œuvre dans le système de sidechain 1 ci-dessus, ledit système comprenant une entité Banque 10 comprend une ou plusieurs banques, B1,B2 ,.. assurant le stockage des actifs numériques A1, A2, ..et des utilisateurs U1, U2, . auxquels ils appartiennent, une entité Exécuteur 11 comprenant un ou plusieurs processors p1, p2 , .. chacun desdits processors assurant la réalisation de process métier PM1, PM2, . et notamment, le comportement effectué à la fin d’un contrat pouvant être exercé par un utilisateur, une entité validateur 12 comprenant un ou plusieurs validateurs V1, V2, .. qui vérifient et valident les preuves pr1, 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 C1, C2, ..permettant la mutualisation des signatures, ledit container étant signé par l’utilisateur et pouvant contenir un ou plusieurs bons b1, b2, .. lesdits bons contenant les adresses, les données et les paramètres des banques B1, B2,.. des processors p1, p2, ..et des validateurs V1, 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 b1, b2 , ..dans un container ;
  • création d’une zone mémoire pour intégrer les identifiants desdits bons ;
  • vérifications des process métiers liés aux contrats dans les processors p1, p2;
  • vérification des validateurs V1, V2,..;
  • vérification des banques B1, B2,..;
  • vérification des parents des bons b1, b2, . dans le container C1, C2 ;
  • vérification des containersC1, C2,. ;
  • envoie des données aux validateurs V1, V2,. ;
  • envoie des données aux processors p1, p2,.. ;
  • envoie des données, retournées par les processors p1, p2,.., aux banques B1, B2,..; .
  • synchronisation et échange du ou des actifs numériques A1, A2,..d’un ou plusieurs utilisateurs U1, U2,..avec la blockchain principale 20.
L’invention concerne également, l’utilisation du système de sidechain 1 ci-dessus, dans une application de vente aux enchères ou dans des applications utilisant la technologie de blockchain.
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 :
représente le schéma des différentes entités du système de sidechain selon la présente invention.
La figure 1 est une représentation simplifiée du système de sidechain 1 dans le cadre d’une utilisation de l’invention pour un système de vente aux enchères. Ce système de sidechain1 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.
L’entité Banque 10 comprenant un ou plusieurs banques B1, B2, .. qui stockent des actifs numériques A1, A2, .., lesdits actifs peuvent être fongibles ou non fongibles. Les banques B1, B2, .. stockent les informations sur les utilisateurs U1, U2,… et les actifs A1, 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 p1, p2,... Dès la création d’un contrat, un processor est défini et il est immutable, les processors p1, 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 U1, 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 V1, V2,.. qui valident et vérifient les preuves pr1, pr2. Les preuves pr1, pr2,., déterminent que chaque action d’un utilisateur a bien été entreprise par ledit utilisateur.
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 b1, b2, … pouvant être regroupés dans un container C1, C2. Le protocole est tel que seul le container est signé. Le container contient un ou plusieurs bons b1, b2,.. Chaque bon, contient l’adresse de la ou les banques B1, B2,.., du ou des processors p1, p2,…, du ou des Validateurs v1, v2,.., de l’opération ainsi que de leurs paramètres. Le container C1, C2, .est signé par un ou plusieurs utilisateurs U1, U2, .afin de satisfaire les validateurs 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.
La structure de chaque bon b1, b2, ..est 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 sidechain 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 sidechain 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 sidechain 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é.
Chaque container C1, 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.
Le process core ou le dispatcher qui met en place le protocole Meerkat dans le système effectue les étapes suivantes : dans le container C1, C2, ..on récupère le nombre de bon b1, 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 PM1, PM2, .aux contrats dans le ou les processors p1, p2, ..pour l’ensemble des bons b1, b2,. . On vérifie ensuite les validateurs V1, V2,... Pour ce, on récupère et on stocke le nombre de validateur, puis on parcoure la liste des bons b1, b2, .. Enfin, on vérifie les banques B1, B2, ..pour l’ensemble des bons b1, b2, . Ensuite les parents des bons sont vérifiés dans le container C1, C2, et on envoie les données aux validateurs V1, V2, ..et aux processors p1, p2,... Les données retournées du ou des processors sont envoyés à la ou les banques B1, B2, ... La dernière étape est la synchronisation et l’échange du ou des actifs A1, A2, ..d’un ou plusieurs utilisateurs U1, U2, ..avec la blockchain principale 20.
Exemple de smart contrat ‘preuve de concept’.
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 ce contrat.
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.
Les arbres de hachage (Merkle tree) 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 :
[Arbre 1]

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.
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 process 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) .
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 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.
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.
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.
Le système de sidechain objet de la présente invention, n'est pas une allocation de sidecoin 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 process métier. La présente invention permet de verrouiller de l'argent sur la chaine principale, mais permet également de verrouiller tout type de token, notamment des tokens non fongibles (NFT). 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 chaine à l'autre. L‘invention permet donc de s'affranchir de la conteste période.
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.
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.

Claims (9)

  1. Système de sidechain (1) permettant la réalisation d’un ou plusieurs consensus pour des actifs numérique caractérisé en ce 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 ce qu’il comprend une entité nommée Banque (10) comprenant une ou plusieurs banques (B1, B2,..) assurant le stockage des actifs numériques (A1, A, ..) et des utilisateurs (U1, U2,..) auxquels ils appartiennent, une entité nommée Exécuteur (11) , comprenant un ou plusieurs processors (p1, p2, ..), chacun desdits processor assurant la réalisation de process métier (PM1, PM2,..) et notamment, le comportement effectué à la fin d’un contrat pouvant être exercé par un utilisateur, une entité nommée validateur (12) comprenant des validateurs (V1, V2,..) qui valident et vérifient les preuves (pr1, 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 (1) comprend en outre un ou plusieurs containers (C1, C2,..) permettant de mutualiser les signatures, lesdits container (C1, C2,..) étant signé par l’utilisateur et pouvant contenir un ou plusieurs bons (b1, b2,..) lesdits bons contenant les adresses, les données et les paramètres des banques (B1, B2, ..) des processors ( p1, p2, ..) et des validateurs (V1, V2,..) afin d’exécuter un ou plusieurs contrats sur les actifs numériques (A1, A2, ..) de l’utilisateur, et en ce que le protocole Meerkat permet de valider le déroulement de l'échange d’actifs numériques sur la blockchain principale (20).
  2. Système de sidechain (1) selon la revendication 1 caractérisé en ce que chaque banque (B1, B2, ..) peut stocker des actifs (A1, A2,..) et des utilisateurs (U1, U2,..) chaque actif étant lié à un utilisateur, et en ce que lesdits actifs peuvent être fongibles ou non fongibles.
  3. Système de sidechain (1) selon la revendication 1 caractérisé en ce que chaque banque (B1, B2,..) procède à la vérification de la signature et à l’exactitude des montants avant d’appliquer les modifications, et stocke la valeur de hachage du bon (b1, b2,..) dans sa mémoire afin qu’elle ne puisse plus être utilisée.
  4. Système de sidechain (1) selon la revendication 1 caractérisé en ce que chaque processor (p1, p2,..) est défini à la création d’un contrat et qu’il est immutable, de telle sorte que chaque contrat a son process métier (PM1, PM2) lié.
  5. Système de sidechain (1) selon la revendication 1 caractérisé en ce que le container (C1, C2, ..) regroupe les bons (b1, b2, .), lesdits bons pouvant être prédictifs, et en ce que la signature d’un utilisateur pour un container permet de signer l’ensemble des bons dudit container.
  6. Système de sidechain (1) selon la revendication 1 caractérisé en ce que la structure des données dans chaque bon (b1, b2, ..) 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é.
  7. Système de sidechain (1) selon l’une des revendication 5 ou 6 caractérisé en ce que les bons (b1, b2, ..) contiennent également des données spécifiques à la transaction utilisées par le protocole pour exécuter sa logique, et en ce que chaque bon (b1, b2, ..) peut être lié aux bons précédents dont ils dépendent, et en ce que les bons sont signés au travers des containers (C1, C2,..) qui stockent leurs messages et leurs signatures, et en ce que plusieurs bons peuvent appartenir à une multitude de containers permettant une signature unique ou une composition à plusieurs signature, le message signé étant une fonction de hachage de la structure du bon et comprenant un préfixe de protection .
  8. Procédé de réalisation de consensus selon le protocole Meerkat mis en œuvre dans le système de sidechain (1), selon les revendications 1 à 7, ledit système comprenant une entité Banque (10) comprenant une ou plusieurs banques (B1, B2,..) assurant le stockage des actifs numériques (A1, A2, ..) et des utilisateurs (U1, U2, ..) auxquels ils appartiennent, une entité Exécuteur (11) comprenant un ou plusieurs processors (p1, p2,..) chacun desdits processors, assurant la réalisation de process métier (PM1, PM2,..) et notamment, le comportement effectué à la fin d’un contrat pouvant être exercé par un utilisateur, une entité validateur (12) comprenant un ou plusieurs validateurs (V1, V2, ..) qui valident et vérifient les preuves (pr1, pr2, ..) que chaque action d’un utilisateur a bien été effectuée par ledit utilisateur, le système comprend en outre un ou plusieurs container (C1, C2, ..) permettant la mutualisation des signatures , lesdits container (C1, C2, ..) étant signé par l’utilisateur et pouvant contenir un ou plusieurs bons(b1, b2, ..) lesdits bons contenant les adresses, les données et les paramètres des banques, des processors et des validateurs afin d’exécuter un ou plusieurs contrat sur les actifs numériques de l’utilisateur, le procédé est caractérisé en ce qu’il comprend des étapes suivantes :
    • récupération de nombre de bon dans un container (C1, C2..) ;
    • création d’une zone mémoire pour intégrer les identifiants desdits bons (b1, b2, ..);
    • vérifications des process métiers (PM1, PM2, ) liés aux contrats dans les processors (p1, p2,..);
    • vérification des validateurs (V1, V2,..) ;
    • vérification des banques (B1, B2,..);
    • vérification des parents des bons dans le container (C1, C2, ..);
    • vérification des containers (C1, C2, ..) ;
    • envoie des données au validateur (V1, V2,..) ;
    • envoie des données au processor (p1, p2,..);
    • envoie des données, retournées par le processor, à la banque (B1, B2,..);
    • synchronisation et échange du ou des actifs numériques d’un ou plusieurs utilisateurs avec la blockchain principale (20).
  9. Utilisation du système de sidechain (1) selon les revendications 1 à 7 dans une application de vente aux enchères ou dans des applications utilisant la technologie de blockchain.
FR1901885A 2019-02-25 2019-02-25 Sidechain sécurisé et décentralisé réalisant des consensus pour des blockchains publique ou privée Active FR3093259B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1901885A FR3093259B1 (fr) 2019-02-25 2019-02-25 Sidechain sécurisé et décentralisé réalisant des consensus pour des blockchains publique ou privée

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1901885 2019-02-25
FR1901885A FR3093259B1 (fr) 2019-02-25 2019-02-25 Sidechain sécurisé et décentralisé réalisant des consensus pour des blockchains publique ou privée

Publications (2)

Publication Number Publication Date
FR3093259A1 true FR3093259A1 (fr) 2020-08-28
FR3093259B1 FR3093259B1 (fr) 2022-11-04

Family

ID=67107807

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1901885A Active FR3093259B1 (fr) 2019-02-25 2019-02-25 Sidechain sécurisé et décentralisé réalisant des consensus pour des blockchains publique ou privée

Country Status (1)

Country Link
FR (1) FR3093259B1 (fr)

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "POA Network Whitepaper . poanetwork/wiki Wiki . GitHub", 28 September 2018 (2018-09-28), XP055625963, Retrieved from the Internet <URL:https://github.com/poanetwork/wiki/wiki/POA-Network-Whitepaper> [retrieved on 20190925] *
HAVE FUN CORPORATION: "A consumer token designed for merchants", 1 January 2018 (2018-01-01), XP055625873, Retrieved from the Internet <URL:https://cryptototem.com/wp-ico/img/files/baNr8J9WIaq4j0nIbaNcwBmfbYB2vvPV35H6tHcF.pdf> [retrieved on 20190925] *
JOHNNY DILLEY ET AL: "Strong Federations: An Interoperable Blockchain Solution to Centralized Third-Party Risks", 16 December 2016 (2016-12-16), XP055625896, Retrieved from the Internet <URL:https://arxiv.org/pdf/1612.05491.pdf> [retrieved on 20190925] *

Also Published As

Publication number Publication date
FR3093259B1 (fr) 2022-11-04

Similar Documents

Publication Publication Date Title
Franco Understanding Bitcoin: Cryptography, engineering and economics
Kaur et al. Scalability in blockchain: Challenges and solutions
EP1441313B1 (fr) Procédé cryptographique à clé publique pour la protection d&#39; une puce électronique contre la fraude
WO2017122187A2 (fr) Procédés et systèmes mis en œuvre dans une architecture en réseau de nœuds susceptibles de réaliser des transactions basées sur messages
CN110941673A (zh) 区块链数据结构及任务处理方法和装置
Vallois et al. Bitcoin transaction: From the creation to validation, a protocol overview
FR3059802A1 (fr) Procede de generation d&#39;une signature electronique d&#39;un document associe a un condensat
Grushack Currency 3.0, Examining Digital Crypto Currency Markets
WO2006048524A1 (fr) Procede de delegation securisee de calcul d&#39;une application bilineaire
EP3767876A1 (fr) Procede de verification d&#39;une transaction dans une base de donnees de type chaine de blocs
EP1166496A1 (fr) Procede d&#39;authentification et de signature de message utilisant des engagements de taille reduite et systemes correspondants
Parham et al. Non-fungible tokens: Promise or peril?
Fajri et al. Hybrid lightning protocol: An approach for blockchain scalability issue
KR20190099365A (ko) 블록체인 기술을 이용한 모바일 게임 사용자 정보 관리 및 아이템 거래
EP1266364B1 (fr) Procede cryptographique de protection contre la fraude
EP1086547B1 (fr) Procede de securisation d&#39;un ou plusieurs ensembles electroniques mettant en oeuvre un algorithme crytographique avec cle secrete, et l&#39;ensemble electronique
US11880836B1 (en) Gated control for blockchain units
WO2017162930A2 (fr) Dispositif d&#39;authentification biométrique adaptatif par échographie, photographies en lumière visible de contraste et infrarouge, sans divulgation, à travers un réseau informatique décentralisé
FR3062499A1 (fr) Procede de reduction de la taille d&#39;une base de donnees repartie de type chaine de blocs, dispositif et programme correspondant
EP1721246B1 (fr) Procede et dispositif pour accomplir une operation cryptographique
FR2834841A1 (fr) Procede cryptographique de revocation a l&#39;aide d&#39;une carte a puce
FR3093259A1 (fr) Sidechain sécurisé et décentralisé réalisant des consensus pour des blockchains publique ou privée
EP0769768B1 (fr) Procédé cryptographique de protection contre la fraude
EP3284209B1 (fr) Procédés de génération et de vérification d&#39;une clé de sécurité d&#39;une unité monétaire virtuelle
US20240354758A1 (en) Gated control for blockchain units

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20200828

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5