WO2023029743A1

WO2023029743A1 - Block management

Info

Publication number: WO2023029743A1
Application number: PCT/CN2022/104315
Authority: WO
Inventors: 卓海振; 张中文
Original assignee: 支付宝(杭州)信息技术有限公司
Priority date: 2021-09-06
Filing date: 2022-07-07
Publication date: 2023-03-09
Also published as: CN113495927A; CN113495927B; CN114817399A

Abstract

One or more embodiments of the present description provide a block management method and apparatus, applied to a management node in a blockchain system. The method comprises: receiving a candidate block sent by an accounting node in a blockchain system, wherein the candidate block is obtained by packaging, by the accounting node, a plurality of blockchain transactions that have passed legitimacy verification, and the candidate block has passed consensus; checking the blockchain transactions comprised in the candidate block according to a predefined management rule; if it is determined that all blockchain transactions comprised in the candidate block meet the management rule, triggering each accounting node to respectively record the candidate block as a new block in a blockchain ledger maintained by the accounting node; and if it is determined that any blockchain transaction that does not meet the management rule is present in the candidate block, triggering each accounting node to abandon the candidate block.

Description

block management

technical field

One or more embodiments of this specification relate to the field of blockchain technology, and in particular to a block management method and device.

Background technique

Blockchain technology, also known as distributed ledger technology, is an emerging technology in which several computing devices jointly participate in "bookkeeping" and jointly maintain a complete distributed database. Since blockchain technology has the characteristics of decentralization, openness and transparency, each computing device can participate in database records, and data synchronization between computing devices can be quickly performed, blockchain technology is used to build a decentralized system, and Various execution programs are included in the distributed database of the blockchain for automatic execution, which has been widely used in many fields.

In the accounting process of the blockchain, it is usually necessary for the blockchain nodes to reach a consensus on the blockchain transactions that have passed the legality verification, and the accounting nodes determined by the consensus algorithm based on the blockchain will package the received transactions as Generate a candidate block, and send the generated candidate block or the block header of the candidate block to other node devices for consensus verification. Other blockchain nodes can directly execute the transactions contained in the block when there is no problem in verifying the received candidate block or the block header of the candidate block. In the blockchain system, the data of the blockchain transaction will be stored on the blockchain. After the transaction is executed, the transaction certificate that cannot be tampered with and will not be lost is stored on the blockchain. This non-tamperable feature of stored information, on the one hand, can make the data on the chain more reliable and credible, effectively improving the security of blockchain transactions; but on the other hand, it will also make some data that does not meet the management requirements be stored on the chain. Cannot be deleted.

Contents of the invention

In view of this, one or more embodiments of this specification provide a block management method and device.

Specifically, one or more embodiments of this specification provide the following technical solutions: According to the first aspect of one or more embodiments of this specification, a block management method is proposed, which is applied to a management node in a blockchain system, Including: receiving the candidate block sent by the bookkeeping node in the blockchain system, the candidate block is obtained by the bookkeeping node packaging a number of blockchain transactions that have passed the legality verification, and the candidate block The block has passed the consensus; the blockchain transactions contained in the candidate block are verified according to the predefined management rules; when it is confirmed that all the blockchain transactions contained in the candidate block comply with the management rules , trigger each bookkeeping node to record the candidate block as the latest block in the blockchain account book maintained by itself; after confirming that there is any blockchain transaction in the candidate block that does not comply with the management rules In this case, each accounting node is triggered to abandon the candidate block.

According to the second aspect of one or more embodiments of this specification, a block management device is proposed, which is applied to a management node in a blockchain system, including: a receiving unit, configured to receive The candidate block sent by the accounting node, the candidate block is obtained by the accounting node by packaging a number of blockchain transactions that have passed the legality verification, and the candidate block has passed the consensus; the verification unit is used for Verify the blockchain transactions contained in the candidate block according to predefined management rules; the first trigger unit is used to confirm that all blockchain transactions contained in the candidate block comply with the management rules In this case, each accounting node is triggered to record the candidate block as the latest block in the blockchain account book maintained by itself; the second trigger unit is used to confirm that there is any block in the candidate block In the case that the chain transaction does not comply with the management rules, each bookkeeping node is triggered to abandon the candidate block.

According to a third aspect of the present specification, there is provided an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein, the processor implements the above-mentioned first aspect by running the executable instructions The method described in the examples.

According to a fourth aspect of the embodiments of the present specification, there is provided a computer-readable storage medium, on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method described in the above-mentioned embodiments of the first aspect are implemented.

It can be seen from the technical solutions provided in this manual above that by setting up management nodes in the blockchain system, all candidate blocks packaged by accounting nodes must be verified by management nodes before being recorded in the blockchain ledger. Only candidate blocks that meet the preset management rules of the management node can be recorded and executed by other blockchain nodes in the blockchain system, which can not only improve the security of blockchain transactions, but also be able to write to the chain Effectively manage the data to prevent data that does not meet the management requirements from being stored on the chain.

Description of drawings

Fig. 1 is a schematic diagram of a block management method provided by an exemplary embodiment;

Fig. 2 is a schematic structural diagram of a block chain system provided by an exemplary embodiment;

Fig. 3 is a structural flow diagram of another block chain system provided by an exemplary embodiment;

Fig. 4 is a schematic diagram of an electronic device provided by an exemplary embodiment;

Fig. 5 is a block diagram of a block management device provided by an exemplary embodiment.

