Blockchain Data Auditing Method, System, Computer Device and Storage Medium

Abstract

This application relates to a blockchain data auditing method, system, computer device, and storage medium. The method includes: the auditing blockchain generates corresponding auditing events for auditing requests through an intelligent auditing contract, allocates multiple auditing nodes and an aggregation node for responding to the auditing requests to the auditing client. Each auditing node audits the same target block data respectively to obtain node auditing results. The aggregation node performs aggregation processing on the node auditing results provided by the multiple auditing nodes to obtain a node aggregation result. By performing aggregation processing on the node auditing results of the multiple auditing nodes through the aggregation node, malicious auditing nodes can be filtered out, avoiding malicious nodes from tampering with the auditing results or providing false auditing results, thereby improving the accuracy of the auditing results.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular, to a blockchain data auditing method, system, computer device, and storage medium. Background Art

[0002] In the field of cross-chain data auditing, some existing auditing methods usually perform data verification and auditing based on the consensus mechanism of a specific blockchain. Some auditing schemes rely on the nodes of the target blockchain itself to execute the auditing tasks. The nodes of the target blockchain itself perform auditing checks on the blockchain data according to predefined rules. Due to the transparency of blockchain data, and the process of relying on the nodes of the target blockchain itself for auditing is vulnerable to interference from malicious nodes.

[0003] For example, malicious nodes may tamper with auditing parameters, provide false auditing results, or even jointly launch attacks, affecting the accuracy of auditing. Therefore, directly performing auditing on the target blockchain cannot meet the application scenarios with high requirements for data privacy protection, and cannot ensure the accuracy of auditing results. Summary of the Invention

[0004] This application provides a blockchain data auditing method, system, computer device, and storage medium to solve the problem that the existing blockchain data auditing methods cannot meet the application scenarios with high requirements for data privacy protection and cannot ensure the accuracy of auditing results.

[0005] In a first aspect, this application provides a blockchain data auditing method, which is applied to an auditing blockchain. The method includes:

[0006] When receiving an auditing request sent by an auditing client, generating an auditing event corresponding to the auditing request through an auditing contract, where the auditing request is used to request the data auditing result obtained by auditing the target block data in the target blockchain according to a preset auditing scheme, and the auditing event includes the storage location of the target block data, the committee nodes responding to the auditing request, and the role types of each committee node, and the role type of the committee node is an auditing node or an aggregation node;

[0007] Broadcasting the auditing event, where the auditing node is used to pull the target block data from the target blockchain based on the auditing event, and perform auditing processing on the target block data according to the preset auditing scheme to obtain a node auditing result, and the aggregation node is used to perform aggregation processing on the node auditing results of multiple auditing nodes to obtain a node aggregation result;

[0008] When receiving the node aggregation result sent by the aggregation node, use the audit contract to perform zero-knowledge verification on the audit proof in the node aggregation result to obtain a verification result;

[0009] When the verification result is verification passed, use the audit parameters in the node aggregation result as the data audit result and feedback it to the audit client.

[0010] In a second aspect, the present application provides a blockchain data auditing method applied to a computing node. The method includes:

[0011] When monitoring an audit event published by an audit blockchain, call the audit contract in the audit blockchain to determine the role type of the computing node. Wherein, the audit event includes the storage location of target block data in a target blockchain, the committee nodes responding to the audit request, and the role types of each of the committee nodes. The committee nodes are computing nodes participating in the audit process, and the role types of the committee nodes are audit nodes or aggregation nodes;

[0012] When the role type of the computing node is an audit node, pull the target block data from the target blockchain according to the audit event, and perform audit processing on the target block data according to the preset audit plan to obtain a node audit result; or,

[0013] When the role type of the computing node is an aggregation node, perform aggregation processing on the node audit results of multiple audit nodes to obtain a node aggregation result, and send the node aggregation result and audit proof to the audit blockchain. The audit blockchain is used to, after auditing the audit proof passes, use the node aggregation result as the data audit result and feedback it to the audit client corresponding to the audit request.

[0014] In a third aspect, the present application provides a blockchain data auditing system. The system includes:

[0015] An audit client, used to initiate an audit request, where the audit request is used to request the data audit result obtained by auditing the target block data in the target blockchain according to a preset audit plan;

[0016] An audit blockchain is used to generate an audit event corresponding to the audit request through an audit contract. The audit event includes the storage location of the target block data, the committee nodes that respond to the audit request, and the role types of each of the committee nodes. The role type of the committee node is an audit node or an aggregation node; broadcast the audit event. Among them, the audit node is used to pull the target block data from the target blockchain based on the audit event, and perform audit processing on the target block data according to the preset audit scheme to obtain a node audit result. The aggregation node is used to perform aggregation processing on the node audit results of multiple audit nodes based on the audit event to obtain a node aggregation result; when receiving the node aggregation result sent by the aggregation node, use the audit contract to perform zero-knowledge verification on the audit proof in the node aggregation result to obtain a verification result; when the verification result is verification passed, use the audit parameters in the node aggregation result as the data audit result and feedback it to the audit client;

[0017] A target blockchain is used to provide target block data to be audited for the audit node, and the target blockchain is any blockchain to be audited.

[0018] In a fourth aspect, the present application provides a computer device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the above blockchain data audit method is implemented.

[0019] In a fifth aspect, the present application further provides a computer storage medium, storing computer-executable instructions for executing the above blockchain data audit method.

[0020] The above technical solution provided by the embodiments of the present application has the following advantages compared with the prior art: In the method provided by the embodiments of the present application, when an audit request sent by an audit client is received, an audit event corresponding to the audit request is generated through an audit contract. Wherein, the audit request is used to request the data audit result obtained by auditing the target block data in the target blockchain according to a preset audit scheme. The audit event includes the storage location of the target block data, the committee nodes responding to the audit request, and the role types of each of the committee nodes. The role types of the committee nodes are audit nodes or aggregation nodes; the audit event is broadcast. Wherein, the audit node is used to pull the target block data from the target blockchain based on the audit event, and audit the target block data according to the preset audit scheme to obtain a node audit result. The aggregation node is used to perform an aggregation process on the node audit results of multiple audit nodes to obtain a node aggregation result; when the node aggregation result sent by the aggregation node is received, the audit proof in the node aggregation result is verified by zero knowledge using the audit contract to obtain a verification result; when the verification result is verified to pass, the audit parameters in the node aggregation result are fed back to the audit client as the data audit result.

[0021] Based on the above method, the audit blockchain generates a corresponding audit event for the audit request through an intelligent audit contract, assigns multiple audit nodes and an aggregation node for responding to the audit request to the audit client. Each audit node audits the same target block data respectively to obtain a node audit result. The aggregation node performs an aggregation process on the node audit results provided by multiple audit nodes to obtain a node aggregation result. The audit blockchain performs zero knowledge verification on the audit proof, which can avoid the audit blockchain knowing the audit content, thereby avoiding the exposure of sensitive information to meet the application scenarios with high requirements for data privacy protection. And by the aggregation node performing an aggregation process on the node audit results of multiple audit nodes, malicious audit nodes can be filtered out, avoiding malicious nodes tampering with the audit result or providing false audit results, thereby improving the accuracy of the audit result, so as to solve the problem that the existing blockchain data audit method cannot meet the application scenarios with high requirements for data privacy protection and cannot ensure the accuracy of the audit result. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The accompanying drawings here are incorporated into the specification and form a part of this specification, showing embodiments consistent with the present invention and used together with the specification to explain the principles of the present invention.

