METHOD FOR SCHEDULING PEER SOLICITATIONS IN A CONSENSUS PROCESS FOR A BLOCKCHAIN

Abstract

A method for executing consensus processes in blockchain development by a peer network includes a preparatory phase where simulations under typical operating conditions are performed (302) to collect (303), independently for each peer, information relating to events in the execution of the consensus process during the development of test blockchains. The collected information is divided (306) into input and output data in order to train (308) a machine learning model to obtain predictions identifying the peers most likely to transmit missing blocks and when. The machine learning model thus trained allows each peer to determine a schedule of requests to other peers in the consensus process for blockchain development, based on the predictions obtained.Thus, the consensus process is more efficient. Figure to be published with the abbreviation: Fig. 3B.

Description

Title of the invention: METHOD FOR SCHEDULING PEER SOLICITATIONS IN A CONSENSUS PROCESS FOR A BLOCKCHAIN technical field

[0001] The present invention relates to an optimization, through machine learning, of a consensus process, for example by proof of authority, in the development of a blockchain by a network of node devices, called "peers". STATE OF PRIOR ART

[0002] Blockchain is a distributed ledger technology that allows data to be stored securely, transparently, and immutably, using cryptographically linked blocks of data. Each block of data contains a timestamp and a link to the previous block, thus forming a continuous chain whose alteration is easily detectable.

[0003] For the development of a blockchain, a network of node devices, called "peers" ("peers" in English), executes a consensus process, which is a data sharing mechanism that ensures security, integrity and decentralization of data transfers and allows peers to agree on the content of the blockchain.

[0004] As an example, a well-known consensus process is Proof of Authority (PoA). In this case, block validation is performed by trusted peers. This type of consensus process is widely used in private networks because of its low energy requirements and the speed of transactions it allows, compared to other consensus processes (Proof of Work (PoW), Proof of Stake, etc.).

[0005] The blockchain aims to store data shared between peers and verified by peers in blocks organized in an ordered manner. All peers must have their data stored in the same order. The purpose of the consensus process is therefore for all peers to reach a common agreement on the data in the blockchain (the data is organized into blocks) and on its order within the blockchain. The number of blocks available to a peer device at a given time t is called the "blockchain height".

[0006] For the development of the blockchain, peers establish peer-to-peer (P2P) connections. For example, [Fig. 1] schematically illustrates a communication system 100 in which four peers PI 111, P2 112, P3 113, P4 114 interact in a network to build the blockchain. In [Fig. 1], each peer has established a peer-to-peer (P2P) connection with every other peer in the communication system 100.

[0007] Each peer PI 111, P2 112, P3 113, P4 114 has an ordered list of connections with the other peers of the communication system 100. For example:

[0008] - the ordered list of peer PI 111 lists the other peers of the communication system 100 in the following order: P2 112, P3 113, P4 114;

[0009] - the ordered list of peer P2 112 lists the other peers of the communication system 100 in the following order: P3 113, P4 114, PI 111;

[0010] - the ordered list of peer P3 113 lists the other peers of the communication system 100 in the following order: P4 114, PI 111, P2 112; and

[0011] - the ordered list of peer P4 114 lists the other peers of the communication system 100 in the following order: PI 111, P2 112, P3 113.

[0012] For each peer, the ordered list to be used is established by default. As in the illustrative example above, the ordered list is generally offset from one peer to the next, thus allowing the distribution of requests among the peers at the start of the blockchain creation process. Subsequently, asynchronies between actions performed by the peers reduce, or even eliminate, this distribution of requests among the peers.

[0013] In more detail, the ordered list defines the order in which the peer in question requests the other peers of the communication system 100 during the consensus process; that is, a sequence of requests to the other peers in the execution of the consensus process. The ordered list is used in a circular fashion. Thus, considering a peer that is missing blocks of data, this peer will attempt to retrieve one or more missing blocks of data from the first peer in its ordered list and will then proceed to the second peer in its ordered list if the first peer does not have all the missing blocks of data, and so on.

[0014] When a peer A requests another peer B to participate in the consensus process, peer A sends peer B a notification message (e.g., a "hello" message) which includes a P2P connection identifier, the signature (hash) of the genesis block of the blockchain, the blockchain height available to peer A, and a list of peers known to peer A. The blockchain height available to peer A identifies the blocks available to peer A. Upon receiving this message, peer B performs standard checks, particularly authentication checks of peer A.

