WO2023185059A1

WO2023185059A1 - Consensus method and blockchain node

Info

Publication number: WO2023185059A1
Application number: PCT/CN2022/135666
Authority: WO
Inventors: 石杰; 徐文博; 邓福喜; 闫莺
Original assignee: 蚂蚁区块链科技(上海)有限公司
Priority date: 2022-03-30
Filing date: 2022-11-30
Publication date: 2023-10-05
Also published as: CN114710507B; CN114710507A

Abstract

A consensus method and a blockchain node, wherein the method is executed by means of a first node in a blockchain, the blockchain comprises a plurality of consensus nodes, and the first node is one of the plurality of consensus nodes. The method comprises: acquiring delegation information of a plurality of consensus nodes from a blockchain, wherein the delegation information is used for indicating the number of delegation nodes associated with each consensus node, and the delegation nodes are nodes in the blockchain that delegate any consensus node to perform consensus; and on the basis of the delegation information, performing a consensus operation on a consensus proposal.

Description

A consensus method and blockchain nodes

This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on March 30, 2022, with application number 202210325860.7 and the application name "A consensus method and blockchain node", the entire content of which is incorporated by reference. in this application.

Technical field

The embodiments of this specification belong to the field of blockchain technology, and particularly relate to a consensus method and blockchain nodes.

Background technique

Blockchain is a new application model of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm. In the blockchain system, data blocks are combined into a chained data structure in a chronological manner and are cryptographically guaranteed to be an untamperable and unforgeable distributed ledger. Due to the characteristics of blockchain, such as decentralization, non-tamperable information, and autonomy, blockchain has also received more and more attention and applications.

Contents of the invention

The purpose of the present invention is to provide a consensus solution to improve the consensus efficiency in the blockchain.

A first aspect of this specification provides a consensus method, which is executed by a first node in a blockchain. The blockchain includes multiple consensus nodes, and the first node is one of the multiple consensus nodes. The method includes: obtaining entrustment information from the blockchain, the entrustment information is used to indicate the number of entrustment nodes associated with each of the consensus nodes, and the entrustment node is the entrustment of any of the consensus nodes in the blockchain. Consensus node; performs consensus operations on consensus proposals based on the delegation information.

A second aspect of this specification provides a consensus node, including: an acquisition unit, configured to acquire delegation information from a blockchain, where the delegation information is used to indicate the number of delegation nodes associated with each consensus node, and the delegation node It is a node in the blockchain that entrusts any of the consensus nodes to carry out consensus; a consensus unit is used to perform consensus operations on consensus proposals based on the entrustment information.

A third aspect of this specification provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed in a computer, the computer is caused to execute the method described in the first aspect.

A fourth aspect of this specification provides a consensus node, including a memory and a processor. The memory stores executable code. When the processor executes the executable code, the method described in the first aspect is implemented.

Through the consensus scheme provided by the embodiments of this specification, through delegation between nodes, the number of nodes participating in the consensus is reduced to a smaller number, the consensus time is reduced, the consensus efficiency is improved, the amount of consensus communication data is reduced, and the cost is reduced.

Description of drawings

In order to explain the technical solutions of the embodiments of this specification more clearly, the drawings needed to be used in the description of the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some of the embodiments recorded in this specification. , for those of ordinary skill in the art, other drawings can also be obtained based on these drawings without exerting creative labor.

Figure 1 is a blockchain architecture diagram in an embodiment;

Figure 2 is a schematic diagram of the consensus process in the PBFT consensus algorithm in an embodiment;

Figure 3 is a flow chart of a method for entrusting nodes to perform consensus in the blockchain in an embodiment of this specification;

Figure 4 is a flow chart of the consensus method in an embodiment of this specification;

Figure 5 is a flow chart of a method for setting up malicious nodes in the blockchain in an embodiment of this specification;

Figure 6 is a flowchart of a method for canceling delegation to a consensus node when a consensus node fails in an embodiment of this specification;

Figure 7 is a structural diagram of a consensus node in an embodiment of this specification.

Detailed ways

In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of this specification. Obviously, the described The embodiments are only some of the embodiments of this specification, but not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts should fall within the scope of protection of this specification.

Blockchains are generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain. In addition, there are many types of combinations, such as private chain + alliance chain, alliance chain + public chain and other different combinations. Among them, the most decentralized one is the public chain. Public chains are represented by Bitcoin and Ethereum. Participants who join the public chain can read data records on the chain, participate in transactions, and compete for the accounting rights of new blocks through consensus. In a private chain, the writing permission of the network is controlled by an organization or institution, and the data reading permission is regulated by the organization. The alliance chain is a blockchain between the public chain and the private chain, which can achieve "partial decentralization". Each node in the alliance chain usually has a corresponding entity or organization; participants join the network through authorization and form a stakeholder alliance to jointly maintain the operation of the blockchain.