Detailed ways

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numerals in different drawings refer to the same or similar elements unless otherwise indicated. Implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with aspects of one or more embodiments of the present specification as recited in the appended claims.

It should be noted that in other embodiments, the steps of the corresponding methods may not necessarily be performed in the order shown and described in this specification. In some other embodiments, the method may include more or less steps than those described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; multiple steps described in this specification may also be combined into a single step in other embodiments describe.

In the blockchain system, the data of the blockchain transaction will be stored on the blockchain. After the transaction is executed, the transaction certificate that cannot be tampered with and will not be lost is stored on the blockchain. This non-tamperable feature of stored information, on the one hand, can make the data on the chain more reliable and credible, effectively improving the security of blockchain transactions; but on the other hand, it will also make some data that does not meet the management requirements be stored on the chain. Cannot be deleted.

In order to solve the above problems, this specification proposes a block management method, which further verifies the block chain transactions to be executed on the basis of traditional legality verification and consensus verification, so as to avoid storing data that does not meet management requirements in the on the blockchain.

Fig. 1 is a flow chart of a block management method according to an exemplary embodiment of this specification. As shown in Figure 1, the method is applied to the management node in the blockchain system, and may include the following steps.

Step 102: Receive the candidate block sent by the bookkeeping node in the blockchain system, the candidate block is obtained by the bookkeeping node packaging a number of blockchain transactions that have passed the legality verification, and the candidate block The block has passed consensus.

In the technical solution of this specification, the management node can be one or more blockchain nodes set in the blockchain system, and is used to verify the blockchain transactions on the blockchain system. In the case that the blockchain system has multiple management nodes at the same time, each management node can verify the blockchain transactions on the blockchain system according to the same management rules, and can also verify the blockchain transactions on the blockchain system according to different management rules. The blockchain transactions on the blockchain system are verified, and this specification does not limit this.

In the block management process, after a blockchain node receives any blockchain transaction, it first needs to verify the validity of the received blockchain transaction. The legality verification of blockchain transactions can usually be achieved by verifying the validity of signatures. When the blockchain adopts the account model, the applicable account of the blockchain usually corresponds to one or more sets of public key-private key pairs, and the above public keys can be recorded in the corresponding account status, or stored in other forms in the In the distributed database of the blockchain, it can be obtained by any node device in the blockchain system. The private key corresponding to the above public key is stored in the account owner's local database or other hardware terminals for the account owner to perform digital signature or encryption and decryption operations. The blockchain transaction initiated by the initiator includes not only the transaction content, but also the digital signature made by the initiator using the private key corresponding to the account for the transaction content. After the blockchain node receives the blockchain transaction, it can verify the legality of the blockchain transaction based on the digital signature contained in the blockchain transaction. Legality verification may generally include: verifying whether the digital signature is obtained based on the transaction content of the blockchain transaction (also called integrity verification), etc. Through the integrity check, it can be ensured that the blockchain transaction is indeed initiated by the user corresponding to the public key, and that the transaction has not been tampered with during transmission. In another case, the initiator's public key can also be carried in the CA certificate issued by the CA center to the initiator. When the initiator sends a blockchain transaction, the CA certificate signed by the CA center's private key can be Send it to the blockchain node together, and the blockchain node will verify the signature of the CA certificate according to the public key of the CA center, and obtain the initiator public key carried in the CA certificate if the verification is successful. Among them, the CA center is an authoritative organization that can be trusted by the blockchain nodes by default. Therefore, as long as the certificate is successfully verified with the public key of the CA center, it can be determined that the public key in the certificate is credible, so that the blockchain nodes can pass The public key verifies the legality of the digital signature contained in the received blockchain transaction. By verifying the legality of the received transaction, it can be determined that the received blockchain transaction has not been tampered with during transmission, which improves the security of the blockchain transaction.

When the legality verification is passed, the bookkeeping node in the blockchain system can package the blockchain transaction with other transactions that have passed the legality verification to generate a candidate block, and the generated candidate block or the candidate The block header of the block is sent to other node devices for consensus verification. The consensus algorithms supported in the blockchain can include: the first type of consensus algorithm, that is, the consensus algorithm that node devices need to compete for the accounting rights of each round of accounting cycle; for example, proof of work (Proof of Work, POW), Consensus algorithms such as Proof of Stake (POS), Delegated Proof of Stake (DPOS) and other consensus algorithms; the second type of consensus algorithm is to pre-elect accounting nodes for each round of accounting cycle (no need to compete for accounting rights) consensus algorithm; for example, consensus algorithms such as Practical Byzantine Fault Tolerance (PBFT).

In the blockchain system using the first type of consensus algorithm, the blockchain node that receives the blockchain transaction broadcasts the blockchain transaction that passes the legality verification to other blockchain nodes in the blockchain system. The node device competing for the bookkeeping right can execute the transaction after receiving the transaction, and the winning node device in the process of competing for the bookkeeping right in this round can serve as the bookkeeping node of the current round. The accounting node packs the received transaction together with other transactions to generate a candidate block, and sends the generated candidate block or the block header of the candidate block to other node devices for consensus.

In the blockchain system that adopts the second type of consensus algorithm, the node equipment with bookkeeping rights has been agreed before the current round of bookkeeping. If the blockchain node that receives the blockchain transaction is the bookkeeping node of the current round, it will directly pack the received transaction together with other transactions into the candidate block, and the generated candidate block or the The block header is sent to other node devices for consensus; if the blockchain node that receives the blockchain transaction is not the bookkeeping node of the current round, the blockchain transaction can be sent to the bookkeeping node of the current round, and the bookkeeper The ledger node packages the blockchain transaction together with other transactions to generate a candidate block, and sends the candidate block or the block header of the candidate block to other node devices for consensus.

