Method and apparatus for governing consensus nodes

Abstract

The application relates to the technical field of communication, and provides a method and device for governing consensus nodes. The method comprises the following steps: sending information of a target transaction to be initiated to a target node; receiving a signature returned by the target node based on the information of the target transaction; initiating the target transaction to the target node in the case that the number of the signature is greater than or equal to a target value, so that the target node updates a consensus node list in the case that the consensus passes the target transaction; wherein the number of the target nodes is multiple; the target transaction is used for governing the consensus nodes; the governance of the consensus nodes refers to adding or deleting the consensus nodes; the target value is determined based on the number of the target nodes, the operation type of the governance of the consensus nodes and the number of the consensus nodes to be governed; each node in the consensus node list trusts each other; and the target transaction carries the information and the signature of the target transaction. The method and device for governing the consensus nodes provided in the application can more simply and conveniently realize the governance of the consensus nodes.

Description

Technical Field

[0001] This application relates to the field of communication technology, specifically to a method and apparatus for governing consensus nodes. Background Technology

[0002] A consortium blockchain is a blockchain jointly managed by several institutions, each operating one or more nodes. Data on the consortium blockchain can only be read, written, and used by these institutions through their respective nodes (hereinafter referred to as "nodes"), and transaction data is collectively recorded. The number of nodes in a consortium blockchain is limited, and the nodes build a peer-to-peer (P2P) network through mutual trust and reach consensus.

[0003] There are three main methods for governing nodes in consortium blockchains (primarily including adding and deleting consensus nodes): The first is centralized governance, such as Ripple, which manages node additions and deletions through a centralized service. Consensus nodes trust the centralized service's public key for signing, and digital signatures ensure the data security of the centralized service. The second is setting up an administrator account in the genesis block, which sends transactions to add or delete nodes. The third is through a governance module with a governance committee. Committee members initiate node governance transactions, and other committee members vote to determine whether the transaction is effective. Public blockchains such as Libra (later renamed Diem) and Cosmos use this method for node governance.

[0004] The first and second methods mentioned above are not suitable for consortium blockchains with a relatively high degree of decentralization; while the third method mentioned above, although it conforms to the characteristics of decentralization, requires a dedicated governance module to assist it, making its implementation relatively complex and labor-intensive.

[0005] In summary, the existing methods for governing consensus nodes are quite complex to implement. Summary of the Invention

[0006] This application provides a method and apparatus for governing consensus nodes, which solves the relatively complex technical problems of governing consensus nodes.

[0007] In a first aspect, embodiments of this application provide a method for governing consensus nodes, including:

[0008] Send information about the target transaction to be initiated to the target node;

[0009] Receive the signature returned by the target node based on the information of the target transaction;

[0010] If the number of signatures is greater than or equal to the target value, the target transaction is initiated to the target node so that the target node updates the consensus node list if the consensus passes the target transaction;

[0011] The target nodes are multiple; the target transaction is used to govern consensus nodes; governing consensus nodes refers to adding or deleting consensus nodes; the target value is determined based on the number of target nodes, the operation type of governing consensus nodes, and the number of consensus nodes to be governed; the nodes in the consensus node list trust each other; the target transaction carries the information of the target transaction and the signature; the information of the target transaction includes the information of the initiating account of the target transaction, the operation type, and the public key of the consensus node to be governed.

[0012] In one embodiment, before initiating the target transaction to the target node when the number of signatures is greater than or equal to the target value, the method further includes:

[0013] The target value is determined based on the number of target nodes, the operation type of the governance consensus nodes, and the number of consensus nodes to be governed.

[0014] In one embodiment, the formula for determining the target value based on the number of target nodes, the operation type of the governance consensus nodes, and the number of consensus nodes to be governed is as follows:

[0015] sigQuorum=min(n,max(1,n / 2-opType+opNodeNum))

[0016] Wherein, sigQuorum represents the target value; n represents the number of target nodes; opType represents the operation type for governing consensus nodes, opType=1 represents adding consensus nodes, opType=0 represents adding or deleting nodes; opNodeNum represents the number of consensus nodes to be governed.

[0017] In one embodiment, the information of the initiating account of the target transaction is generated based on the private key of the first node;

[0018] The first node is a node in the consensus node list that is different from the target node.

[0019] Secondly, embodiments of this application also provide a method for governing consensus nodes, including:

[0020] Receive information about the target transaction to be initiated from the first node;

[0021] Based on the private key of the target node and the information of the target transaction, a signature is generated and returned to the first node;

[0022] Receive the target transaction initiated by the first node;

[0023] A consensus is reached on the target transaction, and if the consensus passes the target transaction, the consensus node list is updated.

[0024] The target transaction is used to govern consensus nodes; governing consensus nodes refers to adding or deleting consensus nodes; the target transaction is initiated by the first node when the number of signatures received is greater than or equal to a target value; the target value is determined based on the number of target nodes, the operation type of the governance consensus nodes, and the number of consensus nodes to be governed; the nodes in the consensus node list trust each other; the target transaction carries the information of the target transaction and the signature; the information of the target transaction includes the information of the initiating account of the target transaction, the operation type, and the public key of the consensus node to be governed.

[0025] In one embodiment, reaching consensus on the target transaction and updating the consensus node list upon successful consensus on the target transaction includes:

[0026] Read the consensus node list;

[0027] Based on the consensus node list and the target transaction, verify whether the signer who generated the signature is legitimate and the validity of the signature;

[0028] If all signers who generated the signatures are legitimate and all the signatures are valid, and the number of signatures is greater than or equal to the target value, then the consensus on the target transaction is determined to be passed.

[0029] The operation of the governance consensus node corresponding to the target transaction is executed on the consensus node list.

[0030] Thirdly, embodiments of this application provide an apparatus for governing consensus nodes, comprising:

[0031] The information sending module is used to send information about the target transaction to be initiated to the target node;

[0032] A signature collection module is used to receive the signature returned by the target node based on the information of the target transaction;

[0033] The transaction sending module is used to initiate the target transaction to the target node when the number of signatures is greater than or equal to the target value, so that the target node updates the consensus node list when the consensus passes the target transaction;

[0034] The target nodes are multiple; the target transaction is used to govern consensus nodes; governing consensus nodes refers to adding or deleting consensus nodes; the target value is determined based on the number of target nodes, the operation type of governing consensus nodes, and the number of consensus nodes to be governed; the nodes in the consensus node list trust each other; the target transaction carries the information of the target transaction and the signature; the information of the target transaction includes the information of the initiating account of the target transaction, the operation type, and the public key of the consensus node to be governed.

