Determining a consensus for adding a block to a blockchain

Abstract

The invention relates to a method for determining a consensus within a set of nodes forming a peer-to-peer network for managing a blockchain, the method comprising implementing the following steps, on a node of the network: computing a score associated with each node, selecting the node with the highest score, receiving at least one block generated by a candidate node and, when the candidate node is the selected node, verifying the validity of the block, when the received block is valid, sending, to the other nodes of the network, a notification identifying the received block as the next block of the blockchain, receiving notifications transmitted by the other nodes of the network, each notification identifying a block selected by a respective node, and adding the block identified by a majority of the received notifications to the blockchain.

Description

DETERMINING CONSENSUS FOR ADDING A BLOCK TO A BLOCKCHAIN Technical field [1] The present disclosure relates to a method of determining a consensus for adding a block to a blockchain. Prior art [2] Distributed ledger technologies are an alternative to centralized structures that rely on a trusted entity. In a distributed structure, a set of computer systems are connected to each other within a peer-to-peer network, allowing the distribution of data processing tasks among the different nodes in the network. The trusted entity is replaced, in such a structure, by a consensus algorithm that ensures that the information stored and the data generated by each node are identical. All nodes in the network maintain an identical copy of a distributed ledger locally. [3] In the case of a blockchain, a new block, representing a set of verified and grouped data, is proposed by a node of the network, and this new block must be the subject of a consensus, defined by the consensus algorithm implemented by all the nodes, to be added to the blockchain stored by each node. [4] A classic consensus algorithm relies on providing a proof of work. Several nodes competing for the production of the next block seek to solve a complex problem requiring high processing time and computing resources. The first node to solve the problem produces the block and receives an associated reward. This type of consensus algorithm has been heavily criticized due to the energy consumption it requires, and the low latency it allows, i.e. the low rate of block production. [5] Also known from the publication of Xiaoyu Zhu et al. “An Improved Proof-of-Trust Consensus Algorithm for Credible Crowdsourcing Blockchain Services”, is a consensus algorithm, hereinafter referred to as IPoT, in which a candidate for producing a block has a reputation score calculated based on past interactions with other nodes. The producer node of the next block is randomly selected based on a probabilistic formula based on a timestamp and a signature of the current block header. [6] This consensus algorithm has reduced energy consumption compared to a proof-of-work consensus. In addition, the probabilistic selection of a block producer node makes the knowledge of the future block producer unpredictable, which increases the security of the algorithm. On the other hand, it also allows forks to occur in the blockchain, i.e. the appearance of two blocks generated following the same initial block. Indeed, several nodes can satisfy the selection formula, because the nodes are distributed and decide independently. In addition, nodes can be desynchronized and possibly use different block headers and therefore different selection parameters. The protocol provides for a verification phase that allows the validation of the generated block, however the article does not deal with the case where multiple blocks are generated during the same round. In such a case, it is necessary to provide an additional mechanism to remove duplicate generated blocks and thus resolve the forks thus produced to maintain a linear chain, such a mechanism directly affecting the performance of the algorithm. [7] Moreover, in a probabilistic consensus, the probability of forks occurring increases with the size of the network, which directly affects the scalability of the algorithm, and therefore its performance and the consistency of the resulting blockchain. Summary [8] This disclosure improves the situation. [9] In particular, one aim of the invention is to propose a secure, scalable and resource-efficient consensus algorithm.

[0010] One aim of the invention is in particular to propose a consensus algorithm which is less resource-intensive than a working protocol, but which does not produce forks in the resulting block chain.

[0011] A method is provided for determining a consensus within a set of nodes forming a peer-to-peer network for managing a blockchain, for adding a new block to the blockchain, the method being implemented by a node of the peer-to-peer network, the node being implemented by a computer system comprising at least one processor and a memory storing a list of active nodes, a current reputation value associated with each active node, and a respective copy of the blockchain, the method comprising: Calculating a score associated with each active node in the list, from the active node's current reputation value and a deposit amount committed by the active node, The selection of the producer node of the next block, this node having the highest score among the calculated scores, the reception of at least one block generated by a candidate node for adding a new block to the blockchain, and, when the candidate node is the node selected as producer of the next block, the verification of the validity of the block, when the received block is valid, the sending to the other active nodes of the network of a notification identifying the received block as the next block of the blockchain, Receiving a plurality of notifications issued respectively by the other active nodes of the network, each notification identifying a block selected by another active node of the network and, Adding to the blockchain the block identified by a majority of the notifications received.

