Resource allocation method and device based on cross-contract call, equipment and storage medium

Abstract

Embodiments of the present application provide a resource allocation method and device based on cross-contract calling, equipment and storage medium, which is used to make each contract in a transaction task be able to be allocated to a process resource, thereby avoiding the situation that the resource is deadlocked and cannot be released. The method comprises the following steps: obtaining identification information of a first virtual machine and contract calling information corresponding to a transaction task; determining a target process pool of a first contract according to the contract calling information and the identification information of the first virtual machine, the target process pool being a cross-contract process pool or an original contract process pool, the cross-contract process pool being a process resource pool of a contract executing the transaction task for the second time or later on the first virtual machine, and the original contract process pool being a process resource pool of a contract executing the transaction task for the first time on the first virtual machine; and allocating a process resource to the first contract when there is an idle process resource in the target process pool. The present application can be applied to the fields of block chain, big data and cloud technology.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a resource allocation method, apparatus, device, and storage medium based on cross-contract calls. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. It is primarily used to organize data chronologically and encrypt it into a ledger, making it tamper-proof and forgery-proof. It also allows for data verification, storage, and updating. Blockchain can also perform encrypted data transmission, node identification, and secure access, making it an advanced distributed infrastructure. Currently, due to its immutability and authenticity, blockchain applications are increasing. Alternatively, a public ledger can be maintained on the blockchain, visible to all nodes in the storage blocks, thus ensuring its immutability and tamper-proof nature. A contract is an assembly language programmed on the blockchain; that is, in a blockchain system, a contract is code that all nodes on the blockchain can understand and execute, capable of executing arbitrary logic and obtaining results. Smart contracts can be understood as executable programs, while the blockchain can be understood as an operating system providing the runtime environment for these programs.

[0003] Based on the aforementioned functionalities, the blockchain's main program implements various functions by calling contracts. The process of the blockchain main program calling a contract is similar to the Common Gateway Interface (CGI) model used by a web server to call external programs. Specifically, within the lifecycle of a single contract call by the main program, the contract has a complete data flow: loading data from disk, performing data calculations, and then writing the calculation results back to disk. After the call lifecycle ends, the smart contract clears the data from memory.

[0004] During contract execution, if a contract occupies one process and the transaction task does not impose process resource restrictions, a situation may easily occur where resources are stuck and cannot be released if there is a large-scale contract execution. Summary of the Invention

[0005] This application provides a resource allocation method, apparatus, device, and storage medium based on cross-contract calls, which enables each contract in a transaction task to be allocated process resources, thereby avoiding resource deadlock and inability to be released.

[0006] In view of this, this application provides a resource allocation method based on cross-contract calls, comprising: obtaining the identification information of a first virtual machine and the contract call information corresponding to a transaction task, wherein the contract call information is used to indicate the virtual machine call status during the execution of the contract of the transaction task, and the first virtual machine is the virtual machine called when executing the first contract in the transaction task; determining the target process pool of the first contract based on the contract call information and the identification information of the first virtual machine, wherein the target process pool is a cross-contract process pool or an original contract process pool, wherein the cross-contract process pool is the process resource pool of the contract executing the transaction task for the second time or thereafter on the first virtual machine, and the original contract process pool is the process resource pool of the contract executing the transaction task for the first time on the first virtual machine; and allocating process resources to the first contract when there are idle process resources in the target process pool.

[0007] This application also provides a resource allocation device, including: an acquisition module, used to acquire the identification information of a first virtual machine and the contract call information corresponding to a transaction task, wherein the contract call information is used to indicate the virtual machine call status during the contract execution of the transaction task, and the first virtual machine is the virtual machine called when executing the first contract in the transaction task;

[0008] The processing module is used to determine the target process pool of the first contract based on the contract call information and the identification information of the first virtual machine. The target process pool is either a cross-contract process pool or an original contract process pool. The cross-contract process pool is the process resource pool of the contract that executes the transaction task for the second time or thereafter on the first virtual machine. The original contract process pool is the process resource pool of the contract that executes the transaction task for the first time on the first virtual machine.

[0009] The allocation module is used to allocate process resources to the first contract when there are idle process resources in the target process pool.

[0010] In one possible design, in another implementation of another aspect of the embodiments of this application, the processing module is specifically used to obtain a set of identification information of virtual machines called during the execution of the transaction task based on the contract call information; compare the identification information of the first virtual machine with the set of identification information to obtain a comparison result; and determine the target process pool of the first contract based on the comparison result.

[0011] In one possible design, in another implementation of another aspect of the embodiments of this application, the contract call information includes a first field; the first field is used to record the identification information of the virtual machine called in the transaction task;

[0012] This processing module is specifically used to read the first field in the contract call information to obtain the set of identification information of the virtual machine called during the execution of the transaction task.

[0013] In one possible design, in another implementation of another aspect of the embodiments of this application, the contract call information further includes a second field and a third field;

[0014] The second field is used to record the number of contract calls for the transaction task;

[0015] The third field is used to record the call queue of the virtual machine in this transaction task.

[0016] In one possible design, in another implementation of another aspect of the embodiments of this application, the processing module is further configured to read the second field in the contract call information to obtain the number of contract calls in the transaction task, and read the third field in the contract call information to obtain the virtual machine call order during the execution of the transaction task.

[0017] In one possible design, in another implementation of another aspect of the embodiments of this application, the contract call information includes 64 bits, which are binary values, wherein the first field includes 8 bits, the second field includes 4 bits, and the third field includes 52 bits.

[0018] Each bit in the first field indicates the identification information of a virtual machine. When a bit in the second field is 1, it indicates that the virtual machine corresponding to the bit with a value of 1 has been invoked.

[0019] The third field uses 4 bits to indicate the identification information of the virtual machine, and the 52 bits of the third field are inserted into the virtual machine identification information queue according to the virtual machine call order in the execution process of the transaction task.

[0020] In one possible design, in another implementation of another aspect of the embodiments of this application, the processing module is specifically used to determine the target process pool of the first contract as the cross-contract process pool when the comparison result indicates that the first virtual machine has been called in the execution process of the transaction task.

[0021] In one possible design, in another implementation of another aspect of the embodiments of this application, the processing module is further configured to add the first contract to the cross-contract task queue before allocating process resources to the first contract when there are idle process resources in the target process pool.

[0022] In one possible design, in another implementation of another aspect of the embodiments of this application, the processing module is specifically used to determine the target process pool of the first contract as the original contract process pool if it is determined from the contract call information that the first virtual machine was not called during the execution of the transaction task.

[0023] In one possible design, in another implementation of another aspect of the embodiments of this application, the processing module is further configured to add the first contract to the original contract task queue before allocating process resources to the first contract when there are idle process resources in the target process pool.

[0024] In one possible design, in another implementation of another aspect of the embodiments of this application, the number of process resources in the cross-contract process pool is greater than the number of process resources in the original contract process pool.

[0025] In one possible design, in another implementation of another aspect of the embodiments of this application, the number of process resources in the cross-contract process pool is equal to the product of the number of process resources in the original contract process pool and a first preset value, the first preset value being equal to the preset contract call layer minus 1.

[0026] This application also provides a computer device, including: a memory, a processor, and a bus system;

[0027] The memory is used to store programs;

[0028] The processor is used to execute programs in memory, and the processor is used to execute the methods mentioned above according to the instructions in the program code;

[0029] Bus systems are used to connect memory and processor to enable communication between them.

[0030] Another aspect of this application provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the methods described above.

[0031] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the above aspects.

[0032] As can be seen from the above technical solutions, the embodiments of this application have the following advantages: the process resources of each virtual machine are divided into the original contract process pool and the cross-contract process pool. In this way, for a transaction task, the first contract executed and the subsequent contracts are allocated process resources using different process pools, so that each contract in the transaction task can be allocated process resources. This avoids the situation where the first execution contract of a large number of transaction tasks occupies all the process resources in the blockchain, while the subsequent contracts have no process resources to allocate, resulting in the resource being stuck and unable to be released. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of the blockchain network architecture in an embodiment of this application;

[0034] Figure 2 This is a schematic diagram illustrating an application scenario of smart contract execution within a blockchain, as illustrated in this application embodiment.

[0035] Figure 3 This is a schematic diagram of one embodiment of the resource allocation method based on cross-contract calls in this application.

[0036] Figure 4 This is an exemplary application scenario of the resource allocation method in the embodiments of this application;

[0037] Figure 5 This is an exemplary data structure for the first field in the contract call information in this application embodiment;

[0038] Figure 6 This is an exemplary data structure for contract invocation information in the embodiments of this application;

[0039] Figure 7 This is a flowchart illustrating the process of reading the second field in the contract call information in an embodiment of this application;

