KR102406020B1 - Apparatus and method for processing distributed consensus on decentralized byzantene fault tolerance - Google Patents

Abstract

A decentralized Byzantine error-tolerant distributed consensus apparatus and method are disclosed. A decentralized Byzantine error-tolerant distributed consensus device according to an embodiment of the present invention is a DELEGATE REQUEST message including a first transaction requesting a distributed consensus proposed by a client from consensus candidate nodes of a blockchain. , determine consensus nodes corresponding to a quorum among the consensus candidate nodes as consensus nodes based on the consensus candidate request messages, and give the consensus nodes agreement on the result of determining the consensus nodes. generating a PREPARE message including a second transaction to obtain, sending the prepare message to the consensus nodes, and in response to the prepare message from the consensus nodes, the digital signature of each of the consensus nodes is The distributed agreement is completed by receiving the included consent (COMMIT) messages, and broadcasting a response (REPLY) message, which is the result of verifying the digital signatures included in the consent messages, to the consensus candidate nodes, and the quorum of the agreement is 2f+1 (f is an integer greater than or equal to 1), where f satisfies both the first and second conditions, and the first condition is that the consensus candidate nodes among all nodes of the block chain are p (p is A condition that is satisfied when the first probability that the number of Byzantine nodes to be selected as the consensus candidate nodes exceeds f is less than or equal to a predetermined first reference probability) , and the second condition is a condition satisfied when the second probability that the number of consensus candidate nodes is 3f or less is less than or equal to the second reference probability. At this time, when the number of next consensus candidates is 3f+1 or more, 3f+1 nodes are randomly selected to update the consensus, and when there are 3f or less, it is not updated.

Description

Decentralized Byzantine Error Tolerant Distributed Consensus Apparatus and Method

The present invention relates to blockchain technology, and more particularly, to a BYZANTENE FAULT TOLERANCE (BFT) distributed consensus protocol and message optimization technology of decentralized nodes.

Byzantine fault tolerance (BYZANTENE FAULT TOLERANCE, BFT) is a technique that enables normal operation even if abnormal nodes exist in a distributed environment composed of multiple nodes. The conventional Byzantine error-tolerant distributed consensus method requires O(N ² ) message exchange in the consensus process. The conventional distributed consensus method of the Byzantine error tolerance series has a limitation in increasing the number of nodes participating in the consensus due to the number of messages. In the case of the Tendermint algorithm, it is assumed that the number of nodes participating in the consensus is 101. O(N ² ) message exchange is required in the consensus process, and various studies have been conducted to reduce it. In the case of FastBFT, the number of exchanged messages is reduced to O(N) through message aggregation technology. Also, Zilliqa et al. have prior technologies that reduce the number of messages to O(N) by using multiple signatures. However, while the prior art succeeded in reducing the consensus message to O(N), there is a limitation in that nodes participating in the consensus are fixed and centralized again. Therefore, in the prior art, decentralization of nodes was realized, but O(N ² ) message exchange was required for consensus. Due to this limitation, in the prior art that realizes the decentralization of nodes, a traffic congestion problem may occur when the number of nodes is increased to hundreds or more, so a new consensus method that can reduce the number of consensus messages to O(N) is required.

On the other hand, Korean Patent Application Laid-Open No. 10-2019-0122149 “Method for selecting a consensus node using Nonce and a method and apparatus for generating a block chain using the same” minimizes resource consumption by participating in consensus among all nodes participating in a distributed agreement, Disclosed is a method and apparatus for creating a blockchain that guarantees that more than a certain number of consensus nodes are selected.

An object of the present invention is to provide a distributed consensus method that allows consensus through O(N) message exchange while accepting Byzantine Error Tolerance (BFT) by decentralized nodes.

In addition, an object of the present invention is to provide a fast consensus among a large number of decentralized nodes by lightening the message exchange and enabling fast operation while blocking participation in distributed consensus of unqualified nodes.

A decentralized Byzantine error-tolerant distributed consensus apparatus according to an embodiment of the present invention for achieving the above object includes one or more processors and an execution memory for storing at least one or more programs executed by the one or more processors, The at least one program receives DELEGATE REQUEST messages including a first transaction requesting a distributed consensus proposed by a client from consensus candidate nodes of a blockchain, and based on the consensus candidate request messages to determine consensus nodes corresponding to a quorum of consensus among the candidate consensus nodes as consensus nodes, and include a second transaction for obtaining agreement from the consensus nodes on the result of determining the consensus nodes (PREPARE) generating a message, sending the preparation message to the consensus nodes, and receiving COMMIT messages including digital signatures of each of the consensus nodes in response to the preparation message from the consensus nodes, and Distributed consensus is completed by broadcasting a response (REPLY) message, which is the result of verifying digital signatures included in consent messages, to the consensus candidate nodes, and the quorum of the consensus is 2f+1 (f is an integer greater than or equal to 1), f satisfies both the first condition and the second condition, and the first condition is that the consensus candidate nodes among all nodes of the block chain will be selected with a probability of p (p is a real number greater than or equal to 0 and less than or equal to 1). In this case, it is a condition that is satisfied when the first probability that the number of Byzantine nodes to be selected as the consensus candidate nodes exceeds f is less than or equal to a predetermined first reference probability, and the second condition is that the consensus candidate nodes are This condition is satisfied when the second probability of being less than or equal to 3f is less than or equal to the second reference probability.

At this time, the at least one program receives the consensus candidate request message including information indicating whether each of the all nodes is selected as the consensus candidate node from the all nodes, and receives the consensus candidate request message If the number of transmitted nodes is 3f+1 or more, 3f+1 nodes are selected and determined as the consensus candidate nodes for the next distributed consensus, and when the number of nodes that transmitted the consensus candidate request message is 3f or less, the consensus Candidate nodes may not be updated.

In this case, when the at least one program receives the consensus quorum of the consensus quorum candidate request messages, based on the same f+1 first transactions included in the consensus quorum of the consensus quorum candidate request messages. The second transaction may be determined.

In this case, the at least one program generates first bitmap information corresponding to the first transaction of the consensus candidate nodes and second bitmap information including a result of determining the consensus nodes, and the first bitmap information, the second bitmap information and the second transaction may be generated.

In this case, the consensus nodes may check the validity of the preparation message based on whether the first bitmap information and the second transaction correspond.

In this case, the at least one program generates a first unified public key and a first unified quorum value by integrating public keys and quorum values included in the consensus candidate request messages, respectively, and the first unified public key and the The preparation message may further include a first hash value obtained by hashing the first unified quorum value.

In this case, the consensus nodes generate a second unified public key and a second unified quorum value by integrating the pre-registered public keys and the pre-registered quorum values, respectively, and the second unified public key and the second unified public key The validity of the preparation message may be checked by comparing whether the second hash value obtained by hashing the quorum value is the same as the first hash value.

At this time, when the second hash value and the first hash value are the same, the consensus nodes generate signature values including the first hash value and secret values previously stored in the consensus nodes, and include The consent messages may be generated by including the signature values and adding the electronic signatures based on the signature values.

At this time, the at least one or more programs apply the signature values included in the consent messages, the public keys of the first integrated public key, and the quorum values of the first integrated quorum value to a multi-signature signature value in the form of a tree, The multi-signature may be generated from the digital signatures by integrating the public key of the multi-signature and the quorum value of the multi-signature.

When the verification result of the multi-signature is true, the at least one or more programs may generate the response message including the second transaction and the multi-signature.

In addition, the decentralized Byzantine error-tolerant distributed consensus method according to an embodiment of the present invention for achieving the above object is a decentralized Byzantine error-tolerant distributed consensus method of a decentralized Byzantine error-tolerant distributed consensus device, a block Receives DELEGATE REQUEST messages including a first transaction requesting a distributed consensus proposed by a client from consensus candidate nodes in the chain, and based on the consensus candidate request messages, among the consensus candidate nodes determining consensus nodes corresponding to the consensus quorum as consensus nodes; generating a PREPARE message including a second transaction for obtaining agreement on a result of determining the consensus nodes to the consensus nodes, and sending the preparation message to the consensus nodes and from the consensus nodes In response to the preparation message, consent (COMMIT) messages including electronic signatures of each of the consensus nodes are received, and a response (REPLY) message, which is a result of verifying electronic signatures included in the consent messages, is transmitted to the consensus candidate. Broadcasting to nodes to complete a distributed agreement, wherein the quorum of the consensus is 2f+1 (f is an integer greater than or equal to 1), where f satisfies both a first condition and a second condition, and the first The condition is that when the consensus candidate nodes among all nodes of the blockchain are selected with a probability of p (p is a real number between 0 and 1), Byzantine nodes to be selected as the consensus candidate nodes are f A condition that is satisfied when the first probability to exceed the number is less than or equal to a predetermined first reference probability, and the second condition is satisfied when the second probability that the number of candidate nodes of the consensus is less than or equal to the second reference probability is less than or equal to the predetermined second reference probability. is a condition

In this case, the determining of the consensus nodes includes receiving the consensus candidate request message including information indicating whether each of the entire nodes has been selected as the consensus candidate node from the entire nodes, and the consensus candidate If more than 3f+1 nodes have transmitted the request message, 3f+1 nodes are selected to determine the consensus candidate nodes for the next distributed consensus, and when the number of nodes that transmitted the consensus candidate request message is 3f or less , the consensus candidate nodes may not be updated.

In this case, the determining of the consensus nodes includes, when receiving the consensus quorum of the consensus candidate request messages, equal to f+1 first transactions included in the consensus quorum of the consensus candidate request messages. The second transaction may be determined based on .

In this case, the transmitting of the preparation message generates first bitmap information corresponding to the first transaction of the consensus candidate nodes and second bitmap information including a result of determining the consensus nodes, and The preparation message including bitmap information, the second bitmap information, and the second transaction may be generated.

In this case, in the transmitting of the preparation message, the consensus nodes may check the validity of the preparation message based on whether the first bitmap information and the second transaction correspond.

