WO2023016164A1 - 一种基于智能合约的数据处理方法、装置、电子设备、计算机可读存储介质及计算机程序产品 - Google Patents

一种基于智能合约的数据处理方法、装置、电子设备、计算机可读存储介质及计算机程序产品 Download PDF

Info

Publication number
WO2023016164A1
WO2023016164A1 PCT/CN2022/104894 CN2022104894W WO2023016164A1 WO 2023016164 A1 WO2023016164 A1 WO 2023016164A1 CN 2022104894 W CN2022104894 W CN 2022104894W WO 2023016164 A1 WO2023016164 A1 WO 2023016164A1
Authority
WO
WIPO (PCT)
Prior art keywords
contract
local
node
consensus
identifier
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2022/104894
Other languages
English (en)
French (fr)
Inventor
蓝虎
王宗友
时一防
刘汉卿
朱耿良
刘区城
廖志勇
刘攀
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to EP22855147.9A priority Critical patent/EP4300398A4/en
Publication of WO2023016164A1 publication Critical patent/WO2023016164A1/zh
Priority to US18/196,878 priority patent/US20230289782A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12—Accounting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]

Definitions

  • the present application relates to the technical field of blockchain, and in particular to a data processing method, device, electronic equipment, computer-readable storage medium and computer program product based on smart contracts.
  • a smart contract is a code that can be understood and executed by each node on the blockchain, and can execute arbitrary logic and obtain results; a smart contract can be understood as an executable program, and a blockchain can be understood as It is the operating system that provides the operating environment for the program. In practical applications, smart contracts can be managed and tested through transactions on the blockchain.
  • business objects can invoke smart contracts that have been deployed on the blockchain by initiating a transaction.
  • all smart contracts are deployed and run on the consensus nodes in the blockchain network.
  • Each consensus node runs the smart contract specified by the exchange respectively.
  • each consensus node will access its own ledger.
  • each consensus node will verify whether the execution results are consistent with each other (consensus). If they are consistent, the execution results will be stored in their respective ledgers, and the execution results will be returned to the business object.
  • the execution results can also be synchronized to other types of nodes. , which makes the amount of data storage and computing workload of the consensus node larger, and then the load of the consensus node is larger, which affects the data processing efficiency.
  • Embodiments of the present application provide a smart contract-based data processing method, device, electronic device, computer-readable storage medium, and computer program product, which can reduce the load on consensus nodes and improve data processing efficiency.
  • An embodiment of the present application provides a data processing method based on a smart contract, the method is executed by a service node in a service network, and the service node includes at least one electronic device, including:
  • the initial contract call request includes the first contract identifier used to call the contract on the target chain; the contract on the target chain is deployed on the consensus node of the core consensus network, the The core consensus network is independent of the business network; both the consensus node and the business node store the first mapping relationship between the first contract identifier and the second contract identifier; the second contract identifier is a deployment The contract identifier of the target local contract on the service node;
  • the embodiment of the present application provides a smart contract-based data processing method, the method is executed by a consensus node in the core consensus network, and the consensus node includes at least one electronic device, including:
  • the target contract call request for executing the transaction business;
  • the target contract call request is sent by the service node based on the local transaction execution result and the initial contract call request, and the service node is located in the service network independent of the core consensus network middle;
  • the local transaction execution result is obtained by the service node executing the local service indicated by the transaction service by calling the target local contract;
  • the target local contract is obtained by the service node based on the second contract identifier ;
  • the second contract identifier is queried by the service node based on the first contract identifier and the first mapping relationship;
  • the first contract identifier refers to the contract used to call the contract on the target chain in the initial contract call request identification;
  • the initial contract call request is used to execute the transaction business;
  • the contract on the target chain is deployed on the consensus node; both the consensus node and the service node store the first contract identification and
  • the second contract identifier is the contract identifier of the target
  • An embodiment of the present application provides a first data processing device based on a smart contract, the first data processing device is stored in a service node of a service network, including:
  • the first obtaining module is used to obtain an initial contract call request for executing transaction services;
  • the initial contract call request includes a first contract identifier for calling a contract on the target chain;
  • the contract on the target chain is deployed on the core consensus network
  • the core consensus network is independent of the business network; both the consensus node and the business node store the first mapping relationship between the first contract identifier and the second contract identifier;
  • the second contract identifier is the contract identifier of the target local contract deployed on the service node;
  • the second execution module is configured to query the second contract identifier based on the first contract identifier and the first mapping relationship, determine the target local contract based on the second contract identifier, and call the target local
  • the contract executes the local business indicated by the transaction business, and obtains the execution result of the local transaction
  • a forwarding module configured to send a target contract call request to the consensus node based on the local transaction execution result and the initial contract call request, where the target contract call request is used by the consensus node based on the first contract identification Obtain the contract on the target chain, and execute the consensus service indicated by the transaction service by calling the contract on the target chain.
  • An embodiment of the present application provides a second data processing device based on a smart contract, the second data processing device is stored in a consensus node of the core consensus network, including:
  • the second obtaining module is used to obtain the target contract call request for executing the transaction business; the target contract call request is sent by the service node based on the local transaction execution result and the initial contract call request, and the service node is located independently of the In the business network of the core consensus network; the local transaction execution result is obtained by the business node by calling the target local contract to execute the local business indicated by the transaction business; the target local contract is obtained by the business node based on The second contract identifier is obtained; the second contract identifier is queried by the service node based on the first contract identifier and the first mapping relationship; the first contract identifier refers to the initial contract call request for Call the contract identifier of the contract on the target chain; the initial contract call request is used to execute the transaction business; the contract on the target chain is deployed on the consensus node; both the consensus node and the business node store The first mapping relationship between the first contract identifier and the second contract identifier; the second contract identifier is the contract identifier of the target local contract deployed on
  • the second execution module is configured to call the target on-chain contract based on the first contract identifier in the target contract call request, and execute the consensus service indicated by the transaction service by calling the target on-chain contract, Get the transaction execution result on the chain.
  • An embodiment of the present application provides an electronic device, including: a processor, a memory, and a network interface; the processor is connected to the memory and the network interface, wherein the network interface is used to provide a data communication function, and the memory is used to store
  • the computer program, the above-mentioned processor is used to call the above-mentioned computer program to execute the data processing method based on the smart contract executed by the business node in the business network provided by the embodiment of the application, or to execute the data processing method provided by the core consensus network provided by the embodiment of the application.
  • An embodiment of the present application provides a computer-readable storage medium.
  • the above-mentioned computer-readable storage medium stores a computer program, and the above-mentioned computer program is suitable for being loaded by a processor and executing the service node in the service network provided by the embodiment of the present application.
  • An embodiment of the present application provides a computer program product, the computer program product includes a computer program or an instruction, and when the computer program or instruction is executed by a processor, it executes the service node in the service network provided by the embodiment of the present application.
  • the data processing method of the smart contract, or the data processing method based on the smart contract executed by the consensus nodes in the core consensus network provided by the embodiment of the application.
  • the business node in the business network can first obtain the initial contract call for executing the transaction business Request, execute the local business indicated by the transaction business, and get the execution result of the local transaction.
  • the business node can determine the target contract call request based on the local transaction execution result and the initial contract call request, and forward the target contract call request to the consensus node to execute the consensus business indicated by the transaction business, that is, to execute the consensus business Previously, the business node could process the received contract call request before the consensus node, so that the local business executed on the consensus node was moved to the business node for processing, reducing the resource consumption of the consensus node to execute local business, so that Reduce the load of consensus nodes and improve the transaction processing efficiency of the blockchain network.
  • FIG. 1 is a schematic diagram of a layered structure of a blockchain network provided by an embodiment of the present application
  • FIGS. 2a-2b are schematic diagrams of a data processing scenario provided by an embodiment of the present application.
  • FIG. 3 is a schematic flow diagram of a smart contract-based data processing method provided by an embodiment of the present application.
  • FIG. 4 is a schematic flow diagram of a smart contract-based data processing method provided by an embodiment of the present application.
  • 5a-5c are schematic diagrams of a data processing scenario provided by an embodiment of the present application.
  • FIG. 6 is a schematic flow diagram of a smart contract-based data processing method provided by an embodiment of the present application.
  • Fig. 7 is a schematic flowchart of another smart contract-based data processing method provided by the embodiment of the present application.
  • FIG. 8 is a schematic flowchart of a data processing method provided in an embodiment of the present application.
  • FIG. 9 is a schematic structural diagram of a first data processing device based on a smart contract provided by an embodiment of the present application.
  • Fig. 10 is a schematic structural diagram of a second data processing device based on a smart contract provided by an embodiment of the present application.
  • FIG. 11 is a schematic structural diagram of a computer device provided by an embodiment of the present application.
  • Transaction which is equivalent to the computer term "transaction”. Transactions include operations that need to be submitted to the blockchain network for execution, not just transactions in a business context. In view of the conventional use of The term “transaction” follows this practice in the embodiment of this application.
  • the deployment (Deploy) transaction is used to install the specified smart contract to the node in the blockchain network and is ready to be called;
  • the call (Invoke) transaction is used to add the record of the transaction in the blockchain by calling the smart contract, and
  • Operations on the state database of the blockchain include update operations (including write operations (including adding key-value pair data and deleting key-value pair data) and delete operations) and query operations (that is, querying key-value pairs in the state database).
  • Blockchain is an encrypted and chained transaction storage structure formed by blocks.
  • the header of each block can include not only the hash value of all transactions in the block, but also the hash value of all transactions in the previous block, so that the transactions in the block can be tamper-proof based on the hash value And anti-counterfeiting; newly generated transactions are filled into the block and after the consensus of the nodes in the blockchain network, they will be appended to the end of the blockchain to form a chain growth.
  • Blockchain Network (Blockchain Network), a collection of nodes that incorporate new blocks into the blockchain through consensus.
  • Smart contracts also known as chain code (Chaincode) or application code
  • Chain code Chain code
  • application code programs deployed in the nodes of the blockchain network, and the nodes execute the smart contracts called in the received transactions to update the state database. Key-value data update or query operations.
  • FIG. 1 is a schematic diagram of a blockchain network layered structure provided by an embodiment of the present application.
  • Blockchain is a new application mode of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm. and forgery, while data verification, storage and updating can be performed.
  • the blockchain is essentially a decentralized database, and each node in the database stores the same blockchain. Among them, the nodes in the blockchain network are at the logical level and can be composed of one or more Devices (servers) are mapped.
  • servers Devices
  • the hierarchical structure of the blockchain network in the embodiment of this application can be the blockchain network 1W shown in Figure 1, and the complete blockchain business system corresponding to the blockchain network 1W can be represented by the business network 1 shown in Figure 1 -1.
  • the core consensus network 1-2 and the routing network 1-3 where the routing node 10D is located also called routing agent network).
  • the embodiment of the present application takes the routing node 10D as an example for illustration, and the routing node 10D can be used for network isolation of the service network 1-1 and the core consensus network 1-2.
  • the routing node 10D can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, and can also provide cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, Cloud servers for basic cloud computing services such as cloud communications, middleware services, domain name services, security services, content delivery network (Content Delivery Network, CDN), and big data and artificial intelligence platforms are not limited here.
  • the routing node 10D can layer the peer-to-peer (Peer To Peer, P2P) network to form a layered structure of "business network 1-1-core consensus network 1-2", which can further improve the data on the blockchain. confidentiality and security.
  • the business network 1-1 (that is, the witness network) shown in Figure 1 and the core consensus network 1-2 are independent of each other, and the blockchain node system corresponding to the business network 1-1 (that is, the first blockchain node system)
  • the first blockchain system may specifically include a node 110a, a node 110b, a node 110c, ..., a node 110n.
  • the blockchain nodes in the business network 1-1 can be called business nodes, and the business nodes do not need to participate in the bookkeeping consensus, and are used to execute the transaction business, so as to obtain information related to the transaction business.
  • Linked transaction data can be a full node (Full Node) that contains a complete blockchain database, or a lightweight node (Simplified Payment Verification, SPV) that stores part of the data in the blockchain database. It defines.
  • the service nodes in the embodiment of this application can be described by taking lightweight nodes as an example.
  • the service nodes store part of the transaction data, and through the routing node 10D, from the In the core consensus network 1-2, block header data and partially authorized block data (for example, transactions associated with the business node itself) are obtained.
  • the blockchain node system corresponding to the core consensus network 1-2 shown in Figure 1 may also include one or more blockchain nodes, and the second blockchain node system will not be used here.
  • the number of nodes in the chain node system is limited.
  • the second blockchain system may specifically include a node 120a, a node 120b, a node 120c, ..., a node 120m.
  • the nodes in the core consensus network 1-2 may be referred to as consensus nodes (ie accounting nodes), and the consensus nodes may run a blockchain consensus protocol.
  • the consensus node in the embodiment of the present application can be a full node including a complete blockchain database.
  • the consensus node can participate in verification, broadcast transaction data and block information, and will discover and maintain connections with other nodes.
  • routing nodes, service nodes, and consensus nodes may be collectively referred to as blockchain nodes in the blockchain network 1W.
  • the blockchain node may be a server connected to the blockchain network 1W, or a user terminal connected to the blockchain network 1W, and the specific form of the blockchain node is not limited here.
  • the service network 1-1 and the core consensus network 1-2 shown in FIG. The consensus nodes running the blockchain consensus protocol are deployed in the private core consensus network 1-2, and the two can interact through the routing boundary.
  • the service node and the consensus node can directly transmit data without going through the routing node.
  • the blockchain system can include smart contracts, which are codes that can be understood and executed by each node of the blockchain (including consensus nodes) in the blockchain system, and can execute arbitrary logic and got the answer.
  • the smart contracts deployed and only run on the business nodes of the business network 1-1 are collectively referred to as local contracts
  • the smart contracts deployed on the consensus nodes of the core consensus network 1-2 are collectively referred to as on-chain contracts.
  • the business object (which can be the user who requests to execute the transaction business or the user who requests to deploy the smart contract) can initiate a contract call request (also called a transaction service request) through the client on the user terminal to call the blockchain system Smart contracts that have been deployed (can be local contracts or on-chain contracts).
  • one or more smart contracts can be included in the blockchain system, and these smart contracts can be identified by a contract (such as an identification number (Identity document, ID) or name, and can also include a contract address or a contract function name (also called It is the contract method name)) to distinguish, and the contract call request initiated by the client can also carry the identification number or name of the smart contract, so as to specify the smart contract that the blockchain needs to run. And if the smart contract specified by the client is a contract that needs to read data, the relevant node will access the local storage to read the data. For transactions that need to be uploaded to the chain, each consensus node will verify whether the execution results are consistent with each other (that is, consensus), and if they are consistent, they can store the execution results in their respective local ledgers and return the execution results to the client.
  • a contract such as an identification number (Identity document, ID) or name, and can also include a contract address or a contract function name (also called It is the contract method name)
  • the contract call request initiated by the client can
  • the on-chain contract specified and invoked by the business object can be called the target on-chain contract, and the contract ID of the target on-chain contract can be called the first contract ID.
  • the contract related to the target on-chain contract can be The linked local contract is called the target local contract, and the contract identifier of the target local contract is called the second contract identifier.
  • the first mapping relationship between the contract identifier and the second contract identifier can be referred to as the first mapping relationship, wherein the business node here specifically refers to the node in the business network 1-1 that has the execution authority for the target local contract, A node (such as node 110a shown in FIG. 1 ) can be designated by the business object in the business network 1-1 shown in FIG. 1 as the business node, that is, the target local contract is deployed and runs on the business node.
  • the service node may first obtain the initial contract invocation request sent by the first user terminal, wherein the first user terminal here refers to the user terminal that sends the initial contract invocation request, and the initial contract invocation request includes the first
  • the contract identifier can be used to execute related transactions, and then based on the first contract identifier and the first mapping relationship, the second contract identifier associated with the contract on the target chain can be queried in the node memory of the business node, and then based on the first
  • the second contract identifier obtains the target local contract, and calls the target local contract to execute the local business indicated by the transaction business, so as to obtain the local transaction execution result.
  • the business node can determine the target contract call request based on the local transaction execution result and the initial contract call request. It should be noted that after executing the local business, the target contract call request obtained may be the same request as the initial Might be a different request than the initial contract call request. Subsequently, the business node can forward the target contract call request to the consensus node.
  • the consensus node After receiving the target contract call request, the consensus node can obtain the contract on the target chain based on the first contract identifier in the target contract call request, and then call the target chain The contract executes the consensus business indicated by the transaction business, and obtains the transaction execution result on the chain; finally, the block to be added to the blockchain (that is, the block to be chained) can be generated according to the transaction execution result on the chain, and the Blocks are uploaded to the chain.
  • the blockchain is the blockchain to which the contract on the target chain belongs.
  • the local contract provided by the embodiment of this application is a special contract that is not executed on the consensus node but only executed on the business node.
  • the business node can first call the target local contract to execute the corresponding local business, and then the consensus node calls the contract on the target chain to execute the corresponding consensus business.
  • each province can have its own different policies. At this time, the business nodes of each province can deploy different Local contracts, only serve this province.
  • local contracts can be checked and calculated in advance to reduce the pressure on consensus nodes; on the other hand, local contracts can access and utilize local business data, so that local business data does not need to be uploaded to the chain, reducing the storage pressure of consensus nodes and making it easier Protect your privacy well.
  • FIG. 2a-FIG. 2b are schematic diagrams of a data processing scenario provided by an embodiment of the present application.
  • the user terminal 20a in Fig. 2a-2b has a binding relationship with the business object A, and the user terminal 20a can invoke the deployed smart contract (on-chain contract or local contract) by initiating a contract invocation request.
  • the business node 20b in Figure 2a- Figure 2b can be a business node with a local contract deployed in the business network, and the business node 20b can be any business node in the business network 1-1 shown in Figure 1 above, for example, node 110a.
  • the consensus node 20c in Figure 2b can be a consensus node with on-chain contracts deployed in the core consensus network, and the consensus node 20c can be any consensus node in the core consensus network 1-2 shown in Figure 1 above, for example, node 120a.
  • the transaction service here can be an asset transfer service, wherein the asset transfer service can be used to transfer virtual assets such as game gold coins, game diamonds, and electronic bills, and the type of virtual assets will not be limited here.
  • the transaction service here may be a file transfer service, where the file transfer service may be used to transfer various forms of electronic documents such as electronic contracts and electronic documents.
  • the transaction service here may also be query service, storage service, etc., which is not limited in this application. It should be noted that when deploying a local contract on a business node, the associated on-chain contract can be specified, so that some data of the on-chain contract can be reused.
  • any service node (for example, service node 20b) in the service network can deploy one or more local contracts (called preset local contracts), and each local contract can perform different functions.
  • the business node has the execution authority for the one or more local contracts, that is, the business node can call the local contracts deployed on the business node.
  • each local contract can be distinguished by a unique contract identifier (such as an identification number or name), for example, the local The contract identifier corresponding to contract 201b is contract identifier 1b, the contract identifier corresponding to local contract 205b is contract identifier 5b, and the contract identifier corresponding to local contract 210b is contract identifier 10b.
  • any consensus node (for example, consensus node 20c) in the core consensus network can deploy one or more on-chain contracts, and the on-chain contracts deployed on each consensus node are the same, each On-chain contracts can also perform different functions.
  • the consensus node 20c as an example, multiple (for example, 30) on-chain contracts can be deployed on the consensus node 20c, including on-chain contracts 201c, on-chain contracts 202c, ..., on-chain contracts 230c, these on-chain
  • the relevant information of the contract can be stored in the node memory 20f of the consensus node 20c, and can also be stored in other storage modules of the consensus node 20c; wherein, each contract on the chain can use a unique contract identifier (such as an identification number or name)
  • the contract identifier corresponding to the on-chain contract 201c is the contract identifier 1c
  • the contract identifier corresponding to the on-chain contract 210c is the contract identifier 10c
  • the contract identifier 10c the contract
  • each local contract can establish an association relationship with one or more contracts on the chain;
  • the mapping relationship between them is used to characterize the association relationship between the two, and these mapping relationships can be stored in the form of a relational mapping table in the node memory or other storage modules of consensus nodes and related business nodes. Please refer to FIG. 2a again. As shown in FIG.
  • a relationship mapping table 20e is stored in the node memory 20d of the service node 20b, and one or more mapping relationships can be stored in the relationship mapping table 20e; for example, contract identifier 3c and contract identifier 1b
  • the mapping relationship between on-chain contract 203c and local contract 201b; the mapping relationship between contract identifier 20c and contract identifier 2b indicates that on-chain contract 220c is associated with local contract 202b.
  • a relationship mapping table 20e may also be stored in the node memory 20f of the consensus node 20c.
  • relationship mapping table 20e only includes the mapping relationship related to the service node 20b, and the node memory 20f may also store To store mapping relationships related to other service nodes, the embodiment of the present application only uses the relationship mapping table 20e as an example for illustration.
  • business object A can send a contract invocation request B (referred to as an initial contract invocation request) to a service node 20b through a user terminal 20a (referred to as a first user terminal); wherein, the contract invocation request B can be used for Execute the transaction business initiated by business object A (for example, business object A transfers virtual assets equal to the amount of assets to be transferred from business object A to business object F, such as transferring 500 yuan), business object A can select the already deployed chain through the user terminal 20a
  • the contract (called the target on-chain contract, for example, the on-chain contract 210c), that is, the contract identifier of the on-chain contract (called the first contract identifier, for example, the contract identifier 10c) can be specified in the contract call request B.
  • the contract identifier 10c (called the first contract identifier) of the on-chain contract 210c and the contract identifier 5b of the local contract 205b (referred to as the second contract identifier) there is a mapping relationship 201e (referred to as the first mapping relationship).
  • the service node 20b When the service node 20b receives the contract invocation request B sent by the user terminal 20a, it can query the contract identifier having a mapping relationship 201e with the contract identifier 10c in the relationship mapping table 20e, and then can determine the queried contract identifier 5b as the second contract identifier 5b ID, and the local contract 205b can be obtained based on the contract ID 5b.
  • the business node 20b can call the local contract 205b to execute the local business indicated by the above transaction business (for example, check in advance whether the remaining asset amount of the business object A meets the transfer condition, that is, whether the remaining asset amount of the business object A is greater than or equal to the value to be transferred asset amount (such as 500 yuan)), get the transaction execution result C (called the local transaction execution result), and then determine the contract call request D (called the local transaction execution result) for sending to the consensus node based on the transaction execution result C and the contract call request B is the target contract call request), the final service node 20b can forward the contract call request D to the consensus node (such as the consensus node 20c) through the routing node in the routing network, or the service node 20b can directly forward the contract call request D to the consensus node node.
  • the contract call request D still includes the contract identifier 10c.
  • the service node before one or more contract call requests are forwarded from the service node to the core chain (ie, the core consensus network), the service node can execute the corresponding local contract to pre-check these contract call requests And filtering (called pre-check processing), only the contract call request that meets the on-chain conditions will be finally forwarded to the core chain for processing.
  • the core chain ie, the core consensus network
  • the contract invocation request D may be a request in the contract invocation request B that satisfies the transfer condition (referred to as the on-chain condition); for another example, the business node 20b checks that the remaining assets of the business object A are greater than 500 yuan, That is, if the contract call request B meets the transfer conditions, the contract call request B can be forwarded to the consensus node 20c as the contract call request D, and then the consensus node 20c will perform the operation of transferring 500 yuan to the business object F; on the contrary, if the business object A’s If the remaining asset amount is less than 500 yuan, that is, the contract call request B does not meet the transfer conditions, then the service node 20b can generate request failure information (for example, information for prompting that the remaining asset amount of the business object A is insufficient) according to the transaction execution result C, and send The request failure information is returned to the user terminal 20a.
  • request failure information for example, information for prompting that the remaining asset amount of the business object A is insufficient
  • the local services indicated by different transaction services may also include different content, such as information completion processing, statistical classification processing, etc., which are not limited in this embodiment of the application .
  • the consensus node 20c can obtain the on-chain contract 210c based on the contract identifier 10c in the contract invocation request D, and then can invoke the on-chain contract 210c to execute the above transaction
  • the consensus business indicated by the business for example, the transfer business of transferring 500 yuan from business object A to business object F can be executed), so as to obtain the transaction execution result E (called the on-chain transaction execution result).
  • the block chain 20g shown in Figure 2b can be the same block chain shared by each consensus node in the core consensus network where the consensus node 20c is located, and each consensus node can be in the block chain 20g
  • the block chain 20g may include multiple (for example, 101) blocks, which are respectively block 1, block 2, ..., block 100 and target Blocks, for example, the block 1 can be called the genesis block of the block chain 20g.
  • the target block in the block chain 20g contains the transaction execution result E.
  • the consensus node 20c is a consensus node with the function of generating blocks in the core consensus network
  • the consensus node 20c can generate a block to be added to the block chain 20g according to the transaction execution result E, and treat the block on the chain
  • the block is processed on the chain, that is, the consensus node 20c can send the block to be chained to other consensus nodes in the core consensus network, so that other consensus nodes can perform block consensus on the block to be chained, and obtain the block for returning to the consensus node.
  • the consensus node 20c can use the block to be uploaded as the target block to write it into the block chain 20g shown in Figure 2b, and also That is, the target block is set as the next block of block 100.
  • the consensus node 20c can call the on-chain contract 210c to perform the transfer business, and modify the remaining assets of business object A and business object F, and generate chain block, and add the block to be linked to the blockchain 20g, so as to complete the writing of the latest remaining assets of the business object A and the latest remaining assets of the business object F into the blockchain 20g.
  • the consensus node 20c can return the transaction execution result (such as the successful transfer result) to the user terminal 20a and the user terminal 20h bound to the business object F through the business node 20b, and the business object A can query its own remaining assets through the user terminal 20a , the displayed remaining asset volume is the latest remaining asset volume of business object A; when business object F inquires its own remaining asset volume through the user terminal 20h, the presented remaining asset volume is the latest remaining asset volume of business object F .
  • the smart contract-based data processing method provided in the embodiment of the present application can be applied to business scenarios such as transferring virtual assets (such as game gold coins, game diamonds, electronic bills) or transferring electronic documents (such as electronic contracts, electronic documents), or Other business scenarios for checking and calculating in advance through local contracts. Since the business node can call the local contract before the consensus node to process the received contract call request accordingly, there is no need to backlog all the operations related to the contract call request on the consensus node, which can reduce the data of the consensus node. Handle pressure, reduce the load on consensus nodes, and improve the overall transaction processing efficiency of the blockchain network.
  • business scenarios such as transferring virtual assets (such as game gold coins, game diamonds, electronic bills) or transferring electronic documents (such as electronic contracts, electronic documents), or Other business scenarios for checking and calculating in advance through local contracts. Since the business node can call the local contract before the consensus node to process the received contract call request accordingly, there is no need to backlog all the operations related to the contract call request on the consensus node, which can reduce
  • FIG. 3 is a schematic flowchart of a smart contract-based data processing method provided by an embodiment of the present application.
  • the method can be executed by a service node in the service network, and the service node can be a server connected to the service network, or a user terminal connected to the service network.
  • the service The specific form of the node is not limited.
  • the service node may be a service node deployed with a target local contract in the service network 1-1 shown in FIG. 1 , for example, node 110a.
  • the smart contract-based data processing method may at least include step S101-step S103, each step will be described below.
  • Step S101 obtain the initial contract call request for executing the transaction business; the initial contract call request includes the first contract identifier used to call the contract on the target chain; both the consensus node and the business node store the first contract identifier and the second contract identifier The first mapping relationship between the identifiers.
  • the target local contract is deployed on the specified business node in the business network
  • the target on-chain contract is deployed on the consensus node of the core consensus network.
  • the core consensus network is independent of the business network. Perform network isolation.
  • the service node can receive the transaction request sent from the user terminal (for example, a contract deployment request or an initial contract call request), and the consensus node can receive the transaction request forwarded by the service node, where the transaction request can be the user terminal according to the business object The request generated by the initiated transaction business.
  • the user terminal that sends the initial contract invocation request can be called the first user terminal, and the user terminal that sends the contract deployment request is called the second user terminal; where the first user terminal and the second user terminal It can be the same user terminal or different user terminals.
  • the business object can deploy one or more local contracts on the business node by initiating a contract deployment request.
  • deploying the target local contract as an example.
  • the business object can initiate a contract deployment request through the second user terminal.
  • the business object can deploy the target local contract on the specified business node; where the specified business node Can include one or more business nodes in the core consensus network.
  • the business object can uniquely identify the smart contract by specifying the contract identifier (eg, ID or name) of the smart contract, and the blockchain node (business node or consensus node) can call the corresponding smart contract through the contract identifier.
  • the contract identifier corresponding to the contract on the target chain is the first contract identifier
  • the contract identifier corresponding to the target local contract is the second contract identifier.
  • the business object can also specify the contract identifiers of one or more on-chain contracts associated with the target local contract in the contract deployment request; wherein, the one or more on-chain contracts include the target on-chain contract.
  • the first mapping relationship between the first contract identifier and the second contract identifier can be stored in the node memory of the consensus node and the designated service node or other storage modules (for example, hard disk, storage or database, etc.). It can be understood that the process of deploying other local contracts is consistent with the process of deploying the target local contract. For the implementation of deploying local contracts, refer to step S201 corresponding to subsequent FIG. 4 and step S401 corresponding to FIG. 7 .
  • the business object can initiate an initial contract invocation request for executing transaction services (for example, asset transfer service, file transfer service, query service, storage service, etc.) through the first user terminal, and the initial contract invocation request can carry the business object
  • transaction services for example, asset transfer service, file transfer service, query service, storage service, etc.
  • the initial contract invocation request can carry the business object
  • the first contract identifier corresponding to the contract on the specified target chain the first user terminal can send the initial contract call request to one or more service nodes deployed with the target local contract, the one or more service nodes receive
  • the target local contract associated with the target on-chain contract can be called according to the initial contract call request, and the implementation method of calling the target local contract can refer to step S102.
  • only one of the service nodes is used as an example for the following steps.
  • the first user terminal and the second user terminal may be different user terminals.
  • the second user terminal is user terminal A
  • the first user terminal is user terminal B.
  • the service node may deploy The successful result is sent to user terminal A; the service node can also send the successful deployment result to user terminal B, so that user terminal B can send an initial contract call request to the service node based on the successful deployment result.
  • user terminal A after receiving the successful deployment result sent by the service node, user terminal A can send a notification that the service node has been deployed to user terminal B, and then user terminal B can send an initial contract call request to the service node.
  • Step S102 based on the first contract identifier and the first mapping relationship, query the second contract identifier, determine the target local contract based on the second contract identifier, execute the local business indicated by the transaction service by calling the target local contract, and obtain the local transaction execution result.
  • local contract information is stored in the service node (for example, in the node memory), and the local contract information refers to information related to the local contract (including the target local contract) deployed on the service node; wherein, the local contract information It can include the mapping relationship between the contract identifiers of these local contracts and the contract identifiers of the associated on-chain contracts.
  • local contract A1 and local contract A2 are deployed on business node A, and the local contract A1 and the specified on-chain contract B1 is associated, the local contract A2 is associated with the specified on-chain contract B2, and both the on-chain contract B1 and the on-chain contract B2 are deployed on the consensus node B, then the business node A can store the local The mapping relationship between the contract identifier of contract A1 and the contract identifier of contract B1 on the chain, and the mapping relationship between the contract identifier of local contract A2 and the contract identifier of contract B2 on the chain.
  • consensus node B can also These mappings are stored in memory.
  • mapping relationship may be stored in a relationship mapping table, where the relationship mapping table includes a first mapping relationship between the first contract identifier and the second contract identifier.
  • An optional form of the relationship mapping table can refer to the relationship mapping table 20e shown in FIG. 2a above.
  • other forms can also be used to store the above mapping relationship, which is not limited in this application.
  • the business node can query the contract ID that has the first mapping relationship with the first contract ID in the relationship mapping table, and then can determine the queried contract ID as the second contract ID associated with the target chain contract.
  • the contract identifier can be determined as the target local contract.
  • a local contract has a unique mapping relationship with an on-chain contract
  • the relationship mapping table can include one or more mapping relationship columns, and a mapping relationship column can be used to store a mapping relationship; therefore, the business node can use the relationship mapping table
  • the mapping relationship column in which the first contract identifier and the first mapping relationship are stored is determined as the target mapping relationship column, and the contract identifier different from the first contract identifier stored in the target mapping relationship column may be determined as the second contract identifier.
  • the service node 20b can query the contract identifier 5b having the mapping relationship 201e with the contract identifier 10c in the relationship mapping table 20e based on the contract identifier 10c and the mapping relationship 201e in the contract invocation request B.
  • the local contract information can also include the local contract function corresponding to the target local contract, and the business node can execute the local business indicated by the transaction business by calling the local contract function; in the embodiment of this application, the business node can first call the target The local contract can read the local contract function in the local contract information, and then the local business data associated with the local business can be accessed from the node memory of the business node through the local contract function, and then the transaction business can be executed through the local business data Indicated local business, get local transaction execution result.
  • the local contract information can also include contract codes
  • the business object can deploy the contract code (that is, the contract program statement) written by the business object in the target local contract.
  • the contract program statement of the business the contract code can include the contract function name corresponding to the local contract function and the function statement corresponding to the contract function name, and the business node can call the target local contract to obtain the contract corresponding to the local contract function in the local contract information The function name, and then the function statement corresponding to the contract function name can be obtained.
  • the function statement can indicate the storage location of the local service data associated with the local service in the service node (for example, in the node memory), that is, the service node can send data to the node memory of the service node through the function statement
  • the read request can further obtain the local service data on the storage location, and the local service data can be used to execute the local service indicated by the transaction service.
  • the local business data can refer to the data related to the business object served by the business node, and the local business data can come from the relevant user terminal, or from other blockchain nodes in the blockchain network ( For example, other business nodes participating in the transaction business, or the superior node of the business node, or the consensus node in the core consensus network).
  • local business refers to the business that business nodes can use local business data to perform, for example, check whether a contract call request meets the on-chain conditions (called pre-check processing, such as checking whether the contract call request meets the relevant policies of the province ), or complete some information unique to business nodes (called information completion processing, such as assigning invoice numbers, completing official seals or signatures, etc.), or counting and categorizing relevant transaction data, and according to the specified Format output (called statistical classification processing, such as counting the number of transfer transactions performed by a certain company on the day), this application does not limit this.
  • pre-check processing such as checking whether the contract call request meets the relevant policies of the province
  • information completion processing such as assigning invoice numbers, completing official seals or signatures, etc.
  • statistical classification processing such as counting the number of transfer transactions performed by a certain company on the day
  • the local contract function can include a pre-check function associated with the local business, and the service node can access the The first local business data, and then based on the first local business data, the request parameter in the initial contract call request can be pre-checked; at this time, the local business data includes the first local business data.
  • relevant request parameters can be generated, and the business node can search the historical transaction information of the electronic note in its own node memory, for example, to determine whether the account of enterprise A exists This electronic bill, whether the accounts of enterprise A and enterprise B are wrong, the source of this electronic bill owned by enterprise A, whether the number of the electronic bill is judged is wrong, etc. If the pre-detection result indicates that the request parameter meets the on-link condition indicated by the local service, the request parameter meeting the on-link condition indicated by the local service can be determined as a legal request parameter, and then the legal request parameter can be used as the local service corresponding The local transaction execution result of .
  • the request parameters that do not meet the uplink conditions indicated by the local service can be determined as illegal request parameters, and the illegal request parameters are used as The local transaction execution result corresponding to the local business, and then the business node can generate request failure information according to the illegal request parameter, and then return the request failure information to the first user terminal that sent the initial contract call request; that is, the business node can send Contract call requests that do not meet the on-chain conditions are filtered or intercepted.
  • the request failure information is used to indicate that the initial contract call request is rejected, and may include specific reasons for rejection, error messages, and the like.
  • pre-checking the initial contract call request on the business node can intercept some malicious or problematic requests. On the one hand, it can reduce the amount of calculation on the consensus node, reduce the data processing pressure of the consensus node, and reduce the consensus The number of contract calls requested by the node; on the other hand, when the consensus node does not have the relevant judgment ability, the business node can use its own local business data to make judgments.
  • the business node can be a business node with target area attributes (such as province, city, district, etc.), and the consensus node can be the superior node of the business node.
  • Target area attributes such as province, city, district, etc.
  • Policies associated with the attributes of the target area such as national policies, city policies, district policies, etc.).
  • the business node in province A can pre-check whether the contract call request B (that is, the initial contract call request) for issuing electronic bills meets the relevant policies of province A, and only the contract call request B meets the relevant policies of province A (for example, for single Only when there is no limit policy on the amount of a single transaction), the business node in province A will forward the contract call request B to the national chain composed of consensus nodes for subsequent processing.
  • the contract call request B that is, the initial contract call request
  • the relevant policies of province A for example, for single Only when there is no limit policy on the amount of a single transaction
  • the on-chain condition can be that the transaction initiator has enough remaining assets, that is, when the transaction initiator's remaining assets are greater than or equal to the amount of assets to be transferred, the business node can use the The transfer contract call request C is forwarded to the consensus node, and the consensus node continues to perform the transfer operation, otherwise, the business node will intercept the contract call request C.
  • the request parameters may refer to parameters related to transaction services, and the specific content contained in the request parameters is different for different transaction services.
  • the request parameters may include parameters related to the flow logic of the entire life cycle of the electronic bill; for example, electronic bill issuance information, electronic bill application information, electronic bill status, and data access rights , keywords on the electronic bill, etc.
  • the request parameters can include the remaining assets of the transaction initiator, signature information, the amount of assets to be transferred, the identifier of the transaction recipient (such as the account number of the transaction recipient), etc.
  • the request parameters can include official seal information, signature information, status information, etc. of the electronic file.
  • the local contract function can include the information completion function associated with the local business, and the business node can access the local business from the business node (for example, in the node memory) through the information completion function
  • the associated second local business data can then complete the request parameters in the initial contract call request based on the second local business data, and then use the completed request parameters as the local transaction corresponding to the local business Execution result; at this time, the local service data includes the second local service data.
  • the local taxation bureau can be used as a business node. When issuing an electronic bill, the business node can complete some information only available to the civil taxation bureau, such as assigning the invoice number.
  • the district court serves as a business node to transfer an electronic document to the Supreme Court (ie consensus node), it can complete the local court's own official seal or signature and other information.
  • the blockchain network can store part of the data originally stored on the consensus node on the business node, so as to use the data or unique capabilities of the business node itself (such as the ability that the contract on the chain does not have) ) to do information completion (that is, data completion), which can reduce multi-party interactions, reduce the storage pressure and calculation pressure of consensus nodes, and can also improve the privacy and security of business node data.
  • Step S103 based on the local transaction execution result and the initial contract call request, send the target contract call request to the consensus node, the target contract call request is used for the consensus node to obtain the contract on the target chain based on the first contract identifier, and execute the contract by calling the contract on the target chain The consensus business indicated by the transaction business.
  • the blockchain network where the business network and the core consensus network are located may also include a routing network for network isolation, and the business node may determine the method for sending The target contract call request to the consensus node, and then the target contract call request can be forwarded to the consensus node.
  • step S102 In conjunction with the above step S102, the following still uses the pre-check processing and information completion processing as examples for illustration.
  • the business node can determine the initial contract call request containing the legal request parameter as the target contract call request; that is, when the initial contract call request When the request parameters in meet the on-chain conditions indicated by the local business, the initial contract call request and the target contract call request are the same contract call request.
  • the service node can intercept the initial contract call request, and can return request failure information to the first user terminal. It can be understood that if the number of initial contract call requests is one or more, the service node may determine the contract call request that meets the on-chain condition among the one or more initial contract call requests as the target contract call request.
  • the service node can forward the target contract call request to the consensus node through the routing nodes in the routing network; in addition, the service node can also directly send the target contract call request to the consensus node.
  • the business node can generate the target contract call request according to the local transaction execution result and the initial contract call request, and the target contract call request can include the request parameters after the information completion; among them, the information complement
  • the completed request parameters can include the original request parameters in the initial contract call request and the updated request parameters generated after information completion processing (that is, the request parameters with the business node's own information added); that is, the business node can Add the updated request parameters to the request parameters of the initial contract call request, so that the target contract call request containing the information-completed request parameters can be obtained, and then the target contract call request can be forwarded to the consensus through the routing nodes in the routing network
  • the node or directly sends the target contract call request to the consensus node without going through the routing node. It can be understood that at this time, the initial contract call request and the target contract call request are different contract call requests.
  • user terminal X1 when issuing electronic bills, user terminal X1 (referred to as the first user terminal) may initiate a contract call request Y1 (referred to as an initial contract call request) for issuing electronic bills, and the contract call request Y1 includes request parameters Z1 ;
  • the business node X2 After the business node X2 receives the contract call request Y1, it can assign an invoice number to the electronic bill based on its local business data, and then generate a request parameter Z2 (called an updated request parameter) according to the invoice number, and send the request parameter Z2 Added to the request parameter Z1 of the contract call request Y1, so that the request parameter Z3 (called the request parameter after information completion) can be obtained; here, the contract call request Y1 containing the request parameter Z3 can be called the contract call request Y2 ( called the target contract call request); then, the business node can send the contract call request Y2 to the consensus node X4 through the routing node X3.
  • the contract call request Y1 referred to as an
  • the business node can also update the relevant fields in the initial contract call request according to the local transaction execution result, and obtain the target contract call request containing the updated field, and then can send the target contract call request (through the routing node Or not through the routing node) to the consensus node, so that the consensus node can call the contract on the target chain to parse the update field into an updated request parameter.
  • the business nodes in the business network can correspond to different levels; for example, the upper-lower relationship (such as county level, city level, provincial level), after the lower-level nodes receive the initial contract call request , the local contract deployed on the lower node can be invoked to obtain the first contract invocation request, and then the first contract invocation request can be sent to the upper-level node, and the upper-level node can invoke the local contract deployed on the upper-level node to obtain the first contract invocation request 2.
  • Contract call request; and so on, the contract call request obtained by the last level business node can be used as the target contract call request sent to the consensus node (with the highest level).
  • the consensus node after the consensus node receives the target contract call request, it can obtain the contract on the target chain based on the first contract identifier in the target contract call request, and then call the contract on the target chain to execute the consensus indicated by the transaction business. business.
  • the consensus node executing the consensus service please refer to step S302 corresponding to the subsequent FIG. 6 .
  • the contract on the target chain can be a contract that has been successfully deployed on the consensus node, or it can be an empty contract on the chain; in the embodiment of this application, when the contract on the target chain is an empty contract, the consensus node will not Any contract on the chain will be called.
  • the business object can also directly specify the target local contract in the contract call request through the first user terminal, that is, the first user terminal can send the contract call request containing the second contract identifier to the target local contract deployed.
  • the business node of the contract which can obtain the target local contract based on the second contract identifier, and then call the target local contract to execute the local business, so as to obtain the local transaction execution result, and then return the local transaction execution result to the first user terminal .
  • a contract call request B for calculating the tax amount can be initiated through the user terminal A1 (referred to as the first user terminal), and in the contract call request B
  • the contract identifier C1 (called the second contract identifier) corresponding to the local contract C (called the target local contract) related to tax calculation can be specified
  • the user terminal A1 can send the contract call request B to the service node A2
  • the service node A2 can obtain the local contract C through the contract identifier C1
  • the local business data D related to tax calculation from the node memory of the business node A2 through the local contract C (for example, tax policy, tax formula, income of business object A, Various expenditures, the area of cultivated land occupied, etc.)
  • the final business node A2 can calculate the tax payable E of the business object A based on the local business data D (called the local transaction execution result), and return the tax payable E to the user terminal A1.
  • the contract calling method provided by the embodiment of the present application can reduce the error rate of the contract calling, and facilitate the management of the smart contract, thereby improving the calling efficiency of the smart contract.
  • each province has its own different policies, and the local contracts deployed by the business nodes in province A only serve province A, which can solve the problem of people in province B mistakenly calling local contracts in province A.
  • FIG. 4 is a schematic flowchart of a smart contract-based data processing method provided by an embodiment of the present application.
  • the smart contract-based data processing method can be executed by service nodes in the service network.
  • the method may at least include step S201-step S203, each step will be described respectively below.
  • Step S201 obtaining a contract deployment request sent by a second user terminal for deploying one or more preset local contracts, and forwarding the contract deployment request to a consensus node.
  • the business object can initiate a contract deployment request for deploying one or more preset local contracts through the second user terminal; wherein, the contract deployment request can be used to add a contract to each preset local contract function (for example, the local contract function corresponding to the target local contract) to achieve the corresponding function, and can also be used to specify the business node that can execute each preset local contract in the business network (called the business node that deploys the preset local contract) ) corresponding to the node ID; in addition, the contract deployment request is also used to specify the associated on-chain contract for the preset local contract (it can be an already deployed on-chain contract or an empty on-chain contract on the consensus node).
  • the contract deployment request can be used to add a contract to each preset local contract function (for example, the local contract function corresponding to the target local contract) to achieve the corresponding function, and can also be used to specify the business node that can execute each preset local contract in the business network (called the business node that deploys the preset local contract) ) corresponding to
  • the information specified by the contract deployment request can be represented by the key field of the contract, and the second user terminal can generate a corresponding contract deployment request based on the key field of the contract, and then send the contract deployment request to the business Any service node in the network.
  • the service node after the service node receives the contract deployment request, it can forward the contract deployment request to any consensus node in the core consensus network through the routing node in the routing network, or directly send The contract deployment request is sent to any consensus node.
  • the consensus node After the consensus node receives the contract deployment request, it can perform consensus on the contract deployment request.
  • the consensus node can generate one or more local contract summaries corresponding to the contract deployment request Information, the local contract summary information includes information corresponding to each preset local contract, and then the local contract summary information can be stored in the consensus node (for example, in the node memory); at this time, one or more The preset local contract is successfully deployed on the core chain.
  • one or more preset local contracts include the target local contract; correspondingly, the summary information of the local contract generated by the consensus node includes information corresponding to the target local contract.
  • the implementation of the consensus node consensus on the contract deployment request and the generation of local contract summary information can refer to the subsequent step S401 corresponding to FIG. 7 .
  • the local contract summary information can be stored in the consensus node (for example, in the node memory) in the form of table storage, key-value storage (Key-Value storage, KV storage), file storage, etc. This application does not do this limited.
  • the local contract summary information can be stored in the form of key-value storage, so that when the local contract is subsequently synchronized or called, the set Key (for example, the contract of the contract on the chain in the relationship mapping table ID) to quickly query the corresponding Value (for example, the contract ID of the local contract in the relational mapping table).
  • FIG. 5a-FIG. 5c are schematic diagrams of a data processing scenario provided by an embodiment of the present application.
  • the user terminal 30a (referred to as the second user terminal) initiates a contract deployment request A, and the contract deployment request A is used to deploy two local contracts (referred to as preset local contracts), which are local contracts L1 And the local contract L2; among them, the contract identifier of the local contract L1 is "Local_A", and the local contract L1 is associated with the on-chain contract C1 whose contract identifier is "Invoice”; the contract identifier of the local contract L2 is "Local_B", and the local contract L2 Associated with the on-chain contract C2 whose contract ID is "collaboration”.
  • preset local contracts which are local contracts L1 And the local contract L2
  • the contract identifier of the local contract L1 is "Local_A”
  • the local contract L1 is associated with the on-chain contract C1 whose contract identifier is "Invoice”
  • the contract C1 on the chain can be used to handle business related to invoices (ie, electronic bills), such as invoice issuance, invoice reimbursement, etc.; and the contract C2 on the chain can be used to handle transactions between different business objects/enterprises/institutions/units Collaborative business (such as multi-party collaborative processing of electronic documents), for example, business object 1 and business object 2 need to sign a contract together, then call the contract C2 on the chain, and the contract signed by business object 1 can be transferred to business object 2 to continue signing .
  • invoices ie, electronic bills
  • invoice reimbursement issuance
  • Collaborative business such as multi-party collaborative processing of electronic documents
  • the user terminal 30a can send the contract deployment request A to the service network 30b, wherein the service network 30b can include a service node 301b and a service node 302b; it can be understood that the service network 30b can also include other The service nodes in Fig. 5a, for example, service node 303b, ..., service node 30mb.
  • Any service node (for example, service node 301b) in the service network 30b can obtain the contract deployment request A; in this application embodiment, if the service node 301b successfully receives the contract deployment request A, the service node 301b can send the contract
  • the deployment request A is forwarded to the core consensus network 30c, wherein the core consensus network 30c may include multiple consensus nodes not shown in Figure 5a, such as consensus node 301c, consensus node 302c, ..., consensus node 30nc, and Each consensus node can obtain the contract deployment request A.
  • the consensus node 301c can broadcast the contract deployment request A to other consensus nodes in the core consensus network 30c , so that each consensus node can verify the contract deployment request A (for example, terminal signature verification, deployment authority verification, etc.), when the verification is successful (called consensus passed), the consensus node 301c can generate a local contract based on the contract deployment request A contract summary information 30d, and store the local contract summary information 30d in the node memory of the consensus node 301c; it can be understood that the same data as the local contract summary information 30d is also stored in the node memory of other consensus nodes.
  • each consensus node can verify the contract deployment request A (for example, terminal signature verification, deployment authority verification, etc.), when the verification is successful (called consensus passed)
  • the consensus node 301c can generate a local contract based on the contract deployment request A contract summary information 30d, and store the local contract summary information 30d in the node memory of the consensus node 301c; it can be understood that the same data as the local contract summary information 30d is also
  • the local contract summary information 30d may include a summary contract information table 30e and a summary relationship mapping table 30f.
  • both the summary contract information table 30e and the summary relationship mapping table 30f are stored in the form of key-value storage.
  • the summary contract information table 30e can store the corresponding contract information of the local contract L1 and the local contract L2, for example, the corresponding contract identifier, contract code (including the code of the contract function), the contract identifier of the associated on-chain contract, and the execution Identification list;
  • the execution identification list (referred to as the executable node identification list) may include the node identification corresponding to the business node that specifies the deployment of the local contract, for example, the contract deployment request A specifies that the local contract L1 is deployed on the business node 301b and the 302b, at this time, the execution identifier list corresponding to the local contract L1 may include the node identifier ID1 corresponding to the service node 301b and the node identifier ID2 corresponding to the service node 302b; and when the contract deployment request A specifies that the local contract L2 is deployed on the service node 303b
  • the execution identification list corresponding to the local contract L2 may include the node identification ID3 corresponding to the service node
  • the summary relationship mapping table 30f can store the mapping relationship related to the local contract L1 and the local contract L2.
  • the mapping relationship between the contract identifier "invoice” and the contract identifier "Local_A” can be stored in ; in addition, in order to facilitate subsequent contract synchronization, the node identifier (such as ID1, ID2) of the business node deployed with the local contract L1 can also be combined with The mapping relationship between the contract identifiers "Local_A" is also stored in the summary relationship mapping table 30f.
  • Step S202 send a contract synchronization request to the consensus node, so that the consensus node can reach a consensus on the contract synchronization request; when the contract synchronization request consensus is passed, obtain the local contract information sent by the consensus node; store the local contract information in the node memory of the business node In , the target local contract is deployed based on the local contract information.
  • any business node in the business network can transfer to the consensus node in the core consensus network through the routing node in the routing network Send a contract synchronization request, or directly send the contract synchronization request to the consensus node in the core consensus network without routing nodes, so as to synchronize the contract information corresponding to the preset local contract that needs to be deployed on the business node; the core consensus network After receiving the contract synchronization request, any one of the consensus nodes can broadcast the contract synchronization request to other consensus nodes, so that the consensus nodes can agree on the contract synchronization request; wherein, the contract synchronization request includes the business node corresponding to Node ID.
  • the consensus node can obtain the local contract information related to the business node ID from the local contract summary information stored in its node memory based on the business node ID, and then can use the local contract information Return (or directly return) to the service node via the routing node.
  • the service node can store the received local contract information in the node memory of the service node, and can create a corresponding preset local contract (for example, a target local contract) based on the local contract information.
  • the local contract information sent by the consensus node can be obtained.
  • the local contract information can include the target local contract and the information of other local contracts also deployed on the business node; Therefore, the local contract information may include a relationship mapping table and a local contract information table; wherein, the relationship mapping table may store the first mapping relationship between the first contract identifier and the second contract identifier, and the second contract identifier and the service node
  • the second mapping relationship between identifiers (that is, the node identifier of the service node), and the local contract information table may include a contract information column corresponding to the target local contract.
  • the service node that obtains and forwards the contract deployment request can be called the first service node (for example, the service node 301b in Figure 5a), and the service node that sends the contract synchronization request (for example, , service node 301b and service node 303b) in Fig. 5b are referred to as the second service node, and both the first service node and the second service node can be any service node in the service network, the first service node and the second service node It can be the same service node or different service nodes.
  • the consensus node (for example, consensus node 301c) in the core consensus network 30c is based on the contract deployment request forwarded by the service node 301b A generates local contract summary information 30d; in addition, service nodes (for example, service node 301b, service node 303b) in the service network 30b can synchronize relevant contract information locally.
  • the business node 301b sends a contract synchronization request B carrying the node identifier ID1 to the core consensus network 30c, and the consensus nodes in the core consensus network 30c can agree on the contract synchronization request B.
  • any consensus node (such as Consensus node 301c) can query the information related to node identifier ID1 in local contract summary information 30d; column as a relationship mapping table 301f; wherein, the relationship mapping table 301f stores the mapping relationship between the node identifier ID1 and the contract identifier "Local_A", and the mapping relationship between the contract identifier "invoice” and the contract identifier "Local_A”; furthermore, The consensus node can query the contract information column with the contract identifier "Local_A" in the summary contract information table 30e based on the contract identifier "Local_A", and use the contract information column as the local contract information table 301e; wherein, the local contract information table 301e stores There is contract information related to the local contract L1.
  • the consensus node 301c can return the relationship mapping table 301f and the local contract information table 301e as local contract information to the service node 301b, and the service node 301b can deploy the local contract L1 based on the relationship mapping table 301f and the local contract information table 301e.
  • the business node 303b can also send the contract synchronization request C carrying the node ID ID3 to the core consensus network 30c, and finally can obtain the relationship mapping table 302f and the local contract information table 302e, and then can based on the relationship mapping table 302f and the local contract information table
  • the information table 302e deploys the local contract L2. It can be understood that after a similar process, the local contract L1 and the local contract L2 can also be deployed on the service node 302b.
  • Step S203 obtaining the initial contract call request for executing the transaction business; querying the contract identifier having the first mapping relationship with the first contract identifier in the relationship mapping table, and determining the queried contract identifier as being associated with the contract on the target chain
  • the second contract identifier of the second contract identifier determine the local contract corresponding to the second contract identifier as the target local contract, call the target local contract to execute the local business indicated by the transaction business, and obtain the local transaction execution result; based on the local transaction execution result and the initial contract call Request, determine the target contract call request to be sent to the consensus node, and forward the target contract call request to the consensus node.
  • step S203 is similar to the implementation process of step S103, and will not be repeated here.
  • the service node 301b has successfully deployed the local Contract L1 (called the target local contract), and then the user terminal 30g (called the first user terminal) can call the contract call request D (called the initial contract call) carrying the contract identifier "invoice" (called the first contract identifier) request) to the service node 301b; thus, the service node 301b can find the contract identifier "Local_A” (called the second contract identifier) that has a mapping relationship with the contract identifier "invoice” in the relationship mapping table 301f, and then can according to the contract Identify "Local_A", find the contract information column with the contract identifier "Local_A" in the local contract information table 301e, so the local contract L1 can be obtained according to the contract identifier "Local_A", and the local contract L1 can be called in the contract information
  • the service node 301b can obtain the contract call request D' (called the target contract call request) based on the local transaction execution result R and the contract call request D. It can be understood that the contract call request D' and the contract call request D are the same at this time request.
  • the business node 301b can forward the contract call request D' to the core consensus network 30c for further processing, and the subsequent consensus nodes in the core consensus network 30c can call the on-chain contract C1 corresponding to the contract identifier "invoice" to perform business related to the invoice (for example, consensus business), so that the invoice data 30h can be obtained (called the transaction execution result on the chain); for example, it can include invoice 1, invoice 2, and invoice 3, and then the consensus node can pack the invoice data 30h into the block to be chained , and perform on-chain processing on the block to be on-chain.
  • the service node 302b deployed with the local contract L1 can also process the contract call request D through a similar process, and the service node 302b and the service node 301b are not aware of each other, and each independently executes the corresponding pre-check processing.
  • the local contract-based data processing method provided in the embodiment of the present application can be applied to a blockchain system with asymmetric nodes. And, in the embodiment of this application, the local contract can be executed on different levels of service nodes, and the service node can call the local contract before the consensus node to perform corresponding processing on the received contract call request (for example, pre-check processing , information completion processing, etc.), instead of backlogging all operations related to contract call requests on the consensus node, it can reduce the computing pressure of the consensus node and improve the overall transaction processing efficiency of the blockchain network.
  • the business node uses the data of its own node (called local business data), which can reduce the resource consumption caused by the local business data on the chain, and can reduce the resource consumption caused by the interaction of multiple parties. And it can improve data privacy and security, and reduce the storage pressure of consensus nodes.
  • FIG. 6 is a schematic flowchart of a smart contract-based data processing method provided by an embodiment of the present application.
  • the smart contract-based data processing method can be executed by a consensus node in the core consensus network.
  • the consensus node can be a server connected to the core consensus network, or a server connected to the core consensus network.
  • User terminals in the network there is no limitation on the form of consensus nodes.
  • the consensus node can be any node in the core consensus network shown in FIG. 1 above, and the target on-chain contract is deployed on the consensus node, for example, node 120a.
  • the consensus node method may at least include step S301-step S303, each step will be described below.
  • Step S301 acquiring a target contract invocation request for executing transaction business.
  • the consensus node can receive the target contract call request for executing the transaction business.
  • the target contract invocation request refers to the request determined by the business node in the business network independent of the core consensus network based on the local transaction execution result and the initial contract invocation request.
  • the local transaction execution result is that the business node invokes the target local contract to execute the transaction
  • the local service indicated by the service is obtained; the target local contract is obtained by the service node based on the second contract identifier; the second contract identifier refers to the service node based on the first contract identifier and the first mapping relationship, in the service node (for example, In the node memory), the contract identifier associated with the contract on the target chain is queried; the first contract identifier refers to the contract identifier used to call the contract on the target chain in the initial contract call request; the initial contract call request is used to execute the transaction business; The contract on the target chain is deployed on the consensus node; both the consensus node and the business node (for example, in the memory of the node) store the first mapping relationship between the first contract identifier and the second contract identifier; the second contract identifier is the deployment The contract identifier of the target local contract on the business node. For the data processing process performed by the business node based on the smart
  • Step S302 based on the first contract identifier in the call request of the target contract, call the contract on the target chain, and obtain the transaction execution result on the chain by calling the contract on the target chain to execute the consensus business indicated by the transaction business.
  • the consensus node can search multiple deployed on-chain contracts based on the first contract identifier, and then can determine the on-chain contract corresponding to the first contract identifier as the target on-chain contract; thus, the consensus node can call the target
  • the on-chain contract can read the on-chain contract function in the consensus node (for example, in the node memory), and then can access the consensus associated with the consensus business in the consensus node (for example, in the node memory) through the on-chain contract function Business data, and the consensus business indicated by the transaction business can be executed through the consensus business data, and the transaction execution result on the chain can be obtained.
  • the consensus business refers to the business performed by the consensus node (such as transferring virtual assets, issuing electronic bills, etc.), and the content of the consensus business is related to the transaction business, which is not limited in this application.
  • each consensus node can read data by accessing its own ledger during business execution.
  • step S303 a block to be added to the target blockchain is generated according to the transaction execution result on the chain, and the block is processed on the chain; the target blockchain is the blockchain to which the contract on the target chain belongs.
  • the consensus node can generate the target transaction data according to the transaction execution result on the chain, and can broadcast the target transaction data to other consensus nodes, and then each consensus node can put the target transaction data into its own transaction The pool is waiting for subsequent packaging processing.
  • a node among multiple consensus nodes can be selected as the first consensus node (also called a packaging node, a block node) through a consensus algorithm (for example, the leader produces blocks, turns out blocks, computing power competes to produce blocks, etc.). ), after the first consensus node obtains the bookkeeping right, it can extract a certain amount of transaction data from its transaction pool for packaging.
  • the first consensus node can broadcast the block to be linked to the second consensus node (that is, the core consensus network except the first nodes other than the consensus node), and then the second consensus node can carry out block consensus on the block to be chained, obtain the block consensus result, and return the block consensus result to the first consensus node, if the block consensus
  • the result is that the consensus is passed, and the first consensus node can add the block to be uploaded to the blockchain to which the contract on the target chain belongs.
  • FIG. 7 is a schematic flowchart of another smart contract-based data processing method provided by an embodiment of the present application. As shown in Figure 7, the smart contract-based data processing method can be executed by consensus nodes in the core consensus network. The smart contract-based data processing method may at least include step S401-step S403, each step will be described below.
  • Step S401 obtain the contract deployment request sent by the second user terminal forwarded by the service node, and perform consensus on the contract deployment request.
  • the contract deployment request consensus is passed, generate one or more preset local contracts corresponding to the contract deployment request.
  • Local contract summary information store the local contract summary information in the consensus node.
  • the second user terminal can send a contract deployment request for deploying one or more preset local contracts to the service node.
  • the service node After the service node successfully receives the contract deployment request, it can pass the contract deployment request through the The routing node forwards (or directly sends) to the consensus node, and then the consensus node can receive the contract deployment request.
  • the one or more preset local contracts include the target local contract.
  • the contract deployment request may include contract key fields corresponding to each preset local contract, wherein the contract key fields may include at least the following fields, which are Local Contract ID (Local Contract ID, also known as Local contract number), local contract version number (Version), local contract type (Type), local contract code (Code), local contract description information (Desc), associated contract identification (Chain Contract ID) and executable node identification list ( Executable Node List).
  • the local contract type can be used to mark the call timing of each preset local contract.
  • the local contract type of A type can be called before forwarding the data to the core consensus network, while the local contract type of B type
  • the contract can be called after the data is synchronized back to the business node;
  • the local contract description information can be used to describe the function of each preset local contract, of course, the key field of the contract may not include the local contract description information;
  • the associated contract identifier refers to the The contract identifier of the on-chain contract associated with each preset local contract on the node;
  • the list of executable node identifiers can include one or more executable node identifiers, and the executable node identifier refers to the The node ID corresponding to the node with execution authority (that is, the business node that needs to deploy each preset local contract specified by the business object), wherein the list of executable node IDs corresponding to the target local contract includes the business node ID.
  • the contract deployment request may also include general fields such as terminal signature information corresponding to the second user terminal (that is, the request initiator), terminal identifier, and request timestamp.
  • the consensus node can reach a consensus on both the terminal signature information and the terminal identification; here, the consensus node can recalculate the expected contract deployment request based on the private key used by the second user terminal to sign the contract deployment request. Signature information, and then compare the signature information with the terminal signature information. If the comparison results are consistent, it is determined that the contract deployment request has passed the security verification (called consensus pass), which means that the contract deployment request has not been passed during network transmission.
  • consensus pass security verification
  • the consensus node can reject the contract deployment request, and can return request rejection information to the second user terminal according to the comparison result; in addition, the consensus node can also obtain the deployment authority of the second user terminal through the terminal identification, and verify the deployment If it is recognized that the deployment authority is legal, it can be determined that the contract deployment request has passed the authority verification (called consensus pass), which means that the second user terminal has the authority to deploy the local contract to the specified business node, otherwise The consensus node can reject the contract deployment request, and can return request rejection information to the second user terminal according to the identification result. It can be understood that the deployment of local contracts in different business scenarios will have different levels, so the deployment authority of the second user terminal may be related to its level.
  • the consensus node when both the terminal signature information and the terminal identification pass the consensus, the consensus node can generate summary A relational mapping table, the summary relational mapping table may include a mapping relation column corresponding to each preset local contract, and each mapping relation column may be used to store the relationship between the local contract identifier and the associated contract identifier of the corresponding preset local contract Mapping relationship, and the mapping relationship between the local contract ID and the corresponding executable node ID.
  • the local contract L1 and the local contract L2 are two preset local contracts
  • the consensus node for example, consensus node 301c
  • the consensus node in the core consensus network 30c can deploy the request A according to the contract Generate a summary relationship mapping table 30f;
  • the summary relationship mapping table 30f can include the contract identifier "Local_A" (ie, the local contract identifier corresponding to the local contract L1) and the contract identifier "invoice” (ie, the associated contract identifier corresponding to the local contract L1)
  • the consensus node can generate a summary contract information table according to the local contract ID, local contract code, associated contract ID, and executable node ID list corresponding to all preset local contracts.
  • the summary contract information table can include each preset local contract The corresponding contract information column.
  • the consensus node (for example, consensus node 301c) in the core consensus network 30c can generate a summary contract information table 30e according to the contract deployment request A; the summary contract information table 30e stores the local contract L1 and the local contract L2 corresponding to contract information column; for example, the contract information column corresponding to the local contract L1 may include the contract identifier "Local_A" (that is, the local contract identifier), the contract code "XXXXXX" (that is, the local contract code), the contract identifier "invoice” (that is, the associated contract ID), executable node ID list [ID1, ID2].
  • the contract information column corresponding to the local contract L1 may include the contract identifier "Local_A" (that is, the local contract identifier), the contract code "XXXXXX" (that is, the local contract code), the contract identifier "invoice” (that is, the associated contract ID), executable node ID list [ID1, ID2].
  • the consensus node can determine the above summary relationship mapping table and summary contract information table as the local contract summary information corresponding to one or more preset local contracts (for example, the local contract summary information 30d shown in Figure 5a ), and then the local contract summary information can be stored in the node memory of the consensus node.
  • Step S402 obtain the contract synchronization request sent by the business node, and perform consensus on the contract synchronization request.
  • the contract synchronization request consensus is passed, based on the business node identification, obtain the local contract information in the local contract summary information, and send the local contract information to the business node.
  • the consensus node is used to synchronize the local contract to the business node that can execute the local contract; during synchronization, the consensus node can quickly calculate the local contract information by accessing the list of executable node identifiers when the local contract is deployed.
  • business nodes including: the consensus node can obtain the contract synchronization request sent by the business node, and the contract synchronization request can include the business node ID and node signature information of the business node, and then can reach a consensus on the node signature information and business node ID;
  • the consensus node can recalculate the expected signature information of the contract synchronization request based on the private key used by the business node to sign the contract synchronization request, and then compare the signature information with the node signature information.
  • the consensus node can reject the contract synchronization request and return it to the business node according to the comparison result request rejection information; in addition, the consensus node can also obtain the execution authority of the business node through the business node identifier, and identify the execution authority. Check whether the business node ID exists in the ID list.
  • the consensus node can reject the contract synchronization request, and can return request rejection information to the business node according to the identification result.
  • the consensus node when both the node signature information and the business node ID pass the consensus, the consensus node can query the summary relationship mapping table based on the business node ID, and the node ID that is queried has the same ID as the business node
  • the mapping relationship column is determined as a relationship mapping table. Therefore, the consensus node can determine the local contract identifier in the relationship mapping table as the key contract identifier, and based on the key contract identifier, query in the summary contract information table, and the contract identifier that is the same as the key contract identifier can be queried
  • the contract information column is determined as a local contract information table.
  • the consensus node can determine the relationship mapping table and the local contract information table as the local contract information, and can send the local contract information to the above-mentioned service node.
  • the relationship mapping table stores the first mapping relationship between the first contract identifier and the second contract identifier and the second mapping relationship between the second contract identifier and the service node identifier
  • the local contract information table may include the target local contract The corresponding contract information column.
  • the business node 301b can send a contract synchronization request B to the consensus node (such as the consensus node 301c) in the core consensus network 30c.
  • the consensus node 301c can first query the contract identifier "Local_A" (that is, the key contract identifier) that has a mapping relationship with the node identifier ID1 of the service node 301b in the summary relationship mapping table 30f, and can determine the mapping relationship column that stores the mapping relationship as The relationship mapping table 301f, and then can be queried in the summary contract information table 30e according to the contract identifier "Local_A", and the contract information column with the contract identifier "Local_A" is determined as the local contract information table 301e, and then the relationship mapping table 301f can be And the local contract information table 301e is returned to the service node 301b.
  • the contract identifier "Local_A" that is, the key contract identifier
  • a long-term connection can be established between the business node and the consensus node, and the consensus node can actively report to the business node with execution authority (that is, the executable node identifier stored in the local contract summary information) at regular intervals.
  • execution authority that is, the executable node identifier stored in the local contract summary information
  • business nodes push the corresponding local contract information, so that these business nodes can store the local contract information in the node memory of the business node, and deploy the specified local contract based on the local contract information.
  • the consensus node can delete the local contract information in its node memory to reduce the pressure on data storage; , may be accessed by other network terminals, causing the local contract information to be tampered with. Therefore, after the local contract information is successfully synchronized, the consensus node can still retain the local contract information in its node memory, and subsequent operations can be performed based on the stored local contract information. related verification.
  • the execution logic of the local contract can also be changed by initiating a request, which is similar to the process of deploying a local contract.
  • Step S403 obtain the target contract call request for executing the transaction business, call the contract on the target chain based on the first contract identifier in the call request of the target contract, and execute the consensus business indicated by the transaction business by calling the contract on the target chain to obtain the chain According to the execution result of the transaction on the chain, a block to be added to the target blockchain is generated according to the execution result of the transaction on the chain, and the block is processed on the chain.
  • step S403 For the implementation process of step S403, reference may be made to step S303 corresponding to the above-mentioned FIG. 6 , and repeated descriptions will not be repeated here.
  • FIG. 8 is a schematic flowchart of a data processing method provided in an embodiment of the present application.
  • the data processing method can be executed by any consensus node in the blockchain network.
  • the data processing method may include steps S1-S5, and each step will be described below.
  • Step S1 the remote procedure call (Remote Procedure Call, RPC) layer of each consensus node (for example, node 1 to node N) obtains the user request (for example, the target contract call request); wherein, the user request is also called a transaction; the RPC layer It is an external interface provided by each consensus node, which can be used to obtain the target contract call request.
  • RPC Remote Procedure Call
  • Step S2 each consensus node broadcasts transactions to each other, and one of the consensus nodes packs several transactions into a block (called a block to be uploaded), and broadcasts to other consensus nodes.
  • the selection of the block producing node (called the first consensus node) varies depending on the consensus algorithm, and can include the leader (Leader) producing blocks, taking turns to produce blocks, computing power competition to produce blocks, etc.
  • the blockchain consensus network in Figure 8 is the above-mentioned core consensus network.
  • Step S3 after each consensus node receives the block, it starts to execute the transactions in the block.
  • the transaction parameters are parsed and the contract is executed (called the contract on the target chain).
  • the execution process includes the processing of reading data in storage (such as node memory), for example, node 1 in Figure 8 reads historical transaction data (called consensus business data) from storage.
  • Step S4 after the execution of the contract is completed, each consensus node checks the execution result (that is, the execution result of the above-mentioned on-chain transaction) with each other.
  • the verification method can be to organize the execution results or changes to the storage into a result tree (for example, Merkle), store the result tree root in the block header through the result tree root hash, and finally verify each consensus node The block hashes are consistent.
  • Step S5 after the consensus is successful, each consensus node writes the data related to the block into storage; including the block header, all transactions contained in the block, execution results, etc.
  • step S1-step S5 For the detailed process of the above step S1-step S5, reference may be made to the corresponding step S301-step S303 in FIG. 6, and the description will not be repeated here.
  • consensus nodes can join business nodes to quickly implement the deployment and synchronization of local contracts.
  • FIG. 9 is a schematic structural diagram of a first data processing device based on a smart contract provided by an embodiment of the present application.
  • the first data processing device 9-1 may be a computer program (including program code) running in a computer device; for example, the first data processing device 9-1 is an application software; the first data processing device 9-1 1 can be used to execute the corresponding steps in the method provided by the embodiment of this application.
  • the first data processing device 9-1 may run on a service node in a service network.
  • the first data processing device 9-1 may include: a first acquisition module 11, a first execution module 12, and a forwarding module 13;
  • the first acquisition module 11 is configured to acquire an initial contract call request for executing transaction services; the initial contract call request includes a first contract identifier for calling a contract on the target chain; the contract on the target chain is deployed in the core consensus On the consensus node of the network, the core consensus network is independent of the business network; both the consensus node and the business node store a first mapping relationship between the first contract identifier and the second contract identifier; The second contract identifier is the contract identifier of the target local contract deployed on the service node;
  • the first execution module 12 is configured to query the second contract identifier based on the first contract identifier and the first mapping relationship, determine the target local contract based on the second contract identifier, and call the target
  • the local contract executes the local business indicated by the transaction business, and obtains the execution result of the local transaction;
  • the forwarding module 13 is configured to send a target contract call request to the consensus node based on the local transaction execution result and the initial contract call request, and the target contract call request is used by the consensus node to Identify and obtain the contract on the target chain, and execute the consensus service indicated by the transaction service by calling the contract on the target chain;
  • the blockchain network where the business network and the core consensus network are located also includes a routing network for network isolation;
  • the above-mentioned forwarding module 13 is further configured to send the target contract call request to the consensus node through the routing node in the routing network based on the local transaction execution result and the initial contract call request.
  • the first data processing device 9 - 1 may further include: a request feedback module 14 .
  • the request feedback module 14 is configured to determine the request parameter that does not meet the on-link condition as an illegal request parameter if the pre-check result indicates that the request parameter does not meet the on-link condition, and The request parameter is used as the execution result of the local transaction corresponding to the local service; request failure information is generated according to the illegal request parameter, and the request failure information is returned to the first user terminal that sent the initial contract call request.
  • the first data processing device 9 - 1 may further include: a first contract deployment module 15 and a first contract synchronization module 16 .
  • the first contract deployment module 15 is configured to forward the contract deployment request sent by the second user terminal to the consensus node, and the contract deployment request is used for the consensus node to generate local contract information corresponding to one or more preset local contracts ;
  • the one or more preset local contracts include the target local contract;
  • the first contract synchronization module 16 is configured to send a contract synchronization request to the consensus node, and the contract synchronization request is used for the consensus node to agree on the contract synchronization request; the contract synchronization request includes the corresponding
  • the contract synchronization request consensus is passed, the local contract information sent by the consensus node is received; the local contract information means that the consensus node is based on the business node identifier and is summarized in the local contract The information obtained in the information; deploy the target local contract based on the local contract information.
  • the above-mentioned first execution module 12 may include: a third query unit 121 , a reading unit 122 , and an execution unit 123 .
  • local contract information is stored in the service node; the local contract information includes a relationship mapping table; and the relationship mapping table includes the first mapping relationship.
  • the third query unit 121 is configured to query the contract identifier having the first mapping relationship with the first contract identifier in the relationship mapping table, determine the queried contract identifier as the second contract identifier, and The local contract corresponding to the second contract identifier is determined as the target local contract.
  • the reading unit 122 is configured to read the local contract information by calling the target local contract;
  • the execution unit 123 is configured to execute the local service indicated by the transaction service through the local service data, and obtain the local transaction execution result.
  • the execution unit 123 may include: a pre-check subunit 1231 and an information completion subunit 1232 .
  • the pre-check subunit 1231 is configured to, based on the first local business data, perform Pre-check; if the pre-check result indicates that the request parameter meets the on-link condition, then determine the request parameter that meets the on-link condition as a legal request parameter, and use the legal request parameter as the corresponding to the local service
  • the local transaction execution result, the on-chain condition is the condition for on-chain indicated by the local business.
  • the information completion subunit 1232 is configured to invoke the request parameters in the request for the initial contract based on the second local business data Carry out information completion; use the request parameter after information completion as the execution result of the local transaction corresponding to the local business.
  • FIG. 10 is a schematic structural diagram of a second data processing device based on a smart contract provided by an embodiment of the present application.
  • the second data processing device 10-2 may be a computer program (including program code) running in a computer device, for example, the data processing device 10-2 is an application software; the second data processing device 10-2 may be It is used to execute the corresponding steps in the method provided by the embodiment of the present application. As shown in FIG. 10, the second data processing device 10-2 can run on a consensus node in the core consensus network.
  • the second data processing device 10-2 may include: a second acquisition module 21, a second execution module 22, and an uplink module 23;
  • the second obtaining module 21 is configured to obtain a target contract call request for executing transaction services; the target contract call request is sent by a service node based on the local transaction execution result and the initial contract call request, and the service node is located independently of In the business network of the core consensus network; the local transaction execution result is obtained by the business node by calling the target local contract to execute the local business indicated by the transaction business; the target local contract is the business node Obtained based on the second contract identifier; the second contract identifier is queried by the service node based on the first contract identifier and the first mapping relationship; the first contract identifier refers to the initial contract call request used is used to call the contract identifier of the contract on the target chain; the initial contract call request is used to execute the transaction business; the contract on the target chain is deployed on the consensus node; both the consensus node and the business node store There is the first mapping relationship between the first contract identifier and the second contract identifier; the second contract identifier is the contract identifier of the target
  • the second execution module 22 is configured to call the contract on the target chain based on the first contract identifier in the call request of the target contract, and execute the consensus business indicated by the transaction business by calling the contract on the target chain , to get the transaction execution result on the chain.
  • the second data processing device 10 - 2 may further include: a second contract deployment module 24 and a second contract synchronization module 25 .
  • the second contract deployment module 24 is configured to perform consensus on the contract deployment request forwarded by the service node, and when the contract deployment request consensus is passed, generate one or more local contracts corresponding to the preset local contracts according to the contract deployment request. Contract summary information; the contract deployment request is sent to the service node by the second user terminal, and the one or more preset local contracts include the target local contract;
  • the second contract synchronization module 25 is configured to perform consensus on the contract synchronization request sent by the service node; the contract synchronization request includes the service node identification corresponding to the service node; when the contract synchronization request consensus is passed, based on the The service node identifier, obtain local contract information from the local contract summary information, send the local contract information to the service node, and use the local contract information for the service node to deploy the target local contract.
  • the contract deployment request includes contract key fields corresponding to each preset local contract, and the contract key fields include local contract identifier, local contract version number, local contract type, local contract code, and local contract description Information, associated contract identifiers, and executable node identifier lists; associated contract identifiers refer to the contract identifiers of on-chain contracts associated with each preset local contract deployed on the consensus node; the executable node identifier list includes one or more Executable node identification; executable node identification refers to the node identification corresponding to the node with execution authority for each preset local contract; the executable node identification list corresponding to the target local contract includes the service node logo.
  • the contract deployment request also includes terminal signature information and terminal identification corresponding to the second user terminal; please refer to FIG. 10 , the second contract deployment module 24 may include: a first consensus unit 241, a mapping table generation unit 242. Information table generation unit 243, determination storage unit 244;
  • the first consensus unit 241 is configured to perform consensus on terminal signature information and terminal identification;
  • the mapping table generation unit 242 is configured to generate a summary relationship mapping table according to the local contract identification, associated contract identification and executable node identification list when the terminal signature information and the terminal identification pass the consensus; the summary relationship mapping table includes one or more Preset the mapping relationship column corresponding to the local contract respectively; the mapping relationship column is used to store the mapping relationship between the local contract ID and the associated contract ID, and the mapping relationship between the local contract ID and the executable node ID;
  • the information table generating unit 243 is configured to generate a summary contract information table according to the local contract identifier, the local contract code, the associated contract identifier and the list of executable node identifiers; the summary contract information table includes contracts corresponding to one or more preset local contracts Information Bar;
  • the determining storage unit 244 is configured to determine the summary relationship mapping table and the summary contract information table as local contract summary information corresponding to one or more preset local contracts.
  • the contract synchronization request may also include node signature information
  • the above-mentioned second contract synchronization module 25 may include: a second consensus unit 251, a first query unit 252, a second query unit 253, and a determination sending unit 254;
  • the second consensus unit 251 is configured to perform consensus on node signature information and service node identifiers
  • the first query unit 252 is configured to perform a query in the summary relationship mapping table based on the service node ID when both the node signature information and the service node ID have passed the consensus, and to query the mapping relationship column of the node ID that is the same as the service node ID. Determined as a relationship mapping table; the relationship mapping table stores the first mapping relationship and the second mapping relationship between the second contract identifier and the service node identifier;
  • the second query unit 253 is configured to determine the local contract identifier in the relational mapping table as the key contract identifier, perform a query in the summary contract information table based on the key contract identifier, and search for contracts with the same contract identifier as the key contract identifier.
  • the information column is determined as the local contract information table; the local contract information table includes the contract information column corresponding to the target local contract;
  • the determining and sending unit 254 is configured to determine the relationship mapping table and the local contract information table as the local contract information, and send the local contract information to the service node.
  • the on-chain module 23 is configured to generate a block to be added to the target blockchain according to the transaction execution result on the chain, and perform on-chain processing on the block;
  • the target blockchain is the blockchain to which the contract on the target chain belongs.
  • FIG. 11 is a schematic structural diagram of a computer device provided by an embodiment of the present application.
  • the computer device 1000 can be a service node in the business network or a consensus node in the core consensus network, and the computer device 1000 can include: a processor 1001, a network interface 1004 and a memory 1005.
  • the above computer device 1000 may also include: a user interface 1003 , and at least one communication bus 1002 .
  • the communication bus 1002 is used to realize connection and communication between these components.
  • the user interface 1003 may include a display screen (Display) and a keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface and a wireless interface.
  • the network interface 1004 may include a standard wired interface and a wireless interface (such as a WI-FI interface).
  • the memory 1004 may be a high-speed random access memory (Random Access Memory, RAM) memory, or a non-volatile memory (Non-Volatile Memory), such as at least one disk memory.
  • the memory 1005 may also be at least one storage device located away from the aforementioned processor 1001 .
  • the memory 1005 as a computer-readable storage medium may include an operating system, a network communication module, a user interface module, and a device control application program.
  • the network interface 1004 can provide network communication functions; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control stored in the memory 1005
  • the application program is used to execute the description of the data processing method based on the smart contract provided by the embodiment of the present application, and the description will not be repeated here. In addition, the description of beneficial effects using the same method will not be repeated.
  • the embodiment of the present application also provides a computer-readable storage medium, and the above-mentioned computer-readable storage medium stores the first data processing device 9-1 based on the smart contract or the second data processing device 9-1 based on the smart contract.
  • the computer program executed by the device 10-2, and the above-mentioned computer program includes program instructions, when the above-mentioned processor executes the above-mentioned program instructions, it can execute the smart contract-based data processing method provided by the embodiment of the present application. Repeat the description. In addition, the description of beneficial effects using the same method will not be repeated.
  • program instructions may be deployed to execute on one electronic device, or on multiple electronic devices located at one location, or, alternatively, on multiple electronic devices distributed across multiple locations and interconnected by a communication network
  • program instructions may be deployed to execute on one electronic device, or on multiple electronic devices located at one location, or, alternatively, on multiple electronic devices distributed across multiple locations and interconnected by a communication network
  • multiple electronic devices distributed in multiple locations and interconnected through a communication network can form a blockchain system.
  • the above-mentioned computer-readable storage medium may be the data processing device based on the smart contract provided by the embodiment of the present application or the internal storage unit of the above-mentioned computer equipment, such as the hard disk or memory of the computer equipment.
  • the computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk equipped on the computer device, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, Flash card (Flash Card), etc.
  • the computer-readable storage medium may also include both an internal storage unit of the computer device and an external storage device.
  • the computer-readable storage medium is used to store the computer program and other programs and data required by the computer device.
  • the computer-readable storage medium can also be used to temporarily store data that has been output or will be output.
  • the embodiment of the present application also provides a computer program product or computer program, where the computer program product or computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium.
  • a processor of an electronic device such as a computer device reads the computer instruction from a computer-readable storage medium, and the processor executes the computer instruction, so that the electronic device executes the smart contract-based data processing method provided by the embodiment of the present application.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Power Engineering (AREA)
  • Computer Hardware Design (AREA)
  • Technology Law (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种基于智能合约的数据处理方法、装置、设备、计算机可读存储介质及计算机程序产品，该基于智能合约的数据处理方法包括：业务节点获取用于执行交易业务的初始合约调用请求；基于第一合约标识和第一映射关系，查询与目标链上合约相关联的第二合约标识，基于第二合约标识调用目标本地合约，并通过调用目标本地合约执行交易业务所指示的本地业务，得到本地交易执行结果；基于本地交易执行结果和初始合约调用请求，向共识节点发送目标合约调用请求；共识节点基于目标合约调用请求中的第一合约标识调用目标链上合约，并通过调用目标链上合约执行交易业务所指示的共识业务。

Description

一种基于智能合约的数据处理方法、装置、电子设备、计算机可读存储介质及计算机程序产品
相关申请的交叉引用
本申请基于申请号为202110923438.7、申请日为2021年08月12日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此引入本申请作为参考。
技术领域
本申请涉及区块链技术领域，尤其涉及一种基于智能合约的数据处理方法、装置、电子设备、计算机可读存储介质及计算机程序产品。
背景技术
在区块链系统中，智能合约是一种区块链上各个节点可以理解并执行的代码，可以执行任意逻辑并得到结果；智能合约可以理解为是可执行程序，而区块链可以理解为是提供程序运行环境的操作系统。在实际应用中，智能合约可以通过区块链上的交易来管理与试用。
在区块链网络中，业务对象可以通过发起一笔交易的方式，调用区块链上已经部署好的智能合约。其中，所有智能合约均部署并运行于区块链网络中的共识节点上，各个共识节点分别运行交易所指定的智能合约，对于需要读取数据的智能合约，各共识节点会访问自己的账本，最终，各个共识节点会互相验证执行结果是否一致(共识)，若一致则将执行结果存入各自的账本中，并将执行结果返回给业务对象，也可以将执行结果同步至其它类型的节点上，这样使得共识节点的数据存储数量以及运算工作量较大，进而共识节点的负载较大，影响了数据处理效率。
发明内容
本申请实施例提供了一种基于智能合约的数据处理方法、装置、电子设备、计算机可读存储介质及计算机程序产品，可以降低共识节点的负载，提升数据处理效率。
本申请实施例提供了一种基于智能合约的数据处理方法，该方法由业务网络中的业务节点执行，所述业务节点包括至少一个电子设备，包括：
获取用于执行交易业务的初始合约调用请求；所述初始合约调用请求包括用于调用目标链上合约的第一合约标识；所述目标链上合约部署在核心共识网络的共识节点上，所述核心共识网络独立于所述业务网络；所述共识节点和所述业务节点中均存储有所述第一合约标识与第二合约标识之间的第一映射关系；所述第二合约标识为部署在所述业务节点上的目标本地合约的合约标识；
基于所述第一合约标识和所述第一映射关系，查询所述第二合约标识，基于所述第二合约标识确定所述目标本地合约，通过调用所述目标本地合约执行所述交易业务所指示的本地业务，得到本地交易执行结果；
基于所述本地交易执行结果和所述初始合约调用请求，向所述共识节点发送目标合 约调用请求，所述目标合约调用请求用于所述共识节点基于所述第一合约标识调用所述目标链上合约，并通过调用所述目标链上合约执行所述交易业务所指示的共识业务。
本申请实施例提供了一种基于智能合约的数据处理方法，该方法由核心共识网络中的共识节点执行，所述共识节点包括至少一个电子设备，包括：
获取用于执行交易业务的目标合约调用请求；所述目标合约调用请求是业务节点基于本地交易执行结果和初始合约调用请求所发送的，所述业务节点位于独立于所述核心共识网络的业务网络中；所述本地交易执行结果是由所述业务节点通过调用目标本地合约执行所述交易业务所指示的本地业务得到的；所述目标本地合约是所述业务节点基于第二合约标识获取到的；所述第二合约标识是所述业务节点基于第一合约标识和第一映射关系查询到的；所述第一合约标识是指所述初始合约调用请求中用于调用目标链上合约的合约标识；所述初始合约调用请求用于执行所述交易业务；所述目标链上合约部署在所述共识节点上；所述共识节点和所述业务节点中均存储有所述第一合约标识与所述第二合约标识之间的所述第一映射关系；所述第二合约标识为部署在所述业务节点上的所述目标本地合约的合约标识；
基于所述目标合约调用请求中的所述第一合约标识，调用所述目标链上合约，通过调用所述目标链上合约执行所述交易业务所指示的共识业务，得到链上交易执行结果。
本申请实施例提供了一种基于智能合约的第一数据处理装置，该第一数据处理装置存储在业务网络的业务节点中，包括：
第一获取模块，用于获取用于执行交易业务的初始合约调用请求；所述初始合约调用请求包括用于调用目标链上合约的第一合约标识；所述目标链上合约部署在核心共识网络的共识节点上，所述核心共识网络独立于所述业务网络；所述共识节点和所述业务节点中均存储有所述第一合约标识与第二合约标识之间的第一映射关系；所述第二合约标识为部署在所述业务节点上的目标本地合约的合约标识；
第二执行模块，用于基于所述第一合约标识和所述第一映射关系，查询所述第二合约标识，基于所述第二合约标识确定所述目标本地合约，通过调用所述目标本地合约执行所述交易业务所指示的本地业务，得到本地交易执行结果；
转发模块，用于基于所述本地交易执行结果和所述初始合约调用请求，向所述共识节点发送目标合约调用请求，所述目标合约调用请求用于所述共识节点基于所述第一合约标识获取所述目标链上合约，并通过调用所述目标链上合约执行所述交易业务所指示的共识业务。
本申请实施例提供了一种基于智能合约的第二数据处理装置，该第二数据处理装置存储在核心共识网络的共识节点中，包括：
第二获取模块，用于获取用于执行交易业务的目标合约调用请求；所述目标合约调用请求是业务节点基于本地交易执行结果和初始合约调用请求所发送的，所述业务节点位于独立于所述核心共识网络的业务网络中；所述本地交易执行结果是由所述业务节点通过调用目标本地合约执行所述交易业务所指示的本地业务得到的；所述目标本地合约是所述业务节点基于第二合约标识获取到的；所述第二合约标识是所述业务节点基于第一合约标识和第一映射关系查询到的；所述第一合约标识是指所述初始合约调用请求中用于调用目标链上合约的合约标识；所述初始合约调用请求用于执行所述交易业务；所述目标链上合约部署在所述共识节点上；所述共识节点和所述业务节点中均存储有所述第一合约标识与所述第二合约标识之间的所述第一映射关系；所述第二合约标识为部署在所述业务节点上的所述目标本地合约的合约标识；
第二执行模块，用于基于所述目标合约调用请求中的所述第一合约标识，调用所述目标链上合约，通过调用所述目标链上合约执行所述交易业务所指示的共识业务，得到 链上交易执行结果。
本申请实施例提供了一种电子设备，包括：处理器、存储器、网络接口；上述处理器与上述存储器、上述网络接口相连，其中，上述网络接口用于提供数据通信功能，上述存储器用于存储计算机程序，上述处理器用于调用上述计算机程序，以执行本申请实施例提供的由业务网络中的业务节点执行的基于智能合约的数据处理方法，或者以执行本申请实施例提供的由核心共识网络中的共识节点执行的基于智能合约的数据处理方法。
本申请实施例提供了一种计算机可读存储介质，上述计算机可读存储介质中存储有计算机程序，上述计算机程序适于由处理器加载并执行本申请实施例提供的由业务网络中的业务节点执行的基于智能合约的数据处理方法，或者以执行本申请实施例提供的由核心共识网络中的共识节点执行的基于智能合约的数据处理方法。
本申请实施例提供了一种计算机程序产品，该计算机程序产品包括计算机程序或指令，该计算机程序或指令被处理器执行时，执行本申请实施例提供的由业务网络中的业务节点执行的基于智能合约的数据处理方法，或者以执行本申请实施例提供的由核心共识网络中的共识节点执行的基于智能合约的数据处理方法。
在本申请实施例中，通过在独立于核心共识网络的业务网络中的业务节点上部署目标本地合约，以及设置第一合约标识与目标本地合约对应的第二合约标识之间的第一映射关系，在核心共识网络的共识节点调用部署在该共识节点上的目标链上合约来执行交易业务所指示的共识业务之前，业务网络中的业务节点可以先获取用于执行该交易业务的初始合约调用请求，执行交易业务所指示的本地业务，得到本地交易执行结果。又由于该业务节点可以基于本地交易执行结果和初始合约调用请求来确定目标合约调用请求，并将目标合约调用请求转发至共识节点来执行交易业务所指示的共识业务，也就是说，执行共识业务之前，业务节点可以先于共识节点对接收到的合约调用请求进行相应的处理，使得共识节点上执行的本地业务移至了业务节点上处理，减少了共识节点执行本地业务的资源消耗，从而可以降低共识节点的负载，提高区块链网络的交易处理效率。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的一种区块链网络分层结构的示意图；
图2a-图2b是本申请实施例提供的一种数据处理的场景示意图；
图3是本申请实施例提供的一种基于智能合约的数据处理方法的流程示意图；
图4是本申请实施例提供的一种基于智能合约的数据处理方法的流程示意图；
图5a-图5c是本申请实施例提供的一种数据处理的场景示意图；
图6是本申请实施例提供的一种基于智能合约的数据处理方法的流程示意图；
图7是本申请实施例提供的另一种基于智能合约的数据处理方法的流程示意图；
图8是本申请实施例提供的一种数据处理方法的流程示意图；
图9是本申请实施例提供的一种基于智能合约的第一数据处理装置的结构示意图；
图10是本申请实施例提供的一种基于智能合约的第二数据处理装置的结构示意图；
图11是本申请实施例提供的一种计算机设备的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。
1)交易(Transaction)，等同于计算机术语“事务”，交易包括了需要提交到区块链网络执行的操作，并非单指商业语境中的交易，鉴于在区块链技术中约定俗成地使用了“交易”这一术语，本申请实施例遵循了这一习惯。
例如，部署(Deploy)交易用于向区块链网络中的节点安装指定的智能合约并准备好被调用；调用(Invoke)交易用于通过调用智能合约在区块链中追加交易的记录，并对区块链的状态数据库进行操作，包括更新操作(包括写操作(包括增加键值对数据和删除键值对数据)和删除操作)和查询操作(即查询状态数据库中的键值对)。
2)区块链(Blockchain)，是由区块(Block)形成的加密的、链式的交易的存储结构。
例如，每个区块的头部既可以包括区块中所有交易的哈希值，同时也包含前一个区块中所有交易的哈希值，从而基于哈希值实现区块中交易的防篡改和防伪造；新产生的交易被填充到区块并经过区块链网络中节点的共识后，会被追加到区块链的尾部从而形成链式的增长。
3)区块链网络(Blockchain Network)，通过共识的方式将新区块纳入区块链的一系列的节点的集合。
4)智能合约(Smart Contracts)，也称为链码(Chaincode)或应用代码，部署在区块链网络的节点中的程序，节点执行接收的交易中所调用的智能合约，来对状态数据库的键值对数据进行更新或查询的操作。
请参见图1，图1是本申请实施例提供的一种区块链网络分层结构的示意图。区块链(Blockchain)是一种分布式数据存储、点对点传输、共识机制以及加密算法等计算机技术的新型应用模式，用于按时间顺序对数据进行整理，并加密成账本，使数据不可被篡改和伪造，同时可进行数据的验证、存储和更新。区块链本质上是一个去中心化的数据库，该数据库中的每个节点均存储一条相同的区块链，其中，区块链网络中的节点，是逻辑层面的，可以由一个或多个设备(服务器)映射而成。本申请实施例中的区块链网络分层结构可以为图1所示的区块链网络1W，该区块链网络1W对应的完整区块链业务体系可以由图1所示的业务网络1-1、核心共识网络1-2以及路由节点10D所在的路由网络1-3(也可称为路由代理网络)所组成。
应当理解，该路由网络1-3中的路由节点的节点数量可以为一个或者多个，在此不做限定。本申请实施例以路由节点10D为例进行说明，该路由节点10D可以用于对该业务网络1-1和核心共识网络1-2进行网络隔离。该路由节点10D可以是独立的一个物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(Content Delivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器，在此不做限定。该路由节点10D可以将点对点(Peer To Peer，P2P)网络进行网络分层，以形成“业务网络1-1—核心共识网络1-2”这样的分层结构，进而能够提高区块链上数据的保密性和安全性。
其中，图1所示的业务网络1-1(即见证网络)与核心共识网络1-2彼此独立，业务网络1-1对应的区块链节点系统(即第一区块链节点系统)中可以包括一个或者多个区块链节点，这里将不对第一区块链节点系统中的节点数量进行限制。比如，第一区块链系统具体可以包括节点110a、节点110b、节点110c、…、节点110n。应当理解，本申请实施例可以将处于业务网络1-1中的区块链节点称之为业务节点，该业务节点不需要参与记账共识，用于执行交易业务，以得到与该交易业务相关联的交易数据。其中，这里的业务节点可以为包含完整的区块链数据库的全量节点(Full Node)，也可以为存储区块链数据库中的部分数据的轻量节点(Simplified Payment Verification，SPV)，这里将不对其进行限定。为了减少业务节点的存储空间的浪费，本申请实施例中的业务节点可以以轻量节点为例进行说明，该业务节点存储的为部分交易数据，并通过路由节点10D，从图1所示的核心共识网络1-2中，获得区块头数据和部分授权可见的区块数据(例如，与业务节点自身相关联的交易)。
其中，图1所示的核心共识网络1-2对应的区块链节点系统(即第二区块链节点系统)中也可以包括一个或者多个区块链节点，这里将不对第二区块链节点系统中的节点数量进行限制。比如，第二区块链系统具体可以包括节点120a、节点120b、节点120c、…、节点120m。应当理解，本申请实施例可以将处于该核心共识网络1-2中的节点称之为共识节点(即记账节点)，该共识节点可以运行有区块链共识协议。其中，本申请实施例中的共识节点可以为包含完整的区块链数据库的全量节点，该共识节点可以参与校验、广播交易数据以及区块信息，且会发现和维持与其他节点的连接。
应当理解，本申请实施例可以将路由节点、业务节点以及共识节点统称为区块链网络1W中的区块链节点。其中，该区块链节点可以为接入该区块链网络1W中的服务器，也可以为接入该区块链网络1W中的用户终端，这里对区块链节点的具体形式不做限定。可以理解的是，图1所示的业务网络1-1和核心共识网络1-2可以处于不同的网络环境，例如，通常来说，业务节点部署在处于公网的业务网络1-1中，而运行区块链共识协议的共识节点则部署在私有的核心共识网络1-2中，二者可以通过路由边界进行交互。在一种实施方式中，业务节点和共识节点可以不通过路由节点而直接进行数据传输。
可以理解的是，区块链系统中可以包括有智能合约，该智能合约在区块链系统中为一种区块链各节点(包括共识节点)可以理解并执行的代码，可以执行任意逻辑并得到结果。本申请实施例可以将部署且仅运行在业务网络1-1的业务节点上的智能合约统称为本地合约，将部署在核心共识网络1-2的共识节点上的智能合约统称为链上合约。业务对象(可以为请求执行交易业务的用户或请求部署智能合约的用户)可以通过用户终端上的客户端发起一个合约调用请求(也可称为交易业务请求)的方式，调用区块链系统中已经部署好的智能合约(可以是本地合约或链上合约)。应当理解，区块链系统中可以包括一个或多个智能合约，这些智能合约可以以合约标识(例如标识号(Identity document，ID)或名称，还可以包括合约地址或合约函数名(也可以称为合约方法名))来进行区分，而客户端发起的合约调用请求中，也可以携带智能合约的标识号或名称，以此指定区块链需要运行的智能合约。而若客户端所指定的智能合约为需要读取数据的合约，则相关节点会访问本地存储来进行数据的读取。对于需要上链的交易，最后各个共识节点会互相验证执行结果是否一致(也就是进行共识)，若一致则可以将执行结果存入各自的本地账本中，并将执行结果返回至客户端。
在本申请实施例中，可以将业务对象指定调用的链上合约称为目标链上合约，将目标链上合约的合约标识称为第一合约标识，同理，可以将与目标链上合约相关联的本地合约称为目标本地合约，将目标本地合约的合约标识称为第二合约标识，需要说明的是，共识节点和部署有该目标本地合约的业务节点的节点内存中均存储有第一合约标识与 第二合约标识之间的映射关系，可将该映射关系称为第一映射关系，其中，这里的业务节点特指业务网络1-1中具有针对目标本地合约的执行权限的节点，可以由业务对象在图1所示的业务网络1-1中指定一个节点(例如图1所示的节点110a)作为该业务节点，也就是说，目标本地合约部署并运行于该业务节点上。
在本申请实施例中，该业务节点可以先获取第一用户终端发送的初始合约调用请求，其中，这里的第一用户终端是指发送初始合约调用请求的用户终端，初始合约调用请求包括第一合约标识，可用于执行相关的交易业务，进而可以基于第一合约标识和第一映射关系，在该业务节点的节点内存中查询与目标链上合约相关联的第二合约标识，随后可以基于第二合约标识获取目标本地合约，并调用目标本地合约执行交易业务所指示的本地业务，从而得到本地交易执行结果。接着，业务节点可以基于本地交易执行结果以及初始合约调用请求，确定目标合约调用请求，需要说明的是，执行本地业务后，得到的目标合约调用请求可能是与初始合约调用请求相同的请求，也可能是与初始合约调用请求不相同的请求。随后，该业务节点可以将目标合约调用请求转发至共识节点，共识节点接收到目标合约调用请求后，可以基于目标合约调用请求中的第一合约标识，获取目标链上合约，进而可以调用目标链上合约执行交易业务所指示的共识业务，得到链上交易执行结果；最终，可以根据该链上交易执行结果生成待添加至区块链的区块(即待上链区块)，并对该区块进行上链处理。其中，该区块链为目标链上合约所属的区块链。
本申请实施例提供的本地合约是一种特殊的、不在共识节点执行而仅在业务节点执行的合约，通过在初始合约调用请求中指定与目标本地合约相关联的目标链上合约的方式，使得业务节点可以先调用目标本地合约执行相应的本地业务，再由共识节点调用目标链上合约执行相应的共识业务。例如，针对国家总局建立的区块链，各省局可以作为业务节点接入，除了满足国家相关要求外，每个省份又可以有各自不同的政策，此时每个省份的业务节点可以部署不同的本地合约，只为这个省份服务。一方面，本地合约可以做提前的检查与计算，减轻共识节点的压力；另一方面，本地合约可以访问与利用本地业务数据，使本地业务数据无需上链，减轻共识节点存储压力的同时也更好地保护自己的隐私。
请参见图2a-图2b，图2a-图2b是本申请实施例提供的一种数据处理的场景示意图。图2a-图2b中的用户终端20a与业务对象A具有绑定关系，该用户终端20a可以通过发起合约调用请求的方式来调用已经部署的智能合约(链上合约或本地合约)。图2a-图2b中的业务节点20b可以为业务网络中部署有本地合约的业务节点，该业务节点20b可以为上述图1所示的业务网络1-1中的任意一个业务节点，例如，节点110a。图2b中的共识节点20c可以为核心共识网络中部署有链上合约的共识节点，该共识节点20c可以为上述图1所示的核心共识网络1-2中的任意一个共识节点，例如，节点120a。
应当理解，业务网络中部署有本地合约的业务节点可以调用该本地合约执行交易业务所指示的本地业务，核心共识网络中部署有链上合约的任一共识节点均可以调用该链上合约执行交易业务所指示的共识业务。例如，这里的交易业务可以为资产转移业务，其中，该资产转移业务可以用于转移游戏金币、游戏钻石、电子票据等虚拟资产，这里将不对虚拟资产的类型进行限定。又例如，这里的交易业务可以为文件转移业务，其中，该文件转移业务可以用于转移电子合同、电子公文等各类形式的电子文件。此外，这里的交易业务还可以为查询业务、存储业务等，本申请对此不做限定。需要说明的是，在业务节点上部署本地合约时，可以指定关联的链上合约，这样可以复用该链上合约的一些数据。
如图2a所示，业务网络中的任意一个业务节点(例如，业务节点20b)均可以部署一个或多个本地合约(称为预置本地合约)，每个本地合约可以执行不同的功能，该业 务节点拥有针对这一个或多个本地合约的执行权限，也就是说，这个业务节点可以调用部署在该业务节点上的本地合约。例如，以业务节点20b为例，可以在业务节点20b上部署多个(例如，10个)本地合约，可以包括本地合约201b、本地合约202b、…、本地合约210b，这些本地合约的相关信息可以存储在业务节点20b的节点内存20d中，也可以存储在业务节点20b的其他存储模块中；其中，每个本地合约均可以采用唯一的合约标识(例如标识号或名称)进行区分，例如，本地合约201b对应的合约标识为合约标识1b，本地合约205b对应的合约标识为合约标识5b，本地合约210b对应的合约标识为合约标识10b。如图2b所示，核心共识网络中的任一共识节点(例如，共识节点20c)均可以部署一个或多个链上合约，且每个共识节点上部署的链上合约是相同的，每个链上合约也可以执行不同的功能。例如，以共识节点20c为例，可以在共识节点20c上部署多个(例如，30个)链上合约，可以包括链上合约201c、链上合约202c、…、链上合约230c，这些链上合约的相关信息可以存储在共识节点20c的节点内存20f中，也可以存储在共识节点20c的其他存储模块中；其中，每个链上合约均可以采用唯一的合约标识(例如标识号或名称)进行区分，例如，链上合约201c对应的合约标识为合约标识1c，链上合约210c对应的合约标识为合约标识10c，链上合约230c对应的合约标识为合约标识30c。
需要说明的是，每个本地合约均可以与一个或多个链上合约建立关联关系；在一种实施方式中，可以采用本地合约的合约标识与该本地合约相关联的链上合约的合约标识之间的映射关系来表征两者的关联关系，并且可以将这些映射关系以关系映射表的形式存储至共识节点以及相关的业务节点的节点内存或其他存储模块中。请再参见图2a，如图2a所示，业务节点20b的节点内存20d中存储有关系映射表20e，关系映射表20e中可以存储一个或多个映射关系；例如，合约标识3c与合约标识1b之间的映射关系，表示链上合约203c与本地合约201b相关联；合约标识20c与合约标识2b之间的映射关系，表示链上合约220c与本地合约202b相关联。同理，如图2b所示，共识节点20c的节点内存20f中也可以存储有关系映射表20e，可以理解，关系映射表20e仅包括与业务节点20b相关的映射关系，节点内存20f中还可以存储与其它业务节点有关的映射关系，本申请实施例仅以关系映射表20e为例进行说明。
如图2a所示，业务对象A可以通过用户终端20a(称为第一用户终端)将合约调用请求B(称为初始合约调用请求)发送至业务节点20b；其中，该合约调用请求B可用于执行业务对象A发起的交易业务(例如，业务对象A向业务对象F转移数量为待转移资产量的虚拟资产，如转账500元)，业务对象A可以通过用户终端20a选择已经部署好的链上合约(称为目标链上合约，例如，链上合约210c)，即可以在合约调用请求B中指定该链上合约的合约标识(称为第一合约标识，例如，合约标识10c)。假设已经预先指定链上合约210c与本地合约205b(称为目标本地合约)之间存在关联关系，则链上合约210c的合约标识10c(称为第一合约标识)与本地合约205b的合约标识5b(称为第二合约标识)之间存在映射关系201e(称为第一映射关系)。业务节点20b接收到用户终端20a发送的合约调用请求B时，可以在关系映射表20e中查询与合约标识10c具有映射关系201e的合约标识，进而可以将查询到的合约标识5b确定为第二合约标识，且可以基于合约标识5b获取本地合约205b。接着，业务节点20b可以调用本地合约205b执行上述交易业务所指示的本地业务(例如，预先检查业务对象A的剩余资产量是否满足转账条件，即业务对象A的剩余资产量是否大于或等于待转移资产量(如500元))，得到交易执行结果C(称为本地交易执行结果)，进而可以基于交易执行结果C和合约调用请求B，确定用于发送给共识节点的合约调用请求D(称为目标合约调用请求)，最终业务节点20b可以通过路由网络中的路由节点将合约调用请求D转发至共 识节点(例如共识节点20c)，或者，业务节点20b可以直接将合约调用请求D转发至共识节点。需要说明的是，合约调用请求D中仍包括合约标识10c。
在一种实施方式中，在一个或多个合约调用请求从业务节点转发至核心链(即核心共识网络)之前，该业务节点可以执行对应的本地合约，以对这些合约调用请求进行预先的检查和过滤(称为预检查处理)，只有满足上链条件的合约调用请求才会最终转发至核心链上进行处理。例如，在转账场景下，合约调用请求D可以是合约调用请求B中满足转账条件(称为上链条件)的请求；又例如，业务节点20b检查到业务对象A的剩余资产量大于500元，即合约调用请求B满足转账条件，则可以将合约调用请求B作为合约调用请求D转发至共识节点20c，再由共识节点20c执行向业务对象F转账500元的操作；反之，若业务对象A的剩余资产量小于500元，即合约调用请求B不满足转账条件，则业务节点20b可以根据交易执行结果C生成请求失败信息(例如，用于提示业务对象A剩余资产量不足的信息)，并将该请求失败信息返回至用户终端20a。
需要说明的是，除了上述举例的预检查处理，不同的交易业务所指示的本地业务也可以包含不同的内容，例如信息补全处理、统计归类处理等，本申请实施例对此不做限定。
下面说明共识节点执行交易业务的过程。如图2b所示，共识节点20c接收到业务节点20b转发的合约调用请求D后，可以基于合约调用请求D中的合约标识10c，获取链上合约210c，进而可以调用链上合约210c执行上述交易业务所指示的共识业务(例如，可以执行业务对象A转账500元至业务对象F的转账业务)，从而得到交易执行结果E(称为链上交易执行结果)。其中，图2b所示的区块链20g可以为共识节点20c所在的核心共识网络中的每个共识节点均共享的一条相同的区块链，每个共识节点均可以在该区块链20g中获取该区块链上所存储的数据信息，应当理解，该区块链20g中可以包括多个(例如101个)区块，分别为区块1、区块2、…、区块100以及目标区块，例如，该区块1可以称之为该区块链20g的创世区块。该区块链20g中的目标区块包含交易执行结果E。其中，假设共识节点20c为核心共识网络中的具备出块功能的共识节点，则共识节点20c可以根据交易执行结果E生成待添加至区块链20g的待上链区块，并对待上链区块进行上链处理，即共识节点20c可以将待上链区块发送至核心共识网络中的其它共识节点，以使其它共识节点对待上链区块进行区块共识，得到用于返回至共识节点20c的区块共识结果，若该区块共识结果为共识通过结果，则共识节点20c可以将该待上链区块作为目标区块，以写入图2b所示的区块链20g中，也就是将该目标区块作为区块100的下一区块。例如，共识节点20c可以调用链上合约210c执行转账业务，并修改业务对象A与业务对象F的剩余资产量，根据业务对象A的最新剩余资产量以及业务对象F的最新剩余资产量生成待上链区块，并将该待上链区块添加至区块链20g中，以完成将业务对象A的最新剩余资产量以及业务对象F的最新剩余资产量写入区块链20g中。
随后，共识节点20c可以通过业务节点20b将交易执行结果(如转账成功结果)返回至用户终端20a以及与业务对象F绑定的用户终端20h，业务对象A通过用户终端20a查询自己的剩余资产量时，所呈现的剩余资产量则为业务对象A的最新剩余资产量；业务对象F通过用户终端20h查询自己的剩余资产量时，所呈现的剩余资产量则为业务对象F的最新剩余资产量。
应当理解，本申请实施例提供的基于智能合约的数据处理方法可以应用于转移虚拟资产(例如游戏金币、游戏钻石、电子票据)或者转移电子文件(例如电子合同、电子公文)等业务场景，或者其它通过本地合约进行提前检查与计算的业务场景。由于业务节点可以先于共识节点调用本地合约对接收到的合约调用请求进行相应的处理，而不需 要将所有与合约调用请求相关的操作都积压在共识节点上执行，从而可以减轻共识节点的数据处理压力，降低共识节点的负载，并可以提高区块链网络整体的交易处理效率。
请参见图3，图3是本申请实施例提供的一种基于智能合约的数据处理方法的流程示意图。如图3所示，该方法可以由业务网络中的业务节点执行，该业务节点可以为接入至该业务网络中的服务器，也可以为接入至该业务网络中的用户终端，这里对业务节点的具体形式不做限定。其中，该业务节点可以为上述图1所示的业务网络1-1中部署有目标本地合约的业务节点，例如，节点110a。该基于智能合约的数据处理方法至少可以包括步骤S101-步骤S103，下面对各步骤分别进行说明。
步骤S101，获取用于执行交易业务的初始合约调用请求；初始合约调用请求包括用于调用目标链上合约的第一合约标识；共识节点和业务节点中均存储有第一合约标识与第二合约标识之间的第一映射关系。
在本申请实施例中，目标本地合约部署在业务网络中指定的业务节点上，目标链上合约则部署在核心共识网络的共识节点上，该核心共识网络独立于业务网络，两者通过路由网络进行网络隔离。其中，业务节点可以接收来自用户终端发送的交易请求(例如，合约部署请求或初始合约调用请求)，而共识节点可以接收经由业务节点转发的交易请求，其中，交易请求可为用户终端根据业务对象发起的交易业务所生成的请求。为便于后续理解和区分，可以将发送初始合约调用请求的用户终端称为第一用户终端，将发送合约部署请求的用户终端称为第二用户终端；其中，第一用户终端和第二用户终端可以为同一个用户终端，也可以为不同的用户终端。
应当理解，业务对象可以通过发起合约部署请求的方式在业务节点上部署一个或多个本地合约。这里以部署目标本地合约为例进行说明，业务对象可以通过第二用户终端发起合约部署请求，通过该合约部署请求，业务对象可以在指定的业务节点上部署目标本地合约；其中，指定的业务节点可以包括核心共识网络中的一个或多个业务节点。
应当理解，业务对象可以通过指定智能合约的合约标识(例如，ID或名称)来对智能合约进行唯一标识，区块链节点(业务节点或共识节点)可以通过合约标识来调用对应的智能合约。在本申请实施例中，目标链上合约对应的合约标识为第一合约标识，目标本地合约对应的合约标识为第二合约标识。鉴于此，业务对象还可以在合约部署请求中指定目标本地合约所关联的一个或多个链上合约的合约标识；其中，这一个或多个链上合约包括目标链上合约。共识节点和指定的业务节点的节点内存或其他存储模块(例如，硬盘、存储器或数据库等)中均可以存储第一合约标识与第二合约标识之间的第一映射关系。可以理解，部署其它本地合约的过程与部署目标本地合约的过程一致，部署本地合约的实现方式可以参见后续图4所对应的步骤S201以及图7所对应的步骤S401。
应当理解，目标本地合约部署成功后，指定的业务节点可以将部署成功结果返回至第二用户终端。从而，业务对象可以通过第一用户终端发起用于执行交易业务(例如，资产转移业务、文件转移业务、查询业务、存储业务等)的初始合约调用请求，该初始合约调用请求中可以携带业务对象指定的目标链上合约所对应的第一合约标识，第一用户终端可以将该初始合约调用请求发送至部署有目标本地合约的一个或多个业务节点，该一个或多个业务节点在接收到该初始合约调用请求后，可以根据该初始合约调用请求调用与目标链上合约相关联的目标本地合约，调用目标本地合约的实现方式可以参见步骤S102。为便于说明，后续的步骤仅以其中一个业务节点为例进行说明。
可以理解的是，第一用户终端和第二用户终端可以为不同的用户终端，例如，第二用户终端为用户终端A，第一用户终端为用户终端B，业务节点在部署完成后可以将部署成功结果发送至用户终端A；业务节点也可以向用户终端B发送部署成功结果，从而， 用户终端B可以基于部署成功结果向业务节点发送初始合约调用请求。在本申请实施例中，用户终端A在接收到业务节点发送的部署成功结果后，可以向用户终端B发送业务节点已部署完成的通知，随后用户终端B可以向业务节点发送初始合约调用请求。
步骤S102，基于第一合约标识和第一映射关系，查询第二合约标识，基于第二合约标识确定目标本地合约，通过调用目标本地合约执行交易业务所指示的本地业务，得到本地交易执行结果。
应当理解，业务节点中(比如，节点内存中)存储有本地合约信息，该本地合约信息是指部署在该业务节点上的本地合约(包括目标本地合约)相关的信息；其中，该本地合约信息可以包括这些本地合约的合约标识与相关联的链上合约的合约标识之间的映射关系，例如，业务节点A上部署了本地合约A1以及本地合约A2，且本地合约A1与指定的链上合约B1相关联，本地合约A2与指定的链上合约B2相关联，链上合约B1与链上合约B2均部署在共识节点B上，则业务节点A可以在其节点内存的本地合约信息中存储本地合约A1的合约标识与链上合约B1的合约标识之间的映射关系，以及本地合约A2的合约标识与链上合约B2的合约标识之间的映射关系，此外，共识节点B也可以在其节点内存中存储这些映射关系。
可以理解，上述映射关系可以存储在关系映射表中，其中，该关系映射表包括第一合约标识与第二合约标识之间的第一映射关系。关系映射表的一种可选的形式可以参见上述图2a所示的关系映射表20e，当然，也可以采用其它的形式来存储上述映射关系，本申请对此不做限定。
在本申请实施例中，业务节点可以在关系映射表中查询与第一合约标识具有第一映射关系的合约标识，进而可以将查询到的合约标识确定为与目标链上合约相关联的第二合约标识，随后，可以将第二合约标识所对应的本地合约确定为目标本地合约。
可以理解，一个本地合约与一个链上合约具有唯一的映射关系，关系映射表可以包括一个或多个映射关系栏，一个映射关系栏可用于存储一个映射关系；因此，业务节点可以将关系映射表中存储有第一合约标识以及第一映射关系的映射关系栏确定为目标映射关系栏，进而可以将该目标映射关系栏中存储的不同于第一合约标识的合约标识确定为第二合约标识。例如，请再次参见图2a，业务节点20b可以基于合约调用请求B中的合约标识10c以及映射关系201e，在关系映射表20e中查询到与合约标识10c具有映射关系201e的合约标识5b。
可以理解，本地合约信息还可以包括目标本地合约对应的本地合约函数，业务节点可以通过调用本地合约函数来执行交易业务所指示的本地业务；在本申请实施例中，业务节点可以先通过调用目标本地合约以在该本地合约信息中读取本地合约函数，进而可以通过该本地合约函数从业务节点的节点内存中访问与本地业务相关联的本地业务数据，随后可以通过本地业务数据执行交易业务所指示的本地业务，得到本地交易执行结果。
在一种实施方式中，本地合约信息还可以包括合约代码，业务对象可以在目标本地合约中部署该业务对象编写的合约代码(即合约程序语句)，该合约代码是指支持目标本地合约执行本地业务的合约程序语句；其中，该合约代码可以包括本地合约函数对应的合约函数名以及该合约函数名对应的函数语句，业务节点可以调用目标本地合约在本地合约信息中获取本地合约函数对应的合约函数名，进而可以获取该合约函数名对应的函数语句。应当理解，该函数语句中可以指出业务节点中(比如，节点内存中)与本地业务相关联的本地业务数据所在的存储位置，即业务节点可以通过该函数语句向业务节点的节点内存等发送数据读取请求，进而可以获取到该存储位置上的本地业务数据，该本地业务数据可用于执行交易业务所指示的本地业务。
需要说明的是，本地业务数据可以指该业务节点所服务的业务对象相关的数据，该本地业务数据可以来自于相关的用户终端，也可以来自于区块链网络中的其它区块链节点(例如参与交易业务的其它业务节点，或者该业务节点的上级节点，或者核心共识网络中的共识节点)。
其中，本地业务是指业务节点可以利用本地业务数据执行的业务，例如，检查某个合约调用请求是否满足上链条件(称为预检查处理，如检查该合约调用请求是否满足所在省份的相关政策)，或者，补全一些业务节点独有的信息(称为信息补全处理，如分配发票号、补全公章或签名等)，或者，对相关交易数据进行统计和归类，并按指定的格式输出(称为统计归类处理，例如统计某个公司当天进行转账的交易数量)，本申请对此不做限定。下面分别以预检查处理和信息补全处理为例进行说明。
针对本地业务为预检查处理的场景，本地合约函数可以包括与本地业务相关联的预检查函数，业务节点可以通过该预检查函数从业务节点中(比如，节点内存中)访问与本地业务相关联的第一本地业务数据，进而可以基于第一本地业务数据对初始合约调用请求中的请求参数进行预检查处理；此时，本地业务数据包括第一本地业务数据。
例如，企业A向企业B转移一张电子票据，由此可生成相关的请求参数，则业务节点可以在自己的节点内存中查找该电子票据的历史交易信息，如，判断企业A的账户是否存在这一张电子票据、企业A和企业B的账户是否有误、企业A所拥有的这张电子票据的来源、判断该电子票据的号码是否有误等。若预检测结果表示该请求参数满足本地业务所指示的上链条件，则可以将满足本地业务所指示的上链条件的请求参数确定为合法请求参数，进而可以将该合法请求参数作为本地业务对应的本地交易执行结果。反之，若预检测结果表示该请求参数不满足本地业务所指示的上链条件，则可以将不满足本地业务所指示的上链条件的请求参数确定为非法请求参数，并将该非法请求参数作为本地业务对应的本地交易执行结果，进而业务节点可以根据该非法请求参数生成请求失败信息，随后可以将请求失败信息返回至发送初始合约调用请求的第一用户终端；也就是说，业务节点可以将不满足上链条件的合约调用请求进行过滤或拦截。其中，请求失败信息用于表示初始合约调用请求被拒绝，可以包括具体的拒绝原因、错误信息等。
可以理解，在业务节点上对初始合约调用请求进行预检查处理，可以拦截掉一些恶意的或有问题的请求，一方面可以减少共识节点上的计算量，减轻共识节点的数据处理压力，减少共识节点的合约调用请求的数量；另一方面，当共识节点不具备相关的判断能力时，业务节点可以利用自身的本地业务数据进行判断。
其中，上链条件的具体内容与交易业务相关，这里将不对其进行限定。例如，在电子票据场景中，业务节点可以为具有目标区域属性(例如省、市、区等)的业务节点，共识节点可以为该业务节点的上级节点，则此时上链条件可以为与该目标区域属性相关联的政策(例如省的政策、市的政策、区的政策等)。例如，省份A的业务节点可以预先检查用于开具电子票据的合约调用请求B(即初始合约调用请求)是否满足省份A的相关政策，只有合约调用请求B满足省份A的相关政策(例如针对单笔交易金额的限制政策)时，省份A的业务节点才会将合约调用请求B再转发到由共识节点组成的国家链上进行后续处理。又例如，在转账场景中，上链条件可以为交易发起方拥有足够的剩余资产量，也就是说，当交易发起方的剩余资产量大于或等于待转移资产量时，业务节点可以将用于转账的合约调用请求C转发到共识节点上，由共识节点继续执行转账操作，否则，业务节点会对合约调用请求C进行拦截。
应当理解，请求参数可以指与交易业务相关的参数，对于不同的交易业务，请求参数所包含的具体内容也不相同。例如，在电子票据场景中，请求参数可以包括与电子票据的整个生命周期的流转逻辑相关的参数；又例如，电子票据开具信息、电子票据申领 信息、电子票据的票据状态、数据的访问权限、电子票据上的关键字等；在转账场景中，请求参数可以包括交易发起方的剩余资产量、签名信息、待转移资产量、交易接收方标识(例如交易接收方的账号)等；在电子文件场景中，请求参数可以包括电子文件的公章信息、签名信息、状态信息等。
针对本地业务为信息补全处理的场景，本地合约函数可以包括与本地业务相关联的信息补全函数，业务节点可以通过信息补全函数从业务节点中(比如，节点内存中)访问与本地业务相关联的第二本地业务数据，进而可以基于第二本地业务数据对初始合约调用请求中的请求参数进行信息补全处理，随后，可以将信息补全后的请求参数作为本地业务对应的本地交易执行结果；此时，本地业务数据包括第二本地业务数据。例如，在电子票据场景中，省税务局可作为业务节点，在开具电子票据时，该业务节点可以补全一些本省税务局才有的信息，如分配发票号。又例如，在电子文件场景中，地方法院作为业务节点向最高法院(即共识节点)转移一份电子文件前，可以补全该地方法院自身的公章或签名等信息。
可以理解，通过部署本地合约，区块链网络可以将原本存储在共识节点上的部分数据存储在业务节点上，以采用业务节点自身拥有的数据或特有的能力(例如链上合约不具备的能力)去做信息补全(即数据补全)，从而可以减少多方交互，且减轻共识节点的存储压力和计算压力，还可以提升业务节点的数据的隐私安全性。
步骤S103，基于本地交易执行结果和初始合约调用请求，向共识节点发送目标合约调用请求，目标合约调用请求用于共识节点基于第一合约标识获取目标链上合约，并通过调用目标链上合约执行交易业务所指示的共识业务。
在一种实施方式中，业务网络与核心共识网络所在的区块链网络中还可以包括用于进行网络隔离的路由网络，业务节点可以基于本地交易执行结果和初始合约调用请求，确定用于发送给共识节点的目标合约调用请求，进而可以将目标合约调用请求转发至共识节点。
结合上述步骤S102，下面仍以预检查处理和信息补全处理为例进行说明。
针对本地业务为预检查处理的场景，当本地交易执行结果为合法请求参数时，业务节点可以将包含合法请求参数的初始合约调用请求确定为目标合约调用请求；也就是说，当初始合约调用请求中的请求参数满足本地业务所指示的上链条件时，初始合约调用请求与目标合约调用请求为相同的合约调用请求。反之，当本地交易执行结果为非法请求参数时，业务节点可以对初始合约调用请求进行拦截，并可以向第一用户终端返回请求失败信息。可以理解，若初始合约调用请求的数量为一个或多个，则业务节点可以将一个或多个初始合约调用请求中满足上链条件的合约调用请求确定为目标合约调用请求。在本申请实施例中，业务节点可以将目标合约调用请求通过路由网络中的路由节点转发至共识节点；另外，业务节点也可以直接将目标合约调用请求发送至共识节点。
针对本地业务为信息补全处理的场景，业务节点可以根据本地交易执行结果以及初始合约调用请求生成目标合约调用请求，该目标合约调用请求中可以包括信息补全后的请求参数；其中，信息补全后的请求参数可以包括初始合约调用请求中原始的请求参数以及经过信息补全处理后生成的更新的请求参数(即附加了业务节点自己的信息的请求参数)；也就是说，业务节点可以将更新的请求参数添加至初始合约调用请求的请求参数中，从而可以得到包含信息补全后的请求参数的目标合约调用请求，进而可以将目标合约调用请求通过路由网络中的路由节点转发至共识节点，或者，不通过路由节点而直接将目标合约调用请求发送至共识节点。可以理解，此时初始合约调用请求与目标合约调用请求是不相同的合约调用请求。
例如，在开具电子票据时，用户终端X1(称为第一用户终端)可以发起一个用于 开具电子票据的合约调用请求Y1(称为初始合约调用请求)，且合约调用请求Y1包括请求参数Z1；业务节点X2接收到合约调用请求Y1后，可以基于其本地业务数据为该电子票据分配发票号，进而可以根据该发票号生成请求参数Z2(称为更新的请求参数)，并将请求参数Z2添加至合约调用请求Y1的请求参数Z1中，从而可以得到请求参数Z3(称为信息补全后的请求参数)；这里，可以将包含请求参数Z3的合约调用请求Y1称为合约调用请求Y2(称为目标合约调用请求)；然后，业务节点可以通过路由节点X3将合约调用请求Y2发送至共识节点X4。在本申请实施例中，业务节点也可以根据本地交易执行结果，对初始合约调用请求中的相关字段进行更新，得到包含更新字段的目标合约调用请求，进而可以将目标合约调用请求(通过路由节点或者不通过路由节点)转发至共识节点，以使共识节点可以调用目标链上合约将更新字段解析为更新的请求参数。
需要说明的是，在本申请实施例中，业务网络中的业务节点可以对应不同的层级；例如，上下级关系(如县级、市级、省级)，下级节点接收到初始合约调用请求后，可以调用部署在该下级节点上的本地合约，得到第一合约调用请求，进而可以将该第一合约调用请求发送至上级节点，上级节点可以调用部署在该上级节点上的本地合约，得到第二合约调用请求；依此类推，最后一级业务节点得到的合约调用请求可以作为发送给共识节点(具有最高级别)的目标合约调用请求。
在本申请实施例中，共识节点接收到目标合约调用请求后，可以基于目标合约调用请求中的第一合约标识，获取目标链上合约，进而可以调用目标链上合约执行交易业务所指示的共识业务。共识节点执行共识业务的具体实现方式可以参见后续图6所对应的步骤S302。
需要说明的是，目标链上合约可以为已经成功部署在共识节点上的合约，也可以为空的链上合约；在本申请实施例中，当目标链上合约为空合约时，共识节点不会调用任意一个链上合约。在本申请实施例中，业务对象还可以通过第一用户终端在合约调用请求中直接指定目标本地合约，即第一用户终端可以将包含有第二合约标识的合约调用请求发送至部署有目标本地合约的业务节点，该业务节点可以基于第二合约标识获取到目标本地合约，进而可以调用目标本地合约执行本地业务，从而得到本地交易执行结果，随后可以将本地交易执行结果返回至第一用户终端。
例如，当业务对象A获取本人在一个时间段内应缴纳的税额时，可以通过用户终端A1(称为第一用户终端)发起一个用于计算税额的合约调用请求B，在该合约调用请求B中可以指定与税额计算相关的本地合约C(称为目标本地合约)对应的合约标识C1(称为第二合约标识)，则用户终端A1可以将合约调用请求B发送至业务节点A2，进而业务节点A2可以通过合约标识C1获取本地合约C，并可以通过本地合约C从业务节点A2的节点内存中获取与税额计算相关的本地业务数据D(例如，纳税政策、纳税公式、业务对象A的收入、各项支出、占用的耕地面积等)，最终业务节点A2可以基于本地业务数据D计算出业务对象A的应纳税额E(称为本地交易执行结果)，并将应纳税额E返回至用户终端A1。
可以理解，通过本地合约执行一些数据统计、查询或计算等操作(例如在本地合约中编写一些内部使用的代码)，降低在核心共识网络上部署新的程序/服务/进程所导致的核心共识网络的数据处理负载。
可以理解，本申请实施例中可以通过接收业务对象对本地合约的其它功能自定义请求，自定义本地合约的其他功能，以适应不同的业务场景，本申请对此不做限定。此外，本申请实施例提供的合约调用方法可以降低合约调用的错误率，并且便于智能合约的管理，从而能够提升智能合约的调用效率。例如，每个省份有各自不同的政策，A省的业 务节点所部署的本地合约只为A省服务，从而能够解决B省人员错误调用到A省的本地合约的问题。
请参见图4，图4是本申请实施例提供的一种基于智能合约的数据处理方法的流程示意图。如图4所示，该基于智能合约的数据处理方法可以由业务网络中的业务节点执行。该方法至少可以包括步骤S201-步骤S203，下面对各步骤分别进行说明。
步骤S201，获取第二用户终端发送的用于部署一个或多个预置本地合约的合约部署请求，将合约部署请求转发至共识节点。
在本申请实施例中，业务对象可以通过第二用户终端发起用于部署一个或多个预置本地合约的合约部署请求；其中，合约部署请求可以用于在每个预置本地合约中添加合约函数(例如，目标本地合约对应的本地合约函数)以实现相应的功能，还可以用于指定业务网络中可以执行每个预置本地合约的业务节点(称为部署该预置本地合约的业务节点)对应的节点标识；此外，合约部署请求还用于为预置本地合约指定关联的链上合约(可以为共识节点上已经部署的链上合约或空的链上合约)。需要说明的是，合约部署请求所用于指定的这些信息均可以由合约关键字段表示，第二用户终端可以基于合约关键字段生成对应的合约部署请求，进而可以将该合约部署请求发送至业务网络中的任意一个业务节点。
在本申请实施例中，业务节点接收到该合约部署请求后，可以将该合约部署请求通过路由网络中的路由节点转发至核心共识网络中的任意共识节点，或者，不通过路由节点而直接将该合约部署请求发送至任意共识节点。共识节点接收到该合约部署请求后，可以对该合约部署请求进行共识，当该合约部署请求共识通过时，共识节点可以根据该合约部署请求生成一个或多个预置本地合约对应的本地合约汇总信息，该本地合约汇总信息包括每个预置本地合约对应的信息，进而可以将本地合约汇总信息存储至该共识节点中(比如，节点内存中)；此时，也就完成了一个或多个预置本地合约成功在核心链上的部署。应当理解，一个或多个预置本地合约包括目标本地合约；相应地，共识节点生成的本地合约汇总信息包括目标本地合约对应的信息。共识节点对合约部署请求进行共识以及生成本地合约汇总信息的实现方式可以参见后续图7所对应的步骤S401。
需要说明的是，本地合约汇总信息可以采用表格存储、键值存储(Key-Value存储，KV存储)、文件存储等形式存储在共识节点中(比如，节点内存中)，本申请对此不做限定。在一种实施方式中，可以采用键值存储的形式来存储本地合约汇总信息，这样后续进行本地合约的同步或调用时，可以通过设定的Key(例如，关系映射表中链上合约的合约标识)快速查询到相应的Value(例如，关系映射表中本地合约的合约标识)。
为便于理解，请一并参见图5a-图5c，图5a-图5c是本申请实施例提供的一种数据处理的场景示意图。如图5a所示，用户终端30a(称为第二用户终端)发起一个合约部署请求A，该合约部署请求A用于部署两个本地合约(称为预置本地合约)，分别为本地合约L1以及本地合约L2；其中，本地合约L1的合约标识为“Local_A”，本地合约L1与合约标识为“发票”的链上合约C1相关联；本地合约L2的合约标识为“Local_B”，本地合约L2与合约标识为“协作”的链上合约C2相关联。可以理解，链上合约C1可用于处理与发票(即电子票据)相关的业务，例如，发票开具、发票报销等；而链上合约C2可用于处理不同业务对象/企业/机构/单位之间的协作业务(如多方协作处理电子文件)，例如，业务对象1和业务对象2需要共同签订一份合同，则调用链上合约C2，可以将业务对象1签订后的合同流转到业务对象2继续签订。
如图5a所示，用户终端30a可以将合约部署请求A发送至业务网络30b，其中，业务网络30b可以包括业务节点301b以及业务节点302b；可以理解，该业务网络30b还可以包括其它未显示在图5a上的业务节点，例如，业务节点303b、…、业务节点30mb。 业务网络30b中的任意一个业务节点(例如，业务节点301b)均可以获取合约部署请求A；在本申请实施例中，若业务节点301b成功接收到合约部署请求A，则业务节点301b可以将合约部署请求A转发至核心共识网络30c，其中，核心共识网络30c可以包括多个未显示在图5a上的共识节点，例如共识节点301c、共识节点302c、…、共识节点30nc，核心共识网络30c中的每一个共识节点均可以获取合约部署请求A，以共识节点301c为例进行说明，共识节点301c接收到合约部署请求A后，可以将合约部署请求A广播至核心共识网络30c中的其它共识节点，使得每个共识节点均可以对合约部署请求A进行验证(例如，终端签名验证、部署权限验证等)，当验证成功时(称为共识通过)，共识节点301c可以基于合约部署请求A生成本地合约汇总信息30d，并将本地合约汇总信息30d存储至共识节点301c的节点内存中；可以理解，其它共识节点的节点内存中也存储有与本地合约汇总信息30d相同的数据。
如图5a所示，本地合约汇总信息30d可以包括汇总合约信息表30e以及汇总关系映射表30f。在本申请实施例中，汇总合约信息表30e以及汇总关系映射表30f均以键值存储的形式进行数据存储。其中，汇总合约信息表30e可以存储本地合约L1以及本地合约L2各自对应的合约信息，例如，对应的合约标识、合约代码(包括合约函数的代码)、相关联的链上合约的合约标识以及执行标识列表；执行标识列表(称为可执行节点标识列表)可以包括指定部署该本地合约的业务节点所对应的节点标识，例如，合约部署请求A中指定本地合约L1部署在业务节点301b以及业务节点302b上，此时，本地合约L1对应的执行标识列表可包括业务节点301b对应的节点标识ID1以及业务节点302b对应的节点标识ID2；而当合约部署请求A中指定本地合约L2部署在业务节点303b上时，本地合约L2对应的执行标识列表可包括业务节点303b对应的节点标识ID3。其中，汇总关系映射表30f则可以存储与本地合约L1以及本地合约L2相关的映射关系，例如，当本地合约L1与合约标识为“发票”的链上合约C1相关联时，汇总关系映射表30f中可以存储合约标识“发票”与合约标识“Local_A”之间的映射关系；此外，为了便于后续的合约同步，还可以将部署有本地合约L1的业务节点的节点标识(例如ID1、ID2)与合约标识“Local_A”之间的映射关系也存储至汇总关系映射表30f中。
步骤S202，向共识节点发送合约同步请求，以使共识节点对合约同步请求进行共识；当合约同步请求共识通过时，获取共识节点发送的本地合约信息；将本地合约信息存储至业务节点的节点内存中，基于本地合约信息部署目标本地合约。
应当理解，将预置本地合约真正部署到相应的业务节点上才能实现后续的本地合约调用；其中，业务网络中的任一业务节点可以通过路由网络中的路由节点向核心共识网络中的共识节点发送合约同步请求，或者，不通过路由节点而直接将合约同步请求发送至核心共识网络中的共识节点，以同步需要部署在该业务节点上的预置本地合约所对应的合约信息；核心共识网络中的任意一个共识节点接收到该合约同步请求后，可以将该合约同步请求广播至其它共识节点，使得共识节点可以对该合约同步请求进行共识；其中，该合约同步请求包括业务节点对应的业务节点标识。从而，当该合约同步请求共识通过时，共识节点可以基于该业务节点标识，从存储在其节点内存的本地合约汇总信息中获取与该业务节点标识相关的本地合约信息，进而可以将本地合约信息经由路由节点返回(或者，直接返回)至该业务节点。此时，该业务节点可以将接收到的本地合约信息存储至该业务节点的节点内存中，并可以基于本地合约信息创建对应的预置本地合约(例如，目标本地合约)。
需要说明的是，对于一个预置本地合约来说，只有具有针对该预置本地合约的执行权限的业务节点所发送的合约同步请求才能通过共识；也就是说，共识节点需要检验每一个发送合约同步请求的业务节点是否具有部署某个预置本地合约的权限。共识节点对 合约同步请求进行共识以及获取本地合约信息的实现方式可以参见下述图7所对应的步骤S402。
以指定部署目标本地合约的业务节点为例进行说明。当该业务节点向共识节点发送的合约同步请求共识通过时，可以得到共识节点发送的本地合约信息，该本地合约信息可以包括目标本地合约以及同样部署在该业务节点上的其它本地合约的信息；因此，该本地合约信息可以包括关系映射表以及本地合约信息表；其中，关系映射表可以存储有第一合约标识与第二合约标识之间的第一映射关系，以及第二合约标识与业务节点标识(即该业务节点的节点标识)之间的第二映射关系，而本地合约信息表则可以包括目标本地合约对应的合约信息栏。
在本申请实施例中，为便于区分，可以将获取并转发合约部署请求的业务节点称为第一业务节点(例如，图5a中的业务节点301b)，将发送合约同步请求的业务节点(例如，图5b中的业务节点301b和业务节点303b)称为第二业务节点，第一业务节点与第二业务节点均可以为业务网络中的任意一个业务节点，第一业务节点和第二业务节点可以是相同的业务节点，也可以是不同的业务节点。
为便于理解，请一并参见图5b，如图5b所示，结合上述图5a中的描述，核心共识网络30c中的共识节点(例如，共识节点301c)基于业务节点301b所转发的合约部署请求A生成了本地合约汇总信息30d；另外，业务网络30b中的业务节点(例如，业务节点301b、业务节点303b)可以将相关的合约信息同步到本地。例如，业务节点301b向核心共识网络30c发送携带有节点标识ID1的合约同步请求B，核心共识网络30c中的共识节点可以对合约同步请求B进行共识，当共识通过时，任一共识节点(例如共识节点301c)可以在本地合约汇总信息30d中查询与节点标识ID1相关的信息；例如，共识节点301c可以在汇总关系映射表30f中查询到包括节点标识ID1的映射关系栏，并将该映射关系栏作为关系映射表301f；其中，关系映射表301f存储有节点标识ID1与合约标识“Local_A”之间的映射关系、以及合约标识“发票”与合约标识“Local_A”之间的映射关系；进而，共识节点可以基于合约标识“Local_A”在汇总合约信息表30e中查询到具有合约标识“Local_A”的合约信息栏，并将该合约信息栏作为本地合约信息表301e；其中，本地合约信息表301e存储有本地合约L1相关的合约信息。随后，共识节点301c可以将关系映射表301f以及本地合约信息表301e作为本地合约信息返回至业务节点301b，业务节点301b可以基于关系映射表301f以及本地合约信息表301e部署本地合约L1。类似地，业务节点303b也可以向核心共识网络30c发送携带有节点标识ID3的合约同步请求C，最终可以获取到关系映射表302f以及本地合约信息表302e，进而可以基于关系映射表302f以及本地合约信息表302e部署本地合约L2。可以理解，经过类似过程，业务节点302b上也可以部署本地合约L1和本地合约L2。
步骤S203，获取用于执行交易业务的初始合约调用请求；在关系映射表中查询与第一合约标识具有第一映射关系的合约标识，将查询到的合约标识确定为与目标链上合约相关联的第二合约标识，将第二合约标识所对应的本地合约确定为目标本地合约，调用目标本地合约执行交易业务所指示的本地业务，得到本地交易执行结果；基于本地交易执行结果和初始合约调用请求，确定用于发送给共识节点的目标合约调用请求，将目标合约调用请求转发至共识节点。
需要说明的是，步骤S203的实现过程步骤S103的实现过程类似，这里不再进行重复描述。
针对本地业务为预检查处理的场景，请一并参见图5c，如图5c所示，结合上述图5b中的描述，业务节点301b已经基于关系映射表301f以及本地合约信息表301e成功部署了本地合约L1(称为目标本地合约)，进而用户终端30g(称为第一用户终端)可 以将携带有合约标识“发票”(称为第一合约标识)的合约调用请求D(称为初始合约调用请求)发送至业务节点301b；从而，业务节点301b可以在关系映射表301f中查找到与合约标识“发票”具有映射关系的合约标识“Local_A”(称为第二合约标识)，进而可以根据合约标识“Local_A”，在本地合约信息表301e中查找到具有合约标识“Local_A”的合约信息栏，因此可以根据合约标识“Local_A”获取本地合约L1，并且可以调用本地合约L1在该合约信息栏中读取到预检查函数S的合约代码；随后，业务节点301b可以通过预检查函数S，在业务节点301b的节点内存中访问本地业务数据T(称为第一本地业务数据)，进而可以基于本地业务数据T对合约调用请求D中的请求参数进行预检查处理(比如，对请求参数进行校验)，并可以将校验成功(称为满足上链条件)的请求参数确定为本地交易执行结果R。这里，业务节点301b可以基于本地交易执行结果R和合约调用请求D，得到合约调用请求D’(称为目标合约调用请求)，可以理解，此时合约调用请求D’与合约调用请求D是相同的请求。最终，业务节点301b可以将合约调用请求D’转发至核心共识网络30c上继续处理，后续核心共识网络30c中的共识节点可以调用合约标识“发票”对应的链上合约C1执行与发票相关的业务(比如，共识业务)，从而可以得到发票数据30h(称为链上交易执行结果)；例如可以包括发票1、发票2以及发票3，进而共识节点可以将发票数据30h打包至待上链区块，并对该待上链区块进行上链处理。可以理解，部署有本地合约L1的业务节点302b同样可以通过类似过程对合约调用请求D进行处理，且业务节点302b与业务节点301b之间互不感知，各自独立执行相应的预检查处理。
本申请实施例提供的基于本地合约的数据处理方法，可以应用于存在不对等节点的区块链系统中。以及，在本申请实施例中，本地合约可以在不同层级的业务节点上执行，并且，业务节点可以先于共识节点调用本地合约对接收到的合约调用请求进行相应的处理(例如，预检查处理、信息补全处理等)，而不需要将所有与合约调用请求相关的操作都积压在共识节点上执行，从而可以减轻共识节点的运算压力，并可以提高区块链网络整体的交易处理效率。另外，在本地合约执行时，业务节点使用自身节点的数据(称为本地业务数据)，能够降低本地业务数据上链所带来的资源消耗，且能够降低多方进行交互所带来的资源消耗，以及能够提升数据隐私安全，减轻共识节点的存储压力。
请参见图6，图6是本申请实施例提供的一种基于智能合约的数据处理方法的流程示意图。如图6所示，该基于智能合约的数据处理方法可以由核心共识网络中的共识节点执行，该共识节点可以为接入至该核心共识网络中的服务器，也可以为接入至该核心共识网络中的用户终端，这里对共识节点的形式不做限定。其中，该共识节点可以为上述图1所示的核心共识网络中的任意一个节点，且共识节点上部署有目标链上合约，例如，节点120a。该共识节点方法至少可以包括步骤S301步骤-步骤S303，下面对各步骤分别进行说明。
步骤S301，获取用于执行交易业务的目标合约调用请求。
在本申请实施例中，共识节点可以接收用于执行交易业务的目标合约调用请求。其中，该目标合约调用请求是指独立于核心共识网络的业务网络中的业务节点基于本地交易执行结果和初始合约调用请求所确定的请求，本地交易执行结果是由业务节点调用目标本地合约执行交易业务所指示的本地业务得到的；目标本地合约是业务节点基于第二合约标识获取到的；第二合约标识是指业务节点基于第一合约标识和第一映射关系，在业务节点中(比如，节点内存中)查询到的与目标链上合约相关联的合约标识；第一合约标识是指初始合约调用请求中用于调用目标链上合约的合约标识；初始合约调用请求用于执行交易业务；目标链上合约部署在共识节点上；共识节点和业务节点中(比如，的节点内存中)均存储有第一合约标识与第二合约标识之间的第一映射关系；第二合约 标识为部署在业务节点上的目标本地合约的合约标识。业务节点执行基于智能合约的数据处理过程可以参见上述图3所对应的描述，这里不再进行重复描述。应当理解，目标合约调用请求携带有第一合约标识。
步骤S302，基于目标合约调用请求中的第一合约标识，调用目标链上合约，通过调用目标链上合约执行交易业务所指示的共识业务，得到链上交易执行结果。
应当理解，共识节点可以基于第一合约标识在多个部署好的链上合约中进行查找，进而可以将第一合约标识对应的链上合约确定为目标链上合约；从而，共识节点可以调用目标链上合约以在该共识节点中(比如，节点内存中)读取链上合约函数，进而可以通过链上合约函数在该共识节点中(比如，节点内存中)访问与共识业务相关联的共识业务数据，以及可以通过共识业务数据执行交易业务所指示的共识业务，得到链上交易执行结果。其中，共识业务是指由共识节点执行的业务(如转移虚拟资产、开具电子票据等)，共识业务的内容与交易业务相关，本申请对此不做限定。另外，对于需要读取数据的链上合约，各个共识节点在业务执行过程中可通过访问自己的账本来进行数据的读取。
步骤S303，根据链上交易执行结果生成待添加至目标区块链的区块，对区块进行上链处理；目标区块链为目标链上合约所属的区块链。
在本申请实施例中，共识节点可以根据链上交易执行结果生成目标交易数据，并且可以将该目标交易数据广播至其它共识节点，随后每个共识节点可以将该目标交易数据放入各自的交易池中等待后续的打包处理。可以理解，可以通过共识算法(例如，leader出块、轮流出块、算力竞争出块等)在多个共识节点中选择一个节点作为第一共识节点(也可称为打包节点、出块节点)，第一共识节点获得记账权后，可以从其交易池中抽取一定数量的交易数据进行打包。当目标交易数据被打包进一个新的区块(称为待上链区块)时，第一共识节点可以将该待上链区块广播至第二共识节点(即核心共识网络中除了第一共识节点之外的节点)，随后第二共识节点可以对该待上链区块进行区块共识，得到区块共识结果，并可以将区块共识结果返回至第一共识节点，若区块共识结果为共识通过结果，则第一共识节点可以将待上链区块添加至目标链上合约所属的区块链中。
可以理解，在执行步骤S301-步骤S303之前，需要在业务节点上部署目标本地合约。请参见图7，图7是本申请实施例提供的另一种基于智能合约的数据处理方法的流程示意图。如图7所示，该基于智能合约的数据处理方法可以由核心共识网络中的共识节点执行。该基于智能合约的数据处理方法至少可以包括步骤S401-步骤S403，下面对各步骤分别进行说明。
步骤S401，获取业务节点转发的由第二用户终端所发送的合约部署请求，对合约部署请求进行共识，当合约部署请求共识通过时，根据合约部署请求生成一个或多个预置本地合约对应的本地合约汇总信息，将本地合约汇总信息存储至共识节点中。
在本申请实施例中，第二用户终端可以将用于部署一个或多个预置本地合约的合约部署请求发送到业务节点，业务节点成功接收后，可以将该合约部署请求通过路由网络中的路由节点转发(或者，直接发送)至共识节点，进而共识节点可以接收该合约部署请求。其中，一个或多个预置本地合约包括目标本地合约。应当理解，合约部署请求可以包括每个预置本地合约分别对应的合约关键字段，其中，合约关键字段至少可以包括以下几种字段，分别为本地合约标识(Local Contract ID，也可称为本地合约编号)、本地合约版本号(Version)、本地合约类型(Type)、本地合约代码(Code)、本地合约描述信息(Desc)、关联合约标识(Chain Contract ID)以及可执行节点标识列表(Executable Node List)。其中，本地合约类型可用于标记每个预置本地合约的调用时机，例如，本地合约类型为A类型的本地合约可在将数据转发到核心共识网络前调用，而本地合约类 型为B类型的本地合约可在数据同步回业务节点后调用；本地合约描述信息可用于描述每个预置本地合约的功能，当然，合约关键字段也可以不包括本地合约描述信息；关联合约标识是指部署在共识节点上的与每个预置本地合约相关联的链上合约的合约标识；可执行节点标识列表可以包括一个或多个可执行节点标识，可执行节点标识是指针对每个预置本地合约具有执行权限的节点(即业务对象指定需要部署每个预置本地合约的业务节点)所对应的节点标识，其中，目标本地合约对应的可执行节点标识列表包括业务节点标识。
此外，合约部署请求还可以包括第二用户终端(即请求发起方)对应的终端签名信息、终端标识以及请求时间戳等通用字段。基于此，共识节点可以对终端签名信息以及终端标识均进行共识；这里，共识节点可以基于第二用户终端对该合约部署请求进行签名时所使用的私钥，重新计算出该合约部署请求期望的签名信息，进而可以将该签名信息与终端签名信息进行比对，若比对结果一致，则确定该合约部署请求通过安全验证(称为共识通过)，表示该合约部署请求在网络传输过程中没有被篡改，否则共识节点可以拒绝该合约部署请求，并可以根据比对结果向第二用户终端返回请求拒绝信息；此外，共识节点还可以通过终端标识获取第二用户终端的部署权限，并对部署权限进行识别，若识别到该部署权限为合法权限，则可以确定该合约部署请求通过权限验证(称为共识通过)，表示第二用户终端有权限将本地合约部署到指定的业务节点上，否则共识节点可以拒绝该合约部署请求，并可以根据识别结果向第二用户终端返回请求拒绝信息。可以理解，不同的业务场景中本地合约的部署会存在不同的分级，因此第二用户终端的部署权限可能与其级别相关。
在本申请实施例中，当终端签名信息以及终端标识均共识通过时，共识节点可以根据合约部署请求中所有预置本地合约对应的本地合约标识、关联合约标识以及可执行节点标识列表，生成汇总关系映射表，该汇总关系映射表可以包括每个预置本地合约分别对应的映射关系栏，每个映射关系栏可用于存储其对应的预置本地合约的本地合约标识与关联合约标识之间的映射关系，以及该本地合约标识与对应的可执行节点标识之间的映射关系。例如，请再次参见图5a，如图5a所示，本地合约L1与本地合约L2为两个预置本地合约，核心共识网络30c中的共识节点(例如，共识节点301c)可以根据合约部署请求A生成汇总关系映射表30f；汇总关系映射表30f可以包括合约标识“Local_A”(即本地合约L1对应的本地合约标识)与合约标识“发票”(即本地合约L1对应的关联合约标识)之间的映射关系，以及合约标识“Local_A”与节点标识ID1、节点标识ID2(即本地合约L1对应的可执行节点标识)之间的映射关系，还有合约标识“Local_B”(即本地合约L2对应的本地合约标识)与合约标识“协作”(即本地合约L2对应的关联合约标识)之间的映射关系，以及合约标识“Local_B”与节点标识ID3(即本地合约L2对应的可执行节点标识)之间的映射关系。
同时，共识节点可以根据所有预置本地合约对应的本地合约标识、本地合约代码、关联合约标识以及可执行节点标识列表，生成汇总合约信息表，该汇总合约信息表可以包括每个预置本地合约分别对应的合约信息栏。如图5a所示，核心共识网络30c中的共识节点(例如，共识节点301c)可以根据合约部署请求A生成汇总合约信息表30e；汇总合约信息表30e存储有本地合约L1以及本地合约L2分别对应的合约信息栏；例如，本地合约L1对应的合约信息栏可以包括合约标识“Local_A”(即本地合约标识)、合约代码“XXXXXX”(即本地合约代码)、合约标识“发票”(即关联合约标识)、可执行节点标识列表[ID1,ID2]。
在本申请实施例中，共识节点可以将上述汇总关系映射表以及汇总合约信息表确定为一个或多个预置本地合约对应的本地合约汇总信息(例如，图5a所示的本地合约汇 总信息30d)，进而可以将该本地合约汇总信息存储至共识节点的节点内存中。
步骤S402，获取业务节点发送的合约同步请求，对合约同步请求进行共识，当合约同步请求共识通过时，基于业务节点标识，在本地合约汇总信息中获取本地合约信息，将本地合约信息发送至业务节点。
应当理解，共识节点用于将本地合约同步给可以执行这个本地合约的业务节点；在同步时，共识节点可以通过访问本地合约部署时的可执行节点标识列表，便可以快速算出可以获取本地合约信息的业务节点，包括：共识节点可以获取业务节点发送的合约同步请求，该合约同步请求可以包括该业务节点的业务节点标识以及节点签名信息，进而可以对该节点签名信息以及业务节点标识进行共识；这里，共识节点可以基于该业务节点对该合约同步请求进行签名时所使用的私钥，重新计算出该合约同步请求期望的签名信息，进而可以将该签名信息与节点签名信息进行比对，若比对结果一致，则确定该合约同步请求通过安全验证，表示该合约同步请求在网络传输过程中没有被篡改，否则共识节点可以拒绝该合约同步请求，并可以根据比对结果向该业务节点返回请求拒绝信息；此外，共识节点还可以通过业务节点标识获取该业务节点的执行权限，并对执行权限进行识别，应当理解，共识节点可以在一个或多个预置本地合约分别对应的可执行节点标识列表中查询是否存在该业务节点标识，若查询到该业务节点标识，则可以识别出该执行权限为合法权限，即确定该合约同步请求通过权限验证，表示该业务节点有权限部署并执行指定的本地合约，否则共识节点可以拒绝该合约同步请求，并可以根据识别结果向该业务节点返回请求拒绝信息。
在本申请实施例中，当节点签名信息以及业务节点标识均共识通过时，共识节点可以基于业务节点标识在汇总关系映射表中进行查询，将查询到的具有与该业务节点标识相同的节点标识的映射关系栏确定为关系映射表。从而，共识节点可以将该关系映射表中的本地合约标识确定为关键合约标识，基于该关键合约标识在汇总合约信息表中进行查询，可以将查询到的与该关键合约标识相同的合约标识的合约信息栏确定为本地合约信息表。随后，共识节点可以将关系映射表以及本地合约信息表确定为本地合约信息，并可以将本地合约信息发送至上述业务节点。其中，关系映射表存储有第一合约标识与第二合约标识之间的第一映射关系以及第二合约标识与该业务节点标识之间的第二映射关系，本地合约信息表可以包括目标本地合约对应的合约信息栏。该业务节点接收到本地合约信息后，可以将本地合约信息存储至该业务节点的节点内存，进而可以基于本地合约信息部署包括目标本地合约在内的一个或多个本地合约。
例如，可以再次参见图5b，如图5b所示，业务节点301b可以向核心共识网络30c中的共识节点(例如共识节点301c)发送合约同步请求B，当合约同步请求B共识通过时，共识节点301c可以先在汇总关系映射表30f中查询到与业务节点301b的节点标识ID1具有映射关系的合约标识“Local_A”(即关键合约标识)，并可将存储有该映射关系的映射关系栏确定为关系映射表301f，进而可以根据合约标识“Local_A”在汇总合约信息表30e中进行查询，并将存在合约标识“Local_A”的合约信息栏确定为本地合约信息表301e，随后可以将关系映射表301f以及本地合约信息表301e返回至业务节点301b。
在本申请实施例中，业务节点和共识节点之间可以建立长连接，则共识节点可以每隔一段时间主动向具有执行权限的业务节点(即本地合约汇总信息中存储的可执行节点标识所对应的业务节点)推送相应的本地合约信息，以使这些业务节点可以将本地合约信息存储至该业务节点的节点内存中，并基于本地合约信息部署指定的本地合约。
需要说明的是，在本地合约信息同步成功后，共识节点可以对其节点内存中的本地合约信息进行删除处理，以减轻数据存储压力；另外，由于业务节点处于公共网络(称 为业务网络)中，可能会被其它网络终端访问，导致本地合约信息被篡改，因此，在本地合约信息同步成功后，共识节点仍然可以在其节点内存中保留该本地合约信息，后续可以基于存储的本地合约信息进行相关验证。
可以理解，当对已经部署的本地合约进行修改(更新或删除)时，也可以通过发起请求的方式来改变本地合约的执行逻辑，该过程与部署本地合约的过程类似。
步骤S403，获取用于执行交易业务的目标合约调用请求，基于目标合约调用请求中的第一合约标识，调用目标链上合约，通过调用目标链上合约执行交易业务所指示的共识业务，得到链上交易执行结果，根据链上交易执行结果生成待添加至目标区块链的区块，对区块进行上链处理。
需要说明的是，步骤S403的实现过程可以参见上述图6所对应的步骤S303，这里不再进行重复描述述。
请一并参见图8，图8是本申请实施例提供的一种数据处理方法的流程示意图。该数据处理方法可以由区块链网络中的任一共识节点执行。如图8所示，该方数据处理法可以包括步骤S1-S5，下面对各步骤分别进行说明。
步骤S1，各共识节点(比如，节点1至节点N)的远程过程调用(Remote Procedure Call，RPC)层获取用户请求(例如，目标合约调用请求)；其中，用户请求也称为交易；RPC层是各共识节点所提供的一种对外接口，可用于获取目标合约调用请求。
步骤S2，各共识节点间相互广播交易，并由其中某一共识节点将若干交易打包成一个区块(称为待上链区块)，并广播给其它共识节点。出块节点(称为第一共识节点)的选择，因共识算法而异，可以包括领导者(Leader)出块，轮流出块，算力竞争出块等。图8中的区块链共识网络即上述的核心共识网络。
步骤S3，各共识节点都收到该区块之后，开始执行该区块里的交易。在逻辑计算层，解析交易参数，并执行合约(称为目标链上合约)。执行过程中包括读取存储(如节点内存)中的数据的处理，如图8中示例的节点1从存储中读取历史交易数据(称为共识业务数据)。
步骤S4，合约执行完毕后，各共识节点对执行结果(即上述的链上交易执行结果)进行互相校验。校验方法可以为将执行结果或对存储的变更组织成结果树(比如，默克尔(Merkle))，通过结果树根哈希将结果树根存储至区块头中，最终校验各共识节点区块哈希一致即可。
步骤S5，共识成功后，各共识节点将本区块相关的数据写入存储；包括区块头，区块包含的所有交易，执行结果等。
上述步骤S1-步骤S5的详细过程可以参见图6所对应的步骤S301-步骤S303，此处不再重复描述。
可以理解的是，共识节点可以联合业务节点，快速实现本地合约的部署与同步。
请参见图9，图9是本申请实施例提供的一种基于智能合约的第一数据处理装置的结构示意图。该第一数据处理装置9-1可以是运行于计算机设备中的一个计算机程序(包括程序代码)；例如，该第一数据处理装置9-1为一个应用软件；该第一数据处理装置9-1可以用于执行本申请实施例提供的方法中的相应步骤。如图9所示，该第一数据处理装置9-1可以运行于业务网络中的业务节点。该第一数据处理装置9-1可以包括：第一获取模块11、第一执行模块12、转发模块13；
第一获取模块11，配置为获取用于执行交易业务的初始合约调用请求；所述初始合约调用请求包括用于调用目标链上合约的第一合约标识；所述目标链上合约部署在核心共识网络的共识节点上，所述核心共识网络独立于所述业务网络；所述共识节点和所述业务节点中均存储有所述第一合约标识与第二合约标识之间的第一映射关系；所述第二 合约标识为部署在所述业务节点上的目标本地合约的合约标识；
第一执行模块12，配置为基于所述第一合约标识和所述第一映射关系，查询所述第二合约标识，基于所述第二合约标识确定所述目标本地合约，通过调用所述目标本地合约执行所述交易业务所指示的本地业务，得到本地交易执行结果；
转发模块13，配置为基于所述本地交易执行结果和所述初始合约调用请求，向所述共识节点发送目标合约调用请求，所述目标合约调用请求用于所述共识节点基于所述第一合约标识获取所述目标链上合约，并通过调用所述目标链上合约执行所述交易业务所指示的共识业务；
在一种实施方式中，业务网络与核心共识网络所在的区块链网络中还包括用于进行网络隔离的路由网络；
上述转发模块13，还配置为基于所述本地交易执行结果和所述初始合约调用请求，通过所述路由网络中的路由节点向所述共识节点发送所述目标合约调用请求。
请参见图9，上述第一数据处理装置9-1还可以包括：请求反馈模块14。
请求反馈模块14，配置为若所述预检查结果表示所述请求参数不满足所述上链条件，则将不满足所述上链条件的所述请求参数确定为非法请求参数，将所述非法请求参数作为所述本地业务对应的所述本地交易执行结果；根据所述非法请求参数生成请求失败信息，将所述请求失败信息返回至发送所述初始合约调用请求的第一用户终端。
请参见图9，上述第一数据处理装置9-1还可以包括：第一合约部署模块15、第一合约同步模块16。
第一合约部署模块15，配置为向所述共识节点转发第二用户终端发送的合约部署请求，所述合约部署请求用于所述共识节点生成一个或多个预置本地合约对应的本地合约信息；所述一个或多个预置本地合约包括所述目标本地合约；
第一合约同步模块16，配置为向所述共识节点发送合约同步请求，所述合约同步请求用于所述共识节点对所述合约同步请求进行共识；所述合约同步请求包括所述业务节点对应的业务节点标识；当所述合约同步请求共识通过时，接收所述共识节点发送的本地合约信息；所述本地合约信息是指所述共识节点基于所述业务节点标识，在所述本地合约汇总信息中获取到的信息；基于所述本地合约信息部署所述目标本地合约。
请参见图9，上述第一执行模块12可以包括：第三查询单元121、读取单元122、执行单元123。
在一种实施方式中，所述业务节点中存储有本地合约信息；所述本地合约信息包括关系映射表；所述关系映射表包括所述第一映射关系。
第三查询单元121，配置为在所述关系映射表中查询与所述第一合约标识具有所述第一映射关系的合约标识，将查询到的合约标识确定为所述第二合约标识，将所述第二合约标识所对应的本地合约确定为所述目标本地合约。
读取单元122，配置为通过调用所述目标本地合约读取所述本地合约信息；
通过读取所述本地合约信息，获取与所述本地业务相关联的本地业务数据；
执行单元123，配置为通过所述本地业务数据执行所述交易业务所指示的所述本地业务，得到所述本地交易执行结果。
请参见图9，上述执行单元123可以包括：预检查子单元1231、信息补全子单元1232。
在一种实施方式中，当所述本地业务数据包括第一本地业务数据时，预检查子单元1231，配置为基于所述第一本地业务数据，对所述初始合约调用请求中的请求参数进行预检查；若预检查结果表示所述请求参数满足上链条件，则将满足所述上链条件的所述请求参数确定为合法请求参数，将所述合法请求参数作为所述本地业务对应的所述本地交易执行结果，所述上链条件为所述本地业务所指示的用于上链的条件。
在一种实施方式中，当所述本地业务数据包括第二本地业务数据时，信息补全子单元1232，配置为基于所述第二本地业务数据，对所述初始合约调用请求中的请求参数进行信息补全；将信息补全后的请求参数作为所述本地业务对应的所述本地交易执行结果。
请参见图10，图10是本申请实施例提供的一种基于智能合约的第二数据处理装置的结构示意图。该第二数据处理装置10-2可以是运行于计算机设备中的一个计算机程序(包括程序代码)，例如，该数据处理装置10-2为一个应用软件；该第二数据处理装置10-2可以用于执行本申请实施例提供的方法中的相应步骤。如图10所示，该第二数据处理装置10-2可以运行于核心共识网络中的共识节点。该第二数据处理装置10-2可以包括：第二获取模块21、第二执行模块22、上链模块23；
第二获取模块21，配置为获取用于执行交易业务的目标合约调用请求；所述目标合约调用请求是业务节点基于本地交易执行结果和初始合约调用请求所发送的，所述业务节点位于独立于所述核心共识网络的业务网络中；所述本地交易执行结果是由所述业务节点通过调用目标本地合约执行所述交易业务所指示的本地业务得到的；所述目标本地合约是所述业务节点基于第二合约标识获取到的；所述第二合约标识是所述业务节点基于第一合约标识和第一映射关系查询到的；所述第一合约标识是指所述初始合约调用请求中用于调用目标链上合约的合约标识；所述初始合约调用请求用于执行所述交易业务；所述目标链上合约部署在所述共识节点上；所述共识节点和所述业务节点中均存储有所述第一合约标识与所述第二合约标识之间的所述第一映射关系；所述第二合约标识为部署在所述业务节点上的所述目标本地合约的合约标识；
第二执行模块22，配置为基于所述目标合约调用请求中的所述第一合约标识，调用所述目标链上合约，通过调用所述目标链上合约执行所述交易业务所指示的共识业务，得到链上交易执行结果。
请参见图10，上述第二数据处理装置10-2还可以包括：第二合约部署模块24、第二合约同步模块25。
第二合约部署模块24，配置为对所述业务节点转发的合约部署请求进行共识，当所述合约部署请求共识通过时，根据所述合约部署请求生成一个或多个预置本地合约对应的本地合约汇总信息；所述合约部署请求由第二用户终端向所述业务节点发送，所述一个或多个预置本地合约包括所述目标本地合约；
第二合约同步模块25，配置为对所述业务节点发送的合约同步请求进行共识；所述合约同步请求包括所述业务节点对应的业务节点标识；当所述合约同步请求共识通过时，基于所述业务节点标识，从所述本地合约汇总信息中获取本地合约信息，将所述本地合约信息发送至所述业务节点，所述本地合约信息用于所述业务节点部署所述目标本地合约。
在一种实施方式中，合约部署请求包括每个预置本地合约分别对应的合约关键字段，合约关键字段包括本地合约标识、本地合约版本号、本地合约类型、本地合约代码、本地合约描述信息、关联合约标识以及可执行节点标识列表；关联合约标识是指部署在共识节点上的与每个预置本地合约相关联的链上合约的合约标识；可执行节点标识列表包括一个或多个可执行节点标识；可执行节点标识是指针对所述每个预置本地合约具有执行权限的节点所对应的节点标识；所述目标本地合约对应的所述可执行节点标识列表包括所述业务节点标识。
在一种实施方式中，合约部署请求还包括第二用户终端对应的终端签名信息以及终端标识；请参见图10，上述第二合约部署模块24可以包括：第一共识单元241、映射表生成单元242、信息表生成单元243、确定存储单元244；
第一共识单元241，配置为对终端签名信息以及终端标识进行共识；
映射表生成单元242，配置为当终端签名信息以及终端标识均共识通过时，根据本地合约标识、关联合约标识以及可执行节点标识列表，生成汇总关系映射表；汇总关系映射表包括一个或多个预置本地合约分别对应的映射关系栏；映射关系栏用于存储本地合约标识与关联合约标识之间的映射关系，以及本地合约标识与可执行节点标识之间的映射关系；
信息表生成单元243，配置为根据本地合约标识、本地合约代码、关联合约标识以及可执行节点标识列表，生成汇总合约信息表；汇总合约信息表包括一个或多个预置本地合约分别对应的合约信息栏；
确定存储单元244，配置为将汇总关系映射表以及汇总合约信息表确定为一个或多个预置本地合约对应的本地合约汇总信息。
在一种实施方式中，合约同步请求还可以包括节点签名信息；
请参见图10，上述第二合约同步模块25可以包括：第二共识单元251、第一查询单元252、第二查询单元253、确定发送单元254；
第二共识单元251，配置为对节点签名信息以及业务节点标识进行共识；
第一查询单元252，配置为当节点签名信息以及业务节点标识均共识通过时，基于业务节点标识在汇总关系映射表中进行查询，将查询到的与业务节点标识相同的节点标识的映射关系栏确定为关系映射表；关系映射表存储有第一映射关系、以及第二合约标识与业务节点标识之间的第二映射关系；
第二查询单元253，配置为将关系映射表中的本地合约标识确定为关键合约标识，基于关键合约标识在汇总合约信息表中进行查询，将查询到的与关键合约标识相同的合约标识的合约信息栏确定为本地合约信息表；本地合约信息表包括目标本地合约对应的合约信息栏；
确定发送单元254，配置为将关系映射表以及本地合约信息表确定为本地合约信息，将本地合约信息发送至业务节点。
在本申请实施例中，上链模块23，配置为根据所述链上交易执行结果生成待添加至目标区块链的区块，对所述区块进行上链处理；所述目标区块链为所述目标链上合约所属的区块链。
请参见图11，是本申请实施例提供的一种计算机设备的结构示意图。如图11所示，该计算机设备1000可以为业务网络中的业务节点或者核心共识网络中的共识节点，该计算机设备1000可以包括：处理器1001，网络接口1004和存储器1005，此外，上述计算机设备1000还可以包括：用户接口1003，和至少一个通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。其中，用户接口1003可以包括显示屏(Display)、键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1004可以是高速随机存取存储器(Random Access Memory，RAM)存储器，也可以是非不稳定的存储器(Non-Volatile Memory)，例如至少一个磁盘存储器。存储器1005可选的还可以是至少一个位于远离前述处理器1001的存储装置。如图11所示，作为一种计算机可读存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及设备控制应用程序。
在如图11所示的计算机设备1000中，网络接口1004可提供网络通讯功能；而用户接口1003主要用于为用户提供输入的接口；而处理器1001可以用于调用存储器1005中存储的设备控制应用程序，以执行本申请实施例提供的基于智能合约的数据处理方法的描述，在此不再重复描述。另外，对采用相同方法的有益效果描述，也不再进行重复描述。
本申请实施例还提供了一种计算机可读存储介质，且上述计算机可读存储介质中存储有前文提及的基于智能合约的第一数据处理装置9-1或者基于智能合约的第二数据处理装置10-2所执行的计算机程序，且上述计算机程序包括程序指令，当上述处理器执行上述程序指令时，能够执行本申请实施例提供的基于智能合约的数据处理方法，因此，这里将不再进行重复描述。另外，对采用相同方法的有益效果描述，也不再进行重复描述。作为示例，程序指令可被部署为在一个电子设备上执行，或者在位于一个地点的多个电子设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个电子设备上执行，分布在多个地点且通过通信网络互连的多个电子设备可以组成区块链系统。
上述计算机可读存储介质可以是本申请实施例提供的基于智能合约的数据处理装置或者上述计算机设备的内部存储单元，例如计算机设备的硬盘或内存。该计算机可读存储介质也可以是该计算机设备的外部存储设备，例如该计算机设备上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。在本申请实施例中，计算机可读存储介质还可以既包括该计算机设备的内部存储单元也包括外部存储设备。计算机可读存储介质用于存储该计算机程序以及该计算机设备所需的其他程序和数据。该计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的数据。
本申请实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备等电子设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该电子设备执行本申请实施例提供的基于智能合约的数据处理方法。
可以理解的是，在本申请实施例中，涉及到交易业务等相关的数据，当本申请实施例运用到具体产品或技术中时，需要获得用户许可或者同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
以上所揭露的仅为本申请较佳实施例而已，当然不能以此来限定本申请之权利范围，因此依本申请权利要求所作的等同变化，仍属本申请所涵盖的范围。

Claims (19)

  1. 一种基于智能合约的数据处理方法，所述方法由业务网络中的业务节点执行，所述业务节点包括至少一个电子设备，包括：
    获取用于执行交易业务的初始合约调用请求；所述初始合约调用请求包括用于调用目标链上合约的第一合约标识；所述目标链上合约部署在核心共识网络的共识节点上，所述核心共识网络独立于所述业务网络；所述共识节点和所述业务节点中均存储有所述第一合约标识与第二合约标识之间的第一映射关系；所述第二合约标识为部署在所述业务节点上的目标本地合约的合约标识；
    基于所述第一合约标识和所述第一映射关系，查询所述第二合约标识，基于所述第二合约标识确定所述目标本地合约，通过调用所述目标本地合约执行所述交易业务所指示的本地业务，得到本地交易执行结果；
    基于所述本地交易执行结果和所述初始合约调用请求，向所述共识节点发送目标合约调用请求，所述目标合约调用请求用于所述共识节点基于所述第一合约标识调用所述目标链上合约，并通过调用所述目标链上合约执行所述交易业务所指示的共识业务。
  2. 根据权利要求1所述的方法，其中，所述业务节点中存储有本地合约信息；所述本地合约信息包括关系映射表；所述关系映射表包括所述第一映射关系；
    所述基于所述第一合约标识和所述第一映射关系，查询所述第二合约标识，基于所述第二合约标识确定所述目标本地合约，包括：
    在所述关系映射表中查询与所述第一合约标识具有所述第一映射关系的合约标识，将查询到的合约标识确定为所述第二合约标识，将所述第二合约标识所对应的本地合约确定为所述目标本地合约。
  3. 根据权利要求2所述的方法，其中，所述通过调用所述目标本地合约执行所述交易业务所指示的本地业务，得到本地交易执行结果，包括：
    通过调用所述目标本地合约读取所述本地合约信息；
    通过读取所述本地合约信息，获取与所述本地业务相关联的本地业务数据；
    通过所述本地业务数据执行所述交易业务所指示的所述本地业务，得到所述本地交易执行结果。
  4. 根据权利要求3所述的方法，其中，当所述本地业务数据包括第一本地业务数据时，所述通过所述本地业务数据执行所述交易业务所指示的所述本地业务，得到所述本地交易执行结果，包括：
    基于所述第一本地业务数据，对所述初始合约调用请求中的请求参数进行预检查；
    若预检查结果表示所述请求参数满足上链条件，则将满足所述上链条件的所述请求参数确定为合法请求参数，将所述合法请求参数作为所述本地业务对应的所述本地交易执行结果，所述上链条件为所述本地业务所指示的用于上链的条件。
  5. 根据权利要求4所述的方法，其中，所述方法还包括：
    若所述预检查结果表示所述请求参数不满足所述上链条件，则将不满足所述上链条件的所述请求参数确定为非法请求参数，将所述非法请求参数作为所述本地业务对应的所述本地交易执行结果；
    根据所述非法请求参数生成请求失败信息，将所述请求失败信息返回至发送所述初始合约调用请求的第一用户终端。
  6. 根据权利要求3所述的方法，其中，当所述本地业务数据包括第二本地业务数据时，所述通过所述本地业务数据执行所述交易业务所指示的所述本地业务，得到所述本地交易执行结果，包括：
    基于所述第二本地业务数据，对所述初始合约调用请求中的请求参数进行信息补全；
    将信息补全后的请求参数作为所述本地业务对应的所述本地交易执行结果。
  7. 根据权利要求1所述的方法，其中，所述业务网络与所述核心共识网络所在的区块链网络中还包括用于进行网络隔离的路由网络；
    所述基于所述本地交易执行结果和所述初始合约调用请求，向所述共识节点发送目标合约调用请求，包括：
    基于所述本地交易执行结果和所述初始合约调用请求，通过所述路由网络中的路由节点向所述共识节点发送所述目标合约调用请求。
  8. 根据权利要求1所述的方法，其中，所述方法还包括：
    向所述共识节点转发第二用户终端发送的合约部署请求，所述合约部署请求用于所述共识节点生成一个或多个预置本地合约对应的本地合约信息；所述一个或多个预置本地合约包括所述目标本地合约；
    向所述共识节点发送合约同步请求，所述合约同步请求用于所述共识节点对所述合约同步请求进行共识；所述合约同步请求包括所述业务节点对应的业务节点标识；
    当所述合约同步请求共识通过时，接收所述共识节点发送的本地合约信息；所述本地合约信息是指所述共识节点基于所述业务节点标识，在所述本地合约汇总信息中获取到的信息；
    基于所述本地合约信息部署所述目标本地合约。
  9. 一种基于智能合约的数据处理方法，所述方法由核心共识网络中的共识节点执行，所述共识节点包括至少一个电子设备，包括：
    获取用于执行交易业务的目标合约调用请求；所述目标合约调用请求是业务节点基于本地交易执行结果和初始合约调用请求所发送的，所述业务节点位于独立于所述核心共识网络的业务网络中；所述本地交易执行结果是由所述业务节点通过调用目标本地合约执行所述交易业务所指示的本地业务得到的；所述目标本地合约是所述业务节点基于第二合约标识获取到的；所述第二合约标识是所述业务节点基于第一合约标识和第一映射关系查询到的；所述第一合约标识是指所述初始合约调用请求中用于调用目标链上合约的合约标识；所述初始合约调用请求用于执行所述交易业务；所述目标链上合约部署在所述共识节点上；所述共识节点和所述业务节点中均存储有所述第一合约标识与所述第二合约标识之间的所述第一映射关系；所述第二合约标识为部署在所述业务节点上的所述目标本地合约的合约标识；
    基于所述目标合约调用请求中的所述第一合约标识，调用所述目标链上合约，通过调用所述目标链上合约执行所述交易业务所指示的共识业务，得到链上交易执行结果。
  10. 根据权利要求9所述的方法，其中，还包括：
    对所述业务节点转发的合约部署请求进行共识，当所述合约部署请求共识通过时，根据所述合约部署请求生成一个或多个预置本地合约对应的本地合约汇总信息；所述合约部署请求由第二用户终端向所述业务节点发送，所述一个或多个预置本地合约包括所述目标本地合约；
    对所述业务节点发送的合约同步请求进行共识；所述合约同步请求包括所述业务节点对应的业务节点标识；
    当所述合约同步请求共识通过时，基于所述业务节点标识，从所述本地合约汇总信息中获取本地合约信息，将所述本地合约信息发送至所述业务节点，所述本地合约信息用于所述业务节点部署所述目标本地合约。
  11. 根据权利要求10所述的方法，其中，所述合约部署请求包括每个预置本地合约分别对应的合约关键字段，所述合约关键字段包括本地合约标识、本地合约版本号、 本地合约类型、本地合约代码、本地合约描述信息、关联合约标识以及可执行节点标识列表；所述关联合约标识是指部署在所述共识节点上的与所述每个预置本地合约相关联的链上合约的合约标识；所述可执行节点标识列表包括一个或多个可执行节点标识；所述可执行节点标识是指针对所述每个预置本地合约具有执行权限的节点所对应的节点标识；所述目标本地合约对应的所述可执行节点标识列表包括所述业务节点标识。
  12. 根据权利要求11所述的方法，其中，所述合约部署请求还包括所述第二用户终端对应的终端签名信息以及终端标识；
    所述对所述业务节点转发的合约部署请求进行共识，当所述合约部署请求共识通过时，根据所述合约部署请求生成一个或多个预置本地合约对应的本地合约汇总信息，包括：
    对所述终端签名信息以及所述终端标识进行共识；
    当所述终端签名信息以及所述终端标识均共识通过时，根据所述本地合约标识、所述关联合约标识以及所述可执行节点标识列表，生成汇总关系映射表；所述汇总关系映射表包括所述一个或多个预置本地合约分别对应的映射关系栏；所述映射关系栏用于存储所述本地合约标识与所述关联合约标识之间的映射关系，以及所述本地合约标识与所述可执行节点标识之间的映射关系；
    根据所述本地合约标识、所述本地合约代码、所述关联合约标识以及所述可执行节点标识列表，生成汇总合约信息表；所述汇总合约信息表包括所述一个或多个预置本地合约分别对应的合约信息栏；
    将所述汇总关系映射表以及所述汇总合约信息表确定为所述一个或多个预置本地合约对应的所述本地合约汇总信息。
  13. 根据权利要求12所述的方法，其中，所述合约同步请求还包括节点签名信息；
    所述对所述业务节点发送的合约同步请求进行共识，当所述合约同步请求共识通过时，基于所述业务节点标识，从所述本地合约汇总信息中获取本地合约信息，包括：
    对所述节点签名信息以及所述业务节点标识进行共识；
    当所述节点签名信息以及所述业务节点标识均共识通过时，基于所述业务节点标识在所述汇总关系映射表中进行查询，将查询到的与所述业务节点标识相同的节点标识的映射关系栏确定为关系映射表；所述关系映射表存储有所述第一映射关系、以及所述第二合约标识与所述业务节点标识之间的第二映射关系；
    将所述关系映射表中的本地合约标识确定为关键合约标识，基于所述关键合约标识在所述汇总合约信息表中进行查询，将查询到的与所述关键合约标识相同的合约标识的合约信息栏确定为本地合约信息表；所述本地合约信息表包括所述目标本地合约对应的合约信息栏；
    将所述关系映射表以及所述本地合约信息表确定为所述本地合约信息。
  14. 根据权利要求9所述的方法，其中，所述通过调用所述目标链上合约执行所述交易业务所指示的共识业务，得到链上交易执行结果之后，所述方法还包括：
    根据所述链上交易执行结果生成待添加至目标区块链的区块，对所述区块进行上链处理；所述目标区块链为所述目标链上合约所属的区块链。
  15. 一种基于智能合约的第一数据处理装置，所述第一数据处理装置存储在业务网络的业务节点中，包括：
    第一获取模块，配置为获取用于执行交易业务的初始合约调用请求；所述初始合约调用请求包括用于调用目标链上合约的第一合约标识；所述目标链上合约部署在核心共识网络的共识节点上，所述核心共识网络独立于所述业务网络；所述共识节点和所述业 务节点中均存储有所述第一合约标识与第二合约标识之间的第一映射关系；所述第二合约标识为部署在所述业务节点上的目标本地合约的合约标识；
    第二执行模块，配置为基于所述第一合约标识和所述第一映射关系，查询所述第二合约标识，基于所述第二合约标识确定所述目标本地合约，通过调用所述目标本地合约执行所述交易业务所指示的本地业务，得到本地交易执行结果；
    转发模块，配置为基于所述本地交易执行结果和所述初始合约调用请求，向所述共识节点发送目标合约调用请求，所述目标合约调用请求用于所述共识节点基于所述第一合约标识获取所述目标链上合约，并通过调用所述目标链上合约执行所述交易业务所指示的共识业务。
  16. 一种基于智能合约的第二数据处理装置，所述第二数据处理装置存储在在核心共识网络的共识节点中，包括：
    第二获取模块，配置为获取用于执行交易业务的目标合约调用请求；所述目标合约调用请求是业务节点基于本地交易执行结果和初始合约调用请求所发送的，所述业务节点位于独立于所述核心共识网络的业务网络中；所述本地交易执行结果是由所述业务节点通过调用目标本地合约执行所述交易业务所指示的本地业务得到的；所述目标本地合约是所述业务节点基于第二合约标识获取到的；所述第二合约标识是所述业务节点基于第一合约标识和第一映射关系查询到的；所述第一合约标识是指所述初始合约调用请求中用于调用目标链上合约的合约标识；所述初始合约调用请求用于执行所述交易业务；所述目标链上合约部署在所述共识节点上；所述共识节点和所述业务节点中均存储有所述第一合约标识与所述第二合约标识之间的所述第一映射关系；所述第二合约标识为部署在所述业务节点上的所述目标本地合约的合约标识；
    第二执行模块，配置为基于所述目标合约调用请求中的所述第一合约标识，调用所述目标链上合约，通过调用所述目标链上合约执行所述交易业务所指示的共识业务，得到链上交易执行结果。
  17. 一种电子设备，包括：处理器、存储器以及网络接口；
    所述处理器与所述存储器、所述网络接口相连，其中，所述网络接口用于提供数据通信功能，所述存储器用于存储程序代码，所述处理器用于调用所述程序代码，以执行权利要求1-8任一项所述的由业务网络中的业务节点执行的基于智能合约的数据处理方法，或者以执行权利要求9-14任一项所述的由核心共识网络中的共识节点执行的基于智能合约的数据处理方法。
  18. 一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序适于由处理器加载并执行权利要求1-8任一项所述的由业务网络中的业务节点执行的基于智能合约的数据处理方法，或者以执行权利要求9-14任一项所述的由核心共识网络中的共识节点执行的基于智能合约的数据处理方法。
  19. 一种计算机程序产品，包括计算机程序或指令，所述计算机程序或指令被处理器执行时，实现权利要求1-8任一项所述的由业务网络中的业务节点执行的基于智能合约的数据处理方法，或者以执行权利要求9-14任一项所述的由核心共识网络中的共识节点执行的基于智能合约的数据处理方法。
PCT/CN2022/104894 2021-08-12 2022-07-11 一种基于智能合约的数据处理方法、装置、电子设备、计算机可读存储介质及计算机程序产品 Ceased WO2023016164A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP22855147.9A EP4300398A4 (en) 2021-08-12 2022-07-11 Smart contract-based data processing method and apparatus, electronic device, computer-readable storage medium, and computer program product
US18/196,878 US20230289782A1 (en) 2021-08-12 2023-05-12 Smart contract-based data processing

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110923438.7 2021-08-12
CN202110923438.7A CN113379422B (zh) 2021-08-12 2021-08-12 基于智能合约的数据处理方法、设备以及可读存储介质

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/196,878 Continuation US20230289782A1 (en) 2021-08-12 2023-05-12 Smart contract-based data processing

Publications (1)

Publication Number Publication Date
WO2023016164A1 true WO2023016164A1 (zh) 2023-02-16

Family

ID=77576994

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/104894 Ceased WO2023016164A1 (zh) 2021-08-12 2022-07-11 一种基于智能合约的数据处理方法、装置、电子设备、计算机可读存储介质及计算机程序产品

Country Status (4)

Country Link
US (1) US20230289782A1 (zh)
EP (1) EP4300398A4 (zh)
CN (2) CN113379422B (zh)
WO (1) WO2023016164A1 (zh)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113379422B (zh) * 2021-08-12 2021-10-15 腾讯科技（深圳）有限公司 基于智能合约的数据处理方法、设备以及可读存储介质
CN117131079B (zh) * 2022-05-19 2025-08-08 腾讯科技（深圳）有限公司 一种基于区块链的数据处理方法、装置、设备及介质
CN117675242A (zh) * 2022-08-26 2024-03-08 抖音视界有限公司 业务请求处理方法、装置、电子设备及存储介质
CN115658806A (zh) * 2022-09-30 2023-01-31 蚂蚁区块链科技(上海)有限公司 区块链系统中的交易执行方法和节点
CN117931933B (zh) * 2022-10-14 2025-10-14 腾讯科技（深圳）有限公司 多区块链数据处理方法、装置、设备、系统以及介质
CN119006150A (zh) * 2023-05-17 2024-11-22 腾讯科技（深圳）有限公司 区块链网络的交易处理方法、装置、产品、设备和介质
CN117118632B (zh) * 2023-08-28 2024-06-11 财智共享(北京)技术服务有限公司 一种基于区块链的函证管理一体机设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111429254A (zh) * 2020-03-19 2020-07-17 腾讯科技（深圳）有限公司 一种业务数据处理方法、设备以及可读存储介质
CN112685505A (zh) * 2021-01-07 2021-04-20 腾讯科技（深圳）有限公司 一种交易数据处理方法、装置、计算机设备及存储介质
US20210203509A1 (en) * 2019-09-12 2021-07-01 Tencent Technology (Shenzhen) Company Limited Data processing method and apparatus in blockchain network, storage medium, and computer device
CN113379422A (zh) * 2021-08-12 2021-09-10 腾讯科技（深圳）有限公司 基于智能合约的数据处理方法、设备以及可读存储介质

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180365201A1 (en) * 2017-06-14 2018-12-20 Clause, Inc. System and method for compound data-driven contracts and documentation
CN107507005B (zh) * 2017-08-01 2020-09-11 众安信息技术服务有限公司 一种基于联盟链的链外数据访问方法和系统
CN109003078B (zh) * 2018-06-27 2021-08-24 创新先进技术有限公司 基于区块链的智能合约调用方法及装置、电子设备
US11276056B2 (en) * 2018-08-06 2022-03-15 Inveniam Capital Partners, Inc. Digital contracts in blockchain environments
CN110851496B (zh) * 2018-12-07 2023-03-14 深圳市智税链科技有限公司 在区块链网络中查询交易信息的方法、装置、记账节点和介质
CN109840429B (zh) * 2019-01-08 2020-04-14 北京众享比特科技有限公司 智能合约部署、调用方法和装置
CN110730204B (zh) * 2019-09-05 2022-09-02 创新先进技术有限公司 区块链网络中删除节点的方法和区块链系统
CN113691597B (zh) * 2019-11-27 2022-06-14 腾讯科技（深圳）有限公司 区块链合约部署方法、装置、设备以及存储介质
CN113032490B (zh) * 2019-12-05 2022-07-12 腾讯科技（深圳）有限公司 一种合约数据处理方法、相关设备及介质
CN111461878A (zh) * 2020-03-10 2020-07-28 杭州溪塔科技有限公司 一种基于链外智能合约的区块链交易处理方法和系统
CN111401903B (zh) * 2020-06-03 2020-09-11 腾讯科技（深圳）有限公司 区块链消息处理方法、装置、计算机以及可读存储介质
CN111770198B (zh) * 2020-08-31 2020-12-18 支付宝(杭州)信息技术有限公司 一种信息共享方法、装置及设备
CN112199186B (zh) * 2020-12-07 2021-03-02 腾讯科技（深圳）有限公司 基于智能合约的数据处理方法、装置、设备及存储介质
CN112632573B (zh) * 2020-12-15 2024-06-21 东软集团股份有限公司 智能合约执行方法、装置、系统、存储介质及电子设备
CN112700246B (zh) * 2020-12-31 2023-11-28 iCALC控股有限公司 基于区块链的数据处理方法、装置、设备及可读存储介质
CN112380149B (zh) * 2021-01-18 2021-04-06 腾讯科技（深圳）有限公司 基于节点内存的数据处理方法、装置、设备以及介质
CN112926982B (zh) * 2021-01-20 2022-08-02 腾讯科技（深圳）有限公司 一种交易数据处理方法、装置、设备及存储介质
CN112907244B (zh) * 2021-02-10 2023-11-28 iCALC控股有限公司 基于区块链的数据处理方法、装置、设备及可读存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210203509A1 (en) * 2019-09-12 2021-07-01 Tencent Technology (Shenzhen) Company Limited Data processing method and apparatus in blockchain network, storage medium, and computer device
CN111429254A (zh) * 2020-03-19 2020-07-17 腾讯科技（深圳）有限公司 一种业务数据处理方法、设备以及可读存储介质
CN112685505A (zh) * 2021-01-07 2021-04-20 腾讯科技（深圳）有限公司 一种交易数据处理方法、装置、计算机设备及存储介质
CN113379422A (zh) * 2021-08-12 2021-09-10 腾讯科技（深圳）有限公司 基于智能合约的数据处理方法、设备以及可读存储介质
CN113988845A (zh) * 2021-08-12 2022-01-28 腾讯科技（深圳）有限公司 基于智能合约的数据处理方法、设备以及可读存储介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4300398A4

Also Published As

Publication number Publication date
CN113379422A (zh) 2021-09-10
CN113988845A (zh) 2022-01-28
CN113988845B (zh) 2022-07-12
US20230289782A1 (en) 2023-09-14
EP4300398A1 (en) 2024-01-03
EP4300398A4 (en) 2024-05-01
CN113379422B (zh) 2021-10-15

Similar Documents

Publication Publication Date Title
WO2023016164A1 (zh) 一种基于智能合约的数据处理方法、装置、电子设备、计算机可读存储介质及计算机程序产品
CN111488393B (zh) 虚拟区块链
CN111989705B (zh) 有许可区块链中的优先级
US20240235817A9 (en) Asset transferring method and apparatus based on multiple blockchains, device, medium, and product
CN110135860B (zh) 一种基于区块链技术的农作物种子安全溯源系统
CN111144881A (zh) 对资产转移数据的选择性访问
KR102139551B1 (ko) 유언장을 관리하는 서버 및 방법
JP2022504348A (ja) ブロックチェーン・リソースを格納するブロックチェーン通知ボード
CN111798233B (zh) 令牌的链接
CN112084186B (zh) 拆分和合并存储
CN113255014A (zh) 一种基于区块链的数据处理方法以及相关设备
CN111340628A (zh) 基于区块链的资产信息管理方法和装置
KR20250038702A (ko) 멀티-블록체인 데이터 처리 방법 및 장치, 그리고 디바이스, 컴퓨터가 판독 가능한 저장 매체 및 컴퓨터 프로그램 제품
WO2024082818A1 (zh) 基于多区块链的跨链处理方法、装置、设备、系统及介质
CN116467062A (zh) 一种基于区块链的数据处理方法、设备以及可读存储介质
CN112883117A (zh) 一种数据同步方法、设备以及计算机可读存储介质
CN117938867A (zh) 一种多区块链数据处理方法、装置、设备、介质及产品
CN112084187B (zh) 存储的拆分和合并
CN120433962A (zh) 一种面向无人机的跨域协作的去中心化数据访问控制方法
CN117931933B (zh) 多区块链数据处理方法、装置、设备、系统以及介质
CN115250354A (zh) 基于区块链网络的资源分配方法、装置、设备及存储介质
WO2024153001A1 (zh) 一种基于分层链网络的数据处理方法、装置、设备及介质
HK40051779B (zh) 基於智能合约的数据处理方法、设备以及可读存储介质
HK40051779A (zh) 基於智能合约的数据处理方法、设备以及可读存储介质
CN113420083A (zh) 一种具有可拓展分布式账本的异构并行区块链结构

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22855147

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 22855147.9

Country of ref document: EP

Ref document number: 2022855147

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2022855147

Country of ref document: EP

Effective date: 20230925

WWE Wipo information: entry into national phase

Ref document number: 11202306404S

Country of ref document: SG

NENP Non-entry into the national phase

Ref country code: DE