Figure 1 shows a blockchain architecture diagram in an embodiment. In the blockchain architecture diagram shown in Figure 1, the blockchain 100 includes, for example, a total of 7 nodes from node 1 to node 7. The connections between nodes schematically represent P2P (Peer to Peer, point-to-point) connections. These nodes can store the entire ledger, that is, store the status of all blocks and all accounts. Among them, each node in the blockchain can generate the same state in the blockchain by executing the same transaction, and each node in the blockchain can store the same state database. It can be understood that although FIG. 1 shows that the blockchain includes 7 nodes, the embodiments of this description are not limited to this, and may include other numbers of nodes. Specifically, the nodes included in the blockchain can meet Byzantine Fault Tolerance (BFT) requirements. The mentioned Byzantine fault tolerance requirements can be understood as meaning that Byzantine nodes can exist within the blockchain, but the blockchain does not reflect Byzantine behavior externally. Generally, some Byzantine fault-tolerant algorithms require the number of nodes to be greater than 3f+1, where f is the number of Byzantine nodes (i.e. malicious nodes), such as the Practical Byzantine Fault Tolerance algorithm PBFT (Practical Byzantine Fault Tolerance).

Transactions in the blockchain field can refer to task units that are executed and recorded in the blockchain. Transactions usually include sending fields (From), receiving fields (To) and data fields (Data). Among them, when the transaction is a transfer transaction, the From field represents the account address that initiated the transaction (that is, initiated a transfer task to another account), the To field represents the account address that received the transaction (that is, received the transfer), and the Data field Include transfer amount. In the case of a transaction calling a smart contract in the blockchain, the From field indicates the account address that initiated the transaction, the To field indicates the account address of the contract called by the exchange, and the Data field includes the function name in the calling contract and the corresponding Data such as the incoming parameters of the function are used to obtain the code of the function from the blockchain and execute the code of the function when the transaction is executed.

The functions of smart contracts can be provided in the blockchain. Smart contracts on the blockchain are contracts that can be triggered and executed by transactions on the blockchain system. Smart contracts can be defined in the form of code. Calling a smart contract in the blockchain is to initiate a transaction pointing to the smart contract address, allowing each node in the blockchain to run the smart contract code in a distributed manner. It should be noted that in addition to smart contracts that can be created by users, smart contracts can also be set by the system in the genesis block. This type of contract is generally called a creation contract. Generally, some blockchain data structures, parameters, properties and methods can be set in the genesis contract. In addition, accounts with system administrator rights can create system-level contracts or modify system-level contracts (referred to as system contracts). Among them, the system contract can be used to add data structures for different business data in the blockchain.

In the scenario of deploying a contract, for example, Bob sends a transaction containing information about creating a smart contract (i.e., deploying the contract) to the blockchain as shown in Figure 1. The data field of the transaction includes the code of the contract to be created ( Such as bytecode or machine code), the to field of the transaction is empty to indicate that the transaction is used to deploy the contract. After the nodes reach an agreement through the consensus mechanism, the contract address "0x6f8ae93..." of the contract is determined. Each node adds the contract account corresponding to the contract address of the smart contract in the state database, allocates the state storage corresponding to the contract account, and stores The contract code is saved in the state storage of the contract, so the contract is created successfully.

In the scenario of calling a contract, for example, Bob sends a transaction for calling a smart contract to the blockchain as shown in Figure 1. The from field of the transaction is the address of the account of the transaction initiator (Bob). "0x6f8ae93..." in the to field represents the address of the smart contract being called, and the data field of the transaction includes the method and parameters for calling the smart contract. After consensus is reached on the transaction in the blockchain, each node in the blockchain can execute the transaction respectively, thereby executing the contract respectively, and update the status database based on the execution of the contract.

