RU2755672C1 - Method for secure storage and updating data in distributed register using quantum communication networks - Google Patents

Abstract

FIELD: computing.

SUBSTANCE: invention relates to the field of computing for data transmission in distributed systems. The effect is achieved through a method for secure distributed storage and updating of data in a distributed ledger based on a quantum communication network, in which all N network nodes, where N>2 are pairwise connected to each other by quantum key distribution devices and store a copy of the distributed ledger, containing the stages at which, using quantum cryptography devices, pairs of symmetric keys between all network nodes are created, the current allowable number of compromised nodes T is recorded in the distributed ledger, a transaction is formed by at least one of the network nodes, and the transaction is broadcast by the node that generated the transaction the rest of the network nodes, at least using the broadcast algorithm on pairwise authenticated messages, or using the broadcast algorithm on pseudosignatures, update their own copies of the registry by the network nodes that have accepted the transaction.

EFFECT: increasing the security of storing and updating data in a distributed ledger.

8 cl, 6 dwg

Description

FIELD OF TECHNOLOGY

[0001] The present technical solution generally relates to the field of data transmission technologies in distributed systems, and more specifically to the secure storage and updating of distributed ledger data in quantum communication networks (quantum cryptography).

LEVEL OF TECHNOLOGY

[0002] Currently, technologies of distributed ledgers, such as blockchain (blockchain, or blockchain), are gaining popularity. Distributed Ledger Technology (DLT) is an electronic database system distributed across multiple network nodes or devices. This technology allows you to record and store information on a network that is both distributed and decentralized. An important feature of DLT is the absence of a central governing body, the sharing and synchronization of information according to the consensus algorithm, and the distribution of this database in different geographic locations.

[0003] DLT has a number of advantages, including a high level of transparency, efficiency, automation (due to the control of the network by the users themselves), no need for intermediaries, third parties or a central regulatory authority, a high level of security due to an innovative storage system for information in distributed the entire network database. It is due to the described advantages that DLT technologies began to be actively implemented in such areas as finance, voting, healthcare, supply chains, agriculture, etc.

[0004] DLT technologies are based on the use of public key cryptography, which is based on the so-called one-way functions, for which it is quite easy to find the function value from a known argument, but the reverse operation is extremely difficult. Based on such functions, the integrity of the database is ensured for all independent users, for example, cryptographic hash functions, electronic digital signatures and other mathematical techniques are used to make it difficult to forge and break this registry.

[0005] In addition, the consensus algorithm is another major component of distributed ledgers for providing secure data updates. A consensus algorithm is a process that is used to reach agreement on a single data value among distributed participants in a network or systems. The nodes of the network reach agreement on the general state of the registry through the use of a special verification mechanism for the proposed updates (mechanisms or algorithms are used that do not allow leading to conflicts in the registry).

[0006] However, with the advent of quantum computers, consensus-building algorithms and digital signature algorithms may be under threat, since such computers allow solving certain mathematical problems (on which classical cryptography is built, among other things), the solution of which was previously not possible with classical computers. ...

[0007] Therefore, the development of technologies for quantum information security and the creation of cryptographically resistant to attacks using a quantum computer algorithms for data transmission and consensus achievement in distributed ledgers are relevant and important problems.

[0008] So, the prior art known technology for updating a distributed ledger in a quantum cryptography network, described in the Chinese patent application No. CN 110602077A (CHANG YAN et al.), Publ. 12/20/2020. This technology describes the possibility of using a quantum communication network to implement anonymous voting using the blockchain and the use of a consensus algorithm to confirm the integrity of the results and collect statistics.

[0009] The disadvantages of this solution can be attributed to its narrow focus (it is used only in the special case of the implementation of a distributed ledger system, namely, only in blockchain technology), which makes it impossible to use it in other distributed ledger systems. In addition, the consensus algorithm in this solution is applicable only when the number of potentially compromised nodes in the entire network is less than one third.

[0010] A common drawback of existing solutions in this area is the lack of a method for updating and securely storing data in a distributed ledger that is resistant to attacks using a quantum computer. In addition, such a method should ensure the security of data integrity for any number of compromised nodes.

ESSENCE OF THE TECHNICAL SOLUTION

[0011] This technical solution is aimed at eliminating the disadvantages inherent in existing solutions known from the prior art.

[0012] The technical problem inherent in the prior art solutions to be solved in this technical solution is to create a new method for securely storing and updating data in a distributed ledger based on a quantum communication network (quantum cryptography).

[0013] The main technical result, which appears when solving the above problem, is to increase the security of storing and updating data in a distributed ledger.

[0014] Another technical result manifested when solving the above problem is the ability to ensure the integrity of the distributed ledger data for any number of compromised nodes.

[0015] The claimed technical results are achieved by implementing a method for secure distributed storage and updating of data in a distributed ledger based on a quantum communication network, in which all N network nodes, where N> 2, are pairwise connected to each other by quantum key distribution devices and store a copy distributed ledger containing the stages at which:

a) create, using quantum cryptography devices, a pair of symmetric keys between all nodes of the network;

b) record the current admissible number of compromised nodes T in the distributed ledger;

c) form, at least one of the network nodes, a transaction;

d) broadcast by the node that generated the transaction, the specified transaction to the rest of the network nodes, using at least one of the following algorithms:

• using the broadcasting algorithm on pairwise authenticated messages, if the current admissible number of compromised nodes T is less than the threshold value T _crit , or

_{• using the broadcasting algorithm on pseudo-signatures} , if the current admissible number of compromised nodes is greater than T or equal to the admissible threshold value T crit;

f) update their own copies of the ledger by the hosts that accepted the transaction in step d).

[0016] In one particular implementation, the threshold value of the allowable number of compromised nodes T _crit is the number of nodes equal to one third of the total number of nodes.

[0017] In another particular implementation, the broadcast algorithm for pairwise authenticated messages is a broadcast algorithm comprising the steps of:

• send a message with a transaction by the node that generated the transaction to the rest of the network nodes together with the corresponding imitation insert;

• two empty sets of transactions are initialized by each recipient of a transaction;

• each of the receiving nodes checks the imitation insert for the received transaction and, if the verification is successful, save a copy of the received transaction to the first set of transactions, and forward the message with the transaction to the rest of the network participants, except for the sending node, adding a transaction receipt token to it, and also own imitation insert;

• upon receipt of a transaction with one or more non-recurring tokens and an imitation insertion, the imitation insertion is checked, and, if the verification is successful, the transaction is saved together with the received receive tokens into the first set of transactions, and this transaction is sent along with the added own receive token to the existing ones. tokens and the corresponding imitation insertion to all nodes of the network, except for the node that generated this transaction, and the nodes of the network, whose tokens were contained in the received message;

• repeat the forwarding of transactions, described in the previous step, until the forwarded messages with transactions contain T tokens;

• transfer all transactions with T tokens to the second set of transactions;

