Data processing methods, devices, equipment, and media based on blockchain systems

Abstract

This application discloses a data processing method, apparatus, device, medium, and product based on a blockchain system. The method includes: a consensus node acquiring a business processing strategy generated by a business party, the business processing strategy including business contract information and a proof algorithm, the proof algorithm being associated with a proof key and a verification key; uploading the business contract information and verification key to the blockchain; distributing the business processing strategy to business nodes; receiving transaction data and first proof data sent by the business nodes, the transaction data being generated by the business contract corresponding to the information triggered by the business node, and the first proof data being obtained by the business node proving the transaction data based on the proof key; verifying the first proof data based on the transaction data and the verification key, and sending the verification result and transaction data to the business party. The technical solution of this application significantly optimizes data processing schemes based on blockchain systems.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a data processing method, apparatus, electronic device, computer-readable storage medium, and computer program product based on a blockchain system. Background Technology

[0002] Currently, blockchain systems include consensus networks and business networks (also known as witness networks). The consensus network includes consensus nodes that reach consensus on data blocks and record the data blocks on the blockchain. The business network includes business nodes, which can verify the data blocks recorded on the blockchain by the consensus nodes or request corresponding transaction data from the consensus nodes.

[0003] In related technologies, any business node in a business network can trigger the execution of a business contract (also known as a local contract). However, the execution of the business contract is not recorded on the blockchain. Therefore, other business nodes in the business network cannot determine whether any particular business node has actually triggered the execution of the business contract.

[0004] It is evident that ensuring the authenticity of business contract execution triggered by business nodes is a problem that urgently needs to be solved. Summary of the Invention

[0005] To address the aforementioned technical problems, embodiments of this application provide a data processing method and apparatus, electronic device, computer-readable storage medium, and computer program product based on a blockchain system, thereby at least to a certain extent ensuring the authenticity of the execution of business contracts triggered by business nodes.

[0006] According to one aspect of the embodiments of this application, a data processing method based on a blockchain system is provided. The blockchain system includes a consensus network with consensus nodes deployed and a business network with business nodes deployed. The method is executed by the consensus nodes and includes: obtaining a business processing strategy generated by a business party, the business processing strategy including business contract information and a proof algorithm, the proof algorithm being associated with a proof key and a verification key; uploading the business contract information and the verification key associated with the proof algorithm to the blockchain; distributing the business processing strategy to the business nodes; receiving transaction data and first proof data sent by the business nodes; wherein the transaction data is generated by the business node triggering a business contract corresponding to the information of the business contract, and the first proof data is obtained by the business node proving the transaction data based on the proof key associated with the proof algorithm; verifying the first proof data based on the transaction data and the verification key associated with the proof algorithm to obtain a first verification result, and sending the first verification result and the transaction data to the business party.

[0007] According to one aspect of the embodiments of this application, a data processing method based on a blockchain system is provided. The blockchain system includes a consensus network with consensus nodes deployed and a business network with business nodes deployed. The method is executed by the business nodes and includes: receiving a business processing strategy generated by a business party sent by the consensus node, the business processing strategy including business contract information and a proof algorithm; triggering the execution of the business contract based on a call request for the business contract corresponding to the information of the business contract sent by the business party, generating transaction data; proving the transaction data based on a proof key associated with the proof algorithm, generating first proof data; sending the transaction data and the first proof data to the consensus node, so that the consensus node verifies the first proof data based on the transaction data and the verification key associated with the proof algorithm, obtaining a first verification result, and sending the first verification result and the transaction data to the business party.

[0008] According to one aspect of the embodiments of this application, a data processing apparatus based on a blockchain system is provided. The blockchain system includes a consensus network with consensus nodes and a business network with business nodes. The apparatus is configured on the consensus nodes and includes: an acquisition module configured to acquire a business processing strategy generated by a business party, the business processing strategy including business contract information and a proof algorithm, the proof algorithm being associated with a proof key and a verification key, and uploading the business contract information and the verification key associated with the proof algorithm to the blockchain; a distribution module configured to distribute the business processing strategy to the business nodes; a first receiving module configured to receive transaction data and first proof data sent by the business nodes; wherein the transaction data is generated by the business node triggering a business contract corresponding to the information of the business contract, and the first proof data is obtained by the business node proving the transaction data based on the proof key associated with the proof algorithm; and a verification module configured to verify the first proof data based on the transaction data and the verification key associated with the proof algorithm, obtain a first verification result, and send the first verification result and the transaction data to the business party.

[0009] In one embodiment of this application, based on the foregoing scheme, the verification module is specifically configured to: obtain the verification key associated with the proof algorithm from the consensus network; verify the first proof data based on the verification key to obtain a first verification result; if the first verification result indicates that the first proof data matches the transaction data, then determine that the verification of the first proof data has passed.

[0010] In one embodiment of this application, based on the foregoing scheme, the first receiving module is further configured to receive second proof data sent by the service node; wherein, the second proof data is obtained by the service node proving the plaintext data used to calculate the transaction data based on the proof key associated with the proof algorithm; the verification module is further configured to verify the second proof data based on the ciphertext data and the verification key associated with the proof algorithm, obtain a second verification result, and send the second verification result to the service party.

[0011] In one embodiment of this application, based on the foregoing scheme, the verification module is specifically configured to: obtain the verification key associated with the proof algorithm from the consensus network; verify the second proof data based on the verification key to obtain a second verification result; if the second verification result indicates that the second proof data matches the ciphertext data, then it is determined that the verification of the second proof data has passed.

[0012] In one embodiment of this application, based on the foregoing scheme, the acquisition module is specifically configured to: receive a deployment request sent by the business party; wherein the deployment request carries a business processing strategy generated by the business party, and the deployment request is used to deploy the business processing strategy; and acquire the business processing strategy from the deployment request.

[0013] In one embodiment of this application, based on the foregoing scheme, the distribution module is specifically configured to: receive a service processing strategy synchronization request sent by the service node; and distribute the service processing strategy to the service node according to the service processing strategy synchronization request, so that the service node can deploy the service processing strategy.

[0014] According to one aspect of the embodiments of this application, a data processing apparatus based on a blockchain system is provided. The blockchain system includes a consensus network with consensus nodes deployed and a business network with business nodes deployed. The apparatus is configured on the business nodes and includes: a second receiving module configured to receive a business processing strategy generated by a business party sent by the consensus node, the business processing strategy including business contract information and a proof algorithm; a first generating module configured to trigger the execution of the business contract and generate transaction data based on a call request for the business contract corresponding to the information of the business contract sent by the business party; a second generating module configured to prove the transaction data based on a proof key associated with the proof algorithm and generate first proof data; and a sending module configured to send the transaction data and the first proof data to the consensus node, so that the consensus node verifies the first proof data based on the transaction data and the verification key associated with the proof algorithm, obtains a first verification result, and sends the first verification result and the transaction data to the business party.

[0015] In one embodiment of this application, based on the foregoing scheme, the second generation module is specifically configured to: receive the proof key associated with the proof algorithm sent by the business party; prove the transaction data based on the proof key to generate the first proof data.

[0016] In one embodiment of this application, based on the foregoing scheme, the second generation module is further configured to prove the plaintext data based on the proof key associated with the proof algorithm, and generate second proof data; the sending module is further configured to send the second proof data to the consensus node, so that the consensus node verifies the second proof data based on the ciphertext data used to calculate the transaction data and the verification key associated with the proof algorithm, obtains a second verification result, and sends the second verification result to the business party.

[0017] In one embodiment of this application, based on the foregoing scheme, the second generation module is specifically configured to: receive the proof key associated with the proof algorithm sent by the business party; prove the plaintext data based on the proof key, and generate the second proof data.

[0018] According to one aspect of the embodiments of this application, an electronic device is provided, including one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to implement the data processing method based on a blockchain system as described above.

[0019] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a computer's processor, causes the computer to perform the data processing method based on a blockchain system as described above.

[0020] According to one aspect of the embodiments of this application, a computer program product is provided, including computer instructions that, when executed by a processor, implement the data processing method based on a blockchain system as described above.

[0021] In the technical solution provided by the embodiments of this application, on the one hand, the business party generates a business processing strategy, which includes business contract information and a proof algorithm. This strategy only needs to be transparently transmitted to the consensus node, allowing the consensus node to flexibly distribute the business processing strategy to the business nodes as needed. This makes the business processing strategy obtained by the business nodes flexible and adaptable, with a wider range of application scenarios. Furthermore, since the business party is the generator of the business processing strategy, it has no malicious intent, thus improving the security of data processing based on the business processing strategy to a certain extent. On the other hand, the business nodes prove the transaction data. Therefore, the business nodes prove to other business nodes that they have triggered the execution of the business contract, thereby ensuring the authenticity of the execution of the business contract triggered by the business nodes and preventing malicious actions by business nodes that could arbitrarily fabricate the execution results of the business contract.

[0022] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0024] Figure 1 This is a schematic diagram of a zero-knowledge proof circuit;

[0025] Figure 2 This is a schematic diagram of the blockchain network structure;

[0026] Figure 3 This is a diagram illustrating the connection relationships between blocks in a blockchain.

[0027] Figure 4 This is a schematic diagram illustrating the process of generating a block;

[0028] Figures 5 to 7This is a diagram illustrating the architecture of the blockchain system used in the embodiments of this application.