Step 104: Verify the blockchain transactions included in the candidate block according to predefined management rules.

In related technologies, after a blockchain node receives a candidate block that has passed the consensus, it will default that there is no problem with the blockchain transactions contained in the candidate block, and the blockchain node can directly use the candidate block Append to the end of the blockchain maintained by itself as the latest block of the blockchain. In the technical solution of this manual, on the basis of passing the consensus, the management node in the blockchain system needs to further verify the candidate block according to the predefined management rules, and only when it passes After this further verification, the candidate block can be added as the latest block, so as to prevent the candidate block from containing risky blockchain transactions, and avoid data that does not comply with management rules from being saved on the blockchain.

In the technical solution of this specification, the management node can verify and manage the blockchain transactions in the candidate block according to the predefined management rules when it is determined that the received candidate block has passed the consensus. Among them, the specific content and specific logic of the management rules can be set by those skilled in the art according to actual needs. For example, the management rules can be set as whether the transaction content and/or the contract status value generated by the transaction contains preset sensitive words, etc. ; or for transfer transactions, the management rules can be set to whether the transaction amount exceeds the preset amount threshold, whether the transaction initiator account and/or the transaction counterparty account is a preset blacklist account, etc.; or for smart contract call transactions, management The rules can be set as whether the originator account has the contract calling authority, etc. This manual does not limit this. For example, if the blockchain transaction in the candidate block is a transaction that invokes a smart contract, the management node will call the management rules to analyze and obtain the initiator account of the transaction in the blockchain transaction after confirming that the candidate block consensus is passed. The From field of the account address, for example, "Bob(0xf5e...)", compare the account address with the blacklist account in the predefined management rules, if there is an account address in the blacklist account of the predefined management rules "Bob(0xf5e...)", the blockchain transaction has not passed the verification of the management node, otherwise, it has passed the verification. For another example, if there is a transfer transaction in the candidate block, the management node can call the predefined management rules after confirming that the candidate block has passed the consensus, and analyze and obtain the block chain transaction indicating that the transaction initiator wants to transfer money to the transaction receiver. The value field of the amount compares the transaction amount with the preset transaction amount threshold in the predefined management rules. If the transfer amount or transaction frequency exceeds the preset amount threshold in the predefined management rules, the blockchain transaction If the verification of the management node is not passed, otherwise, the verification is passed.

Furthermore, the management rules in this specification are not fixed. If necessary, they can be updated on the basis of the original management rules of the management contract, such as adding new management rules and deleting the original management rules. Part of the content, or the original management rules can be modified by modifying the preset parameters in the original management rules. For example, the management rules in the management contract are used to check whether the transaction amount of the transfer transaction is within the preset amount range And whether the transfer object account of the transaction is in the blacklist account, you can modify the value of the original preset amount range, delete some accounts in the original blacklist account, or add new inspection content by updating the management rules.

In this specification, the predefined management rules in the management node can be maintained in the pre-deployed management contract. When the management node receives a candidate block that passes the consensus, it can invoke the management rules pre-deployed at the blockchain management node. Contract to verify the blockchain transactions contained in the candidate block through the predefined management rules in the management contract. Wherein, the management contract can be a genesis contract, that is, the management contract is deployed in the genesis block at the beginning of the creation of the blockchain system. Alternatively, the management contract can also be a system contract, which needs to be deployed by an administrator. In some cases, the deployment can only be completed with the approval of more than a preset ratio of administrators. Of course, it is not excluded that in some cases, the general node members of the blockchain system may deploy the management contract, that is, the management contract can be an ordinary contract that is different from the creation contract and the system contract. Since the blockchain node itself is a logical concept, by creating a node instance on the node device and running the above-mentioned blockchain platform chain code by the node instance, the node instance can become a blockchain node. Therefore, the blockchain platform chain code is the underlying logic that makes the node instance a blockchain node, and the management contract can be deployed in the blockchain platform code running on the blockchain management node, so that the blockchain node is running The chain code of the blockchain platform can be directly executed, so that the blockchain node can actively trigger the call to the management contract through the predefined interface recorded in the chain code of the blockchain platform, without the need for blockchain transactions as in related technologies to call, thus simplifying the call logic of the management contract.

In one embodiment, the management contract can be an on-chain contract deployed at each blockchain node in the blockchain system through a contract deployment transaction. As shown in Figure 2, the blockchain system includes Node A, Node B, Blockchain nodes such as Node C and Node D have the same management contract deployed in each blockchain node. After the deployment of the management contract is completed, any blockchain node can call the locally deployed management contract when receiving the candidate block sent by the bookkeeping node to manage the candidate block through the management rules associated with the contract examine. Taking Node A shown in Figure 2 as an example, this node can submit a contract deployment transaction for management rules in the blockchain system, so that each blockchain node in the blockchain system can reach a consensus on the transaction. When the consensus is passed, each blockchain node in the blockchain system executes the transaction respectively, so as to locally deploy the management contract corresponding to the management rules on each node. The above-mentioned blockchain node Node A can be a management node or a non-management node in the blockchain system, and this specification does not limit it.