[0023] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the accompanying drawings required for the description of the embodiments or the prior art. Obviously, for those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0024] One or more embodiments are exemplarily illustrated by the figures in the corresponding accompanying drawings. These exemplary illustrations do not limit the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute a proportional limitation.

[0025] Figure 1 It is a schematic structural diagram of a blockchain data auditing system provided by an embodiment of the present application;

[0026] Figure 2 It is a schematic flowchart of a blockchain data auditing method provided by an embodiment of the present application;

[0027] Figure 3 It is a schematic flowchart of a blockchain data auditing method provided by an embodiment of the present application;

[0028] Figure 4 It is a schematic flowchart of a blockchain data auditing method provided by an embodiment of the present application;

[0029] Figure 5 It is a schematic internal structure diagram of a computer device provided by an embodiment of the present application. Detailed implementation manners

[0030] To make the objectives, technical solutions, and advantages of the embodiments of the present application clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are some, but not all, of the embodiments of the present application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts fall within the scope of protection of the present application.

[0031] The following disclosure provides many different embodiments or examples for implementing different structures of the present invention. To simplify the disclosure of the present invention, the components and settings of specific examples are described below. Of course, they are only examples and are not intended to limit the present invention. In addition, the present invention may repeat reference numerals and / or letters in different examples. This repetition is for the purpose of simplification and clarity, and does not itself indicate the relationship between the various embodiments and / or settings discussed.

[0032] Figure 1Schematic structural diagram of a blockchain data auditing system in an embodiment. Refer to Figure 1 , the blockchain data auditing system includes:

[0033] An audit client 110, configured to initiate an audit request, where the audit request is used to request a data audit result obtained by auditing target block data in a target blockchain 140 according to a preset audit plan;

[0034] An audit blockchain 120, configured to generate an audit event corresponding to the audit request through an audit contract, where the audit event includes a storage location of the target block data, committee nodes that respond to the audit request, and role types of each of the committee nodes, and the role type of the committee node is an audit node 132 or an aggregation node 131; broadcast the audit event, where the audit node 132 is configured to pull the target block data from the target blockchain 140 based on the audit event, and perform an audit process on the target block data according to the preset audit plan to obtain a node audit result, and the aggregation node 131 is configured to perform an aggregation process on the node audit results of multiple audit nodes 132 based on the audit event to obtain a node aggregation result; when receiving the node aggregation result sent by the aggregation node 131, perform a zero-knowledge verification on the audit proof in the node aggregation result by using the audit contract to obtain a verification result; when the verification result is verified, use the audit parameters in the node aggregation result as the data audit result and feedback it to the audit client 110;

[0035] A target blockchain 140, configured to provide target block data to be audited for the audit node 132, and the target blockchain 140 is any blockchain to be audited.

[0036] Specifically, the audit client 110, the audit blockchain 120, and the target blockchain 140 are connected through a network. The audit client 110 is any client that initiates an audit request, and can be specifically implemented by a desktop terminal or a mobile terminal. The mobile terminal can specifically be at least one of a mobile phone, a tablet computer, a laptop computer, etc.

[0037] An intelligent audit contract is deployed on the audit blockchain 120, which is responsible for managing the key information and rule execution of the audit process, such as node registration, status management, result verification, etc. The client becomes a computing node 130 by registering on the audit blockchain 120, that is, the computing node 130 is used to indicate the user node that has successfully completed registration on the audit blockchain 120, and the computing node 130 participates in the audit process to obtain equity rewards. In the initial state, the audit contract does not register the computing node 130. Any user node can provide a public key, an IP address, and equity (Token) to call the audit contract and register a computing node 130. This process allows a wide range of participants to join the audit system, increasing the decentralization and reliability of the audit. The committee composed of computing nodes 130 undertakes the specific audit computing tasks, and the on-chain audit contract and the off-chain computing node 130 cooperate with each other to complete cross-chain data auditing.

[0038] The target blockchain 140 is any to-be-audited blockchain 120 that provides to-be-audited parameters. When different to-be-audited blockchains 120 need to be audited, the audit blockchain 120 can allocate different committee nodes for different to-be-audited blockchains 120 to achieve synchronous auditing of different to-be-audited blockchains 120.

[0039] The blockchain data audit system implements an audit protocol, and the audit protocol applies an incentive mechanism to reward honest node behaviors and punish improper node behaviors. Honest nodes participating in the audit protocol will receive continuous rewards to compensate for the computing resources they provide, and these rewards can encourage more computing nodes 130 to actively and honestly participate in the audit work. While misbehaving computing nodes 130 may be slashed and lose some or all of the deposited equity. The aggregation node 131 filters out misbehaving audit nodes 132 through the aggregation process, that is, misbehaving audit nodes 132 provide audit results different from those of most audit nodes 132. This incentive mechanism helps to maintain the fairness and reliability of the blockchain data audit system and ensure the authenticity of audit results. The audit protocol does not depend on the consensus mechanism of the target blockchain 140 and does not require an additional intermediate blockchain to be added. Therefore, assuming that the connected blockchain supports smart contracts, the proposed audit protocol can be compatible with different blockchains. This makes the protocol have wide applicability and can implement cross-chain data audit functions in different blockchain ecosystems.

[0040] In one embodiment, Figure 2 is a schematic flowchart of a blockchain data audit method in one embodiment. Referring to Figure 2 , a blockchain data audit method is provided. This embodiment mainly takes the application of this method to the audit blockchain 120 in the above Figure 1 as an example to illustrate. The specific steps of this blockchain data audit method are as follows:

[0041] Step S210, when receiving an audit request sent by the audit client 110, generate an audit event corresponding to the audit request through an audit contract, where the audit request is used to request the data audit result after auditing the target block data in the target blockchain 140 according to a preset audit scheme, and the audit event includes the storage location of the target block data, the committee nodes responding to the audit request, and the role types of each of the committee nodes, and the role type of the committee node is an audit node 132 or an aggregation node 131.

[0042] Specifically, the audit client 110 can be a computing node 130 that has been successfully registered in the audit blockchain 120, or it can be a client that has not been registered in the audit blockchain 120. The audit blockchain 120 supports responding to audit requests initiated by different clients. The audit request is a unique request generated by the audit client 110 by invoking the audit contract for the target block data in the target block of the target blockchain. The audit request is used to request an audit process for the target block data stored in the target block of the target blockchain 140. The audit task is the task of responding to the audit request. The audit request includes the blockchain identifier (ChainIDt) of the target blockchain 140, the block identifier (BlockNumber) of the target block, and the audit reward (Reward) for completing the audit task. The audit reward is used to reward the committee nodes with normal audit behavior and punish the misbehaving audit nodes 132, that is, the audit reward includes a gain amount and a penalty amount. The reward value corresponding to the gain amount is a positive number, and the reward value corresponding to the penalty amount is zero or a negative number, which is specifically customized according to the audit task. This is to encourage more computing nodes 130 to actively and honestly participate in the audit work.