[0015] Peer B sends an acknowledgment which includes the P2P connection identifier, a hash of the blockchain genesis block, and the chain height at Peer B's disposition. Assuming that the chain height at peer B's disposition is greater than that of peer A, peer A can then send peer B a request to receive block hashes that are missing from peer A's disposition (e.g., via a "getblockhashes" message). Upon receiving this message, peer B performs standard checks, particularly cryptographic checks, and if the request is valid, peer B returns a message providing the requested hashes for the missing block(s) (e.g., via a "blockhashes" message). Upon receiving this message, peer A also performs standard checks, particularly cryptographic checks, on the received hashes. Peer A can then, if the received message is valid, request the retrieval of the missing data, block by block (e.g., via a "getblock" message).

[0016] Upon receiving a message requesting the provision of one or more missing blocks, peer B performs standard checks, particularly cryptographic checks, and insofar as the request is valid, the peer in question provides protocol information enabling the retrieval of the block in question, such as information on the encoding type applied to the data of the block concerned and a link to a server (e.g., a web server) where the block in question can be retrieved.

[0017] As schematically illustrated in [Fig.1], after execution of the CONS 120 proof-of-authority consensus process, the peers PI 111, P2 112, P3 113, P4 114 converged to the same chain height and validated the blocks B0 130_0 (genesis block), B1 130_1, B2 130_2,.., Bn 130_n.

[0018] Proof-of-Authority (PoA) consensus processes are known for their speed of execution. However, as the blockchain develops over time, the default configuration of the ordered lists used by peers to establish the order of their requests to other peers becomes less relevant. This phenomenon is further amplified with an increasing number of peers involved. It should be noted that this problem is also found in other types of consensus processes.

[0019] It is therefore desirable to provide a solution that makes it possible to increase the speed of consensus processes, in particular but not exclusively, proof-of-authority (PoA) consensus processes. Description of the invention

[0020] To this end, a method for executing consensus processes in the creation of a blockchain by a network of node devices, called peers, is proposed herein, the method comprising the following steps, from a preparatory phase, prior to the creation of the blockchain:

[0021] - to set up the peer network to perform simulations under conditions usual uses;

[0022] - execute a message exchange protocol to reach a consensus in the development of test blockchains;

[0023] - collect, independently for each peer, information relating to events occurring in the preparatory phase during message exchanges, and the processing of these messages, during executions of the consensus process in the development of test blockchains;

[0024] - distribute the information collected during the preparatory phase between data input and output data for training a machine learning model; and

[0025] - train, independently for each peer, the learning model automatic using the collected distributed information, in order to make predictions of the timing of message exchanges with other peers to execute the consensus process aimed at identifying the peers that are most likely to transmit missing blocks and when.

[0026] In addition, the process includes the following steps of a use phase subsequent to the preparatory phase:

[0027] - to set up the peer network for the development of the blockchain, in activating the machine learning model on each pair;

[0028] - execute the message exchange protocol seeking consensus in the development of the blockchain in question;

[0029] - collect, independently by each peer, information relating to events occurring during the usage phase of message exchanges, and the processing of these messages, during the execution of the consensus process in the development of the blockchain in question;

[0030] - inject the collected information into the machine learning model trained, on each peer in a distributed manner, to obtain predictions of the timing of message exchanges with other peers to execute the consensus process; and

[0031] - determine a sequence of requests from said peer to other peers in the consensus process for developing the blockchain, based on the predictions obtained.

[0032] Thus, thanks to such training of the machine learning model and its influence on the ordering of requests to other peers, the speed of the consensus process is increased.

[0033] According to a particular embodiment, the consensus process is by proof of authority.

[0034] According to a particular embodiment, during the preparatory phase, information is collected by execution cycles, information relating to events occurring during the same execution cycle being buffered together, and over N execution cycles per simulation, the first K execution cycles provide the input data to train the machine learning model and the last NK execution cycles provide the output data to train the machine learning model.

[0035] According to a particular embodiment, the machine learning model has a loss function with weights increased on the block chain height available to each other peer over time.

