FR3018378A1

FR3018378A1 - Systeme et procede transactionnels a architecture repartie fondees sur des transactions de transferts d'unites de compte entre adresses

Info

Publication number: FR3018378A1
Application number: FR1400594A
Authority: FR
Inventors: Enrico Maim
Original assignee: Individual
Current assignee: Individual
Priority date: 2014-03-12
Filing date: 2014-03-12
Publication date: 2015-09-11
Also published as: US11210647B2; US20170091750A1; US20180349877A9; US20180121902A1

Abstract

Un système transactionnel à architecture répartie en peer-to-peer se base sur des transactions permettant de transférer des unités de compte entre nœuds émetteurs d'unités et nœuds receveurs d'unités, chaque transaction ayant en entrée un input se référant à un output d'une transaction précédente (ou plusieurs inputs se référant chacun à un output d'une transaction précédente) et ayant elle-même au moins un nouvel output spécifiant un nombre d'unités de compte et un nœud receveur. Selon l'invention, il met en œuvre : des transactions dites transactions amont, des transactions aval destinées à être sélectivement alimentées par des transactions amont, des moyens pour affecter à une transaction aval au moins une transaction amont en fonction de règles de correspondance entre un code de hachage calculé sur tout ou partie du contenu d'une transaction aval et une valeur de hachage contenue dans une transaction amont, ou inversement, des moyens pour établir des contraintes de répartition du montant d'une transaction aval alimentée par une transaction amont qui lui est affectée entre plusieurs bénéficiaires.

Description

Le domaine de l'invention est l'utilisation de crypto-monnaies et la génération automatique de transactions, notamment pour permettre la mutualisation des risques dans une communauté. Dans un système de crypto-monnaie tel que le système BitCoin, des transactions 5 permettent de transférer des unités de compte entre adresses créées à partir de clés publiques cryptographiques. Chaque transaction a en entrée un input se référant à un 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 10 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 15 le rôle d'un livre de comptes mais contenant en plus l'historique des transactions. En effet, quand un individu A fait 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ù elles viennent. Et ainsi, il transmet une information du type "ces 20 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é envoyées par A. Plus loin, on peut aussi vérifier comment C les a lui-même obtenues et ainsi remonter la chaîne de leurs 25 propriétaires successifs. Autrement dit, on peut reconstruire l'histoire des transactions. Enfin, la validation collective des transactions sert à tendre vers un consensus de réseau par des techniques connues en soi, telles que les techniques « Proofof-Work » et « Proof-of-Stake » de validation des transactions annoncées 30 (« broadcast », diffusées) dans le réseau. Chaque transaction validée est insérée dans un bloc de la chaîne de blocs, bloc organisé en 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.

Résumé de l'invention On définit ici une communauté comme un sous-ensemble du réseau. Il s'agit d'un ensemble de noeuds dans le réseau, correspondant à des individus qui se mutualisent pour mettre dans un « pot commun », le montant nécessaire à pourvoir collectivement à des paiements (transactions) de chacun, paiements ayant une probabilité d'occurrence inférieure à 1. Les paiements des membres peuvent ainsi se faire à partir dudit pot commun (ci-après dénommé pot) dans des cas définis à l'avance. La présente invention vise à permettre d'assurer une telle mutualisation, sans besoin d'un intermédiaire financier, en étant fiable et en étant extrêmement souple sur les contraintes de distribution et de restitution des unités de compte accumulées dans le pot commun. Avantageusement, le procédé de l'invention peut être mis en oeuvre en enrichissant l'Etat de l'Art pour permettre de garantir des paiements via un pot commun. On propose ainsi selon l'invention, selon un premier aspect, 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 ayant en entrée un input se référant à un output d'une transaction précédente (ou plusieurs inputs se référant chacun à un output d'une transaction précédente) 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 transactions dites transactions amont qui ont un output vers un identifiant de noeud receveur, des transactions aval (transactions générées) contenant dans un input un programme (contrat) et un ensemble de paramètres (contexte d'invocation), des transactions aval ne pouvant être alimentées qu'à partir de transactions amont ayant pour identifiant de noeud receveur (Pot) dans leur output une valeur égale à celle résultant de l'application d'une fonction de hachage prédéterminée sur un ensemble d'informations contenant le programme et les paramètres, le programme et les paramètres contenus dans un input d'un transaction aval donnée définissant des contraintes implicitement émises au niveau d'une transaction amont qui l'alimente, ces contraintes étant relatives à un ou plusieurs montants de la transaction aval, et à un ou plusieurs identifiants de noeud receveurs pour ces montants, une transaction aval ne pouvant être validée que si de telles contraintes émises au niveau d'au moins une transaction amont sont satisfaites.