[0043] The intelligent audit contract automatically generates corresponding audit events for audit requests to allocate corresponding audit nodes 132 and aggregation nodes 131 for the audit process of target block data. The audit events include request identifiers corresponding to the audit requests, storage locations of the target block data, committee nodes participating in the audit process, and role types of each committee node. The storage location includes the blockchain identifier of the target blockchain 140 and the block identifier of the target block. The role types of the committee nodes are divided into audit nodes 132 and aggregation nodes 131. There is only one aggregation node 131 among multiple committee nodes, and the others are all audit nodes 132. Specifically, all computing nodes can be used as committee nodes, or some of the computing nodes can be selected as committee nodes. When all computing nodes are selected as committee nodes, the aggregation node can be selected from all committee nodes through a random algorithm, and the other computing nodes are used as audit nodes. The audit nodes 132 are used to audit the target block data to obtain node audit results, while the aggregation node 131 is used to aggregate multiple node audit results, thereby filtering out node audit results different from the majority of node audit results to obtain node aggregation results identical to the majority of node audit results, so as to ensure the accuracy of the audit results.

[0044] Step S220: Broadcast the audit event. Among them, the audit node 132 is used to pull the target block data from the target blockchain 140 based on the audit event and perform audit processing on the target block data according to the preset audit plan to obtain node audit results. The aggregation node 131 is used to aggregate the node audit results of multiple audit nodes 132 based on the audit event to obtain node aggregation results.

[0045] Specifically, the audit blockchain 120 broadcasts the audit event to inform each committee node of its role type in the current audit task. After determining its own role type through the audit event, the committee node triggers the execution action corresponding to the role type. If the committee node determines that it is an audit node 132, it pulls the target block data from the target blockchain 140 and performs audit processing according to the preset audit plan to generate node audit results, and sends the node audit results to the aggregation node 131. If the committee node determines that it is an aggregation node 131, it receives the node audit results sent by multiple audit nodes 132 and performs aggregation processing on the multiple node audit results to generate node aggregation results. The audit proof is used to participate in zero-knowledge verification to ensure the correctness of the node aggregation results. The node aggregation results include the audit proof and the aggregated audit parameters. The audit proof is a zero-knowledge proof.

[0046] The auditing node 132 can continuously respond to different auditing requests, that is, it does not need to wait for the verification of the auditing result of the current auditing request to pass before responding to the next auditing request. As long as the response to the current auditing request ends, it can respond to the next auditing request. Different auditing requests can correspond to blockchains with the same structure or different structures. Therefore, a large number of auditing nodes can freely choose to respond to auditing requests for different blockchains at the same time, making the blockchain data auditing system highly concurrent and distributively collaborative.

[0047] Step S230, when receiving the node aggregation result sent by the aggregation node 131, use the auditing contract to perform zero-knowledge verification on the auditing proof in the node aggregation result to obtain a verification result.

[0048] Specifically, the auditing blockchain 120 uses the auditing contract to perform zero-knowledge verification on the auditing proof. Zero-knowledge verification means that the auditing contract verifies the correctness of the auditing result corresponding to the target block data without knowing the target block data, that is, the verification result is used to indicate the correctness of the auditing result corresponding to the target block data. Performing zero-knowledge verification on the auditing proof can complete the verification without obtaining the auditing content, avoiding the leakage of sensitive information, and is suitable for application scenarios with high requirements for data privacy protection.

[0049] Step S240, when the verification result is verification passed, use the auditing parameters in the node aggregation result as the data auditing result and feedback it to the auditing client 110.

[0050] Specifically, when the verification result is verification passed, it means that the node auditing result corresponding to the target block data is correct, and then the node aggregation result can be used as the data auditing result and feedback to the auditing client 110, so as to complete the auditing task corresponding to the auditing request.

[0051] Based on the above method, the auditing blockchain 120 generates corresponding auditing events for the auditing requests through the intelligent auditing contract, allocates multiple auditing nodes 132 and an aggregation node 131 for responding to the auditing requests to the auditing client 110. Each auditing node 132 audits the same target block data respectively to obtain node auditing results. The aggregation node 131 performs aggregation processing on the node auditing results provided by the multiple auditing nodes 132 to obtain node aggregation results. The auditing blockchain 120 performs zero-knowledge verification on the auditing proofs, which can avoid the auditing blockchain 120 from knowing the auditing content, thus avoiding the exposure of sensitive information to meet the application scenarios with high requirements for data privacy protection. And through the aggregation node 131 performing aggregation processing on the node auditing results of the multiple auditing nodes 132, malicious auditing nodes 132 can be filtered, avoiding malicious nodes from tampering with the auditing results or providing false auditing results, thereby improving the accuracy of the auditing results, and solving the problem that the existing blockchain data auditing methods cannot meet the application scenarios with high requirements for data privacy protection and cannot ensure the accuracy of the auditing results.

[0052] In one embodiment, when receiving the auditing request sent by the auditing client 110, generating the auditing event corresponding to the auditing request through the auditing contract includes:

[0053] When receiving the auditing request sent by the auditing client 110,

[0054] Obtain the account information of each computing node 130 from the preset storage unit, where the account information includes the equity balance;

[0055] Screen out the first preset number of the computing nodes 130 in descending order of the equity balance as the committee nodes;

[0056] Determine the role types and role rewards of each of the committee nodes;

[0057] Generate the auditing event corresponding to the auditing request according to the block number of the target block data, the request identifier, the role types and role rewards of each of the committee nodes.

[0058] Specifically, the audit blockchain 120 uses an audit contract to assign a unique request identifier (RequestID) to an audit request. The preset storage unit can be any tool or instrument with storage function, such as Merkle Tree, hash chain, Patricia tree, InterPlanetary File System (IPFS), etc. In this embodiment, the Merkle Tree is used as the preset storage unit. The audit contract uses the Merkle Tree to store the account information of the registered computing nodes 130. The account information includes address, index, public key, and equity balance. There are two major advantages of using the Merkle Tree. One is that it can efficiently verify the integrity and membership of data. The other is that the audit contract does not store the original account data, but only stores summary information such as hash values, protecting the privacy of the computing nodes 130. At the same time, the Merkle root can be updated to apply state changes. This method saves a large amount of costs compared with directly storing and updating a large amount of original data.

[0059] Sort the computing nodes 130 in descending order according to their equity balances, and select the first preset number of computing nodes 130 as committee nodes in descending order. The first preset number is less than the total number of computing nodes. That is, the equity held by the computing nodes 130 is used to select some computing nodes as committee nodes. The higher the equity held by the computing nodes 130, the higher the probability of being selected to participate in the audit. In this way, it is encouraged that the computing nodes 130 hold more equity. If an attacker wants to control a large number of computing nodes 130, they need to have enough equity, resulting in a higher cost. Therefore, the resistance of the blockchain data audit system to the Sybil Attack can be improved.

