View change timer control method for distributed consensus system

Abstract

One disclosed embodiment relates to a distributed consensus system using a view change algorithm for replacing a leader and, more specifically, to a control method for adjusting the value of a timer used in a view change in order to guarantee the liveness of the distributed consensus system. The control method for electing at least one process as a leader in a distributed system including a plurality of processes, according to various embodiments, may comprise operations in which: at least one process from among the plurality of processes sets a second view value at least partially increased to be greater than a first view value based on a first timer and sets a second timer on the basis of the second view value and starts same; at least one process includes, in a message, information necessary for second timer setting so as to transmit the message to the remaining plurality of processes; at least one process receives and inspects the information necessary for second timer setting; and at least one process resets the second timer on the basis of the inspection result and restarts same.

Description

View Change Timer Control Method for Distributed Consensus Systems

[0001] The disclosed embodiment relates to a distributed consensus system using a view change algorithm for replacing a leader, and more particularly, to a control method for adjusting the value of a timer used for view change to ensure liveness of the distributed consensus system.

[0002]

[0003] Consensus refers to the problem of multiple distributed processes agreeing on the same value, and all the logic used by the processes to solve this is called a consensus protocol. Consensus is a fundamental problem for controlling distributed processes and can be applied to state machine replication, distributed database management, atomic broadcast, blockchain, etc. Representative consensus protocols include the Practical Byzantine Fault Tolerance (PBFT) consensus protocol presented at the 1999 OSDI (Operating Systems Design and Implementation) conference, the Zyzzyva consensus protocol presented at the 2007 ACM SOSP (Symposium on Operating Systems Principles) conference, and the Raft consensus protocol presented at the 2014 USENIX ATC (Annual Technical Conference) conference.

[0004] A consensus protocol must satisfy two conditions: safety and liveness. Safety means that all non-faulty processes must agree on the same value. Liveness means that all non-faulty processes must eventually decide on the same value.

[0005] To ensure security, a threshold or more processes must agree on the same value. When the total number of processes participating in the agreement is n and the maximum number of processes that can cause an error is f, in a crash fault tolerant (CFT) consensus protocol, agreement is possible when n ≥ 2f + 1, and the threshold is the smallest integer greater than n / 2. That is, if n = 2f + 1, the threshold is f + 1. In a Byzantine fault tolerant (BFT) consensus protocol, agreement is possible when n ≥ 3f + 1, and the threshold is the smallest integer greater than 2n / 3. That is, if n = 3f + 1, the threshold is 2f + 1.

[0006] In a typical consensus protocol, one process is designated as the leader. Once the leader proposes a value, the remaining processes exchange messages to confirm that a threshold number of processes have voted on it before committing the value. Once the leader confirms that the proposed value has been committed by a threshold number of processes, the process moves on to the next round, where a new value is agreed upon.

[0007] Consensus protocols that appoint a single leader to facilitate consensus are more efficient than those that don't. Without a leader, multiple processes could simultaneously propose different values, which not only complicates the consensus process but also increases the likelihood of consensus failure.

[0008] However, leader-based consensus protocols can violate liveness if the leader experiences a fault. For example, if the leader crashes and ceases operation, processes will be forced to wait indefinitely for messages from the leader. Another example is a Byzantine fault in the leader, which could prevent processes from reaching consensus if the leader proposes different values ​​to each other.

[0009] The liveness issue in leader-based consensus protocols can be addressed by replacing the leader through a view change. If a leader error is suspected, processes can attempt a view change, and a non-faulty process with a threshold of consensus can be elected as the new leader, thereby satisfying liveness.

[0010] Typically, the order of processes to be elected as leaders through view changes is predetermined. Each process is assigned an integer identifier, and the leader of a new view is determined based on the order of the identifiers. The initial leader is the process with an identifier value of 1, and its view number is 1, the same as the process's identifier. Each subsequent view change attempt increments the view number by 1, and the view number always has the same value as the process's identifier.