[0040] Figure 8a This is a flowchart illustrating the process of modifying the second field in the contract call information when adding a new number of contract call attempts in this application embodiment;

[0041] Figure 8b This is a flowchart illustrating the process of modifying the first field in the contract call information when adding a new number of contract call attempts in this application embodiment;

[0042] Figure 8c This is a flowchart illustrating the process of modifying the third field in the contract call information when adding a new number of contract call attempts in this application embodiment;

[0043] Figure 8d This is a schematic diagram of a data structure for the modified contract call information when adding a new number of contract call attempts in an embodiment of this application;

[0044] Figure 9a This is a flowchart illustrating the process of modifying the second field in the contract call information when deleting the number of contract calls in an embodiment of this application.

[0045] Figure 9b This is a flowchart illustrating the process of modifying the third field in the contract call information when deleting the number of contract calls in this application embodiment;

[0046] Figure 9cThis is a flowchart illustrating the process of modifying the first field in the contract call information when deleting the number of contract calls in this application embodiment;

[0047] Figure 9d This is a schematic diagram of a data structure for the modified contract call information when deleting the number of contract calls in an embodiment of this application;

[0048] Figure 10 This is a schematic diagram illustrating a process for determining whether a virtual machine uses outdated read contract call information in an embodiment of this application.

[0049] Figure 11 This is a flowchart illustrating the process of reading contract call information when querying the virtual machine call status of the k-th contract call in this embodiment of the application.

[0050] Figure 12 This is an exemplary flowchart illustrating the resource allocation method in an embodiment of this application;

[0051] Figure 13 This is a schematic diagram of one embodiment of the resource allocation device in this application.

[0052] Figure 14 This is a schematic diagram of another embodiment of the resource allocation device in this application;

[0053] Figure 15 This is a schematic diagram of another embodiment of the resource allocation device in this application. Detailed Implementation

[0054] This application provides a resource allocation method, apparatus, device, and storage medium based on cross-contract calls, which enables each contract in a transaction task to be allocated process resources, thereby avoiding resource deadlock and inability to be released.

[0055] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “corresponding to,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises 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 processes, methods, products, or apparatus.

[0056] To facilitate understanding, some of the technical terms used in this application are explained below.

[0057] Please see Figure 1 This is a schematic diagram of a network architecture provided in an embodiment of this application. Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. It is mainly used to organize data in chronological order and encrypt it into a ledger, making it tamper-proof and forgery-proof. It also allows for data verification, storage, and updating. Essentially, a blockchain is a decentralized database where each node stores the same blockchain. The blockchain network distinguishes nodes into core nodes, data nodes, and light nodes. Core nodes are responsible for the consensus of the entire blockchain network; that is, core nodes are the consensus nodes in the blockchain network. The process of writing transaction data into the ledger in a blockchain network can be as follows: the client sends transaction data to a data node or light node, and then the transaction data is passed between data nodes or light nodes in the blockchain network in a relay manner until the consensus node receives the transaction data. The consensus node then packages the transaction data into a block and performs consensus with other consensus nodes. After consensus is reached, the block carrying the transaction data is written into the ledger.

[0058] It is understood that a blockchain system can include smart contracts. A smart contract in the blockchain system can be understood and executed by all nodes (including consensus nodes), capable of executing arbitrary logic and obtaining results. Users can initiate a transaction request through a client, invoking a smart contract already deployed on the blockchain. Subsequently, data nodes or light nodes on the blockchain can send the transaction request to the consensus nodes, and each consensus node can run the smart contract. It should be understood that a blockchain can include one or more smart contracts, which can be distinguished by an identity document (ID) or name. The transaction request initiated by the client can also carry the smart contract's identity document or name, thus specifying the smart contract that the blockchain needs to run. If the smart contract specified by the client requires reading data, each consensus node will access its local ledger to read the data. Finally, each consensus node will verify whether the execution results are consistent (i.e., reach consensus). If they are consistent, the execution result can be stored in its respective local ledger and returned to the client. Examples of smart contract applications include: 1. Housing rental: Landlords and tenants establish a housing rental contract. The landlord generates an unlocking key for the property monthly. When the tenant pays the monthly rent to the landlord's account, the system automatically sends the unlocking key to the tenant via a smart contract. 2. Crop insurance: For example, farmer A purchases a financial derivative guaranteeing a yield of 3,000 kilograms of potatoes per acre. If the yield falls short of 3,000 kilograms, farmer A will automatically receive compensation. 3. Ledger system: Users obtain consumption information, which is recorded according to accounting rules to generate ledger information. 4. Transaction system: A and B establish a smart contract project. After B transfers money from their bank account to A's bank account through the blockchain system, the smart contract automatically sends digital assets under A's name to B.

[0059] like Figure 1 As shown, the network architecture may include a core node (consensus node) cluster 1000, a data node or light node cluster 100, and a user terminal (client) cluster 10. The core node cluster 1000 may include at least two core nodes, and the data node cluster 100 may include at least two data nodes. Figure 1 As shown, the core node cluster 1000 may include core node 1000a, core node 1000b, ..., core node 1000n; the data node cluster 100 may specifically include data node 100a, data node 100b, ..., data node 100n; and the user terminal cluster 10 may specifically include user terminal 10a, user terminal 10b, ..., user terminal 10n.

[0060] like Figure 1 As shown, user terminals 10a, 10b, ..., 10n can respectively connect to data nodes 100a, 100b, ..., 100n via the network, so that the user terminals can interact with the data nodes through the network connection; data nodes 100a, 100b, ..., 100n can respectively connect to core nodes 1000a, 1000b, ..., 1000n via the network, so that the data nodes can interact with the core nodes through the network connection; data nodes 100a, 100b, ..., 100n are interconnected to enable data interaction between data nodes; core nodes 1000a, 1000b, ..., 1000n are interconnected to enable data interaction between core nodes.

[0061] Taking user terminal 10a, data node 100a, and core node 1000a as an example, data node 100a can receive a transaction request sent by user terminal 10a (the transaction request carries the ID or name of the smart contract). Subsequently, data node 100a can send the transaction request to core node 1000a through data node cluster 100. Core node 1000a can run the smart contract and execute the transaction through the smart contract. After obtaining the execution result, it can store the execution result in a memory pool (such as a transaction pool) and generate a new block based on the execution result. Subsequently, core node 1000a can send the newly generated block to other core nodes in its blockchain network based on the node identifiers of other core nodes (i.e., consensus nodes). The other core nodes will verify the newly generated block (i.e., reach consensus) and add the newly generated block to their stored blockchain after verification (that is, store the execution result in the blockchain after consensus is reached). In this blockchain network, each core node has a corresponding node identifier, and each core node can store the node identifiers of other core nodes in the blockchain network. This allows for the broadcasting of generated blocks to other core nodes based on their node identifiers, ensuring data consistency across all core nodes. In this application, the core node 1000a can invoke a virtual machine to execute the smart contract. In the blockchain field, virtual machines provide computing resources and runtime containers for smart contracts. Each virtual machine runs in an isolated environment, ensuring resource access security and allowing modification only of the contract's own state records. Smart contracts require termination conditions to limit resource consumption; termination conditions can be based on time, number of instructions, instruction execution cost, etc. A blockchain can include multiple smart contracts, each with different encoding methods. Therefore, to ensure the normal execution of each smart contract in the blockchain, the core node 1000a can determine the type of virtual machine to invoke based on the smart contract's programming method. For example, if smart contract A is generated using Java, then when the core node 1000a runs smart contract A, it needs to call the Java Virtual Machine to run smart contract A.

[0062] In this embodiment, the virtual machine type can include the following possible implementation methods:

[0063] The Ethereum Virtual Machine (EVM) is a stack-based virtual machine that executes a series of bytecode instructions based on specific environment data to modify the system state.

[0064] The Java Virtual Machine (JVM) is a virtual computer that is implemented by simulating various computer functions on a real computer. The JVM has its own complete hardware architecture, such as a processor, stack, registers, etc., and also has a corresponding instruction set.

[0065] The Golang Virtual Machine is a runtime container that runs contracts deployed using the Go language.

