FR3085076A1

FR3085076A1 - Procede de notarisation de masse sans recu de notarisation et decentralise en blokchains et espace a adressage par contenu.

Info

Publication number: FR3085076A1
Application number: FR1870930A
Authority: FR
Inventors: Alexandre Lavergne
Original assignee: Individual
Current assignee: Individual
Priority date: 2018-08-14
Filing date: 2018-08-14
Publication date: 2020-02-21

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] La 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 :

[0002] - 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 contract); le mode opératoire de la vérification est une simple sélection du fichier notarise, un simple glisser/déposer dans un champ de ladite interface;

[0003] - grâce à la nature totalement décentralisée, l’intégrité de la totalité des données et traitements d’exploitation du présent procédé est cryptographiquement vérifiable, elle l’est de façon autonome ; en termes non techniques et en quelques mots : il n’y a pas besoin de tiers de confiance; donc ni serveur d'horodatation ni serveur centralisé de stockage des reçus de notarisation de l'état de l'art;

[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'art, il est développé deux parties : l'état de la technique antérieure puis un exposé de l'invention illustré par les figures relatives à un mode de réalisation qui est numériquement exemplifié. Ainsi : [0005] - on précise ce qu'est une notarisation, notamment une notarisation de niasse 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

Merkle) de ce fichier, [0006] on explique le problème de l'état de l'art qui est de deux ordres :

[0007] a. - l'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] b. - la nécessité d'exploiter au moins un serveur centralisé d'horodatation 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 (confiimée/consolidée) en blockchain 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 :

[0010] a. - un système de fichier à adressage par contenu, typiquement de type InterPlanetary File System (IPFS) ou équivalent (Ethereum Swarm,..), [0011] b. - au moins une blockchain publique à grande rapidité d'exécution des transactions, par exemple dotée d'un consensus distribué de type preuve d'enjeu (EOS, Tezos,..) ou autres mécanismes (Stellar, IOTA, Byteball...), pour permettre l'obtention quasi immédiate de l'adresse de notarisation instantanée sans l'appel à un serveur d'horodatation, [0012] c. une deuxième blockchain publique pour consolider la notarisation sur une infrastructure très sécurisée et très décentralisée qui exploite typiquement un consensus distribué de type preuve de travail'' (Bitcoin, Ethereum,...). 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 [0013] Fonctionnellement, notariser 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'horodatation. On peut notariser tout type de document/ information : document de formalisation d'œuvres 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çabilité, 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 l'empreinte de son contenu ou de notariser l'empreinte d'un document incluant l’empreinte de son contenu. L’empreinte (haché ou condensât) est par exemple obtenue avec une fonction de hachage de type Secure Hash Algorithm sur 256 bits (SHA-256). Compte tenu du coût prohibitif du gravage (stockage) de donnée en blockchain, c'est le troisième mode qui est exploité par I état de l'art. Il s'agit de la notarisation de masse qui exploite essentiellement la technique des arbres de Merkle. Concernant la notarisation sous blockchain, l'homme de l'art pourra se référer au document FR1771454 (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 :

[0014] a. - le document lui même, [0015] b. - son empreinte cryptographique, [0016] c. - son reçu de notarisation ou preuve, [0017] d. la valeur de son ancre gravée dans une blockchain.

