Transaction sending method in blockchain and blockchain node

Abstract

A transaction sending method in a blockchain and a blockchain node, the method comprising: obtaining first data currently stored in the blockchain when a first block in the blockchain is executed; generating a first transaction when it is determined that the first data meets a preset condition; and sending the first transaction to the blockchain.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a transaction sending method and a blockchain node 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 transaction sending method in a blockchain, enabling blockchain nodes to automatically send transactions triggered by data in the blockchain.

[0004] The first aspect of this specification provides a transaction sending method in a blockchain, executed by the first node in the blockchain, including:

[0005] When the first block in the blockchain is completed, retrieve the first data currently stored in the blockchain;

[0006] When the first data is determined to meet the preset conditions, a first transaction is generated;

[0007] Send the first transaction to the blockchain.

[0008] The second aspect of this specification provides a blockchain node, including:

[0009] The acquisition unit is used to acquire the first data currently stored in the blockchain when the first block in the blockchain is completed.

[0010] The generation unit is used to generate a first transaction when it is determined that the first data meets preset conditions;

[0011] A sending unit is used to send the first transaction to the blockchain.

[0012] 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.

[0013] 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.

[0014] In the solutions provided in the embodiments of this specification, transactions are automatically sent by the nodes triggered by data in the blockchain, without the need to create or authorize external accounts to send transactions to the blockchain through devices other than the nodes for system settings. This improves the efficiency of the blockchain system and saves on the hardware and storage costs of the blockchain system. Attached Figure Description

[0015] 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.

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

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

[0018] Figure 3 This is a flowchart of a transaction sending method in a blockchain according to an embodiment of this specification;

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

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

[0021] Figure 6 This is a flowchart illustrating a method for implementing distributed key generation on a blockchain, as described in one of the embodiments of this specification.

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

[0023] 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.

[0024] Figure 1 A blockchain architecture diagram from one embodiment is shown. Figure 1In 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.

[0025] 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.

[0026] 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.

[0027] 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 1 In 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.

[0028] In scenarios where contracts are invoked, for example, Bob sends a transaction to invoke a smart contract, such as... Figure 1In 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.

[0029] 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.

[0030] 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 and send the consensus proposal, along with its signature, to other consensus nodes (i.e., nodes n2 to n4) for block generation. The consensus proposal may include information such as the transaction bodies and the submission order of the transactions. In the Prepare phase, each slave node can sign the consensus proposal and send it to the other nodes. Assuming node n4 is a malicious node, after nodes n1, n2, and n3 receive signatures of the consensus proposal from 2f = 2 other consensus nodes, they can determine that the preparation phase is complete and can 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 it 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.

[0031] In blockchain, it's often necessary to trigger certain transactions based on the chain state. For example, after enabling random rotation of consensus nodes, a transaction needs to be sent to the blockchain at regular block intervals to initiate a request to change the consensus node. Another example is in Distributed Key Generation (DKG). The first node, responding to a contract (such as a DKG contract), receives the public verification vector from the second node. After the first node successfully verifies the second node's public verification vector and secret share, it needs to send a transaction to the blockchain to transmit the first node's confirmation information to the contract.

[0032] In related technologies, system operations are typically completed by manually sending system transactions through external accounts on the blockchain. To automatically trigger transactions based on the chain state, a client independent of the chain node is needed to send and receive transaction responses. Alternatively, external accounts can invoke a corresponding working contract to send system transactions; however, this working contract cannot persistently listen for events and can only trigger the next step of the transaction process through transactions.

[0033] Therefore, in the embodiments of this specification, the node actively sends a transaction to the blockchain based on the data currently stored in the blockchain, thereby utilizing the node's inherent ability to listen to on-chain data and conveniently initiate transactions.

[0034] Figure 3 This is a flowchart illustrating a transaction sending method in a blockchain, as described in the embodiments of this specification, executed by a blockchain node. Hereinafter, node 1 will be used as the execution node. Figure 3 The method shown is described using an example.

[0035] like Figure 3 As shown in S310, when node 1 completes the execution of a block in the blockchain, it obtains the data currently stored in the blockchain.

[0036] In blockchain nodes, state data and block data are typically updated in units of blocks. The completion of storing the state data and block data corresponding to a block signifies the completion of a block's execution. Therefore, the blockchain platform code of a node (hereinafter referred to as the platform code) can be pre-programmed to retrieve the updated stored data (including state data and block data) from the blockchain upon completion of each block, and determine whether to send a transaction to the blockchain based on this updated stored data.

[0037] The data refers to the data that needs to be read pre-set in the platform code of the blockchain node. This data can be the state value of a specific variable in a specific contract, data from transaction receipts of multiple transactions in a block, or data included in the multiple transactions themselves in the block; there are no limitations on this. Specifically, when the data is the state value of a variable in a contract, the node can read the state value of a specific variable in a specific contract from the state database according to the contract address and variable name preset in the node's platform code. When the data is data from transaction receipts, the node can obtain the event of that specific topic from the receipts of multiple transactions in the block according to the event topic preset in the platform code. When the data is data included in the multiple transactions themselves in the block, the node can read the corresponding transaction from multiple transactions according to transaction information such as the transaction type preset in the platform code.

[0038] In S320, when the node determines that the data meets preset conditions, it generates a transaction.

[0039] The platform code of a node can be pre-defined with preset conditions for judging data. After obtaining the data, node 1 determines whether the data meets these preset conditions. If the conditions are met, a transaction corresponding to the data is generated according to the settings in the platform code. This transaction typically calls a contract (usually a system contract), allowing for the configuration of the blockchain system based on the code within that contract.