[0035] Fourthly, embodiments of this application provide an apparatus for governing consensus nodes, comprising:

[0036] The information receiving module is used to receive information about the target transaction to be initiated sent by the first node;

[0037] The signature module is used to generate a signature based on the private key of the target node and the information of the target transaction, and return the signature to the first node;

[0038] A transaction receiving module is used to receive the target transaction initiated by the first node;

[0039] The transaction consensus module is used to reach a consensus on the target transaction and update the consensus node list when the consensus passes the target transaction.

[0040] The target transaction is used to govern consensus nodes; governing consensus nodes refers to adding or deleting consensus nodes; the target transaction is initiated by the first node when the number of signatures received is greater than or equal to a target value; the target value is determined based on the number of target nodes, the operation type of the governance consensus nodes, and the number of consensus nodes to be governed; the nodes in the consensus node list trust each other; the target transaction carries the information of the target transaction and the signature; the information of the target transaction includes the information of the initiating account of the target transaction, the operation type, and the public key of the consensus node to be governed.

[0041] Fifthly, embodiments of this application provide an electronic device, including a processor and a memory storing a computer program, wherein the processor executes the program to implement the governance consensus node method described in the first or second aspect.

[0042] In a sixth aspect, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method for governance consensus nodes described in the first aspect.

[0043] In a seventh aspect, embodiments of this application provide a non-transitory computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the method for governance consensus nodes described in the first or second aspect.

[0044] The method and apparatus for governing consensus nodes provided in this application send information about a target transaction to be initiated to a target node, receive signatures returned by the target node based on the target transaction information, and initiate a target transaction to the target node when the number of signatures is greater than or equal to a target value. This allows the target node to update its consensus node list upon successful consensus through the target transaction, thus simplifying and facilitating consensus node governance. By employing multi-party signature and verification technology, it achieves the effect of decentralized node addition and deletion with multi-party participation. The use of an account-balance model blockchain transaction activation process facilitates the storage and retrieval of the consensus node list on the blockchain. Dynamically calculating the signature threshold ensures a more reasonable signature threshold. Furthermore, existing consensus nodes do not need to be restarted; only newly added consensus nodes need to be started or deleted consensus nodes need to be shut down. No additional governance committee is required; it relies solely on the existing consortium blockchain's transaction and consensus mechanisms, making it simpler and more convenient. Changes to the consensus node list can be recorded on the blockchain in real time. Attached Figure Description

[0045] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0046] Figure 1 This is one of the flowcharts illustrating the governance consensus node method provided in the embodiments of this application;

[0047] Figure 2 This is a second flowchart illustrating the method for governing consensus nodes provided in the embodiments of this application;

[0048] Figure 3 This is a schematic diagram of the process of reaching consensus on a target transaction in the governance consensus node method provided in the embodiments of this application;

[0049] Figure 4 This is the third flowchart illustrating the governance consensus node method provided in this application embodiment;

[0050] Figure 5 This is a schematic diagram of the governance consensus node process provided in the embodiments of this application;

[0051] Figure 6 This is one of the structural schematic diagrams of the governance consensus node device provided in the embodiments of this application;

[0052] Figure 7 This is a second schematic diagram of the structure of the governance consensus node device provided in the embodiments of this application;

[0053] Figure 8 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0054] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0055] Before describing the various embodiments of this application, several concepts involved in the various embodiments of this application will be explained.

[0056] 1. Multi-signature transactions

[0057] A multi-signature transaction, also known as a multi-signature transaction, refers to a transaction that does not require the initiating account's private key to sign, but rather requires the private keys of multiple other accounts to become effective.

[0058] For example, when A transfers money to B, under normal circumstances, A can sign the transaction with his own private key. However, when using multi-party signatures, A essentially "entrusts" his ability to sign the transaction to several other accounts, such as accounts C, D, and E, and sets the rule that as long as two of the three accounts C, D, and E sign the transaction, the signature is valid.

[0059] It's important to note that multi-signature transactions require node program support. For example, among the five common transaction types in cryptocurrency transactions, MS (Multiple Signatures) and P2SH (Pay-to-Script-Hash) are multi-signature transactions, with the latter being a simplified version of the former. Furthermore, the Ripple chain supports setting up a multi-signature list for an account (a transaction of type SignerListSet). In addition to setting the multi-signature list and the threshold for its effectiveness, the transaction can also set the weight of each signer.

[0060] After an account sets up a multi-signature list, the account's own private key is usually disabled, so that only multi-signature can be used.

[0061] The advantages of using multi-signature transactions mainly include: escrow and security. Escrow means that even when the account's private key holder is offline, they can delegate the signing of transactions to other accounts, while still being able to send transactions under their own identity. Security refers to improved account security. In multi-signature transactions, an unauthorized user only needs the account's private key to access all assets; however, multiple accounts' private keys are required, increasing the security level.

[0062] 2. Node private key generation: account address and account public key

[0063] In a consortium blockchain, the identity of a consensus node is typically indicated by its public key. Each consensus node has a public-private key pair. The private key is used to sign the consensus messages it sends, while the public key is configured in the trust list of other consensus nodes that trust this node, and is used to verify the validity of the consensus message signature.

[0064] The identity of a consensus node and the identity of an account are two different concepts. Generally, the relationship between an account address and a private key is as follows: private key -> public key -> account address.

[0065] Some blockchains allow public keys to be used directly as account addresses, but generally, a node's private key is unrelated to the account on the blockchain. For example, in the Ripple chain, different public key prefixes and different public key generation algorithms are used to distinguish between node identity and account identity. In this case, the same private key will result in different account public keys and node public keys.

[0066] Figure 1 This is one of the flowcharts illustrating the governance consensus node method provided in this application embodiment. (Refer to...) Figure 1 This application provides a method for governing consensus nodes, which may include steps 101, 102 and 103.

[0067] Specifically, the implementing entity of the method for governing consensus nodes provided in this application embodiment can be a device for governing consensus nodes. This device for governing consensus nodes is a first node. Any node in the consensus node list can be used as the first node, and all nodes in the consensus node list other than the first node can be used as target nodes. All nodes in the consensus node list are consensus nodes.

[0068] Step 101: Send the information of the target transaction to be initiated to the target node.

[0069] The target nodes are multiple; the target transaction is used to govern consensus nodes; governing consensus nodes refers to adding or deleting consensus nodes; the information of the target transaction includes the information of the initiating account of the target transaction, the operation type, and the public key of the consensus node to be governed.