[0011] Due to view change, a leader-based consensus protocol can be viewed as comprising two algorithms: a normal-case agreement algorithm, in which processes reach agreement on the leader's proposal, and a view change algorithm, which replaces the leader. If a process suspects a leader error, it halts execution of the normal-case agreement algorithm and executes the view change algorithm. When a process is elected as the new leader through the view change algorithm, with a threshold number of processes agreeing, the processes terminate the view change algorithm and restart the normal-case consensus algorithm.

[0012]

[0013] The view change algorithm of conventional leader-based consensus protocols has a problem in that it cannot guarantee the success of a view change. For a view change to succeed, a threshold number of processes must agree on the same new view value. This is possible only when the processes simultaneously execute the view change algorithm with the same new view value. In other words, there must be a common intersection of time intervals where the processes attempt to change the view for the same new view value, and this overlapping interval (hereinafter referred to as the common view change period) must be sufficiently large.

[0014] Conventional view change algorithms use a timer value that increases exponentially each time a view change fails to ensure a sufficiently large common view change interval. For example, the size of the interval during which a view change is attempted for a specific view value can be increased exponentially by using an exponentially increasing timer value. However, this method cannot guarantee a sufficiently large common view change interval.

[0015] The disclosed embodiment seeks to provide a method for controlling a timer that ensures a common view change interval sufficiently large to successfully perform a view change in a distributed consensus system.

[0016]

[0017] According to various embodiments, a control method for electing at least one process as a leader in a distributed system including a plurality of processes may include an operation in which at least one process among the plurality of processes sets a second view value that is at least slightly increased from a first view value based on a first timer and sets and starts a second timer based on the second view value; an operation in which at least one process includes information necessary for setting the second timer in a message and transmits the information to the remaining plurality of processes; an operation in which at least one process receives and examines information necessary for setting the second timer; and an operation in which at least one process resets and restarts the second timer based on a result of the examination.

[0018] According to various embodiments, the operation of setting a second view value of a control method for electing at least one process as a leader in a distributed system including a plurality of processes and setting and starting a second timer based on the second view value may include an operation of setting the second timer so that the sizes of intervals in which the processes attempt view changes for the same second view value are all the same; and an operation of linearly increasing the second timer.

[0019] In various embodiments, in a control method for electing at least one process as a leader in a distributed system including a plurality of processes, the operation of setting a second timer so that the length of the interval during which the processes attempt a view change for the same second view value is all the same may include the operation of setting the second timer based on the second view value and the third view value.

[0020] According to various embodiments, in a distributed system including a plurality of processes, an operation of transmitting information required for setting a second timer in a message to the remaining plurality of processes in a control method for electing at least one process as a leader may include an operation of generating proof for a third view value using messages of other processes that were received when committing in a first view value such as a third view value; and an operation of transmitting the third view value and the proof together in a view change message to the other processes.

[0021] According to various embodiments, an electronic device includes a communication unit for transmitting and receiving messages and data with another electronic device through a network; a processor for performing control for performing operations of the electronic device and proceeding with an agreement protocol; and a memory for storing instructions for a control algorithm or a program that reproduces the control algorithm, wherein the instructions may be configured to set a second view value that is at least slightly greater than a first view value based on a first timer, set and start a second timer based on the second view value, include information necessary for setting the second timer in a message and transmit it to the remaining plurality of processes, and have at least one process receive and examine the information necessary for setting the second timer, and have at least one process reset and restart the second timer based on a result of the examination.

[0022] According to various embodiments, instructions of the electronic device may be configured to set a second timer so that the length of the intervals during which processes attempt to change views for the same second view value is all the same, and to linearly increase the second timer.

[0023] According to various embodiments, instructions of the electronic device may be configured to set a second timer so that the length of the intervals during which processes attempt to change views for the same second view value is all the same, and to linearly increase the second timer.

[0024] According to various embodiments, instructions of the electronic device may be configured to set the second timer based on the second view value and the third view value.

