Dynamic configuration method and device of block chain consensus algorithm, equipment and storage medium

Abstract

The invention provides a dynamic configuration method and device for a block chain consensus algorithm, equipment and a storage medium. The method comprises the steps of obtaining a current configuration block; modifying the current configuration block according to service requirements to obtain a modified configuration block; obtaining a configuration updating proposal based on the current configuration block and the modified configuration block; packaging the configuration updating proposal into a transaction and submitting the transaction to an order node; the transactions are sequenced and packaged into a configuration updating block through an order node, and the configuration updating block is broadcasted to all peer nodes for configuration updating; and performing node leader election based on the updated configuration to complete a block chain consensus process. Through the implementation of the dynamic configuration method for the on-chain configuration, the on-chain configuration change based on the configuration block is realized, the whole system does not need to be stopped, and the convenience and practicability of the voting weight configuration in the block chain consensus process can be effectively improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication, in particular to a dynamic configuration method and device of a blockchain consensus algorithm, equipment and a storage medium. BACKGROUND

[0002] The blockchain is a kind of distributed technology with decentralization and data tamper resistance, and its application prospect is gradually expanding to medical treatment, education and other aspects. In the blockchain system, the consensus algorithm plays a crucial role. Since the blockchain itself is a distributed ledger, the nodes distributed in the world need to reach an agreement on the state of the entire ledger, so consensus is needed. The consensus layer of Hyperledger Fabric realizes pluggability, supports solo, Kafka and Raft algorithms, and at present, due to the compatibility and ease of understanding of the Raft algorithm, it has become the most recommended consensus algorithm of Hyperledger Fabric.

[0003] In the conventional fabric consortium chain, the configuration on the chain is often changed through the configuration file. However, before changing the configuration file, the consortium chain needs to be stopped running, and if the part related to the weight configuration is involved, the local configuration file of all nodes (including the leader node and the follower node) needs to be changed synchronously, and then the consortium chain is restarted, which will have a great impact on the use and operation of the consortium chain, and it is not convenient for the adjustment of the weight among the nodes and the allocation of the weight when the nodes join and leave. SUMMARY

[0004] The purpose of the present application is to provide a dynamic configuration method, device, equipment and storage medium of a blockchain consensus algorithm, which can at least solve the problem of low convenience and practicability caused by the need to stop the consortium chain running before changing the configuration file in the related art.

[0005] In order to solve the above technical problems, the first aspect of the embodiment of the present application provides a dynamic configuration method of a blockchain consensus algorithm, comprising:

[0006] obtaining a current configuration block;

[0007] modifying the current configuration block according to the business requirement to obtain a modified configuration block;

[0008] obtaining a configuration update proposal based on the current configuration block and the modified configuration block;

[0009] packing the configuration update proposal into a transaction and submitting it to an orderer node;

[0010] sorting and packing the transaction into a configuration update block by the orderer node, and broadcasting the configuration update block to all peer nodes for configuration update.

[0011] Perform node leader election based on the updated configuration to complete the blockchain consensus process.

[0012] The second aspect of the embodiments of the present application provides a dynamic configuration device of a blockchain consensus algorithm, comprising:

[0013] The first obtaining module is configured to obtain a current configuration block.

[0014] The modifying module is configured to modify the current configuration block according to a business requirement to obtain a modified configuration block.

[0015] The second obtaining module is configured to obtain a configuration update proposal based on the current configuration block and the modified configuration block.

[0016] The transaction module is configured to package the configuration update proposal into a transaction and submit the transaction to an orderer node.

[0017] The configuration module is configured to sort and package the transaction into a configuration update block by the orderer node, and broadcast the configuration update block to all peer nodes for configuration update.

[0018] The election module is configured to perform node leader election based on the updated configuration to complete the blockchain consensus process.

[0019] The third aspect of the present application provides an electronic device, comprising a memory and a processor, wherein the processor is configured to execute a computer program stored in the memory, and when the processor executes the computer program, each step of the dynamic configuration method of the on-chain configuration described in the first aspect of the embodiments of the present application is implemented.

[0020] The fourth aspect of the present application provides a computer readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, each step of the dynamic configuration method of the on-chain configuration described in the first aspect of the embodiments of the present application is implemented.

[0021] From the above, the embodiment of the application first acquires a current configuration block, then modifies the current configuration block according to service requirements to obtain a modified configuration block, acquires a configuration update proposal based on the current configuration block and the modified configuration block, and packs the configuration update proposal into a transaction and submits the transaction to an orderer node. Next, the orderer node sorts the transaction and packs it into a configuration update block, and broadcasts the configuration update block to all peer nodes for configuration update. Finally, node leadership election is performed based on the updated configuration to complete the blockchain consensus process. Through the implementation of the dynamic configuration method of the on-chain configuration of the application, on-chain configuration changes are realized based on the configuration block, without stopping the entire system, which can effectively improve the convenience and practicality of the configuration of voting weights in the blockchain consensus process.

[0022] It should be understood that the content described in this part is not intended to identify the key or important features of the application, nor is it used to limit the scope of the application. Other features of the application will become apparent from the following description. BRIEF DESCRIPTION OF DRAWINGS

[0023] In order to more clearly illustrate the technical solutions in the related art or the embodiments of the application, the following will briefly introduce the drawings needed to be used in the description of the related art or the embodiments of the application. Obviously, the drawings in the following description are only some embodiments of the application, and not all embodiments. For those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0024] Figure 1 A flowchart of a dynamic configuration method of a blockchain consensus algorithm provided by an embodiment of the application;

[0025] Figure 2 A Raft consensus election flowchart of a dynamic configuration method of a blockchain consensus algorithm provided by an embodiment of the application;

[0026] Figure 3 A program module diagram of a dynamic configuration device of a blockchain consensus algorithm provided by an embodiment of the application;

[0027] Figure 4 A module block diagram of an electronic device provided by an embodiment of the application;

[0028] Figure 5 A module block diagram of a computer readable storage medium provided by an embodiment of the application. DETAILED DESCRIPTION

[0029] In order to make the purposes, technical solutions and advantages of the present application more obvious and easy to understand, the present application will be described clearly and completely below in combination with the embodiments of the present application and the drawings, wherein the same or similar reference signs represent the same or similar elements or elements with the same or similar functions throughout. It should be understood that the various embodiments of the present application described below are only used to explain the present application and do not limit the present application, that is, based on the various embodiments of the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application. In addition, the technical features involved in the various embodiments of the present application described below can be combined with each other as long as they do not conflict with each other.