[0070] Specifically, the target transaction is used to add or remove consensus nodes, that is, to add at least one consensus node to the aforementioned consensus node list, or to remove at least one consensus node from the aforementioned consensus node list.

[0071] The target transaction is a multi-signature transaction. In a consortium blockchain, the consensus nodes trust each other's public keys, which is equivalent to setting up a governance committee: the public key and account address generated by the private keys of each consensus node are equivalent to the committee account, and the consensus nodes together form the governance committee.

[0072] It should be noted that a node trust list (public key array) is configured in the configuration file for both the first node and each target node. The node trust list refers to the list of other consensus nodes that mutually trust this consensus node. Within this list, each other consensus node can be represented by its public key.

[0073] For example, the configuration example of a node trust list is as follows:

[0074] [validator_list]

[0075] xxx (the public key of node 1)

[0076] xxx (the public key of node 2) ...

[0078] xxx (the public key of node n).

[0079] It is understandable that consensus nodes trust each other, and eventually the trust lists of all consensus nodes are consistent, which can be used as the consensus node list.

[0080] It should be noted that before step 101, the program of the nodes (including the target node and the first node) itself needs to add support for transactions that add or delete nodes through multi-party signatures:

[0081] (1) The interface for generating node public and private keys can return the corresponding account address.

[0082] (2) Add an interface for signing transactions using the node's private key, and the signature can be verified by the node's public key.

[0083] (3) Add a multi-signature transaction type. In the transaction implementation, it is necessary to verify the validity of the transaction and then modify the trust list (i.e., the consensus node list) in the global world state.

[0084] As shown in Table 1, the information for a target transaction may include the following:

[0085] Table 1 Information on the Target Transaction

[0086]

[0087] The value of Account must be an account address generated from the private key of a node (i.e., the first node) in the consensus node list.

[0088] Step 102: Receive the signature returned by the target node based on the information of the target transaction.

[0089] Specifically, the process of collecting transaction signatures can be implemented in various ways, including but not limited to the following: it can be collected offline (e.g., any instant messaging application) or online (e.g., through a blockchain operation and maintenance system).

[0090] For example, transaction signatures can be collected in the following ways:

[0091] a) Transactions can be sent to the target node through various network tools. The target node signs the transaction based on its own node private key and a preset signature algorithm, and then returns the signature to the first node through the network tool.

[0092] (b) Alternatively, a web system can be used to collect signatures for node additions and deletions as an event. The transaction initiator (i.e., the first node) publishes the signature collection event on the webpage. The target node receives this event notification, then logs into the web system using its own node private key, and receives user clicks on controls to "agree" or "disagree." If an "agree" click is received, the node signs the transaction locally using its own node private key and a preset signature algorithm, and sends the signature to the transaction initiator. If a "disagree" click is received, the node does not sign the transaction locally. It should be noted that the node's private key must only exist locally and cannot be transmitted over the network.

[0093] Step 103: If the number of signatures is greater than or equal to the target value, initiate a target transaction to the target node so that the target node updates the consensus node list when the consensus passes the target transaction.

[0094] The target value is determined based on the number of target nodes, the operation type of the governance consensus nodes, and the number of consensus nodes to be governed; the nodes in the consensus node list trust each other; the target transaction carries the target transaction information and signature; the target transaction information includes the information of the initiating account of the target transaction, the operation type, and the public key of the consensus node to be governed.

[0095] Specifically, after collecting signatures, the number of signatures collected can be counted.

[0096] The number of collected signatures is compared with the target value. If the number of collected signatures is greater than or equal to the target value, it means that enough signatures have been collected. If the number of collected signatures is less than the target value, it means that not enough signatures have been collected.

[0097] It should be noted that the target value is a threshold for the number of signatures. The target value is dynamically determined based on the number of target nodes, the operation type of the governance consensus nodes, and the number of consensus nodes to be governed.

[0098] The types of operations for governing consensus nodes include adding consensus nodes and deleting consensus nodes.

[0099] After collecting enough signatures, the first node can assemble the target transaction by adding the signature list to the target transaction information, thus forming the target transaction. The target transaction can be shown in Table 2.

[0100] Table 2 Target Transactions

[0101]

[0102] The SignatureList consists of individual signatures. As shown in Table 3, a single signature can contain two fields: the signature itself and the signer's node public key.

[0103] Table 3 Signatures

[0104] field name describe type Signature Signature value String PublicKey The signer's node public key String

[0105] After each target node receives the target transaction, it executes a consensus process for that transaction. Once each target node has successfully completed the process (i.e., confirmed the validity of the target transaction), the transaction consensus is passed, and the global world state is updated, specifically by updating the consensus node list. Newly added consensus nodes only need to start themselves and establish connections with all existing consensus nodes to be considered trusted nodes by the existing consensus nodes and participate in the node consensus process.

[0106] It should be noted that before step 103, the process also includes: recording the list of currently mutually trusted nodes (i.e., the consensus node list) in the genesis block to the global world state.

[0107] When generating the genesis block, the list of currently mutually trusted nodes (consensus nodes trust each other in pairs, and the final trust list is consistent) can be recorded in the global world state of the genesis block.

[0108] This application embodiment sends information about the target transaction to be initiated to the target node, receives the signature returned by the target node based on the target transaction information, and initiates the target transaction to the target node when the number of signatures is greater than or equal to a target value. This allows the target node to update its consensus node list upon successful consensus of the target transaction, thus simplifying and facilitating consensus node governance. By employing multi-party signature and verification technology, it achieves the effect of decentralized node addition and deletion with multi-party participation. The account-balance model blockchain transaction activation process facilitates the storage and retrieval of the consensus node list on the blockchain. Dynamically calculating the signature threshold ensures a more reasonable signature threshold. Furthermore, existing consensus nodes do not need to be restarted; only newly added consensus nodes need to be started or deleted consensus nodes need to be shut down. No additional governance committee is required; it relies solely on the existing consortium blockchain's transaction and consensus mechanisms, making it simpler and more convenient. Changes to the consensus node list can be recorded on the blockchain in real time.

[0109] Based on any of the above embodiments, if the number of signatures is greater than or equal to the target value, before initiating the target transaction to the target node, the method further includes: determining the target value based on the number of target nodes, the operation type of the governance consensus nodes, and the number of consensus nodes to be governed.