[0025] According to various embodiments, instructions of the electronic device may be configured to generate a proof for the third view value using messages from other processes that were received when committing to the first view value, such as the third view value, and to transmit the proof and the third view value together in a view change message to other processes.

[0026] According to various embodiments, instructions of the electronic device may be configured to compare whether its own third view value is less than a third view value received from another process.

[0027] According to various embodiments, the instructions of the electronic device may be configured to change its third view value, and if the third view value is equal to or greater than the second view value, change the second view value to a value that is the third view value plus one, and reset and restart the value of a second timer based on the updated third view value and the second view value.

[0028] A timer control method for a distributed consensus system according to an embodiment of the present disclosure is provided for each process P iYou can use two timers.

[0029] First Timer C i normal (hereinafter referred to as the first timer) is used when executing the steady-state consensus algorithm and can be started at the beginning of each new round. If the first timer C is started before the leader's proposal is committed, i normal When this expires, process P i can suspend the normal state consensus algorithm and execute the view change algorithm. Here, the first timer C i normal △ is a sufficiently long time required to agree on a proposal. normal It can be set to the above. △ normal can be a value greater than the sum of the time it takes for multiple processes to exchange messages with each other and the time it takes to run the consensus algorithm.

[0030] Second Timer C i view (hereinafter referred to as the second timer) can be used when executing the view change algorithm. Process P i When the view change algorithm starts, a second timer C i view can start. If the second timer C is started before a new leader is elected. i view When process P expires i can change the leader candidate and retry the view change. Second timer C i view △ is a sufficiently long time to elect a new leader view It can be set to the above.

[0031] A timer control method for a distributed consensus system according to an embodiment of the present disclosure comprises a first timer C for each process i normal The action of setting and executing the normal case consensus algorithm; the first timer C i normal When this expires, it includes an action of executing a view change algorithm, and the action of executing the view change algorithm may include an action of setting a new view value (hereinafter referred to as a second view value) and setting and starting a second timer based on the second view value; an action of putting information related to the second timer setting into a message and transmitting it to the remaining plurality of processes; an action of receiving and checking information related to the second timer setting; and an action of resetting and restarting the second timer based on the check result.

[0032] The operation of setting the second view value and setting and starting the second timer based on the second view value may include the operation of setting the second timer so that the size of the interval in which all processes attempt to change views for the same second view value is the same; and the operation of linearly increasing the second timer.

[0033] The operation of setting the second timer so that the size of the interval in which the processes attempt to change the view for the same second view value is all the same may include the operation of setting the second timer based on the current view value (hereinafter, the first view value) of the process and the anchor view value (hereinafter, the third view) that is changed through message exchange between the processes.

[0034] The operation of transmitting information related to the second timer setting to the remaining plurality of processes in a message may include an operation of generating proof for the third view value using messages from other processes that were received when committing in the first view value, such as the third view value; and an operation of transmitting the proof for the third view value to other processes in a view change message.

[0035] The operation of transmitting information related to the above second timer setting to the remaining multiple processes in a message can, when applied to a system that tolerates only crash faults and not Byzantine faults, propagate only the third view value to other processes and omit propagation of the proof for the third view value.

[0036] The operation of receiving and examining information related to the second timer setting may include an operation of the process comparing whether its own third view value is less than a third view value received from another process.

[0037] The operation of resetting and restarting the second timer based on the above inspection results may include an operation of the process changing its own third view value and an operation of resetting and restarting the value of the second timer based on the changed third view value.

[0038]

[0039] A timer control method for a distributed consensus system according to an embodiment disclosed always guarantees the success of a view change by securing a common view change interval of sufficient size, thereby enabling satisfying the liveness of a consensus protocol.

[0040]

[0041] Figure 1 is a diagram schematically illustrating the disclosed distributed consensus system.

[0042] Figure 2 is a control block diagram of an individual node that executes the process of a distributed consensus system.

[0043] Figure 3 is a diagram for explaining the normal state consensus algorithm of a conventional consensus protocol.