[0030] In the embodiments of the present application, the blockchain is a decentralized, data tamper-proof distributed technology, and its application prospect is gradually expanding to medical treatment, education and other aspects. In the blockchain system, the consensus algorithm plays a crucial role, because the blockchain itself is a distributed ledger, and the nodes distributed in the world need to reach an agreement on the state of the entire ledger, so consensus is needed. The consensus layer of Hyperledger Fabric realizes pluggability, supports solo, Kafka and Raft algorithms, and at present, due to the compatibility and ease of understanding of the Raft algorithm, it has become the most recommended consensus algorithm of Hyperledger Fabric.

[0031] In a conventional fabric consortium chain, the configuration on the chain is often changed by a configuration file, however, before changing the configuration file, the consortium chain needs to be stopped running, if the part involving the weight configuration is involved, the local configuration file of all nodes (including leader nodes and follower nodes) needs to be changed synchronously, and then the consortium chain is restarted, which will cause great influence on the use and operation of the consortium chain, and it is not convenient for the adjustment of the weight between nodes and the allocation of the weight when the nodes join and leave.

[0032] Therefore, there is a need in the art to solve the problem of low convenience and practicability caused by the need to stop the consortium chain running before changing the configuration file.

[0033] In view of the above problems, the embodiments of the present application propose a dynamic configuration method of a blockchain consensus algorithm, which is applied to an enterprise-level blockchain system, realizes chain configuration change based on a configuration block, does not need to stop the entire system, when there is a demand to assign corresponding consensus weights to different nodes, the method can adapt to the actual situation of flexible arrangement of node weights in business scenarios, thereby effectively improving the performance, security and consistency of the entire blockchain network, ensuring that the blockchain network can still run stably when facing complex business scenarios, achieving efficient and fair consensus effect.

[0034] Please refer toFigure 1 , Figure 1 A flowchart of a dynamic configuration method of a blockchain consensus algorithm according to the first aspect of the embodiments of the present application is shown in FIG. 1. The dynamic configuration method of the on-chain configuration includes the following steps 101-106.

[0035] Step 101: Obtain the current configuration block.

[0036] In the embodiments of the present application, the current configuration block needs to be obtained before modification. Specifically, the client (orderer node: supervisor node or ordinary node) sends a request to one Peer node in the channel through Fabric SDK or CLI tool to extract the current configuration block. The content of the configuration block is a binary file in Protobuf format, which contains all the configuration information of the channel.

[0037] Step 102: Modify the current configuration block according to the business requirements to obtain the modified configuration block.

[0038] In the embodiments of the present application, the client can then modify the configuration block based on the business requirements, for example, adding or deleting organizations, modifying endorsement policies, and modifying access control rules of the channel. The modified configuration block needs to maintain the original structure and can only change the fields that are allowed to be changed.

[0039] Step 103: Obtain the configuration update proposal based on the current configuration block and the modified configuration block.

[0040] In the embodiments of the present application, the client compares the original configuration block and the modified configuration block to generate a configuration update proposal. It can be understood that the configuration update proposal only contains the modified part, not the entire configuration block. Further, the step of generating the configuration update proposal also includes the signature of the channel administrator. The configuration update proposal needs to be signed by the administrator identity of the relevant organization in the channel, and the number and identity of the signature are determined by the modification policy of the channel in the actual application.

[0041] Step 104: Package the configuration update proposal into a transaction and submit it to the orderer node.

[0042] Step 105: Sort and package the transaction into a configuration update block by the orderer node, and broadcast the configuration update block to all peer nodes for configuration update.

[0043] In the embodiments of the present application, the configuration update proposal is packaged into a transaction together with the signature and submitted to the orderer node. The orderer node then sorts and packages the transaction into a block and broadcasts it to all peer nodes.

[0044] In an optional implementation of the embodiment, the step of ordering and packaging the transaction into a configuration update block by the orderer node and broadcasting the configuration update block to all peer nodes for configuration update includes:

[0045] packaging the transaction into a configuration update block by the orderer node and broadcasting the configuration update block to all peer nodes;

[0046] When the peer node receives the configuration update block, the peer node verifies the legality of the content of the configuration update block;

[0047] If the verification is passed, the peer node stores the configuration update block into the ledger for configuration update.

[0048] Specifically, after the peer node receives the block containing the configuration update, it also needs to verify its legality. If the verification is passed, the peer node will store the new configuration block into the ledger and make it the latest configuration of the channel. Through the legality verification, the security and consistency of the configuration change are ensured, and unauthorized modification is prevented.

[0049] In detail, the configuration block legality verification in the present scheme includes the following stages:

[0050] (1) Signature verification: The configuration update proposal needs to be signed by the administrator of the related organization in the channel. The peer node will check whether the signature in the proposal meets the modification policy set by us.

[0051] (2) Configuration field verification: The peer node will check the modification content in the configuration update proposal to ensure its legality, including: field range limit, some configuration fields are read-only and cannot be modified; value legality, the modified field value must comply with the constraints of Fabric.

[0052] (3) Channel consistency verification: The configuration update cannot destroy the overall consistency of the channel, including: ensuring that the MSP (Membership Service Provider) configuration of all organizations in the channel is still valid; ensuring that the communication configuration between the orderer node and the peer node of the channel is not destroyed.

[0053] (4) Block verification: After the configuration update proposal is packaged into a block, all peer nodes will verify the configuration update transaction in the block, including: verifying whether the signature of the transaction meets the modification policy; verifying whether the content of the configuration update complies with the rules of the channel.

[0054] In the legality verification, the following participants and their functions are mainly included:

[0055] (1)orderer node:

[0056] The orderer node is responsible for receiving and ordering configuration update transactions, but does not verify the content of the configuration update. The orderer node is only responsible for packaging the configuration update transaction into a block and broadcasting it to all peer nodes.

[0057] (2) peer node:

[0058] The peer node is the main participant in the verification of the legality of the configuration update. Each peer node independently verifies the configuration update transaction in the block, including: checking whether the signature meets the modification policy; checking whether the configuration update content meets the rules; if the verification is passed, the peer node will store the new configuration in the ledger and update its local channel configuration.

[0059] (3) administrator of the channel:

[0060] The configuration update proposal needs to be signed by the administrator of the channel. The identity of the administrator is defined by the MSP in the channel configuration, which is usually a member of the organization with an administrator role.