Selon un second aspect, on propose un procédé de gestion d'unités de compte mises en commun dans 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 ayant en entrée un input se référant à un output d'une transaction précédente (ou plusieurs inputs se référant chacun à un output d'une transaction précédente) et ayant elle-même au moins un nouvel output spécifiant un nombre d'unités de compte et un noeud receveur, le procédé comprenant les étapes suivantes : prévoir des transactions dites transactions amont ayant un output vers 25 un identifiant de noeud receveur, prévoir des transactions aval (transactions générées) contenant dans un input un programme (contrat) et un ensemble de paramètres (contexte d'invocation), pour une transaction aval donnée, appliquer une fonction de hachage prédéterminée sur un ensemble d'informations contenant le programme et les paramètres contenus dans l'input de ladite transaction aval, et considérer la ou les transactions amont dont l'identifiant de noeud receveur (Pot) est égal au code de hachage obtenu par la fonction de hachage, seules de telles transactions amont pouvant être validées comme alimentant ladite transaction aval, pour une transaction aval donnée, exécuter le programme en utilisant lesdits paramètres pour retrouver la contrainte implicitement émise au niveau d'une transaction amont qui l'alimente, cette contrainte étant relative à un ou plusieurs montants de la transaction aval, et à un ou plusieurs identifiants de noeud receveurs pour ces montants, et valider une transaction aval seulement si la contrainte émise au niveau d'au moins une transaction amont est satisfaite. Brève description des dessins La figure 1 présente schématiquement le procédé de l'invention sur un exemple. La figure 2 est un diagramme de séquence décrivant les interactions entre les différentes entités participant au procédé. La figure 3 introduit le procédé de l'invention sur un exemple de deux fournisseurs qui se mutualisent.

La figure 4 présente des contributions apportées par un troisième fournisseur dans l'exemple de la figure 3. La figure 5 illustre la généralisation du procédé présenté dans la figure 3 afin de pouvoir le mettre en oeuvre sous la forme d'un programme contrat qui est présenté dans l' Annexe 1.

La figure 6 présente le principe du procédé généralisé introduit à la figure 5. Description détaillée Dans le système Bitcoin, un output peut être conditionnel au sens où il ne peut être consommé qu'à certaines conditions qui y sont spécifiées. Notamment, Bitcoin permet de spécifier (dans un « script ») une condition de « 2 signatures sur 3 » (CHECKMULTISIG), par exemple une condition de deux signatures à fournir parmi les signatures (i) d'un fournisseur, (ii) d'un client et (iii) d'un arbitre, ce dernier devant donner sa signature en cas de dispute entre le fournisseur et le client. 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 hash-code (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.comibitcoinibipsiblobjmasteribip0016.mediawiki (plus tard il le sera aussi dans le wiki https://en.bitcoinitjwiki/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 signature, la ou les signatures en question devant être fournies dans ledit input. La partie gauche de la Figure 1 en présente un exemple : Une transaction « Txl » offre 1000 unités de compte à un noeud receveur identifié par un code de hachage dénommé ici « Cl » (dans le 3iP- « [20-byte-ha sh-va lue du OP HASH160 0-byte-haste-'.-' ces 1000 unités ne pouvant être consommées que par un input qui comprenne un script (ii « {serialized script} » mentionné O;n1, le B1P-16) dont le code de hachage (obtenu en appliquant une fonction de hachage prédéterminée sur son contenu) est ce Cl et qui comprenne une ou des signatures qui satisfont la condition spécifiée dans ce script. Quant à la partie droite de la Figure 1, elle présente exactement le même paiement conditionnel 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és à 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 conditionnel 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 forcément consister à payer 1000 unités avec la condition représentée par 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) via le code hachage représentant le Pot dans l'output de Tx1.1, code qui doit être retrouvé lorsqu'on applique la fonction de hachage prédéterminée au contenu (du script) de l'input de Tx2.1 qui permette de retrouver cette contrainte. Autrement dit, pour que Tx2.1 soit valide, l'application de la fonction de hachage prédéterminée au contenu (du script) de l'input de Tx2.1 doit donner P1, 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, 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 20 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) est d'accord (et donc que le fournisseur et le client signent tous les deux, quel 25 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 mises (d'unités de compte) en séquestre dans un « Pot commun » (désigné par le code de hachage « Pot » mentionné plus haut), les engagements des fournisseurs envers les clients se faisant ainsi via ce pot commun 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 des fournisseurs respectifs peuvent être relativement plus faibles. A noter que typiquement, selon la communauté en question, l'arbitre précité 10 (ayant le rôle de donner la deuxième signature, dans le cas de conditions de deux signatures sur trois) peut optionnellement devoir être agréé par la communauté pour que la transaction aval puisse être validée. On a vu que « 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 15 que 1000@C1 qui seront vérifiées sur les outputs de la transaction générée elle-même. 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) sur des paramètres appelés contexte d'invocation (ou contexte). Tant 20 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. Pour toutes les mises en séquestre par les membres d'une communauté donnée, les transactions Tx2i 25 sont générées en l'application du même contrat. A noter que des « commentaires » (non exécutés) peuvent être insérés dans le contenu d'un contrat pour se l'approprier. On pourra par exemple insérer un nombre aléatoire donné dans chaque contrat utilisé dans une communauté donnée pour éviter de le confondre avec un même contrat qui serait utilisé dans une autre 30 communauté.

Lesdits contextes d'invocation qui figurent dans l'input sont signés par la communauté. Il peut s'agir d'une multi-signature (de n parmi m membres de la communauté), ou encore d'une signature d'un agent autonome exploité par la communauté en exploitant la technique connue en soi dite de « trusted computing » en matière de sécurisation d'ordinateurs. Dans un système trusted computing, 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 et gardée secrète. Cette clé privée peut servir à signer au nom d'une communauté donnée. Plus largement, les programmes qui sont exécutés dans un tel ordinateur peuvent ê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 (« remote attestation »). 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 code attendu 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. On peut ainsi exploiter de tels programmes dans le cadre des interactions décrites plus loin en relation avec la figure 2. En résumé, les transactions selon ce procédé 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 ii. Hash(Contrat + Contexte signé) : code de hachage « Pot » (comme le « [2 yte-hash-valuei » du « OF HASI-1160 [20- byte-Ilash-value EQUAL 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 signé) 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).1 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 avoir un input qui en bénéficie (comme on va le voir dans l'exemple qui suit, présenté dans la figure 3). 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 1 Ainsi, au lieu de classiquement signer avec une clé privée correspondant à une adresse (spécifiée dans un noeud émetteur d'unités de compte) ou de signer pour satisfaire un script (comme dans le cas de l'usage actuel du Pay-to-Script-Hash), on donne dans l'input de la transaction générée le contrat et le contexte d'invocation qui correspondent exactement au contrat et au contexte d'activation voulus au moment de la création de la transaction amont et qui ont permis d'obtenir le code de hachage donné dans son output. Alors, dans la mesure où la transaction générée effectue, pour un input, les paiements voulus par le contrat dans le contexte d'invocation du contrat, elle est valide. coordinateur (Root) et qu'il informe les autres fournisseurs du contexte, selon le protocole présenté à la figure 2. Le contexte ainsi communiqué aux membres successifs de la communauté comprend l'ensemble des outputs disponibles dans le pot (correspondant aux mises en séquestre précédentes, ou un sous- ensemble de celles-ci) où chaque nouveau fournisseur (ou plutôt la communauté, en son nom) pourra puiser pour payer (si besoin) son client, le restant des unités de compte des output étant remis au pot pour les prochains. Chaque fournisseur complète les paiements d'autres fournisseurs dans des cas où leurs engagements envers leurs propres clients ne sont pas entièrement couverts, ceci est décrit plus loin et illustré à la figure 4. La figure 2 est un diagramme de séquence présentant les interactions entre les différents acteurs impliqués qui représentent des noeuds d'un réseau. F., F._1 et Root sont des fournisseurs, C. et Ci sont des clients, `Blockchain' représente 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é : c'est 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. Le fournisseur F. est introduit dans la communauté par le fournisseur Fn1 qui lui communique l'adresse de Root 2. F. demande confirmation à Root, en fournissant l'identifiant de F.-1 (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 donnée, Root fournit le contexte (l'état courant de la communauté) signé : 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) attendus par les Clients respectifs 4. Fn hache le contrat et le contexte signé 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. Fn génère les contraintes et les transactions correspondantes et envoie à Root une mise-à-jour du contexte 7. Eventuellement F. 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 des 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 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. La partie droite de la figure 1 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 3 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 Tx1.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 Ci on entend les conditions 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@p5o@c1)./000@c2 » et « 950@C2 » forment ensemble une contrainte 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 » (d'abord C2 ou F2 est payé, ensuite Cl ou Fl 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 4 présente des transactions supplémentaires pour les séquences « C2 Cl » et « Cl C2 » où des inputs sont connectés à des mises en séquestre d'un troisième fournisseur (non présentées dans la figure). La figure 5 présente une manière de généraliser le procédé et faciliter ainsi la 30 mise en oeuvre d'un contrat dont un exemple (simplifié) est présenté (encapsulé entre des balises en formalisme XML) dans l'Annexe. Comparée à la figure 3, dans la figure 5 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 qu'elle fut déjà suffisamment alimentée par Tx1.1. Vu ainsi, le mécanisme 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 6 présente le principe du procédé ainsi généralisé, avec les tests sur les 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é en guise d'exemple en Annexe. Ainsi (le premier output de Tx2.1.1, après l'arrivée de F2), « Al+A2>A1r:Alr,(Al+A2) -> Air -3 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 ainsi 1000 unités de compte) sinon l'output paie Al+A2. Par ce programme présenté en Annexe, pour le contexte suivant où il y a les 3 20 fournisseurs Fl, 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<Output> availableOutputs = new LinkedList<Output>(); availableOutputs.add(new Output(1000,"F1")); 25 availableOutputs.add(new Output(950,"F2")); availableOutputs.add(new Output(900,"F3")); List<ClientRequirement> currentRequirements = new LinkedList<ClientRequirement> Q; currentRequirements.add(new ClientRequirement(1000, "Cl")); currentRequirements.add(new ClientRequirement(1000, "C2")); currentRequirements.add(new ClientRequirement(1000, "C3")); ce contrat fournit la liste de contraintes suivantes (auxquelles les transactions générées doivent se conformer) : 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))11(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))) Dans un autre mode de réalisation, on peut placer le Contexte 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 signé et du Contrat. Il faut cependant que ce mode puisse être détecté pour, lors de la validation des transactions générées, produire les 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). Ces procédés peuvent être combinés. Une autre approche pourrait être que les transactions générées soient « localement » validées par la communauté. Les transactions générées seraient alors des transactions conditionnelles classiques de type Pay-to-Script-hash exigeant 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 multisignature ou la signature d'un agent autonome, tel que décrit plus haut - doit alors être ajoutée avant de l'annoncer (broadcast) au réseau (pour 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 (via le Root) sont aptes à les reconstruire et vérifier les outputs des transactions générées. Le défaut 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 Il est important de mettre en oeuvre le protocole présenté à la figure 2, 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'être sûr qu'elles vont être respectées. L'approche la plus avantageuse est de faire vérifier par le réseau simplement 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. On a alors en plus l'assurance que F. et la communauté sont bien d'accord. On a 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 (des risques) se retrouvant dans le cas d'une mutualisation entre clients. Ces termes peuvent ainsi être librement échangés. Le procédé de l'invention consistant à enrichir l'Etat de l'Art pour permettre d'utiliser un « pot commun » de mutualisation peut s'appliquer à tous les cas de mutualisation de risques. On peut 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.

ANNEXE - Input Script & Simplified Contract <Script> <Context> <AvailableOutputs> <Output address="F1" amount="1000" /> <Output address="F2" amount="950" /> <Output address="F3" amount="900" /> </AvailableOutputs> <ClientRequirements> <ClientRequirement client="C1" amount="1000" /> <ClientRequirement client="C2" amount="1000" /> <ClientRequirement client="C3" amount="1000" /> </ClientRequirements> </ Context> <Contract> class Output { double amount; String address; String toString(){ return address-F":"+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<Constraint> dest = new LinkedList<Constraint>(); List<Constraint> otherOutputs = new LinkedList<Constraint>(); String toString() { String result = "" + amount + "@"; if (cldest != null) { result += cldest; }else{ result += "("; if (dest.size() > 1) { for (int i = 0; i < dest.size(); i++) { Constraint c = dest.get(i); if (i < dest.size() - 1) { result += "(" + c + I"; } else result += "(" + c + ")"; } } } else if (dest.size() > 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<Constraint> dest) setAmount(amount); setDest(dest); } void addToDest(Constraint c) dest.add(c); void addToOtherOutput(Constraint c) otherOutputs.add(c); } } double sum(List<Output> outputs) double result = 0; for (Output o : outputs) result += o.getAmount(); } return result; } List<Constraint> generateConstraints(List<Output> availableOutputs, List<ClientRequirement> currentRequirements) { List<Constraint> results = new LinkedList<Constraint>(); 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<Output> newLO = new LinkedList<Output>(); newL0.add(new Output(total - clr.getAmount(), "POT")); List<ClientRequirement> remainingRequirements = new LinkedList<ClientRequirement>(); remainingRequirements.addAll(currentRequirements); remainingRequirements.remove(clr); List<Constraint> dest = generateConstraints(newLO, remainingRequirements); Constraint otherC = new Constraint(total - clr.getAmount(), dest); c.addToOtherOutput(otherC); } } else c = new Constraint(total, clr.getClient()); results.add(c); } return results; } </Contract> </Script>

Claims

REVENDICATIONS1. 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 à 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 de hachage calculé sur tout ou partie du contenu d'une transaction aval et une valeur de hachage contenue 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.
2. Système selon la revendication 1, dans lequel les contraintes de répartition sont établies dans la transaction amont affectée à la transaction aval.
3. Système selon la revendication 1, dans lequel les contraintes de répartition sont établies dans la transaction aval.
4. Système selon la revendication 3, dans lequel les moyens d'établissement de contraintes de répartition comprennent la mise en oeuvre d'instructions formant contrat sur des paramètres formant contexte d'invocation.
5. Système selon la revendication 4, 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.
6. Système selon la revendication 4 ou 5, 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.
7. Système selon la revendication 5 ou 6, lequel comprend des moyens pour 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.
8. Système selon l'une des revendications 4 à 7, lequel comprend des moyens de sécurisation des transactions par signature des contextes d'invocation respectivement associés auxdites transactions amont, à l'aide d'au moins une clé de contextes.
9. Système selon l'une des revendications 1 à 8, lequel comprend des moyens de validation d'une transaction aval par signature à l'aide d'au moins une clé de transaction.
10. Système selon la revendication 9, 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.
11. Système selon l'une des revendications 9 et 10, 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.