• for each possible sequence of tokens X _K from K tokens, where K sequentially takes values from T-1 to 0, form a transaction with a sequence of tokens X _K in the second set of transactions as a transaction that occurs most frequently in a subset of transactions from a transaction with a sequence of tokens X _{K of the} first set and transactions with K + 1 tokens of the second set, in which the first K tokens coincide with X _K ;

• accept a tokenless transaction from the second set of transactions.

[0018] In another particular implementation, the impersonation is calculated based on a (almost-) strictly universal family of 2nd order functions and a pair of symmetric keys distributed between the sending node of the message and the corresponding receiving node.

[0019] In another particular implementation, the pseudo-signature broadcasting algorithm is a broadcasting algorithm comprising the steps of:

• the node that generated the transaction generates at least one secret pseudo-signature key and a set of corresponding verification keys for the rest of the network nodes,

• generate by the rest of the network nodes at least two secret pseudo-signature keys and a set of corresponding verification keys for at least all other network nodes, except for the node that generated the transaction;

• generate an empty array for new transactions by the rest of the network nodes; a message containing a transaction signed with a pseudo-signature generated using the secret key of the specified node is broadcast by the node that generated the transaction to the rest of the network nodes;

• each of the nodes that received the message with the transaction verify a pseudo-signature, and, if the verification is successful, add the transaction to their array of new transactions;

• each of the nodes that received the message verified in the previous step sign the specified message with an additional pseudosignature created using their first private pseudo-signature key;

• broadcast the message signed at the previous step with the transaction to the rest of the network participants;

• if after the time required for sequential transmission of messages to the number of network nodes T + 1, all transactions in the set of transactions of each node are identical, then this transaction is accepted by this network node.

[0020] In another private implementation, each node, upon receipt of a message with a transaction and a verified set of pseudosignatures, checks whether this transaction is in its array of new transactions, and if the received transaction is not in the array, then the specified node forwards the received message with a new a transaction to all other network participants, signing it with their second secret pseudo-signature key, and also completes the exchange of messages and does not accept any transaction within this broadcast protocol.

[0021] In another particular implementation, pairwise symmetric keys distributed among all network nodes are used to generate private keys and a set of pseudo-signature verification keys.

[0022] In another particular implementation, pairwise symmetric keys are generated using quantum cryptography devices.

DESCRIPTION OF DRAWINGS

[0023] Features and advantages of the present invention will become apparent from the following detailed description of the invention and the accompanying drawings, in which:

[0024] FIG. 1 illustrates a general scheme for constructing a distributed ledger based on a quantum communication network.

[0025] FIG. 2 illustrates a block diagram of a method for securely updating and storing data in a distributed ledger.

[0026] FIG. 3 illustrates an example of the implementation of the broadcast algorithm on pairwise authenticated messages.

[0027] FIG. 4A-4B illustrate an example implementation of a pseudo-signature broadcast algorithm.

[0028] FIG. 5 illustrates a general view of a computing device.

CARRYING OUT THE INVENTION

[0029] The claimed solution provides the ability to securely store and update data in a distributed ledger for any number of potentially compromised network nodes due to a new algorithm for reaching consensus between nodes. Also, this solution protects the network from attacks using quantum computers.

[0030] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the various embodiments of the claimed technical solution. However, it will be apparent to a person skilled in the art that various embodiments of the present technical solution may be practiced without some of these specific details. The following description provides only exemplary embodiments and is not intended to limit the scope or applicability of the disclosure. It should also be appreciated that the elements of the claimed solution can be implemented in practice in a variety of ways in addition to the specific details set forth in this document.

[0031] The claimed technical solution can be implemented using standard computing devices currently known in the prior art, for example, using a computer, smartphone, tablet, server and any other device that provides the execution of the required program logic.

[0032] FIG. 1 is a general diagram of a network 100 for implementing a method for securely updating and storing data in a distributed ledger.

[0033] The specified network 100 can consist of two levels, for example, the first level 105 - can represent a fully connected network for generating symmetric keys using quantum key distribution (QKD, from English. Quantum key distribution / QKD). The specified level 105, in turn, may contain QKD devices 106 and quantum channels 107, with the help of which the process of quantum key distribution takes place. As the quantum channels 107 can be used, for example, optical fiber. It should be obvious to a person skilled in the art that the quantum channels required for the operation of the QKD 106 devices can be constructed using any of the methods known in the art using appropriate equipment.

[0034] All generated keys 108 are then sent to the second layer of the network 110, where only classical data is exchanged (messages between network nodes). In this solution, classical data should be understood as data that is transmitted through classical communication channels built on the transfer of information in the form of bits and / or analog signals (radio communication, cable communication channels, etc.). It should be noted that the division of the network 100 into layers can be both logical and physical (as described above) and should not limit the options for implementing the present solution.

[0035] QKD is a key generation method that uses quantum phenomena to ensure the security of the generated keys. This method allows two parties, connected via an open classical communication channel and a quantum communication channel, to create a pair of identical random bit sequences (keys), which are known only to them, and use them in other cryptographic protocols.

[0036] QKD is based on the fundamental laws of quantum mechanics, which state that the process of measuring a quantum system generally changes its state. A third party trying to obtain a key needs to measure the states transmitted over the quantum communication channel, which leads to their change and the appearance of errors. Thus, the use of quantum states makes it possible to detect the fact of interference in the process of information transmission over a quantum channel due to the appearance of errors. If the number of errors is below a certain threshold, then it is possible to generate a key between two users. Otherwise, the private key will not be generated and the key generation protocol is terminated.

[0037] The principle of operation of the method of quantum key distribution can be based on the transmission of single photons, polarized in one of two bases: rectangular or diagonal. The recipient measures the polarization by choosing bases for measurement at random, and records the measurement results and bases. Then the sender and the receiver exchange information about the used bases (but not about the measurement results) over an open channel, and the data received when the bases did not match are discarded.

[0038] As the protocols used for key transmission, for example, BB84 protocol, B92 protocol, E91 protocol, etc. can be used.

[0039] As the quantum cryptography devices 106 in the network 100, for example, quantum cryptography devices from companies such as ID Quantique, QRate, etc. may be used. These devices can consist of such elements (parts) as radiation sources of single photons, photon detectors, quantum generators of random numbers, switches and other necessary elements.

[0040] For a person skilled in the art, it is obvious that any QKD devices known from the prior art can be used to generate keys between all pairs of network nodes.

[0041] Communication network 100 may represent, for example, a telecommunications network and may include computing devices. In private implementations, network 100 may represent a local area network (LAN), a wide area network (WAN), the Internet, a peer-to-peer network, or a combination thereof. Network 100 can represent a wired network, a wireless network, or a combination thereof for distributed communication between computing devices on such a network. Computing devices can be, for example, communication nodes 121, 122, 123, 124. Said nodes can represent servers, cloud servers, computers, mobile computing devices, smartphones, laptops, etc. Computing devices provide the ability to participate as nodes 121, 122, 123, 124 in the distributed network 100 to form the distributed ledger. Nodes 121-124 are configured to interact with other devices on the network 100, and to follow their instructions.

