FR3018379A1 - Systeme et procedes transactionnels a architecture repartie fondes sur des transactions de transfert d'unites de compte entre adresses - Google Patents

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 directement ou indirectement à 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 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 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.

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é. Etat de l'Art Dans un système réparti de crypto-monnaie tel que le système Bitcoin (https://bitcoin.orgibitcoin.pdf), des transactions permettent 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://www.youtube.comiwatch?v=FXU65XsLiFk) à 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 15 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 20 (« 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 25 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 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 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. La présente invention vise à 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. Plus précisément, 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é). Ainsi 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 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 : - 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 15 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 20 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 25 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 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 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 10 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. - le système comprend également des moyens de validation de transactions au niveau réseau (blockchain), la validation des transactions aval s'effectuant par 15 vérification de leurs signatures. L'invention vise également tous procédés destinés à être exécutés dans un tel système. Avantageusement, le procédé de l'invention permet que les membres de la communauté (tels que des mutualistes), ou que les bénéficiaires potentiels de 20 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 25 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. 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 20 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 le procédé de l'invention sur un exemple. La figure 2 est un diagramme de séquence décrivant les interactions entre les 25 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 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 dont un exemple simplifié est présenté dans l' Annexe 1. La figure 5 présente le principe du procédé généralisé introduit à la figure 4.