[0029] Figure 8 This is a diagram illustrating how a business node triggers the execution of a business contract.

[0030] Figure 9 This is a schematic diagram of an exemplary blockchain system to which the technical solutions of the embodiments of this application can be applied;

[0031] Figure 10 This is a flowchart illustrating a data processing method based on a blockchain system, as shown in an exemplary embodiment of this application;

[0032] Figure 11 yes Figure 10 A flowchart of step S1001 in an exemplary embodiment shown in the illustrated example;

[0033] Figure 12 yes Figure 10 A flowchart of step S1001 in an exemplary embodiment shown in the illustrated example;

[0034] Figure 13 yes Figure 10 A flowchart of step S1002 in an exemplary embodiment shown in the illustrated example;

[0035] Figure 14 yes Figure 10 A flowchart of step S1002 in an exemplary embodiment shown in the illustrated example;

[0036] Figure 15 yes Figure 10 A flowchart of step S1004 in an exemplary embodiment shown in the illustrated example;

[0037] Figure 16 This is a flowchart illustrating a data processing method based on a blockchain system, as shown in an exemplary embodiment of this application;

[0038] Figure 17 yes Figure 16 A flowchart of step S1602 in an exemplary embodiment shown in the illustrated example;

[0039] Figure 18 This is a flowchart illustrating a data processing method based on a blockchain system, as shown in an exemplary embodiment of this application;

[0040] Figure 19 yes Figure 18 A flowchart of step S1803 in an exemplary embodiment shown in the illustrated example;

[0041] Figure 20This is a flowchart illustrating a data processing method based on a blockchain system, as shown in an exemplary embodiment of this application;

[0042] Figure 21 yes Figure 20 A flowchart of step S2001 in an exemplary embodiment shown in the illustrated example;

[0043] Figure 22 This is a schematic diagram of an exemplary blockchain system to which the technical solutions of the embodiments of this application can be applied;

[0044] Figure 23 This is a flowchart illustrating a data processing method based on a blockchain system, as shown in an exemplary embodiment of this application;

[0045] Figure 24 This is a block diagram illustrating a data processing apparatus based on a blockchain system, as shown in an exemplary embodiment of this application;

[0046] Figure 25 This is a block diagram illustrating a data processing apparatus based on a blockchain system, as shown in an exemplary embodiment of this application;

[0047] Figure 26 This is a schematic diagram of the structure of a computer system suitable for implementing the electronic devices of the present application embodiments. Detailed Implementation

[0048] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments identical to those of this application. Rather, they are merely examples of apparatuses and methods identical to some aspects of this application as detailed in the appended claims.

[0049] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0050] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0051] It should be noted that "multiple" as mentioned in this application refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0052] Before introducing the technical solutions of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0053] ZKP (Zero Knowledge Proof): A proof allows one party (the prover) to demonstrate to another party (the verifier) ​​that a statement is true without revealing any information beyond the validity of the statement itself; for example, given the hash of a random number, the prover can convince the verifier that a number with that hash value does exist without revealing what it is.

[0054] zk-SNARK (zero-knowledge succinct non-interactive argument of knowledge): Zero knowledge refers to zero-knowledge proof; Succinctness refers to the shortness of the evidence information, making it easy to verify; Non-interactivity refers to the almost complete lack of interaction, meaning the prover essentially only needs to provide a string for verification, which is crucial for blockchain as it means the message can be publicly verified on-chain; Arguments refers to the computationally soundness of the proof process, making it impossible for the prover to fabricate a false proof within a reasonable timeframe; and of knowledge means that it is impossible for a prover to construct a valid zero-knowledge proof without knowing the specific proof.

[0055] The zk-SNARK principle can be divided into four steps: Step one, transforming the proposition to be proven into a zero-knowledge proof circuit, for example... Figure 1As shown, a zero-knowledge proof circuit for the expression (a + b) × b × c is illustrated, where the circuit is in the form of R1CS (Rank One Constraint System, a language for describing circuits). It can be understood that computational logic, such as calculating expressions and hash values, can be represented as an R1CS circuit. Step two involves using a generation algorithm to generate public parameters, a prover's key, and a verifier's key for the proposition to be proven. The public parameters in the generated data are randomly generated and cannot be disclosed; disclosure would compromise the security of the proof. Step three involves the prover transforming the proposition to be proven into an R1CS circuit and generating proof data using the proof key. Step four involves the verifier verifying the proof data using the verifier's key.

[0056] Next, we will introduce the blockchain technology used in the embodiments of this application.

[0057] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks (i.e., blocks) linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and to generate the next block. A blockchain can include an underlying platform, a platform product service layer, and an application service layer.

[0058] The underlying blockchain platform can include modules for user management, basic services, smart contracts, and operations. The user management module is responsible for managing the identity information of all blockchain participants, including maintaining public and private key generation (account management), key management, and maintaining the correspondence between user real identities and blockchain addresses (access management). Under authorization, it also monitors and audits transactions of certain real identities and provides risk control rule configuration (risk control audit). The basic service module is deployed on all blockchain node devices to verify the validity of business requests. After consensus is reached on valid requests, they are recorded in storage. For a new business request, the basic service first performs interface adaptation parsing and authentication (interface adaptation), then encrypts the business information using a consensus algorithm (consensus management), and transmits it completely and consistently to the shared ledger (network communication) for recording and storage. The smart contract module is responsible for contract registration, issuance, triggering, and execution. Developers can define contract logic using a programming language and publish it to the blockchain (contract registration). Based on the contract terms, it calls keys or other events to trigger execution, completing the contract logic. It also provides functions for contract upgrades and cancellations. The operations module is mainly responsible for deployment, configuration modification, contract settings, cloud adaptation, and real-time status visualization output during product launch, such as alarms.

[0059] The platform's product service layer provides basic capabilities and implementation frameworks for typical applications. Developers can leverage these basic capabilities and add business characteristics to complete the blockchain implementation of business logic.

[0060] The application service layer provides application services based on blockchain solutions for use by business participants.

[0061] As mentioned above, a blockchain is essentially a decentralized database, and it is maintained collaboratively by nodes within a blockchain network. For example, please refer to [link to relevant documentation]. Figure 2 ,exist Figure 2 The blockchain network shown may include multiple nodes 201, which can be various clients forming the blockchain network. Each node 201, in its normal operation, receives input information and maintains shared data within the blockchain network based on this information. To ensure information exchange within the blockchain network, information connections can exist between each node, allowing for information transmission. For example, when any node in the blockchain network receives input information, other nodes in the network obtain this input information according to a consensus algorithm and store it as shared data, ensuring consistency of data stored on all nodes in the blockchain network.

[0062] Each node in a blockchain network has a corresponding node identifier, and each node can store the node identifiers of other nodes. This allows for the broadcast of generated blocks to other nodes in the blockchain network based on their node identifiers. Each node can maintain a list of node identifiers, storing the node name and its corresponding node identifier in this list. The node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node.

[0063] Each node in a blockchain network stores the same blockchain. A blockchain consists of multiple blocks; please refer to [link to relevant documentation]. Figure 3 A blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores input information features, version number, timestamp, and difficulty value, while the block body stores the input information. The next block after the genesis block takes the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the input information features of the current block, the block header features of the parent block, version number, timestamp, and difficulty value, and so on. This ensures that the block data stored in each block is related to the block data stored in the parent block, guaranteeing the security of the input information in the blocks.

[0064] When generating individual blocks in the blockchain, please refer to Figure 4 When a node in the blockchain receives input information, it verifies the input. After verification, it stores the input information in a memory pool and updates its hash tree used to record the input. Then, it updates the timestamp to the time the input information was received and attempts to generate different random numbers, performing feature value calculations multiple times. When a random number that meets the conditions is obtained, the information is stored, generating a block header and block body, thus obtaining the current block. Subsequently, the node in the blockchain sends the newly generated block to other nodes in its data sharing system based on the node identifiers of other nodes. These other nodes verify the newly generated block and add it to their stored blockchain after verification. Nodes can use consensus algorithms to verify the newly generated block, including but not limited to: Proof-of-Work (PoW). of Work (proof of work), Pos (proof of work) of Stake (Proof of Stake), DPoS (Delegated Proof of Stake), PBFT (Practical Byzantine Fault Tolerance), Paxos (a distributed algorithm), and Raft (a distributed consensus algorithm).

[0065] Optionally, each node in the blockchain network can be a server or a terminal device. A server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. Terminal devices can be smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, smart home devices, in-vehicle terminals, etc., but are not limited to these. Nodes can be directly or indirectly connected via wired or wireless communication, and this application does not impose any restrictions on this.

[0066] The aforementioned cloud computing refers to the delivery and usage model of IT infrastructure, specifically the acquisition of required resources through the network in an on-demand and easily scalable manner. In a broader sense, cloud computing refers to the delivery and usage model of services, namely, the acquisition of required services through the network in an on-demand and easily scalable manner. These services can be IT and software-related, internet-related, or other services. Cloud computing is a product of the convergence and development of traditional computer and network technologies such as grid computing, distributed computing, parallel computing, utility computing, network storage technologies, virtualization, and load balancing. Driven by the development of the internet, real-time data streams, the diversification of connected devices, and the demands of search services, social networks, mobile commerce, and open collaboration, cloud computing has developed rapidly. Unlike previous parallel and distributed computing, the emergence of cloud computing will, conceptually, drive a revolutionary change in the entire internet model and enterprise management model.

