Distributed Consensus Method, Apparatus Using Public Node Identifiers, and Blockchain Generation Method Using the Same

Abstract

To provide a method and a system for selecting random nodes as consensus bodies on a block-by-block basis, and allowing these consensus bodies to reach an agreement for adding new blocks to the chain.SOLUTION: A distributed consensus method includes the steps of generating public voting identifiers using public node identifiers corresponding to nodes that constitute a blockchain, performing an operation corresponding to a success probability (p) for each public voting identifier to generate a passing vote list, and performing distributed consensus on the basis of at least some of the consensus nodes corresponding to the passing vote list.SELECTED DRAWING: Figure 7

Description

Technical Field

[0001] The present invention relates to blockchain distributed consensus technology, and particularly to a technology for selecting random nodes as a consensus body in block units and performing a consensus for adding a new block to the chain by these consensus bodies.

Background Art

[0002] Generally, as the number of participating nodes in a blockchain increases, the time required to confirm a block also increases. As one method to overcome this, a part of all nodes is selected as a consensus congress, and the block confirmation time can be shortened by having the new block confirmed by this consensus congress. At this time, when fixed nodes are used as the consensus body, a centralization problem occurs, and to prevent this, a method of selecting random nodes as the consensus body has been used. Existing methods for selecting random nodes as the consensus body introduce distributed consensus technologies such as randomly selecting nodes from all nodes using VRF (Verifiable Random Function) or randomly selecting nodes that constitute the consensus body using a nonce chain.

[0003] In the distributed consensus technology using VRF, each node performs an operation corresponding to VRF, and the presence or absence of consensus body selection is determined according to the result. The nodes selected as the consensus body submit the voting results of the nodes together with evidence. However, the disadvantage of this method is that the size of the consensus body can only be known in a probability distribution, and it is impossible to know exactly how many nodes will be selected as the consensus body. Therefore, since it is impossible to accurately know how many nodes are in the majority or two-thirds of the consensus body, a complex consensus process must be undergone.

[0004] The papers "Algorithm based on Byzantine agreement among decentralized agents (BADA)" published on October 20, 2020, US Published Patent No. 2019-0327084, US Published Patent No. 2019-0379538, US Published Patent No. 2020-0403776, and US Published Patent No. 2023-0066169 disclose in detail a method for selecting a consensus body based on a nonce chain and a method for generating a blockchain using the same. The technologies disclosed in the above papers and patents can determine the size of the consensus body according to the number of participating nodes. Once the consensus body is determined, it is possible to know how many nodes are in the majority or two-thirds. Therefore, a simple consensus algorithm such as PBFT (Practical Byzantine Fault Tolerance) can be used. However, this method also has the disadvantage of requiring a message transmission protocol for determining the consensus body.

[0005] The message transmission protocol for determining the consensus body includes the process of exchanging messages for consensus body formation among nodes, which places a large load on the system as the number of nodes participating in the blockchain increases. Therefore, there is an urgent need for a new blockchain consensus technology that can reduce or eliminate the exchange of messages for consensus body formation.

Summary of the Invention

Problems to be Solved by the Invention

[0006] An object of the present invention is to configure a blockchain consensus body by selecting a random number of nodes corresponding to the size of the consensus body determined according to the number of participating nodes while minimizing the exchange of messages for consensus body formation.

[0007] Another object of the present invention is to reduce the message complexity of a blockchain system and maintain decentralization while improving performance by having a randomly selected consensus body perform consensus using a simple consensus algorithm such as PBFT for each block without exchanging messages for consensus body formation using public node identifiers.

Means for Solving the Problem

[0008] A distributed consensus method performed by a distributed consensus device according to the present invention for achieving the above object includes a step of generating public vote identifiers using public node identifiers corresponding to nodes constituting a blockchain, a step of performing an operation corresponding to a success probability (p) for each of the public vote identifiers to generate a pass vote list, and a step of performing distributed consensus based on at least a part of consensus body nodes corresponding to the pass vote list.

[0009] At this time, the pass vote list is generated by each node constituting the blockchain performing the operation on the node including itself based on the public vote identifier. At this time, the pass vote lists generated by the nodes constituting the blockchain at a specific timing may be the same as each other.

[0010] At this time, the operation may be to compare a random value generated using the public vote identifier and previous block information with a threshold corresponding to the success probability.

[0011] At this time, the public vote identifiers are generated for each of the nodes using the public node identifiers corresponding to the nodes, and the number of votes of each node is used.

[0012] At this time, the consensus body node is selected from among the nodes included in the passing vote list.

[0013] At this time, the consensus on the previous block corresponding to the previous block information is finally confirmed by the chair node selected from among the consensus body nodes for the current block.

[0014] At this time, the public vote identifier is generated by adding or subtracting 1 from among the generated values including 0 to the public node identifier corresponding to each of the nodes.

[0015] At this time, the public node identifier may be a public key corresponding to the node.

[0016] At this time, the node among the consensus body nodes with the largest or smallest value corresponding to the result of the operation may become the chair node.

[0017] Moreover, the distributed consensus device according to an embodiment of the present invention includes one or more processors and an execution memory that stores at least one or more programs executed by the one or more processors.

[0018] At this time, the at least one or more programs generate a public vote identifier using the public node identifier corresponding to the nodes constituting the blockchain, perform an operation corresponding to the success probability (p) for each public vote identifier to generate a passing vote list, and can perform distributed consensus based on at least a part of the consensus body nodes corresponding to the passing vote list.

[0019] At this time, the passing vote list is generated by each node constituting the blockchain performing the operation on the node including itself based on the public vote identifier. At this time, the passing vote lists generated by the nodes constituting the blockchain at a specific timing may be the same as each other.

[0020] At this time, the operation may be to compare a random value generated using the public vote identifier and the previous block information with a threshold corresponding to the success probability.

[0021] At this time, the public vote identifier is generated for each node by using the public node identifier corresponding to each node, and the number of voting rights of each node.

[0022] At this time, the consensus node is selected from among the nodes included in the passing vote list.

[0023] At this time, the consensus on the previous block corresponding to the previous block information is finally confirmed by the chair node selected from among the consensus nodes for the current block.

[0024] In addition, the blockchain generation method according to an embodiment of the present invention includes a step of receiving a COMMITTED message corresponding to a previous block, a step of generating a passing vote list using information regarding the previous block and a public vote identifier, a step in which a chair node corresponding to the current block receives a CONFIRM message from a consensus node corresponding to the passing vote list and finally confirms the consensus result of the previous block based on the CONFIRM message (the chair node is recognized based on the passing vote list), and a step in which the chair node transmits a PREPARE message for connecting the current block to the blockchain to a committee node selected from among the consensus nodes.

[0025] At this time, the blockchain generation method according to an embodiment of the present invention may further include the step of the chair node receiving a COMMIT message from the committee node, and the step of the chair node sending a COMMITTED message corresponding to the current block to all nodes.

[0026] At this time, the passing vote list is generated by each node constituting the blockchain performing an operation corresponding to the success probability (p) on the nodes including itself based on the public vote identifier. At this time, the passing vote lists generated by the nodes constituting the blockchain at a specific timing may be the same as each other.