[0040] A blockchain can include various types of nodes. For example, in a scenario where consensus nodes rotate in a blockchain, the blockchain can include consensus nodes, candidate nodes, and non-consensus nodes. Consensus nodes are nodes that participate in the consensus process, candidate nodes are nodes waiting to be rotated into consensus nodes, and non-consensus nodes are nodes that do not participate in the consensus process and will not be rotated into consensus nodes.

[0041] A node in the blockchain (e.g., node 1), based on its corresponding platform code, can read the block number (e.g., M) of the most recent consensus node rotation and the preset rotation interval (in blocks, e.g., m) from the contract state of the contract used for consensus node rotation (e.g., contract C1) after each block execution is complete. When it is determined that the current block number N is equal to or greater than M+m, a transaction (e.g., transaction Tx1) is generated to enable consensus node rotation in the blockchain. Transaction Tx1 can call contract C1 for consensus node rotation. After executing transaction Tx1, the node in the blockchain determines the consensus node to be rotated as a candidate node and the candidate node to be rotated as a consensus node, and also modifies the most recent block number of consensus node rotation in the contract, that is, updates M to N.

[0042] In this transaction, the sender (i.e., the `from` field) of Tx1 is the identifier of node 1, which could be, for example, the hash value of node 1's node ID. Node 1 also signs Tx1 using its own private key, obtaining a signature for Tx1, which is then sent to the blockchain along with Tx1. To avoid interfering with the processing logic of ordinary transactions, Tx1 also includes a transaction type field, whose value is, for example, "inner_call_contract_tx". This type indicates that the transaction was sent by the node itself.

[0043] Consensus nodes in the blockchain can also read the block number of the most recent DKG (e.g., M) and the preset DKG interval (in blocks, e.g., m) from the DKG contract state after each block execution is complete. When it is determined that the current block number N is equal to or greater than M+m, a transaction for DKG (e.g., transaction Tx2) is generated to enable DKG in the blockchain. Specifically, the execution of the DKG contract stores the public verification vector provided by the node in the receipt of transaction Tx2. This public verification vector is used to verify the secret share provided by the node. After executing transaction Tx2, a node in the blockchain can record an event of a preset topic (e.g., topic 1) in the receipt of transaction Tx2. This preset topic indicates that the event includes the public verification vector uploaded to the DKG contract by a certain node (e.g., node 2) during the DKG process.

[0044] In a blockchain, nodes can also determine whether an event for a predefined topic is included in the receipts of all transactions within each block after the block's execution is complete. Based on the triggering of this predefined topic's event, nodes send transactions to the blockchain. For example, in the DKG process, assuming node 1 is the consensus node, after block execution, node 1 reads the event for topic 1 from the block's receipt. Therefore, node 1 obtains node 2's public verification vector from this event. After verifying the secret share provided by node 2 using this public verification vector, node 1 generates a transaction (e.g., transaction Tx3) to confirm node 2's actions by uploading it to the DKG contract. After executing transaction Tx3, each node in the blockchain records node 1's confirmation of node 2 in the DKG contract for use in generating distributed keys.

[0045] In blockchain scenarios involving both consensus node rotation and Data KG (DKG) processes, a candidate node, even after being rotated into a consensus node, cannot participate in consensus without a distributed key. Therefore, consensus nodes can be further divided into consensus nodes and nodes about to be replaced, and candidate nodes into candidate nodes and those about to be replaced. When each consensus node, through the execution of transaction Tx1, identifies node 3 as about to be rotated from a consensus node to a candidate node and node 4 as about to be rotated from a candidate node to a consensus node, node 3 can identify itself as the consensus node about to be replaced, and node 4 can identify itself as the candidate node about to be replaced. Nodes 3 and 4 can select the platform code to execute based on their node roles to read data from the blockchain according to the corresponding platform code and generate transactions when the data meets preset conditions. Specifically, the consensus node about to be replaced can participate in consensus but does not participate in the DKG process, while the candidate node about to be replaced can participate in the DKG process but does not participate in consensus. Once the DKG process in the blockchain is complete, that is, after the DKG contract stores the DKG completion event in the blockchain, node 3 can determine itself as a candidate node, that is, execute the platform code corresponding to the candidate node, and node 4 can determine itself as a consensus node, that is, execute the platform code corresponding to the consensus node.

[0046] In step S330, the node sends the transaction to the blockchain.

[0047] Taking node 1 as an example, after generating transaction Tx1 and its signature, node 1 can send transaction Tx1 and its signature to the blockchain. Upon receiving transaction Tx1 and its signature, each node in the blockchain determines that the `from` field in transaction Tx1 is the identifier of node 1 based on the transaction type "inner_call_contract_tx", and then obtains the pre-stored public key of node 1 to verify the signature. Specifically, after the pre-execution or execution service in the node determines that transaction Tx1 was sent by node 1 based on the transaction type, it constructs a mapping relationship (auth_map) between the node ID (the identifier of node 1) and the public key of node 1, and verifies the signature of transaction Tx1 based on the auth_map.

[0048] After successful consensus on transaction Tx1 in the blockchain, each node executes transaction Tx1. During the execution of transaction Tx1, each node, based on the transaction type "inner_call_contract_tx" of transaction Tx1, will not store the state corresponding to the node 1 identifier in the from field in the state database.

[0049] Furthermore, after executing transaction Tx1 in the blockchain, the completion of the consensus node rotation can be recorded in the receipt of transaction Tx1, or information indicating the completion of the consensus node rotation can be recorded in the contract state of contract C1. Each consensus node in the blockchain sends a transaction for consensus node rotation to the blockchain when it determines that the current block number N is equal to or greater than M+m. These transactions include, for example, transaction Tx4, which is executed after transaction Tx1. When a node in the blockchain executes transaction Tx4, it terminates the execution of transaction Tx4 based on the consensus node rotation completion information recorded in the receipt of transaction Tx1. In other words, contract C1 can only accept the first successfully arriving transaction for consensus node rotation; subsequent transactions for consensus node rotation will fail.