[0067] Based on blockchain technology, embodiments of this application propose an architecture for a blockchain system. For example... Figure 5 As shown, the blockchain system includes a consensus network 2 and a business network 1. The consensus network 2 includes consensus nodes 21 that reach consensus on data blocks and record them on the blockchain. The business network 1 includes business nodes 11, which can verify the data blocks recorded on the blockchain by the consensus nodes 21, or request corresponding transaction data from the consensus nodes 21.

[0068] Specifically, the verification of the data block recorded on the blockchain by the consensus node 21 by the business node 11 may include the following steps: A consensus node 21 in consensus network 2 uses a key specific to itself to generate a signature based on the transaction information to be included in a data block to be added to the blockchain; the consensus node 21 adds the transaction information and the generated signature to the data block and adds it to the blockchain; the consensus node 21 sends the signature to the business node 11 in business network 1, and the business node 11 verifies the signature using a key specific to itself, thereby enabling the business node 11 to verify the data block recorded on the blockchain by the consensus node 21. The consensus node 21 in consensus network 2 is responsible for recording data blocks to the blockchain, and the business node 11 in business network 1 is responsible for witnessing the results recorded by the consensus node 21. Specifically, the consensus node 21 generates a signature based on the transaction information to be included in a data block to be added to the blockchain, and then adds the transaction information and the generated signature to the data block for on-chain processing. The signature is then sent to business node 11 in business network 1, where business node 11 verifies the signature using a key specific to consensus node 21. Business node 11 in business network 1 can witness the transaction data of the entire network by verifying the signature of consensus node 21 on the block. Although consensus network 2 possesses a monopoly on bookkeeping rights, all actions are publicly traceable because the data blocks have digital signatures representing the bookkeeper's identity. If consensus nodes 21 collectively act maliciously, all nodes in business network 1 will retain evidence of the malicious actions of specific consensus nodes 21. Compared to traditional centralized systems and private blockchains, the system in this embodiment operates more transparently; and compared to traditional decentralized solutions, this solution is more controllable and easier to supervise.

[0069] In one embodiment of this application, consensus network 2 and business network 1 can be connected via proxy node 12. Proxy node 12 can be a business node 11 of business network 1, responsible for transmitting information from consensus node 21 to business node 11. Business node 11 is the terminal of the transaction party that generates various transaction data that needs to be uploaded to the blockchain, and can also be a terminal that queries transaction data from consensus network 2. The transaction data generated by business node 11 is transmitted to consensus node 21 through proxy node 12, and then recorded on the blockchain after consensus. This facilitates the unified processing and supervision of transaction data. Business node 11 can also supervise and witness the uploading of transaction data to the blockchain through information sent by consensus node 21 via proxy node 12. This is of great significance in scenarios where unified supervision is needed, but there is also a fear of collective cheating by the monitored nodes.

[0070] exist Figure 5In the structure shown, business network 1 adopts a P2P (Peer-to-Peer) network model. A P2P network is a distributed application architecture that distributes tasks and workloads among peers. It is a network form or topology of the peer-to-peer computing model at the application layer, i.e., a "point-to-point" or "end-to-end" network. It can be defined as follows: network participants share a portion of their hardware resources (processing power, storage capacity, network connectivity, printers, etc.). These shared resources provide services and content through the network and can be directly accessed by other peer nodes without going through an intermediary entity. Participants in this network are both providers and recipients of resources, services, and content. Therefore, in business network 1, when proxy node 12 receives a message from consensus node 21, it propagates it to surrounding business nodes 11. The surrounding business nodes 11 receive the message and then propagate it to their neighboring business nodes 11, achieving the propagation of the message among all business nodes 11 in business network 1.

[0071] Figure 6 This illustrates the architecture of another blockchain system used in the embodiments of this application. This architecture is similar to... Figure 5 The difference in the architecture shown is that, instead of a P2P network model, a broadcast network model is adopted in business network 1. Specifically, after receiving a message from consensus node 21, proxy node 12 broadcasts the message to other business nodes 11 in business network 1. In this way, the message is also propagated among each business node 11 in business network 1.

[0072] Figure 7 This illustrates another blockchain system architecture used in embodiments of the present invention. This architecture is similar to... Figure 5The difference in the illustrated architecture lies in that its consensus network 2 is divided into multiple branch consensus networks 2. Each branch consensus network 2 is responsible for recording a specific type of transaction information. For example, a company may have supply chain finance business and may need to record contract information, outstanding payments, and other information generated during the supply and sales process on the blockchain. Simultaneously, the company also needs to issue invoices and record invoice information and invoice reimbursement information on the blockchain. In this case, to facilitate the supervision of consensus nodes 21 by the same department, the consensus node 21 recording supply chain finance transactions and the consensus node 21 recording transactions during the invoice circulation process may belong to different departments. For example, the consensus node 21 recording supply chain finance transactions might be an accounting terminal set up by a bank, while the consensus node 21 recording transactions during the invoice circulation process might be an accounting terminal set up by the State Taxation Administration. Furthermore, supply chain finance transactions and transactions recording invoice circulation processes may ultimately be recorded on different branch consensus networks 2. In this case, the agent node 12, based on the transaction type carried in the transaction information sent from the business node 11, sends the transaction information to the branch consensus network 2 corresponding to that transaction type.

[0073] It should be noted that, in Figures 5 to 7 In the architecture of the blockchain system shown, the proxy node 12 is located in the business network 1. In other embodiments of this application, the proxy node 12 may also be located in the consensus network 2, or be independent of the business network 1 and the consensus network 2.

[0074] Understandably, in Figures 5 to 7 In the illustrated blockchain system architecture, the blockchain system may include smart contracts. A smart contract can be understood as code that can be understood and executed by all nodes in the blockchain, capable of performing arbitrary computational logic and obtaining results. Specifically, smart contracts deployed on the consensus nodes of consensus network 2 can be collectively referred to as on-chain contracts, and smart contracts deployed and running only on the business nodes of business network 1 can be collectively referred to as business contracts.

[0075] Optionally, a blockchain system may include one or more smart contracts. These smart contracts can be distinguished by contract identifiers (such as identity document IDs) or names, and may also include contract addresses or contract function names (also known as contract method names). The contract call request initiated by the terminal may also carry the smart contract's identifier or name to specify the smart contract that the blockchain needs to run.

[0076] In related technologies, Figures 5 to 7 The architecture of the blockchain system shown can be applied to electronic invoice application scenarios, such as... Figure 8As shown, a business contract for verifying invoice request parameters is deployed on business node 11. The execution of this business contract is then triggered to verify the invoice request parameters. After successful verification, the data is forwarded to consensus node 21 and uploaded to the core chain. Other business nodes, such as business node 12, can send a synchronized invoice request to the core chain if they have the necessary permissions. However, during this process, the execution of the business contract triggered by business node 11 is not uploaded to the core chain. Therefore, business node 12 cannot perceive whether business node 11 has actually triggered the execution of the business contract. This raises the possibility that business node 11 could act maliciously and arbitrarily fabricate the execution result of the business contract. Currently, there is no clear solution in relevant technologies for ensuring the authenticity of the execution of business contracts triggered by business nodes.

[0077] Based on the aforementioned blockchain technology and the problem in related technologies where the authenticity of business contract execution triggered by business nodes cannot be determined, embodiments of this application provide a data processing method based on a blockchain system. Specifically, in one application scenario of this application, please refer to... Figure 9 It mainly includes business party 901, consensus nodes in consensus network 902, and business nodes in business network 903; among them, business party 901, consensus nodes, and business nodes can communicate with each other.

[0078] In this context, business party 901 can be a user requesting the execution of a transaction or a user requesting the deployment of a smart contract. It can invoke a pre-deployed smart contract (either a local contract or an on-chain contract) in the blockchain system by initiating a contract call request (also known as a transaction request) through a client on a terminal device. Optionally, business party 901 can be located in business network 1, consensus network 2, or independently of both. Optionally, business party 901 can be a credit-related institution, such as banks.

[0079] Among them, the consensus node is the consensus node 21 in the aforementioned consensus network 2.

[0080] The business node is the business node 11 in the aforementioned business network 1. Optionally, the business node can be an authoritative institution, such as a government department, which may possess some of the privacy data of enterprises / individuals; the business node can also be an enterprise / individual.

[0081] In one embodiment of this application, the consensus node can obtain the business processing strategy generated by business party 901. The business processing strategy includes a business contract and a proof algorithm. The proof algorithm is associated with a proof key and a verification key. The consensus node puts the business contract and the verification key associated with the proof algorithm on the blockchain, and then distributes the business processing strategy to the business node. Accordingly, the business node receives the business processing strategy generated by business party 901 sent by the consensus node, and then triggers the execution of the business contract according to the call request for the business contract sent by business party 901, generating transaction data. Then, it proves the transaction data based on the proof key associated with the proof algorithm to generate first proof data, and then sends the transaction data and the first proof data to the consensus node. Accordingly, the consensus node receives the transaction data and the first proof data sent by the business node, and then verifies the first proof data based on the transaction data and the verification key associated with the proof algorithm to obtain a first verification result, and sends the first verification result and the transaction data to business party 901.