Description détaillée 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, httwiigithub.comibitcoin/bip_s/blotilmaster/bip0016.mediawiki (plus tard il le sera aussi dans le wiki https://en.bitcoinitiwikifrransactions#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 1 en présente un exemple : Une transaction « Tx1 » fournit 1000 unités de compte à un noeud receveur 20 identifié par un code de age dénommé ici « Cl » ces 1000 unités ne pouvant être consommées que par un input qui comprenne un script (I dont le code de hachage (obtenu en appliquant une fonction de hachage prédéterminée 25 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 1, 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 3), 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 (F,) 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 C,) le client (correspondant à ce C,) 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 Ci 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 15 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 1 (ainsi que dans les suivantes), le code de vérification « Pot » est 20 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 25 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 2. 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 ii. Hash(Contrat + Contexte) : code de hachage « Pot » ASH1,60 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 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 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 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 2 est un diagramme de séquence présentant les interactions entre les différents acteurs impliqués. F., F.4 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.4 qui lui communique l'adresse de Root (ou une nouvelle aide va être demandée par un fournisseur existant) 2. Fn 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, 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 F. 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 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 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@C1)&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 4 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é 30 entre des balises en formalisme XML) dans l'Annexe 1. Comparée à la figure 3, dans la figure 4 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 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 5 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é 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-FA2>A1r: A1r,(A1A-A2) Alr -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 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 20 les 3 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>0; 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))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))) Quant au contexte (simplifié) présenté dans l'Annexe 2, contexte fourni à F5, il comprend les outputs des fournisseurs Fl à 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, "Fl"); 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 c1= 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<Output> availableOutputs = new LinkedList<Output>(); Pledge p1= new Pledge(); pl.addClientRequirement(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); availableOutputs.add(fl); availableOutputs.add(f2); availableOutputs.add(f3); availableOutputs.add(f4); List<Constraint> ic = generateConstraintsAutoSelectOutputs(f5, availableOutputs, c5,2000,2); for (Constraint c :1c) { 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))11(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 10 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 15 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 20 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 25 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 2, car il s'agit bien d'un contrat passé entre F. et la communauté (représentée par Root) et ce protocole permet à Fn 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 Dans un article « SNARKs for C: Verifying Program Executions Succinctly and in Zero Knowledge » (http_ilcprintiacnorg/2013/E379) Eli Ben-Sasson et al. décrivent leurs travaux sur les preuves, à divulgation nulle de connaissance, d'exécution correcte de programmes écrits en C. Selon ces résultats, on peut 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 correcte (le programme retournant alors par exemple la valeur « vrai »). A noter aussi que comme le système en question est à divulgation nulle de connaissance, l'exécution du programme en question peut aussi se faire sur des données privées fournies en entrée, qui ne seront pas divulguées. Ces travaux se fondent au départ sur les travaux de Shafi Goldwasser, Silvio Micali, et Charles Rackoff qui datent de 1985 (http_://en.wikipedia.org/wikillP %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 » httly,//eccc.hpi-web.deireport/20 13/1651downloadn. Un mode de réalisation du procédé de la présente invention est de spécifier 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, 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 <Script> <Context> <AvailableOutputs> <Output address="F1" amount="1000" client="Cl" /> <Output address="F2" amount="950" client="C2" /> <Output address="F3" amount="900" client="C3" /> </AvailableOutputs> <ClientRequirements> <ClientRequirement client="C1" amount="1000" /> <ClientRequirement client="C2" amount="1000" /> <ClientRequirement client="C3" amount="1000" /> </ClientRequirements> </ Context> <Contract> class Output f 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 toStringQ{ 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>Q; 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 fi < dest.size() - 1) { result += "(" + c + ") I I"; } else { result += "(" + c + ")"; } } } else if (dest.size() > 0) { result += dest.get(0); result "y; } 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.getAmountQ) c = new Constraint(c1r.getAmount(), clr.getClientQ); if (total - clr.getAmount() > 0) { List<Output> newLO = new LinkedList<Output>(); newLO.add(new Output(total - clr.getAmount(), "POT")); List<ClientRequirement> remainingRequirements = new LinkedList<ClientRequirement> Q; remainingRequirements.addAll(currentRequirements); remainingRequirementssemove(c1r); 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> ANNEXE 2 - Contrat simplifié pour démontrer la génération restreinte de contraintes <Script> <Context> <AvailableOutputs> <Output address="F1" amount=" 1000" client="C1" /> <Output address="F2" amount=" 950" client ="C2" /> <Output address="F3" amount=" 900" client ="C3" /> <Output address="F4" amount=" 850" client ="C4" /> </AvailableOutputs> <ClientRequirements> <ClientRequirement client="C1" amount="1000" /> <ClientRequirement client="C2" amount="1000" /> <ClientRequirement client="C3" amount="1000" /> <ClientRequirement client="C4" amount="1000" /> </ClientRequirements> <GenerateContraints> <Output address="F5" amount=' '800" > <ClientRequirement client="C5" amount="1000" /> <Params sum="2000" n="2" /> </GenerateContraints> </ Context > <Contract> class Pledge { List<Output> outputs; List<ClientRequirement> clientRequirements; Pledge(){ outputs = new LinkedList<Output>(); clientRequirements = new LinkedList<ClientRequirement>0; ; } public void addPledge(Pledge p){ for(Output o:p.getOutputs()){ addOutput(o); } for(ClientRequirement cl:p.getClientRequirements()){ addClientRequirement(c1); } 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<Output> outputs; List<ClientRequirement> clientRequirements; } 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<Constraint> dest = new LinkedList<Constraint>(); List<Constraint> otherOutputs = new LinkedList<Constraint>Q; 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 I"; } else { result +=- "(" + c + ")"; } } 28 } 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); } } public class SuretyBond 1** * @param args the command line arguments static double sum(List<Output> outputs) { double result = 0; 30 35 for (Output o : outputs) { result += o.getAmount(); return result; } static List<List<Output» getAvailableOutputCombination(List<Output> outputs) List<List<Output» result = new LinkedList<List<Output»(); for (int i = outputs.size(); i >= 1; { 10 result.addAll(combination0f(outputs, i)); } return result; 15 static List<List<Output» combinationOf(List<Output> outputs, int taken) { List<List<Output» result = null; if (taken == 1) { result = new LinkedList<List<Output»Q; for (Output o : outputs) { 20 List<Output> os = new LinkedList<Output>Q; os.add(o); result.add(os); } else { 25 result = new LinkedList<List<Output»(); List<Output> noutputs = new LinkedList<Output>(); noutputs.addAll(outputs); int k = taken - 1; for (Output ref : outputs) { 30 noutputs.remove(ref); if (noutputs.size() >= k) { List<List<Output» outt1 = combinationOf(noutputs, k); for (List<Output> outl : outt1) { outl.add(0, ref); 35 result.add(outl); } } } return result; } static Pledge getCombinedPledges(List<Output> outputs) { Pledge p = new Pledge(); for (Output o : outputs) Pledge ox = o.getExistingPledge(); 10 if (ox != null) p.addPledge(ox); } return p; 15 } static Constraint generateConstraints( Output pot, Pledge p, List<Output> usedOutputs, 20 List<ClientRequirement> paidRequirements) { List<Output> availableOutputs = new LinkedList<Output>(); availableOutputs.add(pot); List<ClientRequirement> remainingRequirements = new LinkedList<ClientRequirement>O; 25 for (ClientRequirement cr : p.getClientRequirementsO) { if (!paidRequirements.contains(cr)) f remainingRequirements.add(cr); } } 30 double total = sum(availableOutputs); List<Constraint> dest = generateConstraints(availableOutputs, remainingRequirements); Constraint otherC = new Constraint(total, dest); return otherC; } 35 static List<Constraint> generateConstraintsAutoSelectOutputs( Output refOutput, List<Output> availableOutputs, ClientRequirement currentRequirement, double sumAmount, int helps) { List<Output> selectedOutputs = new LinkedList<Output>(); double amt = refOutput.getAmountQ; int i = availableOutputs.sizeQ - 1; while ((amt > sumAmount)&&(selectedOutputs.size()>=helps)) && (i >= 0)) { selectedOutputs.add(availableOutputs.get(i)); amt += availableOutputs.get(i).getAmount(); i--; } return generateConstraints(refOutput, selectedOutputs, currentRequirement); } static List<Constraint> generateConstraints( Output refOutput, List<Output> selectedOutputs, ClientRequirement currentRequirement) List<Constraint> results = new LinkedList<Constraint>Q; List<List<Output» lavo = getAvailableOutputCombination(selectedOutputs); lavo.add(new LinkedList<Output>0); //when there's no other output left for (List<Output> availableOutputs : lavo) { availableOutputs.add(refOutput); double total = sum(availableOutputs); Constraint c = null; if (total > currentRequirement.getAmount()) { c = new Constraint(currentRequirement.getAmount(), currentRequirement.getClient()); if (total - currentRequirement.getAmount() > 0) { Pledge combined = getCombinedPledges(availableOutputs); List<Output> usedOutputs = new LinkedList<Output>(); List<ClientRequirement> paidRequirements = new LinkedList<ClientRequirement>Q; paidRequirements.add(currentRequirement); usedOutputs.addAll(availableOutputs); Output pot = new Output(total - currentRequirement.getAmount(), "POT"); Constraint otherC = generateConstraints(pot, combined, usedOutputs, paidRequirements); c.addToOtherOutput(otherC); } } else { c = new Constraint(total, currentRequirement.getClientO); } results.add(c); } return results; } static List<Constraint> generateConstraints(List<Output> availableOutputs, List<ClientRequirement> currentRequirements) { List<Constraint> results = new LinkedList<Constraint>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<Output> newLO = new LinkedList<Output>(); newLO.add(new Output(total - clr.getAmount(), "POT")); List<ClientRequirement> remainingRequirements = new LinkedList<ClientRequirement>(); remainingRequirements.addAll(currentRequirements); remainingRequirements.remove(c1r); 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; } 1 </Contract> </Script>

Claims (12)

1. 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 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 10 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 15 vérification constitué par un code de hachage d'un script contenu dans la 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, ces moyens étant aptes à mettre en 20 oeuvre des instructions formant contrat sur des paramètres formant contexte d'invocation.
2. 2. Système selon la revendication 1, dans lequel les contraintes d'attribution sont établies dans la transaction amont affectée à la transaction 25 aval.
3. 3. Système selon la revendication 1, dans lequel les contraintes d'attribution sont établies dans la transaction aval.
4. 4. Système selon l'une des revendications 1 à 3, 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.
5. 5. Système selon l'une des revendications 1 à 4, 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.
6. 6. Système selon l'une des revendications 1 à 5, 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.
7. 7. Système selon l'une des revendications 1 à 6, lequel comprend des moyens de validation des transactions aptes à vérifier que les contraintes d'attribution sont satisfaites par les outputs des transactions aval.
8. 8. Système selon la revendication 7, dans lequel les moyens de validation 20 comprennent la prise en compte d'une signature des contextes d'invocation respectivement associés auxdites transactions amont, à l'aide d'au moins une clé de contextes.
9. 9. Système selon la revendication 7, dans lequel les moyens de validation 25 comprennent une signature des transactions à l'aide d'au moins une clé de transaction.
10. 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. 11. Système selon la revendication 7, dans lequel les moyens de validation 5 sont aptes à engendrer un code calculé constituant une preuve d'exécution correcte des instructions formant contrat.
12. 12. Système selon l'une des revendications 1 à 11, lequel comprend également des moyens de validation de transactions au niveau réseau 10 (blockchain), la validation des transactions aval s'effectuant par vérification de leurs signatures.