Consensus node rotation method and blockchain node

Abstract

A method for rotating a consensus node in a blockchain and a blockchain node, the blockchain node in the blockchain comprising a consensus node and a candidate node for rotation to the consensus node, the method being performed by the blockchain node and comprising: obtaining a first transaction, the first transaction invoking a first contract for rotating the consensus node; obtaining, according to the first contract, a random number seed corresponding to a current first block and generated by a current plurality of consensus nodes; determining, based on the random number seed, a node to be rotated from among the consensus node and the candidate node; and storing, according to information of the determined node to be rotated, updated information of the consensus node and the candidate node in the blockchain.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a consensus node rotation method and blockchain nodes in a blockchain. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked together to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain is receiving increasing attention and application. Summary of the Invention

[0003] The purpose of this invention is to provide a consensus node rotation method in a blockchain to ensure the correct operation of consensus node rotation in the blockchain.

[0004] This specification provides a method for rotating consensus nodes in a blockchain, wherein the blockchain nodes include consensus nodes and candidate nodes for rotating as consensus nodes, and the method is executed by the blockchain nodes, including:

[0005] Obtain the first transaction, which calls the first contract to perform consensus node rotation;

[0006] According to the first contract, obtain the random number seed corresponding to the current first block, which is jointly generated by multiple consensus nodes.

[0007] The nodes to be rotated among the consensus nodes and candidate nodes are determined based on the random number seed;

[0008] Based on the determined node information to be rotated, the updated consensus node information and candidate node information are stored in the blockchain.

[0009] A second aspect of this specification provides a blockchain node, which includes a consensus node and candidate nodes for rotating as the consensus node. The blockchain node includes:

[0010] The acquisition unit is used to acquire the first transaction, which calls the first contract for consensus node rotation; and to acquire the random number seed corresponding to the current first block, which is jointly generated by multiple current consensus nodes, according to the first contract.

[0011] The determining unit is used to determine the nodes to be rotated among the consensus nodes and candidate nodes based on the random number seed;

[0012] The storage unit is used to store updated consensus node information and candidate node information in the blockchain based on the determined node information to be rotated.

[0013] A third aspect of this specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0014] A fourth aspect of this specification provides a blockchain node, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method described in the first aspect.

[0015] In the scheme provided in the embodiments of this specification, a transaction invoking a contract is sent to the blockchain by multiple nodes (which may include consensus nodes and / or candidate nodes) to trigger consensus node rotation. When executing this transaction, the blockchain determines the consensus node to be rotated and the candidate node based on a random number seed jointly generated by multiple consensus nodes, according to the contract. This prevents the primary consensus node from predicting or interfering with the generation of random numbers, avoiding affecting the fairness of the blockchain and ensuring the correct operation of consensus node rotation. Attached Figure Description

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

[0017] Figure 1 This is a diagram of a blockchain architecture in one embodiment;

[0018] Figure 2 This is a schematic diagram of the consensus process in the PBFT consensus algorithm;

[0019] Figure 3 This is a flowchart of a method for generating random number seeds on a blockchain, as described in the embodiments of this specification.

[0020] Figure 4 This is a flowchart illustrating the method for initiating consensus node rotation in the embodiments of this specification;

[0021] Figure 5 This is a flowchart illustrating the method for initiating consensus node rotation in another embodiment of this specification;

[0022] Figure 6 This is a flowchart of the consensus node rotation method in the embodiments of this specification;

[0023] Figure 7 This is an architecture diagram of a blockchain node in one of the embodiments of this specification. Detailed Implementation

[0024] 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 with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0025] Figure 1 A blockchain architecture diagram from one embodiment is shown. Figure 1 In the blockchain architecture diagram shown, blockchain 100 includes N nodes. Figure 1 The diagram illustrates nodes 1 through 8. The lines connecting the nodes schematically represent P2P (Peer-to-Peer) connections, such as TCP connections, used for data transfer between nodes. These nodes can store the entire ledger, i.e., the state of all blocks and all accounts. Each node in the blockchain can produce the same state by executing the same transactions, and each node can store the same state database.

[0026] In the blockchain field, a transaction refers to a unit of task executed and recorded within the blockchain. A transaction typically includes a From field, a To field, and a Data field. Specifically, in the case of a transfer transaction, the From field represents the account address initiating the transaction (i.e., initiating a transfer task to another account), the To field represents the account address receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount.

[0027] Blockchain provides the functionality of smart contracts. A smart contract on the blockchain is a contract that can be triggered and executed through transactions within the blockchain system. Smart contracts can be defined in the form of code. Calling a smart contract on the blockchain involves initiating a transaction pointing to the smart contract's address, causing each node in the blockchain to run the smart contract code in a distributed manner.

[0028] In a contract deployment scenario, for example, Bob sends a transaction containing information about creating a smart contract (i.e., deploying the contract) to a server such as... Figure 1In the blockchain shown, the `data` field of the transaction includes the code (such as bytecode or machine code) of the contract to be created, and the `to` field of the transaction is empty, indicating that the transaction is used to deploy the contract. After the nodes reach an agreement through the consensus mechanism, they determine the contract address "0x6f8ae93…". Each node adds a contract account corresponding to the contract address of the smart contract to the state database, allocates state storage corresponding to the contract account, stores the contract code, and saves the hash value of the contract code in the contract's state storage, thus the contract is successfully created.

[0029] In scenarios where contracts are invoked, for example, Bob sends a transaction to invoke a smart contract, such as... Figure 1 In the blockchain shown, the `from` field of this transaction is the address of the account of the transaction initiator (i.e., Bob), the `to` field is the aforementioned "0x6f8ae93…", which is the address of the smart contract being invoked, and the `data` field of the transaction includes the method and parameters for invoking the smart contract. After consensus is reached on this transaction in the blockchain, each node in the blockchain can execute the transaction, thereby executing the contract separately, and updating the state database based on the execution of the contract.

