Blockchain-based transaction management method and apparatus, and computer and storage medium

Abstract

Disclosed in the embodiments of the present application are a blockchain-based transaction management method and apparatus, and a computer and a storage medium. The method comprises: acquiring transaction data, if the transaction data comprises regular transaction data and privacy transaction data, acquiring the regular transaction data from the transaction data, and generating a Merkel management tree according to the transaction data and a regular transaction corresponding to the regular transaction data, wherein the regular transaction data refers to transaction data, other than the privacy transaction data, in the transaction data; calling a privacy contract on the basis of the privacy transaction data, verifying a data execution state of the privacy transaction data by means of the privacy contract, and if the data execution state is a data executable state, executing a privacy transaction corresponding to the privacy contract; and generating a transaction block according to the Merkel management tree and the transaction data, and adding to the blockchain the transaction block. The present application can improve the convenience and efficiency of transaction management.

Description

Blockchain-based transaction management method, device, computer, and storage medium

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on June 26, 2023, with application number 202310763341.3 and invention name “Transaction management method, device, computer and storage medium based on blockchain”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of computer technology, and in particular to a transaction management method, device, computer, and storage medium based on blockchain. Background Art

[0003] When devices conduct transactions, there are often two types of transactions: regular transactions that can be executed by multiple blockchain nodes, and private transactions executed by a single blockchain node. Since private transactions can only be executed by a single blockchain node, the characteristics of these two transactions are different. Therefore, two systems are typically built: one for off-chain collaboration via dedicated lines, performing off-chain tasks and executing private transactions. This utilizes a dedicated network connection for more secure and efficient collaboration; the other for on-chain interaction, performing off-chain tasks and enabling more convenient data sharing and interaction, as well as improved data traceability. However, building this system increases the complexity of the system architecture and the development workload. Furthermore, the increased number of application interfaces and open network ports between organizations complicates operations and management, making transaction management more complex and inefficient.

[0004] Summary of the Invention

[0005] The embodiments of the present application provide a blockchain-based transaction management method, device, computer, and storage medium, which can improve the convenience and efficiency of transaction management.

[0006] The present invention provides a blockchain-based transaction management method, which includes:

[0007] Obtain transaction data. If the transaction data includes regular transaction data and private transaction data, obtain the regular transaction data from the transaction data and generate a Merkle management tree based on the transaction data and the regular transactions corresponding to the regular transaction data. Regular transaction data refers to the transaction data excluding private transaction data.

[0008] The privacy contract is called based on the private transaction data. The data execution status of the private transaction data is verified through the privacy contract. If the data execution status is executable, the private transaction corresponding to the privacy contract is executed.

[0009] Generate transaction blocks based on the Merkle management tree and transaction data, and upload the transaction blocks to the chain.

[0010] In one aspect, an embodiment of the present application provides a blockchain-based transaction management device, comprising:

[0011] Transaction acquisition module, used to obtain transaction data;

[0012] A regular acquisition module, configured to acquire regular transaction data from the transaction data if the transaction data includes regular transaction data and private transaction data;

[0013] A tree construction module is used to generate a Merkle management tree based on transaction data and regular transactions corresponding to regular transaction data; regular transaction data refers to transaction data other than private transaction data;

[0014] The state determination module is used to call the privacy contract based on the private transaction data and verify the data execution status of the private transaction data through the privacy contract;

[0015] The privacy execution module is used to execute the privacy transaction corresponding to the privacy contract if the data execution status is the data executable state;

[0016] The block chain module is used to generate transaction blocks based on the Merkle management tree and transaction data, and to process the transaction blocks on the chain.

[0017] The Merkle management tree includes the transaction tree, receipt tree, and world state tree. The tree construction modules include:

[0018] A first construction unit is configured to generate a transaction tree based on transaction data;

[0019] The privacy construction unit is used to obtain the private on-chain data corresponding to the private transaction data;

[0020] An information acquisition unit, configured to acquire conventional transaction information generated by executing conventional transactions corresponding to conventional transaction data, and to acquire conventional account information corresponding to the conventional transaction data;

[0021] The second construction unit is used to construct a receipt tree based on the private on-chain data and regular transaction information, and to construct a world state tree based on the private on-chain data and regular account information.

[0022] The information acquisition unit includes:

[0023] The result acquisition subunit is used to call the conventional smart contract corresponding to the conventional transaction data through the conventional transaction data, execute the conventional transaction corresponding to the conventional transaction data through the conventional smart contract, and obtain the conventional transaction execution result;

[0024] The information acquisition subunit is used to acquire the regular log information generated during the execution of the regular transaction, and combine the regular transaction execution result and the regular log information to form the regular transaction information generated by the regular transaction;

[0025] The information composition sub-unit is used to update the transaction count of the regular account corresponding to the regular smart contract based on regular transactions, generate a regular transaction hash based on the transaction count of the regular account, and combine the regular transaction hash and the account data of the regular account to form the regular account information corresponding to the regular transaction data.

[0026] The status determination module includes:

[0027] A parameter transfer unit is used to call the proxy contract based on the private transaction data and transfer the transaction encryption parameters and the transaction parameter signature to the proxy contract; the transaction parameter signature is obtained by signing the transaction encryption parameters with the first object private key of the first participant;

[0028] The parameter acquisition unit is used to decrypt the transaction encryption parameters using the target node private key of the target node through the proxy contract to obtain the transaction parameters; the target node refers to the node that obtains the transaction data;

[0029] The parameter verification unit is used to call the privacy contract through the proxy contract, pass the transaction parameters to the privacy contract, and verify the signature of the transaction parameters through the privacy contract;

[0030] a state determination unit, configured to determine that the data execution state of the private transaction data is a data executable state if the transaction parameter signature verification passes;

[0031] The status determination unit is further configured to determine that the data execution status of the private transaction data is a data non-executable state if the transaction parameter signature verification fails.

[0032] Among them, the block chain module includes:

[0033] The block consensus unit is used to generate transaction blocks based on the Merkle management tree and transaction data, and broadcast the transaction blocks to the first consensus node for consensus;

[0034] A block comparison unit is configured to receive the transaction block to be agreed upon sent by the first consensus node, compare the transaction block with the transaction block to be agreed upon, obtain a first consensus result of the transaction block to be agreed upon, and broadcast the first consensus result to the first consensus node, so that the first consensus node, upon detecting that the consensus of the transaction block to be agreed upon is passed, performs on-chain processing on the transaction block to be agreed upon;

[0035] The block chain unit is used to upload the transaction block to the chain if the consensus node passes the consensus on the transaction block.

[0036] The device further comprises:

[0037] The contract encryption module is used to generate a data encryption key and use the data encryption key to encrypt the privacy contract to obtain an encrypted privacy contract;

[0038] A contract signature module is used to encrypt the data encryption key using the target node public key of the target node to generate key protection data, and to generate a contract signature for the encrypted privacy contract and the key protection data using the second object private key of the second participating object;

[0039] The data transmission module is used to transmit the encrypted privacy contract, key protection data and contract signature to the proxy contract;

[0040] The contract deployment module is used to deploy privacy contracts through proxy contracts, encrypted privacy contracts, key protection data and contract signatures.

[0041] Among them, the contract deployment module includes:

[0042] The key acquisition unit is used to verify the contract signature. If the second participant is a private account, the target node private key of the target node is used to decrypt the key-protected data to obtain the data encryption key;

[0043] The contract deployment unit is used to decrypt the encrypted privacy contract using the data encryption key, obtain the privacy contract, and deploy the privacy contract.

[0044] The device further comprises:

[0045] The registration signature verification module is used to respond to privacy account registration requests and verify the registration signature carried in the privacy account registration request through the proxy contract; the registration signature refers to the signature generated by the second party's private key;

[0046] A registration confirmation module is configured to update the registration status of the privacy account registration request to a pending confirmation state if the registration signature verification is successful, and forward the privacy account registration request to the management device, so that the management device returns an account registration confirmation message after verifying the privacy account registration request;

[0047] The confirmation and verification module is used to verify the registration management signature carried in the account registration confirmation message through the proxy contract. If the registration management signature verification passes, the account registration status is updated to the confirmed status;

[0048] The privacy determination module is used to determine the second participant as a privacy account based on the account registration status.

[0049] The device further comprises:

[0050] The proxy deployment module is used to build contract deployment, contract call, and privacy account management functions, integrate contract deployment, contract call, and privacy account management functions into the contract code, generate proxy contracts, and deploy proxy contracts;

[0051] The state determination module is specifically used to:

[0052] Call the proxy contract through private transaction data, and determine the privacy contract corresponding to the private transaction data in the proxy contract;

[0053] Call the contract call function in the proxy contract, use the contract call function to call the privacy contract, and verify the data execution status of the privacy transaction data through the privacy contract.

[0054] The device further comprises:

[0055] A privacy storage module is used to obtain the private transaction information generated by the private transaction, generate a private block based on the private transaction information, and add the private block to the private blockchain; or

[0056] The privacy storage module is also used to obtain the private transaction information generated by the private transaction, obtain the private data identifier corresponding to the private transaction data in the Merkle management tree, and associate the private data identifier with the private transaction information for storage.