In this case, in the step of transmitting the preparation message, a first unified public key and a first unified quorum value are generated by integrating public keys and quorum values included in the consensus candidate request messages, respectively, and the first unified public key and a first hash value obtained by hashing the first unified quorum value may be generated.

In this case, in the step of transmitting the preparation message, the consensus nodes generate a second unified public key and a second unified quorum value by integrating the previously registered public keys and the previously registered quorum values, and the second unified public key and the second unified quorum value are generated. The validity of the preparation message may be checked by comparing whether a second hash value obtained by hashing the two unified public keys and the second unified quorum value and the first hash value are the same.

In this case, the step of completing the distributed agreement may include a signature value including the first hash value and secret values previously stored in the consensus nodes when the second hash value and the first hash value are the same in the consensus nodes. The consent messages may be generated by generating the signature values, including the signature values in the preparation message, and adding the electronic signatures based on the signature values.

In this case, the step of completing the distributed agreement includes signing the signature values included in the consent messages, the public keys of the first unified public key, and the quorum values of the first unified quorum value in a tree-type multi-signature, respectively. value, the public key of the multi-signature, and the quorum value of the multi-signature may be combined to generate the multi-signature from the digital signatures.

In this case, the step of completing the distributed agreement may generate the response message including the second transaction and the multi-signature when the verification result of the multi-signature is true.

The present invention can provide a distributed consensus method that enables consensus through O(N) message exchange while accepting Byzantine Error Tolerance (BFT) by decentralized nodes.

In addition, the present invention can provide a fast consensus of a large number of decentralized nodes by lightening the message exchange and enabling fast operation while blocking the participation of unqualified nodes in distributed consensus.

1 is an operation flowchart illustrating a method of decentralized Byzantine error-tolerant distributed consensus according to an embodiment of the present invention.
FIG. 2 is a detailed operation flowchart illustrating an example of the DELEGATE REQEUST step shown in FIG. 1 .
3 is a diagram illustrating a hash chain and a nonce chain according to an embodiment of the present invention.
4 is a diagram illustrating HEIGHT of a block according to an embodiment of the present invention.
5 is a diagram illustrating a distributed consensus protocol according to an embodiment of the present invention.
6 is a diagram illustrating a first process of processing a distributed sum according to an embodiment of the present invention.
7 is a diagram illustrating a second process of processing a distributed sum according to an embodiment of the present invention.
8 is a diagram illustrating a multi-signature according to an embodiment of the present invention.
9 is a diagram illustrating multi-signature partial verification according to an embodiment of the present invention.
10 is a diagram illustrating a multi-signature tree according to an embodiment of the present invention.
11 is a graph showing a Byzantine node distribution according to an embodiment of the present invention.
12 is a graph showing the distribution of Byzantine nodes in various environments according to an embodiment of the present invention.
13 is a diagram illustrating a computer system according to an embodiment of the present invention.

The present invention will be described in detail with reference to the accompanying drawings as follows. Here, repeated descriptions, well-known functions that may unnecessarily obscure the gist of the present invention, and detailed descriptions of configurations will be omitted. The embodiments of the present invention are provided in order to more completely explain the present invention to those of ordinary skill in the art. Accordingly, the shapes and sizes of elements in the drawings may be exaggerated for clearer description.

Throughout the specification, when a part "includes" a certain element, it means that other elements may be further included, rather than excluding other elements, unless otherwise stated.

Hereinafter, preferred embodiments according to the present invention will be described in detail with reference to the accompanying drawings.

1 is an operation flowchart illustrating a method of decentralized Byzantine error-tolerant distributed consensus according to an embodiment of the present invention. FIG. 2 is a detailed operation flowchart illustrating an example of the DELEGATE REQEUST step shown in FIG. 1 .

Referring to FIG. 1 , in the decentralized Byzantine error-tolerant distributed consensus method according to an embodiment of the present invention, the client may first perform a “REQUSET” step in which a client requests a distributed consensus from consensus candidate nodes (S110).

A client (CLIENT) is a subject that generates a REQUEST, and the REQUEST may correspond to a transaction to be processed. The transaction message to be processed may include means for integrity verification, such as a digital signature.

In addition, nodes in the blockchain network according to an embodiment of the present invention may include a plurality of servers.

For example, the plurality of servers may include SERVERs 0 to 3. SERVER 0~3 is a consensus for the block currently being agreed upon. SERVER 0 may consist of 1 unit, but SERVER(1~3) may consist of f units that are at least 1 or more. where f >= 1 . The consensus can be changed every block.

In this case, SERVER 0 may be a main node (sending side server) corresponding to the decentralized Byzantine error-tolerant distributed consensus apparatus according to an embodiment of the present invention.

In this case, SERVERs 1 to 3 may be sub-nodes (receiving server) that receive a request from a client according to an embodiment of the present invention and deliver a DELEGATE REQUEST to SERVER 0.

That is, in step S110, the client may broadcast a REQUEST message including a first transaction requesting distributed consensus to consensus candidate nodes of the block chain.

In addition, the decentralized Byzantine error-tolerant distributed consensus method according to an embodiment of the present invention may perform a "DELEGATE REQUSET" step of receiving consensus candidate request messages (S120).

That is, in step S120, DELEGATE REQUEST messages including a first transaction requesting that the transactions requested for processing by the client be processed from the consensus candidate nodes of the blockchain are received, and the consensus candidate request is received. Based on the messages, consensus nodes corresponding to the consensus quorum among the consensus candidate nodes may be determined as consensus nodes.

At this time, according to an embodiment of the present invention, nodes that have had an opportunity to directly participate in the consensus of a specific HEIGHT block can be referred to as 'CONGRESS', and the minimum number of nodes required for voting among the consensus body is 'QUORUM' ' can be said.

The quorum of the consensus is 2f+1 (f is an integer greater than or equal to 1), where f satisfies both the first condition and the second condition, and the first condition is that the consensus candidate nodes among all nodes of the blockchain are p When selected with a probability of (p is a real number of 0 or more and 1 or less), the first probability that the number of Byzantine nodes to be selected as the consensus candidate nodes exceeds f is less than or equal to a preset first reference probability This condition is satisfied, and the second condition is a second criterion in which the second probability that the consensus candidate nodes are 3f or less is preset when the same consensus candidate nodes are selected with a probability of p (p is a real number between 0 and 1). It may be a condition that is satisfied when the probability is less than or equal to the probability.

For example, n is the total number of nodes, b _p is the ratio of Byzantine nodes among all nodes, b is the number of Byzantine nodes, and p is the probability that a coin will come up heads when a coin is tossed and a head is selected. .

At this time, if n is 1000 and b _p is 0.2 (20% of the total number of Byzantine nodes), b is calculated as 200 (b = n*b _p = 1,000*0.2 = 200).

For example, it is assumed that all participating nodes n toss a biased coin with a probability p of 0.1 each tossing once, and nodes that come up heads are selected as consensus candidates.

At this time, the number of nodes with heads of the coin follows a binomial distribution, so the average is calculated as n*p and becomes 100.

At this time, since there are sufficiently many nodes (more than 30), the probability that a node is selected can approximate a normal distribution by the "central limit theorem", but can accurately follow a binomial distribution.

At this time, if the coin toss performed by each node is independent of each other (the coin tossed by each node is independent if the result of the coin tossed by the previous node is not affected), some of the nodes are divided into groups and they are selected. Only the probability distribution can be calculated separately.

Therefore, among all nodes (n), only the Byzantine nodes (b) each toss a coin with a probability of coming up heads, and the cumulative probability that f or less of k nodes with heads are selected by Equation 1 below: Yes (cumulative probability of a binomial distribution).

In this case, Equation 2 may satisfy the condition that Byzantine nodes toss a coin with a probability of coming up heads p, and the probability that the number of nodes k with heads of the coin exceeds f is less than or equal to P _{max_bzt} .

In this case, it may correspond to 1.1 e-16 = P _{max_bzt} . This value is not a fixed value, and a different value (eg, 5e-9) may be used depending on the system design.

In addition, the condition that the cumulative probability that the number of nodes x with heads that come up heads is 3f or less is less than or equal to P _{min_node} can be expressed as Equation 3 below by tossing a coin of the same probability p by all participating nodes n.

When the total number of participating nodes n is given, p that simultaneously satisfies Equations 2 and 3 can be calculated while increasing the node selection probability. If a node executes a coin toss with the calculated p, and randomly selects 3f+1 nodes from among the nodes that come up heads as a consensus, the probability that the number of Byzantine nodes included in the consensus exceeds f can be maintained below P _{max_bzt} .

For example, let's say total nodes n=1,000 nodes, Byzantine weight bp = 0.2, the number of Byzantine nodes b = n*bp = 1,000*0.2 = 200 nodes, P _{max_bzt} = 1.1e-16, P _{min_node} = 1.0e-6 can At this time, when the node selection probability p is increased from 0 and when calculating p that Equations 2 and 3 are simultaneously satisfied, if Equations 2 and 3 are satisfied at p = 0.1, each node flips a coin to determine whether or not to select To confirm, if the coin tosses of the nodes are independent of each other, the average of the nodes selected from 200 Byzantine nodes can be 20 (since the node selection probability p is 0.1, the average = b*p=200*0.1=20).

In Equation 2, since the probability that the number of nodes with heads out of 200 Byzantine nodes exceeds 30 is very low, it can be assumed that the probability is less than or equal to P _{max_bzt} .

At this time, if all 1,000 nodes toss a coin, the average of nodes that come up heads may be 100.

At this time, if the probability of coming up heads from less than 90 nodes can be calculated to be lower than P _{min_node} or less, all nodes execute a coin toss, and randomly select 91 nodes from among the nodes that come up heads and decide it as a consensus, The probability that the number of Byzantine nodes contained in 91 nodes exceeds 30 is still It may be less than or equal to P _{max_bzt} .

This is because the probability that more than 30 Byzantine nodes will be selected when 200 Byzantine nodes are tossed with a coin toss at a node selection probability of 0.1 is less than _{_} .

