FR 3018370 A1 20150911 FR 1400719 A 20140324 Le domaine de l'invention est la génération automatique de droits, notamment de crypto-monnaies en contrepartie de risques pris dans une mutuelle. Etat de l'Art Dans un article (http://eprintiacnorg/2013,507.pdf, dont le contenu fait partie de la présente description) publié le 7 Octobre 2013, Eli Ben-Sasson & al. décrivent un système qui permette de prouver l'exécution d'un programme quelconque prenant en entrée des données privées (input privé), sans les dévoiler, ainsi qu'optionnellement des données qui ne sont pas privées (input public). Il s'agit de programmes écrits en C mais le procédé est généralisable à tout langage de programmation. Avec un tel système on peut ainsi exécuter un programme dans un environnement spécial qui permette d'obtenir une preuve succincte et vérifiable très rapidement de (i) l'intégrité du programme qui a ainsi été exécuté (c'est-à-dire la preuve que le programme n'a pas été altéré) et (ii) son exécution complète retournant la valeur vraie. (Un tel programme exécuté dans cet environnement spécial est dans la suite appelé « programme en ZK-SNARK » ou « programme de vérification en ZK-SNARK ».) Le système est à divulgation nulle de connaissance en ce qui concerne les données privées fournies en entrée. Ces travaux se fondent au départ sur les travaux de Shafi Goldwasser, Silvio Micali, et Charles Rackoff dans les années 1980 (http://en.wikipedia.orgjwiki/IP %28complexity%29#PSPACE is a subset of IP; voir aussi une synthèse de l'Etat de l'Art dans l'article « Verifying computations without reexecuting them: from theoretical possibility to near practicality » http://eccc.hpi-web.de/report/2013/165/download/, ainsi que les explications données à la fin de ce texte à la section « Deuxième mode de réalisation »). Une application de cette nouvelle technologie est présentée à la figure 1. Il s'agit de prouver la possession d'un passeport électronique sans dévoiler son contenu, le programme prenant en input privé, par NFC, les données contenues 30 dans le composant (cf. le document de l'OACI qui spécifie ces données http://www.icao.int/publications/Documents/9303 p3 v2 cons en.pdf), et en input public la clé publique (du gouvernement, il peut s'agir de plusieurs clés) ayant permis de signer ces données. Le programme en ZK-SNARK sert ici à vérifier qu'il s'agit bien d'un passeport fourni par ce signataire (le gouvernement). L'invention concerne une extension du procédé utilisé dans cette application. L'invention concerne par ailleurs les systèmes répartis, en peer-to-peer, de crypto-monnaie tel que le système Bitcoin (https://bitcoin.orgibitcoin.pdf), des transactions permettant de transférer des unités de compte entre adresses créées à partir de clés publiques cryptographiques. Chaque transaction a une entrée ou input se référant directement -ou indirectement, au sens du futur système zerocash, cf. https://wwvv.youtube.com/watch?v=FXU65XsLiFk, développée sur la technologie précitée de l'article de Eli Ben-Sasson & al .- à une sortie ou output d'une transaction précédente (ou plusieurs inputs se référant chacun à un output d'une transaction précédente) et peut elle-même avoir un nouvel output (ou plusieurs nouveaux outputs) spécifiant un nombre d'unités de compte et une adresse de bénéficiaire. Lesdites adresses constituent les noeuds d'un réseau de transactions de crypto-monnaie (ci après le réseau) dont les transactions forment les liens. Les transactions sont validées collectivement dans le réseau et forment une structure partagée dans le réseau appelée chaîne de blocs (« blockchain » en terminologie anglo-saxonne) jouant le rôle d'un livre de comptes mais contenant en plus l'historique des transactions. En effet, quand un individu A provoque un transfert d'un certain nombre d'unités de compte depuis une de ses adresses vers une des adresses d'un individu B, A doit prouver d'où proviennent ces unités de compte. Et ainsi, il transmet une information du type "ces unités de compte sont celles que j'ai obtenues quand C me les a envoyées il y a deux jours". Et comme tous les utilisateurs possèdent la même copie de la chaîne de blocs, tout le monde peut vérifier que C les a effectivement envoyées à A et qu'elles n'ont pas déjà été renvoyées par A à quelqu'un d'autre. Plus loin, on peut aussi vérifier comment C les a lui-même obtenues et ainsi remonter la chaîne de leurs propriétaires successifs. Autrement dit, on peut reconstruire l'histoire des transactions. Un tel système peut ainsi être utilisé pour transférer des unités de compte vers une adresse (non secrète) ayant typiquement 34 caractères telle que « 1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T » à partir de laquelle l'individu ayant la clé privée (secrète) correspondante, en l'occurrence une clé de 64 caractères « casec4bbcblibec99d65bf59d85c8cb62ee2db963f0fe106f483d9afa 73bd4e39a8a », peut dépenser ces unités. Un tel système peut aussi être utilisé pour transférer des unités de compte vers une adresse dite multi-signatures (ou MULTISIG) pour laquelle il faut obtenir des signatures avec n parmi m clés privées pour dépenser des unités de compte - par exemple, deux signatures à fournir parmi les signatures (i) d'un fournisseur, (ii) d'un client et (iii) d'un arbitre (deux signatures sur trois), l'arbitre devant donner sa signature en cas de dispute entre le fournisseur et le client. On peut donc exprimer des transactions conditionnelles, les conditions étant des signatures et un output d'une transaction pouvant être dépensé si ces signatures sont fournies. La validation collective des transactions sert à tendre vers un consensus de réseau par des techniques connues en soi, telles que les techniques « Proof-ofWork » et « Proof-of-Stake » de validation des transactions annoncées (« broadcast », diffusées) dans le réseau. En résultat : Chaque transaction validée est insérée dans un bloc de la chaîne de blocs. La chaîne de blocs est une liste chaînée de codes de hachage cryptographiques et chaque bloc est organisé en un accumulateur cryptographique (tel qu'un arbre de Merkle) de façon à ce que toute tentative de modification de la transaction violerait l'intégrité de toute la chaîne de blocs à partir du bloc la contenant, ce qui donc signifie que les transactions insérées dans la chaîne de blocs ne peuvent plus être modifiées et que tous les noeuds dans le réseau peuvent aisément vérifier qu'un même output n'est pas dépensé plus d'une fois. Il n'y a donc pas besoin du réseau de confiance (système bancaire) établi entre les intermédiaires financiers, et donc pas besoin de ces intermédiaires financiers. Résumé de l'invention L'invention vise à répondre au besoin d'identifier de manière « minimale » un individu anonyme (l'utilisateur) à qui certains avantages (ou « droits ») sont donnés de manière limitée dans le temps, afin de pouvoir vérifier qu'il n'a pas déjà reçu ces avantages en trop grande quantité ou trop récemment et que par conséquent il y a encore droit. Le terme « minimal » est ici en rapport avec la notion d'anonymat : l'invention vise à sauvegarder l'anonymat de l'utilisateur le plus possible tout en garantissant qu'il ne bénéficiera pas d'avantages auxquels il n'a pas droit. Ainsi on propose un procédé d'identification minimale et anonyme d'un utilisateur susceptible de bénéficier de droits (avantage), comprenant les étapes suivantes : solliciter à partir d'un poste utilisateur une source de droits, au niveau de la source, communiquer au poste utilisateur un programme de vérification (en ZK-SNARK), sauf si le poste utilisateur l'a déjà, ainsi qu'une chaîne de caractères spécifique représentative d'une période de validité du bénéfice des droits (à moins que le programme le génère automatiquement), au niveau du poste utilisateur, exécution du programme de vérification pour prouver de façon anonyme sa possession du document d'identité, le programme de vérification recevant en input privé des données lisibles par machine du document d'identité, et en input public, ladite chaîne de caractères spécifique, et un code de hachage d'une combinaison de ladite chaîne de caractères spécifique et des données du document d'identité, fourniture à la source de droits du code de hachage ainsi obtenu et d'une preuve de l'exécution du programme de vérification, vérification au niveau de la source de ladite preuve d'exécution, et délivrance de droits pour la période considérée, les codes de hachage, obtenus pour un même utilisateur et lui permettant de bénéficier de droits à différentes périodes, ne pouvant pas être mis en relation par la source, ce qui permet de préserver l'anonymat de l'utilisateur. Selon certains aspects préférés mais non limitatifs de cette invention, les droits 10 sont des unités de comptes mises en oeuvre dans un système transactionnel à architecture répartie en peer-to-peer. On définit ici une communauté comme un sous-ensemble des noeuds du réseau correspondant à des individus qui se mutualisent pour mettre dans un « pot 15 commun » le montant nécessaire à pourvoir collectivement à des paiements (transactions) de chacun, ayant une probabilité d'occurrence inférieure à 1 et liés notamment à un risque. Les paiements des membres de la communauté peuvent ainsi se faire à partir dudit pot commun (ci-après dénommé pot) dans des cas définis à l'avance. 20 Un autre objet de la présente invention est de permettre d'assurer une telle mutualisation, sans besoin d'un intermédiaire financier (celui qui détiendrait la clé du pot dans un système traditionnel), de manière fiable et en étant extrêmement souple sur les contraintes et les critères de distribution et de restitution des unités de compte accumulées dans le pot. 25 Plus précisément, cet autre objet de l'invention vise, tout en se basant sur une architecture transactionnelle en peer-to-peer où les unités de compte de l'output d'une transaction donnée, une fois cette transaction mise dans la chaîne de blocs, ont définitivement changé de mains, à créer des jeux de transactions conditionnelles susceptibles de s'alimenter par un même output, pour un usage à vocation mutualisée (« double-spending » temporaire, organisé pour un usage mutualiste, sous contrôle de la communauté). Cet autre objet de l'invention permet avantageusement que les membres de la communauté (tels que des mutualistes), ou que les bénéficiaires potentiels de paiements via le pot (tels que des organismes de santé), puissent sélectionner les membres à l'origine des paiements (les « membres qui aident ») et réciproquement que les membres puissent sélectionner les « membres aidés » (par exemple les mutualistes qui bénéficient des soins sans les financer totalement eux-mêmes), ou leurs attribuer des priorités. Ces sélections peuvent se faire de manière transparente sur la base de critères donnés. Ainsi par exemple, selon le principe dit « à charge de revanche », un membre peut sélectionner en priorité des paiements potentiels par des membres qui ont déjà été aidés par lui (c'est-à-dire qui ont déjà bénéficié de paiements potentiels avec les unités de compte qu'il a déposées dans le pot), et inversement un membre peut en priorité aider des membres qui l'ont déjà aidé. Plus spécifiquement, la communauté peut décider qu'être aidé par un membre non déjà aidé a un coût et que proposer une aide signifie être disposé à accepter que le membre aidé ait une dette envers soi. Les dettes peuvent être réglées par des aides ultérieures (ou des paiements dans les cas où elles tardent trop). L'invention vise ainsi notamment à permettre d'établir un marché d'aides mutuelles. La gestion elle-même de la mise en place des aides, selon les règles de communauté, peut engendrer encore un autre coût et les membres peuvent ajuster tous ces coûts en limitant le volume des paiements potentiels (par exemple leur nombre et leur total - comme le montre une mise en oeuvre simplifiée présentée en Annexe 2 - éventuellement pondérés par leur fiabilité) en émettant des exigences et préférences par rapport notamment aux dates et durées des dépôts d'unités de compte à partir desquels les aides sont fournies et des comptages ayant pour but d'estimer la disponibilité probable des unités de compte constituant les aides. Plus spécifiquement, chaque membre de la communauté peut bénéficier de droits (au sens du premier objet de l'invention présenté plus haut) sous forme d'une certaine quantité prédéterminée d'unités de compte dans une période ou un intervalle de temps prévu, pour payer les aides dont il a besoin au sein d'une communauté. Ainsi, selon cet autre objet de l'invention, on propose un système transactionnel à architecture répartie en peer-to-peer, mettant en oeuvre des transactions permettant de transférer des unités de compte entre noeuds émetteurs d'unités et noeuds receveurs d'unités, chaque transaction dite transaction aval ayant en entrée un input se référant directement ou indirectement à un output d'une transaction amont (ou plusieurs inputs se référant chacun à un output d'une transaction amont) et ayant elle-même au moins un nouvel output spécifiant un nombre d'unités de compte et un noeud receveur, caractérisé en ce qu'il met en oeuvre : des moyens pour affecter à une transaction aval au moins une transaction amont en fonction de règles de correspondance entre un code calculé sur tout ou partie du contenu d'une transaction aval et un code de 20 vérification contenu dans une transaction amont, ou inversement, des moyens pour établir des contraintes d'attribution du montant d'une transaction aval alimentée par une ou plusieurs transactions amont qui lui sont affectées à un ou plusieurs bénéficiaires. Certains aspects préférés mais non limitatifs de ce système sont les suivants : 25 - les contraintes d'attribution sont établies dans la transaction amont affectée à la transaction aval ou dans la transaction aval. - les moyens d'établissement de contraintes d'attribution comprennent la mise en oeuvre d'instructions formant contrat sur des paramètres formant contexte d'invocation. - le contexte d'invocation comprend des paramètres de contexte temporel établies au moment où la transaction amont affectée est générée. - les instructions formant contrat sont identiques pour toutes les transactions amont affectées à une transaction aval, le contexte d'invocation pouvant être différent. - le système comprend des moyens pour sélectivement affecter une transaction amont à une transaction aval également en fonction de données de nombre de transactions amont déjà affectées à ladite transaction aval. - le système comprend des moyens pour sélectivement affecter une transaction 10 amont à une transaction aval également en fonction de données de volume d'unités de compte total de transactions amont déjà affectées à ladite transaction aval. - le système comprend des moyens de validation des transactions aptes à vérifier que les contraintes d'attribution sont satisfaites par les outputs des 15 transactions aval. - les moyens de validation comprennent la prise e compte d'une signature des contextes d'invocation respectivement associés auxdites transactions amont, à l'aide d'au moins une clé de contextes. - les moyens de validation comprennent une signature des transactions à l'aide 20 d'au moins une clé de transaction. - la ou les clés de signature de contextes et la ou les clés de signature de transaction sont les mêmes. - les moyens de validation sont aptes à engendrer un code calculé constituant une preuve d'exécution correcte des instructions formant contrat. 25 - le système comprend également des moyens de validation de transactions au niveau réseau (blockchain), la validation des transactions aval s'effectuant par vérification de leurs signatures. L'invention vise également tous procédés destinés à être exécutés dans un tel système. Les systèmes et procédés de l'invention peuvent être mis en oeuvre dans tout environnement informatique, y compris en tout ou partie dans des dongles 5 intelligents (par exemple connectables en USB) dédiés et contribuant au moins en partie à la sécurité. Brève description des dessins La figure 1 présente schématiquement l'utilisation de la technologie ZK-SNARK pour une identification anonyme. 10 La figure 2 étend le schéma de la figure 1 au procédé de l'invention. La figure 3 présente schématiquement le procédé de l'invention sur un exemple. La figure 4 est un diagramme de séquence décrivant les interactions entre les différentes entités participant au procédé. La figure 5 introduit le procédé de l'invention sur un exemple de deux 15 fournisseurs qui se mutualisent. La figure 6 illustre la généralisation du procédé présenté dans la figure 5 afin de pouvoir le mettre en oeuvre sous la forme d'un programme contrat dont un exemple simplifié est présenté dans l' Annexe 1. La figure 7 présente le principe du procédé généralisé introduit à la figure 6. 20 Description détaillée de l'objet principal de l'invention Dans une mise en oeuvre possible, on peut étendre l'application précitée (illustrée à la figure 1) de preuve de passeport, en ajoutant en input public le code de hachage du passeport (code obtenu en utilisant une fonction de hachage cryptographique prédéterminée sur le contenu des données du passeport ou 25 d'une partie spécifique des données du passeport) qui doit alors aussi être vérifié par le programme (en plus de la vérification de la signature du gouvernement). Aucune donnée du passeport n'étant divulguée, l'utilisateur est alors identifié par ce seul code de hachage, (par exemple dbcc4aab60687a1e032f012a8ea22dObb03a126943c3ba98351b50018a1e79e5 ) plutôt que par le numéro du passeport par exemple. Cette identification n'est cependant pas « minimale » dans la mesure où l'identifiant (ledit code de hachage) peut être relié à d'autres données qui s'accumulent au fil du temps dans des bases de données et qui par recoupements tendent à dévoiler de plus en plus d'informations privées de l'utilisateur. Au lieu du code de hachage du passeport, l'objet principal de la présente invention prévoit d'utiliser un nouveau code de hachage qui soit « minimal » en ce qu'il ne serve que durant le laps de temps où l'utilisateur a droit à un avantage donné (et un seul). En d'autres termes, l'utilisateur n'ayant pas le droit de bénéficier plus que l'avantage prévu pour un intervalle de temps donné (à compter du moment où il reçoit l'avantage précédent), ou pour une période calendaire courante donnée (telle que le mois courant ou l'heure courante), le nouveau code de hachage ne sert que durant cette intervalle de temps ou cette période calendaire (spécifiquement pour vérifier que l'avantage en question n'a pas déjà été donné dans cette intervalle ou cette période). Comme il devient ensuite obsolète et remplacé par un autre code, et qu'il n'y a pas de relation entre différents codes obtenus dans le temps pour un même utilisateur, ce nouveau code ne pourra pas être relié à des informations caractérisant l'utilisateur en dehors de l'intervalle ou la période en question. La figure 2 est un diagramme présentant le procédé de l'invention. Ce procédé peut être mis en oeuvre avec seuls les acteurs 'utilisateur' et 'source' (au sens de la source de l'avantage en question), c'est-à-dire les ordinateurs respectifs utilisés par ces derniers. Le protocole de vérification au moyen de ce code comprend les étapes suivantes d'interactions entre ces acteurs : 1. L'utilisateur demande à la source l'avantage en question et fournit la (ou les) clé publique de l'autorité signataire de son passeport (à moins que le programme en ZK-SNARK contiennent en soi les clés publiques des autorités, auquel cas l'utilisateur n'a pas à la fournir) 2. La source vérifie ledit signataire (à moins que le programme en ZKSNARK contienne en soi les clés publiques des autorités et puisse ainsi lors de son exécution faire cette vérification sans un tel input) et communique à l'utilisateur le programme en ZK-SNARK (à moins que l'utilisateur l'ait déjà) ainsi qu'une chaîne de caractères spécifique représentative d'une période ou intervalle de validité du bénéfice de l'avantage en question (à moins que ledit programme la génère automatiquement) 3. L'utilisateur exécute ledit programme pour prouver sa possession d'un passeport électronique (sans dévoiler son contenu) signé par ladite autorité, en lui fournissant - en input privé, par NFC, les données contenues dans le composant de ce passeport - en input public L la (ou les) clé publique (de ladite autorité) ayant permis de signer les données du passeport (à moins que ledit programme contiennent en soi les clés publiques des autorités) ii. ladite chaîne de caractères spécifique (à moins que ledit programme la génère automatiquement) iii. et le code de hachage de la concaténation de ladite chaîne de caractères spécifique et des données contenues dans le composant de ce passeport. et fournit à la source ledit code de hachage de la concaténation, ainsi que la preuve en ZK-SNARK que - il s'agit bien d'un passeport fourni par l'autorité et - ledit code de hachage de la concaténation est bien obtenu en appliquant la fonction de hachage sur la concaténation de ladite chaîne de caractères spécifique et des données contenues dans le composant de ce passeport. 4. La source vérifie ladite preuve en ZK-SNARK et la non-existence dans sa base de données dudit code de hachage de la concaténation et, si c'est bien le cas, insère le code de hachage de la concaténation dans sa base de données (dans lequel il pourra être supprimé après ladite période ou intervalle de validité du bénéfice de l'avantage). Ladite chaîne de caractères spécifique peut par exemple être composée de la date courante, la période couverte (ou l'intervalle durant lequel l'avantage n'est pas dû), ainsi qu'éventuellement un code (tel qu'un nombre aléatoire, ou une information spécifique) pour cette période (ou cet intervalle). Les avantages dont il est question sont notamment des unités de compte. Description de l'autre objet de l'invention Récemment, il a été introduit, dans Bitcoin, l'option de pouvoir spécifier la condition d'un output en plaçant dans l'output le code de hachage (dit « Pay to Script Hash ») de cette condition, qui elle doit se trouver en clair dans l'input de la transaction qui consomme cet output (condition qui doit être satisfaite pour que ladite transaction soit valide). Ce procédé est décrit dans le BIT-16 Bitcoin Improvement Proposai, https_://github.com/bitcoin/bipsiblob/masteribip0016.mediawiki (plus tard il le sera aussi dans le wiki https://en.bitcoimitiwiki/Transactions#Pay-to-ScriptHash), dont le contenu est ici considéré comme faisant partie de la présente description. Actuellement, les conditions qui peuvent être exprimées dans Bitcoin sont des conditions de multi-signatures, la ou les signatures en question devant être fournies dans ledit input. On va utiliser la méthode « Pay to Script Hash » dans les exemple qui suivent. La partie gauche de la Figure 3 en présente un exemple : Une transaction « Txl » fournit 1000 unités de compte à un noeud receveur identifié par un code de age dénommé ici « Cl » (dans le B1P-16 il s'agit du x.20-bute- -value » du « OP_IIAS11160 120-bytellash-value] OP_ EQUAL ces 1000 unités ne pouvant être consommées que par un input qui comprenne un script (ii s'agit du « (serialrzed script} » mentionné dans le B1P-16) dont le 30 code de hachage (obtenu en appliquant une fonction de hachage prédéterminée sur son contenu) est ce Cl et qui comprenne les signatures qui satisfont la condition spécifiée dans ce script. Quant à la partie droite de la Figure 3, elle présente exactement le même paiement (de 1000 unités à C1) que dans la partie gauche mais en introduisant une indirection selon le procédé de l'invention : Les 1000 unités sont, dans une première transaction (dite transaction amont), « Tx1.1 », payées à un noeud receveur « P1 » (que l'on appelle Pot), à partir duquel, dans une deuxième transaction (dite transaction générée ou transaction aval), «Tx2.1 », le paiement de 1000 unités doit être conforme à une contrainte représentée par « 1000@C1 » (pour dire que la transaction générée doit consister à payer 1000 unités à C1) implicitement imposée par la première transaction (ainsi dans la figure, la contrainte est représentée sur l'output de la transaction amont, en italique). Plus précisément, P1 est un code de vérification obtenu par l'application d'une fonction prédéterminée au « script » de l'input de Tx2.1, et Tx2.1 doit être conforme à la contrainte (ici la contrainte 1000@C1) produite par le « script » de cet input. (On décrit plus loin comment cette contrainte est produite.) A noter que, comme on le voit dans la suite (par exemple à la figure 5), une transaction générée peut avoir plusieurs inputs et pour être valide il suffit qu'elle soit conforme à la contrainte issue d'un de ces inputs. L'état de l'art ne permet pas de valider les outputs d'une transaction aval par rapport à des contraintes émises au niveau d'une transaction amont. On va dans la suite prendre l'exemple de fournisseurs (Fi) qui dans des transactions (Tx1.i) mettent en séquestre des unités de compte qui ne pourront être débloquées que si (selon une condition Ci) le client (correspondant à ce Ci) et le fournisseur signent tous les deux (quel que soit le bénéficiaire décidé par eux) ou si l'arbitre signe soit avec le fournisseur soit avec le client (condition de deux signatures sur trois précitée). Les séquestres (avec ces conditions de signatures) ont pour but d'assurer aux clients respectifs que, s'ils ne sont pas livrés de manière satisfaisante, les unités de compte séquestrées leurs reviendront. Dans une mise en oeuvre avec « mutualisation de risques », les fournisseurs s'organisent en « communauté » et utilisent le procédé de l'invention pour faire des dépôts (mises en séquestre) d'unités de compte dans un pot, les engagements des fournisseurs envers les clients se faisant ainsi via le pot plutôt que directement par chacun. Ainsi, la probabilité de devoir payer un client étant inférieur à 1, plus le pot se remplit plus les mises en séquestre des fournisseurs respectifs peuvent être relativement plus faibles. Le terme « mise en séquestre » est ici utilisé pour bien mettre en évidence que ces dépôts sont des transactions incluses dans la chaîne de blocs pour que les unités déposées (à partir d'un output plus à l'amont) ne puissent pas être redépensées (mais éventuellement rendues plus à l'aval dans le cas d'une multisignatures C, le permettant). A noter que selon la communauté en question, l'arbitre précité (ayant le rôle de donner la deuxième signature dans le cas de conditions de deux signatures sur trois) peut devoir être agréé par la communauté (pour que la transaction aval puisse être validée). Par ailleurs, la fréquence de ses interventions peut être limitée (par précaution). Selon le procédé de l'invention, en plus de la validation classique (telle que dans Bitcoin par exemple), les transactions générées sont soumises à une validation au niveau du contrat de communauté. On va maintenant en décrire deux modes de réalisation. Premier mode de réalisation Dans la figure 3 (ainsi que dans les suivantes), le code de vérification « Pot » est le code de hachage du contenu (du script) de l'input d'une transaction générée, input permettant de produire des contraintes telle que 1000@C1 qui seront vérifiées par rapport aux outputs de ladite transaction générée. Ces contraintes sont produites par l'exécution d'un programme dénommé contrat (ou « contrat de communauté », qui lie les membres de la communauté en question en ce qui concerne les modalités des mises en séquestre et la génération des transactions aval) sur des paramètres appelés contexte d'invocation (ou contexte). Tant le contrat que le contexte d'invocation font partie de l'input de la transaction générée. Les différents fournisseurs se contraignent mutuellement pour leurs mises en séquestre du fait qu'ils partagent un même contrat et, pour toutes les mises en séquestre par les membres d'une communauté donnée, les transactions Tx2i sont générées en l'application du même contrat. Autrement dit, seules les transactions qui sont conformes au contrat sont valides. Lesdits contextes d'invocation qui figurent dans l'input sont signés par la communauté. Il peut notamment s'agir d'une multi-signature (de n parmi m membres de la communauté), ou encore d'une signature d'un ordinateur en « trusted computing ». Dans un système trusted computing (technologie connue en soi), l'ordinateur possède une paire de clés privée/publique, la clé privée étant inscrite dans le matériel sans possibilité de lecture externe, gardée secrète et pouvant servir à signer au nom de la communauté. Les programmes qui sont exécutés dans un ordinateur en trusted-computing pouvant être authentifiés (en faisant générer des codes de hachage correspondant à ces programmes et en les faisant signer avec la clé privée matérielle précitée, technique de « remote attestation » connue en soi), cette approche permet ainsi non seulement de vérifier (en générant le code de hachage soi-même) que c'est bien le bon code qui est exécuté dans le circuit, mais aussi de sécuriser l'envoi de données au programme en les chiffrant avec la clé publique correspondant à la clé privée du circuit et d'être sûr de l'intégrité des résultats signés retournés. On peut ainsi exploiter de tels programmes pour mettre en oeuvre un protocole de fonctionnement d'une communauté tel que celui décrit plus loin et présenté dans un diagramme de séquence à la figure 4. En résumé, les transactions selon ce mode de réalisation sont caractérisées en ce qu'elles contiennent les éléments suivants : - Dans l'output de la transaction amont : i. Valeur : nombre d'unités de compte ü. Hash(Contrat + Contexte) : code de hachage « Pot » (comme le [20-byte-hash-value- » di « OP_HASI-1160 (20-byte-dash- value] flF._CQUAL» du BIP 16) résultant de l'application de la fonction de hachage prédéterminée au contenu du script de l'input en question de la transaction générée - Dans le script de l'input de la transaction générée : i. Contrat ii. Contexte d'invocation par rapport à l'output connecté, signé. La validation consiste à - vérifier que tous les inputs de la transaction générée contiennent (dans leur scripts respectifs) le même contrat ainsi qu'une signature (ou multisignature) par la communauté du contexte d'invocation fourni ; - obtenir le code de hachage du contenu du script (Contrat + Contexte) de chaque input de la transaction générée et le comparer avec le code de hachage donné dans l'output auquel il se connecte et vérifier qu'ils sont identiques et - exécuter ledit Contrat sur ledit Contexte d'invocation par rapport à l'output connecté, pour : 1. obtenir les contraintes (censées contraindre les outputs) et ensuite 2. vérifier que pour un input de la transaction générée la contrainte obtenue est satisfaite vis-à-vis des outputs de la transaction générée (ceci sera illustré dans les exemples présentés plus loin). La vérification se satisfait de la conformité d'un seul input (c'est-à-dire qu'il suffit de satisfaire les contraintes émises par un seul output connecté) car une transaction générée ne peut pas satisfaire des contraintes émises par une transaction amont antérieure à sa propre transaction amont or il peut (dans la mesure où il bénéficie d'une aide) avoir un input qui en bénéficie (comme on va le voir dans l'exemple qui suit, présenté dans la figure 5). On va maintenant illustrer la création d'une communauté et décrire comment s'effectue la mutualisation de risques. Dans l'exemple qui suit, le principe est que le premier fournisseur (ou un ou plusieurs remplaçants) joue un rôle de coordinateur (Root) et qu'il informe les autres fournisseurs du contexte, selon le protocole présenté à la figure 4. Le contexte ainsi communiqué aux membres successifs de la communauté comprend l'ensemble courant des outputs disponibles dans le pot (correspondant aux mises en séquestre précédentes, ou un sous-ensemble de celles-ci comme on va le voir dans un exemple présenté plus loin) auxquels de nouveaux paiements potentiels (à générer conformément au contrat) pourront se connecter, le restant des unités de compte prises à partir de ces output étant remis au pot pour les prochains. Chaque fournisseur peut ainsi compléter des paiements d'autres fournisseurs dans des cas où leurs engagements envers leurs propres clients ne sont pas entièrement couverts. La figure 4 est un diagramme de séquence présentant les interactions entre les différents acteurs impliqués. F., F...1 et Root sont des fournisseurs, C. et Ci sont des clients, Blockchain' représente abstraitement le réseau : une flèche vers Blockchain indique le fait d'annoncer une ou des transactions dans le réseau en vue de la ou les faire inclure dans la chaîne de blocs. Root est l'initiateur de la communauté, le premier fournisseur, ou un ensemble d'autres fournisseurs lorsque le Root courant n'est plus fonctionnel (lorsque le Root courant quitte la communauté ou devient indisponible). On représente ici les interactions sans préciser si elles sont effectuées manuellement ou de manière automatique (l'intérêt d'un traitement automatique est présenté juste après). Les numéros indiqués dans la figure correspondent aux étapes suivantes : 1. Un nouveau fournisseur F. est introduit dans la communauté par le fournisseur F._1 qui lui communique l'adresse de Root (ou une nouvelle aide va être demandée par un fournisseur existant) 2. F. demande confirmation à Root, en fournissant l'identifiant de Fa_i (typiquement on pourra ajouter ici des sous-étapes de validation de l'entrée du nouveau membre dans la communauté et d'insertion dans le contexte de paramètres spéciaux le concernant, tels que le volume des outputs disponibles dans le pot à prendre en compte) 3. Dans le cas d'une confirmation, Root fournit l'état courant de la communauté contenant notamment l'ensemble des outputs disponibles (ou un sous-ensemble) avec leurs propres contextes respectifs (pour permettre à un nouvel input de les consommer) + l'ensemble des valeurs (nombre d'unités de compte) attendues par les Clients respectifs - les outputs disponibles et les valeurs attendues représentant des éléments essentiels du contexte utilisé au point 4 4. F. hache le contrat et le contexte pour générer le code de hachage qui figurera dans l'output de sa mise en séquestre (Tx1.n) 5. Fn annonce son paiement (Tx1.n) dans le réseau 6. F. génère les contraintes et les transactions correspondantes et envoie à Root une mise-à-jour du contexte 7. Eventuellement Fn informe lui-même son client C. des transactions qui sont à sa disposition 8. Eventuellement Fn informe lui-même les autres clients des transactions complémentaires dont ils pourront bénéficier. On peut bien entendu envisager un système informatique pour assister les fournisseurs (ou dans d'autres exemples d'autres acteurs qui se mutualisent) à générer les contraintes et les transactions, ainsi que pour assister les clients (ou dans d'autres exemples d'autres bénéficiaires potentiels de ces transactions) à générer aussi des transactions pour le cas échéant se faire payer et annoncer ces transactions dans le réseau et les faire insérer dans la chaîne de blocs. Le contrat peut être prévu pour tenir compte d'exigences et de préférences (fournies dans le contexte d'invocation), en particulier quant au volume des montants prévus potentiellement payables par des transactions générées (il s'agit d'ignorer certaines mises en séquestre dans le pot commun et d'exploiter les autres) et aux contraintes produites en conséquence, comme on le voit dans un exemple présenté plus loin. La partie droite de la figure 3 présentait la mise au pot de 1000 unités d'un premier fournisseur (suite à la création d'une nouvelle communauté et de son contrat). La figure 5 présente en plus les transactions ajoutées pour un deuxième fournisseur. On voit dans cette figure quatre lignes de transactions, selon l'ordre de consommation des outputs des premières transactions Txl.i. Ainsi, en cas de défaut de livraison par deux fournisseurs Fl et F2 à deux clients respectifs Cl et C2, la première ligne de transactions présente le cas d'un premier paiement au client Cl par le fournisseur Fl en cas de défaut de livraison de Fl à Cl, la deuxième ligne concerne le cas du paiement à Cl par Fl après que C2 a été payé en cas de défauts de livraison successifs, la troisième ligne présente le cas d'un premier paiement à C2 en cas de défaut de livraison de F2 à C2, et la quatrième ligne le cas du paiement de C2 par F2 après que le paiement de Cl a déjà été effectué. La restitution des sommes mises en séquestre aux fournisseurs dans le cas où les livraisons ont été correctement assurées s'effectue selon le même processus, les bénéficiaires des transactions pouvant dans ce cas être Fl ou F2 à la place de Cl ou C2. Ainsi par les Ci on entend (plutôt que les clients) les conditions (de multi-signatures) qui engendrent un paiement au client ou fournisseur de niveau i. Les contraintes sont présentées ici dans une syntaxe compacte pour spécifier les montants et les noeuds receveurs. Ainsi, sur Tx1.2, « 950@(950@c/)&1000@c2 » et « 950@C2 » forment une contrainte (qui peut aussi être représentée sous la forme « 950@(950@C1)&1000@C2//950@C2 ») signifiant « transaction générée ayant un premier output payant 950 unités (implicitement au pot) à partir duquel une autre transaction générée paye 950 unités à une condition Cl et un deuxième output payant 1000 unités à C2, et transaction générée ayant un output payant 950 unités à une condition C2 ». L'ajout d'une nouvelle mise en séquestre dans le pot permet de complémenter les transactions qui ne payaient pas l'entièreté des montants attendus par les clients. Par exemple, en ce qui concerne la séquence « C2 Cl » (signifiant d'abord `C2 ou F2' est payé, ensuite 'Cl ou F1' est payé), Tx2.2.2 ne paie que 950 unités alors que, le cas échéant, le client Cl s'attend à en recevoir 1000. La figure 6 présente une manière de généraliser le procédé et faciliter ainsi la mise en oeuvre d'un contrat dont un exemple (simplifié) est présenté (encapsulé 5 entre des balises en formalisme XML) dans l'Annexe 1. Comparée à la figure 5, dans la figure 6 la transaction générée Tx2.2.3 est connectée à un output de la transaction générée Tx2.1.1 au lieu d'être connecté à un output de la mise en séquestre (Tx1.2) par F2, qui elle-même alimente Tx2.1.1 bien que cette dernière fut déjà suffisamment alimentée par Tx1.1. Vu ainsi, le mécanisme 10 fonctionne quel que soit les montants mis en séquestre par les différents fournisseurs. Par exemple Tx1.1 peut consister en une mise en séquestre inférieure au montant attendu par Cl (en attendant qu'il y ait d'autres fournisseurs qui participent au pot et complètent sa mise). La figure 7 présente le principe du procédé ainsi généralisé, avec les tests sur les 15 montants Ai (comme Amount) mis en séquestre par les fournisseurs Fi vis-à-vis des montants attendus Air (comme Required Amount) par les clients Ci, pour décider des montants à spécifier sur les outputs, tel que mis en oeuvre dans le programme donné dans l'Annexe len guise d'exemple et de manière simplifiée. Ainsi (le premier output de Tx2.1.1, après l'arrivée de F2), « Al+A2>Alr :Alr,(Al+A2) 20 Air 1000 » signifie « Si Al (la mise en séquestre de Fl) + A2 (la mise en séquestre de F2) est supérieur à Air (le montant attendu par Cl), alors l'output paie Air (en l'occurrence c'est le cas, et l'output paie donc 1000 unités de compte) sinon l'output paie Al+A2. Par le programme présenté dans l'Annexe 1, pour le contexte suivant (où il y a 25 les 3 fournisseurs Fi, F2, F3, ces fournisseurs mettant respectivement en séquestre 1000, 950 et 900 unités de compte, et leurs clients respectifs Cl, C2, C3 attendant chacun 1000 unités de compte) List availableOutputs = new LinkedList (); availableOutputs.add(new Output(1000,"F1")); availableOutputs.add(new Output(950,"F2")); availableOutputs.add(new Output(900,"F3")); List currentRequirements = new LinkedList (); currentRequirements.add(new ClientRequirement(1000, "Cl")); currentRequirements.add(new ClientRequirement(1000, "C2")); currentRequirements.add(new ClientRequirement(1000, "C3")); les contraintes suivantes (auxquelles les transactions générées doivent respectivement se conformer) sont produites : 1000.0@C1&1850.0@((1000.0@C2&850.0@(850.0@C3))11(1000.0@C3 &850.0@(850.0@C2))) 1000.0@C2&1850.0@((1000.0@C1&850.0@(850.0@C3)) I I (1000.0@C3 &850.0@(850.0@C1))) 1000.0@C3&1850.0@((1000.0@C1&850.0@(850.0@C2))11(1000.0@C2 &850.0@(850.0@C1))) Quant au contexte (simplifié) présenté dans l'Annexe 2, contexte fourni à F5, il comprend les outputs des fournisseurs F1 à F4, et F5 restreint les contraintes générées à un montant total d'aides de 2000 unités et à 2 aides au minimum (dans cet exemple), comme on le voit ci-après dans l'appel de fonction « generateConstraintsAutoSelectOutputs(f5, availableOutputs, c5,2000,2); ». Output f1= new Output(1000, "F1"); Output f2 = new Output(950, "F2"); Output f3 = new Output(900, "F3"); Output f4 = new Output(850, "F4"); Output f5 = new Output(800, "F5"); ClientRequirement cl = new ClientRequirement(1000, "Cl"); ClientRequirement c2 = new ClientRequirement(1000, "C2"); ClientRequirement c3 = new ClientRequirement(1000, "C3"); ClientRequirement c4 = new ClientRequirement(1000, "C4"); ClientRequirement c5 = new ClientRequirement(1000, "C5"); List availableOutputs = new LinkedList O; Pledge p1= new Pledge(); pladdClientRequirement(c1); Pledge p2 = new Pledge(); p2.addClientRequirement(c2); Pledge p3 = new Pledge(); p3.addClientRequirement(c3); Pledge p4 = new Pledge(); p4.addClientRequirement(c4); Pledge p5 = new Pledge(); p5.addClientRequirement(c5); fl.setExistingPledge(p1); f2.setExistingPledge(p2); f3.setExistingPledge(p3); f4.setExistingPledge(p4); f5.setExistingPledge(p5); available0utputs.add(f1); availableOutputs.add(f2); available0utputs.add(f3); availableOutputs.add(f4); List le = generateConstraintsAutoSelectOutputs(f5, availableOutputs, c5,2000,2); for (Constraint c : lc) { System.out.println(c); } Ce programme (aussi simplifié) engendre les contraintes suivantes (auxquelles les transactions générées doivent respectivement se conformer) : 1000.0@C5&1550.0@((1000.0@C4&550.0@(550.0@C3))i I (1000.0@C3 &550.0@(550.0@C4))) 1000.0@C5&650.0@(650.0@C4) 1000.0@C5&700.0@(700.0@C3) 800.0@C5 A noter que ce programme ne génère que des transactions aval recevant des 15 aides des fournisseurs précédents (les fournisseurs F1 à F4 ne reçoivent pas d'aide de F5). Ces programmes peuvent facilement être étendus par l'homme du métier pour la génération des transactions elles-mêmes. Dans une variante de ce mode de réalisation, on peut placer le Contexte 20 d'invocation et/ou le Contrat au niveau de l'output de la transaction amont, le noeud receveur étant toujours représenté par le code de hachage du Contexte d'invocation et du Contrat, ou représenté par le code de hachage du Contrat seul. Il faut cependant pouvoir détecter que le système fonctionne selon cette variante pour, lors de la validation des transactions générées, produire les 25 Contraintes à partir de l'exécution du Contrat sur le Contexte d'invocation et vérifier que leurs outputs les satisfont (comme décrit plus haut). Cette détection peut être réalisée par exemple en plaçant dans l'output en question une information représentative du fait que le système opère selon cette variante. Ces procédés peuvent être combinés, chaque output contenant une information du mode considéré, explicite ou implicite. Les transactions générées peuvent à la rigueur être « localement » validées par la communauté. Dans ce cas, les transactions générées seraient des transactions conditionnelles de type Pay-to-Script-Hash (classiquement) exigeant juste une signature de la communauté. Dans chaque transaction générée, la signature de sa validité par la communauté - on entend par là une multi-signature ou la signature d'un ordinateur en trusted computing - doit alors être ajoutée avant de l'annoncer (broadcast) au réseau (en vue de la faire inclure dans la chaîne de blocs). On comprend qu'il n'est alors pas nécessaire de garder in-extenso le contenu des inputs, dans la mesure où les validateurs sont (via le Root) aptes à les reconstruire et vérifier les outputs des transactions générées. La limite d'une telle approche est que n'importe quelle transaction agréée par la communauté peut puiser dans la mise en séquestre du fournisseur F. Il est donc préférable de mettre en oeuvre l'ensemble du protocole présenté à la figure 4, car il s'agit bien d'un contrat passé entre F. et la communauté (représentée par Root) et ce protocole permet à F. de générer les contraintes lui-même sur la base de ce contrat et du contexte courant, en accord avec la communauté, et d'assurer qu'elles vont être respectées. Il en découle que l'approche la plus avantageuse pour ce mode de réalisation est de faire vérifier par le réseau la signature de la communauté (fournie sur la transaction et indiquant que la transaction générée a déjà été vérifiée par la communauté, localement, comme évoqué ci-avant) par rapport à la signature du contexte d'invocation fourni dans chaque input (en comparant les clés publiques correspondant aux clés privées qui ont été utilisées pour signer). On a alors l'assurance que F. et la communauté sont bien d'accord. Deuxième mode de réalisation Un mode de réalisation du procédé de cet objet de l'invention est de spécifier 30 dans l'output de la transaction amont un code de vérification de la preuve à divulgation nulle de connaissance de l'exécution d'un programme (voir l'article précité de Eli Ben-Sasson & al.), cette preuve devant être présente dans l'input de la transaction générée qui se connecte à cet output, ledit programme étant ici le contrat et les données qui lui sont fournies étant le contexte d'invocation ainsi que les outputs de ladite transaction générée. Comparé au mode de réalisation précédent, le programme formant le contrat (dont la preuve d'exécution est fournie dans un input de la transaction générée) est ici légèrement différent au sens où les contraintes produites par son exécution sont directement vérifiées (au cours de l'exécution même) sur le ou les outputs de ladite transaction générée qui contient cette preuve dans un input, alors que dans le mode de réalisation précédent, seules les contraintes sont produites par l'exécution du contrat sur le contexte et cette vérification est faite distinctement du programme. Dans cette approche, le code de vérification est analogue au code de hachage précédemment décrit, mais l'avantage de cette approche est que la validation des contraintes sur l'output de la transaction générée peut se faire une seule fois (il suffit de fournir cette preuve une fois). Dans la mesure où vérifier cette preuve prend beaucoup moins de temps que d'exécuter le contrat lui-même sur le contexte et vérifier les contraintes sur les outputs de la transaction générée, le fait de construire cette preuve une seule fois peut s'avérer plus avantageux, même si cette construction peut prendre un temps non négligeable, que de ré-exécuter le contrat n fois pour valider par n signatures une transaction générée (dans le cas où l'on souhaiterait que n validateurs vérifient chaque transaction générée - plutôt que le Root seulement - pour la valider au nom de la communauté). Le procédé de l'invention, basé sur l'enrichissement de technologies existantes pour permettre d'utiliser un « pot commun » de mutualisation, peut s'appliquer à tous les cas de mutualisation de risques. On a ainsi décrit l'invention en donnant l'exemple d'une mise en séquestre par un fournisseur pour rassurer un client, mais on peut bien sûr aussi appliquer exactement le même procédé pour la mise en séquestre d'un client pour rassurer un fournisseur, l'avantage de la mutualisation (typiquement de risques) se retrouvant dans le cas d'une mutualisation entre clients. On peut également par exemple mutualiser des risques de maladie ou d'accident et mettre en séquestre des unités de compte pour couvrir des dépenses de traitement médical... Il ne s'agit ainsi pas seulement de fournisseurs ou de clients mais biens de n'importe quels types d'acteurs, acteurs qui d'un côté se mutualisent et de l'autre acceptent de recevoir des garanties d'une communauté d'acteurs ainsi mutualisés. Pour terminer, on notera que l'invention s'applique aussi bien à des architectures où des transactions aval se réfèrent directement à des transactions amont qui les alimentent (par exemple système Bitcoin) qu'à des architectures où cette référence est indirecte (par exemple le système Zerocash basé sur des preuves à non-divulgation de connaissance, permettant d'éviter de divulguer l'origine des unités de compte). L'homme du métier saura dans ce cas faire les adaptations nécessaires. ANNEXE 1- Contrat simplifié pour démontrer la génération de contraintes class Output { double amount; String address; String toString(){ return address+":"+amount; } Output(double amount, String address) { setAmount(amount); setAddress(address); } } class ClientRequirement { double amount; String client; String toString(){ return client+":"+amount; } ClientRequirement( double amount, String client) { setAmount(amount); setClient(client); } } class Constraint { double amount; String cldest; List dest = new LinkedList Q; List otherOutputs = new LinkedList Q; String toString() String result = "" + amount + "e"; if (cldest != null) { result += cldest; } else result += "("; if (dest.size() > 1) { for (int i = 0; i 0) { result += dest.get(0); result += ")"; } for (Constraint c : otherOutputs) result += "+" + c; } return result; } Constraint(double amount, String cldest) setAmount(amount); setCldest(cldest); } Constraint(double amount, List dest) setAmount(amount); setDest(dest); } void addToDest(Constraint c) { dest.add(c); void addToOtherOutput(Constraint c) otherOutputs.add(c); double sum(List outputs) { double result = 0; for (Output o : outputs) { result o.getAmount(); } return result; } List generateConstraints(List availableOutputs, List currentRequirements) { List results = new LinkedList 0; double total = sum(availableOutputs); for (ClientRequirement clr currentRequirements) Constraint c = null; if (total > clr.getAmount()) { c = new Constraint(c1r.getAmount(), clr.getClient()); if (total - clr.getAmount() > 0) { List newLO = new LinkedList 0; newLO.add(new Output(total - clr.getAmount(), "POT")); List remainingRequirements = new LinkedList (); remainingRequirements.addAll(currentRequirements); remainingRequirementssemove(c1r); List dest = generateConstraints(newL0, remainingRequirements); Constraint otherC = new Constraint(total - clr.getAmount(), dest); c.addToOtherOutput(otherC); } else c = new Constraint(total, clr.getClient()); results.add(c); } return results; } ANNEXE 2 - Contrat simplifié pour démontrer la génération restreinte de contraintes class Pledge '1000" client="C1" /> '950" client ="C2" /> '900" client ="C3" /> '850" client ="C4" /> amount="1000" /> amount="1000" /> amount="1000" /> amount="1000" /> '800" > amount="1000" /> List outputs; List clientRequirements; Pledge(){ outputs = new LinkedList (); clientRequirements = new LinkedList (); ; } public void addPledge(Pledge p){ for(Output o:p.getOutputsQ){ addOutput(o); } for(ClientRequirement cl:p.getClientRequirements()){ addClientRequirement(cl); } } public void addOutput(Output o){ if(!outputs.contains(o)){ outputs.add(o); } } public void addClientRequirement(ClientRequirement cr){ if(!clientRequirements.contains(cr)){ clientRequirements.add(cr); } class OutputCreationContext { List outputs; 20 List clientRequirements; } class Output { double amount; 25 String address; String toString(){ return address+":"+amount; } 30 Output(double amount, String address) { setAmount(amount); setAddress(address); } 35 } class ClientRequirement { double amount; String client; String toString(){ return client+":"-Famount; } ClientRequirement( double amount, String client) { setAmount(amount); setClient(client); } } class Constraint double amount; String cldest; List dest = new LinkedList (); List otherOutputs = new LinkedList O; String toString() String result = "" + amount + "@"; if (cldest != null) result cldest; } else result += "("; if (dest.size() > 1) { for (int i = 0; i 0) { 33 result += dest.get(0); } result += ")"; for (Constraint c : otherOutputs) result += "+" + c; } return result; } Constraint(double amount, String cldest) { setAmount(amount); setCldest(cldest); } Constraint(double amount, List dest) { setAmount(amount); setDest(dest); } void addToDest(Constraint c) dest.add(c); } void addToOtherOutput(Constraint c) { otherOutputs.add(c); } } public class SuretyBond /** * @param args the command une arguments *1 static double sum(List outputs) double result = 0; 34 for (Output o : outputs) { result += o.getAmountQ; } return result; } static List outputs) List = 1; i--) { result.addAll(combinationOf(outputs, i)); } return result; } static List outputs, int taken) List os = new LinkedList (); os.add(o); resultadd(os); } } else { result = new LinkedList noutputs = new LinkedList (); noutputs.addAll(outputs); int k = taken - 1; for (Output ref : outputs) { noutputs.remove(ref); if (noutputs.size() >= k) List outl outt1) outladd(0, ref); result.add(outl); } } return result; } static Pledge getCombinedPledges(List outputs) Pledge p = new Pledge(); for (Output o : outputs) { Pledge ox = o.getExistingPledge(); if (ox != null) p.addPledge(ox); } } return p; } static Constraint generateConstraints( Output pot, Pledge p, List usedOutputs, List paidRequirements) { List availableOutputs = new LinkedList (); availableOutputs.add(pot); List remainingRequirements = new LinkedList 0; for (ClientRequirement cr : p.getClientRequirements()) { if (!paidRequirements.contains(cr)) remainingRequirements.add(cr); } } double total = sum(availableOutputs); List dest = generateConstraints(availableOutputs, remainingRequirements); Constraint otherC = new Constraint(total, dest); return otherC; static List generateConstraintsAutoSelectOutputs( Output refOutput, List availableOutputs, ClientRequirement currentRequirement, double sumAmount, int helps) List selectedOutputs = new LinkedList Q; double amt = refOutputgetAmount(); int i = availableOutputs.size() - 1; while (!((amt > sumAmount)&&(selectedOutputs.sizeQ>=helps)) && (i >= 0)) { selectedOutputs.add(availableOutputs.get(i)); amt += availableOutputs.get(i).getAmount(); i--; } return generateConstraints(refOutput, selectedOutputs, currentRequirement); } static List generateConstraints( Output refOutput, List selectedOutputs, ClientRequirement currentRequirement) { List results = new LinkedList 0; List Q); //when there's no other output left for (List availableOutputs : lavo) { availableOutputs.add(refOutput); double total = sum(availableOutputs); Constraint c = null; if (total > currentRequirement.getAmount()) c = new Constraint(currentRequirement.getAmountQ, currentRequirement.getClient()); if (total - currentRequirement.getAmount() > 0) { Pledge combined = getCombinedPledges(availableOutputs); List usedOutputs = new LinkedList (); List paidRequirements = new LinkedList (); paidRequirements.add(currentRequirement); usedOutputs.addAll(availableOutputs); Output pot = new Output(total - currentRequirement.getAmount0, "POT"); Constraint otherC = generateConstraints(pot, combined, usedOutputs, paidRequirements); c.addToOtherOutput(otherC); } }else{ c = new Constraint(total, currentRequirement.getClient(); } results.add(c); } return results; } static List generateConstraints(List availableOutputs, List currentRequirements) { List results = new LinkedList (); double total = sum(availableOutputs); for (ClientRequirement clr : currentRequirements) { Constraint c = null; if (total > clr.getAmount()) { c = new Constraint(c1r.getAmount0, clr.getClient()); if (total - clr.getAmount() > 0) { List newLO = new LinkedList (); newLO.add(new Output(total - clr.getAmount(), "POT")); List remainingRequirements = new LinkedList 0; remainingRequirements.addAll(currentRequirements); remainingRequirementssemove(c1r); List dest = generateConstraints(newL0, remainingRequirements); Constraint otherC = new Constraint(total - clr.getAmount(), dest); c.addToOtherOutput(otherC); } else { c = new Constraint(total, clr.getClient()); results.add(c); } return results; REVENDICATIONS1. Procédé d'identification minimale et anonyme d'un utilisateur susceptible de bénéficier de droits (avantage), comprenant les étapes suivantes : solliciter à partir d'un poste utilisateur une source de droits, au niveau de la source, communiquer au poste utilisateur un programme de vérification (en ZK-SNARK), sauf si le poste utilisateur l'a déjà, ainsi qu'une 10 chaîne de caractères spécifique représentative d'une période de validité du bénéfice des droits (à moins que le programme le génère automatiquement), au niveau du poste utilisateur, exécution du programme de vérification pour prouver de façon anonyme sa possession du document d'identité, le programme de vérification recevant en input privé des données lisibles par 15 machine du document d'identité, et en input public, ladite chaîne de caractères spécifique, et un code de hachage d'une combinaison de ladite chaîne de caractères spécifique et des données du document d'identité, fourniture à la source de droits du code de hachage ainsi obtenu et d'une preuve de l'exécution du programme de vérification, 20 vérification au niveau de la source de ladite preuve d'exécution, et délivrance de droits pour la période considérée, les codes de hachage, obtenus pour un même utilisateur et lui permettant de bénéficier de droits à différentes périodes, ne pouvant pas être mis en relation par la source, ce qui permet de préserver l'anonymat de l'utilisateur. 25 2. Procédé selon la revendication 1 dans lequel les droits sont des unités de comptes mises en oeuvre dans le système selon l'une des revendications 3 à 15. 3. Système transactionnel à architecture répartie en peer-to-peer, mettant en oeuvre des transactions permettant de transférer des unités de compte entre noeuds émetteurs d'unités et noeuds receveurs d'unités, chaque transaction dite transaction aval ayant en entrée un input se référant directement ou indirectement à un output d'une transaction amont (ou plusieurs inputs se référant chacun à un output d'une transaction amont) et ayant elle-même au moins un nouvel output spécifiant un nombre d'unités de compte et un noeud receveur, caractérisé en ce qu'il met en oeuvre : des moyens pour affecter à une transaction aval au moins une 10 transaction amont en fonction de règles de correspondance entre un code calculé sur tout ou partie du contenu d'une transaction aval et un code de vérification contenu dans une transaction amont, ou inversement, des moyens pour établir des contraintes d'attribution du montant d'une transaction aval alimentée par une ou plusieurs transactions amont qui lui sont 15 affectées à un ou plusieurs bénéficiaires. 4. Système selon la revendication 3, dans lequel les contraintes d'attribution sont établies dans la transaction amont affectée à la transaction aval. 20 5. Système selon la revendication 3, dans lequel les contraintes d'attribution sont établies dans la transaction aval. 6. Système selon la revendication 4 ou 5, dans lequel les moyens 25 d'établissement de contraintes d'attribution comprennent la mise en oeuvre d'instructions formant contrat sur des paramètres formant contexte d'invocation. 7. Système selon la revendication 6, dans lequel le contexte d'invocation comprend des paramètres de contexte temporel établies au moment où la transaction amont affectée est générée. 8. Système selon la revendication 6 ou 7, dans lequel les instructions formant contrat sont identiques pour toutes les transactions amont affectées à une transaction aval, le contexte d'invocation pouvant être différent. 9. Système selon la revendication 7 ou 8, lequel comprend des moyens pour 10 sélectivement affecter une transaction amont à une transaction aval également en fonction de données de nombre ou de volume d'unités de compte total de transactions amont déjà affectées à ladite transaction aval. 10. Système selon la revendication 3, lequel comprend des moyens de 15 validation des transactions aptes à vérifier que les contraintes d'attribution sont satisfaites par les outputs des transactions aval. 11. Système selon la revendication 10, dans lequel les moyens de validation comprennent la prise en compte d'une signature des contextes d'invocation 20 respectivement associés auxdites transactions amont, à l'aide d'au moins une clé de contextes. 12. Système selon l'une des revendications 3 à 10, dans lequel les moyens de validation comprennent une signature des transactions à l'aide d'au moins une 25 clé de transaction. 13. Système selon la revendication 11, dans lequel la ou les clés de signature de contextes et la ou les clés de signature de transaction sont les mêmes. 14. Système selon les revendications 6 et 10 prises en combinaison, dans lequel les moyens de validation sont aptes à engendrer un code calculé constituant une preuve d'exécution correcte des instructions formant contrat. 15. Système selon l'une des revendications 11 et 12, lequel comprend également des moyens de validation de transactions au niveau réseau (blockchain), la validation des transactions aval s'effectuant par vérification de leurs signatures. 10