KR20220141170A - Leader election method using federated learning for private blockchain, recording medium and device for performing the method - Google Patents

Abstract

A leader election method using federative learning in a private blockchain comprises the following steps of: monitoring parameters of a number of transitions from each node of a private blockchain to a candidate node, freshness of a log index, and a set timeout time; generating a federative learning model by learning about a relationship between the parameters and network stability for previous leaders; calculating a weight that each parameter contributes to the network stability according to the generated federated learning model; calculating a network stability value by applying the calculated weight to each parameter; and if election of a leader is consented, electing the leader by reflecting the calculated network stability. Accordingly, by electing a leader that can guarantee optimized performance according to flexible network environment conditions through an improved raft algorithm, a block confirmation time is shortened to improve performance.

Description

LEADER ELECTION METHOD USING FEDERATED LEARNING FOR PRIVATE BLOCKCHAIN, RECORDING MEDIUM AND DEVICE FOR PERFORMING THE METHOD

The present invention relates to a method for selecting a leader using federated learning in a private block chain, a recording medium and an apparatus for performing the same, and more particularly, a network split problem occurring in a raft algorithm of a private block chain. It is about a technology that improves the leader election mechanism by grafting federated learning to solve the problem.

Recently, business cases using blockchain are increasing in companies in various fields such as software, energy, financial services, and healthcare. In particular, Forbes predicted that enterprise blockchain, a private blockchain in which companies participate, will continue to develop and lead innovation in business processes.

Blockchain refers to a technology in which all nodes maintain the same chain in which blocks containing data are connected in a peer-to-peer distributed network system. The blockchain consists of a ledger, a technology that shares data between nodes connected to a chain, and a consensus algorithm technology, a technology that maintains the consistency of the ledger shared by all nodes. The consensus algorithm maintains the integrity and accuracy of data by applying an appropriate consensus algorithm method that can be used efficiently according to the user's environment.

The consensus algorithm applied depends on the blockchain network environment, and the blockchain network environment can be divided into two environments. It is a public blockchain where anyone can participate as a node and participate in the consensus process, and a private blockchain where only limited users can participate in the node and participate in the consensus process.

Representative consensus algorithms used in private blockchains are PBFT (Practical Byzantine Fault Tolerance) and raft. In PBFT, since a commit message is exchanged between all nodes at each stage of consensus, the complexity of the communication message is large, and thus there is a limit in scalability.

On the other hand, the raft algorithm is a leader-based consensus algorithm, and it is simple because the leader duplicates the log of processing all client requests and transmits it to the node. In addition, since the message related to the client's request flows in only one direction from the reader to the other server, it is possible to agree on a lower communication cost compared to PBFT.

However, in the raft algorithm, when the leader's communication is unstable, the probability of node failure and communication interruption due to packet loss increases. This results in a network split where more than half of the nodes are out of the control of the current leader. When network segmentation occurs in the raft algorithm, the period is changed to a new leader election period. During the leader election period, the network stops processing client requests.

Therefore, TPS (Transaction Per Second) throughput is reduced and block confirmation time is delayed. Since TPS and block confirmation time affect the overall consensus time, they correspond to the main consensus performance criteria. Therefore, the raft algorithm has a weakness that the consensus performance is affected by the network stability of the node.

KR 10-2021-0025411 A KR 10-2021-0022852 A KR 10-2021-0010044 A

D. Ongaro and J. Ousterhout, "In search of an understandable consensus algorithm," 2014 USENIX ATC pp. 305-319., 2014.

Accordingly, the technical task of the present invention was conceived in this regard, and an object of the present invention is to provide a method for selecting a leader using federated learning in a private blockchain.

Another object of the present invention is to provide a recording medium in which a computer program for performing a leader election method using federated learning in the private block chain is recorded.

Another object of the present invention is to provide an apparatus for performing a leader election method using federated learning in the private block chain.