[0050] The following sections will use two examples—consensus node rotation and DKG—to describe the transaction sending scheme implemented in this specification.

[0051] 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.

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

[0053] 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 parameter rotate_enabled 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 parameter rotate_interval represents the period of random rotation, in units of blocks, and last_rotate_block represents the latest block number where random rotation occurred.

[0054] 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`, then it is determined that the current block needs consensus node rotation. It can be understood that, typically, the candidate node determines the current block number is equal to...

[0055] When `last_rotate_block + rotate_interval`, it is determined that consensus node rotation is necessary, and the corresponding transaction is sent. 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, and the value of `last_rotate_block` is not updated. Thus, after block i is completed, the candidate node checks that the current block number `i+1` is greater than `last_rotate_block + rotate_interval`, and therefore the candidate node will still send the transaction for consensus node rotation.

[0056] 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.

[0057] 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. As mentioned above, the `from` field in transaction Tx1 is the candidate node's identifier, and transaction Tx1 includes a `transaction type` field indicating that it was sent by a node. 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 nodes to perform consensus node rotation by executing transaction Tx1.

[0058] 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.

[0059] Figure 5 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 consensus nodes and candidate nodes) will execute multiple transactions in the consensus proposal according to the proposal. Assume that these multiple transactions include the aforementioned transaction Tx1. During the consensus process, the consensus node in the blockchain can pre-determine the random number seed corresponding to block B1 (e.g., block B1) and synchronize this random number seed to each candidate node in the blockchain. Therefore, each node in the blockchain can execute transaction Tx1 according to this random number seed.

[0060] like Figure 5 As shown, firstly, in step S510, the blockchain node obtains transaction Tx1, and transaction Tx1 calls contract C1.

[0061] 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.

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

[0063] 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.

[0064] 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.

[0065] 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 S520 will be negative, meaning that transaction Tx3 will be terminated.

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

[0067] 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 3 Following 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.

[0068] In step S540, the blockchain node determines the consensus node to be rotated and the candidate node based on the random number seed.

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

[0070] 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.

[0071] 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`.

[0072] For example, a blockchain currently includes n=80 consensus nodes and 100 candidate nodes, parameters

[0073] With consensus_max_number = 100 and parameter rotate_node_number = 30, based on the above calculations, 30 candidate nodes need to be selected from the 100 candidate nodes for rotation as consensus nodes, and 80 + 30 - 100 = 10 consensus nodes need to be selected from the current consensus nodes for rotation as candidate nodes.

[0074] Afterwards, blockchain nodes can be based on... Figure 3 The 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.

[0075] 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.

[0076] 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.

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

[0078] 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.

[0079] 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.

[0080] 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.

[0081] Figure 6 This is a flowchart illustrating a method for implementing distributed key generation on a blockchain, as described in an embodiment of this specification. This method can be executed by multiple nodes in the blockchain, including:

[0082] S610: Each consensus node generates a unique set of n secret shares, keeps one for itself, and encrypts and sends the n-1 secret shares to the other n-1 nodes respectively.

[0083] In the DKG algorithm, nodes are renumbered, starting from 1. To maintain consistency with the DKG algorithm, consensus nodes will also be numbered starting from 1.

[0084] Elliptic Curve Cryptography (ECC) is a public-key encryption technique based on elliptic curve theory. It leverages the discrete logarithmic difficulty of the Abelian group formed by points on an elliptic curve over a finite field to achieve encryption, decryption, and digital signatures. The following explanation uses an elliptic curve as an example. Each node can be found in the group Z... q A polynomial of degree t is randomly selected. The Nth degree polynomial function is uniquely determined by N+1 points, because ultimately quorum consensus nodes in the blockchain network are needed to recover the signature; therefore, quorum = N+1, and the degree t of the polynomial is quorum-1. In this way, a complete signature can be recovered from quorum (quorum = t+1) signature shares using the recovery function. Of course, t can also be set to other values. The elliptic curve constructed using this polynomial can be represented as follows:

[0085] f i (z)=a i0 +a i1 z+a i2 z 2 +…+a it z t Formula (1)

[0086] In formula (1), a i0 a i1 a i2 a i3 , ..., a it These are the coefficients of a polynomial, and a polynomial can be determined by this set of coefficients.

[0087] When the number of consensus nodes n in the blockchain network is set to 4, and the quorum for algorithms such as PBFT and HBBFT is 3, then t = 2. In this case, the polynomial is:

[0088] f i (z)=a i0 +a i1 z+a i2 z 2 Formula (2)

[0089] Node 1 can randomly select a set of numbers from a finite prime field as coefficients, i.e., as a. 10 a 11 a 12 The generated polynomial is: f1(z) = a 10 +a 11 z+a 12 z 2 .

[0090] Similarly, node 2 can randomly select a set of numbers from the same finite prime field as coefficients, i.e., as a. 20 a 21 a 22 The generated polynomial is: f2(z) = a 20 +a 21 z+a 22 z 2 .

[0091] Similarly, node 3 can randomly select a set of numbers from the same finite prime field as coefficients, i.e., as a. 30 a 31 a 32 The generated polynomial is: f3(z) = a 30 +a 31 z+a 32 z 2 .

[0092] Similarly, node 4 can randomly select a set of numbers from the same finite prime field as coefficients, i.e., as a. 40 a 41 a 42 The generated polynomial is: f4(z) = a 40 +a 41 z+a 42 z 2 .

[0093] Each node, based on a defined polynomial, can further determine a set of secret shares. The secret shares can be determined from the polynomial coefficients using the following formula:

[0094] s ij =f i (j) mod q (j=1,…,n) Formula (3)