In another embodiment, the management contract may also be a local contract that is only deployed on the management node, and the local contract is only deployed on the management node, and does not need to be deployed to other blockchain nodes in the blockchain system. As shown in Figure 3, the blockchain system includes blockchain nodes such as Node A, Node B, Node C, and Node D. As the management node, Node A locally deploys a management contract, while other nodes (Node B, Node C, and /or Node D) does not deploy the management contract. Among them, any blockchain node other than Node A can be a management node, and of course it can also be a non-management node, which is not limited in this manual. It is understandable that Node A can execute a contract deployment transaction to implement the deployment of the management contract, and the transaction can be a local blockchain transaction that does not require consensus. For example, after Node A receives a contract deployment transaction, it does not need to initiate a consensus on the transaction, but can directly execute the transaction to deploy the corresponding management contract locally. It can be seen that although the blockchain system contains multiple blockchain nodes, only the management nodes among them are locally deployed with the above-mentioned management contract, while the non-management nodes do not deploy the contract, so the deployment process is relatively simple. In addition, because the deployment process of the above-mentioned management contract does not require consensus, it can realize the rapid deployment of the management contract and facilitate the convenient update of the data management rules.

According to the location where the management rules are recorded, the blockchain nodes can update the management rules in different ways. When the management rules are maintained in the contract code of the management contract, the blockchain node can execute a rule update transaction to deploy a new management contract, and the new management rules are recorded in the contract code or contract state of the new management contract. After the deployment is complete, the blockchain node can call the new management contract to perform management checks on the candidate blocks. When the management rules are maintained in the contract state of the management contract, if the management rules need to be updated, the blockchain node can initiate an update transaction for the management rules, and update the value of the contract state of the above management contract to the new management rules , without redeploying the management contract. It should be noted that the update transaction of the management rules can only be initiated by the administrator of the blockchain system. For example, the administrator can be a member of the blockchain corresponding to the management node, and avoid opening the update authority of the management rules to ordinary users. , to prevent security issues caused by this.

In this specification, the predefined management rules in the management node can also be maintained in the database, regardless of the management contract deployed on the blockchain. Then, when there is a management requirement, the management node can autonomously invoke the local management database to verify the received candidate blocks according to the predefined management rules in the management database. When the management rules need to be updated, the management rules in the above-mentioned management database can be updated through the database update technology in the related art; among them, the update operation of the management database can also be restricted by the identity of the operator, so as to ensure that only As mentioned above, the administrator can add, delete or modify the management rules in the management database.

The management rules may include valid management rules in a valid state and invalid management rules in an invalid state, which may be specifically determined according to status information of the management rules. When the management node verifies the blockchain transactions contained in the candidate block according to the management rules, it can select the effective management rules in the valid state for verification according to the state information of each management rule. Then, by configuring the status information of the management rules, the management rules that are expected to be used to verify the candidate blocks can be adjusted according to actual needs without frequent updates to the management rules, which helps to improve the verification efficiency. For example, a total of 100 management rules that may be used can be added in advance. In scenario 1, certain 10 management rules that need to be used can be set to valid status, and the rest of the management rules can be set to invalid status, so that they can be used in scenario 1. These 10 management rules are used to verify the candidate blocks. In scenario 2, if you need to replace 5 of the above 10 management rules with other management rules, you only need to set the original 5 management rules to an invalid state 1. Setting the other five management rules to the valid state can meet the verification requirements in Scenario 2 without repeatedly updating the management rules.

For example, the state information corresponding to the management rule may include a valid time period and an invalid time period, so as to indicate whether the management rule is in a valid state or an invalid state by means of a time period. The management node can determine the receiving time of the candidate block or read the time stamp contained in the candidate block, and match the above receiving time or time stamp with the valid time period corresponding to the management rule, if the above receiving time or the time stamp is within the effective time period of a certain management rule, it can be determined that the management rule is an effective management rule in an effective state, or, if the above-mentioned receiving time or time stamp is within the invalid time period of a certain management rule, Then it can be determined that the management rule is a failure management rule in a failure state.

For another example, the state information corresponding to the management rule may include a valid block height interval and an invalid block height interval, so as to indicate whether the management rule is in a valid state or an invalid state by means of the block height. The management node can determine the block height of the candidate block, and match the above-mentioned block height with the effective height interval corresponding to the management rule. If the above-mentioned block height is within the effective height interval of a certain management rule, it can It is determined that the management rule is an effective management rule in an effective state, or, if the above-mentioned block height is within the invalid block height interval of a certain management rule, it can be determined that the management rule is an invalid management rule. For example, management rule A and management rule B are predefined in the management node. Management rule A sets 1-10 as the effective block height interval, and management rule B sets 11-20 as the effective block height interval. When the block height of the candidate block received by the management node is 15, the block height of the candidate block is within the effective block height interval of management rule B, but not within the effective block height interval of management rule A , it can be determined that management rule B is a management rule in a valid state, and management rule A is a management rule in an invalid state, and the management node can select management rule B to verify the candidate block.