[0057] On the one hand, an embodiment of the present application provides a computer device, including a processor, a memory, and an input and output interface;

[0058] The processor is connected to the memory and the input and output interface respectively, wherein the input and output interface is used to receive and output data, the memory is used to store a computer program, and the processor is used to call the computer program so that the computer device including the processor executes the blockchain-based transaction management method in one aspect of the embodiment of the present application.

[0059] On the one hand, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. The computer program is suitable for being loaded and executed by a processor, so that a computer device having the processor executes the blockchain-based transaction management method in one aspect of the embodiment of the present application.

[0060] In one aspect, an embodiment of the present application provides a computer program product or computer program, which includes 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 methods provided in various optional embodiments of the present application. In other words, when the computer instructions are executed by the processor, the methods provided in various optional embodiments of the present application are implemented.

[0061] Implementing the embodiments of this application will have the following beneficial effects:

[0062] In an embodiment of the present application, transaction data can be obtained. If the transaction data includes regular transaction data and private transaction data, the regular transaction data is obtained from the transaction data, and a Merkle management tree is generated based on the transaction data and the regular transactions corresponding to the regular transaction data. Regular transaction data refers to the transaction data in the transaction data excluding the private transaction data. A private contract is called based on the private transaction data, and the data execution status of the private transaction data is verified by the private contract. If the data execution status is executable, the private transaction corresponding to the private contract is executed. A transaction block is generated based on the Merkle management tree and the transaction data, and the transaction block is processed on the chain. Through the above process, the two types of transactions can be integrated into a single system. In other words, while maintaining the original system architecture of the blockchain node, the on-chain system can be directly used to manage both private transactions and regular transactions. This allows off-chain businesses (i.e., private transaction businesses) to use the on-chain information transmission channel, achieving seamless integration between on-chain and off-chain businesses. This simplifies the system architecture and allows all business functions to be implemented in a single system, simplifying the technical solution and reducing development costs and maintenance difficulties. At the same time, when managing transactions, when data transmission is required, the execution process of private transactions can be ignored, that is, the transaction data and the relevant data of the execution process of regular transactions corresponding to the regular transaction data can be directly transmitted. In this way, even blockchain nodes that cannot execute private transactions can obtain the same execution-related data of private transactions, thereby ensuring the data consistency of multiple transactions under the same system, avoiding the impact of private transactions on the processing process of on-chain data, and improving the convenience and efficiency of transaction management. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0064] FIG1 is a schematic diagram of a blockchain system architecture provided by an embodiment of the present application;

[0065] FIG2 is a schematic diagram of a transaction management scenario provided by an embodiment of the present application;

[0066] FIG3 is a flow chart of a method for blockchain-based transaction management provided in an embodiment of the present application;

[0067] FIG4 is a schematic diagram of a tree-shaped construction scenario provided in an embodiment of the present application;

[0068] FIG5 is a schematic diagram of a world state tree data provided by an embodiment of the present application;

[0069] FIG6 is an optional transaction management flow chart provided in an embodiment of the present application;

[0070] FIG7 is a schematic diagram of a contract deployment process provided by an embodiment of the present application;

[0071] FIG8 is a schematic diagram of an account registration process provided in an embodiment of the present application;

[0072] FIG9 is a schematic diagram of a contract call process provided by an embodiment of the present application;

[0073] FIG10 is a schematic diagram of a blockchain-based transaction management device provided in an embodiment of the present application;

[0074] FIG11 is a schematic structural diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0075] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0076] Among them, if it is necessary to collect the data of the object (such as users, etc.) in this application, a prompt interface or pop-up window will be displayed before or during the collection. The prompt interface or pop-up window is used to remind the user that certain data is currently being collected, such as transaction data, etc. Only after the user confirms the prompt interface or pop-up window, the relevant steps for data acquisition will be started, otherwise the process will end. Moreover, the acquired user data will be used in reasonable and legal scenarios or purposes. Optionally, in some scenarios where user data needs to be used but the user has not authorized it, authorization can be requested from the user, and the user data can be used when the authorization is passed. Among them, the use of user data complies with the relevant provisions of laws and regulations.

[0077] Among them, some of the terms involved in this application are explained as follows:

[0078] 1. Merkle Tree: Also known as a Hash Tree, this is a data structure with a tree-like structure. It can be used to verify the integrity and consistency of large amounts of data and is widely used. A Merkle tree consists of a hash function and leaf nodes, each representing a data block. Each data block is hashed to produce a series of hash values. These hash values ​​are then paired and hashed again to produce a new hash value, called the parent node. This process is repeated until a root node is reached, which is the root hash value of the Merkle tree.

[0079] The primary function of a Merkle tree is to verify data integrity and consistency. When the number of data blocks is large, verifying all of it is very expensive. However, a Merkle tree can reduce verification costs by breaking large amounts of data into multiple blocks, performing a hash operation on each block, and then organizing these hash values ​​into a tree structure. Verifying a data block simply requires verifying that its hash value matches the hash value of the upper-level node. If they do not match, it indicates that the data block or its upper-level node has been tampered with, resulting in incomplete or inconsistent data. This verification method is called a Merkle Proof.

[0080] Merkle trees are widely used to verify the accuracy of transaction data. Each transaction contains its inputs and outputs, as well as other transaction information. This information is hashed using a hash function to produce a transaction hash value. The hash values ​​of all transactions are then combined to form a Merkle tree, the root hash of which is recorded in the block header. This way, when a block is broadcast to the network, other nodes can verify the correctness and consistency of the transaction data by verifying the Merkle root hash in the block header. If the transaction data is tampered with, the Merkle root hash value will also change, making it unverifiable, thus ensuring the security and reliability of the transaction data.

[0081] 2. Digital signature: It is a technology used to ensure the authenticity, integrity and non-repudiation of digital documents (such as emails, electronic contracts, software, etc.). The digital signature process includes the following steps:

[0082] (1) Create a message digest: Use a hash function to generate a message digest from the original data to ensure data integrity.

[0083] (2) Private key encryption: The creator uses his or her own private key to encrypt the message digest and generate a digital signature.

[0084] (3) Public key verification: The receiver uses the creator’s public key to decrypt the digital signature and obtain the message digest.

[0085] (4) Verify the digest: The receiver uses the same hash function on the original data to generate a message digest and compares it with the decrypted digest to verify the integrity of the data.

[0086] If the digital signature is verified, the recipient can trust the authenticity and integrity of the original data, and the creator cannot deny the source and content of the data. Digital signature technology is widely used in e-commerce, digital certificates, digital copyright, and other fields. Among them, each signature involved in this application can be considered a digital signature, such as transaction parameter signatures and contract signatures.