In the method for selecting a leader using federated learning in a private blockchain according to an embodiment for realizing the object of the present invention, the number of conversions from each node of the private blockchain to a candidate node, the log index and monitoring parameters of the set timeout time; generating a federated learning model by learning about the relationship between parameters and network stability for previous leaders; calculating a weight that each parameter contributes to the stability of the network according to the generated federated learning model; calculating a network stability value by applying the calculated weight to each parameter; and when the leader election is agreed upon, selecting a leader by reflecting the calculated network stability.

In an embodiment of the present invention, the step of selecting a leader by reflecting the calculated network stability includes: converting a node in a follower state to a candidate state when the connection with the leader is cut; a node in the candidate state votes for itself and increases the term by one; and transmitting, to all nodes, a leader election request message including parameters of the number of converted candidate nodes, the freshness of a log index, and a set timeout time to all nodes.

In an embodiment of the present invention, the step of selecting a leader by reflecting the calculated network stability may further include a step of changing the state to a leader when the nodes in the candidate state receive a vote from a majority or more.

In an embodiment of the present invention, the step of selecting a leader by reflecting the calculated network stability comprises: checking whether a candidate has a higher term than himself; checking whether it is null or a candidate ID; verifying that the candidate's log is at least as up-to-date as his own; and checking whether the network stability value of the candidate exceeds a threshold value.

In an embodiment of the present invention, the method for selecting a leader using federated learning in the private block chain may further include updating the global federated learning model by synthesizing the local federated learning model learned from each node at regular intervals. have.

In a computer-readable storage medium according to an embodiment for realizing another object of the present invention, a computer program for performing a leader election method using federated learning in the private block chain is recorded.

A leader election device using federated learning in a private block chain according to an embodiment for realizing another object of the present invention is the number of conversions from each node of the private block chain to a candidate node, the log index a parameter selector for monitoring the parameters of the freshness and the set timeout time; a federated learning unit that generates a federated learning model by learning about the relationship between parameters and network stability with respect to previous leaders; a weight calculation unit for calculating a weight that each parameter contributes to the stability of the network according to the generated federated learning model; a stability calculation unit for calculating a network stability value by applying the calculated weight to each parameter; and a voting unit that selects a leader by reflecting the calculated network stability value when the leader election is agreed upon.

In an embodiment of the present invention, the voting unit switches to the candidate state when the node in the follower state is disconnected from the leader, the number of conversions to the candidate node, the freshness of the log index, and the set timeout time A leader election request message including parameters of can be transmitted to all nodes.

In an embodiment of the present invention, the voting unit is configured such that the candidate has a higher term than itself, is null or a candidate ID, the candidate's log is at least as new as its own, and the candidate's network stability value If a condition exceeding this threshold is met, the candidate may be voted as the leader.

According to the leader election method using federated learning in such a private block chain, an improved raft algorithm reduces the frequency of network split problems and increases the computation processing period by reducing the occurrence of the network split problem, thereby increasing the private block related to transaction processing. Improves chain performance. As a result, data availability can be increased while ensuring integrity and transparency, the strengths of existing blockchains, through an improved raft algorithm in a private blockchain in an environment where the network is unstable.

1 is a block diagram of an apparatus for selecting a leader using federated learning in a private blockchain according to an embodiment of the present invention.
2 is a diagram for explaining the state transformation of a node in the raft algorithm used in the present invention.
3 is a view for explaining the associative learning used in the present invention.
4 is a diagram for explaining a data structure stored in the present invention.
5 is a table showing simulation results compared with the prior art in order to verify the performance of the present invention.
6 is a flowchart of a method for selecting a leader using federated learning in a private blockchain according to an embodiment of the present invention.
7 is a flowchart showing a leader election mechanism in the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS [0012] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS [0014] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS [0016] Reference is made to the accompanying drawings, which show by way of illustration specific embodiments in which the present invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the present invention. It should be understood that the various embodiments of the present invention are different but need not be mutually exclusive. For example, certain shapes, structures, and characteristics described herein with respect to one embodiment may be implemented in other embodiments without departing from the spirit and scope of the invention. In addition, it should be understood that the location or arrangement of individual components within each disclosed embodiment may be changed without departing from the spirit and scope of the present invention. Accordingly, the detailed description set forth below is not intended to be taken in a limiting sense, and the scope of the present invention, if properly described, is limited only by the appended claims, along with all scope equivalents to those claimed. Like reference numerals in the drawings refer to the same or similar functions throughout the various aspects.

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

