Contract processing method and device based on block chain, equipment, medium and product

Abstract

The invention provides a blockchain-based contract processing method and device, equipment, a medium and a product. The method comprises the steps that a transaction request is received, the transaction request is used for requesting to execute a target transaction on a block chain, and the transaction request carries a contract identifier of a target smart contract needing to be called for executing the target transaction; obtaining a contract type of the target smart contract, wherein the contract type of the smart contract supported by the block chain at least comprises a first type; the smart contract of the first type is stored in a contract warehouse of central auditing equipment associated with the block chain, and contract files of the smart contract stored in the contract warehouse pass contract detection processing of the central auditing equipment; if the contract type of the target smart contract is a first type, acquiring the target smart contract from a contract warehouse of the central auditing device according to a contract identifier of the target smart contract; and calling the target smart contract to execute the target transaction. The smart contract is stored based on the central auditing device, and the storage pressure of the block chain node can be reduced.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a blockchain-based contract processing method, a blockchain-based contract processing device, a computer device, a computer-readable storage medium, and a computer program product. Background Art

[0002] In blockchain, there are often various smart contracts involved, which are often uploaded and deployed in the blockchain by users in advance. That is to say, each blockchain node in the blockchain needs to store all the smart contracts on the chain. For blockchain, there is a situation where the contract files of a large number of smart contracts are redundantly stored. This is not conducive to the effective storage of smart contracts and is likely to cause a certain storage burden on the blockchain nodes on the chain. Summary of the invention

[0003] The embodiments of the present application propose a blockchain-based contract processing method, apparatus, device, medium and product, which can store smart contracts processed through contract detection in a central audit device associated with the blockchain, thereby reducing the contract storage burden of the node and improving the accuracy of the smart contract.

[0004] On the one hand, an embodiment of the present application provides a blockchain-based contract processing method, the method comprising:

[0005] Receive a transaction request, which is used to request the execution of a target transaction on the blockchain. The transaction request carries the contract identifier of the target smart contract to be called to execute the target transaction;

[0006] Obtaining the contract type of the target smart contract, the contract types of smart contracts supported by the blockchain include at least the first type; the first type of smart contracts are stored in the contract warehouse of the central audit device associated with the blockchain, and the contract files of the smart contracts stored in the contract warehouse have passed the contract detection processing of the central audit device;

[0007] If the contract type of the target smart contract is the first type, the target smart contract is obtained from the contract warehouse of the central audit device according to the contract identifier of the target smart contract;

[0008] Call the target smart contract to execute the target transaction.

[0009] On the one hand, an embodiment of the present application provides a blockchain-based contract processing method, the method comprising:

[0010] Receive a contract acquisition request sent by a blockchain node, where the contract acquisition request is generated after determining that the contract type of the target smart contract to be called to execute the target transaction is the first type, and the transaction request of the target transaction carries the contract identifier of the target smart contract;

[0011] According to the contract identifier of the target smart contract, the target smart contract is obtained from the contract warehouse. The contract files of the smart contract stored in the contract warehouse have passed the contract detection process;

[0012] The target smart contract is returned to the blockchain node, and the target smart contract is used to trigger the execution of the target transaction on the blockchain.

[0013] On the one hand, an embodiment of the present application provides a blockchain-based contract processing device, the device comprising:

[0014] A receiving unit, configured to receive a transaction request, wherein the transaction request is used to request execution of a target transaction on a blockchain, and the transaction request carries a contract identifier of a target smart contract to be called to execute the target transaction;

[0015] An acquisition unit is used to acquire a contract type of a target smart contract, where the contract types of smart contracts supported by the blockchain include at least a first type; the first type of smart contracts are stored in a contract repository of a central audit device associated with the blockchain, and the contract files of the smart contracts stored in the contract repository have passed the contract detection process of the central audit device;

[0016] The acquisition unit is further configured to acquire the target smart contract from the contract repository of the central audit device according to the contract identifier of the target smart contract if the contract type of the target smart contract is the first type;

[0017] The processing unit is used to call the target smart contract to execute the target transaction.

[0018] In a possible implementation, the contract processing method is executed by a blockchain node, and an authentication module is configured in the blockchain node; the transaction request is generated after the request object signs the target transaction; after the receiving unit receives the transaction request, the processing unit is further used to perform the following operations:

[0019] Parse the transaction request and obtain the signature data of the request object;

[0020] According to the signature data, the authentication module is called to perform authentication processing on the request object, and the authentication processing includes: any one or more of signature verification processing and permission verification processing;

[0021] If the authentication of the request object is passed and the contract type of the target smart contract is the first type, the step of obtaining the target smart contract from the contract repository of the central audit device according to the contract identifier of the target smart contract is triggered.

[0022] In a possible implementation, a virtual machine module is further configured in the blockchain node, and the virtual machine module includes: a contract identification submodule, a contract cache submodule, and a contract download submodule; the processing unit method is also used to perform the following operations:

[0023] Call the contract identification submodule to identify the contract type of the target smart contract;

[0024] If the contract type of the target smart contract is identified as the first type, check whether the target smart contract exists in the contract cache submodule;

[0025] If it does not exist, the contract download submodule is called to access the central audit device to obtain the target smart contract to be called from the contract repository of the central audit device.

[0026] In a possible implementation, the virtual machine module further includes a contract authentication submodule; and the processing unit is further configured to perform the following operations:

[0027] Receive the target smart contract, the contract hash of the target smart contract, and the signature data of the central audit device returned by the central audit device;

[0028] Call the contract authentication submodule to verify the contract hash of the target smart contract and the signature data of the central audit device;

[0029] If it is determined that both the contract hash and signature data are verified, the target smart contract is stored in the contract cache submodule to trigger the call of the target smart contract from the contract cache submodule to execute the target transaction.

[0030] In a possible implementation, the contract type of the smart contract supported by the blockchain further includes a second type, and the second type of smart contract is stored on the blockchain; the virtual machine module further includes a system contract submodule; before obtaining the target smart contract from the contract repository of the central audit device according to the contract identifier of the target smart contract, the processing unit is further used to perform the following operations:

[0031] Receive a node registration request initiated by an administrator object for a central audit device. The node registration request is used to request a blockchain node to register its identity with the central audit device. The node registration request carries the target registration address of the central audit device to be accessed.

[0032] If the contract type of the smart contract to be called by the node registration request is the second type, the system contract submodule is called to access the central audit device indicated by the target registration address for identity registration;

[0033] Among them, the blockchain node that completes identity registration is associated with the central audit device.

[0034] In a possible implementation, the node registration request is generated after signature processing of the administrator object; after receiving the node registration request initiated by the administrator object for the central audit device, the processing unit is further used to perform the following operations:

[0035] Call the authentication module to authenticate the administrator object. The authentication process includes: any one or more of signature verification and authority verification.

[0036] If the administrator object is authenticated, the contract identification submodule is called to identify the contract type of the smart contract that needs to be called by the node registration request.

[0037] In a possible implementation, a contract coroutine is running in the virtual machine module, and the target transaction includes multiple subtasks to be executed; the processing unit calls the target smart contract to execute the target transaction, and performs the following operations:

[0038] Run the contract coroutine corresponding to the target smart contract in the virtual machine module;

[0039] Switch to execute each subtask in the contract coroutine corresponding to the target smart contract to obtain the execution results of each subtask.

[0040] On the one hand, an embodiment of the present application provides a blockchain-based contract processing device, the device comprising:

[0041] A receiving unit, configured to receive a contract acquisition request sent by a blockchain node, wherein the contract acquisition request is generated after determining that the contract type of a target smart contract to be called to execute a target transaction is a first type, and the transaction request of the target transaction carries a contract identifier of the target smart contract;

[0042] A processing unit, used to obtain a target smart contract from a contract repository according to a contract identifier of the target smart contract, wherein the contract file of the smart contract stored in the contract repository has passed the contract detection process;

[0043] The sending unit is used to return the target smart contract to the blockchain node, and the target smart contract is used to trigger the execution of the target transaction on the blockchain.

[0044] In a possible implementation, the contract repository is stored in a central audit device associated with the blockchain, and a contract code checking module is configured in the central audit device; the processing unit is also used to perform the following operations:

[0045] Receive a contract upload request sent by a contract upload object, where the contract upload request includes the contract file of the smart contract to be uploaded;

[0046] Authenticate the contract upload object;

[0047] If the authentication of the contract upload object is passed, the contract code check module is called to perform contract detection processing on the contract file of the uploaded smart contract;

[0048] If the contract detection process of the uploaded smart contract passes, storage management is performed on the uploaded smart contract.

[0049] In a possible implementation, the central audit device is further configured with: a contract code storage module and a billing management module, the contract code storage module maintains a contract warehouse; the processing unit performs storage management on the uploaded smart contract, and is used to perform the following operations:

[0050] Perform hash operation on the uploaded smart contract to obtain the contract hash;

[0051] The contract hash and the smart contract to be uploaded are associated and stored in the contract warehouse; and the contract identifier and the smart contract to be uploaded are associated and stored in the contract warehouse, where the contract identifier includes the contract name and contract version;

[0052] The billing management module is called to deduct fees for the storage management performed.

[0053] In a possible implementation, the processing unit is further configured to perform the following operations:

[0054] In response to a node registration request sent by a blockchain node to be registered, the node registration request includes node information of the blockchain node to be registered;

[0055] Determine the node type of the blockchain node to be registered based on the node information, and obtain a blacklist, where the blacklist stores at least one blockchain node that does not meet the registration conditions;

[0056] If the node type belongs to the preset node type and the blacklist does not contain the blockchain node to be registered, the identity registration process is performed on the blockchain node.

[0057] On the one hand, an embodiment of the present application provides a computer device, which includes a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the above-mentioned blockchain-based contract processing method.

[0058] On the one hand, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is read and executed by a processor of a computer device, the computer device executes the above-mentioned blockchain-based contract processing method.

[0059] On the one hand, the embodiments of the present application provide a computer program product or a 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, so that the computer device executes the above-mentioned blockchain-based contract processing method.

[0060] In an embodiment of the present application, a transaction request can be received, the transaction request is used to request the execution of a target transaction on the blockchain, and the transaction request carries the contract identifier of the target smart contract to be called to execute the target transaction; the contract type of the target smart contract is obtained, and the contract type of the smart contract supported by the blockchain includes at least the first type; the first type of smart contract is stored in the contract warehouse of the central audit device associated with the blockchain, and the contract file of the smart contract stored in the contract warehouse has passed the contract detection process of the central audit device; if the contract type of the target smart contract is the first type, the target smart contract is obtained from the contract warehouse of the central audit device according to the contract identifier of the target smart contract; the target smart contract is called to execute the target transaction. It can be seen from this that the present application can store the first type of smart contract in the central audit device associated with the blockchain, and the smart contract does not need to be stored in the blockchain, which can reduce the storage burden of the blockchain node; in addition, the smart contract stored in the contract warehouse of the central audit device has passed the contract detection process, which can improve the accuracy of the smart contract called on the chain. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present application. For ordinary technical objects in this field, other drawings can be obtained based on these drawings without paying creative labor.

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