One of the decentralized features of blockchain technology that distinguishes it from traditional technology is that accounting is performed on each node, or distributed accounting, instead of traditional centralized accounting. In order for the blockchain system to become a decentralized, honest and trustworthy system that is hard to break, open, and cannot tamper with data records, it needs to make distributed data records secure, clear, and irreversible in the shortest possible time. In different types of blockchain networks, in order to maintain the consistency of the ledger in each node that records the ledger, a consensus algorithm is usually used to ensure it, that is, the consensus mechanism mentioned above. For example, blockchain nodes can implement a block-granular consensus mechanism. For example, after a node (such as a unique node) generates a block, if the generated block is recognized by other nodes, the records of other nodes will be the same. block. For another example, a transaction-granularity consensus mechanism can be implemented between blockchain nodes. For example, after a node (such as a unique node) obtains a blockchain transaction, if the blockchain transaction is recognized by other nodes, Each node that recognizes the blockchain transaction can add the blockchain transaction to the latest block maintained by itself, and ultimately ensure that each node generates the same latest block. The consensus mechanism is a mechanism for blockchain nodes to reach a consensus across the entire network on block information (or block data), which can ensure that the latest blocks are accurately added to the blockchain. The current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) ) algorithm, etc. Among them, in various consensus algorithms, the success of the consensus on the consensus proposal is usually determined after a preset number of nodes reach an agreement on the consensus data (ie, consensus proposal). Specifically, in the PBFT algorithm, for N ≥ 3f + 1 consensus nodes, f malicious nodes can be tolerated. That is to say, when 2f + 1 nodes among the N consensus nodes reach an agreement, the consensus can be determined to be successful.

Figure 2 is a schematic diagram of the consensus process in the PBFT consensus algorithm. As shown in Figure 2, according to the PBFT consensus algorithm, the consensus process can be divided into four stages: Request, Pre-Prepare, Prepare and Commit. Assume that a blockchain includes four consensus nodes, node n1 - node n4, where node n1 is, for example, the master node, and node n2 - node n4, for example, are slave nodes. According to the PBFT algorithm, f can be tolerated in node n1 - node n4. =1 malicious node. Specifically, in the request phase, the user of the blockchain can send a request to the node n1 through its user device, and the request is, for example, in the form of a blockchain transaction. In the preliminary stage, after receiving multiple transactions from one or more user devices, node n1 can package the multiple transactions into a consensus proposal, and send the consensus proposal and node n1's signature to the consensus proposal to other consensus nodes. (i.e., node n2 - node n4) to generate blocks. The consensus proposal may include information such as the transaction body of the multiple transactions and the submission order of the multiple transactions. During the preparation phase, each slave node can sign the consensus proposal and send it to each other node. Assuming that node n4 is a malicious node, node n1, node n2 and node n3 can determine that the preparation phase is completed and can enter the submission phase after receiving the signatures of 2f = 2 other consensus nodes on the consensus proposal. For example, as shown in Figure 2, after node n1 receives the signatures of node n2 and node n3, it verifies that the signatures of node n2 and node n3 are correct signatures of the consensus proposal, then it is determined that the preparation phase is completed, and node n2 is After receiving the signature of node n3 and the signature of node n1 in the preparation phase and passing the verification, it is determined that the preparation phase is completed. In the submission phase, each consensus node signs the consensus proposal in the submission phase and sends it to each other consensus node. After receiving the signatures of 2f = 2 other consensus nodes in the submission phase, each consensus node can confirm that the submission phase is completed and the consensus success. For example, after receiving and verifying the signatures of the submission phase of node n2 and node n3, node n1 determines that the submission phase is completed. Therefore, node n1 can execute the multiple transactions according to the consensus proposal, generate and store the multiple transactions including the multiple transactions. The transaction block (for example, block B1) updates the world state based on the execution results of multiple transactions and returns the execution results of multiple transactions to the user device. Similarly, after determining that the submission phase is completed, node n2 and node n3 execute the multiple transactions, generate and store block B1, and update the world state according to the execution results of the multiple transactions. Through the above process, the storage consistency of node n1, node n2 and node n3 is achieved. In other words, nodes n1-node n4 can still achieve successful consensus on the consensus proposal and complete the execution of the block even if there is a malicious node.

In recent years, the scale of blockchain has become larger and larger, and the business has become more and more complex. As the size of the node increases, consensus among multiple consensus nodes through the process shown in Figure 2 will require multiple communications between multiple consensus nodes, causing the consensus efficiency to decrease. For example, in the blockchain shown in Figure 1, the number of nodes is 7. In the case where all 7 nodes participate in the consensus, the number f of malicious nodes that can be tolerated is 2. In the preparation phase or submission phase of the consensus process, each node can only confirm the completion of this phase after receiving and verifying the signatures of 2f = 4 other nodes on the consensus proposal.

In a related technology, multiple nodes vote to elect a preset number of consensus nodes. This related technology usually runs on the public chain and is based on the following three key elements: 1) Incentive mechanism: through the issuance of virtual tokens, equity, interest and other rewards, nodes are encouraged to participate in elections and voting; 2) Equity pledge : Through high enough equity pledge, the cost of doing evil is increased, so that the elected representative nodes will not do evil, ensuring the security of the system; 3) Off-chain governance: through the governance of off-chain foundations and arbitration committees , enhance the value of tokens and ensure the healthy operation of the system. However, since the above elements are usually not included in the alliance chain, the above consensus mechanism cannot be used in the alliance chain.