[0066] Currently, the smart contract runs on core node 1000a, executes the transaction through the smart contract, obtains the execution result, and finally stores the execution result in a memory pool (such as a transaction pool) and generates a new block based on the execution result. In this process, process resources need to be allocated for each contract in the transaction task. In order to ensure that the transaction task can run normally, this application provides the following technical solution to solve this problem: Obtain the identification information of the first virtual machine and the contract call information corresponding to the transaction task. The contract call information is used to indicate the virtual machine call status during the execution of the contract of the transaction task. The first virtual machine is the virtual machine called when executing the first contract in the transaction task; Determine the target process pool of the first contract based on the contract call information and the identification information of the first virtual machine. The target process pool is a cross-contract process pool or an original contract process pool. The cross-contract process pool is the process resource pool of the contract that executes the transaction task for the second time or later on the first virtual machine. The original contract process pool is the process resource pool of the contract that executes the transaction task for the first time on the first virtual machine; When there are idle process resources in the target process pool, allocate process resources to the first contract. This approach divides the process resources of each virtual machine into an original contract process pool and a cross-contract process pool. For a transaction task, the first contract executed and subsequent contracts are allocated process resources using different process pools. This ensures that each contract in a transaction task can be allocated process resources, thus avoiding a situation where the first execution of a large number of transaction tasks occupies all the process resources in the blockchain, leaving no process resources available for subsequent contracts, resulting in resource deadlock and inability to be released.

[0067] It is understood that the methods provided in this application embodiment can be executed by computer devices, including but not limited to terminals or servers. Nodes in this application embodiment can be computer devices. The servers involved in this application can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. Terminal devices can be smartphones, tablets, laptops, PDAs, personal computers, smart TVs, smartwatches, in-vehicle devices, wearable devices, etc., but are not limited to these. In this application, the execution results obtained from executing smart contracts can be stored in the form of a database. A database, simply put, can be viewed as an electronic filing cabinet—a place to store electronic files, where users can perform operations such as adding, querying, updating, and deleting data. A "database" is a collection of data stored together in a certain way, shared by multiple users, with minimal redundancy, and independent of applications. A Database Management System (DBMS) is a computer software system designed to manage databases, generally possessing basic functions such as storage, retrieval, security, and backup. DBMSs can be classified according to the database model they support, such as relational or Extensible Markup Language (XML); or according to the type of computer they support, such as server clusters or mobile devices; or according to the query language used, such as Structured Query Language (SQL) or XQuery; or according to performance priorities, such as maximum scale or maximum operating speed; or other classification methods. Regardless of the classification method used, some DBMSs can cross categories, for example, simultaneously supporting multiple query languages.

[0068] It is understood that in the specific implementation of this application, data related to contract call information and virtual machine identification information are involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0069] For easier understanding, please refer to Figure 2 , Figure 2 This is a schematic diagram of a scenario provided in an embodiment of this application. Wherein, as... Figure 2 The user terminal A shown can be the one described above. Figure 1 Any user terminal in the user terminal cluster 10 in the corresponding embodiment, for example, the user terminal is 10a; for example Figure 2 The blockchain nodes shown can be the above. Figure 1 Any core node in the core node cluster 1000 in the corresponding embodiment, for example, the core node can be core node 1000b.

[0070] like Figure 2 As shown, user A initiates a transfer transaction (user A transfers 5000 yuan to user B) through user terminal A. User A can select a smart contract in blockchain 200 (for example, select smart contract A), meaning user A can choose the smart contract in the blockchain used to execute the transfer transaction. It is understandable that during the execution of this smart contract, at least one cross-contract call statement can be added, adding a contract B to query user A's transfer amount and a contract C to query the credit scores of user A and user B. Figure 2 In the application scenario shown, if contract A is generated according to programming method A, and contracts B and C are generated according to programming method B, the execution logic of the smart contract for this transfer transaction can be summarized in the following five steps:

[0071] 1. Call virtual machine A to execute contract A, and allocate corresponding process resources to contract A so that contract A can run normally, thereby reading user A's balance and user B's balance in the blockchain.

[0072] 2. When calling contract B across contracts, virtual machine B is simultaneously invoked to execute contract B. At this time, corresponding process resources are allocated to contract B to ensure its normal operation. This allows the system to query and read the transfer limit of user A in the blockchain.

[0073] 3. When cross-contract call C calls virtual machine B, corresponding process resources are allocated to contract C to ensure its normal operation, thereby querying the credit status of user A and user B in the blockchain.

[0074] 4. Call virtual machine A to continue executing contract A and perform the transfer logic judgment (it should be understood that this logic judgment also needs to include the logic judgment of the transfer amount and the current transfer amount, as well as the logic judgment of the credit information of user A and user B). If the transfer logic judgment meets the requirements, modify the balance of user A and user B.

[0075] 5. Call virtual machine A to continue executing contract A and write user A's latest balance to the blockchain.

[0076] 6. Call virtual machine A to continue executing contract A and write user B's latest balance to the blockchain.

[0077] Specifically, contracts A, B, and C all require corresponding process resources during their execution. The process resources occupied by contract A will not be released until contract B or contract C has finished executing; they will only be released after contract A has also finished executing. When virtual machine A executes contract A, it determines that this is the first time it is executing a contract, and that contract A is the first contract executed. Therefore, it determines that the target process pool for contract A is the original contract process pool of virtual machine A, and then allocates process resources for contract A from this pool. When virtual machine B executes contract B, it is determined that virtual machine B is executing the contract for the first time, and the contract executed for the first time is contract B. At this time, the target process pool for contract B is determined to be the original contract process pool of virtual machine B, and process resources are allocated for contract B from the original contract process pool of virtual machine B. When virtual machine B executes contract C again, it is determined that virtual machine B is executing the contract for the second time, and the contract executed for the second time is contract C. At this time, the target process pool for contract C is determined to be the cross-contract process pool of virtual machine B, and process resources are allocated for contract C from the cross-contract process pool of virtual machine B.

[0078] In this application, cross-contract invocation refers to the process by which one contract calls another contract through code. Based on the above process, this means that during the execution of contract A, contract B and contract C are called through code. The specific process of cross-contract invocation can be achieved by encapsulating the contract address of contract B or contract C into a contract object, allowing contract A to call functions of contract B or contract C through this contract object. Alternatively, a calling function can be used directly to allow contract A to call contract B or contract C. In this approach, the calling function can be `call()`, `delegatecall()`, or `callcode()`, and the specific method is not limited here.

[0079] Based on the above introduction, for further information, please refer to [link / reference]. Figure 3 , Figure 3 This is a schematic diagram illustrating an embodiment of a resource allocation method based on cross-contract calls provided in this application. The method can be implemented by a blockchain node (such as the one described above). Figure 1 The core node in the corresponding embodiment can be executed, or it can be executed by the blockchain node and the user terminal (e.g., the one mentioned above). Figure 1 The method is jointly executed by the user terminals in the corresponding embodiments. The following explanation will use the execution of this method by a blockchain node as an example. The resource allocation method based on cross-contract calls includes:

[0080] 301. Obtain the identification information of the first virtual machine and the contract call information corresponding to the transaction task. The contract call information is used to indicate the virtual machine call status during the contract execution of the transaction task. The first virtual machine is the virtual machine called when executing the first contract in the transaction task.

[0081] In this application, the blockchain node can be a core node in the blockchain. The core node can receive transaction requests (e.g., contract call requests) from data nodes or light nodes in the blockchain, while the data nodes or light nodes can receive transaction requests from user terminals. These transaction requests can be generated by the user terminal based on a transaction task initiated by the user. After receiving the transaction request, the blockchain node invokes the first contract and the corresponding first virtual machine according to the transaction request. The first virtual machine is used to execute the first contract. In this application, when invoking the first contract, the blockchain node can determine its programming language through the code statements of the first contract, thereby determining the type of virtual machine corresponding to the first contract. Specifically, the blockchain node can invoke the virtual machine type corresponding to the programming method of the first contract. For example, if the first contract is generated using Java, then the identification information of the first virtual machine can be used to indicate that the type of the first virtual machine is a Java Virtual Machine.

[0082] Simultaneously, the blockchain node can also obtain the contract call information for the transaction task. This contract call information indicates the virtual machine's invocation status during the contract execution of the transaction task.

[0083] In this embodiment, the contract call information can be cached in the overall transaction cache area during the contract execution of the transaction task. In one exemplary scheme, the overall execution of the transaction task involves cross-contract calls across five layers, such as... Figure 4As shown, the first layer is Contract 1, which is executed for the first time in this transaction task, and the virtual machine called at this time is Virtual Machine 1; the second layer is Contract 2, which is called through the cross-contract call statement of Contract 1 when Contract 1 is executed in this transaction task, and the virtual machine called at this time is Virtual Machine 2; the third layer is Contract 3, which is called through the cross-contract call statement of Contract 2 when Contract 2 is executed in this transaction task, and the virtual machine called at this time is Virtual Machine 3; the fourth layer is Contract 4, which is called through the cross-contract call statement of Contract 3 when Contract 3 is executed in this transaction task, and the virtual machine called at this time is Virtual Machine 1; the fifth layer is Contract 5, which is called through the cross-contract call statement of Contract 4 when Contract 4 is executed in this transaction task, and the virtual machine called at this time is Virtual Machine 2. It can be understood that in this embodiment, the number of cross-contract call layers only illustrates the layer-by-layer in-depth call of contracts during the execution of the transaction task, and does not involve the return execution process of contracts in the transaction task. When contract 1 is called at the first layer, the blockchain node records the call details of virtual machine 1 and generates contract call information. When contract 2 is called at the second layer, the blockchain node modifies and adds the call details of virtual machine 2 to the contract call information recorded at the first layer. When contract 3 is called at the third layer, the blockchain node modifies and adds the call details of virtual machine 3 to the contract call information recorded at the second layer. And so on, the call details of each virtual machine are recorded through the contract call information.