[0063] Figure 1b This is a schematic diagram of the structure of a blockchain provided by an embodiment of the present application;

[0064] Figure 2 This is a schematic diagram of the architecture of a blockchain-based contract processing system provided in an embodiment of the present application;

[0065] Figure 3a It is a structural diagram of a central audit device provided in an embodiment of the present application;

[0066] Figure 3b This is a schematic diagram of the structure of a blockchain node provided in an embodiment of the present application;

[0067] Figure 4 It is a flowchart of a blockchain-based contract processing method provided in an embodiment of the present application;

[0068] Figure 5 This is a schematic diagram of a scenario for obtaining identity information provided by an embodiment of the present application;

[0069] Figure 6 It is a flowchart of another blockchain-based contract processing method provided in an embodiment of the present application;

[0070] Figure 7 It is an interactive flow chart of a blockchain-based contract processing method provided in an embodiment of the present application;

[0071] Figure 8a It is a schematic diagram of a blockchain node registration process provided by an embodiment of the present application;

[0072] Figure 8b It is a schematic diagram of a contract upload process provided in an embodiment of the present application;

[0073] Figure 8c It is a schematic diagram of a blockchain contract transaction execution process provided by an embodiment of the present application;

[0074] Fig. 9 It is a structural diagram of a blockchain-based contract processing device provided in an embodiment of the present application;

[0075] Fig.10 It is a structural diagram of another blockchain-based contract processing device provided in an embodiment of the present application;

[0076] Fig.11 It is a structural diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0077] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0078] This application provides a blockchain-based contract processing solution, which can store the smart contracts to be called on the blockchain in the contract warehouse of the central audit device associated with the blockchain, and the smart contracts stored in the contract warehouse are processed by contract detection. Therefore, this application can not only reduce the storage burden of blockchain nodes, but also improve the reliability and accuracy of smart contracts. Specifically, the process of the contract processing solution proposed in this application is roughly as follows:

[0079] 1) When a user requests to execute a target transaction (such as a transfer transaction, a game transaction, etc.) on the blockchain, a transaction request for the target transaction can be initiated to the blockchain. The transaction request carries the contract identifier of the target smart contract to be called to execute the target transaction;

[0080] 2) When a blockchain node receives a transaction request, it can obtain the contract type of the target smart contract. Among them, the contract type of smart contracts supported by the blockchain can include at least the first type (for example, the business contract type, the so-called business contract type refers to the business contract uploaded by the user after editing); the first type of smart contracts are stored in the contract warehouse of the central audit device associated with the blockchain, and the contract files of the smart contracts stored in the contract warehouse have passed the contract detection processing of the central audit device, and the contract detection processing includes, for example: any one or more of contract vulnerability detection, security detection, and legality detection;

[0081] 3) If it is determined that the contract type of the target smart contract is the first type, the target smart contract can be obtained from the contract warehouse of the central audit device according to the contract identifier of the target smart contract;

[0082] 4) Finally, the target smart contract can be called to execute the target transaction, such as executing a transfer transaction on the chain.

[0083] It can be seen from this that, on the one hand, the present application can store smart contracts in the contract warehouse of the central audit device associated with the blockchain, without the need to store the smart contracts in each blockchain node of the blockchain, thus reducing the contract storage burden of the blockchain nodes; on the other hand, the smart contracts stored in the contract warehouse of the central audit device have passed the contract detection process, which can ensure the accuracy of the smart contracts in the contract warehouse, thereby improving the reliability of the transaction execution process.

[0084] The following is a detailed introduction to the relevant technical terms involved in the blockchain-based contract processing solution provided by this application.

[0085] 1. Contract Types of Smart Contracts

[0086] A smart contract is a computer protocol designed to disseminate, verify or execute contracts in an information-based manner. Smart contracts allow for trusted transactions without a third party, and these transactions are traceable and irreversible. In this application, the contract types of smart contracts may include at least: the first type and the second type, where the first type of smart contract refers to a business contract edited by the user (such as a resource transfer contract, a game contract, etc.); the second type of smart contract refers to the native contract of the system on the blockchain (such as a system proxy contract, a node management contract, a network configuration contract, etc.).

[0087] Among them, ① the first type of smart contracts are stored in the contract warehouse of the central audit device, and each first type of smart contract stored in the central audit device needs to undergo contract detection processing by the central audit device, such as contract vulnerability detection, security detection, legality detection, etc.; ② The second type of smart contracts are stored in the blockchain.

[0088] 2. Contract Warehouse

[0089] The contract warehouse refers to the database used by the central audit device to store the first type of smart contracts. Among them, the central audit device can be considered as an institution with an authoritative nature, such as a CA institution. Specifically, the construction process of the contract warehouse is as follows: First, the user edits the contract file of the business contract according to business needs, and then sends the edited contract file of the business contract to the central audit device; then, the central audit device performs contract detection processing on the received contract file of the business contract, such as any one or more of contract vulnerability detection, security detection, and legality detection; finally, if it is determined that the current contract file passes the above-mentioned contract detection processing, the current business contract is added to the contract warehouse.

[0090] 3. Blockchain Technology

[0091] Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains relevant information, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. Specifically, this application will introduce the relevant terms such as blockchain system and blockchain structure in detail.

[0092] (1) Blockchain system:

[0093] See also Figure 1a , Figure 1a This is a schematic diagram of the structure of a blockchain system provided by an embodiment of the present application. Figure 1aAs shown, the blockchain system can be a data sharing system. The so-called data sharing system refers to a system for sharing data between node devices. The data sharing system 100 may include multiple node devices 101. The multiple node devices 101 may refer to various computer devices in the data sharing system. The computer device may be, for example, a terminal device or a server. Among them, the device types of different node devices 101 may be the same or different. For example, a certain node device 101 may be a terminal device, and another node device 101 may be a server.

[0094] Specifically, each node device 101 can receive input information when performing normal work, and maintain the shared data in the data sharing system based on the received input information. For example, when any node device 101 in the blockchain system receives input information (for example, receives a transaction request for a target transaction), the node device 101 can obtain the target smart contract from the contract warehouse of the central audit device associated with the blockchain according to the contract identifier of the target smart contract carried in the transaction request, and after calling the target smart contract to execute the target transaction, write the transaction execution result of the target transaction into the blockchain, so that each blockchain node on the blockchain can jointly maintain the transaction execution result of the target transaction.

[0095] (2) Blockchain Node:

[0096] ①Node function:

[0097] a. Application functions are used to be deployed in the blockchain to implement specific businesses according to actual business needs, and record data related to the implementation of business functions to form record data (such as transaction data carried in a transaction request, such as transaction data including the contract identifier of the target smart contract). The transaction request can be used to request the implementation of the business function of the target transaction on the blockchain. For example, business functions may include: resource transfer function, game business function, smart transportation function, etc. In one implementation, a digital signature (i.e., the digital signature of the request object) can be carried in the transaction request to indicate the source of the transaction data, and the transaction data can be sent to other nodes in the blockchain system, so that other nodes can add the transaction data to the temporary block when they successfully verify the source and integrity of the transaction data, thereby completing the on-chain processing of the transaction data.

[0098] b. Contract function. Any blockchain node in the blockchain system has the function of calling and executing the corresponding smart contract. The so-called smart contract (referred to as contract): smart contract has three major elements: commitment, agreement, and digital form. Therefore, it can expand the application scope of blockchain to all aspects of financial industry transactions, payments, settlements, and clearing. Smart contract means that when a pre-compiled condition is triggered, the smart contract will immediately execute the corresponding contract terms. Its working principle is similar to the if-then statement of a computer program. Among them, a smart contract virtual machine (a virtual machine that can execute smart contracts) runs in the blockchain node. The smart contract virtual machine can understand and execute these codes to realize the function of the smart contract. In this application, the second type (system type) of smart contract can be deployed in the blockchain node based on the contract function to realize the system contract function possessed by the blockchain.

[0099] ②Node identification:

[0100] Each node in the blockchain system has a corresponding node identifier, and each node in the blockchain system can store the node identifiers of other nodes in the blockchain system, so that the generated blocks can be broadcast to other nodes in the blockchain system based on the node identifiers of other nodes. Each node can maintain a node identifier list as shown in the following table, and store the node name and node identifier in the node identifier list.

[0101] The node identifier may be an IP (Internet Protocol, a protocol for interconnecting networks) address or any other information that can be used to identify the node. Table 1 only uses the IP address as an example for description.

[0102] Table 1. Node ID list

[0103] Node Name Node ID Node 1 000.000.000.000 Node 2 111.111.111.111 … … Node N xxx.xxx.xxx.xxx

[0104] In the embodiment of the present application, the transaction request carries transaction data, for example, the transaction data includes: the contract identifier of the target smart contract, the account address of the receiving digital resource, the account address of the transferring digital resource, etc. Each blockchain node can perform blockchain consensus on the transaction data carried in the transaction request, and the blockchain consensus process involves data interaction between blockchain nodes. During the data interaction process, any blockchain node can carry its own node identifier, so that other nodes can perform node verification processing based on the corresponding node identifier before performing consensus processing, thereby improving the security of the blockchain consensus process.

[0105] (3) Block structure:

[0106] See also Figure 1b , Figure 1bThis is a schematic diagram of the structure of a blockchain provided by an embodiment of the present application. Figure 1b As shown in the figure, the blockchain consists of multiple blocks, and each blockchain contains a genesis block. As the name implies, the so-called genesis block is the first block, the initial block. The genesis block includes a block header and a block body. The block header stores the input information feature value, version number, timestamp and difficulty value, and the block body stores the input information; the next block of the genesis block uses the genesis block as the parent block, and the next block also includes a block header and a block body. The block header stores the input information feature value of the current block, the block header feature value, version number, timestamp and difficulty value of the parent block, and so on, so that the transaction data stored in each block in the blockchain is associated with the transaction data stored in the parent block, ensuring the security of the transaction data in the block.

[0107] In the present application embodiment, according to Figure 1b The blockchain composed of the block structure shown can ensure the security of relevant transaction data involved in the execution of the target transaction, thereby improving the reliability and security of executing the target transaction on the chain.

[0108] 4. Cloud Technology:

[0109] In the blockchain-based contract processing scheme proposed in this application, the blockchain involves a large number of data computing services and data storage services, so a large amount of computer operating costs are required. Then, this application can perform corresponding contract processing operations based on cloud storage technology in cloud technology, specifically including: data storage can be performed based on the data storage service to store the transaction execution results obtained after executing the target transaction; and, the target transaction can be executed on the blockchain based on the data computing service. Among them, the so-called cloud technology (Cloud technology) is a general term for network technology, information technology, integration technology, management platform technology, application technology, etc. based on the cloud computing business model application, which can form a resource pool, which is used on demand and is flexible and convenient. Among them, cloud technology can include cloud storage technology. The so-called cloud storage (cloud storage) is a new concept extended and developed from the concept of cloud computing. A distributed cloud storage system (hereinafter referred to as a storage system) refers to a storage system that uses cluster applications, grid technology, and distributed storage file systems to bring together a large number of different types of storage devices (storage devices are also called storage nodes) in the network through application software or application interfaces to work together and provide data storage and business access functions to the outside world.