[0012] In embodiments, the method includes, if the generated block is considered invalid by a majority of the active nodes of the network, removing the candidate node that generated the invalid block from the list of active nodes.

[0013] In embodiments, the method further includes redistributing the deposit amount to other active nodes of the network.

[0014] In embodiments Method according to one of the preceding claims, comprising removing an active node from the list of active nodes when the reputation of the node is below a determined threshold.

[0015] In embodiments, each active node defines a collateral amount that must be between determined minimum and maximum collateral amounts, and the method includes removing an active node from the list of active nodes when the collateral amount deposited by the node is less than the minimum collateral amount.

[0016] In embodiments, each active node defines a collateral amount that must be between determined minimum and maximum collateral amounts, and the score of an active node is calculated from: a ratio between the collateral amount defined by the node and the maximum collateral amount, and a ratio between the node's deposit amount and the collateral amount.

[0017] In embodiments, a node's score is a linear combination of the current reputation value, the ratio of the node's set collateral amount to the maximum collateral amount, and the ratio of the node's deposit amount to the collateral amount.

[0018] In embodiments, calculating a node's score further takes into account a block generation rate that decreases with the number of blocks added to the blockchain by the node during a determined period.

[0019] In embodiments, each node is further configured to implement at least one off-blockchain product or service purchase interaction application, to calculate a trust value associated with a purchase interaction that took place off-blockchain, each node further configured to calculate a node's current reputation value based on: a previous reputation value, and the trust value associated with the last purchase interaction that involved the node.

[0020] In embodiments, each node is configured to calculate the current reputation value of a participant by implementing a smart contract-like algorithm.

[0021] According to another object, a computer program product is described, comprising code instructions for implementing the method according to one of the preceding claims, when executed by a computer.

[0022] According to another object, there is described a computer terminal comprising at least one processor and one memory, and being connected to a set of other computer terminals to form a peer-to-peer network for managing a blockchain, the memory of the computer terminal storing a list of so-called active nodes, a current reputation value associated with each active node, and a respective copy of the blockchain, the computer terminal being configured to implement the method according to the preceding description.

[0023] According to another object, a distributed computer system is described comprising a set of computer terminals connected to each other so as to form a peer-to-peer network, each computer terminal comprising at least one processor and one memory and forming a node of said network, the system being characterized in that each terminal is configured to implement the method according to the preceding description.

[0024] The proposed consensus algorithm, based on proof of collateral and reputation with a scoring method for selecting the next block producer node, reduces the computational resources required by nodes for its implementation and thus the associated energy consumption. The scoring method ensures fairness among nodes and solves a monopolization problem that frequently occurs in proof-of-stake consensus algorithms.

[0025] The proposed method also allows for a deterministic selection of the next block producer node in a blockchain. One and only one node, the one with the highest score, is selected in each round. The verification and validation phase of this protocol is faster and more efficient than the prior art. Thus, the overall scalability and consistency of the algorithm are better.

[0026] The score is based on both a security deposit and a node's reputation, which minimizes the risk of malicious nodes since an invalid block or a bad reputation results in a node being kicked off the producer node list. Brief description of the drawings

[0027] Other features, details and advantages will become apparent upon reading the detailed description below, and upon analyzing the attached drawings, in which: Fig. 1

[0028] [Fig. 1] schematically represents a distributed computing system according to one embodiment. Fig. 2

[0029] [Fig. 2] schematically represents the structure of a node. Fig. 3

[0030] [Fig. 3] schematically represents a commercial transaction protocol that can be implemented between two nodes of the network. [Fig. 4]

[0031] [Fig. 4] schematically represents a consensus algorithm implemented by the nodes of the peer-to-peer network according to one embodiment. Fig. 5a

[0032] [Fig. 5a] represents an example of an ideal growth curve of a normal participant. [Fig. 5b]

[0033] [Fig. 5b] shows an example of a malicious participant's growth curve. [Fig. 6]

[0034] [Fig. 6] represents a comparative evolution of the latency of the implementation of different consensus algorithms as a function of the number of nodes. [Fig. 7]

[0035] [Fig. 7] represents a comparative evolution of the throughput of different consensus algorithms as a function of the number of nodes. Description of the embodiments