[0030] One of the decentralized characteristics that distinguishes blockchain technology from traditional technologies is its distributed ledger system, where records are kept on multiple nodes, rather than a centralized system. For a blockchain system to become a robust, publicly accessible, and tamper-proof decentralized system of honest and trustworthy data records, it needs to ensure the security, clarity, and irreversibility of distributed data records in the shortest possible time. In different types of blockchain networks, consensus algorithms are typically used to maintain consistency across the nodes recording the ledger—the consensus mechanisms mentioned earlier. For example, blockchain nodes can implement block-level consensus mechanisms. After a node (e.g., a unique node) generates a block, if this block is recognized by other nodes, those nodes record the same block. As another example, blockchain nodes can implement transaction-level consensus mechanisms. After a node (e.g., a unique node) acquires a blockchain transaction, if this transaction is recognized by other nodes, each node that recognized the transaction can add it to its own latest maintained block, ultimately ensuring that all nodes produce the same latest block. A consensus mechanism is a mechanism by which blockchain nodes reach a network-wide consensus on block information (or block data), ensuring that the latest block is accurately added to the blockchain. Current mainstream consensus mechanisms include Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPoS), and Practical Byzantine Fault Tolerance (PBFT) algorithms. In various consensus algorithms, consensus on a consensus proposal is typically determined after a predetermined number of nodes reach agreement on the proposed data. Specifically, in the PBFT algorithm, for N ≥ 3f+1 consensus nodes, f malicious nodes can be tolerated. That is, when 2f+1 out of N consensus nodes reach agreement, consensus is considered successful.

[0031] Figure 2 This is a schematic diagram of the consensus process in the PBFT consensus algorithm. Figure 2As shown, according to the PBFT consensus algorithm, the consensus process can be divided into four phases: Request, Pre-Prepare (PP), Prepare (P), and Commit (C). Assume a blockchain includes four consensus nodes: n1 to n4. Node n1 is, for example, the master node, and nodes n2 to n4 are, for example, slave nodes. According to the PBFT algorithm, f=1 malicious nodes can be tolerated among nodes n1 to n4. Specifically, in the Request phase, blockchain users can send requests to node n1 through their user devices. These requests can be, for example, in the form of blockchain transactions. In the Pre-Prepare phase, after receiving multiple transactions from one or more user devices, node n1 can package these transactions into a consensus proposal (also called the original transaction list). This consensus proposal, along with node n1's signature on it, is sent to the other consensus nodes (i.e., nodes n2 to n4) for block generation. The consensus proposal may include the transaction bodies and the submission order of the transactions. The signature on the consensus proposal typically refers to generating a signature based on the hash value of the consensus proposal. During the preparation phase, each slave node can sign the consensus proposal and send the signatures to the other nodes. Assuming node n4 is malicious, after nodes n1, n2, and n3 receive signatures for the consensus proposal from 2f = 2 other consensus nodes, they can determine that the preparation phase is complete and proceed to the commit phase. For example, if... Figure 2 As shown, after receiving the signatures from nodes n2 and n3, node n1 verifies that both signatures are correct for the consensus proposal, thus determining that the preparation phase is complete. Similarly, after receiving and verifying the signatures from node n3 and node n1 (from the preparation phase), node n2 determines that the preparation phase is complete. In the commit phase, each consensus node signs the consensus proposal and sends the generated signatures to the other consensus nodes. Each consensus node, after receiving the commit phase signatures from 2f = 2 other consensus nodes, determines that the commit phase is complete and consensus is successful. For example, after receiving and verifying the commit phase signatures from nodes n2 and n3, node n1 determines that the commit phase is complete. Therefore, node n1 can execute the multiple transactions according to the consensus proposal, update the world state based on the execution results of the multiple transactions, generate and store a block including the multiple transactions (e.g., block B1), and return the execution results of the multiple transactions to the user device. Similarly, after determining that the commit phase is complete, nodes n2 and n3 execute the multiple transactions, update the world state based on the execution results of the multiple transactions, and generate and store a block. Through the above process, storage consistency is achieved among nodes n1, n2, and n3. In other words, even with the presence of a malicious node, nodes n1 through n4 can still achieve successful consensus on the consensus proposal and complete the execution of the block.

[0032] In large-scale blockchain systems with over a hundred nodes, having all nodes participate in the consensus algorithm would impact system efficiency. Therefore, a small number (e.g., 64) of nodes can be selected as consensus nodes to form the consensus committee. The remaining nodes serve as alternate nodes. To ensure fairness and security, the consensus committee should be re-elected periodically. Otherwise, a fixed set of consensus nodes would be vulnerable to targeted attacks.

[0033] In one related technology, the master consensus node uses a verifiable random function (VRF) to generate a random number seed, triggering periodic rotation of consensus nodes in the blockchain based on this random number seed. In this scheme, the master consensus node generates the consensus proposal and the random number seed; therefore, the master consensus node may be able to predict or even influence the random value in advance, affecting fairness.

[0034] This specification provides a consensus node rotation scheme in its embodiments. Multiple nodes in the blockchain (including consensus nodes and / or candidate nodes) send a transaction to the blockchain invoking a contract (hereinafter referred to as Contract C1) to trigger consensus node rotation. When executing this transaction, the blockchain determines the consensus node to be rotated and the candidate node based on a random number seed jointly generated by multiple consensus nodes, according to the contract.

[0035] The following describes the scheme in the embodiments of this specification in which multiple consensus nodes jointly generate random number seeds.

[0036] This application provides a method for generating random number seeds on a blockchain, which can be implemented by combining the aforementioned PBFT three-stage process. For example... Figure 3 As shown, it includes:

[0037] S310: Each consensus node, based on the threshold signature algorithm, uses its own private key share to sign the original message containing the unique values ​​of the original transaction list in this consensus, generates a signature share, and broadcasts the signature share.