[0110] It should be noted that the relevant data involved in the contract processing process in this application, for example: the contract identifier of the target smart contract, the contract type, and the signature data of the requesting object, etc. When the above embodiments of this application are applied to specific products or technologies, user permission or consent must be obtained, and the relevant data collection, use and processing process must comply with the relevant laws, regulations and standards of the region, comply with the principles of legality, legitimacy and necessity, and do not involve obtaining data types prohibited or restricted by laws and regulations. In some optional embodiments, the relevant data involved in the embodiments of this application are obtained after the object is authorized separately. In addition, when obtaining the separate authorization of the object, the purpose of the relevant data involved is indicated to the object.

[0111] Combine the following Figure 2 , Figure 3a ,as well as Figure 3b The architecture diagram of the contract processing system provided in the embodiment of the present application is introduced in detail.

[0112] 1. Combination Figure 2 The overall architecture of the contract processing system for this application is introduced.

[0113] See also Figure 2 , Figure 2 Schematic diagram of the architecture of a blockchain-based contract processing system provided in an embodiment of the present application. Figure 2 As shown, the architecture diagram of the contract processing system may include at least: a central audit device 201, at least one blockchain node 202, and a client 203. Among them, each blockchain node 202 constitutes a blockchain network. It should be noted that the number of nodes in the blockchain network is only used for example, and the number of nodes in this application is not specifically limited. Among them, any blockchain node 202 in the blockchain network can be directly or indirectly connected to the central audit device 201 and the client 203 respectively through wired or wireless communication.

[0114] Among them, any computer device in the contract processing system (central audit device 201, blockchain node 202, or client 203) can be a mobile phone, tablet computer, laptop computer, PDA, mobile internet device (MID, mobile internet device), vehicle, vehicle-mounted device, roadside device, aircraft, wearable device, smart device such as smart watch, smart bracelet, pedometer, etc., virtual reality device.... and so on. Any computer device in the contract processing system (central audit device 201, blockchain node 202, or client 203) can be a server. Specifically, the server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides 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, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0115] It is understandable that the types of various computer devices in the contract processing system can be the same or different. For example, the central audit device 201 can be a mobile phone, and the blockchain node 202 can also be a mobile phone; for another example, the central audit device 201 can be a mobile phone, and the blockchain node 202 can be a server. This application does not limit the number and type of various computer devices in the contract processing system.

[0116] Combine the following Figure 2 The data interaction process between the central audit device 201 and the blockchain node 202 in the contract processing system is described in detail:

[0117] ① The user initiates a transaction request in the client 203, which is used to request the execution of a target transaction on the blockchain. The transaction request carries the contract identifier of the target smart contract to be called to execute the target transaction, such as the contract name, contract version and other information.

[0118] ② The client 203 sends the transaction request to the blockchain node 202. The blockchain node 202 may be any node in the blockchain network, or a designated node (such as a master node) in the blockchain network, which is not specifically limited in this application.

[0119] ③ The blockchain node 202 obtains the contract type of the target smart contract. The contract types of smart contracts supported by the blockchain include at least the first type; the first type of smart contracts are stored in the contract warehouse of the central audit device associated with the blockchain, and the contract files of the smart contracts stored in the contract warehouse have passed the contract detection processing of the central audit device.

[0120] ④ If the contract type of the target smart contract is the first type, the blockchain node 202 can initiate a contract acquisition request to the central audit device 201 to obtain the target smart contract from the contract repository of the central audit device 201.

[0121] ⑤ The central audit device 201 obtains the target smart contract from the contract warehouse according to the contract identifier of the target smart contract, and sends the target smart contract to the blockchain node 202.

[0122] ⑥ Blockchain node 202 can call the target smart contract to execute the target transaction.

[0123] 2. Combine the following Figure 3a and Figure 3b The specific structures of the central audit device and blockchain nodes are explained respectively.

[0124] (1) Please see Figure 3a , Figure 3a : is a structural diagram of a central audit device provided in an embodiment of the present application. The central audit device is an authoritative institution or cluster, which maintains a contract warehouse and is responsible for auditing, storing and billing each smart contract in the contract warehouse. Figure 3a As shown, the structure of the central audit device may include at least the following modules:

[0125] a) Network module, which is the module through which the central audit device interacts with the outside world (such as blockchain nodes);

[0126] b) Authentication module, a module where the central audit device verifies the authority of the request;

[0127] i. Signature verification submodule, a module that performs signature verification on the request object of the transaction request;

[0128] ii. The permission verification submodule verifies the permission of the request object, that is, verifies whether the request object has the permission to perform the requested operation;

[0129] c) Billing management module, which is a module for collecting statistics on the audit fees and storage fees of smart contracts;

[0130] d) Contract detection module, which performs contract detection on the contract file / code of the smart contract. For example, contract detection includes: vulnerability detection, legality detection, and security detection;

[0131] e) Contract code cache module, used to cache the contract codes of commonly used smart contracts;

[0132] f) Contract code storage module, which stores the contract codes of all smart contracts in the contract warehouse.

[0133] (2) Please see Figure 3b , Figure 3b Schematic diagram of the structure of a blockchain node provided by an embodiment of the present application. Figure 3b As shown, the structure of the blockchain node may include at least the following modules:

[0134] a) Network module: the module through which the blockchain node interacts with the outside world (such as the client);

[0135] b) Authentication module: a module used by blockchain nodes to verify the authority of transaction requests;

[0136] i. Signature verification submodule, a module that performs signature verification on the request object of the transaction request;

[0137] ii. The permission verification submodule verifies the permission of the request object, that is, verifies whether the request object has the permission to perform the requested operation;

[0138] c) Transaction pool module, a module that caches transactions when packaging blocks;

[0139] d) Block scheduling module, which is responsible for obtaining batch transactions from the transaction pool module and generating new blocks;

[0140] e) Virtual machine module, which is responsible for executing contract transactions;

[0141] i. A contract identification submodule is used to identify the contract type of the smart contract. The contract type may include: system type and business type. The smart contract of the system type is a system contract, and the smart contract of the business type is a business contract;

[0142] ii. Contract download submodule, used to obtain and download smart contracts from the central audit device;

[0143] iii. The contract authentication sub-module is used to authenticate the smart contract returned by the central audit device, for example, to authenticate the integrity and legality of the smart contract;

[0144] iv. Contract cache submodule, used to store contract files of commonly used smart contracts for easy acquisition and quick startup;

[0145] v. Contract process / coroutine, the running state of actually executing contract transactions;

[0146] f) Consensus module, a module that performs blockchain consensus processing on transactions;

[0147] g) Storage module, a module for storing transaction-related data on the blockchain;

[0148] i. Blockchain ledger submodule, a module for storing blockchain ledger data;

[0149] ii. Status data submodule, a module used to store the latest status data of the blockchain.

[0150] Based on this, the overall architecture of the contract processing system described above mainly includes: the network module, authentication module, transaction pool module, block scheduling module, virtual machine module, consensus module and storage module of the blockchain node; and the network module, authentication module, billing management module, contract detection module, contract code cache module and contract code storage module of the central audit device. The above system architecture is the operating basis of the contract processing solution of this application, and the above system architecture can ensure the efficient and stable operation of the system.

[0151] The contract processing system provided by the present application can receive a transaction request, which is used to request the execution of a target transaction on a blockchain, and the transaction request carries the contract identifier of the target smart contract to be called to execute the target transaction; obtain the contract type of the target smart contract, and the contract type of the smart contract supported by the blockchain includes at least the first type; the first type of smart contract is stored in the contract warehouse of the central audit device associated with the blockchain, and the contract file of the smart contract stored in the contract warehouse has passed the contract detection process of the central audit device; if the contract type of the target smart contract is the first type, then according to the contract identifier of the target smart contract, the target smart contract is obtained from the contract warehouse of the central audit device; call the target smart contract to execute the target transaction. It can be seen from this that the present application can store the first type of smart contract in the central audit device associated with the blockchain, and the smart contract does not need to be stored in the blockchain, which can reduce the storage burden of the blockchain node; in addition, the smart contract stored in the contract warehouse of the central audit device has passed the contract detection process, which can improve the accuracy of the smart contract called on the chain.

[0152] It can be understood that the contract processing system described in the embodiment of the present application is to more clearly illustrate the technical solution of the embodiment of the present application, and does not constitute a limitation on the technical solution provided in the embodiment of the present application. It is known to those skilled in the art that with the evolution of the system architecture and the emergence of new business scenarios, the technical solution provided in the embodiment of the present application is also applicable to similar technical problems.

[0153] The following describes a specific embodiment of the blockchain-based contract processing solution in conjunction with the accompanying drawings.

[0154] See also Figure 4 , Figure 4 is a flowchart of a blockchain-based contract processing method provided by an embodiment of the present application. The contract processing method can be Figure 2The blockchain node in the blockchain-based contract processing system shown is executed. The blockchain-based contract processing method mainly includes but is not limited to the following steps S401 to S404:

[0155] S401: Receive a transaction request, where the transaction request is used to request execution of a target transaction on the blockchain. The transaction request carries the contract identifier of a target smart contract to be called to execute the target transaction.

[0156] The target transaction may be any business type of transaction, for example, the target transaction may be a game type of transaction, a resource transfer type of transaction, a smart transaction type of transaction, etc. In addition, the target transaction may refer to any transaction in the transaction pool module of the blockchain node, or a batch transaction consisting of multiple transactions in the transaction pool module, which is not specifically limited in this application.

[0157] In a possible implementation, an authentication module is configured in the blockchain node, and the transaction request is generated by the request object after signing the target transaction. Then, after receiving the transaction request, the blockchain node can also perform the following operations: parse the transaction request to obtain the signature data of the request object; and call the authentication module to authenticate the request object according to the signature data. The authentication processing here includes: any one or more of signature verification processing and authority verification processing. For example, the signature data of the request object is generated after the target transaction is signed by the private key of the request object, then the authentication module can obtain the public key of the request object, and perform signature verification processing on the signature data based on the public key of the request object; further, if the signature verification of the request object is passed, the request object can be further verified for authority, that is, to verify whether the current request object has the authority to initiate the target transaction to the blockchain. If both the signature verification and the authority verification of the request object are passed, the blockchain node can respond to the transaction request and trigger the execution of the subsequent step S402; otherwise, the blockchain node can delete the transaction request. In this implementation, the request object that initiates the transaction request can be authenticated, thereby improving the security of transactions on the chain.