1 is a block diagram of an apparatus for selecting a leader using federated learning in a private blockchain according to an embodiment of the present invention.

The leader election device (10, hereinafter device) using federated learning in the private block chain according to the present invention is a raft that improves the leader election mechanism by grafting federated learning to solve the network division problem that occurs in the existing raft algorithm. (raft) algorithm is proposed. The network segmentation is caused by the communication failure of the leader, so the leader election mechanism is improved so that the network elects a stable node as the leader.

First, as items for evaluating network stability, the number of times the candidate has been converted, the set timeout time, and the status of the log index are selected. The improved raft algorithm collects data on participating nodes based on this item and reduces the frequency of network splitting by selecting only nodes predicted to be stable through federated learning as leaders.

Referring to FIG. 1 , the device 10 according to the present invention includes a parameter selection unit 110 , a joint learning unit 130 , a weight calculation unit 150 , a stability calculation unit 170 and a voting unit 190 . do. The device 10 may be each node constituting the private blockchain or may be a part of each node.

In the device 10 of the present invention, software (application) for performing leader election using federated learning in a private block chain may be installed and executed, and the parameter selection unit 110, the federated learning unit 130, The configuration of the weight calculation unit 150, the stability calculation unit 170 and the voting unit 190 is software for performing leader election using federated learning in the private blockchain executed in the device 10. can be controlled by

The device 10 may be a separate terminal or may be a part of a module of the terminal. In addition, the configuration of the parameter selection unit 110, the joint learning unit 130, the weight calculation unit 150, the stability calculation unit 170 and the voting unit 190 is formed as an integrated module, or one It may consist of more than one module. However, on the contrary, each configuration may be formed of a separate module.

In general, transaction throughput and transaction latency are used when evaluating the performance of a blockchain for consensus. Transaction latency refers to the time between when a transaction is requested and when it is finally committed. In order for the blockchain to have high performance, the transaction latency must be short.

Transaction throughput indicates the rate of processing valid transactions within a specified period and is expressed as number of transactions per second (TPS). The higher the TPS, the better the performance.

The raft algorithm is a leader-based consensus algorithm and is operated by the leader to accept client requests and process requests in all nodes. However, since the byzantine fault is not considered, it is applied as a consensus algorithm in a private blockchain that assumes that all nodes can be trusted.

Raft operates by three mechanisms: leader election, log replication, and safety.

Referring to FIG. 2 , a raft divides a node into three roles: a leader (leader), a candidate (candidate), and a follower (follower). Raft is based on a state replication machine, and each node must be in one of three states.

The leader receives the client's request and delivers the log including this to other nodes. Only the leader can direct the log forwarding and executing the commands contained in the log. Leaders periodically send RPC messages with logs to their followers. RPC message is called AppendEntries and contains contents related to the leader's term, leaderId, and Log. A term means a temporal order in a raft.

When the follower receives the AppendEntries, it sends to the leader that the leader's request has been accepted and the current term. And the follower updates the state machine with the commands contained in the log. As a result, the follower maintains the same sequential log and state as the leader. The log stores the contents requested by the client and the term together in one index in the form of a list. A sequential log is maintained through an index and a term.

In FIG. 2 , a state transition occurs in a node by an RPC message and a timeout. There are two types of timeout: the heart beat timeout of the leader and the leader election timeout of the follower. The heart beat timeout is the interval at which the leader sends the AppendEntries message.

