Distributed consensus method and device using public node identifier 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 a blockchain distributed consensus technology, and in particular to a technology for selecting random nodes as consensus bodies on a block-by-block basis and enabling these consensus bodies to reach an agreement to add a new block to the chain. [Background technology]

[0002] Generally, as the number of participating nodes in a blockchain increases, the time it takes to confirm a block also increases. One way to overcome this is to select a portion of all nodes as a consensus congress and have this consensus congress confirm new blocks, thereby shortening the block confirmation time. In this case, if a fixed node is used as the consensus congress, a problem of centralization occurs, and to prevent this, a method of selecting a random node as the consensus congress has been used. In addition to the existing method of selecting a random node as the consensus congress, a distributed consensus technology has been introduced that randomly selects a node from all nodes using a Verifiable Random Function (VRF) or randomly selects nodes that make up the consensus congress using a nonce chain.

[0003] In distributed consensus technology using VRF, each node performs calculations corresponding to the VRF, and depending on the results, it is decided whether or not to select a consensus body. The node selected as the consensus body submits the node's voting results along with evidence. However, the disadvantage of this method is that the size of the consensus body can only be known as a probability distribution, and it is not possible to know exactly how many nodes will be selected as the consensus body. Therefore, since it is not possible to know exactly how many nodes make up the majority or two-thirds of the consensus body, a complicated consensus process must be carried out.

[0004] The paper "Algorithm based on Byzantine agreement among decentralized agents (BADA)" published on October 20, 2020, US Patent Publication No. 2019-0327084, US Patent Publication No. 2019-0379538, US Patent Publication No. 2020-0403776, and US Patent Publication No. 2023-0066169 disclose in detail a nonce chain-based consensus selection method and a blockchain generation method using the same. The technology disclosed in the paper and patent can determine the size of the consensus according to the number of participating nodes, and once the consensus is determined, it is possible to know how many nodes are the majority or two-thirds, so 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 to determine the consensus.

[0005] The message transmission protocol for determining the consensus involves the process of exchanging messages between nodes for consensus formation, which places a heavy burden on the system as the number of nodes participating in the blockchain increases. Therefore, there is a pressing need for a new blockchain consensus technology that can reduce or eliminate the exchange of messages for consensus formation. Summary of the Invention [Problem to be solved by the invention]

[0006] The objective of the present invention is to construct a blockchain consensus by selecting a number of random nodes corresponding to the size of the consensus determined according to the number of participating nodes while minimizing the exchange of messages for constructing the consensus.

[0007] In addition, the objective of the present invention is to reduce the message complexity of the blockchain system, improve performance, and maintain decentralization by having a randomly selected consensus body for each block reach a consensus using a simple consensus algorithm such as PBFT without exchanging messages to form a consensus body using a public node identifier. [Means for solving the problem]

[0008] In order to achieve the above object, the distributed consensus method performed by the distributed consensus device of the present invention includes the steps of generating public vote identifiers using public node identifiers corresponding to nodes that constitute a blockchain, performing an operation corresponding to a success probability (p) for each of the public vote identifiers to generate a pass vote list, and performing distributed consensus based on at least a portion of the consensus body nodes corresponding to the pass vote list.

[0009] At this time, the passing vote list is generated by each of the nodes constituting the blockchain performing the calculation for 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 identical to each other.

[0010] In this case, 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 probability of success.

[0011] At this time, the public vote identifiers are generated for each of the nodes by using a public node identifier corresponding to each of the nodes, the number of votes being equal to the number of votes of each of the nodes.

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

[0013] At this time, 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.

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

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

[0016] In this case, the node having the largest or smallest value corresponding to the result of the calculation among the consensus nodes may become a chair node.

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

[0018] In this case, the at least one program generates public voting identifiers using public node identifiers corresponding to the nodes that constitute the blockchain, performs an operation corresponding to a success probability (p) for each public voting identifier to generate a passing vote list, and performs distributed consensus based on at least a portion of the consensus nodes corresponding to the passing vote list.

[0019] At this time, the passing vote list is generated by each of the nodes constituting the blockchain performing the calculation for 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 identical to each other.

[0020] In this case, 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 probability of success.

[0021] At this time, the public vote identifiers are generated for each of the nodes by using a public node identifier corresponding to each of the nodes, the number of votes being equal to the number of votes of each of the nodes.