[0038] Specifically, each consensus node can generate a signature share during the commit phase of PBFT and add the signature share to the broadcast commit message for broadcasting.

[0039] Threshold signatures are an important branch of ordinary digital signatures, combining threshold secret sharing technology with digital signatures. Traditional signature schemes can be implemented using the RSA algorithm. RSA is an asymmetric encryption algorithm proposed in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman. RSA can decrypt without directly transmitting the key, ensuring information security while avoiding the risk of information being compromised by directly transmitting the key. RSA includes a private key and a public key, which are paired. Information encrypted with the public key can only be decrypted with the corresponding private key; similarly, information encrypted with the private key can only be decrypted with the corresponding public key. This property is due to the mathematical correlation between the paired private and public keys. For example, one underlying principle is based on number theory: finding two large prime numbers is relatively simple, but factoring their product is extremely difficult. Therefore, the product can be made public as the encryption key, thus ensuring security. Private keys are typically kept strictly confidential and cannot be disclosed, while public keys are public (and can be held by multiple people). Because private keys are kept strictly confidential by the holder, others cannot forge the signature of the private key holder without obtaining the private key.

[0040] The RSA signature mechanism guarantees the integrity of messages during transmission. For example, if node A needs to send a message to node B, and it may pass through several intermediate nodes, A can use the RSA signature mechanism to send the message along with its signature through these intermediate nodes to B. B's verification of the signature confirms that the received message was indeed sent by A and has not been tampered with during transmission. One RSA signature process is as follows:

[0041] b1: A generates a key pair (public key and private key). The private key is kept secret and kept confidential. The public key is public and can be obtained by anyone.

[0042] b2: A signs the hash value of the original message using its private key and then passes the original message and the signature result to B. As mentioned earlier, this transmission process may involve several intermediate nodes.

[0043] Hash algorithms, also known as hashing algorithms, map original content to a fixed-length sequence, called the hash value. Common hash algorithms include SHA256, SHA384, and SHA512. SHA256 results in 256 bits, representing 2^256 possible original content values. Similarly, SHA384 results in 384 bits, and SHA512 results in 512 bits. These hash algorithms are suitable for large amounts of original content, allowing the hash value to be much smaller than the original content. A good hash algorithm ensures that different original content values ​​have a high probability of mapping to different hash values. This mapping is random, meaning the correlation between hash values ​​obtained from different original content values ​​cannot be predicted; it is also inversely compatible, meaning the original content cannot be derived from the hash value.

[0044] The original message may be lengthy and large in size, making direct signature calculation using the private key time-consuming and computationally expensive. Therefore, a hash algorithm can be used to calculate a hash value from the original message. This hash value is short yet fully represents the original message. Then, the private key is used to encrypt this hash value, and the result is the signature.

[0045] b3: After receiving the message, B uses A's public key to verify the signature.

[0046] On one hand, B can use the same hash algorithm as A to calculate the hash value of the original message, denoted as hash1; on the other hand, B uses A's public key to decrypt the signature result and calculate hash2. If hash1 and hash2 are the same, it can be determined that the received original message was sent by A and has not been tampered with during transmission.

[0047] A threshold signature scheme first comprises one total public key and n public-private key pairs. Each public key in a public-private key pair is called a public key share, and each private key in a public-private key pair is called a private key share. Secondly, there exists a recovery function corresponding to this total public key and the n public-private key pairs. This recovery function can recover a complete signature from signature shares signed with at least a threshold number of different private key shares. The generated complete signature can also be verified for correctness using the single total public key. Signature shares fewer than the threshold number cannot be used to generate the complete signature.

[0048] In addition to the RSA-based threshold signature mechanism, other threshold signature mechanisms can be adopted, such as ECDSA (Elliptic Curve Digital Signature Algorithm), Schnorr (a knowledge proof mechanism based on the discrete logarithm problem), and BLS (Boneh-Lynn-Shacham Signature).

[0049] It's important to note that in threshold signatures used in blockchains, the number of private key shares can equal the number of consensus nodes, and the minimum number of signature shares required for the recovery function to generate a complete signature (i.e., the threshold number) can equal the quorum (e.g., 2f+1) in the PBFT algorithm. Conversely, the number of private keys can also differ from the number of consensus nodes, and the minimum number of signature shares required for the recovery function to generate a complete signature can also differ from the quorum in the PBFT algorithm. The following explanation uses the former as an example.

[0050] The single public key and n public-private key pairs can be generated by a centralized processor (dealer) and distributed to n blockchain consensus nodes. This is a centralized key distribution method. In this way, combined with the consensus algorithm, each blockchain consensus node can hold one of the n private key shares. Simultaneously, each blockchain consensus node can hold the same single public key. Alternatively, there is a decentralized key distribution method, where the dealer is eliminated, and the n consensus nodes negotiate to obtain n public-private key pairs and a single public key. Each consensus node still holds one of the n private key shares, and all consensus nodes hold the same single public key.

[0051] Using a threshold signature algorithm, each consensus node can use its own unique private key (e.g., in a blockchain network with four nodes using PBFT as the consensus algorithm, the private key shares held by nodes 0, 1, 2, and 3 using the threshold signature algorithm are sk0, sk1, sk2, and sk3 respectively, where the subscript numbers represent node numbers) to sign the original message containing the unique values ​​of the original transaction list in this consensus, thus obtaining the signature result. Here, the unique values ​​of the original transaction list can be used as the original message to be signed.

[0052] The unique values ​​of the original transaction list can include the original transaction list itself or its hash value. Generally, different transactions have different content, so different original transaction lists or their hash values ​​are usually different. Therefore, the original message can at least include the original transaction list or its hash value. The properties of the hash function are sufficient to distinguish the random number seeds generated after the consensus process for different blocks is completed.