Each time the leader times out, it proves its survival through the AppendEntries message and delivers the log. If the follower does not receive the leader's AppendEntries message within the leader election timeout time, it is judged that there is a problem with the leader and is converted to a candidate. This is called the leader election period. The process of selecting a leader is as follows.

When a candidate becomes a candidate, the candidate increases his or her term by one and sends a RequestVote RPC message requesting a vote to all nodes in the network. RequestVote RPC contains the candidate's current term, candidate ID, and the index and term of the candidate's last log. Upon receiving the RequestVote message, the follower checks whether the candidate meets the criteria for becoming a leader.

If the criteria for becoming a leader are met, the node sends an acknowledgment message with its current term. If more than half of the followers who have sent the approval message, the candidate will be elected as the leader, otherwise it will return to the followers. At this time, the leader election timer is set randomly in order to reduce the probability that several candidate nodes will be converted into followers at the same time.

In a raft, only the leader can handle a client's request. Therefore, the client must ask the leader for an order to be processed. The leader records the client's request in a log, replicates the log to the rest of the server, executes the command in the log and commits it completely, and sends a response to the client indicating that the request was successful.

When consensus is initiated, the client requests processing from a randomly selected server among the servers in the network because there is no information about the leader of the current term. If this selected server is not the leader, it responds with information about the leader of the current term while rejecting the request to the client. However, when there is no leader, such as during the leader election period, a request is made to a random server like the beginning of consensus, and the request is repeated until the request is successful.

In the raft algorithm, packet loss or delay causes network instability between nodes. Network split means that the leader and more than half of the nodes in the network are disconnected. In other words, network segmentation can be said to be the same as the leader election period in a raft. Therefore, an unstable network of nodes causes frequent leader election periods in the raft consensus algorithm.

However, if consensus is in progress on the blockchain by the raft algorithm, the client cannot request a command related to block generation including the transaction from the node when the leader election period is reached by the network split. This delays the block generation time, which inevitably increases the delay time and reduces the TPS. Therefore, by the method of evaluating the consensus performance of the blockchain, it can be said that frequent network splitting degrades the blockchain consensus performance.

Therefore, the present invention aims to reduce the probability that a network split occurs in order to prevent the performance of the blockchain consensus from being deteriorated. Since network segmentation occurs more frequently as the network connection between the leader and other nodes becomes unstable, the probability of occurrence can be reduced by electing a stable node as the next node.

The parameter selector 110 monitors the number of transitions from each node of the private block chain to the candidate node, the freshness of the log index, and the parameters of the set timeout time.

The present invention selects three parameters for evaluating the network stability of a node in a raft. The parameters are as follows.

1) Number of conversions to candidate nodes

If the network connection between the nodes is unstable, the connection with the leader is lost and there is a high probability of being converted into a candidate. Therefore, network stability can be determined through the number of candidate nodes.

2) Up-to-dateness of log index

A node with unstable communication with its leader cannot keep its logs up to date. Therefore, the network stability can be known through the degree to which the last index of the log is smaller than that of the node being compared.

3) Set timeout time

The set timeout time affects the probability of network splitting. The smaller the set timeout, the higher the probability of network splitting. Therefore, the timeout should also be added as a network performance evaluation parameter.

The federated learning unit 130 generates a federated learning model by learning about the relationship between parameters and network stability for previous leaders.

Federated learning is a type of distributed machine learning, which is machine learning that uses distributed training data to train DNNs and Deep Neural Networks. Federated learning improves the accuracy of prediction results by distributing and learning the same learning model and gathering them in one place to create a more sophisticated model.

Referring to FIG. 3 , all servers share the same initial learning model. And each server trains the model using different data. The cloud updates the model with the average value of the parameters of the model learned by each server and repeats the process of learning by each server that receives the parameters of the model again.

The consensus algorithm refers to a technology that allows the system to be maintained even if one failure node exists in a distributed network environment. A raft is a consensus algorithm that allows crash faults. It means that even if a crash occurs in hardware, up to half of the nodes participating in the network can be tolerated.