In the above verification process, the management node can obtain the field values contained in the transactions that can be used for verification by parsing the blockchain transactions in the candidate blocks, so as to verify the field values according to the predefined management rules Verify. Wherein, for the specific manner of invoking the management rule, reference may be made to the relevant description above, which will not be repeated here. By comparing the data to be detected with the preset data in the management rules, for example, when the management rules are used to detect whether the transaction content contained in the data field of the blockchain transaction contains preset sensitive words, the blockchain can be parsed transaction to extract the transaction content of its data field, and compare the extracted transaction content with each preset sensitive word in the management rules. When the transaction content matches any preset sensitive word, the blockchain can be determined If the transaction fails the verification, on the contrary, that is, when the transaction content does not match any preset sensitive words, it can be determined that the blockchain transaction has passed the verification of the management node. For another example, when the management rule is used to detect whether the to field of the blockchain transaction contains a predefined blacklist account, the blockchain transaction can be parsed to extract the transaction content of the to field, and the extracted transaction content can be compared with the management Each predefined blacklist account in the rules is compared. When the transaction content matches any predefined blacklist account, it can be determined that the blockchain transaction has not passed the verification, otherwise, the transaction content does not match any When there is a predefined blacklist account, it can be determined that the blockchain transaction has passed the verification of the management node.

In addition to verifying the field values contained in the transaction, the management node can also pre-execute the blockchain transaction in the candidate block, and verify the pre-execution result of the blockchain transaction, so that the block can be audited more strictly Content in the chain transaction that does not appear directly in the field value. For example, when the management node is used to detect whether the contract state generated by the transaction contains preset sensitive words, it can pre-execute the blockchain transaction in the candidate block and read the execution result from the contract state maintained by the management node , compare the read execution result with each preset sensitive word in the management rules, and when the execution result does not match any sensitive word, it can be determined that the blockchain transaction has passed the verification of the management node.

Furthermore, the above verification of the field values contained in the transaction can also be combined with the verification of the transaction execution result. After the management node receives the candidate block that has passed the consensus, it can first analyze the blockchain transaction contained in the candidate block, and pre-verify the field values contained in the parsed transaction according to the predefined management rules, and then Pre-execute the blockchain transactions that pass the pre-verification, read the execution results from the contract state maintained by the management node, and verify the execution results according to the predefined management rules. For example, when the management rules are used to detect whether the transaction content of the blockchain transaction and the contract status value generated by the transaction contain preset sensitive words or not, the blockchain transaction can be first parsed to extract its data field transaction content, and compare the extracted transaction content with each preset sensitive word in the management rules. When the transaction content matches any preset sensitive word, it can be determined that the blockchain transaction has not passed the verification, otherwise , that is, when the transaction content does not match any preset sensitive words, it is necessary to pre-execute the blockchain transaction to read its execution result, and compare the read execution result with each preset sensitive word in the management rules Yes, when the execution result matches any of the preset sensitive words, it can be determined that the blockchain transaction has not passed the verification. Conversely, when the execution result does not match any of the preset sensitive words, it can be determined that the blockchain transaction Passed the verification of the management node. Through the two-step verification of the blockchain transactions in the candidate block, it is possible to strictly verify the blockchain transactions while avoiding the execution of blockchain transactions that have not passed the pre-verification, thereby reducing the waste of computing resources , improve the verification efficiency.

Step 106: After confirming that all blockchain transactions contained in the candidate block comply with the management rules, trigger each bookkeeping node to record the candidate block as the blockchain account book maintained by itself of the latest block.

In one embodiment, when the management node determines that all the blockchain transactions in the received candidate block have passed the verification, it can send an uplink message to each accounting node in the blockchain system to which it belongs to indicate Each bookkeeping node records the candidate block as the latest block in the blockchain ledger maintained by itself. The management node can transmit the above-mentioned uplink message through the consensus link established with each accounting node. In fact, the "candidate block has passed the consensus" described in step 102 means that the consensus has been passed in the consensus algorithm such as the above, and the technical solution of this specification can be understood as based on these consensus algorithms An additional verification process is added; or, it can also be understood as improving the consensus algorithm mentioned above, so that the improved consensus algorithm adds a verification process compared with the existing consensus algorithm. At this time The above-mentioned on-chain message can be regarded as a consensus message generated under the improved consensus algorithm.

In one embodiment, when the management node determines that all blockchain transactions in the received candidate block have passed the verification, it can use the private key corresponding to its account to sign the candidate block, and send the signed The candidate block is sent to each accounting node in the blockchain system to which it belongs. After each bookkeeping node receives the signed candidate block, it can verify the digital signature in the received candidate block according to the account public key corresponding to the management node. The preset transaction execution conditions of each bookkeeping node If it is satisfied, the candidate block can be recorded as the latest block in the blockchain ledger maintained by itself. Among them, the transaction execution condition is pre-established by the blockchain system administrator according to the needs. For example, when there is only one management node in the blockchain system, the transaction execution condition can be set to receive the candidate block signed by the management node ;For another example, when there are multiple management nodes in the blockchain system, the transaction execution condition can be set to receive the number of candidate blocks signed by the management node is not less than the preset number, or receive the number of candidate blocks signed by the management node The ratio of the number of candidate blocks to the total number of management nodes is not less than the preset ratio, etc., to avoid security risks that may arise when a single or a small number of management nodes are abnormal.

Step 108: When it is confirmed that there is any blockchain transaction in the candidate block that does not comply with the management rules, trigger each bookkeeping node to abandon the candidate block.

In one embodiment, when the management node determines that there is a block chain transaction in the received candidate block that fails to pass the verification, it can send an abandonment message to each accounting node in the block chain system to which it belongs, to instruct each The accounting node abandons the candidate block. Among them, the block abandonment message can be a block abandonment transaction sent on the chain, or a predefined message message sent off the chain, which is not limited in this manual.