[0087] 3. Blockchain is a new application model for computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Blockchain is essentially a decentralized database, a series of data blocks linked using cryptographic methods. Each block contains information about a batch of online transactions, which is used to verify the validity of this information (to prevent counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform, the platform product service layer, and the application service layer.

[0088] 4. A smart contract is a computer protocol designed to communicate, verify, or execute contracts in an information-based manner. Smart contracts allow for trusted transactions without a third party, and these transactions are queryable and irreversible.

[0089] In the embodiments of the present application, please refer to FIG. 1 , which is a schematic diagram of a blockchain system architecture provided by an embodiment of the present application. As shown in FIG. 1 , a blockchain system 100 is a system for sharing data between blockchain nodes. The blockchain system 100 may include multiple blockchain nodes 101 , which may represent individual clients in the data sharing system. Each blockchain node 101 may receive input information during normal operation and maintain shared data within the data sharing system based on the received input information. To ensure information interoperability within the data sharing system, information connections may exist between each blockchain node in the data sharing system, and information can be transmitted between blockchain nodes via these connections. For example, when any blockchain node in the data sharing system receives input information, the other blockchain nodes in the data sharing system obtain the input information according to a consensus algorithm and store the input information as data in the shared data, ensuring that the data stored on all blockchain nodes in the data sharing system is consistent.

[0090] It is understood that any of the blockchain nodes mentioned in the embodiments of the present application may be a computer device, and the computer devices in the embodiments of the present application include but are not limited to terminal devices or servers. In other words, the computer device may be a server or a terminal device, or a system consisting of a server and a terminal device. Alternatively, the computer device may be a terminal device cluster or a server cluster, or a virtual device, etc., without limitation. Among them, the terminal device mentioned above may be an electronic device, including but not limited to a mobile phone, tablet computer, desktop computer, laptop computer, PDA, vehicle-mounted device, augmented reality / virtual reality (AR / VR) device, helmet display, smart TV, wearable device, smart speaker, digital camera, camera and other mobile internet devices (MID) with network access capability, or terminal devices in scenarios such as trains, ships, and flights. Among them, the servers mentioned above can be independent physical servers, or they can be server clusters or distributed systems composed of multiple physical servers. They can also be cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, vehicle-road collaboration, content delivery networks (CDNs), as well as big data and artificial intelligence platforms.

[0091] Optionally, some data involved in the embodiments of the present application can be stored in a computer device, or the data can be stored based on cloud storage technology or a blockchain network, which is not limited here.

[0092] Specifically, see Figure 2, which is a schematic diagram of a transaction management scenario provided by an embodiment of the present application. As shown in Figure 2, taking any blockchain node as an example, it can be recorded as a target node. The target node can obtain transaction data 201, wherein the transaction data 201 may include private transaction data, or may include private transaction data and regular transaction data, or may include regular transaction data, etc. Further, assuming that the transaction data 201 includes private transaction data and regular transaction data, the private transaction corresponding to the private transaction data can be executed, and the regular transaction corresponding to the regular transaction data can be executed. A Merkle management tree 202 can be generated based on the transaction data 201 and the regular transaction corresponding to the regular transaction data. A transaction block is generated based on the Merkle management tree 202 and the transaction data 201, and the transaction block is processed on the chain, that is, the transaction block is added to the blockchain network 203. This approach allows for the execution of both private and regular transactions within a unified system. For transactions that can only be executed by a single or a few blockchain nodes, the same execution process is used as for regular transactions, with only the data generation method for participating in the on-chain storage process being modified. This means that the data generated by the private transaction execution process is not considered in the data (i.e., transaction blocks) that needs to be obtained by multiple blockchain nodes. This allows each blockchain node to obtain the same input and output for the transaction data, even when the private transaction can only be executed by a single or a few blockchain nodes. This allows consensus to be achieved, maintaining consistency in the data processing methods or data processing processes for regular and private transaction data while avoiding the inconsistencies in data obtained by each blockchain node due to the characteristics of private transactions. This allows off-chain businesses to utilize on-chain information transmission channels, simplifying the system architecture, reducing development difficulty and workload, minimizing network vulnerabilities, reducing operational and maintenance difficulties, and improving the convenience and efficiency of transaction management.

[0093] Further, please refer to Figure 3, which is a flowchart of a blockchain-based transaction management method provided in an embodiment of the present application. As shown in Figure 3, any blockchain node is used as the execution subject for description, and the blockchain node is recorded as the target node. The blockchain-based transaction management process includes the following steps:

[0094] Step S301: Acquire transaction data. If the transaction data includes regular transaction data and private transaction data, acquire the regular transaction data from the transaction data, and generate a Merkle management tree based on the transaction data and the regular transactions corresponding to the regular transaction data.

[0095] In an embodiment of the present application, a target node can obtain transaction data, where the transaction data can be transaction data generated by the target node, transaction data sent by other blockchain nodes, or transaction data generated by the target node and other blockchain nodes. The target node can detect whether private transaction data exists in the transaction data. If private transaction data does not exist, the target node executes the transaction corresponding to the transaction data, generates a Merkle management tree based on the transaction data and the transaction corresponding to the transaction data, generates a transaction block based on the Merkle management tree and the transaction data, and uploads the transaction block to the blockchain. If private transaction data exists, the target node obtains regular transaction data from the transaction data, generates a Merkle management tree based on the transaction data and the regular transaction corresponding to the regular transaction data, and then executes steps S302 and S303. Regular transaction data refers to transaction data in the transaction data other than the private transaction data.

[0096] Specifically, the target node can obtain transaction data, trigger a proxy contract based on the transaction data, and call the business contract corresponding to the transaction data through the proxy contract. If the business contract is a regular contract, the transaction data is determined to be regular transaction data; if the business contract is a privacy contract, the transaction data is determined to be privacy transaction data. Optionally, the business contracts deployed in the blockchain system can carry a contract identifier when deployed. The target node can obtain the contract identifier carried by the business contract. If the contract identifier carried by the business contract corresponding to the transaction data is a regular contract identifier, or if the business contract corresponding to the transaction data does not carry a contract identifier, the business contract is determined to be a regular contract; if the contract identifier carried by the business contract corresponding to the transaction data is a privacy contract identifier, the business contract is determined to be a privacy contract. Alternatively, the contract call method of the business contract can be obtained. If the contract call method is a decryption call method, the business contract is determined to be a privacy contract; if the contract call method is a direct call method, the business contract is determined to be a regular contract. Alternatively, if the business contract call fails or the business contract is deployed decrypted, the business contract is determined to be a private contract; if the business contract is deployed directly, the business contract is determined to be a regular contract, etc. Optionally, the number of transaction data can be one or more (i.e., at least two), and the above method can be used to determine the data attributes of each transaction data, that is, to determine whether the transaction data includes regular transaction data and private transaction data.

[0097] A privacy contract is a smart contract used to verify or execute private transactions, and may also be referred to as a privacy smart contract. A regular smart contract is a smart contract used to verify or execute regular transactions, and may also be referred to as a regular contract. Contracts (e.g., business contracts) can be categorized as privacy contracts and regular contracts based on the identifier configured during contract creation or deployment, the contract invocation method, and the contract deployment method. For example, privacy contracts include, but are not limited to, contracts with a privacy identifier, contracts invoking the contract using a decryption invocation method, and contracts deployed using decryption. Regular contracts include, but are not limited to, contracts with or without a regular identifier, contracts invoking the contract using a direct invocation method, and contracts deployed directly.

[0098] Furthermore, if the transaction data includes regular transaction data and private transaction data, the regular transaction data is obtained from the transaction data, and a Merkle management tree is generated based on the transaction data and the regular transactions corresponding to the regular transaction data. Specifically, the Merkle management tree includes a transaction tree, a receipt tree, and a world state tree. A Merkle management tree is a data structure used to store various data in a blockchain system. The transaction tree represents inputs and records transaction inputs, while the receipt tree and the world state tree represent outputs. The receipt tree records transaction outputs, and the world state tree records status information for all accounts. When the inputs and outputs of all blockchain nodes are consistent, the blockchain nodes can be considered consistent. Specifically, the target node can generate a transaction trie based on the transaction data. The transaction trie contains all transaction data (transactions). The transaction data represents transaction records, including but not limited to the sender and recipient of the transaction, and the transaction data volume. Since the number of transactions included in each block in a blockchain system is limited, the transaction trie is typically relatively short, allowing for rapid verification and updating. Optionally, see Figure 4, which is a schematic diagram of a tree-shaped construction scenario provided by an embodiment of the present application. As shown in Figure 4, the Merkel management tree is used to generate a transaction block 401. Specifically, the target node can obtain transaction data 403, which may include but is not limited to the number of transactions, the transaction path (i.e., the direction of resource transfer) and the amount of transaction data (i.e., the amount of data of the resource to be transferred by the exchange corresponding to the transaction data 403), etc., and a transaction data hash is generated based on the transaction data 403, and the transaction data corresponding to the transaction data 403 is hashed to form a transaction tree 4023. Specifically, see the description of the Merkel tree generation process above. The number of transaction data 403 can be one or more, that is, the transaction data hash corresponding to each transaction data 403 can be equivalent to forming a leaf node. Optionally, the transaction data 403 may be divided into multiple transaction data blocks, and the block hash corresponding to each transaction data block may be obtained. The block hash corresponding to each transaction data block may be formed into leaf nodes to generate a transaction tree 4023. Of course, if the transaction tree 4023 is constructed in a block manner, the data block manner adopted by different blockchain nodes should be the same to ensure data consistency.

[0099] The target node can obtain the private on-chain data corresponding to the private transaction data. Specifically, the private on-chain data corresponding to the private transaction data can be determined as a default parameter. This default parameter can be a pre-set fixed parameter used to refer to the private transaction data, such as a placeholder or other meaningless string (e.g., a string consisting of zeros), without limitation. Optionally, the private on-chain data can be data used to construct a receipt tree and a world state tree; or it can include first private on-chain data used to construct a receipt tree and second private on-chain data used to construct a world state tree. Furthermore, regular transaction information generated by executing a regular transaction corresponding to the regular transaction data can be obtained, as well as regular account information corresponding to the regular transaction data. Regular transaction information is information generated by a regular transaction corresponding to the regular transaction data. Regular account information is account information for the regular data. Based on the private on-chain data and the regular transaction information, a receipt trie is constructed, such as receipt tree 4022 shown in FIG. 4 ; based on the private on-chain data and the regular account information, a world state trie is constructed, such as world state tree 4021 shown in FIG. 4 . In other words, when the private transaction corresponding to the private transaction data can only be executed by a single blockchain node or several blockchain nodes, it will lead to inconsistent data among the various blockchain nodes. Therefore, the transaction information corresponding to the private transaction data is referred to as the private on-chain data. This makes it possible to participate in data generation and consensus with the same data regardless of whether the private transaction can be executed, thereby achieving data consistency. This also makes it unnecessary to develop an off-chain transaction system specifically for private transactions, thereby improving the convenience of transaction management.

[0100] When obtaining the regular transaction information generated by executing the regular transaction corresponding to the regular transaction data and the regular account information corresponding to the regular transaction data, the regular smart contract corresponding to the regular transaction data can be called through the regular transaction data. The regular transaction corresponding to the regular transaction data can be executed through the regular smart contract to obtain the regular transaction execution result. The regular transaction execution result is used to represent the result of the regular transaction execution, including a successful transaction execution result or a failed transaction execution result. Regular log information generated during the execution of the regular transaction is obtained, and the regular transaction execution result and the regular log information are combined to form the regular transaction information generated by the regular transaction. The regular transaction information can help verify the legitimacy of the corresponding transaction and query and debug the corresponding transaction. The transaction count of the regular account corresponding to the regular smart contract is updated based on the regular transaction. A regular transaction hash (i.e., a contract hash) is generated based on the transaction count of the regular account. The regular transaction hash and the account data of the regular account are combined to form the regular account information corresponding to the regular transaction data. Optionally, the account data of the regular account may include but is not limited to account resources (i.e., account balance, which represents the amount of data on resources owned by the regular account), contract code and contract data, etc. Regular account information can help verify the legitimacy and consistency of transactions and can support the implementation of smart contracts.

[0101] As shown in Figure 4, the target node can obtain the root node hash in the Account Storage trie 405 and use this root node hash as the storage hash. It can also obtain the account data of the regular account corresponding to the regular transaction data, such as account resources and transaction counts. The storage hash, regular transaction hash, and account data can be combined to form the regular account information 404 of the regular account. A world state tree 4021 can be constructed based on the private on-chain data and the regular account information. Alternatively, if the private on-chain data includes first and second private on-chain data, the world state tree 4021 can be constructed based on the second private on-chain data and the regular account information.

[0102] Among them, the above-mentioned world state tree can maintain the association relationship between account addresses and account information, as shown in Figure 5, which is a schematic diagram of a world state tree data provided by an embodiment of the present application. As shown in Figure 5, the world state tree 501 can maintain the association relationship between account addresses and account information, such as account information 1 corresponding to account address 1, and account information 2 corresponding to account address 2, etc. Among them, taking an account as an example, such as account 502, there are generally two types of accounts: externally owned accounts (EOA) and contract accounts. Among them, EOA is an ordinary account that can transfer resources out (such as transfers) and transfer resources in (such as receiving transfers), while contract accounts are special accounts that contain contract code and contract data. Among them, all contract calls are initially triggered by external accounts. When an external account calls a smart contract, the smart contract can be executed. Subsequently, the contract account can also call other smart contracts, thus forming a complex contract call chain. This chain call design method enables the blockchain system to support various complex smart contracts, thereby realizing more functions. Among them, the contract account can include but is not limited to the transaction number (nonce), which is used to indicate the number of transactions initiated by the contract account. It can be used to prevent replay attacks and ensure that each transaction is unique. When the contract account initiates a new transaction, the transaction number will be updated, such as by one, and the new transaction number will be written into the transaction. Even if an attacker obtains an old transaction, they cannot replay the transaction, thereby improving data security. The contract account can also include account resources (balance), storage hash (storage root) and contract hash (code hash).

[0103] Step S302: Call the privacy contract based on the privacy transaction data, verify the data execution status of the privacy transaction data through the privacy contract, and if the data execution status is executable, execute the privacy transaction corresponding to the privacy contract.

[0104] In an embodiment of the present application, the target node can call a proxy contract based on the private transaction data, and pass the transaction encryption parameters and the transaction parameter signature to the proxy contract; the transaction parameter signature is obtained by signing the transaction encryption parameters with the first object private key of the first participating object. The transaction encryption parameters refer to the encryption parameters used when conducting a transaction. Among them, the transaction encryption parameters and the transaction parameter signature can be data carried in the private transaction data. The transaction encryption parameters can be decrypted by the proxy contract using the target node private key of the target node to obtain the transaction parameters; the target node refers to the node that obtains the transaction data. The privacy contract is called by the proxy contract, the transaction parameters are passed to the privacy contract, and the transaction parameter signature is verified by the privacy contract. If the transaction parameter signature verification passes, the data execution status of the private transaction data is determined to be the data executable state; if the transaction parameter signature verification fails, the data execution status of the private transaction data is determined to be the data non-executable state.

[0105] Alternatively, the proxy contract can be called through the private transaction data. The proxy contract identifies the privacy contract corresponding to the private transaction data. The contract call function in the proxy contract is called, and the privacy contract is called through the contract call function. The data execution status of the private transaction data can be verified through the privacy contract. The verification of the data execution status of the private transaction data through the privacy contract can be seen in the above paragraph.

[0106] Furthermore, if the data execution status is the data executable state, the privacy transaction corresponding to the privacy contract is executed, and step S303 is further executed; if the data execution status is the data non-executable state, step S303 is executed.

[0107] Step S303: Generate a transaction block based on the Merkle management tree and transaction data, and upload the transaction block to the blockchain.

[0108] In an embodiment of the present application, a transaction block is generated based on the Merkel management tree and transaction data, and the transaction block is broadcast to the first consensus node for consensus; if the consensus node passes the consensus on the transaction block, the transaction block is put on the chain. Among them, when the target node broadcasts the transaction block to the first consensus node for consensus, it can also receive the transaction block to be agreed upon sent by the first consensus node, compare the transaction block with the transaction block to be agreed upon, and obtain the first consensus result of the transaction block to be agreed upon. Optionally, if the transaction block is the same as the transaction block to be agreed upon, the data consensus is successfully determined as the first consensus result; if the transaction block is different from the transaction block to be agreed upon, the data consensus failure is determined as the first consensus result. The first consensus result is broadcast to the first consensus node so that the first consensus node can put the transaction block to be agreed upon on the chain when it detects that the consensus on the transaction block to be agreed upon is passed.

[0109] Optionally, the root information of the Merkle management tree can be obtained, and a block header can be constructed based on the root information. The block body can be constructed based on the transaction data, and the block header and block body can be combined to form a transaction block. The root information can include transaction root information of the root node of the transaction tree, receipt root information of the root node of the receipt tree, and state root information of the root node of the world state tree. Alternatively, a block header can be constructed directly based on the Merkle management tree, and a block body can be constructed based on the transaction data. The block header and block body can then be combined to form a transaction block.

[0110] Optionally, there is no restriction on the order of executing the above steps. For example, after obtaining the transaction data, the transaction corresponding to the transaction data may be processed first, including step S302, and then the Merkle management tree (i.e., step S301) and the transaction block (i.e., step S303) may be generated; or, step S301 and step S303 may be executed first, and then step S302, etc., and there is no restriction here.

[0111] In an embodiment of the present application, transaction data can be obtained. If the transaction data includes regular transaction data and private transaction data, regular transaction data is obtained from the transaction data, and a Merkle management tree is generated based on the transaction data and the regular transactions corresponding to the regular transaction data; regular transaction data refers to the transaction data in the transaction data other than the private transaction data; a private contract is called based on the private transaction data, and the data execution status of the private transaction data is verified by the private contract. If the data execution status is a data executable state, the private transaction corresponding to the private contract is executed; a transaction block is generated based on the Merkle management tree and the transaction data, and the transaction block is processed on the chain. Through the above process, the two types of transactions can be integrated into one system. That is, while maintaining the original system architecture of the blockchain node, the on-chain system can be directly used to manage both private transactions and regular transactions, so that off-chain businesses (i.e., private transaction businesses) can also use the on-chain information transmission channel, achieving seamless connection between on-chain and off-chain, simplifying the system architecture, and realizing all business functions in a single system, simplifying the technical solution, and reducing development costs and maintenance difficulties. At the same time, when managing transactions, when data transmission is required, the execution process of private transactions can be ignored, that is, the transaction data and the relevant data of the execution process of regular transactions corresponding to the regular transaction data can be directly transmitted. In this way, even blockchain nodes that cannot execute private transactions can obtain the same execution-related data of private transactions, thereby ensuring the data consistency of multiple transactions under the same system, avoiding the impact of private transactions on the processing process of on-chain data, and improving the convenience and efficiency of transaction management.

[0112] Further, please refer to Figure 6, which is an optional transaction management flow chart provided in an embodiment of the present application. As shown in Figure 6, the process may include the following steps:

[0113] Step S601: deploy the contract.

[0114] In embodiments of the present application, contract deployment, contract invocation, and privacy account management functions can be constructed and integrated into the contract code to generate and deploy a proxy contract. The proxy contract is used to deploy and invoke privacy contracts and manage privacy accounts. The proxy contract utilizes encryption technology to decrypt privacy contracts and contract invocation requests, and can encrypt the return results of contract invocations, thereby protecting privacy and data security. The contract deployment function deploys the encrypted privacy contract code onto the blockchain network, thereby creating a privacy contract. When deploying the privacy contract, the proxy contract can decrypt the encrypted privacy contract code using the node's key, thereby protecting the privacy and security of the privacy contract. The contract invocation function calls a deployed privacy contract and passes in encrypted transaction parameters. When invoking the privacy contract, the proxy contract decrypts the encrypted transaction parameters using the node's key, protecting the privacy and security of the parameters. After the contract invocation is complete, the proxy contract encrypts the return result using the caller's public key and sends it back to the caller. The privacy account management function is used to add an account address to a privacy contract, thereby creating a privacy account. Only privacy accounts can deploy privacy contracts, preventing ordinary users from abusing this function to deploy a large number of privacy contracts. Privacy accounts can be used to protect the privacy and security of accounts, thereby preventing attacks and theft. By deploying a proxy contract, privacy and data security can be protected, while providing a convenient interface that allows developers to more easily deploy and use privacy contracts. The functions included in the proxy contract can be shown in Table 1:

[0115] Table 1

[0116] Furthermore, a privacy contract can be deployed through the contract deployment function within the proxy contract. Specifically, a data encryption key (DEK) can be generated and used to encrypt the privacy contract (referred to as C), resulting in an encrypted privacy contract (referred to as D). The DEK can be considered a symmetric encryption key, used to encrypt and decrypt actual data. This allows for communication where, if the DEK is exposed or leaked, both parties only need to change the DEK, without having to change the key encryption key (KEK). This reduces the number of key renegotiations between the two parties and improves communication security. Furthermore, the first node's first public key is used to encrypt the data encryption key to generate key-protected data. Assuming the privacy contract is deployed on the target node, the target node's target public key is used to encrypt the data encryption key to generate key-protected data. Furthermore, the second object private key of the second participating object is used to generate a contract signature for the encrypted privacy contract and key-protected data. The encrypted privacy contract, key protection data and contract signature are transferred to the proxy contract, and the privacy contract is deployed through the proxy contract, encrypted privacy contract, key protection data and contract signature.

[0117] Among them, when deploying a privacy contract through a proxy contract, an encrypted privacy contract, key protection data, and a contract signature, the contract signature can be verified. If the second participating object is a privacy account, the target node private key of the target node is used to decrypt the key protection data to obtain the data encryption key. In other words, only the privacy account can deploy the privacy contract, improving the accuracy of contract management and contract security; the encrypted privacy contract is decrypted using the data encryption key to obtain the privacy contract and deploy the privacy contract. Optionally, when deploying the privacy contract, the first contract address of the privacy contract can be obtained and the first contract address can be associated with the proxy contract; alternatively, the encrypted privacy contract, key protection data, and contract signature can be directly associated with the proxy contract. Optionally, an optional privacy contract deployment process can be shown in Figure 7, which will not be described in detail here.

[0118] The private account can be a pre-registered account. Specifically, in response to a private account registration request, the proxy contract can verify the registration signature carried in the request. The registration signature is a signature generated by the second private key of the second participant, the second participant being the party registering the private account. If the registration signature verification passes, the account registration status for the private account registration request is updated to pending confirmation, and the private account registration request is forwarded to the management device, which then responds with an account registration confirmation message after verifying the private account registration request. The proxy contract verifies the registration management signature carried in the account registration confirmation message. If the verification passes, the account registration status is updated to confirmed. Based on the account registration status, the second participant is determined to be a private account. Specifically, when the account registration status is confirmed, the account address of the second participant can be obtained, added to the proxy contract, and the second participant indicated by the account address is determined to be a private account. An optional implementation method is shown in Figure 8.

[0119] Step S602: Acquire transaction data, trigger a proxy contract based on the transaction data, and determine private transaction data and regular transaction data in the transaction data based on the triggering of the proxy contract.

[0120] In an embodiment of the present application, the target node can obtain transaction data, trigger a proxy contract based on the transaction data, and invoke the business contract corresponding to the transaction data through the proxy contract. If the business contract is a regular contract, the transaction data is determined to be regular transaction data; if the business contract is a privacy contract, the transaction data is determined to be privacy transaction data. If there are multiple transaction data, the above process can be used to determine whether the transaction data contains privacy transaction data or regular transaction data. For details, please refer to the relevant description of step S301 in Figure 3.

[0121] Step S603: Generate a Merkle management tree based on the transaction data and the regular transactions corresponding to the regular transaction data.

[0122] In the embodiment of this application, please refer to the relevant description of step S301 in Figure 3 and will not be repeated here. A regular transaction corresponding to the regular transaction data can be executed to obtain regular transaction information and regular account information. A Merkle management tree is generated based on the transaction data and the regular transaction corresponding to the regular transaction data, and step S604 is executed. Optionally, a private transaction corresponding to the private transaction data can also be executed, as shown in Figure 9 below, and step S604 is then executed.

[0123] Step S604: Generate a transaction block based on the Merkle management tree and transaction data, and upload the transaction block to the blockchain.

[0124] In the embodiments of this application, please refer to the specific description of step S303 in Figure 3, which will not be repeated here. Of course, if the private transaction corresponding to the private transaction data is not executed in step S603, the private transaction corresponding to the private transaction data can be executed after the transaction block is uploaded to the blockchain.

[0125] Optionally, after executing a private transaction, the private transaction information generated by the private transaction can be obtained, a private block generated based on the private transaction information can be generated, and the private block can be added to the private blockchain. This private blockchain can be considered a private chain and stored locally on the target node. Alternatively, the private transaction information generated by the private transaction can be obtained, and the private data identifier corresponding to the private transaction data in the Merkle management tree can be obtained. The private data identifier can then be associated with the private transaction information and stored.

[0126] Further, referring to Figure 7, Figure 7 is a schematic diagram of a contract deployment process provided by an embodiment of the present application. As shown in Figure 7, assuming that the execution subject is the second node, the process may include the following steps:

[0127] Step S701: Develop a privacy contract.

[0128] In an embodiment of the present application, the development object can develop a privacy contract.

[0129] Step S702: Request to deploy a privacy contract.

[0130] In an embodiment of the present application, the development object can request deployment of a privacy contract through an application.

[0131] Step S703: Generate a data encryption key, and use the data encryption key to encrypt the privacy contract to obtain an encrypted privacy contract.

[0132] In this embodiment of the present application, the second node can generate a data encryption key (DEK) through an application program, and use the DEK to encrypt a privacy contract (referred to as C) to obtain an encrypted privacy contract (referred to as D). The second node can be the node associated with the development object, or any blockchain node in the blockchain network.

[0133] Step S704: Use the first node public key of the first node to encrypt the data encryption key to generate key protection data.

[0134] In this embodiment of the present application, the second node may encrypt the DEK using the first node's public key to generate key protection data (referred to as K). The first node refers to the node to which the privacy contract is deployed, i.e., the node with permission to invoke the privacy contract. Optionally, the second node, the first node, and the target node may be the same node or different nodes; alternatively, the first node, the second node, and the target node may contain two identical nodes, etc., without limitation.

[0135] Step S705: Generate an encrypted privacy contract and a contract signature of the key-protected data using the second object private key of the second participating object.

[0136] In an embodiment of the present application, the second node can use the second object private key of the second participating object to generate a contract signature (which can be called S) of the encrypted privacy contract D and the key protection data K, that is, use the second object private key to sign (D, K) to obtain S.

[0137] Step S706: deploy the privacy contract.

[0138] In this embodiment of the present application, the second node can deploy the privacy contract by calling the proxy contract through the application. Specifically, the application passes (D, K, S) to the proxy contract, and the proxy contract executes steps S707 to S710 to deploy the privacy contract.

[0139] Step S707: Based on the contract signature, determine whether the second participant is a private account.

[0140] In an embodiment of the present application, the second node can detect whether the second participating node is a private account based on the contract signature S. If the second participating object is a private account, step S708 is executed.

[0141] Step S708: Decrypt the key-protected data using the first node private key of the first node to obtain a data encryption key.

[0142] In an embodiment of the present application, (D, K, S) can be directly deployed to the proxy contract to implement the deployment of the privacy contract, that is, regardless of whether the second node is the same node as the first node, it can be directly deployed. Alternatively, when the second node is not the same node as the first node, the second node cannot decrypt the above data. In this case, the second node directly deploys (D, K, S) to the proxy contract to implement the deployment of the privacy contract. The first node can deploy the decrypted privacy contract to the proxy contract. In other words, when the above data cannot be decrypted, or the node does not have the authority to execute the privacy contract, the encrypted privacy contract can be directly deployed. The node with the authority to execute the privacy contract will deploy the decrypted privacy contract. Specifically, taking the second node and the first node as the same node as an example, the decryption deployment process can be to use the first node private key of the first node to decrypt the key protection data K to obtain the data encryption key DEK, and further execute step S709.

[0143] Step S709: Decrypt the encrypted privacy contract using the data encryption key to obtain the privacy contract.

[0144] In the embodiment of the present application, DEK is used to decrypt the encrypted privacy contract D to obtain the privacy contract C.

[0145] Step S710: deploy the privacy contract.

[0146] In an embodiment of the present application, a privacy contract is deployed into a blockchain system. Specifically, the contract address of the privacy contract can be associated with a proxy contract, so that the privacy contract can be called in the proxy contract through the contract call function.

[0147] In this embodiment of the present application, the generated DEK is used to encrypt the privacy contract, ensuring the security of the privacy contract during transmission. The DEK is then encrypted using the node's key and signed using the privacy account's private key, ensuring the security and authenticity of the DEK. Furthermore, based on this encryption process, reverse decryption is performed to ensure the confidentiality and integrity of the privacy contract. This approach allows the deployment and execution of privacy contracts while ensuring confidentiality and integrity.

[0148] Further, referring to Figure 8, Figure 8 is a schematic diagram of an account registration process provided by an embodiment of the present application. As shown in Figure 8, the description can be made using a third node as an example execution subject. The third node can be any blockchain node in the blockchain system. The process may include the following steps:

[0149] Step S801: deploy the proxy contract.

[0150] In the embodiment of the present application, the development object can request the deployment of the proxy contract through the application. Optionally, the management object of the proxy contract can be set.

[0151] Step S802: deploy the proxy contract.

[0152] In an embodiment of the present application, a proxy contract can be deployed in a contract virtual machine through an application.

[0153] Step S803: register a private account.

[0154] In an embodiment of the present application, the second participant (a private account after successful registration) sends a private account registration request to the contract virtual machine through an application.

[0155] Step S804: register a private account.

[0156] In an embodiment of the present application, the third node forwards the privacy account registration request to the contract virtual machine through the application.

[0157] Step S805: register a private account.

[0158] In an embodiment of the present application, a proxy contract is called through a contract virtual machine to register a privacy account.

[0159] Step S806: Change the account registration status.

[0160] In an embodiment of the present application, the third node can verify the registration signature carried by the privacy account registration request through a proxy contract. If the registration signature verification is passed, the account registration status of the privacy account registration request will be updated to a pending confirmation status, and the privacy account registration request will be forwarded to the management device, which is the device associated with the management object. Of course, the management device can be a third node or other device.

[0161] Step S807: Approve the privacy account.

[0162] In an embodiment of the present application, the management object can approve the privacy account.

[0163] Step S808: Approve the privacy account.

[0164] In an embodiment of the present application, the third node can send the account approval result to the contract virtual machine through an application.

[0165] Step S809: delivering the approval result.

[0166] In an embodiment of the present application, the third node can pass the account approval result to the proxy contract through the contract virtual machine. If the account approval result is an account registration confirmation message, the account registration confirmation message can be passed to the proxy contract.

[0167] Step S810: Determine a private account.

[0168] In an embodiment of the present application, the third node can verify the registration management signature carried by the account registration confirmation message through the proxy contract and perform signature verification. If the registration management signature verification is passed, the account registration status is updated to the confirmed status, and the second participating object is determined to be a privacy account.

[0169] In the embodiment of the present application, by adding a privacy account, only the privacy account can deploy the privacy contract, thereby protecting the privacy and security of the account, thereby avoiding large-scale malicious deployment of privacy contracts, and improving the efficiency of contract management and the security of contract deployment.

[0170] Further, referring to Figure 9, Figure 9 is a schematic diagram of a contract call process provided by an embodiment of the present application. As shown in Figure 9, the process is described with the target node as the execution subject. The process may include the following steps:

[0171] Step S901: Request to call the privacy contract.

[0172] In an embodiment of the present application, the development object can request to call a privacy contract.

[0173] Step S902: Request to call the privacy contract.

[0174] In an embodiment of the present application, the development object can request the application to call a privacy contract.

[0175] Step S903: encrypt the transaction parameters using the target node public key of the target node to obtain transaction encryption parameters.

[0176] In an embodiment of the present application, the transaction parameters (args) can be encrypted using the target node public key of the target node through an application program to obtain transaction encryption parameters.

[0177] Step S904: Use the first object private key of the first participating object to sign the transaction encryption parameter to obtain a transaction parameter signature.

[0178] In an embodiment of the present application, the first object private key of the first participating object may be used to sign the transaction encryption parameter to obtain a transaction parameter signature.

[0179] Steps S903 to S904 may be implemented in the target node or in a development device associated with the development object.

[0180] Step S905: calling the privacy contract.

[0181] In this embodiment of the present application, the target node can call the proxy contract through the application, and then call the privacy contract in the proxy contract. Specifically, the transaction encryption parameters and transaction parameter signature are passed to the proxy contract.

[0182] Step S906: Decrypt the transaction encryption parameters using the target node private key of the target node to obtain the transaction parameters.

[0183] In an embodiment of the present application, the target node can use the target node private key of the target node to decrypt the transaction encryption parameters to obtain the transaction parameters args.

[0184] Step S907: Call the privacy contract through transaction parameter request.

[0185] In an embodiment of the present application, the target node can call a privacy contract through a transaction parameter request in a proxy contract. Specifically, the target node can call the contract call function in the proxy contract and call the privacy contract based on the contract address and transaction parameters of the privacy contract.

[0186] Step S908: Detect the contract calling authority of the first participating object.

[0187] In an embodiment of the present application, the target node may detect the contract calling permission of the first participating object. If it is detected that the first participating object has the contract calling permission for the privacy contract, step S909 is executed.

[0188] Step S909: calling the privacy contract.

[0189] In the embodiments of this application, encryption, signature, and decryption algorithms are used to ensure the confidentiality, integrity, and authenticity of data. The proxy contract ensures the security and reliability of the privacy contract, preventing malicious attacks and data leaks. The specific privacy contract contains the business operation logic and can be encrypted to prevent unauthorized callers from invoking the privacy contract.

[0190] Further, please refer to Figure 10, which is a schematic diagram of a blockchain-based transaction management device provided in an embodiment of the present application. The blockchain-based transaction management device can be a computer program (including program code, etc.) running on a computer device. For example, the blockchain-based transaction management device can be an application software; the device can be used to execute the corresponding steps of the method provided in the embodiment of the present application. As shown in Figure 10, the blockchain-based transaction management device 1000 can be used in the computer device in the embodiment corresponding to Figure 3. Specifically, the device can include: a transaction acquisition module 11, a general acquisition module 12, a tree construction module 13, a state determination module 14, a privacy execution module 15 and a block chain module 16.

[0191] Transaction acquisition module 11, used to obtain transaction data;

[0192] A regular acquisition module 12, configured to acquire regular transaction data from the transaction data if the transaction data includes regular transaction data and private transaction data;

[0193] A tree construction module 13 is configured to generate a Merkle management tree based on the transaction data and regular transactions corresponding to regular transaction data; regular transaction data refers to transaction data other than private transaction data;

[0194] A status determination module 14 is configured to call a privacy contract based on the private transaction data and verify the data execution status of the private transaction data through the privacy contract;

[0195] The privacy execution module 15 is used to execute the privacy transaction corresponding to the privacy contract if the data execution status is the data executable state;

[0196] The block chain module 16 is used to generate transaction blocks based on the Merkle management tree and transaction data, and to process the transaction blocks on the chain.

[0197] The Merkle management tree includes a transaction tree, a receipt tree, and a world state tree. The tree construction module 13 includes:

[0198] A first construction unit 131 is configured to generate a transaction tree based on transaction data;

[0199] The privacy construction unit 132 is used to obtain the private on-chain data corresponding to the private transaction data;

[0200] An information acquisition unit 133 is configured to acquire regular transaction information generated by executing a regular transaction corresponding to the regular transaction data, and to acquire regular account information corresponding to the regular transaction data;

[0201] The second construction unit 134 is used to construct a receipt tree based on the private on-chain data and regular transaction information, and to construct a world state tree based on the private on-chain data and regular account information.

[0202] The information acquisition unit 133 includes:

[0203] The result acquisition subunit 1331 is used to call the conventional smart contract corresponding to the conventional transaction data through the conventional transaction data, execute the conventional transaction corresponding to the conventional transaction data through the conventional smart contract, and obtain the conventional transaction execution result;

[0204] The information acquisition subunit 1332 is used to acquire the regular log information generated during the execution of the regular transaction, and combine the regular transaction execution result and the regular log information to form the regular transaction information generated by the regular transaction;

[0205] The information composition subunit 1333 is used to update the transaction count of the regular account corresponding to the regular smart contract based on the regular transaction, generate a regular transaction hash according to the transaction count of the regular account, and combine the regular transaction hash and the account data of the regular account to form the regular account information corresponding to the regular transaction data.

[0206] The state determination module 14 includes:

[0207] The parameter transfer unit 141 is used to call the proxy contract based on the private transaction data and transfer the transaction encryption parameters and the transaction parameter signature to the proxy contract; the transaction parameter signature is obtained by signing the transaction encryption parameters with the first object private key of the first participant;

[0208] The parameter acquisition unit 142 is configured to decrypt the transaction encryption parameters using the target node private key of the target node through the proxy contract to obtain the transaction parameters; the target node is the node that obtains the transaction data;

[0209] The parameter verification unit 143 is used to call the privacy contract through the proxy contract, pass the transaction parameters to the privacy contract, and verify the signature of the transaction parameters through the privacy contract;

[0210] A state determination unit 144 is configured to determine that the data execution state of the private transaction data is a data executable state if the transaction parameter signature verification passes;

[0211] The state determination unit 144 is further configured to determine that the data execution state of the private transaction data is a data non-executable state if the transaction parameter signature verification fails.

[0212] The block chain module 16 includes:

[0213] The block consensus unit 161 is used to generate a transaction block based on the Merkle management tree and transaction data, and broadcast the transaction block to the first consensus node for consensus;

[0214] The block comparison unit 162 is configured to receive the transaction block to be agreed upon sent by the first consensus node, compare the transaction block with the transaction block to be agreed upon, obtain a first consensus result of the transaction block to be agreed upon, and broadcast the first consensus result to the first consensus node, so that the first consensus node can upload the transaction block to the blockchain when detecting that the consensus of the transaction block to be agreed upon has been passed.

[0215] The block chain unit 163 is used to upload the transaction block to the chain if the consensus node passes the consensus on the transaction block.

[0216] The device 1000 further includes:

[0217] The contract encryption module 17 is used to generate a data encryption key and encrypt the privacy contract using the data encryption key to obtain an encrypted privacy contract;

[0218] The contract signing module 18 is configured to encrypt the data encryption key using the target node public key of the target node to generate key protection data, and to generate a contract signature for the encrypted privacy contract and the key protection data using the second object private key of the second participating object;

[0219] Data transmission module 19, used to transmit the encrypted privacy contract, key protection data and contract signature to the proxy contract;

[0220] The contract deployment module 21 is used to deploy privacy contracts through proxy contracts, encrypted privacy contracts, key protection data and contract signatures.

[0221] The contract deployment module 21 includes:

[0222] The key acquisition unit 211 is used to verify the contract signature. If the second participant is a private account, the target node private key of the target node is used to decrypt the key-protected data to obtain the data encryption key.

[0223] The contract deployment unit 212 is used to decrypt the encrypted privacy contract using the data encryption key to obtain the privacy contract and deploy the privacy contract.

[0224] The device 1000 further includes:

[0225] The registration signature verification module 22 is used to respond to the privacy account registration request and verify the registration signature carried in the privacy account registration request through the proxy contract; the registration signature is a signature generated by the second object private key of the second participant;

[0226] The registration confirmation module 23 is configured to update the account registration status of the privacy account registration request to a pending confirmation state if the registration signature verification is successful, and forward the privacy account registration request to the management device, so that the management device returns an account registration confirmation message after verifying the privacy account registration request;

[0227] The confirmation and verification module 24 is used to verify the registration management signature carried in the account registration confirmation message through the proxy contract. If the registration management signature verification passes, the account registration status is updated to the confirmed status;

[0228] The privacy determination module 25 is configured to determine the second participant as a privacy account based on the account registration status.

[0229] The device 1000 further includes:

[0230] The proxy deployment module 26 is used to build contract deployment, contract call, and privacy account management functions, integrate the contract deployment, contract call, and privacy account management functions into the contract code, generate a proxy contract, and deploy the proxy contract;

[0231] The state determination module 14 is specifically configured to:

[0232] Call the proxy contract through private transaction data, and determine the privacy contract corresponding to the private transaction data in the proxy contract;

[0233] Call the contract call function in the proxy contract, use the contract call function to call the privacy contract, and verify the data execution status of the privacy transaction data through the privacy contract.

[0234] The device 1000 further includes:

[0235] The privacy storage module 27 is used to obtain the private transaction information generated by the private transaction, generate a private block based on the private transaction information, and add the private block to the private blockchain; or

[0236] The privacy storage module 27 is further configured to obtain the private transaction information generated by the private transaction, obtain the private data identifier corresponding to the private transaction data in the Merkle management tree, and associate the private data identifier with the private transaction information for storage.

[0237] The present application provides a blockchain-based transaction management device, which can obtain transaction data. If the transaction data includes regular transaction data and private transaction data, the regular transaction data is obtained from the transaction data, and a Merkle management tree is generated based on the transaction data and the regular transaction corresponding to the regular transaction data; regular transaction data refers to transaction data in the transaction data other than private transaction data; a private contract is called based on the private transaction data, and the data execution status of the private transaction data is verified by the private contract. If the data execution status is a data executable state, the private transaction corresponding to the private contract is executed; a transaction block is generated based on the Merkle management tree and the transaction data, and the transaction block is processed on the chain. Through the above process, the two types of transactions can be integrated into a single system. That is, while maintaining the original system architecture of the blockchain node, the on-chain system can be directly used to manage both private transactions and regular transactions, so that off-chain businesses (i.e., private transaction businesses) can also use the on-chain information transmission channel, achieving seamless connection between on-chain and off-chain, simplifying the system architecture, and realizing all business functions in a single system, simplifying the technical solution, and reducing development costs and maintenance difficulties. At the same time, when managing transactions, when data transmission is required, the execution process of private transactions can be ignored, that is, the transaction data and the relevant data of the execution process of regular transactions corresponding to the regular transaction data can be directly transmitted. In this way, even blockchain nodes that cannot execute private transactions can obtain the same execution-related data of private transactions, thereby ensuring the data consistency of multiple transactions under the same system, avoiding the impact of private transactions on the processing process of on-chain data, and improving the convenience and efficiency of transaction management.

[0238] Referring to Figure 11, Figure 11 is a schematic diagram of the structure of a computer device provided in an embodiment of the present application. As shown in Figure 11, the computer device in an embodiment of the present application may include: one or more processors 1101, a memory 1102, and an input / output interface 1103. The processor 1101, the memory 1102, and the input / output interface 1103 are connected via a bus 1104. The memory 1102 is used to store a computer program, which includes program instructions. The input / output interface 1103 is used for data exchange between different blockchain nodes, or for data exchange between different smart contracts. The processor 1101 is used to execute the program instructions stored in the memory 1102.

[0239] The processor 1101 may perform the following operations:

[0240] Obtain transaction data. If the transaction data includes regular transaction data and private transaction data, obtain the regular transaction data from the transaction data and generate a Merkle management tree based on the transaction data and the regular transactions corresponding to the regular transaction data. Regular transaction data refers to the transaction data excluding private transaction data.

[0241] The privacy contract is called based on the private transaction data. The data execution status of the private transaction data is verified through the privacy contract. If the data execution status is executable, the private transaction corresponding to the privacy contract is executed.

[0242] Generate transaction blocks based on the Merkle management tree and transaction data, and upload the transaction blocks to the chain.

[0243] In some feasible implementations, the processor 1101 may be a central processing unit (CPU), or may be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor, or the processor may be any conventional processor, etc.

[0244] The memory 1102 may include a read-only memory and a random access memory, and provides instructions and data to the processor 1101 and the input / output interface 1103. A portion of the memory 1102 may also include a non-volatile random access memory. For example, the memory 1102 may also store device type information.

[0245] In a specific implementation, the computer device can execute the implementation methods provided by the various steps in Figure 3 through its built-in functional modules. For details, please refer to the implementation methods provided by the various steps in Figure 3, which will not be repeated here.

[0246] The embodiment of the present application provides a computer device comprising: a processor, an input / output interface, and a memory. The processor obtains a computer program in the memory, executes the various steps of the method shown in FIG3, and performs a blockchain-based transaction management operation. The embodiment of the present application obtains transaction data. If the transaction data includes regular transaction data and private transaction data, the regular transaction data is obtained from the transaction data, and a Merkle management tree is generated based on the transaction data and the regular transactions corresponding to the regular transaction data; the regular transaction data refers to the transaction data other than the private transaction data in the transaction data; a private contract is called based on the private transaction data, and the data execution status of the private transaction data is verified by the private contract. If the data execution status is a data executable state, the private transaction corresponding to the private contract is executed; a transaction block is generated based on the Merkle management tree and the transaction data, and the transaction block is uploaded to the blockchain. Through the above process, both types of transactions can be integrated into a single system. This means that while maintaining the existing system architecture of blockchain nodes, the on-chain system can be used to manage both private transactions and regular transactions. This allows off-chain businesses (i.e., private transactions) to utilize the on-chain information transmission channel, achieving seamless integration between the on-chain and off-chain systems. This simplifies the system architecture, enabling all business functions to be implemented within a single system, simplifying technical solutions and reducing development costs and maintenance difficulties. Furthermore, when managing transactions and data transmission, the execution process of private transactions can be ignored. Instead, transaction data and the corresponding regular transaction data can be directly transmitted. This allows even blockchain nodes that cannot execute private transactions to obtain the same private transaction execution-related data, thereby ensuring data consistency across multiple transactions within the same system and avoiding the impact of private transactions on the on-chain data processing process, thereby improving the convenience and efficiency of transaction management.

[0247] The embodiment of the present application also provides a computer-readable storage medium, which stores a computer program, and the computer program is suitable for being loaded by the processor and executing the blockchain-based transaction management method provided by each step in Figure 3. For details, please refer to the implementation methods provided in each step in Figure 3, which will not be repeated here. In addition, the description of the beneficial effects of adopting the same method will not be repeated. For technical details not disclosed in the computer-readable storage medium embodiment involved in this application, please refer to the description of the method embodiment of this application. As an example, the computer program can be deployed to be executed on one computer device, or on multiple computer devices located at one location, or on multiple computer devices distributed at multiple locations and interconnected by a communication network.

[0248] The computer-readable storage medium can be the blockchain-based transaction management device provided in any of the aforementioned embodiments, or the internal storage unit of the computer device, such as the computer device's hard drive or memory. The computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc. Furthermore, the computer-readable storage medium can include both the internal storage unit of the computer device and an external storage device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium can also be used to temporarily store data that has been output or is about to be output.

[0249] The present application also provides a computer program product or computer program, which includes 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 the processor executes the computer instructions, causing the computer device to perform the methods provided in the various optional embodiments of FIG3 , thereby integrating the two types of transactions into a single system. That is, while maintaining the original system architecture of the blockchain node, the on-chain system can be directly used to manage both private transactions and regular transactions, allowing off-chain businesses (i.e., private transactions) to use the on-chain information transmission channel, achieving seamless integration between the on-chain and off-chain, simplifying the system architecture, and enabling all business functions to be implemented in a single system, simplifying the technical solution, and reducing development costs and maintenance difficulties. At the same time, when managing transactions, when data transmission is required, the execution process of private transactions can be ignored, that is, the transaction data and the relevant data of the execution process of regular transactions corresponding to the regular transaction data can be directly transmitted. In this way, even blockchain nodes that cannot execute private transactions can obtain the same execution-related data of private transactions, thereby ensuring the data consistency of multiple transactions under the same system, avoiding the impact of private transactions on the processing process of on-chain data, and improving the convenience and efficiency of transaction management.

[0250] The terms "first", "second", etc. in the description, claims, and drawings of the embodiments of the present application are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "comprising" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, apparatus, product, or device comprising a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0251] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in this description according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0252] The methods and related devices provided in the embodiments of the present application are described with reference to the method flow charts and / or schematic diagrams provided in the embodiments of the present application. Specifically, each process and / or block in the method flow charts and / or schematic diagrams, as well as combinations of processes and / or blocks in the flow charts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable blockchain-based transaction management device to produce a machine, such that the instructions executed by the processor of the computer or other programmable blockchain-based transaction management device generate a device for implementing the functions specified in one or more processes in the flow charts and / or one or more blocks in the schematic diagrams. These computer program instructions can also be stored in a computer-readable memory capable of directing the computer or other programmable blockchain-based transaction management device to operate in a specific manner, such that the instructions stored in the computer-readable memory generate an article of manufacture including instruction means that implement the functions specified in one or more processes in the flow charts and / or one or more blocks in the schematic diagrams. These computer program instructions can also be loaded onto a computer or other programmable blockchain-based transaction management device, so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the structural diagram.