[0084] Optionally, in this embodiment, the data structure of the contract call information can be as follows:

[0085] In one possible implementation, the contract call information may include only a first field, which is used solely to indicate the usage of the virtual machine. In one exemplary scheme, the first field in the contract call information includes X bits, where X is a positive integer (understandably, the value of X is related to the total number of virtual machine types in the blockchain; that is, the value of X must be at least greater than or equal to the total number of virtual machine types in the blockchain. For example, if the total number of virtual machine types in the blockchain is 8, then the value of X is 8 or greater than 8), where each bit corresponds to one virtual machine; then, when a bit is 1, it indicates that the virtual machine corresponding to that bit has been called; when a bit is 0, it indicates that the virtual machine corresponding to that bit has not been called. In one exemplary scheme, such as... Figure 5As shown, the first field of the contract call information includes 8 bits, indicating that the blockchain includes 8 different types of virtual machines, which are designated as virtual machine 1 to virtual machine 8 from left to right. If the third bit from left to right is 1, it means that virtual machine 3 has been called. It can be understood that this first field can record each virtual machine call in the transaction task. For example, if virtual machine 4 is called in the execution of contract 1 of the transaction task, the fourth bit in this first field will be 1; if virtual machine 3 is called in the execution of contract 2 of the transaction task, the third bit in this first field will be 1; if virtual machine 3 is called again in the execution of contract 3 of the transaction task, the third bit in this first field will remain 1, meaning that the first field will not be modified.

[0086] Furthermore, to more clearly query the contract call details in the transaction task, the contract call information can also include a second field and a third field. The second field indicates the number of contract calls in the transaction task, and the third field records the call queue of the virtual machines in the transaction task (i.e., records the identification information of each virtual machine called in the order of call). In this embodiment, the second field can include Y bits, which only needs to be sufficient to record the number of contract calls in the transaction task; the specific value is not limited here. The third field can include Q bits, where each P bit is used to indicate the identification information of a virtual machine. It is understood that as long as the P bits can indicate the identification information of the virtual machine and the product of the P bits and the number of contract calls in the transaction task is less than Q, the specific value is not limited here. It is understood that Y, P, and Q are all positive integers.

[0087] In one exemplary solution, the contract call information can be as follows: Figure 6 As shown, the contract call information includes 64 bits. From left to right, bits 0 to 3 form the second field, while four bits are used in binary to record the number of contract calls in the transaction task; bits 4 to 11 form the first field, indicating that the blockchain includes a maximum of 8 virtual machine types, corresponding to virtual machines 1 to 8 from right to left; bits 12 to 63 form the third field, used to record the historical information of the contract calls to the virtual machines. It can be understood that the call history of the virtual machine in the third field is arranged in a queue according to the call order. After each virtual machine call, it will be retrieved from... Figure 6 The virtual machine's number (i.e., the corresponding number in the first field) is inserted on the right side of the contract call information shown. Based on Figure 6As shown, the value of the second field is "0100", which indicates that the contract was called 4 times in the transaction task; the value of the first field is "00000111", which indicates that virtual machine 1, virtual machine 2 and virtual machine 3 were called in the transaction task; the value of the third field is "000000000000000000000000000000000000001100010010010", which indicates that the virtual machine called for the first time was virtual machine 3, the virtual machine called for the second time was virtual machine 1, the virtual machine called for the third time was virtual machine 1, and the virtual machine called for the fourth time was virtual machine 2.

[0088] 302. Determine the target process pool of the first contract based on the contract call information and the identification information of the first virtual machine. The target process pool is either a cross-contract process pool or an original contract process pool. The cross-contract process pool is the process resource pool of the contract that executes the transaction task for the second time or thereafter on the first virtual machine. The original contract process pool is the process resource pool of the contract that executes the transaction task for the first time on the first virtual machine.

[0089] After obtaining the contract call information and the identifier information of the first virtual machine, the blockchain node can retrieve the set of identifier information of the virtual machines invoked during the execution of the transaction task based on the contract call information. Then, it compares the identifier information of the first virtual machine with this set of identifier information to obtain a comparison result. Finally, it determines the target process pool for the first contract based on the comparison result. In this embodiment, a corresponding process pool is allocated to each virtual machine in the blockchain, such as... Figure 4 As shown, each virtual machine is divided into a corresponding original contract process pool and a cross-contract process pool. That is, the target process pool is either the original contract process pool or the cross-contract process pool. Since the number of contracts initially executed in a transaction task is less than the number of contracts called by the cross-contract process pool, the resource allocation between the original contract process pool and the cross-contract process pool can be made so that the process resources of the original contract process pool are less than the process resources of the cross-contract process pool. This reasonable allocation of process resources can ensure the execution efficiency of the transaction task.

[0090] Optionally, to achieve a reasonable allocation of process resources and ensure the execution efficiency of transaction tasks, the allocation of process resources between the original contract process pool and the cross-contract process pool on each virtual machine can further satisfy the following condition: the number of process resources in the cross-contract process pool is equal to the product of the number of process resources in the original contract process pool and a first preset value, where the first preset value is equal to the preset number of contract call layers minus 1. In an exemplary scheme, assuming the maximum number of cross-contract call layers in the blockchain is 6 layers, and the process resources of the original contract process pool of virtual machine 1 are allocated to 40, then the process resources of the cross-contract process pool of virtual machine 1 can be allocated to 40*5=200. In this embodiment, the process resources allocated to each virtual machine can be related to the number of times it is called. For example, if a virtual machine is called more than a threshold in the blockchain, its process resources can be allocated more; while if another virtual machine is called less than a threshold in the blockchain, its process resources can be allocated less. For example, if the blockchain includes 5 virtual machines, and virtual machine 1 has the highest number of calls, then virtual machine 1 can be allocated the most process resources, while virtual machine 5 has the fewest calls, then virtual machine 5 can be allocated the fewest process resources. It's understandable that the process resources allocated to each virtual machine need to satisfy the normal operation of all transaction tasks in the blockchain. Further details will not be elaborated here.

[0091] Optional, based on such Figure 5 or Figure 6 The contract call information shown requires the blockchain node to read the first field to obtain a set of identifiers for the virtual machines called during the execution of the transaction task. Simultaneously, Figure 6 Under the contract call information shown, the blockchain node can also read the second field to obtain the number of contract calls in the transaction task, and read the third field to obtain the virtual machine call order during the execution of the transaction task.

[0092] In this embodiment, the specific process by which the blockchain determines the target process pool based on the comparison result can be as follows:

[0093] If the comparison result indicates that the first virtual machine has been invoked during the execution of the transaction task, then the target process pool of the first contract is determined to be the cross-contract process pool; if the contract invocation information determines that the first virtual machine has not been invoked during the execution of the transaction task, then the target process pool of the first contract is determined to be the original contract process pool. In this embodiment, if the target process pool has no idle resources, the first contract will be added to the task queue of the target process pool.

[0094] Optionally, the specific steps a blockchain node takes to obtain the set of virtual machine identifiers from the contract call information can be found in the following process:

[0095] The following is based on Figure 6 The contract call information shown describes in detail the process by which the blockchain node reads the first, second, and third fields:

[0096] Assuming the second field is field a1, the process by which the blockchain node reads this second field is as follows: Figure 7 As shown: Among them, the Figure 7 In the text, (a) is "0100 11100000000000000000000000000000000000000000001100010010010". To read the "0100" in segment a1, you need to... Figure 7 Shifting the original contract call information shown in (a) 60 bits to the right will move the call level (second field) to the end, resulting in the following: Figure 7 The result shown in (b) is "0000 0000000000000000000000000000000000000000000000000000000100". Then, by directly reading "000000000000 000000000000000000000000000000000000000000000000000100", we can obtain the contract call count as 4.

[0097] Similarly, the first and third fields can also be read in the same way, and the details will not be elaborated here.

[0098] The following is based on Figure 6 The contract call information shown describes the process of modifying the contract call information when the number of contract calls in the transaction task increases by one: In this embodiment, the blockchain node needs to find the values ​​of each field according to the contract call information, then calculate the new values ​​of each field, and finally concatenate the new values ​​to obtain the new contract call information.