[0018] Techniquement, notariser un document consiste à écrire (graver) dans une blockchain une ancre mathématiquement univoquement liée à l’empreinte du contenu du document. Le reçu de notarisation permet de prouver ce lien univoque. La réference de notarisation présente dans le reçu de notarisation précise en particulier quelle est la blockhain qui a été exploitée et le numéro de la transaction qui a permis la notarisation. La notarisation permet alors de prouver que le document ainsi notarise 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 de masse. Il notarise et vérifie sa notarisation avec une simple sélection de son document. Ce document n'est pas stocké dans une blockchain car le coût y est prohibitif, même 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 l'art, les principaux standard pour la notarisation de masse sont Chainpoint (chainpoint.org), Opentimestamps (opentimestamps.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 opentimestamps plutôt que chainpoint : https://www.ge.ch/document/rapport-experimentation-blockchain. Originstamp adresse plutôt directement les particuliers, le grand public. Les notarisations y sont gratuites, elles n'impliquent pas de serveur d'horodatation, mais, ce qui illustre le coût et les contraintes de temps des processus de notarisation de masse, elle 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 Merkle 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 l'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 forme 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 Bitcoin. 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 et 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 blématique se situe donc au niveau de l'existence de ce reçu de notarisation qu'il faut 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] b. - 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 notarisé et son reçu de notarisation [0023] e. - il faut à chaque vérification relancer des calculs cryptographiques liés aux informations présentent dans le reçu de notarisation, ce qui n'est pas le cas avec la présente invention.

[0024] Face à ce problème, quand les serveurs des trois standard évoqués proposent une solution, elle consiste simplement à gérer à la place du client ce 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 ce 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'ail, ce problème de reçu de notarisation est bloquant, notamment pour le secteur dit de l'Internet of Things (ΙοΤ), 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éfrigérateurs 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 différents 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 risation de plusieurs milliers d'octets. Ainsi, le reçu de notarisation donné en exemple sur le site Internet chainpoint.org 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 loT 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 base 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, alors elle est 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 IPFS qui permet de ne pas dupliquer, donc de conserver, les fichiers puisqu'ils sont référencés par leur condensât 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é et 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 implémente en tout point et de façon effective l'horodatage décentralisé (Decentralized Trusted Timestamping) : 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 matière de certification/horodatation. 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 et 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 :

[0028] 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] b. - une notarisation et vérification quasi instantanées (de l'ordre de quelques secondes) [0030] c. - 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) [0031] 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, [ 0032] 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.

[0033] Techniquement, l'invention 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 :

[0034] a. - l'irréversibilité apporte la flèche du temps pour l'horodatation. 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;

[0035] b. - l'unicité de l'empreinte d'un même contenu est exploitée pour l'accès et le stockage intègre de ce contenu dans un espace à adressage par contenu, L'intégrité 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).

[0036] 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 de type IPFS) : les références d'une transaction rapide en blockchain non PoW, transaction dont les données gravées en block chain inclut la première adresse (IPFS) qui pointe sur le sous-contenu constitué de toutes les empreintes des documents à notarise! 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 niais 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 FRI771454 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 IPFS 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 IPFS donne l'horodatation dans le référentiel temporel apportés par les blockchains exploitées et la preuve d'intégrité dans le temps.

[0037] D'autres caractéristiques et avantages de l'invention ressortiront de la description faite 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.l] la figure 1 représente le procédé de notarisation de masse instantanée, [0039] [fig.2] la figure 2 représente le procédé de vérification unitaire de la notarisation de masse instantanée, [0040] [fig.3] la figure 3 représente le procédé de notarisation de masse consolidée, [0041] [fig.4] la figure 4 représente le procédé de vérification unitaire de la notarisation 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” Stellar et la blockchain ultra-sécurisée Ethereum. L'homme de l'art devra donc installer sur le serveur : les logiciels IPFS pour le système de fichier à adressage par contenu, les logiciels Stellar pour l'interfaçage avec cette blockchain et pour contrôler pleinement la réalisation des transactions de notarisation instantanée. Stellar 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 blockchain. La blockchain EOS est pertinente mais encore trop récente, d'autres blockchains, notamment en consensus à preuve d'enjeu pourraient convenir. Pour Ethereum, on utilise Go Ethereum (Geth) pour l'implémentation du protocole et l'interfaçage avec la blockchain Ethereum. Il peut être exploiter en format client léger plutôt qu'en nœud 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 blockchains (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 QTUM. Leur consensus rapide est consolidé par des notarisations régulières de leur état global dans la blockchain 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.

[0043] 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érisé en ce que la notarisation de masse 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), [0044] en phase de notarisation de masse :

[0045] - en étape initiale, un serveur (100) reçoit, à chaque cycle de notarisation, une pluralité d’empreintes (104, 105, 106) de documents (101, 102, 103), [0046] 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 FR1771454 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 blockchain. Ces consignes sont appliquées en phase de conversion analogique/numérique de production du fichier multimédia. On retrouve donc la date 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 (IPFS), pour obtenir l'adresse primaire (109) dudit fichier (107) dans ledit espace (108).