In an embodiment, when the management node determines that there is a blockchain transaction in the received candidate block that fails to pass the verification, corresponding to the embodiment of sending the signed candidate block in step 106 above, the management node may not check the candidate block. Block any operation, avoid sending signed candidate blocks to each bookkeeping node, so that each bookkeeping node in the blockchain system cannot meet the preset transaction execution conditions, and still cannot satisfy the transaction after the preset time In the case of execution conditions, each bookkeeping node can give up the candidate block.

In one embodiment, when the management node determines that there are blockchain transactions that fail verification in the received candidate block, it can also re-submit the blockchain transactions that meet the management rules in the candidate block according to the verification result. Package, generate a new candidate block, and agree on it with other blockchain nodes in the blockchain system. For example, if the candidate block received by the management node includes transaction 1, transaction 2, and transaction 3, transaction 1 and transaction 2 have passed the verification management of the management node, but transaction 3 has not passed the verification management of the management node , then the management node can repackage transaction 1 and transaction 2 to generate a new candidate block. If the new candidate block passes the consensus, the management node can use the private key corresponding to its account to generate a new candidate block. Sign, and send the signed candidate block to each bookkeeping node in the blockchain system to which it belongs, so that each bookkeeping node records the candidate block as its own when the transaction execution conditions are met For the latest block in the maintained blockchain ledger, the specific steps for consensus and signature of the new candidate block can refer to the relevant description above, and this manual will not repeat them here. By repackaging and generating new candidate blocks by the management node, compared with re-selecting blockchain transactions and packaging to generate candidate blocks by other bookkeeping nodes, it can have higher block generation efficiency.

This manual sets up management nodes in the blockchain system, so that all candidate blocks packaged by accounting nodes must be verified by the management node before being recorded in the blockchain ledger. Only those that meet the preset management rules of the management node Candidate blocks can be recorded and executed by other blockchain nodes in the blockchain system, which can not only improve the security of blockchain transactions, but also effectively manage the data written on the chain to avoid non-compliance with management Required data is stored on-chain.

Fig. 4 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to FIG. 4 , at the hardware level, the device includes a processor 402 , an internal bus 404 , a network interface 406 , a memory 408 and a non-volatile memory 410 , and of course may include hardware required by other services. One or more embodiments of this specification may be implemented based on software, for example, the processor 402 reads a corresponding computer program from the non-volatile memory 410 into the memory 408 and executes it. Of course, in addition to software implementations, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each A logic unit, which can also be a hardware or logic device.

Please refer to FIG. 5 , the block management device can be applied to the device shown in FIG. 5 to realize the technical solution of this specification. Wherein, the block management device may include: a receiving unit 502 configured to receive the candidate block sent by the bookkeeping node in the blockchain system, and the candidate block is verified by the bookkeeping node for legality Several blockchain transactions are packaged, and the candidate block has passed the consensus.

The verification unit 504 is configured to verify the blockchain transactions included in the candidate block according to predefined management rules.

The first triggering unit 506 is configured to trigger each accounting node to record the candidate block as self-maintained in the case of confirming that all blockchain transactions contained in the candidate block comply with the management rules The latest block in the blockchain ledger.

The second triggering unit 508 is configured to trigger each accounting node to abandon the candidate block when it is confirmed that there is any blockchain transaction in the candidate block that does not comply with the management rule.

Optionally, the verifying the blockchain transactions contained in the candidate block according to the predefined management rules includes: calling the management contract pre-deployed at the management node of the blockchain to pass the management contract Governance rules predefined in verify the blockchain transactions contained in the candidate block.

Optionally, the management contract includes a system contract deployed in the blockchain platform code running on the blockchain management node, and the calling of the management contract pre-deployed at the blockchain node includes: When the invocation conditions of the management contract are met, the management contract is invoked through a predefined interface recorded in the blockchain platform code; wherein, the invocation conditions of the management contract include: the candidate block passes the consensus .

Optionally, the management rules are maintained in the contract code of the management contract, or in the contract state corresponding to the management contract.

Optionally, the management contract is deployed at each blockchain node in the blockchain system through a contract deployment transaction; or, the management contract is a local contract deployed at the blockchain management node.

Optionally, the management rules are maintained in the contract state corresponding to the management contract, and the device further includes: an update unit 510 configured to call the management contract according to the received rule update transaction, so as to update the The value of the contract state is updated to the updated management rules carried in the rule update transaction.

Optionally, the verifying the blockchain transaction included in the block according to the predefined management rules includes: calling the management database pre-deployed at the blockchain node to pass the pre-defined Define governance rules for validating blockchain transactions in said blocks.

Optionally, the verifying the blockchain transactions contained in the candidate block according to the predefined management rules includes: parsing the blockchain transactions contained in the candidate blocks, and analyzing according to the predefined management rules to obtain Pre-check the field values contained in the transaction; and/or pre-execute the blockchain transaction, and verify the pre-execution result according to the predefined management rules.

Optionally, the management rules are used to implement at least one of the following checks: whether the transaction content and/or the contract status value generated by the transaction contain preset sensitive words; whether the transaction amount exceeds the preset amount threshold; the transaction initiator Whether the account and/or the counterparty account is a preset blacklist account.

Optionally, after confirming that all blockchain transactions included in the candidate block comply with the management rules, each bookkeeping node is triggered to record the candidate block as a block maintained by itself The latest block in the chain ledger, including: signing the candidate block after confirming that all blockchain transactions contained in the candidate block comply with the management rules; The block is sent to each accounting node in the blockchain system, so that each accounting node records the candidate block as the latest in the blockchain ledger maintained by itself when the transaction execution conditions are met. block; wherein, the transaction execution conditions include: the number of candidate blocks signed by the management node is not less than the preset number, or the number of candidate blocks signed by the management node is equal to the total number of management nodes The ratio is not less than the preset ratio.

