A blockchain cross-contract calling method, device, equipment and storage medium

Abstract

Embodiments of the present application disclose a blockchain cross-contract calling method and device, equipment and a storage medium, related embodiments can be applied to various scenes such as cloud technology and intelligent transportation, and are used for improving the blockchain query efficiency. The method of the embodiments of the present application comprises: initially scheduling a first contract instance to execute a statement corresponding to a to-be-processed transaction in a piece, when a first cross-contract calling statement is executed, generating a first auxiliary transaction, scheduling a second contract instance, executing a statement corresponding to the first auxiliary transaction in a piece, when a second cross-contract calling statement is executed, generating a second auxiliary transaction, the first contract instance re-scheduled based on the first cache, executing a statement corresponding to the second auxiliary transaction in a piece, returning the execution result of the second auxiliary transaction to the second contract instance, returning the execution result of the first auxiliary transaction to the initially scheduled first contract instance, when all the statements corresponding to the to-be-processed transaction are executed, storing all the caches in the transaction overall cache into a database.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of secure communication technology, and in particular to a blockchain cross-contract calling method, apparatus, device, and storage medium. Background Art

[0002] The most common smart contract execution engines are the Ethereum Virtual Machine (EVM) and the Java Virtual Machine (JVM), which are used for smart contract development in Solidity and Java, respectively. The EVM can execute arbitrarily complex algorithmic code. Accounts on Ethereum can be divided into external accounts (EOAs) and contract accounts. External accounts are controlled by private keys, while contract accounts are controlled by contract code. In the JVM environment, smart contracts are abstracted into interfaces for invocation.

[0003] When a contract calls another contract, it can usually be implemented based on Ethereum's inter-contract calling schemes such as CALL, CALLCODE, and DELEGATECALL. These schemes essentially execute all calculations in the same virtual machine. The difference is the context switching during the call process. However, contracts can belong to different execution engines, such as Golang, EVM, WASM, etc. Since different contract engines belong to different processes, and the currently commonly used cross-contract calling schemes usually do not have a caching mechanism when exchanging data, it is easy to cause low blockchain query efficiency when the data end is not facing massive query operations on the contract instance side. Summary of the Invention

[0004] The embodiments of the present application provide a blockchain cross-contract calling method, apparatus, device and storage medium for a method of sharing cache for contract instances. When cross-contract calling is performed, if the same contract instance is encountered, the cache of the contract instance can be shared to avoid re-reading and writing data and causing multiple data transmissions, which consumes a lot of time. In addition, the overall transaction cache can be used as a transit station for data transmission and caching to maintain the efficiency and accuracy of the contract instance in calculating and obtaining data, thereby improving the efficiency of blockchain query operations.

[0005] The present invention provides a cross-contract calling method for a blockchain, including:

[0006] When the cross-contract scheduler receives a pending transaction, it initially schedules the first contract instance to execute the statements corresponding to the pending transaction one by one based on the attributes of the pending transaction.

[0007] When the first contract instance of the initial schedule executes the first cross-contract call statement, a first cross-contract call request carrying the first cache corresponding to the first contract instance execution statement and the attributes of the first auxiliary transaction is sent to the cross-contract scheduler, so that the cross-contract scheduler generates a first auxiliary transaction according to the first cross-contract call statement and stores the first cache in the overall transaction cache;

[0008] If the attributes of the first auxiliary transaction are different from the attributes of the pending transaction, the cross-contract scheduler schedules the second contract instance according to the first cross-contract call request, and executes the statements corresponding to the first auxiliary transaction one by one, wherein the second contract instance is different from the first contract instance;

[0009] When the second contract instance executes the second cross-contract call statement, a second cross-contract call request carrying the second cache corresponding to the second contract instance execution statement and the attributes of the second auxiliary transaction is sent to the cross-contract scheduler, so that the cross-contract scheduler generates a second auxiliary transaction according to the second cross-contract call statement and stores the second cache in the overall transaction cache;

[0010] If the attributes of the second auxiliary transaction are the same as those of the pending transaction, the cross-contract scheduler reschedules the first contract instance according to the second cross-contract call request and shares the first cache with the rescheduled first contract instance, so that the rescheduled first contract instance executes the statements corresponding to the second auxiliary transaction one by one based on the first cache.

[0011] When all statements corresponding to the second auxiliary transaction are executed, the execution result of the second auxiliary transaction is returned to the second contract instance, so that the second contract instance executes the statements following the second cross-contract call statement based on the execution result of the second auxiliary transaction;

[0012] When all statements corresponding to the first auxiliary transaction are executed, the execution result of the first auxiliary transaction is returned to the initially scheduled first contract instance, so that the initially scheduled first contract instance executes the statements following the first cross-contract call statement based on the execution result of the first auxiliary transaction;

[0013] When all statements corresponding to the pending transaction are executed, the execution result of the pending transaction is returned to the cross-contract scheduler, so that the cross-contract scheduler stores the execution result of the pending transaction and all caches in the overall transaction cache in the database.

[0014] On the other hand, the present application provides a blockchain cross-contract calling device, including:

[0015] An acquisition unit, configured to, when the cross-contract scheduler receives a pending transaction, initially schedule the first contract instance to execute statements corresponding to the pending transaction one by one according to the attributes of the pending transaction;

[0016] a sending unit, configured to, when the initially scheduled first contract instance executes a first cross-contract call statement, send a first cross-contract call request carrying a first cache corresponding to the first contract instance execution statement and attributes of a first auxiliary transaction to the cross-contract scheduler, so that the cross-contract scheduler generates a first auxiliary transaction according to the first cross-contract call statement and stores the first cache in the overall transaction cache;

[0017] a processing unit, configured to, if the attributes of the first auxiliary transaction are different from the attributes of the to-be-processed transaction, schedule, by the cross-contract scheduler, a second contract instance according to the first cross-contract call request, and execute statements corresponding to the first auxiliary transaction one by one, wherein the second contract instance is different from the first contract instance;

[0018] The sending unit is further configured to, when the second contract instance executes the second cross-contract call statement, send a second cross-contract call request carrying the second cache corresponding to the second contract instance execution statement and the attributes of the second auxiliary transaction to the cross-contract scheduler, so that the cross-contract scheduler generates a second auxiliary transaction according to the second cross-contract call statement and stores the second cache in the overall transaction cache;

[0019] The processing unit is further configured to, if the attributes of the second auxiliary transaction are the same as the attributes of the to-be-processed transaction, cause the cross-contract scheduler to reschedule the first contract instance according to the second cross-contract call request, and share the first cache with the rescheduled first contract instance, so that the rescheduled first contract instance executes statements corresponding to the second auxiliary transaction one by one based on the first cache;

[0020] The processing unit is further configured to return the execution result of the second auxiliary transaction to the second contract instance when all statements corresponding to the second auxiliary transaction are executed, so that the second contract instance executes the statement following the second cross-contract call statement based on the execution result of the second auxiliary transaction;

[0021] The processing unit is further configured to, when all statements corresponding to the first auxiliary transaction are executed, return the execution result of the first auxiliary transaction to the initially scheduled first contract instance, so that the initially scheduled first contract instance executes the statement following the first cross-contract call statement based on the execution result of the first auxiliary transaction;

[0022] The processing unit is also used to return the execution result of the pending transaction to the cross-contract scheduler when all statements corresponding to the pending transaction are executed, so that the cross-contract scheduler stores the execution result of the pending transaction and all caches in the overall transaction cache in the database.

[0023] In one possible design, in an implementation of another aspect of the embodiment of the present application, the acquisition unit may be specifically configured to:

[0024] The blockchain selects pending transactions from the transaction queue and sends them to the cross-contract scheduler;

[0025] When the cross-contract scheduler receives a pending transaction, it creates a task corresponding to the pending transaction;

[0026] Based on the task scheduler, according to the attributes of the pending transaction, the first contract instance is initially scheduled to execute statements corresponding to the pending transaction one by one, wherein the initial scheduling of the first contract instance comes from the first contract virtual machine engine.

[0027] In one possible design, in an implementation of another aspect of the embodiment of the present application, the sending unit may be specifically configured to:

[0028] When the initially scheduled first contract instance executes the first cross-contract call statement, the attributes of the first auxiliary transaction are determined according to the attribute field of the first auxiliary transaction in the first cross-contract call statement;

[0029] The first contract instance initially scheduled generates a first cache based on the statement before the first cross-contract call statement executed;

[0030] Sending a first cross-contract call request carrying attributes of the first cache and the first auxiliary transaction to the cross-contract scheduler;

[0031] When the cross-contract scheduler receives the first cross-contract call request, it generates a first auxiliary transaction according to the first cross-contract call statement;

[0032] The cross-contract scheduler stores the first cache in the cache set corresponding to the first contract instance identifier in the overall transaction cache.

[0033] In one possible design, in an implementation of another aspect of the embodiment of the present application, the processing unit may be specifically configured to:

[0034] The cross-contract scheduler creates the first subtask of the task based on the first auxiliary transaction;

[0035] If the attributes of the first auxiliary transaction are different from the attributes of the transaction to be processed, the task scheduler is used based on the first subtask to schedule the second contract instance to execute the statements corresponding to the first auxiliary transaction one by one according to the attributes of the first auxiliary transaction, wherein the second contract instance originates from the first contract virtual machine engine or the second contract virtual machine engine, and the first contract virtual machine engine is different from the second contract virtual machine engine.

[0036] In one possible design, in an implementation of another aspect of the embodiment of the present application, the sending unit may be specifically configured to:

[0037] When the second contract instance executes the second cross-contract call statement, the attributes of the second auxiliary transaction are determined based on the attribute field of the second auxiliary transaction in the second cross-contract call statement.

[0038] The second contract instance generates a second cache based on the statement before the executed second cross-contract call statement;

[0039] Sending a second cross-contract call request carrying the attributes of the second cache and the second auxiliary transaction to the cross-contract scheduler;

[0040] When the cross-contract scheduler receives the second cross-contract call request, it generates a second auxiliary transaction according to the second cross-contract call statement;

[0041] The cross-contract scheduler stores the second cache in the cache set corresponding to the second contract instance identifier in the overall transaction cache.

[0042] In one possible design, in an implementation of another aspect of the embodiment of the present application, the processing unit may be specifically configured to:

[0043] The cross-contract scheduler creates a second subtask of the task based on the second auxiliary transaction;

[0044] If the attributes of the second auxiliary transaction are the same as the attributes of the pending transaction, then using the task scheduler based on the second subtask, reschedule the first contract instance according to the attributes of the second auxiliary transaction;

[0045] The cross-contract scheduler shares the first cache with the rescheduled first contract instance, so that the rescheduled first contract instance executes the statements corresponding to the first auxiliary transaction one by one.

[0046] In one possible design, in an implementation of another aspect of the embodiment of the present application, the processing unit may be specifically configured to:

[0047] When the first contract instance is rescheduled to execute all statements corresponding to the second auxiliary transaction, the execution result of the second auxiliary transaction and the first cache corresponding to all executed statements are returned to the cross-contract scheduler;

[0048] The cross-contract scheduler stores the received first entire cache into the cache set corresponding to the first contract instance identifier in the overall transaction cache;

[0049] The cross-contract scheduler sends the received execution result of the second auxiliary transaction to the second contract instance, so that the second contract instance executes the statement after the second cross-contract call statement based on the execution result.

[0050] In one possible design, in an implementation of another aspect of the embodiment of the present application, the processing unit may be specifically configured to:

[0051] When the second contract instance completes executing all statements corresponding to the first auxiliary transaction, it returns the execution result of the first auxiliary transaction and the second full cache corresponding to executing all statements to the cross-contract scheduler;

[0052] The cross-contract scheduler stores the received second entire cache into the cache set corresponding to the second contract instance identifier in the overall transaction cache;

[0053] The cross-contract scheduler sends the execution result of the received first auxiliary transaction to the initially scheduled first contract instance, so that the initially scheduled first contract instance executes the statement after the first cross-contract call statement based on the execution result.

[0054] In one possible design, in an implementation of another aspect of the embodiment of the present application, the processing unit may be specifically configured to:

[0055] When the first contract instance initially scheduled completes executing all statements corresponding to the pending transaction, it returns the execution result of the pending transaction and the third full cache corresponding to all executed statements to the cross-contract scheduler;

[0056] The cross-contract scheduler stores the received third entire cache into the cache set corresponding to the first contract instance identifier in the overall transaction cache;

[0057] The cross-contract scheduler stores the execution results of the pending transactions, as well as the first cache, the first total cache, and the third total cache corresponding to the first contract identifier in the overall transaction cache, and the second cache and the second total cache corresponding to the second contract identifier in the blockchain database.

[0058] In one possible design, in an implementation of another aspect of the embodiment of the present application, the processing unit may be specifically configured to:

[0059] The cross-contract scheduler returns the execution result of the pending transaction, as well as the first cache, the first total cache, and the third total cache corresponding to the first contract identifier in the overall transaction cache, and the second cache and the second total cache corresponding to the second contract identifier to the blockchain;