[0053] Considering that a number is generated for the content of this consensus process, if the consensus is complete, the generated number can be used as the block number of the block corresponding to this consensus. Therefore, the block number (i.e., the identifier) ​​can also be used as content in the original message. Regardless of whether the original transaction list contained in the (N+1)th block is the same as the original transaction table contained in the Nth block, block generation is sequential, which can be reflected as the block number of the later block being the block number of the previous block + 1. Therefore, even if the original transaction list contained in the (N+1)th block is the same as the original transaction table contained in the Nth block, each node still obtains a different signature based on (original transaction list + block number) using its own private key. The master node still cannot match the signatures of other nodes, thus making it impossible to predict the complete signature of the (N+1)th block. Therefore, the master node cannot use the publicly available random number seed of the Nth block to predict the random number seed of the (N+1)th block, achieving the purpose of unpredictability. Similar to numbering, timestamps are also unique to a block, with the timestamp of a later block following that of the previous block. Therefore, timestamps can also be used as content within the original message.

[0054] In addition to the unique values ​​of the original transaction list, the signing object can also include other content, such as the random number seed generated in the previous block. That is, the original message can also include the random number seed generated in the previous block. After the aforementioned a140 is executed, as mentioned earlier, each node can generate the m-th block based on the consensus transaction data. Since the m-th block is generated independently by each node locally, if the blockchain nodes do not broadcast and compare the hash values ​​of their generated previous blocks, each node may not be able to determine whether the m-th blocks generated in the blockchain network are the same, or whether, from the perspective of the overall usability of the blockchain system, at least a quorum of consensus nodes have generated the same m-th block. Through the random number seed generation process in this application, the random number seeds of the same block should be the same, and the random number seeds of different blocks should be different. Therefore, the random number seed can be added to the original message. Thus, if the random number seeds generated by each node for the m-th block are different, due to the nature of the threshold signature algorithm, it may be impossible to obtain a complete signature through the recovery function method during the generation of the random number seed for the (m+1)-th block. Therefore, the scheme in this application can help consensus nodes confirm whether the previous block is consistent. Alternatively, the hash value of the previous block can be used instead of the random number seed. Since the hash value of a block is generally unique, this can also help consensus nodes confirm whether the previous block is consistent.

[0055] The original message containing unique values ​​from the original transaction list used in this consensus is signed using one's own private key share. These unique values ​​can be from the original transaction list itself. Generally, the original transaction list has already been broadcast during the PP phase of PBFT, and smaller commit messages broadcast during the C phase are more conducive to propagation and bandwidth saving. Therefore, the unique values ​​from the original transaction list can be the hash values ​​of the original transaction list.

[0056] If the original message contains multiple contents, such as the hash value of the original transaction list, the block number, and the random number seed generated in the previous block, the hash value of the original message can be calculated first, and then the hash value of the original message can be signed using the private key share to obtain the signature result.

[0057] The original message is signed, and the generated signature, along with the original message, can be added to the broadcast commit message. Thus, during the commit phase, each node participating in the consensus sends a commit message to the other consensus nodes and adds its own commit message to its local log (representing its own approval). Furthermore, each node also receives commit messages broadcast by other nodes.

[0058] S320: After each consensus node collects at least a threshold number of signature shares, it uses the recovery method corresponding to the private key share generated by the threshold signature algorithm to obtain a complete signature.

[0059] As mentioned earlier, in application, the threshold signature algorithm can generate one total public key and n public-private key pairs, and can also generate recovery functions corresponding to these n public-private key pairs. As previously mentioned, this recovery function can recover a complete signature from at least the threshold number of correctly verified signatures. The threshold value, i.e., the threshold number, can be set to w. Of course, even if there are more than w correct signatures, a complete signature can still be generated using this recovery function. In other words, whenever the number of correct signatures is greater than or equal to the threshold number w, a complete signature can be generated using this recovery function, and this generated complete signature is deterministic and will not change due to the number of correct signatures input (as long as it is greater than or equal to w).

[0060] The generated complete signature can be verified for correctness using the aforementioned master public key. Thus, any node or other device holding this master public key can use it to verify the correctness of the complete signature. For example, after node 1 generates the complete signature, it can use the master public key to verify its integrity. This involves performing cryptographic operations on the complete signature using the master public key to obtain a first hash, and then performing a hash operation on the original message to obtain a second hash. If the first hash matches the second hash, the integrity of the complete signature is confirmed. This integrity includes the fact that the complete signature is specific to the original message and that the original message has not been tampered with. As another example, after node 1 generates the complete signature, it can send the complete signature, the master public key, and the original message to a device outside the blockchain. This device can then use the master public key and the original message to verify the correctness of the complete signature, following the same principle. The original message here still contains the values ​​specific to the original transaction list in this consensus, or it may also include the block number and / or timestamp of the current block and / or the random number seed generated in the previous block.

[0061] Alternatively, each consensus node can collect each commit message, verify the signature share in the received commit message using the corresponding public key share, and then use the recovery function corresponding to the private key share generated by the threshold signature algorithm to obtain the complete signature. Compared to verifying the generated complete signature using the total public key, verifying each signature share using the public key share, and then restoring the complete signature using the recovery function after successful verification, can determine which signature is erroneous, thereby identifying which node might be a malicious node.

[0062] In the threshold signature algorithm, each consensus node has a total public key and one private key share and one corresponding public key share from n public-private key pairs. As mentioned earlier, these can be generated and distributed by the dealer or negotiated by the consensus nodes.

[0063] Each consensus node can verify the signature share in the received commit message using its corresponding public key share. Specifically, for example, in a consortium blockchain using the PBFT consensus algorithm with four consensus nodes, node 0 broadcasts its generated signature share σ to nodes 1, 2, and 3 in S310. 3,0 , where σ 3,0 The subscript 3 can represent the block number, and 0 can represent that this is the signature share of node 0; in S320, node 0 also receives the signature shares σ broadcast by nodes 1 and 2 respectively. 3,1 σ 3,2 Thus, node 0 has collected at least 3 signature shares, including the signature share σ broadcast by itself. 3,0 The signature share σ broadcast by nodes 1 and 2 3,1 σ 3,2 Of course, node 0 can also collect all the signature shares σ. 3,0 σ 3,1 σ 3,2 and σ 3,3 This also satisfies the minimum number of quorums.