Connections between nodes participating in raft consensus have different network stability. Therefore, the data to be monitored for the network is different for each. If the local model is learned distributedly according to their data, and the leader node synthesizes it and synchronizes it to the global model, it has the meaning of delegating consensus because the local model of the node is reflected in the global model.

In addition, federated learning has the advantage that it can prevent the limitations of centralized networks such as SPOF (Single Point Of Failure) from occurring and the load on the storage space of the server is small. Therefore, it can be said that federated learning is more suitable for a blockchain network environment than a method for learning a model on a central server.

Therefore, the present invention repeats the process of selecting a stable leader by monitoring the network stability of each node while all mechanisms except for leader election follow the existing raft method, and jointly learning using this data.

When switching to a candidate node, a RequestVote message is sent to all nodes in the network. At this time, the RequestVote message is transmitted including the term and the latest index of the node. In the present invention, the node ID and timeout are added and transmitted.

Accordingly, corresponding parameters can be measured through the RequestVote message transmitted by the candidate node. If the network between the nodes is unstable, we cannot be sure which of the two nodes is unstable, but since the data will be aggregated through federated learning, we assume that the node measuring the data has no problem.

Referring to FIG. 4 , the data counted for the parameter is stored in the list together with the term in the same way as the log storage method. In addition, parameter measurement values for each node are stored in two dimensions, and since all nodes participating in the network are monitored, each node finally has three-dimensional data. And all nodes use this data to train a federated learning model for selecting the next leader.

The weight calculation unit 150 calculates a weight that each parameter contributes to the stability of the network according to the generated federated learning model, and the stability calculation unit 170 calculates a network stability value by applying the calculated weight to each parameter. do.

In federated learning, the local model that each node learns calculates the influence (weight) of the parameter on the network stability through the relationship between the number of candidates for the term and the parameter. Then, based on this, the network stability score between 0 and 1 of the nodes is calculated, and this score is reflected in electing the next leader.

And in the learning model, the leader becomes the server and the global model is updated by synthesizing the local model at regular intervals, and federated learning proceeds.

All nodes participating in the network have network stability with respect to other nodes through federated learning. When a candidate occurs, followers vote as the next leader only when the candidate's network stability is higher than a threshold (eg, 0.5), so that the leader is elected only when the network is stable. The reason why the standard for network stability is set to 0.5 is that the lower the number, the harder it is to say that the network is really stable.

When the leader election is agreed upon, the voting unit 190 selects a leader by reflecting the calculated network stability value.

Process client requests by replicating and committing logs around the leader before the leader election period occurs. At the same time, all nodes accumulate the data that monitors the network status and proceed with federated learning.

When a follower loses connection with a leader, he or she transitions to a candidate. After voting for themselves, the candidate increases the term by one and sends a RequestVote RPC to all nodes including the term, the last index number, and the set timeout time.

Followers who receive a RequsetvoteRPC record monitoring data and judge whether they meet the standards of the new leader. The judgment is as follows.

1) You have a higher term than me.

2) Null or candidate ID.

3) The candidate's log is at least as up-to-date as his own.

4) The combined learning result for the candidate is greater than 0.5.

If all of the above conditions are met, the follower sends a response voting the candidate as leader. Candidates become leaders when they receive a majority of votes. Otherwise, the candidate becomes a follower again.

Simulations for evaluating the performance of the present invention were performed with a raft consensus algorithm written in Python in a Linux environment. And it is assumed that membership change does not occur during the simulation where new nodes participate in consensus.

As for the raft algorithm, the smaller the network scale and the smaller the set timeout, the higher the probability of network splitting. Therefore, in order to assume an environment in which a lot of network partitioning occurs, a node with this small timeout is included, and the probability of communication failure of the node increases as the timeout is small was simulated.

5 is a result of comparing the original raft and the mechanism proposed by the present invention with respect to the number of terms that are changed while processing 100 logs periodically occurring at regular time intervals.