[0060] The first cache, the first total cache, the third total cache, the second cache, and the second total cache are traversed respectively. If a conflicting cache exists, the conflicting cache is corrected to obtain a corrected cache and store it in the database.

[0061] In one possible design, in an implementation of another aspect of the embodiment of the present application, the processing unit may be specifically configured to:

[0062] Resend the transaction corresponding to the conflict cache to the cross-contract scheduler so that the cross-contract scheduler receives the transaction to be corrected and creates a correction task corresponding to the transaction to be corrected;

[0063] Based on the correction task, the task scheduler is used to schedule the contract instance to execute the statements corresponding to the transaction to be corrected one by one according to the attributes of the transaction to be corrected;

[0064] When the contract instance completes executing all statements corresponding to the transaction to be corrected, the execution results of the transaction to be corrected and the correction cache of all statements corresponding to the transaction to be corrected are stored in the database, and the conflict cache and the execution results corresponding to the conflict cache are deleted.

[0065] In one possible design, in an implementation of another aspect of the embodiment of the present application, the processing unit may be specifically configured to:

[0066] The cross-contract scheduler returns the execution result of the pending transaction, as well as the first cache, the first total cache, and the third total cache corresponding to the first contract identifier in the overall transaction cache, and the second cache and the second total cache corresponding to the second contract identifier to the blockchain;

[0067] The first cache, the first total cache, the third total cache, the second cache, and the second total cache are traversed respectively. If there is no conflicting cache, the execution result of the pending transaction and the first cache, the first total cache, and the third total cache corresponding to the first contract identifier in the overall transaction cache, as well as the second cache and the second total cache corresponding to the second contract identifier are written into the blockchain cache snapshot, so that the blockchain cache snapshot updates all the written caches into the database in units of blocks.

[0068] Another aspect of the present application provides a computer device, comprising: a memory, a processor, and a bus system;

[0069] Wherein, the memory is used to store programs;

[0070] The processor is used to implement the above-mentioned methods when executing the program in the memory;

[0071] The bus system is used to connect the memory and the processor so that the memory and the processor can communicate with each other.

[0072] Another aspect of the present application provides a computer-readable storage medium, wherein instructions are stored in the computer-readable storage medium. When the computer-readable storage medium is run on a computer, the computer is enabled to execute the above-mentioned methods.

[0073] It can be seen from the above technical solutions that the embodiments of the present application have the following beneficial effects:

[0074] By initially scheduling the first contract instance, the statements corresponding to the pending transaction are executed one by one. When the initially scheduled first contract instance executes the first cross-contract call statement, the first auxiliary transaction and the first cache are generated. When the attributes of the first auxiliary transaction are different from those of the pending transaction, the second contract instance different from the first contract instance is scheduled to execute the statements corresponding to the first auxiliary transaction one by one. When the second cross-contract call statement is executed, a second auxiliary transaction is generated. When the attributes of the second auxiliary transaction are the same as those of the pending transaction, the first cache is shared with the rescheduled first contract instance to execute the statements corresponding to the second auxiliary transaction one by one. Then, the execution result of the second auxiliary transaction by the rescheduled first contract instance is returned to the second contract instance, and the execution result of the first auxiliary transaction by the second contract instance is returned to the initially scheduled first contract instance. Finally, when the initially scheduled first contract instance completes execution of all statements corresponding to the pending transaction, all caches in the overall transaction cache are stored in the database. Through the above method, the caches generated by all contract instances when executing transaction statements can be stored in the overall transaction cache, so that when a cross-contract call statement is executed and the same attribute appears to call the same contract instance, the same contract instance can be previously stored in the cache set corresponding to the same contract instance identifier in the overall transaction cache, and shared to the rescheduled same contract instance to avoid re-reading and writing data and causing multiple data transmissions and consuming a lot of time. In addition, the overall transaction cache can be used as a transit station for data transmission and caching to maintain the efficiency and accuracy of the contract instance in calculating and obtaining data, thereby improving the efficiency of blockchain query operations. BRIEF DESCRIPTION OF THE DRAWINGS

[0075] Figure 1 (a) is a schematic diagram of a blockchain distributed system architecture of a data control system in an embodiment of the present application;

[0076] FIG1( b ) is a block diagram of a data control system in an embodiment of the present application;

[0077] FIG1( c ) is an interactive schematic diagram of a data control system in an embodiment of the present application;

[0078] Figure 2 This is a flowchart of an embodiment of the blockchain cross-contract calling method in the embodiment of the present application;

[0079] Figure 3 This is another flowchart of the blockchain cross-contract calling method in the embodiment of the present application;

[0080] Figure 4 This is another flowchart of the blockchain cross-contract calling method in the embodiment of the present application;

[0081] Figure 5This is another flowchart of the blockchain cross-contract calling method in the embodiment of the present application;

[0082] Figure 6 This is another flowchart of the blockchain cross-contract calling method in the embodiment of the present application;

[0083] Figure 7 This is another flowchart of the blockchain cross-contract calling method in the embodiment of the present application;

[0084] Figure 8 This is another flowchart of the blockchain cross-contract calling method in the embodiment of the present application;

[0085] Figure 9 This is another flowchart of the blockchain cross-contract calling method in the embodiment of the present application;

[0086] Figure 10 This is another flowchart of the blockchain cross-contract calling method in the embodiment of the present application;

[0087] Figure 11 This is another flowchart of the blockchain cross-contract calling method in the embodiment of the present application;

[0088] Figure 12 This is another flowchart of the blockchain cross-contract calling method in the embodiment of the present application;

[0089] Figure 13 This is another flowchart of the blockchain cross-contract calling method in the embodiment of the present application;

[0090] Figure 14 This is a schematic diagram of the principle flow of the blockchain cross-contract calling method in the embodiment of this application;

[0091] Figure 15 This is a flowchart of a blockchain cross-contract calling method for generating a new transaction in an embodiment of the present application;

[0092] Figure 16 This is a flowchart of a blockchain cross-contract calling method for correcting a conflict cache in an embodiment of the present application;

[0093] Figure 17 This is a schematic diagram of a shared cache cross-contract call data structure of a blockchain cross-contract call method in an embodiment of the present application;

[0094] Figure 18 This is a schematic diagram of an embodiment of a blockchain cross-contract calling device in an embodiment of the present application;

[0095] Figure 19 It is a schematic diagram of an embodiment of a computer device in an embodiment of the present application. DETAILED DESCRIPTION

[0096] The embodiments of the present application provide a blockchain cross-contract calling method, apparatus, device and storage medium for a method of sharing cache for contract instances. When cross-contract calling is performed, if the same contract instance is encountered, the cache of the contract instance can be shared to avoid re-reading and writing data and causing multiple data transmissions, which consumes a lot of time. In addition, the overall transaction cache can be used as a transit station for data transmission and caching to maintain the efficiency and accuracy of the contract instance in calculating and obtaining data, thereby improving the efficiency of blockchain query operations.

[0097] The terms "first," "second," "third," "fourth," and the like (if any) in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequential sequence. It should be understood that the terms used in this manner are interchangeable where appropriate, so that the embodiments of the application described herein can, for example, be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "corresponding to," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such process, method, product, or apparatus.

[0098] To facilitate understanding, some terms or concepts involved in the embodiments of this application are first explained.

[0099] 1. Blockchain: A distributed ledger technology in the information technology field, generally composed of consensus, transaction blocks and status data storage, cryptographic identity security, etc. Because the ledger is stored in a distributed manner and the blocks are agreed upon, it has the characteristics of being tamper-proof, traceable, and jointly maintained.

[0100] 2. Shared cache: Shared cache is a mechanism for sharing the running cache among different running instances. Through shared cache, instances can obtain the values ​​of certain status data in advance, avoiding inefficient status data query operations.

[0101] 3. Smart Contract: A program that runs on a blockchain. Unlike regular programs, smart contracts must ensure that the results of their execution are identical on every node in the blockchain network. This allows any node to verify the correctness of the smart contract's execution results in the block.

[0102] 4. Cross-contract call: The process of one contract calling another contract through code.

[0103] It is understandable that in the specific implementation of this application, when data related to pending transactions, the first cache, and the second cache are applied to specific products or technologies, user permission or consent is required, and the collection, use, and processing of relevant data must comply with relevant laws, regulations, and standards of relevant countries and regions.

[0104] It can be understood that the system involved in the blockchain cross-contract calling method disclosed in this application can be a distributed system formed by connecting a client and multiple nodes (any form of computing device connected to the network, such as a server and a user terminal) through network communication.

[0105] Taking a blockchain system as an example, see Figure 1(a). Figure 1(a) shows an optional schematic diagram of the distributed system 100 provided by an embodiment of the present invention, applied to a blockchain system. The distributed system 100 comprises multiple nodes (any type of computing device connected to a network, such as a server or user terminal) and clients. The nodes form a peer-to-peer (P2P) network. The P2P protocol is an application layer protocol running on top of the Transmission Control Protocol (TCP). In a distributed system, any machine, such as a server or terminal, can join and become a node. A node comprises a hardware layer, a middle layer, an operating system layer, and an application layer.

[0106] Referring to Figure 1(a), the functions of each node in the blockchain system include:

[0107] 1) Routing: A basic function of a node, used to support communication between nodes.

[0108] In addition to the routing function, nodes can also have the following functions:

[0109] 2) Applications are deployed in the blockchain to implement specific services based on actual business needs. They record data related to the implementation of the functions to form record data. The record data carries a digital signature to indicate the source of the task data. The record data is sent to other nodes in the blockchain system for other nodes to add to the temporary block when they successfully verify the source and integrity of the record data.

[0110] For example, the services implemented by the application include:

[0111] 2.1) Wallet: This provides functionality for conducting electronic currency transactions, including initiating transactions (i.e., sending the current transaction record to other nodes in the blockchain system. Upon successful verification by other nodes, the transaction record data is stored in a temporary block on the blockchain as a response to acknowledge the transaction's validity). The wallet also supports querying the remaining electronic currency in an electronic currency address.

[0112] 2.2) Shared ledgers are used to store, query, and modify account data. Records of operations on account data are sent to other nodes in the blockchain system. After verification, other nodes acknowledge the validity of the account data by storing the recorded data in a temporary block. They can also send confirmation to the node that initiated the operation.

[0113] 2.3) Smart contracts are computerized protocols that can enforce the terms of a contract. They are implemented through code deployed on a shared ledger that is executed when certain conditions are met. Based on actual business needs, the code is used to complete automated transactions, such as querying the logistics status of a buyer's purchased goods and transferring the buyer's electronic currency to the merchant's address after the buyer signs for the goods. Of course, smart contracts are not limited to executing contracts for transactions; they can also execute contracts that process received information.

[0114] 3) Blockchain, including a series of blocks that are connected to each other in the order of their generation. Once a new block is added to the blockchain, it will not be removed. The block records the record data submitted by the nodes in the blockchain system.

[0115] See Figure 1(b), which shows an optional schematic diagram of a block structure provided by an embodiment of the present invention. Each block includes the hash value of the transaction records stored in the block (the hash value of the current block) and the hash value of the previous block. Blocks are connected by hash values ​​to form a blockchain. Blockchains can also include information such as the timestamp of the block's generation. A blockchain is essentially a decentralized database, a series of data blocks generated using cryptographic methods. Each data block contains relevant information used to verify the validity of the information (to prevent counterfeiting) and generate the next block.

[0116] It should be understood that the blockchain cross-contract calling method provided in this application can be applied to various scenarios, including but not limited to artificial intelligence, cloud technology, maps, smart transportation, etc., and is used to perform cross-contract calls by sharing the cache corresponding to the same contract instance to complete query operations on the blockchain, and can be applied to scenarios such as salary payment, virtual game currency transactions, and commodity purchase transactions.

[0117] In order to solve the above problems, the present application proposes a blockchain cross-contract call method, which is applied to a data control system. The method executes the statements corresponding to the pending transaction one by one by initially scheduling the first contract instance. When the initially scheduled first contract instance executes the first cross-contract call statement, a first auxiliary transaction and a first cache are generated. When the attributes of the first auxiliary transaction are different from the attributes of the pending transaction, a second contract instance different from the first contract instance is scheduled to execute the statements corresponding to the first auxiliary transaction one by one. When the second cross-contract call statement is executed, a second auxiliary transaction is generated. When the attributes of the second auxiliary transaction are the same as the attributes of the pending transaction, the first cache is shared with the rescheduled first contract instance to execute the statements corresponding to the second auxiliary transaction one by one. Then, the execution result of the second auxiliary transaction by the rescheduled first contract instance is returned to the second contract instance, and the execution result of the first auxiliary transaction by the second contract instance is returned to the initially scheduled first contract instance. Finally, when the initially scheduled first contract instance completes execution of all statements corresponding to the pending transaction, all caches in the overall transaction cache are stored in the database. Through the above method, the caches generated by all contract instances when executing transaction statements can be stored in the overall transaction cache, so that when a cross-contract call statement is executed and the same attribute appears to call the same contract instance, the same contract instance can be previously stored in the cache set corresponding to the same contract instance identifier in the overall transaction cache, and shared to the rescheduled same contract instance to avoid re-reading and writing data and causing multiple data transmissions and consuming a lot of time. In addition, the overall transaction cache can be used as a transit station for data transmission and caching to maintain the efficiency and accuracy of the contract instance in calculating and obtaining data, thereby improving the efficiency of blockchain query operations.