[0027] At this time, the operation may be to compare a random value generated using the public vote identifier and information about the previous block with a threshold corresponding to the success probability.

[0028] At this time, the public vote identifier is generated for each node by using the public node identifier corresponding to each node, and the number of votes of each node.

Advantages of the Invention

[0029] According to the present invention, all blockchain nodes including the chair node can know which nodes are selected as the consensus body, how many there are, and who the chairperson is before receiving a message regarding whether other nodes are selected as the consensus body, so that consensus can proceed immediately without the exchange of consensus body configuration-related messages.

[0030] In addition, the present invention can configure a blockchain consensus body by selecting a number of random nodes corresponding to the size of the consensus body determined according to the number of participating nodes while minimizing the exchange of messages for consensus body configuration.

[0031] In addition, the present invention can reduce the message complexity of the blockchain system and improve performance while maintaining decentralization by having a randomly selected consensus body perform consensus using a simple consensus algorithm such as PBFT for each block without exchanging messages for consensus body configuration using public node identifiers.

[0032] In addition, the present invention can efficiently reconstruct a block consensus body with a determined size in block units without exchanging additional messages.

[0033] Furthermore, since the present invention does not require the exchange of messages for consensus body configuration, it can reduce the resulting increase in protocol complexity and delay.

[0034] In addition, the present invention can easily configure a consensus body with a determined size according to the number of participating nodes and apply it to an existing simple consensus algorithm without exchanging consensus body configuration messages.

Brief Description of the Drawings

[0035]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Embodiments for Carrying Out the Invention

[0036] The advantages, features, and methods for achieving them of the present invention will become clear by referring to the embodiments described in detail below together with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below and can be realized in various different forms. Merely, these embodiments are provided to make the disclosure of the present invention complete and to fully inform those with ordinary knowledge in the technical field to which the present invention pertains of the scope of the invention. The present invention is defined only by the scope of the claims. The same reference numerals throughout the specification refer to the same components.

[0037] Although terms such as "first" or "second" are used to describe various components, such components are not limited by such terms. Such terms are merely used to distinguish one component from another. Therefore, the first component mentioned below may be the second component within the technical idea of the present invention.

[0038] The terms used in this specification are for the purpose of describing embodiments and are not intended to limit the present invention. In this specification, the singular form also includes the plural form unless otherwise specifically stated in the text. The term "comprises" or "comprising" used in the specification means that the recited component or step does not exclude the existence or addition of one or more other components or steps.

[0039] Unless otherwise defined, all terms used in this specification shall be construed in a meaning commonly understood by those of ordinary skill in the technical field to which the present invention pertains. Also, terms defined in commonly used dictionaries shall not be interpreted ideally or excessively unless specifically defined otherwise.

[0040] Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. When describing with reference to the drawings, the same or corresponding components are denoted by the same reference numerals, and redundant descriptions thereof are omitted.

[0041] In the above-described existing technology, in the process of forming a consensus body, the chair node could not know how many nodes would be selected as consensus body candidates before receiving a message regarding whether other nodes were selected as the consensus body. Therefore, the chair node according to the existing technology set a threshold time for forming a consensus congress, waited until 3f + 1 (f is a Byzantine size and an integer of 1 or more) nodes responded, and when the threshold time ended and the number of nodes forming the consensus body was less than 3f + 1, an exception handling process was required to handle this. However, according to the present invention, it is possible for the chair to know how many nodes have succeeded in the coin toss operation, who the chair is, and who the nodes forming the consensus body are, and the consensus can be advanced immediately without exchanging messages related to consensus body formation.

[0042] It can be assumed that participating nodes that participate in the blockchain to start block consensus are connected to the network. At this time, generally, nodes use public-key-based encryption for reasons such as transmission data integrity. For this reason, blockchain node x generates a public key pk x from its private key sk x and can share its public key with other nodes connected to the network. Thereafter, node x can securely transmit data using its private key sk x , and other nodes can decrypt the transmitted data using the public key pk x of node x and can also authenticate the origin of the data. At this time, the public key of each blockchain node may be an example of a public node identifier according to an embodiment of the present invention. That is, in an embodiment of the present invention, the public node identifier may be information that is public to other nodes and can identify a specific node. At this time, the public node identifier may be an identifier of a specific node that other nodes know or can know. At this time, the public node identifier is shared from the node to other nodes and is transmitted by information included in a message transmitted from the node to other nodes. For example, the public node identifier may be a serial number assigned to each blockchain node. For example, the public node identifier may be the public key itself of each blockchain node or identification information generated based on the public key.

[0043] As described in detail in the aforementioned U.S. Patent Publication No. 2023-0066169, a blockchain node can have a number of votes corresponding to its held shares. Also in the present invention, a blockchain node can have more than one vote, and a consensus body is selected based on the results of operations corresponding to the success probability p for the number of votes corresponding to the vote. For example, if a specific node has two votes and succeeds in an operation corresponding to the success probability p with even one of these two votes, it becomes a consensus candidate.

[0044] FIG. 1 is a diagram showing an example of a process in which a passed vote list is generated from a public vote identifier according to an embodiment of the present invention.

[0045] Referring to FIG. 1, it can be seen that a passed vote list pass_list is generated using a vote identifier list ID_list in which public vote identifiers are stored.

[0046] The public vote identifier may be an identifier corresponding to each vote (or coin toss), and is generated from a public node identifier. At this time, the public vote identifier is generated for each of the nodes by using the public node identifier corresponding to each node participating in the blockchain, for the number of votes of each of the nodes. For example, if node A has 10 shares and 10 votes, 10 public vote identifiers for node A are generated based on the public node identifier of node A. For example, if node B has 2 shares and 2 votes, 2 public vote identifiers for node B are generated based on the public node identifier of node B.

[0047] The voting identifier list ID_list shown in FIG. 1 stores the public voting identifiers when the number of nodes participating in the blockchain is 4. In the example of FIG. 1, the 4 nodes can each have a unique public node identifier. At this time, the public node identifier of the first node may be ID0, the public node identifier of the second node may be ID1, the public node identifier of the third node may be ID2, and the public node identifier of the fourth node may be ID3. At this time, the public node identifiers ID0, ID1, ID2, and ID3 may be the public keys of each node.

[0048] In the example of FIG. 1, the first node can have 3 voting rights, the second node can have 1 voting right, the third node can have 1 voting right, and the fourth node can have 1 voting right. That is, in the example shown in FIG. 1, the total number of voting rights is 6.

[0049] The first node transmits to other nodes that it owns its public node identifier (for example, public key pk0) and 3 voting rights. Other nodes that receive this data can each calculate 3 public voting identifiers of the first node (ID0, ID0 + 1, ID0 + 2), and the 3 calculated public voting identifiers of the first node are stored in the voting identifier list ID_list. Other nodes also transmit their own public node identifiers and the number of voting rights they have to other nodes in the same way, so the nodes participating in the blockchain can each generate the voting identifier list ID_list shown in FIG. 1.

[0050] In the example shown in FIG. 1, when 4 nodes have a total of 6 voting rights, the nodes exchange their voting right information with each other and generate a voting identifier list ID_list that each contains 6 public voting identifiers.