Referring to FIG. 5 , the network scale means the number of nodes. When the number of nodes is less than 400, there is no difference in the number of terms between the existing raft algorithm and the method proposed in the present invention. However, it can be seen that the number of terms of the mechanism proposed in the present invention is smaller than that of the existing raft consensus method as the model is learned as the network scale increases.

Since the term is increased by one each time the leader is changed, the higher the frequency of network segmentation, the higher the number of terms. If the number of terms is small, the leader election period is short, so the delay time for processing the client's request is prevented. When the delay time for processing a client's request is shortened, it results in increasing the TPS of the blockchain agreed by the raft algorithm. Therefore, it can be said that the performance of the raft consensus used in the blockchain has improved.

The present invention proposes a method for selecting a leader according to network stability in a raft algorithm. This reduces the probability of network splitting of rafts when the network of blockchain nodes is unstable, thereby preventing degradation of blockchain performance.

6 is a flowchart of a method for selecting a leader using federated learning in a private blockchain according to an embodiment of the present invention. 7 is a flowchart showing a leader election mechanism in the present invention.

The method of selecting a leader using federated learning in the private block chain according to the present embodiment may proceed in substantially the same configuration as the device 10 of FIG. 1 . Accordingly, the same components as those of the device 10 of FIG. 1 are given the same reference numerals, and repeated descriptions are omitted.

In addition, the method for selecting a leader using federated learning in the private block chain according to this embodiment may be executed by software (application) for performing leader election using federated learning in the private block chain.

The present invention proposes a raft algorithm that improves the leader election mechanism by grafting federated learning to solve the network segmentation problem that occurs in the existing raft algorithm. The network segmentation is caused by the communication failure of the leader, so the leader election mechanism is improved so that the network elects a stable node as the leader.

Referring to FIG. 6 , in the method of selecting a leader using federated learning in the private blockchain according to this embodiment, the number of conversions from each node of the private blockchain to a candidate node, the latest log index, and a set timeout The parameters of time are monitored (step S10).

If the network connection between the nodes is unstable, the connection with the leader is lost and there is a high probability of being converted into a candidate. Therefore, network stability can be determined through the number of candidate nodes.

Also, nodes with unstable communication with the leader cannot keep their logs up to date. Therefore, the network stability can be known through the degree to which the last index of the log is smaller than that of the node being compared.

The set timeout time affects the probability of network splitting. The smaller the set timeout, the higher the probability of network splitting. Therefore, the timeout should also be added as a network performance evaluation parameter.

A federated learning model is created by learning about the relationship between parameters and network stability for previous leaders (step S20).

Federated learning is a type of distributed machine learning, which is machine learning that uses distributed training data to train DNNs and Deep Neural Networks. Federated learning improves the accuracy of prediction results by distributing and learning the same learning model and gathering them in one place to create a more sophisticated model.

All servers share the same initial training model. And each server trains the model using different data. The cloud updates the model with the average value of the parameters of the model learned by each server and repeats the process of learning by each server that receives the parameters of the model again.

The consensus algorithm refers to a technology that allows the system to be maintained even if one failure node exists in a distributed network environment. A raft is a consensus algorithm that allows crash faults. It means that even if a crash occurs in hardware, up to half of the nodes participating in the network can be tolerated.

Connections between nodes participating in raft consensus have different network stability. Therefore, the data to be monitored for the network is different for each. If the local model is learned distributedly according to their data, and the leader node synthesizes it and synchronizes it to the global model, it has the meaning of delegating consensus because the local model of the node is reflected in the global model.

In addition, federated learning has the advantage that it can prevent the limitations of centralized networks such as SPOF (Single Point Of Failure) from occurring and the load on the storage space of the server is small. Therefore, it can be said that federated learning is more suitable for a blockchain network environment than a method for learning a model on a central server.

Therefore, the present invention repeats the process of selecting a stable leader by monitoring the network stability of each node while all mechanisms except for leader election follow the existing raft method, and jointly learning using this data.