[0036] With reference to Figure 1, the architecture of a distributed computer system 1 according to one embodiment is shown. This computer system comprises a set of computer terminals 10 connected in a peer-to-peer network 11, each computer terminal 10 forming a node of the network. The peer-to-peer network allows a plurality of participants P to interact with the other participants, each participant having a respective computer terminal. Within the network, each node is connected to at least one other node of the network, for example by means of a remote connection. Each computer terminal can in this respect be configured to be able to connect to a wireless communication network, for example a Wi-Fi, 4G, 5G, etc. type network. Each computer terminal can be for example a computer or a connected telephone (smartphone).

[0037] In the following, the term "node" of the network corresponds to a computer equipment connected to at least one other computer terminal of the network and configured to implement the algorithms allowing the operation of the peer-to-peer network, and in particular the consensus algorithm described below. The term "participant" designates a human using the computer equipment forming a node.

[0038] As is known per se, the blockchain is a database that contains a history of all the exchanges made between the nodes 10 of the network since its creation, and which is structured in a succession of blocks, each block of which is linked to the previous one so as to form a chain. Each block typically includes a block identifier, an element making it possible to identify the previous block, and which may in particular be a hash of the identifier of the previous block, and a record of a set of transactions carried out within the network. The term "transaction" here designates information or an action undertaken by a node of the network and which is communicated, in encrypted form and signed by the sender, to the other nodes. It does not necessarily imply a reciprocal nature, that is to say a response or action reciprocally committed by another node of the network.

[0039] All the nodes 10 of the network jointly maintain a common BC blockchain by executing the consensus algorithm described below to update it. Thus, each node 10 of the network comprises at least one computer and a memory storing a respective copy of the blockchain. The computer(s) of a computer terminal may comprise one or more processors or microprocessors (CPUs), and / or one or more graphics processors (GPUs). The memory of the node comprises at least one non-volatile memory or read-only memory, for example of the ROM type, and one volatile memory or random access memory such as a RAM memory.

[0040] Some participants, and therefore some nodes 12 of the network, have an administrator role. The administrators manage in particular the arrival or departure of participants in the network. In particular, the administrator nodes can add or delete nodes 10 to the network. A participant can only join the network after verification of his identity by an administrator, for example by the verification of an identity document of the participant, including for example a capture of facial image(s) and the implementation of an authentication between the captured image(s) and one or more facial images stored in the identity document. In fact, it is not possible to create several nodes corresponding to the same participant.

[0041] As described in more detail below, the consensus algorithm that is implemented by the nodes 10 of the network 11 to add a new block to the blockchain BC takes into account the reputation of the participants operating the nodes in the real world, i.e. outside the blockchain. In this regard, each computer terminal 10 implementing a node is also configured to take part in commercial interactions in the real world, a commercial interaction comprising the provision of a product or service in the real world in return for a sum of money, this sum of money being paid into a cryptocurrency, i.e. in the currency exchanged within the blockchain.

[0042] As described in more detail below, the reputation of a participant corresponding to a node is updated based on the progress of commercial interactions implemented outside the blockchain. To carry out the method of verifying that a service or product has been correctly provided during a transaction outside the blockchain, each node is configured to implement a verification module 20, which may for example use decentralized Oracle Networks (DONs), which allow the creation of hybrid smart contracts, i.e. combining data external and internal to the blockchain to link the operation of the blockchain with events occurring outside it.

[0043] Referring to Figure 2, the structure of a node is schematically represented. Each node is configured to be able to implement the following functional modules: The verification module 20 described above. This module is configured to verify and evaluate that the provision of a product or service in the real world has actually taken place. This module is adapted to immediately verify the commercial interactions carried out and also to monitor the quality of these commercial interactions over time. The verification module retrieves information relating to a commercial interaction with a node 10 acting as buyer B of the transaction, and a node 10 acting as seller S of the transaction, and an independent controller; verifies the consistency of the information collected and produces a certificate that can be understood by all nodes on the basis of the verification carried out. Depending on the nature of the transaction, the independent controller may be a connected autonomous electronic device with a dedicated interface allowing the acquisition of relevant information D relating to a certain type of commercial interaction (for example a smart electricity meter with an interface for sending information relating to the quantity of energy received), or an ad hoc independent physical entity, such as a delivery person in a relay point with a mobile phone or a touchscreen tablet to scan a QRCode carried by the product subject of the transaction.The nature of the information collected depends on the nature of the transaction. It may include, for example, a Boolean indicator confirming whether the transaction took place or not, an indicator of the status of a delivered product, a delivery time, etc. A module 21 for implementing smart contracts, i.e., deterministic and immutable (i.e., non-modifiable) automatic programs that allow certain actions to be automatically implemented if the conditions necessary for their implementation are met. A smart contract can, for example, be implemented in the form of an executable script and a data model stored in the blockchain in the form of a Merkle hash tree. This module implements the entire exchange process and contains three main sub-modules: execution of commercial transactions 210, reputation 211, and guarantee 212. These processes are described in more detail below. A communication module 22 between nodes using P2P or peer-to-peer protocols. Each node must be connected to at least one other node in the network for the network to be functional. A core module 23 comprising all the components of a client of a blockchain, in particular an execution module 230 of the consensus algorithm described below, which makes it possible to verify the transactions of a block of a blockchain, generate and validate a block. The core module 23 also comprises a local storage module 231 of information relating to the blockchain, and a virtual machine 232.