To this end, the embodiment of this specification proposes a solution for converging the scale of consensus nodes through a delegation mechanism. This solution can reasonably utilize some trust relationships between nodes in actual projects and support stable consensus of large-scale nodes.

Figure 3 is a flow chart of a method for entrusting nodes to perform consensus in the blockchain in an embodiment of this specification.

As shown in Figure 3, first in step S301, node 5 sends transaction Tx1 to the blockchain to entrust node 2 to carry out consensus.

Assuming that node 5 in Figure 1 regards node 2 as a trusted node, node 5 can send a transaction Tx1 for delegation to the blockchain, entrusting node 2 to perform consensus on behalf of node 5. Node 5 and node 2 may be, for example, two nodes in the same organization. Specifically, node 5 can generate transaction Tx1, which can be used to call the pre-deployed smart contract C1 in the blockchain to record delegation information in the blockchain. After generating transaction Tx1, node 5 can send transaction Tx1 to any node in the blockchain (for example, node 1) to achieve consensus and execution in the blockchain through the process shown in Figure 2.

In step S303, the node in the blockchain executes the transaction Tx1 and records the delegation information in the blockchain.

Assume that, as shown in Figure 1, nodes 1 to 7 in the blockchain are currently consensus nodes. Each consensus node in the blockchain is proposing consensus on the consensus corresponding to the block where transaction Tx1 is located (for example, block B1). After success, transaction Tx1 is executed respectively, and the world state is updated based on the execution result of transaction Tx1. Taking node 1 as an example, after executing transaction Tx1, node 1 can record the commission information in the contract status of contract C1.

In one implementation, a consensus node information table may be stored in the contract state of contract C1. Before executing transaction Tx1, the consensus node information table is, for example, as shown in Table 1:

Table 1

共识节点Consensus node	权重Weights	委托节点Delegate node
节点1Node 1	11
节点2Node 2	11
节点3Node 3	11
节点4Node 4	11
节点5Node 5	11
节点6Node 6	11
节点7Node 7	11

Table 1 shows that nodes 1 to 7 are all consensus nodes, and their entrusted node columns are all empty, indicating that no other node has entrusted them to perform consensus on their behalf. A weight of 1 indicates that each consensus node currently only performs consensus on its own behalf.

After node 1 executes transaction Tx1 and updates the contract status of contract C1 according to transaction Tx1, according to this transaction Tx1, since node 5 entrusts node 2 to entrust, node 5 no longer performs consensus, so it is deleted from the consensus node information table The information of node 5 and change the information of node 2. After making this modification, the consensus node information table is as shown in Table 2:

Table 2

共识节点Consensus node	权重Weights	委托节点Delegate node
节点1Node 1	11
节点2Node 2	22	节点5Node 5

节点3Node 3	11
节点4Node 4	11
节点6Node 6	11
节点7Node 7	11

Similarly, assume that node 6 sends transaction Tx2 to the blockchain to entrust node 2 for consensus, and node 7 sends transaction Tx3 to the blockchain to entrust node 3 for consensus. The transactions are executed sequentially in the blockchain. Tx2 and transaction Tx3 can obtain the consensus node information table shown in Table 3:

table 3

共识节点Consensus node	权重Weights	委托节点Delegate node
节点1Node 1	11
节点2Node 2	33	节点5、节点6Node 5, Node 6
节点3Node 3	22	节点7Node 7
节点4Node 4	11

After delegation through the process described above, the number of consensus nodes in the blockchain is reduced from 7 to 4, which can greatly reduce the communication volume in the blockchain consensus process. When performing consensus, Node 1-Node 4 can calculate the number of signatures based on the weight, thereby performing consensus on behalf of the entrusted node.

In another embodiment, the contract status of contract C1 also includes a delegation node information table. The delegation node information table includes, for example, the identification of the node that entrusts other nodes to perform consensus and the identification of the corresponding trusted node. After executing each transaction for the entrusted node, the node in the blockchain also updates the entrusted node information table in the contract status of contract C1. For example,

After node 1 executes the above transaction Tx3, it can generate the entrusted node information table as shown in Table 4:

Table 4

委托节点Delegate node	受托节点Trusted node
节点5Node 5	节点2Node 2
节点6Node 6	节点2Node 2
节点7Node 7	节点3Node 3

It can be understood that in the embodiments of this specification, the delegation information recorded in the blockchain is not limited to the above. As long as the delegation information can indicate the number of delegation nodes corresponding to each consensus node, the consensus provided by the embodiments of this specification can be executed. method.

Figure 4 is a flow chart of a consensus method in an embodiment of this specification. This consensus method can be executed by any consensus node in the blockchain, specifically including the following steps:

Step S401, obtain delegation information from the blockchain;