[0082] The following details the various implementation details of the technical solutions in the embodiments of this application:

[0083] Please see Figure 10 , Figure 10 This is a flowchart illustrating a data processing method based on a blockchain system, as shown in one embodiment of this application. This data processing method based on a blockchain system can be... Figure 9 The consensus network 902 in the blockchain system shown executes the process. Figure 10 As shown, the data processing method based on the blockchain system includes at least steps S1001 to S1004, which are described in detail below:

[0084] Step S1001: Obtain the business processing strategy generated by the business party. The business processing strategy includes business contract information and proof algorithm. The proof algorithm is associated with a proof key and a verification key. Upload the business contract information and the verification key associated with the proof algorithm to the blockchain.

[0085] In this embodiment, the business processing strategy refers to the relevant strategy for processing business operations. This strategy is generated and distributed / published / sent / transmitted to the consensus node by the business party. It is understood that the business processing strategy includes business contract information and a proof algorithm. The business contract information includes, but is not limited to, business contract identifier, business contract name, business contract address, business contract function name, and the specific computational logic of the business contract. The business contract corresponding to this information is a smart contract deployed and runs only on business nodes within the business network, and the proof algorithm is also a proof algorithm deployed and runs only on business nodes within the business network.

[0086] In one embodiment of this application, the proof algorithm can be a zero-knowledge proof (zkp) algorithm. Zero-knowledge proof algorithms include, but are not limited to, zero-knowledge concise non-interactive knowledge proof (zk-SNARK) algorithms, elliptic curve cryptography algorithms, and RSA algorithms. In practical applications, the proof algorithm can be flexibly adjusted according to the specific application scenario.

[0087] In this embodiment, the proof algorithm is associated with a proof key and a verification key, both of which are generated by the business party. Specifically, the proof key and verification key are generated when the proof algorithm is generated. For the proof key, the business party sends it to the business network, allowing business nodes to obtain the proof key and use it to prove relevant data involved in the transaction. For the verification key, the business party sends it to the consensus network, allowing consensus nodes to obtain the verification key and verify the data proven by the business nodes.

[0088] In one embodiment of this application, the business party can send the business processing strategy and the verification key associated with the proof algorithm included in the business processing strategy to the consensus node. In this way, the consensus node can receive the business processing strategy and the verification key associated with the proof algorithm included in the business processing strategy, and then put the business contract included in the business processing strategy and the verification key associated with the proof algorithm included in the business processing strategy on the blockchain.

[0089] In one embodiment of this application, the business party may first send the generated business processing strategy and then send the verification key associated with the proof algorithm included in the business processing strategy, or the business party may first send the verification key associated with the proof algorithm included in the generated business processing strategy and then send the business processing strategy. In this way, the consensus node business can also receive the business processing strategy and the verification key associated with the proof algorithm included in the business processing strategy, thereby putting the business contract included in the business processing strategy and the verification key associated with the proof algorithm included in the business processing strategy on the chain.

[0090] In this embodiment, the verification key associated with the business contract and the proof algorithm is uploaded to the core chain. This allows consensus nodes to obtain the business contract from the core chain as needed and distribute it to business nodes. At the same time, consensus nodes can obtain the verification key associated with the proof algorithm from the core chain as needed to verify the data proved by the business nodes.

[0091] In one embodiment of this application, please refer to Figure 11 The process of obtaining the business processing strategy generated by the business party in step S1001 may include steps S1101 to S1102, which are described in detail below:

[0092] Step S1101: Receive a deployment request sent by the business party; wherein the deployment request carries the business processing strategy generated by the business party, and the deployment request is used to deploy the business processing strategy.

[0093] Step S1102: Obtain the business processing strategy from the deployment request.

[0094] In other words, in an optional embodiment, the business party may actively send a deployment request to the consensus node. The deployment request carries the business processing strategy generated by the business party. Accordingly, the consensus node receives the deployment request sent by the business party and then obtains the business processing strategy from the deployment request. In this way, the consensus node can obtain the business processing strategy.

[0095] In one of the optional embodiments, the deployment request refers to a request used by the business party to instruct the consensus node to deploy the business processing strategy. For example, the business party generates a business processing strategy and sends a deployment request carrying the business processing strategy to the consensus node. In this way, the consensus node can obtain the business processing strategy from the deployment request and then distribute the business processing strategy to the corresponding business nodes for deployment as needed.

[0096] In one embodiment of this application, please refer to Figure 12 The process of obtaining the business processing strategy generated by the business party in step S1001 may include steps S1201 to S1202, which are described in detail below:

[0097] Step S1201: Send a business processing strategy retrieval request to the business party so that the business party can retrieve the business processing strategy according to the business processing strategy retrieval request;

[0098] Step S1202: Receive the service processing strategy sent by the service provider.

[0099] In other words, in an optional embodiment, the consensus node may actively send a business processing strategy acquisition request to the business party. Correspondingly, the business party receives the business processing strategy acquisition request sent by the consensus node, then obtains the generated business processing strategy according to the business processing strategy acquisition request, and returns the business processing strategy to the consensus node, so that the consensus node can obtain the business processing strategy.

[0100] In one of the optional embodiments, the business processing strategy acquisition request refers to a request from the consensus node to instruct the business party to acquire the business processing strategy. For example, when the business party generates a business processing strategy, it will not actively send the business processing strategy to the consensus node. Instead, when it receives the business processing strategy acquisition request sent by the consensus node, it will return the business processing strategy to the consensus node and then distribute the business processing strategy to the corresponding business nodes for deployment as needed.

[0101] In one of the optional embodiments, the consensus node can proactively send business processing strategy acquisition requests to the business party at regular or irregular intervals. In practical applications, this can be flexibly adjusted according to the specific application scenario.

[0102] Step S1002: Distribute the business processing strategy to the business nodes.

[0103] In this embodiment, the consensus node obtains the business processing strategy generated by the business party, and then can distribute the business processing strategy to the business node.

[0104] In one embodiment of this application, please refer to Figure 13 The process of distributing the service processing strategy to the service nodes in step S1002 may include steps S1301 to S1302, which are described in detail below:

[0105] Step S1301: Receive a service processing strategy synchronization request sent by a service node;

[0106] Step S1302: Distribute the business processing strategy to the business nodes according to the business processing strategy synchronization request, so that the business nodes can deploy the business processing strategy.

[0107] That is, in an optional embodiment, the business node may actively send a business processing strategy synchronization request to the consensus node. Correspondingly, the consensus node receives the business processing strategy synchronization request sent by the business node, and then distributes the business processing strategy to the business node according to the business processing strategy synchronization request. Correspondingly, the business node receives the business processing strategy sent by the consensus node and then deploys the business processing strategy.

[0108] In one optional embodiment, the business processing strategy synchronization request refers to a request used by the business party to instruct the consensus node to distribute the business processing strategy, thereby synchronizing the business processing strategy. For example, when a new business node is created, it may not have any business processing strategy deployed (or it may have business processing strategy deployed). In this case, the business node can send a business processing strategy synchronization request to the consensus node. The consensus node can then determine that the business node currently has a need to deploy a business processing strategy, and thus distribute the business processing strategy to the business node. Accordingly, the business node receives the business processing strategy sent by the consensus node and then deploys the business processing strategy.

[0109] In one embodiment of this application, please refer to Figure 14 The process of distributing the service processing strategy to the service nodes in step S1002 may include steps S1401 to S1402, which are described in detail below:

[0110] Step S1401: Determine the business nodes to be distributed according to the business processing strategy;

[0111] Step S1402: Distribute the business processing strategy to the business nodes to be distributed, so that the business nodes can deploy the business processing strategy.

[0112] That is, in an optional embodiment, the consensus node may actively distribute the business processing strategy to the business node. Specifically, the consensus node determines the business node to be distributed to based on the business processing strategy, and then distributes the business processing strategy to the business node to be distributed. Correspondingly, the business node receives the business processing strategy sent by the consensus node and then deploys the business processing strategy.

[0113] In one of the optional embodiments, the consensus node can determine the identifier of the business node to be distributed according to the business processing strategy; for example, the identifier of the business node to be distributed is determined to be 11 according to business processing strategy A1, and the identifier of the business node to be distributed is determined to be 12 according to business processing strategy A2.

[0114] In one of the optional embodiments, the consensus node can distribute the business processing strategy to the business node whose identifier matches the business node to be distributed; for example, following the previous example, business processing strategy A1 is distributed to the business node with identifier 11, and business processing strategy A2 is distributed to the business node with identifier 12.

[0115] Step S1003: Receive transaction data and first proof data sent by the business node; wherein, the transaction data is generated by the business contract corresponding to the information of the business contract triggered by the business node, and the first proof data is obtained by the business node proving the transaction data based on the proof key associated with the proof algorithm.

[0116] In this embodiment, when a business node receives a business contract call request, it can trigger the execution of the business contract (i.e., the business contract distributed to the business node by the consensus node as described above), thereby generating transaction data. At the same time, it can prove the generated transaction data based on the proof key associated with the proof algorithm, thereby obtaining the first proof data for the transaction data. Then, it sends the transaction data and the first proof data to the consensus node. Correspondingly, the consensus node receives the transaction data and the first proof data sent by the business node.