[0036] According to a particular embodiment, the machine learning model is a reinforcement learning model, where each peer is an agent, with a reward function representing a time gain to reach the highest blockchain height, the machine learning model continuing to be trained during the usage phase.

[0037] According to a particular embodiment, within each peer during the preparatory phase, the collected data are reorganized by execution cycle, and within each execution cycle, the collected data are grouped, chronologically, by peer with respect to which at least one event has occurred during said execution cycle.

[0038] According to a particular embodiment, a dynamic selection of predominant data types is carried out among the information collected, by determining one or more data types among the input data which have the most influence on the output data.

[0039] According to a particular embodiment, the dynamic selection is carried out by principal component analysis or by random forest analysis.

[0040] According to a particular embodiment, the machine learning model is trained and used only with the collected information which are predominant types of dynamic selection.

[0041] Also proposed here is a communication system comprising a network of node devices, called peers, the peers being configured to execute a consensus process in a blockchain development, the communication system comprising electronic circuitry configured to perform the following steps, from a preparatory phase in which the peer network is set up to carry out simulations under normal conditions of use, prior to the development of the blockchain:

[0042] - execute a message exchange protocol to reach a consensus in the development of test blockchains;

[0043] - collect, independently for each peer, information relating to events occurring in the preparatory phase during message exchanges, and the processing of these messages, during executions of the consensus process in the development of test blockchains;

[0044] - distribute the information collected during the preparatory phase between data input and output data for training a machine learning model; and

[0045] - train, independently for each peer, the learning model automatic using the collected distributed information, in order to make predictions of the timing of message exchanges with other peers to execute the consensus process aimed at identifying the peers that are most likely to transmit missing blocks and when.

[0046] The electronic circuitry is further configured to perform the following steps of a usage phase subsequent to the preparatory phase where the peer network is set up for the development of the blockchain:

[0047] - execute the message exchange protocol seeking consensus in the development of the blockchain in question;

[0048] - collect, independently by each peer, information relating to events occurring during the usage phase of message exchanges, and the processing of these messages, during the execution of the consensus process in the development of the blockchain in question;

[0049] - inject the collected information into the machine learning model trained, on each peer in a distributed manner, to obtain predictions of the timing of message exchanges with other peers to execute the consensus process; and

[0050] - determine a sequence of requests from said peer to other peers in the consensus process for developing the blockchain, based on the predictions obtained. Brief description of the drawings

[0051] The features of the invention mentioned above, as well as others, will become clearer upon reading the following description of at least one exemplary embodiment, said description being made in relation to the accompanying drawings, among which:

[0052] [Fig.1] schematically illustrates a communication system adapted and configured for the development of a blockchain, according to the state of the art;

[0053] [Fig.2] schematically illustrates a suitable and configured communication system for the development of a blockchain, according to the present invention;

[0054] [Fig.3A] schematically illustrates the communication system, in a preparatory phase;

[0055] [Fig.3B] schematically illustrates an algorithm for training a model by machine learning, within the framework of the preparatory phase;

[0056] [Fig.4] schematically illustrates an algorithm for using the machine learning model after training; and

[0057] [Fig.5] schematically illustrates an example of a hardware platform suitable for use in the communication system.

[0058] DETAILED DESCRIPTION OF IMPROVEMENTS

[0059] Figure 2 schematically illustrates the adapted communication system 100 and configured for the development of a blockchain, according to the present invention. Compared to [Fig. 1], each peer PI 111, P2 112, P3 113, P4 114, is here equipped with a machine learning model MOD 200. The machine learning model MOD 200 influences the consensus process CONS 120, and more particularly the ordering of solicitations from each peer to the other peers during the execution of the consensus process CONS 120, so as to improve the speed of block acquisition (increasing the blockchain height).

[0060] In a particular embodiment, the blockchain is a private blockchain. A private blockchain is a blockchain that is accessible only to a selected group of authorized users. Access to the blockchain is thus limited to invited and verified participants, and control is centralized by a network operator. Transparency is then reduced because only authorized users can see the blockchain data. Anonymity is limited because the identities of the selected users are known, but transactions are restricted and controlled.

