Brevet FR3085076A1 — publié le 20200221

Description Titre de l'invention : Procédé de notarisation de masse sans reçu de notarisation et décentralisé en blockchains et espace à adressage par contenu. [0001] _a présente invention concerne un procédé permettant de notariser en masse en blockchain une grande quantité de documents puis de vérifier la notarisation effective de chaque document sur la seule base de son empreinte et de son nom. On exploite, si il s'agit d'un fichier sensoriel (photo, vidéo, enregistrement sonore), un procédé permettant d'avoir en plus une date de création du document à notariser une notarisation ne permettant que d'apporter la preuve d'existence d'un document à une date donnée et pas sa date de création. Le serveur de la présente invention (l'invention) fournit une adresse de notarisation. La chaîne de caractère de cette adresse est exploitée pour renommer chaque document ayant fait l'objet d'une telle notarisation, qu'elle soit instantanée ou consolidée. Contrairement à l'état actuel de l'art, grâce à l'invention, on obtient d'une part une notarisation totalement décentralisée et d'autre part une vérification sans aucune nécessité d'un. reçu de notarisation : [00021 - grâce à l'absence de reçu de notarisation, la vérification se limite à de la lecture d'information en blockchain et la recherche d'une chaîne de caractère (celle de l'adresse de notarisation) dans un Fichier localisé dans un espace de stockage décentralisé à adressage par contenu ; cette vérification s'opère grâce à une interface elle-même décentralisée (l'équivalent d'un contrat intelligent ou. Smart commet); le mode opératoire de la vérification est une simple sélection du fichier notarisé, un simple glisser/déposer dans un champ de ladite interface; [00031 - grâce à la nature totalement décentralisée, l'intégrité de la tot rlité desdonnées et traitements d'exploitation du présent procédé est. cryptographiquement vérifiable, elle l'est de façon autonome ; en tenues non techniques et en quelques mots : il n'y a pas besoin de tiers de confiance; donc ni serveur d'horoclatation ni serveur centralisé de stockage des reçus de notarisation de l'état de l'an; [0004] Ci-après, pour expliciter la solution technique apportée par l'invention au problème technique posé par la notarisation de masse de l'état de l'ait, il est développé deux parties : l'état de la technique antérieure puis un expose de l'invention illustré par les figures relatives à un mode de réalisation qui est numériquement exemplifié. Ainsi : [0005j - on précise ce qu'est une notarisation, notamment une notarisation de masse qui consiste, en chaque cycle, à regrouper un ensemble d'empreintes de documents à notariser, à regrouper ces empreintes dans un fichier (généralement sous la forme d'un arbre de Merkle), puis à graver en blockchain l'empreinte (généralement la racine de l'Aerkle) de ce fichier, [0006[ - on explique le problème de l'état de l'art qui est de deux ordres : [0007; a. - obligation de gérer un document de preuve qui est le reçu de notarisation : cette obligation est la contre-partie de la notarisation de masse, on notarise pour une pluralité de documents mais chacun d'eux se voit dans l'obligation de gérer ce document supplémentaire, [0008, h. - la nécessité d'exploiter au moins un serveur centralisé dborodatation pour délivrer une information de datation et de. notarisation dans les plus bref délais (quelques secondes); la durée de réalisation d'une transaction sécurisée (confirmée/consolidée) en hiockchain sécurisée (Bitcoin, Ethereum,.) étant très longue (en dizaine de minutes), [0009; - on détaille. la solution technique apportée par l'invention qui résout l'un et l'autre. L'explication de la solution de l'invention est assortie de figures qui explicitent et exemplifient un mode de réalisation, Brièvement, sans évoquer le procédé mais l'architecture, cette solution consiste à décentraliser les informations de notarisation dans [ )010] a. - un système de fichier à adressage par contenu, typiquement de type Inter- Planetary File System (IPES) ou équivalent tEthereurn Swarm, ..), [0011; h. - au moins une hiockchain publique à grande rapidité d'exécution des transactions, par exemple dotée d'un consensus distribué de type "preuve d'enjeu" (F,OS, Tezos,..) ou autres mécanismes (Stellar, IOTA, Bytehall...), pour permettre l'obtention quasi immédiate de l'adresse de notarisation instantanée sans l'appel à un serveur d'horodatation, [00121 c. une deuxième blockchain publique pour consolider la notarisation sur une infra- structure très sécurisée et très décentralisée qui exploite typiquement un consensus distribué de type "preuve de travail" (Bitcoin, Fibereum,...). Cette notarisation consolidée, effectuée à une fréquence temporelle plus basse, délivre une adresse de notarisation consolidée définitive, L'adresse de notarisation instantanée reste cependant totalement opérationnelle. Technique antérieure [00131 Fonctionnellement, nolariser un document consiste à l'horodater et d'être en mesure d'en prouver la datation et l'intégrité dans le temps. La notarisation apporte une preuve d'existence d'un document ou d'une information, en l'exact état, à une date donnée par la transaction de notarisation dans la blockchain exploitée. On n'évoque pas ici les infrastructures centralisées publiques étatiques d'hmodatation. On peut notariser tout. type de document / information document de formalisation d'oeuvres de l'esprit (idées, concepts, art, ..) pour en prouver l'antériorité, de vidéos, d'images, de diplômes, de logiciels, de titres de propriété,d'actes de procédures, d'informations de capteurs, de transferts d'actifs,... bref, l'invention est susceptible de commercialisation à grande échelle tant pour les particuliers que les professionnels et ce, dans pratiquement tous les domaines de l'économie et de l'administration publique. Il s'agit principalement des domaines présentant des nécessités de traçahilité, de certification et d'horodatation (logistique, distribution, assurance, banque, justice, éducation, santé, immobilier, cadastre, notariat, transport, .... ). il est fonctionnellement identique de notariser le contenu entier du document (son contenu est "gravé" en blockchain), de, notariser empreinte de son contenu ou de notariscr l'empreinte d'un document incluant l'empreinte de son contenu. L'empreinte (haché ou condensas) est par exemple obtenue avec une fonction de hachage de type. Secure Flash Algorithm sur 256 bits (SHA-256). Compte tenu du coût prohibitif du "gravage" (stockage) de donnée en hlockchain, c'est le troisième modo qui est exploité par l'état de l'art ll s'agit de la notarisation de masse qui exploite essentiellement la technique des arbres de Merkie. Concernant la notarisation sous blockchain, l'homme de l'art pourra se référer au document FR17714.54 (demande. de brevet d'invention du 31 décembre 2017), en particulier de la page 12 ligne 16 à la page 16 ligne 18. Ce document, rédigé par l'auteur de la présente invention, expose longuement les différentes techniques de notarisation. Pour la notarisation de masse de l'état de l'art, notariser un document implique quatre groupes d'informations [00141 a. le document lui même, 100151 h. - son empreinte cryptographique, [00161 c. - son reçu de notarisation ou preuve, [00171 d, la valeur de son ancre gravée dans ut e blockchain. 1.00181 Techniquement, notariser un document consiste à écrire (graver) dans une blockchain une ancre mathématiquement univoquemenl liée à l'empreinte du contenu du document. Le reçu de notarisation permet de prouver ce lien univoque. La révérence de notarisation présente dans le reçu de notarisation précise en particulier quelle est la hlockha.in qui a été exploitée et le numéro de la transaction qui a permis la notarisation. notarisation permet alors de prouver que le document ainsi nolarisé existait dans l'exact état (intégrité) à la. date (horodatation) donnée par la transaction de notarisation de son ancre dans la blockchain exploitée. Selon les "normes" exploitées, il peut exister plusieurs ancres dont une émanant d'un serveur d'horodatation. Ce dernier permet d'avoir une datation plus précise et permet de retourner rapidement un premier résultat aux clients de tels serveurs de notarisation. Par contre, l'existence de serveurs d'horodation introduit de la centralisation : ils peuvent dysfonctionner ou faire l'objet d'acte de malveillance. Dans le cadre de l'invention, on se place donc en situation ou l'utilisateur dispose de son document dans son propre système de fichier avant et après la notarisation dc masse. Il notarisc et vérifie notarisation avec une simple selection de son document. Ce document n'est pas stocké dans une blockchain car le coût y est prohibitif, mémo si dans certaine blockchain plus centralisée (celle à consensus en preuve d'enjeu ou structurées sous la forme de graphe orienté acyclique) ce coût est réduit. Ainsi, dans l'état de Fart, les principaux "standard" pour la notarisation de masse sont Chainpoint (chainpoint.org), Opentimestamps (opend mestarrips,org,) et Originstamp (originstamp.org). Le plus exploité est certainement Chainpoint. Il est mis en oeuvre par la société Tierion et soutenu par les sociétés Microsoft et Philips, Opentimestamps est plus ouvert et a par exemple été préféré à Chainpoint par l'administration Suisse (canton de Genève) pour renforcer et sécuriser la délivrance d'extrait électronique (registre du commerce) cf document de début 2018 qui justifie le choix de opcntimestamps plutôt que chainpoint https://www.ge.chidocument/rapportoxporimentation-blockchain. Originstamp adresse plutôt directement les particuliers, le grand public. Les notarisations y sont gratuites, elles «impliquent pas de serveur d'horodatation, mais, ce qui illustre le coût et les contraintes de temps des processus de notarisation de masse, clic ne s'effectue que par cycle de 24 heures. Il faut donc attendre un maximum de 24 heures pour obtenir un reçu de notarisation de son document. Selon les "standards" Chainpoint et Opentimestamps, il est retourné un reçu de notarisation dont le contenu est structuré autour d'un arbre de Merkle. Un arbre de Nilerkle est produit à chaque cycle. Le reçu de notarisation délivré à chaque client contient son chemin de Merkle, de la. feuille à la racine. Le chemin de Merkle est propre à chaque client, Chaque feuille a la valeur de empreinte d'un document (celui du client). Cette technique permet à chaque client d'avoir en sa possession la preuve de la notarisation de son document. Le reçu de notarisation selon opentimestamps est (à l'origine) différent, n'exploitant pas les arbres de Merkle, il est le cas échéant plus volumineux, Il se présente sous la Corme d'un simple fichier texte regroupant l'ensemble des empreintes des documents soumis par les clients lors d'un cycle de 24 heures. En fin de cycle, on produit l'empreinte de ce fichier, Cette empreinte est exploitée comme la clé privée d'une adresse de la blockchain Blicoin. Il est alors procédé à une transaction vers cette adresse qui constitue l'ancre de tous les documents notarisés dans le même cycle avec ce même fichier d'empreintes. Les trois standards évoqués exploitent les blockchains Bitcoin Ou Ethereum, les plus sécurisées et décentralisées. Selon ces trois standards, pour vérifier une notarisation, il faut alors soumettre à une interface (page web) le document el son reçu de notarisation. L'interface est alors en mesure d'effectuer les calculs cryptographiques qui permettent de recalculer l'ancre : la racine de Merkle (Chainpoint, Opentimestamps) ou l'adresse Bitcoin (originstamp) puis d'aller consulter la transaction en blockchain qui a permis de graver cette ancre. Selon l'état de l'art, toute la pro- Nématique se situe donc au niveau de l'existence de cc reçu de no don qu'il it gérer, soit très concrètement pour chaque client, sachant qu'il sert de support de preuve pour lancer des calculs cryptographiques de vérification [0019] a. - il faut le stocker, [0020] h. - il faut en garantir la permanence d'accès, [0021] c. il faut en garantir l'intégrité dans le temps, [0022] d. - il faut garantir dans le temps le lien univoque entre le document original nntarisé et son reçu de notarisation [00 e. - il faut à chaque vérification relancer des calculs cryptographiques liés aux in- formations présentent dans le reçu de notarisation, ce qui n'est pas le cas avec la présente invention. [0024] Face. à cc problème, quand les serveurs des trois standard évoques proposent une solution, elle consiste simplement à gérer à la place du client cc reçu de notarisation en l'archivant dans une base de données sur leur serveur. On perd ici tous les bénéfices de la décentralisation si la société ou son serveur n'existe plus, alors on perd à tout jamais la preuve de la notarisation de son document. Accessoirement, on remarque aussi que selon ces trois standards, exploiter une interface de vérification introduit encore de la centralisation, Elle est hébergée par un serveur centralisé. Si cc dernier dysfonctionne ou est l'objet de malveillance, alors on ne peut pas prouver la notarisation. Outre les problèmes de centralisation évoqués pour ces trois standards de l'état de l'art, ce problème de reçu de notarisation est bloquant, notamment pour le secteur dit de 'Internet of Things (Jol), Pour prendre un exemple concret de cette problématique bloquante, évoquons le cas d'une société qui centralise les informations en provenance d'une multitude de capteurs de température. Ces milliers de capteurs sont ceux installés dans des petits réfrigérateurs, localisés en différents endroits d'un pays. Ils transmettent typiquement, en France, une petite quantité d'information sur de longues distances sur les réseaux radio LoRa ou Sigfox. Ces petits réfr.gé ateurs conservent à basse température les vaccins produit par une grande société pharmaceutique. Ces vaccins doivent en permanence être maintenu à une température inférieure à une valeur donnée, Les milliers de capteurs envoient toutes les 15 secondes une information qui peut tenir dans un document (un fichier) de moins de 100 octets. Cette information est par exemple : l'identifiant du capteur, l'identifiant du réfrigérateur, les identifiants des ts lots de vaccins qu'il contient, la date, l'heure et la valeur de la température. Idéalement, ces informations doivent être notarisées pour permettre de prouver ultérieurement ou en cas d'accident, que la chaîne du froid a été respectée pendant le transport et la basse température a été maintenu pendant les jours ou les semaines de stockage sur les lieux de l'utilisation, Pour notariser chacun de ces fichiers de 100 octets, l'état de l'art de la notarisation de masse retourne pour chacun un reçu de nota- es risation de plusieurs milliers d'octets. Ainsi, le reçu de notarisation donné en exemple sur le site Internet chainpointorg a une taille de 6051 octets. Selon les cycles et le standard, il peut être beaucoup plus volumineux. Les sociétés qui centralisent les milliers de petits fichiers reçus de capteurs IoT chaque. minute et qui voudrait chacun les notariser se retrouverait alors en plus à gérer pour chacun d'eux, un autre fichier (le reçu de notarisation) pouvant être plus de 60 fois plus volumineux que le document original à notariser. Gérer implique les actions sus-évoquées stocker, garantir la permanence d'accès et l'intégrité ainsi que le lien univoque entre le document notarisé et son reçu de notarisation. Si tout ceci est bien effectué, une vérification implique alors pour chacun des calculs cryptographiques sur la hase du reçu de notarisation et de plus, le serveur les réalisant est un tiers de confiance susceptible de disparaître, de dysfonctionner ou être l'objet de malveillance. [0025] La présente invention apporte une solution technique à ces problèmes techniques de l'état de l'art. A chaque cycle de moins de 10 secondes, la notarisation de masse de l'invention retourne à chaque client une simple adresse de notarisation instantanée identique pour tous. Les clients renomment leur document en y ajoutant la chaîne de caractère de l'adresse de notarisation (de moins de 50 caractères). Il n'y a plus aucun reçu de notarisation à gérer. La vérification s'opère par un simple glisser/déposer (ou une sélection notamment pour les vérifications automatisées) du document dans un champ de l'interface décentralisée d'un serveur. Lors de la première vérification, si une adresse de notarisation consolidée (par exemple sur la. blockchain Ethereum) est disponible, alois elle esl proposée optionnellement au client pour un renommage définitif de son document. La première adresse de notarisation instantanée restant toujours opérationnelle sans limite de temps (on exploite ici le concept de déduplication de IPES qui permet de ne pas dupliquer, donc de conserver, les fichiers puisqu'ils sont référencés par leur condensai. qui reste immuable), L'adresse de notarisation est obtenue en moins de 10 secondes, le temps d'une transaction de notarisation sur une blockchain à grande vitesse de transaction. Cette interface est elle même dans un espace décentralisé (par exemple de type Inter-Planery Naming System) de façon à garantir son intégrité el sa permanence d'accès sans tiers de confiance. Cette interface, toujours accessible à la même adresse IPNS même si son contenu évolue, est par exemple doté de code javascript. On obtient ainsi l'équivalent d'un contrat intelligent (Smart contract) qui exécute de façon immuable le code ouvert, accessible à tous et vérifiable. L'invention irtmlémenle en tout point et de façon effective l'horodatage décentralisé (Decentralized Trusted Ti inestamping) : tous les protocoles exploités étant transparents, résilients et infalsifiables. L'ultime complément peut être que la clé publique associée à l'adresse IPNS fixe de l'interface de vérification soit celle d'un acteur public étatique de référence en malière. de certifïcationlhorodaiation. Cette clé publique est alors largement publiée et connue des clients. Si il en était besoin, cette clé publique est l'information minimum, ultime, atomique, qui relie la puissance fonctionnelle des systèmes informatiques décentralisés ct la réalité concrète, administrative., centralisée de tout un chacun. L'invention peut donc être légitiment exploitée par tout les états et administrations publiques et par extension le grand public pour le quotidien dans tous les secteurs économiques et administratifs. [0026] Exposé de l'invention illustré par les figures d'un mode de réalisation numériquement exemplifié [0027] Globalement l'invention permet [002$] a. une notarisation de masse et une vérification unitaire l'une et l'autre effectivement décentralisées, indépendantes de serveurs centralisés d'horodatation ou d'interfaces de vérifications centralisées [0029] h. - une notarisation et vérification quasi instantanées (de l'ordre de quelques secondes) [0030] e. - une notarisation consolidée sur une des plus robuste et sécurisée des blockchains qui exploitent un consensus distribué. de type preuve de travail (Proof-of-Work PoW) avec un taux de hachage de plusieurs centaines (Ethereum) à plusieurs millions (Bitcoin) de TerraHash par seconde (un TerraHash est égal à mille milliards de hash, ou calcul d'empreinte) [00311 d. une vérification de chaque document sur la seule base de son empreinte et de son nom, sans la nécessité d'un reçu de notarisation, donc sur la simple sélection d'un fichier dans une interface dédiée, [00321 e. - une vérification simplifiée, qui se limite à la lecture de contenu et la recherche d'une chaîne de caractère celle de l'adresse de notarisation instantanée et/ou consolidée. [00331 Techniquement, l n exploite fondamentalement l'irréversibilité et l'unicité des hash (empreintes) produit par les fonctions de hachage exploitées dans les blockchains et les espaces de stockage à adressage par contenu [003 a. l'irréversibilité apporte la "flê,che du temps" pour l'horoda.taiion Pour une empreinte donnée, il est impossible de retrouver le document source qui a permis de la. produire. Cette "flèche du temps" est alors donnée par la succession irréversible des blocs dont chacun contient l'empreinte du précédent dans les blockchains exploitées; [00351 b. l'unicité de l'empreinte d'un même contenu est exploitée pour l'accès et le stockage intègre (le ce contenu dans un espace à adressage par contenu, L'intézrité est native dans un tel espace (système de fichier) ou le contenu d'un fichier est référencé par son empreinte. Cette référence permet d'accéder à son contenu qui par construction reste intègre puisqu'il s'agit de son empreinte cryptographique qui est unique (au taux de collision près des différentes fonctions de hachage). )036-] On obtient au final de façon décentralisée pour les documents traités, l'horodatation et l'intégrité dans l'espace et le temps, En synthèse de l'invention : on l'obtient en intercalant entre une première et une deuxième adresse de contenu (adresse de notarisation instantanée par exemple do type IPES) les références d'une transaction rapide en blockchain "non PoW", transaction dont les données gravées en blockchain inclut la première adresse (IVES) qui pointe sur le sous--contenu constitué de toutes les empreintes des documents à notariser dans un même cycle de notarisation instantanée. A l'issue d'une vérification unitaire, si elle est disponible, la seconde adresse (adresse IPFS de notarisation consolidée) proposée sera celle qui pointe toujours sur le premier sous-contenu mais aussi le second contenu cette fois modifié avec les références d'une transaction en blockchain "PoW" ultra sécurisée. L'adresse de notarisation instantanée ou consolidée est exploitée pour renommer le document initial à notariser. Si le document initial est un fichier sensoriel (photo, vidéo, audio), alors on exploite le procédé décrit dans le document FR1771454 pour avoir une date de création (date de début de création), la présente notarisation apportant la preuve d'existence à la date de la transaction en blockchain (date de fin de création), Au final les deux adresses IPES donnent la "flèche du temps", l'intégrité et l'accès aux contenus manipulés, la transaction en blockchain entre ces deux adresses IPES donne l'horodatation dans le référentiel temporel apportés par les blockchain exploitées et la preuve d'intégrité clans le temps. [0037 D'autres caractérisu les et avantages de l'invention ressortiront de la description raite ci-dessous, notamment en référence aux dessins annexés qui en illustrent numériquement un exemple de réalisation dépourvu de tout caractère limitatif. Sur ces figures : [0038] fig.! la ligure1 représente le procédé de nolsiisa.hin de masse mstantanée, [0039] ifig.21 la figure 2 représente le procédé de vérification unitaire de la notarlsatIon de masse instantanée, [0040] ifig,31 ure 3 représente le procédé de notarisation de masse consolidée, [00411 [fig.4j la figure 4 représente le procédé de vérification unitaire de la notarinaLion de masse consolidée, [0042] Pour reproduire l'exemple de réalisation ci-après proposé, l'homme de l'art devra mettre en oeuvre un serveur doté d'un certain nombre de logiciels. Pour cet exemple numériquement illustré, on exploite IPFS, la. blockchain "rapide" Siellar et la blockchain "ultra-sécurisée" Ethereurn, L'homme de l'ail, devra donc installer sur le 9 serveur : les logiciels IPES pour le système de fichier à adressage par contenu, les lDgicuers Steliar pour l'interfaçage avec cette biockehain et pour contrôler pleinement la réalisation des transactions de notarisation instantanée. Siellar permet de réaliser des transactions entre 3 et 5 secondes, cela convient à l'invention pour faire office à la fois de serveur d'horodation et de notarisation instantanée en blockehain. La hlockchain EOS est pertinente mais encore trop récente, d'autres blockchains, notamment en consensus à "preuve d'enjeu" pourraient convenir. Pour Ethereum, on utilise "Go Ethereurn" (Geth) pour l'implémentation du protocole et l'interfaçage avec la blockehain Ethercum. Il peut être exploiter en format "client léger" plutôt qu'en noeud complet, les contraintes de temps étant bien moindre pour la notarisation de masse consolidée de l'invention. .A noter que l'architecture visant à exploiter ici deux Nockchains (une rapide et l'autre très sécurisée) n'est pas nouvelle, C'est le cas, pour ne. citer qu'elles, pour les blockchains Komodo et ()T'UN& Leur consensus rapide est consolidé par des notarisations régulières de leur état global dans la blockehain Bitcoin. L'homme de l'art devra aussi installer un certain nombre d'utilitaires comme une bibliothèque mathématique pour la manipulation des grands nombres, des utilitaires de conversion de format pour l'expression en base 58, base 64, ... et bien sur un logiciel de gestion de serveur (Apache, nginx,..). De façon générale, le numéro des centaines en référence renvoi au numéro de la figure : 100, 101, ...,130 renvoi à la figure 1; 200, 201, .., 213 renvoi à la figure 2; 300 à 305 renvoi à la figure 3 et 400, 401 et 402 renvoi à la figure 4. [00431 L'invention concerne donc un procédé de notarisation de masse d'une pluralité de documents puis de vérification unitaire de la notarisation de chaque document, procédé caractérise en ce que la notarisation de niasse est décentralisée, ne nécessite pas de reçu de notarisation et produit une adresse de notarisation (118) de telle sorte que la vérification unitaire de la notarisation de chaque document (101, 102, 103) s'effectue sur la. seule base de l'empreinte de son contenu (104, 105, 106) et de son nom (121, 122, 123) renommé avec ladite adresse de notarisation (118), [00441 en phase de notarisation de masse 100451 - en étape initiale, un serveur (100) reçoit, ia chaque cycle de notarisation, pluralité d'empreintes (104, 105, 106) de documents (101, 102, 103), [00461 Les empreintes 104 et 106 des fichiers 101 (photo) et 103 (vidéo) sont typiquement obtenues d'un fichier produit selon le procédé décrit dans le document FRIT71454 précité pour avoir une date de création infalsifiable. Ce procédé permet de produire indépendamment du contenu utile du fichier multimédia, une date de création grâce à des consignes reposant sur l'aléa horodaté (nonce produit par le consensus preuve de travail) d'une hlockchain. Ces consignes sont appliquées en phase de conversion analogique/numérique de production du fichier multimédia. On retrouve donc la date 10 dans le contenu du fichier lui môme. Elle est donc infalsifiable. [0047] - on assemble lesdites empreintes (104, 105, 106) reçues dans un seul fichier d'empreintes (107) dont le nom inclut un numéro d'ordre (130) propre à chaque cycle. [0048] - on insère ledit fichier (107) dans ledit espace. (108), typiquement celui du système de fichier InterPlanetary File System (IPES), pour obtenir l'adresse primaire (109) dudit fichier (107) dans ledit espace (108). [0049] L'homme de l'art peut reproduire le fichier texte la valeur des trois empreintes (107) présentées dans la figure. I pour obtenir la valeur (109) de l'adresse IPES. [ )050] - on duplique dans la mémoire électronique d'une pluralité de serveurs du même espace d'adressage (108), ledit fichier (107), pour garantir la permanence d'accès. [0051] Cette duplication peut par exemple s'effectuer sur les espaces proposés via les serveurs infura.io et ipfs.io. Sur le serveur de l'invention, l'homme de l'art configurcra IPES en conséquence. [0052] dans cette cinquième étape, on réalise une transaction (110) de notarisation dans une blockchain rapide (111), ladite transaction (110) incluant dans sa partie données, ladite adresse primaire (109), le cas échéant encodée selon le protocole de ladite blockchain rapide (non PoW). [0053] Dans cet exemple, l'homme de l'art pourra consulter, à partir d'explorateur public de la blockchain Ste,ilar, ladite partie données (Mémo Nash) de la transaction d588ce05e926df187.1bcdd3e30520e989a99369a62ebbact897711607e8da8d2OD. cette partie données est encodée en hase 64 et est égale à 4-fqqSg5DFspBcckhl.b,A/B/OC7KcF9kFlif3aF1tn3±F,pVg+4= 11 s'agit de l'empreinte SHA-256 encodée dans l'adresse IPFS 109. Ce SHA256 est égale à f9faaa4a0e43 6ca4171c92153007rd02eca7051-64161717687967f84a5583ce. retien le format interplanetary Linked. Data (IPLD cf ipld.io), qui permet de s'extraire des différents protocoles. Les caractère nOm" des adresses présentées (109, 117, 118) renvoi à un encodage en ba.se58 (celui de Bitcoin), à l'identificateur de contenu en version 0 (Cl Dv0) et l'exploitation du SHA-256. [00541 - on construit une référence de notarisation (115) au moins constituée des références (111 et 113) à ladite blockchain el ladite transaction (110). [00551 - on insère ladite référence de notarisation (115) dans ledit espace (108) de telle façon que ladite adresse de notarisation (118) obtenue, pointe (119) sur ledit contenu décentralisé (120) au moins constitué : [00561 a. - du contenu primaire constitué dudit fichier de weintes (107) pointé par ladite adresse primaire (109), [00571 b. - du contenu secondaire constitué de ladite référence de notarisation (115). [00581 Selon un format préférentiel dudit contenu (120), le résultat de cette étape est obtenue en regroupant dans un fichier (1 16) d'un nom donné (129), au moins ladite 11 référence de notarisation (115) et en insérant ce fichier (116) dans ledit espace (108) pour obtenir l'adresse secondaire (117) univoquement associée audit nom (129) dudit contenu secondaire (115), ladite adresse de notarisation (118) pointe alors sur lesdites deux adresses (109 et 117) desdits deux contenus respectifs (107 et 116). [0059] Dans le présent exemple, l'homme de l'art peut exploiter le contenu du fichier texte 116 et les noms donnés des fichiers (fingerprints-128.txt et notarization.txt) pour calculer l'adresse IPES de notarisation 118. [0060] - ledit serveur (100) met à disposition (124) de chaque client du présent cycle., ladite adresse de notarisation (118) aux fins de renommer (121, 122, 123) respectivement chacun desdits documents (101, 102, 103), selon un format donnée, avec la chaîne de caractère constituée d'au moins ladite adresse de notarisation (118). [0061 Cette adresse de notarisation peut en Mus inclure la référence du système de fichier à adressage par contenu exploité. Elle est alors ici précédée de la chaîne de caractère "MES!" puisque l'on a choisi TPFS dans cet exemple non limitatif. [0062] - on recommence un cycle de la phase de notarisation à son étape initiale avec la réception d'une nouvelle pluralité d'empreintes de documents (125, 126) pouvant inclure. en plus un fichier complet (127) d'empreintes respectives de. documents d'un seul et même client (128), selon le nombre de cycles réalisés, les étapes complémentaires d'une notarisation de masse consolidée sont effectuées. [0063 L'envoi L'envoi de fichier complet. d'empreintes peut être intéressant pour des clients souhaitant notariser en masse un même type de document, par exemple les diplômes ou les attestations de formation produites par des entités pour un nombre de personnes donné. De façon générale, toute entité qui doit justifier d'une séquentialité traçable, aujourd'hui implémentée "rustiquement" par de simples carnets papier officiels dont chaque feuille a un numéro séquentiel et sur lesquels les employés doivent reporter des informations de façon manuscrite. [0064] Pour l'exemple, la vérification unitaire est détaillée figure 2 pour une adresse de nota- risation instantanée (1 18), la figure 3 pour une adresse de notarisation consolidée (2.12) et la. figure 4 qui représente le traitement complémentaire pour obtenir une adresse de notarisation consolidée (212) à partir d'une adresse de notarisation instantanée (118) après avoir trouvé son numéro d'ordre (130). Sur a figure 2, les valeurs numérique présentées sont celles de la figure 1, on poursuit le procédé de notarisation par le procédé de vérification. Ainsi, en phase de vérification unitaire, réalisée par une su d'étapes (202 à 207) de lecture d'adresses el de contenu décentralisé [0065] - on sélectionne un document (102), préalablement notarisé dans ladite phase de no- tarisation de masse. Si elle est manuelle, la sélection est typiquement un glisser/ déposer dans un champ de l'interface (page weh) servi par ledit serveur (100). [0066] - an idenli lie, grâce à ladite interface, ledit document (102) en : [ )067] a. - calculant (200) son empreinte (105), typiquement de type Soeur° Flash Algorïthm sur 256 bits (SHA-256), [0068] h. - extrayant (201) son adresse de notarisation (118), typiquement au format IPLD (InterPlanetary Linked Data), dans la chaîne de caractère complète de son nom (122), [0069] c. - extrayant, si il est disponible, le numéro d'ordre (130) de notarisation consolidée. [0070] Si le numéro d'ordre n'est pas disponible, c'est qu'il s'agit une adresse de notarisation instantanée (118), si le numéro est inclut dans le nom du fichier soumis à la véri- fication, alors l'adresse IPES est celle de notarisation consolidée.. [ )071] - on accède (202), à l'aide de ladite adresse de notarisation (118), audit contenu intègre décentralisé (120) dans ledit espace (108), [0072] - on accède (203), dans ledit contenu décentralisé (120), à ladite référence de nota- risation (115), préférentiellement à l'aide du nom donnée (129) selon ledit format préférentiel, [0073] on accède (204), à l'aide de ladite référence de notarisation (115), au contenu horodaté et intègre de ladite transaction (110) dont on mémorise la date (211) d'exécution dans ladite block.chain (111), [ )074] - on accède (205), dans ledit contenu de la ladite transaction (110), à ladite adresse primaire (109) que l'on décode si nécessaire, [0075] - selon la disponibilité du numéro d"ordre : [0076] a. st il (130) n'est pas disponible, il s'agit de l'adresse de notarisation instantanée (118) alors on accède (206) directement, à l'aide de ladite adresse primaire (109), au contenu intègre dudit fichier des empreintes (107) et on obtient le numéro d'ordre (130), [0077] h. si il (130) est disponible, il s'agit de 1 adresse de notarisation consolidée (212.) alors on accède indirectement, à l'aide de l'adresse primaire globale (303) obtenue à Pêtape précédente et le numéro d'ordre (130) au contenu intègre dudit fichier des empreintes (107), 10078 Dans l'exemple présenté sur la figure les empreintes des documents de tous les cycles précédents se retrouvent regroupées sous; une même adresse IPES (303). Le numéro d'ordre permet alors, dans le contenu sous cette adresse (303) de trouver le fichier d'empreintes de chaque cycle (107 ou 302) respectivement référencé par leur propre numéro d'ordre (130 ou 304). On exploite la propriété de déduplication de IPES Elle permet de ne pas avoir à dupliquer les fichiers 107 et 302 et de façon générale, aucun des fichiers d'empreintes produits lors de tous les cycles précédents de notarisation instantanée. En effet, un même fichier d'empreintes reste toujours pointé par une même adresse IPES référençant son même contenu stocké "une fois pour toute" dans les serveurs IPES, Le présent procédé de notarisation consolidée ne rajoute qu'un minimum de nouveau contenu constitué par la nouvelle référence de transaction dans 13 la hlockehain sécurisée (PoW) et trois adresses IPES (303, 212 et celle de la nouvelle référence) donc 200 à 300 octets de plus pour plusieurs dizaines ou centaines de milliers de documents ayant fait l'objet d'une notarisation instantanée. On ne rajoute que trois segments dans le graphe de Merkle orienté acyclique (Merkle DAG) qui structure IPES. [0079] on transfère (207) le contenu dudit fichier (107) vers un traitement de recherche. [0080] - on recherche (208) dans le contenu dudit fichier d'empreintes (107), la valeur de eanpreinte (105) dudit document (102) [ )081] a. - si la valeur de ladite empreinte (105) n'est pas trouvée alors la notarisation dudit document (102) n'est pas vérifiée (209), [0082] h. - si la valeur de ladite empreinte (105) est trouvée alors la notarisation dudit document (102), est vérifiée (210) le contenu du document_ (102) existait en l'exact état à la date (211) et, avec le numéro d'ordre (130) obtenu s'il n'était pas disponible, on effectue un traitement complémentaire (213) à l'aide d'une table de correspondance (400) pour obtenir, si elle est trouvée, l'adresse de notarisation consolidée (212) incluant ledit numéro d'ordre (130) exploités pour renommer (402) définitivement ledit fichier (102). [0083] L'adresse de notarisation consolidée peut ne pas être trouvée si le client effectue une vérification immédiatement après la notarisation instantanée. En effet, le procédé de notarisation consolidée ne s'effectue par exemple toutes les minutes, les dizaines de minutes ou plus. On présente avec la figure 3, l'exemple de la notarisation de masse consolidé, Elle est effectuée sur la hlockchain Elhereurn, C'est un procédé caractérisé en ce que la notarisation de niasse des documents (101 et 102 et 103) est consolidée sur une autre hlockchain (300) à la sécurité et la décentralisation accrues, typiquement une hlockchain dont le consensus distribué est de type preuve de travail (pro& of work des hlockchains Bitcoin, Ethereum, ) procédé tel que, après un nombre donné de cycle de ion de masse instantanée, il est réalisé les étapes complémentaires suivantes de notarisation de masse consolidée : [00841 - sous ledit espace (108), on rassemble l'ensemble des adresses primaires (109, 301) de fichiers d'empreintes (107, 302), produits aux cycles précédents et n'ayant pas fait l'objet d'une notarisation de masse consolidée. [00851 - on produit une adresse primaire globale (303) pointait sur un contenu décentralisé composé : [00861 a. - desdites adresses primaires (109, 301), [0087] h. - desdits Fichiers empreintes (107, 302) et de leur nom respectif uant leur numéro d'ordre (130, 304). [00881 L'homme de l'art peut reproduire, l'exemple en exploitant le contenu présenté du fichier texte 302 d'empreintes, contenant deux empreintes. [00 - on réalise les étapes 5 à 7 de la phase de notarisation Cie masse en traitant ladite adresse primaire globale (:303) comme une adresse primaire normale (109, 301), pour obtenir une adresse de notarisation (212) pointant sur un contenu incluant : [0090] a. - une référence de notarisation (305) dans la blockchain de consolidation (300), [0091] h. - le contenu décentralisé obtenu à l'étape précédente et adressé par ladite adresse primaire globale (303). [0092] L'homme de l'art peut consulter, à partir de n'importe quel explorateur public de la blockchai ri Ethereum (par exemple etherscan.io) le contenu de la transaction 751c005162a765b84e59e767fe34hern7150ac16287d3bad86ca8248652d5205d en paitieulier la partie "Input Data" en format UTF-8 où figure l'adresse 303. [0093] - on met à jour ladite table de correspondance (400) entre les numéros d'ordre exploités (130, 304) et l'adresse de notarisation consolidée correspondante (212). [0094] Le procédé de l'invention est aussi caractérisé en ce que l'adresse de notarisation consolidée (212) avec le numéro d'ordre (130) sont directement obtenus lors d'un traitement en différé [00951 - en étape initiale, le serveur (100) reçoit une pluralité d'empreintes 004, 105 06), de documents (101, 102, 103), typiquement par courriel ou via une application mobile, [0096] - lorsque lesdits documents ont fait l'objet d'une notarisation de masse consolidée, ledit serveur (100) met en retour à disposition des clients l'adresse de notarisation consolidée (212) et le numéro d'ordre obtenu et mémorisé (130). [0097] Le procédé est aussi caractérisé en ce que ladite référence de notarisation comprends en plus des informations complémentaires d'horodation de ladite transaction (110), des informations sur le document notarisé (101, 102, 103) telles que sa taille, son format_ et des informations sur le client telles qu'un ou plusieurs identifiants. [00481 Le procédé est aussi caractérisé en ce qu'aux fins de renommer (121, 123) les documents notarisés (101, 102, 103), ladite chaîne de caractère comprend en plus les références de l'espace décentralisé d'adressage par contenu (1 )8), dans notre exemple la chaîne de caractère "IPFSI". [0099] Le procédé est aussi caractérisé en ce que ladite interface (page web), servie par ledit serveur (100), est stockée, gérée et accessible sous ledit espace d'adressage par contenu (108) à une adresse fixe. Cette adresse Fixe est associée à une clé publique et publiée. Elle est celle d'un tiers de confiance, On exploite typiquement selon le protocole InterPlanetary Naming System (IPNS). IPNS est un protocole, globalement identique à IPES, qui associe à un ensemble d'idenli fiants IPES un seul el unique identifiant IPNS. Une lois que l'identifiant IPNS est généré, il y ajuste besoin d'indiquer au réseau quelles ressources doivent y titre associées_ Ces ressources sont ici un site web doté de code javascript qui permet de procéder aux notarisations et vérifications. L'identifiant IPNS est en lien avec l'identifiant de celui présent avec un serveur sur le réseau 15 (pecrid), qui est l'empreinte de la clef publique qui l'identifie sur le réseau. Comme précédemment évoqué, si cette clé publique et celle, connue et publiée, d'un acteur public, alors l'invention peut être largement exploitée par tout les états et administrations publiques et par extension le grand public; d'autant si on retient IPES et que. ce dernier se déploie pour permettre des accès directs à un espace adressé par contenu. Notons que dos navigateurs populaires (Chromo, firefox,..) implémentent déjà des extensions pour cet accès direct. 16 [Revendication I] [Revendication