[0099] Assuming the second field is field a1, the blockchain node can modify field a1 using the following formula: a1 = (a >> 60 + 1) << 60. It can be understood that 'a' in this formula indicates the information from the previous contract call. Figure 8aIn (a) shown in the image, the previous contract call information is "0011 0000010100000000000000000000000000000000000000000001100010001". Here, "a>>60" indicates that the previous contract call information should be shifted 60 bits to the right to obtain the previous contract call count, that is, "001100000101 000000000000000000000000000000000000000001100010001" becomes "0000000000000". 00000000000000000000000000000000000000000000000011, reading "000000000000 00000000000000000000000000000000000000000000000000011" gives the previous contract call count as 3; "(a>>60+1)" instructs to increment the previous contract call count by 1 to get the new contract call count, that is, "0000 000000000000000000000000000000000000000000000000000000011" results in "0000 0000000000000000000000000000000000000000000000000000000100”; “(a>>60+1)<<60” is used to indicate that the new contract call count is shifted left by 60 to obtain the new a1 field, resulting in, for example Figure 8a (b) "01000000000 0 ...

[0100] Assuming the first field is a2, the specific process of modifying this first field by the blockchain node can be calculated using the following formula: a2 = a & (1 << 60 – 1 << 52) | (1 << (59 - type)). It can be understood that 'a' in this formula indicates the information from the previous contract call. Figure 8b The previous contract call information shown in (a) is “0011 0000010100000000000000000000000000000000000000000001100010001”, where “1<<60–1<<52” is used to obtain the mask for a2, that is, Figure 8bThe “0011 00000101000000000000000000000000000000000000000000001100010001” shown in (a) is transformed into “0000 1111111000000000000000000000000000000000000000000000000000000”; “a&(1<<60–1<<52)” is used to obtain the a2 part, that is, the “0000 11111110 ... Figure 8b The AND operation of “001100000101 0000000000000000000000000000000000000000001100010001” shown in (a) yields “000000000101 0 ... Figure 8b The virtual machine 2 shown in (b) is the second position from right to left in field a2; "1<<(59-type)" is used to obtain the expression of the virtual machine type in the contract call information (such as taking the value 1 or taking the value 0), that is, to obtain the following... Figure 8b The virtual machine 2 shown in (b) has a value of 1 in a2: "a&(1<<60–1<<52)|(1<<(59-type))" is used to add the record of the virtual machine in the first field, resulting in "0000 000001110 ...

[0101] Assuming the third field is a3, the specific process by which the blockchain node modifies the first field can be calculated using the following formula: a3 = ((1 << 52 - 1) & a) << 4 | type. It can be understood that 'a' in this formula indicates the information from the previous contract call. Figure 8c The previous contract call information shown in (a) is “001100000101 00000000000000000000000000000000000000000001100010001”, where “(1<<52-1)” is used to obtain the mask of a3, that is, Figure 8cThe expression "0011 0000010100000000000000000000000000000000000000000001100010001" shown in (a) is transformed into "0000 00000001 ... Figure 8c The AND operation of “001100000101 00000000000000000000000000000000000000000001100010001” shown in (a) yields “0000000000000 0000000000000000000000000000000000000000001100010001”; “((1<<52-1)&a)<<4” is used to make room for the new virtual machine number, that is, “0000 0000000000000000000000000000000000000000000000000001100010001” becomes “0000 00000000000000000000000000000000000000000000011000100010000”; “((1<<52-1)&a)<<4|type” is used to create a new virtual machine number in the last four bits, thus obtaining Figure 8c As shown in (b) is “000000000000 0000000000000000000000000000000000000000001100010010010010”.

[0102] Finally, the new fields a1, a2, and a3 are concatenated (i.e., a = a1|a2|a3) to obtain the following result: Figure 8dThe contract call information shown is obtained by concatenating "0100 000000000000000000000000000000000000000000000000000000000000", "0000 00000111000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001100010010010010 to obtain "010000000111". 000000000000000000000000000000000000001100010010010".

[0103] The following is based on Figure 6 The contract call information shown describes the process of deleting the information of the most recently called contract in this transaction task: In this embodiment, the blockchain node needs to find the values ​​of each field according to the contract call information, then calculate the new values ​​of each field, and finally concatenate the new values ​​to obtain the new contract call information.

[0104] Assuming the second field is field a1, the blockchain node can modify field a1 using the following formula: a1 = (a >> 60 - 1) << 60. It can be understood that 'a' in this formula indicates the information from the previous contract call. Figure 9aIn (a) shown in the image, the previous contract call information is "0100 000001110000000000000000000000000000000000000001100010010010". Here, "a>>60" indicates that the previous contract call information should be shifted 60 bits to the right to obtain the previous contract call count, that is, "010000000111 00000000000000000000000000000000000001100010010010" becomes "0000000000000". 000000000000000000000000000000000000000000000000100, reading "000000000000 0000000000000000000000000000000000000000000000000100" gives the previous contract call count as 4; "(a>>60-1)" indicates that the previous contract call count is subtracted by 1 to get the new contract call count, that is, "0000 000000000000000000000000000000000000000000000000000000100" becomes "0000 000000000000000000000000000000000000000000000000000000000011”; “(a>>60-1)<<60” is used to indicate that the new contract call count is shifted left by 60 to obtain the new a1 field, resulting in, for example Figure 9a (b) "001100000000 0 ...

[0105] In this embodiment, the value of the third field needs to be calculated first, and then the value of the second field needs to be calculated. Assuming the third field is a3, the specific process of modifying the first field in the blockchain node can be calculated using the following formula: a3 = ((1 << 52 - 1) & a) >> 4. It can be understood that 'a' in this formula indicates the previous contract call information. Figure 9b The previous contract call information shown in (a) is “0100 000001110000000000000000000000000000000000000001100010010010, where “(1<<52-1)” is used to obtain the mask of a3, that is, Figure 9bThe expression "0100 000001110000000000000000000000000000000000000001100010010010" shown in (a) is transformed into "0000 00000001 ... Figure 9b The AND operation of “010000000111 000000000000000000000000000000000000001100010010010” shown in (a) yields “000000000000 000000000000000000000000000000000000001100010010010”; “((1<<52-1)&a)>>4” is used to shift four bits to the right, deleting the virtual machine number of the most recently called contract, i.e., “000000000000”. 00000000000000000000000000000000000001100010010010 Figure 9b As shown in (b) in the figure, “0000 00000000 00000000000000000000000000000000000000000000001100010001”.

[0106] After obtaining the latest value of the third field, the value of the first field is calculated based on this latest value. Assuming the first field is a2, the specific process of modifying this first field by the blockchain node can be calculated using the following formula: a2 = a & (1 << 60 – 1 << 52) | (1 << (59 - type)). It can be understood that 'a' in this formula indicates the information from the previous contract call. Figure 9c The previous contract call information shown in (a) is “0100 00000111 0000000000000000000000000000000000000001100010010010, where “1<<60–1<<52” is used to obtain the mask for a2, that is... Figure 9cThe “0100 0000011100000000000000000000000000000000000000001100010010” shown in (a) is transformed into “0000 11111110000000000000000000000000000000000000000000000000000”; “a&(1<<60–1<<52)” is used to obtain the a2 part, that is, the “0000 11111110 ... Figure 9c The AND operation of “010000000111 000000000000000000000000000000000000001100010010” shown in (a) yields “000000000111 0000000000000000000000000000000000000000000000000000000”; “(59-type)” is used to retrieve the position of the deleted virtual machine number in a2 from the third field, i.e., to obtain the result as shown in (a). Figure 9c The virtual machine 2 shown in (b) is the second position from right to left in field a2; "1<<(59-type)" is used to obtain the expression of the virtual machine type in the contract call information (such as taking the value 1 or taking the value 0), that is, to obtain the following... Figure 9c The virtual machine 2 shown in (b) has a position in a2 with a value of 0: "a&(1<<60–1<<52)|(1<<(59-type))" is used to add the record of the virtual machine in the first field, resulting in "0000 000001 ...

[0107] Finally, the new fields a1, a2, and a3 are concatenated (i.e., a = a1|a2|a3) to obtain the following result: Figure 9dThe contract call information shown is obtained by concatenating "0011 00000000000000000000000000000000000000000000000000000000000", "0000 0000010100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001100010001" to obtain "001100000101". 00000000000000000000000000000000000000000001100010001".

[0108] The following is based on Figure 6 The contract call information shown describes the process of determining whether the virtual machine has been used in the transaction task: In this embodiment, the blockchain node needs to find the flag bit of the contract call virtual machine according to the contract call information, then perform a bitwise AND operation to determine whether the result is greater than 0. If it is greater than 0, it proves that the virtual machine has been used; otherwise, it proves that the virtual machine has not been used.