[0061] Further, in an optional embodiment of the present application, the peer node includes a supervision node and a normal node; wherein the sum of the preset proportion of the total voting weight of all supervision nodes exceeds half of the total voting weight, and the remaining voting weight is evenly distributed to the normal nodes;

[0062] The step of verifying by the peer node whether the signature contained in the configuration update block meets the preset modification policy includes:

[0063] If the configuration update block contains a change to the voting weight of the supervision node, the peer node verifies whether the configuration update block contains the signatures of the administrators of all channel organizations on the chain;

[0064] If the configuration update block only contains a change to the voting weight of the normal node, the peer node verifies whether the configuration update block contains the signatures of at least 2 administrators of the channel organization.

[0065] Specifically, in the traditional fabric consortium chain, since the election vote in Raft is completely based on the number of nodes and has nothing to do with the importance of the nodes, when a node leaves or a majority of nodes are malicious, the system is difficult to run safely and effectively, therefore we propose a Raft election scheme based on node weight, and design and implement the function of dynamic change configuration on the chain. We divide the nodes on the chain into supervisor nodes and ordinary nodes, and the supervisor nodes hold the majority weight (more than 51%), while the other nodes are allocated the remaining weight on average, and at the same time, the weight can be adjusted on the chain after the node is offline or leaves, which well makes up for the shortcomings of the original consortium chain. The related content of the consensus process will be described in detail in the subsequent steps.

[0066] Further, in the embodiment of the present application, when the peer node receives the configuration update proposal, it checks whether the signature in the proposal meets the modification policy of the channel. In order to deal with different configuration modification situations, we set different modification policies:

[0067] (1) Adjusting the supervisor node

[0068] The supervisor node plays a crucial role in this scheme, so the configuration block proposal for changing the weight of the supervisor node needs to be signed by all the administrators of the channel organization on the chain, and can be passed and executed, ensuring the safety and legality when adjusting the supervisor node.

[0069] (2) Adjusting the ordinary node

[0070] The ordinary node is a follower node in the weight Raft consensus we designed, so the configuration block proposal for the ordinary node only needs to be signed by 2 administrators of the channel organization, and can be verified.

[0071] Step 106, based on the updated configuration, the node leader election is carried out to complete the blockchain consensus process.

[0072] In the traditional fabric consortium chain, multiple consensus mechanisms are supported, such as Raft, Kafka, etc., among which Raft, as a distributed consensus protocol, is applied by most fabric consortium chains. In the Raft cluster, there is a Leader node (leader node) responsible for processing client requests and replicating logs to other nodes (Follower nodes, also known as follower nodes).

[0073] In the Raft protocol, there is a Leader election mechanism. At the beginning, the Leader is elected by election, and the election process is as follows:

[0074] (1) Initial state: all nodes are Follower.

[0075] (2) Election timeout: If a Follower node does not receive a heartbeat signal from the Leader within a specified time, it becomes a Candidate.

[0076] (3) Initiate election: Candidate nodes send a vote request to other nodes in the cluster.

[0077] (4) Voting rules: Each node can only vote for one candidate, usually the first candidate that receives the request.

[0078] (5) Reach consensus: If a certain candidate node gets more than half of the votes (more than half of the nodes support), it becomes the new Leader.

[0079] (6) Leader runs: The Leader starts sending heartbeat signals to inform other nodes that it is the current Leader.

[0080] If no node gets a majority of votes during the election process, the election will start over until a Leader is elected.

[0081] In this process, since the election vote in Raft is completely based on the number of nodes, and has nothing to do with the importance of the nodes, when nodes leave or a majority of nodes are malicious, the system is difficult to run safely and effectively, therefore we propose a Raft election scheme based on node weight, and design and implement the function of dynamic configuration on the chain. We divide the nodes on the chain into supervisor nodes and ordinary nodes, the supervisor nodes hold the majority of the weight (more than 51%), while the other nodes are evenly distributed the remaining weight, at the same time, we realize the adjustment of weight on the chain after the node is offline or leaves, which well makes up for the shortcomings of the original consortium chain.

[0082] In an optional implementation of the embodiment, the types of the nodes in the node leader election process include: leader node, follower node and candidate node, and the node leader election is performed based on the updated configuration to complete the steps of the blockchain consensus process, including:

[0083] For each follower node, if it is determined that the follower node does not receive the heartbeat information of the leader node within the corresponding election timeout time, the follower node is converted into a candidate node and a leader election is performed;

[0084] If the voting weight received by the candidate node in the leader election exceeds the preset voting weight, it is determined that the candidate node election is successful, and the candidate node is converted into a new leader node; wherein the preset voting weight is 50%.

[0085] It should be noted that in the blockchain technology, especially in the consensus mechanism such as Raft, nodes are usually divided into three roles: leader, follower and candidate, wherein the leader node is responsible for receiving the request of the client and sending the synchronization request of the log to other nodes, and the leader node keeps connected with the follower node by sending heartbeat packets to ensure the normal operation of the network; the follower node is the state at initialization, which unidirectionally receives and persists the log synchronized by the leader node, and if the follower node does not receive any message from the leader node within a preset timeout time, it will become a candidate node and start to elect a new leader; the candidate node is a transitional role in the leader election process, and when the follower node does not receive any message from the leader node within a specified timeout time, it will become a candidate node and start to broadcast election messages to other nodes.

[0086] In the embodiment, for each follower node, when it does not receive the heartbeat information of the leader node within the corresponding election timeout time, it becomes a candidate node and starts to elect a new leader. The election timeout time of the follower node is negatively related to the voting weight of the node, that is, the higher the voting weight of the node, the shorter the election timeout time. In this way, because the node with high voting weight usually means more reliable and more responsible, which can better maintain the safety and stability of the blockchain network, it can ensure that the consensus process is more efficient and accurate.

[0087] In the embodiment, the candidate node sends a voting request message to all other nodes to request other nodes to vote for it. After receiving the information of the candidate node, other nodes will decide whether to vote for the candidate node according to certain rules, and the voting weight of each node is proportional to its voting weight. When the candidate node receives a voting weight that exceeds a preset voting value in the leader election, the preset voting value is preferably half of the total voting weight, it is determined that the candidate node is elected successfully, the candidate node is converted into a new leader node, and the candidate node starts to send heartbeat messages to other nodes to maintain its leader position. If the voting weight received by the candidate node does not exceed the preset voting value, the candidate node is reconverted into a follower node. In this way, by allocating different election rights to nodes according to the voting weight, the node with higher voting weight has greater rights and a greater probability of becoming a leader node, and the node with voting weight has less impact on the cluster, thereby encouraging nodes to actively participate in the consensus process and improving the enthusiasm of nodes participating in the consensus.

