Methods and devices in a blockchain network

Abstract

A first network device for use in a blockchain network is described. The first network device comprises: means for, upon executing a first iteration of a consensus protocol involving a second node device (103), in response to a trigger event (3040), obtaining a time interval function of a time interval start trigger event (3040) and a time interval end trigger event (3080), each event being linked to a message of the consensus protocol, and wherein at least the end trigger event (3080) comprises receiving a message from the second node device; means for sending (3083) to the second node device first data representative of the time interval (Delay_102); means for, during a subsequent iteration of the consensus protocol involving the second node device, receiving a message (3140) from the second node device, said message containing second data representative of said time interval (DelayTX_102) from the second node device; means for authenticating the second node device from the second data. A second network device, methods at the first and second network devices and computer readable media having code for carrying out these methods are also described.

Description

Technical Field

[0001] The methods and devices used in blockchain networks are described, particularly for the authentication of nodes in the network. Background Technology

[0002] Blockchain networks require consensus among participating nodes to accept or reject transactions to be added to the blockchain. Consensus protocols may require the exchange of a large number of messages among participating nodes. To ensure the security of these exchanges, node authentication is necessary. While many authentication protocols exist, it may be desirable to have access to lightweight protocols that allow devices with limited processing or power resources to act as nodes in a blockchain network. Summary of the Invention

[0003] The scope of protection is stated in the independent claims. Any embodiments, examples, and features (if any) described in this specification that are not within the scope of protection shall be interpreted as examples or illustrations that help to understand the various embodiments that are within the scope of protection.

[0004] One or more exemplary embodiments relate to a first node device in a blockchain network, which includes:

[0005] - A component for obtaining a time interval function of a time interval start trigger event and a time interval end trigger event in response to a trigger event during the first iteration of the consensus protocol involving a second node device, each event being linked to a message of the consensus protocol, wherein at least the end trigger event includes receiving a message from the second node device;

[0006] - A component for sending first data representing the time interval to the second node device;

[0007] - A component for receiving messages from the second node device during subsequent iterations of the consensus protocol involving the second node device, the messages containing second data from the second node device representing the time interval;

[0008] - A component used to authenticate the second node device based on the second data.

[0009] According to one or more embodiments, the first data represents a plurality of time intervals accumulated during the iteration of the consensus protocol.

[0010] According to one or more embodiments, the first data represents N most recently determined time intervals, where N is an integer greater than 1.

[0011] According to one or more embodiments, the component for authenticating the second device is configured to authenticate the second device if the second data is equal to the first data.

[0012] According to one or more embodiments, the component for authenticating the second device is configured to authenticate the second device if the second data is equal to a hash of the first data.

[0013] According to one or more embodiments, the first node device is a non-primary replica node device, the start triggering event is the reception of a transaction request sharing message received from the primary replica node device, and the end triggering event is the reception of a commit decision message (3080, 3090).

[0014] According to one or more embodiments, the first node device is a primary replica node device, the second node device is a non-primary node device, the start triggering event is the first node device sending a transaction request sharing message, and the end triggering event is the second node device receiving a commit decision message.

[0015] According to one or more embodiments, the consensus protocol is a practical Byzantine Fault Tolerance (P-BFT) consensus protocol.

[0016] One or more exemplary embodiments relate to a method at a first node device in a blockchain network, the method comprising:

[0017] - When implementing a consensus protocol involving a second node device, in response to a triggering event, obtain the time interval between the representative sending a first message to the second node and receiving a second message from the second node device;

[0018] - Send first data representing the time interval to the second node device;

[0019] - During subsequent iterations of the consensus protocol involving the second node device, a third message is received from the second node device, the third message containing second data representing the time interval from the second node device;

[0020] - Authenticate the second node device based on the second data.

[0021] According to one or more embodiments, the first data represents a plurality of time intervals accumulated during the consensus protocol iteration.

[0022] According to one or more embodiments, the first data represents N most recently determined time intervals, where N is an integer greater than 1.

[0023] According to one or more embodiments, if the second data is equal to the first data, then the second device is authenticated.

[0024] According to one or more embodiments, if the second data is equal to the hash of the first data, then the second device is authenticated.

[0025] According to one or more embodiments, the first node is a non-primary replica node, the start triggering event is the receipt of a transaction request sharing message received from the primary replica node device, and the end triggering event is the receipt of a commit decision message from the second node device.

[0026] According to one or more embodiments, the first node is a primary replica node, the start triggering event is the sending of a transaction request sharing message, and the end triggering event is the receiving of a commit decision message from a second node device.

[0027] One or more exemplary embodiments relate to a first node device comprising at least one processor and at least one memory, the memory containing computer program code, wherein the at least one memory and the computer program code are configured, together with the at least one processor, to cause the communication device to at least execute:

[0028] - When implementing a consensus protocol involving a second node device, in response to a triggering event, obtain the time interval between the representative sending a first message to the second node and receiving a second message from the second node device;

[0029] - Send first data representing the time interval to the second node device;

[0030] - During subsequent iterations of the consensus protocol involving the second node device, a third message is received from the second node device, the third message containing second data representing the time interval from the second node device;

[0031] - Authenticate the second node device based on the second data.

[0032] According to one or more embodiments, the first data represents a plurality of time intervals accumulated during the consensus protocol iteration.

[0033] According to one or more embodiments, the first data represents N most recently determined time intervals, where N is an integer greater than 1.

[0034] According to one or more embodiments, the processor, memory, and code are further configured to cause the first node device to authenticate the second device if the second data is equal to the first data.

[0035] According to one or more embodiments, the processor, memory, and code are further configured to cause the first node device to authenticate the second device if the second data is equal to a hash of the first data.

[0036] According to one or more embodiments, the first node is a non-primary replica node, the triggering event is the receipt of a transaction request sharing message, the second message is a preparation decision message, and the third message is a commit message.

[0037] According to one or more embodiments, the first node is a primary replica node, the triggering event is sending a transaction request sharing message, the second message is a preparation decision message, and the third message is a commit message.

[0038] According to any of the above embodiments, the consensus protocol is a practical Byzantine Fault Tolerance (P-BFT) consensus protocol.

[0039] One or more exemplary embodiments relate to a non-transitory computer-readable medium storing computer-executable code that, when executed by at least one processor at a communication device, causes the communication device to perform the steps of a method according to one or more exemplary embodiments disclosed herein.

[0040] One or more exemplary embodiments relate to a second node device in a blockchain network, the second node device comprising:

[0041] - Components used to implement consensus protocols involving the first node device;

[0042] - A component for receiving first data representing a time interval start trigger event and a time interval end trigger event (3080) from the first node device, wherein each event is linked to a corresponding message of the consensus protocol, and wherein at least the end trigger event contains a message sent by the second node device and received by the first device;

[0043] - A second data function for sending the first data during the second iteration of the consensus protocol to allow the first node device to authenticate the components of the second node device.

[0044] According to one or more embodiments of the second node device, the second node device is a primary replica node device, the first node device is a non-primary replica device, and the second node device further includes a component for sending a second data function of the first data as part of a share request message.

[0045] According to one or more embodiments of the second node device, the second node device is a non-primary replica node device, which further includes components for sending a second data function of the first data as part of a preparation decision message.

[0046] According to one or more embodiments of the second node device, the second data is equal to the first data received during one or more iterations of the consensus protocol; or the second data is obtained by applying a hash function to the first data received during one or more iterations of the consensus protocol.

[0047] According to one or more embodiments of the second node device, the second node device further includes a component for checking whether a delay change between the triggering events causes a change in the first data in the same direction.

[0048] One or more exemplary embodiments relate to a second node device in a blockchain network, the second node device comprising:

[0049] - Components used to implement consensus protocols involving the first node device;

[0050] - A component for receiving first data representing a time interval start trigger event and a time interval end trigger event (3080) from a first node device, wherein each event is linked to a corresponding message of the consensus protocol, and wherein at least the end trigger event contains a message sent by the second node device and received by the first device;

[0051] - A second data function for sending the first data during the second iteration of the consensus protocol to allow the first node device to authenticate the components of the second node device.

[0052] According to one or more exemplary embodiments,

[0053] - The second node device is the primary replica node device.

[0054] - The first node device is a non-primary replica device.

[0055] The second node device also includes a component for sending a second data function of the first data as part of a share request message.

[0056] According to one or more exemplary embodiments of the second node device

[0057] - The second node device is a non-primary replica node device.

[0058] The second node device also includes a component for sending a second data function of the first data as part of a preparation decision message.

[0059] According to one or more embodiments of the second node device

[0060] - The second data is equal to the first data received during one or more iterations of the consensus protocol;

[0061] or

[0062] - The second data is obtained by applying a hash function to the first data received during one or more iterations of the consensus protocol.

[0063] According to one or more embodiments of the second node device, the second node device further includes a component for checking whether a delay change between the aforementioned triggering events causes a change in the first data in the same direction.

[0064] One or more exemplary embodiments relate to a method at a second node device in a blockchain network, the method comprising:

[0065] - Implement a consensus protocol involving the first node device;

[0066] - Receive first data from the first node device representing a time interval start trigger event and a time interval end trigger event (3080), wherein each event is linked to a corresponding message of the consensus protocol, and wherein at least the end trigger event contains a message received by the first device from the second node device;