[0110] Specifically, before step 101 or step 103, the target value can be determined based on the number of target nodes, the operation type of the governance consensus nodes, and the number of consensus nodes to be governed.

[0111] Optionally, the formula for determining the target value based on the number of target nodes, the operation type of the governance consensus nodes, and the number of consensus nodes to be governed can satisfy the following characteristics:

[0112] 1. The target value is between [1, n]. Where n represents the number of target nodes.

[0113] 2. Adding consensus nodes has a greater impact on the total number of consensus nodes than deleting them. The number of signatures required to add consensus nodes is less than that required to delete them.

[0114] 3. The number of signatures required increases or decreases accordingly for each additional or removed consensus node.

[0115] For example, sigQuorum = (n - opType * opNodeNum) * a.

[0116] Where sigQuorum represents the target value; n represents the number of target nodes; opType represents the operation type for governing consensus nodes, opType=1 indicates adding consensus nodes, opType=0 indicates adding or deleting nodes; opNodeNum represents the number of consensus nodes to be governed; a is a preset constant, 0 <a≤1。

[0117] This application embodiment achieves a more reasonable signature threshold by dynamically calculating the threshold number of signatures, thereby improving the security of consensus node governance.

[0118] Based on the content of any of the above embodiments, and taking into account the number of target nodes, the operation type of the governance consensus nodes, and the number of consensus nodes to be governed, the formula for determining the target value is as follows:

[0119] sigQuorum=min(n,max(1,n / 2-opType+opNodeNum))

[0120] Wherein, sigQuorum represents the target value; n represents the number of target nodes; opType represents the operation type for governing consensus nodes, opType=1 represents adding consensus nodes, opType=0 represents adding or deleting nodes; opNodeNum represents the number of consensus nodes to be governed.

[0121] For example, one more consensus node is added to the existing four consensus nodes:

[0122] sigQuorum=min(4,max(1,4 / 2-1+1))=2

[0123] Where: n = 4, opType = 1, opNodeNum = 1.

[0124] For example, the number of consensus nodes is reduced by 1 from 5:

[0125] sigQuorum=min(5,max(1,7 / 2-(-1)+1))=4

[0126] Where: n = 5, opType = -1, opNodeNum = 1.

[0127] Alternatively, min(n, max(1, n / 2 - opType + opNodeNum)) can be rounded to obtain sigQuorum. Rounding can be done by rounding to the nearest integer, rounding up, or rounding down.

[0128] This application embodiment achieves a more reasonable signature threshold by dynamically calculating the threshold number of signatures, thereby improving the security of consensus node governance.

[0129] Based on any of the above embodiments, the information of the initiating account of the target transaction is generated based on the private key of the first node; wherein, the first node is a node in the consensus node list that is different from the target node.

[0130] Specifically, the first node can generate an account using its own node private key, which serves as the initiating account for adding or deleting consensus nodes (i.e., the target transaction). The information of the initiating account for the target transaction can be the specific values ​​of the Account field in Tables 2 and 3.

[0131] The account for a multi-signature transaction (i.e., the account that initiates the target transaction) does not need to be activated on the blockchain; it only needs to correspond to the public key of a consensus node (i.e., the first node).

[0132] By using the private key of the first node to generate the account's public key and account address, and with the target node acting as the transaction signer, the consensus committee composed of consensus nodes can be formed to add or delete nodes.

[0133] The embodiments of this application generate the initiating account of the target transaction based on the private key of the first node, which can realize the initiation of multi-party signed transactions, thereby making consensus node governance simpler and more convenient.

[0134] Figure 2 This is the second flowchart illustrating the governance consensus node method provided in this application's embodiments. (Refer to...) Figure 2 This application provides a method for governing consensus nodes, which may include steps 201, 202, 203 and 204.

[0135] Specifically, the implementing entity of the method for governing consensus nodes provided in this application embodiment can be a device for governing consensus nodes. This device for governing consensus nodes can be any target node. Any node in the consensus node list can be used as the first node, and all nodes in the consensus node list other than the first node can be used as target nodes. All nodes in the consensus node list are consensus nodes.

[0136] Step 201: Receive the target transaction information to be initiated sent by the first node.

[0137] Among them, the target transaction is used to govern consensus nodes; governing consensus nodes refers to adding or deleting consensus nodes; the target transaction is initiated by the first node when the number of signatures received is greater than or equal to the target value; the information of the target transaction includes the information of the account that initiated the target transaction, the operation type, and the public key of the consensus node to be governed.

[0138] Specifically, the first node can obtain information about the target transaction and then send that information to each target node. The target nodes can then receive that information.

[0139] Step 202: Based on the target node's private key and the target transaction information, generate a signature and return the signature to the first node.

[0140] Specifically, the target node signs the target transaction based on the signature algorithm and its own private key, and can return the signature and its own node public key to the first node.

[0141] Step 203: Receive the target transaction initiated by the first node.

[0142] The target transaction is initiated by the first node when the number of signatures received is greater than or equal to the target value; the target value is determined based on the number of target nodes, the operation type of the governance consensus nodes, and the number of consensus nodes to be governed; the target transaction carries the target transaction information and signature.

[0143] Specifically, after collecting signatures, the first node can count the number of signatures collected; if the number of signatures collected is greater than or equal to the target value, it sends the target transaction to each target node. The target nodes can receive the target transaction.

[0144] Step 204: Reach consensus on the target transaction. If the consensus passes the target transaction, update the consensus node list.

[0145] In this consensus node list, the nodes trust each other.

[0146] Specifically, after each target node receives the target transaction, it executes a consensus process for that transaction. Once each target node has successfully completed the process (i.e., confirmed the validity of the target transaction), the transaction consensus is passed, and the global world state is updated, specifically by updating the consensus node list. Newly added consensus nodes only need to start themselves and establish connections with all existing consensus nodes to be considered trusted nodes by the existing consensus nodes and participate in the node consensus process.

[0147] This application embodiment sends information about the target transaction to be initiated to the target node, receives the signature returned by the target node based on the target transaction information, and initiates the target transaction to the target node when the number of signatures is greater than or equal to a target value. This allows the target node to update its consensus node list upon successful consensus of the target transaction, thus simplifying and facilitating consensus node governance. By employing multi-party signature and verification technology, it achieves the effect of decentralized node addition and deletion with multi-party participation. The account-balance model blockchain transaction activation process facilitates the storage and retrieval of the consensus node list on the blockchain. Dynamically calculating the signature threshold ensures a more reasonable signature threshold. Furthermore, existing consensus nodes do not need to be restarted; only newly added consensus nodes need to be started or deleted consensus nodes need to be shut down. No additional governance committee is required; it relies solely on the existing consortium blockchain's transaction and consensus mechanisms, making it simpler and more convenient. Changes to the consensus node list can be recorded on the blockchain in real time.