[0088] In an optional implementation of the embodiment, the step of performing node leader election based on the updated configuration to complete the blockchain consensus process further includes:

[0089] For each follower node, if the follower node receives the voting request information of the candidate node, the follower node determines whether the candidate node has the latest log according to the number and content of log entries of the follower node and the candidate node.

[0090] If it is determined that the candidate node has the latest log, the follower node increases the voting weight of the candidate node according to the voting weight corresponding to the follower node.

[0091] In this embodiment, for each follower node, if the follower node receives the voting information of the candidate node, the follower node can determine whether the candidate node has the latest log according to the number and content of log entries of the follower node and the candidate node.

[0092] Specifically, if the follower node determines that the log of the candidate node is the latest, the follower node casts a reputation value vote to the candidate node, if the follower node finds that the log of the candidate node is not the latest, the follower node refuses to vote for the candidate node, and continues to wait for a new candidate node to initiate an election, or the follower node itself becomes a candidate node and initiates an election, thereby ensuring that only a candidate node with the latest log can obtain a vote and thereby become a leader, which helps to maintain the consistency of the blockchain and ensures that all nodes have the same and latest blockchain state when reaching consensus.

[0093] Further, in an optional implementation of the embodiment, the step of performing node leader election based on the updated configuration to complete the blockchain consensus process further includes:

[0094] If the current cluster is a single-node cluster, the node in the single-node cluster is directly converted into a leader node.

[0095] In the embodiment of the present application, for the case of a single-node cluster, the scheme optimizes the election process and directly allows the node in the single-node cluster to become a Leader without going through a complex election process, thereby improving efficiency and security.

[0096] Next, the embodiment of the present application will exemplarily provide a detailed and specific operation scheme:

[0097] 1. Weight definition and configuration update:

[0098] First, in order to make the configuration block change effective, we need to define the weight first, mainly in two ways:

[0099] Method one: modify the configtx.pb.go file:

[0100] This method is suitable for scenarios where the Proto file does not need to be frequently modified. Directly modify the data structure in the Go code and add the definition of node weight. This method is relatively simple and suitable for developers who have a low frequency of configuration changes.

[0101] The steps include:

[0102] 1. Find the definition of the ConfigGroup structure:

[0103] In the configtx.pb.go file, find the section that defines the network configuration structure. Typically, this section will contain a data structure similar to ConfigGroup, responsible for storing various parameters related to network configuration.

[0104] 2. Add the NodeWeights field:

[0105] In the ConfigGroup structure, add a new field node_weights to store the weight of each node. This field can be a map, with the key as the node name (string) and the value as the weight of the corresponding node (NodeWeight).

[0106] The specific code is as follows:

[0107]

[0108] 3. Save the file and recompile the code:

[0109] After modification, save the file and recompile the Go code, so that the new NodeWeights field is correctly introduced and can be used by subsequent configuration updates and node weight management logic.

[0110] 4. Restart the service (optional):

[0111] After compilation, you need to restart the related services in the Fabric network to ensure that the new weight field takes effect.

[0112] In this way, you can directly define and manage the weight of nodes in the Go code, which is suitable for simple scenarios and avoids frequent modifications to Proto files and code generation processes.

[0113] Method Two: Modify the configtx.proto file

[0114] If you need to generate Go code through the Proto file or want to uniformly use the structure defined by the Proto file in multiple services, you can add the node weight field by modifying the configtx.proto file.

[0115] The steps specifically include:

[0116] 1). Modify the configtx.proto file:

[0117] In configtx.proto, add the NodeWeights field. The NodeWeights field should be a map type, with the key being the node name and the value being the weight of the node. The modified ConfigGroup structure can be as follows:

[0118]

[0119] 2). Regenerate Go code using the protoc tool:

[0120] After modifying the configtx.proto file, you need to regenerate the Go code using the protoc tool. Run the following command to generate the Go code:

[0121] protoc --go_out=. common / configtx.proto

[0122] This command will regenerate the corresponding Go file based on the modified Proto file. Make sure that the generated Go file contains the new NodeWeights field.

[0123] 3). Re-compile and restart the service (optional):

[0124] After generating the new Go code, re-compile the project and restart the Fabric network service to make the new configuration take effect.

[0125] In this way, the definition of node weights can be centrally managed in the configtx.proto file, which is suitable for scenarios that require frequent changes and shared configurations.

[0126] It should be understood that the "re-compile and restart the service" in the above method is a step in the traditional consensus process. Although the present application implements on-chain dynamic configuration without the need to close the blockchain, the traditional configuration method is still retained in this solution, so it is introduced here.

[0127] 2. Setting of initial weight value:

[0128] In Hyperledger Fabric, the weight value of a node is usually defined during network initialization and managed through a configuration file. The initial value of the weight can be set through the configtx.yaml configuration file.

[0129] The specific steps include:

[0130] 1). Modify the configtx.yaml file:

[0131] In the configtx.yaml file, set the initial weight for each node. You can add a NodeWeight field under the Profiles section, specifically under the EtcdRaft consensus settings, to specify the initial weight for each node.

[0132] Here's an example configuration that defines the initial weights for nodes in the SampleMultiNodeEtcdRaft configuration file:

[0133]

[0134]

[0135] In this configuration, the NodeWeight field defines the initial weight for each orderer node. The configuration of node weights directly affects the role that nodes play in the consensus process, especially when using the RAFT consensus. Nodes with higher weights are more likely to become leaders.

[0136] 2). Save and apply the configuration:

[0137] After making the modifications, save the configtx.yaml file. Then, use the configtxlator tool or other Fabric configuration update tools to apply the modified configuration blocks to the network to make the new node weight configuration take effect.

[0138] 3). Verify the configuration:

[0139] After updating the configuration, you can verify that the initial weights for nodes have been correctly applied by checking the network status or querying the configuration blocks in the network.

[0140] Through these two methods, you can flexibly define and manage the weights of nodes in Hyperledger Fabric and dynamically adjust the weight configuration according to your needs. These modifications will directly affect the node election process in the RAFT consensus algorithm, ensuring that in a distributed network, the consensus process and the priority of node roles are adjusted according to business needs and the importance of nodes. In this way, you can optimize the election weight of nodes according to the actual scenario, improving the stability and scalability of the network.