[0049] L'homme de l'art peut reproduire le fichier texte avec la valeur des trois empreintes (107) présentées dans la figure 1 pour obtenir la valeur (109) de l'adresse IPFS.

[0050] - 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 configurera IPFS 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 Stellar, ladite partie données (Memo hash) de la transaction d588ce05e926dfl 871 bcdd3e30520e989a99369a62ebbacf89771607e8da8d20D. cette partie données est encodée en base 64 et est égale à 4-fqqSg5DFspBcckhUwB/0C7KcF9kFhf3aHm3+EpVg+4= Il s'agit de l’empreinte SHA-256 encodée dans l'adresse IPFS 109. Ce SHA256 est égale à :

f9faaa4a0e4316ca4171 c92153007fd02eca705f641617f76879b7f84a55 83ee. On retient le format interplanetary Linked Data (IPLD cf ipld.io), qui permet de s'extraire des différents protocoles. Les caractère Qm des adresses présentées (109, 117, 118) renvoi à un encodage en base58 (celui de Bitcoin), à l’identificateur de contenu en version 0 (CIDvO) et l'exploitation du SHA-256.

[0054] - on construit une référence de notarisation (115) au moins constituée des références (111 et 113) à ladite blockchain et ladite transaction (110).

[0055] - 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é :

[0056] a. - du contenu primaire constitué dudit fichier d’empreintes (107) pointé par ladite adresse primaire (109), [0057] b. du contenu secondaire constitué de ladite référence de notarisation (115).

[0058] Selon un format préférentiel dudit contenu (120), le résultat de cette étape est obtenue en regroupant dans un fichier (116) d'un nom donné (129), au moins ladite réference 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 IPFS 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 plus 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 IPFS/' puisque Ton a choisi IPFS 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 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 notarisation instantanée (118), la figure 3 pour une adresse de notarisation consolidée (212) 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 la 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 suite d'étapes (202 à 207) de lecture d'adresses et de contenu décentralisé :

[0065] - on sélectionne un document (102), préalablement notarisé dans ladite phase de notarisation de masse. Si elle est manuelle, la sélection est typiquement un glisser/' déposer dans un champ de l'interface (page web) servi par ledit serveur (100).

[0066] - on identifie, grâce à ladite interface, ledit document (102) en :

[0067] a. - calculant (200) son empreinte (105), typiquement de type Secure Hash Algorithm sur 256 bits (SHA-256), [0068] b. - 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 (402) du fichier soumis à la vérification, alors l'adresse IPFS est celle de notarisation consolidée.