[0148] Based on the content of any of the above embodiments, consensus is reached on the target transaction, and if the consensus passes the target transaction, the consensus node list is updated, including: reading the consensus node list.

[0149] Specifically, the target node reads the consensus node list from the global world state.

[0150] Based on the consensus node list and the target transaction, verify whether the signer who generated the signature is legitimate and the validity of the signature.

[0151] Specifically, it can be verified whether each signature is generated by a different consensus node, and whether the number of signatures is greater than or equal to the target value.

[0152] The target node can verify the legitimacy of the signer by checking whether the public key of the signer for each signature carried in the target transaction exists in the consensus node list.

[0153] If the signature exists in the consensus node list, the signer who generated the signature is legitimate; if the signature does not exist in the consensus node list, the signer who generated the signature is illegitimate.

[0154] The target node can generate a signature verification object based on the private key corresponding to the signer's public key and the aforementioned signature algorithm. The validity of the signature is verified by comparing whether the signature matches the signature verification object. If the signature matches the signature verification object, the signature is valid; if the signature does not match the signature verification object, the signature is invalid.

[0155] The target transaction consensus is considered passed if all signers who generated the signatures are legitimate, all signatures are valid, and the number of signatures is greater than or equal to the target value.

[0156] Specifically, the number of signatures is counted assuming that all signers who generated the signatures are legitimate and all signatures are valid.

[0157] If the number of signatures is greater than or equal to the target value, the target transaction consensus is passed; if the number of signatures is less than the target value, the target transaction consensus is not passed.

[0158] It should be noted that if any signer who generates the signature is illegitimate or any signature is invalid, the consensus for the target transaction will not pass.

[0159] Perform the operations on the governance consensus node corresponding to the target transaction on the consensus node list.

[0160] Specifically, the governance consensus node corresponding to the target transaction refers to the consensus node that needs to be added or deleted through the target transaction.

[0161] For example, such as Figure 3 As shown, each target node can execute the consensus process for the target transaction according to the following steps:

[0162] Step 301: Read the consensus node list from the global world state.

[0163] Step 302: Verify whether the signing public keys all belong to the consensus node list.

[0164] If yes, proceed to step 303; otherwise, proceed to step 306.

[0165] Step 303: Verify that all signatures are valid.

[0166] If yes, proceed to step 304; otherwise, proceed to step 306.

[0167] Step 304: Verify whether the number of signatures has reached the target value.

[0168] If yes, proceed to step 305; otherwise, proceed to step 306.

[0169] Step 305: Verification passed, update the consensus node list.

[0170] Step 306: Verification failed, transaction invalid.

[0171] The embodiments of this application determine the validity of the target transaction by verifying whether each signature is generated by different consensus nodes and whether the number of signatures is greater than or equal to the target value, thereby improving the security of consensus node governance.

[0172] To facilitate understanding of the above embodiments of this application, the process of consensus node governance will be described below by describing the interaction process between the first node and the target node.

[0173] like Figure 4 As shown, a consensus node governance process may include the following steps:

[0174] Step 401: A consensus node constructs a node to add or delete transactions.

[0175] An account can be generated from the private key corresponding to the public key of any node in the consensus list, serving as the initiating account for the target transaction. This arbitrary node is designated as the first node. Transactions involving the addition or deletion of nodes on this node, i.e., the target transaction, are transactions involving the addition or deletion of consensus nodes on the blockchain.

[0176] Step 402: Send the target transaction information to each target node for signing.

[0177] The initiating account constructs the target transaction (no signature required) and sends it to each target node for signature via a network tool.

[0178] Step 403: Each target node signs the target transaction using its private key.