[0060] The audit contract determines the aggregation node 131 among multiple committee nodes based on a random function. All the committee nodes except the aggregation node 131 among the multiple committee nodes are audit nodes 132. In this way, the role types of each committee node are determined. The role rewards corresponding to different role types are determined based on the audit rewards in the audit request. That is, the audit rewards include gain amounts and penalty amounts, and the gain amounts include the role rewards for different role types. For example, the audit node 132 corresponds to the first role reward, and the aggregation node 131 corresponds to the second role reward. The reward value corresponding to the second role reward is greater than the reward value corresponding to the first role reward. When the node audit result provided by the audit node 132 makes an effective contribution to the final data audit result, the equity balance of the audit node 132 is increased according to the first role reward. Similarly, when the audit proof provided by the aggregation node 131 passes the verification, the equity balance of the aggregation node 131 is increased according to the second role reward. In this way, the equity rewards for different role types are realized.

[0061] An audit event is formed based on the storage location of the target block data (including the blockchain identifier of the target blockchain 140 and the block identifier of the target difference), the request identifier, the role types and role rewards of each committee node, to inform each committee node of its role and rewards in the audit process, so that each committee node can orderly complete its corresponding audit actions.

[0062] In one embodiment, screening out the first preset number of the computing nodes 130 in descending order of equity balance as the committee nodes includes:

[0063] Screening out the first preset number of the computing nodes 130 in descending order of equity balance as the selected nodes, where the computing nodes 130 other than the selected nodes are used as the unselected nodes;

[0064] When receiving a gain request sent by an unselected node, increasing the equity balance corresponding to the unselected node according to the gain request;

[0065] Rescreening out the first preset number of the computing nodes 130 in descending order of equity balance as the selected nodes;

[0066] When no gain request sent by an unselected node is received within a preset duration, using the screened selected nodes as the committee nodes.

[0067] Specifically, the first preset number of computing nodes 130 are sequentially selected as the selected nodes in descending order of the balance of rights and interests. For the computing nodes 130 that are not selected, they are used as unselected nodes. If an unselected node wants to replace a selected node to participate in the audit process, it can apply to join the audit process by increasing its rights and interests. Therefore, when the audit blockchain 120 receives a gain request sent by an unselected node after screening out the selected nodes, the balance of rights and interests of the corresponding unselected node is increased according to the gain request. The gain request includes the public key, the rights and interests to be increased, and the storage proof of the unselected node. The rights and interests to be increased are used to make the balance of rights and interests of the unselected node after gain greater than that of any selected node. The storage proof is a proof indicating that the account information of the unselected node is stored in the preset storage unit. When the preset storage unit is a Merkle tree, the storage proof is the Merkle proof. Since the update of the balance of rights and interests corresponding to the unselected node causes the descending order of the balance of rights and interests to be updated, a selected node is replaced, and the first preset number of computing nodes 130 are reselected as the selected nodes in descending order of the balance of rights and interests. If no gain request sent by an unselected node is received within the preset duration, the selected nodes screened out are used as the committee nodes participating in the audit process. This method ensures that the node committee is always composed of computing nodes 130 with the highest rights and interests. Since nodes with high rights and interests usually have more motivation to maintain the normal operation of the system to protect their own rights and interests, the security and reliability of the audit system can be improved.

[0068] The audit blockchain 120 is further configured to handle the withdrawal of the computing node 130, including:

[0069] When receiving a withdrawal request sent by a target computing node 130, determining the legal status of the target computing node 130 according to the account information of the target computing node 130 and the corresponding Merkle proof. When it is determined that the legal status of the target computing node 130 is legal according to the account information of the target computing node 130 and the corresponding Merkle proof, calculating the delayed withdrawal time corresponding to the target computing node 130, where the delayed withdrawal time is later than the current time by a specified duration; when reaching the delayed withdrawal time corresponding to the target computing node 130, transferring the balance of rights and interests corresponding to the target computing node 130 according to the withdrawal request, and replacing the account information corresponding to the target computing node 130 in the preset storage unit with an empty account. Since the committee usually screens members according to the proportion of rights and interests, the frequent replacement of high-rights users will cause low-rights nodes to be repeatedly squeezed out, and finally the committee will be monopolized by a few high-rights users. Therefore, setting the delayed withdrawal time prevents users with high enough rights and interests from repeatedly removing other committee nodes with lower rights and interests from the audit task by replacing nodes and immediately leaving the system to replace other nodes.

[0070] In one embodiment, when the verification result is verified to pass, the method further includes:

[0071] Updating the storage information of the preset storage unit according to the publicly input data in the node aggregation result, where the publicly input data is the data allowed to be publicly disclosed in the witness data calculated by the aggregation node 131 based on each of the node audit results, and the storage information includes the account information of each of the committee nodes and the state root of the preset storage unit.

[0072] Specifically, the aggregation node 131 is used to calculate witness data according to multiple node audit results. The witness data is used to be incorporated into the constraint circuit program corresponding to zero-knowledge verification to generate an audit proof. The witness data includes publicly input data and privately input data. The publicly input data is the data that can be publicly disclosed, while the privately input data is the privacy data that is not allowed to be publicly disclosed. The publicly input data includes the initial state root (PreStateRoot) corresponding to the preset storage unit before performing the audit task, the end state root (PostStateRoot) corresponding to the preset storage unit after performing the audit task, the block hash (BlockHash) of the target block, the request identifier (RequestID), and the calculated bit vector (AuditorBits).

[0073] Updating the storage information of the preset storage unit according to the publicly input data specifically includes: determining the valid audit nodes 132 that provide effective contributions to the data audit result and the invalid audit nodes 132 that do not provide effective contributions to the data audit result according to the calculated bit vector in the publicly input data, that is, the node audit results provided by the valid audit nodes 132 are the same as and correct compared with the majority of the node audit results, while the node audit results provided by the invalid audit nodes 132 are different from the majority of the node audit results; increasing the equity balances of the valid audit nodes 132 and the party nodes respectively according to the role rewards corresponding to different role types, and updating the equity balance of the invalid audit nodes 132 according to the penalty amount; in the case where the equity balances of each of the committee nodes are updated, updating the state root of the preset storage unit by using the updated equity balances of each of the committee nodes.

[0074] The state root of the preset storage unit refers to the hash value of the root node finally generated in the Merkle tree structure, which represents the encrypted digest of the entire data set. The core role of the state root is to efficiently verify data integrity and quickly locate data changes. The state root is calculated based on the hash values of the root nodes of each computing node 130, and the hash value of the root node of each computing node 130 is the hash value generated based on the account information of the computing node 130. Therefore, when the balance of the computing node 130 changes, the hash value of the root node of the computing node 130 will change, which in turn causes the state root of the preset storage unit to change. However, only when the audit contract determines that the audit proof verification is passed will the storage information in the preset storage unit be substantially changed. During the process of the aggregation node 131 calculating the audit proof, although the account information of the committee nodes will be changed, only the changed account information is separately recorded and used for calculation, and the account information in the preset storage unit is not actually changed, so as to ensure the accuracy of the change of the storage information in the preset storage unit.

[0075] In one embodiment, a blockchain data auditing method is provided. Refer to Figure 3 , which is applied to the computing node 130. The method includes:

[0076] Step S310, when an audit event published by the audit blockchain 120 is monitored, call the audit contract in the audit blockchain 120 to determine the role type of the computing node 130. Among them, the audit event includes the block number of the target block data in the target blockchain 140, the committee nodes responding to the audit request, and the role types of each of the committee nodes. The committee nodes are the computing nodes 130 participating in the audit process, and the role type of the committee node is the audit node 132 or the aggregation node 131.

[0077] Specifically, the committee nodes are the computing nodes 130 related to the audit event. The computing node 130 refers to a client that has successfully registered in the audit blockchain 120. The computing node 130 determines its own role type by monitoring the audit event and parsing the audit event by calling the Query Aggregator function in the audit contract. If it is determined through the audit contract that no role type is assigned to the computing node 130, that is, the role type of the computing node 130 is empty, it means that the computing node 130 does not participate in the audit process; if it is determined through the audit contract that the role type of the computing node 130 is the audit node 132 or the aggregation node 131, then the computing node 130 is used as the committee node participating in the audit process.

[0078] Step S320, when the role type of the computing node 130 is the auditing node 132, pull the target block data from the target blockchain 140 according to the auditing event, and perform auditing processing on the target block data according to the preset auditing scheme to obtain a node auditing result; or,

[0079] Step S330, when the role type of the computing node 130 is the aggregation node 131, perform aggregation processing on the node auditing results of multiple auditing nodes 132 to obtain a node aggregation result, and send the node aggregation result and the auditing proof to the auditing blockchain 120, where the auditing blockchain 120 is used to feedback the node aggregation result as the data auditing result to the auditing client 110 corresponding to the auditing request after the auditing proof is audited and passed.

[0080] Specifically, different auditing actions are performed for computing nodes 130 with different role types. For the auditing node 132, auditing calculations are required. Therefore, the target block data is pulled from the target block in the target blockchain 140 according to the auditing event and audited according to the preset auditing scheme. The preset auditing scheme is the auditing scheme or auditing rule corresponding to the auditing request. Different auditing requests correspond to different auditing schemes. For example, if the auditing request is to check whether the transaction address is in the blacklist, the preset auditing scheme is used to audit whether the transaction address is in the blacklist; if the auditing request is to verify whether the transaction data is correct, the preset auditing scheme is used to audit whether the transaction data is correct. The node auditing result is obtained after auditing according to the preset auditing scheme.

[0081] For the aggregation node 131, it is necessary to aggregate the node auditing results of each auditing node 132 to generate a node aggregation result and an auditing proof, and then send the node aggregation result and the auditing proof to the auditing blockchain 120 for zero-knowledge verification. After the auditing blockchain 120 verifies the auditing proof through the auditing contract, the node aggregation result is feedback to the auditing client 110 as the data auditing result, thereby completing the auditing task.

[0082] In one embodiment, when the role type of the computing node 130 is the auditing node 132, pulling the target block data from the target blockchain 140 according to the auditing event and performing auditing processing on the target block data according to the preset auditing scheme to obtain a node auditing result includes:

[0083] When the role type of the computing node 130 is the auditing node 132, pull the target block data from the target blockchain 140 according to the auditing event, and perform auditing processing on the target block data according to the preset auditing scheme to obtain a node vote;

[0084] Sign the node vote to obtain the node audit result.

[0085] Specifically, the audit node 132 audits the target block data according to a preset audit plan to generate a node vote. The node vote includes the node identifier (AuditorID) of the audit node 132, the request identifier (RequestID) corresponding to the audit request, the audit field (Illegal), and the block hash value (BlockHash) of the target block. The audit field is used to indicate the audit result of the audit node 132 for the target block data. For example, if the audit request is to check whether the transaction address is in the blacklist, the audit field is used to indicate whether the transaction address is in the blacklist or not. Sign the node vote to generate a signed node audit result. The audit node 132 cannot forge an invalid vote. A direct channel (SendAuditedVotes) is established between the audit node 132 and the aggregation node 131. The signed node audit result is sent to the audit node 132 through this channel. The signature ensures the security and integrity of the node audit result during transmission.

[0086] In one embodiment, when the role type of the computing node 130 is the aggregation node 131, aggregating the node audit results of multiple audit nodes 132 to obtain a node aggregation result, and sending the node aggregation result and the audit proof to the audit blockchain 120, including:

[0087] When the role type of the computing node 130 is the aggregation node 131, receive the second preset number of node audit results in the order of the receiving timestamps corresponding to each node audit result, and use the received node audit results as the data to be aggregated. The audit nodes corresponding to the data to be aggregated are used as the participating audit nodes. The second preset number is less than or equal to the first preset number;

[0088] Perform signature verification on each piece of data to be aggregated to obtain the signature verification results corresponding to each participating audit node 132;

[0089] Store the node votes with valid signatures in the memory pool;

[0090] Use the preset algorithm corresponding to the preset audit plan to calculate each node vote in the memory pool to obtain witness data;

[0091] Input the witness data into the constraint circuit program corresponding to the preset audit plan, and execute the constraint circuit program to aggregate multiple node votes in the memory pool to obtain a node aggregation result;

[0092] Send the node aggregation result and the audit proof to the audit blockchain 120.

[0093] Specifically, the aggregation node receives the node audit results of the second preset quantity according to the response speed of each audit node, that is, receives the node audit results of the second preset quantity in the order of the timestamps of receiving each node audit result. The second preset quantity is less than the first preset quantity screened according to the equity balance before. For the node audit results after the second preset quantity, they are no longer received. This ensures that the aggregation node preferentially receives the node audit results sent by the audit nodes with higher response speeds, only uses the received node audit results as the data to be aggregated for subsequent aggregation processing, and uses the audit nodes corresponding to the data to be aggregated as the participating audit nodes. For the audit nodes that have generated node audit results but have not been successfully received by the aggregation node, they are used as the filtered nodes that have not successfully participated in the audit, and no equity rewards will be given to the filtered nodes.

[0094] The aggregation node 131 first performs signature verification processing on each piece of data to be aggregated to determine whether the signature of the data to be aggregated is valid, stores the node votes with valid signatures in the memory pool, and calculates and generates witness data according to the valid node votes and the preset algorithm corresponding to the preset audit plan. That is, the witness data includes public input data and private input data. The public input data is the data that can be made public, while the private input data is the privacy data that is not allowed to be made public. The public input data includes the initial state root (PreStateRoot) corresponding to the preset storage unit before the execution of the audit task, the end state root (PostStateRoot) corresponding to the preset storage unit after the execution of the audit task, the block hash (BlockHash) of the target block, the request identifier (RequestID), and the calculated bit vector (AuditorBits). The private input data includes the account information of the audit node 132 (Auditors), the account information of the aggregation node 131 (Aggregator), and the signature (Signature) of the audit node 132. The preset algorithm corresponding to the preset audit plan is the same as the calculation logic in the preset audit plan, but the preset audit plan is implemented using a constrained circuit program. That is, the calculation logic of the witness data is the same as the calculation logic of the corresponding parameters in the process of generating the audit proof, but the witness data and the audit proof are not calculated using the same calculation tool.