[0064] Furthermore, node 0 can use the corresponding public key share to verify the collected σ. 3,0 σ 3,1 σ 3,2 Or may also include σ 3,3 (or σ) 3,0 σ 3,1 σ 3,3 Or may also include σ 3,2 Or σ 3,1 σ 3,2 σ 3,3 Or may also include σ 3,0 Or σ 3,0 σ 3,2 σ 3,3 Or may also include σ 3,1 The correctness of the signature share σ. Specifically, for example, node 0 can use the corresponding public key share to verify the signature share σ. 3,1 The calculation yields a hash value, which is denoted as hash. 3,1 Node 0 can also perform the same hash calculation on the original message to obtain hash′. 3,1 If hash 3,1 With hash′ 3,1If they are equal, it proves that the original message was sent by node 1 and was not tampered with during transmission. Thus, σ 3,1 The correctness of this has been verified. Similarly, node 0 can be related to σ. 3,2 Further verification will be conducted later, and will not be elaborated upon further.

[0065] Similarly, node 1 can use the corresponding public key share to verify the collected σ. 3,0 σ 3,1 σ 3,2 Or may also include σ 3,3 (or σ) 3,0 σ 3,1 σ 3,3 Or may also include σ 3,2 Or σ 3,1 σ 3,2 σ 3,3 Or may also include σ 3,0 Or σ 3,0 σ 3,2 σ 3,3 Or may also include σ 3,1 The correctness of ).

[0066] Similarly, node 2 can use the corresponding public key share to verify the collected σ. 3,0 σ 3,1 σ 3,2 Or may also include σ 3,3 (or σ) 3,0 σ 3,1 σ 3,3 Or may also include σ 3,2 Or σ 3,1 σ 3,2 σ 3,3 Or may also include σ 3,0 Or σ 3,0 σ 3,2 σ 3,3 Or may also include σ 3,1 The correctness of ).

[0067] Similarly, node 3 can use the corresponding public key share to verify the collected σ. 3,0 σ 3,1 σ 3,2 Or may also include σ 3,3 (or σ) 3,0 σ 3,1 σ 3,3 Or may also include σ 3,2 Or σ 3,1 σ 3,2 σ 3,3 Or may also include σ 3,0 Or σ 3,0 σ 3,2σ 3,3 Or may also include σ 3,1 The correctness of ).

[0068] S330: Each consensus node obtains a random number seed based on the complete signature.

[0069] A random number seed is the initial value used in a pseudo-random number generator to generate pseudo-random numbers. For a single pseudo-random number generator, starting from the same random number seed will yield the same sequence of random numbers. For a single machine, the random number seed can be determined by the current state of the computer, such as the current time. However, for a distributed system, the same random number seed must be generated on all nodes to ensure that the same random numbers are generated based on the same seed in system contracts / business contracts / blockchain platform functions, and that no single node should generate random numbers in a controllable, predictable, and reversible manner. This requires the seed to be jointly determined by the nodes participating in the consensus. Furthermore, considering that distributed networks are often asynchronous or semi-synchronous, for immediacy, random numbers need to be generated and used as soon as transactions in the current block are executed.

[0070] Following steps S310-S320 above, under normal circumstances, each consensus node can obtain the same complete signature. Of course, considering the fault tolerance characteristics of distributed systems, in a blockchain network using the PBFT consensus algorithm, there should be at least a quorum number of consensus nodes, each of which can obtain the same complete signature.

[0071] In this way, based on the complete signature, each consensus node can use the same random number seed generation algorithm to generate a random number seed. A relatively simple random number seed generation algorithm is, for example, the SHA256 algorithm. Of course, the complete signature can also be used directly as the random number seed.

[0072] Through the above process, a random number seed can be generated on the blockchain. After obtaining the random number seed, one or more consensus nodes can synchronize the random number seed to each candidate node. Specifically, the consensus node can include the random number seed in the consensus result and synchronize it to each candidate node. In one implementation, each consensus node sends the random number seed and its signature to each candidate node. Thus, after receiving multiple random number seeds and their signatures from multiple consensus nodes, each candidate node can determine that it has received the correct random number seed if the multiple random number seeds are consistent.

[0073] In this way, during the process of blockchain nodes outputting consensus results after completing the current consensus process—that is, during the execution of a series of transactions with determined content and order—if the code includes smart contracts / system contracts / blockchain platform code that require the use of random numbers, it can be executed based on the S330 random number seed. For example, in smart contracts written in C++, the `mt19937(r)` method provided by the C++ standard library or the Boost library can be used to construct a cross-platform consistent random number engine, where the parameter `r` is the random number seed. Similarly, the `random` library in Python and Java also provides similar random number generation methods. Based on the same random number seed, the same random number generation algorithm can generate the same random numbers. Thus, for example, when each blockchain node executes the same transaction in the same block, the same random number generation process can generate the same random numbers based on the same random number seed, thereby completing the business logic or platform function and obtaining consistent execution results on each node.

[0074] The scheme provided in this application combines the threshold signature algorithm with the PBFT consensus algorithm, making it impossible for any consensus node to predict the complete signature before consensus is achieved. Even the PBFT master node cannot predict the complete signature, and therefore cannot predict the random number seed and random number. In particular, when the threshold is quorum, once consensus is achieved, since the quorum number of nodes have reached a consensus on the content and order of the transaction list, that is, the basic content for generating a new block has been determined, at least the quorum number of nodes will obtain the same complete signature according to the recovery function. The random number seed generated by these quorum number of nodes will also necessarily be the same. Even if no more than f nodes act maliciously and try to control or revoke the obtained random number seed, these f nodes will not affect the consistency of the system. That is, these f nodes cannot manipulate or revoke the generated complete signature, random number seed, and random number.