[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 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.

[0024] In addition, a blockchain generation method according to one embodiment of the present invention includes the steps of receiving a COMMITTED message corresponding to a previous block, generating a pass-through vote list using information about the previous block and a public vote identifier, a chair node corresponding to a current block receiving a CONFIRM message from a consensus node corresponding to the pass-through vote list and finally confirming the consensus result of the previous block based on the CONFIRM message (the chair node is recognized based on the pass-through vote list), and the chair node sending a PREPARE message to a committee node selected from the consensus nodes to link the current block to the blockchain.

[0025] At this time, the blockchain generation method according to one embodiment of the present invention may further include a step of the chair node receiving a COMMIT message from the committee node, and a 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 of the nodes constituting the blockchain performing an operation corresponding to the success probability (p) for 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 identical to each other.

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

[0028] At this time, the public vote identifiers are generated for each of the nodes by using a public node identifier corresponding to each of the nodes, the number of votes being equal to the number of votes of each of the nodes. Effect of the Invention

[0029] According to the present invention, all blockchain nodes, including the chair node, can know which nodes have been selected for the consensus, how many there are, and who the chair is before receiving a message regarding whether other nodes have been selected as the consensus, so that consensus can proceed immediately without exchanging messages related to the consensus formation.

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

[0031] In addition, the present invention reduces the message complexity of the blockchain system, improves performance, and maintains decentralization by allowing a randomly selected consensus body for each block to reach a consensus using a simple consensus algorithm such as PBFT without exchanging messages to form a consensus body using a public node identifier.

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

[0033] Furthermore, the present invention eliminates the need for message exchange for constructing an agreement, thereby reducing the increase in protocol complexity and delay.

[0034] In addition, the present invention can easily configure a consensus whose size is determined according to the number of participating nodes without exchanging consensus configuration messages, and can be applied to existing simple consensus algorithms. [Brief description of the drawings]

[0035] [Figure 1] FIG. 13 is a diagram illustrating an example of a process for generating a passing vote list from a public vote identifier according to an embodiment of the present invention. [Diagram 2] FIG. 2 illustrates an example of a distributed consensus method according to an embodiment of the present invention. [Diagram 3] FIG. 13 is a diagram illustrating another example of a distributed consensus method according to an embodiment of the present invention. [Figure 4] FIG. 13 is a diagram illustrating yet another example of a distributed consensus method according to an embodiment of the present invention. [Diagram 5]1 is an operational flowchart illustrating an example of a process in which a public voting identifier is generated from a public node identifier according to an embodiment of the present invention. [Figure 6] FIG. 13 is a diagram showing an example of the use of a pass vote list in a distributed consensus method according to one embodiment of the present invention. [Figure 7] 1 is an operational flowchart illustrating an example of a distributed consensus method according to an embodiment of the present invention. [Figure 8] 1 is an operational flowchart showing an example of a blockchain generation method according to an embodiment of the present invention. [Figure 9] 1 is a block diagram showing a configuration of a computer system according to an embodiment of the present invention; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0036] The advantages and features of the present invention, as well as the methods for achieving them, will become clear from the following detailed description of the embodiments in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, and may be realized in various different forms. The embodiments are provided solely to complete the disclosure of the present invention and to fully inform those skilled in the art of the present invention of the scope of the invention, and the present invention is defined solely by the scope of the claims. The same reference numerals refer to the same elements throughout the specification.

[0037] Although "first" or "second" is 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 referred to below may be the second component within the technical spirit of the present invention.

[0038] The terms used in the present specification are for describing the embodiments and are not intended to limit the present invention. In the present specification, the singular form includes the plural form unless otherwise specified in the text. The term "comprises" or "comprising" used in the specification includes the meaning that the mentioned component or step does not exclude the presence or addition of one or more other components or steps.

[0039] Unless otherwise defined, all terms used in this specification are to be interpreted in a manner commonly understood by those having ordinary skill in the art to which the present invention pertains. Furthermore, terms defined in commonly used dictionaries are not to be interpreted ideally or excessively unless otherwise clearly defined.