Optionally, when it is confirmed that there is any blockchain transaction in the candidate block that does not comply with the management rules, triggering each bookkeeping node to abandon the candidate block includes: confirming that the candidate block If there is any blockchain transaction in the block that does not comply with the management rules, avoid sending signed candidate blocks to each accounting node.

Optionally, after confirming that all blockchain transactions included in the candidate block comply with the management rules, each bookkeeping node is triggered to record the candidate block as a block maintained by itself The latest block in the chain account book, including: after confirming that all the blockchain transactions contained in the candidate block comply with the management rules, sending an upper Chain message, so that each bookkeeping node respectively records the candidate block as the latest block in the blockchain account book maintained by itself.

Optionally, when it is confirmed that there is any blockchain transaction in the candidate block that does not comply with the management rules, triggering each bookkeeping node to abandon the candidate block includes: confirming that the If there is any blockchain transaction in the candidate block that does not comply with the management rules, send an abandonment message to each accounting node in the blockchain system, so that each accounting node abandons the candidate area piece.

Optionally, the device further includes: a packaging unit 512, configured to package the candidate block in compliance with the management rule if it is confirmed that there is any blockchain transaction in the candidate block All blockchain transactions governing rules to generate new candidate blocks.

The sending unit 514 is configured to send the new candidate block to each bookkeeping node in the blockchain system, so that each bookkeeping node respectively records the new candidate block as a block maintained by itself The latest block in the ledger.

Optionally, the device further includes: a consensus unit 516 configured to agree with each accounting node in the blockchain system on the new candidate block; wherein each accounting node determines the When the new candidate block passes the consensus, it is recorded as the latest block in the blockchain ledger maintained by itself.

Optionally, the verifying the blockchain transactions contained in the candidate block according to the predefined management rules includes: selecting an effective management rule in a valid state from the management rules according to the state information of each management rule ; Wherein, the state information includes a valid state and an invalid state; check the block chain transactions contained in the candidate block according to the effective management rules.

Optionally, when the current moment is within the effective time period corresponding to any management rule, or the block height of the candidate block is within the effective block height interval corresponding to any management rule, the any The management rule is determined to be in an effective state; and/or, at the current moment, it is in the invalidation period corresponding to any management rule, or the block height of the candidate block is in the invalidation block height corresponding to any management rule In the case of an interval, any one of the management rules is determined to be in an invalid state.

The systems, devices, modules, or units described in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementing device is a computer, which may take the form of a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, e-mail device, game control device, etc. desktops, tablets, wearables, or any combination of these.

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

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

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information. Information may be computer readable instructions, data structures, modules of a program, 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 technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, Magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by computing devices. As defined herein, computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.

It should also be noted that the term "comprises", "comprises" or any other variation thereof is intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus comprising a set of elements includes not only those elements, but also includes Other elements not expressly listed, or elements inherent in the process, method, commodity, or apparatus are also included. Without further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article or apparatus comprising said element.

The foregoing describes specific embodiments of this specification. Other implementations are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. Multitasking and parallel processing are also possible or may be advantageous in certain embodiments.

Terms used in one or more embodiments of the present specification are for the purpose of describing specific embodiments only, and are not intended to limit the one or more embodiments of the present specification. As used in one or more embodiments of this specification and the appended claims, the singular forms "a", "the", and "the" are also intended to include the plural forms unless the context clearly dictates otherwise. It should also be understood that the term "and/or" as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present specification to describe various information, the information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of one or more embodiments of this specification, first information may also be called second information, and similarly, second information may also be called first information. Depending on the context, the word "if" as used herein may be interpreted as "at" or "when" or "in response to a determination."

The above descriptions are only preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. Within the spirit and principles of one or more embodiments of this specification, Any modification, equivalent replacement, improvement, etc. should be included in the scope of protection of one or more embodiments of this specification.

Claims

A block management method applied to a management node in a blockchain system, the method comprising:

Receive the candidate block sent by the bookkeeping node in the blockchain system, the candidate block is obtained by the bookkeeping node by packaging a number of blockchain transactions that have passed the legality verification, and the candidate block has been by consensus;

verifying blockchain transactions contained in said candidate block according to predefined governing rules;

After confirming that all the blockchain transactions contained in the candidate block comply with the management rules, each bookkeeping node is triggered to record the candidate block as the latest block in the blockchain account book maintained by itself. piece;

When it is confirmed that there is any block chain transaction in the candidate block that does not comply with the management rules, each bookkeeping node is triggered to abandon the candidate block.
According to the method according to claim 1, said verifying the blockchain transactions contained in said candidate blocks according to predefined management rules comprises:

Invoking the management contract pre-deployed at the management node to verify the blockchain transactions contained in the candidate block through the predefined management rules in the management contract.
According to the method according to claim 2, the management contract includes a system contract deployed in the blockchain platform code running on the management node, and the calling of the management contract pre-deployed at the management node includes:

When the invocation conditions of the management contract are met, the management contract is invoked through a predefined interface recorded in the blockchain platform code; wherein, the invocation conditions of the management contract include: the candidate block passes consensus.
According to the method of claim 2, the management contract is deployed at each blockchain node in the blockchain system through a contract deployment transaction;