That is, all nodes of the block chain according to an embodiment of the present invention can be counted and summed in all cases as to whether the number of Byzantine nodes included in an arbitrary number of nodes obtained by tossing a coin exceeds 33%. have.

At this time, all nodes calculate the number of which the Byzantine maximum value to be selected does not exceed a preset probability, set it as f, which is the number of nodes, and randomly select 3f+1 nodes in an environment where more than 3f+1 total nodes can be selected. As a selection method, a consensus can be selected while maintaining the number of Byzantine nodes at a desired level.

In addition, in step S120, the consensus candidate request message including information indicating whether each of the nodes has been selected as the consensus candidate node is received from all nodes, and the consensus candidate request message is transmitted. When the number of nodes is 3f+1 or more, 3f+1 nodes are selected and determined as the candidate consensus nodes for the next distributed consensus, and when the number of nodes that transmitted the consensus candidate request message is 3f or less, the consensus candidate nodes may not update them.

In this case, in step S120, when receiving the consensus quorum of the consensus candidate request messages, based on the same f+1 number of first transactions included in the consensus quorum of the consensus quorum candidate request messages. A second transaction may be determined.

Step S120 may further include a detailed step of checking the validity of DELEGATE REQUEST messages of consensus candidate nodes that have transmitted consensus candidate request messages as shown in FIG. 2 .

Referring to FIG. 2 , in step S121, a value of Nonce (2N+1) may be checked in the received consensus candidate request messages.

In step S122, it may be checked whether the value obtained by hashing the Nonce (2N+1) value included in the consensus candidate request messages is the same as the Nonce (2N) value of the corresponding consensus candidate node previously registered in the consensus selection process. .

In this case, in step S122, if the nonce(2N+1) value and the nonce(2N) value are not the same, the nonce(2N+1) integrity check may fail (S123).

At this time, in step S124, if the Nonce (2N+1) integrity check is passed, the Hash(msg || Nonce(2N+1)) value is calculated to check the integrity of the pki and Qi registered by the node, It can be compared with the message_digest value received during the consensus selection process.

At this time, in step S124, if the Hash(msg || Nonce(2N+1)) value and the message_digest value do not match, the integrity check failure of pki and Qi registered by the node may occur (S123).

Step S123 accepts the DELEGATE REQUEST of the node only when the integrity check results of steps S122 and S124 are both successful, and either of the integrity checks of steps S122 and S124 fails. In this case, the DELEGATE REQUEST of the corresponding node may not be accepted.

In this case, the integrity check process of step S120 may verify the digital signature included in the DELEGATE REQUEST. However, since it takes about 0.1 seconds to verify one digital signature, when the number of consensus units is increased to several hundred, a delay of tens of seconds occurs in validation. In addition, since a long integrity check time may provide an excuse for a DDoS attack by an attacker, in the present invention, a quick check can be performed through two hash calculations.

At this time, in the integrity check process of step S120, if a continuous hash value is used in the hash chain, it is possible to check whether a man-in-the-middle attack has occurred without a digital signature, thereby minimizing the check cost for validation in the device that has received the DELEGATE REQUEST. can

In this case, the integrity check process of step S120 may simultaneously verify the validity of pki and Qi of the consensus nodes. You can block bogues pki or bogues Qi created by Man in the middle attacker.

In addition, in step S120, when a DELEGATE REQUEST is transmitted from a node other than the consensus candidate node, the message for receiving confirmation of the consensus selection result is the value obtained by hashing the Nonce (2N) of the corresponding node 2N-1 times. (1) It must pass the nonce validation check that must be equal to the value, and the coupon check can be performed to check whether the coupon is smaller than the threshold.

At this time, in step S120, if the check is not passed, the corresponding node may be excluded from the consensus of the next block, and the corresponding situation may be left in the log.

At this time, in step S120, if the remaining consensus is greater than the quorum of the consensus in a situation in which the corresponding node is excluded, normal agreement can be proceeded. may be

In addition, in step S120, when an intermediate attacker (intermediate forwarding node) corrupts and delivers the DELEGATE REQUEST, it is possible to check whether the DELEGATE REQUEST is corrupted through message digest.

The middle attacker intercepts the node's DELEGATE REQUEST and uses a normal nonce (2N), so it may pass the nonce validation and coupon validation.

At this time, the middle attacker will deliver a message that corrupts the original data to the pki or Qi that he created. However, it is impossible for a man-in-the-middle attacker to predict a nonce (2N+1), so it cannot pass the message digest check.

At this time, in step S120, if the message digest check is not passed, the node may be determined as an intermediate attacker and excluded from the consensus, and the corresponding situation may be logged.

At this time, in step S120, if the remaining consensus is greater than the quorum of the consensus in a situation in which the corresponding node is excluded, normal agreement can be proceeded. may be

In addition, the decentralized Byzantine error-tolerant distributed consensus method according to an embodiment of the present invention includes a "PREPARE" step of sending a PREPARE message to the consensus nodes to obtain agreement on the result of determining the consensus nodes. can be performed (S130).

That is, step S130 generates a PREPARE message including a second transaction for obtaining agreement on the result of determining the consensus nodes to the consensus nodes, and transmits the preparation message to the consensus nodes. can

At this time, in step S130, first bitmap information corresponding to the first transaction of the consensus candidate nodes and second bitmap information including a result of determining the consensus nodes are generated, and the first bitmap information , the preparation message including the second bitmap information and the second transaction may be generated.

In this case, in step S130, the consensus nodes may check the validity of the preparation message based on whether the first bitmap information and the second transaction correspond.

In this case, step S130 generates a first unified public key and a first unified quorum value by integrating public keys and quorum values included in the consensus candidate request messages, respectively, and the first unified public key and the first unified public key The preparation message may be generated further including a first hash value obtained by hashing one unified quorum value.

In this case, in step S130, the consensus nodes generate a second unified public key and a second unified quorum value by integrating the previously registered public keys and the registered quorum values, respectively, and the second unified public key The validity of the preparation message may be checked by comparing whether a second hash value obtained by hashing a key and the second unified quorum value is the same as the first hash value.

In addition, in the decentralized Byzantine error-tolerant distributed consensus method according to an embodiment of the present invention, in response to the preparation message from the consensus nodes, COMMIT messages including the digital signature of each of the consensus nodes are received. "COMMIT" step can be performed.

That is, in step S140, in response to the preparation message from the consensus nodes, COMMIT messages including the digital signature of each of the consensus nodes may be received.

At this time, in step S140, when the second hash value and the first hash value are the same in the consensus nodes, the first hash value and the signature values including the secret values previously stored in the consensus nodes are generated, and , including the signature values in the preparation message, and adding the electronic signatures based on the signature values to generate the consent messages.

At this time, in step S140, the signature values included in the consent messages, the public keys of the first unified public key, and the quorum values of the first unified quorum value are respectively converted to a tree-type multi-signature signature value, the The multi-signature may be generated from the digital signatures by integrating the public key of the multi-signature and the quorum value of the multi-signature.

In this case, in step S140, a multi-signature may be generated by integrating the electronic signatures, and a false electronic signature may be excluded from among the electronic signatures by verifying the multi-signature.

At this time, in step S140, in the multi-signature, the tree of signature values, the tree of the first unified public key, and the tree of the first unified quorum value are verified in the order of the tree step from the highest tree step to the lowest tree step. can

At this time, in step S140, if the check result of the values included in the sub-tree step in the current tree step of any one tree among the trees included in the multi-signature is equal to or greater than that of the tree included in the multi-signature, in the sub-tree step of the sub-tree step The included at least one electronic signature may be determined as the false electronic signature.

In addition, the decentralized Byzantine error-tolerant distributed consensus method according to an embodiment of the present invention may perform a "REPLY" step of performing distributed consensus by broadcasting the verification result to candidate nodes.

That is, in step S150, the result of verifying the electronic signatures may be broadcast to the consensus candidate nodes to complete the distributed agreement.

In this case, in step S140, if the verification result of the multi-signature is true, the response message including the second transaction and the multi-signature may be generated.

3 is a diagram illustrating a hash chain and a nonce chain according to an embodiment of the present invention. 4 is a diagram illustrating HEIGHT of a block according to an embodiment of the present invention. 5 is a diagram illustrating a distributed consensus protocol according to an embodiment of the present invention. 6 is a diagram illustrating a first process of processing a distributed sum according to an embodiment of the present invention. 7 is a diagram illustrating a second process of processing a distributed sum according to an embodiment of the present invention. 8 is a diagram illustrating a multi-signature according to an embodiment of the present invention. 9 is a diagram illustrating multi-signature partial verification according to an embodiment of the present invention.

Decentralized Byzantine error-tolerant distributed consensus apparatus and method according to an embodiment of the present invention A distributed consensus subject can be selected.

Referring to FIG. 3 , it can be seen that the process of generating a hash chain (HASH CHAIN) and the process of using the nonce chain (NONCE CHAIN) by extension are shown.

A specific node included in the block chain according to an embodiment of the present invention may disclose 301 (start_height) and 302 (nonce (1)) to use the nonce chain. N is an index value for calculating the nonce index to be used in the nonce chain, and can be obtained by subtracting the start_height value from the current block height value as shown in Equation (4). By calculating N through Equation 4 and continuously using two nonces 303 and 304, security and operation speed can be improved.

Referring to FIG. 4 , it can be seen that an example of the block HEIGHT is shown in detail. If the current block to be agreed to is 402 block HEIGHT, then block 401 represents a block agreed to h-1 HEIGHT, and block 403 is a block to be agreed to h+1 HEIGHT.

In the present invention, in the process of consensus on the current block, registration of the consensus of the next block may be simultaneously performed. For example, if the 402 block consensus registers the 403 block consensus during block consensus, nodes that have obtained the qualification to be included in the 403 block consensus are registered as a 403 block consensus with SERVER 0 of the 402 block during the 402 block consensus period. you can request to be