[0253] The steps in the method of the embodiment of the present application can be adjusted in order, combined and deleted according to actual needs.

[0254] The modules in the device of the embodiment of the present application can be merged, divided and deleted according to actual needs.

[0255] The above disclosure is only a preferred embodiment of the present application, and certainly cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made according to the claims of the present application are still within the scope covered by the present application.

Claims

1. A transaction management method based on blockchain, characterized in that: The method comprises: Acquire transaction data. If the transaction data includes regular transaction data and private transaction data, acquire the regular transaction data from the transaction data, and generate a Merkle management tree according to the transaction data and regular transactions corresponding to the regular transaction data; the regular transaction data refers to transaction data in the transaction data excluding the private transaction data; Calling a privacy contract based on the privacy transaction data, verifying the data execution status of the privacy transaction data through the privacy contract, and executing the privacy transaction corresponding to the privacy contract if the data execution status is a data executable state; A transaction block is generated according to the Merkel management tree and the transaction data, and the transaction block is put on-chain.

2. The method according to claim 1, characterized in that The Merkle management tree includes a transaction tree, a receipt tree and a world state tree; the generating of the Merkle management tree according to the transaction data and the conventional transaction corresponding to the conventional transaction data includes: generating the transaction tree based on the transaction data; Obtain the private on-chain data corresponding to the private transaction data, obtain the conventional transaction information generated by executing the conventional transaction corresponding to the conventional transaction data, and obtain the conventional account information corresponding to the conventional transaction data; The receipt tree is constructed based on the private on-chain data and the regular transaction information, and the world state tree is constructed based on the private on-chain data and the regular account information.