Step S403: Perform consensus operation based on delegation information.

Each step of the method shown in Figure 4 will be described in detail below.

First, in step S401, each consensus node obtains the delegation information in the blockchain.

The method shown in Figure 4 is described below taking node 1 as an example. The delegation information includes, for example, the consensus node information table shown in Table 3 of the contract status of contract C1 in node 1. Assume that node 1 is the master node among multiple consensus nodes. Referring to Figure 2, in the request phase, node 1 generates a consensus proposal after receiving multiple transactions from one or more user devices. The consensus proposal includes, for example, the generation Multiple transactions in block B2 and the submission order of the multiple transactions. In order to reach consensus with the consensus nodes in the blockchain, Node 1 needs to obtain the information of each consensus node in the blockchain. Therefore, node 1 can read the consensus node information table shown in Table 3 from the blockchain. Specifically, node 1 can initiate a query request (or query transaction) for calling contract C1, thereby querying the current consensus node information table of contract C1 locally.

In step S403, each consensus node performs a consensus operation based on the delegation information.

Specifically, in the preliminary stage, node 1 sends the consensus proposal and node 1's signature of the consensus proposal to node 2, node 3 and node 4 respectively based on the identification of each consensus node in Table 3.

In the preparation phase, node 2, node 3 and node 4 respectively sign the consensus proposal and send the consensus proposal and its signature to other consensus nodes respectively. For example, node 1 receives the signatures of node 2 and node 3 on the consensus proposal. Node 1 can calculate the number of signatures S1 obtained based on the weights of node 1, node 2 and node 3 in the consensus node information table, that is, S1=1+3 +2=6. As mentioned above, in the blockchain shown in Figure 1, f = 2 malicious nodes can be tolerated. Therefore, each consensus node needs to obtain the signatures of 2f + 1 = 5 consensus nodes to confirm that the preliminary phase is completed. . Node 1 calculates the signature number S1=6>5 as described above, so it can confirm that the preliminary phase is completed.

After receiving the signatures of node 1 and node 3 on the consensus proposal, node 2 can calculate the number of signatures obtained based on the weights of node 1, node 2 and node 3 in Table 3 S2=1+3+2=6>5, therefore It can be confirmed that the preliminary stage is completed.

Node 3 and Node 4 may similarly determine that the preliminary phase is complete.

After the preparation phase is completed, Node 1-Node 4 respectively send the signatures of the consensus proposal in the preparation phase to other consensus nodes in Table 3. Each consensus node can similarly determine the number of signatures obtained according to Table 3. When the number of signatures is greater than or equal to 5, it can be determined that the preparation phase is completed, and therefore the consensus process for block B2 is completed.

Node 1 - After completing the consensus on block B2, node 4 executes multiple transactions in block B2, generates block B2, and updates the world state based on the execution results of block B2. Afterwards, Node 1-Node 4 can respectively send the generated block B2 to their respective entrusting nodes. Specifically, node 2 can send the block B2 it generates to node 5 and node 6, and node 3 can send the block B2 it generates to node 7. After receiving block B2, each delegation node stores block B2 and updates the world state by executing multiple transactions included in block B2, thereby achieving a world state consistent with the consensus node.

In another implementation, each consensus node may broadcast a block synchronization event to each node of the blockchain after generating block B2. After the delegated node receives the event, it synchronizes block B2 from its delegated consensus node. In another implementation, the entrusting node can periodically send query requests to the consensus node it entrusts to query the block height of the consensus node. When it is found that the block height of the consensus node is higher than its own block height, the entrusted consensus node can Nodes synchronize new blocks.

During the consensus process, each consensus node can record information such as the identity of the source node of each received signature in the log, so that a fork occurs when a consensus proposal is received (that is, different consensus proposals and their signatures are received) In this case, the malicious nodes among the consensus nodes can be locked based on the logs. After the consensus node identifies a malicious node, it can limit its participation in the consensus by recording the malicious node and its delegated nodes in the blockchain.

Figure 5 is a flow chart of a method for setting up malicious nodes in the blockchain according to an embodiment of this specification.

As shown in Figure 5, assume that node 4 determines that node 3 is a malicious node during the consensus process. By querying the contract status of the above-mentioned smart contract, node 4 can determine that the weight of node 3 is 2, which is what the above-mentioned blockchain can tolerate. The number of malicious nodes, therefore, node 3 can be set as a malicious node through consensus in this blockchain.

Specifically, in step S501, node 4 sends transaction Tx4 to node 1. Transaction Tx4 can be used to call the above smart contract to set node 3 as a malicious node in the blockchain.

In step S503, the consensus node in the blockchain executes transaction Tx4 and updates the delegation information in the blockchain.