At this time, as in Equation 5, pki, Qi, (message required for 402 block consensus) may be transmitted together. Here, the subscript i in pki and Qi may mean data generated in one of the consensus bodies (SERVER (0~3)).

Candidate nodes of the consensus are generated by hashing the Nonce (2N) value 303 and the head hash value of the 401 block to check whether the 403 block consensus is selected after calculating N by Equation 2 when the 401 block is REPLYed. An operation can be performed that compares a random value to whether it is smaller than the block consensus selection threshold.

At this time, if the comparison result is true, the candidate nodes of the consensus include the Nonce(2N) value and pki and Qi necessary for the block 403 consensus process to prove to other nodes that they are a node that has been properly selected. As shown in 5, concatenated (msg, message digest) data can be generated and delivered to SERVER 0 of the 402 block consensus.

In Equation 5, || is a concatenate operation operation that concatenates two arguments to create one data, and Hash() may mean a function that generates an arbitrary value by hashing the arguments as a hash function.

SERVER 0 of block 402 may check the validity of the Nonce (2N) of each node through the threshold comparison described above with respect to the received message. All nodes that have passed the validity check of SERVER 0 can become a consensus for block 403.

In order to distinguish the roles of SERVERs (0~3) in the selected 403 block consensus, a coupon can be generated by cutting a part of the Nonce (2N) data transmitted by each node (eg, LSB 32bits).

At this time, the node with the minimum coupon value may be SERVER 0. If there are two or more nodes having the minimum coupon value, the node having the smallest Nonce(1) value 301 of the node may be selected as SERVER 0. In this case, a Nonce(2N-1) or the like may be used instead of the Nonce(1) value 301 as a comparison object. In addition, when a problem occurs in SERVER 0 during consensus and consensus becomes impossible, the node with the smallest coupon except for SERVER 0 may perform a new SERVER 0 role.

A method of transmitting msg and message digest in the process of selecting a consensus for block 403 of FIG. 4 may be performed by FIG. 6, FIG. 7, or a separate process.

Referring to FIG. 4, the 402 block agreements include the REQUEST contents verified in the DELEGATE REQUEST step for the 402 block consensus, their Nonce (2N+1) value 304, and the digital signature value for these messages to SERVER 0. can transmit

For example, the value obtained by hashing the 303 value included in the msg and message digest of the 402 block 2N-1 times should be the same as the 302 value. can transmit At this time, at the time of block 403 consensus, SERVER 0 hashes the 304 values of SERVER 1 to SERVER 3 once, and the value must be the same as the 303 value of SERVER 1 to SERVER 3 stored in block 402.

Referring to FIG. 6 , when agreement on block 402 is currently being made, it can be seen that the agreement information of block 403 is fixed through multiple signatures together with DELEGATE REQUEST.

Referring to FIG. 7 , it can be seen that the consensus is fixed by adding 403 block consensus information to the COMMITed block. Also, a method of selecting and managing the consensus body separately from the block can be used.

Referring to FIG. 5 , it can be seen that blocks are agreed upon through the DELEGATE REQUEST step, the PREPARE step, the COMMIT step, and the REPLY step. It can be seen that the role of each node is indicated on the left side of FIG. 5 . In FIG. 5 , SERVERs 0 to 3 are consensus bodies for blocks currently being agreed upon. SERVER 0 is composed of 1 unit, but SERVERs 1 to 3 are each composed of f units. where f >= 1 . The consensus can be changed every block.

When the 401 block shown in FIG. 3 is REPLY, if the selected 402 block consensus information is included and delivered to the nodes, it is a step of agreeing the 402 block, and according to the system design assumption, according to an embodiment of the present invention The decentralized Byzantine error-tolerant distributed consensus apparatus and method can select any one of SCHEME 1 to 3 to use the consensus and the quorum of the consensus.

SCHEME 1 can fix the number of consensus bodies at 3f+1 and the quorum of consensus at 2f+1.

SCHEME 1 replaces the consensus by randomly selecting 3f+1 nodes among them when the number of nodes requesting the registration of the consensus body is 3f+1 or more, and consensus can be performed by a quorum of 2f+1 consensus among the consensus body. According to Equation 3, the probability of selecting 3f or less nodes is P _{min_node} or less, so the consensus can be replaced with 1-P _{min_node} probability probabilistically, but due to network errors or node malfunctions, the consensus is lower than this. can be replaced. The advantage of SCHEME 1 is that since there are always 3f+1 consensus bodies, there are enough spare nodes to form a consensus quorum of 2f+1, so even if consensus fails, it is easy to reconstruct the consensus quorum by adding these spare nodes. The disadvantage is that the consensus replacement success probability is less than 1-P _{min_node} , so although the probability is low, a situation in which the consensus body is not replaced may occur.

As described above, in SCHEME 1, the quorum of the sum is 2f+1 (f is an integer greater than or equal to 1), where f satisfies both the first condition and the second condition, and the first condition is the entire block chain. When the consensus candidate nodes among the nodes are selected with a probability of p (p is a real number between 0 and 1), the first probability that the number of Byzantine nodes to be selected as the consensus candidate nodes exceeds f is A condition that is satisfied when the first reference probability is less than or equal to a predetermined first reference probability, and the second condition may be a condition that is satisfied when the second probability that the number of consensus candidate nodes is 3f or less is less than or equal to the second reference probability.

For example, n is the total number of nodes, b _p is the ratio of Byzantine nodes among all nodes, b is the number of Byzantine nodes, and p is the probability that a coin will come up heads when a coin is tossed and a head is selected. .

At this time, if n is 1000 and b _p is 0.2 (20% of the total number of Byzantine nodes), b may be 200 (b = n*bp = 1,000*0.2 = 200).

For example, it is assumed that all participating nodes n toss a biased coin with a probability p of 0.1 each tossing once, and nodes that come up heads are selected as consensus candidates.

In this case, an average of 100 nodes may be selected with a probability distribution of a binomial distribution.

At this time, since there are enough nodes (more than 30), the probability that a node is selected can approximate a normal distribution by "central limit theorem", and more accurately approach a binomial distribution.

At this time, if the coin toss performed by each node is independent of each other (the coin tossed by each node is independent if the result of the coin tossed by the previous node is not affected), some of the nodes are divided into groups and they are selected. Only the probability distribution can be calculated separately.

Therefore, among all nodes (n), only the Byzantine nodes (b) each toss a coin with a probability of coming up heads, and the cumulative probability that f or less of the number of nodes k with heads are selected by Equation 1 can be calculated by (Cumulative probability of a binomial distribution).

Equation 2 may satisfy a condition in which the probability that the number of Byzantine nodes selected by a coin toss among the Byzantine nodes is greater than f and the probability of being selected is less than or equal to P _{max_bzt} .

In this case, it may correspond to 1.1 e-16 = P _{max_bzt} . This value is not a fixed value, and a different value (eg, 5*10-9) may be used depending on the system design.

In addition, the condition that the cumulative probability that all participating nodes toss a coin with the same probability p and the number of nodes that came up heads x is 3f or less is less than or equal to P _{min_node} can be expressed as Equation 3 below.

When the total number of participating nodes n is given, p that simultaneously satisfies Equations 2 and 3 can be calculated while increasing the node selection probability. If a node executes a coin toss with the calculated p, and randomly selects 3f+1 nodes from among the nodes that come up heads as a consensus, the probability that the number of Byzantine nodes included in the consensus exceeds f can be maintained below P _{max_bzt} .

For example, let's say total nodes n=1,000 nodes, Byzantine weight bp = 0.2, the number of Byzantine nodes b = n*bp = 1,000*0.2 = 200 nodes, P _{max_bzt} = 1.1e-16, P _{min_node} = 1.0e-6 can At this time, when the node selection probability p is increased from 0 and when calculating p that Equations 2 and 3 are simultaneously satisfied, if Equations 2 and 3 are satisfied at p = 0.1, each node flips a coin to determine whether or not to select When confirmed, if the coin tosses of nodes are independent of each other, the average of nodes selected from 200 Byzantine nodes can be 20 (since the node selection probability p is 0.1).

In Equation 2, since the probability that the number of nodes with heads out of 200 Byzantine nodes exceeds 30 is very low, it can be calculated with a probability of P _{max_bzt} or less.

At this time, if all 1,000 nodes toss a coin, the average of nodes that come up heads may be 100.

At this time, if the probability of coming up heads from less than 90 nodes can be calculated to be lower than P _{min_node} or less, all nodes execute a coin toss, and randomly select 91 nodes from among the nodes that come up heads and decide it as a consensus, The probability that the number of Byzantine nodes included in 91 nodes exceeds 30 may still be less than or equal to P _{max_bzt} .

This is because, at a node selection probability of 0.1, when 200 Byzantine nodes toss a coin, the probability of selecting 30 or more Byzantine nodes is less than P _{max_bzt} .

That is, all nodes of the block chain according to an embodiment of the present invention can be calculated and summed in all cases as to whether the number of Byzantine nodes included in a random number of nodes obtained by tossing a coin exceeds 33%. .

At this time, all nodes calculate the number of which the Byzantine maximum value to be selected does not exceed a preset probability, set it as f, which is the number of nodes, and randomly select 3f+1 nodes in an environment where more than 3f+1 total nodes can be selected. As a selection method, a consensus can be selected while maintaining the number of Byzantine nodes at a desired level.

In SCHEME 2, the number of consensus bodies is 2f+1 or more, and the quorum of consensus can be fixed at 2f+1.

In SCHEME 2, the quorum of consensus is fixed at 2f+1, and if the number of nodes reported as a consensus is 2f+1+β (0≤β≤f) or more, the number of consensus bodies is set to be 2f+1+β and 3f+1 or more. Agreements can be replaced. When SCHEME 2 forms a consensus quorum (2f+1) in the PREPARE and COMMIT stages, consensus can proceed even if up to β nodes do not respond due to network or node failure. That is, in SCHEME 2, if β nodes are included in f nodes that do not respond in 3f+1, consensus can always proceed by a quorum of 2f+1 consensus.