A weight that each parameter contributes to the stability of the network is calculated according to the generated federated learning model (step S30). A network stability value by applying the calculated weight to each parameter is calculated (step S40).

In federated learning, the local model that each node learns calculates the influence (weight) of the parameter on the network stability through the relationship between the number of candidates for the term and the parameter. Then, based on this, the network stability score between 0 and 1 of the nodes is calculated, and this score is reflected in electing the next leader.

And in the learning model, the leader becomes the server and the global model is updated by synthesizing the local model at regular intervals, and federated learning proceeds.

All nodes participating in the network have network stability with respect to other nodes through federated learning. When a candidate occurs, followers vote as the next leader only when the candidate's network stability is higher than a threshold (eg, 0.5), so that the leader is elected only when the network is stable. The reason why the standard for network stability is set to 0.5 is that the lower the number, the harder it is to say that the network is really stable.

When the leader election is agreed upon, a leader is elected by reflecting the calculated network stability (step S50).

Referring to Figure 7, each node performs federated learning by making a data set by measuring parameters for other followers while learning a model using the parameter data sets of previous leaders while generating blocks (step S11) .

When the node in the follower state is disconnected from the leader (step S12), it switches to the candidate state. When switching to a candidate node, a RequestVote message is sent to all nodes in the network. At this time, the RequestVote message is transmitted including the term and the latest index of the node. In the present invention, the node ID and timeout are added and transmitted.

Accordingly, corresponding parameters can be measured through the RequestVote message transmitted by the candidate node. If the network between the nodes is unstable, we cannot be sure which of the two nodes is unstable, but since the data will be aggregated through federated learning, we assume that the node measuring the data has no problem.

The follower who has received the RequsetvoteRPC records the monitoring data and judges whether it meets the criteria of the new leader (step S13). The judgment is as follows.

1) You have a higher term than me.

2) Null or candidate ID.

3) The candidate's log is at least as up-to-date as his own.

4) The combined learning result for the candidate is greater than 0.5.

If all of the above conditions are met, the follower sends a response voting the candidate as leader. Candidates become leaders when they receive a majority of votes. Otherwise, the candidate becomes a follower again (step S14).

The present invention improves the private blockchain performance related to transaction processing by reducing the frequency of occurrence of a network split problem by an improved raft algorithm and increasing the computation processing period. As a result, data availability can be increased while ensuring integrity and transparency, the strengths of existing blockchains, through an improved raft algorithm in a private blockchain in an environment where the network is unstable.

Such a method for selecting a leader using federated learning in a private block chain can be implemented as an application or implemented in the form of a program command that can be executed through various computer components and recorded in a computer-readable recording medium. The computer-readable recording medium may include program instructions, data files, data structures, etc. alone or in combination.

The program instructions recorded on the computer-readable recording medium are specially designed and configured for the present invention, and may be known and available to those skilled in the art of computer software.

Examples of the computer-readable recording medium include a hard disk, a magnetic medium such as a floppy disk and a magnetic tape, an optical recording medium such as a CD-ROM and DVD, and a magneto-optical medium such as a floppy disk. media), and hardware devices specially configured to store and execute program instructions such as ROM, RAM, flash memory, and the like.

Examples of program instructions include not only machine language codes such as those generated by a compiler, but also high-level language codes that can be executed by a computer using an interpreter or the like. The hardware device may be configured to operate as one or more software modules to perform processing according to the present invention, and vice versa.

Although the above has been described with reference to the embodiments, those skilled in the art can variously modify and change the present invention within the scope without departing from the spirit and scope of the present invention described in the claims below You will understand.

The raft algorithm, a representative consensus algorithm of the private blockchain, is used by many companies such as IBM and Blocko, but there is a lack of consensus research on an unstable network environment. The improved raft proposed in the present invention is a consensus technology that can improve blockchain performance in an unstable network environment, so VANET (Vehicle Ad-hoc Network), FANET (Flying Ad-hoc Network), which have relatively low network stability ), UWSN (Underwater Wireless Sensor Network), etc., can ensure improved data availability and reliability.