[0179] Each target node signs the target transaction using its own node private key and sends the signature and signing public key (i.e., the target node's own node public key) to the initiating account.

[0180] Step 404: The transaction initiator collects the signatures and signature public keys of each target node.

[0181] The transaction initiator (i.e., the first node) collects the signatures of all participants.

[0182] Step 405: Once the number of signatures is sufficient, send the transaction with multiple signatures.

[0183] Once the signature ratio reaches the dynamically calculated threshold (i.e., the target value), the transaction can be sent to the blockchain for consensus.

[0184] Step 406: On-chain voting and consensus are achieved for multi-party signed transactions.

[0185] After receiving the transaction, the target node verifies the validity of the signature and whether the signature ratio reaches the dynamically calculated threshold. If the conditions are met, it votes in favor of the transaction and modifies the consensus list in the global world state.

[0186] Step 407: The transaction is effective, and the consensus node has been successfully added or deleted.

[0187] If a majority of the target nodes vote in favor of the transaction, the transaction consensus is passed, the list of consensus nodes in the global world is updated, and the process of adding or deleting nodes takes effect.

[0188] Wherein: step 401 is the transaction construction process, steps 402-404 are the transaction signature collection process, step 405 is the transaction sending process, and steps 406-407 are the transaction consensus activation process.

[0189] For example, the process of adding one consensus node from four target nodes can be as follows: Figure 5 As shown.

[0190] The apparatus for a governance consensus node provided in the embodiments of this application will be described below. The apparatus for a governance consensus node described below can be referred to in correspondence with the method for a governance consensus node described above.

[0191] Figure 6 This is one of the structural schematic diagrams of the governance consensus node device provided in the embodiments of this application. Based on the content of any of the above embodiments, such as Figure 6 As shown, the device includes an information sending module 601, a signature collection module 602, and a transaction sending module 603, wherein:

[0192] The information sending module 601 is used to send information about the target transaction to be initiated to the target node;

[0193] The signature collection module 602 is used to receive the signature returned by the target node based on the information of the target transaction;

[0194] The transaction sending module 603 is used to initiate a target transaction to the target node when the number of signatures is greater than or equal to the target value, so that the target node updates the consensus node list when the consensus passes the target transaction;

[0195] The target nodes are multiple; the target transaction is used to govern consensus nodes; governing consensus nodes refers to adding or deleting consensus nodes; the target value is determined based on the number of target nodes, the operation type of the governance consensus nodes, and the number of consensus nodes to be governed; the nodes in the consensus node list trust each other; the target transaction carries the target transaction information and signature; the target transaction information includes the information of the initiating account of the target transaction, the operation type, and the public key of the consensus node to be governed.

[0196] Specifically, the information sending module 601, the signature collection module 602, and the transaction sending module 603 can be electrically connected in sequence.

[0197] The information sending module 601 can obtain the information of the target transaction and then send the information of the target transaction to each target node.

[0198] After receiving the information of the target transaction, the target node signs the transaction and returns the signature to the first node.

[0199] The signature collection module 602 receives the signature returned by the target node.

[0200] The transaction sending module 603 can count the number of collected signatures; if the number of collected signatures is greater than or equal to the target value, it can assemble the obtained signatures (which may also include the node public key of the signer) and the information of the target transaction into a target transaction and send the target transaction to each target node.

[0201] After each target node receives the target transaction, it executes a consensus process for that transaction. Once each target node has successfully completed the process (i.e., confirmed the validity of the target transaction), the transaction consensus is passed, and the global world state is updated, specifically by updating the consensus node list.

[0202] Optionally, the apparatus for the governance consensus node may further include:

[0203] The threshold determination module is used to determine the target value based on the number of target nodes, the operation type of governance consensus nodes, and the number of consensus nodes to be governed.

[0204] Optionally, the threshold determination module determines the target value based on the number of target nodes, the operation type of the governance consensus nodes, and the number of consensus nodes to be governed, using the following formula:

[0205] sigQuorum=min(n,max(1,n / 2-opType+opNodeNum))

[0206] Wherein, sigQuorum represents the target value; n represents the number of target nodes; opType represents the operation type for governing consensus nodes, opType=1 represents adding consensus nodes, opType=0 represents adding or deleting nodes; opNodeNum represents the number of consensus nodes to be governed.

[0207] Optionally, the information of the initiating account of the target transaction is generated based on the private key of the first node;

[0208] The first node is a node in the consensus node list that is different from the target node.

[0209] The apparatus for a governance consensus node provided in this application is used to execute the governance consensus node method of the above embodiments of this application. Its implementation method is consistent with the implementation method of the governance consensus node method provided in the above embodiments of this application, and can achieve the same beneficial effects, which will not be repeated here.

[0210] The apparatus for governing consensus nodes is used in the methods for governing consensus nodes in the foregoing embodiments. Therefore, the descriptions and definitions in the methods for governing consensus nodes in the foregoing embodiments can be used to understand the execution modules in the embodiments of this application.

[0211] This application embodiment sends information about the target transaction to be initiated to the target node, receives the signature returned by the target node based on the target transaction information, and initiates the target transaction to the target node when the number of signatures is greater than or equal to a target value. This allows the target node to update its consensus node list upon successful consensus of the target transaction, thus simplifying and facilitating consensus node governance. By employing multi-party signature and verification technology, it achieves the effect of decentralized node addition and deletion with multi-party participation. The account-balance model blockchain transaction activation process facilitates the storage and retrieval of the consensus node list on the blockchain. Dynamically calculating the signature threshold ensures a more reasonable signature threshold. Furthermore, existing consensus nodes do not need to be restarted; only newly added consensus nodes need to be started or deleted consensus nodes need to be shut down. No additional governance committee is required; it relies solely on the existing consortium blockchain's transaction and consensus mechanisms, making it simpler and more convenient. Changes to the consensus node list can be recorded on the blockchain in real time.

[0212] Figure 7 This is a second structural schematic diagram of the governance consensus node device provided in the embodiments of this application. Based on the content of any of the above embodiments, as... Figure 7 As shown, the device includes an information receiving module 701, a signature module 702, a transaction receiving module 703, and a transaction consensus module 704, wherein:

[0213] The information receiving module 701 is used to receive information about the target transaction to be initiated sent by the first node;

[0214] The signature module 702 is used to generate a signature based on the private key of the target node and the information of the target transaction and return the signature to the first node;

[0215] Transaction receiving module 703 is used to receive target transactions initiated by the first node;

[0216] The transaction consensus module 704 is used to reach consensus on the target transaction and update the consensus node list when the consensus passes the target transaction.

[0217] Among them, the target transaction is used to govern consensus nodes; governing consensus nodes refers to adding or deleting consensus nodes; the target transaction is initiated by the first node when the number of signatures received is greater than or equal to the target value; the target value is determined based on the number of target nodes, the operation type of the governance consensus nodes, and the number of consensus nodes to be governed; the nodes in the consensus node list trust each other; the target transaction carries the target transaction information and signature; the target transaction information includes the information of the initiating account of the target transaction, the operation type, and the public key of the consensus node to be governed.

[0218] Specifically, the information receiving module 701, the signature module 702, the transaction receiving module 703, and the transaction consensus module 704 can be electrically connected in sequence.

[0219] The first node can obtain the target transaction information and then send the target transaction information to each target node. The information receiving module 701 can receive the target transaction information.

[0220] The signature module 702 signs the target transaction based on the signature algorithm and its own private key, and can return the signature and its own node public key to the first node.

[0221] After collecting signatures, the first node can count the number of signatures collected; if the number of signatures collected is greater than or equal to the target value, the target transaction is sent to each target node. The transaction receiving module 703 can receive the target transaction.

[0222] After receiving the target transaction, the transaction consensus module 704 executes the consensus process for that target transaction. Once each target node has successfully executed the process (i.e. confirmed the validity of the target transaction), the transaction consensus is passed, and the global world state is updated, specifically by updating the consensus node list.

[0223] Optionally, the transaction consensus module 704 can be specifically used to read the consensus node list; based on the consensus node list and the target transaction, verify whether the signer who generated the signature is legitimate and the validity of the signature; if all signers who generated the signature are legitimate and all signatures are valid, and the number of signatures is greater than or equal to the target value, determine that the consensus of the target transaction has passed; and execute the operation of the governance consensus node corresponding to the target transaction on the consensus node list.

[0224] The apparatus for a governance consensus node provided in this application is used to execute the governance consensus node method of the above embodiments of this application. Its implementation method is consistent with the implementation method of the governance consensus node method provided in the above embodiments of this application, and can achieve the same beneficial effects, which will not be repeated here.

[0225] The apparatus for governing consensus nodes is used in the methods for governing consensus nodes in the foregoing embodiments. Therefore, the descriptions and definitions in the methods for governing consensus nodes in the foregoing embodiments can be used to understand the execution modules in the embodiments of this application.

[0226] This application embodiment sends information about the target transaction to be initiated to the target node, receives the signature returned by the target node based on the target transaction information, and initiates the target transaction to the target node when the number of signatures is greater than or equal to a target value. This allows the target node to update its consensus node list upon successful consensus of the target transaction, thus simplifying and facilitating consensus node governance. By employing multi-party signature and verification technology, it achieves the effect of decentralized node addition and deletion with multi-party participation. The account-balance model blockchain transaction activation process facilitates the storage and retrieval of the consensus node list on the blockchain. Dynamically calculating the signature threshold ensures a more reasonable signature threshold. Furthermore, existing consensus nodes do not need to be restarted; only newly added consensus nodes need to be started or deleted consensus nodes need to be shut down. No additional governance committee is required; it relies solely on the existing consortium blockchain's transaction and consensus mechanisms, making it simpler and more convenient. Changes to the consensus node list can be recorded on the blockchain in real time.

[0227] Figure 8 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application, such as... Figure 8As shown, the electronic device may include: a processor 810, a communication interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communication interface 820, and the memory 830 communicate with each other through the communication bus 840. The processor 810 can call a computer program in the memory 830 to execute steps of a method for governing consensus nodes, such as: sending information about a target transaction to be initiated to a target node; receiving a signature returned by the target node based on the target transaction information; initiating a target transaction to the target node if the number of signatures is greater than or equal to a target value, so that the target node updates the consensus node list if the consensus passes the target transaction; wherein there are multiple target nodes; the target transaction is used to govern consensus nodes; governing consensus nodes refers to adding or deleting consensus nodes; the target value is determined based on the number of target nodes, the operation type of governing consensus nodes, and the number of consensus nodes to be governed; the nodes in the consensus node list trust each other; the target transaction carries information and a signature of the target transaction; the information of the target transaction includes information about the initiating account of the target transaction, the operation type, and the number of nodes to be governed. The consensus node's public key; or, including: receiving information about the target transaction to be initiated from the first node; generating a signature based on the target node's private key and the target transaction information and returning the signature to the first node; receiving the target transaction initiated by the first node; reaching consensus on the target transaction, and updating the consensus node list if the consensus passes the target transaction; wherein, the target transaction is used to govern consensus nodes; governing consensus nodes refers to adding or deleting consensus nodes; the target transaction is initiated by the first node when the number of received signatures is greater than or equal to a target value; the target value is determined based on the number of target nodes, the operation type of the governance consensus nodes, and the number of consensus nodes to be governed; the nodes in the consensus node list trust each other; the target transaction carries the target transaction information and signature; the target transaction information includes the information of the initiating account of the target transaction, the operation type, and the public key of the consensus node to be governed.

[0228] Furthermore, the logical instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0229] The processor 810 in the electronic device provided in this application embodiment can call the logical instructions in the memory 830. Its implementation method is consistent with the implementation method of the governance consensus node provided in this application, and can achieve the same beneficial effects. It will not be described again here.