[0042] The term "instructions" as used in this application may refer generally to instructions in a program that are written to perform a specific function, such as generating a transaction, sending and receiving messages and / or transactions, storing a copy of a distributed ledger , signature formation, etc. Instructions can be implemented in a variety of ways, including, for example, object-oriented methods. For example, instructions can be implemented using the C ++ programming language, Java, Python, various libraries (for example, "MFC" - Microsoft Foundation Classes), etc. The instructions that carry out the processes described in this solution can be transmitted over both wired and wireless transmission lines.

[0043] Nodes 121-124, in general, can refer to a separate system (eg, computer, server) that is connected to the network 100 and consists of the specified nodes, each of which and / or part of which is involved in the formation, updating and storage of distributed ledger data. In the example of FIG. 1, each network member corresponds to each node 121-124, however, it will be obvious to a person skilled in the art that a member can correspond to several nodes of the network 100, as well as several participants can be combined into one node. In addition, in one particular embodiment, each node of the network 100 can participate in a consensus (reaching agreement on a single decision by all network participants regarding the data (transactions) that are proposed to update the distributed ledger).

[0044] Returning to FIG. 1, network 100 is a peer-to-peer network of nodes 121, 122, 123, 124, where the nodes are computing devices that participate in the distributed ledger update processes. Node 121, Node 122, Node 123 and Node 124 are connected in pairs and are configured to exchange data and store their own copies of the register. Quantum communication channels, as described above, can be formed on existing communication channels of the network 100 or be isolated and are intended for pairing network nodes and distributing keys between these nodes. As described above, for pairwise distribution of keys between network nodes, quantum cryptography devices and corresponding protocols can be used to ensure unconditional security. In the illustrated example, each of the nodes 121-124 represents a member of the distributed ledger and may execute a set of functions or instructions containing a sequence of actions associated with updating the distributed ledger and interacting with other nodes on the network.

[0045] FIG. 2 shows a flow diagram of a method 200 for securely updating and storing data in a distributed ledger. This method may be performed on the network 100 by means of the elements of the network 100 described above. Formation of a distributed data storage and update system implies the interaction in a network, such as network 100, of a set of independent nodes, such as nodes 121-124, to provide distributed ledger functions. The requirement for the number of network nodes N is the number of nodes N> 2, to ensure the conditions for the formation of a distributed register, and all nodes must be connected in pairs with each other by QKD devices and store a copy of the distributed register.

[0046] At step 201, symmetric key pairs are generated between all nodes in the network. At the specified step 201, all network nodes, pairwise connected to each other using QKD devices, generate symmetric keys. As mentioned above, keys are generated using quantum channels connecting these nodes to each other. This stage guarantees, due to the laws of quantum mechanics, the unconditional safety of the generated keys. Method 200 then proceeds to 202.

[0047] At step 202, the current allowed number of compromised nodes T is recorded in the distributed ledger. The specified parameter T is fixed in the data of the distributed registry at each stage of its updating. The initial allowable number of compromised nodes T in the distributed ledger can be set at the stage of forming the initial state of the ledger ("genesis block") and is determined by the requirements for the future ledger.

[0048] At step 203, a transaction is generated by at least one of the network nodes. The specified transaction is generated by the host to initiate changes to the distributed ledger. The network node forms a transaction containing new and / or changed data of the distributed ledger, and proposes the specified change to all other network nodes (broadcasts the transaction to all other network nodes). A transaction in this solution refers to a section of data that is broadcast to the network.

[0049] At step 204, the node that generated the transaction, the specified transaction is broadcast to the rest of the network nodes using at least one of the following algorithms: using the broadcast algorithm on pairwise authenticated messages, if the current allowable number of compromised nodes T is less than the threshold values of T _crit , or using the broadcasting algorithm on pseudo-signatures, in case the current allowed number of compromised nodes T is greater than or equal to the allowed threshold value T _crit .

[0050] At this step 204, a process of reaching consensus between all nodes of the distributed ledger takes place. To maintain the integrity of the registry, when updating it, all network nodes must either accept the transaction received from the node that initiated the update of the register (the sender) and update, in accordance with the contents of the specified transaction, their own copy of the register, or not accept the transaction if it was not possible to reach consensus on the specified transaction. However, due to the fact that the nodes cannot trust each other and the sender, among other things, to update the distributed ledger, you need to make sure that the sender actually broadcast the same transaction to all other nodes, and not different transactions to each node, and, in If such differences are found, terminate the transaction commit process independently. To meet the above requirements, the present technical solution has implemented the broadcast algorithms described below.

[0051] Consider the broadcasting algorithm on pairwise authenticated messages. The principle of operation of this algorithm is based on the method for solving the problem of Byzantine generals, known from [3]. So, if the current admissible number of compromised nodes T is less than the threshold value T _crit , then the broadcasting algorithm on pairwise authenticated messages is used to reach consensus. As mentioned above, the value of the parameter T can be obtained by each host from the data of the distributed registry. The threshold value of the admissible number of compromised nodes T _crit when choosing a broadcasting algorithm can be a value not exceeding one third of the total number of nodes. The specified threshold value was selected based on the features of the algorithm. The broadcasting algorithm based on pairwise authenticated messages is designed to agree on a single version of a transaction that will be accepted by all network participants.

[0052] To ensure the integrity of the data transmission, the node that generated the transaction (the sender) generates a dummy insert to update the register, and sends the transaction along with the dummy insert to the rest of the network nodes (broadcasts the specified transaction). Imitation insertion ensures the integrity and protection against falsification of the transmitted transaction. Imitation insertion can be generated for each receiving node based on the (almost) strictly universal family of 2nd order functions and a pair of symmetric keys distributed between the sending node of this message and the corresponding receiving node. (Almost-) strictly universal families of second-order functions are described in more detail in the source [1]. Thus, each node in the network receives a version of the transaction from the sender.

[0053] After the nodes receive the sender's transaction, each network node stores the received transaction in its own first set of transactions. A set of transactions can be initialized by nodes on a network in such a node's storage medium. It will be apparent to a person skilled in the art that any number of transaction sets can be generated. The specified set of transactions can represent a file in node memory, a table, a list, etc.

[0054] Before adding the received copy of the transaction, each of the recipient nodes checks the impersonation for the received transaction and, if successful, saves a copy of the received transaction in the first set of transactions generated in the previous step. Then it sends the received transaction to the rest of the network nodes, with the exception of the sending node, adding to it a transaction receipt token, as well as its own imitation insert. The transaction receipt token can be designed to determine the route of the transaction and can be a node identification code in the network, confirming that this node has received the specified transaction.

[0055] Further, all nodes of the network, upon receipt of a transaction with one or more non-recurring tokens and impersonation, check the impersonation, and, if the verification is successful, save the transaction along with the received tokens to the first set of transactions, and transfer this transaction together with a custom receive token added to the previously available tokens and the corresponding impersonation of all nodes in the network, except for the node that generated this transaction and the nodes in the network whose tokens were contained in the received message. This step provides the ability to exchange versions of the sender's transaction between all nodes in the network.