Assuming no network or node failures occur, the probability that consensus is less than 2f+1+β may be less than 1.0e-6. This means that consensus 1 may not change during 1 million rotations of consensus. However, considering f that will not respond due to network or node failure, it is desirable to form a consensus with β large enough. The disadvantage of this method is that if β is small, the possibility of forming a quorum to proceed with consensus is low if consensus fails.

SCHEME 3 can be configured so that the number c of consensus satisfies 2f+1≤c≤3f+1-α, and the quorum of the consensus can be fixed at 2f+1.

If the maximum number of Byzantine nodes that can be included in the randomly selected node is greater than f, SCHEME 3 can obtain the consent of f+α+1 nodes in the PREPARE step to select a consensus body and a quorum for consensus.

SCHEME 3 may assume that the remainder obtained by subtracting f from the maximum number of probabilistically possible Byzantine nodes is α, and in the PREPARE step, it can be assumed that the number of f+α+1 nodes satisfying Equation 6 is obtained instead of f+1. In this case, when c is the number of nodes in the consensus, if c satisfies the condition of Equation 7, fork may not occur.

For example, when f=1 and α=1, Max Bzt=2 and f+α+1=3 according to Equation (6).

Also, the number of consensus candidate nodes may be 3≤c≤3 according to Equation (7). Therefore, if the number of consensus is 3 and the quorum of the consensus is 3, SERVER 0, SERVER1, and SERVER2 can create only one quorum of the consensus, so fork does not occur, but this example can be the same as the BFT consensus.

As another example, if f=3, α=1, and SERVER 0 and SERVER1 group are Byzantine nodes, MaxBzt=f+α=4, f+α+1=5 by Equation 6, so that at least one Normal nodes of may be included. According to Equation 7, the range of the number of consensus candidate nodes may be 7≤c≤9. Since the quorum of consensus for COMMIT (2f+1) is 7, it is necessary to include at least 3 normal nodes excluding 4 Byzantine nodes to satisfy the consensus quorum. therefore. Since two COMMITs cannot be made without including at least one normal node in duplicate, finality can be guaranteed.

Therefore, when the maximum Byzantine node that can be selected probabilistically is less than 2f, SCHEME 3 to which Equations 6 and 7 are applied may be used.

Consensus update does not update if the number of nodes requested as the consensus of the next block is less than 2f+1, and the current block consensus becomes the next block consensus again, or empty agreement may be performed by nodes less than 2f+1. If the number of nodes requested to the next block consensus is 2f+1 or more and less than 3f+1-α, the consensus is updated. If the number of nodes requested to the next block consensus exceeds 3f+1-α, SERVER 0 is 3f+1 -α nodes can be randomly selected and updated.

SERVER 0 can proceed with consensus by reflecting the node's own opinion in the 402 block consensus process. In the present invention, for multi-signature of servers, the EC-Schnorr multi-signature of FIG. 8 may be used.

The decentralized Byzantine error-tolerant distributed consensus according to an embodiment of the present invention consists of REQUEST, DELEGATE REQUEST, PREPARE, COMMIT, and REPLY steps, and each step will be described in detail.

In the REQUEST phase, the consensus is not fixed and reconfigured for every block, so the client can broadcast the REQUEST to all candidate nodes (or servers). Since the consensus is randomly selected, other candidate nodes that have not been selected by the consensus can continue to receive the REQUEST. At this time, all nodes may not receive the REQUEST due to an error, delay, or malicious intent. In general, in the PBFT algorithm, it is assumed that f among 3f+1 nodes do not receive, so that SERVER 3 of FIG. 5 is in a passive state, all operations can be ignored.

In the DELEGATE REQUEST step, the operation of the sending server (SERVER 0~3) and the operation of SERVER0 are explained separately. First, the operation of the sending server will be described.

The consensus candidate nodes according to an embodiment of the present invention may check whether each of the first transactions of the REQUESTs including the first transaction requesting the distributed consensus proposed from the client is abnormal. Upon receiving the REPLY block from SERVER 0 of block 401, the consensus bodies of block 402 can initiate a DELEGATE REQUEST.

Consensus parties can transmit proposed transaction, which are the first transactions that have no abnormality in the above check, to DELEGATE REQUEST and send it to SERVER 0. DELEGATE REQUEST of each server may include Proposed Transaction, Nonce(2(N+1)), Q _i (h+1), pk _i (h+1). Here, the Proposed Transaction may correspond to Transactions (first transactions) determined as normal by each server. nonce(2(N+1)), Q _i (h+1), pk _i (h+1) can be information used for the 402 consensus to become a 403 block consensus again if the 403 block consensus is not changed. have. In addition, all contents including the corresponding message can be added with the digital signature of the sending server. The added digital signature can be used to check the error of the server by checking the digital signature only when there is a problem with the multi-signature of the servers in the COMMIT stage without verifying directly at SERVER 0.

At this time, SERVER 0 receives DELEGATE REQUEST from 2f+1 servers including itself, and when receiving DELEGATE REQUEST from servers as many as 2f+1 individual consensus quorum including itself, these are the consensus nodes corresponding to the consensus quorum. can be determined and the following actions can be performed. At this time, SERVER 0 may continue to receive DELEGATE REQUEST from the remaining servers.

개 또는 f+1 개의 노드가 송신한 transaction 집합을 뽑아 제1 트랜잭션을 기초로 제2 트랜잭션인 Prepared transaction을 결정할 수 있다. 이 때, 완성된 SERVER 0은 Prepared transaction에서 합의 노드들에게 상기 합의 노드들을 결정한 결과를 확인시키기 위해 표 1과 같은 제1 비트맵 정보인 bitmap을 만들고 이를 모든 합의 노드들에 제시하여 SERVER 0 이 거짓으로 제1 트랜잭션을 Prepared transaction을 만들지 못하게 할 수 있다.SERVER 0 is a normal first transaction of the received 2f + 1 DELEGATE REQUEST in proposed transactions.

A prepared transaction, which is a second transaction, can be determined based on the first transaction by extracting a set of transactions sent by 1 or f+1 nodes. At this time, the completed SERVER 0 creates a bitmap that is the first bitmap information as shown in Table 1 and presents it to all consensus nodes to confirm the result of determining the consensus nodes to the consensus nodes in the prepared transaction, so that SERVER 0 is false to prevent the first transaction from creating a prepared transaction.

Server bit map 0 One 2 transaction0 One 0 One transaction1 One One One transaction2 0 One One transaction3 0 * 0 transaction4 One One 0 transaction5 One 0 One transaction6 0 One One transaction7 0 * 0 transaction8 0 0 * transaction9 One One One

It can be seen that Table 1 shows an example of the Proposed Transaction (More then f+1 servers DELEGATE REQUEST) bitmap, which is the first bitmap information corresponding to the second transaction.

개 노드에서 각각 유효성 검사를 통과한 트랜잭션의 집합이며, 제1 비트맵 정보인 Proposed Transaction bitmap과 SERVER 0의 전자서명에 의해 내용을 데이터 전달 중간에 공격자가 내용을 바꿀 수 없는 상태로 만들 수 있다.SERVER 0 may prepare a PREPARE message including the second transaction and first bitmap information (Prepared transaction, Proposed Transaction bitmap). SERVER 0 is prepared transaction, Proposed transaction bitmap is minimum

It is a set of transactions that have passed each validation check in each node, and by the first bitmap information, the Proposed Transaction bitmap and the digital signature of SERVER 0, an attacker can make the contents in a state that cannot be changed in the middle of data transmission.

For example, SERVER 0 can assume a situation in which 10 transactions originating from the client are distributed to 4 servers as shown in Table 2.

It can be seen that Table 2 shows the valid transaction requests of the clients received by each server.

number of transactions server0 0, 1, 4, 5, 9 server1 1, 2, 3, 4, 6, 7, 9 server2 0, 1, 2, 5, 6, 8, 9 server3 0, 2, 3, 5, 7

이상이 (이 예의 경우

로 가정) 동시에 DELEGATE REQUEST 한 트랜잭션 번호는 표 3과 같이 "0,1,2,4,5,6,9"가 될 수 있다.At this time, assuming that SERVER 3 is in a passive state and does not perform any action, SERVER 0 is among the transactions proposed by SERVERs (0, 1, 2).

More than that (in this example

) The transaction number that has been DELEGATE REQUEST at the same time can be "0,1,2,4,5,6,9" as shown in Table 3.

number of transactions Prepared transaction 0, 1, 2, 4, 5, 6, 9

It can be seen that Table 3 shows an example of the prepared transaction, which is the second transaction.

이상인 것들은 서버들 중에

개 이상이 동시에 DELEGATE REQUEST 한 것을 의미하며,

미만인 비트의 트랜잭션은 동의를 얻는데 실패한 것을 표시하는 것을 알 수 있다. DELEGATE REQUEST 서버는 최소 한 개의 트랜잭션을 제안해야 유효한 DELEGATE REQUEST 서버로 카운트 될 수 있다. 표 1의 * 표시는

개 동의를 받은 트랜잭션에 대해서만 '1'을 표시 할 때는 '0'으로 표시할 수 있고, DELEGATE REQUEST 서버가 최소 한 개 이상의 트랜잭션을 포함해야 한다고 제한 하는 경우에는 '1'로 표시 하는 방법을 사용할 수 있다.Table 3 is expressed as a bitmap, which is the first bitmap information, as shown in Table 1. In Table 1, '1' indicates that the server has requested a corresponding transaction, and '0' may indicate a transaction that the server does not propose. Each row can represent one transaction. The number of columns in Table 1 may be 2f+1. The sum of bits that is '1' in each row is

The above are among the servers

It means that more than one DELEGATE REQUEST was made at the same time,

It can be seen that a transaction with less than a bit is indicative of a failure to obtain consent. A DELEGATE REQUEST server must propose at least one transaction to be counted as a valid DELEGATE REQUEST server. * in Table 1 indicates