[0044] Figure 4 is a diagram for explaining the view change algorithm of a conventional consensus protocol.

[0045] Figure 5 is a diagram illustrating problems that may occur in conventional consensus protocols.

[0046] Figure 6 is a diagram for explaining an example in which a common view change section does not exist in a conventional consensus protocol.

[0047] FIG. 7 is a diagram for explaining a timer control method of a distributed consensus system capable of obtaining a common view change interval of sufficient size according to various embodiments.

[0048] FIG. 8 is a flowchart illustrating a timer control method of a distributed consensus system that sets a second timer so that the length of the intervals in which processes attempt to change views for the same new view value are all the same, according to various embodiments.

[0049]

[0050] Throughout the specification, the same reference numerals denote the same components. This specification does not describe all elements of the embodiments, and any content that is general in the technical field to which the present invention pertains or that overlaps between embodiments is omitted. The terms 'part, module, element, block' used in the specification may be implemented in software or hardware, and depending on the embodiments, multiple 'parts, modules, elements, blocks' may be implemented as a single component, or a single 'part, module, element, block' may include multiple components.

[0051] Throughout the specification, when a part is said to be "connected" to another part, this includes not only direct connection but also indirect connection, and indirect connection includes connection via a wireless communication network.

[0052] Additionally, when a part is said to "include" a component, this does not mean that it excludes other components, but rather that it may include other components, unless otherwise specifically stated.

[0053] Throughout the specification, when we say that an element is "on" another element, this includes not only cases where the element is in contact with the other element, but also cases where another element exists between the two elements.

[0054] The terms first, second, etc. are used to distinguish one component from another, and the components are not limited by the aforementioned terms.

[0055] Singular expressions include plural expressions unless the context clearly indicates otherwise.

[0056] The identification codes for each step are used for convenience of explanation and do not describe the order of each step. Each step may be performed in a different order than specified unless the context clearly indicates a specific order.

[0057] The operating principle and embodiments of the present invention will be described with reference to the attached drawings below.

[0058] Figure 1 is a schematic diagram illustrating the disclosed distributed consensus system, and Figure 2 is a control block diagram of individual nodes executing the distributed consensus system's processes. To avoid redundant explanations, they are described together.

[0059] Referring first to FIG. 1, a distributed consensus system (1) according to one disclosed embodiment may be a set of computer programs in which a plurality of nodes (10), such as a first node (10-1), a first node (10-2), a first node (10-3), and a first node (10-4), are connected via a network. This distributed consensus system (1) may utilize computer resources in each computing node to achieve a shared common goal.

[0060] Referring to FIG. 2, each node (10-1, 10-2, 10-3 or 10-4) of the distributed consensus system (1) may be composed of a communication unit (11), a processor (12) and a memory (13).

[0061] Specifically, the communication unit (11) is a configuration for transmitting and receiving messages and data between nodes (10) via a network. The communication unit (11) may include one or more components that enable communication with an external device, and may include, for example, at least one of a short-range communication module, a wired communication module, and a wireless communication module.

[0062] The short-range communication module may include various short-range communication modules that transmit and receive signals using a wireless communication network at a short distance, such as a Bluetooth module, an infrared communication module, an RFID (Radio Frequency Identification) communication module, a WLAN (Wireless Local Access Network) communication module, an NFC communication module, and a Zigbee communication module.

[0063] The wired communication module may include various wired communication modules such as a Controller Area Network (CAN) communication module, a Local Area Network (LAN) module, a Wide Area Network (WAN) module, or a Value Added Network (VAN) module, as well as various cable communication modules such as a Universal Serial Bus (USB), a High Definition Multimedia Interface (HDMI), a Digital Visual Interface (DVI), RS-232 (recommended standard 232), power line communication, or plain old telephone service (POTS).