[0118] It is understandable that this application proposes a blockchain cross-contract calling method, which is applied to data control systems. In actual scenarios, more types of terminal devices can participate in the data processing process. Terminal devices include but are not limited to mobile phones, computers, intelligent voice interaction devices, smart home appliances, car terminals, etc. The specific number and type depend on the actual scenario and are not limited here. In addition, in actual scenarios, multiple servers can also participate, especially in the scenario of multi-model training interaction. The number of servers depends on the actual scenario and is not limited here.

[0119] It should be noted that in this embodiment, the server can be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. Terminal devices and servers can be connected directly or indirectly via wired or wireless communications, and terminal devices and servers can be connected to form a blockchain network, which is not limited in this application.

[0120] For ease of understanding, please refer to Figure 1 (c). Figure 1 (c) is an interactive diagram of the data control system in an embodiment of the present application. As shown in Figure 1 (c), transaction processing mainly includes the blockchain side and the smart contract virtual machine engine side. First, the transaction queue on the blockchain side will put all pending tasks (pending transactions) into the transaction queue, and the transaction queue will send pending transactions to the smart contract virtual machine engine in batches; secondly, when the smart contract virtual machine engine accepts the task, it will notify the task scheduler as needed and schedule the process manager to call the appropriate contract instance process to execute the task; then, the contract instance process executes the corresponding contract code according to the received task and forms a read-write set cache; finally, after the task is completed, the execution result and the corresponding read-write set cache of the contract instance are returned to the blockchain cache snapshot, so that the cache snapshot will update the accumulated cache in blocks to the database, and all transactions are completed.

[0121] Combined with the above introduction, the following will introduce the blockchain cross-contract calling method in this application, please refer to Figure 2 In the embodiment of the present application, an embodiment of the blockchain cross-contract calling method includes:

[0122] In step S101, when the cross-contract scheduler receives a pending transaction, it initially schedules the first contract instance to execute the statements corresponding to the pending transaction one by one according to the attributes of the pending transaction;

[0123] In this embodiment, the transaction queue on the blockchain side will first place all pending transactions to be executed in the transaction queue, and the transaction queue will send the pending transactions to the cross-contract scheduler in batches. When the cross-contract scheduler receives the pending transactions, it can select the smart contract virtual machine engine according to the attributes of the pending transactions, and send the pending transactions to the selected smart contract virtual machine engine. Through the process manager, the first contract instance is initially scheduled to execute the statements corresponding to the pending transactions one by one.

[0124] It is understandable that in order to better implement cross-contract calls, this embodiment samples Figure 15 The following is a method for implementing cross-contract calls based on newly generated transactions. The specific process is as follows:

[0125] 1) When a blockchain generates a block, it can obtain a batch of transactions from the transaction pool and execute them in sequence;

[0126] 2) If the transactions in the current batch have not been completed, remove a transaction;

[0127] 3) Schedule the contract instance to execute the transaction;

[0128] 4) Execute a statement of the transaction;

[0129] 5) If the return statement is executed, it returns directly and schedules the contract instance to run the next transaction;

[0130] 6) Otherwise, determine whether the cross-contract call statement is executed;

[0131] 7) If not, continue executing the next statement;

[0132] 8) Otherwise, a new transaction is generated and the contract instance is called to continue executing step 3 for the new transaction;

[0133] 9) Wait for all transactions to be executed and all scheduling to be completed.

[0134] The cross-contract scheduler is used by the blockchain side to schedule the smart contract virtual machine engine to execute transactions. The first contract instance is used to refer to a contract instance in general, which can be a salary transaction contract, a securities transaction contract, an account verification contract, etc. There is no specific restriction here, such as Figure 14 The attributes of the pending transaction may include transaction name, transaction type, and special transaction identifier, etc., which are not specifically limited here.

[0135] For ease of understanding, Figure 14 As shown, this embodiment is subsequently introduced using a cross-contract call with a depth of 3 as an example. The first and third depth layers are both from contract 1, and the second layer is from contract 2. Here, the cross-contract scheduling is responsible for managing the calls and status synchronization of all contract instances, and the status database is responsible for the final storage status. It can be understood that the actual application scenario may involve multiple layers of depth and multiple contract instances, and no specific restrictions are made here.

[0136] Specifically, if Figure 14 As shown, when the cross-contract scheduler receives a pending transaction, it can initiate a task to a smart contract virtual machine engine (such as Figure 14 1. Initiate a task), based on the initiation of the task Figure 14The depth shown is 1, the first contract instance is initially scheduled (such as Figure 14 The contract 1 in the depth 1 shown in the figure) reads and writes the contract code and related data corresponding to the pending transaction, and can initially schedule the first contract instance according to the attributes of the pending transaction (such as transaction type) as described above. Figure 15 Execute the corresponding statements of the pending transaction one by one (such as Figure 14 Read and write data at depth 1 as shown).

[0137] It should be noted that the blockchain in this embodiment supports contract engine capabilities, the blockchain has cross-contract calling capabilities, and the contract instances have caching capabilities.

[0138] In step S102, when the initially scheduled first contract instance executes the first cross-contract call statement, a first cross-contract call request carrying the first cache corresponding to the first contract instance execution statement and the attributes of the first auxiliary transaction is sent to the cross-contract scheduler, so that the cross-contract scheduler generates a first auxiliary transaction according to the first cross-contract call statement and stores the first cache in the overall transaction cache;

[0139] In this embodiment, the first cross-contract call statement is used to indicate the code statement that needs to be cross-contracted, which may specifically include the attribute fields of the transaction and other key fields of the transaction. The first cache is used to represent the stage cache generated from the first statement corresponding to the pending transaction to the first cross-contract call statement executed by the first contract instance (e.g. Figure 14 (The first half of the depth 1 cache of Contract 1 is shown in the figure). The first auxiliary transaction is a new transaction that needs to be executed on top of the pending transaction. That is, the pending transaction can only be completed after the new transaction is executed. For example, when executing the salary payment transaction of Object A (the pending transaction), the account authentication transaction of Object A (the first auxiliary transaction) must also be completed before the salary payment transaction of Object A (the pending transaction) can be continued.

[0140] Specifically, if Figure 14 As shown, when the first contract instance of the initial schedule executes the first cross-contract call statement, the first cross-contract call request (such as Figure 14 The depth shown is 1, which sends 2 to the cross-contract scheduler and requests a cross-contract call).

[0141] Furthermore, based on the above Figure 15 In the execution steps, this embodiment can generate a first auxiliary transaction (i.e., Figure 15 Generate a new transaction as shown), and store the first cache to the transaction overall cache (such as Figure 14 The depth 1 is shown in the figure. The cross-contract scheduler 3 executes the first cross-contract call request to schedule the contract 1 depth 1 front half cache to the transaction overall cache.

[0142] In step S103, if the first auxiliary transaction attribute is different from the attribute of the transaction to be processed, the cross-contract scheduler schedules a second contract instance according to the first cross-contract call request, and executes the statements corresponding to the first auxiliary transaction one by one, wherein the second contract instance is different from the first contract instance.

[0143] In this embodiment, if the first auxiliary transaction attribute is different from the attribute of the transaction to be processed in the first cross-contract call request obtained by the cross-contract scheduler, a second contract instance different from the first contract instance can be scheduled to execute the statements corresponding to the first auxiliary transaction one by one, so as to maintain the safe execution of the first auxiliary transaction, and the calculation and transmission of the contract instance data.

[0144] The attribute of the first auxiliary transaction is used to generally refer to the attribute of other transactions different from the transaction to be processed, which can be specifically transaction name, transaction type, special transaction identifier, etc., which is not limited here.

[0145] Specifically, as shown in the figure, when a new transaction, i.e. the first auxiliary transaction, is generated, it can be first determined whether the first auxiliary transaction attribute is the same as the attribute of the transaction to be processed. If not, it can be understood that other contract instances, i.e. the second contract instance, different from the first contract instance need to be called. Therefore, the cross-contract scheduler initiates a subtask to depth 2 as shown in the figure, so that depth 2 can schedule the second contract instance according to the first cross-contract call request, such as contract 2 in depth 2 as shown in the figure, to execute the statements corresponding to the first auxiliary transaction one by one, such as read-write data in depth 2 as shown in the figure. Figure 14 Figure 14 Figure 14 Figure 14

[0146] In step S104, when the second contract instance executes the second cross-contract call statement, a second cross-contract call request carrying the second cache corresponding to the second contract instance execution statement and the attribute of the second auxiliary transaction is sent to the cross-contract scheduler, so that the cross-contract scheduler generates the second auxiliary transaction according to the second cross-contract call statement, and stores the second cache to the transaction overall cache.

[0147] In this embodiment, the second cross-contract call statement is used to indicate the code statement that needs to be cross-contracted, which can specifically include the attribute field of the transaction and other key fields of the transaction. The second cache is used to represent the stage cache generated by the second contract instance executing the first statement corresponding to the first auxiliary transaction to the first cross-contract call statement (such as the cache in depth 2 as shown in the figure). Figure 14 ​​​​The second auxiliary transaction is a new transaction that needs to be executed after the first auxiliary transaction. That is, the first auxiliary transaction and pending transactions must be completed only after the new transaction is executed. For example, when executing the salary payment transaction of object A (the pending transaction), the account verification transaction of object A (the first auxiliary transaction) must be completed, and the frozen funds status query transaction of object A (the second auxiliary transaction) must also be executed before the account verification transaction of object A (the first auxiliary transaction) can be executed, and then the salary payment transaction of object A (the pending transaction) can be executed.

[0148] Specifically, if Figure 14 As shown, when the second contract instance of the initial schedule executes the second cross-contract call statement, a second cross-contract call request (such as Figure 14 The depth 2 shown sends 5 to the cross-contract scheduler, requesting a cross-contract call).

[0149] Furthermore, based on the above Figure 15 In the execution steps, this embodiment can generate a second auxiliary transaction (i.e., Figure 15 Generate a new transaction as shown), and store the second cache in the overall transaction cache (such as Figure 14 The depth 2 shown is executed by the cross-contract scheduler 6, synchronizing the first half of the depth 2 cache of contract 2 to the overall transaction cache).

[0150] In step S105, if the attributes of the second auxiliary transaction are the same as the attributes of the pending transaction, the cross-contract scheduler reschedules the first contract instance according to the second cross-contract call request and shares the first cache with the rescheduled first contract instance, so that the rescheduled first contract instance executes the statements corresponding to the second auxiliary transaction one by one based on the first cache.

[0151] In this embodiment, if the attributes of the second auxiliary transaction are the same as the attributes of the transaction to be processed in the second cross-contract call request obtained by the cross-contract scheduler, the first contract instance can be rescheduled and the first cache can be shared with the rescheduled first contract instance, so that the rescheduled first contract instance can execute the statements corresponding to the second auxiliary transaction one by one based on the first cache to maintain the safe execution of the second auxiliary transaction, as well as the calculation and acquisition of transmission data of the contract instance.

[0152] The attributes of the second auxiliary transaction are used to generally refer to the attributes of other transactions different from the transaction to be processed, and may specifically be manifested as transaction name, transaction type, special transaction identifier, etc., which are not specifically limited here.

[0153] Specifically, if Figure 14 As shown, when generating a new transaction, i.e., the second auxiliary transaction, it is possible to first determine whether the attributes of the second auxiliary transaction are the same as those of the pending transaction. If they are the same, it can be understood that the same contract instance is encountered and a shared cache can be performed, i.e., the first contract instance needs to be re-called. Therefore, the cross-contract scheduler can send Figure 14 The depth 3 initiated subtask and the shared first cache (such as Figure 14 The cross-contract scheduler shown in the figure executes 7 to depth 3, initiates a subtask, and sends the first half of the cache of contract 1), so that depth 3 can start a new contract process according to the first cross-contract call request and reschedule the first contract instance (such as Figure 14 As shown in the depth 3 of the contract 1), execute the statements corresponding to the second auxiliary transaction one by one (such as Figure 14 Read and write data at depth 3 as shown).

[0154] In step S106, when all statements corresponding to the second auxiliary transaction are executed, the execution result of the second auxiliary transaction is returned to the second contract instance, so that the second contract instance executes the statement following the second cross-contract call statement based on the execution result of the second auxiliary transaction;

[0155] It is understandable that if Figure 17 As shown, since the transaction cache as a whole is essentially a recursive call in the cross-contract call, that is, the initial contract instance of the first layer calls the contract instance of the second layer, and similarly, the second layer contract instance calls the contract instance of the third layer, and so on. The contract call of the next layer can be carried out in sequence. Then, when the contract instance of each layer is executed, it will return to the contract instance of the previous layer to continue execution. For example, when the contract instance of the third layer is executed, it will return to the contract instance of the second layer for execution. When the contract instance of the second layer is executed, it will return to the contract instance of the first layer to continue execution, and so on until the initial contract of the first layer is executed.

[0156] When executing a contract instance at each layer, a read-write set is generated, which can be used to detect cache conflicts and modify the final database. The overall transaction cache in this embodiment can be used to store the final database on the one hand, and to accelerate data acquisition of running contract instances on the other hand.

[0157] Among them, such as Figure 17 As shown, the cross-contract call data structure of the shared cache has the following relationship:

[0158] a) Data mapping, the read and write sets of different contracts will not conflict (the key contains the contract information), and the same contract shares the cache, so, for example Figure 17As shown, the cached data can be divided by contract name, such as contract name 1 is mapped to read-write data 1, so as to facilitate the screening of contract cache and share or transfer.

[0159] b) Read and write data, including cached data involved in the contract execution process.