When '1' is displayed only for transactions for which consent has been obtained, it can be displayed as '0'. have.

이상의 노드들이 동의를 획득한 결과인 제2 트랜잭션에 대해 합의 정족수의 합의 노드들을 결정한 결과에 대한 동의를 받기 위한 메시지(PREPARE 블록)를 각 합의 노드들(SERVER 0~2)로 전달할 수 있다. 합의가 완료된 401 블록에는 402 블록 합의체로 선택되었던 노드들의 pk_i 와 Q_i가 기록되어 있다. 따라서 SERVER 0은 선택된 합의 정족수의 pk_i를 수학식 8과 같이 합쳐 통합 공개키 Pk를 생성하고, 수학식 9과 같이 Q_i도 합쳐 Q를 생성할 수 있다.The PREPARE step is in DELEGATE REQUEST.

A message (PREPARE block) for obtaining agreement on the result of determining the consensus nodes of the consensus quorum for the second transaction, which is the result of obtaining consent by the above nodes, may be transmitted to each consensus node (SERVER 0 to 2). The pk _i and Q _i of the nodes selected as the 402 block consensus are recorded in the 401 block where the consensus is completed. Accordingly, SERVER 0 may generate a unified public key Pk by combining pk _i of the selected quorum as shown in Equation 8, and may also generate Q by combining Q _i as shown in Equation 9.

In Equations 8 and 9, it can be seen that quorum represents a node included in the quorum of 2f+1 sums. Finally, SERVER 0 generates r as shown in Equation 10. In this case, Msg may be the head value of a complete block including the previously generated second transaction prepared transaction. The PREPARE block must be a complete block including transactions, just like a general blockchain.

At this time, SERVER 0 can prevent changing or adding even one bit of a later block through multi-signature signed by all of the quorum of consensus for the prepared PREPARE block.

In addition, SERVER 0 can create and send the delegate server bitmap, which is the second bitmap information, to check who each of the 2f+1 nodes are. (If DELEGATE REQUEST is limited to include at least one transaction, the second bitmap information delegate server bitmap may be calculated from the first bitmap information Proposed Transaction bitmap.)

Accordingly, SERVER 0 is the second transaction, the first bitmap information, the second bitmap information, the public key and the hash value r (prepared transaction, Proposed Transaction bitmap, delegate server bitmap, Pk, r) in the prepared message including its own You can create a PREPARE block by adding a digital signature and deliver it to the SERVER(0,1,2) to perform multi-signature.

The COMMIT step is Each node included in the consensus quorum generates a COMMIT message including a digital signature as an expression of agreement to the PREPARE message of SERVER 0, and SERVER 0, which received the agreement message, records the digital signatures of each consensus node. It can integrate into multi-signature and verify multi-signature.

SERVER 0 may perform a process of aggregating digital signatures into multi-signature. SERVER 0 can receive the consent of all 2f+1 servers included in the consensus quorum by multi-signature.

Each SERVER(0,1,2) that has received the PREPARE block performs the following operation if the validation result of the digital signature generated by SERVER 0 is true to check whether the PREPARE block generated by SERVER 0 is abnormal. In the case of , an action such as an empty agreement can be performed by notifying other nodes of this.

In addition, in order to verify the validity of r generated by SERVER 0, each SERVER(0,1,2) determines whether the second bitmap information delegate server bitmap has 2f+1 or more '1s' or the first bitmap information Proposed At least one '1' is marked in each column of the transaction bitmap, and it can be checked whether the number of these columns becomes 2f+1.

At this time, each SERVER(0,1,2) may extract pk _i and Q _i of the server corresponding to each bit from the information recorded in block 401 when the above result is true.

In this case, each SERVER(0,1,2) may generate Pk and Q using Equations 6 and 7 and generate r' through Equation 10.

At this time, each SERVER(0,1,2) compares the generated r' with the r transmitted by SERVER 0, and if the value is the same, the following operation can be performed.

At this time, if each SERVER(0,1,2) is not the same, SERVER 0 is cheating Pk, Q, or Msg. can

개의 동의를 얻은 transaction들만 포함하고 있는지 검사할 수 있다.At this time, each SERVER(0,1,2) transmits the second transaction prepared in the PREPARE block sent by SERVER 0 and each transaction through the first bitmap information Proposed Transaction bitmap.

You can check whether only transactions for which consent is obtained are included.

이상(본 예에서는 2개) 일 경우는 유효성 검사 성공,

미만이 하나라도 포함된 경우 유효성 검사 실패가 될 수 있다. 예를 들어 표 3의 Prepared transaction에 transaction (3,7,8) 중 하나가 포함되어 있을 경우

개의 서버가 이를 제안한 것이 아니므로 유효성 검사 실패가 될 수 있다.For example, when Table 3 is information on the prepared transaction for the second transaction sent by each server, and Table 1 is the Proposed Transaction bitmap for the server that proposed the transaction, the row matching the transaction included in Table 3 is Table 1 , and the sum of the counts of all '1's in the row is

If it is more than (two in this example), validation is successful,

If any less than one is included, it may be a validation failure. For example, if Prepared transaction in Table 3 contains one of transaction (3,7,8)

This could be a validation failure as the server did not suggest this.

At this time, if the check is successful, each SERVER(0,1,2) checks whether '1' is displayed in the bitmap of the part other than the transaction it proposes. You can check if only '1' is displayed.

At this time, each SERVER(0,1,2) will fail validation if '1' is displayed in the transaction not proposed by it. For example, if Table 3 contains transaction 3 and the bit corresponding to SERVER 0 or SERVER 2 is marked as '1' in the 4th row of Table 1, SERVER 0 or SERVER 2 is a lie. validation may fail. Also, validation failure may occur if multiple signatures are not received within a given time from SERVER 1 or SERVER 2 for a normal Proposed Transaction bitmap. An empty agreement can be initiated when any one of the abnormal validation results fails, and when the check result is successful, the next step can be performed.

)에 적용하여 s_i를 생성하고 이를 포함한 메시지에 각 서버의 전자서명을 추가하여 SERVER 0에게 전달할 수 있다. At this time, each SERVER(0,1,2) represents r delivered from SERVER 0 when all the validation results are true, and k _i , sk _i that each server has as a secret in the equation (

) to generate s _i , and add each server's digital signature to the message including it and deliver it to SERVER 0.

SERVER 0 that has received s _i may first verify the aggregated multi-signature as shown in FIG. 8 without immediately verifying the digital signature of each server. If the verification result is false, it is also possible to find a false signature to check whether the signature is damaged by a middle-attacker, and perform the digital signature verification procedure of the server.

If the verify result for the signature (r,S) generated by SERVER 0 is false and SERVER 0 does not generate a false signature, SERVER 0 can find the servers (1~2) that delivered false s _i .

When SERVER 0 has completed receiving s _i from all 2f+1 servers, it generates S and performs the verify check of FIG. 8 and returns a message including (Prepared transaction, Pk, (r, S)) when the result is true In the REPLY phase, consensus can be completed by broadcasting to all nodes.

In addition, the following processing can be done for errors that occur during the consensus process. Each of the DELEGATE REQUEST, PREPARE, and COMMIT steps sets a timer at the start time, and if the next step does not start before the timer expires, error handling may occur. An empty agreement may be referred to as an empty agreement for nodes according to an embodiment of the present invention to agree on a block that does not contain any transactions. An empty agreement does not contain a valid transaction, but may have the effect of changing the agreement.

Nodes according to an embodiment of the present invention may perform view change in order to resolve the failure of consensus because consensus nodes are fixed. However, since consensus nodes are not fixed in nodes according to an embodiment of the present invention, when consensus fails, a consensus node may be reconfigured rather than view change.

When the nodes according to an embodiment of the present invention fail to agree, creating a block that does not include a transaction can reduce the risk and reduce the complexity of the protocol, rather than re-consenting the untrusted nodes.

An empty agreement can proceed through agreement of at least f+α+1. Empty agreement can prevent the creation of multiple empty agreement blocks in each network when the network is segmented. For this, the consensus nodes included in the consensus quorum may be set not to change during one block consensus time.

In the error handling of the DELEGATE REQUEST phase, when SERVER 0 of block 402 receives the result of the 401 block consensus, it starts the DELEGATE REQUEST timer and starts the 402 block consensus. If the normal DELEGATE REQUEST of 2f+1 consensus quorum is not received until the DELEGATE REQUEST timer of SERVER 0 expires, f+α+1 among consensus nodes including an error message indicating that a request less than 2f+1 has been received. By the above, empty agreement can be performed. In addition, each server (SERVER 0~3) can start its own DELEGATE REQUEST timer while transmitting its own DELEGATE REQUEST packet after receiving the REPLY result of the 401 block consensus. If SERVER 0 does not PREPARE until its own DELEGATE REQUEST timer expires, each server may declare the server with the smallest coupon as SERVER 0 and attempt empty agreement except for the coupon possessed by SERVER 0. In this case, the block may contain a log of that error.

Error handling in the PREPARE phase can start the PREPARE timer while SERVER 0 delivers the first PREPARE packet. If SERVER 0 does not receive si from all servers with a consensus quorum of 2f+1 before the PREPARE timer expires, the server that did not transmit si is added to the blacklist, and excluding the blacklist from the consensus quorum, the An empty agreement can be proceeded by

Error handling in the COMMIT stage is when the signature integrated by SERVER 0 is not verified, finds a problematic server among the received si and adds it to the blacklist, and by consensus of the nodes above f+α+1 excluding the blacklist from the quorum of the consensus You can proceed with an empty agreement. In addition, each server corresponding to the consensus quorum starts a COMMIT timer upon receiving the PREPARE packet of SERVER 0. If SERVER 0 does not start REPLY before the COMMIT timer expires, SERVER 0 can be replaced with a new SERVER 0 and empty agreement can be proceeded by consensus of more than f+α+1 nodes except for the existing SERVER 0.