[0044] The verification module 20 has a specific external interface for retrieving information relating D to off-blockchain business interactions as indicated above. The verification module 20 communicates with the module 21 for implementing smart contracts. In particular, the verification module 20 provides the module 21 with the certificates that result from the verification of off-blockchain transactions. The module 21 and the core module 23 interact to enable the implementation of the consensus algorithm from the reputation and guarantee values ​​and update these values ​​after the implementation of the consensus algorithm. Finally, the communication module 22 establishes communication with the other nodes of the network to enable the implementation of the consensus algorithm.

[0045] With reference to Figure 3, an example of a commercial interaction method implemented between two nodes 10 of the network comprising a buyer B and a seller S is shown, the method involving the supply of a product or service in the real world by the seller S, i.e. outside the blockchain, in return for a sum of money provided by the buyer B, the payment being made in the blockchain. As described in more detail below, the commercial interaction method comprises the generation of a set of transactions which are recorded in the blockchain BC.

[0046] Each new participant must register with 12 nodes acting as administrators. Once registered, each node is associated with a digital wallet that can be refilled by converting off-blockchain currency into its equivalent on-blockchain currency.

[0047] The general structure of a transaction made in the blockchain is as follows: \Flag\H(Tx)\Sig T \Amount\ where "Flag" indicates the transaction type, H(T X ) is the hash of a data T x which depends on the transaction, Sig? is the signature of the person initiating the transaction and Amount is the amount of money that the person initiating the transaction paid to initiate the transaction. All generated transactions are encrypted, signed and sent to the network 11 by the communication module of the participant's node initiating the transaction.

[0048] At step S10, a seller S wishing to sell a new product or service generates a transaction that includes the price of the service or product and a guarantee proportion Q that the seller recovers if the service or product is rejected by the buyer B upon receipt. Indeed, the process then includes a step of verification of the product or service by the buyer, the latter may reject the product or service received. To protect sellers from too many or unfounded rejections from buyers, the sellers set the guarantee proportion Q, which is the amount transferred from the buyer to the seller in the event of rejection of the service or product. The guarantee proportion Q is a share of the amount of the product or service in question. The sellers must therefore determine a value of Q that is a compromise between a Q that is too low, which weakly protects the seller against the risk of rejection by the buyer, and a Q that is too high, which dissuades the buyer.

[0049] The transaction is then sent to all nodes within the network for verification. If the transaction is validated, it is stored T10 in the BC blockchain and the set of products and services available for sale for the seller node is updated. A buyer node B can then choose a product or service that suits it and generates a transaction B10 to make a purchase, which contains an identification of the product or service purchased. This transaction is sent to all nodes in the network for verification and, if validated, it is stored in the T11 blockchain.

[0050] In step S11, a seller accepts a buyer's proposal and generates a transaction including the identification of the accepted purchase order. This transaction is sent to all nodes in the network for verification and, if validated, is stored in the blockchain T12. The method then comprises a step of depositing a deposit D B11 by the buyer (arrow Y in Figure 3). The deposit transaction T13 includes the identifier of the buyer and the seller and the amount of the deposit D. This transaction is recorded in the blockchain to prove that the buyer has actually paid a deposit for the corresponding purchase order. Alternatively, if the seller does not receive confirmation of the deposit after a certain time, the purchase order is rejected (arrow N).

[0051] The method then comprises the step S12 of supplying the product or service that was the subject of the purchase order, this supply taking place outside the blockchain. 3 also represents B12 the receipt of the product or service by the buyer B. Evidence of the delivery of the product or the performance of the service is retrieved T14 as mentioned above by the verification modules of the network nodes corresponding to the participants S and B of the transaction to verify and validate that the supply of the product or service has indeed taken place, and the modules generate a certificate that is also recorded in the blockchain by means of a transaction for validating a purchase order that is established from the identifier of the purchase order and the generated certificate. An arrow Y at the output of step T14 represents the case where the supply of the product or service has taken place, and an arrow N represents the case where it has not.