[0158] Optionally, during the authentication process of the request object, the blockchain node can also request to obtain the identity information of the request object, and perform identity authentication on the request object based on the identity information of the request object. Figure 5 , Figure 5 Schematic diagram of a scenario for obtaining identity information provided by an embodiment of the present application. Figure 5As shown, before obtaining the identity information of the request object, the blockchain node needs to send an authorization request to the request object. The authorization request is used to request the authorization of the request object. The identity information of the request object can be obtained only after the request object agrees to the authorization. For example, after the terminal device used by the request object obtains the authorization request sent by the blockchain node, the interface S500 can be displayed in the terminal device. The interface S500 displays a prompt message, which is used to prompt the request object whether to authorize the identity information, and is provided with a confirmation control 501 and a rejection control 502. If the request object clicks the confirmation control 501, it means that the request object agrees to the authorization. If the request object clicks the rejection control 502, it means that the request object refuses the authorization. In this way, when obtaining the identity information of the request object, the authorization of the request object can be requested, thereby improving the security of the identity information of the request object and avoiding data leakage.

[0159] S402: Obtain the contract type of the target smart contract. The contract types of smart contracts supported by the blockchain include at least the first type. The first type of smart contracts are stored in the contract repository of the central audit device associated with the blockchain. The contract files of the smart contracts stored in the contract repository have passed the contract detection process of the central audit device.

[0160] In one possible implementation, the association of a blockchain with a central audit device may include: a communication connection relationship between any blockchain node in the blockchain and the central audit device, or a communication connection relationship between a blockchain node in the blockchain that currently receives a transaction request and the central audit device.

[0161] In a possible implementation, a virtual machine module is also configured in the blockchain node, and the virtual machine module includes: a contract identification submodule. The blockchain node obtains the contract type of the target smart contract, which may include: calling the contract identification submodule to identify the contract type of the target smart contract to determine the contract type of the target smart contract. Among them, the contract type of the smart contract may include at least: a first type and a second type, the first type may be a business type (such as a game type, a resource transfer type), and the second type may be a system type; the first type of smart contract is a business contract, and the second type of smart contract is a native system contract deployed by the blockchain system.

[0162] Specifically, if the contract type of the target smart contract is the first type, the subsequent step S403 is triggered; if the contract type of the target smart contract is the second type, the second type of target smart contract is directly called from the blockchain node to execute the target transaction. It can be seen that in this application, the first type of smart contract is stored in the contract warehouse of the central audit device associated with the blockchain, and there is no need to store the smart contract on the blockchain, which can reduce the storage burden of the blockchain node.

[0163] S403: If the contract type of the target smart contract is the first type, the target smart contract is obtained from the contract repository of the central audit device according to the contract identifier of the target smart contract.

[0164] In a possible implementation, the virtual machine module of the blockchain node is further configured with: a contract cache submodule and a contract download submodule. If the contract type of the target smart contract is the first type, it is possible to check whether the target smart contract exists in the contract cache submodule. If it exists, the target smart contract is directly obtained from the contract cache submodule; if it does not exist, the contract download submodule is called to access the central audit device to obtain the target smart contract to be called from the contract warehouse of the central audit device. Specifically, the blockchain node can generate a contract acquisition request, which carries the contract identifier of the target smart contract, and then send the contract acquisition request to the central audit device to obtain the target smart contract from the contract warehouse of the central audit device based on the contract download submodule.

[0165] In a possible implementation, the virtual machine module of the blockchain node also includes a contract authentication submodule. The blockchain node can also perform the following operations: ① Receive the target smart contract, the contract hash of the target smart contract, and the signature data of the central audit device returned by the central audit device. ② Call the contract authentication submodule to verify the contract hash of the target smart contract and the signature data of the central audit device respectively. In specific implementation, for example, the target smart contract can be hashed to obtain the hash value of the target smart contract, wherein the hash algorithm used in the above hash operation may include but is not limited to: MD5 algorithm, SHA-1 algorithm, SHA-256 algorithm, SHA-512 algorithm, etc., and the embodiment of the present application does not specifically limit this; then the calculated hash value is compared with the contract hash returned by the central audit device. If they are consistent, the contract hash of the target smart contract is verified; for example, the public key of the central audit device can be obtained, and then the signature data returned by the central audit device is verified based on the public key of the central audit device. If the verification is successful, the signature data of the central audit device is verified. ③ If it is determined that both the contract hash and signature data are verified, the target smart contract is stored in the contract cache submodule to trigger the call of the target smart contract from the contract cache submodule to execute the target transaction.

[0166] The following is an explanation of the identity registration process of blockchain nodes and central audit equipment.

[0167] In a possible implementation, the contract type of the smart contract supported by the blockchain also includes a second type, and the second type of smart contract is stored on the blockchain, and the virtual machine module of the blockchain node also includes a system contract submodule. According to the contract identifier of the target smart contract, before obtaining the target smart contract from the contract warehouse of the central audit device, it is also used to execute the following process: receiving a node registration request initiated by an administrator object for the central audit device, the node registration request is used to request the blockchain node to register its identity with the central audit device, and the node registration request carries the target registration address of the central audit device to be accessed; if the contract type of the smart contract to be called by the node registration request is the second type, then calling the system contract submodule to access the central audit device indicated by the target registration address for identity registration; wherein the blockchain node that has completed the identity registration is associated with the central audit device.

[0168] In specific implementation, the node registration request is generated after the signature processing of the administrator object; after receiving the node registration request initiated by the administrator object for the central audit device, it is also used to execute the following process: calling the authentication module to authenticate the administrator object, and the authentication process includes: any one or more of the signature verification process and the authority verification process; if the authentication of the administrator object is passed, the contract identification submodule is called to identify the contract type of the smart contract to be called by the node registration request. Specifically, when the contract type of the smart contract to be called by the node registration request is the second type of smart contract, the second type of smart contract (i.e., the system contract) can be called to parse the node registration request to execute the node registration transaction, and then the system contract can send the node registration request to the central audit device to carry out the identity registration process of the blockchain node to the central audit device.

[0169] It should be understood that the blockchain node that has completed identity registration in the central audit device is used to indicate that the blockchain node is associated with the central audit device. Then, the blockchain node can access the central audit device to obtain the target smart contract to be called from the contract warehouse of the central audit device. In this implementation, the blockchain node after identity registration is allowed to access the contract warehouse of the central audit device, avoiding the risk of contract data being leaked, and improving the security of smart contracts in the contract warehouse.

[0170] S404: Call the target smart contract to execute the target transaction.

[0171] In a possible implementation, if the number of target transactions is one, a contract process can be started in the virtual machine module of the blockchain node, and the target smart contract can be called to execute the target transaction in the contract process. For example, if the target transaction is a transaction in which a requesting object transfers resources to a requesting object (i.e., a resource transfer transaction), then the target smart contract can be a resource transfer contract, and the current resource transfer transaction can be executed in the contract process by calling the resource transfer contract.

[0172] In another possible implementation, if the target transaction includes multiple subtasks to be executed. Then the contract coroutine corresponding to the target smart contract can be run in the virtual machine module; and each subtask can be switched to be executed in the contract coroutine corresponding to the target smart contract to obtain the execution results of each subtask. For example, the target transaction can be a transaction in which a request object transfers resources to multiple second objects respectively, that is, the target transaction includes multiple resource transfer subtasks, one subtask corresponds to one second object to be transferred, and the target smart contract can be a resource transfer contract, then the subtasks of resource transfer to each second object can be executed in sequence in the contract coroutine by calling the resource transfer contract.

[0173] In an embodiment of the present application, a transaction request can be received, the transaction request is used to request the execution of a target transaction on the blockchain, and the transaction request carries the contract identifier of the target smart contract to be called to execute the target transaction; the contract type of the target smart contract is obtained, and the contract type of the smart contract supported by the blockchain includes at least the first type; the first type of smart contract is stored in the contract warehouse of the central audit device associated with the blockchain, and the contract file of the smart contract stored in the contract warehouse has passed the contract detection process of the central audit device; if the contract type of the target smart contract is the first type, the target smart contract is obtained from the contract warehouse of the central audit device according to the contract identifier of the target smart contract; the target smart contract is called to execute the target transaction. It can be seen from this that the present application can store the first type of smart contract in the central audit device associated with the blockchain, and the smart contract does not need to be stored in the blockchain, which can reduce the storage burden of the blockchain node; in addition, the smart contract stored in the contract warehouse of the central audit device has passed the contract detection process, which can improve the accuracy of the smart contract called on the chain.

[0174] See also Figure 6 , Figure 6 is a flowchart of another blockchain-based contract processing method provided in an embodiment of the present application. The contract processing method can be Figure 2 The central audit device in the blockchain-based contract processing system shown is executed. The blockchain-based contract processing method mainly includes but is not limited to the following steps S601 to S603:

[0175] S601: Receive a contract acquisition request sent by a blockchain node. The contract acquisition request is generated after determining that the contract type of the target smart contract to be called to execute the target transaction is the first type. The transaction request of the target transaction carries the contract identifier of the target smart contract.

[0176] Among them, the blockchain node that sends the contract acquisition request is a blockchain node that has completed identity registration. In a possible implementation, in response to the node registration request sent by the blockchain node to be registered, the node registration request includes the node information of the blockchain node to be registered (such as node identification, node name, etc.); based on the node information, the node type of the blockchain node to be registered is determined, and a blacklist list is obtained, in which at least one blockchain node that does not meet the registration conditions is stored, wherein the blacklist list can be pre-set by the central audit device, for example, some nodes that do not meet the credit indicators are stored in the blacklist; or, nodes with security risks are stored in the blacklist, and so on; if the node type belongs to a preset node type (such as a master node or an accounting node, etc.), and the blacklist list does not contain the blockchain node to be registered, the identity registration process is performed on the blockchain node. Specifically, the node information of the blockchain node that has completed identity registration can be stored in the whitelist, that is, the blockchain nodes stored in the whitelist are allowed to interact with the central audit device.

[0177] In a possible implementation, after receiving the contract acquisition request sent by the blockchain node, the central audit device can authenticate the blockchain node. If it is determined that the authentication process of the blockchain node is passed, the execution step S602 can be triggered; otherwise, the central audit device can delete the contract acquisition request. Among them, the above-mentioned authentication process mainly includes: any one or more of signature verification, authority verification, security verification, and legality verification. For example, the contract acquisition request is generated after being signed based on the private key of the blockchain node, then the central audit device can obtain the public key of the blockchain node, and perform signature verification on the contract acquisition request based on the public key of the blockchain node. If the signature verification is successful, it means that the signature verification is passed; for another example, the central audit device can check whether the current blockchain node has completed the identity registration process in the central audit device. If the identity registration has been completed, the authority verification of the blockchain node is passed, and so on. In this way, the blockchain node requesting to obtain the target smart contract can be authenticated, thereby improving the reliability and security of the data interaction process.

[0178] S602: Obtain the target smart contract from the contract repository according to the contract identifier of the target smart contract.

[0179] In a possible implementation, the contract files of each smart contract stored in the contract warehouse have been processed by the central audit device. The so-called contract detection includes: vulnerability detection, legality detection, and security detection. Therefore, the target smart contract obtained by the blockchain node from the contract warehouse has been security-tested, which can make the target smart contract obtained by the blockchain node safe and reliable.