[0061] Various types of consensus processes can be used, such as: Proof of Authority (PoA) consensus processes, Proof of Delegated Authority (PoDA) consensus processes, Proof of Elapsed Time (PoET) consensus processes, and Proof of Stake (PoS) consensus processes. The latter is most often used in the development of public blockchains but is also suitable for private blockchains. Other hybrid or customized consensus processes based on one or more of the consensus processes listed above can also be used.

[0062] In a particular embodiment, the CONS 120 consensus process is a Proof of Authority (PoA) consensus process.

[0063] To do this, the MOD 200 machine learning model is previously trained, during a preparatory phase, as detailed below in relation to Figs. 3A and 3B.

[0064] Each pair PI 111, P2 112, P3 113, P4 114, is equipped with a MON 300 data monitoring device or function to collect information to enable the training of the MOD 200 machine learning model and its subsequent use once trained.

[0065] As schematically illustrated in [Fig. 3A], when the training has Not yet implemented, the MOD 200 machine learning model is not present on any of the peers PI 111, P2 112, P3 113, P4 114. As detailed below, training requires prior COLL 340 collection of a set of information obtained by each MON 300 data monitoring device or function.

[0066] These collected data are then processed to enable independent training of the MOD 200 machine learning model for each pair PI 111, P2 112, P3 113, P4 114. As schematically illustrated in [Fig. 3A], each pair PI 111, P2 112, P3 113, P4 114 transmits its collected data to a respective processing platform PP1 351, PP2 352, PP3 353, PP4 354. Each processing platform PP1 351, PP2 352, PP3 353, PP4 354 is then configured to train the MOD 200 machine learning model specifically for said pair PI 111, P2 112, P3 113, P4 114 with the data collected from the pair PI 111, P2 112, P3 113, P4 114. 114 in question.In one embodiment, each pair PI 111, P2 112, P3 113, P4 114 has adequate processing and memory resources to process the collected data and perform its own training of the MOD 200 machine learning model without resorting to an external processing platform. In another embodiment, all the pairs PI 111, P2 112, P3 113, P4 114 transmit their collected data to the same processing platform PP. This processing platform PP then processes the collected data of the pairs PI 111, P2 112, P3 113, P4 114 separately and performs the training of the MOD 200 machine learning model independently for each pair PI 111, P2 112, P3 113, P4 114. This embodiment simply allows the pooling of processing and memory resources.

[0067] Then, in a step 301, the communication system 100 is put in place for the purpose of further training the MOD 200 machine learning model.

[0068] In a step 302, simulations of the execution of the CONS 120 consensus process under real-world conditions are performed. In other words, the blocks used contain test data, potentially without any particular significance (but of a size consistent with the data (blocks) that are assumed to be shared subsequently and trying to be very varied), but the CONS 120 consensus process is carried out by peers PI 111, P2 112, P3 113, P4 114 on these test data blocks under real-world conditions of use of the communication system 100.

[0069] Simulations can be triggered with test block chains already started, with different block chain heights for peers PI 111, P2 112, P3 113, P4 114. One or more blocks can be added during the simulation.

[0070] The simulations preferentially include phases of operation of the communication system 100 where consensus is reached, phases of operation of the communication system 100 where consensus leads to failure, phases of hardware failures and operational recovery following these failures, situations of adding one or more peers and situations of deleting one or more peers.

[0071] During these simulations, information relating to events occurring in the execution of a message exchange protocol, and in the processing of these messages, in the search for consensus in the development of test blockchains is collected.

[0072] In a particular embodiment, information relating to the progress of the development of the test blockchain is thus obtained and stored, as well as network information from the communication system 100, by each MON 300 data monitoring device or function in a step 303.

[0073] The collection of the information in question is therefore distributed.

[0074] Additional information derived from the collected information, such as statistics (mean, variance), can be added during or after the execution of all or part of the set of simulations, by each MON 300 data monitoring device or function.

[0075] In a particular embodiment, data collection is organized in cycles. Subsequently, and analogously, predictions by the MOD 200 machine learning model are also performed in cycles. These are referred to as execution cycles (generally called "timesteps" in Anglo-Saxon terminology). Execution cycles allow for the definition of temporal checkpoints to pace the behavioral analysis of peers. In particular, events occurring during the same execution cycle are buffered together, which allows them to be manipulated (e.g., cleaning, preprocessing, etc.) and reorganized by cycle. This facilitates the training of the MOD 200 machine learning model, as well as the subsequent generation and use of predictions.