In case the agreement fails in the above, other than empty agreement, a method of reconsenting through view change may be included.

10 is a diagram illustrating a multi-signature tree according to an embodiment of the present invention.

Referring to FIG. 10, it can be seen that the multi-signature generation process performed in the COMMIT step according to an embodiment of the present invention is shown. SERVER 0 can arbitrarily combine two or more signatures as shown in FIG. 10 according to the characteristics of EC-schnorr multi-signature in order to find an incorrect multi-signature fragment s _i and check whether the combined signature is abnormal.

을 수행할 때 모든 s_i 를 무조건 더하는 것이 아니라 도 10과 같이 임의의 두 값을 더하고 이 결과 값을 다시 둘씩 짝지어 더하는 과정을 반복하여 트리(tree)로 구성할 수 있다. 이 때, 트리의 꼭지점이 각각 도 8의 S, Q, Pk 에 상응할 수 있다. 여기서 S는 schnorr 다중서명 결과값 중 일부이며, Q 는 Q_i 조각을 합친 값이고, Pk는 합쳐진 다중서명의 공개키이다.Therefore, Equation 11

When performing , instead of unconditionally adding all s _i , as shown in FIG. 10 , the process of adding two arbitrary values and pairing and adding the resulting values may be repeated to form a tree. In this case, the vertices of the tree may correspond to S, Q, and Pk of FIG. 8 , respectively. Here, S is a part of the result of schnorr multi-signature, Q is the sum of Q _i fragments, and Pk is the public key of the combined multi-signature.

For example, in the multi-signature verification process, if a problem occurs in the final signature S verification, Sp0 and Sp1 below one level of the tree are checked, and if the check result in Sp0 fails, S ₀ or S ₁ Since one of the two partial signatures has a problem, the inspection time can be reduced by examining only the digital signature of the corresponding server.

If one server sends a fake partial signature, which is a false digital signature, if the partial signatures are integrated and verified in a tree form, the server that sent the fake signature can be found through partial signature inspection through the tree and one digital signature inspection .

11 is a graph showing a Byzantine node distribution according to an embodiment of the present invention. 12 is a graph showing the distribution of Byzantine nodes in various environments according to an embodiment of the present invention.

Referring to FIG. 11 , if it is assumed that the parameters of the nodes are sufficiently large and a node is arbitrarily selected by threshold comparison, the number of selected nodes may have a normal distribution. If the average (μ) of this distribution is 3f+1, the probabilistic characteristic as shown in FIG. 11 can be calculated. It can be seen that FIG. 11 shows the calculated results assuming that 10,000 parameters and 25% of Byzantine nodes are included. It can be seen that the number of nodes in each condition is indicated on the y-axis when the average number of consensus agreements to be selected is changed from 10 to 1,000 on the x-axis. 11 shows that three lines are drawn. It can be seen that the min node line is a line with a probability of 1.0000e-6 or less of selecting y or less nodes when an average of x nodes is selected. It can be seen that the 2f+1 line is a line marked with 2f+1 on the y-axis when an average of x nodes is selected. It can be seen that the Max Bzt line is a line whose probability of selecting y or more Byzantine nodes is 3.1710e-17 or less when the average x nodes are selected.

In FIG. 11 , three intersections may have an important meaning as a node selection criterion. At the intersection of 2f+1 > bzt in FIG. 11 , when the average of the number of consensuses is set to less than 101 in a 25% Byzantine environment, there may be a probability that a quorum of consensus consisting only of Byzantine nodes will be formed. Therefore, when the quorum of the consensus is fixed at 2f+1, it can be seen that the average of the number of consensus bodies is 101 or more.

The min > bzt intersection in FIG. 11 may mean a starting point at which the minimum node value to be selected becomes greater than the maximum Byzantine node when the average of the number of consensuses is selected as x.

It can be seen that the min > 2f+1 intersection in FIG. 11 is a starting point that ensures that the probability that the minimum number of nodes of the consensus is 2f+1 or less is 1.0000e-6 or less when an average of x consensus is selected. Assuming that there are no node failures or packet forwarding problems in the network, if the average of the number of consensuses is set above this intersection point, it is possible to secure at least 2f+1 of the minimum consensus quorum for every block. If the consensus is less than 2f+1, empty agreement can be performed.

At this time, if the agreement of f+1 is obtained in the PREPARE stage and 2f+1 consent is obtained in the COMMIT stage to complete the agreement, the reason for obtaining the consent of f+1 in the PREPARE stage is that Byzantine is up to 33% f This is because, when +1 consent is obtained, at least one normal node must be included, so byzantine alone can never agree. 2f+1 consent in the COMMIT phase is to prevent double consensus.

12, it shows the result of comparing the maximum value of the Byzantine node that can be selected when the Byzantine node changes from 20% to 35%, f+1, 2f+1, 3f+1, and min node. it can be seen that 11 , the x-axis may mean the average number of randomly selected consensus bodies, and the y-axis may mean the number of nodes corresponding to each condition. If x is about 800 or more in an environment including 20% Byzantine nodes, the maximum possible Byzantine value can always have a value smaller than f+1. Therefore, it can be seen that SCHEME 1 or SCHEME 2 can be used when the maximum number of Byzantine nodes is guaranteed to be less than or equal to f.

In Fig. 12, when x is about 200 or more, the ratio of Byzantine nodes ranges from 25% to 35%. In all sections, the maximum number of Byzantine nodes is always smaller than 2f and larger than f. More consent may be required. However, as described above, finality may be broken in this case.

13 is a diagram illustrating a computer system according to an embodiment of the present invention.

Referring to FIG. 13 , the decentralized Byzantine error-tolerant distributed consensus apparatus and all nodes of the block chain according to an embodiment of the present invention may be implemented in a computer system 1100 such as a computer-readable recording medium. As shown in FIG. 13 , the computer system 1100 includes one or more processors 1110 , a memory 1130 , a user interface input device 1140 , and a user interface output device 1150 that communicate with each other via a bus 1120 . and storage 1160 . In addition, the computer system 1100 may further include a network interface 1170 coupled to the network 1180 . The processor 1110 may be a central processing unit or a semiconductor device that executes processing instructions stored in the memory 1130 or the storage 1160 . The memory 1130 and the storage 1160 may be various types of volatile or non-volatile storage media. For example, the memory may include a ROM 1131 or a RAM 1132 .

A decentralized Byzantine error-tolerant distributed consensus apparatus according to an embodiment of the present invention includes one or more processors 1110; and an execution memory 1130 for storing at least one or more programs executed by the one or more processors 1110, wherein the at least one program executes a distributed consensus proposed by a client from consensus candidate nodes of a blockchain. Receives DELEGATE REQUEST messages including the requesting first transaction, and determines consensus nodes corresponding to a quorum of consensus candidates among the consensus candidate nodes based on the consensus candidate request messages, and , generate a PREPARE message including a second transaction for obtaining agreement on the result of determining the consensus nodes to the consensus nodes, and send the preparation message to the consensus nodes, and from the consensus nodes In response to the preparation message, consent (COMMIT) messages including electronic signatures of each of the consensus nodes are received, and a response (REPLY) message, which is a result of verifying electronic signatures included in the consent messages, is transmitted to the consensus candidate. The distributed agreement is completed by broadcasting to the nodes, the quorum of the agreement is 2f+1 (f is an integer greater than or equal to 1), the f satisfies both the first condition and the second condition, and the first condition is the When the consensus candidate nodes among all nodes of the blockchain are selected with a probability of p (p is a real number between 0 and 1), the number of Byzantine nodes to be selected as the consensus candidate nodes exceeds f. A condition that is satisfied when the first probability is less than or equal to a predetermined first reference probability, and the second condition is a condition that is satisfied when the second probability that the number of consensus candidate nodes is 3f or less is less than or equal to the second reference probability.

In this case, the at least one program includes the consensus candidate request message including information indicating whether the node that transmitted the consensus candidate request message has selected each of the all nodes as the consensus candidate node from all the nodes. , and when there are 3f+1 or more nodes that have transmitted the consensus candidate request message, 3f+1 nodes are selected to determine the consensus candidate nodes for the next distributed consensus, and the consensus candidate request message is transmitted When one node is 3f or less, the consensus candidate nodes may not be updated.

In this case, when the at least one program receives the consensus quorum of the consensus quorum candidate request messages, based on the same f+1 first transactions included in the consensus quorum of the consensus quorum candidate request messages The second transaction may be determined.

In this case, the at least one program generates first bitmap information corresponding to the first transaction of the consensus candidate nodes and second bitmap information including a result of determining the consensus nodes, and the first bitmap information, the second bitmap information and the second transaction may be generated.

In this case, the consensus nodes may check the validity of the preparation message based on whether the first bitmap information and the second transaction correspond.

In this case, the at least one program generates a first unified public key and a first unified quorum value by integrating public keys and quorum values included in the consensus candidate request messages, respectively, and the first unified public key and the The preparation message may further include a first hash value obtained by hashing the first unified quorum value.

In this case, the consensus nodes generate a second unified public key and a second unified quorum value by integrating the pre-registered public keys and the pre-registered quorum values, respectively, and the second unified public key and the second unified public key The validity of the preparation message may be checked by comparing whether the second hash value obtained by hashing the quorum value is the same as the first hash value.

At this time, when the second hash value and the first hash value are the same, the consensus nodes generate signature values including the first hash value and secret values previously stored in the consensus nodes, and include The consent messages may be generated by including the signature values and adding the electronic signatures based on the signature values.

At this time, the at least one or more programs apply the signature values included in the consent messages, the public keys of the first integrated public key, and the quorum values of the first integrated quorum value to a multi-signature signature value in the form of a tree, The multi-signature may be generated from the digital signatures by integrating the public key of the multi-signature and the quorum value of the multi-signature.

When the verification result of the multi-signature is true, the at least one or more programs may generate the response message including the second transaction and the multi-signature.