[0160] i. Read the set (such as Figure 17 The contract name 1 shown is mapped to the read set in read-write data 1, such as key 1 and its corresponding value, key 2 and its corresponding value, etc.), and the cache generated by requesting data during contract execution.

[0161] ii. Write a collection (e.g. Figure 17 The contract name 1 shown is mapped to the write set in read-write data 1, such as key 1 and its corresponding value, key 2 and its corresponding value, etc.), and the cache generated by the request to write data during the contract execution.

[0162] Therefore, if Figure 14 As shown, when all statements corresponding to the second auxiliary transaction are executed, it can return to the call of the contract instance of the upper layer, that is, return the execution result of the second auxiliary transaction to the second contract instance (such as Figure 14 10, return result), so that the second contract instance continues to execute the statements after the second cross-contract call statement according to the execution steps shown in 15 above based on the execution result of the second auxiliary transaction.

[0163] In step S107, when all statements corresponding to the first auxiliary transaction are executed, the execution result of the first auxiliary transaction is returned to the initially scheduled first contract instance, so that the initially scheduled first contract instance executes the statements following the first cross-contract call statement based on the execution result of the first auxiliary transaction;

[0164] Specifically, based on the above recursive call principle, such as Figure 14 As shown, when all statements corresponding to the first auxiliary transaction are executed, it is possible to return to the call of the contract instance of the upper layer, that is, to return the execution result of the first auxiliary transaction to the first contract instance of the initial scheduling and share the first all cached to the initial first contract instance (such as Figure 14 13, return result, send contract 1 all cache), so that the first contract instance of the initial call can continue to execute the statements after the second cross-contract call statement according to the execution steps shown in 15 above based on the execution result of the second auxiliary transaction.

[0165] In step S108, when all statements corresponding to the pending transaction are executed, the execution result of the pending transaction is returned to the cross-contract scheduler, so that the cross-contract scheduler stores the execution result of the pending transaction and all caches in the overall transaction cache in the database.

[0166] Specifically, based on the above recursive call principle, such as Figure 14 As shown, when all the statements corresponding to the pending transaction are executed, it can be understood that the execution of the initial contract instance is completed, and the execution result of the pending transaction is returned to the cross-contract scheduler (such as Figure 14 14, return result), so that the cross-contract scheduler stores the execution results of the pending transaction and all the caches in the overall transaction cache into the database (such as Figure 14 16, storage and delivery).

[0167] In an embodiment of the present application, a blockchain cross-contract calling method is provided. Through the above method, the caches generated by all contract instances when executing transaction statements can be stored in the transaction overall cache, so that when a cross-contract calling statement is executed and the same attribute appears to call the same contract instance, the same contract instance can be previously stored in the cache set corresponding to the same contract instance identifier in the transaction overall cache, and shared to the rescheduled same contract instance to avoid re-reading and writing data to cause multiple data transmissions and consume a lot of time. In addition, the transaction overall cache can also be used as a transit station for data transmission and caching to maintain the efficiency and accuracy of the contract instance in calculating and obtaining data, thereby improving the efficiency of blockchain query operations.

[0168] Optionally, in the above Figure 2 On the basis of the corresponding embodiment, in another optional embodiment of the blockchain cross-contract calling method provided in the embodiment of the present application, as Figure 3 As shown, in step S101, when the cross-contract scheduler receives a pending transaction, it initially schedules the first contract instance to execute the statements corresponding to the pending transaction one by one according to the attributes of the pending transaction, including:

[0169] In step S301, the blockchain selects pending transactions from the transaction queue and sends them to the cross-contract scheduler;

[0170] In step S302, when the cross-contract scheduler receives a pending transaction, it creates a task corresponding to the pending transaction;

[0171] In step S303, based on the task scheduler used, according to the attributes of the pending transaction, the first contract instance is initially scheduled to execute statements corresponding to the pending transaction one by one, wherein the initial scheduling of the first contract instance comes from the first contract virtual machine engine.

[0172] In this embodiment, the transaction queue on the blockchain side will first place all pending transactions to be executed into the transaction queue. The blockchain selects pending transactions from the transaction queue and sends them to the cross-contract scheduler. When the cross-contract scheduler receives the pending transactions, it selects the smart contract virtual machine engine and establishes the task corresponding to the pending transactions. Then, based on the task, the task scheduler is used to initially schedule the first contract instance to execute the statements corresponding to the pending transactions one by one according to the attributes of the pending transactions.

[0173] The initial scheduling of the first contract instance originates from a first contract virtual machine engine. The first contract virtual machine engine generally refers to a smart contract virtual machine engine capable of supporting contract engine capabilities. The smart contract virtual machine engine may include a task scheduler, a process manager, and multiple contract running instances.

[0174] Specifically, if Figure 14 As shown, after the blockchain selects pending transactions from the transaction queue, it can send them to the cross-contract scheduler. When the cross-contract scheduler receives the pending transactions, it can initiate a task to a smart contract virtual machine engine (such as Figure 14 1. Initiate a task), use the task scheduler based on the task, schedule the process, and start the contract instance process through the process manager (such as Figure 14 Depth 1 as shown), to initially schedule the first contract instance (such as Figure 14 The contract 1 in the depth 1 shown in the figure) reads and writes the contract code and related data corresponding to the pending transaction, and can initially schedule the first contract instance according to the attributes of the pending transaction (such as transaction type) as described above. Figure 15 The execution steps shown are to execute the statements corresponding to the pending transactions one by one (such as Figure 14 Read and write data at depth 1 as shown).

[0175] Optionally, in the above Figure 2 On the basis of the corresponding embodiment, in another optional embodiment of the blockchain cross-contract calling method provided in the embodiment of the present application, as Figure 4 As shown, in step S102, when the first contract instance of the initial schedule executes the first cross-contract call statement, a first cross-contract call request carrying the first cache corresponding to the first contract instance execution statement and the attributes of the first auxiliary transaction is sent to the cross-contract scheduler, including:

[0176] In step S401, when the initially scheduled first contract instance executes the first cross-contract call statement, the attributes of the first auxiliary transaction are determined according to the attribute field of the first auxiliary transaction in the first cross-contract call statement;

[0177] In step S402, the first contract instance initially scheduled generates a first cache based on the statement before the first cross-contract call statement executed;

[0178] In step S403, a first cross-contract call request carrying the first cache and the attributes of the first auxiliary transaction is sent to the cross-contract scheduler;

[0179] In step S404, when the cross-contract scheduler receives the first cross-contract call request, it generates a first auxiliary transaction according to the first cross-contract call statement;

[0180] In step S405 , the cross-contract scheduler stores the first cache into the cache set corresponding to the first contract instance identifier in the overall transaction cache.

[0181] In this embodiment, when the first contract instance initially scheduled executes the first cross-contract call statement, the attributes of the first auxiliary transaction can be determined according to the attribute field of the first auxiliary transaction in the first cross-contract call statement. The first contract instance initially scheduled generates a first cache based on the statement before the executed first cross-contract call statement, and sends a first cross-contract call request carrying the first cache and the attributes of the first auxiliary transaction to the cross-contract scheduler, so that when the cross-contract scheduler receives the first cross-contract call request, it can generate a first auxiliary transaction according to the first cross-contract call statement and store it in the cache set corresponding to the first contract instance identifier in the overall transaction cache, so as to facilitate subsequent sharing and transmission of the cache to maintain the efficiency of data transmission, thereby improving the efficiency of blockchain query operations to a certain extent.