[0064] The wireless communication module may include a wireless communication module that supports various wireless communication methods such as GSM (global System for Mobile Communication), CDMA (Code Division Multiple Access), WCDMA (Wideband Code Division Multiple Access), UMTS (universal mobile telecommunications system), TDMA (Time Division Multiple Access), and LTE (Long Term Evolution), in addition to a WiFi module and a WiBro (Wireless broadband) module.

[0065] Node (10) may be implemented with a memory (13) that stores data on an algorithm for controlling the operation of components of each node, such as a communication unit (11), an input / output unit (not shown), or a program that reproduces the algorithm, and a processor (12) that performs the aforementioned operation using the data stored in the memory. In this case, the memory (13) and the processor (12) may each be implemented as separate chips. Meanwhile, unlike FIG. 2, the memory (13) and the processor (12) may also be implemented as a single chip.

[0066] Memory (13) may be implemented as at least one of non-volatile memory elements such as cache, ROM (Read Only Memory), PROM (Programmable ROM), EPROM (Erasable Programmable ROM), EEPROM (Electrically Erasable Programmable ROM), and flash memory, or volatile memory elements such as RAM (Random Access Memory), or storage media such as a hard disk drive (HDD) or CD-ROM, but is not limited thereto.

[0067] The processor (12) is responsible for the control part for carrying out the operation of the node (10) and the initiated consensus protocol, and below, the operation of the node (10) will be described as the operation of a process executed in the processor (12).

[0068] Meanwhile, in addition to each configuration of the node (10) illustrated in FIG. 2, the node (10) may further include several other hardware configurations. Below, a description will be given of how the disclosed distributed consensus system (1) performs a consensus protocol.

[0069] Figure 3 is a diagram for explaining the normal state consensus algorithm of a conventional consensus protocol.

[0070] In a distributed consensus system (1), processes execute a steady-state consensus algorithm to process a target task, and each process can individually and distinctly utilize its own resources.

[0071] Referring to Figure 3, each process P of node (10) in operation 20 i Each time a new consensus round starts, the first timer C i normal You can set up and start.

[0072] Process P of node (10) at action 30 i can attempt to reach an agreement by exchanging messages with other processes.

[0073] Process P of node (10) at action 40 i If an agreement is reached before the first timer expires, the next consensus round can begin.

[0074] If the first timer expires before consensus is successful, process P of node (10) in action 50 i can interrupt the normal state algorithm and execute the view change algorithm.

[0075] Figure 4 is a diagram for explaining the view change algorithm of a conventional consensus protocol.

[0076] Referring to Figure 4, process P of node (10) in operation 60 i After increasing the first view value (current view value) by 1 and setting the second view value (new view value), the second timer C i view You can start the view change by setting the start.

[0077] Process P of node (10) at action 70 i can attempt to change views by exchanging messages with other processes.

[0078] Process P of node (10) at action 80 i is the second timer C i view If the view change succeeds before the expires, the view change algorithm can be terminated and the normal state consensus algorithm can be executed.

[0079] If the view change is successful before the second timer C i view When expired, process P of node (10) in action 90 i increases the second view value by 1 and starts the second timer C i view You can retry the view change by restarting .

[0080] Figure 5 is a diagram illustrating a problem in which a common view change section may not exist in a conventional consensus protocol.

[0081] Conventional consensus protocols such as PBFT and Zyzzyva use a second timer T every time a view change fails consecutively. i view The value of 2△ view , 4△ view , 8△ view It increases exponentially, as shown in Fig. 5. This is to ensure a common view change period of sufficient size, but as can be seen in Fig. 5, this is not the case in reality.

[0082] Referring to Fig. 5, P1 starts a view change at t1 with the second view value (new view value) 4, and P2 starts a view change at t2 with the second view value (new view value) 6. In Fig. 5, it can be seen that there is no intersection of the intervals in which the two processes attempt view changes for the same new view value, that is, no common view change interval. It can also be seen that even if the processes double the value of the second timer each time they retry the view change, thereby increasing the interval in which they attempt view changes, they cannot obtain a common view change interval.