[0071] - 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 notarisation (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 blockchain (111), [0074] - 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 dordre :

[0076] a. - si 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] b. si il (130) est disponible, il s'agit de l'adresse de notarisation consolidée (212) alors on accède indirectement, à l'aide de l'adresse primaire globale (303) obtenue à l'étape précédente et le numéro d'ordre (130) au contenu intègre dudit fichier des empreintes (107), [0078] Dans l’exemple présenté sur la figure 3, les empreintes des documents de tous les cycles précédents se retrouvent regroupées sous une même adresse IPFS (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 IPFS. 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 IPFS référençant son même contenu stocké une fois pour toute dans les serveurs IPFS. 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 la blockchain sécurisée (PoW) et trois adresses IPFS (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 IPFS.

[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 l’empreinte (105) dudit document (102) :

[0081] 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] b. - 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 blockchain Ethereum. C'est un procédé caractérisé en ce que la notarisation de masse des documents (101 et 102 et 103) est consolidée sur une autre blockchain (300) à la sécurité et la décentralisation accrues, typiquement une blockchain dont le consensus distribué est de type preuve de travail (proof of work des blockchains Bitcoin, Ethereum,....) procédé tel que, après un nombre donné de cycle de notarisation de masse instantanée, il est réalisé les étapes complémentaires suivantes de notai!sation de masse consolidée :

[0084] - 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.

[0085] on produit une adresse primaire globale (303) pointant sur un contenu décentralisé composé :

[0086] a. - desdites adresses primaires (109, 301), [0087] b. - desdits fichiers empreintes (107, 302) et de leur nom respectif incluant leur numéro d'ordre (130, 304).

[0088] L'homme de l'art peut reproduire l'exemple en exploitant le contenu présenté du fichier texte 302 d'empreintes, contenant deux empreintes, [0089] - on realise les étapes 5 à 7 de la phase de notarisation de 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 ] b. - 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 blockchain Ethereum (par exemple etherscan.io) le contenu de la transaction

751 c005162a765b84e59c767fe34beb7150ac 16287d3bad86ca8248652d5205d en particulier la pallie 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é :

[0095] - en étape initiale, le serveur (100) reçoit une pluralité d'empreintes (104, 105, 106), 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 infonnations sur le document notarise (101, 102, 103) telles que sa taille, son format,... et des infonnations sur le client telles qu'un ou plusieurs identifiants.

[0098] Le procédé est aussi caractérisé en ce qu'aux fins de renommer (121, 122, 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 (108), dans notre exemple la chaîne de caractère IPFS/.

[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 à IPFS, qui associe à un ensemble d'identifiants IPFS un seul et unique identifiant IPNS. Une fois que l'identifiant IPNS est généré, il y ajuste besoin d'indiquer au réseau quelles ressources doivent y être 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 (peerid), 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 IPFS et que ce dernier se déploie pour permettre des accès directs à un espace adressé par contenu. Notons que des navigateurs populaires (Chrome, Firefox,..) implémentent déjà des extensions pour cet accès direct.

Claims

Revendications [Revendication 1] Procédé de notarisation de masse sans tiers de confiance d'une pluralité de documents (101, 102, 103) caractérisé en ce qu'il ne nécessite ni la production ni la gestion ni l'exploitation d’un fichier de reçu de notarisation et permet un accès décentralisé à la preuve de notarisation de chacun desdits documents (101, 102, 103) grâce à une transaction d'horodatation ( 110) en blockchain (111) insérée entre au moins deux adresses (109, 118) d’un espace de stockage décentralisé adressé par contenu (108) avec au moins les étapes suivantes d'un cycle : • on calcule une première adresse (109) qui est l'empreinte du contenu (107) constitué d'un ensemble préalablement calculées d'empreintes (104, 105, 106) desdits documents (101, 102, 103); on effectue ladite transaction d'horodatation (110) insérant dans le bloc horodaté d'une blockchain (111) au moins ladite première adresse (109); • on calcule la deuxième adresse (118) dite de notarisation, qui est l’empreinte de deux contenus (116, 107) regroupés en un seul (120) constitué d'au moins : o le contenu (116), d'un nom donné (129), contenant au moins les références (115) de ladite transaction d'horodatation (110) soit son numéro (113) en blockchain et la référence de ladite blockchain (111), selon un format préférentiel, ledit contenu (116) et son nom donné (129) son univoquement associés à une adresse (117) dudit espace (108); o le contenu (107) nommé (130) pointé par ladite première adresse (109); • on duplique ledit seul contenu (120) pointés par ladite adresse de notarisation (118), par principe temporellement subséquente à ladite première adresse (109), sur plusieurs serveurs dudit espace (108) pour, au delà de l'intégrité et de l'horodatation, garantir l’accès décentralisé (sans passer par un serveur central) et permanent aux preuves de notarisation; le serveur (100) de notarisation met à disposition (124) de chaque client du présent cycle, au moins ladite adresse de notarisation (118), aux fins de l'associer, préférentiellement par renommage (121, 122, 123) respectivement à chacun desdits documents (101, 102, 103). [Revendication 2] Procédé, selon la revendication 1, caractérisé en ce 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) grâce au renommage avec au moins ladite adresse de notarisation (118) puis les étapes séquentielles (202 à 207) suivantes de lecture d'adresses et de contenu décentralisé :

• on sélectionne un document (102) préalablement notarisé, si elle est manuelle, la sélection est typiquement un glisser/déposer dans un champ de l'interface (page web) en code source servie par ledit serveur (100):

• on identifie, grâce à ladite interface, ledit document (102) au mois en : o calculant (200) son empreinte (105), typiquement de type Secure Hash Algorithm sur 256 bits (SHA-256);

o 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);