[0076] It should be noted that the duration of the execution cycles is not necessarily the same for all peers, since each peer independently collects the data which are used to train its own MOD 200 machine learning model.

[0077] In a particular embodiment, during an exchange with each said peer, each time a predefined event occurs (e.g., receipt of a message, triggering of a cryptographic verification, etc.), the information collected is:

[0078] - peer identifier in question;

[0079] - session time;

[0080] - known blockchain height of the peer in question (see hello message) at moment of the exchange;

[0081] - number of previous sessions (data which is stored in memory and which is incremented at each session);

[0082] - quantity of data transmitted;

[0083] - cryptographic verification time;

[0084] - peer latency.

[0085] At the end of an execution cycle, in a particular embodiment, the number of sessions per collection cycle can be added to the collected information.

[0086] A session is a communication protocol concept that allows computer systems to communicate coherently and interactively for the duration of a given interaction. A session is a temporary interaction between two or more endpoints in a network. It begins with the establishment of a connection and ends with its closure. Sessions allow for the interactive exchange of data between the devices or services involved. Sessions are generally stateful.

[0087] Peer latency refers to the time it takes for two peers to exchange data. It depends primarily on the available bandwidth and the physical distance between the peers in question within the network. Peer latency is distinct from the overall blockchain network latency, which includes the time it takes to add a complete block. Note that private networks generally generate lower and more predictable latency than open public networks.

[0088] It should be noted that, when a peer makes a signature, that peer can then be identified through a database of public keys stored in a decentralized manner by each peer.

[0089] Each simulation terminates when all the peers P111, P2112, P3113, P4114 converge to a desired test block chain height. Alternatively, each simulation terminates when a predetermined number of execution cycles is reached. In another variant, each simulation terminates when a number A predetermined number of execution cycles without data collection (no relevant event occurring) is reached.

[0090] In an optional step 304, the collected data are transferred to a processing platform to have more resources available for processing and training the MOD 200 machine learning model (independently for each of the peers PI 111, P2 112, P3 113, P4 114), as already explained above in relation to [Fig.3A].

[0091] In an optional step 305, the collected data is cleaned and / or the data is preprocessed in order to improve the quality of the data presented to the MOD 200 machine learning model for training.

[0092] For example, cleaning can be to remove, from the collected data, non-significant data (e.g., beyond an acceptable margin in relation to a standard deviation) or poorly recorded data (e.g., typing error for example).

[0093] For example, a pre-processing step could be to create a history of events linked to each peer in the network. In practice, the collected information, whose descriptor includes the identifier of the peer in question, is grouped and ordered according to its timestamp. This allows for machine learning using a descriptor.

[0094] For example, a pre-processing step may be to normalize or standardize values, to perform a digital encoding of categorical information (e.g., "one-hot encoding").

[0095] For example, a preprocessing step could be to include padding data to ensure dimensionality consistency in the collected and formatted descriptors. For instance, at each time information is collected on any of the peers, a dummy descriptor is added for each of the other peers. Thus, the event history associated with any peer has the same number of elements as any other peer, making the event histories easier to manipulate and feed into the MOD 200 machine learning model.

[0096] In a particular embodiment, within each peer, the collected data are reorganized by execution cycle, and within each execution cycle, the collected data are grouped, chronologically, by peer with respect to which at least one event occurred during said execution cycle.

[0097] An example would be the following, for data collected by a peer identified by ID3 having interacted with other peers identified by ID1, ID2, ID4 during execution cycles "Timestep 1", "Timestep 2". Note that each event corresponds to a data point or a set of data (identified here by dataX where X is a number) is associated with a timestamp (identified here by h_dataX) representing the time at which the event in question occurred.

[0098] -Timestep 1:

[0099] ID1:

[0100] -data 1, h_data 1

[0101] -data2, h_data2

[0102] -data3, h_data3

[0103] ID2:

[0104] -data 1, h_data 1

[0105] -data2, h_data2

[0106] -data3, h_data3

[0107] -data4, h_data4

[0108] -Timestep 2:

[0109] ID1:

[0110] -data 1, h_data 1 [YES] -data2, h_data2

[0112] ID4:

[0113] -data 1, h_data 1

[0114] -...

[0115] Note, as already indicated above, that there may be execution cycles where no event has occurred, and therefore during which no data has been collected.

[0116] Thus, each peer obtains a chronological description over N execution cycles (“N timesteps”) of data sets representing the action of all other peers in the communication system 100.

[0117] In a step 306, a distribution of the collected data between input data and output data is carried out.

[0118] The goal of training the MOD 200 machine learning model is to predict events in advance to determine which peers are most likely to transmit missing blocks and when. To do this, for each simulation, a portion of the collected data (the first K execution cycles out of the N execution cycles covered by the data collection) is used as input to the MOD 200 machine learning model, and the remainder of the collected data (the last NK execution cycles out of the N execution cycles covered by the data collection) is used as output to the MOD 200 machine learning model; that is, to train the MOD 200 machine learning model to make predictions of the last NK execution cycles based on the first K execution cycles.

[0119] The higher the number of peers, the larger K is compared to NK for the same value of N. In other words, the higher the number of peers, the more desirable it is to increase the number of execution cycles considered.

[0120] In machine learning, the loss function quantifies the margin of error between a prediction of the considered machine learning model and the actual expected target output. Different weights can then be defined for the error made on the output data. Thus, in a particular embodiment, the MOD 200 machine learning model has a loss function with weights increased on the block chain height (as predicted) available to each other peer over time.

[0121] In step 307, a dynamic selection of predominant data types is preferentially performed from among the collected (and potentially cleaned and preprocessed) data, using the input / output data distribution, by determining one or more data types among the input data that most influence the output data. For example, a Principal Component Analysis (PCA) is performed. Another example is a Random Forest Analysis (RFA).

[0122] This dynamic selection allows, in a particular embodiment, for the MOD 200 machine learning model to be trained only with the collected data that are of these predominant types. This accelerates training, and subsequently, in actual use of the communication system 100 for blockchain development, it allows for the collection of only the information corresponding to these predominant types, thus conserving memory and processing resources.

[0123] Alternatively, this dynamic selection allows the prediction by the MOD 200 machine learning model to be carried out only on data of these predominant types even if, as input, all the collected data are injected into the MOD 200 machine learning model.

[0124] Also, in a particular embodiment, this dynamic selection makes it possible to assign more weight to a prediction error on data of these predominant types in a machine learning loss function.

[0125] In a step 308, the MOD 200 machine learning model is trained. The training is carried out according to the distribution of the collected data between input and output data established in step 306, possibly limiting itself to the predominant data types selected in step 307. The MOD 200 machine learning model is thus trained to make predictions of exchange timing with other peers for the execution of the consensus process, aimed at identifying the peers who are most likely to transmit missing blocks and when.

[0126] A deep learning model can be used, for example of the LSTM (Long Short-Term Memory) or GRU (Gated Recurrent Unit) type.

[0127] Alternatively, a reinforcement learning model is used, where each peer is an agent, the communication system 100 is the environment, and the rewarding function represents a time gain in reaching the highest blockchain height. Thus, in the usage phase (i.e., once the model is trained), the MOD 200 machine learning model can continue its training and further improve its performance in predicting the timing of exchanges with other peers for the execution of the consensus process by taking into account, as they occur, the actual exchanges between peers.

[0128] Figure 4 schematically illustrates an algorithm for using the model by MOD 200 machine learning (use phase) after training for the development of a blockchain.

[0129] In a 401 step, the communication system 100 is set up for the purpose of developing the blockchain in question. The machine learning model MOD 200 after training is activated on at least one peer, preferably on all peers PI 111, P2 112, P3 113, P4 114.

[0130] In a 402 step, the blockchain construction is initiated. Peers execute a message exchange protocol, as during simulations, when they seek consensus in the construction of the blockchain.

[0131] In a 403 step, each peer collects information relating to events occurring in the execution of the message exchange protocol, and in the processing of these messages, in the search for consensus in the creation of the blockchain. Each peer collects this information independently and for its own purposes, i.e., to feed input data into its own MOD 200 machine learning model.