In addition, the decentralized Byzantine error-tolerant distributed consensus apparatus and method according to an embodiment of the present invention enables BFT-series distributed agreement by randomly selected nodes, thereby enabling BFT agreement by decentralized nodes.

In addition, in the decentralized Byzantine error-tolerant distributed consensus apparatus and method according to an embodiment of the present invention, when nodes are arbitrarily selected and they proceed with a BFT-based consensus, the consensus problem such as Equation 4, which the existing PBFT cannot solve, is solved. It is possible.

In addition, the decentralized Byzantine error-tolerant distributed consensus apparatus and method according to an embodiment of the present invention requires one step more message exchange between servers than the existing MinBFT, but O(N ² ) rather than O(N 2 ) in the COMMIT step. ) message, so a quick consensus is possible.

In addition, the decentralized Byzantine error-tolerant distributed consensus apparatus and method according to an embodiment of the present invention requires only the same O(N) message exchange as that of the existing FastBFT, and quick consensus is possible because the message exchange step is one step less.

In addition, the decentralized Byzantine error-tolerant distributed consensus apparatus and method according to an embodiment of the present invention can verify the node participation qualification of the node in the DELEGATE REQUEST step through two hash operations. At this time, the decentralized Byzantine error-tolerant distributed consensus device and method block the participation of unqualified nodes in the distributed consensus while enabling fast computation, enabling quick consensus even in a large number of node situations.

As described above, in the apparatus and method of decentralized Byzantine error-tolerant distributed consensus according to an embodiment of the present invention, the configuration and method of the described embodiments are not limitedly applicable as described above, but the embodiments are various All or part of each of the embodiments may be selectively combined and configured so that modifications may be made.

1100: computer system 1110: processor
1120: bus 1130: memory
1131: rom 1132: ram
1140: user interface input device
1150: user interface output device
1160: storage 1170: network interface
1180: network

Claims (20)

one or more processors; and
an execution memory for storing at least one or more programs executed by the one or more processors;
including,
the at least one program
Receives DELEGATE REQUEST messages including a first transaction requesting a distributed consensus proposed by a client from consensus candidate nodes of a blockchain, and based on the consensus candidate request messages, the consensus candidate nodes Determining consensus nodes corresponding to the consensus quorum as consensus nodes;
generating a PREPARE message including a second transaction for obtaining consent from the consensus nodes, and sending the preparation message to the consensus nodes;
In response to the preparation message from the consensus nodes, consent (COMMIT) messages including electronic signatures of each of the consensus nodes are received, and a response (REPLY) that is a result of verifying the electronic signatures included in the consent messages Broadcast a message to the consensus candidate nodes to complete the distributed consensus,
The quorum of the sum is 2f+1 (f is an integer greater than or equal to 1),
f satisfies both the first condition and the second condition,
The first condition is that when the consensus candidate nodes among all nodes of the block chain are selected with a probability of p (p is a real number between 0 and 1), Byzantine to be selected as the consensus candidate nodes It is a condition that is satisfied when the first probability that the number of nodes exceeds f is less than or equal to the preset first reference probability,
The second condition is a condition that is satisfied when the second probability that the number of consensus candidate nodes is 3f or less is less than or equal to a second reference probability,
The first condition corresponds to Equation 1 below, and the second condition corresponds to Equation 2 below,
[Equation 1]

(b is the number of Byzantine nodes, P _{max_bzt} is the first reference probability, k is an integer index)
[Equation 2]

(n is the total number of nodes, P _{min_node} is the second reference probability, x is an integer index)
The decentralized Byzantine error-tolerant distributed consensus device, characterized in that p is determined to satisfy both Equations 1 and 2. The method according to claim 1,
the at least one program
receiving the consensus candidate request message including information indicating whether each of the entire nodes has been selected as the consensus candidate node from the all nodes;
If there are more than 3f+1 nodes that have transmitted the consensus candidate request message, 3f+1 nodes are selected and determined as the consensus candidate nodes for the next distributed consensus, and the node that transmitted the consensus candidate request message is 3f Decentralized Byzantine Error Tolerant Distributed Consensus Device, characterized in that the consensus candidate nodes are not updated when the number is less than or equal to. 3. The method according to claim 2,
the at least one program
Decentralization that determines the second transaction based on the same number of f+1 first transactions included in the consensus quorum of the consensus candidate request messages as many as the consensus quorum The Byzantine Error Tolerant Distributed Consensus Device. 3. The method according to claim 2,
the at least one program
generating first bitmap information corresponding to the first transaction of the consensus candidate nodes and second bitmap information including a result of determining the consensus nodes, the first bitmap information, the second bitmap information and Decentralized Byzantine error-tolerant distributed consensus apparatus, characterized in that generating the preparation message including the second transaction. 5. The method according to claim 4,
The consensus nodes are
Decentralized Byzantine error-tolerant distributed consensus apparatus, characterized in that the validity of the preparation message is checked based on whether the first bitmap information and the second transaction correspond. 6. The method of claim 5,
the at least one program
A first unified public key and a first unified quorum value are generated by integrating public keys and quorum values included in the consensus candidate request messages, respectively, and the first unified public key and the first unified quorum value are hashed 1 Decentralized Byzantine error-tolerant distributed consensus device, characterized in that it generates the ready message further including a hash value. 7. The method of claim 6,
The consensus nodes are
A second hash value obtained by integrating the pre-registered public keys and pre-registered quorum values to generate a second unified public key and a second unified quorum value, and hashing the second unified public key and the second unified quorum value Decentralized Byzantine error-tolerant distributed consensus apparatus, characterized in that by comparing whether the first hash value is the same to check the validity of the preparation message. 8. The method of claim 7,
The consensus nodes are
If the second hash value and the first hash value are the same, generate signature values including the first hash value and secret values pre-stored in the consensus nodes, and include the signature values in the preparation message; Decentralized Byzantine error-tolerant distributed consensus apparatus, characterized in that by adding the digital signatures based on the signature values to generate the consent messages. delete delete In the decentralized Byzantine error-tolerant distributed consensus method of the decentralized Byzantine error-tolerant distributed consensus device,
Receives DELEGATE REQUEST messages including a first transaction requesting a distributed consensus proposed by a client from consensus candidate nodes of a blockchain, and based on the consensus candidate request messages, the consensus candidate nodes determining consensus nodes corresponding to the consensus quorum among consensus nodes;
generating a PREPARE message including a second transaction for obtaining agreement from the consensus nodes, and sending the PREPARE message to the consensus nodes; and
In response to the preparation message from the consensus nodes, consent (COMMIT) messages including electronic signatures of each of the consensus nodes are received, and a response (REPLY) that is a result of verifying the electronic signatures included in the consent messages broadcasting a message to the consensus candidate nodes to complete distributed consensus;
including,
The quorum of the sum is 2f+1 (f is an integer greater than or equal to 1),
f satisfies both the first condition and the second condition,
The first condition is that when the consensus candidate nodes among all nodes of the block chain are selected with a probability of p (p is a real number between 0 and 1), Byzantine to be selected as the consensus candidate nodes It is a condition satisfied when the first probability that the number of nodes exceeds f is less than or equal to a predetermined first reference probability,
The second condition is a condition that is satisfied when the second probability that the number of consensus candidate nodes is 3f or less is less than or equal to a second reference probability,
The first condition corresponds to Equation 1 below, and the second condition corresponds to Equation 2 below,
[Equation 1]

(b is the number of Byzantine nodes, P _{max_bzt} is the first reference probability, k is an integer index)
[Equation 2]

(n is the total number of nodes, P _{min_node} is the second reference probability, x is an integer index)
Wherein p is determined to satisfy both Equations 1 and 2, A method of decentralized Byzantine error-tolerant distributed consensus. 12. The method of claim 11,
The step of determining the consensus nodes is
receiving the consensus candidate request message including information indicating whether each of the entire nodes has been selected as the consensus candidate node from the all nodes;
If there are more than 3f+1 nodes that have transmitted the consensus candidate request message, 3f+1 nodes are selected and determined as the consensus candidate nodes for the next distributed consensus, and the node that transmitted the consensus candidate request message is 3f Decentralized Byzantine error-tolerant distributed consensus method, characterized in that the consensus candidate nodes are not updated when the number is less than or equal to. 13. The method of claim 12,
The step of determining the consensus nodes is
Decentralization that determines the second transaction based on the same number of f+1 first transactions included in the consensus quorum of the consensus candidate request messages as many as the consensus quorum Byzantine error-tolerant distributed consensus method. 13. The method of claim 12,
The step of sending the preparation message is
generating first bitmap information corresponding to the first transaction of the consensus candidate nodes and second bitmap information including a result of determining the consensus nodes, the first bitmap information, the second bitmap information and Decentralized Byzantine error-tolerant distributed consensus method, characterized in that generating the ready message including the second transaction. 15. The method of claim 14,
The step of sending the preparation message is
Decentralized Byzantine error-tolerant distributed consensus method, characterized in that the consensus nodes check the validity of the preparation message based on whether the first bitmap information and the second transaction correspond. 16. The method of claim 15,
The step of sending the preparation message is
A first unified public key and a first unified quorum value are generated by integrating public keys and quorum values included in the consensus candidate request messages, respectively, and the first unified public key and the first unified quorum value are hashed 1 Decentralized Byzantine error-tolerant distributed consensus method, characterized in that generating the ready message further including a hash value. 17. The method of claim 16,
The step of sending the preparation message is
The consensus nodes generate a second unified public key and a second unified quorum value by integrating the pre-registered public keys and the pre-registered quorum values, respectively, and hash the second unified public key and the second unified quorum value. A decentralized Byzantine error-tolerant distributed consensus method, characterized in that the second hash value and the first hash value are compared to check the validity of the prepared message. 18. The method of claim 17,
The step of completing the distributed agreement is
When the second hash value and the first hash value are the same, the consensus nodes generate signature values including the first hash value and secret values previously stored in the consensus nodes, and include the signature value in the preparation message and generating the consent messages by adding the digital signatures based on the signature values. delete delete

Images