[0083] Figure 6 is a diagram illustrating a problem in which the size of a common view change interval does not increase even if it exists in a conventional consensus protocol.

[0084] Referring to Figure 6, process P1 starts a view change at time t1 with a new view value of 4, and at this time, the second timer C1 view The value of △ view is set to . Process P2 starts a view change at t2 with a new view value of 5, and a second timer C2 view The value of △ view is set to . In this case, [t1+ △ view , t2+ △ view ] is a common view change interval for the new view value 5, and there is a possibility that the view change will succeed because two processes simultaneously attempt a view change for the same new view value 5. However, the common view change interval [t1+ △ view , t2+ △ view ] is not large enough, i.e. t2- t1 is △ viewIf it is not equal to or greater than , the success of the view change is not guaranteed. After this, both processes double the second timer value each time the view change fails, but the size of the common view change interval does not increase and remains constant.

[0085] FIG. 7 is a diagram for explaining a timer control method of a distributed consensus system capable of obtaining a common view change interval of sufficient size according to various embodiments of the present invention.

[0086] The core idea of ​​the disclosed control method is to increase the size of the view change interval each time a view change is retried, but to ensure that the intervals in which processes attempt view changes for the same new view value are all the same size.

[0087] Figure 7 illustrates an example in which the sizes of the intervals in which processes attempt to change views for the same new view value are all set to be the same using the timer control method according to the disclosed embodiment. Specifically, the sizes of the intervals in which processes attempt to change views for the new view value 9 are all set to be the same 4△ view If the view change fails and the new view value increases to 10, the size of the interval in which all processes attempt the view change is the same, 5△ view It should be noted that the size of the common view change interval also increases, and that the size of the common view change interval also increases when the value of the second timer is linearly increased. This property can be mathematically proven, but it is omitted in this disclosure.

[0088] FIG. 8 is a flowchart illustrating a timer control method of a distributed consensus system that sets a second timer so that the length of the intervals in which processes attempt to change views for the same new view value are all the same, according to various embodiments.

[0089] Referring to Figure 8, each process P of node (10) in operation 100 i is the second view value V i new Set up V first i new Based on the second timer C i view The value of T i view You can set and start the value T of the second timer. i view There are many ways to set V, one way is as in Equation 1 i new It uses an increasing function f() that has as its only variable.

[0090] [Mathematical Formula 1]

[0091] T i view = f(V i new )

[0092] However, f(V i new ) has a minimum value of △ view It must be a value greater than or equal to . As an example that satisfies this condition, the function f() defined in mathematical expression 2 can be used.

[0093] [Equation 2]

[0094] f(V i new ) = V i new Х △ view

[0095] Using Equation 2, all processes have the same second timer value for the same second view value, and thus the size of the common view change interval increases monotonically until a sufficiently large common view change interval is eventually obtained. For example, the value of the new view V i new= When 8, the second timer value of all processes is 8△ view is set to , and the value V of the new view i new = When it is 9, the second timer value of all processes is 9△ view can be set to .

[0096] However, if Equation 1 or Equation 2 is used, the initial value of the second timer used to start the view change may be too large, which may cause the time required for the view change to succeed to be too long. For example, consider a process P with a first view value of 7. i When the view change algorithm starts, the second view value V i new Since it is 8, the value of the second timer is 8△ view can be set to . If V i new = If the view change fails due to an error in the leader candidate to be selected from 8, process P i is set by the second timer to a maximum of 8△ view After waiting for the time of V i new = You can retry the view change to 9.

[0097] Another way to implement the aforementioned idea is to introduce the concept of a third view (anchor view) and set the value of the second timer based on the second view value (new view value) and the third view value (anchor view value). This method can be effective in reducing the initial value of the second timer.

[0098] Process P i The first view value (current view) of V i current , and the third view value (anchor view) is V i anchor Let's represent process P iis the third view value V i anchor The value can be set according to mathematical formula 3.

[0099] [Equation 3]