[0109] like Figure 10 As shown, the contract call information is as follows: Figure 10 (a) shows "0100 0000011100000000000000000000000000000000000000001100010010010". The blockchain node needs to obtain the information in the first field (i.e., field a2) to determine the flag bit of the virtual machine to be identified. It is understandable that the method by which the blockchain node obtains this field can be found in the aforementioned... Figure 8b or Figure 9c As shown, details will not be elaborated here; after obtaining the a2 field, the identification information of the virtual machine to be identified is compared with the flag bits of each virtual machine in the a2 field to obtain the flag bit of that virtual machine. For example, if the identification information of the virtual machine numbered 3 in the a2 field is set to Java Virtual Machine, and the identification information of the virtual machine numbered 2 is set to Ethereum Virtual Machine, if the identification information of the virtual machine to be identified is Java Virtual Machine, then the flag bit of that virtual machine can be determined to be the flag bit numbered 3 in the a2 field. Figure 10 As shown in (b) above. Finally, perform a bitwise AND operation on the value of the flag bit. If the result is greater than 0, it indicates that the virtual machine has been used; otherwise, it indicates that the virtual machine has not been used.

[0110] The following is based on Figure 6The contract call information shown describes the process of obtaining the virtual machine information called when determining the k-th contract call in the transaction task: In this embodiment, the blockchain node needs to find the offset required to obtain the k-th call, and then shift 'a' (which can be understood as 'a' being used to indicate the previous contract call information) to the right by the corresponding offset, so that the k-th mark is moved to the end. Then, the node performs a bitwise AND operation with the last four bits of the mask to obtain the specific virtual machine number of the k-th call.

[0111] like Figure 11 As shown, the specific method can be implemented using the following formula: a >> ((a >> 60 - k) * 4) & 4. It can be understood that 'a' is used to indicate the previous contract call information. This contract call information is as follows: Figure 11(a) shows “0100 00000111 00000000000000000000000000000000000000001100010010010”, where “a>>60” is used to get the number of times the current contract is called, that is, “0100 00000111000000000000000000000000000000000000001100010010010” becomes “0000 000000000000000000000000000000000000000000000000000000000100”, thus obtaining the current number of contract calls as 4. If k is the first layer, then the offset is "(a>>60-k)*4", which is (4-1)*4=12; then according to "0100 00000111 00000000000000000000000000000000000000001100010010010", we get "0000 00000000 1 ... Shift the "00000000000000000000000000000000000001100010010010" to the right by 12 bits to get "0000 00000000 0100000001110000000000000000000000000000000000011"; then, combine the last four bits of "0000 000000000 01000000011100000000000000000000000000000000000011" with "0000 The last four bits of "000000001 ... Figure 11 As shown in (b) of the diagram.

[0112] 313. When there are idle process resources in the target process pool, allocate process resources to the first contract.

[0113] In this embodiment, the first contract can be allocated according to the resource allocation of the target process pool. In one exemplary scheme, if the first contract is assigned to the original contract process pool of the first virtual machine, and the original contract process pool of the first virtual machine currently has no idle resources, then the first contract is added to the original contract task queue of the first virtual machine. When there are idle resources in the original contract process pool of the first virtual machine, the blockchain node allocates resources to the first contract from the original contract process pool of the first virtual machine.

[0114] If the first contract is assigned to the cross-contract process pool of the first virtual machine, and there are currently no idle resources in the cross-contract process pool of the first virtual machine, then the first contract is added to the cross-contract task queue of the first virtual machine. When there are idle resources in the cross-contract process pool of the first virtual machine, the blockchain node allocates resources to the first contract from the cross-contract process pool of the first virtual machine.

[0115] The following example illustrates a specific application scenario of cross-contract calls, such as... Figure 12 As shown:

[0116] Step 1: Before generating a block, the blockchain retrieves a batch of transactions from the transaction pool, assuming there are N transactions. The blockchain nodes then execute these N transactions sequentially. During this process, each blockchain node invokes a contract.

[0117] Step 2: When the blockchain node executes the target contract of the transaction task, it calls the virtual machine corresponding to the target contract.

[0118] Step 3: The blockchain node determines whether the virtual machine has been used during the execution of the transaction task. If so, proceed to steps 4 and 5; otherwise, proceed to steps 6 and 7.

[0119] Step 4: Add the target contract to the cross-contract task queue of the virtual machine.

[0120] Step 5: When there are idle resources in the cross-contract process pool of the virtual machine, allocate process resources to the target contract.

[0121] Step 6: Add the target contract to the original contract task queue of the virtual machine.

[0122] Step 7: When there are idle resources in the original contract process pool of the virtual machine, allocate process resources to the target contract.

[0123] Execute each transaction according to the above process until all N transactions have been executed.

[0124] The resource allocation device in this application is described in detail below. Please refer to [link / reference]. Figure 13 , Figure 13This is a schematic diagram of one embodiment of the resource allocation device in this application. The resource allocation device 20 includes:

[0125] The acquisition module 201 is used to acquire the identification information of the first virtual machine and the contract call information corresponding to the transaction task. The contract call information is used to indicate the virtual machine call status during the contract execution of the transaction task. The first virtual machine is the virtual machine called when executing the first contract in the transaction task.

[0126] The processing module 202 is used to determine the target process pool of the first contract based on the contract call information and the identification information of the first virtual machine. The target process pool is either a cross-contract process pool or an original contract process pool. The cross-contract process pool is the process resource pool of the contract that executes the transaction task for the second time or later on the first virtual machine. The original contract process pool is the process resource pool of the contract that executes the transaction task for the first time on the first virtual machine.

[0127] The allocation module 203 is used to allocate process resources to the first contract when there are idle process resources in the target process pool.

[0128] This application provides a resource allocation device. Using this device, the process resources of each virtual machine are divided into an original contract process pool and a cross-contract process pool. Thus, for a transaction task, the first executed contract and subsequent invoked contracts use different process pools for process resource allocation. This ensures that each contract in a transaction task can be allocated process resources, thereby avoiding a situation where the first executed contract of a large number of transaction tasks occupies all the process resources in the blockchain, leaving no process resources available for subsequent invoked contracts, leading to resource deadlock and inability to be released.

[0129] Optionally, in the above Figure 13 Based on the corresponding embodiments, in another embodiment of the resource allocation device 20 provided in this application, the processing module 202 is specifically used to obtain the set of identification information of the virtual machines called during the execution of the transaction task according to the contract call information; compare the identification information of the first virtual machine with the set of identification information to obtain a comparison result; and determine the target process pool of the first contract according to the comparison result.

[0130] In this embodiment of the application, a resource allocation device is provided. Using this device, the system determines whether the first contract is executed for the first time or subsequently on the first virtual machine based on recorded virtual machine call information, thereby determining the process resource pool of the first contract. This ensures that the first contract can be allocated process resources, thus avoiding a situation where the first contract occupies process resources while subsequent contracts have no process resources available, leading to resource deadlock and inability to release resources.

[0131] Optionally, in the above Figure 13 Based on the corresponding embodiments, in another embodiment of the resource allocation device 20 provided in this application, the contract call information includes a first field; the first field is used to record the identification information of the virtual machine called in the transaction task;

[0132] The processing module 202 is specifically used to read the first field in the contract call information to obtain the set of identification information of the virtual machine called during the execution of the transaction task.

[0133] This application provides a resource allocation device. Using this device, it is determined whether the first contract is executed for the first time or subsequently on the first virtual machine based on the recorded virtual machine call information. This determines the process resource pool for the first contract, ensuring that the first contract can be allocated process resources. This avoids a situation where the first contract occupies process resources, leaving no process resources available for subsequent contracts, leading to resource deadlock and inability to release resources. Furthermore, using fields to record the virtual machine call information saves storage space.

[0134] Optionally, in the above Figure 13 Based on the corresponding embodiments, in another embodiment of the resource allocation device 20 provided in this application, the contract call information further includes a second field and a third field;

[0135] The second field is used to record the number of contract calls for the transaction task;

[0136] The third field is used to record the call queue of the virtual machine in this transaction task.

[0137] This application provides a resource allocation device. Using this device, other record fields in the contract call information, along with the number of contract calls and the call queue of the virtual machine, can be easily queried to obtain the specific execution details of the transaction task, thereby enabling backtracking of the transaction task's execution process.

[0138] Optionally, in the above Figure 13 Based on the corresponding embodiments, in another embodiment of the resource allocation device 20 provided in this application, the processing module 202 is further configured to read the second field in the contract call information to obtain the number of contract calls in the transaction task, and read the third field in the contract call information to obtain the virtual machine call order during the execution of the transaction task.

[0139] This application provides a resource allocation device. Using this device, other record fields in the contract call information, along with the number of contract calls and the call queue of the virtual machine, are used to obtain the specific execution details of the transaction task, thereby enabling backtracking of the transaction task's execution process. Furthermore, using fields to record the virtual machine call information saves storage space.

