KR-20260063050-A - Method of consensus for between consensus node and proposer re-election node by on round reset

Abstract

The present invention discloses a method for consensus among consensus nodes, comprising the steps of: (S10) collecting consensus opinions on a pre-generated block and transmitting a block message to a plurality of nodes; (S20) selecting a proposal node among a certain number of consensus nodes; and (S30) generating a proposal message through the proposal node and having the proposal node propose the proposal message to a certain number of consensus nodes.

Inventors

• 전명산
• 김종현

Assignees

• (주)소셜인프라테크

Dates

Publication Date

20260507

Application Date

20241030

Claims (10)

1. In a consensus method among consensus nodes that elects a certain number of consensus nodes and elects a leader among the certain number of consensus nodes to propose a new block and proceed with consensus on a proposal message, (S10) A step of collecting consensus opinions on a pre-generated block and transmitting a block message to multiple nodes; (S20) A step of selecting a proposal node among the above-mentioned number of consensus nodes; and (S30) A method for inter-node consensus through selective consensus node configuration and proposal re-election, characterized by including the step of generating the proposal message through the proposal node and the proposal node proposing the proposal message to a certain number of consensus nodes.
2. In paragraph 1, the above method is, (S40) A method for inter-node consensus through selective consensus node configuration and proposal re-election, characterized by including the step of a certain number of consensus nodes proceeding with consensus on the proposal message transmitted from the proposal node.
3. In paragraph 1, the above method is, Before the above (S10) step, (S9) A method for inter-node consensus through selective consensus node configuration and proposal re-election, characterized by including the step of selecting a certain number of consensus nodes among the plurality of nodes.
4. In paragraph 3, the above method is, After the above (S40) step, (S41) A method for inter-node consensus through selective consensus node configuration and proposal re-election, characterized by including the step of providing the verification result of the proposal message determined through the predetermined number of consensus nodes to the plurality of nodes.
5. In paragraph 1, the proposed node is, A method for inter-node consensus through selective consensus node configuration and proposal re-election, characterized by selecting from a certain number of consensus nodes according to a pre-set proposal node selection rule.
6. In paragraph 5, the above (S30) step is, (S31) A step in which the proposal message is generated through the proposal node; and (S32) A method for inter-node consensus through selective consensus node configuration and proposal re-election, characterized by including a step of waiting to receive the proposal message from the proposal node.
7. In paragraph 1, the above step (S30) is, (S32-1) A method for inter-node consensus through selective consensus node configuration and proposal re-election, characterized by including the step of resetting the consensus round after waiting for a certain period of time according to a preset waiting time when a problem occurs with the proposal message proposal through the proposal node.
8. In paragraph 1, the above (S10) step is, (S11) A step of gathering consensus opinions on the pre-generated block among the plurality of nodes; (S12) A step of generating the block message after gathering the above consensus opinions; and (S13) A method for inter-node consensus through selective consensus node configuration and proposal re-election, characterized by including the step of transmitting the block message to the plurality of nodes.
9. In paragraph 1, the above (S10) step is, (S13-1) A method for inter-node consensus through selective consensus node configuration and proposal re-election, characterized by including the step of resetting the consensus round if the consensus opinion on the previously generated block does not converge.
10. In paragraph 9, the above-mentioned fixed number of consensus nodes is, A method for inter-node consensus through selective consensus node configuration and proposal re-election, characterized by a fixed number of consensus nodes being set according to arbitrary rules and re-elected according to each consensus round.

Description

Method of consensus for between consensus node and proposer re-election node by on round reset The present invention relates to a method for consensus among nodes, and more specifically, to a method in which a consensus node composed of arbitrary nodes is elected in each consensus round, a leader proposing a new block is elected according to a leader election rule, the leader's proposal message is verified, and the result is transmitted to a group of nodes. The paper *Impossibility of Distributed Consensus with One Faulty Process*, written in 1985, argues that there is no distributed consensus algorithm that simultaneously satisfies both Safety and Liveness in asynchronous networks. Practical Byzantine Fault Tolerance (hereinafter PBFT) is a methodology developed by Castro and Liskov in 1999 that aims to solve the consensus problem in asynchronous networks by sacrificing some Liveness in exchange for securing Safety. The PBFT algorithm can be summarized as follows: in an asynchronous network, if there are f traitor nodes and the total number of nodes in the network is 3f+1, the consensus result of that network is reliable. In the case of the pure PBFT algorithm, consensus is achieved in the order of Request → Pre-prepare → Prepare → Commit → Reply, where messages are propagated via broadcasting at each of the Pre-prepare, Prepare, and Commit stages. In other words, as the size of the network increases, the number of message propagations from a single node to other nodes also increases exponentially. In addition, since each node must receive a certain number of messages transmitted via broadcasting to proceed to the next consensus stage, it is always placed in a waiting state for a certain period of time after a consensus stage begins. According to the PBFT algorithm, each node must receive a certain proportion of messages relative to the total number of nodes to trust the network; in short, this means that as the scale of the network increases, the time a single node must wait to receive a certain number of messages also increases. This is a problem directly related to the scalability of PBFT and can be a direct cause of reduced consensus speed in large-scale PBFT-based blockchain networks that account for message loss or delay. For example, PoW has the problem that it is not suitable for industries and business environments where data must be processed as close to real-time as possible, because it requires waiting from a few minutes to an hour for data confirmation. To fully utilize blockchain in industry, near-real-time data finality must be secured. A prior patent document regarding a blockchain based on the PBFT algorithm is "Easing of practical Byzantine Fault Tolerance blockchain consensus and node synchronization (Registration No. 10-2193549, hereinafter referred to as Patent Document 1)." In the case of Patent Document 1, the method comprises: setting a timer that expires prior to the timeout of a view change by a first consensus node; transmitting a request for one or more lost consensus messages by the first consensus node to a second consensus node in response to the timer expiring; receiving one or more consensus messages from the second consensus node, each digitally signed by the private key of the corresponding consensus node generating each of the one or more consensus messages; and determining that a block of transactions is valid when the number of commit messages included in the received one or more consensus messages is 2f + 1 or more, and f is the maximum number of fault nodes allowed by the blockchain based on Practical Byzantine Fault Tolerance (PBFT). In addition, there also exists "Consensus System Downtime Recovery (Registration No. 10-2365793, hereinafter referred to as Patent Document 2)." In the case of Patent Document 2, it includes a computer program encoded on a computer storage medium for consensus system downtime recovery. According to the invention of Patent Document 2, the method comprises the steps of: obtaining a pre-preparation message from a primary node; multicasting a preparation message indicating acceptance of the pre-preparation message to at least some of the remaining (N-2) backup nodes and primary nodes; obtaining (Q-1) or more preparation messages from (Q-1) or more backup nodes among the backup nodes; storing the pre-preparation message and (Q-1) or more preparation messages; multicasting a confirmation message indicating that one backup node agrees to (Q-1) or more preparation messages to at least some of the remaining backup nodes and primary nodes; and obtaining Q or more confirmation messages from Q or more nodes among the primary node and backup nodes, wherein each of the Q or more confirmation messages indicates that the corresponding node agrees to (Q-1) or more preparation messages. In addition, there is also “an improved PBFT-based blockchain management method, blockchain system and node device (Registration No. 10-2447063, hereinafter referred to a