[0056] Repeat the forwarding of transactions described in the previous step until the forwarded transaction messages contain T tokens;

[0057] Transferring all transactions with T tokens to the second set of transactions;

[0058] For each possible sequence of tokens X _K of K non-repeating tokens, where K sequentially takes values from T-1 to 0, form a transaction with a sequence of tokens X _K in the second set of transactions as the transaction most frequently encountered in the subset of transactions from transaction with a sequence of markers X _{K of the} first set and transactions with K + 1 markers of the second set, in which the first K tokens coincide with X _K.

[0059] A token-free transaction from the second set of transactions is received.

[0060] For a clearer understanding of the operation of this algorithm, consider an example of its implementation shown in FIG. 3. This example reflects the principle of the algorithm on the example of a network containing seven nodes connected in pairs to update and store data from a distributed registry.

[0061] We will consider the value of the parameter T = 2, less than one third of the total number of nodes.

[0062] Each of the nodes 301, 302, 303, 304, 305, 306, 307 is a member of a distributed network and can perform functions inherent to such a network, such as forming a transaction, storing a copy of the register, interacting with other network nodes, exchanging symmetric keys, the process of verifying and signing transactions, etc.

[0063] As described above, since there is no trusted authority in a distributed network that can confirm the sender's honesty and store the results of the interaction of network participants, the main task of such a network is to achieve consensus, i.e. reaching agreement on a single solution by all network nodes regarding a certain set of data proposed for entering into a distributed system. Consensus provides reliability in a network involving multiple untrusted nodes (potentially compromised).

[0064] Consider the process of reaching a consensus on the example of these nodes.

[0065] The following example is described with the understanding that the exchange process is complete and secure, i. E. each transaction sent and received by any of the network nodes in the above example contains an imitation insert formed on the basis of a pair of symmetric keys between the sending and receiving nodes, and is also verified and is correct.

[0066] Suppose node 301 has generated a transaction to update the distributed ledger. To update all other network nodes on their own copies of the registry, node 301 broadcasts the transaction to nodes 302, 303, 304, 305, 306, 307, respectively (step 1). For convenience, we will denote a transaction as m. Since nodes 302, 303, 304, 305, 306, 307 cannot be sure that node 301 is an uncompromised node and each of the recipients has the same version of the transaction, each of the recipient nodes creates a set of transactions in local storage and stores there is the version of the transaction from the recipient. Thus, in each of the local set of recipient nodes, there is a copy of the sender's transaction. Let us denote them as m ₁ - a copy of the sender's transaction received by node 302, m ₂ is a copy of the sender's transaction received by node 303, m ₃ is a copy of the sender's transaction received by node 304, m ₄ is a copy of the sender's transaction received by node 305, m ₅ - a copy of the sender's transaction received by node 306, m ₆ is a copy of the sender's transaction received by node 307.

[0067] Next, the versions of the received transactions are exchanged between recipient nodes 302, 303, 304, 305, 306, 307 (step 2). Each of the nodes 302, 303, 304, 305, 306, 307 adds a receive token to the version of the transaction received from the node 301 and sends it to the rest of the nodes on the network. The specified token is used to uniquely identify the forwarding route of the transaction version. After exchanging transaction versions, each of the nodes 302, 303, 304, 305, 306, 307 saves all received versions to a local set of transactions. So, node 302 will contain the following transactions: m ₁ , m ₁₂ , m ₁₃ , m ₁₄ , m ₁₅ , m ₁₆ , where m ₁₂ , m ₁₃ , m ₁₄ , m ₁₅ and m ₁₆ , the versions of the transactions received by the nodes 303, 304, 305, 306 and 307, respectively, and sent by the indicated nodes to node 302. Similarly, node 303 will contain the following transactions: m ₂ , m ₂₁ , m ₂₃ , m ₂₄ , m ₂₅ , m ₂₆ , node 304 will contain the following transactions: m ₃ , m ₃₁ , m ₃₂ , m ₃₄ , m ₃₅ , m ₃₆ , node 305 will contain the following transactions: m ₄ , m ₄₁ , m ₄₂ , m ₄₃ , m ₄₅ , m ₄₆ , node 306 will contain the following transactions: m ₅ , m ₅₁ , m ₅₂ , m ₅₃ , m ₅₄ , m ₅₆ , node 307 will contain the following transactions: m ₆ , m ₆₁ , m ₆₂ , m ₆₃ , m ₆₄ , m ₆₅ .

[0068] At the next step (step 3) of the specified broadcasting algorithm, the network nodes, when receiving a transaction with one or more non-repeating tokens, forward this transaction, adding their own receiving token to the previously available tokens, to all network nodes, except for the node that generated this transaction. and hosts whose tokens were contained in the received message. The specified forwarding of transactions will continue until the forwarded transactions contain T = 2 tokens.

[0069] Thus, the local set of transactions of node 302 will contain the following transactions: m ₁ , m ₁₂ , m ₁₃ , m ₁₄ , m ₁₅ , m ₁₆ , m ₁₂₃ , m ₁₂₄ , m ₁₂₅ , m ₁₂₆ , m ₁₃₂ , m ₁₃₄ , m ₁₃₅ , m ₁₃₆ , m ₁₄₂ , m ₁₄₃ , m ₁₄₅ , m ₁₄₆ , m ₁₅₂ , m ₁₅₃ , m ₁₅₄ , m ₁₅₆ , m ₁₆₂ , m ₁₆₃ , m ₁₆₄ , m ₁₆₅ , where m ₁₂₃ , For example, a transaction received by node 303 from node 301 and sent to node 304, which in turn sent it to node 302, m ₁₂₄ is a transaction received by node 303 from node 301 and sent to node 305, which in turn sent it to node 302, m ₁₃₂ is a transaction received by node 304 from node 301 and sent to node 303, which in turn sent it to node 302, and so on.

[0070] The rest of the nodes of the network - 303, 304, 305, 306, 307 - will contain sets of transactions received in a similar way as node 302.

[0071] After the formation of the specified local sets of transactions by each node of the network, an independent selection of the transaction occurs, based on which the copy of the distributed ledger in the node will be updated.

[0072] To do this, each node 302, 303, 304, 305 transfers all transactions with T = 2 tokens to a second local set of transactions. Consider this operation using the example of node 302. So, node 302 transfers transactions with the following markers: m ₁₂₃ , m ₁₂₄ , m ₁₂₅ , m ₁₂₆ , m ₁₃₂ , m ₁₃₄ , m ₁₃₅ , m ₁₃₆ , m ₁₄₂ , m ₁₄₃ , m ₁₄₅ , m ₁₄₆ , m ₁₅₂ , m ₁₅₃ , m ₁₅₄ , m ₁₅₆ , m ₁₆₂ , m ₁₆₃ , m ₁₆₄ , m ₁₆₅ . These transactions have a non-repeating path, characterized by node markers, through all nodes of the network, except for the sender and directly the node that sent these transactions (node 302).