[0141] 3. Change the code logic to read node weights:

[0142] After updating the configuration file, the next step is to adjust the source code of Hyperledger Fabric to be able to read and apply the node weights defined in the configuration. This process involves modifications to multiple core source code files, particularly those related to consensus algorithms, node election, and voting.

[0143] To correctly use the new node weight field in the code, we need to make modifications to multiple source code files. These files mainly involve the logic of voting, election, and node state tracking in the RAFT consensus module. Here is a specific overview of modifying the code.

[0144] 1).orderer / consensus / etcdraft / tracker.go

[0145] This file is responsible for managing and tracking the status of nodes in the RAFT cluster and the voting results. In this file, we need to modify the node voting strategy to consider the weight of the node.

[0146] 2).vendor / go.etcd.io / etcd / raft / v3 / raft.go

[0147] This is the core implementation file of the RAFT protocol, responsible for communication and election between nodes. In this file, we need to modify the election logic to use node weights to determine which node is most likely to become the leader.

[0148] 3).vendor / go.etcd.io / etcd / raft / v3 / quorum / joint.go

[0149] This file handles the logic of joining and exiting nodes in the RAFT cluster, and the addition of weights may affect the dynamic changes of the cluster.

[0150] 4).vendor / go.etcd.io / etcd / raft / v3 / quorum / majority.go

[0151] This file implements the logic of majority nodes consensus in the cluster, and the introduction of weights may affect how to determine the majority of nodes.

[0152] 5).vendor / go.etcd.io / etcd / raft / v3 / tracker / tracker.go

[0153] This file is responsible for tracking the state of nodes, logs, and heartbeat information. Here, we need to modify the node election and tracking logic to prioritize the leader based on the weight of the node.

[0154] Specific steps to modify the code:

[0155] 1). Read the NodeWeights field

[0156] First, modify the field reading logic of the ConfigGroup struct to correctly read the NodeWeights field defined in the configuration file. Typically, this logic is located in the initialization code of the consensus module.

[0157] Example code modification:

[0158] / / Read node weights from configuration

[0159] nodeWeights := configGroup.GetNodeWeights()

[0160] Here, GetNodeWeights() is a custom method that extracts the weight data of each node from the configuration. The implementation of this method depends on the definition of the node weight field in configtx.pb.go or configtx.proto.

[0161] 2). Apply weight values

[0162] Next, we need to apply the read weight values to the consensus module. In the RAFT consensus protocol, node election is usually based on voting to determine the leader. Therefore, during the election process, node weight will affect the voting strategy, making nodes with higher weights more likely to be elected as leaders.

[0163] Modify election logic:

[0164] During each vote and election, combine the node's weight to calculate the final election result. Suppose we combine the node's weight value with the voting result to make more granular election decisions:

[0165]

[0166] Where nodeID is the identifier of the current node, and threshold is a predefined weight threshold. When the node's weight is greater than this threshold, it will be given priority consideration in the election and may be elected as the leader.

[0167] 3). Update node weight logic

[0168] In the election logic, weights have a real impact on the election of nodes. For example, if you modify the voting strategy in the raft.go or tracker.go file, you can use weights to determine which node can get more votes and become the leader. It is important to note that weights may affect the majority calculation in the cluster, heartbeat detection, and dynamic adjustment when nodes join or leave.

[0169] Modify the voting strategy:

[0170] Assuming there is an ongoing election process, we need to consider the weights of the nodes to determine which node can get more votes.

[0171]

[0172]

[0173] In this way, through weight adjustment, the voting behavior of nodes and the final election result will be significantly affected, ensuring that in a network with different node importance, the leader can be reasonably elected.

[0174] After completing the code modification, you need to recompile and deploy the updated code. This process ensures that all nodes can use the latest binary file and correctly load the new configuration.

[0175] Compilation command:

[0176] Execute the following command to compile the modified code: go build

[0177] This will recompile all modified source code and generate new binary files.

[0178] Deployment instructions:

[0179] 1. Ensure that all nodes use the updated binary file:

[0180] When deploying, ensure that each node in the Hyperledger Fabric network is started using the updated binary file, so that the new code logic and configuration can be applied.

[0181] 2. Update the configuration file and environment variables:

[0182] Make sure the NodeWeights field in the configtx.yaml configuration file of each node is correctly configured, and all environment variables are correctly set. For example, the FABRIC_CFG_PATH environment variable should point to the latest configuration file directory.

[0183] 3. Restart the node:

[0184] All nodes must be restarted after using the new binary in order to load the updated configuration and logic.

[0185] 4. Verify Deployment:

[0186] After all nodes have been deployed and restarted, you can verify the status of the nodes in the network and the election results by checking the logs or using Fabric-provided tools such as the peer channel command. This ensures that the weight configuration has taken effect.

[0187] With these modifications, the election and voting mechanisms in the Hyperledger Fabric network can be dynamically adjusted based on the node weights in the configuration. This not only improves the flexibility of the network but also ensures that critical nodes have more priority and influence in the consensus process.

[0188] 4. Configuration Update and Testing

[0189] After updating the configuration, first use the command-line tool to obtain the latest configuration block to ensure that we have the updated configuration block and that the new weight configuration has been correctly reflected in the configuration.

[0190] Command:

[0191] peer channel fetch config config_block.pb -o orderer.example.com:7050 -c mychannel --tls --cafile / path / to / orderer / tls / ca.crt

[0192] Parameter Explanation:

[0193] peer channel fetch config: This command is used to obtain the configuration block from the specified channel.

[0194] config_block.pb: Output file name, save the configuration block as a config_block.pb file (Protocol Buffer format).

[0195] -o orderer.example.com:7050: Specifies the address and port of the orderer node.

[0196] -c mychannel: Specifies the channel name to query (such as mychannel).

[0197] --tls: Enable TLS secure connection.

[0198] --cafile / path / to / orderer / tls / ca.crt: Specifies the path to the orderer node's TLS certificate, used to verify the security of the connection.

[0199] After executing this command, the latest configuration block from the specified channel will be fetched and saved in the local file config_block.pb.

[0200] Next, the configuration block needs to be decoded:

[0201] The configuration block (in PB format) needs to be decoded into a readable JSON format in order to inspect and modify the configuration information within it. For this purpose, the configtxlator tool can be used for decoding operations.