[0230] On the other hand, this application also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can perform the steps of the governance consensus node method provided in the above embodiments, such as: sending information about a target transaction to be initiated to a target node; receiving a signature returned by the target node based on the target transaction information; initiating a target transaction to the target node when the number of signatures is greater than or equal to a target value, so that the target node updates the consensus node list when the consensus passes the target transaction; wherein, the number of target nodes is multiple; the target transaction is used to govern consensus nodes; governing consensus nodes refers to adding or deleting consensus nodes; the target value is determined based on the number of target nodes, the operation type of governing consensus nodes, and the number of consensus nodes to be governed; the nodes in the consensus node list trust each other; the target transaction carries information about the target transaction. The target transaction information includes the information of the initiating account, the operation type, and the public key of the consensus node to be governed; or, it includes: receiving the target transaction information sent by the first node; generating a signature based on the target node's private key and the target transaction information and returning the signature to the first node; receiving the target transaction initiated by the first node; reaching consensus on the target transaction, and updating the consensus node list if the consensus passes the target transaction; wherein, the target transaction is used to govern consensus nodes; governing consensus nodes refers to adding or deleting consensus nodes; the target transaction is initiated by the first node when the number of received signatures is greater than or equal to a target value; the target value is determined based on the number of target nodes, the operation type of the governing consensus nodes, and the number of consensus nodes to be governed; the nodes in the consensus node list trust each other; the target transaction carries the target transaction information and signature; the target transaction information includes the information of the initiating account, the operation type, and the public key of the consensus node to be governed.

[0231] When the computer program product provided in this application is executed, the method for implementing the above-mentioned governance consensus node is implemented in the same way as the implementation method described in the aforementioned method embodiments, and can achieve the same beneficial effects, so it will not be repeated here.

[0232] On the other hand, embodiments of this application also provide a processor-readable storage medium storing a computer program for causing a processor to execute the steps of the methods provided in the above embodiments, such as: sending information about a target transaction to be initiated to a target node; receiving a signature returned by the target node based on the information about the target transaction; initiating a target transaction to the target node when the number of signatures is greater than or equal to a target value, so that the target node updates the consensus node list when the consensus passes the target transaction; wherein, the number of target nodes is multiple; the target transaction is used to govern consensus nodes; governing consensus nodes refers to adding or deleting consensus nodes; the target value is determined based on the number of target nodes, the operation type of governing consensus nodes, and the number of consensus nodes to be governed; the nodes in the consensus node list trust each other; the target transaction carries information about the target transaction and a signature; the information about the target transaction includes the target transaction... The information includes the initiating account, operation type, and public key of the consensus node to be governed; or, it includes: receiving information about the target transaction to be initiated from the first node; generating a signature based on the private key of the target node and the information of the target transaction and returning the signature to the first node; receiving the target transaction initiated by the first node; reaching consensus on the target transaction, and updating the consensus node list if the consensus passes the target transaction; wherein, the target transaction is used to govern consensus nodes; governing consensus nodes refers to adding or deleting consensus nodes; the target transaction is initiated by the first node when the number of received signatures is greater than or equal to a target value; the target value is determined based on the number of target nodes, the operation type of the governing consensus node, and the number of consensus nodes to be governed; the nodes in the consensus node list trust each other; the target transaction carries the information and signature of the target transaction; the information of the target transaction includes the information of the initiating account of the target transaction, the operation type, and the public key of the consensus node to be governed.

[0233] When the computer program stored on the non-transitory computer-readable storage medium provided in this application is executed, the method for implementing the above-mentioned governance consensus node has the same specific implementation method as the implementation method described in the aforementioned method embodiments, and can achieve the same beneficial effects, so it will not be repeated here.