[0095] In formula (3), q is the same large number used by each node for f. i (j) The purpose of using q as the modulus is to make f i The value of (j) is limited to the range [0, q-1]. For example:

[0096] Consensus node 1 generates 4 secret shares, namely S 11 =f1(1)mod q,S 12 =f1(2)mod q,S 13 =f1(3)mod q,S 14=f1(4)mod q. Here, the 4 secret shares represent the total number of consensus nodes. In other words, to ultimately achieve the goal of generating a complete signature by taking any w from the n signature shares and then using the recovery function, n secret shares need to be generated. The same applies below.

[0097] Consensus node 2 generates 4 secret shares, namely S 21 =f2(1)mod q,S 22 =f2(2)mod q,S 23 =f2(3)mod q,S 24 =f2(4)mod q.

[0098] Consensus node 3 generates 4 secret shares, namely S 31 =f3(1)mod q,S 32 =f3(2)mod q,S 33 =f3(3)mod q,S 34 =f3(4)mod q.

[0099] Consensus node 4 generates 4 secret shares, namely S 41 =f4(1)mod q,S 42 =f4(2)mod q,S 43 =f4(3)mod q,S 44 =f4(4)mod q.

[0100] Furthermore, in addition to retaining its own secret share, each node can exchange other secret shares generated with other consensus nodes through a P2P network. Specifically, this can be done as follows:

[0101] Consensus node 1 retains S 11 , will S 12 Send to node 2, and send S 13 Send to node 3, and send S 14 The secret share can be sent to node 4 via the underlying P2P (Peer-to-Peer) network component in the blockchain network. The sent secret share needs to be kept confidential. Consensus node 1 can encrypt the secret share to be sent using the recipient's public key before sending it to the recipient, or send it to the recipient via a secure connection such as TLS (Transport Layer Security).

[0102] Consensus node 2 retains S 22 , will S 21 Send to node 1, and send S 23 Send to node 3, and send S 24Sending to node 4 can be done through the underlying P2P network components in the blockchain network. Similarly, the sent secret share needs to be kept confidential. Consensus node 2 can encrypt the secret share to be sent using the recipient's public key before sending it to the recipient, or send it to the recipient through a secure connection such as TLS.

[0103] Consensus node 3 retains S 33 , will S 31 Send to node 1, and send S 32 Send to node 2, and send S 34 Sending to node 4 can be done through the underlying P2P network components in the blockchain network. Similarly, the sent secret share needs to be kept confidential. Consensus node 3 can encrypt the secret share to be sent using the recipient's public key before sending it to the recipient, or send it to the recipient through a secure connection such as TLS.

[0104] Consensus node 4 retains S 44 , will S 41 Send to node 1, and send S 42 Send to node 2, and send S 43 Sending to node 3 can be done through the underlying P2P network components in the blockchain network. Similarly, the sent secret share needs to be kept confidential. Consensus node 4 can encrypt the secret share to be sent using the recipient's public key before sending it to the recipient, or send it to the recipient through a secure connection such as TLS.

[0105] As you can see, the two numbers in the subscript of the secret share represent the node number that issued the secret share (left) and the node number that received the secret share (right). Thus:

[0106] Consensus node 1 has a secret share S generated by different nodes locally. 11 S 21 S 31 S 41 ;

[0107] Consensus node 2 has a different secret share S generated by different nodes locally. 12 S 22 S 32 S 42 ;

[0108] Consensus node 3 has a secret share S generated by different nodes locally. 13 S 23 S 33 S 43 ;

[0109] Consensus node 4 has a different secret share S generated by different nodes locally. 14 S 24S 34 S 44 .

[0110] Among them, consensus node 1 has S locally. 11 It is generated by itself, and the consensus node 2 has it locally. 22 It is generated by itself, and consensus node 3 has it locally. 33 It is generated by itself, and consensus node 4 has it locally. 44 It was generated by itself.

[0111] Ideally, consensus nodes should sign the secret share to be sent, for example, using their own private key or a MAC (Message Authentication Code), to ensure message integrity and prevent man-in-the-middle attacks. Correspondingly, the node receiving the secret share can verify the correctness of the signature.

[0112] S620: Each node generates public verification parameters corresponding to its own secret share and broadcasts them through the DKG contract.

[0113] Each consensus node can generate a set of verification parameters corresponding to its own key share. The generation method can use the following formula:

[0114]

[0115] In formula (4), g is a base point on the elliptic curve. According to the operational properties of elliptic curves, a power of g is also a point on the elliptic curve. t is the degree of the polynomial, typically set to (quorum-1). As mentioned earlier, to ultimately achieve the goal of generating a complete signature from any w signatures selected from n signature shares using the recovery function, the degree of the polynomial needs to be set to t, where t = w-1. The same applies below.

[0116] Based on the above formula (4), let t = 2, and the set of verification parameters generated by consensus node 1 is as follows: 10 A 11 A 12 This set of verification parameters is broadcast via an on-chain contract. Similarly, based on the above formula, consensus node 2 generates a set of verification parameters as follows: 20 A 21 A 22 This set of verification parameters is broadcast via an on-chain contract. Similarly, based on the above formula, consensus node 3 generates a set of verification parameters as follows: 30 A 31 A 32 This set of verification parameters is broadcast via an on-chain contract. Similarly, based on the above formula, consensus node 4 generates a set of verification parameters as follows: 40 A​​​​41 A 42 > This set of verification parameters is broadcast via an on-chain contract.

[0117] Based on the properties of cryptography, A ik Even if it's published, it won't lead to the derivation of a. ik Therefore, even if the published A is obtained from the chain... ik It is also impossible to obtain the polynomial in S610.