[0052] The rest of the process may include, in the event that the seller has not provided the service or product, returning the deposit to the buyer and updating the seller's reputation as described in more detail below. This is the subject of a transaction T15 recorded in the blockchain. Alternatively, in the event that the product or service has been correctly provided but the buyer does not accept it (arrow N after step B13 of accepting the service), the deposit may be returned by being distributed between the buyer and the seller according to a predetermined rule, and the buyer's reputation may be updated. This is also the subject of a transaction recorded in the blockchain T16. According to yet another possibility, the seller has correctly provided the product or service and the buyer has accepted it, and the deposit is transferred to the buyer, and the reputation of the buyer and seller is updated T17.In all cases, a transaction is recorded in the blockchain identifying the portion of the deposit returned and the recipient of the deposit return, as well as updating the reputation of one or both participants in the commercial interaction.

[0053] The payment of the amount returned to the buyer and / or seller is implemented by implementing a smart contract type program by the modules 21 of the respective nodes corresponding to the buyer and the seller.

[0054] We will now describe an embodiment for calculating the reputation of a network node. The reputation is calculated from trust values ​​assigned to the buyer and / or the seller after each sales interaction. The trust value associated with a seller T* after a sales interaction i in the real world is provided by: T s = S - T sub^s + (1 - S) T obj^s Where T Ub ^ s represents the subjective trust value and T ( L )b j^ s represents the objective confidence value, and 0 is a weighting coefficient between the two. Preferably, 0 is chosen so as to give more weight to the objective confidence value. The subjective confidence value T^ ub ^ s directly represents the buyer's opinion about the seller and is advantageously calculated by implementing subjective trust logic as described in the following publications: J. Audun et al. “Trust Network Analysis with Subjective Logic”, in Dobbie, G. Estivill-Castro, V (Eds.) Conference Proceedings of the Twenty-Ninth Australasian Computer Science Conference (ACSW 2006), Australian Computer Society, CD Rom, pp. 85-94. J. Keng et al., “Towards secure blockchain-enabled Internet of vehicles: Optimizing consensus management using reputation and contract theory”, 2018, arXiv: 1809.08387.

[0055] When a buyer B interacts with a seller S, an opinion rated O b (t,d,u) is provided to express the confidence of buyer b in the reliability of seller s, where t, d and u represent trust, distrust, and uncertainty, respectively; verify t+d+u=1 , t,d,u are included in [0,1] and are defined as follows: And the value of T^ ub ^ s after the i ème interaction is: T sub^s = t + m Where m and n are respectively the number of valid and invalid purchase interactions between b and s, If represents the frequency of interaction, the higher it is, the lower the uncertainty, is a weighting coefficient of uncertainty.

[0056] The objective confidence value Tg bj ^ s depends on the results of the verification process implemented during the purchasing process described above and the metrics used during this process, which depend on the purpose of the transaction.

[0057] Where C is a boolean indicating the presence (C=1) or absence of the certificate (C=0) issued for a valid transaction, Pj are additional evaluation parameters, which vary depending on the type of transaction considered, and <r7est un coefficient de pondération associé à Pj. Comme le certificat est généré à partir de preuves objectives de la fourniture du produit ou de la réalisation du service, on peut tenir compte de façon plus importante de la confiance objective en un nœud en donnant plus de poids au certificat.

[0058] The combination of objective and subjective trust values ​​provides an overall seller trust value at the i èmeinteraction. The same model is used to calculate the buyer's trust value.

[0059] The trust value associated with a node after an interaction i is then used to update the node's reputation. Each node in the network is associated with an initial reputation value Rinit, this value being considered a lower threshold that each node's reputation must not cross. In the event that the reputation falls below this initial value, the participant associated with the node is considered not credible by the other participants in the system, who will refuse to interact with it in a subsequent commercial interaction. Therefore, it becomes very difficult for it to return to a reputation value higher than Rinit.

[0060] The reputation of one or more nodes is therefore updated after a commercial interaction that took place in the real world, outside the blockchain, and involved the node (i.e. as a buyer or seller). The only way to increase the reputation value is to carry out valid interactions of purchase / sale of product or services outside the blockchain.