[0234] The processor-readable storage medium can be any available medium or data storage device that the processor can access, including but not limited to magnetic memory (e.g., floppy disk, hard disk, magnetic tape, magneto-optical disk (MO)), optical memory (e.g., CD, DVD, BD, HVD), and semiconductor memory (e.g., ROM, EPROM, EEPROM, non-volatile memory (NAND FLASH), solid-state drive (SSD)).

[0235] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0236] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0237] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for governing consensus nodes, characterized in that, include: Send information about the target transaction to be initiated to the target node; Receive the signature returned by the target node based on the information of the target transaction; If the number of signatures is greater than or equal to the target value, the target transaction is initiated to the target node so that the target node updates the consensus node list if the consensus passes the target transaction; The target nodes are multiple; the target transaction is used to govern consensus nodes; governing consensus nodes refers to adding or deleting consensus nodes; the target value is determined based on the number of target nodes, the operation type of governing consensus nodes, and the number of consensus nodes to be governed; the nodes in the consensus node list trust each other; the target transaction carries the information of the target transaction and the signature; the information of the target transaction includes the information of the initiating account of the target transaction, the operation type, and the public key of the consensus node to be governed; The formula for determining the target value based on the number of target nodes, the operation type of the governance consensus nodes, and the number of consensus nodes to be governed is as follows: sigQuorum = min(n, max(1,n / 2 - opType + opNodeNum )) Wherein, sigQuorum represents the target value; n represents the number of target nodes; opType represents the operation type for governing consensus nodes, opType=1 represents adding consensus nodes, opType=0 represents deleting consensus nodes; opNodeNum represents the number of consensus nodes to be governed.

2. The method for governing consensus nodes according to claim 1, characterized in that, The information of the initiating account of the target transaction is generated based on the private key of the first node; The first node is a node in the consensus node list that is different from the target node.

3. A method for governing consensus nodes, characterized in that, include: Receive information about the target transaction to be initiated from the first node; Based on the private key of the target node and the information of the target transaction, a signature is generated and returned to the first node; Receive the target transaction initiated by the first node; A consensus is reached on the target transaction, and if the consensus passes the target transaction, the consensus node list is updated. The target transaction is used to govern consensus nodes; governing consensus nodes refers to adding or deleting consensus nodes; the target transaction is initiated by the first node when the number of received signatures is greater than or equal to a target value; the target value is determined based on the number of target nodes, the operation type of the governance consensus nodes, and the number of consensus nodes to be governed; the nodes in the consensus node list trust each other; the target transaction carries the information of the target transaction and the signature; the information of the target transaction includes the information of the initiating account of the target transaction, the operation type, and the public key of the consensus node to be governed; The formula for determining the target value based on the number of target nodes, the operation type of the governance consensus nodes, and the number of consensus nodes to be governed is as follows: sigQuorum = min(n, max(1,n / 2 - opType + opNodeNum )) Wherein, sigQuorum represents the target value; n represents the number of target nodes; opType represents the operation type for governing consensus nodes, opType=1 represents adding consensus nodes, opType=0 represents deleting consensus nodes; opNodeNum represents the number of consensus nodes to be governed.

4. The method for governing consensus nodes according to claim 3, characterized in that, The process of reaching consensus on the target transaction, and updating the consensus node list if the consensus passes on the target transaction, includes: Read the consensus node list; Based on the consensus node list and the target transaction, verify whether the signer who generated the signature is legitimate and the validity of the signature; If all signers who generated the signatures are legitimate and all the signatures are valid, and the number of signatures is greater than or equal to the target value, then the consensus on the target transaction is determined to be passed. The operation of the governance consensus node corresponding to the target transaction is executed on the consensus node list.

5. A device for governing consensus nodes, characterized in that, include: The information sending module is used to send information about the target transaction to be initiated to the target node; A signature collection module is used to receive the signature returned by the target node based on the information of the target transaction; The transaction sending module is used to initiate the target transaction to the target node when the number of signatures is greater than or equal to the target value, so that the target node updates the consensus node list when the consensus passes the target transaction; The target nodes are multiple; the target transaction is used to govern consensus nodes; governing consensus nodes refers to adding or deleting consensus nodes; the target value is determined based on the number of target nodes, the operation type of governing consensus nodes, and the number of consensus nodes to be governed; the nodes in the consensus node list trust each other; the target transaction carries the information of the target transaction and the signature; the information of the target transaction includes the information of the initiating account of the target transaction, the operation type, and the public key of the consensus node to be governed; The formula for determining the target value based on the number of target nodes, the operation type of the governance consensus nodes, and the number of consensus nodes to be governed is as follows: sigQuorum = min(n, max(1,n / 2 - opType + opNodeNum )) Wherein, sigQuorum represents the target value; n represents the number of target nodes; opType represents the operation type for governing consensus nodes, opType=1 represents adding consensus nodes, opType=0 represents deleting consensus nodes; opNodeNum represents the number of consensus nodes to be governed.

6. A device for governing consensus nodes, characterized in that, include: The information receiving module is used to receive information about the target transaction to be initiated sent by the first node; The signature module is used to generate a signature based on the private key of the target node and the information of the target transaction, and return the signature to the first node; A transaction receiving module is used to receive the target transaction initiated by the first node; The transaction consensus module is used to reach a consensus on the target transaction and update the consensus node list when the consensus passes the target transaction. The target transaction is used to govern consensus nodes; governing consensus nodes refers to adding or deleting consensus nodes; the target transaction is initiated by the first node when the number of received signatures is greater than or equal to a target value; the target value is determined based on the number of target nodes, the operation type of the governance consensus nodes, and the number of consensus nodes to be governed; the nodes in the consensus node list trust each other; the target transaction carries the information of the target transaction and the signature; the information of the target transaction includes the information of the initiating account of the target transaction, the operation type, and the public key of the consensus node to be governed; The formula for determining the target value based on the number of target nodes, the operation type of the governance consensus nodes, and the number of consensus nodes to be governed is as follows: sigQuorum = min(n, max(1,n / 2 - opType + opNodeNum )) Wherein, sigQuorum represents the target value; n represents the number of target nodes; opType represents the operation type for governing consensus nodes, opType=1 represents adding consensus nodes, opType=0 represents deleting consensus nodes; opNodeNum represents the number of consensus nodes to be governed.

7. An electronic device comprising a processor and a memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the method for a governance consensus node as described in any one of claims 1 to 4.

8. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method for governance consensus nodes as described in any one of claims 1 to 4.

Images