After receiving the consensus proposal for block B3 including transaction Tx4, the current consensus nodes (node 1-node 4) in the blockchain consensus on the consensus proposal through the process shown in Figure 2. Due to the weight of each consensus node The sum (7) and the weight 2 of the malicious node (node 3) satisfy the relationship of 3f+1:f, so nodes 1-node 3 can successfully propose a consensus for this consensus. Take node 1 as an example. After the consensus proposal for block B3 succeeds, node 1 executes transaction Tx4. In the contract status of contract C1, the information of node 3 is deleted in Table 3, and the information of node 7 is deleted in Table 4. information, and put node 3 and node 7 into the malicious node list in the contract state. After adding node 3 and node 7 to the malicious node list, node 3 and node 7 can no longer participate in the consensus, but can only participate in the consensus from either Consensus nodes synchronize blocks.

It can be understood that in the case where the consensus node determines that node 2 is a malicious node, since the weight of node 2 is 3, the sum of the weights of each consensus node (7) cannot satisfy the relationship of less than or equal to f: 3f+1, so it cannot Set node 2 as a malicious node by executing the transaction.

In addition, the consensus nodes can monitor each other's operating status, or the entrusting node can monitor the status of the entrusted consensus node after entrusting the consensus node. When a failure of the consensus node is detected, a transaction can be sent to the blockchain to cancel the entrustment. Delegation of nodes to consensus nodes.

Figure 6 is a flowchart of a method for canceling delegation to a consensus node when a consensus node fails in an embodiment of this specification.

As shown in Figure 6, assuming that node 4 determines that node 3 is faulty, in step S601, node 4 can send a transaction Tx5 that calls the above contract C1 to node 1 to cancel the entrustment of node 3 by the entrusting node (ie node 7). .

In step S603, node 1 executes transaction Tx5 and updates the delegation information.

Assume that the current consensus nodes in the blockchain are as shown in Table 3. As mentioned above, since the weight of node 3 and the sum of the weights of all consensus nodes satisfy the relationship f:3f+1, therefore, node 1, node 2 and node 4. The consensus on the transaction Tx5 can be successful, and the commission information will be updated based on the transaction Tx5. Specifically, taking node 1 as an example, after node 1 executes transaction Tx5 and reaches consensus successfully, it deletes the information of node 3 in the consensus node information table in Table 3, and adds node 7 as a consensus node. In the delegation shown in Table 4 Delete the information of node 7 from the node information table.

Figure 7 is a structural diagram of a consensus node in an embodiment of this specification, including:

The acquisition unit 71 is used to acquire the entrustment information of multiple consensus nodes from the blockchain. The entrustment information is used to indicate the number of entrustment nodes associated with each consensus node. The entrustment node is in the blockchain. A node that entrusts any of the consensus nodes to carry out consensus;

The consensus unit 72 is configured to perform a consensus operation on the consensus proposal based on the delegation information.

In one implementation, the consensus node further includes: a receiving unit, configured to receive a first transaction, the first transaction being sent by a second node among the plurality of consensus nodes, and used to entrust the plurality of consensus nodes to The third node among the consensus nodes performs consensus; an update unit is used to update the delegation information according to the first transaction.

In one implementation, the delegation information includes a consensus node information table. The consensus node information table includes the identification and weight of each consensus node. The weight is used to indicate the delegation node associated with each consensus node. The update unit is specifically configured to: delete the information of the second node in the consensus node information table, and increase the weight of the third node by one.

In one implementation, the delegation information further includes a delegation node information table, and the update unit is specifically configured to record the delegation of the second node to the third node in the delegation node information table.

In one implementation, the consensus unit 72 is specifically configured to: generate its own signature for the consensus proposal, receive the signatures of the other consensus nodes for the consensus proposal from other consensus nodes, and generate The weight information is used to calculate the number of signatures obtained for the consensus proposal, and whether the consensus is successful is confirmed based on the number of signatures.

In one implementation, the delegation information of the first node also includes an identification of a fourth node that delegates the first node, and the consensus node further includes: a generating unit for proposing a consensus on the consensus. After success, the first block is generated according to the consensus proposal, and the first block is sent to the fourth node.

In one implementation, the blockchain includes a smart contract, the delegation information is stored in a contract state of the smart contract, and the first transaction calls the smart contract.

In one implementation, the delegation information further includes a malicious node list, and the receiving unit is further configured to: receive a second transaction, where the second transaction is used to indicate that the fifth node among the plurality of consensus nodes is Malicious node, the update unit is also configured to: execute the second transaction, delete the information of the fifth node in the consensus node information table, and add the identification of the fifth node to the malicious node list The identifier of the delegation node associated with the fifth node.