[0075] In the embodiments described in this specification, the contract C1 used for consensus node rotation defines parameters such as `rotate_enabled`, `rotate_interval`, and `last_rotate_block`. The `rotate_enabled` parameter is a boolean value indicating whether the rotation function is enabled. When the number of consensus nodes in the blockchain is greater than or equal to the preset maximum number of consensus nodes, the value of `rotate_enabled` can be updated to `true` by sending a transaction to the blockchain calling contract C1 through an external account with management permissions, indicating that the rotation function is enabled. The `rotate_interval` parameter represents the period of random rotation, in units of blocks. `last_rotate_block` represents the latest block number where random rotation has occurred. Each consensus node, upon completing the execution of a block and starting the processing of the next block, can check whether `rotate_enabled` is `true` and whether the current block number is greater than or equal to `last_rotate_block + rotate_interval`. If both conditions are met, it indicates that consensus node rotation may occur in the current block, thus enabling the rotation of consensus nodes. Figure 3 The method flow is shown. If the check determines that either of the two conditions is not met, the consensus node will not proceed. Figure 3 The method flow is shown below. In one implementation, when each consensus node begins processing the next block (e.g., block B1), it can determine whether the consensus proposal for block B1 includes a transaction for random rotation of consensus nodes. If so, it checks whether rotate_enabled is true and whether the current block number is greater than or equal to last_rotate_block + rotate_interval. If both conditions are met, it proceeds as follows: Figure 3 The method flow is shown.

[0076] Figure 4 This is a flowchart illustrating the method for initiating consensus node rotation in the embodiments of this specification. This method can be executed by multiple candidate nodes in the blockchain, or by multiple consensus nodes, or by multiple candidate nodes and multiple consensus nodes together. Taking multiple candidate nodes as an example, each candidate node can execute the following... Figure 4 The method shown ensures the correct operation of the random rotation function. The following description uses a candidate node as an example. Figure 4 The method shown.

[0077] like Figure 4 As shown, firstly, in step S410, the blockchain node determines whether the current block needs to undergo consensus node rotation.

[0078] Each candidate node can begin execution after each block has been completed, such as... Figure 4 The method is as follows. The candidate node first queries the `rotate_enabled` parameter in contract C1 to determine if its value is true. If `rotate_enabled` is true, the candidate node also checks if the current block number is greater than or equal to `last_rotate_block + rotate_interval`. If the current block number is greater than or equal to `last_rotate_block + rotate_interval`, it determines that the current block requires consensus node rotation. Under normal circumstances, if the candidate node determines that the current block number equals `last_rotate_block + rotate_interval`, it determines that consensus node rotation is necessary and sends the corresponding transaction. In some cases, assuming the block number of block i is equal to last_rotate_block + rotate_interval, due to the lag in transaction execution, the transaction sent by the candidate node for consensus node rotation is not packaged into block i. Therefore, the transaction is not executed in block i, nor is the value of last_rotate_block updated. As a result, after block i is completed, the candidate node checks that the current block number i+1 is greater than last_rotate_block + rotate_interval, so the candidate node will still send the transaction for consensus node rotation.

[0079] In step S420, if a candidate node determines that a consensus node rotation is necessary, it sends transaction Tx1 to the blockchain for the purpose of the rotation. If a candidate node determines that a consensus node rotation is not necessary, it does not send a transaction to the blockchain for the purpose of the rotation.

[0080] After determining that a consensus node rotation is needed for the current block, the candidate node generates transaction Tx1. Transaction Tx1 invokes contract C1 to trigger the consensus node rotation process within the blockchain. The candidate node then sends transaction Tx1 to the blockchain. Specifically, the candidate node can send transaction Tx1 to the primary consensus node, which then generates a consensus proposal and broadcasts it to the blockchain, allowing all nodes to perform the consensus node rotation by executing transaction Tx1.

[0081] In this scheme, each candidate node executes, for example, Figure 4 The process shown involves sending transactions (including transaction Tx1) to the blockchain for consensus node rotation, thereby ensuring the correct operation of the consensus node rotation process.

[0082] Figure 5 This is a flowchart illustrating another embodiment of the method for initiating consensus node rotation in this specification. This method can be executed by each consensus node in the blockchain.

[0083] like Figure 5 As shown, in step S510, the consensus node determines whether the current block needs to undergo consensus node rotation.

[0084] This step can be referred to in the description of step S410 above, and will not be repeated here.

[0085] In step S520, if a consensus node determines that a consensus node rotation is required for this block, it inserts transaction Tx2 into the transaction list of the consensus completion result for use in the consensus node rotation. If a consensus node determines that a consensus node rotation is not required for this block, it does not insert a transaction for consensus node rotation into the transaction list.

[0086] After determining that a consensus node rotation is necessary, each consensus node does not send a transaction to the blockchain for consensus. Instead, it directly inserts a transaction Tx2 for the consensus node rotation into the consensus result. For example, transaction Tx2 can be inserted at the end of the transaction list in the consensus proposal. This avoids a large number of nodes sending transactions simultaneously when the rotation period arrives, preventing the blockchain from broadcasting and processing multiple transactions. Furthermore, this scheme requires each consensus node to run the same logic; otherwise, different results will be produced, leading to a chain fork.

[0087] The following text uses transaction Tx1 as an example to describe the process of consensus node rotation in a blockchain. It can be understood that nodes in the blockchain can similarly perform the consensus node rotation process by executing transaction Tx2.

[0088] Figure 6 This is a flowchart of the consensus node rotation method in the embodiments of this specification. After consensus is reached on a consensus proposal in the blockchain, each node in the blockchain (including the consensus node and candidate nodes) will execute multiple transactions in the consensus proposal according to the consensus proposal. Assume that these multiple transactions include the aforementioned transaction Tx1. As described above, the consensus node in the blockchain has pre-determined the random number seed corresponding to the block (e.g., block B1) corresponding to the consensus proposal during the consensus process, and synchronizes the random number seed to each candidate node in the blockchain. Therefore, each node in the blockchain can execute transaction Tx1 according to the random number seed.