[0095] The constraint circuit program is a program constructed by zk-SNARK for indicating a zero-knowledge verification circuit. The witness data is input into the constraint circuit program, and by executing the constraint circuit program, a node aggregation result and an audit proof are generated. The audit proof is a zero-knowledge proof used to prove that the witness data satisfies the constraint conditions corresponding to the constraint circuit program without revealing the specific content of the witness data, thereby ensuring the privacy and security of the private input data. Then, the node aggregation result and the audit proof are sent to the audit blockchain 120 for on-chain verification.

[0096] In one embodiment, inputting the witness data into the constraint circuit program corresponding to the preset audit scheme and executing the constraint circuit program to perform an aggregation process on the multiple node audit results in the memory pool to obtain a node aggregation result, including:

[0097] Inputting the witness data into the constraint circuit program corresponding to the preset audit scheme and executing the constraint circuit program to obtain a witness value and the node aggregation result;

[0098] Generating the audit proof according to the witness value and the proof key corresponding to the constraint circuit program.

[0099] Specifically, substituting the witness data into the constraint circuit program, obtaining a witness value (Witness) and a node aggregation result by executing the constraint circuit program, and then generating an audit proof Proof based on the proof key (Proving Key, PK) locally stored in the aggregation node 131 and the calculated witness value through the proof method (groth16.Prove) in the zero-knowledge proof library (gnark).

[0100] In one embodiment, executing the constraint circuit program to obtain a witness value and the node aggregation result, including:

[0101] Determining the current voting times of each audit node 132 for the audit request;

[0102] Determining a first root matching result between the pre-aggregation state root corresponding to the preset storage unit and the initial state root in the witness data;

[0103] Aggregate the audit results of multiple nodes to obtain a second aggregation result, where the second aggregation result is used to indicate the voting result of the node with the most votes; when the second aggregation result matches the first aggregation result in the witness data, use the first aggregation result or the second aggregation result as the node aggregation result, and increase the equity balance of the aggregation node 131 according to the first preset reward to obtain the first reward balance of the aggregation node 131; update the intermediate state root corresponding to the preset storage unit based on the first reward balance of the aggregation node 131 to obtain the first state root;

[0104] Traverse the account information of each audit node 132, and verify the legal status of each audit node 132 according to the account information of each audit node 132; use the audit node 132 with a legal status as a node to be rewarded, and increase the equity balance of the node to be rewarded according to the second preset reward to obtain the second reward balance of the node to be rewarded; update the node bit vector and the first state root according to the second reward balance of the node to be rewarded to obtain an intermediate bit vector and a second state root; when the traversal of all node audit results is completed, determine the bit vector matching result between the finally obtained intermediate bit vector and the calculated bit vector in the witness data, and the second root matching result between the finally obtained second state root and the calculated state root in the witness data;

[0105] Determine the witness value based on the bit vector matching result between the finally obtained intermediate bit vector and the calculated bit vector in the witness data, and the second root matching result between the finally obtained second state root and the calculated state root in the witness data.

[0106] Specifically, during the execution of the constraint circuit program, it is used to verify the witness data, and the verification content includes any of the following:

[0107] 1. Determine whether the current voting times of each audit node 132 for the audit request is one, that is, determine whether the number of node audit results initiated by the same audit node 132 for the same audit request is one, so as to ensure that the same audit node 132 does not vote multiple times for the same audit request. For each audit request, each audit node 132 has only one voting opportunity. Therefore, the aggregation node 131 needs to iterate through the node audit results submitted by all audit nodes 132 to ensure that each audit node 132 has only initiated one vote.

[0108] 2. Call the verifyMerkleProof tool to verify whether the initial state root calculated by the aggregation node 131 is consistent with the pre-aggregation state root (preStateRoot) corresponding to the preset storage unit, that is, obtain the first root matching result, ensure that the pre-aggregation state root is consistent with the initial state root calculated by the aggregation node 131, so as to check whether the preset storage unit contains the account information of the aggregation node 131 and ensure the legality of the aggregation node 131.

[0109] 3. Traverse and count the audit results of all nodes, and take the audit results of most of the same nodes as the second aggregation result, that is, the second aggregation result is the same as the audit results of most nodes. And count the first node quantity (Illegal) and the second node quantity (Legal) respectively according to the clustering results of the audit results of each node. The first node quantity is used to indicate the number of audit nodes 132 whose audit results are different from those of most nodes, which is used to indicate the number of audit nodes 132 with misbehavior. The second node quantity is used to indicate the number of audit nodes 132 whose audit results are the same as those of most nodes, which is used to indicate the number of audit nodes 132 with honest behavior. Match the first aggregation result in the witness data with the second aggregation result. If the match is successful, it means that the verification of the first aggregation result in the witness data is successful, then take the first aggregation result or the second aggregation result as the node aggregation result. In the case where the verification of the first aggregation result is successful, it is necessary to give an interest reward to the aggregation node 131. Therefore, increase the interest balance of the aggregation node 131 according to the first preset reward in the audit reward to obtain the first reward balance of the aggregation node 131. At this time, the first reward balance is a recorded value and does not actually reward the interest balance of the aggregation node 131, that is, the interest balance of the aggregation node 131 in the preset storage unit does not change substantially at this time. Update the intermediate state root corresponding to the preset storage unit based on the recorded first reward balance to obtain the first state root. Similarly, the first state root is a recorded value and does not actually change the state root of the preset storage unit, which is for subsequent verification.

[0110] 4. Traverse the account information of each auditing node 132 again, verify the Merkle proof (verifyMerkleProof), message hash (verifyHash), and signature (verifySignature) of each auditing node 132, so as to determine the legal status of each auditing node 132. Take the auditing nodes 132 with a legal status of legal as the nodes to be rewarded. Increase the equity balance of each node to be rewarded according to the second reward balance in the auditing reward to obtain the second reward balance. The second reward balance is also a recorded value and does not actually reward the equity balance of each auditing node 132 in the preset storage unit. The second reward balance is used to update the bit vector and the first state root of the computing node 130. The node bit vector is a binary identifier that records the index and voting results of the auditing nodes 132 participating in the audit. This can be used in zero-knowledge proofs to efficiently verify the membership of a certain set without storing the complete list, thereby reducing the computing and storage overhead. When the bit value in the node bit vector is 1, it means that the auditing node 132 with the corresponding index has made an effective contribution to the node aggregation result, that is, it is determined that the auditing node 132 is an honest computing node 130. When the bit value is 0, it means that the auditing node 132 with the corresponding index has not made an effective contribution to the node aggregation result.

[0111] For example, when only the first auditing node 132 makes an effective contribution, the corresponding index of the first auditing node 132 is validator.Index = 0, then 2^0 = 1, and the node bit vector updated based on the first auditing node 132 is 0001. When only the second auditing node 132 makes an effective contribution, the corresponding index of the second auditing node 132 is validator.Index = 2, then 2^2 = 4, and the node bit vector updated based on the first auditing node 132 is 0100. If both the first auditing node 132 and the second auditing node 132 make effective contributions, validatorBits = 0 + 2^0 + 2^2 = 1 + 4 = 5, which is converted to binary as 0101, indicating that the auditing nodes 132 with indexes 0 and 2 have both made effective contributions to the audit result. The auditing nodes 132 that do not make effective contributions will not be recorded in the node bit vector.