In one implementation, the receiving unit is further configured to receive a third transaction, the third transaction is used to indicate that the sixth node among the plurality of consensus nodes is a fault node, and execute the third transaction, To delete the information of the sixth node in the consensus node information table, and add the identification and weight of the delegation node associated with the sixth node in the consensus node information table.

In the 1990s, improvements in a technology could be clearly distinguished as hardware improvements (for example, improvements in circuit structures such as diodes, transistors, switches, etc.) or software improvements (improvements in method processes). However, with the development of technology, many improvements in today's method processes can be regarded as direct improvements in hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement of a method flow cannot be implemented using hardware entity modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic functions are determined by the user programming the device. Designers can program themselves to "integrate" a digital system on a PLD, instead of asking chip manufacturers to design and produce dedicated integrated circuit chips. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented using "logic compiler" software, which is similar to the software compiler used in program development and writing, and before compilation The original code must also be written in a specific programming language, which is called Hardware Description Language (HDL), and HDL is not just one kind, but there are many, such as ABEL (Advanced Boolean Expression Language) , AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., are currently the most commonly used The two are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that by simply logically programming the method flow using the above-mentioned hardware description languages and programming it into the integrated circuit, the hardware circuit that implements the logical method flow can be easily obtained.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (eg, software or firmware) executable by the (micro)processor. , logic gates, switches, Application Specific Integrated Circuit (ASIC), programmable logic controllers and embedded microcontrollers. Examples of controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, For Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the memory's control logic. Those skilled in the art also know that in addition to implementing the controller in the form of pure computer-readable program code, the controller can be completely programmed with logic gates, switches, application-specific integrated circuits, programmable logic controllers and embedded logic by logically programming the method steps. Microcontroller, etc. to achieve the same function. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the means for implementing various functions can be considered as structures within hardware components as well as software modules implementing the methods.

The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not rule out that with the development of computer technology in the future, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, or a personal digital assistant. , media player, navigation device, email device, game console, tablet, wearable device, or a combination of any of these devices.

Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-inventive means. The sequence of steps listed in the embodiment is only one way of executing the sequence of many steps, and does not represent the only execution sequence. When the actual device or terminal product is executed, it may be executed sequentially or in parallel according to the methods shown in the embodiments or figures (for example, a parallel processor or a multi-thread processing environment, or even a distributed data processing environment). The terms "comprises," "comprises" or any other variation thereof are intended to cover a non-exclusive inclusion such that a process, method, product or apparatus including a list of elements includes not only those elements but also others not expressly listed elements, or also elements inherent to the process, method, product or equipment. Without further limitation, it does not exclude the presence of additional identical or equivalent elements in a process, method, product or apparatus including the stated elements. For example, if the words "first" and "second" are used to express names, they do not indicate any specific order.

For the convenience of description, when describing the above device, the functions are divided into various modules and described separately. Of course, when implementing one or more of this specification, the functions of each module can be implemented in the same or multiple software and/or hardware, or the modules that implement the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. . The device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated. to another system, or some features can be ignored, or not implemented. On the other hand, the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each process and/or block in the flowchart illustrations and/or block diagrams, and combinations of processes and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing device to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing device produce a use A device for implementing the functions specified in one process or processes of the flowchart and/or one block or blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory that causes a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction means, the instructions The device implements the functions specified in a process or processes of the flowchart and/or a block or blocks of the block diagram.

These computer program instructions may also be loaded onto a computer or other programmable data processing device, causing a series of operating steps to be performed on the computer or other programmable device to produce computer-implemented processing, thereby executing on the computer or other programmable device. Instructions provide steps for implementing the functions specified in a process or processes of a flowchart diagram and/or a block or blocks of a block diagram.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