[0089] like Figure 6As shown, firstly, in step S610, the blockchain node obtains transaction Tx1, and transaction Tx1 calls contract C1.

[0090] After a consensus is reached, each blockchain node can obtain multiple transactions (including the aforementioned transaction Tx1) from the consensus proposal and execute these transactions in the order they are arranged in the consensus proposal.

[0091] In step S620, the blockchain node determines whether the current block needs to undergo consensus node rotation.

[0092] The determination process can be referred to the description of step S410 above, and will not be repeated here. If the determination result is negative, the execution of transaction Tx1 is terminated and the transaction execution failure is recorded. If the determination result is positive, the execution of transaction Tx1 continues.

[0093] When executing transaction Tx1, each blockchain node also checks the above two conditions to verify whether the current block needs consensus node rotation, thereby preventing malicious nodes from deliberately sending consensus node rotation requests frequently.

[0094] Furthermore, as mentioned above, multiple candidate nodes simultaneously send transactions for consensus node rotation to the blockchain after confirming that both conditions are met. By checking the above two conditions separately when executing these multiple transactions for consensus node rotation, only the first transaction executed among them can be successfully executed. After the first transaction is successfully executed, the parameter last_rotate_block in the contract is updated to the block number of the current block. Therefore, when a node executes a subsequent transaction for consensus node rotation (e.g., transaction Tx3), the result obtained from step S620 will be negative, meaning that transaction Tx3 will be terminated.

[0095] In step S630, if the determination result in step S620 is yes, the blockchain node obtains a random number seed according to contract C1.

[0096] If the above-mentioned result is confirmed to be yes, the blockchain node begins executing contract C1 called in transaction Tx1. According to contract C1, the blockchain node first obtains... Figure 3 The process shown obtains a random number seed. Wherein, if the blockchain node is a consensus node, the consensus node executes... Figure 3Following the process shown, the random number seed can be generated and stored locally. The consensus node can then read the stored random number seed from its local machine according to the instructions in contract C1. If the blockchain node is a candidate node, it can receive the random number seed synchronously from the consensus node. For example, the consensus node can include the random number seed in the consensus result and synchronize it to the candidate node. The candidate node can store the consensus result, and then retrieve the random number seed from the consensus result according to the instructions in contract C1.

[0097] Step S640: The blockchain node determines the consensus node to be rotated and the candidate node based on the random number seed.

[0098] The first step for blockchain nodes is to determine the number of consensus nodes and candidate nodes that need to be rotated.

[0099] Specifically, contract C1 also defines the parameter `rotate_node_number`, which indicates the maximum number of candidate nodes allowed to rotate in each preset rotation. The blockchain node can also obtain the current number of candidate nodes and determine the minimum value between `rotate_node_number` and the current number of candidate nodes as the number `a` of candidate nodes to be rotated as consensus nodes. In one implementation, for example, contract C1 is a node governance contract, which includes a parameter for recording the current number of candidate nodes. Thus, the blockchain node can obtain the current number of candidate nodes from the contract state of contract C1. In another implementation, the node governance contract is contract C2, which can be called from contract C1 to obtain the current number of candidate nodes from its contract state.