[0132] In a 404 step, each peer feeds the collected information into its own MOD 200 machine learning model. The MOD 200 machine learning model then generates predictions of the timing of exchanges with other peers for the execution of the consensus process. Based on the training performed, the predictions aim to identify the peers most likely to transmit missing blocks and when.

[0133] Thus, thanks to its own MOD 200 machine learning model, trained on data that was collected specifically for it, each peer can deduce an optimized sequence of requests from other peers in the pursuit of execution of rounds of consensus processes in the development of the blockchain.

[0134] Thus, in step 405, the peer in question determines a sequence of requests to other peers in the execution of the consensus process, based on the exchange timing predictions obtained by its MOD 200 machine learning model. According to these predictions, the sequence defines which other peer to request, and at what time, to increase the blockchain height of the peer in question as quickly as possible. The sequence is therefore not fixed, as in the ordered list of the prior art, and is dynamically defined to improve the performance of the communication system 100 in seeking consensus for the creation of the blockchain.

[0135] Information gathering continues, as well as the real-time definition of the ordering of requests to other peers, by looping through steps 403, 404 and 405.

[0136] The algorithm in [Fig.4] is executed until the end of the blockchain development.

[0137] Figure 5 schematically illustrates an example of a DISP 500 device hardware platform, which is suitable for use in the communication system 100. This example of a DISP 500 device hardware platform is suitable for implementing each PI pair 111, P2 112, P3 113, P4 114. This example of a DISP 500 device hardware platform is suitable for implementing the PP 350 processing platform.

[0138] The hardware platform of the DISP 500 device then comprises, connected by a communication bus 510: a processor or CPU (for "Central Processing Unit") 501, or a cluster of such processors, such as GPUs ("Graphics Processing Units"); a random access memory (RAM) 502; a read-only memory (ROM) 503, or a rewritable memory of the type EEPROM ("Electrically Erasable Programmable ROM"), for example of the Flash type; a data storage device, such as a hard disk drive (HDD) 504, or a storage media reader, such as an SD card reader (for "Secure Digital");a set of input and / or output interfaces, such as 505 communication interfaces, enabling communication and, in particular, for peers to exchange messages during the execution of the CONS 120 consensus process in the development of blockchains. ;

[0139] The processor 501 is capable of executing instructions loaded into RAM 502 from ROM 503, from external memory (not shown), from a storage media, such as an SD card or HDD, or a communication network. When the DISP 500 device hardware platform is powered on, the 501 processor is able to read instructions from RAM 502 and execute them. These instructions form a computer program causing the 501 processor to implement the steps, behaviors, and algorithms described herein in relation to the device (peer, PP 350 processing platform) in question.

[0140] All or part of the steps, behaviors, and algorithms described herein can thus be implemented in software form by executing a set of instructions by a programmable machine, such as a DSP (Digital Signal Processor) or a processor, or be implemented in hardware form by a dedicated machine or component (chip) or a dedicated set of components (chipset), such as an FPGA (Field-Programmable Gate Array) or an ASIC (Application-Specific Integrated Circuit). Generally, the hardware platform of the DISP 500 device comprises electronic circuitry arranged and configured to implement the steps, behaviors, and algorithms described herein in relation to the device (pair, PP 350 processing platform) in question.

Claims

1. Demands Method for executing consensus processes (120) in the creation of a blockchain by a network of node devices, called peers (111, 112, 113, 114), the method comprising the following steps, from a preparatory phase, prior to the creation of the blockchain: - to set up (301) the peer network (111, 112, 113, 114) to carry out (302) simulations under normal operating conditions; - execute a message exchange protocol to reach a consensus in the development of test blockchains; - collect (303), independently for each pair (111, 112, 113, 114), information relating to events occurring in the preparatory phase during message exchanges, and processing of these messages, during executions of the consensus process (120) in the development of test blockchains; - distribute (306) the information collected during the preparatory phase between input data and output data in order to train a machine learning model (200); - train (308), independently for each peer, the machine learning model (200) using the distributed collected information, in order to make predictions of the timing of message exchanges with other peers to execute the consensus process (120) aimed at identifying the peers that are most likely to transmit missing blocks and when; the process further comprising the following steps of a use phase subsequent to the preparatory phase: - set up (401) the peer network (111, 112, 113, 114) for the development of the blockchain, by activating the machine learning model (200) on each peer (111, 112, 113, 114); - execute the message exchange protocol seeking consensus in the development of the blockchain in question; - collect (403), independently by each peer, information relating to events occurring during the usage phase exchanges of messages, and processing of these messages, during executions of the consensus process (120) in the development of the blockchain in question; - inject (404) the information collected into the machine learning model (200) trained, on each peer (111, 112, 113, 114) in a distributed manner, in order to obtain predictions of the timing of message exchanges with the other peers (111, 112, 113, 114) to execute the consensus process (120); and - determine (405) a scheduling of solicitations of said peer to the other peers (111, 112, 113, 114) in the consensus process (120) for the development of the blockchain, according to the predictions obtained.

