WO2017122187A2 - Procédés et systèmes mis en œuvre dans une architecture en réseau de nœuds susceptibles de réaliser des transactions basées sur messages - Google Patents

Procédés et systèmes mis en œuvre dans une architecture en réseau de nœuds susceptibles de réaliser des transactions basées sur messages Download PDF

Info

Publication number
WO2017122187A2
WO2017122187A2 PCT/IB2017/050228 IB2017050228W WO2017122187A2 WO 2017122187 A2 WO2017122187 A2 WO 2017122187A2 IB 2017050228 W IB2017050228 W IB 2017050228W WO 2017122187 A2 WO2017122187 A2 WO 2017122187A2
Authority
WO
WIPO (PCT)
Prior art keywords
node
nodes
message
program
soc
Prior art date
Application number
PCT/IB2017/050228
Other languages
English (en)
Other versions
WO2017122187A3 (fr
Inventor
Enrico Maim
Original Assignee
Enrico Maim
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from PCT/IB2016/050440 external-priority patent/WO2016120826A2/fr
Priority to EP17705166.1A priority Critical patent/EP3403213A2/fr
Priority to US16/068,497 priority patent/US11159318B2/en
Priority to CN201780006951.1A priority patent/CN109643350A/zh
Application filed by Enrico Maim filed Critical Enrico Maim
Publication of WO2017122187A2 publication Critical patent/WO2017122187A2/fr
Publication of WO2017122187A3 publication Critical patent/WO2017122187A3/fr
Priority to CN201880016861.5A priority patent/CN110392888A/zh
Priority to PCT/IB2018/050247 priority patent/WO2018131004A2/fr
Priority to US16/477,631 priority patent/US11587070B2/en
Priority to EP18705491.1A priority patent/EP3568794B1/fr
Priority to US17/509,607 priority patent/US20240064014A9/en
Priority to US18/170,986 priority patent/US12026700B2/en
Priority to US18/463,863 priority patent/US20240048376A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/085—Payment architectures involving remote charge determination or related payment systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C1/00—Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2153—Using hardware token as a secondary aspect

Definitions

  • the present invention relates to methods and systems useful in a network architecture, generally decentralized, nodes capable of performing transactions with each other on the basis of messages.
  • PGP's decentralized trust model (Web-of-Trust, 1992) is already known to allow peers to act as initiators and validators of public keys and proposing a metric for decentralized validation of a digital identity, which focused on the email addresses of the peers in question, since then other approaches have been proposed to establish identity without the CA (such as by Carl Ellison in 1996).
  • the invention aims first of all to allow a decentralized identification both simpler and wider use, and directly meeting the needs for implementation of executables commitments, type "smart contracts” [https: / /en.wikipedia.org/wiki/Smart contract], now implemented on consensus protocols, especially in a "permissionless" environment where anyone can join and leave dynamically, and where there is no prior knowledge of consensus nodes, relying generally on computer puzzles [Dwork & Naor, 1992: http://www.hashcash.org/papers/pyp.pdf; Back, 2002 : http://www.hashcash.org/papers/hashcash.pdf] to counter the "sybil attacks" and with the assumption that a majority of computing power is held by honest participants [Nakamoto, 2008: https : //bitcoin.org/bitcoin.pdf]
  • the state of the art in smart contracts is mainly presented by the Ethereum system
  • the invention aims more precisely at such an implementation and moreover on hardware that is within the reach of a large number of manufacturers, in order to achieve decentralization even at the level of the manufacturers themselves, and also aims to to propose decentralized identification mechanisms that make it possible to mitigate sybil attacks (when an adversary generates any number of new nodes that he controls in the network).
  • the invention aims not only benefits of speed (the consensus by blockchain is slow) and cost (transaction cost), but even qualitative advantages, especially the article "Why Many Smart Contract Use Cases Are Simply Impossible "[http://www.coindesk.com/three-smart-contract-misconceptions/] has limitations Ethereum in relation to interactions with the outside world (see in particular under "Contacting External Services”:
  • the smart contract waits until the time, retrieves the weather report from an external service and behaves appropriately based on the data received.
  • the invention compensates for this lack by first allowing access by a "Wallet Node” WN (see WO2016120826A2), securely, to any HTTPS website directly (thus eliminating the need for a smart contract "oracle "], by exploiting the end-to-end TLS protocol
  • This access can be implemented on a plurality of nodes" WN clones "able to redundantly access to a data source.
  • the risk of modification of the response by the source between two requests, the WN clones are able to coordinate to treat, according to pre-determined rules (according to configuration parameters), cases of different responses to the same requests (according to approaches such as taking the majority, the average, etc.] - the essential advantage brought compared to the Ethereum nodes being the access to the network, thus avoiding the intermediation by a trusted third party.
  • the aforementioned article then evokes the need to send a message to the network.
  • Ethereum smart contracts are understood as “cryptography” boxes “that contain value and only unlock it if certain conditions are met” [sentence extracted from Ethereum White Paper already cited], whereas according to the system of the invention, smart contracts are implemented as "Wallet Program” (WP) executable contracts between nodes (WN) of the Wallet Nodes network, and having the following characteristics:
  • a WM being likely to include one or more transfer transactions "values" of the transmitter WN to the receiver WN;
  • the WN system comprising means in each WN to prevent a double-spend of these values
  • a WN advantageously comprising means for reserving the consumption of these values to one or more authorized WP programs.
  • the WN nodes are comparable to the Ethereum nodes: the address of an Ethereum node, determined from the public key of a key pair, is analogous to the address of a WN which is determined from the public key of the WN in question.
  • a smart contract is an executable code "Wallet Program” (identified by its hash “#WP”], compilable code from a language like Solidity [http://solidity.readthedocs.io/en/develop /introduction-to-smart-contracts.html (incorporated here by reference]] but with adaptations allowing the WN to have access to the network, that the transactions generated by a WN can transfer values in any units (and not only ethers], etc.
  • WN While in Ethereum a contract execution is performed on a large number of nodes (the miners) which validate it, in the case of WN, when a contract (WP) is executed, the node on which this execution was caused is the only one that executes it and has its own persistent state variables.
  • WP contract
  • WNs represent a more general model in that the persistent variables of a node are of general use, they do not represent only a balance in ether and they are not necessarily contract-related variables for all the nodes that execute it (they are not necessarily the shared variables constituting the key / value store of an Ethereum contract [see Ethereum White Paper already cited]].
  • the WNs guarantee the integrity of execution by hardware constraints and, advantageously, by redundancy (for even greater security), said node then being a virtual node materialized by a plurality of mirror nodes memorizing, manipulating and maintaining synchronized the variables specific to said virtual node.
  • the invention also aims to enable smarts contracts (WP) to be executed on WNs using the Bitcoin blockchain (or other blockchain), by generating and inserting in the blockchain only some of the transactions, on instruction from the WNs. concerned, which offers the triple advantage of having the power of smart contracts on Bitcoin, to avoid the slowness of its consensus protocol and not to pay transaction fees (for transactions that are not inserted in the blockchain)
  • the "Bitcoin Off-Chain Transactions" section describes a method for consuming units of value (such as bitcoins or ethers) by different types of WP programs, thus giving a Bitcoin-based system the power of smart contracts of a system such as Ethereum.
  • the Bitcoin protocol requires waiting for block-by-block transaction confirmations that, depending on the approach adopted, take today from a few seconds to about ten minutes each and involve limited transaction volumes. Ethereum and the process as described in FR 3,018,377 A1 in the name of the applicant, allow the decentralized execution of executable contracts.
  • the hardware proposed according to the invention allows a treatment without disclosure, property (called “confidentiality”) offered in particular by security environments such as new Intel processors for their environments (enclaves) secure "SGX" , and there is some research on homomorphic encryption for cloud processing that offers guarantees of the integrity of execution and non-disclosure of the processed data and even of the executed code.
  • the homomorphic encryption technology is in research phase and not yet operational except in limited or special cases.
  • SoC system-on-chip
  • WN wallet Node
  • IoT Internet of Things
  • the only possible execution of a WN is to react to an incoming message, verifying its integrity and then executing the "Wallet Program” executable code corresponding to the hash specified in this message, with reference to this PCT request, in the present text, by “message” we mean “Wallet Message” except when it is explicit that this is not the case.
  • a method for establishing connection weights between nodes of a network implemented by communicating computing processing units is proposed at each node. associated with a public key and a private key, a given node being able to communicate its public key to another node, thus forming a so-called real connection ("IRL-connected") between the two nodes, and each node being also capable of communicate to another node a public key received from another node again, thus forming an indirect connection between the other node and the other node, a node being able to have a specific connection weight vis-à-vis screw to another node with which it has a real or indirect connection, the method comprising, for determining the connection weight of a second node vis-à-vis a first node, calculating a determined combination of weighting factors (influence, proximity) of third nodes that are IRL-connected to the second node.
  • connection weight of the second node influences the weighting factors of the third nodes, and furthermore comprising an update of the values of the weighting factors of the third nodes after calculation of the connection weight of the second node.
  • a first processing unit implementing the first node making available by proximity read a machine-readable code encoding a random data (nonce), at another processing unit implementing the other node, read the machine-readable code, extracting said random data and calculating a hash of said random data,
  • connection weights with the first node, and wherein the determination of the connection weight of a given second node vis-à-vis the first node is also based on the weights of said second second connections nodes vis-à-vis the first node
  • a method for determining the influence of a first node in a network of nodes implemented by communicating computing processing units comprising determining an influence factor of a given node based on the number of second nodes having an actual connection with said given node and connection weight values determined by the method of the in which a plurality of second nodes have connection weights with the first node, and wherein determining the weight of connection of a second given node vis-à-vis the first node is also based on the weight of connections of said other second nodes vis-à-vis the first node for the different second nodes
  • connection weight of a second node vis-à-vis the first node is also determined on the basis of values of the respective influence factors of the third nodes having a real connection with said second node.
  • connection weight and influence factor are determined iteratively until their convergence into values that no longer vary significantly.
  • a method for establishing so-called quasi-real connections between nodes of a network implemented by communicating computing processing units, each node being associated with a public key and a private key, a given node being capable of communicating its public key to another node, thereby forming a so-called real connection ("IRL-connected") between the two nodes, and each node also being able to communicate to another node a public key received from another node again, thus forming an indirect connection between the other node and the other node, each node being able to have a specific connection weight vis-à-vis another node with which it has a real connection or indirect, including the following steps:
  • the second node in response to receiving the random code in redundancy, generate a signature of the random code using the private key of the second node and return to the intermediate nodes said signature and the public key of the second node , encrypted using the public keys of the intermediate nodes, respectively,
  • the first and second nodes can then exchange encrypted information with a security linked to the connection weights of the intermediate nodes.
  • the random code is generated jointly by a set of nodes formed by the first node and by the intermediate nodes, by the implementation of the following steps:
  • said distinct communication channel is based on a social network, and comprising a step of publication by the second node on said social network of a signature of said random code and its public key.
  • the method further comprises, in response to the success of the verification step of the signature of the random code received from the second node, a step of assigning a connection weight of the second node vis-à-vis the first node .
  • the method according to the first aspect is implemented in a network comprising nodes with quasi-real connections established according to the third aspect, and the quasi-real connections are considered as real connections in the sense of the process, with a weight taking into account the quasi-real character of the connection.
  • a method for securing the operation of a network of nodes capable of executing programs (WP) in response to the reception is provided.
  • WM messages
  • the nodes being capable of being interconnected according to different connection weights obtained in particular by the method according to the first aspect or by the method according to the third aspect where, in response to the success of the step of verification of the signature of the random code received from the second node, there is provided a step of assigning a connection weight of the second node vis-à-vis the first node, comprising the following steps:
  • connection weight values assigning to each node at least one countersignatory node having a connection weight above a threshold vis-à-vis it,
  • each node maintaining a list of nodes countersigning nodes capable of receiving messages (WM) from the node in question, each node and its countersigning nodes forming a set of mirror nodes,
  • WM messages
  • the messages are sent by the sending node as well as by the only countersigning nodes of the sending node which are also countersigning of the destination node.
  • a message sent from a first node to a second node is validated by the second node only if the respective sets of mirror nodes of the first and second nodes have an intersection whose number of elements is greater than a certain threshold and if the second node has received the same message (in redundancy) from at least a given fraction of said mirror nodes belonging to this intersection.
  • a node in a method according to the first aspect implemented in a network comprising mirror nodes according to the fifth aspect, a node is considered to be countersigning a given node only if the connection weight of the node in question is at least equal to the small connection weights of the nodes having actual connections with the given node.
  • a system for securing the operation of a network of nodes capable of executing programs (WP) in response to the reception of messages [WM], the nodes being able to be linked together according to weights different connection, able to:
  • connection weight values assigning to each node at least one countersignatory node having a connection weight above a threshold vis-à-vis it,
  • each node maintaining a list of nodes countersigning nodes capable of receiving messages from the node in question, each node and its countersigning nodes forming a set of mirror nodes,
  • a destination node of a message only validates it if the respective sets of mirror nodes of the sending and receiving nodes have an intersection whose number of elements is greater than a given threshold and if the receiving node has received this same message (in redundancy) from at least a given fraction of said mirror nodes belonging to this intersection.
  • a system for securing the operation of a network of nodes constituted by systems on a chip capable of executing programs (WP) in response to the reception of messages (WM), characterized in that it comprises in combination the two following architectures:
  • an architecture for determining countersigning nodes, for duplicating messages from / to the countersigning nodes, and for determining the identical nature of the messages received.
  • a system for the secure execution of programs in an architecture comprising a set of equipment connected in a network, characterized in that it comprises in at least one device, a system-on-chip (SoC). in which is stored in a manner inaccessible otherwise than by the SoC a private key SoC, or the SoC is able to dynamically regenerate this private key (PUF technology),
  • SoC system-on-chip
  • SoC SoC able to communicate with other equipment only by messages and being able to execute programs only in response to receiving messages
  • a SoC being able to store at least one program to be executed after encryption by the SoC and to generate a hash of the or each program making it possible to retrieve the encrypted program
  • the equipment being further able to send the SoC a message containing data input (data) for a certain program to execute, and the hash of said program (# P2), the SoC being able, in response to such a message, securely, (i) access the encrypted program to run to from the hash (# P2) of the program received in the message, (ii] decipher on the fly the instructions of the program, and (iii) execute on the fly the decrypted instructions.
  • the SoC before sending a message by the SoC, the SoC inserts the hash (# P1) of the program running in the message to be sent, as well as the signature of this hash by means of said secret private key of the SoC. * before sending a message by the SoC, the SoC inserts the hash (# P1) of the running program into the body of the message to be sent that the SoC signs by means of the secret private key of the SoC.
  • the SoC includes a cryptographic memory management unit (CMMU) in which is stored - or able to dynamically regenerate (PUF technology)
  • CMMU cryptographic memory management unit
  • said decryption for execution on the fly by at least one processor unit included in the
  • the CMMU performs encryption and instruction block storage by instruction block and provides the processor with only one instruction block decrypted at a time for on-the-fly execution. * before a message is sent by the SoC, the CMMU inserts the hash (# P1) of the program being executed in the message to be sent, as well as the signature of this hash by the CMMU by means of said key private secret of the SoC.
  • a SoC-on-chip system is proposed intended to form a Wallet Node (WN) node of a network, comprising a unit cryptographic memory management system with encryption (CMMU) adapted to ensure a blind execution (blind) of programs by at least one SoC processor, wherein:
  • the CMMU is able to memorize at least one program to be executed after encryption by the CMMU and to generate a hash of the or each program making it possible to retrieve the encrypted program,
  • the interactions between the system-on-chip and other nodes of the network are carried out exclusively by messages and the messages are received / emitted by the CMMU unit exclusively, ⁇ the messages include the identification of a certain program to execute, identified by his hash,
  • the CMMU in response to receiving a message, the CMMU (i) accesses the encrypted program to be executed from the hash of the program received in the message (in particular via a PHT table), (ii) decrypts the instructions of the program , and (iii) transmits to the processor to execute decrypted instructions on said received data.
  • the or at least one processor is able to access, and manipulate (creation, update, deletion), via the CMMU, persistent state variables (PSV) associated with a given program, which are also encrypted and stored in memory by the CMMU and decrypted on the fly.
  • PSV persistent state variables
  • a message may contain one or more unit of account (UA) transfer transactions from a sending node to a receiving node, the units of account received by a receiving node being able to be transferred again by a transaction contained in a message sent by said receiving node.
  • U unit of account
  • the method includes a memory space for units of account (tags) received by transactions.
  • the method is capable of combining units of account of different tags in the same transaction to be transmitted, able to be combined and transferred between SoCs.
  • the CMMU comprises means neutralizing a tag that feeds an emitted transaction, so that the UAs thus consumed can not be consumed by another transaction.
  • the CMMU unit comprises means for controlling the use of the tags by the different programs, so that only an authorized program can feed a transaction to be generated from a given tag.
  • a program can alternatively be triggered on the flow of a timeout for a given program and the CMMU unit is also able, on occurrence of a timeout associated with the hash of a program (i) to access in memory the program encrypted to from this hash, (ii) decrypt the instructions of the program, and (iii) transmit to the processor for execution the decrypted instructions.
  • the CMMU performs said encryption and instruction block storage by instruction block and provides said processor with a single block decrypted at a time, for on-the-fly execution.
  • the CMMU unit inserts the hash (# P1) of the running program in the message to be sent, as well as the signature of this hash by the CMMU by means of said secret private key.
  • the CMMU unit inserts the hash (# P1) of the running program in the body of the message to be sent that it signs by means of said secret private key.
  • Certain [WM] messages constitute tag transfer messages stored in systems with memory space for units of account (tags) received by transactions, and validation of a tag transfer message at the level of a destination node is realized only if it exists in intersection between the set of mirror nodes of the destination node and the set of mirror nodes of each of the upstream nodes from which such a tag was initially transferred a number of nodes greater than a given threshold.
  • a method for guaranteeing the commitments of a system-on-a-chip (WN) in a systems-on-a-chip (WN) architecture able to transfer between them units of account via messages (WM). , for the case such a system-on-chip would become non-responsive, comprising the following steps:
  • a transactional system with a distributed peer-to-peer architecture implementing transactions for transferring units of account between unit sending nodes and unit receiving nodes, each transaction having as input a number of units. input referring to an output of a previous transaction (or several inputs each referring to an output of a previous transaction) and itself having at least one new output specifying a number of units of account and a receiving node, each transaction that can be validated by inserting, in a block chain stored in a distributed manner between the nodes, a signature of the transaction, characterized in that at least some of the transactions are performed by nodes capable of providing a condition of said transactions, in that it includes means for processing a set of transactions satisfying the blindness condition of in order to simplify this set according to the quantities of units of account and the addresses of the sending nodes and the receiving nodes involved in these transactions, to generate a reduced set of transactions, and to generate and store in the blockchain only those transaction signatures of the reduced transaction set.
  • a transactional system with a distributed peer-to-peer architecture implementing transactions for transferring units of account between unit sending nodes and unit receiving nodes, each transaction having as input a number of units. input referring to an output of a previous transaction (or several inputs each referring to an output of a previous transaction) and itself having at least one new output specifying a number of units of account and a receiving node, each transaction that can be validated by inserting, in a block chain stored in a distributed manner between the nodes, a signature of the transaction, characterized in that at least some of the transactions are performed by nodes capable of providing a condition of said transactions, in that it includes means for processing a set of transactions satisfying the blindness condition of in order to simplify this set according to the quantities of units of account and the addresses of the sending nodes and the receiving nodes involved in these transactions, to generate a reduced set of transactions, and to generate and store in the blockchain only certain signatures of said reduced set and that on instruction of the concerned no
  • a method for carrying out a transaction between nodes of a network associated with users and capable of transferring between them units of accounts and capable of communicating with each other by messages, each message designating a WP program to be executed in the receiving node of this message, and the users being able to broadcast offers elements comprising one or more bid criteria and likely to give rise to transactions on the network, the method comprising the following steps:
  • the quasi-real connections are considered as real connections in the sense of the process, with a weight taking into account the quasi-real nature of the connection.
  • FIGS. 1a, 1b and 2a, 2b show methods for calculating the connection weight of the nodes of the user's environment.
  • Figures 3a to 3d schematically show messages sent between mirror nodes.
  • Figure 4 illustrates a use of a persistent state variable (tag) by two WP programs on a Wallet Node.
  • FIGS 5a and 5b schematically show tag transfer transactions.
  • Figure 6 shows schematically the behavior of the mirror nodes in the case of a message chain transmitting tag transfer transactions.
  • Figure 7 illustrates a message with a specification of all hashes of valid executable codes.
  • Figure 8 illustrates the propagation of acknowledgments between Wallet Nodes.
  • Figure 9 shows schematically an example of payments made between Wallet Nodes by abstract Bitcoin transactions.
  • Figures 10 to 15 show schematically the actual Bitcoin transactions corresponding to the abstract transactions in Figure 9.
  • Figure 16 schematically shows another example of payments made between Wallet
  • FIGs 17 to 19 show schematically the actual Bitcoin transactions corresponding to the abstract transactions in Figure 16.
  • Figure 20 shows schematically the process to guarantee the commitments of a Wallet Node that would become non-responsive.
  • Figure 21 schematically shows a SoC including a CMMU receiving an executable program.
  • Figure 22 schematically shows a SoC comprising a CMMU receiving a message comprising input data for a program to be executed.
  • Figure 23 shows the general architecture of a Wallet Node.
  • the term “user” may designate, depending on the context, a particular node of a network, each node having a pair of cryptographic keys. Moreover, the term “user”, except when speaking explicitly of a human user, may designate a device or a program associated with it. For example, an indication of the type "user A sends user B such data” will mean that "the device or program associated with user A sends such data to the device or program associated with user B". Finally, vis-à-vis a device or given program, the term “user” may in some cases designate another device or program.
  • the nodes are "Wallet Nodes” WN respectively associated with users U and able to communicate with each other by "Wallet Messages” WM to materialize different types transactions or commitments (typically of smart contracts type) affecting the U users associated with the WNs
  • These WNs constitute the nodes of a graph with links between the WN constituting the edges of the graph.
  • the WNs can be of different types (soft or hard) and the links between WN can be noted or weighted
  • a WM message can only be sent by an originating WN to a destination WN if the link between the two WNs considered satisfies a certain notation and / or weighting.
  • FIG 23 shows the architecture of a WN.
  • the "quasi-WM” messages are messages (in reception) which are not issued by a WN but whose format is the same, in that, like the WMs, they contain the hash of the WP to execute on reception of the message
  • his "Quasi-WM” message includes the hash of the generation WP of this transaction (this information is automatically added by the terminal.]
  • Another example is that when a WP subcontracts "non-light” processing (see below) to a remote computer, the result is returned to it as a "Quasi” message.
  • -WM "featuring the hash of the WP that subcontracted to him.
  • this architecture provides that processor processing (PROCESSOR) is light and that WM and Non-WM message transmissions are non-blocking:
  • Non-blocking A response from a WN to a WM is another WM that refers to the first one. It is not blocking either the execution of a WP waiting for the response of "User” or "Network” to a "Non-WM" message sent- "User” being the terminal of the user (such as 'a computer' and 'Network' representing a remote device (such as a computer) - these messages being asynchronous calls whose return (callback) is transformed into a 'quasi-WM' message.
  • HTTPS HyperText Transfer Protocol
  • TLS handshakes can be implemented using a library such as "mbed TLS” [https://tls.mbed.org/] whose modules are loosely coupled and allow to use parts without having to include the total library] and perform all cryptographic operations, leaving the terminal to which it is coupled the role of input / output interface supporting low layers (TCP), to ensure the integrity of said data end-to-end .
  • non-light processing which is subcontracted by non-WM messages
  • the HTTPS messages considered “blocking” are subcontracted to a computer able to return a certificate of authenticity and integrity in practice (enclave SGX).
  • Emitted HTTPS messages that prove to be blocking are canceled and automatically outsourced.
  • FIG 23 shows that the WM are able to transfer values (tags), in the form of transactions (tx) which is described later in the sections “Tags”, “CMMU - Crypto Memory Management Unit” and “Improvements to CCC ".
  • connection weight a connection weight that is based on identifications between users of WN by traversing different paths of the graph, then different methods using such connection weights.
  • a first user and his terminal, for example a mobile phone
  • his terminal for example a mobile phone
  • shows him a Nonce a random number used once
  • a QR code generated in his terminal from this Nonce.
  • This other user (who is nearby, by means of his terminal) photographs this QR code, interprets it to reconstitute this Nuncio, calculates its hash (by chopping means the result of the application of a function of predetermined common cryptographic hash], and returns to the first user his own public key in clear and his signature (of the hash) of said nuncio.
  • a secret "passphrase” may be communicated by oral, this can be done by phone if the other user is not nearby, and the other user calculates in his terminal the hash of this "passphrase” instead of the minced Nuncio, then returns his signature with his key.
  • the terminal of the first user checks the signature against the key received and the Nunc (and / or passphrase) and records the key (public) of the other user.
  • the node of said first user is "IRL-connected" (IRL for "In Real Life") to the node of each of said other users having communicated its key by the method described above, each node being identified by its key public address (or an address derived from it).
  • the nodes also communicate to each other keys of nodes which are not IRL-connected but indirectly connected via one or more intermediate nodes, each node can reconstitute a part of the network, constituting its "entourage", and associate with each node of the entourage a "connection weight”.
  • IRL-connections or "real connections" in the entourage of an NI node, composed of six nodes (including NI) whose connection weight is therefore to be determined.
  • the connections are bidirectional and the solid lines represent IRL-connections.
  • the process is implemented by the first node (NI), which associates with each node of its entourage a connection weight and an influence factor (which are implicitly equal to zero by default.) Initially, the first node has a influence factor equal to 1 (and all other nodes implicitly have a zero influence factor.)
  • the method comprises the following steps:
  • connection weight of each second node is the normalized sum of the influence factors of the nodes (called “third nodes") which are IRL-connected (or to which it is IRL-connected), added to its weight of The connection weights are then normalized again (that is, divided by 2).
  • Step 2 The influence factor of each third node is the normalized sum of the connection weights of the (second) nodes that are IRL-connected to it.
  • Step 3 The process is repeated from step 1 until convergence (i.e. as the difference between the last connection weights determined in step 2 and the previous connection weights remains higher at a threshold].
  • Figure la presents an example of IRL-connections between nodes.
  • the connection weights resulting from the method, associated by the first node with the nodes of its entourage are indicated on each node.
  • the node 3 which is IRL-connected has a connection weight (equal to 0.15) less than that of the node 5 (0.21) which is not, this being due to the fact that the latter is indirectly connected via cluster nodes 1 and 6.
  • the first node (the user) will accept messages (WM) only from nodes whose connection weight is greater than or equal to the smallest connection weight among the connection weights of the nodes with which it is IRL-connected
  • messages (WM) from nodes whose connection weight is less than the connection weights of all IRL-connected nodes to the first node are not valid.
  • NI accepts messages (WM) that would arrive from any node in its vicinity except node 4 (whose connection weight, which is 0.12, is less than connection of all IRL-connected nodes to the first node, namely nodes 1, 3 and 6].
  • the validation of WM can be implemented with a coefficient applied to the connection weights (determined according to the configuration parameters, as already stated.)
  • the messages (WM) are not valid on the part of nodes whose the connection weight multiplied by a given coefficient is less than the connection weights of all IRL-connected nodes at the first node.
  • Figure lb shows these same nodes placed in a set of second nodes ("2 d nodes") and third nodes "3 rd nodes” .
  • the respective influence factors of the third nodes and the weights respective connection connections of the second node are indicated in parentheses with respect to their values at the first iteration, and underlined when they have converged.
  • a coefficient (determined according to the configuration parameters, in particular according to the size of the entourage) may advantageously be applied to said previous connection weights before adding.
  • a first node (the user) assigns a "connection weight" to a second node based on the number of intermediate nodes leading to it (and configuration parameters).
  • the first node itself is associated a weight 1
  • at the nodes IRL-connected to the first node are associated a weight of 0.5
  • at the nodes IRL-connected to the latter a weight of 0.25, and so on dividing them by two (if this is the parameter) each time an additional intermediate node is added.
  • connection weight is normalized.
  • Figure 2a shows an example of "proximity" connection weight at a node N1, associated by this node to the nodes of its surroundings.
  • a first node (the user) assigns a "connection weight" to a second node as follows: Among the nodes of the entourage of the first node,
  • the influence of the third nodes is also a function of the connection weights of the second nodes that are IRL-connected to them.
  • connection weight by distillation this circular definition requires an iterative process, by successive refinements until convergence (or quasi-convergence, that is to say until the gain of an iteration additional becomes negligible], a process where the same node can alternately play the role of second and third node.
  • An implementation of the method may comprise the following steps:
  • Step 1 Each node of the user's environment is associated with a proximity factor (proximity to the first node) based on configuration parameters, as described in the previous section "Connection weight as proximity”.
  • Step 2 At each (second) node of the user's entourage is associated a connection weight equal to the sum (normalized) of the respective proximities of the (third) nodes that are IRL-connected there.
  • Step 3 At each (third) node of the user's entourage is (re) associated an influence factor equal to the sum of the connection weights of the (second) nodes of the user's entourage. is standardized.
  • Step 4 At each (second) node of the entourage of the user is associated a new connection weight equal to the normalized sum (on IRL-nodes connected to the second node) of the products "influence * proximity",
  • Step 5 Repeat from Step 3 as long as the difference between the final connection weights determined in step 4 and the previous connection weights remains above a threshold (based on configuration parameters).
  • FIG 2a shows the nodes of the user's entourage with their respective proximity factors (calculated in Step 1) in relation to the first node (identified by "2"), factors indicated in italics.
  • Figure 2b shows these same nodes in two sets: the set of third nodes ("3 rd nodes") and the set of second nodes ("2 nd nodes”)
  • This figure indicates (in parentheses) a connection weight initial (calculated in Step 2, relative to the first node) for each second node (as being the sum of the respective proximities of the third nodes that are IRL-connected thereto) .
  • the initial influence factor (calculated at the first execution of the first node) 'step 3] is indicated in parentheses to the left of each third node (this factor is equal to the sum of the connection weights of the nodes to which the third node is IRL-connected)
  • the calculated connection weight (relative to the first node) in Step 4 after convergence is indicated underlined (in 2 d nodes).
  • connection weight is obtained by summing (and normalizing) the products "influence * proximity".
  • step 4 of the mixed method the term “influence * proximity” of the calculation expression of the connection weight can be replaced by an expression of the type “lambda * influence + (l-lambda) "proximity", the lambda coefficient can typically take the value 0.5
  • this coefficient is increased, the proximity factor (proximity to the first node) of each third node thus leaving the place progressively to the connection weights at the first node of the second nodes that are IRL-connected to it.
  • connection weights such as those presented above.
  • their results can be weighted according to coefficients refined by learning. These results allow the first node (the user) to validate other nodes in the various processes presented in this text.
  • connection weights allow to use a connection method similar to that described above in the section "Communication on Out-of-Band-Channel", but automatically, if one uses a plurality of nodes in redundancy.
  • a method implementing this method is described below on an example of a key exchange between a first node (Alice) and a second node (Bob) via intermediate nodes having a high connection weight with respect to
  • the WNs corresponding to these nodes are able to receive or send messages on a plurality of channels (such as SMS, email, etc.) -
  • This method comprises the following steps:
  • the WNs of said intermediate nodes use a separate and easily automatable channel, such as SMS, to communicate (in redundancy) this same Nuncio to Bob's node, as well as their respective public keys (it is all the better if they use different channels between them];
  • the WN of Bob's node detects the arrival of these Nonces and returns, to said intermediate nodes, his signature of this Nonce and his public key encrypted by means of the public keys of these latter;
  • the WNs of these intermediate nodes verify the signature by Bob's node of this Nuncio (decrypting it with its public key and checking the hash) and, if successful, communicate to the
  • Alice's WN the key of Bob's node signed by themselves and encrypted with Alice's public key
  • Alice's WN then records the key of Bob's node and can then exchange encrypted information with this node.
  • connection weights of said intermediate nodes can then represent connections all the more secure that said connection weights of said intermediate nodes are strong and that their number is significant.
  • the connections with the nodes for which said intermediate nodes have strong connection weights and are in sufficient number are marked “quasi-real” and the method for determining connection weights (such as those described above: “Connection weight per Distillation ",” Connection weight as proximity "and” Mixed process "] assimilate them to IRL-connections, to a close coefficient.
  • step 1 of the above method instead of Alice's WN generating said Nuncio individually, this Nuncio is generated together with the WNs of said selected intermediate nodes.
  • This complementary process is also automatic and comprises the following steps:
  • step 2 of the "Redundant Key Communication” method the intermediate nodes do not simply communicate the same final Nuncio to Bob's node, but also communicate said respective nuncios they have each separately generated (like described above], in step 3 Bob signs all these received nuncios, which allows the N intermediate nodes to ensure in step 4 that Bob has received the N nonces they have communicated in total.
  • the WN of first node (Alice) gets the key of the second node (Bob) directly from these intermediate nodes.
  • WN app on a social network.
  • the "Alice” user of this app is one of the nodes.
  • This app is able to receive and send messages on a plurality of channels (such as SMS, email, etc.).
  • connection weight of a friend can be determined according to the method described above, be added as an attribute in said list of friendly nodes and made accessible from from this list.
  • friends with a connection weight greater than a given threshold can be retrieved by a function call such as the following:
  • the respective WN apps of these friends use a separate and easily automatable channel, such as SMS, to communicate (redundantly) that same Nuncio to Bob's WN app, as well as their respective public keys (this is 'all the better if these friends use different channels between them];
  • Bob's WN app detects the arrival of these Nuncios and publishes in the social network (on his wall) his public key and his signature of that Nuncio - moreover, optionally, Bob's WN app returns directly, the WN app said Alice's three friends, his signature of this Nuncio and his public key encrypted using the public keys of the latter;
  • the respective WN app of the said three Alice friends check the signature by Bob's WN app of this Nuncio (decrypting it with its key and checking the hash) and, if successful, communicate to the Alice's WN app the key of Bob's node signed by themselves and encrypted with Alice's public key (advantageously he also certifies this key by publishing their own signature on Bob's wall);
  • Alice's WN app checks (double-check) the key of Bob's node by decrypting his published signature on his wall with that key and checking for the Nuncio's hash, records the key to Bob's knot, and can now, if successful, exchange encrypted information with Bob's node.
  • connection weights equates them with IRL-connections, with a coefficient near.
  • Bob's public key published by Bob in the social network is permanently accessible by at least all the nodes connected to Bob as friends.
  • step 1 of the above method instead of Alice's WN app generating said Nuncio individually, this Nuncio is generated together with the WN app of said selected friend nodes.
  • This complementary method is the same as that presented above, except that the WN are WN app here.
  • said N friends will also communicate to Bob the different nuncios (respectively) from which the final nuncio was generated, which will enable them to verify that Bob has received the N nuncios they have communicated in total.
  • the WN of first node gets the key of the second node (Bob) directly from these intermediate nodes, so to connect to the WN app of a "Bob" node, an "Alice" node can ask message WM] his friends having a strong connection weight:
  • a redundancy is created for each node with "mirror nodes" in which the data are kept synchronized and some of which perform the mirror processing, for at the same time:
  • a “node” (Wallet Node) is now a virtual node (denoted VWN X for "virtual wallet node” of the user x], materialized by a plurality of mirror nodes comprising:
  • a real node RWN (corresponding to said virtual node)
  • two nodes can not be linked by “smart contracts” (see the “Wallet Program” (WP) smart contracts described in PCT application WO2016120826A2) executing on their respective nodes. , that only:
  • a message (WM) sent from one to the other is valid only if at least 10% (or other percentage also determined according to configuration parameters ] of common mirror nodes executed this contract identically ("mirrored") and issued an identical message (WM) to the other node.
  • a destination node of a message only validates this message if the respective sets of mirror nodes of the sending and receiving nodes have an intersection whose number of elements is greater than a given first threshold and if the destination node has received the same message (in redundancy) from at least a given fraction (corresponding to a second threshold) of said mirror nodes belonging to this intersection.
  • the actual WN app of the Bob node will only consider a WM message sent by the actual WN app of the Alice node to be valid if it also receives this sent message (on behalf of the Alice node) from at least 10% of their mirror nodes in common (which are for example also WN app).
  • Each node running Wallet Programs synchronizes its data (ie: the persistent state variables (PSV) of its Wallet Programs, as well as its "Tags", described later) on all of its mirror nodes, this set including the union of all respective sets of mirror nodes that are in common with the nodes with which said each node has an active Wallet Program.
  • PSV persistent state variables
  • Wallet Program in part by sending (by Wallet Program) a WM message that triggers the update of the data (PSV and tags) by (same) Wallet Programs that run on the receiving nodes and, for the nodes that do not receive them , the data is synchronized directly by data update notification WMs.
  • each node synchronizes the list of its mirror nodes with the nodes with which it has a connection weight greater than a threshold, and said data synchronizations are performed with respect to these lists of mirror nodes.
  • the synchronization of the lists is carried out by corresponding WMs.
  • Figure 3a illustrates the propagation of a WM from a given VWN 1 to a destination VWN2.
  • the mirror nodes RWN1, CWN1 each memorize the list L2 of the mirror nodes of VWN2 in order to be able to direct the WM of identical content for all the sending mirror nodes and the destination mirror nodes.
  • Figure 3b describes more precisely the sending of messages between mirror nodes. It shows two of the sets of countersigned nodes in common, CWNAB between the nodes of Alice and Bob on the one hand, and CWNBC between the nodes of Bob and Cari on the other hand, Yunion of these two sets (+ the real node Bob RWNB] being the set of mirror nodes of Bob's node that are synchronized following any WM message sent to Bob's node.
  • the Alice and Carl nodes each know not only their respective mirror nodes in common with the Bob node, but the entire set of mirror nodes of the Bob node (thanks to the mirror node list synchronization discussed above). .
  • Figure 3b also shows a WM message generated by Alice's node following an interaction with the user (Alice), a WM message to be sent to Bob's node,
  • PWM announcement message
  • PWM Pre-wallet-message
  • the WM message is sent by Alice RWNA's actual node to Alice CWNAB mirror nodes that are in common with Bob's node (a single PWM being shown not to burden the figure)
  • the other Alice CWNXA nodes receive a data sync message (DSM), and then Alice RWNA's actual node, as well as each of these CWNAB cross-connect nodes in common with the node.
  • DSM data sync message
  • Bob send the relevant WM message to the Bob node, that is, to the actual Bob RWNB node and to the cross-referenced nodes of the Bob node (only a portion of these WM messages being illustrated not to weigh down the figure ].
  • Figure 3c shows a synchronization attempt phase of all the mirror nodes (RWNB, CWNAB, CWNBC] Bob via DSM type messages, in a situation where the real node RWNB is not responsive for one reason or another .
  • Figure 3d shows a message WM 'sent by the node VWNB to the Cari node VWNc, message generated not following an interaction of the real node of Bob with his user (Bob), but following said WM message received from the node of Alice (generated by the executed WP instructions)
  • the mirror nodes that actually received this message from the Alice node are able to generate the message at the Cari node (by executing this WP).
  • Figure 3d shows, however, that Bob's real node is non-responsive and therefore does not issue the WM 'message (which is represented by a "! In the figure), and that despite this, the other mirror nodes of the node Bob sends this message to the Cari VWNc node (which solves the non-responsiveness problem).
  • each of the mirror nodes of VWNc that receive WM ' will require the receipt of an identical message from 10% (or other percentage determined according to configuration parameters) of nodes CWN BC mirrors in common with this node (of Bob) .
  • Cari can thus count on the fact that the message was generated, and well generated by the WP smart contract in question which has not been altered (it solves thus the commitment guarantee problem].
  • connection weights of the mirror nodes are each greater than or equal to the smallest connection weight of the IRL-connected nodes (or in quasi-real connection) of its entourage.
  • a coefficient can be applied to it: the weight of each mirror node must be greater than or equal to the smallest connection weight multiplied by a coefficient (determined according to the configuration parameters), among the connection weights of the nodes with which it is IRL-connected (and by another coefficient for nodes in near-real connection].
  • a hard WN is a SoC as described in FIG. PCT application WO2016120826A2 and further to the section "CMMU"
  • the public key (corresponding to the secret private) of each hard WN being certified by its manufacturer, and these hard wallet may be from different manufacturers- however, the messages exchanged between Nodes are valid only if the nodes of their manufacturers are themselves linked by mirror nodes of manufacturers in common (see the description below).
  • the node that detects this conflict notifies the information of the conflicting mirror node keys to their respective manufacturers, and these keys are then revoked from these manufacturers, and after they are recycled, they are overwritten. is implemented according to the following steps:
  • each manufacturer is associated with a hard WN representing him and of which he is himself the manufacturer (certifying his own public key);
  • each manufacturer node is IRL-connected to the node of each other manufacturer having communicated its key by the method described in the section "Communication on Out-of-Band-Channel", some of which also communicating to it the keys of other nodes of manufacturers who are thus indirectly connected, each thus constituting his entourage, each node of the entourage being associated with a connection weight as described above;
  • the respective sets of mirror nodes of the manufacturer node of the sending node on the one hand and the manufacturer node of the destination node on the other hand must have an intersection whose number of elements is greater than a given threshold (this in addition to the two conditions specified above for the mirror nodes of the sending and receiving nodes) - thus, since hard-shell node nodes of different manufacturers must be able to interact, at the nodes of these manufacturers are associated mirror nodes, in case of conflict (during a synchronization (by DSM message), or when receiving non-compatible WM from mirror nodes of the same sender node, etc.], the information of the keys of the mirror nodes that are in conflict is communicated by sending messages (WM) to the nodes of their respective manufacturers (and if they are different, to their respective mirror nodes);
  • WM sending messages
  • the majority of hard WN is considered as authentic and the mirror nodes which are different are invalidated and blacklisted.
  • the information of the blacklisted nodes is immediately communicated to the nodes of the environment of the user and of these to the nodes of their own entourages, and so on (and the process can be sophisticated, according to the state of the art and progress in the field of Byzantine consensus protocols].
  • each WN mirror that is hard WN proposes, to the other hard WN mirrors where appropriate, to issue the message itself and the first one wins.
  • the method comprises the following steps:
  • a first hard mirror WN offers other hard WN mirrors (if any) to issue the message in question, which expires after a pre-agreed time (according to a configuration parameter);
  • FIG. 7 of WO2016120826A2 shows a payment of 10 units of account (UA) from a "WN 1" node to a "WN 2" node, these 10 AUs are deducted from the balance ("balance") of WN1 and added to the balance WN 2, these balances being persistent state variables (PSV) on these WNs.
  • U 10 units of account
  • the WN2 user who receives a WM1 payment message, from a WN1 node, following a sale he has made to the WN1 node, executes a payment Wallet Program WP1, and then pays a insurance premium by running a WP2 Insurance Wallet Program.
  • 10 AUs are transferred from WN1 to WN2, by means of a WM1 message sent by executing WP1 (this message containing hash # WP1) and these 10 AUs are paid by WN2 for set an insurance premium, by running WP2 sending a WM2 message (including hash # WP2) to a WN3 node.
  • UA tag BTC (Bitcoin units) originally from a Bitcoin transaction inserted and confirmed n times in the Bitcoin blockchain (as explained below, the private key secret of the beneficiary WN is in this case a private key corresponding to a Bitcoin address], without being limiting, the same mechanisms that can be used for any type of UA, including UAs created ex-nihilo by WNs for example, in Gift Cards.
  • WO2016120826A2 describes certain uses of tags that are created by an owner-owning node "Owner Wallet Node", have attributes certified by nodes "VWN"("Viewer Wallet Node”) as part of a supply chain (or commercial chain), and transferred from one OWN to another, reflecting the fact that instances of product (the products ts, physical or intangible] they represent are in the real world transferred between the users of these Wallet Nodes OWN.
  • Such tags may be recomposed (that is, merged or decomposed) in one transaction to give other tags, for example, with reference to Figure 5a, in a given transaction (tx1), a tag of 10 UA and a tag of 3 AU, constituting the inputs of the transaction, can be recomposed into three tags, constituting the outputs of the transaction, here a tag of 5 AU, a tag of 6 AU and tag of 2 AU, the total of UA being kept (the UA unit in question was not indicated in the figure, it can for example be BTC.)
  • One will call "transaction of transfer of tags" of such transactions
  • a transaction of transfer of tags is generated by the WN (OWN) able to sign the outputs of the transactions that specify its signature key
  • WN WN
  • FIG. 6 shows a message written "WMcy / t gx" sent by the Cari node to a node Y (of which only "CWNCY" countersignal nodes). common to the Cari node are in the figure.)
  • This WMcy / t gx message transmits a transaction whose predecessor transactions (in the "tgx" chain of tag successions) were previously passed by the WMXA / tgx, WMAB / tgx messages.
  • a Bitcoin transaction is like transferring BTCs, by signing (with a private key) at least one output of a previous transaction that allocates them, to at least one new owner whose Bitcoin address is derived from its public key
  • the secret private key of a WN is a private key corresponding to a Bitcoin address (that is, the WN generates a Bitcoin address from its secret private key).
  • each tag includes the information of the upstream tag transfer transaction graph, each indicating the address of the WN that generated it (these WN are called "upstream WN"), which allows a WN destination of a tag transfer WM, to check directly if at least one mirror (or some number) of all the upstream nodes are in its surroundings, is part of its own mirror nodes and is a hard WN, and for each WN upstream which is not in this case if the connection weight of one of its mirrors which is a hard WN would allow him to be part of it (after possible exchanges of new connections with nodes of his entourage).
  • upstream WN the address of the WN that generated it
  • each tag is associated all the upstream tags (that is to say, appearing in the upstream graph, in all chains of successions of tag transfer transactions leading to the tag in question), with the address of the tag. owner node that generated it and with, if any, the adr each of its subsequent owners (OWN), as well as the addresses of their mirror nodes, which allows each destination node of a WM transmitting a tag transfer transaction to directly check the required intersection between its own mirror nodes. and the mirror node addresses of each of these owners, as well as the fact that at least one (or some, depending on the configuration parameters) are hard WN, and a search for nodes having strong connection weights is necessary launched to associate new mirror nodes.
  • OWN adr each of its subsequent owners
  • such an offer to purchase from a key K WN includes a set of elements ⁇ H (S]; $ R; $ P; T [; params] ⁇ announced on this market with SigK signature.
  • $ P is a penalty that a supplier who agrees to provide at time T must pay if he does not do not (see also the "Use Scenario" below)
  • the term ⁇ H (S]; $ R; $ P; T [; params] ⁇ is also called "supply elements".
  • WMBid WM (Sig, # WP1), communicating a service offer statement for a "Sig" service (corresponding to an offer element signature by a WN, as described above), message whose recipient is the signatory of Sig and who, if accepted by the latter, binds its issuer (the one proposing the service in question) to pay a penalty in the amount of $ P in the event of non-supply within a given period of time. ;
  • WMAccept WM (WMBid, # WP1), communicating, in response to a given WMBid message, the acceptance of the service offer in question, and committing its issuer to pay the amount $ R
  • WMS WM (WMAccept, S, # WP1), communicating the secret S in response to a given WMAccept message and triggering on the receiving WN its verification (with respect to the H (S) specified in the offer elements in question in previous messages] and, in the event of a successful verification, generating on the receiving WN a payment transaction of the amount $ R (also specified in the offering elements) sent to the issuer of that WMS message by a final WM of the WN receiver.
  • WP1 is also able, after receiving a WMAccept message, to subcontract the processing (here brute force search secret S) to a trusted computer able to return a certificate of authenticity and integrity of execution, attestation which will be automatically checked by WP1 before sending the WMS message.
  • processing here brute force search secret S
  • attestation which will be automatically checked by WP1 before sending the WMS message.
  • the U2 user of WN2 does not already know this secret S, and also assume that the parameters paramsl include the indication of the maximum number of characters of the searched secret, number indicating that the trusted computer can find the desired secret by force search in a reasonable time. U2 then decides to send by his Wallet Node WN2, to the Wallet Node WN1 of Ul, the message
  • WMBid2 WM (Sigl, # WP1)
  • WMAcceptl WM (WMBid2, # WP1)
  • WMS2 WM (WMAcceptl, SI, # WP1]
  • WN1 communicating the desired secret SI to WN1, and upon receipt of this message and checking the correspondence of the hash of the secret received with H (S1), WN1 generates the payment transaction from $ R to WN2 and sends it (by WM) to WN2.
  • the offer elements can also represent an offer of sale and the approach of the method allows negotiation by iterations of offers and counter-offers, the offer elements being able to evolve in these iterations, the messages then being essentially as follows (if we consider that the first message, here WMBid, is sent by the supplier):
  • WMBid WM (Sig, ⁇ H (S); $ R; $ P; T [; params] ⁇ , WP1], communicating a counter-offer ⁇ H (S]; $ R; $ P; T [; params ] ⁇ in relation to "Sig", message whose recipient is the signatory of Sig and which, in case of acceptance "identical” by the latter, commits its issuer (the WN which proposes the service in question] to pay a penalty of the amount given $ P in the event of non-supply within the given period T;
  • WMAccept WM (WMBid or WMNewBid, ⁇ H (S); $ R; $ P; T [; params] ⁇ , # WP1), communicating a counter-offer in response to a given WMBid or WMNewBid message; in the case where ⁇ H (S]; $ R; $ P; T [; params] ⁇ is identical to the offer elements of the latter, this WMAccept message commits its issuer to pay the amount given $ R upon receipt of a WMS message comprising said secret whose hash corresponds to H (S]; also, in the case where, within a (pre-determined) delay, a WMNewBid message proposing identical offer elements arrives, this WMAccept message directly commits its issuer to pay the amount given $ R upon receipt of a WMS message including the secret whose hash corresponds to H (S];
  • WMNewBid WM (WMAccept, ⁇ H (S]; $ R; $ P; T [; params] ⁇ , WP1], communicating a counter-offer ⁇ H (S]; $ R; $ P; T [; params ] ⁇ with respect to a given WMAccept offer and whose recipient is the originator of this WMAccept message, in the case where ⁇ H (S]; $ R; $ P; T [; params] ⁇ is identical to the elements of offer of this given WMAccept message, this WMNewBid message directly commits its issuer (the one proposing the service in question) to pay the penalty of a $ P amount in case of non-supply within the given time period T (without waiting for a new WMAccept message acceptance]
  • WMS WM (WMAccept, S, # WP1), communicating the secret S in response to a given WMAccept message and triggering on the receiver WN its verification and, if successful of this verification, the generation of a payment transaction the amount $ R sent to the sender of this WMS message by a final WM from the receiving WN.
  • a variant of this method consists in transferring to the trusted computer, in addition, the verification task of the result provided, and the said trusted computer provides an attestation (of the authenticity and the integrity of the processing performed for this verification) which serves as the proof.
  • WMA2 WM (WMAccept1, SI, A2, # WP1]
  • A2 is said attestation of this successful check performed in said trusted computer, WN1 then not having to perform this check before generating the settlement transaction from $ R to WN2.
  • the certificate A2 is returned without immediately providing the result S1, and this result is provided after WN1 returns (a WM comprising] a payment transaction (at least partial, the payment being then completed by the sending of a final transaction after receipt of the result SI- also note that in the case where the result can be partitioned, several payment-partition iterations can follow one another until complete supply].
  • a problem-solving auction market can be created, ensuring for example that a supplier offering a better offer (more complete and / or faster and / or 7) seals a deal. only in providing a solution to a given problem but also in verification processes of a proposed solution (in the software testing sector for example).
  • the WN's ability to outsource processing to trusted computers thus extends the power of the WN network, the WN network eliminating neutral third parties in the exchanges, with each WN being able to be manufactured at low cost in a single technology. accessible and relatively widespread, by a plurality of manufacturers, precisely thanks to this possibility of outsourcing which allows the WN to take care of only the treatment concerning the exchanges (the conditions of exchange, the payments, etc.).
  • the Wallet Nodes allow to implement treatments without disclosure of processed data or the code executed in these processes.
  • the execution model adopted for this executable code P is a finite state machine, the execution of which is triggered by the reception of an incoming message and capable of sending outgoing messages. Thus, its reception of an incoming message results in the generation of 0 to n outgoing messages and 0 to m changes of states (persistent states).
  • a proxy is associated with a pair of public / private keys, the public key ["K2") of Proxy having previously been certified, in the form of a decrypable signature with a certain public key "K" (in the name of the manufacturer of the SoC, “On behalf of the SoC manufacturer”], to guarantee the "blindness” property of Proxy and including the guarantee of integrity of execution (called “hash-locked execution", “hash” meaning "hashed”].
  • K2 is certified with ⁇ K2> (i.e. decryptable using K)
  • Proxy sends K2 to Client (and ⁇ K2, meaning ⁇ (K2) ⁇ is accessible by Client)
  • Proxy decrypts ⁇ ⁇ ⁇ , hashes P (#P) and stores ⁇ ⁇ ⁇ in association with #P, in a table PHT (Program Hash Table)
  • Proxy decrypts ⁇ K2 (input + # P '%) as well as fcP ( ⁇ K2 P being retrieved from PHT using #P)
  • Proxy (blindly) runs P (decrypted on the fly) with I (once decrypted), encrypts the results using Kl ( ⁇ K iOutput) and returns nonce and ⁇ K iOutput (or garlic encrypted together) along with sign K2 ( Nuncio, ⁇ K iOutput ...) to Client, without the owner of Proxy being able to see I, P or thesis results 12.
  • Client decrypts the results and checks them by decrypting their signature with K2.
  • step 8 instead of simply encrypting I + # P with the K2 key of Proxy, Client number I + # P + K1 [ ⁇ K2input + # P + K1), and at step 9, Client communicates his public key K1 by sending ⁇ K2input + # P + K1. Proxy then returns the results to Client (at his address which can be # KI) without Kl being unveiled.
  • nonce can also be part of the body of the encrypted message [ ⁇ K2input + # P + Kl + nonce) and in the message returned by Proxy to Client, it also appears encrypted [ ⁇ KiOutput + nonce].
  • #P so that the user or owner of Proxy can not make the relationship with Customer.
  • the message from Client to Proxy includes:
  • nonce and ⁇ KiOutput can be obtained by decrypting signK2 (nonce, ⁇ KiOutput) by means of K2, but it is considered in the following that the signatures consist of hash ciphers]
  • nonce advantageously allowing to match an outgoing message to an incoming message and K2 and signK2 (nonce, ⁇ KiOutput) allowing Client to verify that the treatment has been done by Proxy having this key K2 (certified).
  • #P is the executable code hash that can be used by Client or Proxy.
  • # P1 is the executable code hash executed by the issuer of this message M
  • ⁇ # P2 is the hash of the executable code required to perform the processing on receipt of this message M.
  • nonce2 identifies the message in question (M), while noncel is the identifier of the incoming message received that triggered the processing that gave rise to this message M.
  • a more complete message format also includes a #spec argument containing, where appropriate, the hash of a specification of the constraints connecting # P1 and # P2, that is to say, restricting all valid # P2's following a # P1:
  • this "spec" specification can be the set of valid executable codes [# P1, # P2, etc.].
  • this specification can be the set of valid executable codes [# P1, # P2, etc.].
  • the set of valid executable code hashes (# P2 ) for each executable code whose hash is given [# P1] is provided in this specification the set of valid executable code hashes (# P2 ).
  • the executable code (in its entirety) which is to be executed by the message receiver is required to be the same as that executed by the sender of the message, ie say that the same #P is propagated from an incoming message received to one (or each) outgoing message generated
  • the message format be the following (and we can use or refer to this particular option of unified format in the following, without being limiting]:
  • a microcontroller comprising a general-purpose processor (such as a processor implementing the RISC-V architecture) equipped with a memory Only this processor can access the "Sign" part providing cryptographic functions, including the signature functionality of the SoC, the latter being in turn the only one able to access the part containing the secret key of the chip (Secret Key].
  • a general-purpose processor such as a processor implementing the RISC-V architecture
  • the "Secret Key” part is shown in parentheses in the figure since in some implementation options the secret key is not stored but dynamically regenerated
  • the Wallet Programs part stores encrypted executable codes [ ⁇ P ) and their respective hashs.
  • the Microcontroller loads into its memory in a secure way, depending on the hash (#P) included in the incoming message (or from the via ⁇ / 0] one or the other of these executable codes. These are able to handle, in a non-volatile memory, persistent state variables that are only accessible by the Microcontroller.
  • the sub Pers system. State Variables does not make said Pers.
  • the signature subsystem of the transmitting WN in order to transmit a WM to a recipient WN, the signature subsystem of the transmitting WN generates (or verifies] encryption of the executing WP (ie WP commonly loaded] with the appropriate data to be transmitted, by means of the public key of the recipient WN, and includes it in said WM to be sent before signature of said WM to be sent (and on receipt of the WN recipient load for execution this WP once decrypted] thus guaranteeing that the same WP is re-executed in the recipient WN
  • the WPs can be organized in versions, the choppers of the previous versions of the WP supplied in the WM then accompany the latter and, for each variable d the state stored in the chip, the hash of the version of the WP that has recently manipulated it is associated with it so that the state variables of a WP can be updated
  • the public key corresponding to said secret private key is "certified" by the manufacturer of said WN system-on-chip.
  • This certificate is a signature (it is the signature, by an entity representing the manufacturer, of the public key corresponding to said secret key of the WN) whose signature key (that is to say public key representing the manufacturer) is shared between all (or at least a plurality of) WN-on-chip systems of the same manufacturer, said certificate is generated automatically, regardless of the mode of manufacture: mode where said secret key is etched in the chip as in the TPM or the smart cards, mode where it is stored in a secure way, mode where it is automatically generated in the chip according to the "PUF” [Physically Unclonable Function] technology introduced in [PS Ravikanth, "Physical one-way functions "PhD Thesis, MIT, 2001] and [Pappu et al.,” Physical one-way functions ", Science, 297 (5589): 2026-2030, 2002] (technology implemented in particular in SoC FPGA Smartfusion2 and other
  • the authenticity of said public key of a WN transmitting a WM (including the authenticity of the signatures made by means of the secret key of this WN) is automatically verified by the WN receiver of this WM when it receives against
  • the system automatically includes the said certificate in the WMs.
  • BIST Busilt-In Self Test
  • SoC SoC
  • BIST Bus-In Self Test
  • a SoC Blind has a secret private key.
  • a SoC Blind can communicate with other equipment only through messages and is able to execute programs only in response to receiving messages (as shown in Figure 23) .
  • a SoC Blind is also able to memorize a program to execute. received, received encrypted and / or encrypted by the Blind SoC, and generate a hash of each program, this hash to find the program encrypted by means of a table "Program Hash Table" (PHT).
  • PHT Program Hash Table
  • the Blind SoC can send to the Blind SoC a message containing input data [data] for a certain program to execute (P2), as well as the hash (# P2) of this program.
  • the Blind SoC accesses the program to be executed from the hash of the program (# P2) received in the message, (ii) decrypts the program on the fly, and (iii) executes the decrypted instructions on the fly.
  • Blind SoC includes a Crypto Memory Management Unit (CMMU) which stores - or is able to dynamically regenerate (by PUF technology, previously mentioned) - said secret key of the Blind SoC (which is only accessible by the CMMU which never reveal it], and it is through this CMMU that are performed:
  • CMMU Crypto Memory Management Unit
  • said decryption for execution on the fly by at least one processor unit included in the Blind SoC,
  • FIG. 21 shows schematically the steps of CMMU reception of a message containing a program to be loaded into memory (MEMORY) Note that the memory (MEMORY) can be external to the SoC or not, and it includes a placeholder to the tags described above
  • the numbered steps represent the following steps:
  • said program to be loaded being encrypted and the hash of said program before encryption being determined, reservation of a space in memory that can contain this encrypted program and its persistent state variables which will also be encrypted, and storage of said encrypted program, said hashed allowing later to find it via a table (PHT).
  • PHT table
  • the CMMU unit makes said storage of the encrypted instruction block program per instruction block and provides (to said processor) a single instruction block that is decrypted at a time (for execution by the processor of the instructions that the block includes].
  • the method for loading programs (executable codes) in Blind SoC advantageously comprises the following steps: On receipt by Bind SoC of a message comprising P and #PP (in encrypted form feP + # PP ...], PP being the program program load and P being the executable code content to load, the CMMU:
  • the processor unit executes on the fly the decrypted instructions on the input data, the persistent state variables linked to P being stored in isolation in addrl..addr2, and the generated messages including #P and being signed by CMMU.
  • CMMU locates in the table PHT, from said hash, said encrypted program, loads it into its cache and decrypts it (block by block);
  • CMMU transmits on the fly the (one block at a time) decrypted program to PROCESSOR for execution;
  • PROCESSOR requires access to or updates / modifies persistent state variables (PSV and / or tags) and requests them to be stored or deleted, and
  • CMMU accesses and decrypts / encrypts and stores said persistent state variables
  • PROCESSOR prepares a message to be sent
  • CMMU inserts the hash of said executing program and its signature by means of the secret key and sends the message.
  • the CMMU is able to check the required intersections of sets of mirror nodes described above when receiving a WM and for each received tag transfer transaction.
  • the WMs can be issued by a SoC Blind (generated by the execution of a WP program) or received as an input of the user or by another device ("Quasi- WM" messages). And] include the #WP hash of this program in both cases.
  • Figure 23 shows a WM tag transfer message, which conveys a transaction (txl), this transaction causing in the memory (MEMORY) at the tag level, the insertion of the tags brought by this new transaction, each tag comprising the data representative of the succession (graph) of transactions upstream, as already described, each associated with the address of the upstream WN that has generated it and the addresses of its WN mirrors, With this information, to validate or not the message, the CMMU verifies the required intersection between its own mirror nodes and said WN mirrors addresses, as well as the fact that at least one (or some, depending on the configuration parameters) are hard WN.
  • CMMU handles the transaction simplifications described below in the "Bitcoin Off-Chain Transactions" section: a simplification consists in replacing at least two previous inter-WN transactions that are not yet inserted in the blockchain with a new one. (or as little as possible] replacement transaction, the CMMU ensuring that the current balance remains unchanged by these replacements (this mechanism is generic, tag transfer transactions being more general than Bitcoin transactions).
  • Figure 23 also shows a CMMU generated https request that supports handshakes and cryptographic operations, leaving the terminal to which it is coupled the role of input / output interface (at TCP level) to ensure end-to-end data integrity (the accessed site being trusted).
  • the CMMU also supports Blind SoC management and signing of non-WM messages (as shown in Figure 23 and described above in "WN sending a message to the outside world").
  • the CMMU includes a mechanism to constrain the use of tags by WP programs.
  • a tag can be reserved for use by a WP or linked WPs (see Figure 7), so that tag units of account can not be spent by a WP that is not authorized to do so.
  • a WP is able to indicate to the CMMU that a tag is reserved for its use, and the CMMU assigns to this tag a mark indicating this reservation at the memory MEMORY.
  • This marking can be lifted on the initiative of the same program, thus making the tag usable again by other WPs.
  • WNs In the case of an attempt by a WP to generate a transaction fed by a tag for which this WP is not authorized, the CMMU prohibits the operation, and the UAs of this tag can not be consumed (since such a transaction can not take place.]
  • This architecture allows WNs to reserve UA materialized by tags for certain types of operations to be executed by the WPs that reserved them respectively, and thus to implement implementation of UA-based commitments that are blocked for this purpose, such as the CCCs described in WO2016 / 120826 A2.
  • the general framework here is a set of nodes that are beneficiaries of CCC commitments and can themselves provide CCC commitment of the same type to other nodes, the latter to others, and so on, the nodes and CCC's commitments thus forming a "networked-insurance" network.
  • a first node having provided second nodes CCC commitment of a certain type, adds (typically staggered in time) to its CCC balance (sum of UA reserved tags) and in accordance with this commitment, a " premium "(similar to an insurance premium) to cover all of these second nodes, and specifies for each second node a threshold signifying how high this second node is covered by it, threshold called" maximum potential contribution ".
  • the first node transfers to this second node, from its CCC balance, a certain amount of UA (see “UA transfer transaction") in exchange of "bonus coupons” (see definition below) issued by the second node
  • UA transfer transaction a certain amount of UA
  • bonus coupons in exchange of "bonus coupons” (see definition below) issued by the second node
  • the amount of this transfer is a function of the CCC balance of the first node and is up to the maximum potential contribution specified for the second particular node.
  • a "bonus coupon" issued by a second node is a "bearer” debt acknowledgment issued in return for a contribution received by the second node in execution of a CCC commitment, following a loss, contribution received from the the first node that is the provider of this CCC commitment.
  • This debt is repayable by the second node in accordance with this CCC commitment (typically in a staggered manner over time) within the limit of the amount of the premium provided for the second node, and pro rata of this contribution received (among a plurality, if necessary).
  • the premiums are "bearer” in the sense that, as long as their respective amounts of debt are not yet cleared (that is, there are still AUs to be received), they represent a certain amount of futures value, have some "immediate value in UA", and can be transferred (see “UA Transfer Transaction") from one node to another "The immediate value in UA" a bonus bond is defined as the sum of the amounts it represents on different scheduled terms minus the sum of the respective interests for the terms of those terms
  • the first holder of a bonus bond is the first contributing node , in execution of a eng CCC, the second stricken knot that issued this bonus coupon.
  • the immediate value of the bonus coupon thus received by the first node is added to the CCC balance (which is reserved to pay claims] and it can not be spent (or even partly) to compensate for a claim under this CCC commitment, by the authorized WP (s).
  • Said second stricken node also transfers, to said first node, all the bonus coupons which it has itself received from the downstream nodes to which it has contributed in the past within the framework of the same CCC, always in a mode " to be used only in the event of a disaster ", but here in a” competing "mode (that is, replicated and synchronized) and half (or for a given proportion in the CCC) of their respective values.
  • Each bonus coupon can be replicated on multiple nodes at once, can only be used for payment (for all or part of its immediate value) in the event of a disaster and only for the CCC in question, and a payment per voucher of bonus consumes it simultaneously (by synchronization) on all the nodes where it is (including on said first node which contributed to the disaster which is at the origin and towards which it was transferred first]. do this, every claim payment per claim slip ime is, if necessary, notified by the paying node to the other competing nodes where it has also been transferred and when its value drops to zero, it is deleted on all of these nodes. Sending Message
  • This message expires after a certain amount of time, set for the given executable code, after which time it is typically re-issued a number of times (see “Non-responsiveness commitment guarantee” section below).
  • the acknowledgment of receipt thus has the following form:
  • a first message (WM1) by a first transmitter (WN1) to a recipient WN2 is, in a given period of time from the sending of WM1 (which is typically fixed for the current executable code), followed by Yen voi
  • WM1 from WN1 to WN2 noncel, ⁇ K2 data + # P, nonce2: Nl, Kl, sign K i (noncel, ⁇ K2 data + # P, nonce2.-Nl), sign K (KI)
  • the message WM2 of Figure 12 sent from WN2 to WN3, is of the following form:
  • payload being a content dependent on the executable code in question, such as for example the content of WM2.
  • the acknowledgment received from the fourth (WN4) is also propagated step by step to the first transmitter (WN1), to arrive at the message "((ack (WM3]]” sent by WN2 to WN1 and with information ": ⁇ (ack (N2), payloadl), (ack (N3), payload2) ⁇ ” corresponding to the following messages exchanged:
  • payloadl and payload2 depending on the executable code in question and being for example the respective contents of WM2 and WM3.
  • WM2 and WM3 the respective contents of WM2 and WM3.
  • only the part that is useful to communicate is, possibly after transformation.
  • a WN-based method will now be described for materializing (serializing) value-unit transfer transactions, so that they can be stored in a blockchain, for example: Bitcoin transactions in the implementation described hereinafter , valid and directly insertable into the Bitcoin Blockchain, are generated - but without necessarily having to insert them in this Blockchain, while offering the same guarantees as if they were. (The same process that can be transposed to other blockchain-based protocols Thus, in what follows, the units of value in question are BTCs.
  • Figure 9 thus shows an example with three Wallet Nodes ("WN1", “WN2” and "WN3”] where first of all the WN1 user (or a third party) creates an incoming Bitcoin transaction ("Txl") in favor of WN1 (having an output giving 10 BTC to WN1), and classically broadcast (“broadcast”) this transaction which is then inserted in the blockchain, this having the effect of guaranteeing the user of WN1 that only WN1 can spend these 10 BTC available to it on Txl.
  • Txl incoming Bitcoin transaction
  • each transaction is represented abstractly by a box (a square) placed on an arrow.
  • the number inside this box represents the amount transferred from the point of view of the user. that is, which are not transactions between WN] are represented by larger boxes than inter-WN transactions.These balances are shown in italics (along the large vertical lines to their right).
  • deletion of an inter-WN transaction is presented by a small oblique line on the end of the arrow representing this transaction.
  • These replacement transactions (such as Tx6) are represented separately by a double-headed arrow and when they are deleted (as in the case of Tx8) this is also represented by a small oblique line.
  • Figure 9 shows in the upper left, a re-entry (Txl) of 10 BTC on WNl whose balance was just before 0.
  • Txl re-entry
  • WN2 transfers (by Tx3] 5 BTCs to WN3 (it thus remains 5).
  • BTC are transferred to WN2 from a non-WN address (through the Tx4 transaction that was inserted into the blockchain), the balance of WN2 thus increasing from 5 to 15.
  • Tx10 and Tx15 are generated between WN1 and WN3, are of the same value, in reverse and non-broadcast, and can therefore simply cancel each other out, that is, be deleted without giving rise to a replacement transaction. (Here again, it is interesting to see in Figures 13 and 14 the details at the Bitcoin level].
  • Txl l and Txl6 which are of the same meaning (from WN3 to WN2) and non-broadcast, give rise to the replacement transaction Txl7 which transfers their sum and which is itself replaceable as long as it remains non-broadcast (details at Bitcoin level in Figures 14 and 13].
  • the outgoing transaction Txl8 [broadcast] causes the broadcast of the chain of transactions that feed it and can not be deleted anymore, in this case it is Txl3 (see Figure 15).
  • FIG 9 The Bitcoin transactions presented in Figure 9 are "abstract" in that they present the amounts transferred from the user's point of view but do not show the inputs and outputs of these Bitcoin transactions.
  • Figures 10 to 15 present the real transactions corresponding to the abstract transactions of Figure 9 (by explaining their inputs and outputs).
  • the method of their generation is based on the fact that at a balance available in a WN (the number in italics in the figure) always corresponds to at least (an amount available on] an output in favor of this WN (the total of these outputs being equal to this balance], that one can combine such outputs to connect them to the inputs of a transaction generated by said WN, and in the case of an overrun, return the surplus (called "change") audit WN by an additional output and with regard to the implementation of replacements / deletions, even in the case where an output of a transaction to be deleted (for example Tx10, see Figure 13) is connected to an input of a transaction that is not expected to delete (Txl l) in the same operation, the latter can be automatically updated to be connected to an available output of another transaction (Txl3).
  • the creation of a transaction comprises the sending of message (s) in the sense of the preceding section, For example, the generation of Tx3 by WN2 causes the sending by WN2 of a message indicating to WN3 and this transaction is actually created only upon return of an acknowledgment by WN3 (see also the "Non-responsiveness commitment guarantee" section.)
  • Figure 10 shows the actual Txl to Tx5 transactions, which corresponds to the abstract transactions of the same label in Figure 9.
  • Tx3 only transfers 5 BTCs to WN3, its input takes 10 BTCs from Tx2 (because Tx2 did not a BTC output in favor of WN2] and returns 5 BTCs to WN2, that is, Tx3 has an output of 5 BTC in favor of WN2, in addition to the output of 5 BTC in favor of WN3.
  • Tx3 and Tx5 transactions in Figure 10 are replaced in Figure 11 with the transaction Tx6, generated by WN2 (and the replacement notification is sent to WN3) .
  • WN2 can connect Tx6 to Tx2 or to the Incoming Tx4 transaction is preferred because the upstream supply chain is shorter (or by more complex heuristics) because the same figure shows the outbound Tx7 transaction that is broadcast immediately, and if Tx6 was connected to Tx2, Tx2 should also have been broadcast and could not have been replaced later as shown in Figure 12.
  • Figure 12 shows the result of the replacement of Tx2 and Tx8 with Tx9, as well as the generation of Tx10 transactions by WN1 (to WN3), Txll by WN3 (to WN2) and Txl2 again by WN1 (but to WN2).
  • Txl5 has the effect of canceling the effect of Tx10, in fact it transfers 1 BTC in the opposite direction.
  • Figure 14 shows the result of this cancellation which results in the update of the input and the output of Txl l.
  • Txll and Txl6 are replaced by Txl7 which connects its input to the output of Tx7.
  • This Figure also shows that WN1 generates the outgoing Txl8 transaction powered by Txl3, which makes Txl3 broadcast and therefore not removable.
  • FIGS 16 to 19 show the example of Figures 9 to 15 but with the difference that in Figures 16 to 19 transaction Tx7 is generated (by WN3) after transaction Tx13 is entered (generated by WN1). Note that the same method could have been described in the example shown in Figures 9 to 15, but considering that Tx7 is not broadcast before Txl3 is endorsed.] Thanks to the propagation by WN2 to WNl of the acknowledgment by WN3 of Tx6 for 9 BTC, transactions Tx9 and Txl2 for a total of 9 BTC also being accepted (on receipt by WNl of acknowledgments from WN2), WNl replaces these three transactions by a single transaction Txl9 which transfers 9 BTC from WNl to WN3 directly.
  • Tx9 5 BTC
  • Tx12 4 BTC
  • Txl3 9 BTC, from WN1 to WN2
  • Tx6 9 BTC, from WN2 to WN3
  • Tx19 9 BTC
  • Figure 17 shows Figure 13 but without Tx7 and the following ones being generated.
  • Figure 18 shows transaction Txl9 (9 BTC from WN1 to WN3) which replaces transactions Txl3 (9 BTC from WN1 to WN2) and Tx6 (9 BTC from WN2 to WN3, taking 10 BTC from Tx4 and keeping a change BTC] shown in Figure 17.
  • Txl9 (9 BTC from WN1 to WN3
  • Tx6 9 BTC from WN2 to WN3
  • Tx4 9 BTC from WN2 to WN3
  • this method can be applied to simplify inter-WN transaction paths in a network of more than three WN (without limitation of this number).
  • the units of account in question are advantageously implemented as tags and said Bitcoin transactions are tag transfer transactions whose AUs are BTCs (as described above).
  • PCT Application No. WO2016 / 120826 A2 discloses a system and method in which, in response to the receipt of a message by a device with a processor, non-modifiable instructions (similar to Root-of-Trust , or RoT] load in this system-on-chip executable code whose hash corresponds to a given hash included in said received message .
  • the execution that follows of this executable code, in said device is thus predetermined with respect to this This correspondence is guaranteed to the extent that appropriate access restrictions between the different parts of said system-on-a-chip exist and can not be altered.
  • the executable code thus imposed by the sender of the message is arbitrary and suitable. to update state variables (only the executable code having these state variables being able to modify them) and to generate further messages that will themselves propagate the same code of ha to other such devices.
  • Figure 20 shows a WN commitment provider likely to be non-responsive (El), a WN supposed to benefit from the commitment in question (E4), as well as WN buyers of this commitment in case of non-responsiveness (E51 to E53)
  • the method comprises the following steps, with reference to this figure:
  • PT-List specification A (any) commitment from a provider of this commitment (El) to a beneficiary of this commitment (E4] specifies a list "PT-List" (Potential Transferred List) of WN potential takers (E51 , E52, E53] in case of non-responsiveness of said supplier (El).
  • Non-Responsiveness Confirmation Following the sending of a WM by the said beneficiary (E) to the supplier (El), found by the said beneficiary (E4) of the non-responsiveness of the said supplier (El).
  • Step 3 If the said selected buyer is non-responsive or, for a subsequent WM issued by a beneficiary of a commitment of the said supplier that was non-responsive (El), if the latter is still non-responsive, the same process is applied from Step 3 (Non-Responsiveness Confirmation).
  • CTCs Commitment Commitment Commitments
  • TOC Takeover Commitment
  • a CTC is used to indicate to the recipient of a commitment that, if the supplier (Wallet Node) of the said commitment becomes non-responsive, the CLC's provider (Wallet Node) automatically honors the said commitment in its place.
  • CTC provider is called "Potential Transferred" ("PT").
  • any commitment (any engagement, smart contract) issued is associated with a "Potential Transferred List" ("PT-List") containing the addresses of the Wallet Nodes (PTs) that provided a CTC to the provider (or to the signatories ] of this undertaking (in order to indicate to the beneficiary which entities (Wallet Nodes) are responsible for honoring it in its place if it becomes non-responsive], the latter being in charge of executing the undertaking is in default to the extent that this execution is automatic, without any input from the user.
  • PT-List a "Potential Transferred List”
  • the said Wallet Nodes (E51, E52, E53) of the PT-List of a non-responsive provider (El) In order for the said Wallet Nodes (E51, E52, E53) of the PT-List of a non-responsive provider (El) to be able to honor its commitment in its place, they must have the current state of the PSVs. For example, in the case of a CCC takeover, they must have the current values of the persistent variables (including balances, amount + and amount - for different issuers) of the CCC Wallet Program in order to ability to generate a UA transfer transaction, if applicable For this purpose, at each update of its data, the Wallet Node (El) provider of a commitment notifies all WNs (E51, E52, E53) of the PT-List given in this commitment, the new state of its data .. Thanks to the blindness property of Wallet Nodes the users or owners of these WN can not access this data. Non-Responsiveness Confirmation
  • said recipient (E4) Failing receipt of an acknowledgment of receipt of a WM regularly re-transmitted to said provider (El) for a previously agreed duration, said recipient (E4) reissues this same WM to the WN of the PT-List (E51, E52, E53] and said provider (E1) is expected to send also to the latter (E51, E52, E53) a copy of said acknowledgment of receipt of the WM sent by the beneficiary (E4), said provider (E1) being considered as non-responsive by the beneficiary (E4) when, during a previously agreed period, no PT of the PT-List notifies the beneficiary (E4) of receipt of the acknowledgment of receipt.
  • each PT of the PT-List sends it the last n WM of data update (persistent state variables) received from the said provider (El), which makes it possible to automatically select at least one of the PTs in this list (E51) among those whose data has been updated most recently Thanks to the blindness property of the Wallet Nodes, the user or owner of the beneficiary WN (E4) can not access to these messages.
  • This step may include selecting several buyers from the potential buyers of the PT-List, who must sign the transactions of transfer of units of account, in a multisignature of n among m WN (n being less than m to predict the where all selected PTs are not responsive at the same time].
  • the selection of the m takers may be done according to a protocol (as in the random selection protocol described above) where each (or at least a number) of the potential PT-List resellers returns a sub-list of PTs drawn to the PT-List. randomly from this list, first in the form of a hash, then unveiled in a second round, and the potential buyers of the PT-List then select by cross confirmations the m selected buyers according to a selection rule (such as for example taking m that were randomly selected by the most potential buyers] pre-established in the commitment in question or by default.
  • a protocol as in the random selection protocol described above
  • each (or at least a number) of the potential PT-List resellers returns a sub-list of PTs drawn to the PT-List. randomly from this list, first in the form of a hash, then unveiled in a second round, and the potential buyers of the PT-List then select by cross confirmations the m selected buyers according to a selection rule (such as for example taking
  • Said supplier notifies the selected PT (s) (E51) that then executes the commitment of said provider, in its place, in response to said WM, then notifies all the other PTs (E52, E53). ] as well as said provider that was non-responsive (El), from the new current state of the persistent persistent state.
  • any new WM issued to that provider for the same commitment can re-trigger the same process from step 3 in the case where said provider is non-responsive again.
  • the credibility of any commitment is related not only to aspects such as the amounts available, but also to the quantity of PTs in its PT-List weighted by the probable responsiveness of each PT.
  • the future beneficiary of a commitment automatically evaluates this credibility, and weights its value before acquiring this commitment, based on known responsiveness parameters associated with these PTs (releases from one WN to another).
  • the WN beneficiary of this commitment may itself be a PT (that is to say, be part of the PT-List of the same supplier and for the same commitment).
  • the state variables are synchronized to the recipient of the commitment who himself becomes able to perform this commitment of which he is the beneficiary.
  • a case of use of the non-responsiveness commitment recovery method, described above, is to use a given WN (E4) as a replacement WN of another WN (E1) typically of a same undertaking:
  • the commitment in question is simply: to transfer on request a balance of the other WN (El) which is the supplier of the said commitment, to the given WN (E4) which is the beneficiary of the said commitment and who issues this request.
  • it may be replaced by said given WN (E4), the balance being automatically transferred to said given WN (E4) even if said other WN (El) has become non-responsive.
  • E4) being itself a PT (of El), no other PT is necessary to ensure the replacement of WN.
  • the owner in question can provide several such WN replacement (E4) for the same other WN (El) and use any for the replacement.
  • a set of WNs can play the role of WNs replacing each other and becoming interchangeable.
  • the undertaking in question may provide that the said transfer may be for part of the balance, and that a number (given in the undertaking) of replacement WN must sign together for a transfer of an amount greater than a certain amount.
  • threshold multisignature of n among m WN, n and m being a function of the amount to be transferred).
  • the non-responsiveness commitment recovery method described above may be extended to ensure commitment also in the event of non-responsiveness.
  • the commitment provider (El) also communicates the hash of the commitment WP (as well as its content when missing) a step of cross verification of the synchronizations is added to the process, in the step "Non-Responsiveness Confirmation" (here renamed "Non-responsiveness or non-conformity notification"), the beneficiary of the commitment (E4) notifies the non-responsiveness -conformity, if any, of the provider WN (El) with respect to said commitment, at the "Delegated Execution” step, the processing of said WM by said selected acquirer (E51) includes a specific processing, provided for in the WP, to rectify has it the non-compliant WN, and a step is

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer And Data Communications (AREA)
  • Storage Device Security (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Un procédé d'établissement de poids de connexion entre nœuds d'un réseau est mis en œuvre par des unités de traitement informatiques communicantes, à chaque nœud étant associées une clé publique et une clé privée, un nœud donné étant susceptible de communiquer sa clé publique à un autre nœud, formant ainsi une connexion dite réelle (« IRL-connecté »] entre les deux nœuds, et chaque nœud étant également susceptible de communiquer à un autre nœud une clé publique reçue d'un autre nœud encore, formant ainsi une connexion dite indirecte entre l'autre nœud et l'autre nœud encore ? Chaque nœud est susceptible d'avoir un poids de connexion spécifique vis-à-vis d'un autre nœud avec lequel il a une connexion réelle ou indirecte. Le procédé comprend, pour déterminer le poids de connexion d'un deuxième nœud vis-à-vis d'un premier nœud, le calcul d'une combinaison déterminée de facteurs de pondération (influence, proximité] de troisièmes nœuds qui sont IRL-connectés au deuxième nœud.

Description

Titre
Procédés et systèmes mis en œuvre dans une architecture en réseau de nœuds susceptibles de réaliser des transactions basées sur messages Domaine de l'invention
La présente invention concerne des procédés et systèmes utiles dans une architecture en réseau, en général décentralisée, de nœuds susceptible de réaliser des transactions entre eux sur la base de messages. Arrière-plan de l'invention et résumé de l'invention
On notera ici que certaines parties de la description qui suit sont en langue anglaise, leur traduction fidèle en français étant à considérer comme faisant partie également de la description.
Par ailleurs, on se référera à la demande WO2016120826A2 au nom du demandeur, dont le contenu est incorporé ici par référence.
On connaît déjà le modèle de confiance décentralisé de PGP (Web-of-Trust, 1992] permettant à des pairs d'agir en tant qu'introducteurs et validateurs de clés publiques et proposant une métrique de validation décentralisée d'une identité numérique, qui se focalisa sur les adresses emails des pairs en question. Depuis, d'autres approches ont été proposées pour établir l'identité sans l'autorité de certification (telles que par Cari Ellison en 1996]. Par ailleurs, on connaît des procédés utilisant une approche « out of band channel » et nécessitant d'utiliser un terminal fiable pour réaliser un échange de clés publiques de manière sûre en présence du risque de « Man-in-the-Middle (MitM] attack », notamment le procédé SafeSlinger
[http://www.netsec.ethz.ch/publications/papers/farb_safeslinger_mobicom2013.pdf]
conçu pour optimiser le cas où chacun des utilisateurs d'un groupe, tel que dans un « key signing party », réalise un échange de clés avec tous les autres.
L'invention vise tout d'abord à permettre une identification décentralisée à la fois plus simples et d'un usage plus large, et répondant directement aux besoins de mise en œuvre d'engagements exécutables, de type « smart contracts » [https://en.wikipedia.org/wiki/Smart contract], aujourd'hui mis en œuvre sur des protocoles de consensus, notamment dans un environnement sans permission (« permissionless »] où n'importe qui peut se joindre et quitter dynamiquement, et où il n'y a aucune connaissance a priori des nœuds de consensus, en s'appuyant en général sur des puzzles informatiques [Dwork & Naor, 1992 : http://www.hashcash.org/papers/pyp.pdf ; Back, 2002 : http://www.hashcash.org/papers/hashcash.pdf] pour contrer les « sybil attacks » et avec l'hypothèse qu'une majorité de la puissance de calcul est détenue par des participants honnêtes [Nakamoto, 2008: https://bitcoin.org/bitcoin.pdf]. L'état de la technique en matière de smart contracts est principalement représenté par le système Ethereum
[https://github.com/ethereum/wiki/wiki/White-Paper],
On ne connaît pas de mise en œuvre de « smart contracts » (sans tiers de confiance] seulement basés sur du matériel (« hardware »] de fabricants de confiance.
L'invention vise plus précisément une telle mise en œuvre et de surcroît sur du hardware qui soit à la portée d'un grand nombre de fabricants, afin d'atteindre une décentralisation même au niveau des fabricants eux-mêmes, et vise en outre à proposer des mécanismes d'identification décentralisée qui permettent de mitiger les sybil attacks (lorsqu'un adversaire engendre un nombre quelconque de nouveaux nœuds qu'il contrôle dans le réseau].
Grâce au hardware, l'invention vise non seulement des avantages de rapidité (le consensus par blockchain est lent] et de coût (transaction cost], mais même des avantages qualitatifs. Notamment, l'article "Why Many Smart Contract Use Cases Are Simply Impossible" [http://www.coindesk.com/three-smart-contract-misconceptions/] présente des limitations d'Ethereum par rapport aux interactions avec le monde extérieur (voir en particulier sous « Contacting External Services »:
"Often, the first use case proposed is a smart contract that changes its behavior in response to some external event. For example, an agricultural insurance policy which pays out conditionally based on the quantity ofrainfall in a given month.
The imagined process goes something like this: The smart contract waits until the predetermined time, retrieves the weather report from an external service and behaves appropriately based on the data received.
This ail sounds simple enough, but it's also impossible. Why? Because a blockchain is a consensus-based System, meaning that it only works if every node reaches an identical state after processing every transaction and block.
Everything that takes place on a blockchain must be completely deterministic, with no possible way for différences to creep in. The moment that two honest nodes disagree about the chain 's state, the entire System becomes worthless.
Now, recall that smart contracts are executed independently by every node on a chain. Therefore, if a smart contract retrieves some information from an external source, this retrieval is performed repeatedly and separately by each node. But because this source is outside of the blockchain, there is no guarantee that every node will receive the same answer.
Perhaps the source will change its response in the time between requests from différent nodes, or perhaps it will become temporarily unavailable. Either way, consensus is broken and the entire blockchain dies.
So, what's the workaround? Actually, it's rather simple. Instead ofa smart contract initiating the retrieval of external data, one or more trusted parties ("oracles" créâtes a transaction which embeds that data in the chain. Every node will have an identical copy of this data, so it can be safely used in a smart contract computation."
L'invention pallie ce manque tout d'abord en permettant l'accès par un « Wallet Node » WN (voir WO2016120826A2], de manière sécurisée, à un site Web HTTPS quelconque directement (éliminant ainsi le besoin d'un smart contract "oracle"], en exploitant le protocole TLS de bout en bout. Cet accès peut être mis en œuvre sur une pluralité de nœuds "WN clones" aptes à accéder en redondance à une source de données. Concernant le risque de modification de la réponse par la source entre deux requêtes, les WN clones sont aptes à se coordonner pour traiter, selon des règles préconvenues (selon des paramètres de configuration], des cas de réponses différentes à de mêmes requêtes (selon des approches telles que prendre la majorité, la moyenne, etc.]— l'avantage essentiel apporté comparé aux nœuds d'Ethereum étant l'accès au réseau, évitant ainsi l'intermédiation par un tiers de confiance. L'article précité évoque ensuite le besoin d'émettre un message au monde extérieur :
"When it cornes to smart contracts causing events in the outside world, a similar problem appears. For example, many like the idea ofa smart contract which calls a bank's API in order to transfer money. But if every node is independently executing the code in the chain, who is responsible for calling this API? If the answer is just one node, what happens if that particular node malfunctions, deliberately or not?" L'invention pallie ce manque en permettant de mettre en œuvre un protocole fiable selon lequel exactement l'un des nœuds miroirs du nœud censé émettre un message au monde extérieur, émet ce message (voir plus loin section « WN émettant un message au monde extérieur »].
Dans les deux cas d'utilisation susmentionnés, la limitation intrinsèque des nœuds d'Ethereum par rapport au réseau va à rencontre de son but de décentralisation ; cf. article précité :
"they both require a trusted entity to manage the interactions between the blockchain and the outside world. While this is technically possible, it undermines the goal ofa decentralised System."
L'autre limitation importante d'Ethereum décrite par l'article précité est sa non-confidentialité intrinsèque : "// one smart contract can't access another's data, have we solved the problem of biockchain confidentiality? Does it make sensé to talk of hiding information in a smart contract? Unfortunately, the answer is no.
Because even if one smart contract can't read another's data, that data is still stored on every single node in the chain. For each biockchain participant, it's in the memory or disk of a System which that participant completely controls. And there's nothing to stop them reading the information from their own System, if and when they choose to do so."
Cette limitation forte d'Ethereum est palliée par la propriété de blindness (signifiant "confidentialité étendue au hardware"] des WN, obtenue par l'architecture hardware proposée par l'invention.
Les smart contracts d'Ethereum sont compris comme "cryptographie "boxes" that contain value and only unlock it if certain conditions are met" [phrase extraite du Ethereum White Paper déjà cité], alors que selon le système de l'invention, les smart contracts sont mis en œuvre comme des contrats exécutables "Wallet Program" (WP] entre nœuds (WN] du réseau de Wallet Nodes, et ayant les caractéristiques suivantes :
« les WN interagissent par messages "Wallet Message" [WM);
• chaque WM spécifiant le WP que le WN récepteur doit exécuter pour le traiter;
• un WM étant susceptible de comporter une ou plusieurs transactions de transfert de "valeurs" du WN émetteur vers le WN récepteur;
• valeurs qui appartiendront au WN récepteur (ou à tout le moins seront gérées par le WN récepteur] et qui pourra à son tour les transférer en générant d'autres transactions (dans le cadre de l'exécution d'un WP qui en général pourra être différent du WP spécifié dans le WM qui les lui a transférées],
• le système des WN comportant des moyens dans chaque WN pour empêcher un double-spend de ces valeurs, et
· un WN comprenant avantageusement des moyens pour réserver la consommation de ces valeurs à un ou plusieurs programmes WP habilités.
Néanmoins, lesdites "cryptographie boxes" peuvent aisément être construites sur des WN. Le système de l'invention marie ainsi la conception classique des contrats ["something that should be "fulfilled" or "complied with "") avec celle d'Ethereum {"rather, they are more like "autonomous agents" that live inside ofthe Ethereum exécution environment, always executing a spécifie pièce of code when "poked" by a message or transaction, and having direct control over their own ether balance and their own key /value store to keep track of persistent variables"] [phrases aussi tirées du Ethereum White Paper déjà cité].
Les nœuds WN sont comparables aux nœuds d'Ethereum : l'adresse d'un nœud Ethereum, déterminée à partir de la clé publique d'une paire de clés, est analogue à l'adresse d'un WN qui est déterminée à partir de la clé publique du WN en question. Dans un WN, un smart contrat est un code exécutable "Wallet Program" (identifié par son haché "#WP"], code compilable à partir d'un langage comme Solidity [http://solidity.readthedocs.io/en/develop/introduction-to-smart-contracts.html (incorporé ici par référence]] mais avec adaptations permettant que les WN aient accès au réseau, que les transactions générées par un WN puissent transférer des valeurs en n'importe quelles unités (et pas seulement des ethers], etc.
Alors que dans Ethereum une exécution de contrat est effectuée sur un grand nombre de nœuds (les mineurs] qui la valident, dans le cas des WN, lorsqu'un contrat (WP] est exécuté, le nœud sur lequel cette exécution a été provoquée est le seul qui l'exécute et a ses propres variables persistantes d'état. Les WN représentent un modèle plus général en ce sens que les variables persistantes d'un nœud sont d'un usage général, elle ne représentent pas uniquement un solde en ether et elles ne sont pas nécessairement des variables associées au contrat pour tous les nœuds qui l'exécutent (elles ne sont pas nécessairement les variables partagées constituant le key /value store d'un contrat Ethereum [voir la Ethereum White Paper déjà cité]]. Les WN garantissent l'intégrité d'exécution par des contraintes hardware et, avantageusement, par de la redondance (pour encore plus de sécurité], ledit nœud étant alors un nœud virtuel matérialisé par une pluralité de nœuds miroirs mémorisant, manipulant et maintenant de manière synchronisée les variables spécifiques audit nœud virtuel.
II est utile de se référer à la description de la Figure 23 au début de la section « description détaillée de formes de réalisation préférées ».
L'invention vise par ailleurs à permettre d'exécuter des smarts contracts (WP] sur des WN en utilisant la blockchain Bitcoin (ou autre blockchain], en ne générant et n'insérant dans la blockchain que certaines des transactions, sur instruction des WN concernés, ce qui offre le triple avantage d'avoir la puissance des smart contracts sur Bitcoin, d'éviter la lenteur de son protocole de consensus et de ne pas payer de transaction fees (pour les transactions qui ne sont pas insérées dans la blockchain]. La section « Transactions Bitcoin off-chain » décrit un procédé permettant de faire consommer des unités de valeurs (telles que des bitcoins ou des ethers] par différents types de programmes WP, procédé qui confère ainsi à un système basé sur Bitcoin la puissance des smart contracts d'un système tel que Ethereum.
Le protocole Bitcoin nécessite d'attendre des confirmations de transactions bloc par bloc qui, selon l'approche adoptée, prennent aujourd'hui de l'ordre de quelques secondes à la dizaine de minutes chacune et impliquent des volumes de transactions limités. Ethereum et le procédé tel que décrit dans FR 3 018 377 Al au nom du demandeur, permettent l'exécution décentralisée de contrats exécutables. La technologie Sidechains a été conçue pour essentiellement permettre de gérer des engagements et transactions de manière autre que celle prévue dans Bitcoin et pouvoir revenir au protocole Bitcoin d'origine à souhait [https://blockstream.com/sidechains.pdf] (ce que permet en substance l'invention]. Plus récemment ont été proposés en complément de ces systèmes, des « state-channel networks » tels que « Lightning Network » [https://lightning.network/lightning-network-paper.pdf], et « Payment-Channel Network » [http://raiden.network ] pour Ethereum, pour éviter de nécessairement utiliser la blockchain pour chaque transaction. Cette approche implique que les nœuds surveillent la blockchain pour réagir en cas d'insertion de transactions qui ne reflètent pas l'état courant, pour rectifier, ce qui nécessite de mettre en œuvre des verrous sécurisant une fenêtre temporelle d'observation, engendrant une certaine lenteur. L'invention pallie cette difficulté du fait de la garantie d'intégrité d'exécution des WP qu'elle offre d'emblée : les transactions insérées générées par WN ne nécessitent pas de surveillance.
On notera par ailleurs que le hardware proposé selon l'invention permet d'assurer un traitement sans divulgation, propriété (appelée « confidentialité »] offerte notamment par les environnements sécurités tels que les nouveaux processeurs Intel pour leurs environnements (enclaves] sécurisés « SGX », et l'on connaît des recherches sur le chiffrement homomorphique pour le traitement sur le Cloud offrant des garanties d'intégrité d'exécution et de non-divulgation des données traitées ni-même du code exécuté. Toutefois la technologie de chiffrement homomorphique est en phase de recherche et pas encore opérationnelle sauf dans des cas restreints ou particuliers.
Rappelons que la demande WO2016/120826 A2 décrit un système-sur-puce (SoC, appelé « Wallet Node », ou « WN », ou encore « entité »] intégré à - ou couplé avec - un dispositif connecté tel qu'un smartphone, un objet connecté de l'Internet des Objets (IoT] ou encore un ordinateur, offrant des garanties d'intégrité d'exécution dans la mesure où les restrictions d'accès entre ses différentes parties ne peuvent pas être altérées ou contournées. Essentiellement, la seule exécution possible d'un WN est de réagir à un message entrant, en en vérifiant son intégrité et en exécutant ensuite le code exécutable "Wallet Program" correspondant au haché spécifié dans ce message. En référence à cette demande PCT, dans le présent texte, par "message" on entend "Wallet Message" sauf lorsqu'il est explicite que ce n'est pas le cas.
On propose selon un premier aspect un procédé d'établissement de poids de connexion entre nœuds d'un réseau mis en œuvre par des unités de traitement informatiques communicantes, à chaque nœud étant associées une clé publique et une clé privée, un nœud donné étant susceptible de communiquer sa clé publique à un autre nœud, formant ainsi une connexion dite réelle (« IRL-connecté »] entre les deux nœuds, et chaque nœud étant également susceptible de communiquer à un autre nœud une clé publique reçue d'un autre nœud encore, formant ainsi une connexion dite indirecte entre l'autre nœud et l'autre nœud encore, un nœud étant susceptible d'avoir un poids de connexion spécifique vis-à-vis d'un autre nœud avec lequel il a une connexion réelle ou indirecte, le procédé comprenant, pour déterminer le poids de connexion d'un deuxième nœud vis-à-vis d'un premier nœud, le calcul d'une combinaison déterminée de facteurs de pondération (influence, proximité] de troisièmes nœuds qui sont IRL-connectés au deuxième nœud.
Avantageusement mais facultativement :
* le poids de connexion du deuxième nœud influence les facteurs de pondération des troisièmes nœuds, et comprenant en outre une mise à jour des valeurs des facteurs de pondération des troisièmes nœuds après calcul du poids de connexion du deuxième nœud.
* le procédé est mis en œuvre de façon itérative jusqu'à convergence.
* l'établissement d'une connexion dite réelle (IRL-connexion] entre un premier nœud et un autre nœud comprend les étapes suivantes :
au niveau d'une première unité de traitement implémentant le premier nœud, rendre accessible par lecture de proximité un code lisible par machine codant une donnée aléatoire (nonce] ; au niveau d'une autre unité de traitement implémentant l'autre nœud, lire le code lisible par machine, extraire ladite donnée aléatoire et calculer un haché de ladite donnée aléatoire,
transmettre de ladite autre unité de traitement vers la première unité de traitement via un canal de communication la clé publique associée audit autre nœud et une signature (du haché] de la donnée aléatoire effectuée avec sa clé privée,
au niveau de la première unité de traitement, vérifier ladite signature à l'aide de la clé publique reçue et de la donnée aléatoire utilisée pour générer le code lisible par machine, et enregistrer ladite clé publique si la vérification aboutit.
* l'établissement d'une connexion dite réelle (IRL-connexion] entre un premier nœud et un autre nœud comprend les étapes suivantes :
au niveau d'une première unité de traitement implémentant le premier nœud, générer un passphrase et le rendre accessible à l'utilisateur de ladite première unité de traitement,
au niveau d'une autre unité de traitement implémentant l'autre nœud, introduire en entrée ledit passphrase, communiqué par l'utilisateur de la première unité de traitement à l'utilisateur de l'autre unité de traitement par une voie de communication mettant en jeu une action humaine entre les deux utilisateurs,
transmettre de ladite autre unité de traitement vers le première unité de traitement via un canal de communication la clé publique associée audit autre nœud et une signature (du haché] du passphrase introduit, effectuée avec sa clé privée,
au niveau de la première unité de traitement, vérifier ladite signature à l'aide de la clé publique reçue et du passphrase initialement rendu accessible à l'utilisateur de la première unité de traitement, et enregistrer ladite clé publique si la vérification aboutit.
* une pluralité de deuxièmes nœuds ont des poids de connexion avec le premier nœud, et dans lequel la détermination du poids de connexion d'un deuxième nœud donné vis-à-vis du premier nœud est également basée sur les poids de connexions desdits autres deuxièmes nœuds vis-à-vis du premier nœud
On propose selon un deuxième aspect un procédé de détermination de l'influence d'un premier nœud dans un réseau de nœuds mis en œuvre par des unités de traitement informatiques communicantes, à chaque nœud étant associées une clé publique et une clé privée, un nœud étant susceptible de communiquer sa clé publique à un autre nœud, formant ainsi une connexion dite réelle (IRL- connexion] entre les deux nœuds, et chaque nœud étant également susceptible de communiquer à un autre nœud une clé publique reçue d'un autre nœud encore, formant ainsi une connexion dite indirecte entre l'autre nœud et l'autre nœud encore, le procédé comprenant la détermination d'un facteur influence d'un nœud donné sur la base du nombre de deuxièmes nœuds ayant une connexion réelle avec ledit nœud donné et des valeurs de poids de connexion déterminées par le procédé de la dans lequel une pluralité de deuxièmes nœuds ont des poids de connexion avec le premier nœud, et dans lequel la détermination du poids de connexion d'un deuxième nœud donné vis-à-vis du premier nœud est également basée sur les poids de connexions desdits autres deuxièmes nœuds vis-à-vis du premier nœud, pour les différents deuxièmes nœuds.
Avantageusement mais facultativement :
* le poids de connexion d'un deuxième nœud vis-à-vis du premier nœud est déterminé aussi sur la base de valeurs des facteurs influence respectifs des troisièmes nœuds ayant une connexion réelle avec ledit deuxième nœud.
* les valeurs de poids de connexion et de facteur influence sont déterminées itérativement jusqu'à leurs convergence en des valeurs qui ne varient plus de manière significative.
On propose selon un troisième aspect un procédé pour établir des connexions dites quasi-réelles entre nœuds d'un réseau mis en œuvre par des unités de traitement informatiques communicantes, à chaque nœud étant associées une clé publique et une clé privée, un nœud donné étant susceptible de communiquer sa clé publique à un autre nœud, formant ainsi une connexion dite réelle (« IRL- connecté »] entre les deux nœuds, et chaque nœud étant également susceptible de communiquer à un autre nœud une clé publique reçue d'un autre nœud encore, formant ainsi une connexion dite indirecte entre l'autre nœud et l'autre nœud encore, chaque nœud étant susceptible d'avoir un poids de connexion spécifique vis-à-vis d'un autre nœud avec lequel il a une connexion réelle ou indirecte, le comprenant les étapes suivantes :
à partir d'un premier nœud et d'un deuxième nœud entre lesquels une connexion doit être établie, sélectionner une pluralité de nœuds intermédiaires entre le premier nœud et le deuxième nœud, parmi ceux présentant les plus grands poids de connexion vis-à-vis du premier nœud,
communiquer à partir du premier nœud vers les nœuds intermédiaires sélectionnés une donnée aléatoire (nonce] destinée à être communiquée au deuxième nœud,
via un ou plusieurs canaux de communication distincts du canal de communication entre nœuds, communiquer de façon redondante à partir des nœuds intermédiaires vers le deuxième nœud ledit code aléatoire ainsi que les clés publiques desdits nœuds intermédiaires,
au niveau du deuxième nœud, en réponse à la réception du code aléatoire en redondance, générer une signature du code aléatoire à l'aide de la clé privée du deuxième nœud et retourner vers les nœuds intermédiaire ladite signature ainsi que la clé publique du deuxième nœud, chiffrée à l'aide des clés publiques des nœuds intermédiaires, respectivement,
au niveau de chacun des nœuds intermédiaires, vérification de la signature du code aléatoire reçue du deuxième nœud et, en cas de succès, communication au premier nœud de la clé publique du deuxième nœud, chiffrée à l'aide de la clé publique du premier nœud, et
au niveau du premier nœud, déchiffrement et mémorisation de la clé publique du deuxième nœud,
les premier et deuxième nœuds pouvant alors s'échanger des informations chiffrées avec une sécurité liée aux poids de connexion des nœuds intermédiaires.
Avantageusement mais facultativement :
* la sélection des nœuds intermédiaire s'effectue également parmi ceux présentant les plus grands poids de connexion vis-à-vis du deuxième nœud.
* le code aléatoire est généré conjointement par un ensemble de nœuds formés par le premier nœud et par les nœuds intermédiaires, par la mise en œuvre des étapes suivantes :
génération d'un code aléatoire au niveau de chaque nœud de l'ensemble, échange entre les nœuds de l'ensemble, avec chiffrement à l'aide des clés respectives des nœuds, de hachés desdits codes aléatoires,
échange entre lesdits nœuds de l'ensemble, avec chiffrement à l'aide des clés respectives des nœuds, des codes aléatoires tels quels,
vérification au niveau de chaque nœud de l'ensemble que le code aléatoires tels quels correspondent bien à leurs hachés respectifs reçus à l'étape précédente, et
génération d'un code aléatoire final destiné à être communiqué au deuxième nœud par combinaison prédéterminée des codes aléatoires générés au niveau de chaque nœud de l'ensemble.
* ledit canal de communication distinct est basé sur un réseau social, et comprenant une étape de publication par le deuxième nœud sur ledit réseau social d'une signature dudit code aléatoire et sa clé publique.
* le procédé comprend en outre, en réponse au succès de l'étape de vérification de la signature du code aléatoire reçue du deuxième nœud, une étape d'attribution d'un poids de connexion du deuxième nœud vis-à-vis du premier nœud.
* le procédé selon le premier aspect est mis en œuvre dans un réseau comprenant des nœuds à connexions quasi-réelles établies selon le troisième aspect , et les connexions quasi-réelles sont considérés comme des connexions réelles au sens du procédé, avec un poids tenant compte du caractère quasi-réel de la connexion.
Selon un quatrième aspect, on propose un procédé pour sécuriser le fonctionnement d'un réseau de nœuds aptes à exécuter des programmes (WP] en réponse à la réception de messages (WM], les nœuds étant susceptibles d'être liés entre eux selon des poids de connexion différents déterminés par le procédé selon le premier aspect ou par le procédé selon le troisième aspect, le procédé comprenant, lors de la réception d'un message (WM] au niveau d'un nœud récepteur, la comparaison du poids de connexion du nœud ayant émis ce message avec les poids de connexion d'autres nœuds avec lesquels le nœud récepteur possède des connexions réelles, et l'acceptation dudit message seulement si le poids de connexion du nœud émetteur est égal ou supérieur au plus petit desdits poids de connexion. Selon un cinquième aspect, on propose un procédé pour sécuriser le fonctionnement d'un réseau de nœuds aptes à exécuter des programmes (WP] en réponse à la réception de messages (WM], les nœuds étant susceptibles d'être liés entre eux selon des poids de connexion différents obtenus notamment par le procédé selon le premier aspect ou par le procédé selon le troisième aspect où, en réponse au succès de l'étape de vérification de la signature du code aléatoire reçue du deuxième nœud, on prévoit une étape d'attribution d'un poids de connexion du deuxième nœud vis-à-vis du premier nœud, comprenant les étapes suivantes :
sur la base des valeurs de poids de connexion, affecter à chaque nœud au moins un nœud contresignataire ayant vis-à-vis de lui un poids de connexion supérieur à un seuil,
au niveau de chaque nœud, maintenir une liste de nœuds contresignataires de nœuds susceptibles de recevoir des messages (WM] à partir du nœud en question, chaque nœud et ses nœuds contresignataires formant un ensemble de nœuds miroirs,
lorsqu'un message doit être envoyé par un nœud émetteur à un nœud destinataire, provoquer l'envoi de ce message par au moins certains des nœuds miroirs du nœud émetteur vers au moins certains des nœuds miroirs du nœud destinataire,
valider le message seulement si une fraction donnée des messages émis a été reçue.
Avantageusement mais facultativement :
* les messages sont émis vers tous les nœuds miroirs du nœud destinataire.
* les messages sont émis par le nœud émetteur ainsi que par les seuls nœuds contresignataires du nœud émetteur qui sont également contresignataires du nœud destinataire.
* un message envoyé d'un premier nœud à un second nœud n'est validé par le second nœud que si les ensembles respectifs de nœuds miroirs des premiers et deuxième nœuds ont une intersection dont le nombre d'éléments est supérieur à un certain seuil et si le second nœud a reçu ce même message (en redondance] de la part d'au moins une fraction donnée desdits nœuds miroirs appartenant à cette intersection.
* dans un procédé selon le premier aspect mise en œuvre dans un réseau comprenant des nœuds miroirs selon le cinquième aspect, un nœud est considéré comme contresignataire d'un nœud donné seulement si le poids de connexion du nœud en question est au moins égal au plus petit des poids de connexion des nœuds ayant des connexions réelles avec le nœud donné.
On propose selon un sixième aspect un système pour sécuriser le fonctionnement d'un réseau de nœuds aptes à exécuter des programmes (WP] en réponse à la réception de messages [WM], les nœuds étant susceptibles d'être liés entre eux selon des poids de connexion différents, apte à :
sur la base des valeurs de poids de connexion, affecter à chaque nœud au moins un nœud contresignataire ayant vis-à-vis de lui un poids de connexion supérieur à un seuil,
au niveau de chaque nœud, maintenir une liste de nœuds contresignataires de nœuds susceptibles de recevoir des messages à partir du nœud en question, chaque nœud et ses nœuds contresignataires formant un ensemble de nœuds miroirs,
lorsqu'un message doit être envoyé par un nœud émetteur à un nœud destinataire, provoquer l'envoi de ce message par au moins certains des nœuds miroirs du nœud émetteur vers au moins certains des nœuds miroirs du nœud destinataire.
Avantageusement mais facultativement :
* un nœud destinataire d'un message (WM] ne le valide que seulement si les ensembles respectifs de nœuds miroirs des nœuds émetteur et destinataire ont une intersection dont le nombre d'éléments est supérieur à un seuil donné et si le nœud destinataire a reçu ce même message (en redondance] de la part d'au moins une fraction donnée desdits nœuds miroirs appartenant à cette intersection.
On propose selon un septième aspect un système pour sécuriser le fonctionnement d'un réseau de nœuds constitués par des systèmes sur puce aptes à exécuter des programmes (WP] en réponse à la réception de messages (WM], caractérisé en ce qu'il comprend en combinaison les deux architectures suivantes :
- au niveau de chaque nœud, une architecture d'accès à des programmes chiffrés sur la base de hachés de ces programmes, contenus dans les messages entrants,
- au niveau de chaque nœud, une architecture de détermination de nœuds contresignataires, de duplication des messages de/vers les nœuds contresignataires, et de détermination du caractère identique des messages reçus.
On propose selon un huitième aspect un système pour l'exécution sécurisée de programmes dans une architecture comprenant un ensemble d'équipements reliés en réseau, caractérisé en ce qu'il comprend dans au moins un équipement, un système-sur-puce (SoC] sécurisé dans lequel est mémorisé de façon inaccessible autrement que par le SoC une clé privée de SoC, ou le SoC est apte à dynamiquement régénérer cette clé privée (technologie PUF],
un SoC pouvant communiquer avec un autre équipement uniquement par des messages et étant apte à exécuter des programmes seulement en réponse à la réception de messages,
un SoC étant apte à mémoriser au moins un programme à exécuter après chiffrement par le SoC et à générer un haché du ou de chaque programme permettant de retrouver le programme chiffré, l'équipement étant apte en outre à adresser au SoC un message contenant des données d'entrée (data] pour un certain programme à exécuter, ainsi que le haché dudit programme (#P2], le SoC étant apte, en réponse à un tel message, de façon sécurisée, (i] accéder au programme chiffré à exécuter à partir du haché (#P2] du programme reçu dans le message, (ii] déchiffrer à la volée les instructions du programme, et (iii] exécuter à la volée les instructions déchiffrées.
Avantageusement mais facultativement :
* avant émission d'un message par le SoC, le SoC insère le haché (#P1] du programme en cours d'exécution dans le message à émettre, ainsi que la signature de ce haché au moyen de ladite clé privée secrète du SoC. * avant émission d'un message par le SoC, le SoC insère le haché (#P1] du programme en cours d'exécution dans le corps du message à émettre que le SoC signe au moyen de la clé privée secrète du SoC.
* le SoC comprend une unité de gestion cryptographique de mémoire (CMMU, Crypto Memory Management Unit] dans lequel est mémorisé - ou apte à dynamiquement régénérer (technologie PUF]
- la clé secrète du SoC qui n'est accessible que par l'unité CMMU qui ne la dévoile jamais, et c'est par cette unité CMMU que sont effectués :
ledit chiffrement du programme avant mémorisation,
une allocation d'adresse mémoire (addrl..addr2 range] pour le programme ainsi chiffré, - ladite génération du haché du programme et
ledit décryptage pour exécution à la volée par au moins une unité processeur comprise dans le
SoC.
* l'unité CMMU effectue chiffrement et mise en mémoire bloc d'instructions par bloc d'instructions et fournit audit processeur un seul bloc d'instructions déchiffré à la fois, pour leur exécution à la volée. * avant émission d'un message par le SoC, l'unité CMMU insère le haché (#P1] du programme en cours d'exécution dans le message à émettre, ainsi que la signature de ce haché par le CMMU au moyen de ladite clé privée secrète du SoC.
* avant émission d'un message par le SoC, l'unité CMMU insère le haché (#P1] du programme en cours d'exécution dans le corps du message à émettre qu'elle signe au moyen de la clé privée secrète du SoC. * un SoC est apte à émettre un message ayant un même haché pour le programme en cours d'exécution (#P1] et pour le programme à exécuter par le destinataire (#P1 = #P2], ce programme (PI = P2] étant un engagement exécutable (smart contract] dans le cas où le destinataire dudit message est un SoC. On propose selon un neuvième aspect un système-sur-puce SoC destiné à former un nœud Wallet Node (WN] d'un réseau, comprenant une unité de gestion cryptographique de mémoire avec chiffrement (CMMU] apte à assurer une exécution en aveugle (blind] de programmes par au moins un processeur du SoC, dans lequel :
* dans l'unité CMMU est mémorisée (ou dynamiquement régénérée] de façon inaccessible autrement que par l'unité CMMU une clé privée (clé secrète],
* l'unité CMMU est apte à mémoriser au moins un programme à exécuter après chiffrement par l'unité CMMU et à générer un haché du ou de chaque programme permettant de retrouver le programme chiffré,
* ledit processeur n'est apte à exécuter des programmes que sur commande de l'unité CMMU,
* les interactions entre le système-sur-puce et d'autres nœuds du réseau s'effectuent exclusivement par messages et les messages sont reçus/émis par l'unité CMMU exclusivement, · les messages comprennent l'identification d'un certain programme à exécuter, identifié par son haché,
* en réponse à la réception d'un message, l'unité CMMU (i] accède au programme chiffré à exécuter à partir du haché du programme reçu dans le message (notamment via une table PHT], (ii] déchiffre les instructions du programme, et (iii] transmet au processeur pour exécuter les instructions déchiffrées sur lesdites données reçues.
Avantageusement mais facultativement :
* le ou au moins un processeur est apte à accéder à, et à manipuler (création, mise-à-jour, suppression], via l'unité CMMU, des variables persistantes d'état (PSV] associées à un programme donné, lesquelles sont également chiffrées et stockées en mémoire par l'unité CMMU et déchiffrées à la volée.
* ledit programme à exécuter et ses variables persistantes d'état (PSV] sont mémorisés dans un espace d'adressage spécifique assurant leur isolement par rapport aux autres programmes.
* un message est susceptible de contenir une ou plusieurs transactions de transfert d'unités de compte (UA] d'un nœud émetteur vers un nœud récepteur, les unités de compte reçues par un nœud récepteur étant susceptibles d'être à nouveau transférées par une transaction contenue dans un message émis par ledit nœud récepteur.
* le procédé comprend un espace de mémoire pour des unités de compte (tags] reçues par des transactions.
* le procédé est apte à combiner des unités de compte de différents tags dans une même transaction à émettre, aptes à être combinées et transférées entre SoCs.
* l'unité CMMU comprend des moyens neutralisation d'un tag qui alimente une transaction émise, de telle sorte que les UA ainsi consommées ne puissent être consommées par une autre transaction.
* l'unité CMMU comprend des moyens de contrôle de l'utilisation des tags par les différents programmes, de telle sorte que seul un programme habilité puisse alimenter une transaction à générer à partir d'un tag donné.
* ladite mémoire est dans le SoC.
* ladite mémoire est séparée du SoC.
* un programme peut alternativement être déclenché sur écoulement d'un timeout pour un programme donné et l'unité CMMU est également apte, sur survenance d'un timeout associé au haché d'un programme (i] à accéder en mémoire au programme chiffré à partir de ce haché, (ii] déchiffrer les instructions du programme, et (iii] transmettre au processeur pour exécution les instructions déchiffrées.
*l'unité CMMU effectue lesdits chiffrement et mise en mémoire bloc d'instructions par bloc d'instructions et fournit audit processeur un seul bloc déchiffré à la fois, pour exécution à la volée.
* avant émission d'un message, l'unité CMMU insère le haché (#P1] du programme en cours d'exécution dans le message à émettre, ainsi que la signature de ce haché par le CMMU au moyen de ladite clé privée secrète.
* avant émission d'un message, l'unité CMMU insère le haché (#P1] du programme en cours d'exécution dans le corps du message à émettre qu'elle signe au moyen de ladite clé privée secrète.
* l'unité CMMU est apte à émettre un message ayant un même haché pour le programme en cours d'exécution (#P1] et pour le programme (#P2] à exécuter par le destinataire (#P1 = #P2], ce programme (PI = P2] étant ainsi un engagement exécutable (smart contract] dans le cas où le destinataire dudit message est aussi un SoC où, avant émission d'un message par le SoC, le SoC insère le haché (#P1] du programme en cours d'exécution dans le message à émettre, ainsi que la signature de ce haché au moyen de ladite clé privée secrète du SoC.
* certains messages [WM] constituent des messages de transfert de tags mémorisés dans des systèmes avec un espace de mémoire pour des unités de compte (tags] reçues par des transactions, et la validation d'un message de transfert de tag au niveau d'un nœud destinataire est réalisée seulement s'il existe en intersection entre l'ensemble des nœuds miroirs du nœud destinataire et l'ensemble des nœuds miroirs de chacun des nœuds amonts à partir desquels un tel tag a été initialement transféré un nombre de nœuds supérieur à un seuil donné.
On propose selon un dixième aspect un procédé pour garantir les engagements d'un système-sur-puce (WN) dans une architecture de systèmes-sur-puce (WN) aptes à transférer entre eux des unités de compte via des messages (WM], pour le cas un tel système-sur-puce deviendrait non-responsif, comprenant les étapes suivantes :
(a] lors d'un engagement (quelconque] d'un WN fournisseur de cet engagement (El] à un WN bénéficiaire de cet engagement (E ], mettre à disposition du WN bénéficiaire (E4] une liste « PT-List » (Potentiel Transférées List] de WN repreneurs potentiels (E51, E52, E53] en cas de non- responsiveness dudit WN fournisseur (El] ;
(b] synchroniser à partir dudit WN fournisseur (El] l'état (PST] de l'engagement en question vers tous les WN repreneurs potentiels (E51, E52, E53].
(c] suite à l'envoi d'un message (WM] par ledit WN bénéficiaire (E4] audit WN fournisseur (El], constater au niveau dudit WN bénéficiaire (E4] la non-responsivité dudit WN fournisseur (El], (d] déterminer au niveau dudit WN bénéficiaire (E ] un WN repreneur qui a priorité (E51] parmi les WN repreneurs potentiels de ladite liste (PT-List],
(e] traiter ledit message (WM) au niveau dudit WN repreneur prioritaire (E51], ce dernier synchronisant ensuite l'état (PST] de l'engagement en question vers les autres WN repreneurs potentiels (E52, E53] ainsi que vers ledit WN fournisseur qui était non-responsif (El],
(f] pour un message (WM] ultérieur émis par un WN bénéficiaire d'un engagement dudit WN fournisseur qui était non-responsif (El], si ce dernier est toujours non-responsif, exécuter le même procédé à partir de l'étape (c].
On propose selon un onzième aspect un système transactionnel à architecture répartie en peer-to- peer, mettant en œuvre 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, chaque transaction pouvant être validée par insertion, dans une chaîne de blocs mémorisée de façon répartie entre les nœuds, d'une signature de la transaction, , caractérisé en ce qu'au moins certaines des transactions sont réalisées par des nœuds aptes à assurer une condition de blindness desdites transactions, en ce qu'il comprend des moyens pour traiter un ensemble de transactions satisfaisant à la condition de blindness de manière à simplifier cet ensemble en fonction des quantités d'unités de compte et des adresses des nœuds émetteurs et des nœuds récepteurs impliqués dans ces transaction, pour générer un ensemble de transactions réduit, et pour ne générer et mémoriser dans la chaîne de blocs que les signatures de transactions de l'ensemble de transactions réduit.
On propose selon un douzième aspect un système transactionnel à architecture répartie en peer-to- peer, mettant en œuvre 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, chaque transaction pouvant être validée par insertion, dans une chaîne de blocs mémorisée de façon répartie entre les nœuds, d'une signature de la transaction,, caractérisé en ce qu'au moins certaines des transactions sont réalisées par des nœuds aptes à assurer une condition de blindness desdites transactions, en ce qu'il comprend des moyens pour traiter un ensemble de transactions satisfaisant à la condition de blindness de manière à simplifier cet ensemble en fonction des quantités d'unités de compte et des adresses des nœuds émetteurs et des nœuds récepteurs impliqués dans ces transaction, pour générer un ensemble de transactions réduit, et pour ne générer et mémoriser dans la chaîne de blocs que certaines des signatures dudit ensemble réduit et que sur instruction des nœuds concernés.
On propose selon un treizième aspect un procédé pour réaliser une transaction entre nœuds d'un réseau associés à des utilisateurs et susceptibles de transférer entre eux des unités de comptes et capables de communiquer entre eux par messages, chaque message désignant un programme WP à exécuter dans le nœud récepteur de ce message, et les utilisateurs étant capables de diffuser des éléments d'offres comprenant un ou plusieurs critères d'offres et susceptibles de donner lieu à des transactions sur le réseau, le procédé comprenant les étapes suivantes :
- envoi par un nœud offreur à un nœud demandeur d'un utilisateur ayant émis des éléments d'offre correspondants, d'un message d'offre de fourniture répondant au(x] critère(s] et engageant ledit nœud, et identifiant un programme WP donné,
- envoi par le nœud demandeur au nœud offreur d'un message d'acceptation de l'offre de fourniture, identifiant le même programme WP donné,
- génération d'une attestation de réalisation, d'existence ou mise à disposition de la fourniture accessible par le nœud offreur, susceptible d'être vérifiée par ledit programme WP donné, - vérification de l'attestation par le programme WP donné au niveau de l'un des deux nœuds au moins, et
- si la vérification réussit, génération au niveau du nœud demandeur d'un message de transfert d'unités de compte constituant la contrepartie de la fourniture et envoi de ce message au nœud offreur.
Selon un autre aspect avantageux, dans un procédé selon le second aspect mis en œuvre dans un réseau comprenant des nœuds à connexions quasi-réelles établies selon le procédé selon le troisième aspect, les connexions quasi-réelles sont considérés comme des connexions réelles au sens du procédé, avec un poids tenant compte du caractère quasi-réel de la connexion.
Brève description des dessins
D'autres aspects, buts et avantages des systèmes et procédés décrits ici apparaîtront clairement à la lumière de la description détaillée qui suit, donnée à titre d'exemple et faite en référence aux dessins annexés, sur lesquels :
Les Figures la, lb et 2a, 2b présentent des procédés de calcul de poids de connexion des nœuds de l'entourage de l'utilisateur.
Les Figures 3a à 3d présentent schématiquement des envois de messages entre nœuds miroirs. La Figure 4 illustre une utilisation d'une variable persistante d'état (tag] par deux programmes WP sur un Wallet Node.
Les Figures 5a et 5b présentent schématiquement des transactions de transfert de tags.
La Figure 6 présente schématiquement le comportement des nœuds miroirs dans le cas d'une chaîne de messages transmettant des transactions de transfert de tags.
La Figure 7 illustre un message comportant une spécification de l'ensemble des hash des codes exécutables valides.
La Figure 8 illustre la propagation d'accusés de réception entre Wallet Nodes.
La Figure 9 présente schématiquement un exemple de paiements effectués entre Wallet Nodes par transactions Bitcoin abstraites.
Les Figures 10 à 15 présentent schématiquement les transactions Bitcoin réelles correspondant aux transactions abstraites de la Figure 9.
La Figure 16 présente schématiquement un autre exemple de paiements effectués entre Wallet
Nodes par transactions Bitcoin abstraites.
Les Figures 17 à 19 présentent schématiquement les transactions Bitcoin réelles correspondant aux transactions abstraites de la Figure 16.
La Figure 20 présente schématiquement le procédé pour garantir les engagements d'un Wallet Node qui deviendrait non-responsive.
La Figure 21 présente schématiquement un SoC comprenant une unité CMMU recevant un programme exécutable.
La Figure 22 présente schématiquement un SoC comprenant une unité CMMU recevant un message comprenant des données d'entrée pour un programme à exécuter.
La Figure 23 présente l'architecture générale d'un Wallet Node.
Description détaillée de formes de réalisation préférées
Dans la suite, le terme "utilisateur" pourra désigner, selon le contexte, un nœud particulier d'un réseau, chaque nœud possédant une paire de clés cryptographiques. Par ailleurs, le terme "utilisateur", sauf lorsque l'on parle explicitement d'un utilisateur humain, peut désigner un dispositif ou un programme qui lui est associé. Par exemple, une indication du type « l'utilisateur A envoie à l'utilisateur B telle donnée » signifiera que « le dispositif ou programme associé à l'utilisateur A envoie telle donnée au dispositif ou programme associé à l'utilisateur B ». Enfin, vis-à-vis d'un dispositif ou programme donné, le terme « utilisateur » peut dans certains cas désigner un autre dispositif ou programme.
On va maintenant décrire une certain nombre d'aspects d'un tel réseau où les nœuds sont des « Wallet Nodes » WN associés respectivement à des utilisateurs U et capables de communiquer entre eux par des « Wallet Messages » WM en vue de matérialiser différents types de transactions ou d'engagements (typiquement de type smart contracts] touchant les utilisateurs U auxquels sont associés les WN. Ces WN constituent les nœuds d'un graphe avec des liaisons entre les WN constituant les arêtes du graphe.
Les WN peuvent être de différents types (soft ou hard] et les liaisons entre WN peuvent être notées ou pondérées. Un message WM ne peut être envoyé par un WN d'origine à un WN de destination que si la liaison entre les deux WN considérés satisfait à une certaine notation et/ou pondération.
Un exemple d'un tel réseau est décrit dans la demande PCT WO2016120826A2 au nom du demandeur, dont le contenu est incorporé ici par référence. On utilise les termes « entité », « Wallet Node », « WN » ou simplement « nœud » pour désigner un nœud d'un tel réseau, et un tel nœud est identifié par sa clé publique ou une adresse qui en est dérivée, ces termes « clé », « adresse » pouvant être utilisé pour signifier identifiant d'un nœud, et réciproquement.
La Figure 23 présente l'architecture d'un WN. En référence à cette figure, les messages "Quasi-WM" sont des messages (en réception] qui ne sont pas émis par un WN mais dont le format est le même, en ce sens que, comme les WM, ils contiennent le haché du WP à exécuter sur réception du message. Ainsi, par exemple, lorsque l'utilisateur initie une transaction (via son terminal auquel est couplé le WN], son message "Quasi-WM" comporte le haché du WP de génération de cette transaction (cette information étant automatiquement ajoutée par le terminal]. Autre exemple, lorsqu'un WP sous-traite un traitement "non léger" (voir ci-dessous] à un ordinateur distant, le résultat lui est retourné sous la forme d'un message "Quasi-WM" comportant le haché du WP qui le lui a sous-traité.
Avantageusement, cette architecture prévoit que les traitements du processeur (PROCESSOR] sont légers et que les émissions de messages WM et Non-WM sont non-bloquants :
• Non-bloquant: Une réponse d'un WN par rapport à un WM est un autre WM qui fait référence au premier. N'est pas bloquante non plus l'exécution d'un WP en attente de la réponse de "User" ou "Network" à un message "Non-WM" émis— "User" étant le terminal de l'utilisateur (tel qu'un ordinateur] et "Network" représentant un dispositif distant (tel qu'un ordinateur]— ces messages étant des appels asynchrones dont le retour (callback] est transformé en un message "Quasi-WM".
• Léger: Lorsqu'un WP doit effectuer un traitement qui n'est pas léger (par exemple, multiplier deux matrices d'une centaine de lignes fois une centaine de colonnes], il le sous-traite (par un message "Non-WM") à un ordinateur apte à exécuter des traitements dans un environnement sécurisé (tel que l'enclave SGX des nouveaux microprocesseurs Intel] et apte à retourner une attestation d'authenticité et d'intégrité de l'exécution [https://software.intel.com/en- us/articles/intel-software-guard-extensions-remote-attestation-end-to-end-example] la réponse étant prise comme un message "Quasi-WM".
Le but des messages "HTTPS" émis par un WN est de lui permettre d'accéder à une source de données (dans un site Web "de confiance"] en protocole HTTPS de bout en bout. Pour ce faire, le WN prend en charge les handshakes TLS (pouvant être mis en œuvre en utilisant une librairie telle que "mbed TLS" [https://tls.mbed.org/] dont les modules sont faiblement couplés et qui permette d'en utiliser des parties sans avoir à inclure la bibliothèque totale] et performe toutes les opérations cryptographiques, en laissant au terminal auquel il est couplé le rôle d'interface d'entrée/sortie prenant en charge les couches basses (TCP], pour assurer l'intégrité desdites données de bout en bout.
Avantageusement, comme pour les traitements "non légers" (qui sont sous-traités par messages Non- WM], les messages en HTTPS considérés "bloquants" sont sous-traités à un ordinateur apte à retourner une attestation d'authenticité et d'intégrité d'exécution (enclave SGX]. En pratique, les messages HTTPS émis qui s'avèrent être bloquants (après une durée égal à un seuil donné] sont annulés et sous-traités d'office.
Le fait que les messages soient légers et non-bloquants permet une mise en œuvre des WN ne nécessitant pas la technologie la plus récente de fabrication de chips et la met à la portée d'une pluralité de fabricants de WN (et en baisse le cout], tendant ainsi à favoriser la décentralisation même au niveau des fabricants, ce qui est un des buts visés par l'invention. On décrit plus loin des classes d'applications (à la section "marché de connaissances sans tiers de confiance"].
Enfin, la figure 23 montre que les WM sont susceptibles de transférer des valeurs (tags], sous forme de transactions (tx] ce qui est décrit plus loin aux sections « Tags », « CMMU - Crypto Memory Management Unit » et « Perfectionnements aux CCC ».
On va maintenant décrire en détail un certain nombre d'aspects et caractéristiques de systèmes basés sur de tels WN.
Identité décentralisée
On va tout d'abord décrire un procédé pour attribuer à un WN un poids de connexion, basé sur des identifications entre utilisateurs de WN en parcourant différents chemins du graphe, puis différents procédés utilisant de tels poids de connexion.
Communication sur Out-of-Band-Channel
Pour s'identifier de manière décentralisée, des individus peuvent, via des terminaux intelligents respectifs, s'échanger leurs clés publiques respectives directement et se confirmer les uns les autres les attributs qui y sont associés. Il est essentiel à cette étape de se protéger d'une attaque de personne interposée dite MitM (« Man in the Middle attack » en terminologie anglo-saxonne]. Un exemple de méthode pour que deux individus s'échangent leurs clés sans risque de MitM (méthode adaptable pour n individus] est le suivant :
1. Un premier utilisateur (et son terminal, par exemple un téléphone mobile] s'approche d'un autre utilisateur et lui montre un Nonce (un nombre aléatoire servant une seule fois], présenté sous forme d'un QR code généré dans son terminal à partir de ce Nonce.
2. Ledit autre utilisateur (qui se trouve à proximité, au moyen de son terminal] photographie ce QR code, l'interprète pour reconstituer ce Nonce, calcule son haché (par haché on entend le résultat de l'application d'une fonction de hachage cryptographique prédéterminée commune], et retourne au premier utilisateur sa propre clé publique en clair et sa signature (du haché] dudit nonce. (A noter que, au lieu - ou en plus - du QR code, un « passphrase » secret peut être communiqué par oral, ceci peut se faire par téléphone si l'autre utilisateur n'est pas à proximité, et l'autre utilisateur calcule dans son terminal le haché de ce « passphrase » au lieu du haché du Nonce, puis en retourne sa signature avec sa clé.]
3. Le terminal du premier utilisateur vérifie la signature par rapport à la clé reçue et au Nonce (et/ou passphrase] et enregistre la clé (publique] de l'autre utilisateur.
4. Dans la mesure où leurs terminaux sont fiables (voir la description des Wallet Nodes dans WO2016120826A2], les deux utilisateurs peuvent maintenant se communiquer des informations chiffrées (optionnellement en générant/utilisant une clé symétrique commune par Diffie-Hellman] - à commencer bien sûr par la communication par le premier utilisateur de sa clé publique (chiffrée au moyen de la clé publique de l'autre utilisateur]. Ces communications incluent aussi des clés d'autres utilisateurs que chaque utilisateur a pu auparavant recevoir en utilisant la même méthode ou des clés communiquées par encore d'autres utilisateurs à ces autres utilisateurs par la même méthode, et ainsi de suite.
On dit que le nœud dudit premier utilisateur est "IRL-connecté" (IRL pour "In Real Life"] au nœud de chacun desdits autres utilisateurs lui ayant communiqué sa clé par la méthode décrite ci-dessus, chaque nœud étant identifié par sa clé publique (ou une adresse qui en est dérivée]. Dans la mesure où (comme mentionné ci-dessus] les nœuds se communiquent aussi entre eux des clés de nœuds qui ne sont pas IRL-connectés mais indirectement connectés via un ou plusieurs nœuds intermédiaires, chaque nœud peut reconstituer une partie du réseau, constituant son "entourage", et associer à chaque nœud de l'entourage un "poids de connexion".
On va maintenant décrire plusieurs formes de réalisation d'un procédé de détermination, par un premier nœud (NI, l'utilisateur], des poids respectifs de connexion (vis-à-vis du premier nœud] des nœuds (appelés tous « deuxième nœud »] constituant son entourage.
Les procédés sont illustrés par un exemple de 8 IRL-connections (ou "connections réelles"] dans l'entourage d'un nœud NI, composé de six nœuds (en incluant NI] dont il s'agit donc de déterminer le poids de connexion. Les connexions sont bidirectionnelles et les traits pleins représentent des IRL- connections.
Ces procédés sont mis en œuvre selon des paramètres de configuration (tels que des seuils ou des coefficients de pondération], qui avantageusement peuvent être affinés par apprentissage.
A noter que la demande WO2016120826A2 qui est ici incorporée par référence décrit comment compléter un tel processus d'identification décentralisée, sur la base notamment d'attributs d'utilisateurs reconnus par d'autres utilisateurs et s'appuyant sur le graphe de WN.
Poids de connexion par distillation
Le procédé est mis en œuvre par le premier nœud (NI], qui associe à chaque nœud de son entourage un poids de connexion et un facteur d'influence (qui sont implicitement égaux à zéro par défaut]. Initialement, le premier nœud a un facteur d'influence égal à 1 (et tous les autres nœuds ont implicitement un facteur d'influence nul]. Le procédé comprend les étapes suivantes :
Etape 1 : Le poids de connexion de chaque deuxième nœud est la somme normalisée des facteurs d'influence des nœuds (dits « troisièmes nœuds »] qui lui sont IRL-connectés (ou auxquels il est IRL- connecté], ajoutée à son poids de connexion précédent. Les poids de connexion sont ensuite normalisés à nouveau (c'est-à-dire divisés par 2].
Etape 2 : Le facteur d'influence de chaque troisième nœud est la somme normalisée des poids de connexion des (deuxièmes] nœuds qui lui sont IRL-connectés.
Etape 3 : le processus est répété à partir de l'étape 1 jusqu'à convergence (c'est-à-dire tant que la différence entre les derniers poids de connexion déterminés à l'étape 2 et les poids de connexion précédents reste supérieure à un seuil].
La Figure la présente un exemple d'IRL-connexions entre nœuds. Les poids de connexion résultant du procédé, associés par le premier nœud aux nœuds de son entourage sont indiqués sur chaque nœud. On remarque que le nœud 3 qui est IRL-connecté a un poids de connexion (égal à 0,15] inférieur à celui du nœud 5 (0,21] qui ne l'est pas, ceci étant dû au fait que ce dernier est indirectement connecté via le cluster des nœuds 1 et 6.
Avantageusement, le premier nœud (l'utilisateur] ne va accepter des messages (WM] que de la part de nœuds dont le poids de connexion est supérieur ou égal au plus petit poids de connexion parmi les poids de connexion des nœuds avec lesquels il est IRL-connecté. Autrement dit, pour l'utilisateur, les messages (WM] de la part de nœuds dont le poids de connexion est inférieur aux poids de connexion de tous les nœuds IRL-connectés au premier nœud ne sont pas valides. Ainsi, dans l'exemple de la Figure la, NI accepte les messages (WM] qui arriveraient de n'importe quel nœud de son entourage sauf du nœud 4 (dont le poids de connexion, qui est de 0,12, est inférieur aux poids de connexion de tous les nœuds IRL-connectés au premier nœud, à savoir les nœuds 1, 3 et 6].
A noter que la validation de WM pourra être mise en œuvre avec un coefficient appliqué aux poids de connexion (déterminé selon les paramètres de configuration, comme déjà dit]. Ainsi, ne sont pas valides les messages (WM] de la part de nœuds dont le poids de connexion multiplié par un coefficient donné est inférieur aux poids de connexion de tous les nœuds IRL-connectés au premier nœud.
La Figure lb présente ces mêmes nœuds placés dans un ensemble de deuxièmes nœuds ("2d nodes"] et troisièmes nœuds "3rd nodes"]. Les facteurs influence respectifs des troisièmes nœuds et les poids de connexion respectifs des deuxièmes nœud sont indiqués entre parenthèses en ce qui concerne leurs valeurs à la première itération, et en souligné lorsqu'ils ont convergé.
Enfin, à l'étape 1 de ce procédé, un coefficient (déterminé selon les paramètres de configuration, notamment selon la taille de l'entourage] pourra avantageusement être appliqué auxdits poids de connexion précédents avant ajout.
Poids de connexion comme proximité
Selon cette variante, un premier nœud (l'utilisateur] attribue un "poids de connexion" à un deuxième nœud sur la base du nombre de nœuds intermédiaires menant à lui (et de paramètres de configuration].
Par exemple, au premier nœud lui-même est associé un poids 1, aux nœuds IRL-connectés au premier nœud sont associés un poids de 0.5, aux nœuds IRL-connectés à ces derniers un poids de 0.25, et ainsi de suite en les divisant par deux (si tel est le paramètre] à chaque ajout d'un nœud intermédiaire supplémentaire.
Chaque chemin supplémentaire menant à un même nœud augmente davantage le poids de connexion associé à ce nœud. Par exemple, si à un nœud auquel est associé un poids de connexion courant de 0.25, un autre chemin apporte 0.12, le facteur associé à ce nœud est augmenté de la moitié de cet apport supplémentaire (si tel est le paramètre], i.e. 0.25+0.12/2=0.31 (à l'apport le plus fort est ajouté la moitié de l'apport supplémentaire].
Le poids de connexion est normalisé. La Figure 2a montre un exemple de poids de connexion "proximité" à un nœud NI, associés par ce nœud aux nœuds de son entourage.
Procédé mixte
Un premier nœud (l'utilisateur] attribue un "poids de connexion" à un deuxième nœud comme suit : Parmi les nœuds de l'entourage du premier nœud,
plus il y a de troisièmes nœuds qui sont IRL-connectés au deuxième nœud
· et plus ils sont proches du premier nœud,
plus grand est le poids de connexion du premier nœud au deuxième,
Yinfluence les troisièmes nœuds étant aussi fonction des poids de connexion des deuxièmes nœuds qui leurs sont IRL-connectés.
Comme pour le procédé "Poids de connexion par distillation" , cette définition circulaire nécessite un procédé itératif, par affinages successifs jusqu'à convergence (ou quasi-convergence, c'est-à-dire jusqu'à que le gain d'une itération supplémentaire devienne négligeable], procédé où un même nœud peut tour à tour jouer le rôle de deuxième et troisième nœud.
Une mise en œuvre du procédé peut comprendre les étapes suivantes :
Etape 1 : A chaque nœud de l'entourage de l'utilisateur est associé un facteur proximité (proximité au premier nœud] sur la base de paramètres de configuration, comme décrit à la section précédente "Poids de connexion comme proximité".
Etape 2 : A chaque (deuxième] nœud de l'entourage de l'utilisateur est associé un poids de connexion égal à la somme (normalisée] des proximités respectives des (troisièmes] nœuds qui y sont IRL- connectés.
Etape 3 : A chaque (troisième] nœud de l'entourage de l'utilisateur est (re-]associé un facteur influence égal à la somme des poids de connexion des (deuxièmes] nœuds de l'entourage de l'utilisateur. Ce facteur est normalisé.
Etape 4 : A chaque (deuxième] nœud de l'entourage de l'utilisateur est associé un nouveau poids de connexion égal à la somme normalisée (sur nœuds IRL-connectés au deuxième nœud] des produits "influence*proximité",
le produit "influence*proximité" étant normalisé, c'est-à-dire égal à la somme normalisée des influences respectives des (troisièmes] nœuds de l'entourage de l'utilisateur qui sont IRL-connectés au deuxième nœud pondérées par leurs proximités respectives au premier nœud (ou autre combinaison de ces facteurs, telle que celle décrite plus bas]. Etape 5 : Répéter à partir de l'Etape 3 tant que la différence entre les derniers poids de connexion déterminés à l'étape 4 et les poids de connexion précédents reste supérieure à un seuil (basé sur des paramètres de configuration].
Ce procédé est illustré aux Figures 2a et 2b sur le même exemple d'un entourage de 6 nœuds dont il s'agit de déterminer le poids de connexion.
La Figure 2a représente les nœuds de l'entourage de l'utilisateur avec leurs facteurs proximité respectifs (calculés à l'Etape 1] par rapport au premier nœud (identifié par « 2 »], facteurs indiqués en italiques.
La Figure 2b représente ces mêmes nœuds dans deux ensembles: l'ensemble des troisièmes nœuds ("3rd nodes"] et l'ensemble des deuxième nœuds ("2nd nodes"]. Cette figure indique (entre parenthèses] un poids de connexion initial (calculé à l'Etape 2, par rapport au premier nœud] pour chaque deuxième nœud (comme étant la somme des proximités respectives des troisièmes nœuds qui y sont IRL-connectés]. Le facteur influence initial (calculé à la première exécution de l'étape 3] est indiqué entre parenthèses à gauche de chaque troisième nœud (ce facteur est égal à la somme des poids de connexion des nœuds auxquels le troisième nœud est IRL-connecté]. Le poids de connexion (par rapport au premier nœud] calculé à l'Etape 4 après convergence est indiqué en souligné (dans 2d nodes].
Dans cet exemple, le poids de connexion initial de valeur 0,09 pour le nœud « 4 » (qui est indiqué entre parenthèses à la Figure 2b dans les deuxièmes nœuds] est obtenu en additionnant les facteurs proximité des nœuds « 3 » et « 5 » (indiqués à la Figure la] puis en divisant le résultat de cette addition par le total des poids de connexion afin de les normaliser (0,14+0,12]/2,76=0,09]. Le facteur influence initial de valeur 0,09 associé au nœud « 3 » (qui est indiqué entre parenthèses à la Figure 2b dans les troisièmes nœuds] est obtenu en additionnant les poids de connexion initiaux des nœuds « 2 » et « 4 » (qui sont indiqués entre parenthèses à la Figure 2a dans les deuxièmes nœuds] puis en divisant le résultat de cette addition par le total des facteurs influence afin de les normaliser (0,18+0,09]/2,96=0,09]. Dans les étapes ultérieures le poids de connexion est obtenu en sommant (et en normalisant] les produits "influence*proximité". Le procédé converge ici en trois étapes pour fournir la valeur 0,1 pour le facteur influence final associé au nœud « 3 » (indiquée en souligné à la Figure 2b dans les troisièmes nœuds] et la valeur 0,05 pour le poids de connexion final du nœud « 4 » (indiqué en souligné à la Figure 2b dans les deuxièmes nœuds]. Quant au poids de connexion final du nœud 5, le procédé converge en la valeur 0,13, égale à celle pour le nœud 3.
Enfin, en dernière variante, à l'étape 4 du procédé mixte, le terme "influence*proximité" de l'expression de calcul du poids de connexion peut être remplacé par une expression de type "lambda*influence + (l-lambda]*proximité", le coefficient lambda pouvant typiquement prendre la valeur 0,5. Avantageusement, à chaque itération à l'étape 5, ce coefficient est augmenté, le facteur proximité (proximité au premier nœud] de chaque troisième nœud laissant ainsi la place progressivement aux poids de connexion au premier nœud des deuxièmes nœuds qui lui sont IRL- connectés.
Différentes formes de réalisations du procédé de détermination des poids de connexion, telles que celles présentées ci-avant, peuvent être combinées. Avantageusement, leurs résultats peuvent être pondérés selon des coefficients affinés par apprentissage. Ces résultats permettent au premier nœud (l'utilisateur] de valider d'autres nœuds dans le cadre des différents procédés présentés dans ce texte. Communication de clé en redondance
Les poids de connexion permettent d'utiliser une méthode de connexion analogue à celle décrite plus haut à la section "Communication sur Out-of-Band-Channel", mais de manière automatique, si l'on utilise une pluralité de nœuds en redondance.
Un procédé mettant en œuvre cette méthode est décrite ci-dessous sur un exemple d'échange de clé entre un premier nœud (Alice] et un deuxième nœud (Bob] via des nœuds intermédiaires ayant un fort poids de connexion vis-à-vis du premier nœud. Pour cette mise en œuvre, les WN correspondant à ces nœuds sont aptes à recevoir ou émettre des messages sur une pluralité de canaux (tels que SMS, email, etc.]- Ce procédé comprend les étapes suivantes :
1. Le WN de Alice sélectionne N nœuds intermédiaires parmi ceux ayant les plus grands poids de connexion au nœud d'Alice et de préférence ayant, le cas échéant, les plus grands poids de connexion au nœud de Bob (ici trois nœuds intermédiaires sont sélectionnés (N=3], ce nombre étant déterminé selon des paramètres de configuration, en fonction notamment de la valeur de ces poids de connexion], et leur communique de manière chiffrée un Nonce à communiquer au nœud de Bob;
2. Les WN desdits nœuds intermédiaires utilisent un canal séparé et aisément automatisable, tel que des SMS, pour communiquer (en redondance] ce même Nonce au nœud de Bob, ainsi que leurs clés publiques respectives (c'est d'autant mieux s'ils utilisent des canaux différents entre eux];
3. Le WN du nœud de Bob détecte l'arrivée de ces Nonces et retourne, auxdits nœuds intermédiaires, sa signature de ce Nonce et sa clé publique chiffrée au moyen des clés publiques de ces derniers;
4. Les WN desdits nœuds intermédiaires vérifient la signature par le nœud de Bob de ce Nonce (en la décryptant avec sa clé publique et en en vérifiant le hash] et, en cas de succès, communiquent au
WN d'Alice la clé du nœud de Bob signée par eux-mêmes et chiffrée avec la clé publique d'Alice;
5. Le WN d'Alice enregistre alors la clé du nœud de Bob et peut alors échanger avec ce nœud des informations chiffrées.
Les clés ainsi échangées peuvent alors représenter des connexions d'autant plus sûres que lesdits poids de connexion desdits nœuds intermédiaires sont forts et que leur nombre est significatif. Les connexions avec les nœuds pour lesquels lesdits nœuds intermédiaires ont des poids de connexion forts et sont en nombre suffisant sont marqués « quasi-réelles » et le procédé de détermination de poids de connexion (tels que ceux décrits plus haut : « Poids de connexion par distillation », « Poids de connexion comme proximité » et « Procédé mixte »] les assimilent à des IRL-connexions, à un coefficient près.
Avantageusement, à l'étape 1 du procédé ci-dessus, au lieu que ce soit le WN d'Alice qui génère ledit Nonce individuellement, ce Nonce est généré conjointement avec les WN desdits nœuds intermédiaires sélectionnés. Ce procédé complémentaire est aussi automatique et comprend les étapes suivantes :
1. génération d'un nonce par chacun desdits WN des N nœuds sélectionnés ainsi que par le WN d'Alice (chacun génère un nonce séparément et le garde secret jusqu'à l'étape 3];
2. échange (de manière chiffrée] entre ces WN, de hachés desdits nonces respectifs qu'ils ont générés (sans encore dévoiler les nonces eux-mêmes];
3. échange (de manière chiffrée] entre ces WN, des nonces en clair et chaque nœud récepteur vérifie que les nonces reçus correspondent bien aux hachés respectifs reçus à l'étape 2;
4. génération du Nonce final (celui à communiquer à Bob] par combinaison, selon une règle commune préconvenue (telle que de simples opérations arithmétiques], desdits nonces respectifs qu'ils ont générés.
Par ailleurs, à l'étape 2 du procédé de "Communication de clé en redondance », les nœuds intermédiaires ne communiquent pas simplement un même Nonce final au nœud de Bob, mais communiquent aussi lesdits nonces respectifs qu'ils ont chacun générés séparément (comme décrit ci- dessus]; à l'étape 3 Bob signe l'ensemble de ces nonces reçu ; ce qui permet aux N nœuds intermédiaires de s'assurer à l'étape 4 que Bob a bien reçu les N nonces qu'ils lui ont communiqués au total.
Avantageusement, dans le cas où, de part et d'autre, les poids de connexion d'un nombre suffisant de nœuds intermédiaires sont forts (vis-à-vis d'Alice et vis-à-vis de Bob], le WN du premier nœud (Alice] obtient la clé du deuxième nœud (Bob] directement à partir de ces nœuds intermédiaires.
Exploiter un réseau Social existant On va maintenant décrire une application « app WN » sur un réseau social. L'utilisateur "Alice" de cette app en constitue l'un des nœuds. Cette app est apte à recevoir et émettre des messages sur une pluralité de canaux (tels que SMS, email, etc.].
A l'installation, l'app WN :
· génère sa paire de clés privée/publique (à moins que l'app WN soit couplée avec une hard WN, auquel cas cette paire de clés existe déjà],
mémorise une liste de nœuds "amis" ("Friends"] directement connectés, fournie par le réseau social :
F ends(Alice)
et détermine (par requêtes aux amis] quels sont les amis qui ont l'app WN installée (et les amis qui ne l'ont pas sont invités à l'installer] :
F endsWN (Alice)
Dans la mesure ou certains nœuds sont IRL-connectés et servent d'intermédiaires, le poids de connexion d'un ami peut être déterminé selon le procédé décrit plus haut, être ajouté comme attribut dans ladite liste des nœuds amis et être rendu accessible à partir de cette liste. Ainsi, les amis ayant un poids de connexion supérieur à un seuil donné (ce seuil étant déterminé selon des paramètres de configuration] peuvent être retrouvés par un appel de fonction tel que le suivant :
F endsWNConnected(Alice)
Pour être IRL-connecté à un nœud ami "Bob" faisant partie de FriendsWN(Alice], Alice peut lui communiquer via un Out-of-Band-Channel un Nonce que Bob doit lui retourner signé, comme décrit plus haut.
Cependant, le réseau social peut être exploité pour communiquer la clé de l'app WN du nœud Bob selon un procédé automatique (simplement en étendant le procédé décrit à la section "Communication de clé en redondance"] :
1. L'app WN du nœud Alice sélectionne N amis, parmi les éléments de l'intersection entre F endsWNConnected(Alice) et F endsWN (Bob), ayant les plus grands poids de connexion au nœud d'Alice et de préférence ayant aussi les plus grands poids de connexion au nœud de Bob (ici N=3, ce nombre N étant déterminé selon des paramètres de configuration, en fonction notamment de la valeur de ces poids de connexion], et leur communique de manière chiffrée un Nonce à communiquer à l'app WN du nœud Bob;
2. Les app WN respectifs de ces amis utilisent un canal séparé et aisément automatisable, tel que des SMS, pour communiquer (en redondance] ce même Nonce à l'app WN de Bob, ainsi que leurs clés publiques respectives (c'est d'autant mieux si ces amis utilisent des canaux différents entre eux];
3. L'app WN de Bob détecte l'arrivée de ces Nonces et publie dans le réseau social (sur son mur] sa clé publique et sa signature de ce Nonce— de plus, facultativement, l'app WN de Bob retourne directement, aux app WN desdits trois amis d'Alice, sa signature de ce Nonce et sa clé publique chiffrées au moyen des clés publiques de ces derniers;
4. Les app WN respectifs desdits trois amis d'Alice vérifient la signature par l'app WN de Bob de ce Nonce (en la décryptant avec sa clé et en en vérifiant le hash] et, en cas de succès, communiquent à l'app WN d'Alice la clé du nœud de Bob signée par eux-mêmes et chiffrée avec la clé publique d'Alice (avantageusement en plus il certifient cette clé en en publiant leur propre signature sur le mur de Bob];
5. L'app WN d'Alice vérifie alors (double-check] la clé du nœud de Bob en décryptant sa signature publiée sur son mur avec cette clé et en en vérifiant le hash du Nonce, enregistre la clé du nœud de Bob et peut maintenant, en cas de succès, échanger avec le nœud de Bob des informations chiffrées.
Ici encore, les connexions avec les nœuds pour lesquels lesdits amis ont des poids de connexion forts et sont en nombre suffisant sont marqués « quasi-réelles » et le procédé de détermination de poids de connexion les assimilent à des IRL-connexions, à un coefficient près. Avantageusement, la clé publique de Bob publiée par Bob dans le réseau social est en permanence accessible par au moins tous les nœuds connectés à Bob en tant qu'amis.
Et ici encore, avantageusement, à l'étape 1 du procédé ci-dessus, au lieu que ce soit l'app WN d'Alice qui génère ledit Nonce individuellement, ce Nonce est généré conjointement avec les app WN desdits nœuds amis sélectionnés. Ce procédé complémentaire est le même que celui présenté plus haut, à ceci près que les WN sont ici des app WN.
Puis comme aussi décrit plus haut, lesdits N amis vont aussi communiquer à Bob les nonces différents (respectivement] à partir desquels le nonce final a été généré, ce qui leur permettra de vérifier que Bob a bien reçu les N nonces qu'ils lui ont communiqués au total.
Enfin, dans le cas où, de part et d'autre, les poids de connexion d'un nombre suffisant de nœuds intermédiaires sont forts (vis-à-vis d'Alice et vis-à-vis de Bob], le WN du premier nœud (Alice] obtient la clé du deuxième nœud (Bob] directement à partir de ces nœuds intermédiaires. Ainsi, pour se connecter à l'app WN d'un nœud "Bob", un nœud "Alice" peut lui demander (par message WM] ses amis ayant un fort poids de connexion :
F endsWNConnected(Bob),
en prendre l'intersection avec ses propres amis fortement connectés :
F endsWNConnected(Alice),
et si cette intersection n'est pas nulle, demander la clé de Bob à un sous-ensemble de cette intersection composé des amis sélectionnés parmi ceux ayant les plus grands poids de connexion.
WN Miroirs
Avantageusement, on crée une redondance pour chaque nœud avec des "nœuds miroirs" dans lesquels les données sont tenues synchronisés et dont certains effectuent les traitements en miroir, pour en même temps :
· pallier la « non-responsiveness » et
mitiger le risque de violation (« tampe ng »].
Définition:
Un "nœud" (Wallet Node] est maintenant un nœud virtuel (noté VWNX pour « virtual wallet node » de l'utilisateur x], matérialisé par une pluralité de nœuds miroirs comprenant:
· un nœud réel RWN (correspondant audit nœud virtuel] et
un ensemble de nœuds contresignataires CWN.
Dans cet aspect de l'invention, deux nœuds (WN] ne peuvent être liés par des « smart contracts » (cf. les smart contracts "Wallet Program" (WP] décrits dans la demande PCT WO2016120826A2) s'exécutant sur leurs nœuds respectifs, que seulement :
· s'ils sont associés chacun à un nombre supérieur à un premier seuil donné de nœuds miroirs communs ayant des poids de connexion (vis-à-vis de chacun de ces deux nœuds] qui soient supérieurs à un deuxième seuil (seuils déterminés selon des paramètres de configuration] et
lorsque deux nœuds interagissent par exécution d'un smart contract (WP], un message (WM] envoyé de l'un à l'autre n'est valide que si au moins 10% (ou autre pourcentage aussi déterminé selon des paramètres de configuration] de nœuds miroirs communs ont exécuté ce contrat à l'identique ("en miroir"] et ont émis un message (WM] identique à destination de l'autre nœud.
En d'autres termes, un nœud destinataire d'un message (WM] ne valide ce message que si les ensembles respectifs de nœuds miroirs des nœuds émetteur et destinataire ont une intersection dont le nombre d'éléments est supérieur à un premier seuil donné et si le nœud destinataire a reçu ce même message (en redondance] de la part d'au moins une fraction donnée (correspondant à un second seuil] desdits nœuds miroirs appartenant à cette intersection.
Par exemple, l'app WN réel du nœud Bob ne va considérer comme valide un message WM envoyé par l'app WN réel du nœud Alice que s'il reçoit aussi ce message émis (au nom du nœud Alice] de la part d'au moins 10% de leurs nœuds miroirs en commun (qui sont par exemple aussi des app WN]. Chaque nœud exécutant des Wallet Programs synchronise ses données (à savoir: les variables persistantes d'état (PSV] de ses Wallet Programs, ainsi que ses "Tags", décrits plus loin] sur l'ensemble de ses nœuds miroirs, cet ensemble incluant l'union de tous les ensembles respectifs de nœuds miroirs qui sont en commun avec les nœuds avec lesquels ledit chaque nœud a un Wallet Program actif.
Lesdites synchronisations de données s'effectuent :
en partie par envoi (par Wallet Program] de message WM qui déclenchent la mise à jour des données (PSV et tags] par des (mêmes] Wallet Programs qui s'exécutent sur les nœuds receveurs et, pour les nœuds qui ne les reçoivent pas, les données sont synchronisées directement par des WM de notification de mise-à-jour de données.
Par ailleurs, chaque nœud synchronise la liste de ses nœuds miroirs avec les nœuds avec lesquels il a un poids de connexion supérieur à un seuil, et lesdites synchronisations de données s'y effectuent par rapport à ces listes de nœuds miroirs. La synchronisation des listes s'effectue par des WM correspondants.
La Figure 3a illustre la propagation d'un WM à partir d'un VWN 1 donné vers un VWN2 destinataire. Les nœuds miroirs RWN1, CWN1 mémorisent chacun la liste L2 des nœuds miroirs de VWN2 afin de pouvoir aiguiller le WM de contenu identique pour tous les nœuds miroir d'émission et les nœuds miroir de destination.
La Figure 3b décrit de manière plus fine les envois de messages entre nœuds miroirs. Elle montre deux parmi les ensembles de nœuds contresignataires en commun, CWNAB entre les nœuds d'Alice et Bob d'une part, et CWNBC entre les nœuds de Bob et Cari d'autre part, Yunion de ces deux ensembles (+ le nœud réel de Bob RWNB] étant l'ensemble des nœuds miroirs du nœud de Bob qui sont synchronisés suite à n'importe quel message WM envoyé au nœud de Bob.
Ainsi, les nœuds d'Alice et Cari connaissent chacun non seulement leurs nœuds miroirs respectifs en commun avec le nœud de Bob, mais l'ensemble entier de nœuds miroirs du nœud Bob (grâce à la synchronisation de liste de nœuds miroirs évoqué plus haut].
La Figure 3b montre aussi un message WM généré par le nœud d'Alice suite à une interaction avec l'utilisateur (Alice], message WM qui doit être envoyé au nœud de Bob. En premier, un message d'annonce (noté PWM pour « pre-wallet-message »] du message WM est envoyé par le nœud réel d'Alice RWNA aux nœuds miroirs d'Alice CWNAB qui sont en commun avec le nœud de Bob (un seul PWM étant illustré pour ne pas alourdir la figure], et les autres nœuds CWNXA d'Alice reçoivent un message de synchronisation de données (noté DSM pour « data sync message »] . Ensuite, le nœud réel d'Alice RWNA, ainsi que chacun desdits nœuds contresignataires CWNAB en commun avec le nœud de Bob, envoient le message WM en question au nœud de Bob, c'est-à-dire au nœud réel de Bob RWNB et aux nœuds contresignataires du nœud de Bob (seule une partie de ces messages WM étant illustré pour ne pas alourdir la figure].
On notera ici que lorsqu'un tel WN doit être envoyé par un CWN à lui même, il n'est pas émis (ici CWNAB n'envoie pas le WN à lui-même].
La Figure 3c montre une phase de tentative de synchronisation de l'ensemble des nœuds miroirs (RWNB, CWNAB, CWNBC] de Bob via des messages de type DSM, dans une situation où le nœud réel RWNB est non responsif pour une raison ou une autre.
La Figure 3d montre enfin un message WM' envoyé par le nœud VWNB au nœud de Cari VWNc, message généré non pas suite à une interaction du nœud réel de Bob avec son utilisateur (Bob], mais suite audit message WM reçu du nœud d'Alice (généré par les instructions du WP exécuté]. Dans ce cas, les nœuds miroirs qui ont effectivement reçu ce message du nœud d'Alice sont aptes à générer ledit message au nœud de Cari (par l'exécution de ce WP]. La Figure 3d montre toutefois que le nœud réel de Bob est non-responsif et n'émet donc pas le message WM' (ce qui est représenté par un « ! » sur la figure], et que malgré cela, les autres nœuds miroirs du nœud de Bob envoient ce message au nœud de Cari VWNc (ce qui résout le problème de non-responsiveness]. Enfin, de nouveau, comme le message WM' est émis (par le nœud de Bob] non pas suite à une interaction avec l'utilisateur mais par l'exécution d'un smart contrat WP (sur ce nœud de Bob] en réaction à un message WM (reçu du nœud d'Alice], chacun des nœuds miroirs de VWNc qui reçoivent WM' va requérir la réception d'un message identique de la part de 10 % (ou autre pourcentage déterminé selon des paramètres de configuration] de nœuds miroirs CWNBC en commun avec ce nœud (de Bob]. Cari peut ainsi compter sur le fait que ledit message a bien été généré, et bien été généré par le smart contract WP en question qui n'a pas été altéré (on résout ainsi le problème de garantie d'engagements].
On va maintenant décrire un processus de sélection de nœuds miroirs.
Pour chaque nœud, les poids de connexion des nœuds miroirs sont chacun supérieurs ou égal au plus petit poids de connexion des nœuds IRL-connectés (ou en connexion quasi-réelle] de son entourage. Avantageusement, un coefficient pourra y être appliqué : le poids de connexion de chaque nœud miroir doit être supérieur ou égal au plus petit poids de connexion multiplié par un coefficient (déterminé selon les paramètres de configuration], parmi les poids de connexion des nœuds avec lesquels il est IRL-connecté (et par un autre coefficient pour les nœuds en connexion quasi-réelle].
Parmi lesdits nœuds miroirs communs entre un nœud émetteur et un nœud récepteur d'un WM, au moins un (ou un certain nombre, selon les paramètres de configuration] en est un hard WN (un hard WN est un SoC tel que décrit dans la demande PCT WO2016120826A2 et plus loin à la section "CMMU"], la clé publique (correspondant à la privée secrète] de chaque hard WN étant certifiée par son fabricant, et ces hard Wallet peuvent être de fabricants différents— toutefois, les messages échangés entre nœuds ne sont valides que si les nœuds de leurs fabricants sont eux-mêmes liés par des nœuds miroirs de fabricants en commun (voir la description ci-après].
En cas d'un conflit détecté pour des nœuds miroir d'un nœud donné (conflit détecté lors des synchronisations entre les nœuds miroirs associés à un nœud, ou suite à la réception de WM non- compatibles de la part de nœuds miroirs dudit nœud donné, etc.], le nœud qui détecte ce conflit notifie l'information des clés des nœuds miroirs qui sont en conflit à leurs fabricants respectifs et ces clés sont alors révoquées chez ces fabricants. Ensuite, suite à leur recyclage, elles sont remplacées. Ceci est mis en œuvre selon les étapes suivantes :
à chaque fabricant est associé un hard WN le représentant et dont il est lui-même le fabricant (certifiant sa propre clé publique];
chaque nœud de fabricant est IRL-connecté au nœud de chaque autre fabricant lui ayant communiqué sa clé par la méthode décrite à la section "Communication sur Out-of-Band-Channel", dont certains lui communiquant aussi des clés d'autres nœuds de fabricants qui sont ainsi indirectement connectés, chacun constituant ainsi son entourage, à chaque nœud de l'entourage étant associé un poids de connexion comme décrit plus haut;
pour qu'un WM quelconque soit validé par son nœud destinataire, les ensembles respectifs de nœuds miroirs du nœud fabricant du nœud émetteur d'une part et du nœud fabricant du nœud destinataire d'autre part doivent avoir une intersection dont le nombre d'éléments est supérieur à un seuil donné (ceci en plus des deux conditions spécifiées plus haut concernant les nœuds miroirs des nœuds émetteur et destinataire]— ainsi, dans la mesure où des nœuds hard Wallet Node de fabricants différents doivent pouvoir interagir, aux nœuds de ces fabricants sont associés des nœuds miroirs; en cas de conflit (lors d'une synchronisation (par message DSM], ou lors d'une réception de WM non-compatibles de la part de nœuds miroirs d'un même nœud émetteur, etc.], l'information des clés des nœuds miroirs qui sont en conflit est communiquée par envoi de messages (WM] aux nœuds de leurs fabricants respectifs (et s'ils sont différents, à leurs nœuds miroirs respectifs];
les nœuds de fabricant (c'est-à-dire leurs miroirs] enregistrent dans une liste de révocation les clés de nœuds miroirs en conflit;
les nœuds miroirs en conflit qui sont hard WN sont remplacés par leurs fabricants respectifs; dans le cas où le conflit est résolu, ladite synchronisation (DSM] et/ou le message WM qui, le cas échéant, était suspendu car en conflit, est reprise/renvoyé, respectivement;
dans le cas où le conflit persiste, la majorité des hard WN est considérée comme faisant foi et les nœuds miroirs qui en diffèrent sont invalidés et blacklistés.
L'information des nœuds blacklistés est immédiatement communiquée aux nœuds de l'entourage de l'utilisateur et de ceux-ci aux nœuds de leurs propres entourages, et ainsi de suite (et le procédé peut être sophistiqué, selon l'état de l'art et les progrès dans le domaine des protocoles de consensus byzantins].
A noter qu'un jeton de coût, analogue au "gas" de Ethereum (cf. Ethereum: A secure decentralized generalised transaction ledger, EIP-150 revision, Dr. Gavin Wood— Appendix G. Fee Schedule— http://paper.gavwood.com/], permettant d'identifier le coût relatif entre les opérations (calculs, stockage, accès à la mémoire, etc.] d'une exécution de contrat, peut être utilisé pour contrôler les traitements par les miroirs. WN émettant un message au monde extérieur
Pour l'envoi d'un message au monde extérieur (c'est-à-dire à une entité qui n'est pas un WN] chaque WN miroir qui est hard WN propose, aux autres hard WN miroirs le cas échéant, d'émettre lui-même le message en question et le premier gagne. Le procédé comprend les étapes suivantes:
• un premier hard WN miroir propose aux autres hard WN miroirs (le cas échéant] d'émettre le message en question, proposition qui expire après une durée pré-convenue (selon un paramètre de configuration];
• lorsqu'une telle proposition est reçue par un hard WN miroir, si cette proposition vient avant une autre proposition reçue ou émise (pour ledit message en question], alors elle est approuvée, sinon elle est rejetée;
· lorsque le nombre d'approbations est supérieur à la moitié du nombre de hard WN miroirs qui ont répondus, cette proposition est attribuée, le message en question est alors effectivement émis et les autres hard WN miroirs sont notifiés que le message en question a bien été émis.
Selon les cas, le besoin d'émission du message en question peut être clos directement ou lorsqu'un retour arrive de la part du destinataire. L'homme du métier saura en outre tirer parti de l'état de l'art en matière de protocole de consensus byzantins.
Tags
On se référera ici à nouveau à la notion de « Wallet Node » WN décrite en détail dans le document WO2016120826A2 au nom du demandeur. La Figure 7 de WO2016120826A2 présente un paiement de 10 unités de compte (UA] d'un nœud "WN 1" à un nœud "WN 2". Ces 10 UA sont retranchées du solde (« balance »] de WN1 et ajoutées au solde WN 2, ces soldes étant des variables persistantes d'état (PSV pour « Persistent State Variables »] sur ces WN.
On va maintenant considérer, en référence à la Figure 4, que de tels soldes d'UA ne sont pas des PSV d'un certain WP particulier exécuté dans un WN, mais des données, appelées "tags" (ou "value tags"], utilisables le WN quel que soit le WP qu'il exécute. Des UA amenés sous la forme d'un tag par un WP appartiennent ainsi au WN, et peuvent être utilisées par un autre WP sur le même WN - ce sont des variables persistantes d'état pour le WN pris globalement.
Pour prendre un exemple, l'utilisateur WN2 qui reçoit un message WMl de paiement, à partir d'un nœud WN1, suite à une vente qu'il a effectué à ce dernier, exécute un Wallet Program de paiement WPl, et paye ensuite une prime d'assurance en exécutant un Wallet Program d'assurance WP2. Ainsi, dans l'exemple présenté à la Figure 4, 10 UA sont transférées de WN1 à WN2, au moyen d'un message WMl émis en exécutant WPl (ce message comportant le haché #WP1] et ces 10 UA sont payés par WN2 pour régler une prime d'assurance, en exécutant WP2 envoyant un message WM2 (comportant le haché #WP2] à un nœud WN3. Dans la suite, pour être concret on va considérer, comme UA de tag, des BTC (unités Bitcoin] provenant à l'origine d'une transaction Bitcoin insérée et confirmée n fois dans la blockchain Bitcoin (comme expliqué plus loin, la clé privée secrète du WN bénéficiaire est dans ce cas une clé privée correspondant à une adresse Bitcoin], sans que ce soit limitatif, les mêmes mécanismes pouvant être utilisés pour n'importe quels types d'UA, notamment des UA créées ex-nihilo par des WN, comme par exemple dans des bons d'achat (Gift Cards]. En particulier, la demande WO2016120826A2 décrit certaines utilisations de tags qui sont créés par un nœud propriétaire "OWN" ("Owner Wallet Node"], ont des attributs certifiés par des nœuds "VWN" ("Viewer Wallet Node"] dans le cadre d'une chaîne de transformation, ou chaîne logistique (Supply Chain] (ou encore chaîne commerciale], et transférés d'un OWN à un autre, reflétant le fait que les instances de produit (les produits, physiques ou immatériels] qu'ils représentent sont dans le monde réel transférés entre les utilisateurs de ces Wallet Nodes OWN.
De tels tags peuvent être recomposés (c'est-à-dire fusionnés ou décomposés] dans une transaction pour donner d'autre tags. Par exemple, en référence à la Figure 5a, dans une transaction donnée (txl], un tag de 10 UA et un tag de 3 UA, constituant les entrées de la transaction, peuvent être recomposés en trois tags, constituant les sorties de la transaction, ici un tag de 5 UA, un tag de 6 UA et tag de 2 UA, le total des UA étant conservé (l'unité UA en question n'a pas été indiquée dans la figure, il peut par exemple s'agir de BTC]. On appellera "transaction de transfert de tags" de telles transactions. Une transaction de transfert de tags est générée par le WN (OWN] apte à signer les outputs des transactions qui spécifient sa clé de signature. On remarquera que ce modèle subsume le modèle des transactions Bitcoin (entre autres] : une transaction Bitcoin est un cas particulier de transaction de transfert de tags. Un autre exemple de transaction de transfert de tags est illustré à la Figure 5b, qui montre le cas de 10 poissons (10 tags différents], ayant chacun une valeur en Euros différente, transformés (par exemple découpés] en une caisse à poissons (la caisse ayant un tag propre ayant le libellé "tg87"] d'une valeur de 100 Euros, cette transaction tx2 ayant été générée par propriétaire OWN des 9 poissons.
On notera que le cas particulier d'un transfert d'un tag d'un OWN à un autre, même sans qu'il y ait fusion ou décomposition, sera ici toujours représenté par une telle transaction de recomposition, ceci dans un but de simplicité de mise en œuvre. (La mise en œuvre du traitement des transactions de transfert de tags sera décrite plus bas dans la section "CMMU "].
On va maintenant décrire, en référence à la Figure 6, un procédé d'utilisation des nœuds miroirs (décrits plus haut] pour mitiger le risque de double-spending dans une succession de WM de transfert de tags, ce procédé permettant notamment de mettre en œuvre des transactions Bitcoin off-chain (l'utilisation de la blockchain devenant facultative]. Cette Figure montre un message noté "WMcy / tgx" envoyé par le nœud de Cari à un nœud Y (dont seuls des nœuds contresignataires "CWNCY" en commun avec le nœud de Cari sont dans la figure]. Ce message WMcy / tgx transmet une transaction dont des transactions prédécesseurs (dans la chaîne "tgx" de successions de tags] étaient auparavant transmis par les messages WMXA / tgx , WMAB / tgx et WMBC / tgx- Le but de la figure est de montrer que le nœud de Cari s'assure d'avoir un ou un certain nombre de nœuds miroirs en commun dont un est (ou certains sont] hard WN, avec tous les nœuds à l'amont, dont ici avec le nœud d'Alice (ceci est indiqué dans la figure ainsi : "CWNCY = CWNXA").
Rappelons qu'une transaction Bitcoin revient à transférer des BTC, en signant (avec une clé privée] au moins un output d'une transaction précédente qui les alloue, à au moins un nouveau propriétaire dont l'adresse Bitcoin est dérivée de sa clé publique. On considère ici le cas où la clé privée secrète d'une WN est une clé privée correspondant à une adresse Bitcoin (c'est-à-dire que le WN génère une adresse Bitcoin à partir de sa clé privée secrète]. Un WN est ainsi apte à générer une transaction Bitcoin dont l'input (ou un des ses inputs] est connecté à un output (qui lui est destiné] d'une transaction amont (auquel, par exemple, l'utilisateur dudit WN a pu accéder du fait qu'elle est publiée dans la blockchain et qui l'a entrée audit WN en input dans son terminal], et (facultativement] à l'annoncer (broadcast] pour qu'elle soit insérée dans la blockchain. On comprends par là qu'il s'agit d'une transaction Bitcoin réelle et bien formée qui est générée par ledit WN, néanmoins dans ce qui suit (à la section "Transactions Bitcoin off-chain"] on explique justement les avantages de ne pas l'y insérer. Des BTC dépensés par un WN peuvent provenir d'une succession de transactions off-chain, formant un graphe et transférant des BTC d'un ou plusieurs nœuds à un ou plusieurs autres nœuds, et l'on veut mitiger le risque d'un double-spend sur l'un quelconque de ces nœuds générant ces transactions. Ceci est obtenu par la condition supplémentaire suivante (qui s'ajoute aux conditions spécifiées plus haut concernant les nœuds miroirs des nœuds émetteur et destinataire d'un WM] : Pour qu'un WM transférant un tag donné (par exemple 0.5 BTC] soit validé par son nœud destinataire, l'ensemble des nœuds miroirs du nœud destinataire doit avoir une intersection, dont le nombre d'éléments est supérieur à un seuil donné, avec l'ensemble des nœuds miroirs de chacun des nœuds du graphe amont (de transactions de transfert de tags] d'où provient ce tag, et au moins l'un ou un d'entre eux doit (ou certain nombre d'entre eux doivent] être hard WN. La mise en œuvre de l'exécution du procédé par un WN inclut ainsi la traversée, en parcourant de l'aval vers l'amont, du graphe des WM véhiculant des transactions de transfert de tags et de vérifier ladite condition d'intersection de nœuds miroirs.
Avantageusement, chaque tag inclut l'information du graphe des transactions de transfert de tags à l'amont, chacune indiquant l'adresse du WN l'ayant généré (ces WN sont appelées "WN amont"], ce qui permet, à un WN destinataire d'un WM de transfert de tag, de vérifier directement si au moins un miroir (ou un certains nombre] de tous les nœuds amont figurent dans son entourage, fait partie de ses propres nœuds miroirs et est un hard WN, et pour chaque WN amont qui n'est pas dans ce cas si le poids de connexion d'un de ses miroirs qui est un hard WN lui permettrait d'en faire partie (après échanges éventuels de nouvelles connexions avec des nœuds de son entourage]. Ainsi, plus précisément, à chaque tag sont associés tous les tags amont (c'est-à-dire figurant dans le graphe amont, dans toutes les chaînes de successions de transactions de transfert de tags menant au tag en question], avec l'adresse du nœud propriétaire qui l'a généré et avec, le cas échéant, l'adresse de chacun de ses propriétaires ultérieurs (OWN], ainsi que les adresses de leurs nœuds miroirs, ce qui permet à chaque nœud destinataire d'un WM transmettant une transaction de transfert de tags de vérifier directement l'intersection requise entre ses propres nœuds miroirs et lesdites adresses de nœuds miroirs de chacun de ces propriétaires, ainsi que le fait qu'au moins un (ou certains, selon les paramètres de configuration] sont des hard WN, et une recherche de nœuds ayant de forts poids de connexion est si besoin lancé afin de s'associer de nouveaux nœuds miroirs.
Marché de connaissances
La capacité des WN à sous-traiter des traitements à des trusted computers (aptes à retourner une attestation d'authenticité et d'intégrité d'exécution, tels que des ordinateurs munis de microprocesseur(s] Intel à enclaves SGX], permet de mettre en œuvre directement un marché de connaissances sans tiers de confiance et de manière plus simple que dans l'état de l'art des smart contracts :
Supposons par exemple que l'utilisateur Ul (ayant un Wallet Node WN1 de clé publique Kl] cherche un autre utilisateur U2 (WN2, K2] qui lui vende un secret (SI] que U2 connaît et que Ul ne connaît pas, mais dont Ul connaît le haché H(S1] pour une raison ou une autre, et que Ul soit prêt à payer pour ce service rendu un montant $R1 (R comme Reward] qui se trouve actuellement disponible dans le solde (de tags] de WN1 de Ul.
Plus précisément, une telle offre d'achat de la part d'un WN de clé K comprend un ensemble d'éléments {H(S];$R;$P;T[;params]} annoncé sur ce marché avec signature SigK({H(S];$R;$P;T[;params]}] de ce WN, où $P est une pénalité qu'un fournisseur qui s'engage à fournir au temps T doit payer s'il ne le fait pas (voir aussi le "Scénario d'utilisation" plus bas]. Dans la suite, le terme {H(S];$R;$P;T[;params]} est aussi appelé "éléments d'offre".
Voici en substance comment le procédé opère : 1. Ul rend disponible et diffuse un Wallet Program (WP1] permettant d'émettre trois types de messages (seuls les éléments essentiels ont été indiqués et de manière abstraite, on verra plus loin les composants précis d'un WM] :
• WMBid : WM( Sig, #WP1], communiquant une déclaration d'offre de service pour un service "Sig" (correspondant à une signature d'éléments d'offre par un WN, comme décrit ci-dessus], message dont le destinataire est le signataire de Sig et qui, en cas d'acceptation par ce dernier, engage son émetteur (celui qui propose le service en question] à payer une pénalité d'un montant $P en cas de non fourniture dans un délai donné T;
• WMAccept : WM( WMBid, #WP1], communiquant, en réponse à un message WMBid donné, l'acceptation de l'offre de service en question, et qui engage son émetteur à payer le montant $R
(spécifié dans les éléments d'offre en question] sur réception d'un message WMS comprenant le secret dont le haché correspond à H(S] (spécifié dans les éléments d'offre en question]; et
• WMS : WM( WMAccept, S, #WP1], communiquant le secret S en réponse à un message WMAccept donné et déclenchant sur le WN récepteur sa vérification (par rapport au H(S] spécifié dans les éléments d'offre en question dans les messages précédents] et, en cas de succès de cette vérification, la génération sur le WN récepteur d'une transaction de paiement du montant $R (aussi spécifié dans les éléments d'offre] envoyée à l'émetteur de ce message WMS par un WM final du WN récepteur.
WP1 est en outre apte, suite à réception d'un message WMAccept, à sous-traiter les traitements (ici de recherche par force brute du secret S] à un trusted computer apte à retourner une attestation d'authenticité et d'intégrité d'exécution, attestation qui sera automatiquement vérifiée par WP1 avant émission du message WMS.
2. Ul annonce son offre {H(Sl];$Rl;$Pl;Tl [;paramsl]} qu'il diffuse avec sa signature Sigl({H(Sl];$Rl;$Pl;Tl [;paramsl]}].
Voici le scénario d'utilisation:
Supposons que l'utilisateur U2 de WN2 ne connaisse pas déjà ce secret S, et supposons aussi que les paramètres paramsl incluent l'indication du nombre maximum de caractères du secret recherché, nombre indiquant que le trusted computer pourra trouver le secret désiré par recherche force brute en un temps raisonnable. U2 décide alors de faire envoyer par son Wallet Node WN2, à destination du Wallet Node WN1 de Ul, le message
WMBid2 : WM( Sigl, #WP1]
en guise d'offre de service, puis (comme Ul accepte cette offre de service] WN1 lui répond avec le message
WMAcceptl : WM( WMBid2, #WP1]
en guise d'acceptation, ce qui (soit automatiquement, soit sur commande de l'utilisateur U2 qui peut par exemple sélectionner le trusted computer auquel sous-traiter] déclenche la sous-traitance en question à un trusted computer. Plus tard, lorsque le résultat— le secret SI recherché correspondant à H(S1]— est retourné par ce trusted computer, WN2 envoie automatiquement le message
WMS2 : WM( WMAcceptl, SI, #WP1]
communiquant le secret désiré SI à WN1, et dès réception de ce message et vérification de la correspondance du haché du secret reçu avec H(S1], WN1 génère la transaction de paiement de $R à WN2 et l'envoie (par WM] à WN2.
A noter que les éléments d'offre peuvent aussi représenter une offre de vente et l'approche de la méthode permet la négociation par itérations d'offres et contre-offres, les éléments d'offre pouvant évoluer dans ces itérations, les messages étant alors essentiellement comme suit (si l'on considère que le premier message, ici WMBid, est envoyé par le fournisseur] :
• WMBid : WM(Sig, {H(S);$R;$P;T[;params]}, WP1], communiquant une contre- offre {H(S];$R;$P;T[;params]} par rapport à "Sig", message dont le destinataire est le signataire de Sig et qui, en cas d'acceptation "à l'identique" par ce dernier, engage son émetteur (le WN qui propose le service en question] à payer une pénalité du montant donné $P en cas de non fourniture dans le délai donné T;
• WMAccept : WM( WMBid ou WMNewBid, {H(S);$R;$P;T[;params]}, #WP1), communiquant une contre-offre en réponse à un message WMBid ou WMNewBid donné; dans le cas où {H(S];$R;$P;T[;params]} est identique aux éléments d'offre de ce dernier, ce message WMAccept engage son émetteur à payer le montant donné $R sur réception d'un message WMS comprenant ledit secret dont le haché correspond à H(S]; également, dans le cas où dans un délai (préconvenu] un message WMNewBid proposant des éléments d'offre identiques arrive, ce message WMAccept engage directement son émetteur à payer le montant donné $R sur réception d'un message WMS comprenant le secret dont le haché correspond à H(S];
• WMNewBid : WM(WMAccept, {H(S];$R;$P;T[;params]}, WP1], communiquant une contre- offre {H(S];$R;$P;T[;params]} par rapport à une offre WMAccept donnée et dont le destinataire est l'émetteur de ce message WMAccept; dans le cas où {H(S];$R;$P;T[;params]} est identique aux éléments d'offre de ce message WMAccept donné, ce message WMNewBid engage directement son émetteur (celui qui propose le service en question] à payer la pénalité d'un montant $P en cas de non fourniture dans le délai donné T (sans attendre un nouveau message WMAccept d'acceptation];
• WMS : WM( WMAccept, S, #WP1], communiquant le secret S en réponse à un message WMAccept donné et déclenchant sur le WN récepteur sa vérification et, en cas de succès de cette vérification, la génération d'une transaction de paiement du montant $R envoyée à l'émetteur de ce message WMS par un WM final de la part du WN récepteur.
Une variante de cette méthode consiste à déporter audit trusted computer, en plus, la tâche de vérification du résultat fourni, et ledit trusted computer en fournit une attestation (de l'authenticité et l'intégrité des traitements effectués pour cette vérification] qui sert de preuve.
Ainsi, lors de la fourniture du résultat SI, au lieu d'un simple message "WMS2 : WM( WMAcceptl, SI, #WP1]", WN2 retourne un message
WMA2 : WM( WMAcceptl, SI, A2, #WP1]
dans lequel A2 est ladite attestation de cette vérification successful effectuée dans ledit trusted computer, WN1 n'ayant alors pas à effectuer cette vérification avant de générer la transaction de règlement de $R à WN2.
En variante et dans un but de sécurité supplémentaire, l'attestation A2 est retournée sans fournir immédiatement le résultat SI, et ce résultat est fourni après que WN1 retourne (un WM comprenant] une transaction de paiement (au moins partiel, le paiement étant alors complété par l'envoi d'une transaction finale après réception du résultat SI— à noter aussi que dans le cas où le résultat peut être partitionné, plusieurs itérations paiement-partition peuvent se succéder jusqu'à fourniture complète].
Le fait de communiquer une telle attestation (A2] couvre un champ d'application plus large, en effet ladite vérification peut parfois consister en des traitements longs et coûteux (contrairement à l'exemple ci dessus où il s'agissait seulement de vérifier que le haché du résultat SI fourni correspond au H(S1] spécifié au départ] ou qui simplement ne doivent pas être effectués dans un Wallet Node, un Wallet Node étant destiné à ne gérer que des accords (agreements] entre nœuds et devant rester disponible (en performances] dans ce but.
Enfin, un marché aux enchères de résolution de problèmes peut être créé, assurant par exemple qu'un fournisseur proposant une meilleure offre (plus complète et/ou plus rapide et/ou...] scelle un deal. Une telle offre peut consister non seulement en l'apport d'une solution à un problème donné mais aussi en des traitements de vérification d'une solution proposée (dans le secteur du software testing par exemple]. La possibilité des WN de sous-traiter des traitements à des trusted computers étend ainsi la puissance du réseau de WN, le réseau de WN permettant de se passer de tiers neutres dans les échanges, chaque WN pouvant être fabriqué à bas coût, dans une technologie accessible et relativement répandue, par une pluralité de fabricants, justement grâce à cette possibilité de sous-traitance qui permet aux WN de ne prendre en charge que les traitement concernant les échanges (les conditions d'échange, les paiements, etc.].
« Blind Proxy »
Les Wallet Nodes permettent de mettre en œuvre des traitements sans divulgation des données traitées ni du code exécuté dans ces traitements.
On considère un dispositif "Client" et un dispositif "Blind Proxy" (ou "Proxy"], Client faisant tourner sur Proxy un code exécutable "P" (comme Program] sur des données "/" (comme Input] qu'il envoie à Proxy.
Le modèle d'exécution adopté pour ce code exécutable P est une machine à états finis, dont l'exécution est déclenchée par la réception d'un message entrant et susceptible d'émettre des messages sortants. Ainsi, sa réception d'un message entrant entraîne la génération de 0 à n messages sortants et 0 à m changements d'états (persistent states].
A Proxy sont associées une paire de clés publique/privée, la clé publique ["K2") de Proxy ayant préalablement été certifiée, sous forme d'une signature décryptable avec une certaine clé publique "K" (au nom du fabricant du SoC, « on behalf of the SoC manufacturer »], pour garantir la propriété "blindness" de Proxy et incluant la garantie d'intégrité d'exécution (dite « hash-locked exécution », "hash" voulant dire "haché"].
Considérons tout d'abord le procédé suivant pour réaliser un « Blind Proxy ». Dans la suite on utilise le symbole « § » pour un chiffrement, la lettre « P » qui peut être suivie d'un chiffre (Pi] pour un programme, la lettre « K » qui peut être suivie d'un chiffre [Kl) pour une clé, celle-ci étant clé publique lorsqu'il s'agit de générer un chiffrement (tel que dans §κΡ) et clé privée lorsqu'il s'agit de la clé utilisée pour générer une signature, tel que dans sign^X). Ce procédé Blind Proxy est le suivant :
Provide Proxy to Client:
I. Provide (on behalf of the Proxy manufacturer certification public key (K) (accessible by Client) 2. Generate Proxy's public key (K2)
3. K2 is certified with signi<(K2) (i.e. décryptable using K)
4. Proxy sends K2 to Client (and {K2, signi<(K2)} is accessible by Client)
Client provides an exécutable code (P) to Proxy:
5. Client encrypts P using K2 (§κ∑Ρ) and sends §κ∑Ρ to Proxy
6. Proxy decrypts §κ∑Ρ, hashes P (#P) and stores §κ∑Ρ in association with #P, in a table PHT (Program Hash Table)
7. Client hashes P (#P)
For each exécution request:
8. Client encrypts l+#P
Figure imgf000030_0001
using K2 (or §K2input+#P+Kl, where Kl is Client's public key) 9. Client sends to Proxy §K2input+#P and Kl (or §K2input+#P+Kl), along with a nonce (nonce) (or sends
Figure imgf000030_0002
+nonce)
10. Proxy ("blindly") decrypts §K2(input+#P '...) as well as fcP (§K2P being retrieved from PHT using #P)
I I. Proxy (blindly) runs P (decrypted on the fly) with I (once decrypted), encrypts the results using Kl (§KiOutput) and returns nonce and §KiOutput (or ail encrypted together) along with signK2(nonce,§KiOutput...) to Client, without the owner of Proxy being able to see I, P or thèse results 12. Client decrypts the results and checks them by decrypting their signature with K2. Comme mentionné ci-dessus, avantageusement, à l'étape 8, au lieu de simplement chiffrer I+#P avec la clé K2 de Proxy, Client chiffre I+#P+K1 [§K2input+#P+Kl), et à l'étape 9, Client communique sa clé publique Kl en envoyant §K2input+#P+Kl. Proxy retourne alors les résultats à Client (à son adresse qui peut être #KÏ) sans que Kl ne soit dévoilé. Selon une autre option, nonce peut faire aussi partie du corps du message chiffré [§K2input+#P+Kl +nonce) et dans le message retourné par Proxy à Client, il figure aussi de manière chiffrée [§KiOutput+nonce). Pour simplicité et clarté, ces options, que l'homme du métier saura mettre en œuvre aisément, ne sont pas reprises dans la suite. L'important ici est le fait de ne pas dévoiler #P pour que l'utilisateur ou propriétaire de Proxy ne puisse pas en faire la relation avec Client.
Dans une implémentation possible (d'autres implémentations pouvant bien entendu être envisagées], le message de Client à Proxy comprend :
message: §K2Ïnput+ttP, Kl, nonce
et le retour (de Proxy à Client] comprend :
message: nonce, §KiOUtput, [K2,] signK2(nonce,§KiOUtput),
(ou simplement
message: signK2(nonce,§KiOUtput)
dans le cas où nonce et §KiOutput peuvent être obtenus en décryptant signK2(nonce,§KiOutput) au moyen de K2, mais on considère dans la suite que les signatures consistent en des chiffrements de hash]
nonce permettant avantageusement de faire correspondre un message sortant à un message entrant et K2 et signK2(nonce,§KiOutput) permettant à Client de vérifier que le traitement a bien été fait par Proxy ayant cette clé K2 (certifiée].
Pour que Client puisse vérifier le certificat garantissant la propriété "blindly" (ainsi que d'intégrité d'exécution - il est entendu ici que « blindness » suppose (« subsumes » en anglais] l'intégrité d'exécution hash-locked exécution integrity] du traitement par Proxy (qui a signé le résultat de ce traitement par signK2(nonce,§KiOutput)),
• signi<(K2) est communiqué à Client au préalable et Client le stocke, et/ou avantageusement
• signi<(K2) est inclus dans chaque message de retour, comme suit:
message: nonce, §KiOUtput, [K2,] signK2(nonce, §KiOUtput), signK(K2)
II y a des cas où l'on veut que même Client soit une entité ayant la propriété de blindness ou d'intégrité d'exécution et, pour le garantir l'on veut également que (i] le message de Client à Proxy soit signé par Client [signKi(nonce,§K2input+#P) ] et (ii] que la clé Kl de Client soit certifiée [sign^Kl )) :
message: §K2Ïnput+ttP, nonce, Kl, signKi(§K2Ïnput+ttP, nonce), signK(Kl)
(ici #P étant le hash du code exécutable utilisable par Client ou Proxy].
L'utilité d'un tel procédé est par exemple manifeste dans le cas de la vérification d'un passeport électronique, en référence à la Figure 6 de la demande PCT No. WO2016/120826 A2 : la garantie de l'intégrité d'exécution de Client - exécutant un programme de vérification du passeport, dont le hash du code exécutable est #P1 - signifie garantir l'existence de ce passeport :
message: §K2Ïnput+ttPl, nonce, Kl, signKi(§K2Ïnput+ttPl, nonce), signK(Kl ) .
On peut alors concevoir un format unifié (présenté ici de façon non limitative, d'autres formats pouvant être choisis] pour les messages de Client à Proxy et les retours de Proxy à Client, qui est le suivant:
message: noncel, §K2(data+ttPl +ttP2), nonce2, Kl, SignKi(noncel, §K2(data+ttPl +ttP2), nonce2), signK(Kl) .
Dans un message M ayant ce format :
• M étant vu comme un message sortant (du point de vue de son émetteur], noncel reproduit le cas échéant le nonce2 reçu dans le message amont qui avait déclenché le traitement qui a donné lieu à ce message M; • M étant vu comme message entrant (du point de vue de son destinataire], nonce2 désigne le noncel du (ou de chaque] message sortant qui sera émis par ledit destinataire au cours du traitement en réaction à la réception de ce message M;
• #P1 est le hash du code exécutable exécuté par l'émetteur de ce message M;
· #P2 est le hash du code exécutable requis pour effectuer le traitement en réception de ce message M.
On comprend donc que nonce2 identifie le message en question (M], tandis que noncel est l'identifiant du message entrant reçu qui avait déclenché le traitement qui a donné lieu à ce message M.
Selon les cas, certains de ces arguments seront omis pour appliquer ce format aux différents cas d'usage. Par exemple, pour le procédé "blind proxy" présenté ci-dessus (où le message de Client à Proxy comprend :
message: §K2Ïnput+ttP, Kl, nonce
et le retour (de Proxy à Client] comprend
message: nonce, §KiOUtput, K2, signK2(nonce, §KiOUtput), signK(K2) ],
le message de Client à Proxy sous cette forme comprend les arguments suivants :
message: _ , §K2(data+_+ttP2), nonce2 , Kl, _ , _
et le retour sous cette forme comprend les arguments suivants:
message: noncel, §K2(data+ttPl +_) , _ , Kl, SignKi(noncel, §K2(data+ttPl +_) , _ ), signK(Kl ) .
Avantageusement, un format de message plus complet comprend en plus un argument #spec contenant le cas échéant le hash d'une spécification des contraintes reliant #P1 et #P2, c'est-à-dire, restreignant l'ensemble des #P2 valides à la suite d'un #P1 :
message: noncel, §K2(data+ttPl+ttP2), ttspec, nonce2, Kl, SignKi(noncel, §K2(data+ttPl +ttP2), spec, nonce2), signK(Kl)
Dans une mise en œuvre, cette spécification « spec » peut être l'ensemble des codes exécutables [#P1,#P2, etc.] valides. Dans une autre mise en œuvre, en référence à la Figure 11, pour chaque code exécutable dont le hash est donné [#PÏ] est fourni dans cette spécification l'ensemble des hash des codes exécutables (#P2...] valides.
Dans le cas où, pour un message donné, il est requis que le code exécutable (dans son intégralité] qui doit être exécuté par le récepteur du message soit le même que celui exécuté par l'émetteur du message, c'est-à-dire que le même #P soit propagé d'un message entrant reçu à un (ou à chaque] message sortant généré, il est préférable que le format des messages soit le suivant (et l'on pourra utiliser ou se référer à cette option particulière de format unifié dans la suite, sans que ce soit limitatif] :
message: noncel, §K2data+ttP, nonce2, Kl, SignKi(noncel, §K2data+ttP, nonce2), signK(Kl)
Rappel
En référence à la Figure 5 de WO2016120826A2, au sein du SoC se trouve un microcontrôleur [Microcontroller) comprenant un processeur généraliste (« general-purpose processor », tel qu'un processeur implémentant l'architecture RISC-V] muni d'une mémoire interne. Seul ce processeur peut accéder à la partie « Sign » fournissant des fonctions cryptographiques, notamment la fonctionnalité de signature par le SoC, cette dernière étant à son tour la seule à pouvoir accéder à la partie contenant la clé secrète de la puce (Secret Key]. La partie « (Secret Key] » est présentée entre parenthèses dans la figure puisque dans certaines options de mise en œuvre la clé secrète n'est pas stockée mais régénérée dynamiquement. La partie Wallet Programs mémorise des codes exécutables chiffrés [§P) ainsi que leurs hachés respectifs. Le Microcontroller charge dans sa mémoire de manière sécurisée, en fonction du hash (#P] inclus dans le message entrant (ou de l'entrée via Ι/0] l'un ou l'autre de ces codes exécutables. Ces derniers sont aptes à manipuler, dans une mémoire non volatile, des variables d'état persistantes qui ne sont accessibles que par le Microcontroller. Dans WO2016120826A2, le sous- système Pers. State Variables ne rend accessible lesdites Pers. State Variables (PSV] que seulement pour l'exécution des WP respectifs spécifiques auxquels ces variables appartiennent. Ces variables d'état ne peuvent ainsi être accédées/manipulées que (exclusivement] par leurs WP respectifs. (Toutefois, dans la présente invention, les variables persistantes d'état incluent aussi les tags, décrits plus haut] Au power-up et power-reset, le code exécutable stocké dans la partie « Check/Load » est le premier à être chargé et exécuté dans le Microcontroller, et des hachés peuvent alors être (re] associés aux WP disponibles dans la partie « Wallet Programs ». Lorsqu'un WM arrive (via l'I/O], cette partie Check/Load en vérifie l'intégrité et l'authenticité (la clé publique du WN émetteur de ce WM est utilisée pour décrypter la signature par ce WN émetteur et vérifier l'intégrité du message; la clé de la signature de certification en représentation du fabricant est vérifiée et la clé publique qu'elle certifie est alors validée comme étant une clé de WN, ce qui permet de confirmer l'authenticité dudit WM], le WP correspondant audit haché est, le cas échéant, sélectionné dans la partie « Wallet programs » et chargé pour exécution. L'émission de WM, le cas échéant, par ledit Wallet program, se fait par l'intermédiaire de la partie Sign qui vérifie le haché inséré dans le WM en préparation avant de le signer. A noter que dans une variante de mise en œuvre possible, pour émettre un WM vers un WN destinataire, le sous-système de signature du WN émetteur génère (ou vérifie] un chiffrement du WP en exécution (c'est-à-dire du WP couramment chargé] avec le cas échéant les données à transmettre, au moyen de la clé publique du WN destinataire, et l'inclut dans ledit WM à émettre avant signature dudit WM à émettre (et à réception le WN destinataire charge pour exécution ce WP une fois décrypté] garantissant ainsi que le même WP est re-exécuté dans le WN destinataire. Avantageusement, les WP peuvent être organisés en versions ; les hachés des versions précédentes du WP fournit dans le WM accompagnent alors ce dernier et, pour chaque variable d'état stockée dans la puce, le haché de la version du WP qui l'a dernièrement manipulée lui est associé. Ainsi les variables d'états d'un WP peuvent être mises à jour par celui-ci même lorsque sa version évolue.
On considère dans la suite qu'un WP est transféré d'un WN à un autre au sein d'un WM au moyen d'un WP spécifique de transmission (voir dans la suite code exécutable « PP »].
Comme déjà évoqué, la clé publique correspondant à ladite clé privée secrète est « certifiée » par le fabricant dudit système-sur-puce WN. Ce certificat est une signature (c'est la signature, par une entité représentant le fabricant, de la clé publique correspondant à ladite clé secrète du WN] dont la clé de signature (c'est-à-dire clé publique représentant le fabricant] est partagée entre tous les (ou du moins une pluralité de] systèmes-sur-puce WN d'un même fabricant. Ledit certificat est produit automatiquement, quel que soit le mode de fabrication : mode où ladite clé secrète est gravée dans la puce comme dans les TPM ou les cartes à puce, mode où elle est stockée de manière sécurisée, mode où elle est automatiquement générée dans la puce selon la technologie « PUF » [Physically Unclonable Function) introduite dans [P. S. Ravikanth, « Physical one-way functions », PhD Thesis, MIT, 2001] et [Pappu& al., « Physical one-way functions », Science, 297(5589] : 2026-2030, 2002] (technologie mise en œuvre notamment dans les SoC FPGA Smartfusion2 et d'autres puces du fabricant Microsemi], ou selon une technique analogue à ces dernières. L'authenticité de ladite clé publique d'un WN émetteur d'un WM (notamment l'authenticité des signatures effectuées au moyen de la clé secrète de ce WN] est automatiquement vérifiée par le WN récepteur de ce WM lors de sa réception par rapport audit certificat. Avantageusement le système inclut d'office ledit certificat dans les WM.
Classiquement, il existe une logique intégrée dans les SoC, appelée BIST (Built-In Self Test] qu'on utilise typiquement pour tester la clé secrète du SoC. Selon un aspect inventif, on utilisera cette même logique BIST pour générer la signature du fabricant (certificat] automatiquement au moment de ce test, c'est-à-dire au moment de sa fabrication, la clé privée du fabricant permettant cette signature étant elle-même secrète. Ainsi, au moment dudit test si la clé secrète (clé privée] est opérationnelle et permet d'en dériver la clé publique correspondante, une requête de certification de cette dernière est transmise à un dispositif de signature au moyen de la clé privée représentant le fabricant. La signature qui le cas échéant en résulte est avantageusement inscrite dans le SoC. CMMU - Crypto Memory Management Unit
On va maintenant décrire un système-sur-puce « Blind SoC » assurant la propriété de « blindness », apte à mettre en œuvre le procédé présenté au début de la section « Blind Proxy » et les messages ayant le format unifié décrit plus haut.
Un Blind SoC possède une clé privée secrète. Un Blind SoC peut communiquer avec un autre équipement uniquement par des messages et est apte à exécuter des programmes seulement en réponse à la réception de messages (comme présenté à la Figure 23]. Un Blind SoC est par ailleurs apte à mémoriser un programme à exécuter reçu, reçu de manière chiffrée et/ou après chiffrement par le Blind SoC, et à générer un haché de chaque programme, ce haché permettant de retrouver le programme chiffré au moyen d'une table « Program Hash Table » (PHT]. Un équipement (Client] peut adresser au Blind SoC un message contenant des données d'entrée [data) pour un certain programme à exécuter (P2], ainsi que le haché (#P2] dudit programme. En réponse à un tel message, le Blind SoC (i] accède au programme à exécuter à partir du haché du programme (#P2] reçu dans le message, (ii] décrypte à la volée le programme, et (iii] exécute à la volée les instructions décryptées.
Avantageusement, avant émission d'un message, un Blind SoC y insère le haché (#PÎ] du programme en cours d'exécution dans le corps du message à émettre, qu'il signe au moyen de sa clé secrète. Lorsqu'un message a un même haché pour le programme en cours d'exécution (#PÎ] que pour le programme à exécuter par le destinataire de ce message [#P1 = #P2), ledit programme [PI = PZ) est un « engagement exécutable » (smart contract] dans le cas où le destinataire dudit message offre la garantie d'intégrité d'exécution de ce programme P2. (Egalement, si le haché [#PÏ] émis pour le programme en cours d'exécution est différent de celui [#P2] pour le programme à exécuter par le destinataire offrant garantie d'intégrité d'exécution de ce programme (P2], mais la correspondance est garantie au moyen d'une spécification commune de ces programmes [PI, P2..., comme déjà décrit en référence à la Figure 7] ces programmes représentent un « engagement exécutable » (smart contract]].
Blind SoC comprend une unité CMMU (Crypto Memory Management Unit] qui mémorise - ou qui est apte à dynamiquement régénérer (par technologie PUF, précédemment citée] - ladite clé secrète du Blind SoC (qui n'est accessible que par l'unité CMMU qui ne la dévoile jamais], et c'est par cette unité CMMU que sont effectués :
ledit chiffrement du programme avant mémorisation,
une allocation de place en mémoire [addrl..addr2 range] où stocker le programme ainsi chiffré, cette place allouée permettant aussi de stocker des variables persistantes d'état liées à ce programme et assurant l'isolation des programmes les uns par rapport aux autres,
- ladite génération du haché du programme et
ledit décryptage pour exécution à la volée par au moins une unité processeur comprise dans le Blind SoC,
les autres traitements décrits plus bas dans la présente description.
La Figure 21 présente schématiquement les étapes de réception par CMMU d'un message contenant un programme à charger en mémoire (MEMORY]. A noter que la mémoire (MEMORY] peut être externe au SoC ou pas, et qu'elle comprend un espace réservé aux tags décrits plus haut. Les étapes numérotées représentent les étapes suivantes :
1] réception d'un message contenant un programme à charger en mémoire
2] ledit programme à charger étant chiffré et le haché dudit programme avant chiffrement étant déterminé, réservation d'un espace en mémoire pouvant contenir ce programme chiffré et ses variables persistantes d'état qui seront également chiffrées, et mémorisation dudit programme chiffré, ledit haché permettant par la suite de le retrouver via une table (PHT].
Avantageusement, l'unité CMMU effectue ladite mémorisation du programme chiffré bloc d'instructions par bloc d'instructions et fournit (audit processeur] un seul bloc d'instructions déchiffré à la fois (pour exécution par le processeur des instructions que le bloc comprend]. Ainsi le procédé pour charger des programmes (codes exécutables] dans Blind SoC comprend avantageusement les étapes suivantes. Sur réception par Bind SoC d'un message comprenant P et #PP (sous forme chiffrée feP+#PP...], PP étant le programme de chargement de programme et P étant le contenu du code exécutable à charger, l'unité CMMU :
1. décrypte fcP... et calcule le hash du programme à charger (#P] ;
2. crée une clé symétrique [PK] dérivée de {#P + la clé secrète du Blind SoC };
3. chiffre les blocs d'instructions de ce code exécutable avec cette clé symétrique [§ρκΡϊ] ;
4. alloue de l'espace mémoire [addrl..addr2) dans la mémoire pour ces blocs §PKPI ainsi que pour les futures variables persistantes d'état manipulées par ce programme, et y enregistre ces blocs §PKPI ;
5. insère des informations comprenant #P, addrl, addr2 dans une table PHT (Program Hash Table].
Lorsqu'un message, contenant des données d'entrée pour un certain programme à exécuter (P] et le haché (#P] de ce programme, est reçu par le Blind SoC, son unité CMMU:
1. accède à partir du haché du programme #P reçu dans le message et via la table PHT, aux blocs du programme chiffré à exécuter §PKP stockés en mémoire dans l'espace qui lui est réservé [addrl..addrZ] ;
2. décrypte à la volée les blocs d'instructions de P, et les transmet à l'unité processeur ;
3. l'unité processeur exécute à la volée les instructions décryptées sur les données d'entrées, les variables d'état persistantes liées à P étant stockées en isolation dans addrl..addr2, et les messages générés incluant #P et étant signés par CMMU.
Ainsi, avant émission d'un message par le Blind SoC, l'unité CMMU insère dans le message à émettre le haché (#P] du programme en cours d'exécution ainsi que la signature de ce haché par le CMMU au moyen de la clé secrète (ou insère ledit haché du programme dans le corps du message à émettre qu'elle signe avec la clé secrète], ce qui permet, dans le cas où #P = #P1 = #P2 (ou selon la description plus haut en référence à la Figure 7, dans le cas où les programmes sont groupés selon une spécification] et si l'entité destinataire garantit aussi leur intégrité d'exécution, d'utiliser de tels programmes comme engagements exécutables (smart contract] au sens de la présente invention. La Figure 22 présente schématiquement les interactions que représentent ces étapes entre les différentes parties (PROCESSOR, CMMU, MEMORY] du système :
1] Réception par CMMU d'un message contenant des données d'entrée d'un programme à exécuter ainsi que le haché dudit programme ;
2] CMMU localise dans la table PHT, à partir dudit haché, ledit programme chiffré, le charge dans son cache et le décrypte (bloc par bloc] ;
3] CMMU transmet à la volée le (un bloc à la fois du] programme décrypté à PROCESSOR pour exécution ;
4] Le cas échéant, PROCESSOR requiert d'accéder à des variables persistantes d'état (PSV et/ou tags] déjà créées ou en crée/les met à jour et demande de les stocker, ou en supprime, et
5] CMMU accède et décrypte / chiffre et mémorise lesdites variables persistantes d'état ;
6] Le cas échéant, PROCESSOR prépare un message à émettre, et
7] CMMU y insère le haché dudit programme en exécution et sa signature au moyen la clé secrète et émet le message. Avantageusement, le CMMU est apte à vérifier les intersections requises d'ensembles de nœuds miroirs décrits plus haut lors de la réception d'un WM et pour chaque transaction de transfert de tags reçue.
En référence à la Figure 22, les WM peuvent être émis par un Blind SoC (générés par l'exécution d'un programme WP] ou reçus en tant qu'input de l'utilisateur ou par un autre dispositif (messages « Quasi- WM »] et comprennent le haché #WP de ce programme dans les deux cas.
La Figure 23 présente un message WM de transfert de tags, en entrée, qui véhicule une transaction (txl], cette transaction provoquant dans la mémoire (MEMORY] au niveau des Tags, l'insertion des tags amenés par cette nouvelle transaction, chaque tag comprenant les données représentatives de la succession (graphe] des transactions à l'amont, comme déjà décrit, à chacune étant associé l'adresse du WN amont l'ayant généré et les adresses de ses WN miroirs. Avec ces informations, pour valider ou non le message, le CMMU vérifie l'intersection requise entre ses propres nœuds miroirs et lesdites adresses de WN miroirs, ainsi que le fait qu'au moins un (ou certains, selon les paramètres de configuration] sont des hard WN. Cette figure présente également un message WM de transfert de tags en sortie qui véhicule une transaction (tx2] générée par le CMMU sur instruction d'un WP, le CMMU neutralisant (rendant inconsommables à nouveau] les tags consommés par cette transaction générée (pour éviter un double-spend] et générant le ou les nouveaux tags qui en sont en output, des graphes respectifs des transactions à l'amont leur étant associés (à partir des graphes à leur amont].
Par ailleurs, le CMMU gère les simplifications de transactions décrites plus loin à la section « Transactions Bitcoin off-chain » : une simplification consiste à remplacer au moins deux transactions inter-WN antérieures qui ne sont pas encore insérées dans la blockchain, par une nouvelle (ou le moins possible de] transactionfs] de remplacement, le CMMU veillant à ce que le solde courant restant inchangé par ces remplacements (ce mécanisme est générique, les transactions de transfert de tags étant plus générales que les transactions Bitcoin].
La Figure 23 montre également une requête https générée par le CMMU qui prend en charge les handshakes et les opérations cryptographiques, laissant au terminal auquel il est couplé le rôle d'interface d'entrée/sortie (au niveau TCP] afin d'assurer l'intégrité des données de bout en bout (le site accédé étant de confiance].
Enfin, le CMMU prend aussi en charge la gestion et la signature par le Blind SoC des messages Non-WM (en sortie, comme présenté à la Figure 23 et décrit plus haut à la section « WN émettant un message au monde extérieur »].
Contraintes sur les tags
Le CMMU inclut un mécanisme permettant de contraindre l'utilisation des tags par les programmes WP. Ainsi un tag peut être réservé pour usage par un WP ou des WP liés (cf. Figure 7], de manière à éviter que des unités de compte du tag ne puisse être dépensées par un WP qui n'est pas habilité à le faire.
Ainsi un WP est capable d'indiquer au CMMU qu'un tag est réservé à son usage, et le CMMU affecte à ce tag un marquage indiquant cette réservation au niveau de la mémoire MEMORY.
Ce marquage peut être levé à l'initiative du même programme, rendant ainsi le tag à nouveau utilisable par d'autres WP.
Dans le cas d'une tentative, par un WP, de génération de transaction alimentée par un tag pour lequel ce WP n'est pas habilité, le CMMU interdit l'opération, et les UA de ce tag ne pouvant donc pas être consommées (du fait qu'une telle transaction ne peut avoir lieu]. Cette architecture permet aux WN de réserver des UA matérialisées par des tags à certains types d'opérations destinées à être exécutées par les WP qui les ont respectivement réservées, et donc de mettre en œuvre des engagements sur la base d'UA qui sont bloquées à cet effet, tels que les CCC décrits dans WO2016/120826 A2.
Perfectionnements aux CCC
Rappel du cadre général Le cadre général est ici un ensemble de nœuds qui sont bénéficiaires d'engagements CCC et peuvent eux-mêmes fournir un engagement CCC du même type à d'autres nœuds, ces derniers à encore d'autres, et ainsi de suite, les nœuds et les engagements CCC formant ainsi un réseau de "networked- insurance".
Prime et Contribution potentielle maximum
Un premier nœud, ayant fournit à des seconds nœuds un engagement CCC d'un certain type, ajoute (typiquement de manière échelonnée dans le temps] sur son solde CCC (somme d'UA de tags réservés] et conformément à cet engagement, une "prime" (analogue à une prime d'assurance] pour couvrir l'ensemble de ces seconds nœuds, et spécifie pour chaque second nœud un seuil signifiant à quelle hauteur ce second nœud est couvert par lui, seuil appelé "contribution potentielle maximum". Suite à un sinistre sur l'un des seconds nœuds couverts par un premier nœud : le premier nœud transfère à ce second nœud, à partir de son solde CCC, un certain montant d'UA (voir "Transaction de transfert d'UA"] en échange de "bons de prime" (voir la définition qui suit] émis par ce second nœud. Le montant de ce transfert est fonction du solde CCC du premier nœud et est à hauteur de la contribution potentielle maximum spécifiée pour ce second nœud particulier.
Bons de prime
Un "bon de prime" émis par un second nœud est une reconnaissance de dette "au porteur" émise en contrepartie d'une contribution reçue par ce second nœud en exécution d'un engagement CCC, suite à un sinistre, contribution reçue de la part du premier nœud qui est le fournisseur de cet engagement CCC. Cette dette est remboursable par le second nœud conformément à cet engagement CCC (typiquement de manière échelonnée dans le temps] dans la limite du montant de la prime prévue pour le second nœud, et pro rata de cette contribution reçue (parmi le cas échéant une pluralité de contributions reçues]. Les bons de prime sont "au porteur" en ce sens que, tant que leurs montants respectifs de dette ne sont pas encore épongés (c'est-à-dire qu'il reste encore des UA à recevoir], ils représentent un certain montant de valeur à terme, ont une certaine "valeur immédiate en UA", et peuvent être transférés (voir "Transaction de transfert d'UA"] d'un nœud à un autre. La "valeur immédiate en UA" d'un bon de prime est défini comme étant la somme des montants qu'il représente à différents termes prévus moins la somme des intérêts respectifs pour les durées de ces termes. Le premier porteur d'un bon de prime est le premier nœud ayant contribué, en exécution d'un engagement CCC, au second nœud sinistré qui a émis ce bon de prime. A noter que ce dernier le lui a transféré en mode "à n'utiliser qu'en cas de sinistre" : la valeur immédiate du bon de prime ainsi reçu par le premier nœud s'ajoute au solde CCC (qui est réservé à payer des sinistres] et il ne peut être dépensé (ni même en partie] que pour dédommager un sinistre selon cet engagement CCC, par le ou les WP habilités.
Bons de prime concurrents
Ledit second nœud sinistré transfère également, audit premier nœud, tous les bons de prime qu'il a lui même reçu à partir des nœuds à l'aval auxquels il a contribué dans le passé dans le cadre du même CCC, toujours dans un mode "à n'utiliser qu'en cas de sinistre", mais ici dans un mode "concurrent" (c'est-à-dire répliqué et synchronisé] et pour moitié (ou pour une proportion donnée dans le CCC] de leurs valeurs respectives. Chaque bon de prime peut ainsi être répliqué sur plusieurs nœuds à la fois, peut seulement être utilisé pour paiement (pour toute ou partie de sa valeur immédiate] en cas de sinistre et seulement dans le cadre du CCC en question, et un paiement par bon de prime le consomme en même temps (par synchronisation] sur tous les nœuds où il se trouve (y compris sur ledit premier nœud qui a contribué au sinistre qui en est à l'origine et vers lequel il a été transféré en premier]. Pour ce faire, chaque paiement de sinistre par bon de prime est le cas échéant notifié par le nœud payeur aux autres nœuds concurrents où il a également été transféré et lorsque sa valeur tombe à zéro, il est supprimé sur l'ensemble de ces nœuds. Envoi de Message
On va maintenant décrire un mode de réalisation selon lequel un message émis comportant (et identifié par] un nonce2 est considéré comme "envoyé" par son émetteur sur réception d'un message d'accusé de réception (ack) retourné par le destinataire de ce message et comportant ledit nonce2 comme décrit ci-avant, c'est-à-dire en tant que valeur de l'argument noncel.
Ledit message expire après un certain temps, fixé pour le code exécutable donné, temps après lequel il est typiquement re-émis un certain nombre de fois (voir plus loin la section « Garantie d'engagement en cas de non-responsiveness »].
L'accusé de réception a ainsi la forme suivante :
message: noncel:receivedNonce2, §K2(data:ack(receivedNonce2)+#P), nonce2, Kl, signKi(noncel:receivedNonce2, §K2(data:ack(receivedNonce2)+#P), nonce2), signK(Klj)
En outre, en référence à la Figure 8, lorsque Y envoi
• d'un premier message (WM1] par un premier émetteur (WN1] à un destinataire WN2 est, dans un laps de temps donné à partir de l'envoi de WM1 (qui typiquement est fixé pour le code exécutable courant], suivi de Yen voi
• d'un deuxième message (WM2] par WN2 à un autre destinataire (WN3],
un message noté "(ack(WM2]]" (entouré de parenthèses à la Figure 8], propageant l'accusé de réception "ack(WM2]" reçu de WN3 par WN2, est envoyé par ce dernier au premier émetteur (WN1]. Pour illustrer ce procédé, le message WM1 en référence à la Figure 8 est de la forme suivante :
WM1 from WN1 to WN2: noncel, §K2data+#P, nonce2:Nl, Kl, signKi(noncel, §K2data+#P, nonce2.-Nl ), signK(Kl )
et son accusé de réception (qui entérine cet envoi de WM1] est de la forme suivante :
ack(WMl) from WN2 to WN1: noncel.Nl, §K2data:ack(Nl)+#P, nonce2, Kl, signKl(noncel:Nl, §K2data:ack(Nl )+#P, nonce2), signK(Kl )
A la suite de ce premier message identifié par le nonce2 "NI", le message WM2 de la Figure 12, envoyé de WN2 à WN3, est de la forme suivante:
WM2 from WN2 to WN3: noncel, §K2data+#P, nonce2:N2, Kl, signKi(noncel, §K2data+#P, nonce2:N2), signK(Kl )
Sur réception de l'accusé de réception entérinant WM2 retourné par WN3, qui est de la forme suivante :
ack(WM2] from WN3 to WN2: noncel:N2, §K2data:ack(N2)+#P, nonce2, Kl, signKi(noncel:N2, §K2data:ack(N2)+#P, nonce2), signK(Kl)
pourvu que cet accusé de réception parvienne à WN2 dans le laps de temps donné à partir de l'envoi de WM1, comme le montre la Figure 12, WN2 le propage à WN1 en un message « (ack(WM2]] » qui est de la forme suivante :
(ack(WM2]] from WN2 to WN1: noncel.Nl, §K2datœ{(ack(N2),payload)}+#P, nonce2, Kl, signKi(noncel:N2, §K2data:{(ack(N2),payload)}+#P, nonce2), signK(Kl)
payload étant un contenu dépendant du code exécutable en question, telle que par exemple le contenu de WM2.
Le même procédé se poursuit dans le cas d'une chaîne plus longue de messages jusqu'à une profondeur maximum donnée (typiquement cette profondeur étant fixée pour le code exécutable donné]. Par exemple, et en référence à la Figure 8, cette chaîne étant composée
• d'un premier message (WM1] d'un premier émetteur (WN1] à un deuxième (WN2],
• suivi (dans un laps de temps donné] d'un message (WM2] du deuxième à un troisième (WN3], puis
• suivi (dans le laps de temps donné à partir de l'envoi de WM1] d'un message (WM3] du troisième à un quatrième (WN4],
l'accusé de réception reçu du quatrième (WN4] est aussi propagé de proche en proche jusqu'au premier émetteur (WN1], pour aboutir au message "((ack(WM3]] " envoyé par WN2 à WN1 et comportant une information « :{(ack(N2),payloadl), (ack(N3),payload2)} » correspondant à la suite des messages échangés :
C(ack(WM3]]] from WN2 to WN1: noncel.Nl, §K2data:{(ack(N2),payloadl), (ack(N3),payload2)}+#P, nonce2, Kl, signKi(noncel:N2, §K2data:{(ack(N2),payloadl), (ack(N3),payload2)}+ttP, nonce2), signK(Kl)
payloadl et payload2 dépendant du code exécutable en question et étant par exemple les contenus respectifs de WM2 et WM3. De préférence, dans un but de privacy, seule la partie qu'il est utile de communiquer l'est, éventuellement après transformation.
On verra l'intérêt de cette propagation d'accusés de réception dans le procédé suivant.
Transactions Bitcoin off-chain
On va maintenant décrire un procédé à base de WN pour matérialiser (sérialiser] des transactions de transfert d'unités de valeur, de sorte à pouvoir les enregistrer par exemple dans une blockchain. Dans la mise en œuvre décrite ci-après, des transactions Bitcoin, valides et directement insérables dans la Bitcoin Blockchain, sont générées - mais sans nécessairement devoir les insérer dans cette Blockchain, tout en offrant les mêmes garanties que si elles l'étaient. (Le même procédé pouvant être transposé aux autres protocoles à base de blockchain, tels qu'Ethereum]. Ainsi, dans ce qui suit, les unités de valeur dont il est question sont des BTC.
La Figure 9 présente ainsi un exemple avec trois Wallet Nodes (« WN1 », « WN2 » et « WN3 »] où tout d'abord l'utilisateur de WN1 (ou un tiers] crée une transaction Bitcoin entrante (« Txl »] en faveur de WN1 (ayant un output donnant 10 BTC à WN1], et classiquement diffuse (« broadcast »] cette transaction qui est alors insérée dans la blockchain, ceci ayant pour effet de garantir à l'utilisateur de WN1 que seul WN1 peut dépenser ces 10 BTC qui lui sont disponibles sur Txl. (A noter que même dans le cas où Txl a été créée indépendamment de WN1, des moyens sont prévus pour que WN1 en soit notifié et/ou le vérifie/détecte après son insertion dans la blockchain, attende ou pas un certain nombre de confirmations de blocks, et mette à jour ses variables persistantes d'état par rapport à cette nouvelle entrée.]
Les trois grands traits verticaux représentent l'évolution de ces Wallet Nodes dans le temps (de haut en bas]. Ainsi, à la suite de Txl, on voit sur cette figure une séquence de plusieurs transactions entre WN (Tx2, Tx3, etc.], ainsi que d'autres transactions entrantes (à partir d'adresses non-WN, en faveur de WN1, WN2 ou WN3, telle que Tx4 qui est une transaction entrante en faveur de WN2] et des transactions sortantes (à partir de WN1, WN2 ou WN3 en faveur d'adresses non-WN, telle que Tx7], avec à chaque fois que c'est faisable, un remplacement d'au moins deux transactions inter-WN antérieures par une nouvelle, afin qu'il ne reste de préférence qu'une seule (ou le moins possible de] transaction non-broadcast entre deux WN données, celles qui ont été remplacées étant supprimées (on entend par là qu'elles sont au moins marquées comme tel et considérées comme elles l'étaient] et le solde courant restant inchangé par ces remplacements. D'une manière générale, le procédé consiste à simplifier un ensemble de transactions par mises à jour de ces derniers, tirant parti du fait qu'elles ne sont pas broadcast (ci après « non-broadcast »].
Lorsqu'une transaction transférant des BTC de WN1 à WN2 est générée (telle que Tx2], elle est signée par WN1 (signature classique de transaction Bitcoin] et communiquée à WN2 par message. Une création (ou mise-à-jour ou annulation de transaction, pour autant qu'elle soit non-broadcast) est entérinée par envoi de message (au sens de la section précédente].
Sur la Figure 9, chaque transaction est représentée abstraitement par une boîte (un carré] placée sur une flèche. Le nombre à l'intérieur de cette boîte représente le montant transféré du point de vue de l'utilisateur. Lesdites transactions entrantes et sortantes (c'est-à-dire qui ne sont pas des transactions entre WN] sont représentées par des boîtes plus grandes que les transactions inter-WN. Lesdits soldes sont représentés en italique (le long des grands traits verticaux, à leur droite]. Ladite suppression d'une transaction inter-WN est présentée par un petit trait oblique sur le bout de la flèche représentant cette transaction. Lesdites transactions de remplacement (tel que Tx6] sont représentées de manière distincte au moyen d'une flèche à double trait et lorsqu'elles sont elles-mêmes supprimées (comme dans le cas de Tx8] ceci est aussi présenté par un petit trait oblique.
Ainsi, la Figure 9 montre en haut à gauche, une rentrée (Txl] de 10 BTC sur WNl dont le solde était juste avant à 0. Par cette transaction, son solde passe ainsi à 10 (montré en italique]. Ces 10 BTC sont transférés (par Tx2] à WN2, le solde de WNl repassant à 0 et le solde de WN2 passant de 0 à 10. Puis WN2 transfère (par Tx3] 5 BTC à WN3 (il lui en reste ainsi 5]. Plus bas, 10 BTC sont transférés à WN2 à partir d'une adresse non-WN (par la transaction Tx4 qui a été insérée dans la blockchain], le solde de WN2 passant ainsi de 5 à 15. WN2 transfère 4 BTC à WN3 (Tx5], les soldes de part et d'autre passant ainsi respectivement à (15-4=] 11 et (5+4=] 9.
Il y a maintenant deux transactions non-broadcast de WN2 à WN3 (Tx3 et Tx5] et elles peuvent être remplacées par une transaction transférant leur somme (Tx6, transférant 5+4=9 BTC]. Tx3 et Tx5 sont ainsi supprimées, ce qui est montré sur la Figure 9 par les petits traits obliques sur les flèches représentant ces transactions.
WN3 transfère 1 BTC à un tiers non-WN par la transaction Tx7 qui est broadcast. Par conséquent, toute la chaîne des transactions qui l'alimentent (il s'agit ici de Tx6 et Tx4 seulement, comme montré à la Figure 11 décrite plus loin] sont aussi broadcast (insérées dans la blockchain pour que que Tx7 puisse aussi l'être] et ne pourront donc pas être supprimées - elles cessent ainsi d'être remplaçables. WN2 transfère 5 BTC à WNl (Tx8]. Alors, comme il y a aussi la transaction Tx2 entre ces WN, ces deux transactions (Tx2 et Tx8] sont remplacées avec Tx9 de WNl à WN2, qui transfère leur différence (10- 5=5 BTC] du fait qu'elles sont en sens inverse. Tx2 et Tx8 sont ainsi supprimées.
Cette transaction de remplacement Tx9 est elle-même supprimée suite à la génération de Txl 2 (toutes deux étant non-broadcast], donnant lieu à la transaction de remplacement Txl3. (La Figure 9 montre ce remplacement tel qu'il est perçu par l'utilisateur, tandis que les Figures 12 et 13 décrites plus loin en montrent les détails au niveau Bitcoin].
TxlO et Txl5 sont générées entre WNl et WN3, sont de même valeur, en sens inverse et non- broadcast, et peuvent donc simplement s'annuler, c'est-à-dire être supprimées sans donner lieu à une transaction de remplacement. (Ici encore, il est intéressant d'en voir aux Figures 13 et 14 les détails au niveau Bitcoin].
Txl l et Txl6 qui sont de même sens (de WN3 à WN2] et non-broadcast, donnent lieu à la transaction de remplacement Txl7 qui transfère leur somme et qui est elle-même remplaçable tant qu'elle reste non-broadcast (détails au niveau Bitcoin aux Figures 14 et 13].
En revanche, la transaction sortante Txl8 [broadcast] provoque le broadcast de la chaîne des transactions qui l'alimentent et qui ne peuvent dès lors plus être supprimées, en l'occurrence il s'agit de Txl3 (voir la Figure 15].
Les transactions Bitcoin présentées à la Figure 9 sont « abstraites », en ce sens qu'elles présentent les montants transférés du point de vue de l'utilisateur mais ne montrent pas les inputs et outputs de ces transactions au sens de Bitcoin. Les Figures 10 à 15 présentent les réelles transactions correspondant aux transactions abstraites de la Figure 9 (en explicitant leurs inputs et outputs].
Le procédé de leur génération se base sur le fait qu'à un solde disponible dans une WN (le nombre en italique sur la figure] correspond toujours au moins (un montant disponible sur] un output en faveur de ce WN (le total de ces outputs étant égal à ce solde], que l'on peut combiner de tels outputs pour les connecter aux inputs d'une transaction générée par ledit WN, et dans le cas d'un dépassement, retourner le surplus (appelé « change »] audit WN par un output supplémentaire. Et en ce qui concerne la mise en œuvre de remplacements/suppressions, même dans le cas où un output d'une transaction à supprimer (par exemple TxlO, voir Figure 13] est connecté à un input d'une transaction qu'il n'est pas prévu de supprimer (Txl l] dans la même opération, ce dernier peut être automatiquement mis à jour pour être connecté à un output disponible d'une autre transaction (Txl3]. Sur les Figures 10 à 15, les input(s] et output(s] des transactions sont montrés par des petites flèches horizontales et leurs connexions sont montrées par de fines lignes courbes pointillées (un output libellé « WN1 » d'une transaction est connecté à un input aussi libellé « WN1 » d'une transaction ultérieure, et ainsi de suite].
II est implicite sur ces figures que la création d'une transaction comprend Y envoi de message(s] au sens de la section précédente. Par exemple, la génération de Tx3 par WN2 entraîne Y envoi par WN2 d'un message l'indiquant à WN3 et cette transaction n'est réellement créée que sur retour d'un accusé de réception par WN3 (voir aussi la section « Garantie d'engagement en cas de non-responsiveness »]. La Figure 10 montre les transactions réelles Txl à Tx5, qui correspondent aux transactions abstraites de même libellé de la Figure 9. On y voit que, bien que, selon la Figure 9, Tx3 ne transfère que 5 BTC à WN3, son input prend 10 BTC de Tx2 (du fait que Tx2 n'a qu'un output de 10 BTC en faveur de WN2] et retourne 5 BTC à WN2. Autrement dit, Tx3 a un output de 5 BTC en faveur de WN2, en plus de l'output de 5 BTC en faveur de WN3.
Les transactions Tx3 et Tx5 de la Figure 10 sont remplacées à la Figure 11 avec la transaction Tx6, générée par WN2 (et dont la notification de remplacement est envoyée à WN3]. Pour effectuer ce remplacement, WN2 peut connecter Tx6 à Tx2 ou à la transaction entrante Tx4. Cette dernière est préférée du fait que la chaîne de transactions d'alimentation à l'amont est plus courte (ou par application d'heuristiques plus complexes]. En effet, cette même figure présente la transaction sortante Tx7 qui est broadcast d'emblée et, si au contraire Tx6 était connectée à Tx2, Tx2 aurait aussi dû être broadcast et n'aurait pas pu être plus tard remplacé comme le présente la Figure 12.
La Figure 12 présente le résultat du remplacement de Tx2 et Tx8 avec Tx9, ainsi que la génération des transactions TxlO par WN1 (vers WN3], Txll par WN3 (vers WN2] et Txl2 de nouveau par WN1 (mais vers WN2].
La Figure 13 présente le remplacement par Txl 3 de la transaction de remplacement Tx9, suite à la génération de Txl2. En effet, comme le montre la Figure 9 (et la Figure 12], l'effet cumulé de ces deux transactions est de fournir 5+4=9 BTC de WN1 à WN2. Ce remplacement a comme effet de mettre à jour l'input de TxlO, ainsi que son deuxième output qui est maintenant connectée à la nouvelle transaction Txl3. On voit aussi sur cette figure la génération des transactions Txl4 à Txl6.
La génération de Txl5 a pour effet d'annuler l'effet de TxlO, en effet elle transfère 1 BTC en sens inverse. La Figure 14 présente le résultat de cette annulation qui entraîne la mise à jour de l'input et l'output de Txl l.
Enfin, à la Figure 15, Txll et Txl6 sont remplacées par Txl7 qui connecte son input à l'output de Tx7. Cette Figure montre aussi que WN1 génère la transaction sortante Txl8 alimentée par Txl3, ce qui rend Txl3 broadcast et donc non supprimable.
On a déjà décrit plus haut et dans la demande PCT WO2016/120826 A2 la propriété de garantie d'intégrité d'exécution et blindness des WN selon laquelle, sur réception d'un WM, le WN exécute nécessairement le WP spécifique indiqué dans ce WM, à l'exclusion de toutes autres instructions, sur les données d'entrée fournies, à l'exclusion de toutes autres données, et n'émet que les WM qui le cas échéant sont prévus dans ledit WP par rapport à ces données d'entrée et les variables persistantes d'état, en assurant Yinaccessibilité sans discontinuité à la fois des données d'entrée, de leur traitement, des variables d'état et du résultat du traitement.
Les opérations décrites ci-dessus de génération et manipulation de transactions Bitcoin (qui peuvent être insérées ou non dans la blockchain] tirent parti de ces propriétés pour sécuriser lesdits suppressions/remplacements. Ainsi, par exemple, la génération par WN1 de la transaction de remplacement Tx6 (en référence aux Figures 9 et 11] ne présente pas le risque que WN2 (ou son utilisateur ou propriétaire] ne supprime pas la transaction Tx2 que Tx6 remplace. En effet :
• tant que WN2 ne broadcaste pas Tx2 pour insertion dans la blockchain (par exemple suite à une commande de l'utilisateur], l'utilisateur ne peut pas voir ie contenu de Tx2 (ce contenu comprenant la signature par WNl de ce paiement et que l'utilisateur de WN2 aurait pu, s'il n'y avait pas la propriété de blindness, copier et broadcaste plus tard par d'autres moyens] ;
• une commande de broadcast n'est pas prise en compte par WN2 après que Tx2 est supprimée (ou lorsque Tx2 est marquée comme étant en mode « supprimée »] dans WN2 ;
· lorsque le contenu de Tx2 a été dévoilé à l'utilisateur (suite à son broadcast], il ne peut plus être supprimé/remplacé au sens du présent procédé de l'invention.
A noter que toutes les différentes sortes de transactions Bitcoin possibles peuvent être générées (et du fait que les WN sont aptes à garder leurs états, le présent procédé de l'invention est également applicable à Ethereum notamment]. Les transactions sont communiquées par WM aux WN ayant les adresses spécifiées sur ou pour les outputs de ces transactions. Des signatures requises peuvent être communiquées par WM. Par exemple, une transaction requérant n parmi m signatures (multisig] peut être générée par WN et communiquée par WM aux m signataires potentiels dont certains retourneront leur signature.
Le fait de ne pas avoir à insérer une transaction dans la blockchain présente les avantages notamment de (1] confirmation instantanée, (2] non-paiement de fees et (3] volume théoriquement illimité des transactions possibles. Dans quels cas a-t-on besoin d'insérer une transaction dans la blockchain ?
— Les transactions entrantes (à partir d'adresses non-WN] doivent nécessairement être insérées dans la blockchain au préalable afin de se prémunir d'un double spend. Ainsi, le WN ne prend en compte (ou n'entérine] une transaction entrante qu'une fois qu'elle est visible dans la blockchain. — Les transactions sortantes ne sont broadcast que facultativement, dans la mesure où il n'y a (presque] aucun risque de double spend par le WN (le risque de violation (« tampering ») d'un système-sur-puce de l'état de l'art étant faible, d'autant plus en présence de WN miroirs - voir la description des WN miroirs plus haut]. En pratique, une transaction sortante est peut-être insérée dans la blockchain au moment où au moins un output destiné à une adresse non-WN est prévu d'être dépensé. A ce moment, son contenu devient accessible, ainsi que les transactions amont, et ces transactions cessent d'être supprimables.
— Les transactions inter-WN peuvent avantageusement ne pas être broadcasté, mais il n'est pas interdit de le faire (n'importe quand]. Une transaction broadcastée (en vue de la faire insérer dans la blockchain] ne sera pas remplacée puisqu'elle ne peut être supprimée, mais les autres transactions continuent à présenter les avantages susmentionnées sauf lorsqu'elles l'alimentent (la perte d'avantage est locale à la transaction broadcast + la chaîne des transactions amont qui l'alimentent]. On a vu que les transactions Bitcoin inter-WN générées sont entérinées sur réception d'accusé de réception (de leurs bénéficiaires respectifs] et que deux transactions entre deux WN données sont, dans le cas où aucune n'est broadcastée, simplifiées (remplacées par une seule transaction ou simplement annulées] dans certains cas. On va maintenant décrire, en référence aux Figures 16 à 19, un procédé de simplification (aussi par remplacement ou simple annulation] d'une pluralité de transactions entre plus de deux WN. Ce procédé utilise le procédé de propagation d'accusés de réception décrit plus haut, leurs payloads (aussi décrit plus haut] propageant l'information des BTC transférés entre des WN non directement voisins.
Les Figures 16 à 19 reprennent l'exemple des Figures 9 à 15 mais à la différence près que sur les Figures 16 à 19, la transaction Tx7 est générée (par WN3] après que la transaction Txl3 est entérinée (générée par WNl]. (A noter que le même procédé aurait pu être décrit sur l'exemple présenté aux Figures 9 à 15, mais en considérant que Tx7 n'est pas broadcastée avant que Txl3 ne soit entériné.] Grâce à la propagation par WN2 vers WNl de l'accusé de réception par WN3 de Tx6 pour 9 BTC, les transactions Tx9 et Txl2 pour un total aussi de 9 BTC étant entérinées (sur réception par WNl d'accusés de réception de la part de WN2], WNl remplace ces trois transactions par une seule transaction Txl9 qui transfère 9 BTC de WNl à WN3 directement.
En variante de mise en œuvre (et c'est cette variante qui est présenté dans les Figures 16 à 19], tout d'abord Tx9 (5 BTC] et Txl2 (4 BTC], toutes deux de WNl à WN2, sont remplacées par Txl3 (9 BTC, de WN1 à WN2], puis cette dernière et Tx6 (9 BTC, de WN2 à WN3) sont remplacées par Txl9 (9 BTC] de WN1 à WN3.
Pour présenter les transactions Bitcoin réelles générées, la Figure 17 reprend la Figure 13 mais sans que Tx7 et les suivantes ne soient encore générées. La Figure 18 montre la transaction Txl9 (9 BTC de WN1 à WN3] qui remplace les transactions Txl3 (9 BTC de WN1 à WN2) et Tx6 (9 BTC de WN2 à WN3, en prenant 10 BTC de Tx4 et en se gardant un change de 1 BTC] montrés à la Figure 17. Enfin, comme on le voit à la Figure 19, l'ensemble des neuf transactions inter-WN de cet exemple ont été simplifiées en un ensemble de deux transactions seulement (Txl9 et Txl7].
On comprend que ce procédé peut être appliqué pour simplifier des chemins de transactions inter-WN dans un réseau de plus de trois WN (sans limitation de ce nombre].
Les unités de compte dont il a été question (BTC] sont avantageusement mises en œuvre sous forme de tags et lesdites transactions Bitcoin sont des transactions de transfert de tags dont les UA sont des BTC (comme décrit plus haut].
Ainsi la possibilité de faire consommer des UA de tags par différents types de programmes WP, pour autant qu'ils soient habilités à le faire (cf. description des tags et CCC], permet de conférer à un système basé sur Bitcoin la puissance des smart contracts d'un système tel que Ethereum.
Garantie d'engagement en cas de non-responsiveness
Pour rappel, la demande PCT No. WO2016/120826 A2 décrit un système et procédé dans lesquels, en réaction à la réception d'un message par un dispositif muni d'un processeur, des instructions non modifiables (analogues au Root-of-Trust, ou RoT] chargent dans ce système-sur-puce un code exécutable dont le hash correspond à un hash donné inclus dans ledit message reçu. L'exécution qui suit de ce code exécutable, dans ledit dispositif, est ainsi prédéterminée par rapport à ce message reçu. Ladite correspondance est garantie dans la mesure où des restrictions d'accès appropriées entre les différentes parties dudit système-sur-puce existent et ne peuvent pas être altérées. Le code exécutable ainsi imposé par l'émetteur du message est quelconque et apte à mettre à jour des variables d'état (seul le code exécutable possédant ces variables d'état étant apte à les modifier] et générer encore d'autres messages qui vont eux-mêmes propager ce même code de hachage vers encore d'autres tels dispositifs.
Le système permet ainsi de garantir les engagements exécutables (décrits plus haut] que représentent lesdits codes exécutables, dans la mesure où ledit dispositif reste responsif (actif, allumé]. En effet, ce procédé et système garantissent (i] que le dispositif récepteur d'un tel message réagit selon le « smart contract a que ce message impose et (ii] que ce message a lui-même été généré dans le cadre exactement du même smart contract (puisque produit par le même code exécutable]. Ce dispositif est mis en œuvre en un système-sur-puce muni d'une clé privée secrète (accessible exclusivement par un sous-système de signature « Sign », cf. Figure 5 de cette demande PCT] et apte :
* en réaction à la réception d'un message (« Wallet Message » ou « WM »] contenant un hash (« #WP »], à charger pour exécution, à partir d'un sous-système de codes exécutables quelconques (« Wallet Programs »], le code exécutable quelconque (« Wallet program » ou « WP »] dont le hash du contenu correspond audit hash inclus (« #WP »] contenu dans ledit message (WM] ;
* avant la signature d'un message (WM] à émettre, à amener le sous-système de signature (Sign] à générer ou à vérifier le hash du code exécutable quelconque couramment chargé (#WP], pour inclusion dans ledit message (après éventuel chiffrement de ce hash avec d'autres données à transmettre], garantissant ainsi que le même hash est re-propagé d'un message reçu à un message émis (ou, avantageusement et comme déjà décrit, les WN s'échangent des WM incluant des hachés différents de WP différents à exécuter, mais dont la correspondance est garantie au moyen d'une spécification commune des WP à exécuter, incluse dans les WM]. On va maintenant décrire un procédé, complémentaire au procédé de gestion d'engagements en général, pour garantir un ou plusieurs engagements d'un WN pour le cas où ce WN deviendrait non- responsive.
La Figure 20 présente un WN fournisseur d'engagement susceptible d'être non-responsif (El], un WN censé pouvoir bénéficier de l'engagement en question (E4], ainsi que des WN repreneurs de cet engagement en cas de non-responsiveness (E51 à E53]. Le procédé comprend les étapes suivantes, en référence à cette figure :
1. PT-List spécification : Un engagement (quelconque] d'un fournisseur de cet engagement (El] à un bénéficiaire de cet engagement (E4] spécifie une liste « PT-List » (Potentiel Transférées List] de WN repreneurs potentiels (E51, E52, E53] en cas de non-responsiveness dudit fournisseur (El].
2. Persistent State Variables Synchronisation : Ledit fournisseur (El] synchronise autant que possible les Persistent State Variables de l'engagement en question vers tous les WN repreneurs potentiels (E51, E52, E53].
3. Non-Responsiveness Confirmation : Suite à l'envoi d'un WM par ledit bénéficiare (E ] audit fournisseur (El], constat par ledit bénéficiare (E4] du non-responsiveness dudit fournisseur (El].
4. Transférée Sélection : Ledit bénéficiaire (E4] et/ou lesdits repreneurs sélectionnent au moins un repreneur (E51] parmi les repreneurs potentiels de la PT-List.
5. Delegated Execution : Traitement dudit WM par ledit repreneur sélectionné (E51] et ce dernier synchronise ensuite les variables persistantes d'état autant que possible vers tous les autres WN repreneurs potentiels (E52, E53] ainsi que vers ledit fournisseur qui était non-responsive (El].
6. Continuation : Si ledit repreneur sélectionné est non-responsive ou, pour un WM ultérieur émis par un bénéficiaire d'un engagement dudit fournisseur qui était non-responsive (El], si ce dernier est toujours non-responsive, le même procédé est appliqué à partir de l'étape 3 (Non- Responsiveness Confirmation].
Ces étapes sont mises en œuvre corne suit :
PT-List spécification
On va d'abord introduire les engagements de type « Commitment Transfer Commitment » (CTC] : de manière analogue aux TOC [« Takeover Commitment ») dont le but est de satisfaire un client qui change de fournisseur (décrits dans la demande PCT WO2016/120826], un CTC sert à indiquer au bénéficiaire d'un engagement quelconque que, si le fournisseur (Wallet Node] dudit engagement quelconque devient non-responsive, automatiquement le fournisseur (Wallet Node] du CTC honore ledit engagement quelconque à sa place. Un fournisseur de CTC est appelé « Potential Transférée » (« PT »].
Selon ce procédé, à tout engagement (engagement quelconque, smart contract] émis est associé une « Potential Transférées List » (« PT-List »] contenant les adresses des Wallet Nodes (PT] qui ont fourni un CTC au fournisseur (ou aux signataires] de cet engagement (ceci afin d'indiquer à son bénéficiaire quelles sont les entités (Wallet Nodes] chargées de l'honorer à sa place s'il devient non-responsive], ces derniers étant en charge d'exécuter l'engagement qui est en défaut dans la mesure où cette exécution est automatique, sans aucun input de la part d'utilisateur.
Persistent state variables Synchronisation
Pour que lesdits Wallet Nodes repreneurs (E51, E52, E53] de la PT-List d'un fournisseur non- responsive (El] soient aptes à honorer son engagement à sa place, il faut qu'ils aient l'état courant des PSV et tags du WP correspondant. Par exemple, dans le cas de reprise d'un CCC, il faut qu'ils aient les valeurs courantes des variables persistantes (notamment les soldes, montant+ et montant- pour différents émetteurs] du Wallet Program CCC afin de pouvoir générer une transaction de transfert d'UA le cas échéant. Dans ce but, à chaque mise-à-jour de ses données, le Wallet Node (El] fournisseur d'un engagement notifie tous les WN (E51, E52, E53] de la PT-List donnée dans cet engagement, du nouvel état de ses données. Grâce à la propriété de blindness des Wallet Nodes les utilisateurs ou proprétaires de ces WN ne peuvent pas accéder à ces données. Non-Responsiveness Confirmation
A défaut de réception d'un accusé de réception d'un WM réémis régulièrement vers ledit fournisseur (El] pendant une durée préalablement convenue, ledit bénéficiaire (E4] réémet ce même WM vers les WN de la PT-List (E51, E52, E53] et ledit fournisseur (El] est censé envoyer aussi à ces derniers (E51, E52, E53] une copie dudit accusé de réception du WM envoyé par le bénéficiaire (E4]. Ledit fournisseur (El] est considéré comme non-responsive par le bénéficiaire (E4] lorsque, pendant une durée préalablement convenue, aucun PT de la PT-List ne notifie au bénéficiaire (E4] sa réception dudit accusé de réception.
Transférée Sélection
Sur demande dudit bénéficiaire (E4], chaque PT de la PT-List lui envoie les n derniers WM de mise-à- jour de données (variables persistantes d'état] reçues dudit fournisseur (El], ce qui permet d'automatiquement sélectionner au moins un des PT de cette liste (E51] parmi ceux dont les données ont été mis à jour le plus récemment. Grâce à la propriété de blindness des Wallet Nodes, l'utilisateur ou propriétaire dudit WN bénéficiaire (E4] ne peut pas accéder à ces messages.
Cette étape peut prévoir de sélectionner plusieurs repreneurs parmi les repreneurs potentiels de la PT-List, ceux-ci devant signer les transactions de transfert d'unités de compte, en une multisignature de n parmi m WN (n étant inférieur à m pour prévoir le cas où tous les PT sélectionnés ne sont pas responsifs en même temps].
La sélection des m repreneurs peut être effectuée selon un protocole (comme dans le protocole de sélection aléatoire décrit plus haut] où chacun (ou au moins un certain nombre] des repreneurs potentiels de la PT-List renvoie une sous-liste de PT tirés au hasard parmi cette liste, tout d'abord sous forme de hash, puis dévoilés dans un second tour, et les repreneurs potentiels de la PT-List sélectionnent ensuite par confirmations croisées les m repreneurs sélectionnés selon une règle de sélection (telle que par exemple prendre les m qui ont été sélectionnés au hasard par le plus de repreneurs potentiels] préétablie dans l'engagement en question ou par défaut.
Delegated Execution
Ledit fournisseur (E4] notifie le (ou les] PT sélectionné (E51] qui exécute(nt] alors l'engagement dudit fournisseur, à sa place, en réaction audit WM, puis notifie(nt] tous les autres PT (E52, E53] ainsi que ledit fournisseur qui était non-responsive (El], du nouvel état courant des vraibles persistantes d'état. Continuation
Dans la mesure où les variables persistantes d'état sont synchronisés dans les PT de la PT-List, tout nouveau WM émis à destination dudit fournisseur pour le même engagement pourra ré-enclencher le même procédé à partir de l'étape 3 dans le cas où ledit fournisseur est non-responsif à nouveau.
On comprend que la crédibilité d'un engagement quelconque, tel qu'un CCC décrit dans la demande PCT No. WO2016/120826 A2, est liée non seulement à des aspects tels que les montants disponibles, mais aussi à la quantité des PT de sa PT-List pondérée par la responsiveness probable de chaque PT. Le futur bénéficiaire d'un engagement évalue automatiquement cette crédibilité, et pondère sa valeur avant d'acquérir cet engagement, en fonction de paramètres connus de responsiveness associés à ces PT (communiqués d'un WN à un autre].
A noter que pour un engagement donné d'un fournisseur, le WN bénéficiaire de cet engagement peut lui-même être un PT (c'est-à-dire faire partie de la PT-List du même fournisseur et pour le même engagement]. Dans ce cas, les variables d'état sont synchronisées chez le bénéficiaire de l'engagement qui devient lui-même apte à exécuter cet engagement dont il est bénéficiaire.
WN de remplacement en cas de non-responsiveness
Un cas d'usage du procédé de reprise d'engagement en cas de non-responsiveness, décrit ci-dessus, est d'utiliser un WN donné (E4] comme WN de remplacement d'un autre WN (El] typiquement d'un même propriétaire. L'engagement en question est simplement : transférer sur simple demande un solde dudit autre WN (El] qui est le fournisseur dudit engagement, vers ledit WN donné (E4] qui est le bénéficiaire dudit engagement et qui émet cette demande. Ainsi, en cas de perte ou de non- fonctionnement dudit autre WN (El], il peut être remplacé par ledit WN donné (E4], le solde étant automatiquement transféré audit WN donné (E4] même si ledit autre WN (El] est devenu non- responsif. Avantageusement, ledit WN donné (E4] étant lui-même un PT (de El], aucun autre PT n'est nécessaire pour assurer le remplacement de WN.
Le propriétaire en question peut prévoir plusieurs tels WN de remplacement (E4] pour un même autre WN (El] et utiliser n'importe lequel pour le remplacement.
Un ensemble de WN peuvent jouer le rôle de WN de remplacement l'un de l'autre et devenir interchangeables.
L'engagement en question peut prévoir que ledit transfert peut se faire pour une partie du solde, et qu'un certain nombre (donné dans l'engagement] de WN de remplacement doivent signer ensemble pour un transfert d'un montant supérieur à un certain seuil (multisignature de n parmi m WN, n et m étant fonction du montant à transférer].
Le procédé de reprise d'engagement en cas de non-responsiveness, décrit ci-dessus, (procédé pour garantir un engagement d'un WN pour le cas où il deviendrait non-responsive] peut être étendu pour garantir l'engagement aussi en cas de tampe ng, dans l'approche suivante : à l'étape « Persistent State Variables Synchronisation », le fournisseur de l'engagement (El] communique aussi le haché du WP de l'engagement (ainsi que son contenu lorsqu'il manque] ; une étape de vérification croisée des synchronisations est ajoutée au procédé ; à l'étape « Non-Responsiveness Confirmation » (ici renommée « Non-responsiveness or non-conformity notification »], le bénéficiaire de l'engagement (E4] notifie la non-conformité, le cas échéant, du WN fournisseur (El] par rapport audit engagement ; à l'étape « Delegated Execution », le traitement dudit WM par ledit repreneur sélectionné (E51] comprend un traitement spécifique, prévu dans le WP, pour rectifier le comportement altéré du WN non-conforme ; enfin une étape est ajoutée consistant à black-lister un WN non-conforme.
Bien entendu, la présente invention n'est nullement limitée aux formes de réalisation décrites et représentées, et l'homme du métier saura y apporter de nombreuses variantes et modifications. L'homme du métier saura également combiner et dissocier les différentes caractéristiques décrites ici en fonction des besoins et des applications.

Claims

REVENDICATIONS
1. Procédé d'établissement de poids de connexion entre nœuds d'un réseau mis en œuvre par des unités de traitement informatiques communicantes, à chaque nœud étant associées une clé publique et une clé privée, un nœud donné étant susceptible de communiquer sa clé publique à un autre nœud, formant ainsi une connexion dite réelle (« IRL-connecté »] entre les deux nœuds, et chaque nœud étant également susceptible de communiquer à un autre nœud une clé publique reçue d'un autre nœud encore, formant ainsi une connexion dite indirecte entre l'autre nœud et l'autre nœud encore, un nœud étant susceptible d'avoir un poids de connexion spécifique vis-à-vis d'un autre nœud avec lequel il a une connexion réelle ou indirecte, le procédé comprenant, pour déterminer le poids de connexion d'un deuxième nœud vis-à-vis d'un premier nœud, le calcul d'une combinaison déterminée de facteurs de pondération (influence, proximité] de troisièmes nœuds qui sont IRL-connectés au deuxième nœud.
2. Procédé selon la revendication 1, dans lequel le poids de connexion du deuxième nœud influence les facteurs de pondération des troisièmes nœuds, et comprenant en outre une mise à jour des valeurs des facteurs de pondération des troisièmes nœuds après calcul du poids de connexion du deuxième nœud.
3. Procédé selon la revendication 2, lequel est mis en œuvre de façon itérative jusqu'à convergence.
4. Procédé selon l'une des revendications 1 à 3, dans lequel l'établissement d'une connexion dite réelle (IRL-connexion] entre un premier nœud et un autre nœud comprend les étapes suivantes : au niveau d'une première unité de traitement implémentant le premier nœud, rendre accessible par lecture de proximité un code lisible par machine codant une donnée aléatoire (nonce] ; au niveau d'une autre unité de traitement implémentant l'autre nœud, lire le code lisible par machine, extraire ladite donnée aléatoire et calculer un haché de ladite donnée aléatoire,
transmettre de ladite autre unité de traitement vers la première unité de traitement via un canal de communication la clé publique associée audit autre nœud et une signature (du haché] de la donnée aléatoire effectuée avec sa clé privée,
au niveau de la première unité de traitement, vérifier ladite signature à l'aide de la clé publique reçue et de la donnée aléatoire utilisée pour générer le code lisible par machine, et enregistrer ladite clé publique si la vérification aboutit.
5. Procédé selon l'une des revendications 1 à 3, dans lequel l'établissement d'une connexion dite réelle (IRL-connexion] entre un premier nœud et un autre nœud comprend les étapes suivantes : au niveau d'une première unité de traitement implémentant le premier nœud, générer un passphrase et le rendre accessible à l'utilisateur de ladite première unité de traitement,
au niveau d'une autre unité de traitement implémentant l'autre nœud, introduire en entrée ledit passphrase, communiqué par l'utilisateur de la première unité de traitement à l'utilisateur de l'autre unité de traitement par une voie de communication mettant en jeu une action humaine entre les deux utilisateurs,
transmettre de ladite autre unité de traitement vers le première unité de traitement via un canal de communication la clé publique associée audit autre nœud et une signature (du haché] du passphrase introduit, effectuée avec sa clé privée,
au niveau de la première unité de traitement, vérifier ladite signature à l'aide de la clé publique reçue et du passphrase initialement rendu accessible à l'utilisateur de la première unité de traitement, et enregistrer ladite clé publique si la vérification aboutit.
6. Procédé selon l'une des revendications 1 à 5, dans lequel une pluralité de deuxièmes nœuds ont des poids de connexion avec le premier nœud, et dans lequel la détermination du poids de connexion d'un deuxième nœud donné vis-à-vis du premier nœud est également basée sur les poids de connexions desdits autres deuxièmes nœuds vis-à-vis du premier nœud:
7. Procédé de détermination de l'influence d'un premier nœud dans un réseau de nœuds mis en œuvre par des unités de traitement informatiques communicantes, à chaque nœud étant associées une clé publique et une clé privée, un nœud étant susceptible de communiquer sa clé publique à un autre nœud, formant ainsi une connexion dite réelle (IRL-connexion] entre les deux nœuds, et chaque nœud étant également susceptible de communiquer à un autre nœud une clé publique reçue d'un autre nœud encore, formant ainsi une connexion dite indirecte entre l'autre nœud et l'autre nœud encore, le procédé comprenant la détermination d'un facteur influence d'un nœud donné sur la base du nombre de deuxièmes nœuds ayant une connexion réelle avec ledit nœud donné et des valeurs de poids de connexion déterminées par le procédé de la revendication 6 pour les différents deuxièmes nœuds.
8. Procédé selon la revendication 7, dans lequel le poids de connexion d'un deuxième nœud vis-à- vis du premier nœud est déterminé aussi sur la base de valeurs des facteurs influence respectifs des troisièmes nœuds ayant une connexion réelle avec ledit deuxième nœud.
9. Procédé selon l'une des revendications 7 et 8, dans lesquels les valeurs de poids de connexion et de facteur influence sont déterminées itérativement jusqu'à leurs convergence en des valeurs qui ne varient plus de manière significative.
10. Procédé pour établir des connexions dites quasi-réelles entre nœuds d'un réseau mis en œuvre par des unités de traitement informatiques communicantes, à chaque nœud étant associées une clé publique et une clé privée, un nœud donné étant susceptible de communiquer sa clé publique à un autre nœud, formant ainsi une connexion dite réelle (« IRL-connecté »] entre les deux nœuds, et chaque nœud étant également susceptible de communiquer à un autre nœud une clé publique reçue d'un autre nœud encore, formant ainsi une connexion dite indirecte entre l'autre nœud et l'autre nœud encore, chaque nœud étant susceptible d'avoir un poids de connexion spécifique vis-à-vis d'un autre nœud avec lequel il a une connexion réelle ou indirecte, le comprenant les étapes suivantes :
à partir d'un premier nœud et d'un deuxième nœud entre lesquels une connexion doit être établie, sélectionner une pluralité de nœuds intermédiaires entre le premier nœud et le deuxième nœud, parmi ceux présentant les plus grands poids de connexion vis-à-vis du premier nœud,
communiquer à partir du premier nœud vers les nœuds intermédiaires sélectionnés une donnée aléatoire (nonce] destinée à être communiquée au deuxième nœud,
via un ou plusieurs canaux de communication distincts du canal de communication entre nœuds, communiquer de façon redondante à partir des nœuds intermédiaires vers le deuxième nœud ledit code aléatoire ainsi que les clés publiques desdits nœuds intermédiaires,
au niveau du deuxième nœud, en réponse à la réception du code aléatoire en redondance, générer une signature du code aléatoire à l'aide de la clé privée du deuxième nœud et retourner vers les nœuds intermédiaire ladite signature ainsi que la clé publique du deuxième nœud, chiffrée à l'aide des clés publiques des nœuds intermédiaires, respectivement,
au niveau de chacun des nœuds intermédiaires, vérification de la signature du code aléatoire reçue du deuxième nœud et, en cas de succès, communication au premier nœud de la clé publique du deuxième nœud, chiffrée à l'aide de la clé publique du premier nœud, et
au niveau du premier nœud, déchiffrement et mémorisation de la clé publique du deuxième nœud, les premier et deuxième nœuds pouvant alors s'échanger des informations chiffrées avec une sécurité liée aux poids de connexion des nœuds intermédiaires.
11. Procédé selon la revendication 10, dans lequel la sélection des nœuds intermédiaire s'effectue également parmi ceux présentant les plus grands poids de connexion vis-à-vis du deuxième nœud.
12. Procédé selon l'une des revendications 10 et 11, dans lequel le code aléatoire est généré conjointement par un ensemble de nœuds formés par le premier nœud et par les nœuds intermédiaires, par la mise en œuvre des étapes suivantes :
génération d'un code aléatoire au niveau de chaque nœud de l'ensemble,
échange entre les nœuds de l'ensemble, avec chiffrement à l'aide des clés respectives des nœuds, de hachés desdits codes aléatoires,
échange entre lesdits nœuds de l'ensemble, avec chiffrement à l'aide des clés respectives des nœuds, des codes aléatoires tels quels,
vérification au niveau de chaque nœud de l'ensemble que le code aléatoires tels quels correspondent bien à leurs hachés respectifs reçus à l'étape précédente, et
génération d'un code aléatoire final destiné à être communiqué au deuxième nœud par combinaison prédéterminée des codes aléatoires générés au niveau de chaque nœud de l'ensemble.
13. Procédé selon l'une des revendications 10 à 12, dans lequel ledit canal de communication distinct est basé sur un réseau social, et comprenant une étape de publication par le deuxième nœud sur ledit réseau social d'une signature dudit code aléatoire et sa clé publique.
14. Procédé selon l'une des revendications 10 à 13, lequel comprend en outre, en réponse au succès de l'étape de vérification de la signature du code aléatoire reçue du deuxième nœud, une étape d'attribution d'un poids de connexion du deuxième nœud vis-à-vis du premier nœud.
15. Procédé selon l'une des revendications 1 à 6, dans un réseau comprenant des nœuds à connexions quasi-réelles établies selon le procédé selon l'une des revendications 10 à 14, dans lequel les connexions quasi-réelles sont considérés comme des connexions réelles au sens du procédé, avec un poids tenant compte du caractère quasi-réel de la connexion.
16. Procédé pour sécuriser le fonctionnement d'un réseau de nœuds aptes à exécuter des programmes (WP] en réponse à la réception de messages [WM), les nœuds étant susceptibles d'être liés entre eux selon des poids de connexion différents déterminés par le procédé selon l'une des revendications 1 à 9 ou par le procédé de la revendication 14, le procédé comprenant, lors de la réception d'un message (WM] au niveau d'un nœud récepteur, la comparaison du poids de connexion du nœud ayant émis ce message avec les poids de connexion d'autres nœuds avec lesquels le nœud récepteur possède des connexions réelles, et l'acceptation dudit message seulement si le poids de connexion du nœud émetteur est égal ou supérieur au plus petit desdits poids de connexion.
17. Procédé pour sécuriser le fonctionnement d'un réseau de nœuds aptes à exécuter des programmes (WP] en réponse à la réception de messages (WM], les nœuds étant susceptibles d'être liés entre eux selon des poids de connexion différents obtenus notamment par le procédé de l'une des revendications 1 à 9 ou par le procédé de la revendication 14, comprenant les étapes suivantes :
sur la base des valeurs de poids de connexion, affecter à chaque nœud au moins un nœud contresignataire ayant vis-à-vis de lui un poids de connexion supérieur à un seuil, au niveau de chaque nœud, maintenir une liste de nœuds contresignataires de nœuds susceptibles de recevoir des messages (WM] à partir du nœud en question, chaque nœud et ses nœuds contresignataires formant un ensemble de nœuds miroirs,
lorsqu'un message doit être envoyé par un nœud émetteur à un nœud destinataire, provoquer l'envoi de ce message par au moins certains des nœuds miroirs du nœud émetteur vers au moins certains des nœuds miroirs du nœud destinataire,
valider le message seulement si une fraction donnée des messages émis a été reçue.
18. Procédé selon la revendication 17, dans lequel les messages sont émis vers tous les nœuds miroirs du nœud destinataire.
19. Procédé selon la revendication 17 ou 18, dans lequel les messages sont émis par le nœud émetteur ainsi que par les seuls nœuds contresignataires du nœud émetteur qui sont également contresignataires du nœud destinataire.
20. Procédé selon l'une des revendications 17 à 19, dans lequel un message envoyé d'un premier nœud à un second nœud n'est validé par le second nœud que si
les ensembles respectifs de nœuds miroirs des premiers et deuxième nœuds ont une intersection dont le nombre d'éléments est supérieur à un certain seuil et si
le second nœud a reçu ce même message (en redondance] de la part d'au moins une fraction donnée desdits nœuds miroirs appartenant à cette intersection.
21. Procédé selon l'une des revendications 1 à 6 dans un réseau comprenant des nœuds miroirs selon l'une des revendications 17 à 20, dans lequel un nœud est considéré comme contresignataire d'un nœud donné seulement si le poids de connexion du nœud en question est au moins égal au plus petit des poids de connexion des nœuds ayant des connexions réelles avec le nœud donné.
22. Système pour sécuriser le fonctionnement d'un réseau de nœuds aptes à exécuter des programmes (WP] en réponse à la réception de messages (WM], les nœuds étant susceptibles d'être liés entre eux selon des poids de connexion différents, apte à :
sur la base des valeurs de poids de connexion, affecter à chaque nœud au moins un nœud contresignataire ayant vis-à-vis de lui un poids de connexion supérieur à un seuil,
au niveau de chaque nœud, maintenir une liste de nœuds contresignataires de nœuds susceptibles de recevoir des messages à partir du nœud en question, chaque nœud et ses nœuds contresignataires formant un ensemble de nœuds miroirs,
lorsqu'un message doit être envoyé par un nœud émetteur à un nœud destinataire, provoquer l'envoi de ce message par au moins certains des nœuds miroirs du nœud émetteur vers au moins certains des nœuds miroirs du nœud destinataire.
23. Système selon la revendication 22, dans lequel un nœud destinataire d'un message (WM] ne le valide que seulement si les ensembles respectifs de nœuds miroirs des nœuds émetteur et destinataire ont une intersection dont le nombre d'éléments est supérieur à un seuil donné et si le nœud destinataire a reçu ce même message (en redondance] de la part d'au moins une fraction donnée desdits nœuds miroirs appartenant à cette intersection.
24. Système pour sécuriser le fonctionnement d'un réseau de nœuds constitués par des systèmes sur puce aptes à exécuter des programmes (WP] en réponse à la réception de messages (WM], caractérisé en ce qu'il comprend en combinaison les deux architectures suivantes : - au niveau de chaque nœud, une architecture d'accès à des programmes chiffrés sur la base de hachés de ces programmes, contenus dans les messages entrants,
- au niveau de chaque nœud, une architecture de détermination de nœuds contresignataires, de duplication des messages de/vers les nœuds contresignataires, et de détermination du caractère identique des messages reçus.
25. Système pour l'exécution sécurisée de programmes dans une architecture comprenant un ensemble d'équipements reliés en réseau, caractérisé en ce qu'il comprend dans au moins un équipement, un système-sur-puce (SoC] sécurisé dans lequel est mémorisé de façon inaccessible autrement que par le SoC une clé privée de SoC, ou le SoC est apte à dynamiquement régénérer cette clé privée (technologie PUF],
un SoC pouvant communiquer avec un autre équipement uniquement par des messages et étant apte à exécuter des programmes seulement en réponse à la réception de messages,
un SoC étant apte à mémoriser au moins un programme à exécuter après chiffrement par le SoC et à générer un haché du ou de chaque programme permettant de retrouver le programme chiffré, l'équipement étant apte en outre à adresser au SoC un message contenant des données d'entrée (data] pour un certain programme à exécuter, ainsi que le haché dudit programme (#P2], le SoC étant apte, en réponse à un tel message, de façon sécurisée, (i] accéder au programme chiffré à exécuter à partir du haché (#P2] du programme reçu dans le message, (ii] déchiffrer à la volée les instructions du programme, et (iii] exécuter à la volée les instructions déchiffrées.
26. Système selon la revendication 25, dans lequel avant émission d'un message par le SoC, le SoC insère le haché (#P1] du programme en cours d'exécution dans le message à émettre, ainsi que la signature de ce haché au moyen de ladite clé privée secrète du SoC.
27. Système selon la revendication 25, dans lequel avant émission d'un message par le SoC, le SoC insère le haché (#P1] du programme en cours d'exécution dans le corps du message à émettre que le SoC signe au moyen de la clé privée secrète du SoC.
28. Système selon l'une des revendication 25 à 27, dans lequel le SoC comprend une unité de gestion cryptographique de mémoire (CMMU, Crypto Memory Management Unit] dans lequel est mémorisé - ou apte à dynamiquement régénérer (technologie PUF] - la clé secrète du SoC qui n'est accessible que par l'unité CMMU qui ne la dévoile jamais, et c'est par cette unité CMMU que sont effectués :
ledit chiffrement du programme avant mémorisation,
une allocation d'adresse mémoire (addrl..addr2 range] pour le programme ainsi chiffré, ladite génération du haché du programme et
ledit décryptage pour exécution à la volée par au moins une unité processeur comprise dans le
SoC.
29. Système selon la revendication 28, dans lequel l'unité CMMU effectue chiffrement et mise en mémoire bloc d'instructions par bloc d'instructions et fournit audit processeur un seul bloc d'instructions déchiffré à la fois, pour leur exécution à la volée.
30. Système selon la revendication 28 ou 29, dans lequel avant émission d'un message par le SoC, l'unité CMMU insère le haché (#P1] du programme en cours d'exécution dans le message à émettre, ainsi que la signature de ce haché par le CMMU au moyen de ladite clé privée secrète du SoC.
31. Système selon la revendication 28 ou 29, dans lequel avant émission d'un message par le SoC, l'unité CMMU insère le haché (#P1] du programme en cours d'exécution dans le corps du message à émettre qu'elle signe au moyen de la clé privée secrète du SoC.
32. Système selon l'une des revendications 25 à 31, dans lequel un SoC est apte à émettre un message ayant un même haché pour le programme en cours d'exécution (#P1] et pour le programme à exécuter par le destinataire (#P1 = #P2], ce programme (PI = P2] étant un engagement exécutable (smart contract] dans le cas où le destinataire dudit message est un SoC.
33. Système-sur-puce SoC destiné à former un nœud Wallet Node (WN] d'un réseau, comprenant une unité de gestion cryptographique de mémoire avec chiffrement (CMMU] apte à assurer une exécution en aveugle (blind] de programmes par au moins un processeur du SoC, dans lequel :
• dans l'unité CMMU est mémorisée (ou dynamiquement régénérée] de façon inaccessible autrement que par l'unité CMMU une clé privée (clé secrète],
· l'unité CMMU est apte à mémoriser au moins un programme à exécuter après chiffrement par l'unité CMMU et à générer un haché du ou de chaque programme permettant de retrouver le programme chiffré,
• ledit processeur n'est apte à exécuter des programmes que sur commande de l'unité CMMU,
• les interactions entre le système-sur-puce et d'autres nœuds du réseau s'effectuent exclusivement par messages et les messages sont reçus/émis par l'unité CMMU exclusivement,
• les messages comprennent l'identification d'un certain programme à exécuter, identifié par son haché,
• en réponse à la réception d'un message, l'unité CMMU (i] accède au programme chiffré à exécuter à partir du haché du programme reçu dans le message (notamment via une table PHT], (ii] déchiffre les instructions du programme, et (iii] transmet au processeur pour exécuter les instructions déchiffrées sur lesdites données reçues.
34. Système selon la revendication 33, dans lequel le ou au moins un processeur est apte à accéder à, et à manipuler (création, mise-à-jour, suppression], via l'unité CMMU, des variables persistantes d'état (PSV] associées à un programme donné, lesquelles sont également chiffrées et stockées en mémoire par l'unité CMMU et déchiffrées à la volée.
35. Système selon la revendication 33 ou 34, dans lequel ledit programme à exécuter et ses variables persistantes d'état (PSV] sont mémorisés dans un espace d'adressage spécifique assurant leur isolement par rapport aux autres programmes.
36. Système selon l'une des revendications 33 à 35, dans lequel un message est susceptible de contenir une ou plusieurs transactions de transfert d'unités de compte (UA] d'un nœud émetteur vers un nœud récepteur, les unités de compte reçues par un nœud récepteur étant susceptibles d'être à nouveau transférées par une transaction contenue dans un message émis par ledit nœud récepteur.
37. Système selon l'une des revendications 33 à 36, lequel comprend un espace de mémoire pour des unités de compte (tags] reçues par des transactions.
38. Système selon la revendication 37, lequel est apte à combiner des unités de compte de différents tags dans une même transaction à émettre, aptes à être combinées et transférées entre SoCs.
39. Système selon l'une des revendications 37 à 38, dans lequel l'unité CMMU comprend des moyens neutralisation d'un tag qui alimente une transaction émise, de telle sorte que les UA ainsi consommées ne puissent être consommées par une autre transaction.
40. Système selon la revendication 37 à 39, dans lequel l'unité CMMU comprend des moyens de contrôle de l'utilisation des tags par les différents programmes, de telle sorte que seul un programme habilité puisse alimenter une transaction à générer à partir d'un tag donné.
41. Système selon l'une des revendications 33 à 40, dans lequel ladite mémoire est dans le SoC.
42. Système selon l'une des revendications 33 à 40, dans lequel ladite mémoire est séparée du SoC.
43. Système selon l'une des revendications 33 à 42, dans lequel un programme peut alternativement être déclenché sur écoulement d'un timeout pour un programme donné et l'unité CMMU est également apte, sur survenance d'un timeout associé au haché d'un programme (i] à accéder en mémoire au programme chiffré à partir de ce haché, (ii] déchiffrer les instructions du programme, et (iii] transmettre au processeur pour exécution les instructions déchiffrées.
44. Système selon l'une des revendications 33 à 43, dans lequel l'unité CMMU effectue lesdits chiffrement et mise en mémoire bloc d'instructions par bloc d'instructions et fournit audit processeur un seul bloc déchiffré à la fois, pour exécution à la volée.
45. Système selon l'une des revendications 33 à 44, dans lequel, avant émission d'un message, l'unité CMMU insère le haché (#P1] du programme en cours d'exécution dans le message à émettre, ainsi que la signature de ce haché par le CMMU au moyen de ladite clé privée secrète.
46. Système selon l'une des revendications 33 à 44, dans lequel, avant émission d'un message, l'unité CMMU insère le haché (#P1] du programme en cours d'exécution dans le corps du message à émettre qu'elle signe au moyen de ladite clé privée secrète.
47. Système selon l'une des revendications 33 à 46, dans lequel, l'unité CMMU est apte à émettre un message ayant un même haché pour le programme en cours d'exécution (#P1] et pour le programme (#P2] à exécuter par le destinataire (#P1 = #P2], ce programme (PI = P2] étant ainsi un engagement exécutable (smart contract] dans le cas où le destinataire dudit message est aussi un SoC selon la revendication 26.
48. Procédé selon l'une des revendications 17 à 20, dans lequel certains messages (WM) constituent des messages de transfert de tags mémorisés dans des systèmes selon la revendication 37, dans lequel la validation d'un message de transfert de tag au niveau d'un nœud destinataire est réalisée seulement s'il existe en intersection entre l'ensemble des nœuds miroirs du nœud destinataire et l'ensemble des nœuds miroirs de chacun des nœuds amonts à partir desquels un tel tag a été initialement transféré un nombre de nœuds supérieur à un seuil donné.
49. Procédé pour garantir les engagements d'un système-sur-puce (WN] dans une architecture de systèmes-sur-puce (WN] aptes à transférer entre eux des unités de compte via des messages (WM], pour le cas un tel système-sur-puce deviendrait non-responsif, comprenant les étapes suivantes :
(a] lors d'un engagement (quelconque] d'un WN fournisseur de cet engagement (El] à un WN bénéficiaire de cet engagement (E4], mettre à disposition du WN bénéficiaire (E4] une liste « PT-List » (Potentiel Transférées List] de WN repreneurs potentiels (E51, E52, E53] en cas de non- responsiveness dudit WN fournisseur (El] ;
(b] synchroniser à partir dudit WN fournisseur (El] l'état (PST] de l'engagement en question vers tous les WN repreneurs potentiels (E51, E52, E53].
(c] suite à l'envoi d'un message (WM] par ledit WN bénéficiaire (E4] audit WN fournisseur (El], constater au niveau dudit WN bénéficiaire (E4] la non-responsivité dudit WN fournisseur (El],
(d] déterminer au niveau dudit WN bénéficiaire (E ] un WN repreneur qui a priorité (E51] parmi les WN repreneurs potentiels de ladite liste (PT-List],
(e] traiter ledit message (WM] au niveau dudit WN repreneur prioritaire (E51], ce dernier synchronisant ensuite l'état (PST] de l'engagement en question vers les autres WN repreneurs potentiels (E52, E53] ainsi que vers ledit WN fournisseur qui était non-responsif (El],
(f] pour un message (WM] ultérieur émis par un WN bénéficiaire d'un engagement dudit WN fournisseur qui était non-responsif (El], si ce dernier est toujours non-responsif, exécuter le même procédé à partir de l'étape (c].
50. Système transactionnel à architecture répartie en peer-to-peer, mettant en œuvre 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, chaque transaction pouvant être validée par insertion, dans une chaîne de blocs mémorisée de façon répartie entre les nœuds, d'une signature de la transaction, , caractérisé en ce qu'au moins certaines des transactions sont réalisées par des nœuds aptes à assurer une condition de blindness desdites transactions, en ce qu'il comprend des moyens pour traiter un ensemble de transactions satisfaisant à la condition de blindness de manière à simplifier cet ensemble en fonction des quantités d'unités de compte et des adresses des nœuds émetteurs et des nœuds récepteurs impliqués dans ces transaction, pour générer un ensemble de transactions réduit, et pour ne générer et mémoriser dans la chaîne de blocs que les signatures de transactions de l'ensemble de transactions réduit.
51. Système transactionnel à architecture répartie en peer-to-peer, mettant en œuvre 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, chaque transaction pouvant être validée par insertion, dans une chaîne de blocs mémorisée de façon répartie entre les nœuds, d'une signature de la transaction,, caractérisé en ce qu'au moins certaines des transactions sont réalisées par des nœuds aptes à assurer une condition de blindness desdites transactions, en ce qu'il comprend des moyens pour traiter un ensemble de transactions satisfaisant à la condition de blindness de manière à simplifier cet ensemble en fonction des quantités d'unités de compte et des adresses des nœuds émetteurs et des nœuds récepteurs impliqués dans ces transaction, pour générer un ensemble de transactions réduit, et pour ne générer et mémoriser dans la chaîne de blocs que certaines des signatures dudit ensemble réduit et que sur instruction des nœuds concernés.
52. Procédé pour réaliser une transaction entre nœuds d'un réseau associés à des utilisateurs et susceptibles de transférer entre eux des unités de comptes et capables de communiquer entre eux par messages, chaque message désignant un programme WP à exécuter dans le nœud récepteur de ce message, et les utilisateurs étant capables de diffuser des éléments d'offres comprenant un ou plusieurs critères d'offres et susceptibles de donner lieu à des transactions sur le réseau, le procédé comprenant les étapes suivantes :
- envoi par un nœud offreur à un nœud demandeur d'un utilisateur ayant émis des éléments d'offre correspondants, d'un message d'offre de fourniture répondant au(x] critère(s] et engageant ledit nœud, et identifiant un programme WP donné,
- envoi par le nœud demandeur au nœud offreur d'un message d'acceptation de l'offre de fourniture, identifiant le même programme WP donné,
- génération d'une attestation de réalisation, d'existence ou mise à disposition de la fourniture accessible par le nœud offreur, susceptible d'être vérifiée par ledit programme WP donné,
- vérification de l'attestation par le programme WP donné au niveau de l'un des deux nœuds au moins, et
- si la vérification réussit, génération au niveau du nœud demandeur d'un message de transfert d'unités de compte constituant la contrepartie de la fourniture et envoi de ce message au nœud offreur.
53. Procédé selon l'une des revendications 7 à 9, dans un réseau comprenant des nœuds à connexions quasi-réelles établies selon le procédé selon l'une des revendications 10 à 14, dans lequel les connexions quasi-réelles sont considérés comme des connexions réelles au sens du procédé, avec un poids tenant compte du caractère quasi-réel de la connexion.
PCT/IB2017/050228 2015-01-30 2017-01-16 Procédés et systèmes mis en œuvre dans une architecture en réseau de nœuds susceptibles de réaliser des transactions basées sur messages WO2017122187A2 (fr)

Priority Applications (10)

Application Number Priority Date Filing Date Title
EP17705166.1A EP3403213A2 (fr) 2016-01-15 2017-01-16 Procédés et systèmes mis en oeuvre dans une architecture en réseau de noeuds susceptibles de réaliser des transactions basées sur messages
US16/068,497 US11159318B2 (en) 2015-01-30 2017-01-16 Methods and systems implemented in a network architecture with nodes capable of performing message-based transactions
CN201780006951.1A CN109643350A (zh) 2016-01-15 2017-01-16 在有节点能够执行基于消息的交易的网络架构中实施的方法和系统
EP18705491.1A EP3568794B1 (fr) 2017-01-16 2018-01-16 Procédés et systèmes pour l'exécution de contrats intelligents dans des environnements sécurisés
US16/477,631 US11587070B2 (en) 2017-01-16 2018-01-16 Methods and systems for executing smart contracts in secure environments
CN201880016861.5A CN110392888A (zh) 2017-01-16 2018-01-16 用于在安全环境中执行智能合约的方法和系统
PCT/IB2018/050247 WO2018131004A2 (fr) 2017-01-16 2018-01-16 Procédés et systèmes pour l'exécution de programmes dans des environnements sécurisés
US17/509,607 US20240064014A9 (en) 2016-01-15 2021-10-25 Methods and systems implemented in a network architecture with nodes capable of performing message-based transactions
US18/170,986 US12026700B2 (en) 2023-02-17 Methods and systems for executing smart contracts in secure environments
US18/463,863 US20240048376A1 (en) 2016-01-15 2023-09-08 Methods and systems implemented in a network architecture with nodes capable of performing message-based transactions

Applications Claiming Priority (13)

Application Number Priority Date Filing Date Title
FR1650352 2016-01-15
FR1650352 2016-01-15
FR16/50352 2016-01-15
US201615123663A 2016-01-28 2016-01-28
IBPCT/IB2016/050440 2016-01-28
PCT/IB2016/050440 WO2016120826A2 (fr) 2015-01-30 2016-01-28 Systèmes et procédés pour la gestion d'engagements en réseau d'entités sécurisées
US15/123,663 2016-09-05
US201662399358P 2016-09-24 2016-09-24
US62/399,358 2016-09-24
US201662400174P 2016-09-27 2016-09-27
US62/400,174 2016-09-27
EPPCT/EP2017/050041 2017-01-02
EPPCT/EP2017/050041 2017-01-02

Related Parent Applications (6)

Application Number Title Priority Date Filing Date
US201615123663A Continuation 2015-01-30 2016-01-28
US201615123663A Continuation-In-Part 2015-01-30 2016-01-28
PCT/IB2016/050440 Continuation WO2016120826A2 (fr) 2015-01-30 2016-01-28 Systèmes et procédés pour la gestion d'engagements en réseau d'entités sécurisées
PCT/IB2016/050440 Continuation-In-Part WO2016120826A2 (fr) 2015-01-30 2016-01-28 Systèmes et procédés pour la gestion d'engagements en réseau d'entités sécurisées
EPPCT/EP2017/050041 Continuation-In-Part 2015-01-30 2017-01-02
PCT/IB2017/050041 Continuation WO2017118934A1 (fr) 2016-01-07 2017-01-05 Réduction de signalisation pour utilisateurs désynchronisés

Related Child Applications (4)

Application Number Title Priority Date Filing Date
US16/068,497 A-371-Of-International US11159318B2 (en) 2015-01-30 2017-01-16 Methods and systems implemented in a network architecture with nodes capable of performing message-based transactions
PCT/IB2018/050247 Continuation WO2018131004A2 (fr) 2017-01-16 2018-01-16 Procédés et systèmes pour l'exécution de programmes dans des environnements sécurisés
US16/477,631 Continuation US11587070B2 (en) 2017-01-16 2018-01-16 Methods and systems for executing smart contracts in secure environments
US17/509,607 Continuation US20240064014A9 (en) 2016-01-15 2021-10-25 Methods and systems implemented in a network architecture with nodes capable of performing message-based transactions

Publications (2)

Publication Number Publication Date
WO2017122187A2 true WO2017122187A2 (fr) 2017-07-20
WO2017122187A3 WO2017122187A3 (fr) 2017-09-08

Family

ID=65000835

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2017/050228 WO2017122187A2 (fr) 2015-01-30 2017-01-16 Procédés et systèmes mis en œuvre dans une architecture en réseau de nœuds susceptibles de réaliser des transactions basées sur messages

Country Status (3)

Country Link
US (3) US11159318B2 (fr)
EP (1) EP3403213A2 (fr)
WO (1) WO2017122187A2 (fr)

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018104890A2 (fr) 2016-12-06 2018-06-14 Enrico Maim Procédés et entités notamment transactionnels mettant en jeu des dispositifs sécurisés
CN108737536A (zh) * 2018-05-14 2018-11-02 百度在线网络技术（北京）有限公司 一种区块链系统的实现方法、装置、设备和存储介质
CN109104286A (zh) * 2018-07-26 2018-12-28 杭州安恒信息技术股份有限公司 一种基于门限数字签名的共识的新区块生成方法
WO2019032659A1 (fr) 2017-08-09 2019-02-14 Gridplus Inc. Système de stockage sécurisé de clés cryptographiques
WO2019097450A1 (fr) 2017-11-15 2019-05-23 Enrico Maim Terminaux et procédés pour transactions sécurisées
WO2019138391A1 (fr) * 2018-01-15 2019-07-18 Enrico Maim Systèmes et procédés transactionnels à base de tokens
WO2019179829A1 (fr) * 2018-03-22 2019-09-26 NEC Laboratories Europe GmbH Système et procédé de vérification de transaction sécurisée dans un système de registre distribué
WO2019234686A1 (fr) 2018-06-06 2019-12-12 Enrico Maim Système transactionnel sécurisé dans une architecture p2p
CN111768304A (zh) * 2018-08-06 2020-10-13 阿里巴巴集团控股有限公司 区块链交易方法及装置、电子设备
CN112438035A (zh) * 2018-07-19 2021-03-02 区块链控股有限公司 用于控制分布式系统的处理步骤的计算机实现的系统和方法
US10958438B2 (en) 2018-10-31 2021-03-23 Advanced New Technologies Co., Ltd. Method, apparatus, and electronic device for blockchain-based recordkeeping
CN113438068A (zh) * 2019-05-31 2021-09-24 创新先进技术有限公司 基于区块高度实现动态加密的方法及装置
US11240032B2 (en) 2017-06-28 2022-02-01 Nchain Holdings Ltd System and method for hierarchical token distribution on blockchain network
US11494344B2 (en) 2018-03-06 2022-11-08 International Business Machines Corporation Customized endorsement logic for blockchain
US11777738B2 (en) 2019-06-04 2023-10-03 International Business Machines Corporation Metadata-based endorsement
US11799637B2 (en) 2017-07-24 2023-10-24 Nchain Licensing Ag Methods and systems for blockchain-implemented event-lock encryption
US11941624B2 (en) 2017-08-29 2024-03-26 Nchain Licensing Ag Concurrent state machine processing using a blockchain
US11991294B2 (en) 2021-11-12 2024-05-21 Gridplus, Inc. Peer-to-peer secure conditional transfer of cryptographic data
US12026710B2 (en) 2017-08-29 2024-07-02 Nchain Licensing Ag Constraints on outputs of an unlocking transaction in a blockchain

Families Citing this family (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11038718B2 (en) 2016-01-27 2021-06-15 Securrency, Inc. Method, apparatus, and computer-readable medium for transaction management spanning multiple heterogeneous computing networks
US11170346B2 (en) * 2016-09-19 2021-11-09 Sap Se Decentralized credentials verification network
US10621157B2 (en) 2016-10-10 2020-04-14 AlphaPoint Immediate order book failover
KR102574255B1 (ko) * 2017-01-31 2023-09-04 엔체인 홀딩스 리미티드 블록체인 상에 저장된 사용자 관련 데이터를 생성하고 추출하기 위한 컴퓨터 구현 시스템 및 방법
US10541886B2 (en) * 2017-05-24 2020-01-21 International Business Machines Corporation Decentralized change management based on peer devices using a blockchain
JP2019012415A (ja) * 2017-06-30 2019-01-24 株式会社ｂｉｔＦｌｙｅｒ ネットワークにおける合意形成方法及び当該ネットワークを構成するノード
US10567168B2 (en) * 2017-11-16 2020-02-18 International Business Machines Corporation Blockchain transaction privacy enhancement through broadcast encryption
JP7287279B2 (ja) * 2017-12-04 2023-06-06 ソニーグループ株式会社 情報処理装置、情報処理方法およびプログラム
US10320843B1 (en) * 2017-12-08 2019-06-11 Symbiont.Io, Inc. Methods, systems, and devices for encrypted electronic storage and confidential network transfer of private data through a trustless distributed ledger technology system
US10476847B1 (en) 2017-12-08 2019-11-12 Symbiont.Io, Inc. Systems, methods, and devices for implementing a smart contract on a distributed ledger technology platform
EP3531362A1 (fr) * 2018-02-22 2019-08-28 Banco Bilbao Vizcaya Argentaria, S.A. Procédé de validation d'un bon d'échange
US20190287107A1 (en) * 2018-03-15 2019-09-19 International Business Machines Corporation Resource equity for blockchain
CN108520462B (zh) 2018-03-30 2020-07-24 阿里巴巴集团控股有限公司 基于区块链的业务执行方法及装置、电子设备
US11188920B2 (en) * 2018-05-23 2021-11-30 International Business Machines Corporation Autocommit transaction management in a blockchain network
CN108876401B (zh) 2018-05-29 2022-03-01 创新先进技术有限公司 基于区块链的商品理赔方法及装置、电子设备
US20190370791A1 (en) * 2018-05-30 2019-12-05 International Business Machines Corporation Distributing cryptographic asset returns
US11556874B2 (en) * 2018-06-11 2023-01-17 International Business Machines Corporation Block creation based on transaction cost and size
US11410174B2 (en) * 2018-08-07 2022-08-09 International Business Machines Corporation Custom blockchain for IoT devices
CN112232817A (zh) * 2018-10-25 2021-01-15 创新先进技术有限公司 基于区块链的交易处理方法及装置、电子设备
BR112019008000B1 (pt) 2018-11-16 2022-03-15 Advanced New Technologies Co., Ltd Método implementado por computador para a autenticação de um nome de domínio, método implementado por computador, meio não transitório legível por computador e sistema para a implementação de um método
WO2019072273A2 (fr) * 2018-11-16 2019-04-18 Alibaba Group Holding Limited Interactions entre chaînes utilisant un système de noms de domaine dans des systèmes de chaînes de blocs
EP3559874B1 (fr) * 2018-12-13 2022-02-02 Advanced New Technologies Co., Ltd. Traitement de flux de travaux par chaîne de blocs guidé par les événements
US11329968B2 (en) * 2019-03-18 2022-05-10 Microsoft Technology Licensing, Llc Authentication across decentralized and centralized identities
US10911523B2 (en) 2019-03-18 2021-02-02 Microsoft Technology Licensing, Llc Broadcast intent signaling using a decentralized network
EP3953834A4 (fr) 2019-04-12 2023-01-04 Symbiont.io, Inc. Systèmes, dispositifs et procédés associés à des plateformes de gestion de données basées sur une dlt et à des produits de données
WO2020214175A1 (fr) * 2019-04-18 2020-10-22 Visa International Service Association Procédé, système et produit programme informatique pour commander un processus dans un réseau de serveurs
JP2022535497A (ja) * 2019-04-29 2022-08-09 セキュレンシー、インコーポレイテッド 複数の異質なコンピューティング・ネットワークにまたがる取引管理のための方法、装置、及びコンピュータ可読媒体
WO2020263915A1 (fr) * 2019-06-26 2020-12-30 Eland Blockchain Fintech Inc. Système et procédé de traitement de transactions de paiement par l'intermédiaire d'un réseau de chaînes de blocs
CN111316303B (zh) 2019-07-02 2023-11-10 创新先进技术有限公司 用于基于区块链的交叉实体认证的系统和方法
EP3688930B1 (fr) 2019-07-02 2021-10-20 Advanced New Technologies Co., Ltd. Système et procédé d'émission de revendications vérifiables
EP3688633A4 (fr) 2019-07-02 2020-10-07 Alibaba Group Holding Limited Système et méthode de vérification de demandes vérifiables
CN111066020B (zh) 2019-07-02 2023-08-04 创新先进技术有限公司 用于创建去中心化标识的系统和方法
CN116910726A (zh) 2019-07-02 2023-10-20 创新先进技术有限公司 用于将去中心化标识映射到真实实体的系统和方法
CN111213147B (zh) 2019-07-02 2023-10-13 创新先进技术有限公司 用于基于区块链的交叉实体认证的系统和方法
WO2021006616A1 (fr) * 2019-07-11 2021-01-14 Coinplug, Inc. Procédé pour fournir un service d'identifiant décentralisé relationnel et nœud de chaîne de blocs l'utilisant
KR20210016764A (ko) * 2019-08-05 2021-02-17 삼성전자주식회사 시스템 온 칩
CN111490994B (zh) * 2020-04-16 2022-05-27 杭州萌格信息科技有限公司 区块链节点群间dpos与节点群内pow结合的共识机制方法
CN111523900A (zh) 2020-07-03 2020-08-11 支付宝(杭州)信息技术有限公司 基于拜占庭容错算法的区块链的共识方法、装置及系统
CN111930847B (zh) * 2020-09-16 2021-01-08 深圳壹账通智能科技有限公司 基于区块链的数据处理方法、装置及存储介质
CN112634054A (zh) * 2021-01-11 2021-04-09 杭州复杂美科技有限公司 交易执行方法、区块链一体机和区块链网络
US20230206231A1 (en) * 2021-12-27 2023-06-29 Paypal, Inc. Laundering detection in second layer networks
US20230275913A1 (en) * 2022-02-25 2023-08-31 Microsoft Technology Licensing, Llc Using graph enrichment to detect a potentially malicious access attempt

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3018377A1 (fr) 2014-03-07 2015-09-11 Enrico Maim Systeme et procede transactionnels a architecture repartie fondes sur des transactions de transfert d'unites de compte entre adresses
WO2016120826A2 (fr) 2015-01-30 2016-08-04 Enrico Maim Systèmes et procédés pour la gestion d'engagements en réseau d'entités sécurisées

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8910247B2 (en) * 2010-10-06 2014-12-09 Microsoft Corporation Cross-site scripting prevention in dynamic content
WO2012122994A1 (fr) 2011-03-11 2012-09-20 Kreft Heinz Transfert hors ligne de jetons électroniques entre dispositifs homologues
US9231975B2 (en) * 2013-06-27 2016-01-05 Sap Se Safe script templating to provide reliable protection against attacks

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3018377A1 (fr) 2014-03-07 2015-09-11 Enrico Maim Systeme et procede transactionnels a architecture repartie fondes sur des transactions de transfert d'unites de compte entre adresses
WO2016120826A2 (fr) 2015-01-30 2016-08-04 Enrico Maim Systèmes et procédés pour la gestion d'engagements en réseau d'entités sécurisées

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
P. S. RAVIKANTH: "PhD Thesis", 2001, MIT, article "Physical one-way functions"
PAPPU: "Physical one-way functions", SCIENCE, vol. 297, no. 5589, 2002, pages 2026 - 2030, XP002285061, DOI: doi:10.1126/science.1074376

Cited By (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3971750A1 (fr) 2016-12-06 2022-03-23 Enrico Maim Procédés et entités notamment transactionnels mettant en jeu des dispositifs sécurisés
WO2018104890A2 (fr) 2016-12-06 2018-06-14 Enrico Maim Procédés et entités notamment transactionnels mettant en jeu des dispositifs sécurisés
US11838420B2 (en) 2017-06-28 2023-12-05 Nchain Licensing Ag System and method for hierarchical token distribution on blockchain network
US11240032B2 (en) 2017-06-28 2022-02-01 Nchain Holdings Ltd System and method for hierarchical token distribution on blockchain network
US11799637B2 (en) 2017-07-24 2023-10-24 Nchain Licensing Ag Methods and systems for blockchain-implemented event-lock encryption
WO2019032659A1 (fr) 2017-08-09 2019-02-14 Gridplus Inc. Système de stockage sécurisé de clés cryptographiques
US11233644B2 (en) 2017-08-09 2022-01-25 Gridplus Inc. System for secure storage of cryptographic keys
EP3665863A4 (fr) * 2017-08-09 2021-04-07 Gridplus Inc. Système de stockage sécurisé de clés cryptographiques
US12026710B2 (en) 2017-08-29 2024-07-02 Nchain Licensing Ag Constraints on outputs of an unlocking transaction in a blockchain
US11941624B2 (en) 2017-08-29 2024-03-26 Nchain Licensing Ag Concurrent state machine processing using a blockchain
WO2019097450A1 (fr) 2017-11-15 2019-05-23 Enrico Maim Terminaux et procédés pour transactions sécurisées
CN111699502A (zh) * 2018-01-15 2020-09-22 E·马伊姆 基于代币的交易系统和方法
WO2019138391A1 (fr) * 2018-01-15 2019-07-18 Enrico Maim Systèmes et procédés transactionnels à base de tokens
US11494344B2 (en) 2018-03-06 2022-11-08 International Business Machines Corporation Customized endorsement logic for blockchain
WO2019179829A1 (fr) * 2018-03-22 2019-09-26 NEC Laboratories Europe GmbH Système et procédé de vérification de transaction sécurisée dans un système de registre distribué
CN108737536A (zh) * 2018-05-14 2018-11-02 百度在线网络技术（北京）有限公司 一种区块链系统的实现方法、装置、设备和存储介质
CN112236792A (zh) * 2018-06-06 2021-01-15 E·马伊姆 P2p架构中的安全交易系统
WO2019234686A1 (fr) 2018-06-06 2019-12-12 Enrico Maim Système transactionnel sécurisé dans une architecture p2p
CN112438035A (zh) * 2018-07-19 2021-03-02 区块链控股有限公司 用于控制分布式系统的处理步骤的计算机实现的系统和方法
CN109104286B (zh) * 2018-07-26 2021-08-17 杭州安恒信息技术股份有限公司 一种基于门限数字签名的共识的新区块生成方法
CN109104286A (zh) * 2018-07-26 2018-12-28 杭州安恒信息技术股份有限公司 一种基于门限数字签名的共识的新区块生成方法
CN111768304A (zh) * 2018-08-06 2020-10-13 阿里巴巴集团控股有限公司 区块链交易方法及装置、电子设备
US11258612B2 (en) 2018-10-31 2022-02-22 Advanced New Technologies Co., Ltd. Method, apparatus, and electronic device for blockchain-based recordkeeping
US10958438B2 (en) 2018-10-31 2021-03-23 Advanced New Technologies Co., Ltd. Method, apparatus, and electronic device for blockchain-based recordkeeping
CN113438068A (zh) * 2019-05-31 2021-09-24 创新先进技术有限公司 基于区块高度实现动态加密的方法及装置
CN113438068B (zh) * 2019-05-31 2024-01-09 创新先进技术有限公司 基于区块高度实现动态加密的方法及装置
US11777738B2 (en) 2019-06-04 2023-10-03 International Business Machines Corporation Metadata-based endorsement
US11991294B2 (en) 2021-11-12 2024-05-21 Gridplus, Inc. Peer-to-peer secure conditional transfer of cryptographic data

Also Published As

Publication number Publication date
US20190013943A1 (en) 2019-01-10
US11159318B2 (en) 2021-10-26
WO2017122187A3 (fr) 2017-09-08
US20220069994A1 (en) 2022-03-03
US20240048376A1 (en) 2024-02-08
EP3403213A2 (fr) 2018-11-21
US20240064014A9 (en) 2024-02-22

Similar Documents

Publication Publication Date Title
WO2017122187A2 (fr) Procédés et systèmes mis en œuvre dans une architecture en réseau de nœuds susceptibles de réaliser des transactions basées sur messages
EP3568794B1 (fr) Procédés et systèmes pour l&#39;exécution de contrats intelligents dans des environnements sécurisés
US11477032B2 (en) System and method for decentralized-identifier creation
CN110870254B (zh) 提供分布式私有子空间化数据结构的方法和系统
EP3499789B1 (fr) Dispositif de chaîne de blocs primaire et secondaire
EP3251046B1 (fr) Systèmes et procédés pour la gestion d&#39;engagements en réseau d&#39;entités sécurisées
AU2022226929B2 (en) Advanced non-fungible token blockchain architecture
US20200374113A1 (en) Decentralized application platform for private key management
WO2019179534A2 (fr) Système et procédé de création d&#39;identifiants décentralisés
EP3788522A1 (fr) Système et procédé de mise en correspondance d&#39;identifiants décentralisés avec des entités du monde réel
JP7075393B2 (ja) ブロックチェーンにより実現されるシステム及び方法
AU2017239154A1 (en) Business process execution on a blockchain platform
CN111108521A (zh) 实现基于区块链的工作流
FR3049089A1 (fr) Procede permettant de gerer les validations des messages relatifs a une chaine de messages de facon unitaire a travers un reseau de validation decentralise
CN115868141A (zh) 用于数字签名的单轮多方计算的技术
FR3035248A1 (fr) Systeme-sur-puce a fonctionnement securise et ses utilisations
WO2017162930A2 (fr) Dispositif d&#39;authentification biométrique adaptatif par échographie, photographies en lumière visible de contraste et infrarouge, sans divulgation, à travers un réseau informatique décentralisé
EP3803745B1 (fr) Système transactionnel sécurisé dans une architecture p2p
US20230419274A1 (en) Fully Collateralized Automated Market Maker
Khacef Trade-off betweew security and scalability in blockchain systems
FR3101991A1 (fr) Système et méthode d&#39;authentification et d&#39;assurance d’objets

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17705166

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2017705166

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2017705166

Country of ref document: EP

Effective date: 20180816