[0051] Therefore, for each of the second node, the third node, and the fourth node, one public voting identifier is generated, and for the first node, three public voting identifiers are generated. At this time, one of the three public voting identifiers (ID0) for the first node is set to be the same as the public node identifier of the first node (e.g., public key pk0). At this time, another one of the three public voting identifiers (ID0 + 1) for the first node is set to the value obtained by adding 1 to its public node identifier. At this time, yet another one of the three public voting identifiers (ID0 + 2) for the first node is set to the value obtained by adding 2 to the public node identifier of the first node. In particular, when the public key is used as the public node identifier, even if the public voting identifiers generated by adding 1 to the public node identifier one by one are used in this way, the possibility of duplicate public voting identifiers becoming a problem is almost zero. That is, the public voting identifiers ID0 + 1 and ID0 + 2 are values obtained by adding arbitrary values to the public key of the node, and it is almost impossible to find the corresponding private key, which can be said to be arbitrary data. In this way, the voting identifier list ID_list stores the public key of the node and arbitrary data as many as the total number of voting rights.

[0052] At this time, the public voting identifier ID1 for the second node is set to be the same as the public node identifier of the second node (e.g., public key pk1). At this time, the public voting identifier ID2 for the third node is set to be the same as the public node identifier of the third node (e.g., public key pk2). At this time, the public voting identifier ID3 for the fourth node is set to be the same as the public node identifier of the fourth node (e.g., public key pk3).

[0053] As a result, as shown in FIG. 1, a total of six public voting identifiers ID0, ID0+1, ID0+2, ID1, ID2, ID3 for four nodes are stored in the voting identifier list, and this voting identifier list is generated based on the public node identifiers that have been made public to all, so it is independently generated by each node participating in the blockchain. The generated public voting identifiers may be matched one-to-one with the voting rights.

[0054] In the example of FIG. 1, when multiple public voting identifiers are generated from one public node identifier, a method of increasing the public node identifier by a preset number (for example, 1) one by one (the first public voting identifier is set to the public node identifier) is used, but there are also various other ways to generate multiple public voting identifiers from one public node identifier. In particular, when generating multiple public voting identifiers from one public node identifier, it is preferable to use a method that minimizes the possibility of generating duplicate public voting identifiers.

[0055] That is, according to an embodiment of the present invention, each node participating in the blockchain can disclose its own public node identifier (for example, public key) and the number of voting rights it has to other nodes. Therefore, each of all the nodes participating in the blockchain can know the public node identifiers and the number of voting rights of all the nodes participating in the blockchain including itself, so the voting identifier list ID_list shown in FIG. 1 can be generated. At this time, the public voting identifiers included in the voting identifier list ID_list can each correspond to a voting right (vote).

[0056] In the example shown in FIG. 1, when a block to be added to the blockchain is input, data stored in the voting identifier list ID_list can be extracted to generate a passing vote list pass_list. That is, the passing vote list pass_list according to an embodiment of the present invention is generated after the consensus block is completed and can be maintained only for that block.

[0057] In the blockchain consensus process, when the consensus block is completed and stored in the committed message and propagated to all nodes. That is, the chair can propagate the block completed in the COMMIT step of the blockchain consensus process to all nodes in the COMMITTED step. Therefore, each node of the blockchain can generate the voting identifier list ID_list when the consensus block is completed, and when receiving the COMMITTED message in which the consensus block is completed and propagated to all nodes, an operation corresponding to the success probability (p) can be performed using the head value Block_Header of the completed block to generate the passing vote list pass_list.

[0058] That is, the node that receives the block extracts the head value Block_Header of the block and uses it together with the public voting identifier in the voting identifier list ID_list generated as shown in FIG. 1 to perform an operation corresponding to the success probability (p), thereby generating the passing vote list pass_list.

[0059] In the example shown in FIG. 1, Hash() is a hash function that takes the head value Block_Header of the block and the public voting identifier as inputs, and H i (where i is the voting right identifier) is a random value generated by the hash function. At this time, the public voting identifiers are taken one by one from the voting identifier list ID_list, and a hash operation is performed together with the head value Block_Header of the block to obtain H ican be calculated. At this time, H i can be expressed as Hash(Header_B n , ID i ). At this time, Header_B n may represent the Block_Header corresponding to block B shown in Figure 2 n , and ID i may be the public voting identifier corresponding to index i.

[0060] At this time, the hash function may be SHA256 or the like. At this time, the random value H i generated corresponding to the public voting identifier ID i may be a value obtained by extracting only some bits of the output of the hash function. For example, the random value H i may be a value corresponding to some bits (e.g., the lower 32 bits [31:0]) of the 256-bit [255:0] output of the SHA256 function.