[0067] - During the second iteration of the consensus protocol, a second data function is used to send the first data to allow the second node device to be authenticated by the first node device.

[0068] According to one or more exemplary embodiments of the method at the second node device

[0069] - The second node device is the primary replica node device.

[0070] The first node device is a non-primary replica device.

[0071] The method includes sending a second data function of the first data as part of a share request message.

[0072] According to one or more exemplary embodiments of the method at the second node device

[0073] - The second node device is a non-primary replica node device.

[0074] The method includes sending a second data function of the first data as part of a preparation decision message.

[0075] According to one or more embodiments of the method in the second node device

[0076] - The second data is equal to the first data received during one or more iterations of the consensus protocol;

[0077] or

[0078] - The second data is obtained by applying a hash function to the first data received during one or more iterations of the consensus protocol.

[0079] According to one or more embodiments of the method on a second node device, the method further includes the second node device checking whether a change in the delay between the triggering events causes a change in the first data in the same direction.

[0080] One or more exemplary embodiments relate to a second node device in a blockchain network, the second node device comprising at least one processor and at least one memory, the memory containing computer program code, the at least one memory and the computer program code being configured, together with the at least one processor, to cause the communication device to at least execute:

[0081] Implement a consensus protocol involving the first node device;

[0082] First data is received from the first node device representing a time interval start trigger event and a time interval end trigger event (3080), wherein each event is linked to a corresponding message of the consensus protocol, and wherein at least the end trigger event contains a message sent by the second node device and received by the first device.

[0083] During the second iteration of the consensus protocol, a second data function is used to send the first data to allow the second node device to be authenticated by the first node device.

[0084] According to one or more embodiments, the processor, memory, and code are also configured to cause the second device to perform the methods described herein, particularly the methods mentioned above. Brief description of the attached diagram

[0085] Exemplary embodiments will be more fully understood from the detailed description and accompanying drawings provided herein, which are given by way of illustration only.

[0086] Figure 1 This is a diagram illustrating messages exchanged by network nodes according to the blockchain consensus protocol;

[0087] Figure 2 Between the primary node and a given non-primary node Figure 1 A diagram illustrating a subset of the messages;

[0088] Figure 3a and Figure 3bIt refers to the upper and lower parts of a message sequence diagram according to one or more exemplary embodiments;

[0089] Figure 4 This is a diagram illustrating the identification data exchanged between two nodes;

[0090] Figure 5 It is a schematic block diagram of a network device according to one or more exemplary embodiments.

[0091] It should be noted that these figures are intended to illustrate the general characteristics of the methods, structures, and / or materials used in some exemplary embodiments and to supplement the written description provided below. However, these figures are not drawn to scale and may not accurately reflect the exact structural or performance characteristics of any given embodiment, and should not be construed as defining or limiting the range of values ​​or properties covered by the exemplary embodiments. The use of similar or identical reference numerals in the various figures is intended to indicate the presence of similar or identical elements or features. Detailed Implementation

[0092] Various exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, the specific structural and functional details disclosed herein are for the purpose of describing exemplary embodiments only. Exemplary embodiments may be embodied in many alternative forms and should not be construed as being limited to the embodiments described herein. It should be understood that the exemplary embodiments are not intended to be limited to the specific forms disclosed.

[0093] Those skilled in the art will understand that any function, engine, block diagram, flowchart, state transition diagram, and / or diagram herein represents a conceptual view of an illustrative circuit system embodying the principles of exemplary embodiments. Similarly, it should be understood that any flowchart, diagram, state transition diagram, pseudocode, etc., represents various processes that can be represented substantially in a computer-readable medium and executed by a computer or processing device, regardless of whether such a computer or processor is explicitly shown.

[0094] Each described function, engine, block, or step may be implemented in hardware, software, firmware, middleware, microcode, or any suitable combination thereof. If implemented in software, the functions, engines, or blocks of the block diagram and / or flowchart may be implemented by computer program instructions / software code, which may be stored or transmitted through a computer-readable medium, or loaded onto a general-purpose computer, special-purpose computer, or other programmable processing device and / or system to produce a machine, such that the computer program instructions or software code executing on the computer or other programmable processing device create components for implementing the functions described herein.