2. A method according to claim 1, wherein the consensus process is by proof of authority.

3. A method according to claim 1 or 2, wherein, during the preparatory phase, information is collected (303) by execution cycles, information relating to events occurring during the same execution cycle being buffered together, and over N execution cycles per simulation, the first K execution cycles provide the input data to train (308) the machine learning model and the last NK execution cycles provide the output data to train (308) the machine learning model.

4. A method according to any one of claims 1 to 3, wherein the machine learning model (200) has a loss function with weights augmented over the block chain height available to each other pair (111, 112, 113, 114) in time.

5. A method according to any one of claims 1 to 4, wherein the machine learning model (200) is a reinforcement learning model, where each pair (111, 112, 113, 114) is an agent, with a reward function representing a time gain to reach the highest blockchain height, the machine learning model (200) continuing to be trained during the usage phase.

6. A method according to any one of claims 1 to 5, wherein, within each pair (111, 112, 113, 114) during the preparatory phase, the collected data are reorganized by cycle execution cycle, and within each execution cycle, the collected data are grouped chronologically by pair (111, 112, 113, 114) with respect to which at least one event occurred during said execution cycle.

7. A method according to any one of claims 1 to 6, wherein a dynamic selection of predominant data types is carried out (306) among the information collected, by determining one or more data types among the input data that most influence the output data.

8. A method according to claim 7, wherein the dynamic selection is carried out by principal component analysis or by random forest analysis.

9. A method according to claim 7 or 8, wherein the machine learning model is trained and used only with the collected information which is predominantly of the dynamic selection types.

10. Communication system (100) comprising a network of node devices, called peers (111, 112, 113, 114), the peers (111, 112, 113, 114) being configured to execute a consensus process in a blockchain development, the communication system comprising electronic circuitry configured to perform the following steps, from a preparatory phase in which the peer network (111, 112, 113, 114) is set up (301) to carry out (302) simulations under normal operating conditions, prior to the development of the blockchain: - execute a message exchange protocol enabling consensus to be reached in the development of test blockchains;- collect (303), independently for each pair (111, 112, 113, 114), information relating to events occurring in the preparatory phase during message exchanges and message processing during executions of the consensus process in the development of test blockchains; - distribute (306) the information collected during the preparatory phase between input and output data in order to train (308) a machine learning model (200); - train (308), independently for each pair (111, 112, 113, 114), the machine learning model (200) using the; distributed collected information, in order to make predictions of the timing of message exchanges with other peers (111, 112, 113, 114) to execute the consensus process (120) aimed at identifying the peers (111, 112, 113, 114) that are most likely to transmit missing blocks and at what time; the electronic circuitry being further configured to perform the following steps of a usage phase subsequent to the preparatory phase where the peer network (111, 112, 113, 114) is set up (401) for the development of the blockchain: - execute the message exchange protocol seeking consensus in the development of the blockchain in question; - collect (403), independently by each peer (111, 112, 113, 114), information relating to events occurring in the usage phase during message exchanges, and in the processing of these messages, during executions of the consensus process (120) in the development of the blockchain in question; - inject (404) the information collected into the trained machine learning model (200), on each peer (111, 112, 113, 114) in a distributed manner, in order to obtain predictions of the timing of message exchanges with the other peers (111, 112, 113, 114) to execute the consensus process (120); and - determine (405) a scheduling of solicitations of said peer to the other peers (111, 112, 113, 114) in the consensus process (120) for the development of the blockchain, according to the predictions obtained.

Images