[0117] In this embodiment, the first proof data refers to the proof data obtained by the business node proving the transaction data based on the proof key associated with the proof algorithm; that is, the object of proof is the transaction data. The specific proof process is described below.

[0118] Step S1004: Verify the first proof data based on the transaction data and the verification key associated with the proof algorithm to obtain the first verification result, and send the first verification result and transaction data to the business party.

[0119] In this embodiment, the consensus node receives transaction data and first proof data sent by the business node. Then, it can verify the first proof data based on the transaction data and the verification key associated with the proof algorithm to obtain a first verification result, and send the first verification result and transaction data to the business party.

[0120] In this embodiment of the application, the first verification result refers to the verification result obtained by verifying the first proof data based on the transaction data and the verification key associated with the proof algorithm, that is, the verification object is the first proof data.

[0121] In one embodiment of this application, please refer to Figure 15 The process of verifying the first proof data based on the transaction data and the verification key associated with the proof algorithm in step S1004 to obtain the first verification result may include steps S1501 to S1503, which are described in detail below:

[0122] Step S1501: Obtain the verification key associated with the proof algorithm from the consensus network;

[0123] Step S1502: Verify the first proof data based on the verification key to obtain the first verification result;

[0124] Step S1503: If the first verification result indicates that the first proof data matches the transaction data, then it is determined that the verification of the first proof data has passed.

[0125] In other words, in the optional embodiment, since the business party sends the verification key associated with the proof algorithm to the consensus network, and the consensus node has uploaded the verification key associated with the proof algorithm to the chain, the consensus node can obtain the verification key associated with the proof algorithm from the consensus network. Then, it verifies the first proof data based on the verification key to obtain the first verification result. Specifically, if the first verification result indicates that the first proof data matches the transaction data, it signifies that the verification of the first proof data has passed, meaning that the verification of the first proof data can be determined to be successful. If the first verification result indicates that the first proof data does not match the transaction data, it signifies that the verification of the first proof data has failed, meaning that the verification of the first proof data has failed.

[0126] For example, suppose the transaction data is a + b = y. The first proof data obtained by business node 11 based on the proof key associated with the proof algorithm is Proof1 = Prove(y) = Therefore, at this point, the consensus node can verify the first proof data Proof1 based on the verification key associated with the proof algorithm, obtaining the first verification result, such as zkVerifier1 = zkVerify (Proof1). It is understandable that the first verification result primarily verifies the first proof data. Does it match the transaction data y? If the first proof data... If the data matches the transaction data y, then the verification of the first proof data is confirmed, meaning that the sum of a and b is indeed equal to y.

[0127] In this way, by verifying the first proof data based on the transaction data and the verification key associated with the proof algorithm, not only can the authenticity of the execution of the business contract triggered by the business node be guaranteed, but also the accuracy of the calculation results of the transaction data can be guaranteed.

[0128] In one embodiment of this application, the consensus network stores ciphertext data used to calculate transaction data. This ciphertext data is generated by other business nodes encrypting (e.g., hashing) the plaintext data used for calculating the transaction data and then sending it to the consensus node. It is understood that these other business nodes and the business node that proves the transaction data are different business nodes; for example, the other business node might be business node 12, and the business node that proves the transaction data might be business node 11. The other business nodes could be authoritative institutions such as government departments possessing the plaintext data used to calculate the transaction data, while the business node that proves the transaction data could be an enterprise / individual.

[0129] In one embodiment of this application, the business network stores plaintext data used to calculate transaction data. This plaintext data, used for calculating transaction data, is sent by other business nodes to a business node that verifies the plaintext data. It is understood that the other business node and the business node that encrypts the plaintext data used for calculating transaction data are the same business node, such as both being business node 12. The other business node can be an authoritative institution, such as a government department, possessing the plaintext data used for calculating transaction data, while the business node that verifies the plaintext data can be an enterprise / individual.

[0130] In one embodiment of this application, please refer to Figure 16 Before the process of verifying the first proof data based on the transaction data and the verification key associated with the proof algorithm in step S1004, steps S1601 to S1602 may also be included, as detailed below:

[0131] Step S1601: Receive the second proof data sent by the business node; wherein, the second proof data is obtained by the business node proving the plaintext data used to calculate the transaction data based on the proof key associated with the proof algorithm;

[0132] Step S1602: Verify the second proof data based on the encrypted data and the verification key associated with the proof algorithm to obtain the second verification result, and send the second verification result to the business party.

[0133] That is, in the optional embodiment, the business node can trigger the execution of the business contract upon receiving a business contract call request, thereby generating transaction data. In addition to proving the generated transaction data based on the proof key associated with the proof algorithm to obtain first proof data for the transaction data, it also proves the plaintext data used to calculate the transaction data based on the proof key associated with the proof algorithm to obtain second proof data for the plaintext data used to calculate the transaction data. Then, the transaction data, the first proof data, and the second proof data are sent to the consensus node. Correspondingly, the consensus node receives the transaction data, the first proof data, and the second proof data sent by the business node, and verifies the first proof data based on the transaction data and the verification key associated with the proof algorithm to obtain a first verification result, and verifies the second proof data based on the ciphertext data and the verification key associated with the proof algorithm to obtain a second verification result.

[0134] In the optional embodiment, the second proof data refers to the proof data obtained by the business node using the proof key associated with the proof algorithm to prove the plaintext data used to calculate the transaction data; that is, the object of proof is the plaintext data used to calculate the transaction data. The specific proof process is described later.

[0135] In one optional embodiment, the consensus node receives the second proof data sent by the business node, and then verifies the second proof data based on the encrypted data and the verification key associated with the proof algorithm to obtain the second verification result, and sends the second verification result to the business party.

[0136] In the optional embodiment, the second verification result refers to the verification result obtained by verifying the second proof data based on the verification key associated with the proof algorithm, that is, the verification object is the second proof data.

[0137] In one embodiment of this application, please refer to Figure 17 The process of verifying the second proof data based on the ciphertext data and the verification key associated with the proof algorithm in step S1602 to obtain the second verification result may include steps S1701 to S1703, which are described in detail below:

[0138] Step S1701: Obtain the verification key associated with the proof algorithm from the consensus network;

[0139] Step S1702: Verify the second proof data based on the verification key to obtain the second verification result;

[0140] Step S1703: If the second verification result indicates that the second proof data matches the ciphertext data, then the verification of the second proof data is confirmed to be successful.

[0141] In other words, in the optional embodiment, since the business party sends the verification key associated with the proof algorithm to the consensus network, and the consensus node has uploaded the verification key associated with the proof algorithm to the chain, the consensus node can obtain the verification key associated with the proof algorithm from the consensus network. Then, it verifies the second proof data based on the verification key to obtain the second verification result. Specifically, if the second verification result indicates that the second proof data matches the ciphertext data, it signifies that the verification of the second proof data has passed; if the second verification result indicates that the second proof data does not match the ciphertext data, it signifies that the verification of the second proof data has failed.

[0142] For example, firstly, other business nodes, such as business node 12, perform a hash operation on 'a' to obtain the ciphertext data H(a) corresponding to 'a', and then send H(a) to the consensus network, and also send 'a' to business node 11; and secondly, other business nodes, such as business node 13, perform a hash operation on 'b' to obtain the ciphertext data H(b) corresponding to 'b', and then send H(b) to the consensus network, and also send 'b' to business node 11. Business node 11, based on the proof key associated with the proof algorithm, proves the plaintext data 'a' used to calculate the transaction data, and obtains the second proof data Proof2a = Prove(a) = H(a); and business node 11, based on the proof key associated with the proof algorithm, proves the plaintext data 'b' used to calculate the transaction data, and obtains the second proof data Proof2b = Prove(b) = H(b). Therefore, at this point, the consensus node can verify the second proof data Proof2a based on the verification key associated with the proof algorithm, obtaining a second verification result, such as zkVerifier2a = zkVerify (Proof2a), and verify the second proof data Proof2a based on the verification key associated with the proof algorithm, obtaining a second verification result, such as zkVerifier2b = zkVerify (Proof2b). It can be understood that the second verification result mainly verifies whether the second proof data H(a) matches the stored ciphertext data H(a). If the second proof data H(a) matches the stored ciphertext data H(a), then the verification of the second proof data is confirmed to be successful, meaning the source of 'a' is reliable. Correspondingly, the second verification result also mainly verifies whether the second proof data H(b) matches the stored ciphertext data H(b). If the second proof data H(b) matches the stored ciphertext data H(b), then the verification of the second proof data is confirmed to be successful, meaning the source of 'b' is reliable.

[0143] In this way, by verifying the second proof data based on the ciphertext data and the verification key associated with the proof algorithm, not only can the authenticity of the execution of the business contract triggered by the business node be guaranteed, but also the reliability of the source of the computational data of the transaction data (i.e., the ciphertext / plaintext data used to calculate the transaction data) can be guaranteed.

[0144] In one embodiment of this application, if the consensus node needs to send transaction data, the first verification result, and the second verification result to the business party, the transaction data, the first verification result, and the second verification result can be integrated and sent to the business party together, or the transaction data, the first proof data, and the second proof data can be sent to the business party separately; in practical applications, this can be flexibly adjusted according to the specific application scenario.

[0145] Figure 10The illustrated embodiment is presented from the perspective of the consensus node. The following is combined with... Figure 18 The implementation details of the technical solution in this application embodiment are described in detail from the perspective of business nodes:

[0146] Please see Figure 18 , Figure 18 This is a flowchart illustrating a data processing method based on a blockchain system, as shown in one embodiment of this application. This data processing method based on a blockchain system can be... Figure 9 The blockchain system shown is executed by business node 903 of the business network. For example... Figure 18 As shown, the data processing method based on the blockchain system includes at least steps S1801 to S1803, which are described in detail below:

[0147] Step S1801: Receive the business processing strategy generated by the business party sent by the consensus node. The business processing strategy includes information about the business contract and the proof algorithm.

[0148] The information and proof algorithm of the business contract in this embodiment have been described above and will not be repeated here.

[0149] In one embodiment of this application, a service node may proactively send a service processing policy synchronization request to a consensus node. Accordingly, the consensus node receives the service processing policy synchronization request sent by the service node, and then distributes the service processing policy to the service node according to the service processing policy synchronization request. Accordingly, the service node receives the service processing policy sent by the consensus node.

[0150] In one embodiment of this application, the consensus node may actively distribute the service processing strategy to the service node. Specifically, the consensus node determines the service node to be distributed to based on the service processing strategy, and then distributes the service processing strategy to the service node to be distributed. Correspondingly, the service node receives the service processing strategy sent by the consensus node.

[0151] Understandably, once a business node receives the business processing strategy generated by the business party from the consensus node, it can deploy the business contract on the business node side (also known as the local side of the business node); at the same time, it can deploy the proof algorithm on the business node side.

[0152] Step S1802: Based on the business contract call request corresponding to the information on the business contract sent by the business party, the execution of the business contract is triggered, and transaction data is generated.

[0153] In this embodiment of the application, the business party can send a business contract invocation request to the business node as needed. Correspondingly, the business node receives the business contract invocation request sent by the business party, and then can trigger the execution of the business contract based on the business contract invocation request to generate transaction data.

[0154] Step S1803: Prove the transaction data based on the proof key associated with the proof algorithm to generate the first proof data.

[0155] In this embodiment, the business node triggers the execution of the business contract based on the call request sent by the business party, generates transaction data, and then proves the transaction data based on the proof key associated with the proof algorithm, thereby obtaining the first proof data for the transaction data.

[0156] In this embodiment of the application, the first proof data refers to the proof data obtained by proving the transaction data based on the proof key, that is, the object of proof is the transaction data.

[0157] In one embodiment of this application, please refer to Figure 19 The process of proving the transaction data based on the proof key associated with the proof algorithm and generating the first proof data in step S1803 may include steps S1901 to S1902, which are described in detail below:

[0158] Step S1901: Receive the proof key associated with the proof algorithm sent by the business party;

[0159] Step S1902: Prove the transaction data based on the proof key to generate the first proof data.

[0160] That is, in the optional embodiment, since the business party sends the proof key associated with the proof algorithm to the business network, the business node can obtain the proof key associated with the proof algorithm from the business network, and then prove the transaction data based on the proof key associated with the proof algorithm, thereby obtaining the first proof data for the transaction data.

[0161] Step S1804: Send transaction data and first proof data to the consensus node so that the consensus node can verify the first proof data based on the transaction data and the verification key associated with the proof algorithm, obtain the first verification result, and send the first verification result and transaction data to the business party.

[0162] In one embodiment of this application, please refer to Figure 20 Before sending transaction data and first proof data to the consensus node in step S1804, steps S2001 to S2002 may also be included, as detailed below:

[0163] Step S2001: Prove the plaintext data based on the proof key associated with the proof algorithm to generate second proof data;

[0164] Step S2002: Send the second proof data to the consensus node so that the consensus node can verify the second proof data based on the ciphertext data used to calculate the transaction data and the verification key associated with the proof algorithm, obtain the second verification result, and send the second verification result to the business party.

[0165] That is, in the optional embodiment, the business node can trigger the execution of the business contract upon receiving a business contract call request, thereby generating transaction data. In addition to proving the transaction data based on the proof key to obtain first proof data for the transaction data, it also proves the plaintext data used to calculate the transaction data based on the proof key associated with the proof algorithm, thereby obtaining second proof data for the plaintext data used to calculate the transaction data. Then, the transaction data, the first proof data, and the second proof data are sent to the consensus node. Correspondingly, the consensus node receives the transaction data, the first proof data, and the second proof data sent by the business node, and verifies the first proof data based on the transaction data and the verification key associated with the proof algorithm to obtain a first verification result, and verifies the second proof data based on the ciphertext data and the verification key associated with the proof algorithm to obtain a second verification result.

[0166] In the optional embodiment, the second proof data refers to the proof data obtained by proving the plaintext data used to calculate the transaction data based on the proof key, that is, the proof object is the plaintext data used to calculate the transaction data.

[0167] In one embodiment of this application, please refer to Figure 21 The process of proving the plaintext data based on the proof key associated with the proof algorithm and generating the second proof data in step S2001 may include steps S2101 to S2102, which are described in detail below:

[0168] Step S2101: Receive the proof key associated with the proof algorithm sent by the business party;

[0169] Step S2102: Prove the plaintext data based on the proof key to generate second proof data.

[0170] That is, in the optional embodiment, since the business party sends the proof key associated with the proof algorithm to the business network, the business node can obtain the proof key associated with the proof algorithm from the business network, and then prove the plaintext data used to calculate the transaction data based on the proof key associated with the proof algorithm, thereby obtaining the second proof data for the plaintext data used to calculate the transaction data.

[0171] In one embodiment of this application, if a business node needs to send transaction data, first proof data, and second proof data to a consensus node, the transaction data, first proof data, and second proof data can be integrated and sent to the consensus node together, or the transaction data, first proof data, and second proof data can be sent to the consensus node separately. In practical applications, this can be flexibly adjusted according to specific application scenarios.

[0172] In this embodiment, because the business node verifies the transaction data, it proves to other business nodes that it has triggered the execution of the business contract. This ensures the authenticity of the business node's triggering of the business contract execution and prevents malicious actions by business nodes that could arbitrarily fabricate the execution results of the business contract. Furthermore, because the business node verifies the transaction data, it also verifies the calculation results of the transaction data, thus ensuring the accuracy of the calculation results. Moreover, the business node verifies the calculation data of the transaction data, thus proving the source of the calculation data, thereby ensuring the reliability of the source of the calculation data.

[0173] The following provides a detailed description of a specific application scenario of this application:

[0174] Please see Figure 22 This mainly includes a credit institution 2201, an enterprise / individual 2202, a first institution 2203, a second institution 2204, a third institution 2205, and a consensus node 2206 in the core chain. Specifically, the credit institution 2201 acts as the business party in the aforementioned embodiments, the enterprise / individual 2202 acts as the business node interacting with the consensus node in the aforementioned embodiments, and the first institution 2203, the second institution 2204, and the third institution 2205 act as other business nodes mentioned in the aforementioned embodiments. It is understood that the credit institution 2201, the enterprise / individual 2202, the first institution 2203, the second institution 2204, and the third institution 2205 can all be located within the business network.

[0175] Among them, the credit institution 2201 is mainly used to generate business processing strategies. The business processing strategies include local contract information and proof algorithms. The proof algorithms are associated with proof keys and verification keys.

[0176] Among them, the first institution 2203, the second institution 2204, and the third institution 2205 are mainly responsible for providing the enterprise / individual 2202 with the relevant computational data required during a transaction calculation process, and uploading the relevant computational data to the blockchain. Optionally, the first institution 2203, the second institution 2204, and the third institution 2205 can encrypt the relevant computational data required during a transaction calculation process (i.e., ciphertext data) and send it to the consensus node 2206, while simultaneously sending the relevant computational data required during the transaction calculation process (i.e., plaintext data) to the enterprise / individual 2202.

[0177] Specifically, Enterprise / Individual 2202 is primarily used to trigger the execution of a local contract upon receiving a call request from Credit Institution 2201, thereby generating transaction calculation results (i.e., the aforementioned transaction data) and uploading these results to the blockchain. Simultaneously, Enterprise / Individual 2202 proves to Credit Institution 2201, without disclosing private data, that: firstly, it used data provided by institutions such as the first institution 2203, the second institution 2204, and the third institution 2205 as calculation inputs; and secondly, provided that the first point is satisfied, the transaction calculation result is derived from the local contract provided by Credit Institution 2201.

[0178] Among them, consensus node 2206 is mainly used to verify the proof data obtained by enterprise / individual 2202, and send the corresponding verification results and transaction calculation results to credit institution 2201, so that credit institution 2201 can determine the proof status of the aforementioned two points of enterprise / individual 2202.

[0179] Please see Figure 23 , Figure 23 This is a flowchart illustrating a data processing method based on a blockchain system, as shown in one embodiment of this application. Figure 23 As shown, the data processing method based on the blockchain system includes at least steps S2301 to S2312, which are described in detail below:

[0180] In step S2301, the first organization performs a hash operation on the first computational data and sends it to the consensus node.

[0181] The first calculated data is a set of calculated data required during the calculation process of this transaction. Optionally, the first calculated data is { }, a commitment can be made to this first computed data through the Perdersen hash operation to generate At this time, the first institution will Send to the consensus node.

[0182] In step S2302, the second organization performs a hash operation on the second computation data and sends it to the consensus node.