[0140] Optionally, in the above Figure 13 Based on the corresponding embodiment, in another embodiment of the resource allocation device 20 provided in this application, the contract call information includes 64 bits, which are binary values, wherein the first field includes 8 bits, the second field includes 4 bits, and the third field includes 52 bits.

[0141] Each bit in the first field indicates the identification information of a virtual machine. When a bit in the second field is 1, it indicates that the virtual machine corresponding to the bit with a value of 1 has been invoked.

[0142] The third field uses 4 bits to indicate the identification information of the virtual machine, and the 52 bits of the third field are inserted into the virtual machine identification information queue according to the virtual machine call order in the execution process of the transaction task.

[0143] This application provides a resource allocation device. Using this device, a specific data structure for contract call information is provided. In this scheme, only 64 bits are needed to record the virtual machine call information in a transaction task, saving storage space.

[0144] Optionally, in the above Figure 13 Based on the corresponding embodiments, in another embodiment of the resource allocation device 20 provided in this application, the processing module 202 is specifically used to determine the target process pool of the first contract as the cross-contract process pool when the comparison result indicates that the first virtual machine has been called in the execution process of the transaction task.

[0145] In this embodiment of the application, a resource allocation device is provided. Using this device, the system determines whether the first contract is executed for the first time or subsequently on the first virtual machine based on recorded virtual machine call information, thereby determining the process resource pool of the first contract. This ensures that the first contract can be allocated process resources, thus avoiding a situation where the first contract occupies process resources while subsequent contracts have no process resources available, leading to resource deadlock and inability to release resources.

[0146] Optionally, in the above Figure 13Based on the corresponding embodiments, in another embodiment of the resource allocation device 20 provided in this application, the processing module 202 is further configured to add the first contract to the cross-contract task queue before allocating process resources to the first contract when there are idle process resources in the target process pool.

[0147] In this embodiment of the application, a resource allocation device is provided. Using this device, when all process pool resources of the target process pool on the virtual machine have been allocated, the first contract is added to the execution queue. This ensures that the first contract is executed according to the queue and guarantees that the first contract can be executed, avoiding blocking and forced execution failure.

[0148] Optionally, in the above Figure 13 Based on the corresponding embodiments, in another embodiment of the resource allocation device 20 provided in this application, the processing module 202 is specifically used to determine the target process pool of the first contract as the original contract process pool if it is determined from the contract call information that the first virtual machine was not called during the execution of the transaction task.

[0149] In this embodiment of the application, a resource allocation device is provided. Using this device, the system determines whether the first contract is executed for the first time or subsequently on the first virtual machine based on recorded virtual machine call information, thereby determining the process resource pool of the first contract. This ensures that the first contract can be allocated process resources, thus avoiding a situation where the first contract occupies process resources while subsequent contracts have no process resources available, leading to resource deadlock and inability to release resources.

[0150] Optionally, in the above Figure 13 Based on the corresponding embodiments, in another embodiment of the resource allocation device 20 provided in this application, the processing module 202 is further configured to add the first contract to the original contract task queue before allocating process resources to the first contract when there are idle process resources in the target process pool.

[0151] In this embodiment of the application, a resource allocation device is provided. Using this device, when all process pool resources of the target process pool on the virtual machine have been allocated, the first contract is added to the execution queue. This ensures that the first contract is executed according to the queue and guarantees that the first contract can be executed, avoiding blocking and forced execution failure.

[0152] Optionally, in the above Figure 13 Based on the corresponding embodiments, in another embodiment of the resource allocation device 20 provided in this application, the number of process resources in the cross-contract process pool is greater than the number of process resources in the original contract process pool.

[0153] In this embodiment of the application, a resource allocation device is provided. Using this device, the process resource sizes of the original contract process pool and the cross-contract process pool are limited. Since the number of contracts initially executed in a transaction task is less than the number of contracts called across the contract pool, the process resources of the original contract process pool can be made smaller than the process resources of the cross-contract process pool. This reasonable allocation of process resources ensures the execution efficiency of the transaction task.

[0154] Optionally, in the above Figure 13 Based on the corresponding embodiments, in another embodiment of the resource allocation device 20 provided in this application, the number of process resources in the cross-contract process pool is equal to the product of the number of process resources in the original contract process pool and a first preset value, wherein the first preset value is equal to the preset contract call layer minus 1.

[0155] This application provides a resource allocation device. Using this device, the process resource sizes of the original contract process pool and the cross-contract process pool are limited. The process resources of the cross-contract process pool are determined based on the number of layers in a typical cross-contract call and the process resources of the original contract process pool. This reasonable allocation of process resources ensures the execution efficiency of transaction tasks.

[0156] The resource allocation device provided in this application can be used on a server; please refer to [link / reference]. Figure 14 , Figure 14 This is a schematic diagram of a server structure provided in an embodiment of this application. The server 300 can vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) 322 (e.g., one or more processors) and memory 332, and one or more storage media 331 (e.g., one or more mass storage devices) for storing application programs 342 or data 344. The memory 332 and storage media 330 can be temporary or persistent storage. The program stored in the storage media 330 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server. Furthermore, the CPU 322 may be configured to communicate with the storage media 331 to execute the series of instruction operations in the storage media 330 on the server 300.

[0157] Server 300 may also include one or more power supplies 326, one or more wired or wireless network interfaces 350, one or more input / output interfaces 358, and / or one or more operating systems 341, such as Windows Server. TM Mac OS X TM UnixTM Linux TM FreeBSD TM etc.

[0158] The steps performed by the blockchain node in the above embodiments can be based on this. Figure 14 The server structure shown.

[0159] The resource allocation device provided in this application can be used in terminal devices. Please refer to [link / reference]. Figure 15 For ease of explanation, only the parts relevant to the embodiments of this application are shown. For specific technical details not disclosed, please refer to the method section of the embodiments of this application. In the embodiments of this application, a smartphone is used as an example for illustration:

[0160] Figure 15 This is a block diagram illustrating a portion of the structure of a smartphone related to the terminal device provided in the embodiments of this application. (Reference) Figure 15 The smartphone includes components such as a radio frequency (RF) circuit 410, a memory 420, an input unit 430, a display unit 440, a sensor 450, an audio circuit 460, a wireless fidelity (WiFi) module 470, a processor 480, and a power supply 490. Those skilled in the art will understand that... Figure 15 The smartphone structure shown does not constitute a limitation on smartphones and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0161] The following is combined with Figure 15 A detailed introduction to the various components of a smartphone:

[0162] RF circuit 410 can be used for receiving and transmitting signals during information transmission or calls. Specifically, it receives downlink information from the base station and processes it with processor 480; additionally, it transmits uplink data to the base station. Typically, RF circuit 410 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low-noise amplifier (LNA), a duplexer, etc. Furthermore, RF circuit 410 can also communicate wirelessly with networks and other devices. The aforementioned wireless communication can use any communication standard or protocol, including but not limited to Global System for Mobile Communication (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, Short Message Service (SMS), etc.

[0163] The memory 420 can be used to store software programs and modules. The processor 480 executes various functions and data processing of the smartphone by running the software programs and modules stored in the memory 420. The memory 420 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the smartphone (such as audio data, phonebook, etc.). In addition, the memory 420 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0164] The input unit 430 can be used to receive input numerical or character information, and to generate key signal inputs related to user settings and function control of the smartphone. Specifically, the input unit 430 may include a touch panel 431 and other input devices 432. The touch panel 431, also known as a touch screen, can collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel 431), and drive the corresponding connected devices according to a pre-set program. Optionally, the touch panel 431 may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch position and the signal generated by the touch operation, and transmits the signal to the touch controller; the touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to the processor 480, and can also receive and execute commands sent by the processor 480. In addition, the touch panel 431 can be implemented using various types such as resistive, capacitive, infrared, and surface acoustic wave. In addition to the touch panel 431, the input unit 430 may also include other input devices 432. Specifically, other input devices 432 may include, but are not limited to, one or more of the following: physical keyboard, function keys (such as volume control buttons, power buttons, etc.), trackball, mouse, joystick, etc.

[0165] Display unit 440 can be used to display information input by the user or information provided to the user, as well as various menus of the smartphone. Display unit 440 may include display panel 441, optionally configured as a liquid crystal display (LCD), organic light-emitting diode (OLED), or similar form. Further, touch panel 431 may cover display panel 441. When touch panel 431 detects a touch operation on or near it, it transmits the information to processor 480 to determine the type of touch event. Subsequently, processor 480 provides corresponding visual output on display panel 441 based on the type of touch event. Although in Figure 15 In this embodiment, the touch panel 431 and the display panel 441 are two separate components to realize the input and output functions of the smartphone. However, in some embodiments, the touch panel 431 and the display panel 441 can be integrated to realize the input and output functions of the smartphone.