Memory may include non-permanent storage in computer-readable media, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer-readable media includes both persistent and non-volatile, removable and non-removable media that can be implemented by any method or technology for storage of information. Information may be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), and read-only memory. (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, Magnetic tape, magnetic tape storage, graphene storage or other magnetic storage devices or any other non-transmission medium can be used to store information that can be accessed by a computing device. As defined in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

It should be understood by those skilled in the art that one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment that combines software and hardware aspects. Furthermore, one or more embodiments of the present description may employ a computer program implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein. Product form.

One or more embodiments of this specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. One or more embodiments of the present description may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including storage devices.

Each embodiment in this specification is described in a progressive manner. The same and similar parts between the various embodiments can be referred to each other. Each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple. For relevant details, please refer to the partial description of the method embodiment. In the description of this specification, reference to the terms "one embodiment," "some embodiments," "an example," "specific examples," or "some examples" or the like means that specific features are described in connection with the embodiment or example. , structures, materials or features are included in at least one embodiment or example of this specification. In this specification, the schematic expressions of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the specific features, structures, materials or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and combine different embodiments or examples and features of different embodiments or examples described in this specification unless they are inconsistent with each other.

The above descriptions are only examples of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. To those skilled in the art, various modifications and changes may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this specification shall be included in the scope of the claims.

Claims

A consensus method is executed by a first node in a blockchain, the blockchain includes multiple consensus nodes, the first node is one of the multiple consensus nodes, the method includes:

Obtain entrustment information from the blockchain. The entrustment information is used to indicate the number of entrustment nodes associated with each consensus node. The entrustment node is a node in the blockchain that entrusts any of the consensus nodes to perform consensus. ;

The consensus operation on the consensus proposal is performed based on the delegation information.
The method of claim 1, further comprising:

Receive a first transaction, the first transaction is sent by a second node among the plurality of consensus nodes, and is used to entrust a third node among the plurality of consensus nodes to carry out consensus;

According to the first transaction, the information of the second node is deleted from the delegation information, and the number of delegation nodes associated with the third node is updated.
The method according to claim 2, the delegation information includes a consensus node information table, the consensus node information table includes the identification and weight of each consensus node, the weight is used to indicate the delegation associated with each of the consensus nodes. The number of nodes. The updating of the delegation information according to the first transaction includes:

Delete the information of the second node in the consensus node information table, and add one to the weight of the third node.
According to the method of claim 3, the delegation information further includes a delegation node information table, and the method further includes: recording the delegation of the second node to the third node in the delegation node information table.
According to the method of claim 1 or 2, the consensus operation on the consensus proposal based on the delegation information includes: generating its own signature on the consensus proposal, and receiving the signature of the other consensus node on the consensus proposal from other consensus nodes. For the signature of the consensus proposal, the number of signatures obtained for the consensus proposal is calculated based on the number of delegation nodes associated with each consensus node, and whether the consensus is successful is confirmed based on the number of signatures.
The method according to claim 1 or 2, wherein the delegation information further includes an identification of a fourth node that delegates the first node, and the method further includes:

After the consensus proposal is successfully reached, a first block is generated according to the consensus proposal, and the first block is sent to the fourth node.
The method of claim 2, wherein the blockchain includes a smart contract, the delegation information is stored in a contract state of the smart contract, and the first transaction calls the smart contract.
The method of claim 3, wherein the delegation information further includes a list of malicious nodes, and the method further includes: receiving a second transaction, the second transaction being used to indicate that a fifth node among the plurality of consensus nodes is The malicious node executes the second transaction, deletes the information of the fifth node in the consensus node information table, and adds the identifier of the fifth node and the information associated with the fifth node in the malicious node list. The identifier of the delegate node.
The method of claim 3, further comprising: receiving a third transaction, the third transaction being used to indicate that a sixth node among the plurality of consensus nodes is a fault node, and executing the third transaction to ensure that the sixth node among the plurality of consensus nodes is a fault node. Delete the information of the sixth node from the consensus node information table, and add the identification and weight of the delegation node associated with the sixth node to the consensus node information table.
A blockchain node including:

An acquisition unit is used to obtain entrustment information from the blockchain. The entrustment information is used to indicate the number of entrustment nodes associated with each of the consensus nodes. The entrustment node is the entrustment of any one of the consensuses in the blockchain. The node where the node performs consensus;

A consensus unit is used to perform consensus operations on consensus proposals based on the delegation information.
The node of claim 10, further comprising:

A receiving unit, configured to receive a first transaction sent by a second node among the plurality of consensus nodes, and to entrust a third node among the plurality of consensus nodes to perform consensus;

An update unit, configured to delete the information of the second node in the delegation information according to the first transaction, and update the number of delegation nodes associated with the third node.
The node according to claim 11, the delegation information includes a consensus node information table, the consensus node information table includes the identification and weight of each consensus node, the weight is used to indicate the delegation associated with each of the consensus nodes. The number of nodes, the update unit is specifically used to:

Delete the information of the second node in the consensus node information table, and add one to the weight of the third node.
According to the node according to claim 10 or 11, the consensus unit is specifically configured to: generate its own signature for the consensus proposal, receive the signatures of the other consensus nodes for the consensus proposal from other consensus nodes, and according to each The number of delegated nodes associated with the consensus node is calculated by calculating the number of signatures obtained for the consensus proposal, and whether the consensus is successful is confirmed based on the number of signatures.
A computer-readable storage medium on which a computer program is stored. When the computer program is executed in a computer, the computer is caused to perform the method described in any one of claims 1-9.
A consensus node includes a memory and a processor. The memory stores executable code. When the processor executes the executable code, it implements the method described in any one of claims 1-9.