• on accède (202), à laide de ladite adresse de notarisation (118), audit contenu horodaté, intègre et décentralisé (120) dans ledit espace (108), • on accède (203), dans ledit contenu décentralisé (120), à ladite référence de notarisation (115) grâce audit nom donné (129);

• 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 blockchain (111);

• on accède (205), dans ledit contenu de la ladite transaction (110), à ladite adresse primaire (109) préalablement décodée si nécessaire;

on accède (206), à l'aide de ladite adresse primaire (109), au contenu intègre nommé (130) dudit fichier des empreintes (107);

• on transfère (207) le contenu dudit fichier d'empreintes (107) pour rechercher (208) dans son contenu, la valeur de l'empreinte (105) dudit document (102) calculée à la deuxième étape :

o 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);

o 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 ) de ladite transaction ( 110).

Revendication 3] Procédé de notarisation de masse d’une pluralité de documents (101, 102, 103 et 125, 126) selon les revendications 1, caractérisé en ce que la notarisation est consolidée sur une autre blockchain (300) à la sécurité et la décentralisation accrue, typiquement par un consensus distribué de type preuve de travail (Proof of Work : PoW), grâce aux étapes complémentaires suivantes :

• ledit contenu nommé inclut en plus un numéro d'ordre propre à chaque cycle (130, 304) de notarisation d'une pluralité d’empreintes (101,102,103 et 125, 126); dans ledit espace (108), on rassemble l'ensemble des adresses primaire (109, 301) de fichiers d'empreintes (107, 302) produit aux cycles précédents et n'ayant pas fait l'objet d'une notarisation de masse consolidée; • on produit une adresse primaire globale (303) pointant sur le contenu décentralisé adressé par lesdites adresses primaires (109, 301) chacune associées à leur nom respectif incluant leur numéro d'ordre (130, 304); • on réalise une transaction sous une blockchain consolidée (PoW) 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 : o une référence de notarisation (305) dans la blockchain de consolidation (300); o le contenu adressé par ladite adresse primaire globale (303); • on met à jour une table de correspondance (400) entre les numéros d'ordre exploités (130, 304) et l'adresse de notarisation consolidée correspondante (212); • ledit serveur (100) met à disposition, en plus de l’adresse de notarisation consolidée (212), ledit numéro d'ordre respectif (130, 304) aux fins de l'associer audit document traité, préférentiellement par renommage (402). Revendication 4] Procédé de vérification unitaire de notarisation consolidée, selon la revendication 2, caractérisé en ce que ledit document (102) est en plus identifié, après l'extraction (201) de son nom, par un numéro d'ordre (130 ou 304) de telle sorte que : • si le numéro d'ordre n'est pas disponible, à l’issu de la vérification (213) et grâce à ladite table de correspondance (400), il est mis à disposition 1‘adresse de notarisation consolidée (212) ainsi que le numéro d’ordre associé (130 ou 304) aux fins de renommage (402) du fichier (102) vérifié: • si le numéro d'ordre est disponible, il est exploité conjointement à l'adresse de notarisation consolidée (212) pour obtenir directement le fichier d'empreinte (107 ou 302) correspondant localisé sous ladite adresse primaire globale (303) qui n'est pas associée audit nom donné (129).

[ Revendication 5] [Revendication 6] [Revendication 7]

Procédé, selon les revendications 3, caractérisé en ce que l'adresse de notarisation consolidée (212) avec le numéro d’ordre (130) sont directement obtenus typiquement après réception par ledit serveur (100) d’une pluralité d'empreintes de documents (101, 102, 103 ou 125, 126 ou liste 127) par courriel ou via. une application mobile.

Procédé, selon l'une quelconque des revendications précédentes, caractérisé en ce qu'aux fins de renommer (121, 122, 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 (108). Procédé, selon l'une quelconque des revendications précédentes, 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 associée à une clé publique et publiée d'un tiers de confiance, typiquement selon le protocole Inter-PlanetaryNaming System (IPNS).