[0061] The reputation associated with a node involved in a purchase interaction i is updated as follows: Where RM represents the reputation at the end of the previous interaction i-1 , is a weighting function a> taking Nb and Ti as inputs (Ti is the trust value associated with the node at the end of transaction i, whether the node is a seller or a buyer), where Nb is the number of blocks added to the blockchain since the considered node joined the network. The advantage of this formula is that the weighting factor a> used is variable. It is a sigmoid function that is positively correlated to Nb and Ti, so that the longer a node stays in the network, the more likely it is to improve its reputation if it behaves honestly during buy / sell interactions. An example of a reputation curve of an honest node as a function of time is shown in Figure 5a, with the protocol according to the invention denoted PoGR. The IPoT curve corresponds to the reputation curve of an honest participant according to the IPoT protocol of the publication by Zhu et al.Mentioned above, K is the maximum value of the weighting coefficient, which can. only be achieved when Nb becomes very high. Moreover, the weighting function depends not only on Nb, but also on the trust score Ti calculated at the last interaction, so that dishonest behavior represented by a low score Ti in the last interaction will have a direct impact on the reputation score. In this regard, a reputation curve of a dishonest node as a function of time is shown in Figure 5b by being compared between the PoGR protocol according to the invention and the IPoT protocol of the publication by Zhu et al.

[0062] Referring to Figure 4, we will now describe a consensus algorithm, this algorithm being implemented by all the nodes of the network involved in the storage and updating of the blockchain. This consensus algorithm is based on a proof of guarantee and reputation, with a scoring method for selecting the BP node producing the next block added to the blockchain.

[0063] To be able to implement the consensus algorithm and therefore, for a node, be involved in the management and updating of the blockchain, each node must initially generate two TXGB transactions, which sets a GB collateral amount committed by the node, and TXG P , which defines a deposit amount G P , which is a part of the guarantee amount Gb and which corresponds to a risk accepted by the node. Indeed, G Pcorresponds to a sum of money, taken from the Gb collateral amount, which is lost by the node when it has generated an invalid block. The sum of money G P is transferred and distributed to other nodes. The GB collateral amount must be between predefined Gmin and Gmax values ​​set by the administrators, and the deposit amount G P is between Gmin and the guarantee amount Gb.

[0064] TXGB and TXG transactions P are verified and stored in the blockchain, through the implementation of the consensus algorithm by the other nodes in the network already involved in managing the blockchain. The node can only implement the consensus algorithm if the following two conditions are met: TXGb and TXGp transactions are valid, and The node reputation is greater than Rmin where Rmin > Rinit is the minimum value a participant must have to be able to operate a node and participate in consensus. Each node participating in the consensus algorithm stores a list of active nodes, i.e., a list of nodes implementing the consensus algorithm, and the reputation score associated with each node. This list is updated after each new block is added to the blockchain. If the node's reputation falls below Rmin or if the collateral amount Gb committed by the node falls below Gmin, then the node is automatically removed from the list of active nodes by the node implementing the consensus algorithm. In addition, an administrator can exclude the node from the network and prevent a future return of the node by blocking a node identifier, for example, its blockchain address, i.e., its public key. An administrator can also prohibit a participant from generating a new node by blocking its address. Both functionalities are ensured using a smart contract that defines the rights and roles of each participant.

[0065] The consensus algorithm includes, for each node that executes it, calculating a score associated with each active node in the list, based on the node's current reputation value and the deposit amount committed by the node. The score also takes into account the amount of collateral committed by the node.

[0066] In one embodiment, the score is a linear combination of three parameters: the node's reputation, a factor G = GB / GM3X which is the ratio between the node's collateral amount and the maximum amount that can be committed, and which therefore represents the proportion of the maximum amount that the node blocks as collateral balance, and a factor E=GP / GB which represents the risk taken by the participant, since the closer the deposit amount is to the collateral amount, the higher the risk for the node to be removed from the list of active nodes in the event of an invalid block.

[0067] According to an example, the score S nassociated with a node n is calculated according to the following formula: S n = (a. G + p. E + y. R). T n ; a + + y = 1 r n is a block generation rate initially equal to 1, and which decreases exponentially with the number of blocks generated by node n and which have been added to the blockchain during a cycle B c . B c is a duration expressed as the number of blocks added to the blockchain since the generation of a block by the considered node n. Bc corresponds to a period during which a node must not generate a block to be able to recover a rate of 100%. For example, if Bc = 5, and a node n generates a new block, the node only recovers a generation rate of 100% after adding five blocks generated by other nodes in the network to the blockchain. In other words, r nonly returns to the value of 1 after node n generates a block, when the considered node n does not generate any of the following five blocks. Moreover, r n continues to decrease exponentially depending on the number of blocks generated by node n during this period.