[0182] The first contract instance identifier is used to indicate the first contract instance, and can be specifically expressed as the name of the first contract instance (such as Figure 17 The cache set corresponding to the first contract instance identifier is used to indicate the read and write data sets with a mapping relationship for the first contract instance (such as Figure 17 The read and write data corresponding to the contract name 1 shown).

[0183] Specifically, if Figure 14 As shown, when the first contract instance of the initial scheduling executes the first cross-contract call statement, the attributes of the first auxiliary transaction can be determined according to the attribute field of the first auxiliary transaction in the first cross-contract call statement. At the same time, in order to better realize the memory sharing of the same contract, this embodiment can record the running instance cache of each contract instance (such as Figure 17 The running instance cache shown in the figure, and the read set and write set included in the running instance cache), that is, when the first contract instance initially scheduled executes the first cross-contract call statement, the running instance cache of the statement before the first cross-contract call statement executed by the first contract instance initially scheduled can be recorded, that is, the first cache.

[0184] Furthermore, the process of the first contract instance initially scheduled may send a first cross-contract call request (such as Figure 14 The depth shown is 1, which sends 2 to the cross-contract scheduler and requests a cross-contract call).

[0185] Furthermore, when the cross-contract scheduler receives the first cross-contract call request, it can be based on the above Figure 15 The execution step is to generate a first auxiliary transaction according to the first cross-contract call statement through the cross-contract scheduler (i.e. Figure 15 Generate a new transaction as shown), and store the first cache in the cache set corresponding to the first contract instance identifier in the overall transaction cache (such as Figure 14 The depth 1 shown is executed by the cross-contract scheduler 3, synchronizing the first half of the depth 1 cache of contract 1 to the overall transaction cache).

[0186] Optionally, in the above Figure 3 On the basis of the corresponding embodiment, in another optional embodiment of the blockchain cross-contract calling method provided in the embodiment of the present application, as Figure 5 As shown, in step S103, if the attributes of the first auxiliary transaction are different from the attributes of the transaction to be processed, the cross-contract scheduler schedules the second contract instance according to the first cross-contract call request and executes the statements corresponding to the first auxiliary transaction one by one, including:

[0187] In step S501, the cross-contract scheduler creates a first subtask of the task based on the first auxiliary transaction;

[0188] In step S502, if the attributes of the first auxiliary transaction are different from the attributes of the transaction to be processed, the task scheduler is used based on the first subtask to schedule the second contract instance to execute the statements corresponding to the first auxiliary transaction one by one according to the attributes of the first auxiliary transaction, wherein the second contract instance originates from the first contract virtual machine engine or the second contract virtual machine engine, and the first contract virtual machine engine is different from the second contract virtual machine engine.

[0189] In this embodiment, after the cross-contract scheduler generates the first auxiliary transaction, the first subtask of the task can be established based on the first auxiliary transaction. Then, if the attributes of the first auxiliary transaction are different from the attributes of the transaction to be processed in the first cross-contract call request obtained by the cross-contract scheduler, the task scheduler can be used based on the first subtask to schedule the second contract instance different from the first contract instance according to the attributes of the first auxiliary transaction to execute the statements corresponding to the first auxiliary transaction one by one, so as to maintain the safe execution of the first auxiliary transaction and maintain the efficiency of the contract instance in calculating and obtaining transmission data.

[0190] The first subtask is used to refer to the subtasks under the tasks created by the cross-contract scheduler (such as Figure 14 (See 4. Initiate subtask in the illustration.) The second contract instance originates from the first contract virtual machine engine or the second contract virtual machine engine, where the first contract virtual machine engine is different from the second contract virtual machine engine. The second contract virtual machine engine is generally used to refer to a smart contract virtual machine engine with contract capabilities different from the first contract virtual machine engine.

[0191] Specifically, if Figure 14 As shown, after the cross-contract scheduler generates the first auxiliary transaction, the first subtask of the task can be established according to the first auxiliary transaction (such as Figure 14 4. Initiate subtasks) Based on the generation of a new transaction, namely the first auxiliary transaction, it can be judged whether the attributes of the first auxiliary transaction are the same as those of the pending transaction. If they are different, it can be understood that it is necessary to call another contract instance different from the first contract instance, namely the second contract instance. Therefore, the cross-contract scheduler sends a Figure 14 The depth 2 shown initiates a subtask to use the task scheduler based on the first subtask, and the scheduling process manager is turned on so that Figure 14 The contract process at depth 2 shown in the figure can schedule a second contract instance (such as Figure 14 As shown in the depth 2 of the contract 2), according to the above Figure 15 The execution steps shown are to execute the statements corresponding to the first auxiliary transaction one by one (such as Figure 14 Read and write data at depth 2 as shown).

[0192] Optionally, in the above Figure 2 On the basis of the corresponding embodiment, in another optional embodiment of the blockchain cross-contract calling method provided in the embodiment of the present application, as Figure 6 As shown, in step S104, when the second contract instance executes the second cross-contract call statement, a second cross-contract call request carrying the second cache corresponding to the second contract instance execution statement and the attributes of the second auxiliary transaction is sent to the cross-contract scheduler, including:

[0193] In step S601, when the second contract instance executes the second cross-contract call statement, the attributes of the second auxiliary transaction are determined according to the attribute field of the second auxiliary transaction in the second cross-contract call statement;

[0194] In step S602, the second contract instance generates a second cache based on the statement before the executed second cross-contract call statement;

[0195] In step S603, a second cross-contract call request carrying the attributes of the second cache and the second auxiliary transaction is sent to the cross-contract scheduler;

[0196] In step S604, when the cross-contract scheduler receives the second cross-contract call request, it generates a second auxiliary transaction according to the second cross-contract call statement;

[0197] In step S605, the cross-contract scheduler stores the second cache in the cache set corresponding to the second contract instance identifier in the overall transaction cache.

[0198] In this embodiment, when the initially scheduled second contract instance executes the second cross-contract call statement, the attributes of the second auxiliary transaction can be determined according to the attribute field of the second auxiliary transaction in the second cross-contract call statement. The initially scheduled second contract instance generates a second cache based on the statement before the executed second cross-contract call statement, and sends a second cross-contract call request carrying the second cache and the attributes of the second auxiliary transaction to the cross-contract scheduler, so that when the cross-contract scheduler receives the second cross-contract call request, it can generate a second auxiliary transaction according to the second cross-contract call statement and store it in the cache set corresponding to the second contract instance identifier in the overall transaction cache, so as to facilitate subsequent sharing and transmission of the cache, so as to maintain the efficiency of data transmission, thereby improving the efficiency of blockchain query operations to a certain extent.

[0199] The second contract instance identifier is used to indicate the second contract instance, and can be specifically expressed as the name of the second contract instance (such as Figure 17 The cache set corresponding to the second contract instance identifier is used to indicate the read and write data sets with a mapping relationship for the second contract instance (such as Figure 17 The read and write data corresponding to the contract name 2 shown).

[0200] Specifically, if Figure 14 As shown, when the second contract instance of the initial scheduling executes the second cross-contract call statement, the attributes of the second auxiliary transaction can be determined according to the attribute field of the second auxiliary transaction in the second cross-contract call statement. At the same time, in order to better realize the memory sharing of the same contract, this embodiment can record the running instance cache of each contract instance (such as Figure 17 The running instance cache shown in the figure, and the read set and write set included in the running instance cache), that is, when the initially scheduled second contract instance executes the second cross-contract call statement, the running instance cache of the statement before the second cross-contract call statement executed by the initially scheduled second contract instance can be recorded, that is, the second cache.

[0201] Furthermore, the process of the second contract instance initially scheduled may send a second cross-contract call request (such as Figure 14 The depth 1 shown sends 5 to the cross-contract scheduler, requesting a cross-contract call).

[0202] Furthermore, when the cross-contract scheduler receives the second cross-contract call request, it can be based on the above Figure 15 The execution step is to generate a second auxiliary transaction (i.e. Figure 15 Generate a new transaction as shown), and store the second cache in the cache set corresponding to the second contract instance identifier in the overall transaction cache (such as Figure 14 The depth 2 shown is executed by the cross-contract scheduler 6, synchronizing the first half of the depth 2 cache of contract 2 to the overall transaction cache).

[0203] Optionally, in the above Figure 3 On the basis of the corresponding embodiment, in another optional embodiment of the blockchain cross-contract calling method provided in the embodiment of the present application, as Figure 7 As shown, in step S105, if the second auxiliary transaction attribute is the same as the attribute of the pending transaction, the cross-contract scheduler reschedules the first contract instance according to the second cross-contract call request and shares the first cache with the rescheduled first contract instance, including:

[0204] In step S701, the cross-contract scheduler creates a second subtask of the task based on the second auxiliary transaction;

[0205] In step S702, if the attributes of the second auxiliary transaction are the same as the attributes of the pending transaction, then based on the second subtask, the task scheduler is used to reschedule the first contract instance according to the attributes of the second auxiliary transaction;

[0206] In step S703, the cross-contract scheduler shares the first cache with the rescheduled first contract instance, so that the rescheduled first contract instance executes the statements corresponding to the first auxiliary transaction one by one.

[0207] In this embodiment, after the cross-contract scheduler generates a second auxiliary transaction, a second subtask of the task can be established based on the second auxiliary transaction. Then, if the attributes of the second auxiliary transaction are the same as the attributes of the transaction to be processed in the second cross-contract call request obtained by the cross-contract scheduler, the task scheduler can be used based on the second subtask to reschedule the first contract instance according to the attributes of the second auxiliary transaction, and share the first cache to the rescheduled first contract instance, so that the rescheduled first contract instance can execute the statements corresponding to the second auxiliary transaction one by one based on the first cache, so as to maintain the safe execution of the second auxiliary transaction, and maintain the efficiency of the contract instance in calculating and obtaining transmission data.

[0208] The second subtask is used to refer to the subtasks under the tasks created by the cross-contract scheduler (such as Figure 14Schematic 7, initiate subtask). The second subtask is different from the first subtask, wherein the second subtask can be in a parallel relationship or an inclusive relationship with the first subtask (for example, the first subtask includes the second subtask).

[0209] Specifically, if Figure 14 As shown, after the cross-contract scheduler generates the second auxiliary transaction, the second subtask of the task can be established according to the second auxiliary transaction (such as Figure 14 7. Initiate subtasks) Based on the generation of a new transaction, namely the second auxiliary transaction, it can be determined whether the attributes of the second auxiliary transaction are the same as those of the pending transaction. If they are the same, it can be understood that the same contract instance is encountered and a shared cache can be performed. Therefore, the cross-contract scheduler sends a request to the following transaction: Figure 14 The depth 3 shown initiates a subtask to use the task scheduler based on the second subtask, and the scheduling process manager is turned on so that Figure 14 The contract process at depth 3 shown in the figure can call the first contract instance again, and the cross-contract scheduler can send Figure 14 The contract processes at depth 3 shown share the first cache (e.g. Figure 14 The cross-contract scheduler shown in the figure executes 7 to depth 3, initiates a subtask, and sends the first half of the cache of contract 1), so that the contract process at depth 3 is based on the first cache, as described above. Figure 15 The execution steps shown are to execute the statements corresponding to the second auxiliary transaction one by one (such as Figure 14 Read and write data at depth 3 as shown).

[0210] Optionally, in the above Figure 2 On the basis of the corresponding embodiment, in another optional embodiment of the blockchain cross-contract calling method provided in the embodiment of the present application, as Figure 8 As shown, step S106 returns the execution result of the second auxiliary transaction to the second contract instance when all statements corresponding to the second auxiliary transaction are executed, including:

[0211] In step S801, when the first contract instance is rescheduled to execute all statements corresponding to the second auxiliary transaction, the execution result of the second auxiliary transaction and the first full cache corresponding to the execution of all statements are returned to the cross-contract scheduler;

[0212] In step S802, the cross-contract scheduler stores the received first entire cache into the cache set corresponding to the first contract instance identifier in the overall transaction cache;

[0213] In step S803, the cross-contract scheduler sends the received execution result of the second auxiliary transaction to the second contract instance, so that the second contract instance executes the statement after the second cross-contract call statement based on the execution result.

[0214] In this embodiment, when the first contract instance is rescheduled to execute all statements corresponding to the second auxiliary transaction, the execution result of the second auxiliary transaction and the first full cache corresponding to the execution of all statements can be returned to the cross-contract scheduler, so that the cross-contract scheduler can store the received first full cache in the cache set corresponding to the first contract instance identifier in the overall transaction cache, and send the received execution result of the second auxiliary transaction to the second contract instance, so that the second contract instance executes the statement after the second cross-contract call statement based on the execution result, so as to maintain the smooth and complete execution of the subsequent first auxiliary transaction, and maintain the efficiency of the contract instance in calculation and acquisition of transmission data.

[0215] Among them, the first full cache indicates that the first contract instance has completed the execution of all statements corresponding to the second auxiliary transaction, and the resulting running instance cache (such as Figure 17 The first full cache can be used to share with other running first contract instances.

[0216] Specifically, based on the above recursive call principle, such as Figure 14 As shown, when the first contract instance is rescheduled to execute all the statements corresponding to the second auxiliary transaction, it can return to the call of the contract instance on the upper layer, that is, return the execution result of the second auxiliary transaction to the cross-contract scheduler (such as Figure 14 10, return result), and return the first complete cache corresponding to the execution of all statements to the cross-contract scheduler (such as Figure 14 9, synchronize all caches of contract 1 at depth 3), so that the second contract instance can continue to execute the statements after the second cross-contract call statement according to the execution steps shown in 15 above based on the execution result of the second auxiliary transaction.

[0217] For example, when rescheduling the first contract instance (such as Figure 14 After the contract 1 at depth 3 executes all the statements of the frozen fund status query transaction (i.e., the second auxiliary transaction) of object A, the execution result of the frozen fund status query transaction (i.e., the second auxiliary transaction) of object A can be returned to the call of the contract instance at the upper layer (e.g., Figure 14 The depth 2 of the contract 2 is shown), so that the second contract instance (such as Figure 14 Contract 2 at depth 2 shown in the figure can continue to execute the statements after the second cross-contract call statement in the account authentication transaction of object A (i.e., the first auxiliary transaction).

[0218] Optionally, in the above Figure 8 On the basis of the corresponding embodiment, in another optional embodiment of the blockchain cross-contract calling method provided in the embodiment of the present application, as Figure 9As shown, in step S107, when all statements corresponding to the first auxiliary transaction are executed, the execution result of the first auxiliary transaction is returned to the initially scheduled first contract instance, so that the initially scheduled first contract instance executes the statements after the first cross-contract call statement based on the execution result of the first auxiliary transaction, including:

[0219] In step S901, when the second contract instance completes executing all statements corresponding to the first auxiliary transaction, it returns the execution result of the first auxiliary transaction and the second full cache corresponding to executing all statements to the cross-contract scheduler;

[0220] In step S902, the cross-contract scheduler stores the received second entire cache into the cache set corresponding to the second contract instance identifier in the overall transaction cache;

[0221] In step S903, the cross-contract scheduler sends the received execution result of the first auxiliary transaction to the initially scheduled first contract instance, so that the initially scheduled first contract instance executes the statement after the first cross-contract call statement based on the execution result.

[0222] In this embodiment, when the second contract instance completes executing all statements corresponding to the first auxiliary transaction, it can return the execution result of the first auxiliary transaction and the second full cache corresponding to the execution of all statements to the cross-contract scheduler, so that the cross-contract scheduler can store the received second full cache in the cache set corresponding to the second contract instance identifier in the overall transaction cache, and send the received execution result of the first auxiliary transaction to the initially scheduled first contract instance, so that the initially scheduled first contract instance can execute the statement after the second cross-contract call statement based on the execution result, so as to maintain the smooth and complete execution of subsequent pending transactions, as well as maintain the efficiency of the contract instance's calculation and acquisition of transmission data.

[0223] Among them, the second full cache indicates that the second contract instance has completed the execution of all statements corresponding to the first auxiliary transaction, and the resulting running instance cache (such as Figure 17 The second full cache can be used to share with other running second contract instances.

[0224] Specifically, based on the above recursive call principle, such as Figure 14 As shown, when the second contract instance completes the execution of all statements corresponding to the first auxiliary transaction, it can return to the call of the contract instance of the upper layer, that is, return the execution result of the first auxiliary transaction to the cross-contract scheduler (such as Figure 14 11, return result), and return the second cache corresponding to the execution of all statements to the cross-contract scheduler (such as Figure 1412, synchronize all caches of contract 2 depth 2), and at the same time, the cross-contract scheduler can share the first entire cache corresponding to the first contract instance identifier with the initially scheduled first contract instance, so that the initially scheduled first contract instance can continue to execute the statements after the first cross-contract call statement according to the execution steps shown in 15 above based on the execution result of the first auxiliary transaction and the first entire cache.

[0225] For example, when the second contract instance (such as Figure 14 After the contract 2 of depth 2 has executed all the statements of the account authentication transaction (i.e. the first auxiliary transaction), the execution result of the account authentication transaction (i.e. the first auxiliary transaction) of object A can be returned to the call of the contract instance of the upper layer (e.g. Figure 14 The depth 1 of the contract 1 is shown as follows), so that the first contract instance of the initial schedule (such as Figure 14 Contract 1 at depth 1 shown in the figure can continue to execute the statements after the first cross-contract call statement in object A's salary payment transaction (i.e., the pending transaction).

[0226] Optionally, in the above Figure 9 On the basis of the corresponding embodiment, in another optional embodiment of the blockchain cross-contract calling method provided in the embodiment of the present application, as Figure 10 As shown, step S108 returns the execution result of the pending transaction to the cross-contract scheduler when all statements corresponding to the pending transaction are executed, including:

[0227] In step S1001, when the initially scheduled first contract instance completes executing all statements corresponding to the pending transaction, it returns the execution result of the pending transaction and the third full cache corresponding to executing all statements to the cross-contract scheduler;

[0228] In step S1002, the cross-contract scheduler stores the received third full cache into the cache set corresponding to the first contract instance identifier in the overall transaction cache;

[0229] In step S1003, the cross-contract scheduler stores the execution result of the pending transaction, as well as the first cache, the first total cache, and the third total cache corresponding to the first contract identifier in the overall transaction cache, and the second cache and the second total cache corresponding to the second contract identifier in the database of the blockchain.

[0230] In this embodiment, when the initially scheduled first contract instance completes execution of all statements corresponding to the pending transaction, it can return the execution result of the pending transaction and the third full cache corresponding to the execution of all statements to the cross-contract scheduler, so that the cross-contract scheduler can store the received third full cache in the cache set corresponding to the first contract instance identifier in the overall transaction cache, and enable the cross-contract scheduler to store the execution result of the pending transaction, as well as the first cache, first full cache and third full cache corresponding to the first contract identifier in the overall transaction cache, and the second cache and second full cache corresponding to the second contract identifier in the database of the blockchain, so as to complete the smooth and complete execution of the pending transaction and maintain the efficiency of the contract instance in calculating and obtaining transmission data.

[0231] Among them, the third all cache indicates that the first contract instance of the initial scheduling has completed all the statements corresponding to the pending transaction, and the resulting running instance cache (such as Figure 17 The third overall cache can be used to share with other running first contract instances.

[0232] Specifically, based on the above recursive call principle, such as Figure 14 As shown, when the first contract instance of the initial schedule completes the execution of all statements corresponding to the pending transaction, it can be understood that the task transaction is completed, and the execution result of the pending transaction can be returned to the cross-contract scheduler (such as Figure 14 14, return result), and return the third cache corresponding to the execution of all statements to the cross-contract scheduler (such as Figure 14 15, synchronize all caches of contract 1 depth 1), so that the cross-contract scheduler can execute the results of pending transactions (such as Figure 14 14, return result), and store the first cache, the first total cache and the third total cache corresponding to the first contract identifier in the transaction overall cache, and the second cache and the second total cache corresponding to the second contract identifier in the blockchain database (such as Figure 14 16, storage and delivery).

[0233] For example, when the first contract instance is initially scheduled (e.g. Figure 14 After contract 1 at depth 1 completes executing all statements of the account authentication transaction (i.e., the first auxiliary transaction), it can return the execution result of object A's salary payment transaction (i.e., the pending transaction) to the cross-contract scheduler.

[0234] Optionally, in the above Figure 10 On the basis of the corresponding embodiment, in another optional embodiment of the blockchain cross-contract calling method provided in the embodiment of the present application, as Figure 11As shown, in step S1003, the cross-contract scheduler stores the execution result of the pending transaction, as well as the first cache, the first total cache, and the third total cache corresponding to the first contract identifier in the overall transaction cache, and the second cache and the second total cache corresponding to the second contract identifier in the blockchain database, including:

[0235] In step S1101, the cross-contract scheduler returns the execution result of the pending transaction, as well as the first cache, the first total cache, and the third total cache corresponding to the first contract identifier in the overall transaction cache, and the second cache and the second total cache corresponding to the second contract identifier to the blockchain;

[0236] In step S1102 , the first cache, the first total cache, the third total cache, the second cache, and the second total cache are traversed respectively. If there is a conflicting cache, the conflicting cache is corrected to obtain a corrected cache and stored in the database.

[0237] In this embodiment, when the cross-contract scheduler receives the execution result of the pending transaction returned by the first contract instance of the initial schedule, and the third full cache, it can first return the execution result of the pending transaction, and the first cache, first full cache and third full cache corresponding to the first contract identifier in the overall transaction cache, and the second cache and second full cache corresponding to the second contract identifier to the blockchain. Then, the first cache, first full cache, third full cache, second cache and second full cache in the blockchain are traversed respectively. If the conflict cache is traversed, the conflict cache can be corrected to obtain the corrected cache and store it in the database. The cache on the blockchain side and the contract instance cache on the smart contract virtual machine engine side can be maintained respectively, thereby reducing the cost of data transmission and improving the efficiency of blockchain query operations to a certain extent.

[0238] It is understandable that since the contract instance generates a read-write set during operation, this part of the read-write set is both a cache and the data that needs to be stored in the database. Therefore, after the contract instance is completed, the generated read-write set will be returned to the blockchain for storage. For ease of understanding, this embodiment is introduced with a transaction. Figure 16 As shown, the specific steps for conflict detection and correction are as follows:

[0239] (1) The blockchain sends the transaction to the smart contract virtual machine engine;

[0240] (2) The smart contract virtual machine engine can start a contract instance to execute the above transaction;

[0241] (3) When the transaction is completed, the contract instance also generates a complete read-write set cache;

[0242] (4) The contract instance returns the read-write set cache to the blockchain for processing;

[0243] (5) The blockchain traverses all read-write sets in the result;

[0244] (6) If there is a conflict cache, that is, the read-write set conflicts (another read-write set has read and written the transaction), return to step 1 and re-execute the above steps; otherwise, go to step 7;

[0245] (7) Write the read-write set into the final snapshot, and the execution ends.

[0246] The conflict cache can be used to represent the cache generated by the same contract instance executing the transaction triggered at different time points, or the cache generated by different contract instances executing the transaction triggered at different time points, or the cache generated by different contract instances executing the transaction triggered at the same time point, and the like, and can also be represented as other, which is not specifically limited here.

[0247] Specifically, according to steps (1) to (3) in the execution steps shown in Figure 16 , when the cross-contract scheduler receives the execution result of the initial scheduled first contract instance returned by the to-be-processed transaction, and the third overall cache, it can first return the execution result of the to-be-processed transaction and the overall cache in the transaction to the blockchain according to step (4) in the execution steps shown in Figure 16 , that is, the first cache corresponding to the first contract identifier, the first overall cache and the third overall cache, and the second cache corresponding to the second contract identifier and the second overall cache, and then traverse the first cache, the first overall cache, the third overall cache, the second cache and the second overall cache in the blockchain respectively. If a conflict cache is traversed, the conflict cache can be corrected, that is, steps (1) to (6) in the execution steps shown in Figure 16 are repeated to obtain a corrected cache, and the corrected execution result and the corrected overall cache are written into the blockchain cache snapshot, so that the blockchain cache snapshot updates the written overall cache to the database in units of blocks.

[0248] Optionally, based on the above Figure 11 corresponding embodiments, another optional embodiment of the blockchain cross-contract calling method provided by the embodiments of the present application is shown in Figure 12 , if there is a conflict cache, the conflict cache is corrected to obtain a corrected cache and stored in the database, including:

[0249] In step S1201, the transaction corresponding to the conflict cache is resent to the cross-contract scheduler, so that the cross-contract scheduler receives the transaction to be corrected and creates a correction task corresponding to the transaction to be corrected;

[0250] In step S1202, based on the correction task, a task scheduler is used to schedule the contract instance to execute the statements corresponding to the transaction to be corrected one by one according to the attributes of the transaction to be corrected;

[0251] In step S1203, when the contract instance completes executing all statements corresponding to the transaction to be corrected, the execution result of the transaction to be corrected and the correction cache of all statements corresponding to the transaction to be corrected are stored in the database, and the conflict cache and the execution result corresponding to the conflict cache are deleted.

[0252] In this embodiment, after traversing the conflict cache, the transaction corresponding to the conflict cache can be resent to the cross-contract scheduler, so that the cross-contract scheduler receives the transaction to be corrected and re-establishes the correction task corresponding to the transaction to be corrected. Then, the task scheduler can be used based on the correction task, and according to the attributes of the transaction to be corrected, the contract instance can be rescheduled to execute the statements corresponding to the transaction to be corrected one by one. Then, when the contract instance has completed executing all the statements corresponding to the transaction to be corrected, the execution result of the transaction to be corrected and the correction cache of all the statements corresponding to the transaction to be corrected can be stored in the database, and the conflict cache and the execution result corresponding to the conflict cache can be deleted to maintain the cache on the blockchain side and the contract instance cache on the smart contract virtual machine engine side, thereby reducing the cost of data transmission and improving the efficiency of blockchain query operations to a certain extent.

[0253] Specifically, according to the above Figure 16 In the execution steps (1) to (4) shown in FIG, if the conflict cache is traversed, the conflict cache can be corrected, that is, the above steps are repeated. Figure 16 Steps (1) to (6) in the execution steps shown are to resend the transaction corresponding to the conflict cache to the cross-contract scheduler, so that the cross-contract scheduler receives the transaction to be corrected and re-establishes the correction task corresponding to the transaction to be corrected. Then, based on the correction task, the task scheduler can be used to reschedule the contract instance to execute the statements corresponding to the transaction to be corrected one by one according to the attributes of the transaction to be corrected. Then, when the contract instance completes the execution of all the statements corresponding to the transaction to be corrected, the execution result of the transaction to be corrected and the correction cache of all the statements corresponding to the transaction to be corrected can be returned to the blockchain for processing, and the conflict cache and the execution result corresponding to the conflict cache are deleted. Then, all the caches in the blockchain are traversed again. If the conflict cache is not traversed, the above steps are followed. Figure 16Step (7) in the execution steps shown writes the corrected execution result in the blockchain and all the corrected caches into the blockchain cache snapshot, so that the blockchain cache snapshot updates all the written caches into the database in units of blocks.

[0254] Optionally, in the above Figure 10 On the basis of the corresponding embodiment, in another optional embodiment of the blockchain cross-contract calling method provided in the embodiment of the present application, as Figure 13 As shown, in step S1003, the cross-contract scheduler stores the execution result of the pending transaction, as well as the first cache, the first total cache, and the third total cache corresponding to the first contract identifier in the overall transaction cache, and the second cache and the second total cache corresponding to the second contract identifier in the blockchain database, including:

[0255] In step S1301, the cross-contract scheduler returns the execution result of the pending transaction, as well as the first cache, the first total cache, and the third total cache corresponding to the first contract identifier in the overall transaction cache, and the second cache and the second total cache corresponding to the second contract identifier to the blockchain;

[0256] In step S1302, the first cache, the first total cache, the third total cache, the second cache, and the second total cache are traversed respectively. If there is no conflicting cache, the execution result of the pending transaction and the first cache, the first total cache, and the third total cache corresponding to the first contract identifier in the overall transaction cache, as well as the second cache and the second total cache corresponding to the second contract identifier are written into the blockchain cache snapshot, so that the blockchain cache snapshot updates all the written caches into the database in units of blocks.

[0257] In this embodiment, when the cross-contract scheduler receives the execution result of the pending transaction returned by the first contract instance of the initial schedule, and the third full cache, the execution result of the pending transaction, and the first cache, the first full cache, and the third full cache corresponding to the first contract identifier in the overall transaction cache, and the second cache and the second full cache corresponding to the second contract identifier can be returned to the blockchain first. Then, the first cache, the first full cache, the third full cache, the second cache, and the second full cache in the blockchain are traversed respectively. If no conflicting cache is traversed, the execution result of the pending transaction and the first cache, the first full cache, and the third full cache corresponding to the first contract identifier in the overall transaction cache, and the second cache and the second full cache corresponding to the second contract identifier can be written into the blockchain cache snapshot, so that the blockchain cache snapshot updates all the written caches to the database in units of blocks to maintain the cache on the blockchain side and the contract instance cache on the smart contract virtual machine engine side, thereby reducing the cost of data transmission and improving the efficiency of blockchain execution query operations to a certain extent.

[0258] Specifically, according to the above Figure 16 In the execution steps (1) to (3) shown in FIG, when the cross-contract scheduler receives the execution result of the pending transaction returned by the first contract instance of the initial schedule, and the third full cache, it can be executed as described above. Figure 16 In step (4) of the execution steps shown, the execution result of the pending transaction and all the caches in the overall transaction cache, such as the first cache, the first total cache and the third total cache corresponding to the first contract identifier, and the second cache and the second total cache corresponding to the second contract identifier, are first returned to the blockchain. Then, the first cache, the first total cache, the third total cache, the second cache and the second total cache in the blockchain can be traversed respectively. If no conflicting cache is traversed, the above-mentioned steps are followed. Figure 16 Step (7) in the execution steps shown writes the execution result of the pending transaction and the first cache, the first total cache, and the third total cache corresponding to the first contract identifier in the overall transaction cache, and the second cache and the second total cache corresponding to the second contract identifier into the blockchain cache snapshot, so that the blockchain cache snapshot updates all the written caches into the database in units of blocks.

[0259] The following is a detailed description of the blockchain cross-contract calling device in this application. Figure 18 , Figure 18 This is a schematic diagram of an embodiment of a blockchain cross-contract calling device in an embodiment of the present application. The blockchain cross-contract calling device 20 includes:

[0260] The acquisition unit 201 is configured to, when the cross-contract scheduler receives a pending transaction, initially schedule the first contract instance to execute statements corresponding to the pending transaction one by one according to the attributes of the pending transaction;

[0261] A sending unit 202 is configured to, when the initially scheduled first contract instance executes a first cross-contract call statement, send a first cross-contract call request carrying a first cache corresponding to the first contract instance execution statement and attributes of a first auxiliary transaction to the cross-contract scheduler, so that the cross-contract scheduler generates a first auxiliary transaction based on the first cross-contract call statement and stores the first cache in the overall transaction cache;

[0262] Processing unit 203 is configured to, if the attributes of the first auxiliary transaction are different from the attributes of the to-be-processed transaction, schedule, by the cross-contract scheduler, a second contract instance according to the first cross-contract call request, and execute statements corresponding to the first auxiliary transaction one by one, wherein the second contract instance is different from the first contract instance;

[0263] The sending unit 202 is further configured to, when the second contract instance executes the second cross-contract call statement, send a second cross-contract call request carrying the second cache corresponding to the second contract instance execution statement and the attributes of the second auxiliary transaction to the cross-contract scheduler, so that the cross-contract scheduler generates a second auxiliary transaction according to the second cross-contract call statement and stores the second cache in the overall transaction cache;

[0264] Processing unit 203 is further configured to, if the attributes of the second auxiliary transaction are the same as the attributes of the pending transaction, cause the cross-contract scheduler to reschedule the first contract instance according to the second cross-contract call request, and share the first cache with the rescheduled first contract instance, so that the rescheduled first contract instance executes statements corresponding to the second auxiliary transaction one by one based on the first cache;

[0265] Processing unit 203 is further configured to, when all statements corresponding to the second auxiliary transaction are executed, return the execution result of the second auxiliary transaction to the second contract instance, so that the second contract instance executes the statement following the second cross-contract call statement based on the execution result of the second auxiliary transaction;

[0266] Processing unit 203 is further configured to, when all statements corresponding to the first auxiliary transaction are executed, return the execution result of the first auxiliary transaction to the initially scheduled first contract instance, so that the initially scheduled first contract instance executes the statements following the first cross-contract call statement based on the execution result of the first auxiliary transaction;

[0267] The processing unit 203 is also used to return the execution result of the pending transaction to the cross-contract scheduler when all statements corresponding to the pending transaction are executed, so that the cross-contract scheduler stores the execution result of the pending transaction and all caches in the overall transaction cache in the database.

[0268] Optionally, in the above Figure 18 On the basis of the corresponding embodiment, in another embodiment of the blockchain cross-contract calling device provided by the embodiment of the present application, the acquisition unit 201 can be specifically used to:

[0269] The blockchain selects pending transactions from the transaction queue and sends them to the cross-contract scheduler;

[0270] When the cross-contract scheduler receives a pending transaction, it creates a task corresponding to the pending transaction;

[0271] Based on the task scheduler, according to the attributes of the pending transaction, the first contract instance is initially scheduled to execute statements corresponding to the pending transaction one by one, wherein the initial scheduling of the first contract instance comes from the first contract virtual machine engine.

[0272] Optionally, in the above Figure 18 On the basis of the corresponding embodiment, in another embodiment of the blockchain cross-contract calling device provided by the embodiment of the present application, the sending unit 202 can be specifically used to:

[0273] When the initially scheduled first contract instance executes the first cross-contract call statement, the attributes of the first auxiliary transaction are determined according to the attribute field of the first auxiliary transaction in the first cross-contract call statement;

[0274] The first contract instance initially scheduled generates a first cache based on the statement before the first cross-contract call statement executed;

[0275] Sending a first cross-contract call request carrying attributes of the first cache and the first auxiliary transaction to the cross-contract scheduler;

[0276] When the cross-contract scheduler receives the first cross-contract call request, it generates a first auxiliary transaction according to the first cross-contract call statement;

[0277] The cross-contract scheduler stores the first cache in the cache set corresponding to the first contract instance identifier in the overall transaction cache.

[0278] Optionally, in the above Figure 18 On the basis of the corresponding embodiment, in another embodiment of the blockchain cross-contract calling device provided by the embodiment of the present application, the processing unit 203 can be specifically used to:

[0279] The cross-contract scheduler creates the first subtask of the task based on the first auxiliary transaction;

[0280] If the attributes of the first auxiliary transaction are different from the attributes of the transaction to be processed, the task scheduler is used based on the first subtask to schedule the second contract instance to execute the statements corresponding to the first auxiliary transaction one by one according to the attributes of the first auxiliary transaction, wherein the second contract instance originates from the first contract virtual machine engine or the second contract virtual machine engine, and the first contract virtual machine engine is different from the second contract virtual machine engine.

[0281] Optionally, in the above Figure 18 On the basis of the corresponding embodiment, in another embodiment of the blockchain cross-contract calling device provided by the embodiment of the present application, the sending unit 202 can be specifically used to:

[0282] When the second contract instance executes the second cross-contract call statement, the attributes of the second auxiliary transaction are determined based on the attribute field of the second auxiliary transaction in the second cross-contract call statement.

[0283] The second contract instance generates a second cache based on the statement before the executed second cross-contract call statement;

[0284] Sending a second cross-contract call request carrying the attributes of the second cache and the second auxiliary transaction to the cross-contract scheduler;

[0285] When the cross-contract scheduler receives the second cross-contract call request, it generates a second auxiliary transaction according to the second cross-contract call statement;

[0286] The cross-contract scheduler stores the second cache in the cache set corresponding to the second contract instance identifier in the overall transaction cache.

[0287] Optionally, in the above Figure 18 On the basis of the corresponding embodiment, in another embodiment of the blockchain cross-contract calling device provided by the embodiment of the present application, the processing unit 203 can be specifically used to:

[0288] The cross-contract scheduler creates a second subtask of the task based on the second auxiliary transaction;

[0289] If the attributes of the second auxiliary transaction are the same as the attributes of the pending transaction, then using the task scheduler based on the second subtask, reschedule the first contract instance according to the attributes of the second auxiliary transaction;

[0290] The cross-contract scheduler shares the first cache with the rescheduled first contract instance, so that the rescheduled first contract instance executes the statements corresponding to the first auxiliary transaction one by one.

[0291] Optionally, in the above Figure 18 On the basis of the corresponding embodiment, in another embodiment of the blockchain cross-contract calling device provided by the embodiment of the present application, the processing unit 203 can be specifically used to:

[0292] When the first contract instance is rescheduled to execute all statements corresponding to the second auxiliary transaction, the execution result of the second auxiliary transaction and the first cache corresponding to all executed statements are returned to the cross-contract scheduler;

[0293] The cross-contract scheduler stores the received first entire cache into the cache set corresponding to the first contract instance identifier in the overall transaction cache;

[0294] The cross-contract scheduler sends the received execution result of the second auxiliary transaction to the second contract instance, so that the second contract instance executes the statement after the second cross-contract call statement based on the execution result.

[0295] Optionally, in the above Figure 18 On the basis of the corresponding embodiment, in another embodiment of the blockchain cross-contract calling device provided by the embodiment of the present application, the processing unit 203 can be specifically used to:

[0296] When the second contract instance completes executing all statements corresponding to the first auxiliary transaction, it returns the execution result of the first auxiliary transaction and the second full cache corresponding to executing all statements to the cross-contract scheduler;

[0297] The cross-contract scheduler stores the received second entire cache into the cache set corresponding to the second contract instance identifier in the overall transaction cache;

[0298] The cross-contract scheduler sends the execution result of the received first auxiliary transaction to the initially scheduled first contract instance, so that the initially scheduled first contract instance executes the statement after the first cross-contract call statement based on the execution result.

[0299] Optionally, in the above Figure 18 On the basis of the corresponding embodiment, in another embodiment of the blockchain cross-contract calling device provided by the embodiment of the present application, the processing unit 203 can be specifically used to:

[0300] When the first contract instance initially scheduled completes executing all statements corresponding to the pending transaction, it returns the execution result of the pending transaction and the third full cache corresponding to all executed statements to the cross-contract scheduler;

[0301] The cross-contract scheduler stores the received third entire cache into the cache set corresponding to the first contract instance identifier in the overall transaction cache;

[0302] The cross-contract scheduler stores the execution results of the pending transactions, as well as the first cache, the first total cache, and the third total cache corresponding to the first contract identifier in the overall transaction cache, and the second cache and the second total cache corresponding to the second contract identifier in the blockchain database.

[0303] Optionally, in the above Figure 18 On the basis of the corresponding embodiment, in another embodiment of the blockchain cross-contract calling device provided by the embodiment of the present application, the processing unit 203 can be specifically used to:

[0304] The cross-contract scheduler returns the execution result of the pending transaction, as well as the first cache, the first total cache, and the third total cache corresponding to the first contract identifier in the overall transaction cache, and the second cache and the second total cache corresponding to the second contract identifier to the blockchain;

[0305] The first cache, the first total cache, the third total cache, the second cache, and the second total cache are traversed respectively. If a conflicting cache exists, the conflicting cache is corrected to obtain a corrected cache and store it in the database.

[0306] Optionally, in the above Figure 18 On the basis of the corresponding embodiment, in another embodiment of the blockchain cross-contract calling device provided by the embodiment of the present application, the processing unit 203 can be specifically used to:

[0307] Resend the transaction corresponding to the conflict cache to the cross-contract scheduler so that the cross-contract scheduler receives the transaction to be corrected and creates a correction task corresponding to the transaction to be corrected;

[0308] Based on the correction task, the task scheduler is used to schedule the contract instance to execute the statements corresponding to the transaction to be corrected one by one according to the attributes of the transaction to be corrected;

[0309] When the contract instance completes executing all statements corresponding to the transaction to be corrected, the execution results of the transaction to be corrected and the correction cache of all statements corresponding to the transaction to be corrected are stored in the database, and the conflict cache and the execution results corresponding to the conflict cache are deleted.

[0310] Optionally, in the above Figure 18 On the basis of the corresponding embodiment, in another embodiment of the blockchain cross-contract calling device provided by the embodiment of the present application, the processing unit 203 can be specifically used to:

[0311] The cross-contract scheduler returns the execution result of the pending transaction, as well as the first cache, the first total cache, and the third total cache corresponding to the first contract identifier in the overall transaction cache, and the second cache and the second total cache corresponding to the second contract identifier to the blockchain;

[0312] The first cache, the first all cache, the third all cache, the second cache and the second all cache are traversed respectively, and if there is no conflict cache, the execution result of the to-be-processed transaction and the first cache corresponding to the first contract identifier in the transaction cache, the first all cache and the third all cache corresponding to the first contract identifier, and the second cache and the second all cache corresponding to the second contract identifier are written into the blockchain cache snapshot, so that the blockchain cache snapshot updates all the caches written in the unit of block to the database.

[0313] Another aspect of the present application provides another computer device schematic diagram, as shown in Figure 19 Figure 19 is a computer device structure schematic diagram provided by an embodiment of the present application. The computer device 300 can have great differences due to different configurations or performances, and can include one or more central processing units (CPUs) 310 (for example, one or more processors) and a memory 320, one or more storage media 330 (for example, one or more mass storage devices) storing application programs 331 or data 332. The memory 320 and the storage media 330 can be temporary storage or persistent storage. The programs stored in the storage media 330 can include one or more modules (not shown in the figure), and each module can include a series of instruction operations in the computer device 300. Further, the central processing unit 310 can be configured to communicate with the storage media 330 and execute a series of instruction operations in the storage media 330 on the computer device 300.

[0314] The computer device 300 can also include one or more power supplies 340, one or more wired or wireless network interfaces 350, one or more input and output interfaces 360, and / or one or more operating systems 333, such as Windows Server TM , Mac OS X TM , Unix TM , Linux TM , FreeBSD TM , etc.

[0315] The computer device 300 is further configured to perform the steps in the embodiments. Figures 2 to 13

[0316] Another aspect of the present application provides a computer readable storage medium having a computer program stored thereon, when the computer program is executed by a processor, the steps in the method described in the embodiments as shown in Figures 2 to 13

[0317] ​​​Another aspect of the present application provides a computer program product comprising a computer program, which, when executed by a processor, implements the following Figures 2 to 13 The illustrated embodiments describe steps in a method.

[0318] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0319] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0320] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0321] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0322] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, and other media that can store program code.

Claims

1. A blockchain cross-contract calling method, characterized in that: include: When the cross-contract scheduler receives a pending transaction, it initially schedules the first contract instance to execute the statements corresponding to the pending transaction one by one based on the attributes of the pending transaction. When the initially scheduled first contract instance executes a first cross-contract call statement, a first cross-contract call request carrying a first cache corresponding to the first contract instance execution statement and attributes of a first auxiliary transaction is sent to the cross-contract scheduler, so that the cross-contract scheduler generates a first auxiliary transaction according to the first cross-contract call statement and stores the first cache in the overall transaction cache; If the attributes of the first auxiliary transaction are different from the attributes of the pending transaction, the cross-contract scheduler schedules a second contract instance according to the first cross-contract call request, and executes statements corresponding to the first auxiliary transaction one by one, wherein the second contract instance is different from the first contract instance; When the second contract instance executes the second cross-contract call statement, a second cross-contract call request carrying the second cache corresponding to the second contract instance execution statement and the attributes of the second auxiliary transaction is sent to the cross-contract scheduler, so that the cross-contract scheduler generates a second auxiliary transaction according to the second cross-contract call statement and stores the second cache in the overall transaction cache; If the attributes of the second auxiliary transaction are the same as the attributes of the pending transaction, the cross-contract scheduler reschedules the first contract instance according to the second cross-contract call request, and shares the first cache with the rescheduled first contract instance, so that the rescheduled first contract instance executes the statements corresponding to the second auxiliary transaction one by one based on the first cache; When all statements corresponding to the second auxiliary transaction are executed, the execution result of the second auxiliary transaction is returned to the second contract instance, so that the second contract instance executes the statement following the second cross-contract call statement based on the execution result of the second auxiliary transaction; When all statements corresponding to the first auxiliary transaction are executed, the execution result of the first auxiliary transaction is returned to the initially scheduled first contract instance, so that the initially scheduled first contract instance executes the statements following the first cross-contract call statement based on the execution result of the first auxiliary transaction; When all statements corresponding to the pending transaction are executed, the execution result of the pending transaction is returned to the cross-contract scheduler, so that the cross-contract scheduler stores the execution result of the pending transaction and all caches in the overall transaction cache in the database.

2. The method according to claim 1, characterized in that When the cross-contract scheduler receives a pending transaction, it initially schedules the first contract instance to execute statements corresponding to the pending transaction one by one according to the attributes of the pending transaction, including: The blockchain selects the pending transaction from the transaction queue and sends it to the cross-contract scheduler; When the cross-contract scheduler receives the pending transaction, it creates a task corresponding to the pending transaction; Based on the task, a task scheduler is used, and according to the attributes of the pending transaction, the first contract instance is initially scheduled to execute statements corresponding to the pending transaction one by one, wherein the initial scheduling of the first contract instance comes from the first contract virtual machine engine.

3. The method according to claim 1, characterized in that When the initially scheduled first contract instance executes a first cross-contract call statement, sending a first cross-contract call request carrying a first cache corresponding to the first contract instance execution statement and attributes of the first auxiliary transaction to the cross-contract scheduler includes: When the initially scheduled first contract instance executes a first cross-contract call statement, determining the attributes of the first auxiliary transaction according to the attribute field of the first auxiliary transaction in the first cross-contract call statement; The first contract instance initially scheduled generates the first cache based on the statement before the first cross-contract call statement executed; Sending a first cross-contract call request carrying the first cache and the attributes of the first auxiliary transaction to the cross-contract scheduler; When the cross-contract scheduler receives the first cross-contract call request, generating the first auxiliary transaction according to the first cross-contract call statement; The cross-contract scheduler stores the first cache in the cache set corresponding to the first contract instance identifier in the overall transaction cache.

4. The method according to claim 2, characterized in that If the first auxiliary transaction attribute is different from the attribute of the pending transaction, the cross-contract scheduler schedules the second contract instance according to the first cross-contract call request and executes statements corresponding to the first auxiliary transaction one by one, including: The cross-contract scheduler establishes a first subtask of the task according to the first auxiliary transaction; If the attributes of the first auxiliary transaction are different from the attributes of the to-be-processed transaction, the task scheduler is used based on the first subtask to schedule the second contract instance to execute statements corresponding to the first auxiliary transaction one by one according to the attributes of the first auxiliary transaction, wherein the second contract instance originates from the first contract virtual machine engine or the second contract virtual machine engine, and the first contract virtual machine engine is different from the second contract virtual machine engine.

5. The method according to claim 1, wherein When the second contract instance executes the second cross-contract call statement, sending a second cross-contract call request carrying the second cache corresponding to the second contract instance execution statement and the attributes of the second auxiliary transaction to the cross-contract scheduler includes: When the second contract instance executes the second cross-contract call statement, determining the attributes of the second auxiliary transaction according to the attribute field of the second auxiliary transaction in the second cross-contract call statement; The second contract instance generates the second cache based on the statement before the second cross-contract call statement executed; Sending a second cross-contract call request carrying the second cache and the attributes of the second auxiliary transaction to the cross-contract scheduler; When the cross-contract scheduler receives the second cross-contract call request, generating the second auxiliary transaction according to the second cross-contract call statement; The cross-contract scheduler stores the second cache in the cache set corresponding to the second contract instance identifier in the overall transaction cache.

6. The method according to claim 2, characterized in that If the second auxiliary transaction attribute is the same as the attribute of the pending transaction, the cross-contract scheduler rescheduling the first contract instance according to the second cross-contract call request and sharing the first cache with the rescheduled first contract instance, including: The cross-contract scheduler creates a second subtask of the task according to the second auxiliary transaction; If the attributes of the second auxiliary transaction are the same as the attributes of the pending transaction, rescheduling the first contract instance based on the attributes of the second auxiliary transaction using the task scheduler based on the second subtask; The cross-contract scheduler shares the first cache with the rescheduled first contract instance, so that the rescheduled first contract instance executes statements corresponding to the first auxiliary transaction one by one.

7. The method according to claim 1, characterized in that When all statements corresponding to the second auxiliary transaction are executed, returning the execution result of the second auxiliary transaction to the second contract instance includes: When the first contract instance is rescheduled to execute all statements corresponding to the second auxiliary transaction, the execution result of the second auxiliary transaction and the first cache corresponding to the execution of all statements are returned to the cross-contract scheduler; The cross-contract scheduler stores the received first entire cache into the cache set corresponding to the first contract instance identifier in the overall transaction cache; The cross-contract scheduler sends the received execution result of the second auxiliary transaction to the second contract instance, so that the second contract instance executes the statement after the second cross-contract call statement based on the execution result.

8. The method according to claim 7, characterized in that When all statements corresponding to the first auxiliary transaction are executed, returning the execution result of the first auxiliary transaction to the initially scheduled first contract instance, so that the initially scheduled first contract instance executes the statement following the first cross-contract call statement based on the execution result of the first auxiliary transaction, including: When the second contract instance completes executing all statements corresponding to the first auxiliary transaction, it returns the execution result of the first auxiliary transaction and the second full cache corresponding to executing all statements to the cross-contract scheduler; The cross-contract scheduler stores the received second entire cache into the cache set corresponding to the second contract instance identifier in the overall transaction cache; The cross-contract scheduler sends the received execution result of the first auxiliary transaction to the initially scheduled first contract instance, so that the initially scheduled first contract instance executes the statement after the first cross-contract call statement based on the execution result.

9. The method according to claim 8, characterized in that When all statements corresponding to the pending transaction are executed, returning the execution result of the pending transaction to the cross-contract scheduler includes: When the initially scheduled first contract instance completes executing all statements corresponding to the pending transaction, it returns the execution result of the pending transaction and the third cache corresponding to executing all statements to the cross-contract scheduler; The cross-contract scheduler stores the received third entire cache into the cache set corresponding to the first contract instance identifier in the overall transaction cache; The cross-contract scheduler stores the execution result of the pending transaction, as well as the first cache, the first total cache and the third total cache corresponding to the first contract instance identifier in the overall transaction cache, and the second cache and the second total cache corresponding to the second contract instance identifier in the database of the blockchain.

10. The method according to claim 9, characterized in that The cross-contract scheduler stores the execution result of the pending transaction, the first cache, the first overall cache, and the third overall cache corresponding to the first contract instance identifier in the overall transaction cache, and the second cache and the second overall cache corresponding to the second contract instance identifier in a database of the blockchain, including: The cross-contract scheduler returns the execution result of the pending transaction, as well as the first cache, the first overall cache, and the third overall cache corresponding to the first contract instance identifier in the overall transaction cache, and the second cache and the second overall cache corresponding to the second contract instance identifier to the blockchain; The first cache, the first total cache, the third total cache, the second cache and the second total cache are traversed respectively. If a conflicting cache exists, the conflicting cache is corrected to obtain a corrected cache and stored in the database.

11. The method according to claim 10, characterized in that If a conflicting cache exists, correcting the conflicting cache to obtain a corrected cache and storing it in the database includes: Resending the transaction corresponding to the conflict cache to the cross-contract scheduler, so that the cross-contract scheduler receives the transaction to be corrected and creates a correction task corresponding to the transaction to be corrected; Using a task scheduler based on the correction task, and according to the attributes of the transaction to be corrected, scheduling contract instances to execute statements corresponding to the transaction to be corrected one by one; When the contract instance completes executing all statements corresponding to the transaction to be corrected, the execution result of the transaction to be corrected and the correction cache of all statements corresponding to the transaction to be corrected are stored in the database, and the conflict cache and the execution result corresponding to the conflict cache are deleted.

12. The method according to claim 9, characterized in that The cross-contract scheduler stores the execution result of the pending transaction, the first cache, the first overall cache, and the third overall cache corresponding to the first contract instance identifier in the overall transaction cache, and the second cache and the second overall cache corresponding to the second contract instance identifier in a database of the blockchain, including: The cross-contract scheduler returns the execution result of the pending transaction, as well as the first cache, the first overall cache, and the third overall cache corresponding to the first contract instance identifier in the overall transaction cache, and the second cache and the second overall cache corresponding to the second contract instance identifier to the blockchain; The first cache, the first overall cache, the third overall cache, the second cache, and the second overall cache are traversed respectively. If no conflicting cache exists, the execution result of the pending transaction and the first cache, the first overall cache, and the third overall cache corresponding to the first contract instance identifier in the overall transaction cache, as well as the second cache and the second overall cache corresponding to the second contract instance identifier, are written into the blockchain cache snapshot, so that the blockchain cache snapshot updates all the written caches into the database in units of blocks.

13. A blockchain cross-contract calling device, characterized in that: include: an acquisition unit, configured to, when the cross-contract scheduler receives a pending transaction, initially schedule the first contract instance to execute statements corresponding to the pending transaction one by one according to the attributes of the pending transaction; a sending unit, configured to, when the initially scheduled first contract instance executes a first cross-contract call statement, send a first cross-contract call request carrying a first cache corresponding to the first contract instance execution statement and attributes of a first auxiliary transaction to the cross-contract scheduler, so that the cross-contract scheduler generates a first auxiliary transaction according to the first cross-contract call statement and stores the first cache in the overall transaction cache; a processing unit, configured to, if the first auxiliary transaction attribute is different from the attribute of the to-be-processed transaction, cause the cross-contract scheduler to schedule a second contract instance according to the first cross-contract call request, and execute statements corresponding to the first auxiliary transaction one by one, wherein the second contract instance is different from the first contract instance; The sending unit is further configured to, when the second contract instance executes a second cross-contract call statement, send a second cross-contract call request carrying a second cache corresponding to the second contract instance execution statement and attributes of a second auxiliary transaction to the cross-contract scheduler, so that the cross-contract scheduler generates a second auxiliary transaction according to the second cross-contract call statement and stores the second cache in the overall transaction cache; The processing unit is further configured to, if the attributes of the second auxiliary transaction are the same as the attributes of the pending transaction, cause the cross-contract scheduler to reschedule the first contract instance according to the second cross-contract call request, and share the first cache with the rescheduled first contract instance, so that the rescheduled first contract instance executes statements corresponding to the second auxiliary transaction one by one based on the first cache; The processing unit is further configured to, when all statements corresponding to the second auxiliary transaction are executed, return the execution result of the second auxiliary transaction to the second contract instance, so that the second contract instance executes the statement following the second cross-contract call statement based on the execution result of the second auxiliary transaction; The processing unit is further configured to, when all statements corresponding to the first auxiliary transaction are executed, return the execution result of the first auxiliary transaction to the initially scheduled first contract instance, so that the initially scheduled first contract instance executes the statement following the first cross-contract call statement based on the execution result of the first auxiliary transaction; The processing unit is further configured to return the execution result of the pending transaction to the cross-contract scheduler when all statements corresponding to the pending transaction are executed, so that the cross-contract scheduler stores the execution result of the pending transaction and all caches in the overall transaction cache in the database.

14. The device according to claim 13, characterized in that The acquisition unit is specifically configured to: The blockchain selects the pending transaction from the transaction queue and sends it to the cross-contract scheduler; When the cross-contract scheduler receives the pending transaction, it creates a task corresponding to the pending transaction; Based on the task, a task scheduler is used, and according to the attributes of the pending transaction, the first contract instance is initially scheduled to execute statements corresponding to the pending transaction one by one, wherein the initial scheduling of the first contract instance comes from the first contract virtual machine engine.

15. The device according to claim 13, characterized in that The sending unit is specifically configured to: When the initially scheduled first contract instance executes a first cross-contract call statement, determining the attributes of the first auxiliary transaction according to the attribute field of the first auxiliary transaction in the first cross-contract call statement; The first contract instance initially scheduled generates the first cache based on the statement before the first cross-contract call statement executed; Sending a first cross-contract call request carrying the first cache and the attributes of the first auxiliary transaction to the cross-contract scheduler; When the cross-contract scheduler receives the first cross-contract call request, generating the first auxiliary transaction according to the first cross-contract call statement; The cross-contract scheduler stores the first cache in the cache set corresponding to the first contract instance identifier in the overall transaction cache.

16. A computer device comprising a memory, a processor and a bus system, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 12 are implemented; The bus system is used to connect the memory and the processor so that the memory and the processor can communicate with each other.

17. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 12 are implemented.

18. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 12 are implemented.

Images