[0073] Further, each network node, for each possible sequence of tokens X _K from K tokens, where K sequentially takes values from T-1 to 0, forms a transaction with a sequence of tokens X _K in the second set of transactions as a transaction that occurs most frequently in a subset of transactions from a transaction with a sequence of tokens X _{K of the} first set and transactions with K + 1 tokens of the second set, in which the first K tokens coincide with X _K. As a function that performs such comparison and selection, for example, a majority element, etc. can be used. It will be apparent to one of ordinary skill in the art that any function that compares input values and selects one that occurs in most inputs can be used.

[0074] Consider this step for the example of node 302. Consider messages with a T-1 = 1 token. Let us select message m _{12 , with the receiving token of node 303. The subset {m 12} , m ₁₂₃ , m ₁₂₄ , m ₁₂₅ , m ₁₂₆ } will act as a subset of transactions to form a transaction in the second set. Denote the most frequently occurring transaction among this set as the m _'12. Then a second set of transactions entered transaction m _'12 to receive marker assembly 303. A similar procedure is repeated for the other transactions with T 1 = 1 marker: m _13, m _14, m _15, m _16. As a result, the second set of transactions appear related transactions m _'13, m' _14, m _'15, m' _16. Further, for forming a transaction without markers considered subset transaction {m _1, m _'12, m' _13, m _'14, m' _15, m _'16}. As a result, in the second set, transaction m'i is obtained, which does not contain tokens.

[0075] Nodes 303, 304, 305, 306, 307 also perform the specified sequence of actions.

[0076] This step ends with the receipt by each of the network nodes involved in reaching the consensus, a transaction from the second set of transactions that does not contain tokens. This transaction is the result of a consensus.

[0077] Let us now consider in more detail the pseudo-signature broadcasting algorithm. This algorithm ensures consensus at any potential number of compromised nodes, but depends on the generation rate and the number of required keys for pseudo- _{signatures by QKD} devices, so its use is more expedient only in cases where the number of potentially compromised nodes T is greater than the T crit value, which in turn is less or equal to one third of the total number of nodes. For a person skilled in the art, it will be obvious that this algorithm is applicable for any number of compromised nodes and the choice of the broadcasting algorithm is only dictated by the speed of key generation by the QKD devices.

[0078] The pseudo-signature algorithm operates based on specially generated keys. So, to generate a pseudo-signature for a given message, a secret key is required, which only the author of the message possesses. To verify the pseudo-signature of the message, each of the potential recipients uses their own verification key, which must be unknown to the rest of the network participants. The collection of the pseudo-signature generation secret key and the corresponding verification keys will be called the set of pseudo-signature keys. The correctness of the pseudo-signature of the message ensures that the author of the message was the node in possession of the corresponding secret key. The pseudo-signature is one-time, so new keys are needed to generate and verify each new message. Unlike conventional signature algorithms, the pseudo-signature algorithm is information-theoretical and immune to attacks using quantum computers. The specified algorithm is known from the prior art and a more detailed principle of its operation is disclosed in the information source [2].

[0079] To implement the broadcasting algorithm on pseudosignatures, it is necessary to distribute one set of pseudo-signature keys, in which the secret key belongs to the node generating the transaction, and 2 (N-1) sets of pseudo-signature keys, in which each node-recipient of the transaction owns two keys for generating the pseudo-signature.

[0080] Thus, the node that generated the transaction generates at least one secret pseudo-signature key and a set of corresponding verification keys for the rest of the network nodes.

[0081] In turn, the rest of the network nodes generate at least two secret pseudo-signature keys and a set of corresponding verification keys for at least all other network nodes except for the node that generated the transaction. [0082] To generate secret keys and a set of pseudo-signature verification keys, pairwise symmetric keys are used, distributed among all network nodes.

[0083] Next, the node that generated the transaction broadcasts a message containing the transaction, signed with a pseudo-signature, to the rest of the network nodes;

[0084] verifies a pseudo-signature by each of the nodes that received the transaction message, and, if the verification is successful, add the transaction to their array of new transactions;

[0085] each of the nodes that received the message, verified in the previous step, sign the specified message with an additional pseudo-signature created using their first secret key of the pseudo-signature;

[0086] broadcasting the message signed in the previous step with the transaction to the rest of the network participants;

[0087] if, after the time required for sequential transmission of messages to the number of network nodes T + 1, all transactions in the set of transactions of each node are identical, then this transaction is accepted by this network node.

[0088] If in the set of transactions at least one transaction differs, then the network node forwards the received message with a new transaction to all other network participants, signing it with its second secret pseudo-signature key, and also completes the exchange of messages and does not accept any transaction within the framework of this protocol broadcasting. This principle is disclosed in more detail in FIG. 4B.

[0089] Let us consider in more detail the principle of this algorithm using the example of the network shown in FIG. 4A. The specified network in this example consists of five nodes 401, 402, 403, 404, 405, which are members of the distributed ledger and can perform the functions prescribed to them for updating, storing and executing the process of reaching consensus in accordance with the described algorithm. As mentioned above, to implement a pseudo-signature, a node forming a transaction needs a secret key, and each receiving node needs two pseudo-signature generation keys and, accordingly, verification keys for each pseudo-signature generation key.

[0090] As noted above, in order for the broadcast algorithm to work on pseudo signatures, before initiating a registry update, the sending node needs to generate secret and verification keys for pseudo signatures for all nodes participating in the consensus (step 1 and step 2). To generate pseudo-signature keys, a protocol can be used that generates secret keys for each node (one secret key for the sending node, and at least two secret keys for each receiving node) and sets of verification keys for each generated secret key of each node. In the course of this process, the nodes interact with each other in such a way that, as a result of the creation of a set of verification keys, the node signing the transaction with the secret key does not know which verification key is in the particular recipient node. The specified algorithm is known from the prior art and a more detailed principle of its operation is disclosed in the information source [2].

, где верхний индекс ключа показывает номер узла, сообщение которого должно верифицироваться ключом, а нижний индекс показывает номер узла, который совершает верификацию сообщения, которое было отправлено узлом, чей номер находится в верхнем индексе. Аналогичным образом верифицирующие ключи распределяются между остальными узлами сети. Так, узел 403 получает верифицирующий ключ

узел 404 получает верифицирующий ключ

узел 405 получает верифицирующий ключ

[0091] So, in step 1, the node 401, which is the sender in this example, generates its secret key Sk ₄₀₁ , and each receiving node 402-405 generates its own set of verification keys Vk. The secret and verification keys are generated based on pairs of symmetric keys distributed between network nodes using quantum cryptography devices. Thus, each node 402-405 receives its own verification key Vk, which is used to verify the authenticity of the message sent by the node 401 and signed with its secret key. Node 402 receives a verification key

, where the superscript of the key shows the number of the node whose message is to be verified by the key, and the subscript shows the number of the node that verifies the message that was sent by the node whose number is in the superscript. In a similar way, verification keys are distributed among the rest of the network nodes. So, node 403 receives a verification key

node 404 receives a verification key

node 405 receives a verification key

[0092] In the next step of the algorithm (step 2), each receiving node 402-405 generates at least two secret keys and, accordingly, two sets of verification keys for the remaining nodes. These secret keys are designed to uniquely identify and maintain the integrity of the message, which will be further sent by nodes 402-405. Thus, the generation of its own set of secret keys and sets of verification keys for other nodes makes it impossible to change the message received from the sending node by one of the receiving nodes. So, for example, if the receiving node tries to spoof a message with a transaction and signs it with its own key, then any next node to whom the message is forwarded will detect the absence of a previous signature (for example, the sender), and, therefore, will notice the forgery.

, и, соответственно, два набора верифицирующих ключей Vk для всех остальных узлов сети (узлы 403-405). Секретные и верифицирующие ключи узла 402 генерируются таким же образом, как и ключи узла 401. Кроме того, каждый получающий узел 403-405 также генерирует два секретных ключа Sk и

, и два набора верифицирующих ключей Vk. По итогу генерации всеми получающими узлами сети 402-405 собственных секретных ключей Sk и

, а также наборов верифицирующий ключей Vk и дальнейшего обмена верифицирующими ключами Vk между друг другом, каждый узел сети будет иметь следующий локальный набор секретных и верифицирующих ключей: локальный набор ключей узла 402 будет содержать следующие ключи:

, Sk₄₀₂,

,

,

,

,

,

,

, где, соответственно, верифицирующие ключи

,

,

,

,

,

, являются ключами, предназначенными для верификации сообщений, подписанных первым или вторым собственным секретным ключом каждого из узлов 403-405. Локальный набор ключей узла 403 будет содержать следующие ключи:

, Sk₄₀₃,

,

,

,

,

,

,

, локальный набор узла 404 будет соответственно содержать следующие ключи:

, Sk₄₀₄,

,

,

,

,

,

,

, и локальный набор ключей узла 405 будет содержать:

, Sk₄₀₅,

,

,

,

,

,

,

.[0093] So, at the specified step of the algorithm, the node 402 will generate two secret keys Sk ₄₀₂ and

, and, accordingly, two sets of verification keys Vk for all other network nodes (nodes 403-405). The secret and verification keys of the node 402 are generated in the same way as the keys of the node 401. In addition, each receiving node 403-405 also generates two secret keys Sk and

, and two sets of verification keys Vk. As a result of the generation by all receiving nodes of the network 402-405 their own secret keys Sk and

, as well as sets of verification keys Vk and further exchange of verification keys Vk between each other, each network node will have the following local set of secret and verification keys: the local set of keys of node 402 will contain the following keys:

, Sk ₄₀₂ ,

,

,

,

,

,

,

, where, respectively, verification keys

,

,

,

,

,

are keys for verifying messages signed by the first or second own private key of each of the nodes 403-405. The local keyset of node 403 will contain the following keys:

, Sk ₄₀₃ ,

,

,

,

,

,

,

, the local set of node 404 will accordingly contain the following keys:

, Sk ₄₀₄ ,

,

,

,

,

,

,

, and the local keyset of node 405 will contain:

, Sk ₄₀₅ ,

,

,

,

,

,

,

...

[0094] Thus, in the above step 1 and step 2 of the pseudo-signature broadcast algorithm, keys are generated and exchanged to implement the pseudo-signature. For a person skilled in the art, it is obvious that as the number of nodes involved in updating the registry and reaching consensus increases, the number of verification keys will increase in proportion to the number of nodes.

[0095] After generating the required number of keys and exchanging such keys between the network nodes, the node initiating the registry update signs the transaction message with its secret key and broadcasts the specified message to the rest of the network nodes (step 3).

[0096] Consider the specified step 3 on the example of node 401, which in our case is the sender of the message with the transaction. It should be noted that any node in the network can act as the sender of the transaction. Thus, node 401 signs the message with the key Sk ₄₀₁ and broadcasts it to nodes 402-405.

,

,

,

псевдоподпись отправляющего узла, и, в случае успешной проверки, сохраняет полученную транзакцию в собственный локальный массив транзакций. Как упоминалось выше, массив транзакций может храниться в локальном средстве хранения узла.[0097] As indicated above, since nodes 402-405 cannot be sure that node 401 has broadcast the same message to all nodes on the network, we will denote the transaction message offered by node 401 as m _n , where index n characterizes the version of the message received by the n-th node. Thus, node 402 receives message m ₄₀₂ , node 403 receives message m ₄₀₃ , node 404 receives message m ₄₀₄ , node 405 receives message m ₄₀₅ . Further, each of the nodes 402-405 checks with its own verification key

,

,

,

pseudo-signature of the sending node, and, if successful, saves the received transaction to its own local array of transactions. As mentioned above, the array of transactions can be stored in the local storage of the node.

[0098] To achieve consensus between receiving nodes 402-405, a single decision is required on the sender's transaction, i. E. if the sender 401 is honest, then each node 402-405 must receive the same transaction m _n (m ₄₀₂ = m ₄₀₃ = m ₄₀₄ = m ₄₀₅ ), if the sender 401 is compromised and at least one of the versions of transactions m ₄₀₂ , t ₄₀₃ , t ₄₀₄ or t ₄₀₅ is different from the others, then the nodes 402-405 must stop the process of accepting the transaction and complete the algorithm, that is, reach a consensus to terminate the algorithm.

[0099] To do this, at step 4, each of the nodes 402-405 signs with its secret key Sk _n , where n is the node number, its version of the verified message m _n. Thus, at this step, node 402 signs transaction m ₄₀₂ with its first key Sk ₄₀₂ , node 403 signs transaction m ₄₀₃ with its first key Sk ₄₀₃ , node 404 signs transaction m ₄₀₄ with its first key Sk ₄₀₄ and node 405 signs transaction m ₄₀₅ with its first key Sk ₄₀₅ .

,

,

. Также, стоит отметить, что для получения транзакций m₄₀₃, m₄₀₄, m₄₀₅, после их проверки узлом 402 соответствующими верифицирующими ключами, узел 402 также проверяет псевдоподпись узла 401, которая хранится в каждом из указанных сообщений. Такая проверка исключает любую попытку подлога узлом, осуществляющим пересылку транзакции, и сохраняет целостность отправляемого сообщения.[0100] Accordingly, each of the nodes 402-405 then broadcasts its version of the transaction, signed by its secret key to the rest of the network nodes (step 5). In this case, each node receiving a transaction containing a pseudo-signature of another node verifies its authenticity with a verification key. Thus, each of the nodes 402-405 generates the following set of transactions: node 402 will contain the following transactions: m ₄₀₂ , m ₄₀₃ , m ₄₀₄ , m ₄₀₅ . Moreover, transactions t ₄₀₃ , t ₄₀₄ , t ₄₀₅ upon receipt were signed with the keys Sk ₄₀₃ , Sk ₄₀₄ and Sk _405, respectively, and verified for authenticity by the specified node 402 using verified keys

,

,

... It is also worth noting that in order to receive transactions m ₄₀₃ , m ₄₀₄ , m ₄₀₅ , after being verified by node 402 with the appropriate verification keys, node 402 also checks the pseudo-signature of node 401, which is stored in each of these messages. This verification eliminates any attempt at forgery by the forwarding node and preserves the integrity of the message being sent.

[0101] Accordingly, the nodes 403-405 form their local sets of transactions in a similar manner.

[0102] In the last step of the algorithm (step 6), each of the nodes 402-405 compares transactions from a local set of transactions with each other. Moreover, the comparison takes place only after the lapse of the time required for the sequential transmission of messages to the number of network nodes T + 1. So, after making such a comparison, if all transactions in each of the nodes 402-405 are identical, then the nodes 402, 403, 404, 405 receive the initial version of the transaction and update their own copies of the registry and the algorithm ends.

[0103] In one particular embodiment, if at least one version of the transaction in at least one node 402-405 is different from the others, then the algorithm performs a sequence of steps aimed at reaching a consensus that the process of accepting the transaction by all nodes in the network is terminated. These steps are discussed in more detail in FIG. 4B.

[0104] Thus, the above steps of the algorithm (step 1 through step 6) allow reaching a consensus on the transaction proposed for updating the registry, and the use of pseudosignatures built on symmetric keys distributed using quantum cryptography devices provides protection against attacks using quantum computers and makes it impossible to spoof a broadcast message without being detected by other nodes on the network.

[0105] Let us now consider in more detail an example implementation of the algorithm shown in FIG. 4B. The above example reveals the case when the transaction versions of at least one node 402-405 in step 6 differ from the other versions. This example is a special case of the implementation of Fig. 4A, and depicts a communications network in which node 403 could be compromised.

[0106] So, at step 6 of the above algorithm, when it detects in the local set of transactions m ₄₀₂ , m ₄₀₃ , m ₄₀₄ , m ₄₀₅ , for example, node 402, at least one version of a transaction that differs from other transactions, the algorithm goes to step 7. Similarly with node 402, if it detects at least one version of the transaction that is different from the others in any other node 403, 404, 405, the algorithm also goes to step 7.

[0107] Consider step 7 in more detail using the example of node 402, which received from node 403 a version of the message that differs from the versions of nodes 404 and 405 (m ₄₀₂ = m ₄₀₄ = m ₄₀₅ ≠ m ₄₀₃ ). Since the versions of the transactions differ from each other, the node 402 needs to complete the algorithm and not accept the specified transaction; nodes 403-405 could potentially receive local sets of transactions where all transactions would be the same.

транзакцию m₄₀₃ и транслирует ее остальным участникам сети. Введем обозначение указанной транзакции как

(транзакция m₄₀₃ подписанная вторым ключом

).[0108] Therefore, in order for the rest of the network nodes to also receive information from the node 402 that the transaction versions are different, the node 402 signs with its second key

transaction m ₄₀₃ and broadcasts it to the rest of the network participants. Let us introduce the designation of the indicated transaction as

(transaction m ₄₀₃ signed with the second key

).

,

и подписывает своим вторым секретным ключом

,

указанную верифицированную транзакцию

, т.к. указанные узлы не могут доверять узлу 402. После подписи узлами 404, 405, каждый из указанных узлов транслирует сообщение всем остальным узлам.[0109] Each of the network nodes verifies transaction m₄₀₃, sent by node 402 with the corresponding key

,

and signs with his second secret key

,

the specified verified transaction

since these nodes cannot trust node 402. After being signed by nodes 404, 405, each of these nodes broadcasts the message to all other nodes.

,

транзакцию

и проверяет, совпадает ли транзакция, полученная от узла 402 и подписанная его вторым секретным ключом, с транзакцией, которую указанные узел 402 также отослал другим узлам. За счет дополнительной пересылки транзакции

узлами, получившими ее от узла 402 (в нашем примере узлы 404, 405), указанные узлы определяют находится ли узел 402 в сговоре, и, следовательно, честно ли он разослал всем участникам сети транзакцию

.[0110] Next, each receiving node 404, 405 verifies with its key

,

transaction

and checks if the transaction received from node 402 and signed by its second secret key matches the transaction that said node 402 has also sent to other nodes. Due to additional forwarding of the transaction

nodes that received it from node 402 (in our example, nodes 404, 405), these nodes determine whether node 402 is in collusion, and, therefore, whether it honestly sent a transaction to all network participants

...

[0111] As a result of such transfer and further verification with the corresponding keys, each network node becomes notified, and also confirms, by signing with its second secret key, that during the attempt to update the registry, an attempt was made to spoof the transaction, and, therefore, it is necessary to stop broadcasting and complete algorithm (reach consensus at the end of the algorithm).

[0112] For a person skilled in the art it is obvious that the specified algorithm can be applied to a larger number of compromised nodes.

[0113] Thus, in FIG. 4A to FIG. 4B, a pseudo-signature broadcasting algorithm was disclosed that allows consensus in a network with any number of compromised nodes.

[0114] Next, method 200, after applying one of the broadcast algorithms described above, proceeds to block 205.

[0115] At block 205, the hosts that have accepted the transaction update their own copies of the registry. As a result of broadcasting a transaction using one of the broadcast algorithms, if the nodes have reached a consensus, then all the nodes that have accepted the specified transaction update their own copies of the distributed ledger based on the information contained in the transaction and, therefore, update the state of the distributed ledger.

[0116] Thus, the present application materials describe a secure method for updating a distributed ledger with any number of compromised nodes, resistant to attacks using a quantum computer, which can be used to violate the integrity of data contained in the distributed ledger.

[0117] FIG. 5 illustrates an example of a general view of computing device 500.

[0118] In the General case, the computing device (500) contains one or more processors (501) united by a common bus of information exchange, memory means such as RAM (502) and ROM (503), input / output interfaces (504), devices input / output (505), and a device for networking (506).

[0119] The processor (501) (or multiple processors, multi-core processor, etc.) can be selected from a range of devices currently widely used, for example, manufacturers such as Intel ™, AMD ™, Apple ™, Samsung Exynos ™ , MediaTEK ™, Qualcomm Snapdragon ™, etc. Under the processor or one of the processors used in the device (500), it is also necessary to take into account the graphics processor, for example, NVIDIA GPU or Graphcore, the type of which is also suitable for full or partial execution of the execution of the control module, and can also be used for training and applying machine learning models in various information systems.

[0120] RAM (502) is a random access memory and is intended for storing machine-readable instructions executed by the processor (501) for performing necessary operations for logical data processing. RAM (502), as a rule, contains executable instructions of the operating system and corresponding software components (applications, software modules, etc.). In this case, the available memory of the graphics card or graphics processor can act as RAM (502).

[0121] ROM (503) is one or more persistent storage devices, such as a hard disk drive (HDD), solid state data storage (SSD), flash memory (EEPROM, NAND, etc.), optical storage media ( CD-R / RW, DVD-R / RW, BlueRay Disc, MD), etc.

[0122] Various types of I / O interfaces (504) are used to organize the operation of the components of the computing device (500) and to organize the operation of external connected devices. The choice of the appropriate interfaces depends on the specific version of the computing device, which can be, but are not limited to: PCI, AGP, PS / 2, IrDa, FireWire, LPT, COM, SATA, IDE, Lightning, USB (2.0, 3.0, 3.1, micro, mini, type C), TRS / Audio jack (2.5, 3.5, 6.35), HDMI, DVI, VGA, Display Port, RJ45, RS232ht.h.

[0123] To ensure user interaction with the computing device (500), various I / O means (505) are used, for example, a keyboard, display (monitor), touch display, touch pad, joystick, mouse manipulator, light pen, stylus, touch panel, trackball, speakers, microphone, augmented reality, optical sensors, tablet, light indicators, projector, camera, biometric identification (retina scanner, fingerprint scanner, voice recognition module), etc.

[0124] The networking tool (506) provides data transmission via an internal or external computer network, for example, Intranet, Internet, LAN, and the like. One or more means (506) may be used, but not limited to: Ethernet card, GSM modem, GPRS modem, LTE modem, 5G modem, satellite communication module, NFC module, Bluetooth and / or BLE module, Wi-Fi module, and etc. [0125] The submitted application materials disclose preferred examples of the implementation of the technical solution and should not be interpreted as limiting other, particular examples of its implementation, not going beyond the scope of the claimed legal protection, which are obvious to specialists in the relevant field of technology.

[0126] Modifications and improvements to the above-described embodiments of the present technical solution will be apparent to those skilled in the art. The foregoing description is presented only as an example and does not imply any restrictions for the purpose of implementing other particular embodiments of the claimed technical solution, which does not go beyond the scope of the claimed scope of legal protection. Structural elements, such as microcontrollers, blocks, modules, etc., described above and used in this technical solution, can be implemented using standard electronic components used to create digital integrated circuits or similar solutions that provide the implementation of specified functions with using programming processes.

Sources of information:

1. M.N. Wegman, J.L. Carter. New hash functions and their use in authentication and set equality. // Journal of Computer and System Sciences, Volume 22, Issue 3, June 1981, Pages 265-279

2. Pfitzmann et al. Information-Theoretic Pseudosignatures and Byzantine Agreement for t≥n / 3 // IBM Research Report RZ 2882 (# 90830) 11/18/96

3. Lamport et al. The Byzantine Generals Problem // ACM Transactions on Programming Languages and Systems, Vol. 4, No. 3, July 1982, Pages 382-401.

Claims (30)

1. A method for secure distributed storage and updating of data in a distributed ledger based on a quantum communication network, in which all N network nodes, where N> 2, are pairwise connected to each other by quantum key distribution devices and store a copy of the distributed ledger containing the stages at which : a) create, using quantum cryptography devices, a pair of symmetric keys between all nodes of the network; b) record the current allowed number of compromised nodes T in the distributed ledger; c) form at least one of the network nodes a transaction; d) broadcast by the node that generated the transaction, the specified transaction to the rest of the network nodes using at least one of the following algorithms: - using the broadcasting algorithm on pairwise authenticated messages, if the current admissible number of compromised nodes T is less than the threshold value T _crit , or - using a pseudosignature broadcasting algorithm, if the current admissible number of compromised nodes T is greater than or equal to the admissible threshold value T _crit ; e) updating their own copies of the ledger by the hosts that committed the transaction in step d). 2. The method according to claim 1, characterized in that the threshold value of the allowable number of compromised nodes T _crit is the number of nodes equal to one third of the total number of nodes. 3. The method according to claim 1, characterized in that the broadcasting algorithm for pairwise authenticated messages is a broadcasting algorithm containing the stages at which: - a message with a transaction is sent by the node that formed the transaction to the rest of the network nodes along with the corresponding imitation insert; - two empty sets of transactions are initialized by each recipient of a transaction; - check, by each of the receiving nodes, an imitation insert for the received transaction, and if the verification is successful, save a copy of the received transaction in the first set of transactions, and send the message with the transaction to the rest of the network participants, except for the sending node, adding a transaction receipt token to it, as well as its own imitation insert; - upon receipt of a transaction with one or more non-recurring tokens and imitation insertion, the imitation insertion is checked, and if the verification is successful, the transaction is saved together with the received receive tokens into the first set of transactions, and this transaction is sent along with the added own receive token to the previously available tokens and the corresponding imitation insertion to all nodes of the network, except for the node that generated this transaction, and the nodes of the network, whose tokens were contained in the received message; - repeat the forwarding of transactions described in the previous step until the forwarded messages with transactions contain T tokens; - transfer all transactions with T tokens to the second set of transactions; - for each possible sequence of tokens X _K of K tokens, where K sequentially takes values from T-1 to 0, form a transaction with a sequence of tokens X _K in the second set of transactions as a transaction that occurs most frequently in a subset of transactions from transactions with a sequence of tokens X _{K of the} first set and transactions with K + 1 tokens of the second set, in which the first K tokens coincide with X _K ; - accept a transaction from the second set of transactions that does not contain tokens. 4. The method according to claim 3, characterized in that the simulated insertion is calculated on the basis of a (almost-) strictly universal family of 2nd order functions and a pair of symmetric keys distributed between the sender node of the given message and the corresponding recipient node. 5. The method according to claim 1, characterized in that the broadcasting algorithm on pseudosignatures is a broadcasting algorithm, comprising the stages at which: - generate by the node that generated the transaction, at least one secret pseudo-signature key and a set of corresponding verification keys for the rest of the network nodes, - generate by the rest of the network nodes at least two secret pseudo-signature keys and a set of corresponding verification keys for at least all other network nodes, except for the node that generated the transaction; - the rest of the network nodes generate an empty array for new transactions; a message containing a transaction signed with a pseudo-signature generated using the secret key of the specified node is broadcast by the node that generated the transaction to the rest of the network nodes; - a pseudo-signature is verified by each of the nodes that received a message with a transaction, and if the verification is successful, the transaction is added to its array of new transactions; - each of the nodes that received the message verified in the previous step sign the specified message with an additional pseudo-signature created using their first secret key of the pseudo-signature; - broadcast the message signed at the previous step with the transaction to the rest of the network participants; - if after the time required for sequential transmission of messages to the number of network nodes T + 1, all transactions in the set of transactions of each node are identical, then this transaction is accepted by this network node. 6. The method according to claim 5, characterized in that each node, upon receipt of a message with a transaction and a verified set of pseudosignatures, checks whether this transaction is in its array of new transactions, and if the received transaction is not in the array, then the specified node forwards the received message with a new transaction to all other network participants, signing it with their second secret pseudo-signature key, and also completes the exchange of messages and does not accept any transaction within the framework of this broadcast protocol. 7. The method according to claim 5, characterized in that pairwise symmetric keys distributed between all network nodes are used to generate secret keys and a set of pseudo-signature verification keys. 8. The method according to claim 7, characterized in that pairwise symmetric keys are generated using quantum cryptography devices.

Images