[0112] Compare the intermediate bit vector calculated based on the constraint circuit program with the calculated bit vector in the witness data to obtain the bit vector matching result, and compare the second state root calculated based on the constraint circuit program with the calculated state root in the witness data to obtain the second root matching result, so as to verify the calculated bit vector and the calculated state root in the witness data.

[0113] There is no restriction on the verification order of the above four verification contents. After the above verification contents are verified, a verification value is output. The verification value is used to reflect the verification results of the verification contents participating in the verification and is used to indicate the correctness of the witness data. Based on the bit vector matching result between the finally obtained intermediate bit vector and the calculated bit vector in the witness data, and the second root matching result between the finally obtained second state root and the calculated state root in the witness data, the witness value is determined.

[0114] In a specific embodiment, referring to Figure 4 , the audit request is to request to check whether the transaction address is in the blacklist. The audit process is as follows:

[0115] Step 1: The audit client 110 sends an audit request to the audit blockchain 120 by calling the request function (AuditRequest) in the audit contract. The audit request provides a request identifier (RequestID), the blockchain identifier (ChainIDt) of the target blockchain 140 requested, the block number (BlockNumber) of the target block, and the audit reward (Reward) of the audit node 132 that executes the request.

[0116] Step 2: The audit contract assigns an aggregator node 131 (AggregatorID) and an audit node 132 (AuditorID) to the audit request and triggers an audit event (AuditRequestEvent) (the audit event includes the request identifier, the block number of the target block, the blockchain identifier, and the audit reward) to notify the committee nodes.

[0117] Step 3: After the committee nodes monitor the audit event, they determine their respective current role types by calling the query aggregation function of the audit contract.

[0118] Step 4: The audit node 132 obtains the parameters (request identifier, blockchain identifier, block number) in the audit event, retrieves the block corresponding to the block number of the specified target blockchain 140 according to the blockchain identifier, obtains all the transaction addresses in the block, then checks locally whether the transaction address is in the blacklist, and creates a node vote composed of the audit node 132 identifier (AuditorID), the request identifier (RequestID), the address in the blacklist (Illegal audit field), and the hash value (BlockHash) of the retrieved block. Then, the audit node 132 signs the node vote to obtain the node audit result. Therefore, the auditor cannot forge an invalid vote.

[0119] Step 5: The auditing node 132 establishes a direct channel with the aggregation node 131 and sends the node auditing result with the corresponding signature to the aggregation node 131 through the channel (i.e., implementing SendAuditedVotes).

[0120] Step 6: After receiving the node auditing result from the auditing node 132, the aggregation node 131 performs signature verification processing. If the signature is determined to be valid through signature verification, the aggregation node 131 considers the node vote to be valid and stores the node auditing result in the memory pool of the aggregation node 131. After receiving a majority of valid votes with the same result for the auditing request, the aggregation node 131 starts aggregating the auditing results of the aggregation node 131. During this process, the aggregation node 131 aggregates the auditing vote results locally and generates an auditing proof Proof, which is used to prove that the submitted aggregated result and the changes to the account information of the auditing nodes 132 participating in the audit are correct, that is, to prove that the witness data calculated by the aggregation node 131 is correct.

[0121] Step 7: The aggregation node 131 feeds back the node aggregation result to the auditing contract. The node aggregation result includes public input data and an auditing proof (Proof). The public input data includes a request identifier (RequestID), a block hash (BlockHash), an auditing field (Illegal) used to indicate whether an illegal transaction address is included in the specified block, a calculated bit vector (AuditorBits), and a calculated state root (PostStateRoot). The correctness of the witness data is verified by verifying the Proof.

[0122] Step 8: After successful verification, a contract event is triggered, that is, the auditing parameters in the public input data are fed back to the auditing client 110 as the data auditing result. The auditing parameters include a request identifier (RequestID), a block hash (BlockHash), and an auditing field (Illegal) used to indicate whether an illegal transaction address is included in the specified block, to notify the administrator of the final auditing result.

[0123] Figures 2 to 4 It is a schematic flowchart of a blockchain data auditing method in an embodiment. It should be understood that although Figures 2 to 4 the steps in the flowchart are shown in sequence according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless there is a clear description in this article, the execution of these steps has no strict order limit, and these steps can be executed in other orders. Moreover, Figures 2 to 4At least some of the steps may include multiple sub-steps or multiple stages, and these sub-steps or stages do not necessarily need to be executed and completed at the same time, but can be executed at different times, and the execution order of these sub-steps or stages does not necessarily need to be sequential, but can be executed alternately or in turn with at least some of the other steps or sub-steps or stages of the other steps.

[0124] As Figure 5 shown, an embodiment of the present application provides a computer device, including a processor 711, a communication interface 712, a memory 713, and a communication bus 714. Among them, the processor 711, the communication interface 712, and the memory 713 complete mutual communication through the communication bus 714;

[0125] The memory 713 is used to store computer programs;

[0126] When the processor 711 is used to execute the program stored on the memory 713, it implements the blockchain data auditing method provided by any one of the foregoing method embodiments.

[0127] Those skilled in the art can understand that Figure 5 the structure shown in is only a block diagram of some structures related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine some components, or have different component arrangements.

[0128] In one embodiment, the blockchain data auditing system provided by the present application can be implemented in the form of a computer program, and the computer program can run on a computer device as Figure 5 shown. Each program module constituting the blockchain data auditing system can be stored in the memory of the computer device, and the computer program constituted by each program module enables the processor to execute the blockchain data auditing methods of various embodiments of the present application described in this specification.

[0129] An embodiment of the present application also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the blockchain data auditing method provided by any one of the foregoing method embodiments.

[0130] The system embodiments described above are only illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

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

[0132] It should be understood that the terms used herein are for the purpose of describing specific example embodiments only and are not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms "a", "an", and "the" as used herein may also include the plural form. The terms "comprising", "including", "containing", and "having" are inclusive and thus specify the presence of the stated features, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and / or their combinations. The method steps, processes, and operations described herein are not to be construed as necessarily requiring them to be performed in the particular order described or illustrated, unless the order of performance is explicitly stated. It should also be understood that additional or alternative.

[0133] The above are only specific embodiments of the present invention, enabling those skilled in the art to understand or implement the present invention. Various modifications to these embodiments will be obvious to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to these embodiments shown herein, but rather will be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A blockchain data auditing method, characterized in that, Applied to an auditing blockchain, the method includes: When receiving an audit request sent by at least one audit client, generating an audit event corresponding to the audit request through an audit contract, where the audit request is used to request obtaining the data audit result after auditing the target block data in the target blockchain according to a preset audit scheme, the audit event includes the storage location of the target block data, the committee nodes responding to the audit request, and the role types of each of the committee nodes, the role types of the committee nodes are audit nodes or aggregation nodes, and the target blockchain is a blockchain with any structure; Broadcasting the audit event, where the audit nodes are used to pull the target block data from the target blockchain based on the audit event and perform audit processing on the target block data according to the preset audit scheme to obtain node audit results, and the aggregation nodes are used to perform aggregation processing on the node audit results of multiple audit nodes based on the audit event to obtain node aggregation results; When receiving the node aggregation result sent by the aggregation node, using the audit contract to perform zero-knowledge verification on the audit proof in the node aggregation result to obtain a verification result; When the verification result is verified to pass, using the audit parameters in the node aggregation result as the data audit result and feedbacking it to the audit client.