[0061] That is, a random value H i corresponding to each voting right is generated, and only the values not greater than a preset threshold T among the generated random values are stored in the passing vote list pass_list in the form of [node number, H i .

[0062] At this time, the threshold T can be any arbitrary value. However, as described in the aforementioned US Published Patent No. 2023-0066169 and the like, the voting (coin toss) success probability p of the node and the size 3f + 1 of the consensus congress can be calculated by applying the following mathematical formulas 1 and 2. At this time, considering the maximum value of the random value H i , a threshold T that satisfies the coin toss success probability p can be calculated.

Equation

Equation

[0063] Threshold value T and random value H i Realize a coin toss with a success probability p through a process (operation) of comparing the magnitudes of all random values H i Perform a coin toss for each, and if the coin toss is successful, add the pair [node number, H i to the passing vote list pass_list.

[0064] In the example shown in FIG. 1, it can be seen that only the random values corresponding to 5 out of 6 voting rights are included in the passing vote list pass_list. That is, among the three public vote identifiers ID0, ID0 + 1, ID0 + 2 for the first node, only the random values H0, H 0+1 corresponding to two of the vote identifiers ID0, ID0 + 1 are successful in the operation (threshold comparison result, random value does not exceed T), and the random value H 0+2 corresponding to one vote identifier ID0 + 2 fails in the operation (threshold comparison result, random value exceeds T). It can be seen that the random values H1, H2, H3 corresponding to the public vote identifiers ID1, ID2, ID3 for the remaining nodes are all successful in the operation (threshold comparison result, random value does not exceed T), and a total of 5 random values H0, H 0+1 , H1, H2, H3 are stored together with the corresponding node numbers in the passing vote list pass_list.

[0065] That is, only the results of successful operations (threshold comparison result, random value does not exceed T) are stored in the passing vote list pass_list in the example of FIG. 1. Therefore, for the first node, [NODE0, H0], which is the result of the operation using the public vote identifier ID0, and [NODE0, H 0+1Two results are stored. For the second node, the result [NODE1, H1] calculated using the public voting identifier ID1 is stored. For the third node, the result [NODE2, H2] calculated using the public voting identifier ID2 is stored. For the fourth node, the result [NODE3, H3] calculated using the public voting identifier ID3 is stored.

[0066] At this time, the result values stored in the passing vote list pass_list are sorted in ascending order of the magnitude of the random values. For example, the result values stored in the passing vote list pass_list are sorted in ascending order according to the magnitude of the random values. In the example shown in FIG. 1, the magnitudes of the random values are H2 < H0 < H3 < H 0+1 <H1. It can be seen that at this time, after the calculations for all public voting identifiers are completed, 3f + 1 nodes can be selected in ascending order from the passing vote list pass_list and defined as a consensus congress.

[0067] FIG. 2 is a diagram showing an example of a distributed consensus method according to an embodiment of the present invention.

[0068] Referring to FIG. 2, it can be seen that a total of four nodes NODE0, NODE1, NODE2, and NODE3 participate in the blockchain, and the total number of voting rights is six (3 for NODE0, 1 for NODE1, 1 for NODE2, and 1 for NODE3).

[0069] Node NODE2 is the chair node for the consensus of block B n and sends a PREPARE message for the consensus of block B n to the consensus committee nodes NODE1, NODE2, and NODE3, receives a COMMIT message from the consensus committee nodes NODE1, NODE2, and NODE3, and after completing the consensus block B n completes the consensus block B nSend committed messages to all nodes NODE0, NODE1, NODE2, NODE3.

[0070] Completed consensus block B n All nodes NODE0, NODE1, NODE2, NODE3 that have received the committed message for can use the block information Header_B for block B n for block B n to form a consensus congress. n+1 That is, as shown in Figure 2, the chairman node NODE2 corresponding to the consensus block B propagates the block B completed in the commit step to all nodes NODE0, NODE1, NODE2, NODE3 in the committed step.

[0071] That is, as shown in Figure 2, the consensus block B n The corresponding chairman node NODE2 propagates the block B completed in the commit step to all nodes NODE0, NODE1, NODE2, NODE3 in the committed step. n to all nodes NODE0, NODE1, NODE2, NODE3 in the committed step.

[0072] Block B n The node that receives block B extracts the head value of block B, performs a hash operation with each of the public voting identifiers included in the voting identifier list to generate a random value, and compares this random value with a preset threshold to generate a passed voting list. n The passed voting list for block B can be calculated by all nodes that have received the committed message corresponding to block B. Information about the members of the consensus of the passed voting list is for block B

[0073] Block B n+1 The passed voting list for block B is for block B n All nodes that have received the committed message corresponding to block B can calculate. Information about the members of the consensus of the passed voting list is for block B n+1It must be maintained to ensure that all nodes that receive the corresponding committed message have signed the block by a valid signer. At this time, the chair may need the consensus member information in the pass-through voting list at all steps of the consensus (CONFIRM, PREPARE, COMMIT, COMMITTED) to form a consensus congress and a consensus committee. If the remaining nodes other than the chair are members of the consensus congress, they need the consensus member information in the pass-through voting list to confirm the chair node and proceed with the consensus, and nodes that are not included in the consensus congress may need the consensus member information in the pass-through voting list to confirm whether the committed block was signed by a node that belongs to the committee.

[0074] At this time, Block B n+1 The passing vote list for block B n is generated only after receiving a committed message corresponding to p, so that the valid pass-through vote list is not maintained for an excessively long time, and a random value used in the coin toss (a calculation with probability of success p) is appropriately generated.

[0075] In the example shown in FIG. n+1 The passing vote list for is [NODE1, H1], [NODE0, H0], [NODE3, H3], [NODE0, H 0+1 ] and [NODE2, H2] are the random values ​​H i In the example shown in FIG. 2, the random values ​​may be sorted in ascending order of their magnitude. <H0<H3< H0+1 <H2であることが分かる。また、図2に示された例において、6個の投票権のうちノードNODE0の3番目投票権に相応するパブリック投票識別子のみコイントスに失敗し、残りのパブリック投票識別子はすべてコイントスに成功したことが分かる。

[0076] At this time, [NODE1, H1] is the operation result corresponding to the random value H1 calculated based on the public voting identifier (1) of node NODE1, [NODE0, H0] is the operation result corresponding to the random value H0 calculated based on the first public voting identifier (for example, the public key of node NODE0) among the three public voting identifiers of node NODE0, [NODE3, H3] is the operation result corresponding to the random value H3 calculated based on the public voting identifier (1) of node NODE3, and [NODE0, H 0+1 is the operation result corresponding to the random value H calculated based on the second public voting identifier (for example, the public key of node NODE0 + 1) among the three public voting identifiers of node NODE0. [NODE2, H2] may be the operation result corresponding to the random value H2 calculated based on the public voting identifier (1) of node NODE2. In the example of Figure 2, the random value H 0+1 calculated based on the third public voting identifier (for example, the public key of node NODE0 + 2) among the three public voting identifiers of node NODE0 cannot pass the threshold comparison (coin toss). 0+2 It can be seen that it cannot pass the threshold comparison (coin toss).

[0077] At this time, B n+1 The consensus body 201 of the block is composed of [NODE1, H1], [NODE0, H0], [NODE3, H3], [NODE0, H 0+1 . At this time, since [NODE1, H1] corresponds to the smallest random value, as shown in Figure 2, node NODE1 may become the chairman node for the consensus of the next block B n+1 .

[0078] In the example of Figure 2, when the consensus of block B n+1 starts, the chairman node NODE1 selects [NODE1, H1], [NODE0, H0], [NODE3, H3] as the consensus committee 202 and sends a PREPARE message to the corresponding nodes NODE1, NODE0, NODE3.

[0079] As described above, in the existing technology, each voting right based on the share of a node could not be exercised individually by the consortium. However, according to an embodiment of the present invention, when selecting a consortium, the voting rights can be divided according to the voting rights of the nodes and exercised for consortium selection.

[0080] Block B n+1 The consensus for Block B is carried out in the process that the chairman node NODE1 receives COMMIT messages from the nodes NODE0, NODE1, and NODE3 corresponding to the consensus committee as shown in FIG. 2, and sends corresponding COMMITTED messages to all nodes.

[0081] Block B n+1 Upon receiving the committed message corresponding to Block B, all nodes can generate a passing vote list corresponding to Block B. That is, the nodes that receive the committed message corresponding to Block B extract the head value of Block B respectively, perform a hash operation with each of the public vote identifiers included in the vote identifier list to generate a random value, compare this random value with a preset threshold, and generate a passing vote list for Block B. n+2 n+1 n+1 n+2

[0082] In the example shown in FIG. 2, the passing vote list for Block B may include [NODE3, H3], [NODE0, H n+2 , [NODE0, H0], [NODE2, H2], and [NODE1, H1] stored in ascending order of the size of the random value H 0+1 i n+2 0+1It can be seen that H0 < H2 < H1. Also, in the example shown in FIG. 2, it can be seen that among the six voting rights, only the public voting identifier corresponding to the third voting right of NODE0 fails the coin toss, and all the remaining public voting identifiers succeed in the coin toss.

[0083] At this time, [NODE3, H3] is the operation result corresponding to the random value H3 calculated based on the public voting identifier (one) of NODE3, and [NODE0, H 0+1 is the operation result corresponding to the random value H 0+1 calculated based on the second public voting identifier (for example, the public key of NODE0 + 1) among the three public voting identifiers of NODE0, [NODE0, H0] is the operation result corresponding to the random value H0 calculated based on the first public voting identifier (for example, the public key of NODE0) among the three public voting identifiers of NODE0, [NODE2, H2] is the operation result corresponding to the random value H2 calculated based on the public voting identifier (one) of NODE2, and [NODE1, H1] may be the operation result corresponding to the random value H1 calculated based on the public voting identifier (one) of NODE1. In the example of FIG. 2, the random value H 0+2 calculated based on the third public voting identifier (for example, the public key of NODE0 + 2) among the three public voting identifiers of NODE0 n+2 cannot pass the threshold comparison (coin toss) when forming the consensus body for block B.

[0084] At this time, the consensus body 205 of block B n+2 is composed of [NODE3, H3], [NODE0, H 0+1 , [NODE0, H0], and [NODE2, H2]. At this time, since [NODE3, H3] corresponds to the smallest random value, as shown in FIG. 2, NODE3 may become the chairman node for the consensus of the next block B n+2 .

[0085] In the example of FIG. 2, block B n+2 starts the agreement, and the chairman node NODE2 selects [NODE3, H3], [NODE0, H 0+1 , [NODE0, H0] as the consensus committee 206, and sends PREPARE messages to the corresponding nodes NODE3 and NODE0.

[0086] Existing distributed consensus technologies such as the distributed consensus method using the Nano chain require that the node that has succeeded in the coin toss create a message to prove that it has succeeded in the coin toss and send it to other nodes. Other nodes had no choice but to confirm that the node had succeeded in the coin toss based on the message received from a specific node and form a consensus body.

[0087] However, according to the present invention, using a public node identifier assigned to each node such as a public key, all nodes can generate the same passing vote list for a specific block. Therefore, it is possible to easily confirm which node formed the consensus body without another message for consensus body formation, and thus the consensus efficiency can be maximized.

[0088] That is, according to the present invention, even if a distributed node connected to the blockchain does not receive a new consensus body-related message from other nodes, it can calculate the formation of the consensus body of the next block by itself. The nodes participating in the consensus can independently calculate the values for the selection of the consensus body of the next block for each node from the public vote identifiers of all participating nodes and the data extracted from the current block, and calculate the consensus body of the next block.

[0089] FIG. 3 is a diagram showing another example of the distributed consensus method according to an embodiment of the present invention.

[0090] Referring to FIG. 3, it can be seen that a total of five nodes, NODE0, NODE1, NODE2, NODE3, and NODE4, participate in the blockchain, and the total number of voting rights is five (one for each node). That is, FIG. 3 shows the process of forming a random consensus body without the exchange of additional messages for consensus formation when all participating nodes have a share of 1, and the process by which they reach an agreement.

[0091] The example in FIG. 3 may correspond to the process of initial block generation after the participating nodes participating in the blockchain share their public node identifiers and the number of voting rights they hold with each other. At this time, before the process shown in FIG. 3 is carried out, the setup of a set of voting right identifier lists including public voting right identifiers may be completed.

[0092] In the example shown in FIG. 3, for the sake of convenience of explanation, assuming that all nodes each have one voting right, the protocol for initial block generation and the consensus process has been described. However, as described above, each node may have multiple voting rights. When some nodes participate in the consensus body with multiple voting rights, if only one message for consensus is transmitted and the consensus count uses the count included in the committee, efficient consensus is possible.

[0093] Initial block B init In the consensus process for the initial block B, the node NODE0 arbitrarily selected as the chairman for the consensus of the initial block alone goes through steps such as PREPARE and COMMIT, signs the block to create the initial block, and transmits this to all nodes NODE0, NODE1, NODE2, NODE3, and NODE4.

[0094] As shown in FIG. 3, the consensus process goes through four stages. In the consensus process for the initial block B init since only the node NODE0 participates in the consensus body, the PREPARE and COMMIT steps are carried out inside the node NODE0. In this process, using the private key of the node NODE0, the initial block Binit A signature is made for it, and the final block with the signature completed is transmitted to all nodes NODE0, NODE1, NODE2, NODE3, NODE4 in the COMMITTED step. In the example of FIG. 3, EC-schnorr multi-signature can be used for consensus. Multi-signature in the consensus process and the like are disclosed in detail in the above-mentioned US Patent Publication No. 2020-0403776 and the like.

[0095] In the CONFIRM step, each node verifies the signature of the initial block B init and if there is a problem, since the consensus has failed, the re-consensus protocol is advanced. If there is no problem with the verification result, using the voting identifier stored in the stored node's voting identifier list ID_list and the header value of the initial block B init as described with reference to FIG. 1, a passed vote list pass_list is generated. As described above, all nodes that have received the committed message can generate a passed vote list.

[0096] In the example of FIG. 3, assuming that 5 nodes NODE0, NODE1, NODE2, NODE3, NODE4 participate with one voting right each, p that satisfies the above formulas 1 and 2 is 1.0 and f is 1. All [node number, H i pairs that satisfy the threshold comparison condition are added to the passed vote list pass_list, and 4 nodes are selected as the consensus body in ascending order of H among them. In the example of FIG. 3, even if all 5 voting rights pass the threshold comparison and 5 [node number, H i pairs are stored in ascending order in the passed vote list pass_list. At this time, from the stored values, the result values for 4 nodes NODE2, NODE0, NODE4, NODE3 which are 3f + 1 are selected as corresponding to the consensus body. Therefore, the next block B i is selected. init+1The consensus nodes for the consensus are node NODE2, node NODE0, node NODE4, and node NODE3, and among them, the smallest H i corresponding node NODE2 becomes the chairman node of block B init+1 .

[0097] Figure 3 shows an example where nodes NODE2, NODE0, NODE4, and NODE3 are selected as a consensus body to proceed with the consensus. This process is carried out by all distributed nodes, and since the operation (coin toss) results of all nodes that have confirmed the same initial block B init are the same, all nodes can form the same consensus body without exchanging messages between the nodes for forming the consensus body.

[0098] Referring to Figure 3 again, in the CONFIRM step, the nodes NODE2, NODE0, NODE4, and NODE3 selected for the consensus body of the next block each generate a random k i and generate Q i on the elliptic curve. Each node included in the consensus body transmits the checksum of its received block header and Q i to node NODE2, which is the chairman node of the next block B init+1 , so as to confirm the consensus result of the initial block B init and prepare for the consensus of the next block. At this time, the checksum and Q i are transmitted together with the signature of node i to ensure integrity. At this time, the nodes selected for the consensus body transmit the unprocessed transactions to the chairman node so that the chairman can process them.

[0099] Node NODE2, which is the chairman of block B init+1 , arbitrarily selects 2f + 1 from the nodes that have submitted the checksum and Q i , checks whether the checksums of the selected nodes are the same as each other, and checks whether the nodes have the same block B initVerify that it has been received and proceed with consensus with these 2f + 1 nodes. In the example shown in Figure 3, for block B init+1 The node NODE2, which is the leader of, selects 3 (2f + 1) of the 4 (3f + 1) consensus nodes NODE2, NODE0, NODE4, NODE3, namely the committee nodes NODE2, NODE0, NODE3, verifies that the checksums of nodes NODE2, NODE0, NODE3 are the same, and proceeds with consensus with nodes NODE2, NODE0, NODE3.

[0100] As can be seen from Figure 3, the initial block B init The leader who started is node NODE0, but the node NODE2, which is the leader of the next block B init+1 can finally verify the consensus result of the initial block B init .

[0101] Block B init+1 In the PREPARE step of, node NODE2 generates a preliminary block including the transactions it received from the guest or the transactions transmitted from nodes in the CONFIRM step of block B init . At this time, for consensus, generate a PREPARE message (including the prepare block) by including in the block the public keys of nodes NODE2, NODE0, NODE3 respectively, Pk combined with Q i and Q and r values, and transmit this to nodes NODE2, NODE0, NODE3. Nodes NODE2, NODE0, NODE3 that receive the PREPARE message verify the presence or absence of block anomalies. If there are no anomalies, generate s i signed with their own private key and send a COMMIT message back to the leader node NODE2. The leader node NODE2 that has received all the COMMIT messages combines s i to generate S, then completes the signature (r, S) to generate a COMMITTED block and transmits it to all nodes.

[0102] Upon receiving a committed block, each node checks the public keys and signatures corresponding to 2f + 1 nodes in the consensus group to verify the validity of the block. If the verification result is valid, for block B init+1 calculate H with the header value of i and can create the following passing vote list, and can form the consensus group for block B init+2 In the example of Figure 3, nodes NODE4, NODE3, NODE1, and NODE2 form a consensus group and send a confirmation message to node NODE4, which is the leader of block B init+2 That is, in the confirm (CONFIRM) step of block B init+1 nodes NODE4, NODE3, NODE1, and NODE2 each transmit the checksum and Q i to node NODE4 to complete the consensus for block B init+1 Then, for block B init+1 the consensus for block B init+2 can be advanced through the process as described above.

[0103] Figure 4 is a diagram showing yet another example of the distributed consensus method according to an embodiment of the present invention.

[0104] Referring to Figure 4, it can be seen that node NODE5 is added as a participating node in addition to the existing five nodes NODE0, NODE1, NODE2, NODE3, and NODE4.

[0105] That is, throughout Figure 4, when node NODE5 is added as a participating node at the consensus time of block B n it can be seen that node NODE5 can normally participate in the consensus group from the consensus of block B n+1 (node addition process).

[0106] In the example of Figure 4, for block B nAssume that the intention of Node NODE5 to participate in the consensus is transmitted to Node NODE3, which is the chairman. Node NODE5 first connects to the network where the consensus is in progress and collects information on the nodes that have currently participated in the consensus. After receiving the information about the consensus nodes and the public node identifier (e.g., public key), it creates a list of voting identifiers ID_list that includes the public voting identifier based on this, and transmits its intention to participate in the consensus to other nodes. Block B n-1 The nodes that receive information about the newly joined node at the time corresponding to Block B n can each transmit the content to Node NODE3, which is the chairman, at the time corresponding to Block B n Node NODE3 can include the content in the transaction for the joint discussion to advance the consensus. At this time, the block for which the commit step has been completed may include information about the newly joined node. Therefore, when the commit step is completed, Node NODE3, which is the chairman, can add the public voting identifier of Node NODE5 to its list of voting identifiers ID_list. Node NODE3, which is the chairman, can transmit the blocks generated by all nodes in the committed step. All nodes that receive the committed message add the public voting identifier of Node NODE5, which is the new node, to their list of voting identifiers ID_list respectively. Therefore, from the confirm step of Block B

[0107] Block B n+1 In the consensus step of Block B, Node NODE2, which is the chairman node, reaches a consensus on the new block through prepare and commit, and propagates the completed block to all nodes. That is, a new node can participate in the consensus through the process shown in Figure 4.

[0108] FIG. 5 is an operation flowchart showing an example of a process in which a public vote identifier is generated from a public node identifier according to an embodiment of the present invention.

[0109] Referring to FIG. 5, it can be seen that a public key is used as an example of the public node identifier of the node, and a public vote identifier is generated based on the public key of the node and included in the vote identifier list ID_list.

[0110] The steps shown in FIG. 5 show a process of generating one or more public vote identifiers using the public node identifier of a specific node. Each step shown in FIG. 5 is performed for each public node identifier. Through the process shown in FIG. 5, public vote identifiers equal to the number of voting rights of the node are generated for a specific public node identifier (for example, a public key).

[0111] First, in step S510, variables for generating a public vote identifier are initialized. That is, in step S510, the variable loop is set to a value corresponding to the number of voting rights (NUMBER OF VOTES) of the node, the variable count is set to 0, and the vote identifier list ID_list is initialized.

[0112] Thereafter, in step S520, the variable count and the variable loop are compared. If, as a result of the comparison in step S520, count is smaller than loop, a public vote identifier corresponding to the value obtained by adding the variable count to the public key (PUBLIC KEY, public node identifier) of the node is added to the vote identifier list ID_list (S530). As shown in FIG. 5, the node number may be stored in the vote identifier list ID_list together with the public vote identifier.

[0113] In step S530, when a public vote identifier is added, the variable count is incremented by 1 (S540), and then it returns to step S520 again to compare the variable count and the variable loop.

[0114] If the comparison result in step S520 shows that count is not less than loop, the process of generating the voting identifier for the node ends.

[0115] Through the process shown in FIG. 5, corresponding public voting identifiers (public key, public key + 1, public key + 2,..., public key + number of voting rights - 1) for a specific node are generated according to the corresponding number of voting rights.

[0116] In the example of FIG. 5, the case where a preset number is added to the public node identifier to generate the public voting identifier is taken as an example. However, the method of generating public voting identifiers for the number of voting rights from the public node identifier can be in various forms.

[0117] At this time, the public voting identifier is generated by a voting identifier generator (function). In the example shown in FIG. 5, the voting identifier generator can be a function that adds count, which increases by 1 each time, to the input public node identifier (public key).

[0118] The voting identifier generator (function) can be a function in various forms that receives the public node identifier as input and outputs public voting identifiers for the number of voting rights. At this time, the voting identifier generator can include a duplicate checker that checks for duplicates of the generated public voting identifiers. At this time, the duplicate checker can check not only for duplicates between the generated public voting identifiers and other voting identifiers, but also for duplicates between the generated public voting identifiers and the public node identifiers corresponding to other nodes.

[0119] In this way, when generating public voting identifiers for the number of voting rights of one node and using them for coin toss, parallel execution of coin toss is possible compared to the method of hashing the result of one coin toss at a specific node and then performing the next coin toss, and the computing speed for consensus selection is increased.

[0120] The public voting identifier generated by the voting identifier generator may ultimately be a unique identifier corresponding to the voting rights of each node, and the number of bits indicating the public voting identifier and the number of bits indicating the public node identifier may be the same as or different from each other.

[0121] FIG. 6 is a diagram showing an example of using a passed vote list in a distributed consensus method according to an embodiment of the present invention.

[0122] Referring to FIG. 6, it can be seen that the passed vote lists 601 generated by the nodes NODE0, NODE1, NODE2, and NODE3 that received the committed block of block B n are the same. At this time, the nodes NODE0, NODE1, NODE2, and NODE3 can each confirm whether they are included in the consensus body with the node NODE1 as the chairman.

[0123] Node NODE0 confirms that from the passed vote list, [NODE1, H1], [NODE0, H0], [NODE3, H3], [NODE0, H 0+1 up to are selected as the consensus body, and confirms that the result value corresponding to itself ([NODE0, H0]) is located second on the passed vote list, thereby confirming that it is selected into the consensus body. At this time, node NODE0 can see that node NODE1 has become the chairman based on the first result value ([NODE1, H1]) of the passed vote list. Furthermore, node NODE0 confirms that the result value corresponding to itself ([NODE0, H 0+1 ) is located fourth on the passed vote list, thereby confirming that it has two voting rights in the consensus body.

[0124] Node NODE1 confirms that from the passed vote list, [NODE1, H1], [NODE0, H0], [NODE3, H3], [NODE0, H 0+1 up to are selected as the consensus body, and based on the first result value ([NODE1, H1]), it can be seen that it is selected into the consensus body and that it has become the chairman.

[0125] Node NODE2 confirms that from the passing vote list, [NODE1, H1], [NODE0, H0], [NODE3, H3], [NODE0, H 0+1 up to has been selected as the consensus body, and can confirm that its corresponding result value ([NODE2, H2]) is not included in the consensus body. At this time, Node NODE2 can see that Node NODE1 has become the chairman based on the first result value ([NODE1, H1]) in the passing vote list.

[0126] Node NODE3 confirms that from the passing vote list, [NODE1, H1], [NODE0, H0], [NODE3, H3], [NODE0, H 0+1 up to has been selected as the consensus body, and can confirm that its corresponding result value ([NODE3, H3]) is located at the third position on the passing vote list, and can confirm that it has been selected into the consensus body. At this time, Node NODE3 can see that Node NODE1 has become the chairman based on the first result value ([NODE1, H1]) in the passing vote list.

[0127] Since Node NODE1 is the chairman, it receives CONFIRM messages from the consensus nodes NODE0, NODE1, and NODE3.

[0128] Nodes NODE0 and NODE3 confirm that although they are not the chairman, they are included in the consensus body, and send CONFIRM messages to Node NODE1.

[0129] The chairman constitutes the consensus committee among the consensus congress. In the example shown in FIG. 6, it can be seen that Node NODE1, Node NODE0, and Node NODE3 have been selected into the committee. At this time, the second public vote identifier ID of Node NODE0 0+1 corresponding result value ([NODE0, H 0+1)) is included in the consensus body but not in the committee.

[0130] If the chairperson configures nodes NODE1, NODE0, and NODE3 as the committee as shown in Figure 6, when the chairperson combines the public keys, Pk which is the combination of the public keys of nodes NODE1, NODE0, and NODE3 103 is used to generate r 103 and this is provided to the committee nodes.

[0131] If the chairperson, different from that shown in Figure 6, forms the committee with [NODE1, H1], [NODE0, H0], [NODE0, H 0+1 among the result values corresponding to the consensus body, when the chairperson combines the public keys, Pk which is the combination of the public keys of nodes NODE1 and NODE0 10 is used to generate r 10 and this is provided to the committee nodes.

[0132] Therefore, since the Pk and r generated by the composition of the committee are different, the members of the committee use the received r to generate s i in a state where they don't know who among them signs, and the chairperson cannot create two multi-signatures simultaneously.

[0133] However, in order for the chairperson to confirm whether to complete the consensus by receiving 2f + 1 signatures, it is necessary to inform the committee nodes of which nodes belong to the committee (603). At this time, since all nodes have the passing vote list pass_list, the chairperson node is assigned number 0, and numbers are assigned in order according to the position on the passing vote list, and the composition information of the committee can be represented by a bitmap and transmitted.

[0134] As shown in Figure 6, the chairperson maintains the committee with the passing vote list pass_list to confirm the members of the signed committee (604).

[0135] When the multi-signature is completed, the block that has reached an agreement in the committed block is transmitted. At this time, the committee composition information is provided and used to verify the nodes that have signed on the passing vote list pass_list (605).

[0136] Furthermore, the node regenerates the passing vote list pass_list for the formation of the quorum for the next block B n+2 using the received block.

[0137] FIG. 7 is an operation flowchart showing an example of a distributed consensus method according to an embodiment of the present invention.

[0138] Referring to FIG. 7, a distributed consensus method according to an embodiment of the present invention generates a public vote identifier using a public node identifier corresponding to a node constituting a blockchain (S710).

[0139] At this time, the public vote identifier is generated for each of the nodes by using the public node identifier corresponding to each of the nodes, with the number of voting rights of each of the nodes.

[0140] At this time, the public vote identifier is generated by adding or subtracting 1 from the generated values including 0 to the public node identifier corresponding to each of the nodes.

[0141] At this time, the public node identifier may be a public key corresponding to the node.

[0142] Also, a distributed consensus method according to an embodiment of the present invention performs an operation corresponding to the success probability (p) for each of the public vote identifiers to generate a passing vote list (S720).

[0143] At this time, the passing vote list is generated by each node constituting the blockchain performing the operation for the node including itself based on the public vote identifier. At this time, the passing vote lists generated by the nodes constituting the blockchain at a specific timing may be the same as each other.

[0144] At this time, the operation may be to compare a random value generated using the public vote identifier and the previous block information with a threshold corresponding to the success probability.

[0145] Also, the distributed consensus method according to an embodiment of the present invention performs distributed consensus based on at least a part of the consensus nodes corresponding to the passing vote list (S730).

[0146] At this time, the consensus nodes are selected from among the nodes included in the passing vote list.

[0147] At this time, the consensus on the previous block corresponding to the previous block information is finally confirmed by a chair node selected from among the consensus nodes for the current block.

[0148] At this time, the node among the consensus nodes having the largest or smallest value corresponding to the result of the operation may become the chair node.

[0149] The distributed consensus method shown in FIG. 7 is performed by a distributed consensus device. The distributed consensus device can be realized with the configuration shown in FIG. 9.

[0150] FIG. 8 is an operation flowchart showing an example of a blockchain generation method according to an embodiment of the present invention.

[0151] Referring to FIG. 8, the blockchain generation method according to an embodiment of the present invention receives a COMMITTED message corresponding to the previous block (S810).

[0152] Further, the blockchain generation method according to an embodiment of the present invention generates a passing vote list using the information regarding the previous block and the public vote identifier (S820).

[0153] At this time, the passing vote list is generated by each node constituting the blockchain performing an operation corresponding to the success probability (p) on the node including itself based on the public vote identifier. At this time, the passing vote lists generated by the nodes constituting the blockchain at a specific timing may be the same as each other.

[0154] At this time, the operation may be to compare a random value generated using the public vote identifier and the information regarding the previous block with a threshold corresponding to the success probability.

[0155] At this time, the public vote identifier is generated for each of the nodes by using the public node identifier corresponding to each of the nodes, in the number of voting rights of each of the nodes.

[0156] Further, the blockchain generation method according to an embodiment of the present invention is such that a chair node corresponding to the current block receives a CONFIRM message from a consensus node corresponding to the passing vote list, and finally confirms the consensus result of the previous block based on the CONFIRM message (S830). At this time, the chair node is recognized based on the passing vote list.

[0157] Further, the blockchain generation method according to an embodiment of the present invention is such that the chair node transmits a PREPARE message for connecting the current block to the blockchain to a committee node selected from among the consensus nodes (S840).

[0158] Furthermore, in the blockchain generation method according to an embodiment of the present invention, the chair node receives a COMMIT message from the committee node (S850).

[0159] Also, in the blockchain generation method according to an embodiment of the present invention, the chair node transmits a COMMITTED message corresponding to the current block to all nodes (S860).

[0160] FIG. 9 is a block diagram showing the configuration of a computer system according to an embodiment of the present invention.

[0161] The distributed consensus device, the blockchain generation device, and the nodes constituting the blockchain according to the embodiment are realized in a computer system 900 such as a computer-readable recording medium.

[0162] The computer system 900 can include one or more processors 910 that communicate with each other via a bus 920, a memory 930, a user interface input device 940, a user interface output device 950, and a storage 960. Further, the computer system 900 can further include a network interface 970 connected to a network 980. The processor 910 may be a semiconductor device that executes a program or processing instruction stored in the central processing unit or the memory 930 and the storage 960. The memory 930 and the storage 960 may be a storage medium including at least one or more of a volatile medium, a non-volatile medium, a separable medium, a non-separable medium, a communication medium, or an information transmission medium. For example, the memory 930 can include a ROM 931 and a RAM 932.

[0163] At this time, at least one program is recorded in the memory 930.

[0164] At this time, the processor 910 can execute the program. At this time, the program generates a public voting identifier using the public node identifier corresponding to the nodes constituting the blockchain, and for each public voting identifier, performs an operation corresponding to the success probability (p) to generate a passed voting list, and can perform distributed consensus based on at least a part of the consensus body nodes corresponding to the passed voting list.

[0165] At this time, the passed voting list is generated by each of the nodes constituting the blockchain performing the operation for the node including itself based on the public voting identifier. At this time, the passed voting lists generated by the nodes constituting the blockchain at a specific timing may be the same as each other.

[0166] At this time, the operation may be to compare a random value generated using the public voting identifier and the previous block information with a threshold corresponding to the success probability.

[0167] At this time, the public voting identifier is generated for each of the nodes by adding or subtracting 1 from among the generated values including 0 to the public node identifier corresponding to each of the nodes.

[0168] At this time, the consensus body nodes are selected from among the nodes included in the passed voting list.

[0169] At this time, the consensus on the previous block corresponding to the previous block information is finally confirmed by a chair node selected from among the consensus body nodes for the current block.

[0170] At this time, the public voting identifier is generated by adding or subtracting 1 to the public node identifier corresponding to each of the nodes from among the generated values including 0.

[0171] At this time, the public node identifier may be the public key corresponding to the node.

[0172] At this time, among the consensus nodes, the node with the largest or smallest value corresponding to the result of the operation may become the chair node.

[0173] As described above, the distributed consensus method, apparatus, and blockchain generation method according to the present invention are not limited to the configurations and methods of the embodiments described above, and all or part of each embodiment may be selectively combined and configured so that various modifications can be made to the above embodiments.

Description of Reference Numerals

[0174] 900: Computer system 910: Processor 920: Bus, 930: Memory 931: ROM, 932: RAM 940: User interface input device 950: User interface output device 960: Storage, 970: Network interface 980: Network

Claims

1. A distributed consensus method performed by a distributed consensus device, generating a public voting identifier using a public node identifier corresponding to a node that constitutes the blockchain; performing an operation corresponding to a probability of success (p) for each public vote identifier to generate a passing vote list; performing distributed consensus based on at least a portion of the consensus nodes corresponding to the passing vote list; A distributed consensus method, comprising:

2. The passing vote list is: Each of the nodes constituting the blockchain performs the calculation for the nodes including itself based on the public vote identifier, and the passing vote lists generated by the nodes constituting the blockchain at a specific timing are identical to each other.

2. The method of claim 1 .

3. The operation is to compare a random value generated using the public vote identifier and previous block information with a threshold corresponding to the probability of success. The method of claim 2 .

4. The public voting identifier is: A public node identifier corresponding to each of the nodes is used to generate a number of voting rights for each of the nodes; The method of claim 3 .

5. The consensus node is selected from among the nodes included in the pass-through voting list. The method of claim 4 .

6. The consensus for the previous block corresponding to the previous block information is finally confirmed by a chair node selected from the consensus nodes for the current block; The method of claim 5 .

7. The public voting identifier is: A public node identifier corresponding to each of the nodes is generated by adding or subtracting 1 from a generated value including 0, The method of claim 5 .

8. The public node identifier is a public key corresponding to the node; The method of claim 7 .

9. Among the consensus nodes, a node having a value corresponding to the result of the operation that is the largest or smallest becomes a chair node; The method of claim 3 .

10. one or more processors; an execution memory for storing at least one program to be executed by said one or more processors; Including, The at least one program is Generate a public voting identifier using a public node identifier corresponding to a node that constitutes the blockchain; For each public vote identifier, an operation corresponding to a success probability (p) is performed to generate a passing vote list; performing distributed consensus based on at least a portion of the consensus nodes corresponding to the passing vote list; Distributed consensus device.

11. The passing vote list is: Each of the nodes constituting the blockchain performs the calculation for the nodes including itself based on the public vote identifier, and the passing vote lists generated by the nodes constituting the blockchain at a specific timing are identical to each other.

11. The distributed consensus apparatus of claim 10.

12. The operation is to compare a random value generated using the public vote identifier and previous block information with a threshold corresponding to the probability of success.

12. The distributed consensus apparatus of claim 11.

13. The public voting identifier is: A public node identifier corresponding to each of the nodes is used to generate a number of voting rights for each of the nodes; 13. The distributed agreement apparatus of claim 12.

14. The consensus node is selected from among the nodes included in the pass-through voting list.

14. The distributed consensus apparatus of claim 13.

15. The consensus for the previous block corresponding to the previous block information is finally confirmed by a chair node selected from the consensus nodes for the current block; 15. The distributed agreement apparatus of claim 14.

16. A computer device corresponding to a node of the blockchain, receiving a COMMITTED message corresponding to a previous block; generating a passing vote list using the information about the previous block and the public vote identifier; A chair node corresponding to a current block receives a CONFIRM message from a consensus node corresponding to the pass-through vote list, and finally confirms the consensus result of the previous block based on the CONFIRM message (the chair node is recognized based on the pass-through vote list); The chair node sends a prepare message to a committee node selected from among the consensus nodes to link the current block to the blockchain; A method for generating a blockchain.

17. The chair node is receiving a COMMIT message from the committee node; The chair node sends a COMMITTED message corresponding to the current block to all nodes; 17. The blockchain generation method of claim 16, further comprising:

18. The passing vote list is: Each of the nodes constituting the blockchain performs an operation corresponding to a success probability (p) for the nodes including itself based on the public vote identifier, and the passing vote lists generated by the nodes constituting the blockchain at a specific timing are identical to each other.

20. The method of claim 17, wherein the block chain is generated.

19. The operation compares a random value generated using the public vote identifier and information about the previous block to a threshold corresponding to the probability of success.

20. The method of claim 18, wherein the block chain is generated by

20. The public voting identifier is: A public node identifier corresponding to each of the nodes is used to generate a number of voting rights for each of the nodes; 20. The method of claim 19 .

Images