[0183] The second calculated data is a set of calculated data required during the calculation process of this transaction. Optionally, the second calculated data is { }, a commitment can be made to this first computed data through the Perdersen hash operation to generate At this time, the second agency will Send to the consensus node.

[0184] In step S2303, the first organization sends the first calculation data to the enterprise / individual.

[0185] Optionally, the first agency will { Send to businesses / individuals.

[0186] In step S2304, the second organization sends the second calculation data to the enterprise / individual.

[0187] Optionally, the second agency will { Send to businesses / individuals.

[0188] It should be noted that steps S2301 to S2304 can be executed in any order or in parallel.

[0189] In step S2305, the credit institution generates a business processing strategy, which includes information about the local contract and a proof algorithm. The proof algorithm is associated with a proof key and a verification key. The generated business processing strategy and the verification key associated with the proof algorithm are then sent to the consensus node.

[0190] Optionally, the business processing strategy generated by the credit institution includes information about the local contract (which may be the computational logic of the local contract itself) and a proof algorithm (which may be a zero-knowledge proof circuit). The zero-knowledge proof circuit is initialized as: KeyGen(C) → (σ, τ), where σ is a public string. The public disclosure of σ does not affect the security of the algorithm. σ includes ek and vk, where ek is the prover's public string (i.e., the proof key) and vk is the verifier's public string (i.e., the verification key). τ is a trapdoor that needs to be deleted immediately after initialization; if τ is made public, it will affect the security of the algorithm. The zero-knowledge proof circuit can be in the form of an R1CS circuit and verifiable computation can be constructed using QAP (quadratic arithmetic programming) according to the Groth16 scheme.

[0191] In step S2306, the consensus node receives the business processing strategy sent by the credit institution and uploads the verification key associated with the local contract and the proof algorithm to the blockchain.

[0192] Optionally, the local contract can be associated with the verification key linked to the proof algorithm and uploaded to the blockchain, for example...

[0193] The contract is associated with the blockchain in the form of {local contract identifier, validator key}.

[0194] Step S2307: The consensus node distributes the business processing strategy to enterprises / individuals.

[0195] Optionally, the consensus node may receive a business processing strategy synchronization request sent by an enterprise / individual, and then distribute the business processing strategy to the enterprise / individual according to the business processing strategy synchronization request, so that the enterprise / individual can deploy the business processing strategy.

[0196] In step S2308, the credit institution sends a local contract invocation request to the enterprise / individual.

[0197] Optionally, the credit institution may send a local contract call request to the enterprise / individual as needed.

[0198] The credit institution will also send the proof key associated with the proof algorithm to the enterprise / individual (not shown in the figure) so that the corresponding proof can be made subsequently based on the proof key associated with the proof algorithm.

[0199] In step S2309, the enterprise / individual triggers the execution of the local contract based on the call request of the local contract sent by the credit institution, generates a transaction calculation result, and proves the transaction calculation result based on the proof key associated with the proof algorithm to generate first proof data. The enterprise / individual also proves the first calculation data and the second calculation data based on the proof key associated with the proof algorithm to generate second proof data.

[0200] Optionally, businesses / individuals may perform proof: Prove(C, σ, , w)→π, where C is the circuit corresponding to the proof algorithm, σ is the common string, It is a public statement. It contains the result y' of the circuit computation, and the Perdersen hash of each input (i.e., the first computation data and the second computation data), w is the privacy input, and π is the proof.

[0201] In step S2310, the enterprise / individual sends the transaction calculation result, the first proof data, and the second proof data to the consensus node.

[0202] In step S2311, the consensus node verifies the first proof data based on the transaction calculation result and the verification key associated with the proof algorithm to obtain the first verification result, and verifies the second proof data based on the ciphertext data and the verification key associated with the proof algorithm to obtain the second verification result.

[0203] Optionally, the credit institution performs verification: 1) Verify(C, σ, ,π)→0 / 1, according to public statements Verify the correctness of the proof provided by the enterprise / individual; specifically, verify whether y equals y' (i.e., verify whether the first proof data matches the transaction calculation result); and verify whether the Perdersen hash of each input equals... That is, verifying whether the commitment value of the first calculated data in the second proof data obtained from the verification is equal to the commitment value of the first calculated data sent by the first institution, and verifying whether the commitment value of the second calculated data in the second proof data obtained from the verification is equal to the commitment value of the second calculated data sent by the second institution.

[0204] In step S2312, the consensus node integrates the first verification result and the second verification result to obtain the final verification result, and sends the final verification result and transaction calculation result to the credit institution.

[0205] Optionally, if verifying y equals y', and the Perdersen hash of each input equals ... If the result is positive, the final verification result q=1; otherwise, q=0.

[0206] Optionally, the credit structure can also put the final verification results on the blockchain.

[0207] In this embodiment, the business nodes prove the transaction calculation results. Therefore, the enterprise / individual proves to other business nodes that it has triggered the execution of the local contract, thereby ensuring the authenticity of the execution of the local contract triggered by the business nodes. At the same time, the business nodes prove the calculation data (first calculation data and second calculation data) of the transaction calculation results, thus proving the reliability of the source of the calculation data of the transaction calculation results, thereby improving the accuracy of the transaction calculation results.

[0208] Figure 24 This is a block diagram illustrating a data processing apparatus based on a blockchain system, as shown in one embodiment of this application. Figure 24 As shown, the blockchain system includes a consensus network with consensus nodes and a business network with business nodes. The data processing device based on the blockchain system is configured in the consensus nodes, and the device includes:

[0209] The acquisition module 2401 is configured to acquire the business processing strategy generated by the business party. The business processing strategy includes the information of the business contract and the proof algorithm. The proof algorithm is associated with a proof key and a verification key. The information of the business contract and the verification key associated with the proof algorithm are put on the blockchain.

[0210] Distribution module 2402 is configured to distribute business processing strategies to business nodes;

[0211] The first receiving module 2403 is configured to receive transaction data and first proof data sent by the business node; wherein, the transaction data is generated by the business contract corresponding to the information of the business contract triggered by the business node, and the first proof data is obtained by the business node proving the transaction data based on the proof key associated with the proof algorithm;

[0212] The verification module 2404 is configured to verify the first proof data based on the transaction data and the verification key associated with the proof algorithm, obtain the first verification result, and send the first verification result and the transaction data to the business party.

[0213] In one embodiment of this application, the verification module 2404 is specifically configured as follows:

[0214] Obtain the verification key associated with the proof algorithm from the consensus network;

[0215] The first proof data is verified based on the verification key to obtain the first verification result;

[0216] If the first verification result indicates that the first proof data matches the transaction data, then the verification of the first proof data is deemed successful.

[0217] In one embodiment of this application, the first receiving module 2403 is further configured to receive second proof data sent by the service node; wherein, the second proof data is obtained by the service node proving the plaintext data used to calculate the transaction data based on the proof key associated with the proof algorithm;

[0218] The verification module 2404 is also configured to verify the second proof data based on the encrypted data and the verification key associated with the proof algorithm, obtain the second verification result, and send the second verification result to the business party.

[0219] In one embodiment of this application, the verification module 2404 is specifically configured as follows:

[0220] Obtain the verification key associated with the proof algorithm from the consensus network;

[0221] The second proof data is verified based on the verification key to obtain the second verification result;

[0222] If the second verification result indicates that the second proof data matches the ciphertext data, then the verification of the second proof data is deemed successful.

[0223] In one embodiment of this application, the acquisition module 2401 is specifically configured as follows:

[0224] Receive deployment requests sent by business parties; the deployment request carries the business processing strategy generated by the business party, and the deployment request is used to deploy the business processing strategy.

[0225] Obtain the business processing strategy from the deployment request.

[0226] In one embodiment of this application, the distribution module 2402 is specifically configured as follows:

[0227] Receive business processing strategy synchronization requests sent by business nodes;

[0228] The business processing strategy is synchronously distributed to the business nodes according to the business processing strategy, so that the business nodes can deploy the business processing strategy.

[0229] Figure 25 This is a block diagram illustrating a data processing apparatus based on a blockchain system, as shown in one embodiment of this application. Figure 25 As shown, the blockchain system includes a consensus network with consensus nodes and a business network with business nodes. The data processing device based on the blockchain system is configured in the business nodes, and the device includes:

[0230] The second receiving module 2501 is configured to receive the business processing strategy generated by the business party sent by the consensus node. The business processing strategy includes information about the business contract and the proof algorithm.

[0231] The first generation module 2502 is configured to trigger the execution of the business contract and generate transaction data based on the business contract call request corresponding to the information on the business contract sent by the business party.

[0232] The second generation module 2503 is configured to prove the transaction data based on the proof key associated with the proof algorithm and generate the first proof data;

[0233] The sending module 2504 is configured to send transaction data and first proof data to the consensus node, so that the consensus node can verify the first proof data based on the transaction data and the verification key associated with the proof algorithm, obtain the first verification result, and send the first verification result and transaction data to the business party.

[0234] In one embodiment of this application, the second generation module 2503 is specifically configured as follows:

[0235] Receive the proof key associated with the proof algorithm sent by the business party;

[0236] The transaction data is validated using the validation key to generate the first validation data.

[0237] In one embodiment of this application, the second generation module 2503 is further configured to prove the plaintext data based on the proof key associated with the proof algorithm, and generate second proof data;

[0238] The sending module 2504 is also configured to send second proof data to the consensus node, so that the consensus node verifies the second proof data based on the ciphertext data used to calculate the transaction data and the verification key associated with the proof algorithm, obtains the second verification result, and sends the second verification result to the business party.

[0239] In one embodiment of this application, the second generation module 2503 is specifically configured as follows:

[0240] Receive the proof key associated with the proof algorithm sent by the business party;

[0241] The plaintext data is validated using the validation key to generate second validation data.

[0242] It should be noted that the apparatus provided in the above embodiments and the method provided in the above embodiments belong to the same concept, and the specific way in which each module and unit performs operations has been described in detail in the method embodiments, and will not be repeated here.

[0243] Embodiments of this application also provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, which, when executed by one or more processors, enable the electronic device to implement the aforementioned data processing method based on a blockchain system.

[0244] Figure 26 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown.

[0245] It should be noted that, Figure 26 The computer system 2600 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0246] like Figure 26 As shown, the computer system 2600 includes a Central Processing Unit (CPU) 2601, which can perform various appropriate actions and processes, such as executing the methods described in the above embodiments, based on programs stored in Read-Only Memory (ROM) 2602 or programs loaded from storage portion 2608 into Random Access Memory (RAM) 2603. The RAM 2603 also stores various programs and data required for system operation. The CPU 2601, ROM 2602, and RAM 2603 are interconnected via a bus 2604. An Input / Output (I / O) interface 2605 is also connected to the bus 2604.