[0118] Through on-chain contract broadcasting, specifically, each node can sign a transaction with its own private key and send it to the blockchain. Each node can have a built-in blockchain SDK (Software Development Kit). An SDK is a collection of program interfaces, documentation, examples, development tools, etc. With a built-in SDK, a blockchain node can initiate transactions to the blockchain network like a blockchain client. Transactions signed by a blockchain node with its own private key can contain calls to smart contracts on the blockchain. The called contract, for example, is a DKG contract. This DKG contract can be a system-level contract, that is, a contract pre-deployed on the blockchain, such as a contract created by an account with system administrator privileges, providing system-level control functions, rather than a contract developed and deployed by the user to implement specific business logic.

[0119] Like other contracts, DKG contracts can execute in a virtual machine (such as the Ethereum Virtual Machine, EVM) or a container (such as Docker); the execution is not limited to either. An external account initiates a transaction to the blockchain to invoke an on-chain contract, triggering its execution. The transaction's `f` field includes fields such as `from`, `to`, `value`, and `data`. The `from` field can be the account address of the transaction initiator, the `to` field can represent the address of the smart contract being invoked, the `value` field can be a native token on the blockchain (such as the value of Ether in Ethereum), and the `data` field can contain the method and parameters for invoking the smart contract. By specifying the address of the smart contract to be invoked in the `to` field, it indicates that a call is being made to a specific smart contract on the blockchain. A smart contract typically includes one or more functions, each of which can include some input parameters. The `data` field in the transaction specifies the function within the smart contract to be invoked and contains the required parameters.

[0120] The outcome of contract execution can alter the contract's storage, i.e., its world state. Furthermore, the transaction's execution result or related information can be recorded in a blockchain receipt. Specifically, the contract execution result / related information can be represented as events within the receipt. An event's structure might look like this:

[0121] Event:

[0122] [topic][msg]

[0123] [topic][msg] ......

[0125] In the example above, there can be one or more events. Each event can include fields such as topic and data. The format of the events output during transaction execution can be specified in the contract. Through the built-in SDK, blockchain clients or blockchain nodes can listen for events on specific topics, and upon detecting events on a specific topic, retrieve the content of the corresponding message, and perform preset processing after listening for certain content from a specific topic or the corresponding message.

[0126] Through this event mechanism, nodes can store execution results in the `msg` field corresponding to a specific topic, allowing listeners of that topic (i.e., clients with the built-in blockchain SDK or blockchain nodes) to obtain the corresponding execution results. In S620, a node may transmit the generated public verification parameters to the blockchain network by initiating a call to the first function in the DKG contract (e.g., a function named Broadcast, which may include parameters, including public verification parameters). One result of the blockchain network executing this transaction is that the public verification parameters are placed into the `msg` field corresponding to the specific topic in the receipt. Nodes listening to that topic can then obtain the content of the `msg` field, i.e., obtain the public verification parameters. This completes the on-chain contract broadcast.

[0127] You can register events to listen for with a blockchain node via an SDK. Specifically, the blockchain node can bind a hook function to the generated events in the running blockchain platform code (the hook function can be edited along with the platform code during the development phase). This hook function is a callback function that can be called when the listened-for event occurs and can execute certain processing logic. The listening code can include, for example, listening to the transaction content of blockchain transactions, the contract state of smart contracts, receipts generated by contracts, or one or more other things. After registering the listening events with the blockchain node via the SDK, the blockchain node can maintain a mapping relationship between the listened-for events and the listeners (e.g., the network connection of the client / node that has embedded the SDK and initiated event listening, which generally includes information such as IP address and port number). For example, it can maintain a mapping relationship between listening to a specific event of a specific contract and the listeners. When the hook function detects that the corresponding event topic has occurred, it can be called, and the hook function can then query the mapping relationship and push the listened-for event to the network connection. In this way, the SDK that initiated the listening can obtain the listened-for events through the maintained network connection. Contract execution is also implemented in a similar way through on-chain contract broadcasting. Specifically, the execution results of the contract and other transactions in the same block are stored in a transaction result cache area of ​​the blockchain node. Once all transactions in the blockchain have been executed and organized into a block, the blockchain platform code can listen to the receipts in the transaction results and broadcast the monitored events to the SDK that initiated the listening. Here, through this listening mechanism, nodes can listen to registered events for specific topics, and when such events occur, they can obtain the corresponding message (msg) for that topic through the maintained connection, thus obtaining the content of the message, which includes public verification parameters. In short, the blockchain's event mechanism can be used to broadcast public verification parameters, and the event listening mechanism can be used to receive the broadcast content.

[0128] Thus, the result of broadcasting the public verification parameters generated by each node on the blockchain can be as follows:

[0129] Consensus node 1 has a secret share S generated by different nodes locally. 11 S 21 S 31 S 41 and verification parameters 10 A 11 A 12 > and can obtain public verification parameters from the chain. 20 A 21 A 22 >, 30 A 31 A 32 >, 40 A​​​​41 A 42 >;

[0130] Consensus node 2 has a different secret share S generated by different nodes locally. 12 S 22 S 32 S 42 and verification parameters 20 A 21 A 22 > and can obtain public verification parameters from the chain. 10 A 11 A 12 >, 30 A 31 A 32 >, 40 A 41 A 42 >;

[0131] Consensus node 3 has a secret share S generated by different nodes locally. 13 S 23 S 33 S 43 and verification parameters 30 A 31 A 32 > and can obtain public verification parameters from the chain. 10 A 11 A 12 >, 20 A 21 A 22 >, 40 A 41 A 42 >;

[0132] Consensus node 4 has a different secret share S generated by different nodes locally. 14 S 24 S 34 S 44 and verification parameters 40 A 41 A 42 > and can obtain public verification parameters from the chain. 10 A 11 A 12 >, 20 A 21 A 22 >, 30 A 31 A 32 >