[0202] Command:

[0203] configtxlator proto_decode --input config_block.pb --type common.Block

[0204] Parameter explanations:

[0205] proto_decode: Decoding operation that converts a file in Protocol Buffer format to JSON format.

[0206] --input config_block.pb: Input configuration block file (config_block.pb obtained earlier via the peer channel fetch command).

[0207] --type common.Block: Specifies that the decoding target type is common.Block, which is the default type for Hyperledger Fabric configuration blocks.

[0208] After executing this command, the decoded configuration content will be output to the terminal, where you can view the NodeWeights field and other configuration information.

[0209] The decoded configuration file will be displayed in JSON format, where you can find the NodeWeights field and update the node weights as needed. You can use any text editor (such as vim, nano, VS Code, etc.) to open the decoded file and make modifications.

[0210] Steps:

[0211] Open the decoded config.json file (by default, the configtxlator tool names the decoded file config.json).

[0212] Find and modify the NodeWeights field. For example, let's say we need to adjust the weights for orderer1.example.com and orderer2.example.com.

[0213] Modification example:

[0214]

[0215] In this example, we set the weight of orderer1.example.com to 15 and orderer2.example.com to 25. Depending on the requirements, the weights can be set according to the business needs of different nodes.

[0216] Save the modified file. After modifying config.json, you can proceed to the next step.

[0217] After modifying the configuration, the next step is to encode it back to the Protocol Buffer format to submit the configuration update.

[0218] Command:

[0219] configtxlator proto_encode --input modified_config.json --type common.ConfigUpdate --output modified_config.pb

[0220] Parameter explanation:

[0221] proto_encode: Encoding operation, which converts the JSON format configuration file back to the Protocol Buffer format.

[0222] --input modified_config.json: The input modified configuration file (modified_config.json).

[0223] --type common.ConfigUpdate: Specifies the target type of encoding as common.ConfigUpdate, which is the standard type for configuration updates.

[0224] --output modified_config.pb: Specifies the output file as modified_config.pb, which is the encoded configuration file.

[0225] After executing this command, the modified_config.pb file will contain the modified configuration, which can be submitted to the channel.

[0226] To submit the updated configuration, we need to calculate the difference between the new and old configuration blocks. This can be done using the configtxlator tool, which generates an incremental update file (update.pb) that contains the differences between the two configuration blocks and can be used to submit the update.

[0227] Command:

[0228] configtxlator compute_update --channel_id mychannel --original config_block.pb --updated modified_config.pb --output update.pb

[0229] Parameter Explanation:

[0230] compute_update: Calculates the difference between the configuration blocks.

[0231] --channel_id mychannel: Specifies the name of the channel to update (e.g., mychannel).

[0232] --original config_block.pb: Input the original configuration block file.

[0233] --updated modified_config.pb: Input the modified configuration block file.

[0234] --output update.pb: Output the incremental update file (update.pb) that contains the differences between the new and old configuration blocks.

[0235] After executing this command, an update.pb file will be generated, containing the configuration differences that can be used to update the configuration of Hyperledger Fabric.

[0236] The final step is to commit the calculated configuration updates to the channel. Use the peer channel update command to submit the incremental update file (update.pb) to the network so that all nodes can apply the changes.

[0237] Command:

[0238] peer channel update-f update.pb-c mychannel-o orderer.example.com:7050--tls--cafile / path / to / orderer / tls / ca.crt

[0239] Parameter Explanation:

[0240] peer channel update: Command to submit configuration updates.

[0241] -f update.pb: Specifies the incremental update file (update.pb).

[0242] -c mychannel: Specifies the channel name (e.g., mychannel) to update.

[0243] -o orderer.example.com:7050: Specifies the address and port of the orderer node.

[0244] --tls: Enables TLS secure connection.

[0245] --cafile / path / to / orderer / tls / ca.crt: Specifies the TLS certificate path of the orderer node for verifying the security of the connection.

[0246] After executing this command, the configuration updates will be committed to the channel, and all nodes will start applying the new configuration, including the updated node weights.

[0247] Through the above steps, we have successfully updated the configuration block of Hyperledger Fabric, modified the node weights, and submitted the configuration updates. These changes will directly affect the election strategy of the RAFT consensus module and enable dynamic adjustment of the consensus process based on node weights. Ensure that all nodes are restarted using the updated configuration file and binary file to make the updates take effect.

[0248] In summary, the Raft consensus election process diagram of the dynamic configuration method of the blockchain consensus algorithm provided by the embodiments of the present application is as follows: Figure 2As shown, the Raft consensus election process of the present application is referred to as c-Raft, which includes:

[0249] (1) Enter the election phase (c-Raft leader election): The system enters the leader election phase of c-Raft, preparing to start a new round of Leader node election.

[0250] (2) Trigger election timeout (raft.tickElection trigger): If the current node does not receive the heartbeat signal of the Leader within the election timeout time, trigger the election timeout and enter the election process.

[0251] (3) Launch election (campaign ()): The node calls the campaign() method to start campaigning for the Leader.

[0252] (4) Determine whether it is a single-node cluster: If the current cluster has only one node, it becomes the Leader directly. Call the r.becomeLeader() method, the election is successful, and the process ends. If it is not a single-node cluster, go to the next step.

[0253] (5) Become a candidate (r.becomeCandidate): The node switches its state to Candidate and starts sending vote requests to other nodes.

[0254] (6) Follower node checks the log: Each Follower node receives a vote request and checks whether the candidate has the latest log:

[0255] If there is the latest log: Send a message agreeing to vote to the candidate.

[0256] If there is no latest log: Send a message refusing to vote to the candidate.

[0257] (7) Candidate counts votes (candidate counts votes): The candidate node receives votes from other nodes and counts the current votes.

[0258] (8) Determine whether the received weight value exceeds half:

[0259] If more than half: The candidate node calls the r.becomeLeader() method and successfully becomes the Leader, ending the election.

[0260] If not more than half: The candidate node calls the r.becomeFollower() method, the election fails, and returns to the Follower state.

[0261] (9) Term renewal (term = term + 1): During the election process, the term of the candidate is increased by 1 each time the election is initiated, and the r.send() method is called to publish the election information to other nodes.

[0262] (10) Election results:

[0263] Successful election as Leader: If the candidate obtains more than half of the weight value support, the election is successful, and the candidate becomes the Leader.