[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 designated by the same reference numerals, and duplicate descriptions thereof will be omitted.

[0041] In the above-mentioned existing technology, in the process of forming a consensus congress, the chair node cannot know how many nodes are selected as candidates for the consensus congress before receiving a message regarding whether other nodes have been selected as a consensus congress. Therefore, the chair node in the existing technology sets a threshold time for forming a consensus congress and waits until 3f+1 (f is the Byzantine size and is an integer equal to or greater than 1) nodes respond, and when the threshold time expires, if the number of nodes forming the consensus congress is less than 3f+1, an exception handling process is required to handle this. However, according to the present invention, all nodes can know how many nodes have succeeded in the coin toss operation, who is the chairperson, and who are the nodes forming the consensus congress, and the consensus can proceed immediately without exchanging messages related to the formation of the consensus congress.

[0042] It can be assumed that a participating node that participates in the blockchain to start a block agreement is connected to the network. In general, the node uses public key-based encryption for the integrity of transmitted data, and for this purpose, the blockchain node x uses its private key sk x From public key pk x Then, node x can generate its private key sk and share its public key with other nodes connected to the network. x Data can be securely transmitted using the public key pk of node x. x 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 publicly disclosed to other nodes and can identify a specific node. In this case, the public node identifier may be an identifier of a specific node that other nodes know or can know. In this case, the public node identifier is shared from the node to other nodes and is transmitted by information included in a message sent 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 the stake held. In the present invention, a blockchain node can have a number of votes greater than 1, and a consensus body is selected based on the results of a calculation corresponding to the success probability p for the number of votes corresponding to the votes. For example, if a particular node has two votes and succeeds in a calculation corresponding to the success probability p for at least one of the two votes, it becomes a consensus body candidate.

[0044] FIG. 1 is a diagram illustrating an example of a process for generating a passing vote list from a public vote identifier according to an embodiment of the present invention.

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

[0046] The public vote identifiers may be identifiers corresponding to each vote (or coin toss) and are generated from the public node identifier. In this case, public vote identifiers are generated for each node participating in the blockchain using the public node identifier corresponding to each node, the number of votes of each node. For example, if node A has 10 shares and has 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 has 2 votes, 2 public vote identifiers for node B are generated based on the public node identifier of node B.

[0047] The vote identifier list ID_list shown in FIG. 1 stores public vote identifiers when the number of nodes participating in the blockchain is four. In the example of FIG. 1, the four nodes may each have a unique public node identifier. In this case, 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. In this case, the public node identifiers ID0, ID1, ID2, and ID3 may be the public keys of each node.

[0048] In the example of Figure 1, the first node can have 3 votes, the second node can have 1 vote, the third node can have 1 vote, and the fourth node can have 1 vote, i.e., in the example shown in Figure 1, the total number of votes is 6.

[0049] The first node transmits its public node identifier (e.g., public key pk0) and the fact that it has three voting rights to other nodes. Other nodes that receive this data can each calculate the first node's three public voting identifiers (ID0, ID0+1, ID0+2), and the calculated three public voting identifiers of the first node are stored in the voting identifier list ID_list. Other nodes also transmit their public node identifiers and the number of voting rights they have to other nodes in a similar manner, so that nodes participating in the blockchain can each generate the voting identifier list ID_list shown in Figure 1.

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

[0051] Therefore, one public voting identifier is generated for each of the second, third, and fourth nodes, and three public voting identifiers are generated for the first node. At this time, one of the three public voting identifiers for the first node (ID0) is set to 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 for the first node (ID0+1) is set to a value obtained by adding 1 to its public node identifier. At this time, another one of the three public voting identifiers for the first node (ID0+2) is set to a value obtained by adding 2 to the public node identifier of the first node. In particular, when a public key is used as the public node identifier, the possibility of duplication of public voting identifiers being a problem is close to zero even if public voting identifiers generated by adding 1 to the public node identifiers are used. In other words, the public voting identifiers ID0+1 and ID0+2 are values ​​obtained by adding an arbitrary value to the public key of the node, and it is almost impossible to find a private key corresponding to them, so they can be called arbitrary data. In this way, the vote identifier list ID_list stores the public keys of the nodes and arbitrary data in the same number as the total number of votes.

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

[0053] As a result, as shown in Figure 1, a total of six public voting identifiers ID0, ID0+1, ID0+2, ID1, ID2, and ID3 for the four nodes are stored in the voting identifier list, which is generated based on the public node identifiers published to all, and is therefore generated independently 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 Figure 1, when multiple public voting identifiers are generated from one public node identifier, a method of incrementing the public node identifier by a preset number (e.g., 1) (the first public voting identifier is set to the public node identifier) ​​is used, but various other methods can be used 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 one embodiment of the present invention, each node participating in the blockchain can publish its public node identifier (e.g., public key) and the number of voting rights it has to other nodes. Therefore, each node participating in the blockchain can know the public node identifiers and the number of voting rights of all nodes participating in the blockchain, including itself, and can generate the vote identifier list ID_list shown in Fig. 1. At this time, the public vote identifiers included in the vote identifier list ID_list can each correspond to a vote.

[0056] In the example shown in Fig. 1, when a block to be added to the blockchain is input, the pass vote list pass_list can be generated by extracting data stored in the vote identifier list ID_list. That is, the pass vote list pass_list according to one embodiment of the present invention is generated after the consensus block is completed and can be maintained only for the block.

[0057] In the blockchain consensus process, a consensus block is completed and stored in a 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 in the blockchain can already generate a vote identifier list ID_list when the consensus block is completed, and when it receives a COMMITTED message that propagates the consensus block to all nodes after completion, it can generate a pass vote list pass_list by performing an operation corresponding to the success probability (p) using the head value Block_Header of the completed block.

[0058] That is, a node that receives a block extracts the block's header value (Block_Header) and uses it together with the public vote identifier in the vote identifier list (ID_list) generated as shown in Figure 1 to perform an operation corresponding to the success probability (p) to generate a pass vote list (pass_list).

[0059] In the example shown in Figure 1, Hash() is a hash function whose input is the block header value Block_Header and the public vote identifier, and H i (i is the voting right identifier) ​​is a random value generated by a hash function. At this time, take the public voting identifiers one by one from the voting identifier list ID_list, perform a hash operation with the block header value Block_Header to obtain H ican be calculated. At this time, H i is Hash(Header_B n , ID i ) can be shown as follows. In this case, Header_B n is block B shown in Figure 2. n It may also indicate a Block_Header corresponding to ID i may be the public vote identifier corresponding to index i.

[0060] In this case, the hash function may be SHA256, etc. In this case, the public voting identifier ID i A random value H generated corresponding to 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 a portion of the 256-bit output [255:0] of the SHA256 function (for example, the lower 32 bits [31:0]).

[0061] That is, a random value H i Among the generated random values, only those values ​​that are not greater than a preset threshold T are added to the pass voting list pass_list [node number, H i ] are stored in the form of pairs.

[0062] At this time, the threshold T can be any arbitrary value, but as described in the above-mentioned U.S. Patent Publication No. 2023-0066169, the probability p of a successful vote (coin flip) of a node and the size 3f+1 of the consensus congress can be calculated by applying the following formulas 1 and 2. At this time, the random value H i Taking into account the maximum value of p, we can calculate a threshold T that satisfies the probability of success of the coin toss p.

number

number

[0063] Threshold T and random value H i By comparing the size of all random values ​​H i If the coin toss is successful, [node number, H i ] pair is added to the pass vote list pass_list.

[0064] In the example shown in FIG. 1, it can be seen that only random values ​​corresponding to five votes out of six votes are included in the pass_list. That is, the random values ​​H0 and H1 corresponding to two vote identifiers ID0 and ID0+1 out of three public vote identifiers ID0, ID0+1, and ID0+2 for the first node are included in the pass_list. 0+1 Only the random value H corresponding to one voting identifier ID0+2 is calculated successfully (the random value does not exceed T as a result of comparing with the threshold). 0+2 It can be seen that the calculation of H1, H2, and H3 corresponding to the public voting identifiers ID1, ID2, and ID3 for the remaining nodes is successful (the random value does not exceed T) and the pass voting list pass_list contains a total of five random values ​​H0, H1, H2, and H3. 0+1 , H1, H2, and H3 are stored with the corresponding node numbers.

[0065] In other words, in the example of FIG. 1, only the results of successful calculations (threshold comparison result, random value does not exceed T) are stored in the pass vote list pass_list. For the first node, the result of calculation using the public vote identifier ID0, [NODE0, H0], and the result of calculation using the public vote identifier ID0+1, [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 determined as the 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 4 nodes NODE0, NODE1, NODE2, and NODE3 participate in the blockchain, and the total number of voting rights is 6 (3 for NODE0, 1 for NODE1, 1 for NODE2, and 1 for NODE3).

[0069] Node NODE2 is the chair node for the consensus on block B n and sends a PREPARE message for the consensus on 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 a COMMITTED message to all nodes NODE0, NODE1, NODE2, and NODE3.

[0070] Completed consensus block B n All nodes NODE0, NODE1, NODE2, and NODE3 that received the COMMITTED message for n Block information for Header_B n Using block B n+1 A consensus congress can be formed for this purpose.

[0071] That is, as shown in Figure 2, Agreement Block B n The chair node NODE2, which corresponds to n This is propagated to all nodes NODE0, NODE1, NODE2, and NODE3 in the COMMITTED step.

[0072] Block B n The node that receives block B n The head value of is extracted, hashed with each of the public vote identifiers included in the vote identifier list to generate a random value, and the random value is compared with a preset threshold to generate a passing vote list.

[0073] Block B n+1 The passing vote list for block B n The information on the members of the consensus body of the pass-through voting list can be calculated by all nodes that have received the corresponding committed message. n+1All nodes that have received a committed message corresponding to it must be maintained to confirm that they have been signed by valid signers of the block. At this time, the chair may need the consensus member information of the passing vote list in all steps of the consensus (CONFIRM, PREPARE, COMMIT, COMMITTED) to form the consensus congress and the consensus committee. The remaining nodes except the chair need to confirm the chair node if they are members of the consensus, and need the consensus member information of the passing vote list to proceed with the consensus. Nodes not included in the consensus may need the consensus member information of the passing vote list to confirm whether the committed block has been signed by nodes belonging to the committee.

[0074] At this time, block B n+1 The passing vote list for is only generated after receiving the committed message corresponding to block B n Therefore, the time for maintaining a valid passing vote list is managed so that it is not overly long, and a random value that is appropriately used for coin toss (an operation with a success probability of p) is generated.

[0075] In the example shown in Figure 2, for block B n+1 The passing vote list for may store [NODE1, H1], [NODE0, H0], [NODE3, H3], [NODE0, H 0+1 and [NODE2, H2] in ascending order according to the size of the random value H i H0+1 . That is, in the example shown in Figure 2, it can be seen that the size of the random value is H1 < H0 < H3 < H0+1 < H2. Also, in the example shown in Figure 2, it can be seen that only the public vote identifier corresponding to the third vote right of node NODE0 among the six vote rights fails in the coin toss, and all the remaining public vote identifiers succeed in the coin toss.

[0076] In this case, [NODE1, H1] is a calculation result corresponding to the random value H1 calculated based on the public voting identifier (1) of node NODE1, [NODE0, H0] is a calculation result corresponding to the random value H0 calculated based on the first public voting identifier (e.g., the public key of node NODE0) among the public voting identifiers (3) of node NODE0, [NODE3, H3] is a calculation result corresponding to the random value H3 calculated based on the public voting identifier (1) of node NODE3, [NODE0, H 0+1 ] is a random value H calculated based on the second public voting ID (e.g., the public key of node NODE0 + 1) of the three public voting IDs of node NODE0. 0+1 [NODE2, H2] may be a calculation result corresponding to a random value H2 calculated based on the public voting identifier (1) of node NODE2. In the example of FIG. 2, the random value H2 calculated based on the third public voting identifier (e.g., the public key of node NODE0+2) among the public voting identifiers (3) of node NODE0 may be a calculation result corresponding to a random value H 0+2 It can be seen that does not pass the threshold comparison (coin toss).

[0077] At this time, B n+1 The block consensus 201 is [NODE1, H1], [NODE0, H0], [NODE3, H3], [NODE0, H 0+1 In this case, since [NODE1, H1] corresponds to the smallest random value, as shown in FIG. 2, node NODE1 is selected as the next block B n+1 A node may become the chair node for the consensus.

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

[0079] In this way, in existing technologies, the voting rights based on the shares of nodes could not be exercised individually for each consensus body, but according to one embodiment of the present invention, when selecting a consensus body, the voting rights for selecting the consensus body can be divided according to the voting rights of the nodes and exercised.

[0080] Block B n+1 As shown in Figure 2, the consensus is achieved by the chair node NODE1 receiving COMMIT messages from the nodes NODE0, NODE1, and NODE3, which correspond to the consensus committee, and sending corresponding COMMITTED messages to all nodes.

[0081] Block B n+1 Upon receiving the committed message corresponding to block B, all nodes commit n+2 That is, we can generate a pass-through vote list corresponding to block B n+1 Each node that receives the corresponding committed message commits block B n+1 The head value of the block B is extracted, hashed with each public voting identifier included in the voting identifier list to generate a random value, and the random value is compared with a preset threshold to generate a block B. n+2 Generate a pass vote list for

[0082] In the example shown in FIG. n+2 The passing vote list for is [NODE3, H3], [NODE0, H 0+1 ], [NODE0,H0], [NODE2,H2] and [NODE1,H1] are the random values ​​H i In the example shown in FIG. 2, the blocks B n+2 The size of the random value generated for the consensus of H3 <H 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 also 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 The consensus started, and NODE2, the chair, formed the consensus committee 206, which consisted of [NODE3, H3], [NODE0, H 0+1 ], [NODE0, H0] and sends a prepare message to the corresponding nodes NODE3 and NODE0.

[0086] In existing distributed consensus technologies, such as the distributed consensus method using nonce chains, a node that succeeded in a coin toss had to create a message to prove that it succeeded in the coin toss and send it to other nodes. Other nodes had to form a consensus body by confirming that the node succeeded in the coin toss based on the message received from the specific node.

[0087] However, according to the present invention, all nodes can generate the same pass vote list for a specific block using a public node identifier, such as a public key, assigned to each node. Therefore, it is easy to confirm which nodes have formed a consensus without a separate message for forming the consensus, thereby maximizing the efficiency of consensus.

[0088] That is, according to the present invention, a distributed node connected to a blockchain can calculate the configuration of the consensus of the next block by itself without receiving a new consensus-related message from another node. The nodes participating in the consensus can independently calculate the value for selecting the consensus of the next block for each node from the public voting identifiers of all participating nodes and the data extracted from the current block, and calculate the consensus of the next block.

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

[0090] Referring to Figure 3, we can see that a total of five nodes, NODE0, NODE1, NODE2, NODE3, and NODE4, participate in the blockchain and the total number of voting rights is 5 (1 for each node). In other words, Figure 3 shows the process of forming a random consensus without exchanging additional messages for consensus formation when all participating nodes have a stake of 1, and then collaborating among them.

[0091] The example of Fig. 3 may correspond to the process of generating an initial block 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 performed, the setup of the voting right identifier list including the public voting right identifier may be completed.

[0092] In the example shown in Figure 3, for convenience of explanation, the protocol for initial block generation and consensus process was explained assuming that all nodes have one voting right, but as mentioned above, each node may have multiple voting rights. If some nodes participate in the consensus body with multiple voting rights, efficient consensus is possible by transmitting only one message for consensus and using the count included in the committee as the consensus count.

[0093] Initial Block B init During the consensus process, the node NODE0, which is arbitrarily selected as the chairman for the initial block consensus, independently goes through the PREPARE and COMMIT steps, signs the block, creates the initial block, and transmits it to all nodes NODE0, NODE1, NODE2, NODE3, and NODE4.

[0094] As shown in Figure 3, the consensus process goes through four stages. Initial Block B init In the process of the agreement for , only node NODE0 participates in the consensus body, so the prepare and commit steps are performed inside node NODE0. In this process, the initial block B is created using the private key of node NODE0.init The final block with the signature completed is transmitted to all nodes NODE0, NODE1, NODE2, NODE3, and NODE4 in the COMMITTED step. In the example of Figure 3, EC-schnorr multi-signature can be used for the agreement. Multi-signatures in the agreement process are disclosed in detail in the aforementioned U.S. Patent Publication No. 2020-0403776.

[0095] In the CONFIRM step, each node confirms the initial block B init If there is a problem, the agreement has failed, so the re-agreement protocol is carried out. If there is no problem with the verification result, the voting ID stored in the voting ID list ID_list of the stored node and the initial block B init Using the header values ​​of and , a pass vote list pass_list is generated as described with reference to Fig. 1. As described above, all nodes that receive the committed message can generate a pass vote list.

[0096] In the example of FIG. 3, it is assumed that five nodes NODE0, NODE1, NODE2, NODE3, and NODE4 participate with one voting right each, so p, which satisfies the above formula 1 and formula 2, is 1.0 and f is 1. All [node numbers, H i ] pairs are added to the pass vote list pass_list, and from these, H i In the example of Figure 3, all five voting rights pass the threshold comparison, and five [node number, H i ] pairs may be sorted in ascending order and stored in the pass vote list pass_list. At this time, from among the stored values, the result values ​​for the four nodes NODE2, NODE0, NODE4, and NODE3, which are 3f+1, are selected as corresponding to the consensus. Therefore, the next block B init+1The consensus nodes for the agreement are NODE2, NODE0, NODE4, and NODE3. i The node NODE2 corresponding to block B init+1 The chairman node of the

[0097] In Figure 3, an example is shown in which nodes NODE2, NODE0, NODE4, and NODE3 are selected as consensus bodies to proceed with the consensus. This process is carried out by all distributed nodes, and the same initial block B init Since the calculation (coin toss) results of all nodes that confirm the above are the same, all nodes can form the same consensus without exchanging messages between nodes to form the consensus.

[0098] Referring again to FIG. 3, in the CONFIRM step, the nodes NODE2, NODE0, NODE4, and NODE3 selected as the consensus for the next block are randomly selected by k i and generate Q on the elliptic curve i Each node in the consensus group generates the checksum of the block header it received and Q i Next block B init+1 The node NODE2, which is the chair node of the init This allows the result of the consensus to be verified, and prepares for the next block consensus. At this time, the checksum and Q i is transmitted along with the signature of node i to ensure its integrity. At this time, the nodes selected as consensus nodes transmit pending transactions to the chairman node so that the chairman can process them.

[0099] Block B init+1 NODE2, the chairman of i Randomly select 2f+1 nodes from among the nodes that submitted the block B. Check whether the checksums of the selected nodes are the same. initIn the example shown in Figure 3, block B init+1 The node NODE2, which is the chairman of the consensus group, selects three (2f+1) committee nodes NODE2, NODE0, and NODE3 out of the four (3f+1) consensus nodes NODE2, NODE0, NODE4, and NODE3, confirms that the checksums of nodes NODE2, NODE0, and NODE3 are identical, and proceeds with the consensus with nodes NODE2, NODE0, and NODE3.

[0100] As can be seen from Figure 3, the initial block B init The chairman who started the block is node NODE0, but the next block B init+1 The node NODE2, the chairman of init The results of the agreement can then be finally confirmed.

[0101] Block B init+1 In the PREPARE step, node NODE2 prepares the transaction or block B it received from the guest. init In the CONFIRM step, a preliminary block is generated that contains the transactions transmitted from the nodes. At this time, the public keys and Q of nodes NODE2, NODE0, and NODE3 are used for consensus. i By including the combined Pk, Q, and r values ​​in the block, a prepare message (including a prepare block) can be generated and transmitted to nodes NODE2, NODE0, and NODE3. Nodes NODE2, NODE0, and NODE3 that receive the prepare message check whether there are any abnormalities in the block, and if there are no abnormalities, they send the prepared block signed with their own private keys. i After receiving all the COMMIT messages, the chair node NODE2 generates s i After combining them to generate S, the signature (r, S) is completed to generate a committed block and transmit it to all nodes.

[0102] Each node that receives a committed block checks the public keys and signatures of the 2f+1 nodes in the consensus group to verify the validity of the block. If the check result is valid, block B init+1 Header value of H i Then, the next passing vote list can be created, and block B init+2 In the example of Figure 3, nodes NODE4, NODE3, NODE1, and NODE2 form a consensus and block B init+2 The node sends a confirm message to NODE4, the chairman of block B. init+1 In the CONFIRM step, nodes NODE4, NODE3, NODE1, and NODE2 confirm the checksum and Q i to node NODE4 and block B init+1 Then, block B init+1 For block B, init+2 This would allow the agreement to proceed.

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

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

[0105] That is, through FIG. 4, block B n If node NODE5 joins the participating nodes at the time of the agreement, node NODE5 will participate in block B. n+1 From the agreement, it can be seen that it is possible to join the consensus body normally (node ​​addition process).

[0106] In the example of FIG. 4, block B nAssume that node NODE5's intention to participate in the agreement has been communicated to node NODE3, the chairman of Block B. Node NODE5 first connects to the network where the agreement is in progress and collects information on the nodes currently participating in the agreement. After receiving information on the agreement nodes and public node identifiers (e.g., public keys), it creates a voting identifier list ID_list including public voting identifiers based on this and communicates its intention to participate in the agreement to other nodes. Block B n-1 The nodes that receive the information about the new joining node at the time corresponding to n The node NODE3 can then include the content in the transaction to be agreed upon and proceed with the agreement. At this time, the block for which the COMMIT step has been completed may contain information about the new joining node. Therefore, the node NODE3 can add the public voting identifier of node NODE5 to its voting identifier list ID_list when the COMMIT step is completed. The node NODE3 can then communicate the block generated in the COMMITTED step to all nodes. All nodes that receive the COMMITTED message will each add the public voting identifier of the new node NODE5 to their own voting identifier list ID_list. Therefore, block B n From the CONFIRM step, nodes NODE0, NODE1, NODE2, NODE3, NODE4, and NODE5 become able to participate in the agreement.

[0107] Block B n+1 In the agreement step, the chair node NODE2 agrees on a new block by PREPARE and COMMIT, and propagates the completed block to all nodes. That is, new nodes can participate in the agreement by the process shown in Figure 4.

[0108] FIG. 5 is a flowchart illustrating an example of a process in which a public voting ID is generated from a public node ID according to an embodiment of the present invention.

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

[0110] The steps shown in Figure 5 illustrate a process for generating one or more public voting identifiers for a particular node using the node's public node identifier. Each step shown in Figure 5 is performed for each public node identifier. The process shown in Figure 5 generates public voting identifiers for a particular public node identifier (e.g., public key) equal to the number of voting rights of the node.

[0111] First, in step S510, variables for generating public vote identifiers are initialized. That is, in step S510, a variable loop is set to a value corresponding to the number of votes of the node, a variable count is set to 0, and a vote identifier list ID_list is initialized.

[0112] Thereafter, in step S520, the variable count is compared with the variable loop. If the comparison result in step S520 is that count is smaller than loop, a public voting identifier equivalent 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 voting identifier list ID_list (S530). As shown in Fig. 5, the voting identifier list ID_list may store node numbers together with public voting identifiers.

[0113] When the public vote identifier is added in step S530, the variable count is incremented by 1 (S540), and the process returns to step S520 to compare the variable count with the variable loop.

[0114] If the comparison result in step S520 indicates that count is not smaller than loop, the voting identifier generation process for the node is terminated.

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

[0116] In the example of Figure 5, a case is shown in which a public voting identifier is generated by adding a preset number to a public node identifier, but the method of generating public voting identifiers equal to the number of voting rights from a public node identifier may be various.

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

[0118] The voting identifier generator (function) may be a function of various types that receives a public node identifier as an input and outputs public voting identifiers equal to the number of voting rights. In this case, the voting identifier generator may include a duplication checker that checks whether the generated public voting identifier is duplicated. In this case, the duplication checker may check not only whether the generated public voting identifier is duplicated with other voting identifiers, but also whether the generated public voting identifier is duplicated with public node identifiers corresponding to other nodes.

[0119] In this way, if a public voting identifier is generated for each voting right of a node and a coin toss is performed using this, the coin tosses can be performed in parallel, and the calculation speed for selecting the consensus body can be faster than a method in which a specific node hashes the result of one coin toss and then performs the next coin toss.

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

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

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

[0123] Node NODE0 selects [NODE1, H1], [NODE0, H0], [NODE3, H3], and [NODE0, H 0+1 ] has been selected as the consensus body, and the result value corresponding to itself ([NODE0, H0]) is ranked second on the pass-through voting list, so it can confirm that it has been selected as the consensus body. At this point, node NODE0 knows that node NODE1 has become the chairman based on the first result value on the pass-through voting list ([NODE1, H1]). Furthermore, node NODE0 knows that node NODE1 has become the chairman based on the result value corresponding to itself ([NODE0, H 0+1 ]) is fourth on the passing vote list, and so can verify that he has two votes in the consensus.

[0124] Node NODE1 selects [NODE1, H1], [NODE0, H0], [NODE3, H3], and [NODE0, H 0+1 ] was selected as the consensus body, and based on the first result value ([NODE1, H1]), you can see that you have been selected as the consensus body and have become the chairperson.

[0125] Node NODE2 selects [NODE1, H1], [NODE0, H0], [NODE3, H3], and [NODE0, H 0+1 ] was selected as the consensus body, and it can be confirmed that the result value corresponding to itself ([NODE2, H2]) is not included in the consensus body. At this time, node NODE2 knows that node NODE1 has become the chairman based on the first result value ([NODE1, H1]) in the pass-through vote list.

[0126] Node NODE3 will select [NODE1, H1], [NODE0, H0], [NODE3, H3], [NODE0, H 0+1 ] has been selected as the consensus body, and the result value corresponding to itself ([NODE3, H3]) is the third in the pass-through voting list, so it can confirm that it has been selected as the consensus body. At this time, node NODE3 knows that node NODE1 has become the chairman based on the first result value in the pass-through voting list ([NODE1, H1]).

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

[0128] Nodes NODE0 and NODE3 confirm that they are not the chair but are included in the consensus, and send a CONFIRM message to node NODE1.

[0129] The chairman forms a consensus committee within the consensus congress. In the example shown in Figure 6, it can be seen that nodes NODE1, NODE0, and NODE3 were selected as committee members. At this time, the second public voting identifier ID of node NODE0 is 0+1 The result value ([NODE0, H 0+1)) is included in the consensus body but not in the committee.

[0130] If the chairman configures the nodes NODE1, NODE0, and NODE3 as a committee as shown in Figure 6, when the chairman binds the public keys, the Pk 103 Using r 103 and provides it to the committee node.

[0131] If the chairman were to select the result values ​​corresponding to the consensus body, which are different from those shown in Figure 6, then [NODE1, H1], [NODE0, H0], and [NODE0, H 0+1 ], when the chairman binds the public keys, the public keys of the nodes NODE1 and NODE0 are bound to Pk 10 Using r 10 and provides it to the committee node.

[0132] Therefore, since Pk and r generated by the committee are different, the members of the committee can use the received r to sign s without knowing who will sign it. i The chairman cannot create two multi-signatures at the same time.

[0133] However, in order to confirm whether the chairman receives 2f+1 signatures to complete the agreement, it is necessary to inform the committee nodes of who the nodes are in the committee (603). At this time, since all nodes have a pass_list, the chairman node is assigned the number 0, and the nodes are assigned numbers in order according to their position on the pass_list, and the committee composition information can be transmitted as a bitmap.

[0134] As shown in FIG. 6, the chair maintains a pass vote list, pass_list, for identifying the members of the committee who signed (604).

[0135] Once the multi-signature is complete, the agreed upon block is transmitted in the committed block. At this time, the committee configuration information is provided and used to verify the nodes that signed on the pass vote list pass_list (605).

[0136] Furthermore, the node uses the received block to generate the next block B n+2 Regenerate the pass vote list pass_list for consensus formation for

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

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

[0139] At this time, the public vote identifiers are generated for each of the nodes by using a public node identifier corresponding to each of the nodes, the number of votes being equal to the number of votes of each of the nodes.

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

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

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

[0143] At this time, the passing vote list is generated by each of the nodes constituting the blockchain performing the calculation for 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 identical to each other.

[0144] In this case, 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 probability of success.

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

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

[0147] At this time, 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.

[0148] In this case, the node having the largest or smallest value corresponding to the result of the calculation among the consensus nodes may become a 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 by the configuration shown in Fig. 9.

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

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

[0152] In addition, the block chain generating method according to one embodiment of the present invention generates a passing vote list using the information about the previous block and the public vote identifier (S820).

[0153] At this time, the passing vote list is generated by each of the nodes constituting the blockchain performing an operation corresponding to the success probability (p) for 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 identical to each other.

[0154] In this case, the operation may compare a random value generated using the public vote identifier and information about the previous block with a threshold corresponding to the probability of success.

[0155] At this time, the public vote identifiers are generated for each of the nodes by using a public node identifier corresponding to each of the nodes, the number of votes being equal to the number of votes of each of the nodes.

[0156] In addition, in the blockchain generation method according to an embodiment of the present invention, 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 (S830). At this time, the chair node is recognized based on the pass-through vote list.

[0157] In addition, in the blockchain generation method according to one embodiment of the present invention, the chair node sends a prepare message to a committee node selected from the consensus nodes to link the current block to the blockchain (S840).

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

[0159] In addition, in the blockchain generation method according to one embodiment of the present invention, the chair node sends 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 that constitute 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 may include one or more processors 910, memory 930, a user interface input device 940, a user interface output device 950, and storage 960, which communicate with each other via a bus 920. The computer system 900 may further include a network interface 970 coupled to a network 980. The processor 910 may be a central processing unit or a semiconductor device that executes programs or processing instructions stored in the memory 930 or the storage 960. The memory 930 and the storage 960 may be storage media including at least one of a volatile medium, a non-volatile medium, a separate medium, a non-separate medium, a communication medium, or an information transmission medium. For example, the memory 930 may 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 can generate public voting identifiers using public node identifiers corresponding to nodes constituting the blockchain, perform an operation corresponding to a success probability (p) for each public voting identifier to generate a passing vote list, and perform distributed consensus based on at least a portion of the consensus nodes corresponding to the passing vote list.

[0165] At this time, the passing vote list is generated by each of the nodes constituting the blockchain performing the calculation for 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 identical to each other.

[0166] In this case, 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 probability of success.

[0167] At this time, the public vote identifiers are generated for each of the nodes by using a public node identifier corresponding to each of the nodes, the number of votes being equal to the number of votes of each of the nodes.

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

[0169] At this time, 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.

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

[0171] In this case, the public node identifier may be a public key corresponding to the node.

[0172] In this case, the node having the largest or smallest value corresponding to the result of the calculation among the consensus nodes may become a chair node.

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

[0174] 900: Computer Systems 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 includes: 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 voting right for each of the nodes, the number of voting rights for each of the nodes being generated. 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 includes: 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 voting right for each of the nodes, the number of voting rights for each of the nodes being generated.

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 includes: 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 voting right for each of the nodes, the number of voting rights for each of the nodes being generated.

20. The method of claim 19 .

Images