[0133] ​​​​​​​​​​​​S630: Each consensus node verifies each received secret share and its corresponding public verification parameters.

[0134] Each consensus node can receive secret shares from any other node and receive public verification parameters broadcast by the on-chain contract.

[0135] As mentioned in S610 above, each consensus node generates n secret shares S. ij Each node retains one copy and sends its n-1 secret shares, encrypted, to the other n-1 nodes via a P2P network component. As mentioned in S620 above, each node generates public verification parameters corresponding to its own secret share and broadcasts them via an on-chain contract.

[0136] If the secret share issued by each node and the corresponding public verification parameter belong to the same polynomial, then the following equation should hold:

[0137]

[0138] As mentioned before, t = quorum - 1; when n = 4, quorum = 3, and at this time t = 2.

[0139] Based on the property of formula (5), this formula can be used to verify each received secret share and public verification parameter. If the verification equation holds, it means that the secret share and the corresponding public verification parameter belong to the same polynomial; otherwise, they do not belong to the same polynomial. This can also be used to check whether the node that generates the secret share and the corresponding public verification parameter has engaged in malicious behavior. A typical malicious behavior is, for example, a node generating S based on the first polynomial. ij However, A was generated using different polynomials. ik (k = 0, ..., t).

[0140] The above verification, specifically:

[0141] When j=1, that is, consensus node 1 can verify the following:

[0142] i=1: (In fact, consensus node 1 does not need to verify whether this equation holds, because the secret share S) 11 and verification parameters 11 A 12 A 13 >All are generated by themselves)

[0143] i = 2:

[0144] i = 3:

[0145] i = 4:​

[0146] When j=2, that is, consensus node 2 can verify the following:

[0147] i=1:

[0148] i = 2: (In fact, consensus node 2 does not need to verify whether this equation holds, because the secret share S) 22 and verification parameters 20 A 21 A 22 >All are generated by themselves)

[0149] i = 3:

[0150] i = 4:

[0151] When j=3, that is, consensus node 3 can verify the following:

[0152] i=1:

[0153] i = 2:

[0154] i = 3: (In fact, consensus node 3 does not need to verify whether this equation holds, because the secret share S) 33 and verification parameters 30 A 31 A 32 >All are generated by themselves)

[0155] i = 4:

[0156] When j=4, that is, consensus node 4 can verify the following:

[0157] i=1:

[0158] i = 2:

[0159] i = 3:

[0160] i = 4: (In fact, consensus node 4 does not need to verify whether this equation holds, because the secret share S) 44 and verification parameters 40 A 41 A 42 >All are generated by themselves)

[0161] ​​​S640: After each consensus node passes each verification, it sends the node number of the verified node to the contract; the contract determines the node set based on the node numbers sent by each consensus node.

[0162] Consensus Node 2 Verification Equation If established, a transaction to invoke the DKG contract can be initiated. This transaction can include the node 1 number to indicate that the secret share issued by node 2 to node 1 and the corresponding public verification parameters have passed the verification. For example, it can be a function that verifies the successful invocation of DKG (e.g., named confirm(v), where the parameter v is, for example, the number of the confirmed node).

[0163] Consensus Node 3 Verification Equation If the transaction is successful, a transaction calling the DKG contract can be initiated. This transaction can include the node 1 number to indicate that the secret share issued by node 3 to node 1 and the corresponding public verification parameters have passed the verification. Similarly, the confirm(v) function in the DKG contract can be invoked.

[0164] Consensus Node 4 Verification Equation If the transaction is successful, a transaction calling the DKG contract can be initiated. This transaction can include the node 1 number to indicate that the secret share issued by node 4 to node 1 and the corresponding public verification parameters have passed the verification. Similarly, the confirm(v) function in the DKG contract can be invoked.

[0165] In this way, the DKG contract can collect confirmations from all nodes except node 1 regarding node 1's verification. Therefore, it can be assumed that the secret share issued by node 1 and the corresponding public verification parameters belong to the same polynomial.

[0166] akin:

[0167] Consensus Node 1 verifies the equation If the transaction is successful, a transaction calling the DKG contract can be initiated. This transaction can include the node 2 number to indicate that the secret share issued by node 1 to node 2 and the corresponding public verification parameters have passed the verification. Similarly, the confirm(v) function in the DKG contract can be invoked.

[0168] Consensus Node 3 Verification Equation If the transaction is successful, a transaction calling the DKG contract can be initiated. This transaction can include the node 2 number to indicate that the secret share issued by node 3 to node 2 and the corresponding public verification parameters have passed the verification. Similarly, the confirm(v) function in the DKG contract can be invoked.

[0169] Consensus Node 4 Verification Equation If the transaction is successful, a transaction calling the DKG contract can be initiated. This transaction can include the node 2 number to indicate that the secret share and corresponding public verification parameters issued by node 4 to node 2 have passed the verification. Similarly, the confirm(v) function in the DKG contract can be invoked.

[0170] In this way, the DKG contract can collect confirmations from all nodes except node 2 regarding node 2's verification. Therefore, it can be assumed that the secret share issued by node 2 and the corresponding public verification parameters belong to the same polynomial.

[0171] akin:

[0172] Consensus Node 1 verifies the equation If the transaction is successful, a transaction calling the DKG contract can be initiated. This transaction can include the node 1 number to indicate that the secret share and corresponding public verification parameters issued by node 1 to node 3 have passed the verification. Similarly, the confirm(v) function in the DKG contract can be invoked.

[0173] Consensus Node 2 Verification Equation If the transaction is successful, a transaction calling the DKG contract can be initiated. This transaction can include the node 3 number to indicate that the secret share issued by node 2 to node 3 and the corresponding public verification parameters have passed the verification. Similarly, the confirm(v) function in the DKG contract can be invoked.