[0100] V i anchor = V i current

[0101] Second Timer C i view The value of T i view is V i new Increasing function g() for V i new It can be set according to mathematical formula 4 using the function g() whose partial derivative value is greater than 0.

[0102] [Equation 4]

[0103] T i view = g(V i new , V i anchor )

[0104] However, g(V i new , V i anchor ) has a minimum value of △ view It must be equal to or greater than . As an example that satisfies this condition, the function g(V) defined in mathematical expression 5 i new , V i anchor ) can be used.

[0105] [Equation 5]

[0106] g(V i new , V i anchor ) = (V i new - V i anchor ) Х △ view

[0107] Referring to Equation 4 or Equation 5, if the third view value V of all processes i anchor If we can make them equal in value, then the processes will always have the same second view value V i new may have the same second timer value.

[0108] Let the total number of processes be 3f + 1. If the distributed consensus system has reached an agreement just before starting a view change, the first view values ​​of more than a threshold, that is, more than 2f + 1 processes, are all the same. If those processes set their third view values ​​to the same value as the first view value according to Equation 3, the third view values ​​of more than 2f + 1 processes all become the same. Typically, when a distributed consensus system starts, the initial value of the first view values ​​of the processes is set to 1. Therefore, if the system has not reached an agreement before starting a view change, the third view values ​​of all processes are the same 1. Consequently, at any moment, more than 2f + 1 processes always have the same third view value, and such a third view value is called a global anchor view value and is denoted by V anchor Let's express it as .

[0109] Meanwhile, at most f processes have a global anchor view value V anchor , and may have different third view values. Such processes are those that have not reached an agreement just before starting a view change, and their first view values ​​are equal to or less than the first view values ​​of the 2f + 1 processes that have reached an agreement. Therefore, their third view values ​​must also be equal to or less than the global anchor view value. For such f or fewer processes, the global anchor view value V is determined by the following method. anchor It can be made to have the same third view value.

[0110] Again, in operation 110, the processes of node (10) can exchange view change messages containing their third view values ​​and proofs thereof with other processes.

[0111] In operation 120, the processes of node (10) can check whether a change in the second timer value is required and change the second timer value. For example, process P i Its own third view value V i anchor Another third view value V with a larger value j anchor If found, you can change the second timer value.

[0112] If it is determined that a change in the second timer value is necessary, in operation 130, the processes of node (10) can change and restart the second timer. For example, process P i Change the third view value according to Equation 6 and T according to Equation 4 i view You can restart the second timer by changing .

[0113] [Equation 6]

[0114] V i anchor = V j anchor (if V i anchor < V j anchor )

[0115] Any process P i The third view value V i anchor is always the global anchor view value V anchor Since it is equal to or less than, the third view values ​​of the processes are eventually equal to the global anchor view value V by mathematical expression 6. i anchor It converges to .

[0116] However, V changed according to mathematical formula 6 i anchor Go V i new There may be cases where it is equal to or greater than V, in which case V is calculated according to Equation 7. i new Let's change that too.

[0117] [Equation 7]

[0118] V i new = V i anchor + 1

[0119] Process P i The third view value V i anchor When sending V to another process i anchor A proof that the value is correct must be transmitted together. Otherwise, a faulty process that has a Byzantine error can propagate an arbitrary value, causing the third view values ​​of the processes to diverge. To prevent this, each process P i is V i anchor V is the same value as i current At the time of commit, a set of messages received from a threshold number of other processes is used as proof. This prevents the propagation of invalid third-view values ​​from processes that have Byzantine errors.

[0120] If we consider only crash fault tolerance and not Byzantine fault tolerance, V i anchor It is enough to just spread the word, V i anchor The proof for can be omitted.

[0121] If it is determined that a change in the second timer value is not necessary, in operation 140, the processes of node (10) can check whether the view change was successful before the second timer expires.

[0122] If the view change is successful before the second timer expires, at operation 150, the processes of node (10) can terminate the view change algorithm and start the normal state consensus algorithm.