[0100] Contract C1 also predefines the parameter `consensus_max_number`, which indicates the maximum preset number of consensus nodes. The blockchain node also obtains the current number of consensus nodes, `n`. If `n+a` > `consensus_max_number`, then the number of consensus nodes to be rotated as candidate nodes is determined to be `n+a - `consensus_max_number`.

[0101] For example, if the blockchain currently includes n = 80 consensus nodes and 100 candidate nodes, with parameters consensus_max_number = 100 and rotate_node_number = 30, then according to the above calculations, 30 candidate nodes need to be selected from the 100 candidate nodes to be rotated into consensus nodes, and 80 + 30 - 100 = 10 consensus nodes need to be selected from the current consensus nodes to be rotated into candidate nodes.

[0102] Afterwards, blockchain nodes can be based on... Figure 3The method shown generates a random number seed, which is used to generate a random sequence according to a preset random number algorithm. This generated random sequence, for example, includes 30 natural numbers from 1 to 100, allowing 30 candidate nodes to be selected from 100 candidate nodes for rotation. Similarly, blockchain nodes can generate a random sequence based on the random number seed, which includes 10 natural numbers from 1 to 80, allowing 10 consensus nodes to be selected from 80 consensus nodes for rotation.

[0103] When each blockchain node executes the same transaction in the same block, the same random number generation process can generate the same random number based on the same random number seed, so that each blockchain node can get the same execution result.

[0104] In addition, since the random number seed is jointly determined by multiple consensus nodes when processing the current block, each blockchain node can only obtain the random number and determine the node to be rotated when executing a transaction. Therefore, no node can predict or intervene in the rotation of consensus nodes in advance.

[0105] In step S650, the blockchain node stores updated information about consensus nodes and candidate nodes in the blockchain.

[0106] After successfully executing transaction Tx1, the blockchain node generates an updated list of node identifiers for the consensus nodes and candidate nodes based on the previously determined list of nodes to be rotated, and stores this updated list in the blockchain. For example, the blockchain node can store this updated list of node identifiers in the form of a transaction receipt within a block. Alternatively, the blockchain node can store this updated list of node identifiers in the contract state of contract C1.

[0107] Additionally, the blockchain node updates the value of the parameter `last_rotate_block` in contract C1 to the block number of the current block (block B1). This is used to indicate the timing of the next consensus node rotation.

[0108] Each node in a blockchain can make operational changes based on the updated list of consensus nodes and candidate nodes stored in the blockchain. For example, if the original consensus node n1 becomes a candidate node, node n1 will no longer participate in the consensus process, but only in the transaction execution process. If the original candidate node n2 becomes a consensus node, then node n2 will participate as a consensus node in the consensus process for the next block after block B1 is completed.

[0109] Figure 7This is an architecture diagram of a blockchain node according to an embodiment of this specification. The blockchain node includes a consensus node and candidate nodes for rotating as the consensus node. The blockchain node includes:

[0110] The acquisition unit 71 is used to acquire the first transaction, which calls the first contract for consensus node rotation; and to acquire the random number seed corresponding to the current first block, which is jointly generated by multiple current consensus nodes, according to the first contract.

[0111] The determining unit 72 is used to determine the node to be rotated among the consensus node and the candidate node based on the random number seed;

[0112] Storage unit 73 is used to store updated consensus node information and candidate node information in the blockchain based on the determined node information to be rotated.

[0113] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform actions such as... Figures 3-6 The method shown in any of the accompanying figures.

[0114] This specification also provides a blockchain node, including a memory and a processor. The memory stores executable code, and when the processor executes the executable code, it implements... Figures 3-6 The method shown in any of the accompanying figures.

[0115] In the scheme provided in the embodiments of this specification, a transaction invoking a contract is sent to the blockchain by multiple nodes (which may include consensus nodes and / or candidate nodes) to trigger consensus node rotation. When executing this transaction, the blockchain determines the consensus node to be rotated and the candidate node based on a random number seed jointly generated by multiple consensus nodes, according to the contract. This prevents the primary consensus node from predicting or interfering with the generation of random numbers, avoiding affecting the fairness of the blockchain and ensuring the correct operation of consensus node rotation.

[0116] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, 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, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0117] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0118] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0119] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0120] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0121] This 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 block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0122] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0123] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

[0125] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0126] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, 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), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0127] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0128] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0129] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0130] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A consensus node rotation method in a blockchain, wherein the blockchain nodes include consensus nodes and candidate nodes for rotation as consensus nodes, the method being executed by the blockchain nodes, comprising: Obtain the first transaction, which calls the first contract to perform consensus node rotation; According to the first contract, during the execution of the first transaction, a random number seed generated by multiple consensus nodes during the consensus process for the current first block is obtained; The nodes to be rotated among the consensus nodes and candidate nodes are determined based on the random number seed; Based on the determined node information to be rotated, the updated consensus node information and candidate node information are stored in the blockchain.

2. The method according to claim 1, wherein the blockchain stores the value of a first parameter and the value of a second parameter, the first parameter indicating the identifier of the latest block in which consensus node rotation has occurred, and the second parameter indicating the cycle of consensus node rotation in the blockchain, the method further comprising: After the second block is completed, each candidate node determines whether to send a second transaction based on the first parameter and the second parameter. The second transaction is used for consensus node rotation. The first transaction is included in the multiple second transactions sent by multiple candidate nodes. The second block is the block preceding the first block.

3. The method according to claim 2, further comprising: After the execution of the first transaction begins, it is determined whether the execution of the first transaction needs to be terminated based on the first parameter and the second parameter; According to the first contract, during the execution of the first transaction, obtaining a random number seed jointly generated by multiple consensus nodes during the consensus process for the current first block includes, in the case that it is determined that the first transaction does not need to be terminated, obtaining a random number seed jointly generated by multiple consensus nodes during the execution of the first transaction according to the first contract.

4. The method according to claim 3, further comprising: After the first transaction is successfully executed, the value of the first parameter is updated in the blockchain to the identifier of the first block.

5. The method according to claim 4, further comprising: After the value of the first parameter is updated to the identifier of the first block, when executing the third transaction among the plurality of second transactions, if it is determined that the current block number is less than the sum of the first parameter and the second parameter, the execution of the third transaction is terminated.

6. The method according to claim 1 or 2, wherein the blockchain further stores a third parameter, a fourth parameter, and a fifth parameter, wherein the third parameter is used to indicate a preset maximum number of candidate nodes that can participate in the rotation, the fourth parameter is used to indicate the current number of candidate nodes, and the fifth parameter is used to indicate a preset maximum number of consensus nodes, and the method further includes: The first number of candidate nodes to be rotated is determined based on the third and fourth parameters; Based on the first number of candidate nodes to be rotated and the fifth parameter, the second number of consensus nodes to be rotated is determined.

7. The method according to claim 6, wherein determining the node to be rotated among the consensus node and candidate nodes based on the random number seed comprises: Based on the random number seed, the first number of random sequences are generated, and the first number of candidate nodes to be rotated are selected from the current multiple candidate nodes according to the random sequences.

8. The method according to claim 2, further comprising: Each consensus node, based on the threshold signature algorithm, uses its own private key share to sign the data corresponding to the current block, generates a signature share, and broadcasts the signature share. After each consensus node collects at least a threshold number of signature shares, it uses the recovery function corresponding to the private key share generated by the threshold signature algorithm to obtain a complete signature. Each consensus node obtains a random number seed based on the complete signature; One or more consensus nodes synchronize the random number seed to each candidate node.

9. The method according to claim 8, further comprising: After the second block is completed, each consensus node determines whether to generate a random number seed based on the first and second parameters. The generation of signature shares by each consensus node includes: when it is determined that a random number seed needs to be generated, each consensus node generates a signature share.

10. A blockchain node, comprising a consensus node and candidate nodes for rotating as the consensus node, the blockchain node comprising: The acquisition unit is used to acquire the first transaction, which calls the first contract for consensus node rotation. According to the first contract, during the execution of the first transaction, a random number seed generated by multiple consensus nodes during the consensus process for the current first block is obtained; The determining unit is used to determine the nodes to be rotated among the consensus nodes and candidate nodes based on the random number seed; The storage unit is used to store updated consensus node information and candidate node information in the blockchain based on the determined node information to be rotated.

11. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 1-9.

12. A blockchain node comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-9.

Images