[0095] In this specification, a function block denoted as “a component configured to perform…” (a specific function) should be understood as a function block containing a circuit system suitable for performing or configured to perform a specific function. Therefore, a component configured to perform a specific function does not necessarily mean that such a component performs the function (at a given moment). Furthermore, any entity described herein as a “component” may correspond to or be implemented as “one or more modules,” “one or more devices,” “one or more units,” etc. When provided by a processor, the function may be provided by a single dedicated processor, a single shared processor, or multiple separate processors, some of which may be shared. Furthermore, the explicit use of the terms “processor” or “controller” should not be construed as referring only to hardware capable of executing software and may implicitly include, but is not limited to, digital signal processor (DSP) hardware, network processors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), read-only memory (ROM), random access memory (RAM), and non-volatile memory for storing software. Other conventional or custom hardware may also be included. Their functions can be implemented through program logic operations, through dedicated logic, through the interaction of program control and dedicated logic, or even manually. The specific technology can be selected by the implementer based on a more specific understanding of the context.

[0096] Although flowcharts can describe operations as a sequential process, many operations can be executed in parallel, concurrently, or simultaneously. Furthermore, the order of operations can be rearranged. A process can terminate when its operations are completed, but it may also have additional steps not included in the diagram. A process can correspond to a method, function, procedure, subroutine, etc. When a process corresponds to a function, its termination can correspond to the function returning to the calling function or the main function.

[0097] As disclosed herein, the terms "storage medium," "computer-readable storage medium," or "non-transitory computer-readable storage medium" can refer to any physical medium that can be read, written, or more generally accessed by a computer / processing device. Examples of computer storage media include, but are not limited to, flash drives or other flash memory devices (e.g., memory keys, memory sticks, USB key drives), CD-ROMs or other optical storage, DVDs, disk storage or other magnetic storage devices, solid-state storage, memory chips, RAM, ROM, EEPROM, smart cards, relational database management systems, traditional databases, or any other suitable medium that can be used to carry or store program code (readable by a computer processor) in the form of instructions or data structures. Furthermore, various forms of computer-readable media can be used to transmit or carry instructions to a computer, including routers, gateways, servers, or other transmission devices, wired (coaxial cable, fiber optic, twisted pair, DSL cable) or wireless (infrared, radio, cellular, microwave). Instructions may include code from any computer programming language, including but not limited to assembly, C, C++, Basic, SQL, MySQL, HTML, PHP, Python, Java, JavaScript, etc. Embodiments of computer-readable media include, but are not limited to, both computer storage media and communication media, including any medium that facilitates the transfer of a computer program from one place to another. Specifically, program instructions or computer-readable program code for performing the embodiments described herein may be stored, in whole or in part, temporarily or permanently, on a non-temporary computer-readable medium comprising one or more storage media on a local or remote storage device.

[0098] Furthermore, exemplary embodiments may be implemented via hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented as software, firmware, middleware, or microcode, program code or code segments for performing necessary tasks may be stored in a machine or computer-readable medium (e.g., a computer-readable storage medium). When implemented as software, one or more processors will perform the necessary tasks. For example, as described above, according to one or more example embodiments, at least one memory may include or store computer program code, and at least one memory and computer program code may be configured, together with at least one processor, to cause a network element or network device to perform necessary tasks. Furthermore, the processor, memory, and example algorithms encoded as computer program code act as components for providing or causing the performance of the operations discussed herein.

[0099] A code segment of computer program code can represent any combination of programs, functions, subroutines, routines, modules, software packages, classes, instructions, data structures, or program statements. A code segment can be coupled to another code segment or hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc., can be passed, forwarded, or sent via any suitable technology, including memory sharing, message passing, token passing, network transmission, etc.

[0100] The terms “including” and / or “having” as used herein are defined as including (i.e., open-ended). The term “coupling” as used herein is defined as a connection, although not necessarily a direct connection or a mechanical connection. Terms derived from the word “indicating” (e.g., “indicates” and “indication”) are intended to encompass all the various techniques that can be used to communicate or reference the indicated object / information. Some (but not all) examples of techniques that can be used to communicate or reference the indicated object / information include the communication of the indicated object / information, the communication of an identifier of the indicated object / information, the communication of information used to generate the indicated object / information, the communication of certain parts or parts of the indicated object / information, the communication of certain derivatives of the indicated object / information, and the transmission of certain symbols representing the indicated object / information.

[0101] Although the terms first, second, etc., may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element, without departing from the scope of this disclosure. As used herein, the term "and / or" includes any one and all combinations of one or more of the associated listed terms.

[0102] According to example embodiments, network elements, network devices, data servers, network resource controllers, network apparatuses, clients, routers, gateways, network nodes, computers, cloud-based servers, web servers, application servers, proxies or proxy servers, etc., may be (or include) hardware, firmware, hardware executing software, or any combination thereof. Such hardware may include processing or control circuitry, such as, but not limited to, one or more processors, one or more CPUs, one or more integrated circuits, one or more controllers, one or more ALUs, one or more DSPs, one or more microcomputers, one or more FPGAs, one or more SOCs, one or more PLUs, one or more microprocessors, one or more ASICs, or any other device capable of responding to and executing instructions in a defined manner.