Accordingly, smart cities, smart farms, and underwater networks in which communication failures occur frequently due to the mobility, communication distance, and geographic obstacles of IIoT (Industrial Internet of Things), IoV (Internet of Vehicles), and IoUT (Internet of Under water Things) devices Performance can be improved by applying it to the environment. In addition, as it can flexibly cope with communication failures, it is a technology with wide scalability as it can improve performance in various industries such as sports, construction, and medical as well as in unstable network environments.

10: Leader Election Device Using Federated Learning in Private Blockchain
110: parameter selection unit
130: Union Learning Department
150: weight calculation unit
170: stability calculation unit
190: Voting Department

Claims (10)

monitoring the number of transitions from each node of the private blockchain to the candidate node, the freshness of the log index, and the parameters of the set timeout time;
generating a federated learning model by learning about the relationship between parameters and network stability for previous leaders;
calculating a weight that each parameter contributes to the stability of the network according to the generated federated learning model;
calculating a network stability value by applying the calculated weight to each parameter; and
When leader election is agreed upon, selecting a leader by reflecting the calculated network stability; A method of selecting a leader using federated learning in a private block chain, including.
The method of claim 1, wherein the step of selecting a leader by reflecting the calculated network stability comprises:
transitioning to the candidate state when the node in the follower state loses connection with the leader;
a node in the candidate state votes for itself and increases the term by one; and
Transmitting a leader election request message including parameters of the number of conversion to candidate nodes, log index updateness, and set timeout time to all nodes; further comprising, using federated learning in a private blockchain How to elect a leader.
The method of claim 2, wherein the step of selecting a leader by reflecting the calculated network stability comprises:
When the node in the candidate state receives a vote from a majority or more, the state is converted to a leader; a method for selecting a leader using federated learning in a private block chain, further comprising a.
The method of claim 1, wherein the step of selecting a leader by reflecting the calculated network stability comprises:
checking whether the candidate has a higher term than himself;
checking whether it is null or a candidate ID;
verifying that the candidate's logs are at least as up-to-date as their own; and
A method of selecting a leader using federated learning in a private block chain, including; checking whether the candidate's network stability value exceeds a threshold value.
According to claim 1,
The step of updating the global federated learning model by synthesizing the local federated learning model learned from each node at regular intervals; a method for selecting a leader using federated learning in a private block chain, further comprising a.
A computer-readable storage medium in which a computer program for performing the method for selecting a leader using federated learning in the private block chain according to claim 1 is recorded.
a parameter selection unit that monitors the number of transitions from each node of the private blockchain to a candidate node, the freshness of a log index, and parameters of a set timeout time;
a federated learning unit that generates a federated learning model by learning about the relationship between parameters and network stability with respect to previous leaders;
a weight calculation unit for calculating a weight that each parameter contributes to the stability of the network according to the generated federated learning model;
a stability calculation unit for calculating a network stability value by applying the calculated weight to each parameter; and
When leader election is agreed upon, a voting unit that selects a leader by reflecting the calculated network stability value; a leader election device using federated learning in a private block chain, including.
The method of claim 7, wherein the voting unit,
When a node in the follower state loses connection with the leader, it switches to the candidate state and sends all the leader election request messages including the parameters of the number of transitions to the candidate node, the freshness of the log index, and the set timeout time. A leader election device using federated learning in a private blockchain that transmits to nodes.
The method of claim 7, wherein the voting unit,
If the candidate has a higher term than itself, is null or a candidate ID, the candidate's log is at least as new as its own, and the candidate's network stability value exceeds the threshold , a leader election device using federated learning in a private blockchain that votes candidates as leaders.
The method of claim 7, wherein the voting unit,
A leader election device using federated learning in a private blockchain that converts the state to a leader when a node in the candidate state receives a majority vote or more.

Images