3. The method according to claim 2, characterized in that The obtaining of conventional transaction information generated by executing the conventional transaction corresponding to the conventional transaction data, and obtaining of conventional account information corresponding to the conventional transaction data, includes: Calling a conventional smart contract corresponding to the conventional transaction data through the conventional transaction data, executing a conventional transaction corresponding to the conventional transaction data through the conventional smart contract, and obtaining a conventional transaction execution result; Acquire the conventional log information generated during the execution of the conventional transaction, and combine the conventional transaction execution result and the conventional log information to form the conventional transaction information generated by the conventional transaction; The transaction number of the regular account corresponding to the regular smart contract is updated based on the regular transaction, a regular transaction hash is generated according to the transaction number of the regular account, and the regular transaction hash and the account data of the regular account are combined to form the regular account information corresponding to the regular transaction data.

4. The method according to any one of claims 1 to 3, characterized in that The calling of the privacy contract based on the privacy transaction data and verifying the data execution status of the privacy transaction data through the privacy contract includes: Based on the private transaction data, the proxy contract is called, and the transaction encryption parameters and the transaction parameter signature are passed to the proxy contract; the transaction parameter signature is obtained by signing the transaction encryption parameters with the first object private key of the first participating object; The transaction encryption parameters are decrypted by the proxy contract using the target node private key of the target node to obtain the transaction parameters; the target node refers to the node for obtaining the transaction data; Calling the privacy contract through the proxy contract, passing the transaction parameters to the privacy contract, and verifying the signature of the transaction parameters through the privacy contract; If the transaction parameter signature verification is successful, then the data execution state of the private transaction data is determined to be a data executable state; If the transaction parameter signature verification fails, the data execution state of the private transaction data is determined to be a data non-executable state.