[0103] In this application, the term "circuit system" may refer to one or more or all of the following:

[0104] (a) Hardware circuit implementations only (such as implementations only in analog and / or digital circuit systems), and

[0105] (b) A combination of hardware circuitry and software, such as (if applicable):

[0106] (i) A combination of analog and / or digital hardware circuitry (one or more) and software / firmware, and

[0107] (ii) Any part of a hardware processor (one or more) (including digital signal processors (one or more)) having software, software, and memory (one or more),

[0108] They work together to enable devices such as mobile phones or servers to perform various functions, and

[0109] (c) Hardware circuitry (one or more) and / or processors (one or more), such as microprocessors (one or more) or a portion thereof, which require software (e.g. firmware) to operate, but which may be absent when it does not require software to operate.

[0110] One or more non-limiting exemplary embodiments will now be described within the framework of blockchain replication among peer nodes in a blockchain network. The description of these exemplary embodiments includes references to so-called consortium blockchains using a Practical Byzantine Fault-Tolerant consensus protocol (“P-BFT” protocol). However, the principles disclosed herein can be applied to other types of blockchains besides consortium blockchains, whenever message authentication is required. As non-limiting examples of consensus protocols other than P-BFT, Leaderless Byzantine Fault-Tolerant (LBFT) and Istanbul Byzantine Fault-Tolerant (IBFT) protocols are conceivable.

[0111] A blockchain is a linked list of records or blocks, where each block includes the hash of the previous block, a timestamp, and transaction data, among other things. Blockchains record transactions in a permanent and verifiable manner and are typically maintained by a “blockchain network,” a set of network devices or nodes, each ideally holding a copy of the blockchain. Protocols commonly applied by the nodes define the communication between them and how a block with a new transaction is added to the blockchain after a client device makes a request. New transactions are verified before being accepted into the blockchain. This verification may be based on a consensus protocol, according to which a certain number of nodes must agree on a transaction for it to be accepted. To provide fault tolerance (whether intentional or unintentional), consensus protocols allow nodes to reach a consensus even when some nodes are absent (e.g., when one or more nodes are offline), or when some nodes malfunction or provide inconsistent information (e.g., due to software issues or compromised security). Consortium blockchains (such as P-BFT) provide a decisive way to reach consensus and ultimately achieve state machine replication. Consortium blockchains offer strong security properties and are reasonably cost-effective in terms of i) the amount of information exchanged between peers and ii) computational overhead.

[0112] Figure 1 This diagram schematically illustrates client device 101 and nodes 102, 103, 104, and 105 of a blockchain network, as well as the messages exchanged at different stages of the P-BFT consensus protocol. Nodes in this context are also called "replicas," with the node playing a dominant role in the consensus protocol called the "primary replica," and other nodes called "secondary replicas" or "non-primary" replicas. The term "replica" itself refers to state machine replication, which is one of the goals of blockchain technology.

[0113] - Request: The client device sends a transaction request to all nodes.

[0114] - Pre-preparation: A set of requests (received from the client) is ordered by the "master" node (the blockchain node that takes the lead in this round of consensus) and submitted to all other nodes. This is the set of transactions that will be processed in this round of consensus protocol.

[0115] -Preparation: By resubmitting the master node's messages to all nodes, the nodes reach a consensus on the order of the transaction set.

[0116] - Commit: Perform another round of consensus, where nodes finally decide the response that must be sent to the client device. This involves all nodes sending messages to every other node.

[0117] - Response: Each node sends a response to the client, and each response contains the decision made by a majority of the nodes.

[0118] The master node may have been designated as such or selected through a separate process, which will not be detailed here.

[0119] like Figure 1 As the number of nodes increases, the number of messages exchanged during the pre-preparation, preparation, and commit phases can become increasingly important. To prevent nodes from sending false or erroneous messages, authentication should also be performed on each interaction between nodes. Authentication can include, for example, PKI (Public Key Infrastructure), PKI and / or Message Authentication Code (MAC). However, given the large number of messages exchanged, such solutions (meaning the use of cryptographic primitives) can be computationally expensive, potentially limiting the management of P-BFT-based blockchains to devices with sufficient processing power, such as servers, desktop and laptop computers, tablets, and smartphones. However, the processing power of some node devices in a blockchain network may be limited, such as IoT devices like sensors, wearables, and home automation devices. Battery power may also be limited for portable devices. For at least these reasons, limiting the computational burden associated with the authentication steps, allowing more devices to act as nodes in the blockchain network participating in the blockchain protocol, and managing and / or maintaining the blockchain without relying on additional, more powerful devices, seems desirable.