[0180] The following is a detailed description of the process of generating a contract warehouse.

[0181] In one possible implementation, a contract code checking module is configured in the central audit device; the central audit device is also used to execute the following process: receiving a contract upload request sent by a contract upload object, the contract upload request including the contract file of the smart contract to be uploaded; performing authentication processing on the contract upload object; if the authentication of the contract upload object is passed, calling the contract code checking module to perform contract detection processing on the contract file of the smart contract to be uploaded; if the contract detection processing of the smart contract to be uploaded is passed, performing storage management on the smart contract to be uploaded.

[0182] In specific implementation, the central audit device is also configured with: a contract code storage module and a billing management module. The contract code storage module maintains a contract warehouse. The central audit device performs storage management on the smart contract to be uploaded, including the following processes: performing a hash operation on the smart contract to be uploaded to obtain a contract hash; associating the contract hash with the smart contract to be uploaded and storing it in the contract warehouse; and associating the contract identifier with the smart contract to be uploaded and storing it in the contract warehouse. The contract identifier includes the contract name and contract version; calling the billing management module to deduct fees for the storage management performed.

[0183] For example, the contract warehouse of the central audit device stores at least: at least one first type of smart contract, and the contract identifier of each smart contract, where the contract identifier may include: contract name and contract version; optionally, the contract warehouse also stores the contract hash of each smart contract. For example, the storage structure of the contract warehouse is shown in Table 2 below:

[0184] Table 2. Contract warehouse

[0185] Smart Contracts Contract Hash Contract Name Contract Version Smart contract1 ji12v358x6dfg Contract 1 1.0 Smart contract2 wjsuxingniix1 Contract 2 2.0 Smart contract3 tfhytbcbok3vb Contract 3 3.0 ... ... ... ...

[0186] As shown in Table 2 above, the storage structure of the contract warehouse, for example, if the contract identifier of the target smart contract is: Contract 1 + Version 1.0, then the target smart contract determined from the contract warehouse is Smart contract 1; if the contract identifier of the target smart contract is: Contract 2 + Version 2.0, then the target smart contract determined from the contract warehouse is Smart contract 2.

[0187] S603: Return the target smart contract to the blockchain node, and the target smart contract is used to trigger the execution of the target transaction on the blockchain.

[0188] In a possible implementation, the central audit device can sign the target smart contract and the contract hash of the target smart contract and other data to obtain the signature data of the central audit device. Then, the central audit device can send the target smart contract, the contract hash of the target smart contract, and the signature data of the central audit device to the blockchain node; or, the central audit device can also encrypt the above data (i.e., the target smart contract, the contract hash of the target smart contract, and the signature data of the central audit device) and send the encrypted data to the blockchain node. In this way, the security of the data interaction process can be improved, and the data of the target smart contract can be guaranteed to be safe and reliable.

[0189] It should be noted that the detailed process of executing the target transaction on the blockchain based on the target smart contract can refer to the specific steps executed by the blockchain node in step S404 in the above embodiment, and the embodiments of the present application will not be repeated here.

[0190] In the embodiment of the present application, a contract warehouse is maintained in the central audit device, and a plurality of first-type smart contracts are stored in the contract warehouse. The contract files of these smart contracts are processed by the contract detection of the central audit device; when the blockchain node requests to obtain a smart contract, the matching target smart contract can be obtained from the contract warehouse and sent to the blockchain node. It can be seen that when the blockchain node executes the target transaction on the chain, it can obtain the target smart contract to be called from the contract warehouse. The blockchain node does not need to store each smart contract by itself, which can reduce the storage pressure of the blockchain node and thus improve the performance of the blockchain node.

[0191] See also Figure 7 , Figure 7 This is an interactive flow chart of a blockchain-based contract processing method provided in an embodiment of the present application. Figure 7 As shown, the interactive process of the contract processing method can be jointly executed by: the client, the blockchain node, and the central audit device. Specifically, the interactive process of the contract processing method specifically includes: blockchain node registration process, contract upload and installation process, and blockchain contract transaction execution process; wherein the above process mainly includes the following steps S701-S714:

[0192] S701: The administrator object initiates a node registration request on the client.

[0193] Specifically, the node registration request may include the identity information of the administrator object and the node information of the blockchain node to be registered. For example, the node information may include any one or more of: node identification, node type, and node name.

[0194] S702: The client sends a node registration request to the blockchain node.

[0195] S703: The blockchain node performs authentication processing on the administrator object.

[0196] Specifically, the blockchain node can call the authentication module to perform authentication processing on the administrator object. The authentication processing here can include: any one or more of signature verification processing and permission verification processing.

[0197] S704: If the contract type of the smart contract is the second type, the blockchain node sends a node registration request to the central audit device.

[0198] S705: The central audit device performs node registration processing on the blockchain node.

[0199] Specifically, the central audit device can perform authentication processing on the blockchain node. When the authentication processing of the blockchain node is passed, the blockchain node is registered, for example, the node information of the blockchain node is stored in a whitelist. The authentication processing here may include any one or more of signature verification processing and permission verification processing. It should be understood that if the central audit device completes the node registration of the blockchain node, the central audit device is associated with the blockchain node, that is, data interaction between the two is allowed, such as the interaction of smart contracts between the central audit device and the blockchain node.

[0200] S706: The client sends a contract upload request to the central audit device.

[0201] Specifically, the contract upload object can edit the business contract (i.e., the first type of smart contract) according to business needs, and use the edited first type of smart contract as the smart contract to be uploaded, so as to generate a contract upload request in the client and send it to the central audit device.

[0202] S707: The central audit device performs contract detection processing on the uploaded smart contract.

[0203] Specifically, the contract detection process includes: vulnerability detection, legality detection, and security detection. Optionally, before the central audit device performs contract detection on the uploaded smart contract, it can also perform authentication processing (such as signature verification processing and permission verification processing) on ​​the contract upload object. If the authentication of the contract upload object is passed, it triggers the execution of the contract detection process for the uploaded smart contract.

[0204] S708: The central audit device stores the smart contract to be uploaded in the contract warehouse.

[0205] Specifically, first, the central audit device can calculate the contract hash of the smart contract to be uploaded, and store the contract hash in association with the smart contract. In addition, the central audit device can also use the contract name and contract version of the smart contract to be uploaded as the contract identifier of the smart contract, and store the contract name + contract version (i.e., contract identifier) ​​in association with the smart contract.

[0206] S709: The blockchain node receives the transaction request sent by the client.

[0207] Among them, the transaction request is used to request the execution of the target transaction on the blockchain, and the transaction request carries the contract identifier of the target smart contract that needs to be called to execute the target transaction.

[0208] S710: The blockchain node obtains the contract type of the target smart contract.

[0209] S711: If the contract type of the target smart contract is the first type, the blockchain node sends a contract acquisition request to the central audit device.

[0210] S712: The central audit device obtains the target smart contract from the contract repository according to the contract identifier of the target smart contract.

[0211] S713: The central audit device returns the target smart contract to the blockchain node.

[0212] S714: The blockchain node calls the target smart contract to execute the target transaction.

[0213] It should be noted that the detailed process of the relevant steps in the embodiments of the present application can be specifically referred to above Figure 4 Examples and Figure 6 The relevant step descriptions in the embodiments are not repeated in this application.

[0214] In summary, the blockchain-based contract processing solution proposed in this application involves the full life cycle process of the contract warehouse sharing solution based on the central audit device. This process mainly includes the following three processes: blockchain node registration process (the process of blockchain nodes registering their identities to the central audit device), contract upload and installation process (the process of users uploading and installing smart contracts to the central audit device), and blockchain contract transaction execution process (the process of users sending transaction requests to the blockchain to execute contract transactions). The following is a detailed description of the above three processes in conjunction with the corresponding figures:

[0215] (1) Blockchain node registration process

[0216] See also Figure 8a , Figure 8a Schematic diagram of a blockchain node registration process provided by an embodiment of the present application. Figure 8a As shown in the figure, the blockchain node registration process mainly includes the following steps:

[0217] S1. The process starts.

[0218] S2. The administrator object initiates a node registration request for the central audit device to the blockchain.

[0219] S3. The network module of the blockchain node receives the node registration request.

[0220] S4. The authentication module of the blockchain node verifies the signature of the administrator object.

[0221] S5. Is the signature verification passed? If passed, execute S7; otherwise, execute S6.

[0222] S6. Return the result of signature verification failure and jump to S29.

[0223] S7. The authentication module of the blockchain node verifies the authority of the administrator object.

[0224] S8. Does the administrator object have the authority to register the node of the central audit device? If so, execute S10; otherwise, execute S9.

[0225] S9. Return the result that the administrator object does not have the permission, and jump to S29.

[0226] S10. The transaction pool module receives the node registration request.

[0227] S11. The block scheduling module schedules the transaction requested by the above node registration.

[0228] S12. The virtual machine module recognizes that the smart contract to be called by the transaction is a system contract.

[0229] S13. The system contract parsing node registers a request to execute the above transaction.

[0230] S14. Can the system contract access the central audit device through the node registration request? If so, execute S16; otherwise, execute and go to S15.

[0231] S15. The system contract returns an error that the target registration address cannot be accessed and jumps to S29.

[0232] S16. The system contract sends a node registration request to the central audit device.

[0233] S17. The network module of the central audit device receives the node registration request.

[0234] S18. The authentication module of the central audit device performs signature verification on the blockchain node.

[0235] S19: Is the signature verification passed? If yes, execute S21; otherwise, execute S20.

[0236] S20. Return the result of the central audit device signature verification failure, and execute S25.

[0237] S21. Does the blockchain node have the authority to register? If yes, execute S23; otherwise, execute S22.

[0238] S22. Return the result that the central audit device authority verification failed, and execute S25.

[0239] S23. The billing management module adds the billing record of the blockchain node.

[0240] S24. Return the result of adding the correct result.

[0241] S25. The blockchain node calls the system contract to receive the request and packages it into a block.

[0242] S26. Is the block consensus passed? If yes, execute S28; otherwise, execute S27.

[0243] S27, the blockchain discards the block and jumps to S29.

[0244] S28. The blockchain appends the block to the ledger data.

[0245] S29. The process ends.

[0246] In this process, when the blockchain node registers its identity with the central audit device, the blockchain node needs to perform signature verification and permission verification on the administrator object that initiated the node registration. Only when the authentication of the administrator object is passed can the central audit device be accessed and the corresponding node registration process be performed. It can be seen that multiple verification processes need to be performed during the identity registration of the node, which can improve the reliability and security of the node registration process; in addition, only blockchain nodes that have completed node registration can be allowed to access the central audit device, thereby improving the data security of the contract processing process of this application.

[0247] (2) Contract upload and installation process

[0248] See also Figure 8b , Figure 8b Schematic diagram of a contract upload process provided by an embodiment of the present application. Figure 8bAs shown in the figure, the contract upload process mainly includes the following steps:

[0249] S1. The process starts.

[0250] S2. The contract upload object sends a contract upload request for contract upload and installation to the central audit device.

[0251] S3. The network module of the central audit device receives the contract upload request.

[0252] S4. The authentication module of the central audit device performs signature verification on the contract uploaded object.

[0253] S5. Is the signature verification passed? If yes, execute S7; otherwise, execute S6.

[0254] S6. Return the result of the central audit device signature verification failure and jump to S19.

[0255] S7. Does the contract upload object have the authority to upload the contract? If yes, execute S9; otherwise, execute S8.

[0256] S8. Return the result of failure of central audit device authority verification and jump to S19.

[0257] S9. The billing management module of the central audit equipment performs fee deduction processing for contract vulnerability detection.

[0258] S10. The contract detection module of the central auditing device performs contract detection processing on the smart contract.

[0259] S11. Is the contract detection process passed? If yes, execute S13; otherwise, execute S12.

[0260] S12: Return the error indicating that the contract detection failed and jump to S19.

[0261] S13. The central audit device calculates the contract hash of the smart contract.

[0262] S14. The central audit device stores the mapping association between the contract hash and the contract code in the contract code storage module.

[0263] S15. The central audit device stores the mapping association between the contract name, the contract version and the contract code in the contract code storage module.

[0264] S16. The central audit device returns the contract hash, contract name, contract version and result information to the client where the contract upload object is located.

[0265] S17. The billing management module of the central auditing device performs fee deduction processing for contract storage management.

[0266] S18. The client records the returned information.

[0267] S19. The process ends.

[0268] In this process, the smart contract uploaded by the contract upload object to the central audit device is a business contract edited according to business needs. This application can flexibly meet the user's needs for different smart contracts; in addition, the smart contracts uploaded to the central audit device are required to undergo the more authoritative contract detection and processing of the central audit device, thereby ensuring the security and reliability of the smart contracts stored in the contract warehouse, thereby improving the security of the contract processing process.

[0269] (3) Blockchain contract transaction execution process

[0270] See also Figure 8c , Figure 8c This is a schematic diagram of a blockchain contract transaction execution process provided by an embodiment of the present application. Figure 8c As shown in the figure, the blockchain contract transaction execution process mainly includes the following steps:

[0271] S1. The process starts.

[0272] S2. The requesting party initiates a transaction request to the blockchain to execute the target transaction on the blockchain.

[0273] S3. The network module of the blockchain node receives the transaction request.

[0274] S4. The authentication module of the blockchain node verifies the signature of the request object.

[0275] S5. Is the signature verification successful? If yes, execute S7; otherwise, execute S6.

[0276] S6. Return the result of signature verification failure and jump to S36.

[0277] S7. The authentication module of the blockchain node verifies the permissions of the request object.

[0278] S8. Does the requesting object have the authority to request to call the target smart contract? If yes, execute S10; otherwise, execute S9.

[0279] S9. Return the result that the requested object does not have the permission, and jump to S36.

[0280] S10. The transaction pool module receives the transaction request.

[0281] S11. The block scheduling module schedules the target transaction to execute the transaction request.

[0282] S12. The virtual machine module recognizes that the target smart contract is a business contract.

[0283] S13. The virtual machine module checks whether the target transaction exists in the contract cache module. If so, execute S30; otherwise, execute S14.

[0284] S14. The contract download submodule of the virtual machine module accesses the central audit device to download the target smart contract.

[0285] S15. The network module of the central audit device receives the transaction request.

[0286] S16. The authentication module of the central audit device performs signature verification on the blockchain node.

[0287] S17. Is the signature verification passed? If yes, execute S19; otherwise, execute S18.

[0288] S18. Return the result of the central audit device signature verification failure and jump to S31.

[0289] S19. Does the blockchain node have the authority to query the contract? If yes, execute S21; otherwise, execute S20.

[0290] S20. Return the result of failure of central audit device authority verification and jump to S31.

[0291] S21. Does the central audit device check whether the target smart contract exists in the contract code cache module? If so, execute S26; otherwise, execute S22.

[0292] S22. Does the central audit device check whether the target smart contract exists in the contract code storage module? If so, execute S24; otherwise, execute S23.

[0293] S23. The central audit device returns the information that the contract code storage does not exist and jumps to S27.

[0294] S24. The central audit device obtains the target smart contract from the contract repository in the contract code storage module.

[0295] S25. The central audit device puts the acquired target smart contract into the contract code cache module.

[0296] S26. The central audit device returns the target smart contract, the contract hash of the target smart contract, and the signature data of the central audit device to the blockchain node, and jumps to S28.

[0297] S27. The blockchain node records the information that the transaction execution failed and the contract does not exist, and jumps to S32.

[0298] S28. The contract authentication module of the blockchain node authenticates the correctness of the contract hash and signature data of the target smart contract.

[0299] S29. The blockchain node receives the target smart contract and puts it into the contract cache module.

[0300] S30. The blockchain node obtains the target smart contract from the contract cache module and starts the contract process or contract coroutine to execute the target transaction.

[0301] S31. The blockchain node records the transaction execution result of the target transaction.

[0302] S32: Is the block consensus passed? If yes, execute S34; otherwise, execute S33.

[0303] S33, the blockchain discards the block and jumps to S36.

[0304] S34. The blockchain appends the block to the ledger data.

[0305] S35. The block records the transaction execution results into the status database.

[0306] S36. The process ends.

[0307] In this process, when the request object requests to execute the target transaction in the blockchain, the blockchain node can determine the contract type of the target smart contract to be called by the current target transaction. If the contract type of the target smart contract is the first type, that is, the target smart contract is a business contract, the blockchain node can request the central audit device to obtain the target smart contract to be called, so as to execute the target transaction on the blockchain. It can be seen that the blockchain node device does not need to store the target smart contract by itself. Since each smart contract has been uploaded to the contract warehouse of the central audit device for storage, the corresponding target smart contract can be obtained by accessing the contract warehouse of the central audit device to reduce the storage pressure of the blockchain node, thereby improving the efficiency of contract processing. In addition, the target smart contract in the contract warehouse has passed the contract detection, so the obtained target smart contract can be guaranteed to be safe and reliable, thereby improving the reliability of the contract processing process.

[0308] The following provides an apparatus of an embodiment of the present application. Next, in combination with the blockchain-based contract processing solution provided in the above-mentioned embodiment of the present application, the relevant apparatus of the embodiment of the present application is introduced accordingly.

[0309] See also Fig. 9 , Fig. 9 Schematic diagram of a blockchain-based contract processing device provided in an embodiment of the present application. Fig. 9As shown, the blockchain-based contract processing device 900 can be applied to the blockchain node mentioned in the above embodiments. Specifically, the blockchain-based contract processing device 900 can be a computer program (including program code) running in a computer device, for example, the contract processing device 900 is an application software; the contract processing device 900 can be used to execute the corresponding steps in the blockchain-based contract processing method provided in the embodiment of the present application. In specific implementation, the blockchain-based contract processing device 900 can specifically include:

[0310] A receiving unit 901 is used to receive a transaction request, where the transaction request is used to request execution of a target transaction on a blockchain, and the transaction request carries a contract identifier of a target smart contract to be called to execute the target transaction;

[0311] The acquisition unit 902 is used to acquire the contract type of the target smart contract, and the contract type of the smart contract supported by the blockchain includes at least the first type; the first type of smart contract is stored in the contract warehouse of the central audit device associated with the blockchain, and the contract file of the smart contract stored in the contract warehouse has passed the contract detection processing of the central audit device;

[0312] The acquisition unit 902 is further configured to acquire the target smart contract from the contract repository of the central audit device according to the contract identifier of the target smart contract if the contract type of the target smart contract is the first type;

[0313] The processing unit 903 is used to call the target smart contract to execute the target transaction.

[0314] In a possible implementation, the contract processing method is executed by a blockchain node, and an authentication module is configured in the blockchain node; the transaction request is generated after the request object signs the target transaction; after the receiving unit 901 receives the transaction request, the processing unit 903 is further used to perform the following operations:

[0315] Parse the transaction request and obtain the signature data of the request object;

[0316] According to the signature data, the authentication module is called to perform authentication processing on the request object, and the authentication processing includes: any one or more of signature verification processing and permission verification processing;

[0317] If the authentication of the request object is passed and the contract type of the target smart contract is the first type, the step of obtaining the target smart contract from the contract repository of the central audit device according to the contract identifier of the target smart contract is triggered.

[0318] In a possible implementation, a virtual machine module is further configured in the blockchain node, and the virtual machine module includes: a contract identification submodule, a contract cache submodule, and a contract download submodule; the processing unit 903 method is also used to perform the following operations:

[0319] Call the contract identification submodule to identify the contract type of the target smart contract;

[0320] If the contract type of the target smart contract is identified as the first type, check whether the target smart contract exists in the contract cache submodule;

[0321] If it does not exist, the contract download submodule is called to access the central audit device to obtain the target smart contract to be called from the contract repository of the central audit device.

[0322] In a possible implementation, the virtual machine module further includes a contract authentication submodule; and the processing unit 903 is further configured to perform the following operations:

[0323] Receive the target smart contract, the contract hash of the target smart contract, and the signature data of the central audit device returned by the central audit device;

[0324] Call the contract authentication submodule to verify the contract hash of the target smart contract and the signature data of the central audit device;

[0325] If it is determined that both the contract hash and signature data are verified, the target smart contract is stored in the contract cache submodule to trigger the call of the target smart contract from the contract cache submodule to execute the target transaction.

[0326] In a possible implementation, the contract type of the smart contract supported by the blockchain further includes a second type, and the second type of smart contract is stored on the blockchain; the virtual machine module also includes a system contract submodule; before obtaining the target smart contract from the contract repository of the central audit device according to the contract identifier of the target smart contract, the processing unit 903 is further used to perform the following operations:

[0327] Receive a node registration request initiated by an administrator object for a central audit device. The node registration request is used to request a blockchain node to register its identity with the central audit device. The node registration request carries the target registration address of the central audit device to be accessed.

[0328] If the contract type of the smart contract to be called by the node registration request is the second type, the system contract submodule is called to access the central audit device indicated by the target registration address for identity registration;

[0329] Among them, the blockchain node that completes identity registration is associated with the central audit device.

[0330] In a possible implementation, the node registration request is generated after signature processing of the administrator object; after receiving the node registration request initiated by the administrator object for the central audit device, the processing unit 903 is further configured to perform the following operations:

[0331] Call the authentication module to authenticate the administrator object. The authentication process includes: any one or more of signature verification and authority verification.

[0332] If the administrator object is authenticated, the contract identification submodule is called to identify the contract type of the smart contract that needs to be called by the node registration request.

[0333] In a possible implementation, a contract coroutine is running in the virtual machine module, and the target transaction includes multiple subtasks to be executed; the processing unit 903 calls the target smart contract to execute the target transaction, and is used to perform the following operations:

[0334] Run the contract coroutine corresponding to the target smart contract in the virtual machine module;

[0335] Switch to execute each subtask in the contract coroutine corresponding to the target smart contract to obtain the execution results of each subtask.

[0336] In an embodiment of the present application, a transaction request can be received, the transaction request is used to request the execution of a target transaction on the blockchain, and the transaction request carries the contract identifier of the target smart contract to be called to execute the target transaction; the contract type of the target smart contract is obtained, and the contract type of the smart contract supported by the blockchain includes at least the first type; the first type of smart contract is stored in the contract warehouse of the central audit device associated with the blockchain, and the contract file of the smart contract stored in the contract warehouse has passed the contract detection process of the central audit device; if the contract type of the target smart contract is the first type, the target smart contract is obtained from the contract warehouse of the central audit device according to the contract identifier of the target smart contract; the target smart contract is called to execute the target transaction. It can be seen from this that the present application can store the first type of smart contract in the central audit device associated with the blockchain, and the smart contract does not need to be stored in the blockchain, which can reduce the storage burden of the blockchain node; in addition, the smart contract stored in the contract warehouse of the central audit device has passed the contract detection process, which can improve the accuracy of the smart contract called on the chain.

[0337] See also Fig.10 , Fig.10 Schematic diagram of another blockchain-based contract processing device provided in an embodiment of the present application. Fig.10As shown, the blockchain-based contract processing device 1000 can be applied to the central audit device mentioned in the above embodiments. Specifically, the blockchain-based contract processing device 1000 can be a computer program (including program code) running in a computer device, for example, the contract processing device 1000 is an application software; the contract processing device 1000 can be used to execute the corresponding steps in the blockchain-based contract processing method provided in the embodiment of the present application. In specific implementation, the blockchain-based contract processing device 1000 can specifically include:

[0338] The receiving unit 1001 is used to receive a contract acquisition request sent by a blockchain node. The contract acquisition request is generated after determining that the contract type of the target smart contract to be called to execute the target transaction is the first type. The transaction request of the target transaction carries the contract identifier of the target smart contract.

[0339] The processing unit 1002 is used to obtain the target smart contract from the contract warehouse according to the contract identifier of the target smart contract, and the contract file of the smart contract stored in the contract warehouse has passed the contract detection process;

[0340] The sending unit 1003 is used to return the target smart contract to the blockchain node, and the target smart contract is used to trigger the execution of the target transaction on the blockchain.

[0341] In a possible implementation, the contract repository is stored in a central audit device associated with the blockchain, and a contract code checking module is configured in the central audit device; the processing unit 1002 is further used to perform the following operations:

[0342] Receive a contract upload request sent by a contract upload object, where the contract upload request includes the contract file of the smart contract to be uploaded;

[0343] Authenticate the contract upload object;

[0344] If the authentication of the contract upload object is passed, the contract code check module is called to perform contract detection processing on the contract file of the uploaded smart contract;

[0345] If the contract detection process of the uploaded smart contract passes, storage management is performed on the uploaded smart contract.

[0346] In a possible implementation, the central audit device is further configured with: a contract code storage module and a billing management module, the contract code storage module maintains a contract repository; the processing unit 1002 performs storage management on the uploaded smart contract, and is used to perform the following operations:

[0347] Perform hash operation on the uploaded smart contract to obtain the contract hash;

[0348] The contract hash and the smart contract to be uploaded are associated and stored in the contract warehouse; and the contract identifier and the smart contract to be uploaded are associated and stored in the contract warehouse, where the contract identifier includes the contract name and contract version;

[0349] The billing management module is called to deduct fees for the storage management performed.

[0350] In a possible implementation, the processing unit 1002 is further configured to perform the following operations:

[0351] In response to a node registration request sent by a blockchain node to be registered, the node registration request includes node information of the blockchain node to be registered;

[0352] Determine the node type of the blockchain node to be registered based on the node information, and obtain a blacklist, where the blacklist stores at least one blockchain node that does not meet the registration conditions;

[0353] If the node type belongs to the preset node type and the blacklist does not contain the blockchain node to be registered, the identity registration process is performed on the blockchain node.

[0354] In the embodiment of the present application, a contract warehouse is maintained in the central audit device, and a plurality of first-type smart contracts are stored in the contract warehouse. The contract files of these smart contracts are processed by the contract detection of the central audit device; when the blockchain node requests to obtain a smart contract, the matching target smart contract can be obtained from the contract warehouse and sent to the blockchain node. It can be seen that when the blockchain node executes the target transaction on the chain, it can obtain the target smart contract to be called from the contract warehouse. The blockchain node does not need to store each smart contract by itself, which can reduce the storage pressure of the blockchain node and thus improve the performance of the blockchain node.

[0355] See also Fig.11 , Fig.11It is a structural diagram of a computer device provided in an embodiment of the present application. The computer device 1100 is used to execute the steps performed by the blockchain node or the central audit device in the aforementioned method embodiment, and the computer device 1100 includes: one or more processors 1101; one or more input devices 1102, one or more output devices 1103 and a memory 1104. The above-mentioned processor 1101, input device 1102, output device 1103 and memory 1104 are connected via a bus 1105. Among them, the processor 1101 (or CPU (Central Processing Unit)) is the processing core of the computer device, and the processor 1101 is suitable for implementing one or more program instructions, and is specifically suitable for loading and executing one or more program instructions to implement the above-mentioned blockchain-based contract processing method process. Specifically, the memory 1104 is used to store a computer program, and the computer program includes program instructions.

[0356] In a feasible embodiment, when the computer device 1100 is a blockchain node, the processor 1101 is used to call the program instructions stored in the memory 1104 to perform the following operations:

[0357] Receive a transaction request, which is used to request the execution of a target transaction on the blockchain. The transaction request carries the contract identifier of the target smart contract to be called to execute the target transaction;

[0358] Obtaining the contract type of the target smart contract, the contract types of smart contracts supported by the blockchain include at least the first type; the first type of smart contracts are stored in the contract warehouse of the central audit device associated with the blockchain, and the contract files of the smart contracts stored in the contract warehouse have passed the contract detection processing of the central audit device;

[0359] If the contract type of the target smart contract is the first type, the target smart contract is obtained from the contract warehouse of the central audit device according to the contract identifier of the target smart contract;

[0360] Call the target smart contract to execute the target transaction.

[0361] In a possible implementation, the contract processing method is executed by a blockchain node, and an authentication module is configured in the blockchain node; the transaction request is generated after the request object signs the target transaction; after receiving the transaction request, the processor 1101 is further used to perform the following operations:

[0362] Parse the transaction request and obtain the signature data of the request object;

[0363] According to the signature data, the authentication module is called to perform authentication processing on the request object, and the authentication processing includes: any one or more of signature verification processing and permission verification processing;

[0364] If the authentication of the request object is passed and the contract type of the target smart contract is the first type, the step of obtaining the target smart contract from the contract repository of the central audit device according to the contract identifier of the target smart contract is triggered.

[0365] In a possible implementation, a virtual machine module is further configured in the blockchain node, and the virtual machine module includes: a contract identification submodule, a contract cache submodule, and a contract download submodule; the processor 1101 method is also used to perform the following operations:

[0366] Call the contract identification submodule to identify the contract type of the target smart contract;

[0367] If the contract type of the target smart contract is identified as the first type, check whether the target smart contract exists in the contract cache submodule;

[0368] If it does not exist, the contract download submodule is called to access the central audit device to obtain the target smart contract to be called from the contract repository of the central audit device.

[0369] In a possible implementation, the virtual machine module further includes a contract authentication submodule; the processor 1101 is further configured to perform the following operations:

[0370] Receive the target smart contract, the contract hash of the target smart contract, and the signature data of the central audit device returned by the central audit device;

[0371] Call the contract authentication submodule to verify the contract hash of the target smart contract and the signature data of the central audit device;

[0372] If it is determined that both the contract hash and signature data are verified, the target smart contract is stored in the contract cache submodule to trigger the call of the target smart contract from the contract cache submodule to execute the target transaction.

[0373] In a possible implementation, the contract type of the smart contract supported by the blockchain further includes a second type, and the second type of smart contract is stored on the blockchain; the virtual machine module also includes a system contract submodule; before obtaining the target smart contract from the contract repository of the central audit device according to the contract identifier of the target smart contract, the processor 1101 is further used to perform the following operations:

[0374] Receive a node registration request initiated by an administrator object for a central audit device. The node registration request is used to request a blockchain node to register its identity with the central audit device. The node registration request carries the target registration address of the central audit device to be accessed.

[0375] If the contract type of the smart contract to be called by the node registration request is the second type, the system contract submodule is called to access the central audit device indicated by the target registration address for identity registration;

[0376] Among them, the blockchain node that completes identity registration is associated with the central audit device.

[0377] In a possible implementation, the node registration request is generated after signature processing of the administrator object; after receiving the node registration request initiated by the administrator object for the central audit device, the processor 1101 is further configured to perform the following operations:

[0378] Call the authentication module to authenticate the administrator object. The authentication process includes: any one or more of signature verification and authority verification.

[0379] If the administrator object is authenticated, the contract identification submodule is called to identify the contract type of the smart contract that needs to be called by the node registration request.

[0380] In a possible implementation, a contract coroutine is running in the virtual machine module, and the target transaction includes multiple subtasks to be executed; the processor 1101 calls the target smart contract to execute the target transaction, and is used to perform the following operations:

[0381] Run the contract coroutine corresponding to the target smart contract in the virtual machine module;

[0382] Switch to execute each subtask in the contract coroutine corresponding to the target smart contract to obtain the execution results of each subtask.

[0383] In another feasible embodiment, when the computer device 1100 is a central audit device, the processor 1101 is used to call the program instructions stored in the memory 1104 to perform the following operations:

[0384] Receive a contract acquisition request sent by a blockchain node, where the contract acquisition request is generated after determining that the contract type of the target smart contract to be called to execute the target transaction is the first type, and the transaction request of the target transaction carries the contract identifier of the target smart contract;

[0385] According to the contract identifier of the target smart contract, the target smart contract is obtained from the contract warehouse. The contract files of the smart contract stored in the contract warehouse have passed the contract detection process;

[0386] The target smart contract is returned to the blockchain node, and the target smart contract is used to trigger the execution of the target transaction on the blockchain.

[0387] In a possible implementation, the contract repository is stored in a central audit device associated with the blockchain, and a contract code checking module is configured in the central audit device; the processor 1101 is further configured to perform the following operations:

[0388] Receive a contract upload request sent by a contract upload object, where the contract upload request includes the contract file of the smart contract to be uploaded;

[0389] Authenticate the contract upload object;

[0390] If the authentication of the contract upload object is passed, the contract code check module is called to perform contract detection processing on the contract file of the uploaded smart contract;

[0391] If the contract detection process of the uploaded smart contract passes, storage management is performed on the uploaded smart contract.