[0068] Once a score has been calculated for each of the active nodes, each node implementing the consensus algorithm selects, as the BP node producing the next block to be added to the blockchain, the node with the highest score. Step C20 in Figure 4 represents the calculation of each node's score and the selection of the BP node. This is followed by the generation C21 of a block to be added to the blockchain by one or more candidate nodes, and therefore by the reception C10 by a node (or each node in the network) of the generated block(s).

[0069] To add a new block to the BC blockchain, when a node receives a block generated by another node n in the network during a step C10, it verifies during a step C11 that the block was generated by the node BP selected as the producer of the next block added to the chain. If this is not the case (arrow N), then the block is kept C12 for a later iteration of the algorithm. When the block actually comes (arrow Y) from the selected node as producer of the next BP block added to the chain, then the node that received the block verifies the validity of the C13 block, that is, the validity of all the transactions recorded in the block.

[0070] The node implementing the consensus algorithm then sends C13 to the other nodes in the network a notification indicating the result of the block validity verification.

[0071] If the block is valid (C13a), the notification therefore identifies this block as the next block to be added to the blockchain, since it has been selected on the block producer node and then verified for block validity.

[0072] As the same algorithm is implemented by all nodes, the node that sent the notification also receives C14 equivalent notifications issued by other nodes, identifying a block verified as valid, and corresponding to a node selected as the BP producer of the next block to be added to the blockchain, as the next block to be added to the blockchain.

[0073] Following the reception of the notifications, the node adds C15 to its respective copy of the blockchain the block that has been identified in the majority of the notifications received, i.e. that has been identified in a number of notifications greater than or equal to N+1 / 2 where N is the number of nodes in the network implementing the consensus algorithm. The algorithm therefore assumes a consensus on the identity of the block producer node and on the validity of the block.

[0074] If, on the other hand, the block is invalid (C13b), the notification sent to the other nodes in the network identifies the block as invalid. The node can similarly receive notifications C15 issued by other nodes, identifying a block as invalid. When a majority of notifications designate a block as invalid, then the node removes the node that produced the block from the list of active nodes C16. Since all nodes implement the same consensus algorithm, the node is thus removed from the list of active nodes of all nodes. The deposit amount Gp committed by the node is then transferred and distributed to the other participants. A network administrator node, having identification information of the human participant corresponding to the node, can also prevent the participant from generating a new node at a later date. For example, the generation of a node can be conditioned

[0075] In the absence of a majority of notifications identifying the same block as invalid (arrow N at the output of block C14), the protocol is repeated C20 with the generation C21 by one or more nodes 10 of the network of a new block to be added to the block chain, and the reception by the nodes implementing the consensus algorithm of the block(s) (C10).

[0076] The proposed algorithm is secure against many types of attacks. For example, a malicious participant who operates a node and attempts to generate an invalid block, i.e., one that includes at least one invalid transaction, will have their node immediately deleted after verification by other nodes in the network, and will also lose their Gp deposit amount.

[0077] The algorithm also ensures fairness between nodes thanks to the node generation rate which is involved in calculating a node's score, so that even if a node has a high collateral balance it is not guaranteed to succeed in adding a new block to the blockchain, the node generation rate being favorable to nodes that have not yet added a block to the blockchain.

[0078] Comparative simulations were implemented with a cluster of eight computer terminals whose characteristics are given in Table 1 below. The compared algorithms were evaluated by the Hyperledger Caliper program for evaluating the performance of blockchain algorithms to test and compare the performance of different solutions such as latency and throughput. The following configurations were adopted: “Permissioning Smart Contract” from Consensys for the rights management module, “Hyperledger Besu” for the exchange management module and “Web3js” for the interaction of client applications with the rights management module. Table 1