5. The method according to any one of claims 1 to 4, characterized in that The generating a transaction block according to the Merkel management tree and the transaction data, and performing on-chain processing on the transaction block, includes: Generate a transaction block according to the Merkle management tree and the transaction data, and broadcast the transaction block to the first consensus node for consensus; Receive the transaction block to be agreed upon sent by the first consensus node, compare the transaction block with the transaction block to be agreed upon, obtain a first consensus result for the transaction block to be agreed upon, and broadcast the first consensus result to the first consensus node, so that the first consensus node can process the transaction block to be agreed upon on the chain when detecting that the consensus on the transaction block to be agreed upon is passed; If the consensus node passes the consensus on the transaction block, the transaction block will be put on the chain.

6. The method according to any one of claims 1 to 5, characterized in that The method further comprises: Generate a data encryption key, and use the data encryption key to encrypt the privacy contract to obtain an encrypted privacy contract; The target node public key of the target node is used to encrypt the data encryption key to generate key protection data, and the second object private key of the second participating object is used to generate a contract signature for the encrypted privacy contract and the key protection data; The encrypted privacy contract, the key protection data and the contract signature are transmitted to the proxy contract, and the privacy contract is deployed through the proxy contract, the encrypted privacy contract, the key protection data and the contract signature.

7. The method according to claim 6, characterized in that The deploying of the privacy contract through the proxy contract, the encrypted privacy contract, the key protection data and the contract signature includes: Performing signature verification on the contract signature, and if the second participant is a private account, using the target node private key of the target node to decrypt the key protection data to obtain the data encryption key; The encrypted privacy contract is decrypted using the data encryption key to obtain the privacy contract, and the privacy contract is deployed.