2. The method according to claim 1, characterized in that, The step of generating an audit event corresponding to the audit request through an audit contract when receiving an audit request sent by an audit client includes: When receiving an audit request sent by an audit client, obtaining the account information of each computing node from a preset storage unit, where the account information includes the equity balance; Screening out the first preset number of the computing nodes in descending order of the equity balance as the committee nodes; Determining the role types and role rewards of each of the committee nodes; Generating the audit event corresponding to the audit request according to the storage location of the target block data, the request identifier, the role types and role rewards of each of the committee nodes.

3. The method according to claim 2, wherein The step of screening out the first preset number of the computing nodes in descending order of the equity balance as the committee nodes includes: Screening out the first preset number of the computing nodes in descending order of the equity balance as the selected nodes, where the computing nodes other than the selected nodes are the unselected nodes; When receiving a gain request sent by an unselected node, increasing the equity balance corresponding to the unselected node according to the gain request; Rescreening out the first preset number of the computing nodes in descending order of the equity balance as the selected nodes; When no gain request sent by an unselected node is received within a preset duration, using the screened selected nodes as the committee nodes.

4. The method according to claim 1, wherein When the verification result is verified to pass, the method further includes: Update the storage information of a preset storage unit according to the publicly disclosed input data in the node aggregation result, where the publicly disclosed input data is the data allowed to be publicly disclosed in the witness data calculated by the aggregation node based on the audit results of each node, and the storage information includes the account information of each committee node and the state root of the preset storage unit.

5. A blockchain data auditing method, characterized in that, Applied to a computing node, the method includes: When an audit event published by the audit blockchain is monitored, call the audit contract in the audit blockchain to determine the role type of the computing node, where the audit event includes the storage location of the target block data in the target blockchain, the committee nodes responding to the audit request, and the role types of each committee node. The committee nodes are the computing nodes participating in the audit process, and the role types of the committee nodes are audit nodes or aggregation nodes; When the role type of the computing node is an audit node, pull the target block data from the target blockchain according to the audit event, and perform audit processing on the target block data according to a preset audit plan to obtain a node audit result; or, When the role type of the computing node is an aggregation node, perform aggregation processing on the node audit results of multiple audit nodes to obtain a node aggregation result, and send the node aggregation result and an audit proof to the audit blockchain, where the audit blockchain is used to feed back the node aggregation result as a data audit result to the audit client corresponding to the audit request after verifying the audit proof.

6. The method according to claim 5, characterized in that, When the role type of the computing node is an audit node, pulling the target block data from the target blockchain according to the audit event, and performing audit processing on the target block data according to the preset audit plan to obtain a node audit result, includes: When the role type of the computing node is an audit node, pull the target block data from the target blockchain according to the audit event, and perform audit processing on the target block data according to the preset audit plan to obtain a node vote; Perform signature processing on the node vote to obtain the node audit result.

7. The method according to claim 6, wherein When the role type of the computing node is an aggregation node, performing aggregation processing on the node audit results of multiple audit nodes to obtain a node aggregation result, and sending the node aggregation result and an audit proof to the audit blockchain, includes: When the role type of the computing node is an aggregation node, receive a second preset number of node audit results in the order of the receive timestamps corresponding to each node audit result, and use the received node audit results as data to be aggregated, and use the audit nodes corresponding to the data to be aggregated as participating audit nodes. The second preset number is less than or equal to the first preset number; Perform signature verification processing on each piece of data to be aggregated to obtain the signature verification results corresponding to each participating audit node; Store the node votes with valid signatures in the memory pool; Use the preset algorithm corresponding to the preset audit plan to calculate the node votes in the memory pool to obtain witness data; Input the witness data into the constraint circuit program corresponding to the preset audit plan, and execute the constraint circuit program to aggregate the votes of multiple nodes in the memory pool to obtain a node aggregation result; Send the node aggregation result and the audit proof to the audit blockchain.

8. The method according to claim 7, wherein Inputting the witness data into the constraint circuit program corresponding to the preset audit plan and executing the constraint circuit program to aggregate the audit results of multiple nodes in the memory pool to obtain a node aggregation result, including: Input the witness data into the constraint circuit program corresponding to the preset audit plan, and execute the constraint circuit program to obtain a witness value and the node aggregation result; Generate the audit proof according to the witness value and the proof key corresponding to the constraint circuit program.

9. The method according to claim 8, wherein Executing the constraint circuit program to obtain a witness value and the node aggregation result, including: Aggregate the audit results of multiple nodes to obtain a second aggregation result, where the second aggregation result is used to indicate the voting result of the node with the largest number of votes; when the second aggregation result matches the first aggregation result in the witness data, use the first aggregation result or the second aggregation result as the node aggregation result, and increase the equity balance of the aggregated node according to the first preset reward to obtain the first reward balance of the aggregated node; update the intermediate state root corresponding to the preset storage unit based on the first reward balance of the aggregated node to obtain the first state root; Traverse the account information of each audit node, and verify the legal status of each audit node according to the account information of each audit node; regard the audit node with a legal status as a node to be rewarded, and increase the equity balance of the node to be rewarded according to the second preset reward to obtain the second reward balance of the node to be rewarded; update the node bit vector and the first state root according to the second reward balance of the node to be rewarded to obtain an intermediate bit vector and a second state root; when the traversal of all the node audit results is completed, determine the bit vector matching result between the finally obtained intermediate bit vector and the calculated bit vector in the witness data, and the second root matching result between the finally obtained second state root and the calculated state root in the witness data; Determine the witness value based on the bit vector matching result between the finally obtained intermediate bit vector and the calculated bit vector in the witness data, and the second root matching result between the finally obtained second state root and the calculated state root in the witness data.

10. A blockchain data auditing system, characterized in that, The system includes: An audit client for initiating an audit request, where the audit request is used to request the data audit result after auditing the target block data in the target blockchain according to a preset audit plan; An auditing blockchain is used to generate an auditing event corresponding to the auditing request through an auditing contract. The auditing event includes the storage location of the target block data, the committee nodes responding to the auditing request, and the role types of each of the committee nodes. The role type of the committee node is an auditing node or an aggregation node; broadcast the auditing event. Among them, the auditing node is used to pull the target block data from the target blockchain based on the auditing event, and perform auditing processing on the target block data according to the preset auditing scheme to obtain a node auditing result. The aggregation node is used to perform aggregation processing on the node auditing results of multiple auditing nodes based on the auditing event to obtain a node aggregation result; when receiving the node aggregation result sent by the aggregation node, use the auditing contract to perform zero-knowledge verification on the auditing proof in the node aggregation result to obtain a verification result; when the verification result is verification passed, use the auditing parameters in the node aggregation result as the data auditing result and feedback it to the auditing client; A target blockchain is used to provide target block data to be audited for the auditing node, and the target blockchain is any blockchain to be audited.

11. A computer device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1 to 9.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the method according to any one of claims 1 to 9.

Images