[0392] In a possible implementation, the central audit device is further configured with: a contract code storage module and a billing management module, the contract code storage module maintains a contract warehouse; the processor 1101 performs storage management on the uploaded smart contract, and is used to perform the following operations:

[0393] Perform hash operation on the uploaded smart contract to obtain the contract hash;

[0394] The contract hash and the smart contract to be uploaded are associated and stored in the contract warehouse; and the contract identifier and the smart contract to be uploaded are associated and stored in the contract warehouse, where the contract identifier includes the contract name and contract version;

[0395] The billing management module is called to deduct fees for the storage management performed.

[0396] In a possible implementation manner, the processor 1101 is further configured to perform the following operations:

[0397] In response to a node registration request sent by a blockchain node to be registered, the node registration request includes node information of the blockchain node to be registered;

[0398] Determine the node type of the blockchain node to be registered based on the node information, and obtain a blacklist, where the blacklist stores at least one blockchain node that does not meet the registration conditions;

[0399] If the node type belongs to the preset node type and the blacklist does not contain the blockchain node to be registered, the identity registration process is performed on the blockchain node.

[0400] In an embodiment of the present application, a transaction request can be received, the transaction request is used to request the execution of a target transaction on the blockchain, and the transaction request carries the contract identifier of the target smart contract to be called to execute the target transaction; the contract type of the target smart contract is obtained, and the contract type of the smart contract supported by the blockchain includes at least the first type; the first type of smart contract is stored in the contract warehouse of the central audit device associated with the blockchain, and the contract file of the smart contract stored in the contract warehouse has passed the contract detection process of the central audit device; if the contract type of the target smart contract is the first type, the target smart contract is obtained from the contract warehouse of the central audit device according to the contract identifier of the target smart contract; the target smart contract is called to execute the target transaction. It can be seen from this that the present application can store the first type of smart contract in the central audit device associated with the blockchain, and the smart contract does not need to be stored in the blockchain, which can reduce the storage burden of the blockchain node; in addition, the smart contract stored in the contract warehouse of the central audit device has passed the contract detection process, which can improve the accuracy of the smart contract called on the chain.

[0401] In addition, it should be pointed out here that: the embodiment of the present application also provides a computer storage medium, and a computer program is stored in the computer storage medium, and the computer program includes program instructions. When the processor executes the above program instructions, the method in the corresponding embodiment of the foregoing text can be executed, so it will not be repeated here. For technical details not disclosed in the computer storage medium embodiment involved in this application, please refer to the description of the method embodiment of this application. As an example, the program instructions can be deployed on a computer device, or executed on multiple computer devices located in one place, or, executed on multiple computer devices distributed in multiple locations and interconnected by a communication network.

[0402] According to one aspect of the present application, an embodiment of the present application further provides a computer program product or a computer program, the computer program product or the computer program including computer instructions, the computer instructions being stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device can execute the method in the above corresponding embodiment, and therefore, it will not be described in detail here.

[0403] A person skilled in the art can appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed in this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. A person skilled in the art 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.

[0404] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present invention is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted through a computer-readable storage medium. The computer instructions can be transmitted from a website site, a computer, a server or a data center to another website site, a computer, a server or a data center by wired (e.g., coaxial cable, optical fiber, digital line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can access or a data processing device such as a server, a data center, etc. that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)), etc.

[0405] The above disclosure is only the preferred embodiment of the present application, which 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 contract processing method based on blockchain, characterized in that: include: Receive a transaction request, where the transaction request is used to request execution of a target transaction on a blockchain, and the transaction request carries a contract identifier of a target smart contract to be called to execute the target transaction; Acquire the contract type of the target smart contract, where the contract types of smart contracts supported by the blockchain include at least a first type; the first type of smart contracts are stored in a contract repository of a central audit device associated with the blockchain, and the contract files of the smart contracts stored in the contract repository have passed the contract detection process of the central audit device; If the contract type of the target smart contract is the first type, obtaining the target smart contract from the contract repository of the central audit device according to the contract identifier of the target smart contract; Call the target smart contract to execute the target transaction.

2. The method according to claim 1, characterized in that The contract processing method is executed by a blockchain node, and an authentication module is configured in the blockchain node; the transaction request is generated after the request object signs the target transaction; After receiving the transaction request, the method further includes: Parsing the transaction request to obtain signature data of the request object; According to the signature data, calling the authentication module to perform authentication processing on the request object, the authentication processing including: any one or more of signature verification processing and authority verification processing; If the authentication of the request object is passed and the contract type of the target smart contract is the first type, the step of obtaining the target smart contract from the contract repository of the central audit device according to the contract identifier of the target smart contract is triggered.

3. The method according to claim 2, characterized in that The blockchain node is also configured with a virtual machine module, which includes: a contract identification submodule, a contract cache submodule, and a contract download submodule; the method also includes: Calling the contract identification submodule to identify the contract type of the target smart contract; If the contract type of the target smart contract is identified as the first type, checking whether the target smart contract exists in the contract cache submodule; If it does not exist, the contract download submodule is called to access the central audit device to obtain the target smart contract to be called from the contract repository of the central audit device.

4. The method according to claim 3, characterized in that The virtual machine module also includes a contract authentication submodule; the method also includes: Receive the target smart contract, the contract hash of the target smart contract, and the signature data of the central audit device returned by the central audit device; Calling the contract authentication submodule to verify the contract hash of the target smart contract and the signature data of the central audit device respectively; If it is determined that both the contract hash and the signature data are verified, the target smart contract is stored in the contract cache submodule to trigger calling the target smart contract from the contract cache submodule to execute the target transaction.

5. The method according to claim 3, characterized in that The contract type of the smart contract supported by the blockchain also includes a second type, and the smart contract of the second type is stored on the blockchain; the virtual machine module also includes a system contract submodule; before obtaining the target smart contract from the contract warehouse of the central audit device according to the contract identifier of the target smart contract, it also includes: Receive a node registration request initiated by an administrator object for a central audit device, wherein the node registration request is used to request a blockchain node to register its identity with the central audit device, and the node registration request carries a target registration address of the central audit device to be accessed; If the contract type of the smart contract to be called by the node registration request is the second type, calling the system contract submodule to access the central audit device indicated by the target registration address to perform identity registration; Among them, the blockchain node that completes identity registration is associated with the central audit device.

6. The method according to claim 5, characterized in that The node registration request is generated after being processed by the signature of the administrator object; After receiving the node registration request initiated by the administrator object for the central audit device, the method further includes: Calling the authentication module to perform authentication processing on the administrator object, wherein the authentication processing includes: any one or more of signature verification processing and authority verification processing; If the administrator object is authenticated, the contract identification submodule is called to identify the contract type of the smart contract to be called by the node registration request.

7. The method according to claim 3, characterized in that A contract coroutine is running in the virtual machine module, and the target transaction includes a plurality of subtasks to be executed; calling the target smart contract to execute the target transaction includes: Running the contract coroutine corresponding to the target smart contract in the virtual machine module; Switch and execute each subtask in the contract coroutine corresponding to the target smart contract to obtain the execution results of each subtask.

8. A contract processing method based on blockchain, characterized in that: include: Receive a contract acquisition request sent by a blockchain node, where the contract acquisition request is generated after determining that the contract type of a target smart contract to be called to execute a target transaction is a first type, and the transaction request of the target transaction carries a contract identifier of the target smart contract; According to the contract identifier of the target smart contract, the target smart contract is obtained from the contract warehouse, and the contract file of the smart contract stored in the contract warehouse has passed the contract detection process; The target smart contract is returned to the blockchain node, and the target smart contract is used to trigger the execution of the target transaction on the blockchain.

9. The method according to claim 8, characterized in that The contract repository is stored in a central audit device associated with the blockchain, and a contract code checking module is configured in the central audit device; the method further includes: Receive a contract upload request sent by a contract upload object, wherein the contract upload request includes a contract file of a smart contract to be uploaded; Authenticate the contract upload object; If the contract upload object is authenticated, the contract code checking module is called to perform contract detection processing on the contract file of the smart contract to be uploaded; If the contract detection process of the smart contract to be uploaded passes, storage management is performed on the smart contract to be uploaded.

10. The method according to claim 9, characterized in that The central audit device is also configured with: a contract code storage module and a billing management module, wherein the contract code storage module maintains a contract warehouse; the storage management of the smart contract to be uploaded includes: Performing hash operation on the smart contract to be uploaded to obtain a contract hash; The contract hash and the smart contract to be uploaded are associated and stored in the contract warehouse; and the contract identifier and the smart contract to be uploaded are associated and stored in the contract warehouse, wherein the contract identifier includes the contract name and the contract version; The billing management module is called to perform fee deduction processing on the executed storage management.

11. The method according to claim 8, characterized in that The method further comprises: In response to a node registration request sent by a blockchain node to be registered, the node registration request includes node information of the blockchain node to be registered; Determine the node type of the blockchain node to be registered based on the node information, and obtain a blacklist, wherein the blacklist stores at least one blockchain node that does not meet the registration conditions; If the node type belongs to a preset node type and the blockchain node to be registered is not included in the blacklist, identity registration processing is performed on the blockchain node.

12. A blockchain-based contract processing device, characterized in that: include: A receiving unit, configured to receive a transaction request, wherein the transaction request is used to request execution of a target transaction on a blockchain, and the transaction request carries a contract identifier of a target smart contract to be called to execute the target transaction; An acquisition unit, configured to acquire a contract type of the target smart contract, wherein the contract types of smart contracts supported by the blockchain include at least a first type; the smart contracts of the first type are stored in a contract repository of a central audit device associated with the blockchain, and the contract files of the smart contracts stored in the contract repository have passed the contract detection process of the central audit device; The acquisition unit is further configured to acquire the target smart contract from the contract repository of the central audit device according to the contract identifier of the target smart contract if the contract type of the target smart contract is the first type; A processing unit is used to call the target smart contract to execute the target transaction.

13. A contract processing device based on blockchain, characterized in that: include: A receiving unit, configured to receive a contract acquisition request sent by a blockchain node, wherein the contract acquisition request is generated after determining that the contract type of a target smart contract to be called to execute a target transaction is a first type, and the transaction request of the target transaction carries a contract identifier of the target smart contract; A processing unit, configured to obtain the target smart contract from a contract repository according to the contract identifier of the target smart contract, wherein the contract file of the smart contract stored in the contract repository has passed the contract detection process; A sending unit is used to return the target smart contract to the blockchain node, and the target smart contract is used to trigger the execution of the target transaction on the blockchain.

14. A computer device, characterized in that: include: storage devices and processors; a memory storing one or more computer programs; A processor, used to load the one or more computer programs to implement the blockchain-based contract processing method as described in any one of claims 1-7 or 8-11.

15. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, which is suitable for being loaded by a processor and executing a blockchain-based contract processing method as described in any one of claims 1-7 or 8-11.

16. A computer program product, characterized in that The computer program product includes a computer program, which is suitable for being loaded by a processor and executing a blockchain-based contract processing method as described in any one of claims 1-7 or 8-11.

Images