[0120] According to one or more exemplary embodiments, entropy embedded in the network layer is applied to derive an identification factor used to verify the authenticity of messages received between nodes in the blockchain network during the consensus protocol phase. Here, inherently unpredictable network latency is used to generate a random identification factor, which is subsequently used in the authentication process between two devices. As a result, a lightweight consensus protocol is obtained that eliminates the use of standard cryptographic primitives in message authentication after the first cycle. However, this allows devices with limited processing power for the blockchain protocol to participate.

[0121] Figure 2 It is similar to Figure 1 The diagram illustrates a subset of messages, specifically one message used for each phase of the consensus protocol. During the "preparation" phase, node 103 (acting as the master node) sends a message to node 102. Then, during the "preparation" phase, node 102 sends a message back to node 103. Finally, in response, node 103 sends another message to node 102 during the "commit" phase.

[0122] According to one or more exemplary embodiments, a delay is used in the authentication process between the two nodes between the first node receiving a message from the second node, the first node sending a message to the second node, and the first node receiving a message from the second node as a response. Figure 2 In this context, it corresponds to the combination of the preparation and submission phases.

[0123] Figure 3a and Figure 3b (hereinafter collectively referred to as) Figure 3a / b) represents a message sequence diagram illustrating one or more exemplary embodiments of an authentication protocol based on network latency. Figure 3a / b's diagram representation in Figure 1 The exchange occurs between four devices (e.g., client device 101 and three blockchain node devices 102 to 104). Assume device 105 is offline, for example.

[0124] As previously mentioned, client device 101 sends a new transaction request to all other nodes—the corresponding message (referred to as "NewRequest(Tx)" in the flowchart) in... Figure 3a The process is initialized in the "preparation" phase by marking 3010, 3020, and 3030 in / b. Then the preparation phase begins, during which the master node (node ​​103 in this example) shares transaction requests (messages "ShareRequest(Tx)" 3040 and 3050) with the remaining (i.e., non-master) nodes 102 and 104.

[0125] The receipt of ShareRequest messages by non-master nodes 102 and 104 triggers the recording of internal clock values ​​on these nodes ('StartTime_102' and 'StartTime_104' in steps 3041 and 3051, respectively).

[0126] During the "preparation" phase, each of blockchain nodes 102, 103, and 104 then rebroadcasts the transaction to all other blockchain nodes in a further message (referred to as "PrepareDecision(Tx)" in the flowchart). Messages sent by node 102 are messages 3042 and 3043. Messages sent by node 103 are messages 3060 and 3070. Messages sent by node 104 are messages 3052 and 3053.

[0127] During the "commit" phase, each of the blockchain nodes broadcasts another message (referred to in the flowchart as "CommitDecision(Tx)") to all other blockchain nodes. These messages are referred to as 3051, 3052, 3061, 3062, 3080, and 3090, respectively.

[0128] After receiving the "CommitDecision(Tx)" message from the master node, each node has received at least two messages (i.e., PrepareDecision and CommitDecision messages) from each of the other nodes. Non-master nodes 102 and 104 record their respective internal clock values ​​at steps 3081 and 3091 ("EndTime_102" and "EndTime_104" at steps 3081 and 3091, respectively), and calculate their respective delays Delay_102 and Delay_104 at steps 3082 and 3092, respectively, resulting from the difference in clock values ​​at the start and end times. In the frame of this exemplary embodiment, this delay represents the time interval covering the interaction between the non-master node and the master node during the three-way handshake protocol. Figure 3a In the example frame of / b, this is the delay between receiving the ShareRequest (TX) message from the master node and receiving the CommitDecision (TX) message. Each non-master node sends its delay value to the master node (in the corresponding steps 3083 and 3093, messages "ShareDelay_102" and "ShareDelay_104"). Non-master nodes also store their delay values. The master node stores the delay value along with the identifier of the node that provided the delay value so that it can obtain the correct delay value for future communication with that particular node.

[0129] According to a variant embodiment, standard cryptographic primitives are used for authentication during the first cycle between the two nodes.

[0130] According to a variant embodiment, the delay is obtained from the corresponding timers that start and stop at steps 3041, 3051, 3081, and 3091, respectively.

[0131] According to a variant embodiment, the start of the delay is triggered by the node somewhere between the node receiving the ShareRequest(TX) message and the node sending the PrepareDecision(TX) message; that is, it does not need to fall exactly on the receipt of the ShareRequest(TX) message, but is linked to that receipt. The exact triggering strategy may vary from node to node. A similar approach can be applied to determine the end of the delay, which does not need to fall exactly on the receipt of the CommitDecision(TX) message, but can be determined at a later time.