[0174] Consensus Node 4 Verification Equation If the transaction is successful, a transaction calling the DKG contract can be initiated. This transaction can include the node 1 number to indicate that the secret share issued by node 4 to node 3 and the corresponding public verification parameters have passed the verification. Similarly, the confirm(v) function in the DKG contract can be invoked.

[0175] In this way, the DKG contract can collect confirmations from all nodes except node 3 regarding node 3's verification. Therefore, it can be assumed that the secret share issued by node 3 and the corresponding public verification parameters belong to the same polynomial.

[0176] akin:

[0177] Consensus Node 1 verifies the equation If the transaction is successful, a transaction calling the DKG contract can be initiated. This transaction can include the node 1 number to indicate that the secret share issued by node 1 to node 4 and the corresponding public verification parameters have passed the verification. Similarly, the confirm(v) function in the DKG contract can be invoked.

[0178] Consensus Node 2 Verification Equation If the transaction is successful, a transaction calling the DKG contract can be initiated. This transaction can include the node 3 number to indicate that the secret share issued by node 2 to node 4 and the corresponding public verification parameters have passed the verification. Similarly, the confirm(v) function in the DKG contract can be invoked.

[0179] Consensus Node 4 Verification Equation If the transaction is successful, a transaction calling the DKG contract can be initiated. This transaction can include the node 1 number to indicate that the secret share issued by node 3 to node 4 and the corresponding public verification parameters have passed the verification. Similarly, the confirm(v) function in the DKG contract can be invoked.

[0180] In this way, the DKG contract can collect confirmations from all nodes except node 4 regarding node 4's verification. Therefore, it can be assumed that the secret share issued by node 4 and the corresponding public verification parameters belong to the same polynomial.

[0181] Furthermore, the contract can determine the node set based on the node numbers sent by each consensus node.

[0182] For example, the DKG contract can determine the node set based on transaction verifications sent by each consensus node. Specifically, for a given node, if the DKG contract receives confirmations from all other nodes, the DKG contract adds the confirmed node to the node set. This set could be, for example, the QUAL set.

[0183] For example, in the S640 example, if the DKG contract receives confirmations from nodes 2, 3, and 4 regarding node 1, then the DKG contract adds node 1 to the QUAL set; similarly, if the DKG contract receives confirmations from nodes 1, 3, and 4 regarding node 2, then the DKG contract adds node 2 to the QUAL set; similarly, if the DKG contract receives confirmations from nodes 1, 2, and 4 regarding node 3, then the DKG contract adds node 3 to the QUAL set; similarly, if the DKG contract receives confirmations from nodes 1, 2, and 3 regarding node 4, then the DKG contract adds node 4 to the QUAL set.

[0184] After the execution of the above contract, the QUAL set includes the node set {1,2,3,4}.

[0185] It's important to note that in blockchain networks, due to the semi-synchronous or asynchronous nature of the network, contract execution doesn't necessarily occur within the same block. Instead, it may be performed in parts across different blocks. In such cases, a state machine can typically be set up within the contract, allowing the state machine to transition as a part of the execution is completed, or until the state machine reaches a certain final state. Each step of the state machine execution can be triggered upon receiving a transaction. Therefore, the set of nodes determined by the DKG contract in this step may span multiple blocks.

[0186] S650: Each consensus node obtains the set of nodes, calculates its public key share based on the verification parameters and the set of nodes, and calculates its own private key share based on its local secret share and the set of nodes.

[0187] On the one hand, each consensus node can calculate its public key share locally based on the verification parameters and the set of nodes in the contract. This public key share can be calculated using the following formula:

[0188]

[0189] Thus, for example, the public key share calculated by consensus node 1 could be:

[0190]

[0191] Similarly, the public key share calculated by consensus node 2 could be:

[0192]

[0193] Similarly, the public key share calculated by consensus node 3 could be:

[0194]

[0195] Similarly, the public key share calculated by consensus node 4 could be:

[0196]

[0197] On the other hand, each consensus node calculates its own private key share based on its local secret share and the set of nodes in the contract, which can be calculated according to the following formula:

[0198] x j =∑ i∈QUAL s ij mod q formula (7)

[0199] For example, consensus node 1 calculates its own private key share locally:

[0200]

[0201] Consensus node 2 calculates its own private key share locally:

[0202]

[0203] Consensus node 3 calculates its own private key share locally:

[0204]

[0205] Consensus node 4 calculates its own private key share locally:

[0206]

[0207] It is evident that the private key shares calculated by nodes 1, 2, 3, and 4 are not the same.

[0208] On the other hand, each consensus node can calculate the total public key locally based on the verification parameters and the set of nodes in the contract. This total public key can be calculated using the following formula:

[0209] y=∏ i∈QUAL y i Formula (8)

[0210] Among them, y i =A i0 .

[0211] Thus, for example, consensus node 1 can calculate the total public key as follows:

[0212] y = y1 * y2 * y3 * y4 = A 10 *A 20 *A 30 *A 40

[0213] Similarly, for example, consensus node 2 can calculate the total public key as follows:

[0214] y = y1 * y2 * y3 * y4 = A 10 *A 20 *A 30 *A 40

[0215] Similarly, for example, consensus node 3 can calculate the total public key as follows:

[0216] y = y1 * y2 * y3 * y4 = A 10 *A 20 *A 30 *A 40

[0217] Similarly, for example, consensus node 4 can calculate the total public key as follows:

[0218] y = y1 * y2 * y3 * y4 = A 10 *A 20 *A 30 *A 40

[0219] As can be seen, the total public key calculated by nodes 1, 2, 3 and 4 is the same, that is, each node obtains the same total public key through the above method.