[0123] If the view change is not successful and the second timer expires, the processes of node (10) can return to operation 100, increase the second view value by 1, and retry the view change by updating the second timer value according to mathematical expression 4 or mathematical expression 5.

[0124] Using the timer control method for the aforementioned distributed consensus system, a sufficiently large common view change interval, which was not guaranteed by conventional consensus protocols, can be achieved. This means that the consensus protocol's liveness can be satisfied. Furthermore, by using linearly growing timer values ​​instead of the exponentially increasing ones used in conventional consensus protocols, the speed of view changes can also be improved.

Claims

1. A control method for electing at least one process as a leader in a distributed system including multiple processes, An operation in which at least one process among the plurality of processes sets a second view value that is at least slightly increased from a first view value based on a first timer and sets and starts a second timer based on the second view value; An action of at least one process sending a message containing information necessary for setting the second timer to the remaining plurality of processes; An operation of at least one process receiving and examining information necessary for setting the second timer; and A timer control method of a distributed consensus system, wherein at least one process includes an operation of resetting and restarting the second timer based on the inspection result.

2. In paragraph 1, The operation of setting the second view value and setting and starting the second timer based on the second view value is as follows: Setting a second timer so that the intervals during which processes attempt to change views for the same second view value are all the same size; and A timer control method of a distributed consensus system including an operation of linearly increasing the second timer.

3. In paragraph 2, The operation of setting the second timer so that the length of the interval during which the processes attempt to change views for the same second view value is all the same is, A timer control method of a distributed consensus system, comprising an operation of setting the second timer based on the second view value and the third view value.

4. In paragraph 1, The action of sending a message containing the information required for setting the second timer to the remaining multiple processes is as follows: An operation of generating a proof for the third view value using messages from other processes that were received when committing on the first view value, such as the third view value; and A timer control method of a distributed consensus system including an operation of transmitting the third view value and the proof together in a view change message to other processes.

5. In paragraph 1, The operation of receiving and checking the information required for setting the second timer is as follows: A timer control method of a distributed consensus system, comprising an operation of comparing whether one's own third view value is less than a third view value received from another process.

6. In paragraph 1, The action of resetting and restarting the second timer based on the above test results is: Action to change your own third view value; If the third view value is equal to or greater than the second view value, an action of changing the second view value to a value that adds 1 to the third view value; and A timer control method of a distributed consensus system, comprising an operation of resetting and restarting the value of a second timer based on an updated third view value and a second view value.

7. In electronic devices, A communications unit that transmits and receives messages and data with other electronic devices over a network; A processor that performs control for the operation of the electronic device and for proceeding with the agreement protocol; and A memory storing instructions for a control algorithm or a program reproducing said control algorithm, The above instructions are, An electronic device configured to set a second view value that is at least slightly increased from a first view value based on a first timer, set and start a second timer based on the second view value, transmit information necessary for setting the second timer to the remaining plurality of processes by including the information in a message, and have the at least one process receive and examine the information necessary for setting the second timer, and have the at least one process reset and restart the second timer based on a result of the examination.

8. In paragraph 7, The above instructions are, An electronic device configured to set a second timer so that the length of the interval during which the processes attempt to change views for the same second view value is all the same, and to linearly increase the second timer.

9. In paragraph 8, The above instructions are, An electronic device configured to set the second timer based on the second view value and the third view value.

10. In paragraph 7, The above instructions are, An electronic device configured to generate a proof for a third view value using messages received from other processes when committing to a first view value such as a third view value, and to transmit the proof and the third view value together in a view change message to other processes.

11. In paragraph 7, The above instructions are, An electronic device set to compare whether its own third view value is less than a third view value received from another process.

12. In paragraph 7, The above instructions are, An electronic device configured to change its own third view value, and if the third view value is equal to or greater than the second view value, change the second view value to a value that is the third view value plus 1, and reset and restart the value of a second timer based on the updated third view value and the second view value.

Images