8. The method according to claim 7, characterized in that The method further comprises: In response to the privacy account registration request, verify the registration signature carried by the privacy account registration request through the proxy contract; the registration signature refers to the signature generated by the second object private key of the second participating object; If the registration signature verification is successful, the account registration status of the privacy account registration request is updated to a pending confirmation status, and the privacy account registration request is forwarded to the management device, so that the management device feeds back an account registration confirmation message after verifying the privacy account registration request; The registration management signature carried by the account registration confirmation message is verified through the proxy contract. If the registration management signature is verified, the account registration status is updated to the confirmed status; Based on the account registration status, the second participant is determined as a private account.

9. The method according to any one of claims 1 to 8, characterized in that The method further comprises: Constructing contract deployment function, contract calling function and privacy account management function, integrating the contract deployment function, contract calling function and privacy account management function into the contract code, generating a proxy contract, and deploying the proxy contract; The calling of the privacy contract based on the privacy transaction data and verifying the data execution status of the privacy transaction data through the privacy contract includes: Calling the proxy contract through the private transaction data, and determining the private contract corresponding to the private transaction data in the proxy contract; The contract calling function in the proxy contract is called, the privacy contract is called by the contract calling function, and the data execution status of the privacy transaction data is verified through the privacy contract.

10. The method according to any one of claims 1 to 9, characterized in that The method further comprises: Obtaining the private transaction information generated by the private transaction, generating a private block according to the private transaction information, and adding the private block to the private blockchain; or Obtain the privacy transaction information generated by the privacy transaction, obtain the privacy data identifier corresponding to the privacy transaction data in the Merkel management tree, and associate the privacy data identifier with the privacy transaction information for storage.