[0166] The smartphone may also include at least one sensor 450, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor, wherein the ambient light sensor can adjust the brightness of the display panel 441 according to the ambient light level, and the proximity sensor can turn off the display panel 441 and / or the backlight when the smartphone is moved to the ear. As a type of motion sensor, an accelerometer sensor can detect the magnitude of acceleration in various directions (generally three axes), and can detect the magnitude and direction of gravity when stationary. It can be used for applications that recognize the smartphone's posture (such as landscape / portrait switching, related games, magnetometer posture calibration), vibration recognition-related functions (such as pedometer, tapping), etc. Other sensors that may be configured in the smartphone, such as gyroscopes, barometers, hygrometers, thermometers, and infrared sensors, will not be described in detail here.

[0167] Audio circuit 460, speaker 461, and microphone 462 provide an audio interface between the user and the smartphone. Audio circuit 460 converts received audio data into electrical signals and transmits them to speaker 461, where speaker 461 converts them into sound signals for output. On the other hand, microphone 462 converts collected sound signals into electrical signals, which are received by audio circuit 460, converted into audio data, and then processed by processor 480 before being transmitted via RF circuit 410 to, for example, another smartphone, or the audio data can be output to memory 420 for further processing.

[0168] WiFi is a short-range wireless transmission technology. Smartphones, through their WiFi modules (470), can help users send and receive emails, browse web pages, and access streaming media, providing wireless broadband internet access. Although Figure 15 WiFi module 470 is shown, but it is understood that it is not an essential component of a smartphone and can be omitted as needed without changing the nature of the invention.

[0169] The processor 480 is the control center of the smartphone, connecting various parts of the smartphone through various interfaces and lines. It performs various functions and processes data by running or executing software programs and / or modules stored in the memory 420, and by calling data stored in the memory 420, thereby providing overall monitoring of the smartphone. Optionally, the processor 480 may include one or more processing units; optionally, the processor 480 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the aforementioned modem processor may also not be integrated into the processor 480.

[0170] The smartphone also includes a power supply 490 (such as a battery) that supplies power to various components. Optionally, the power supply can be logically connected to the processor 480 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system.

[0171] Although not shown, smartphones may also include a camera, Bluetooth module, etc., which will not be described in detail here.

[0172] The steps performed by the terminal device in the above embodiments can be based on this Figure 15 The terminal device structure is shown.

[0173] This application also provides a computer-readable storage medium storing a computer program that, when run on a computer, causes the computer to perform the methods described in the foregoing embodiments.

[0174] This application also provides a computer program product including a program, which, when run on a computer, causes the computer to perform the methods described in the foregoing embodiments.

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

[0176] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0177] The units described as separate components may or may not be physically separate. 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 the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0178] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0179] If the integrated unit is implemented as 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 this application, in essence, 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. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0180] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A resource allocation method based on cross-contract calls, characterized in that, include: Obtain the identification information of the first virtual machine and the contract call information corresponding to the transaction task. The contract call information is used to indicate the virtual machine call status during the contract execution of the transaction task. The first virtual machine is the virtual machine called when executing the first contract in the transaction task. The target process pool of the first contract is determined based on the contract call information and the identification information of the first virtual machine. The target process pool is either a cross-contract process pool or an original contract process pool. The cross-contract process pool is the process resource pool of the contract that executes the transaction task for the second time or thereafter on the first virtual machine. The original contract process pool is the process resource pool of the contract that executes the transaction task for the first time on the first virtual machine. When there are idle process resources in the target process pool, process resources are allocated to the first contract.

2. The method according to claim 1, characterized in that, The step of determining the target process pool for the first contract based on the contract call information and the identification information of the first virtual machine includes: Based on the contract call information, obtain the set of identifier information of the virtual machines called during the execution of the transaction task; The identification information of the first virtual machine is compared with the identification information set to obtain the comparison result; The target process pool for the first contract is determined based on the comparison results.

3. The method according to claim 2, characterized in that, The contract call information includes a first field; the first field is used to record the identification information of the virtual machine called in the transaction task; The set of identifier information of the virtual machine invoked during the execution of the transaction task, obtained based on the contract invocation information, includes: The first field in the contract call information is read to obtain the set of identification information of the virtual machine called during the execution of the transaction task.

4. The method according to claim 3, characterized in that, The contract call information also includes a second field and a third field; The second field is used to record the number of contract calls for the transaction task; The third field is used to record the call queue of the virtual machine in the transaction task.

5. The method according to claim 4, characterized in that, After obtaining the contract call information corresponding to the transaction task, the method further includes: The number of contract calls in the transaction task is obtained by reading the second field in the contract call information, and the virtual machine call order during the execution of the transaction task is obtained by reading the third field in the contract call information.

6. The method according to claim 4, characterized in that, The contract call information includes 64 bits, which are binary values. The first field includes 8 bits, the second field includes 4 bits, and the third field includes 52 bits. Each bit in the first field indicates the identification information of a virtual machine. When a bit in the second field is 1, it indicates that the virtual machine corresponding to the bit with a value of 1 has been invoked. The third field uses 4 bits to indicate the identification information of the virtual machine, and the 52 bits of the third field are inserted into the virtual machine identification information queue according to the virtual machine calling order in the execution process of the transaction task.

7. The method according to any one of claims 2 to 6, wherein determining the target process pool of the first contract based on the comparison result comprises: If the comparison result indicates that the first virtual machine has been invoked during the execution of the transaction task, then the target process pool of the first contract is determined to be the cross-contract process pool.

8. The method according to claim 7, characterized in that, Before allocating process resources to the first contract when idle process resources exist in the target process pool, the method further includes: Add the first contract to the cross-contract task queue.

9. The method according to any one of claims 2 to 6, characterized in that, The step of determining the target process pool for the first contract based on the contract call information and the identification information of the first virtual machine includes: If it is determined from the contract call information that the first virtual machine was not invoked during the execution of the transaction task, then the target process pool of the first contract is determined to be the original contract process pool.

10. The method according to claim 9, characterized in that, Before allocating process resources to the first contract when idle process resources exist in the target process pool, the method further includes: Add the first contract to the original contract task queue.

11. The method according to any one of claims 1 to 6, characterized in that, The number of process resources in the cross-contract process pool is greater than the number of process resources in the original contract process pool.

12. The method according to claim 11, characterized in that, The number of process resources in the cross-contract process pool is equal to the product of the number of process resources in the original contract process pool and a first preset value, where the first preset value is equal to the preset contract call layer minus 1.

13. A resource allocation device, characterized in that, include: The acquisition module is used to acquire the identification information of the first virtual machine and the contract call information corresponding to the transaction task. The contract call information is used to indicate the virtual machine call status during the contract execution of the transaction task. The first virtual machine is the virtual machine called when executing the first contract in the transaction task. The processing module is used to determine the target process pool of the first contract based on the contract call information and the identification information of the first virtual machine. The target process pool is either a cross-contract process pool or an original contract process pool. The cross-contract process pool is the process resource pool of the contract that executes the transaction task for the second time or thereafter on the first virtual machine. The original contract process pool is the process resource pool of the contract that executes the transaction task for the first time on the first virtual machine. The allocation module is used to allocate process resources to the first contract when there are idle process resources in the target process pool.

14. The apparatus according to claim 13, characterized in that, The processing module is specifically used to obtain a set of identification information of virtual machines called during the execution of the transaction task based on the contract call information; compare the identification information of the first virtual machine with the set of identification information to obtain a comparison result; and determine the target process pool of the first contract based on the comparison result.

15. The apparatus according to claim 14, characterized in that, The contract call information includes a first field; the first field is used to record the identification information of the virtual machine called in the transaction task; The processing module is specifically used to read the first field in the contract call information to obtain the set of identification information of the virtual machine called during the execution of the transaction task.

16. The apparatus according to claim 15, characterized in that, The contract call information also includes a second field and a third field; The second field is used to record the number of contract calls for the transaction task; The third field is used to record the call queue of the virtual machine in the transaction task.

17. A computer device, characterized in that, include: Memory, processor, and bus system; The memory is used to store programs; The processor is configured to execute a program in the memory, and the processor is configured to execute the method of any one of claims 1 to 12 according to instructions in the program code; The bus system is used to connect the memory and the processor to enable communication between the memory and the processor.

18. A computer-readable storage medium comprising instructions that, when executed on a computer, cause the computer to perform the method as claimed in any one of claims 1 to 12.

19. A computer program product, characterized in that, The computer program product includes instructions that, when executed on a computer device, cause the computer device to perform the method as described in any one of claims 1 to 12.

Images