[0079] Figure 6 shows a comparison of the algorithm's latency over the number of nodes, between the algorithm presented above, denoted PoGR in the figure, and two other protocols: Ethach (Ethereum's proof-of-work algorithm) and Clique (Ethereum's proof-of-authority algorithm). Latency refers to the difference in time in seconds between the submission and completion of a transaction, a transaction being completed once it has been verified and recorded in the blockchain. Figure 7 shows a comparison of the algorithm's throughput over the number of nodes, with throughput being measured as the number of transactions recorded per second. It can be observed that the algorithm presented above outperforms the performance of a proof-of-work-based algorithm. Moreover, by adding nodes to the network, the results show that the throughput of the proof-of-work-based algorithm increases to reach a peak but decreases once this peak is reached, unlike the throughput of the PoGR protocol described herein, which remains stable since the protocol does not depend on the number of nodes. Moreover, compared to a proof-of-authority-based algorithm, no significant performance difference could be observed in the case of a small network. This is due to the experimental setup where all nodes produce blocks in a fixed period. However, when the network size exceeds a certain threshold (in this case 12 nodes), the throughput of the Clique protocol starts to decrease. The throughput of the protocol according to the invention remains better than that of Clique and Ethach.This is justified by the fact that in Clique, the probability of generating forks in the blockchain increases with the number of validators, which is not the case in the protocol according to the invention.

Claims

Claims

1. A method for determining a consensus within a set of nodes forming a peer-to-peer network for managing a blockchain, for adding a new block to the blockchain, the method being implemented by a node of the peer-to-peer network (11), the node being implemented by a computer system (10) comprising at least one processor and a memory storing a list of active nodes, a current reputation value associated with each active node, and a respective copy of the blockchain, the method comprising: Calculating a score (C20) associated with each active node in the list, from the current reputation value of the active node and a deposit amount (Gp) committed by the active node, The selection of the producer node of the next block, this node having the highest score among the calculated scores, the reception (C10) of at least one block generated by a candidate node for adding a new block to the blockchain, and, when the candidate node is the node selected as producer of the next block, the verification of the validity of the block, when the received block is valid, the sending (C13) to the other active nodes of the network of a notification identifying the received block as the next block of the blockchain, Receiving (C14) a plurality of notifications issued respectively by the other active nodes of the network, each notification identifying a block selected by another active node of the network and, The addition (C15) to the blockchain of the block identified by a majority of the notifications received.

2. Method according to claim 1, comprising, if the generated block is considered invalid by a majority of the active nodes of the network, the deletion (C16) of the candidate node having generated the invalid block from the list of active nodes.

3. The method of claim 2, further comprising receiving a portion of the deposit amount deposited by the deleted node.

4. Method according to one of the preceding claims, comprising removing an active node from the list of active nodes when the reputation of the node is below a determined threshold.

5. A method according to one of the preceding claims, wherein each active node defines a guarantee amount (GB) which must be between determined minimum and maximum guarantee amounts, and the method comprises removing an active node from the list of active nodes when the guarantee amount (GB) deposited by the node is less than the minimum guarantee amount.

6. Method according to one of the preceding claims, in which each active node defines a guarantee amount (GB) which must be between determined minimum and maximum guarantee amounts, and the score of an active node is calculated from: a ratio between the guarantee amount defined by the node and the maximum guarantee amount (Gs / Gmax), and a ratio between the deposit amount of the node and the guarantee amount (GP / GB).

7. The method of the preceding claim, wherein the score of a node is a linear combination of the current reputation value, the ratio of the node-defined collateral amount to the maximum collateral amount, and the ratio of the node's deposit amount to the collateral amount.

8. A method according to any preceding claim, wherein the calculation of a node's score further takes into account a block generation rate that decreases with the number of blocks added to the blockchain by the node during a determined period.

9. Method according to one of the preceding claims, in which each node is further configured to implement at least one product or service purchase interaction application outside the blockchain, to calculate a trust value associated with a purchase interaction having taken place outside the blockchain, each node being further configured to calculate the current reputation value of a node as a function of: a previous reputation value, and the trust value associated with the last purchase interaction having involved the node.

10. Method according to the preceding claim, in which each node is configured to calculate the current reputation value of a participant by implementing a smart contract type algorithm.

11. Computer program product, comprising code instructions for implementing the method according to one of the preceding claims, when executed by a computer.

12. Computer terminal (10) comprising at least one processor and one memory, and being connected to a set of other computer terminals to form a peer-to-peer network (11) for managing a blockchain, the memory of the computer terminal storing a list of so-called active nodes, a current reputation value associated with each active node, and a respective copy of the blockchain, the computer terminal being configured to implement the method according to one of claims 1 to 10.

13. Distributed computer system (1) comprising a set of computer terminals (10) connected together so as to form a peer-to-peer network (11), each computer terminal comprising at least one processor and one memory and forming a node of said network, the system being characterized in that each terminal is configured to implement the method according to one of claims 1 to 10.

Images