11. A transaction management device based on blockchain, characterized in that: The device comprises: Transaction acquisition module, used to obtain transaction data; A conventional acquisition module, configured to acquire the conventional transaction data from the transaction data if the transaction data includes conventional transaction data and private transaction data; A tree construction module, used to generate a Merkle management tree according to the transaction data and the regular transaction corresponding to the regular transaction data; the regular transaction data refers to the transaction data other than the private transaction data in the transaction data; A state determination module, configured to call a privacy contract based on the privacy transaction data and verify the data execution state of the privacy transaction data through the privacy contract; A privacy execution module, configured to execute the privacy transaction corresponding to the privacy contract if the data execution state is a data executable state; The block chain module is used to generate a transaction block according to the Merkel management tree and the transaction data, and to process the transaction block on the chain.

12. A computer device, characterized in that: Includes processor, memory, input and output interfaces; The processor is connected to the memory and the input / output interface respectively, wherein the input / output interface is used to receive and output data, the memory is used to store a computer program, and the processor is used to call the computer program so that the computer device executes the method described in any one of claims 1-10.

13. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and the computer program is suitable for being loaded and executed by a processor, so that a computer device having the processor executes the method according to any one of claims 1 to 10.

14. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the method according to any one of claims 1 to 10 is implemented.

Images