Alternatively, the management contract is a local contract deployed on the management node.
According to the method according to claim 2, the management rules are maintained in the contract state corresponding to the management contract, further comprising:

Call the management contract according to the received rule update transaction, so as to update the value of the contract state to the updated management rule carried by the rule update transaction.
According to the method of claim 2, the management rules are maintained in the contract code of the management contract, or in the contract state corresponding to the management contract.
According to the method according to claim 1, said verifying the blockchain transactions contained in said blocks according to predefined management rules comprises:

Invoking the management database pre-deployed at the management node to verify the blockchain transactions in the candidate block through the predefined management rules in the management database.
According to the method according to claim 1, the verification of the blockchain transactions contained in the candidate block according to the predefined management rules comprises:

Analyzing the blockchain transactions contained in the candidate block, and pre-verifying the field values contained in the parsed transactions according to predefined management rules; and/or

The blockchain transaction is pre-executed, and the pre-executed result is verified according to predefined management rules.
According to the method according to claim 1, the management rules are used to implement at least one of the following checks:

Whether the transaction content and/or the contract status value generated by the transaction contain preset sensitive words;

Whether the transaction amount exceeds the preset amount threshold;

Whether the transaction initiator account and/or the transaction counterparty account is a preset blacklist account.
According to the method according to claim 1, when it is confirmed that all blockchain transactions contained in the candidate block comply with the management rules, each bookkeeping node is triggered to record the candidate block as itself The latest block in the maintained blockchain ledger, including;

signing the candidate block after confirming that all blockchain transactions contained in the candidate block comply with the management rules;

Send the signed candidate block to each bookkeeping node in the blockchain system, so that each bookkeeping node records the candidate block as the area maintained by itself when the transaction execution conditions are met. The latest block in the block chain account book; wherein, the transaction execution conditions include: the number of candidate blocks signed by the management node is not less than the preset number, or the number of candidate blocks signed by the management node is received The ratio to the total number of management nodes is not less than a preset ratio.
According to the method according to claim 9, when it is confirmed that there is any blockchain transaction in the candidate block that does not comply with the management rules, triggering each accounting node to abandon the candidate block includes:

When it is confirmed that there is any blockchain transaction in the candidate block that does not comply with the management rules, it is avoided to send the signed candidate block to each accounting node.
According to the method according to claim 1, when it is confirmed that all blockchain transactions contained in the candidate block comply with the management rules, each bookkeeping node is triggered to record the candidate block as itself The latest block in the maintained blockchain ledger, including:

After confirming that all blockchain transactions contained in the candidate block comply with the management rules, send an uplink message to each bookkeeping node in the blockchain system, so that each bookkeeping node Record the candidate block as the latest block in the blockchain ledger maintained by itself.
According to the method according to claim 1, when it is confirmed that there is any blockchain transaction in the candidate block that does not comply with the management rules, triggering each bookkeeping node to abandon the candidate block includes:

In the case of confirming that there is any blockchain transaction in the candidate block that does not comply with the management rules, send an abandonment message to each accounting node in the blockchain system, so that each accounting node The node discards the candidate block.
The method according to claim 1, further comprising:

In the case of confirming that there is any blockchain transaction in the candidate block that does not comply with the management rules, pack all the blockchain transactions in the candidate block that meet the management rules to generate a new candidate block ;

Send the new candidate block to each bookkeeping node in the blockchain system, so that each bookkeeping node records the new candidate block as the latest block in the blockchain account book maintained by itself .
The method according to claim 14, further comprising: consensusing on the new candidate block with each bookkeeping node in the blockchain system; wherein each bookkeeping node is determining the new candidate block In the case of consensus, it is recorded as the latest block in the blockchain ledger maintained by itself.
According to the method according to claim 1, said verifying the blockchain transactions contained in said candidate blocks according to predefined management rules comprises:

According to the status information of each management rule, select an effective management rule in an effective state from the management rules; wherein, the state information includes a valid state and an invalid state;

The blockchain transactions contained in the candidate block are verified according to the valid management rules.
According to the method according to claim 15, when the current moment is in the effective time period corresponding to any management rule, or the block height of the candidate block is in the effective block height interval corresponding to the any management rule, any of said management rules is determined to be in an active state; and/or,

In the case that the current moment is in the invalid time period corresponding to any management rule, or the block height of the candidate block is in the invalid block height interval corresponding to the any management rule, the any management rule is determined is in an invalid state.
A block management device applied to a management node in a blockchain system, the device comprising:

The receiving unit is used to receive the candidate block sent by the bookkeeping node in the blockchain system, the candidate block is obtained by the bookkeeping node by packaging several blockchain transactions that have passed the legality verification, and the The above candidate blocks have passed the consensus;

A verification unit, configured to verify the blockchain transactions contained in the candidate block according to predefined management rules;

The first triggering unit is configured to trigger each accounting node to record the candidate block as a zone maintained by itself when it is confirmed that all blockchain transactions contained in the candidate block comply with the management rules The latest block in the blockchain ledger;

The second trigger unit is configured to trigger each accounting node to abandon the candidate block when it is confirmed that there is any blockchain transaction in the candidate block that does not comply with the management rules.
An electronic device comprising:

processor;

memory for storing processor-executable instructions;

Wherein, the processor implements the method according to any one of claims 1-17 by running the executable instructions.
A computer-readable storage medium, on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method according to any one of claims 1-17 are implemented.