[0220] The aforementioned private key share x1 corresponds to public key share pub1, private key share x2 corresponds to public key share pub2, private key share x3 corresponds to public key share pub3, and private key share x4 corresponds to public key share pub4. As mentioned earlier, each public key share can be used to verify the signature share generated by the corresponding private key share. Moreover, a complete signature recovered by the recovery function from the signature shares generated by at least quorum private key shares can be verified by the corresponding total public key.

[0221] By using the above method, on the basis of ensuring the overall consistency and synchronization of the blockchain network through the consensus mechanism, distributed key generation is achieved by combining blockchain smart contracts. This ensures that the generation of distributed keys is achieved by the cooperation of various participants, and that the generated results are consistent and reliable. This eliminates the strong dependence of distributed key generation outside the original blockchain on network synchronization and solves the problem of unreliability of the generated results in this case.

[0222] Figure 7 This is an architecture diagram of a blockchain node as described in one embodiment of this specification, including:

[0223] The acquisition unit 71 is used to acquire the first data currently stored in the blockchain when the first block in the blockchain is completed.

[0224] Generation unit 72 is used to generate a first transaction when it is determined that the first data meets preset conditions;

[0225] Sending unit 73 is used to send the first transaction to the blockchain.

[0226] 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.

[0227] 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.

[0228] In the solutions provided in the embodiments of this specification, transactions are automatically sent by the nodes triggered by data in the blockchain. There is no need to create or authorize external accounts to send transactions to the blockchain through devices other than the nodes for system settings. There is no need to create the account status of the nodes in the blockchain, which improves the efficiency of the blockchain system and saves the hardware and storage costs of the blockchain system.

[0229] 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... Figure 3 The method shown.

[0230] This specification also provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements, as described above. Figure 3 The method shown.

[0231] 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.

[0232] 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.

[0233] 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.

[0234] 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.

[0235] 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.

[0236] 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.

[0237] 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.

[0238] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus 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.

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

[0240] 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.

[0241] 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.

[0242] 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.

[0243] 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.

[0244] 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.

[0245] 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 transaction sending method in a blockchain, executed by a first node in the blockchain, wherein the first node is any consensus node or a candidate node in the blockchain, and the candidate node is a node waiting to be rotated into a consensus node, the method comprising: When the first block in the blockchain is completed, the latest block number of the block in which the consensus node rotation occurred and the preset consensus node rotation cycle are obtained from the contract state of the first contract. When it is determined that the block number of the current block is greater than or equal to the sum of the block number of the latest block in which consensus node rotation occurred and the consensus node rotation period, a first transaction is generated. This first transaction is used to invoke a first contract to perform system settings in the blockchain according to the code in the first contract. The first transaction is also used to perform consensus node rotation. Furthermore, the first transaction includes a transaction type field, which indicates that the first transaction is generated by a node in the blockchain through built-in blockchain platform code. Send the first transaction to the blockchain; Execute the first transaction, wherein, during the execution of the first transaction, the state of the first node is not stored in the state database according to the transaction type field; After the first transaction is completed, the block number of the latest block in which the consensus node rotation occurred is updated in the contract state of the first contract.

2. The method according to claim 1, wherein the first transaction includes the identifier of the first node as the identifier of the transaction sender, and the method further includes: The signature of the first transaction is generated using the private key of the first node; The signature is sent to the blockchain along with the first transaction.

3. The method according to claim 2, further comprising: Receive a second transaction and its signature, wherein the sender of the second transaction is a second node in the blockchain, and the signature of the second transaction is generated based on the private key of the second node; Obtain the pre-stored public key of the second node; Generate signature verification information for the second transaction, the signature verification information including the node identifier of the second node and the public key of the second node; The signature of the second transaction is verified based on the verification information.

4. The method according to claim 3, wherein the second transaction includes a transaction type identifier for indicating that the second transaction is a transaction type sent by a node, and the method further includes: Based on the transaction type of the second transaction, the sender of the second transaction is determined to be the second node.

5. The method according to claim 4, further comprising: During the execution of the second transaction, the sender's status is not stored in the status database, depending on the transaction type of the second transaction.

6. The method according to claim 1, further comprising: Determine whether the transaction receipt of the first block includes a preset event. If the transaction receipt of the first block includes a preset event, obtain first data in response to the preset event. The preset event includes: the first contract receiving a public verification vector sent by the second node, and the first data including the public verification vector; when the secret share provided by the second node is successfully verified through the public verification vector, generate a third transaction. The third transaction is used to store the confirmation information of the first node to the second node in the blockchain.

7. The method according to claim 1, further comprising: The first transaction is used to store information in the blockchain after execution to indicate that the operation corresponding to the first transaction has been completed.

8. A blockchain node, wherein the blockchain node is any consensus node or a candidate node in a blockchain, the candidate node being a node to be rotated into a consensus node, the blockchain node comprising: The acquisition unit is used to obtain the latest block number of the block in which the consensus node rotation has occurred and the preset consensus node rotation cycle from the contract state of the first contract when the first block in the blockchain is completed. A generation unit is configured to generate a first transaction when it is determined that the block number of the current block is greater than or equal to the sum of the block number of the latest block in which consensus node rotation occurred and the consensus node rotation period. The first transaction is used to invoke a first contract to perform system settings in the blockchain according to the code in the first contract. The first transaction is also used to perform consensus node rotation. The first transaction includes a transaction type field, which indicates that the first transaction is sent by a node in the blockchain through built-in blockchain platform code. A sending unit is used to send the first transaction to the blockchain; An execution unit is configured to execute the first transaction, wherein, during the execution of the first transaction, the state of the blockchain node is not stored in the state database according to the transaction type field; An update unit is used to update the block number of the latest block in which consensus node rotation has occurred in the contract state of the first contract after the first transaction is completed.

9. 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-7.

10. A computing device 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-7.

Images