[0247] The following components are connected to I / O interface 2605: an input section 2606 including a keyboard, mouse, etc.; an output section 2607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 2608 including a hard disk, etc.; and a communication section 2609 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 2609 performs communication processing via a network such as the Internet. A drive 2610 is also connected to I / O interface 2605 as needed. Removable media 2611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 2610 as needed so that computer programs read from them can be installed into storage section 2608 as needed.

[0248] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 2609, and / or installed from removable medium 2611. When the computer program is executed by central processing unit (CPU) 2601, it performs various functions defined in the system of this application.

[0249] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. The transmitted data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0250] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0251] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0252] Another aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned data processing method based on a blockchain system. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not incorporated into the electronic device.

[0253] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the data processing method based on the blockchain system provided in the various embodiments above.

[0254] The above description is merely a preferred exemplary embodiment of this application and is not intended to limit the implementation of this application. Those skilled in the art can easily make corresponding modifications or alterations based on the main concept and spirit of this application. Therefore, the scope of protection of this application should be determined by the scope of protection claimed in the claims.

Claims

1. A data processing method based on a blockchain system, characterized in that, The blockchain system includes a consensus network with consensus nodes deployed and a business network with business nodes deployed. The method is executed by the consensus nodes and includes: Obtain the business processing strategy generated by the business party. The business processing strategy includes business contract information and a proof algorithm. The proof algorithm is associated with a proof key and a verification key. Upload the business contract information and the verification key associated with the proof algorithm to the blockchain. The business nodes to be distributed are determined according to the business processing strategy, and the business processing strategy is distributed to the business nodes so that the business nodes can deploy the business processing strategy in the business nodes; The system receives transaction data and first proof data sent by the business node; wherein the transaction data is generated by the business contract corresponding to the information triggered by the business node in the business contract, and the first proof data is obtained by the business node proving the transaction data based on the proof key associated with the proof algorithm; The verification key associated with the proof algorithm is obtained from the consensus network, and the first proof data is verified based on the verification key to obtain a first verification result. If the first verification result indicates that the first proof data matches the transaction data, a first verification result is obtained to characterize the successful verification of the first proof data, and the first verification result and the transaction data are sent to the business party.

2. The method of claim 1, wherein, The consensus network stores encrypted data used to calculate the transaction data; Before obtaining the verification key associated with the proof algorithm from the consensus network, the method further includes: The service node receives second proof data; wherein the second proof data is obtained by the service node proving the plaintext data used to calculate the transaction data based on the proof key associated with the proof algorithm. The second proof data is verified based on the encrypted data and the verification key associated with the proof algorithm to obtain a second verification result, which is then sent to the business party.

3. The method as described in claim 2, characterized in that, The second verification result is obtained by verifying the second proof data based on the ciphertext data and the verification key associated with the proof algorithm, including: Obtain the verification key associated with the proof algorithm from the consensus network; The second proof data is verified based on the verification key to obtain a second verification result; If the second verification result indicates that the second proof data matches the encrypted data, then the verification of the second proof data is deemed successful.

4. The method according to any one of claims 1 to 3, characterized in that, The acquisition of the business processing strategy generated by the business party includes: Receive a deployment request sent by the business party; wherein the deployment request carries a business processing strategy generated by the business party, and the deployment request is used to deploy the business processing strategy; Obtain the business processing strategy from the deployment request.

5. The method according to any one of claims 1 to 3, characterized in that, The method further includes: Receive the service processing strategy synchronization request sent by the service node; The business processing strategy is synchronously requested to distribute the business processing strategy to the business node so that the business node can deploy the business processing strategy.

6. A data processing method based on a blockchain system, characterized in that, The blockchain system includes a consensus network with consensus nodes and a business network with business nodes. The method is executed by the business nodes and includes: The system receives a business processing strategy generated by the business party from the consensus node, and deploys the business processing strategy in the business node. The business processing strategy includes information about the business contract and a proof algorithm. The business node is determined and distributed by the consensus node according to the business processing strategy. Based on the business contract call request corresponding to the information of the business contract sent by the business party, the execution of the business contract is triggered, and transaction data is generated; Receive the proof key associated with the proof algorithm sent by the business party, and prove the transaction data based on the proof key to generate first proof data; The transaction data and the first proof data are sent to the consensus node, so that the consensus node verifies the first proof data based on the transaction data and the verification key associated with the proof algorithm, obtains a first verification result, and sends the first verification result and the transaction data to the business party.

7. The method as described in claim 6, characterized in that, The business network stores plaintext data used to calculate the transaction data; before sending the transaction data and the first proof data to the consensus node, the method further includes: The plaintext data is proved based on the proof key associated with the proof algorithm to generate second proof data; The second proof data is sent to the consensus node, so that the consensus node verifies the second proof data based on the ciphertext data used to calculate the transaction data and the verification key associated with the proof algorithm, obtains a second verification result, and sends the second verification result to the business party.

8. The method as described in claim 7, characterized in that, The process of proving the plaintext data based on the proof key associated with the proof algorithm to generate second proof data includes: Receive the proof key associated with the proof algorithm sent by the business party; The plaintext data is validated based on the validation key to generate the second validation data.

9. A data processing device based on a blockchain system, characterized in that, The blockchain system includes a consensus network with consensus nodes and a business network with business nodes. The device is configured on the consensus node and includes: The acquisition module is configured to acquire the business processing strategy generated by the business party. The business processing strategy includes information about the business contract and a proof algorithm. The proof algorithm is associated with a proof key and a verification key. The information about the business contract and the verification key associated with the proof algorithm are uploaded to the blockchain. The distribution module is configured to determine the business nodes to be distributed according to the business processing strategy, and distribute the business processing strategy to the business nodes so that the business nodes deploy the business processing strategy in the business nodes; The first receiving module is configured to receive transaction data and first proof data sent by the business node; wherein, the transaction data is generated by the business contract corresponding to the information triggered by the business node, and the first proof data is obtained by the business node proving the transaction data based on the proof key associated with the proof algorithm; The verification module is configured to obtain the verification key associated with the proof algorithm from the consensus network, and verify the first proof data based on the verification key to obtain a first verification result. If the first verification result indicates that the first proof data matches the transaction data, a first verification result is obtained to characterize the successful verification of the first proof data, and the first verification result and the transaction data are sent to the business party.

10. A data processing device based on a blockchain system, characterized in that, The blockchain system includes a consensus network with consensus nodes and a business network with business nodes. The device is configured on the business node and includes: The second receiving module is configured to receive the business processing strategy generated by the business party sent by the consensus node, and deploy the business processing strategy in the business node. The business processing strategy includes information about the business contract and a proof algorithm, and the business node is determined and distributed by the consensus node according to the business processing strategy. The first generation module is configured to trigger the execution of the business contract and generate transaction data based on the business contract call request corresponding to the information of the business contract sent by the business party. The second generation module is configured to receive the proof key associated with the proof algorithm sent by the business party; prove the transaction data based on the proof key, and generate first proof data; The sending module is configured to send the transaction data and the first proof data to the consensus node, so that the consensus node verifies the first proof data based on the transaction data and the verification key associated with the proof algorithm, obtains a first verification result, and sends the first verification result and the transaction data to the business party.

11. An electronic device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by the electronic device, cause the electronic device to implement the data processing method based on a blockchain system as described in any one of claims 1 to 5, or to implement the data processing method based on a blockchain system as described in any one of claims 6 to 8.

12. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the data processing method based on the blockchain system as described in any one of claims 1 to 5, or implements the data processing method based on the blockchain system as described in any one of claims 6 to 8.

13. A computer program product comprising computer instructions, characterized in that, When executed by a processor, the computer instructions implement the data processing method based on a blockchain system as described in any one of claims 1 to 5, or implement the data processing method based on a blockchain system as described in any one of claims 6 to 8.

Images