[0264] Election failure: If more than half of the weight value support is not obtained, the election fails, and the node returns to the Follower state, waiting for the next round of election.

[0265] In this scheme, the core idea of Raft is combined, and a weight mechanism is introduced to enhance the flexibility and fairness of the election. During the election process, the candidate node judges whether it has obtained more than half of the support according to the weight value of the node, rather than simply counting the number of nodes, to ensure that the election result is more reasonable. At the same time, the Follower node will check whether the candidate's log is the latest, and only the node with the latest log has the qualification to become the Leader, thereby guaranteeing the consistency of data. In addition, for the case of a single node cluster, the process is optimized to allow the node to become the Leader directly without going through a complex election process, improving efficiency and security.

[0266] To sum up, the embodiment of the application first acquires the current configuration block, then modifies the current configuration block according to the business requirements to obtain the modified configuration block, and then acquires the configuration update proposal based on the current configuration block and the modified configuration block, and packs the configuration update proposal into a transaction and submits it to the orderer node. Next, the orderer node sorts the transaction and packs it into a configuration update block, and broadcasts the configuration update block to all peer nodes for configuration update. Finally, node leadership election is performed based on the updated configuration to complete the blockchain consensus process. Through the implementation of the dynamic configuration method of the on-chain configuration, on-chain configuration changes based on configuration blocks are realized without stopping the entire system, effectively improving the convenience and practicality of weight configuration during the blockchain consensus process. This scheme can be applied to scenarios where different nodes are assigned corresponding consensus weights, ensuring that the blockchain network can still run stably when facing complex business scenarios, achieving efficient and fair consensus effect.

[0267] It should be understood that the size of the serial number of each step in the embodiment does not mean the order of execution of the steps, and the execution order of each step should be determined by its function and inherent logic, and should not constitute the only limitation on the implementation process of the embodiment of the application.

[0268] Please refer to Figure 3 , Figure 3 A dynamic configuration device of a blockchain consensus algorithm is provided for an embodiment of the present application. The device can be used to implement the dynamic configuration method of on-chain configuration involved in the embodiment of the present application. The dynamic configuration device of the blockchain consensus algorithm mainly includes:

[0269] A first acquisition module 301 is configured to acquire a current configuration block.

[0270] A modification module 302 is configured to modify the current configuration block according to a business requirement to obtain a modified configuration block.

[0271] A second acquisition module 303 is configured to acquire a configuration update proposal based on the current configuration block and the modified configuration block.

[0272] A transaction module 304 is configured to package the configuration update proposal into a transaction and submit the transaction to an orderer node.

[0273] A configuration module 305 is configured to sort and package the transaction into a configuration update block through the orderer node, and broadcast the configuration update block to all peer nodes for configuration update.

[0274] An election module 306 is configured to perform node leader election based on the updated configuration to complete a blockchain consensus process.

[0275] In some embodiments of the present embodiment, when the configuration module 305 performs the step of sorting and packaging the transaction into a configuration update block through the orderer node, and broadcasting the configuration update block to all peer nodes for configuration update, it is specifically configured to package the transaction into a configuration update block through the orderer node, and broadcast the configuration update block to all peer nodes.

[0276] When the peer node receives the configuration update block, the content of the configuration update block is verified for legality through the peer node.

[0277] If the verification is passed, the peer node is controlled to store the configuration update block into a ledger for configuration update.

[0278] Further, in some embodiments of the present embodiment, when the configuration module 305 performs the step of verifying the content of the configuration update block for legality through the peer node, it is specifically configured to verify whether the signature contained in the configuration update block satisfies a preset modification strategy through the peer node, and verify whether the modified content in the configuration update block satisfies a preset channel rule through the peer node.

[0279] Further, in some embodiments of the present embodiment, the peer nodes include supervisor nodes and ordinary nodes; wherein a preset proportion of the sum of the voting weights of all supervisor nodes exceeds half of the total voting weight, and the remaining voting weight is evenly distributed among the ordinary nodes;

[0280] The configuration module 305, in the process of executing the step of verifying, by the peer node, whether the signature contained in the configuration update block meets the preset modification policy, is specifically configured to: if the configuration update block contains a change to the voting weight of a supervisor node, verify, by the peer node, whether the configuration update block contains an administrator signature of all channel organizations on the chain;

[0281] If the configuration update block only contains a change to the voting weight of an ordinary node, verify, by the peer node, whether the configuration update block contains at least two administrator signatures of channel organizations.

[0282] In some embodiments of the present embodiment, the types of nodes in the node leader election process include leader nodes, follower nodes, and candidate nodes. The election module 306, in the process of executing the step of performing node leader election based on the updated configuration to complete the blockchain consensus process, is specifically configured to: for each follower node, if it is determined that the follower node does not receive heartbeat information from the leader node within the corresponding election timeout time, convert the follower node into a candidate node and perform leader election;

[0283] If the candidate node receives a voting weight that exceeds a preset voting weight in the leader election, it is determined that the candidate node is elected successfully, and the candidate node is converted into a new leader node; wherein the preset voting weight is 50%.

[0284] In some embodiments of the present embodiment, the election module 306, in the process of executing the step of performing node leader election based on the updated configuration to complete the blockchain consensus process, is further specifically configured to: for each follower node, if the follower node receives a voting request information of a candidate node, determine whether the candidate node has the latest log according to the number and content of log entries of the follower node and the candidate node;

[0285] If it is determined that the candidate node has the latest log, increase the voting weight of the candidate node according to the voting weight corresponding to the follower node.

[0286] In some embodiments of the present embodiment, the election module 306, in the process of executing the step of performing node leader election based on the updated configuration to complete the blockchain consensus process, is further specifically configured to: if the current cluster is a single-node cluster, the node in the single-node cluster is directly converted into a leader node.

[0287] In summary, the embodiment of the present application first acquires a current configuration block, then modifies the current configuration block according to service requirements to obtain a modified configuration block, acquires a configuration update proposal based on the current configuration block and the modified configuration block, and packs the configuration update proposal into a transaction and submits it to an orderer node. Next, the orderer node sorts the transaction and packs it into a configuration update block, and broadcasts the configuration update block to all peer nodes for configuration update. Finally, node leadership election is performed based on the updated configuration to complete the blockchain consensus process. Through the implementation of the dynamic configuration device of the blockchain consensus algorithm of the present application, on-chain configuration changes based on the configuration block are realized without stopping the entire system, which effectively improves the convenience and practicality of the configuration of voting weights in the blockchain consensus process.