[0132] All blockchain nodes send responses to the client devices, containing their decisions regarding the transaction request in "Response(TX)" messages 3084, 3094, and 3100.

[0133] When a node receives a new request from a client ("NewRequest(Tx')" messages 3110, 3120, 3130), the master node includes the non-master node's identifier factor in its ShareRequest message ("ShareRequest(Tx', DelayTx)") sent to the given master node for that new transaction Tx'. Figure 3a In the example of / b, the identifier factor is the previously received latency value. Therefore, the master node references the identifier factor received from the given node during a previous consensus protocol cycle. This latency value forms the identifier factor or identifier for the non-master node. The given non-master node performs a check (step 3141 for node 102 or step 3151 for node 104) to determine whether the latency value received from the master node is the same as its latency value in memory. If this is the case, the master node is authenticated, and the consensus protocol is followed by the non-master node. Otherwise, the consensus protocol is aborted by the non-master node.

[0134] Despite Figure 3a This is not shown in / b, but the master node can include the corresponding identification factor of the non-master nodes in any message it sends to these non-master nodes, not just ShareRequest messages, to allow the non-master nodes to authenticate each message.

[0135] According to one or more embodiments, the identification factor used by a node to authenticate another node with which it communicates can be a function of more than one latency value. For example, the identification factor can be a function of latency values ​​accumulated over multiple communication cycles or consensus protocol cycles. As a non-limiting example, N latency values ​​can be accumulated in a sliding window, where N is an integer equal to or greater than 1. The authentication node (i.e., in...) Figure 3a In the example of / b, the non-master node will still send only one delayed value to the node to be authenticated in each "preparation" and "commit" phase cycle (i.e., Figure 3a (The master node in the example of / b). Both nodes accumulate latency values ​​in the same way. This enhances security because eavesdropping devices need to be able to perform the same accumulation over multiple consensus protocol cycles.

[0136] N delay values ​​can be stored in matrix form. Figure 4 An example of such a matrix stored by node 401 is shown, where each row corresponds to a delay value Di generated during period i. In this non-limiting example, each delay value contains 10 bits. Node 401 can be an authenticating node or a node to be authenticated.

[0137] According to a variant embodiment, M delay values ​​are sent by the authenticating node to the node to be authenticated, where M is less than N, and the M delay values ​​are selected according to a scheme known to both nodes.

[0138] According to a variant embodiment, the node to be authenticated sends its entire latency value matrix as an identification factor (i.e., M = N with respect to the previous segment).

[0139] According to a variant embodiment, the node to be authenticated sends a hash of at least one delay value, and the authenticating node compares the received hash with a hash of the same at least one delay value that it has in memory. For example, when considering multiple values, such a hash can be obtained by performing an XOR operation between two or more delay values. Other hash functions are known to those skilled in the art, including hash functions suitable for a single delay value. Sending hash values ​​from the node to be authenticated to the authenticating node reduces the amount of data sent compared to sending one or more delay values ​​or the entire matrix.

[0140] According to one or more embodiments, the node to be authenticated checks whether a change in the time between the start and end of the delay message at the node that triggered the authentication results in a change (i.e., an increase or decrease) in the delay value Di obtained by the node to be authenticated in the same direction. For example, the node to be authenticated may specifically delay sending the commit decision message to create such a change.

[0141] although Figure 3a / b's message sequence graph focuses on authentication between master nodes and non-master nodes, but similar protocols can be applied to interactions between any pair of nodes to provide authentication.

[0142] For example, when considering two non-master nodes, the start of network latency at one or both of these nodes can be linked to receiving a ShareRequest(TX) message from the master node, and the end of latency at one node can be linked to receiving a CommitDecision(TX) message from the other node. When the node determining the network latency is the master node itself, the start of the time interval can, for example, be linked to the master node that sent the ShareRequest(TX) message.

[0143] Although these protocols themselves are not the same as the three-way handshake protocol described in conjunction with Figure 3, since three devices are involved, the start and end of the time interval are derived in a similar manner. Once the delay is determined, a ShareDelay(TX) message for the above situation can be sent after the "Commit" phase, as shown in the example in Figure 3. A node that has already received a ShareDelay(TX) message from one or more other nodes will be able to include the corresponding identification factor in any message it sends to any of these one or more nodes.

[0144] Figure 5This is a block diagram of a device 500 that can be used to implement a blockchain node device according to an exemplary embodiment. Device 500 includes a printed circuit board 501 on which a communication bus 502 connects a processor 503, random access memory 504, storage medium 511, an interface 505 for connecting a display 506, a series of connectors 507 for connecting user interface devices or modules such as a mouse or touchpad 508 and a keyboard 509, a wireless network interface 510, and a wired network interface 512. Depending on the required functionality, the node device may implement only a portion of the above-described functions. Figure 5 Some modules may be internal or externally connected, in which case they do not necessarily form part of the device itself. For example, display 506 may be a display that is only connected to the device under certain circumstances, or the device may be controlled by another device having a display; that is, such a device does not require a specific display 506 and interface 505. Memory 511 contains software code that, when executed by processor 503, causes the device to perform the methods described herein. Storage medium 513 is a removable device such as a USB flash drive that stores software code that can be uploaded to memory 511.

[0145] Although aspects of this disclosure have been specifically shown and described with reference to the foregoing embodiments, those skilled in the art will understand that various additional embodiments can be contemplated through modifications to the disclosed machines, systems, and methods without departing from the scope of the disclosure. Such embodiments should be understood to fall within the scope of this disclosure as defined by the claims and any equivalents thereto.

Claims

1. A first node device in a blockchain network, comprising: At least one processing core, At least one memory, which includes computer program code, The at least one memory and the computer program code are configured, together with the at least one processing core, to enable the first node device: During the first iteration of the consensus protocol involving the second node device, in response to a triggering event, a time interval function for a time interval start triggering event and a time interval end triggering event is obtained, each event being linked to a message of the consensus protocol, and wherein at least the end triggering event includes receiving a message from the second node device; Send first data representing the time interval to the second node device; During subsequent iterations of the consensus protocol involving the second node device, a message is received from the second node device, the message containing second data representing the time interval from the second node device; The second node device is authenticated based on the second data.

2. The first node device according to claim 1, wherein, The first data represents multiple time intervals accumulated during the iteration of the consensus protocol.

3. The first node device according to claim 2, wherein, The first data represents N most recently determined time intervals, where N is an integer greater than 1.

4. The first node device according to claim 1, wherein the first node device is further configured to authenticate the second node device if the second data is equal to the first data.

5. The first node device according to claim 1, wherein the first node device is further configured to authenticate the second node device if the second data is equal to the hash of the first data.

6. The first node device according to claim 1, wherein the first node device is a non-primary replica node device, the start triggering event is the reception of a transaction request sharing message received from the primary replica node device, and the end triggering event is the reception of a commit decision message.

7. The first node device according to claim 1, wherein, The first node device is a primary replica node device, the second node device is a non-primary node device, the start trigger event is the first node device sending a transaction request sharing message, and the end trigger event is the second node device receiving a commit decision message.

8. A method at a first node device in a blockchain network, the method comprising: During the first iteration of the consensus protocol involving the second node device, a time interval function is obtained for a time interval start trigger event and a time interval end trigger event, each event being linked to a message of the consensus protocol, and wherein at least the end trigger event includes receiving a message from the second node device; Send first data representing the time interval to the second node device; During subsequent iterations of the consensus protocol involving the second node device, a message is received from the second node device, the message containing second data representing the time interval from the second node device; The second node device is authenticated based on the second data.

9. The method of claim 8, wherein the first data represents a plurality of time intervals accumulated during the iteration of the consensus protocol.

10. The method of claim 9, wherein the first data represents N most recently determined time intervals, where N is an integer greater than 1.

11. The method of claim 8, wherein the second node device is authenticated if the second data is equal to the first data.

12. The method of claim 8, wherein the second node device is authenticated if the second data is equal to the hash of the first data.

13. The method of claim 8, wherein the first node is a non-primary replica node device, the start triggering event is the reception of a transaction request sharing message received from the primary replica node device, and the end triggering event is the reception of a commit decision message from the second node device.

14. The method of claim 8, wherein the first node device is a primary replica node, the start triggering event is the sending of a transaction request sharing message, and the end triggering event is the receiving of a commit decision message from the second node device.

15. A second node device in a blockchain network, comprising: At least one processing core, At least one memory, which includes computer program code, The at least one memory and the computer program code are configured, together with the at least one processing core, to enable the first node device: Implement a consensus protocol involving the first node device; First data is received from the first node device representing a time interval start trigger event and a time interval end trigger event, wherein each event is linked to a corresponding message of the consensus protocol, and wherein at least the end trigger event contains a message received by the first node device from the second node device. During the second iteration of the consensus protocol, second data is sent to allow the first node device to authenticate the second node device.

16. The second node device according to claim 15, wherein the second node device is a non-primary replica node device.

17. The second node device of claim 15, further configured to send the second data as part of a preparation decision message.

18. The second node device of claim 15, wherein the second data is equal to the first data received during one or more iterations of the consensus protocol; or the second data is obtained by applying a hash function to the first data received during one or more iterations of the consensus protocol.

19. The second node device of claim 15, further configured to check whether a change in the delay between the triggering events causes a change in the first data in the same direction.

Images