[0288] Referring to Figure 4 , Figure 4 a module block diagram of an electronic device provided by the embodiment of the present application is provided.

[0289] As Figure 4 shown, the embodiment of the present application further provides an electronic device which can be used to implement the dynamic configuration method of on-chain configuration in the foregoing embodiments, and the electronic device comprises a memory 401 and at least one processor 402; wherein the memory 401 is used to store at least one program, and when the at least one program is executed by the at least one processor 402, the at least one processor 402 executes the dynamic configuration method of on-chain configuration provided by the embodiment of the present application.

[0290] Referring to Figure 5 , Figure 5 a module block diagram of a computer readable storage medium provided by the embodiment of the present application is provided.

[0291] As Figure 5 shown, the embodiment of the present application further provides a computer readable storage medium 500, and the computer readable storage medium 500 stores executable instructions 510, and the executable instructions 510 are executed to execute the dynamic configuration method of on-chain configuration provided by the embodiment of the present application.

[0292] The steps of the methods or algorithms described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. The software module can be placed in a random access memory (RAM), a memory, a read only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0293] In the embodiments described above, all or part of the embodiments can be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded on a computer and executed, all or part of the processes or functions described in the present application are produced. The computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions can be stored in a computer readable storage medium or transferred from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions can be transferred from one website, computer, server or data center to another website, computer, server or data center through wired (such as coaxial cable, optical fiber, digital subscriber line) or wireless (such as infrared, wireless, microwave, etc.) mode. The computer readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. integrated with one or more available media. The available media can be magnetic media (such as floppy disk, hard disk, magnetic tape), optical media (such as DVD), or semiconductor media (such as Solid State Disk) and the like.

[0294] It should be noted that each of the embodiments in the present application is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For product class embodiments, since they are similar to method class embodiments, the description is relatively simple, and the relevant parts can be referred to the part of the description of the method class embodiments.

[0295] It should also be noted that in the present application, the relationship terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between the entities or operations. Moreover, the terms "include", "contain" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or equipment including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or equipment. Without more limitations, the element defined by the statement "including a" does not exclude the presence of other identical elements in the process, method, article or equipment including the element.

[0296] The above description of disclosed embodiments allows a skilled person to implement or use the present content. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined can be applied to other embodiments without departing from the spirit or scope of the content. Thus, the content is not to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed.

Claims

1. A dynamic configuration method for a blockchain consensus algorithm, characterized in that, include: Get the current configuration block; The current configuration block is modified according to business requirements to obtain the modified configuration block; Obtain a configuration update proposal based on the current configuration block and the modified configuration block; The configuration update proposal is packaged into a transaction and submitted to the orderer node; The orderer node sorts the transactions and packages them into configuration update blocks, and broadcasts the configuration update blocks to all peer nodes for configuration updates. Node leader election is conducted based on the updated configuration to complete the blockchain consensus process.

2. The dynamic configuration method according to claim 1, characterized in that, The steps of sorting the transactions and packaging them into configuration update blocks through the orderer node, and broadcasting the configuration update blocks to all peer nodes for configuration updates, include: The orderer node packages the transaction into a configuration update block and broadcasts the configuration update block to all peer nodes. When the peer node receives the configuration update block, it verifies the legality of the content of the configuration update block. If the verification is successful, the peer node is controlled to store the configuration update block in the ledger for configuration update.

3. The dynamic configuration method according to claim 2, characterized in that, The step of validating the content of the configuration update block through the peer node includes: The peer node verifies whether the signature contained in the configuration update block meets the preset modification policy, and verifies whether the modification content in the configuration update block meets the preset channel rules.

4. The dynamic configuration method according to claim 3, characterized in that, The peer nodes include supervisory nodes and ordinary nodes; wherein, the sum of the voting weights of all supervisory nodes accounts for more than half of the total voting weight, and the remaining voting weights are distributed equally among the ordinary nodes; The step of verifying whether the signature contained in the configuration update block satisfies the preset modification policy through the peer node includes: If the configuration update block contains a change in the voting weight of the supervisory node, then the peer node verifies whether the configuration update block contains the administrator signatures of all channel organizations on the chain. If the configuration update block only contains changes to the voting weights of the ordinary nodes, then the peer node verifies whether the configuration update block contains the administrator signatures of at least two channel organizations.

5. The dynamic configuration method according to claim 4, characterized in that, The types of nodes in the node leader election process include: leader nodes, follower nodes, and candidate nodes. The step of conducting node leader election based on the updated configuration to complete the blockchain consensus process includes: For each follower node, if it is determined that the follower node has not received the heartbeat information from the leader node within the corresponding election timeout period, then the follower node is converted into the candidate node and a leader election is conducted. If the candidate node receives more votes than a preset voting weight in the leader election, the candidate node is determined to have been successfully elected and is converted into a new leader node; wherein the preset voting weight is 50%.

6. The dynamic configuration method according to claim 5, characterized in that, The step of electing a node leader based on the updated configuration to complete the blockchain consensus process also includes: For each follower node, if the follower node receives a voting request from the candidate node, it is determined whether the candidate node has the latest log based on the number and content of log entries of the follower node and the candidate node. If it is determined that the candidate node has the latest logs, then the candidate node is given an additional vote weight according to the voting weight of the follower node.

7. The dynamic configuration method according to claim 6, characterized in that, The step of electing a node leader based on the updated configuration to complete the blockchain consensus process also includes: If the current cluster is a single-node cluster, then the nodes in the single-node cluster are directly converted into leader nodes.

8. A dynamic configuration device for a blockchain consensus algorithm, characterized in that, include: The first acquisition module is used to acquire the current configuration block; The modification module is used to modify the current configuration block according to business requirements to obtain the modified configuration block; The second acquisition module is used to acquire a configuration update proposal based on the current configuration block and the modified configuration block; The transaction module is used to package the configuration update proposal into a transaction and submit it to the orderer node; The configuration module is used to sort the transactions and package them into configuration update blocks through the orderer node, and to broadcast the configuration update blocks to all peer nodes for configuration updates; The election module is used to elect a node leader based on the updated configuration in order to complete the blockchain consensus process.

9. An electronic device, characterized in that, Includes memory and processor, of which: The processor is used to execute computer programs stored in the memory; When the processor executes the computer program, it implements the steps in the dynamic configuration method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps in the dynamic configuration method according to any one of claims 1 to 7.

Images