Contract calling method and related equipment

Abstract

The invention discloses a contract calling method and related equipment, and the method comprises the steps: adding a contract calling bit region in a target contract, and recording a contract calling identifier, a contract calling method name and a contract calling parameter in the contract calling bit region; determining a calling state of a target contract in current contract calling based on the contract calling identifier; if the calling state of the target contract is a contract calling state, reading a contract calling bit region, and enabling the target contract to call a to-be-called contract by using the read contract calling parameter and a contract calling method corresponding to the contract calling method name; and if the calling state of the target contract is a called contract state, reading the contract calling bit region, and enabling the calling contract to call the target contract by using a contract calling method corresponding to the contract calling method name by using the read contract calling parameters. According to the invention, contract calling among different types of smart contracts can be realized.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a contract calling method and related equipment. Background Art

[0002] Blockchain is a database with a data "hash verification" function. Blocks, or data blocks, can be combined into a chain structure in chronological order, and cryptographic algorithms are used to collectively maintain the reliability of the database in a distributed accounting manner. All data blocks are connected in chronological order to form a blockchain.

[0003] In current related technologies, an intermediate transfer layer is generally inserted between multiple virtual machines to adapt and connect different types of virtual machines. When a contract caller calls a contract, the blockchain system learns the type of virtual machine declared by the contract issuer and passes the contract caller's input and the contract code together to the specified type of virtual machine for interpretation and execution.

[0004] Existing technical solutions attempt to establish a universal heterogeneous interaction protocol in various types of virtual machines, but different virtual machines have their own unique architectures and interaction interfaces. When it comes to each specific type of virtual machine, whether the solution can be applied remains to be demonstrated in practice. Therefore, the scope of the current solution is too broad and its feasibility remains to be discussed. Summary of the invention

[0005] An embodiment of the present application provides a contract calling method and related equipment. The related equipment may include a contract calling device, an electronic device, a computer-readable storage medium and a computer program product, which can realize contract calling between different types of smart contracts.

[0006] The present application embodiment provides a contract calling method, including:

[0007] Add a contract call bit area in the target contract, wherein the contract call bit area records the contract call identifier, the contract call method name, and the contract call parameters;

[0008] Based on the contract call identifier, determine the call status of the target contract in the current contract call;

[0009] If the calling state of the target contract is the calling contract state, read the contract calling bit area, and make the target contract use the read contract calling parameters and the contract calling method corresponding to the contract calling method name to call the contract to be called;

[0010] If the calling state of the target contract is the called contract state, read the contract calling bit area, and make the calling contract use the read contract calling parameters and the contract calling method corresponding to the contract calling method name to call the target contract.

[0011] Accordingly, the embodiment of the present application provides a contract calling device, including:

[0012] An area adding unit, used for adding a contract call bit area in the target contract, wherein the contract call bit area records a contract call identifier, a contract call method name, and a contract call parameter;

[0013] A state determination unit, configured to determine the call state of the target contract in the current contract call based on the contract call identifier;

[0014] The first execution unit is used for reading the contract calling bit area if the calling state of the target contract is the calling contract state, and making the target contract use the read contract calling parameters and the contract calling method corresponding to the contract calling method name to call the contract to be called;

[0015] The second execution unit is used to read the contract calling bit area if the calling state of the target contract is the called contract state, and enable the calling contract to use the read contract calling parameters and the contract calling method corresponding to the contract calling method name to call the target contract.

[0016] Optionally, in some embodiments of the present application, the first execution unit may include a first execution subunit, a first reading subunit, and a first calling subunit, as follows:

[0017] A first execution subunit, configured to execute the target contract through a first virtual machine if the calling state of the target contract is a calling contract state;

[0018] A first reading subunit is used to read the contract call bit area if it is determined that the current contract call is a heterogeneous call;

[0019] The first calling subunit is used to call the contract to be called through the second virtual machine corresponding to the contract to be called based on the read contract calling method name and the contract calling parameters.

[0020] Optionally, in some embodiments of the present application, the first calling subunit may include a first writing subunit, a first parsing subunit and a second calling subunit, as follows:

[0021] A first writing subunit, used for writing the read contract calling method name and the contract calling parameters into the first virtual machine;

[0022] A first parsing subunit, used to read and parse the contract calling method name and the contract calling parameters from the first virtual machine to obtain the contract calling method and the parsed parameters;

[0023] The second calling subunit is used to call the contract to be called through a second virtual machine corresponding to the contract to be called based on the contract calling method and the parsed parameters.

[0024] Optionally, in some embodiments of the present application, the second calling sub-unit can be specifically used to obtain the contract address of the contract to be called, and based on the contract address, determine the contract type of the contract to be called; determine a second virtual machine corresponding to the contract type; based on the contract calling method name and the contract calling parameters, call the contract to be called through the second virtual machine.

[0025] Optionally, in some embodiments of the present application, the first parsing sub-unit can be specifically used to read the contract calling method name and the contract calling parameters from the first virtual machine; determine the contract calling method based on the contract calling method name; parse the contract calling parameters based on the contract type to obtain the parsed parameters.

[0026] Optionally, in some embodiments of the present application, the second execution unit may include a second execution subunit and a third execution subunit, as follows:

[0027] A second execution subunit is used for executing the calling contract through the first virtual machine if the calling state of the target contract is the called contract state, and the calling contract carries the contract calling method name and contract calling parameters;

[0028] The third execution sub-unit is used to determine that the current contract call is a heterogeneous call based on the contract type of the calling contract, and to perform the operation of calling the target contract through the calling contract based on the contract calling method name and the contract calling parameters.

[0029] Optionally, in some embodiments of the present application, the third execution subunit may include a second writing subunit and a second reading subunit, as follows:

[0030] A second writing subunit is used to write the contract calling method name and the contract calling parameters into a second virtual machine corresponding to the target contract;

[0031] The second reading subunit is used to read the contract calling method name and the contract calling parameters in the second virtual machine through the distribution function of the target contract, and call the target contract.

[0032] Optionally, in some embodiments of the present application, the second reading subunit may include a second parsing subunit and a third calling subunit, as follows:

[0033] A second parsing subunit is used to read and parse the contract calling method name and the contract calling parameters in the second virtual machine through the distribution function of the target contract to obtain the contract calling method and the parsed parameters;

[0034] The third calling subunit is used to call the target contract based on the parsed parameters and the contract calling method.

[0035] Optionally, in some embodiments of the present application, the second parsing sub-unit can be specifically used to read the contract call method name in the second virtual machine through the distribution function of the target contract; determine the contract call method, the number of contract call parameters, the order of contract call parameters, and the type of contract call parameters that match the contract call method name; read the contract call parameters that meet the number of contract call parameters from the second virtual machine through the distribution function of the second contract; parse the contract call parameters based on the contract call parameter order and the contract call parameter type to obtain the parsed parameters.

[0036] An electronic device provided in an embodiment of the present application includes a processor and a memory, wherein the memory stores a plurality of instructions, and the processor loads the instructions to execute the steps in the contract calling method provided in the embodiment of the present application.

[0037] An embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored, wherein when the computer program is executed by a processor, the steps in the contract calling method provided in the embodiment of the present application are implemented.

[0038] In addition, an embodiment of the present application also provides a computer program product, including a computer program or instructions, which, when executed by a processor, implements the steps in the contract calling method provided in the embodiment of the present application.

[0039] The embodiment of the present application provides a contract calling method and related equipment, which can add a contract calling bit area in the target contract, and the contract calling bit area records the contract calling identifier, the contract calling method name, and the contract calling parameters; based on the contract calling identifier, determine the calling state of the target contract in the current contract calling; if the calling state of the target contract is the calling contract state, read the contract calling bit area, and make the target contract use the read contract calling parameters to call the contract to be called by the contract calling method corresponding to the contract calling method name; if the calling state of the target contract is the called contract state, read the contract calling bit area, and make the calling contract use the read contract calling parameters to call the target contract by the contract calling method corresponding to the contract calling method name. The technical solution of the present application can be used to add a contract calling bit area in the target contract, so as to understand the contract calling identifier, contract calling method name, and contract calling parameters required for the contract calling according to the contract calling bit area, and then use the above information to realize the contract calling between different types of contracts. Because in the prior art, an intermediate switching layer is generally inserted between multiple virtual machines to adapt and dock different types of virtual machines. When the contract caller calls the contract, the blockchain system learns the type of virtual machine declared by the contract issuer, and passes the input of the contract caller and the contract code to the specified type of virtual machine for interpretation and execution. The existing technical solutions attempt to establish a universal heterogeneous interaction protocol in various virtual machines, but different virtual machines have their own unique architecture and interaction interface. When it comes to each specific type of virtual machine, whether the solution can be applied remains to be demonstrated in practice. Therefore, the scope of the existing technology is too broad and its feasibility remains to be discussed. The technical solution of the present application can avoid the insertion of the intermediate transfer layer, so that the method and parameters of the contract call can be directly obtained, which greatly simplifies the procedure of the contract call and improves the efficiency of the contract call. In addition, the application of the technical solution of the present application can also obtain the method name and parameters required for the call through the contract call bit area, thereby bypassing the ABI interface and the calldata parameter mechanism, so as to avoid some contracts that use the ABI interface and the calldata parameter mechanism, so that other virtual machines cannot recognize the method and parameters of the call, and thus it is difficult to achieve interconnection between different types of contracts. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0041] Figure 1It is a scenario diagram of the contract calling method provided in the embodiment of the present application;

[0042] Figure 2 This is the first flow chart of the contract calling method provided in the embodiment of the present application;

[0043] Figure 3 is a second flow chart of the contract calling method provided in an embodiment of the present application;

[0044] Figure 4 It is a third flow chart of the contract calling method provided in the embodiment of the present application;

[0045] Figure 5 It is a structural diagram of the blockchain system provided in the embodiment of the present application;

[0046] Figure 6 It is another structural schematic diagram of the blockchain system provided in an embodiment of the present application;

[0047] Figure 7 This is a flow chart of a target contract calling a contract to be called provided by an embodiment of the present application;

[0048] Figure 8 This is a flowchart of a calling contract calling a target contract provided by an embodiment of the present application;

[0049] Fig. 9 It is a structural diagram of a contract calling device provided in an embodiment of the present application;

[0050] Fig.10 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0051] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of this application.

[0052] The embodiment of the present application provides a contract calling method and related equipment, and the related equipment may include a contract calling device, an electronic device, a computer-readable storage medium and a computer program product. The contract calling device can be integrated in an electronic device, and the electronic device can be a terminal or a server.

[0053] Specifically, the server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal can be a smart phone, a tablet computer, a laptop, a desktop computer, a smart speaker, a smart watch, etc., but is not limited to this. The terminal and the server can be directly or indirectly connected via wired or wireless communication, and this application does not limit this.

[0054] like Figure 1 As shown, a contract calling method is executed by a terminal and a server together as an example. The contract calling system provided in the embodiment of the present application includes a terminal and a server; the terminal and the server are connected via a network, such as a wired or wireless network connection, wherein the contract calling device can be integrated in the server.

[0055] Among them, the server can be used to: add a contract call bit area in the target contract, in which the contract call bit area records the contract call identifier, the contract call method name, and the contract call parameters; based on the contract call identifier, determine the call status of the target contract in the current contract call; if the call status of the target contract is the call contract status, read the contract call bit area, and make the target contract use the read contract call parameters to call the contract to be called using the contract call method corresponding to the contract call method name; if the call status of the target contract is the called contract status, read the contract call bit area, and make the calling contract use the read contract call parameters to call the target contract using the contract call method corresponding to the contract call method name. Among them, the server can be a single server, or it can be a server cluster or cloud server composed of multiple servers. The contract call method or device disclosed in this application, wherein multiple servers can be composed of a blockchain, and the server is a node on the blockchain.

[0056] The terminal can be used to receive the result of calling the contract from the server so that the contract caller can perform corresponding subsequent operations based on the result. The terminal can include a tablet computer, a laptop, or a personal computer (PC). A client can also be set on the terminal, which can be an application client or a browser client, etc.

[0057] It should be noted that the contract calling system provided in the embodiment of the present application can be a distributed system connected by a client and multiple nodes (any form of computing device in the access network, such as a server and a user terminal) through network communication.

[0058] Take the distributed system as the blockchain system as an example, see Figure 5 , Figure 5 It is an optional structural diagram of the distributed system 100 provided in the embodiment of the present application applied to the blockchain system, which is formed by multiple nodes 200 (any form of computing devices in the access network, such as servers, user terminals) and clients 300. The nodes form a point-to-point network, which is an application layer protocol running on the Transmission Control Protocol (TCP). In a distributed system, any machine such as a server or a terminal can join and become a node, and the node includes a hardware layer, an intermediate layer, an operating system layer, and an application layer.

[0059] See also Figure 5 The functions of each node in the blockchain system shown include:

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

[0061] In addition to the routing function, the node can also have the following functions:

[0062] 2) Applications are deployed in the blockchain to implement specific businesses based on actual business needs, record data related to the implementation of functions to form record data, carry digital signatures in the record data to indicate the source of the task data, and send the record data to other nodes in the blockchain system for other nodes to add the record data to a temporary block when they successfully verify the source and integrity of the record data.

[0063] See also Figure 6 , Figure 6 This is an optional schematic diagram of the block structure provided by the embodiment of the present application. Each block includes the hash value of the transaction record stored in this block (the hash value of this block) and the hash value of the previous block. Each block is connected by the hash value to form a blockchain. In addition, the block can also include information such as the timestamp when the block was generated. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains relevant information for verifying the validity of its information (anti-counterfeiting) and generating the next block.

[0064] It should be noted that the description order of the following embodiments is not intended to limit the preferred order of the embodiments.

[0065] This embodiment will be described from the perspective of a contract calling device, which can be integrated into an electronic device, such as a server or terminal. It is understandable that in the specific implementation of this application, 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 relevant data must comply with relevant laws, regulations and standards of relevant countries and regions. Figure 2 As shown, the specific process of the contract calling method can be as follows:

[0066] 201. Add a contract call bit area in the target contract, and the contract call bit area records the contract call identifier, the contract call method name, and the contract call parameters.

[0067] Among them, blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains a batch of network transaction information, which is used to verify the validity of its information and generate the next block.

[0068] Smart contracts are computer protocols designed to disseminate, verify or execute contracts in an information-based manner. They are essentially a computer-executed program. The contract trigger conditions, execution matters and other detailed contract contents are stored in the blockchain network in the form of code. When the trigger conditions are met, the transaction can be accurately and automatically executed without the involvement of a third party, thus ensuring the fairness, justice and reliability of the execution of smart contracts. Among them, smart contracts can include multiple contract types, for example, contract types can include solidity contracts, wasm (WebAssembly) contracts, and so on.

[0069] Among them, the target contract is a contract that is configured in the original protocol to encode the information required for the contract call into a byte stream when the contract is called, such as a solidity smart contract. Among them, the solidity smart contract is a smart contract written in the solidity language, which is used to write smart contracts for the Ethereum network, and the smart contract written by it is executed by the Ethereum virtual machine. Because in solidity, the called methods and parameters will be encoded as a byte stream in the form of calldata by the ABI interface, such a mechanism makes it impossible for other virtual machines to recognize the called methods and parameters, making heterogeneous calls between solidity contracts and other types of contracts troublesome. This application can use the parameter buffer to bypass the calldata parameter mechanism, thereby realizing heterogeneous calls between solidity contracts and other types of contracts.

[0070] Among them, wasm is a program encoding format. When the program code is encoded into wasm bytecode, the program can be executed by the wasm virtual machine.

[0071] Among them, contract calls can include isomorphic calls and heterogeneous calls. Isomorphic calls refer to calls where the contract type and virtual machine type of the calling contract are exactly the same as those of the called contract, such as a solidity contract calling a solidity contract, or a wasm contract calling a wasm contract. Heterogeneous calls refer to calls where the calling contract and the called contract have different contract and virtual machine types. Heterogeneous calls are also called cross-contract type calls, or cross-type and cross-contract calls, such as a solidity contract calling a wasm contract.

[0072] Among them, the contract call bit area is a state variable of byte stream array type set in the smart contract, which is used to store the relevant information required for the contract call. The state variable is a variable type of the solidity contract, and the assignment and modification of this type of variable will be automatically stored permanently. For example, when calling other types of contracts through solidity contracts, the contract call bit area can be used as a parameter buffer, and the relevant information required for the contract call is written into the contract call bit area, so that when the contract call operation is subsequently executed, the contract call operation can be performed according to the information written in the contract call bit area. For another example, when calling a solidity contract through other types of contracts, the contract call bit area can be used as an input parameter extraction area, and the relevant information required for the contract call is written into the contract call bit area, so that when the contract call operation is subsequently executed, the contract call operation can be performed according to the information written in the contract call bit area.

[0073] Among them, the contract call identifier can be used to characterize this contract call. The contract call identifier is stored in the contract call bit area. The contract call identifier can be used to understand the relevant information of this contract call, such as the call status of the contract in this contract call, whether it is a heterogeneous call, etc.

[0074] Among them, the contract call method name can represent the contract call method actually applied in this contract call. The contract call method name is stored in the contract call bit area, and the method used in this contract call can be understood through the contract call method name.

[0075] Among them, the contract call parameters are the parameters required for this contract call, and the contract call parameters are stored in the contract call bit area. The contract call parameters may include a tag for identifying the parameter type or index, as well as parameter value and other information. The contract call operation can be executed through the contract call parameters.

[0076] For example, a contract call bit area can be added to the target contract, in which the contract call identifier, contract call method name, and contract call parameters are recorded. However, for different contract call states of the target contract, the contract call bit area also has certain differences, such as Figure 7 As shown in, this is the storage format of the contract call bit area when the target contract is in the contract call state; Figure 8 As shown, this is the storage format of the contract call bit area when the target contract is in the called contract state.

[0077] Among them, the contract call status includes the calling contract status and the called contract status. If the target contract is in the calling contract status, it means that in this contract call, other contracts are called through the target contract; if the target contract is in the called contract status, it means that in this contract call, the target contract is called through other contracts.

[0078] In one embodiment, for example, if the call state of the target contract is the call contract state, Figure 7 As shown, the target contract can be a solidity contract, and a state variable of byte stream array type can be set in the target contract as a parameter buffer for heterogeneous calls, and the state variable is the contract call bit area. Then write the contract call identifier in the first element of the contract call bit area to identify the current contract call as a heterogeneous call. Write the contract call method name in the second element of the contract call bit area to identify the contract call method used by the current contract call. Write the contract call parameters in the area other than the first element and the second element of the contract call bit area, wherein the contract call parameters can be arranged in sequence as pairs and written into the contract call bit area, each pair identifies a parameter of a contract call method, and in each pair of parameters, the element at the front position is used to identify the parameter type or parameter index, and the element at the back position is used to identify the parameter value, and the two elements before and after identify a complete parameter. After all contract call parameters are written into the contract call bit area, the parameter end marker can also be appended to the end of the contract call bit area to indicate that the information related to the contract call has been stored.

[0079] Among them, whether to specifically identify the parameter type or parameter index in the contract call parameters depends on the language type of the contract to be called. For example, for a contract to be called in a static language type, the parameter type needs to be identified in the contract call parameters; for a contract to be called in a dynamic language type and using unordered parameters, the parameter index needs to be identified in the contract call parameters, and so on.

[0080] Among them, static language types are languages ​​with type declarations when defining variables. The type of the variable is determined at compile time, and the type of the variable cannot be modified at runtime, so that the compiler can determine the total amount of memory required at runtime.

[0081] Among them, the dynamic language type is a language without type declaration when defining variables. The type of the variable is determined at runtime, and the type of the variable can be modified at runtime.

[0082] In one embodiment, for example, if the calling state of the target contract is the called contract state, such as Figure 8 As shown, the target contract can be a solidity contract, and a state variable of a read-only byte stream array type can be set in the target contract as an input parameter extraction area, wherein the state variable is the first state variable of the target contract and is of read-only type, and the state variable is the contract call bit area. Then, the second virtual machine corresponding to the target contract supports the writing of data in the contract call bit area, writes the contract call identifier in the first element of the contract call bit area, writes the contract call method name in the second element, and writes the contract call parameters in the area other than the first element and the second element in the contract call bit area. The size of the contract call bit area can be set to the number of parameters of the method with the largest number of parameters in the current contract plus 1, wherein the extra 1 is used to store the contract call method name.

[0083] Using the technical solution of this application, when a solidity contract is called isomorphically or directly by a user, the contract call method and contract call parameters will be read from the calldata area in the contract where data is stored. However, when a solidity contract is called heterogeneously by other types of contracts, data will no longer be read from calldata, but the contract call method name and contract call parameters will be read from the contract call bit area.

[0084] 202. Based on the contract call identifier, determine the call status of the target contract in the current contract call.

[0085] For example, the contract call identifier can be used to understand the call status of the target contract in this contract call, so as to determine whether the target contract calls other contracts or is called by other contracts in this contract call.

[0086] 203. If the calling state of the target contract is the calling contract state, read the contract calling bit area, and enable the target contract to use the read contract calling parameters and the contract calling method corresponding to the contract calling method name to call the contract to be called.

[0087] Among them, the contract to be called refers to the contract called by other contracts in the contract calling operation. For example, in an embodiment of the present application, when the calling state of the target contract is the calling contract state, the contract to be called is the contract called by the target contract.

[0088] For example, if it is known from the contract call identifier that in this contract call, the call status of the target contract is the calling contract status, it means that the target contract needs to make a contract call to the contract to be called in this contract call. Then, the contract call bit area in the target contract can be read, and the target contract can use the read contract call parameters and the contract call method corresponding to the contract call method name to call the contract to be called.

[0089] Optionally, in one embodiment, the step of “if the calling state of the target contract is the calling contract state, reading the contract calling bit area, and causing the target contract to use the read contract calling parameters and the contract calling method corresponding to the contract calling method name to call the contract to be called” may include:

[0090] If the calling state of the target contract is the calling contract state, executing the target contract through the first virtual machine;

[0091] If the current contract call is determined to be a heterogeneous call, read the contract call bit area;

[0092] Based on the read contract calling method name and contract calling parameters, the contract to be called is called through the second virtual machine corresponding to the contract to be called.

[0093] A virtual machine is a complete computer system that is simulated by software and has complete hardware system functions and runs in a completely isolated environment. Any work that can be done in a physical computer can also be done in a virtual machine. When creating a virtual machine in a computer, part of the hard disk and memory capacity of the physical machine needs to be used as the hard disk and memory capacity of the virtual machine. Each virtual machine has an independent CMOS, hard disk and operating system, and the virtual machine can be operated just like a physical machine.

[0094] For example, if the call state of the target contract is the call contract state, the target contract can be executed through the first virtual machine. If the current contract call is determined to be a heterogeneous call, the contract call bit area can be read, and then based on the read contract call method name and contract call parameters, the second virtual machine corresponding to the contract to be called can be used to call the contract to be called.

[0095] Optionally, in one embodiment, the step of “calling the contract to be called through the second virtual machine corresponding to the contract to be called based on the read contract calling method name and contract calling parameters” may include:

[0096] Write the read contract call method name and contract call parameters into the first virtual machine;

[0097] Read and parse the contract calling method name and contract calling parameters from the first virtual machine to obtain the contract calling method and the parsed parameters;

[0098] Based on the contract calling method and the parsed parameters, the contract to be called is called through the second virtual machine corresponding to the contract to be called.

[0099] For example, a heterogeneous call switch, a parameter counter, and a parameter recorder can be set in the first virtual machine, where the first virtual machine can be an EVM virtual machine, and the heterogeneous call switch, parameter counter, and parameter recorder set in the first virtual machine are bound to the contract instance to ensure that each contract instance has an exclusive heterogeneous call switch, a parameter counter, and a parameter recorder, thereby avoiding data competition and data contamination problems caused by concurrent execution of contracts.

[0100] Among them, the heterogeneous call switch can be used to identify whether the step of storing data in the virtual machine has entered the parameter preparation process of the heterogeneous call. If the heterogeneous call switch is in the on state, it means that the step of storing data in the virtual machine has entered the parameter preparation process of the heterogeneous call; if the heterogeneous call switch is in the off state, it means that the step of storing data in the virtual machine has not yet entered the parameter preparation process of the heterogeneous call.

[0101] Among them, the parameter counter is used to determine the element number in the contract call bit area currently stored by the first virtual machine since the heterogeneous call switch is turned on, and then determine whether the currently stored element is the contract call method name, contract call parameter, or parameter end mark.

[0102] Among them, the parameter recorder is used to record the contract call method name and contract call parameters identified by the parameter counter. The record of the contract call parameters in the parameter recorder should retain the parameter type or parameter index, parameter value, and the order between them.

[0103] For example, when the first virtual machine stores data through the sstore instruction, it will first check whether the heterogeneous call switch is turned on. If the heterogeneous call switch is turned on, it means that the heterogeneous call mode has been turned on and is currently in the parameter preparation stage of the heterogeneous call. Among them, the sstore instruction is an instruction in the virtual machine used to store the state variables in the contract on the chain.

[0104] Then, the parameter counter can be used to determine which element is currently stored in the contract call bit area, and then determine the type of element currently stored, that is, whether the element belongs to the contract call method name, contract call parameter, or parameter end mark, and increase the value in the parameter counter by 1. Then, the contract call method name and contract call parameter are recorded in the parameter recorder according to the element type.

[0105] If the currently stored data is a parameter end marker, then turn off the heterogeneous call switch to indicate that the subsequent storage of the sstore instruction is normal storage to avoid accidental loss of normal storage data. Then, read and parse the contract call method name and contract call parameters from the first virtual machine to obtain the contract call method and the parsed parameters, and based on the contract call method and the parsed parameters, call the contract to be called through the second virtual machine corresponding to the contract to be called.

[0106] In one embodiment, for example, when the first virtual machine stores data through the sstore instruction, it will first check whether the heterogeneous call switch is turned on. If the heterogeneous call switch is not turned on, the sstore instruction also needs to check the contract call identifier to determine whether the current contract call is a heterogeneous call. If it is determined that the current contract call is not a heterogeneous call, it means that the current storage is just ordinary storage, not heterogeneous call parameter preparation, then the storage operation is continued according to the conventional storage method; if it is determined that the current contract call is a heterogeneous call, the heterogeneous call switch is turned on and the parameter counter is initialized, indicating that the parameter preparation of the heterogeneous call has begun.

[0107] Optionally, in one embodiment, the step of “reading and parsing the contract calling method name and the contract calling parameters from the first virtual machine to obtain the contract calling method and the parsed parameters” may include:

[0108] Read the contract calling method name and contract calling parameters from the first virtual machine;

[0109] Determine the contract calling method based on the contract calling method name;

[0110] Parse the contract call parameters based on the contract type and obtain the parsed parameters.

[0111] For example, the embodiment of the present application can transform the call instruction or staticcall instruction of the first virtual machine so that it reads and parses the contract calling method name and contract calling parameters in the parameter recorder, determines the contract calling method according to the contract calling method name, parses the contract calling parameters according to the contract type of the contract to be called, obtains the parsed parameters, and finally executes heterogeneous cross-contract calls.

[0112] Among them, the call instruction or staticcall instruction is an instruction in the virtual machine used to execute the call contract. The call instruction represents a normal call, and the staticcall instruction represents a static call, that is, the state variables of the called contract will not change after the call.

[0113] Optionally, in one embodiment, the step of “calling the contract to be called through the second virtual machine corresponding to the contract to be called based on the contract calling method name and the contract calling parameters” may include:

[0114] Get the contract address of the contract to be called, and determine the contract type of the contract to be called based on the contract address;

[0115] Determining a second virtual machine corresponding to the contract type;

[0116] Based on the contract calling method name and the contract calling parameters, the contract to be called is called through the second virtual machine.

[0117] For example, when the first virtual machine executes a call instruction or a staticcall instruction, the contract address of the contract to be called can be obtained, and the contract type of the contract to be called and the contract code of the contract to be called can be determined based on the contract address. Then, the second virtual machine corresponding to the contract to be called is queried based on the contract type of the contract to be called, and the virtual machine instance of the second virtual machine is started. Then, the contract call method name and contract call parameters recorded in the parameter recorder in the first virtual machine are read, and the contract call method is determined based on the contract call method name, and the contract call parameters are parsed based on the contract type of the contract to be called to obtain the parsed parameters.

[0118] Among them, if the language type of the contract to be called is a dynamic language, the second virtual machine is called to execute the contract call method through the parameter index and parameter value in the contract call parameter; if the language type of the contract to be called is a static language, the parameter value of the byte stream type is converted to the value of the corresponding parameter type through the parameter type in the contract call parameter, and then the second virtual machine is called to execute the contract call method through the converted parameter value. If the execution is successful, the execution result is returned; if the execution fails, an error message is returned.

[0119] In one embodiment, for example, when the call instruction or staticcall instruction returns, the first virtual machine can clear the parameters previously prepared for the heterogeneous call and reset the parameter counter to the initial value. If the current target contract has multiple heterogeneous contract calls, the contract call bit area can also be reused.

[0120] The prior art generally inserts an intermediate transfer layer between multiple virtual machines to adapt and connect various types of virtual machines. When the contract caller calls the contract, the blockchain system learns the type of virtual machine declared by the contract publisher, and passes the input of the contract caller and the contract code to the specified type of virtual machine for interpretation and execution. The prior art solution attempts to establish a universal heterogeneous interaction protocol in various virtual machines, but different virtual machines have their own unique architecture and interaction interface. When it comes to each specific type of virtual machine, whether the solution can be applied remains to be demonstrated in practice. Therefore, the scope of the current solution is too broad and its feasibility remains to be discussed. In addition, the prior art solution inserts a universal API layer between various virtual machines and the world state, which will significantly increase the redundancy of the blockchain code. The more types of virtual machines that are adapted, the more redundant code of the API, and the more complex the calling interface, the corresponding decrease in interactive performance and the increase in vulnerability risk. The technical solution of this application is designed for solidity heterogeneous calls alone, with clear logic, no redundant code of the universal adaptation solution, and no reduction in performance and increase in vulnerability risk due to increased code complexity.

[0121] At the same time, since the solidity contract will use the ABI interface (application binary interface) to encode the methods and parameters to be called into the form of calldata, the virtual machine cannot recognize the methods and parameters to be called using the existing technical solution, and thus cannot implement the solution of calling other types of contracts through the solidity contract. By using the parameter buffer mechanism in the technical solution of this application, the ABI interface and calldata parameter mechanism are bypassed, so that the solidity contract can call other types of contracts across virtual machines with a clear and feasible solution, which is more targeted and certain to implement. Among them, the ABI interface is the application binary interface of solidity, which is used to encode the methods and parameters to be called into calldata. When calling the solidity contract, the calldata can be directly passed in, thereby improving the parsing efficiency of the virtual machine.

[0122] By applying the technical solution of this application, the solidity contract can bypass the ABI interface and calldata mechanism when calling other types of contracts in a heterogeneous manner, making the entire implementation method more specific and clear, thereby reducing the complexity of parameter parsing and processing, and being more user-friendly in use. In addition, by applying the technical solution of this application, on the one hand, the logical complexity brought about by adding general adaptation solutions such as intermediate interactions in the prior art can be avoided; on the other hand, the problems brought about by code redundancy, increased development burden, increased security risks, and decreased user experience in the prior art can also be avoided.

[0123] 204. If the calling state of the target contract is the called contract state, read the contract calling bit area, and make the calling contract use the read contract calling parameters to call the target contract using the contract calling method corresponding to the contract calling method name.

[0124] Among them, the calling contract refers to the contract that calls other contracts in the contract calling operation. For example, in an embodiment of the present application, when the calling state of the target contract is the called contract state, the calling contract is the contract that calls the target contract.

[0125] For example, if it is known from the contract call identifier that in this contract call, the call status of the target contract is the called contract status, it means that the target contract needs to be called by other contracts in this contract call. Then the contract call bit area in the target contract can be read, and the calling contract can use the read contract call parameters and the contract call method corresponding to the contract call method name to call the target contract.

[0126] Optionally, in one embodiment, the step of “if the calling state of the target contract is the called contract state, reading the contract calling bit area, and causing the calling contract to use the read contract calling parameters to call the target contract using the contract calling method corresponding to the contract calling method name” may include:

[0127] If the calling state of the target contract is the called contract state, the calling contract is executed by the first virtual machine, and the calling contract carries the contract calling method name and contract calling parameters;

[0128] If the current contract call is determined to be a heterogeneous call based on the contract type of the calling contract, the operation of calling the target contract is executed by calling the contract based on the contract calling method name and contract calling parameters.

[0129] For example, if the calling state of the target contract is the called contract state, the calling contract can be executed through the first virtual machine, wherein the calling contract carries the contract calling method name and the contract calling parameters. In addition, a heterogeneous calling switch can be set in the second virtual machine corresponding to the target contract, and a heterogeneous calling switch is bound to a contract instance to avoid data competition and data contamination problems caused by concurrent execution of contracts. The heterogeneous calling switch will be closed after the contract calling parameters are written.

[0130] Before the second virtual machine is called to execute the target contract, the second virtual machine will first determine the contract type of the calling contract. If the contract type of the calling contract is the same as the contract type of the target contract, it is considered an isomorphic cross-contract call and the contract call is performed according to the original process; if the contract type of the calling contract is different from the contract type of the target contract, the heterogeneous call switch is turned on to indicate that the next process is executed according to the heterogeneous call. For example, the operation of calling the target contract can be executed by calling the contract based on the contract call method name and the contract call parameters.

[0131] Optionally, in one embodiment, the step of “calling the target contract by calling the contract execution based on the contract calling method name and the contract calling parameters” may include:

[0132] Write the contract call method name and contract call parameters into the second virtual machine corresponding to the target contract;

[0133] Through the distribution function of the target contract, the contract calling method name and contract calling parameters in the second virtual machine are read, and the target contract is called.

[0134] For example, an input parameter extraction area can be set in the second virtual machine corresponding to the target contract. The input parameter extraction area is the specific implementation of the contract input parameter extraction area at the virtual machine layer. The data directly read from the contract input parameter extraction area is actually stored here. Among them, one input parameter extraction area is bound to one contract instance to ensure that each input parameter extraction area is exclusively occupied by only one contract instance, thereby avoiding data competition and data contamination problems caused by concurrent execution of contracts.

[0135] After the heterogeneous call switch is turned on, the second virtual machine will write the contract call method name and contract call parameters into the input parameter extraction area in sequence, where the position of the input parameter extraction area can be confirmed by the slot of the second virtual machine. Because the input parameter extraction area is set to the position of the first state variable of the target contract, the writing of the contract call method name and contract call parameters must start from slot 0 until the input parameter end mark is written.

[0136] Specifically, the contract call identifier can be written at the position of the first element in the input parameter extraction area, and then the contract call method name can be converted into a byte stream and written into the position of the second element in the input parameter extraction area. The contract call parameters are then converted into a byte stream and written one by one in sequence to the subsequent positions of the input parameter extraction area. Since the contract call parameters themselves have a certain order, writing into the input parameter extraction area must also follow a certain order. After all the contract call parameters have been written, the input parameter end marker can be appended to the end of the parameters so that when the parameters are read later, the heterogeneous call switch can be turned off when the input parameter end marker is read.

[0137] Optionally, in one embodiment, the step of “reading the contract call method name and contract call parameters in the second virtual machine through the distribution function of the target contract, and calling the target contract” may include:

[0138] Through the distribution function of the target contract, read and parse the contract calling method name and contract calling parameters in the second virtual machine to obtain the contract calling method and the parsed parameters;

[0139] Call the target contract based on the parsed parameters and the contract calling method.

[0140] The distribution function is a function set as the contract entry in the target contract. The distribution function has no parameters and returns a byte stream type return value. The function name, parameters, and return value of the distribution function are uniformly fixed, so the function signature is also uniformly fixed. When other types of functions call the target contract, they can directly pass in the signature call of the distribution function.

[0141] For example, the second virtual machine generates a contract instance based on the contract call method name and contract call parameters, and calls the contract execution with the signature of the target contract's distribution function. The distribution function reads the contract call method name and contract call parameters from the input parameter extraction area and matches the execution. When the target contract's distribution function reads elements from the input parameter extraction area, the sload instruction of the second virtual machine is triggered. When the sload instruction is executed, it is necessary to first check whether the heterogeneous call switch is turned on. Among them, the sload instruction is an instruction in the virtual machine used to read data from storage for contract execution.

[0142] If the heterogeneous call switch is not turned on, data is read from the storage according to the original logic; if the heterogeneous call switch is already turned on, data is read from the input parameter extraction area, and if the data read is ordinary data, the instruction returns the data, and the code logic of the target contract distinguishes whether the data read is the contract call method name or the contract call parameter according to the reading position; if the data read is the end mark of the input parameter, it is regarded as the completion of parameter reading, and the heterogeneous call switch can be turned off to indicate that data is read from the storage later.

[0143] Optionally, in one embodiment, the step of “reading and parsing the contract call method name and contract call parameters in the second virtual machine through the distribution function of the target contract to obtain the contract call method and the parsed parameters” may include:

[0144] Read the contract calling method name in the second virtual machine through the distribution function of the target contract;

[0145] Determine the contract call method, contract call parameter number, contract call parameter order, and contract call parameter type that match the contract call method name;

[0146] Reading, through the distribution function of the second contract, contract call parameters satisfying the number of contract call parameters from the second virtual machine;

[0147] Based on the contract call parameter order and contract call parameter type, parse the contract call parameters to obtain the parsed parameters.

[0148] For example, the first element of the input parameter extraction area can be read through the distribution function of the target contract to obtain the contract call method name, and then the actual contract call method to be called, as well as the number of parameters, parameter order, and parameter type required to call the method can be determined based on the contract call method name. Then, the subsequent elements are read from the input parameter extraction area as contract call parameters, where the number of contract call parameters is the number of parameters that have been obtained. Because the contract call parameters are ordered, the writing of parameters during heterogeneous call-in must also be ordered. The read contract call parameters can be converted one by one into actual parameter values ​​of the corresponding type according to the parameter order and parameter type, that is, the parsed parameters. Finally, the contract call method can be called through the parsed parameters to execute the target contract. The result returned by the actual call to the contract call method in the target contract must be serialized into a byte stream type and then returned by the distribution function. After the calling contract obtains the return result of the byte stream type, it is deserialized to obtain the required result.

[0149] Therefore, when calling the target contract, the calling contract only needs to specify the contract calling method name and contract calling parameters, without any other processing. The second virtual machine decides to turn on the heterogeneous calling switch according to the type of the calling contract, writes the contract calling method name and contract calling parameters into the input parameter extraction area, and then calls the target contract with the signature of the distribution function.

[0150] The existing technology generally inserts an intermediate transfer layer between multiple virtual machines to adapt and connect different types of virtual machines. When the contract caller calls the contract, the blockchain system learns the virtual machine type declared by the contract issuer and passes the contract caller's input and the contract code together to the specified type of virtual machine for interpretation and execution.

[0151] First, the existing technical solution inserts a universal interaction layer between various virtual machines, which will significantly increase the redundancy of blockchain code, and the more types of virtual machines are adapted, the more redundant code the API has. However, the technical solution of this application, by designing the input parameter extraction area and the distribution function, saves the caller the step of encoding the method and parameter calldata through the ABI interface. Not only does it not have the redundant code of the universal adaptation solution, but it also reduces the development and maintenance workload of the application party to a certain extent.

[0152] Secondly, in the existing technical solutions, the more types of virtual machines are supported, the more complicated the adaptation of the intermediate interaction layer is, and the corresponding interactive performance decreases and the risk of vulnerabilities increases. However, the technical solution of this application is only designed for the specific situation of heterogeneous calls to solidity contracts, with clear logic, reducing the probability of vulnerabilities in the development process and improving the security of the program.

[0153] Thirdly, different virtual machines have their own unique architectures and interactive interfaces. When the existing solutions are implemented in each specific category of virtual machines, whether the solutions can be applied remains to be demonstrated in practice. Therefore, the scope of the current solutions is too broad and its feasibility remains to be discussed. In particular, solidity contracts have unique ABI interfaces and calldata parameter mechanisms, and there is no corresponding solution in the existing technology comparison. The technical solution of this application only targets the situation where other types of contracts call solidity contracts, so that heterogeneous calls to solidity contracts have clear and feasible solutions, which are more targeted and certain to be implemented.

[0154] The technical solution of this application can enable other types of contracts to have the ability to call solidity contracts, solving the problem of heterogeneous calls to solidity contracts. It is not only beneficial to the interaction and collaboration of different types of contracts on the chain, but also provides blockchain application parties with the ability to collaboratively develop and integrate smart contracts. In addition, the contract caller saves the process of encoding calldata through the ABI interface, and can directly call the solidity contract through the contract call method name and contract call parameters without any special processing. The blockchain will automatically transfer and distribute the methods and parameters, which not only reduces the complexity of development, but also makes it more intuitive and friendly in use, thereby reducing the threshold for heterogeneous cross-contract calls to solidity, and generating a gain effect on the development of the blockchain application ecosystem.

[0155] As can be seen from the above, the present application can add a contract call bit area to the target contract, and the contract call bit area records the contract call identifier, the contract call method name, and the contract call parameters; based on the contract call identifier, determine the call status of the target contract in the current contract call; if the call status of the target contract is the call contract status, read the contract call bit area, and make the target contract use the read contract call parameters to use the contract call method corresponding to the contract call method name to call the contract to be called; if the call status of the target contract is the called contract status, read the contract call bit area, and make the calling contract use the read contract call parameters to use the contract call method corresponding to the contract call method name to call the target contract. The technical solution of the present application can be used to add a contract call bit area to the target contract, so as to understand the contract call identifier, contract call method name, and contract call parameters required for the contract call according to the contract call bit area, and then use the above information to realize the contract call between different types of contracts. Because in the prior art, an intermediate transfer layer is generally inserted between multiple virtual machines to adapt and dock different types of virtual machines. When the contract caller calls the contract, the blockchain system learns the type of virtual machine declared by the contract issuer, and passes the input of the contract caller and the contract code to the specified type of virtual machine for interpretation and execution. The existing technical solutions attempt to establish a universal heterogeneous interaction protocol in various virtual machines, but different virtual machines have their own unique architecture and interaction interface. When it comes to each specific type of virtual machine, whether the solution can be applied remains to be demonstrated in practice. Therefore, the scope of the existing technology is too broad and its feasibility remains to be discussed. The technical solution of the present application can avoid the insertion of the intermediate transfer layer, so that the method and parameters of the contract call can be directly obtained, which greatly simplifies the procedure of the contract call and improves the efficiency of the contract call. In addition, the application of the technical solution of the present application can also obtain the method name and parameters required for the call through the contract call bit area, thereby bypassing the ABI interface and the calldata parameter mechanism, so as to avoid some contracts that use the ABI interface and the calldata parameter mechanism, so that other virtual machines cannot recognize the method and parameters of the call, and thus it is difficult to achieve interconnection between different types of contracts.

[0156] According to the method described in the previous embodiment, the following will take the specific integration of the contract calling device in an electronic device as an example to further explain the technical solution of solidity contract calling other types of contracts. The embodiment of the present application provides a contract calling method, such as Figure 3 As shown, the specific process of the contract calling method can be as follows:

[0157] 301. The electronic device sets a contract call bit area for heterogeneous calls in the solidity contract.

[0158] For example, a state variable of byte stream array type can be set in the solidity contract as a parameter buffer for heterogeneous calls. The parameter buffer is the contract call bit area. Then, the information required for the heterogeneous call can be written into the contract call bit area:

[0159] 1. Write the contract call identifier in the first element of the contract call bit area to identify the current contract call as a heterogeneous call;

[0160] 2. Write the contract calling method name in the second element of the contract calling bit area to identify the called contract method;

[0161] 3. Divide the elements of the contract call bit area except the first and second elements into pairs, and arrange them in order. Each pair of elements identifies a contract call parameter of the called method. Among them, the first element in each pair of elements is used to identify the parameter type or parameter key, and the last element in each pair of elements is used to identify the parameter value. The first and last two elements identify a complete parameter;

[0162] Among them, whether the first element in each pair of elements is used to identify the parameter type or the parameter key depends on the language type of the contract to be called. If the language type of the contract to be called is a static language type, then the first element in each pair of elements is used to identify the parameter type; if the language type of the contract to be called is a dynamic language type and uses unordered parameters, then the first element in each pair of elements is used to identify the parameter key.

[0163] 4. After all parameters are written into the contract call bit area, a parameter end marker is appended to the end.

[0164] 302. The electronic device reads the contract call bit area and writes the read content into the first virtual machine.

[0165] For example, a heterogeneous call switch, a parameter counter, and a parameter recorder can be set in the first virtual machine. The heterogeneous call switch, parameter counter, and parameter recorder are all bound to the contract instance to ensure that each contract instance has an exclusive heterogeneous call switch, a parameter counter, and a parameter recorder, thereby avoiding data competition and data contamination problems when concurrent contracts are executed.

[0166] The heterogeneous call switch can be used to identify whether the storage has entered the parameter preparation process of the heterogeneous call.

[0167] Among them, the parameter counter is used to determine the element currently stored in the contract call bit area since the heterogeneous call switch is turned on, and then determine whether the currently stored element is the contract call method name, parameter type, parameter index, parameter value, or parameter end marker.

[0168] Among them, the parameter recorder is used to record the contract call method name and contract call parameters identified by the parameter counter. The record of the contract call parameters should retain the parameter type / parameter index, parameter value, and the order between them.

[0169] When the first virtual machine stores data through the sstore instruction, it first checks whether the heterogeneous call switch is turned on:

[0170] 1. If it is not turned on, the sstore instruction also needs to check whether the contract call identifier to be stored is a heterogeneous call tag;

[0171] If it is not a heterogeneous call mark, it means that the current storage is just ordinary storage, not heterogeneous call parameter preparation, then continue the operation according to the normal storage; if it is a heterogeneous call mark, turn on the heterogeneous call switch bound to the solidity contract in the first virtual machine, and initialize the parameter counter to indicate that the parameter preparation of the heterogeneous call has begun.

[0172] 2. If it is turned on, it means that the heterogeneous call mode has been turned on and is currently in the parameter preparation stage of the heterogeneous call. The parameter counter can be increased by 1, and the type of data to be stored can be determined based on the parameter counter, that is, whether the data to be stored is the contract call method name, parameter type / parameter index, parameter value, or parameter end mark, and then recorded in the parameter recorder by type. If the data to be stored is the parameter end mark, turn off the heterogeneous call switch to indicate that the next storage of the sstore instruction is normal storage to avoid accidental loss of normal storage data.

[0173] 303. The electronic device obtains the contract type and contract code of the contract to be called.

[0174] For example, when the first virtual machine executes a call instruction or a staticcall instruction, the contract type and the contract code of the contract to be called can be obtained according to the contract address of the contract to be called. Then, according to the contract type of the contract to be called, the second virtual machine corresponding to the contract to be called is queried and the second virtual machine instance is started.

[0175] 304. The electronic device reads and parses the contract calling method name and contract calling parameters in the first virtual machine.

[0176] For example, the contract call method name and contract call parameters in the first virtual machine parameter recorder can be read, and the contract call parameters can be parsed according to the contract type. If the language type of the contract is a dynamic language, the second virtual machine is called with the parameter index and parameter value to execute the contract call method; if the language type of the contract is a static language, the parameter value of the byte stream type is converted to the value of the corresponding parameter type, and then the second virtual machine is called with the converted parameter value to execute the contract call method. If the execution is successful, the execution result is returned; if the execution fails, an error message is returned.

[0177] 305. The electronic device executes an operation of calling the contract to be called through the second virtual machine.

[0178] For example, after the call instruction or staticcall instruction returns, the first virtual machine can clear the parameters previously prepared for the heterogeneous call and reset the parameter counter to the initial value. If the current contract has multiple heterogeneous contract calls, the parameter buffer can be reused.

[0179] As can be seen from the above, the present application can set a contract call bit area for heterogeneous calls in a solidity contract through an electronic device, read the contract call bit area, and write the read content into the first virtual machine, obtain the contract type and contract code of the contract to be called, read and parse the contract call method name and contract call parameters in the first virtual machine, and execute the operation of calling the contract to be called through the second virtual machine. The technical solution of the present application can be used to add a contract call bit area to the target contract, so that the contract call identifier, contract call method name, and contract call parameters required for the contract call can be understood according to the contract call bit area, and then the above information can be used to realize the contract call between different types of contracts. Because in the prior art, an intermediate transfer layer is generally inserted between multiple virtual machines to adapt and dock different types of virtual machines. When the contract caller calls the contract, the blockchain system learns the virtual machine type declared by the contract publisher, and passes the contract caller's input and the contract code together into the virtual machine of the specified type for interpretation and execution. The existing technical solutions attempt to establish a universal heterogeneous interaction protocol in various types of virtual machines, but different virtual machines have their own unique architectures and interaction interfaces. When implemented in each specific category of virtual machines, whether the solution can be applied remains to be demonstrated in practice. Therefore, the scope of the existing technology is too broad and its feasibility remains to be discussed. The use of the technical solution of the present application can avoid the insertion of the intermediate transfer layer, so that the method and parameters of the contract call can be directly obtained, which greatly simplifies the procedure of contract calls and improves the efficiency of contract calls. In addition, the application of the technical solution of the present application can also obtain the method name and parameters required for the call through the contract call bit area, thereby bypassing the ABI interface and the calldata parameter mechanism, so as to avoid some contracts that use the ABI interface and the calldata parameter mechanism, so that other virtual machines cannot recognize the call method and parameters, and thus it is difficult to achieve interconnection between different types of contracts.

[0180] According to the method described in the previous embodiment, the following will take the specific integration of the contract calling device in an electronic device as an example to further explain the technical solution of calling solidity contracts by other types of contracts. The present application embodiment provides a contract calling method, such as Figure 4 As shown, the specific process of the contract calling method can be as follows:

[0181] 401. The electronic device sets a contract call bit area for heterogeneous calls in the solidity contract.

[0182] For example, in the blockchain, you can set status information for users, which should include user type information, which can be used to distinguish whether the user is a normal account or a contract account. You can also set contract status information for contract accounts, which includes contract name, contract address, contract type, etc. The contract type can be used to distinguish which language the contract is written in or which virtual machine it is executed by.

[0183] In addition, a contract call bit area for heterogeneous calls can be set in the solidity contract. The contract call bit area is a state variable of a read-only byte stream array type. The state variable is the first state variable of the solidity contract and is of read-only type. The state variable can also be called the input parameter extraction area. Among them, the first element in the contract call bit area can be regarded as the contract call method name when heterogeneously calling the solidity contract. The actual contract call method can be matched according to the contract call method name. The subsequent elements in the contract call bit area can be regarded as the contract call parameters actually required to call the contract call method. The size of the contract call bit area can be set to the number of parameters of the method with the largest number of parameters in the solidity contract plus 1, and the extra 1 is used to store the contract call method name.

[0184] 402. The electronic device obtains the contract calling method name and contract calling parameters of the calling contract through the first virtual machine.

[0185] 403. The electronic device writes the contract calling method name and the contract calling parameters into the second virtual machine.

[0186] For example, a heterogeneous call switch can be set in the second virtual machine corresponding to the solidity contract, where a heterogeneous call switch is bound to a contract instance to avoid data competition and data contamination during concurrent contract execution. The heterogeneous call switch will be turned off after the contract call parameters are written. Before the second virtual machine is called to execute the solidity contract, the second virtual machine will first obtain the type of the contract caller to determine whether the contract caller is a contract or a user. If the contract caller is a contract, then whether the contract is a different type of contract from the solidity contract, and then determine whether the current contract call is a heterogeneous call.

[0187] 1. If the contract caller is not a contract, it will be regarded as a normal user call without cross-contract call, and the contract call operation will be executed directly according to the original process;

[0188] 2. If the contract caller is not a contract, get the contract type of the calling contract:

[0189] If the called contract is a solidity contract, it is considered as a homogeneous cross-contract call, and the contract call operation is performed according to the original process;

[0190] If the calling contract is not a solidity contract, turn on the heterogeneous call switch to instruct the subsequent process to execute according to the heterogeneous call.

[0191] In addition, an input parameter extraction area can be set in the second virtual machine. This is the specific implementation of the contract input parameter extraction area at the virtual machine layer. The data read from the contract input parameter extraction area is actually stored here. One input parameter extraction area is bound to one contract instance to ensure that each input parameter extraction area is exclusively occupied by one contract instance, avoiding data competition and pollution when concurrent contracts are executed.

[0192] Since the input parameter extraction area must be declared at the position of the first state variable of the contract, the writing of the contract call method name and the contract call parameters must start from slot 0 in the second virtual machine until the input parameter end mark is written. Therefore, after the heterogeneous call switch is turned on, the second virtual machine will write the contract call method name and the contract call parameters into the input parameter extraction area in sequence, and the position of the input parameter extraction area can be confirmed through the slot of the second virtual machine.

[0193] 1. The contract call identifier can be written into the first element position in the input parameter extraction area, and the contract call method name can be converted into a byte stream and written into the second element position in the input parameter extraction area;

[0194] 2. The contract call parameters can also be converted into byte streams and written one by one in sequence to the subsequent positions of the input parameter extraction area. Since the parameters of the solidity function are ordered, the contract call parameters must be written in sequence;

[0195] 3. After all the contract call parameters are written, the parameter end marker can be appended to the end of the parameters.

[0196] 404. The electronic device reads and parses the contract calling method name and contract calling parameters in the second virtual machine through the distribution function of the solidity contract.

[0197] In one embodiment, a distribution function can be set in the solidity contract as the entry point of the contract. The distribution function has no parameters and returns a byte stream type return value. The function name, parameters and return value of the distribution function are unified and fixed, so the function signature is also unified and fixed. When other types of functions call the solidity contract, they can directly pass in the signature call of the distribution function.

[0198] For example, after writing the contract call method name and contract call parameters into the second virtual machine, a contract instance can be generated through the second virtual machine, and the contract execution can be called with the signature of the distribution function. The distribution function will read the contract call method name and contract call parameters from the input parameter extraction area and match them for execution. Then, when reading elements from the input parameter extraction area, the sload instruction of the second virtual machine will be triggered. When the sload instruction is executed, it will first check whether the heterogeneous call switch is turned on:

[0199] 1. If the heterogeneous call switch is not turned on, data is read from the storage according to the original logic;

[0200] 2. If the heterogeneous call switch is turned on, read data from the input parameter extraction area;

[0201] If the data read is ordinary data, the instruction returns the data, and the contract code logic distinguishes whether the data read is the contract call method name or the contract call parameter according to the read position;

[0202] If the data read is the end mark of parameter input, the parameter reading is considered complete, and the heterogeneous call switch can be turned off to indicate that data is read from the storage later.

[0203] Among them, the specific method of reading data from the input parameter extraction area can be as follows:

[0204] 1. First, read the first element of the input parameter extraction area, which is regarded as the name of the contract call method actually called;

[0205] 2. Determine the actual contract calling method to be called according to the contract calling method name, as well as the number of parameters, parameter order, and parameter type required to call the method;

[0206] 3. Read subsequent elements from the input parameter extraction area. The number of elements read is the number of parameters determined in the previous step.

[0207] 4. Convert the elements read subsequently into actual parameter values ​​of corresponding types one by one according to the order and type of the parameters, that is, the parsed parameters. Because the parameters of Solidity are ordered, the writing of parameters during heterogeneous call-in must also be ordered.

[0208] 5. After the conversion is completed, call this method with the converted actual parameter value to execute the contract.

[0209] 405. The electronic device executes an operation of calling the solidity contract through the second virtual machine.

[0210] For example, the result returned by the actual call of the contract call method in the solidity contract must be serialized into a byte stream type and then returned by the distribution function. After the calling contract gets the return result of the byte stream type, it deserializes it to get the required result.

[0211] Therefore, when calling a solidity contract, the calling contract only needs to specify the contract calling method name and contract calling parameters, without any other processing. The second virtual machine decides to turn on the heterogeneous calling switch according to the type of the calling contract, writes the contract calling method name and contract calling parameters into the input parameter extraction area, and then calls the solidity contract execution with the signature of the distribution function.

[0212] As can be seen from the above, the present application can set a contract call bit area for heterogeneous calls in the solidity contract, obtain the contract call method name and contract call parameters of the calling contract through the first virtual machine, write the contract call method name and contract call parameters into the second virtual machine, read and parse the contract call method name and contract call parameters in the second virtual machine through the distribution function of the solidity contract, and execute the operation of calling the solidity contract through the second virtual machine. The technical solution of the present application can be used to add a contract call bit area to the target contract, so as to understand the contract call identifier, contract call method name, and contract call parameters required for the contract call according to the contract call bit area, and then use the above information to realize the contract call between different types of contracts. Because in the prior art, an intermediate transfer layer is generally inserted between multiple virtual machines to adapt and dock different types of virtual machines. When the contract caller calls the contract, the blockchain system learns the type of virtual machine declared by the contract publisher, and passes the input of the contract caller and the contract code together into the virtual machine of the specified type for interpretation and execution. The existing technical solutions attempt to establish a universal heterogeneous interaction protocol in various types of virtual machines, but different virtual machines have their own unique architectures and interaction interfaces. When implemented in each specific category of virtual machines, whether the solution can be applied remains to be demonstrated in practice. Therefore, the scope of the existing technology is too broad and its feasibility remains to be discussed. The use of the technical solution of the present application can avoid the insertion of the intermediate transfer layer, so that the method and parameters of the contract call can be directly obtained, which greatly simplifies the procedure of contract calls and improves the efficiency of contract calls. In addition, the application of the technical solution of the present application can also obtain the method name and parameters required for the call through the contract call bit area, thereby bypassing the ABI interface and the calldata parameter mechanism, so as to avoid some contracts that use the ABI interface and the calldata parameter mechanism, so that other virtual machines cannot recognize the call method and parameters, and thus it is difficult to achieve interconnection between different types of contracts.

[0213] In order to better implement the above method, the present application embodiment also provides a contract calling device, such as Fig. 9 As shown, the contract calling device may include a region adding unit 901, a state determining unit 902, a first executing unit 903, and a second executing unit 904, as follows:

[0214] The area adding unit 901 is used to add a contract call bit area in the target contract, wherein the contract call bit area records the contract call identifier, the contract call method name, and the contract call parameters;

[0215] A state determination unit 902, configured to determine the call state of the target contract in the current contract call based on the contract call identifier;

[0216] The first execution unit 903 is used to read the contract call bit area if the call state of the target contract is the call contract state, and enable the target contract to call the to-be-called contract by using the read contract call parameters and the contract call method corresponding to the contract call method name;

[0217] The second execution unit 904 is used to read the contract calling bit area if the calling state of the target contract is the called contract state, and enable the calling contract to use the read contract calling parameters and the contract calling method corresponding to the contract calling method name to call the target contract.

[0218] Optionally, in some embodiments of the present application, the first execution unit 903 may include a first execution subunit, a first reading subunit, and a first calling subunit, as follows:

[0219] A first execution subunit, configured to execute the target contract through a first virtual machine if the calling state of the target contract is a calling contract state;

[0220] A first reading subunit is used to read the contract call bit area if it is determined that the current contract call is a heterogeneous call;

[0221] The first calling subunit is used to call the contract to be called through the second virtual machine corresponding to the contract to be called based on the read contract calling method name and the contract calling parameters.

[0222] Optionally, in some embodiments of the present application, the first calling subunit may include a first writing subunit, a first parsing subunit and a second calling subunit, as follows:

[0223] A first writing subunit, used for writing the read contract calling method name and the contract calling parameters into the first virtual machine;

[0224] A first parsing subunit, used to read and parse the contract calling method name and the contract calling parameters from the first virtual machine to obtain the contract calling method and the parsed parameters;

[0225] The second calling subunit is used to call the contract to be called through a second virtual machine corresponding to the contract to be called based on the contract calling method and the parsed parameters.

[0226] Optionally, in some embodiments of the present application, the second calling sub-unit can be specifically used to obtain the contract address of the contract to be called, and based on the contract address, determine the contract type of the contract to be called; determine a second virtual machine corresponding to the contract type; based on the contract calling method name and the contract calling parameters, call the contract to be called through the second virtual machine.

[0227] Optionally, in some embodiments of the present application, the first parsing sub-unit can be specifically used to read the contract calling method name and the contract calling parameters from the first virtual machine; determine the contract calling method based on the contract calling method name; parse the contract calling parameters based on the contract type to obtain the parsed parameters.

[0228] Optionally, in some embodiments of the present application, the second execution unit 904 may include a second execution subunit and a third execution subunit, as follows:

[0229] A second execution subunit is used for executing the calling contract through the first virtual machine if the calling state of the target contract is the called contract state, and the calling contract carries the contract calling method name and contract calling parameters;

[0230] The third execution sub-unit is used to determine that the current contract call is a heterogeneous call based on the contract type of the calling contract, and to perform the operation of calling the target contract through the calling contract based on the contract calling method name and the contract calling parameters.

[0231] Optionally, in some embodiments of the present application, the third execution subunit may include a second writing subunit and a second reading subunit, as follows:

[0232] A second writing subunit is used to write the contract calling method name and the contract calling parameters into a second virtual machine corresponding to the target contract;

[0233] The second reading subunit is used to read the contract calling method name and the contract calling parameters in the second virtual machine through the distribution function of the target contract, and call the target contract.

[0234] Optionally, in some embodiments of the present application, the second reading subunit may include a second parsing subunit and a third calling subunit, as follows:

[0235] A second parsing subunit is used to read and parse the contract calling method name and the contract calling parameters in the second virtual machine through the distribution function of the target contract to obtain the contract calling method and the parsed parameters;

[0236] The third calling subunit is used to call the target contract based on the parsed parameters and the contract calling method.

[0237] Optionally, in some embodiments of the present application, the second parsing sub-unit can be specifically used to read the contract call method name in the second virtual machine through the distribution function of the target contract; determine the contract call method, the number of contract call parameters, the order of contract call parameters, and the type of contract call parameters that match the contract call method name; read the contract call parameters that meet the number of contract call parameters from the second virtual machine through the distribution function of the second contract; parse the contract call parameters based on the contract call parameter order and the contract call parameter type to obtain the parsed parameters.

[0238] As can be seen from the above, in this embodiment, a contract call bit area can be added to the target contract through the area adding unit 901, and the contract call bit area records the contract call identifier, the contract call method name, and the contract call parameters; based on the contract call identifier, the state determination unit 902 determines the call state of the target contract in the current contract call; if the call state of the target contract is the call contract state, the contract call bit area is read through the first execution unit 903, and the target contract uses the read contract call parameters to call the contract to be called using the contract call method corresponding to the contract call method name; if the call state of the target contract is the called contract state, the contract call bit area is read through the second execution unit 904, and the calling contract uses the read contract call parameters to call the target contract using the contract call method corresponding to the contract call method name. By using the technical solution of this application, the contract call bit area can be added to the target contract, so that the contract call identifier, contract call method name, and contract call parameters required for the contract call can be understood according to the contract call bit area, and then the above information can be used to realize the contract call between different types of contracts. Because in the prior art, an intermediate transfer layer is generally inserted between multiple virtual machines to adapt and connect different types of virtual machines. When the contract caller calls the contract, the blockchain system learns the type of virtual machine declared by the contract publisher, and passes the input of the contract caller and the contract code to the specified type of virtual machine for interpretation and execution. The prior art scheme attempts to establish a universal heterogeneous interaction protocol in various virtual machines, but different virtual machines have their own unique architecture and interaction interface. When it is implemented in each specific category of virtual machine, whether the scheme can be applied remains to be demonstrated in practice. Therefore, the scope of the prior art is too broad and its feasibility remains to be discussed. The technical scheme of the present application can avoid the insertion of the intermediate transfer layer, so that the method and parameters of the contract call can be directly obtained, which greatly simplifies the procedure of the contract call and improves the efficiency of the contract call. In addition, the application of the technical scheme of the present application can also obtain the method name and parameters required for the call through the contract call bit area, thereby bypassing the ABI interface and the calldata parameter mechanism, so as to avoid some contracts due to the use of the ABI interface and the calldata parameter mechanism, so that other virtual machines cannot recognize the method and parameters of the call, and thus it is difficult to achieve interconnection between different types of contracts.

[0239] The present application also provides an electronic device, such as Fig.10 As shown, it shows a schematic diagram of the structure of an electronic device involved in an embodiment of the present application, and the electronic device may be a terminal or a server, etc. Specifically:

[0240] The electronic device may include components such as a processor 1001 with one or more processing cores, a memory 1002 with one or more computer-readable storage media, a power supply 1003, and an input unit 1004. Those skilled in the art will appreciate that Fig.10 The electronic device structure shown in the figure does not constitute a limitation on the electronic device, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0241] The processor 1001 is the control center of the electronic device, and uses various interfaces and lines to connect various parts of the entire electronic device. By running or executing software programs and / or modules stored in the memory 1002, and calling data stored in the memory 1002, the processor 1001 performs various functions of the electronic device and processes data. Optionally, the processor 1001 may include one or more processing cores; preferably, the processor 1001 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the modem processor mainly processes wireless communications. It is understandable that the above-mentioned modem processor may not be integrated into the processor 1001.

[0242] The memory 1002 can be used to store software programs and modules. The processor 1001 executes various functional applications and data processing by running the software programs and modules stored in the memory 1002. The memory 1002 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 1002 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices. Accordingly, the memory 1002 may also include a memory controller to provide the processor 1001 with access to the memory 1002.

[0243] The electronic device also includes a power supply 1003 for supplying power to each component. Preferably, the power supply 1003 can be logically connected to the processor 1001 through a power management system, so as to manage charging, discharging, and power consumption through the power management system. The power supply 1003 can also include one or more DC or AC power supplies, recharging systems, power failure detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0244] The electronic device may further include an input unit 1004, which may be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal input related to user settings and function control.

[0245] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically in this embodiment, the processor 1001 in the electronic device will load the executable file corresponding to the process of one or more application programs into the memory 1002 according to the following instructions, and the processor 1001 will run the application program stored in the memory 1002, thereby realizing various functions, as follows:

[0246] A contract call bit area is added to the target contract, and the contract call bit area records the contract call identifier, the contract call method name, and the contract call parameters; based on the contract call identifier, the call status of the target contract in the current contract call is determined; if the call status of the target contract is the calling contract status, the contract call bit area is read, and the target contract uses the read contract call parameters and the contract call method corresponding to the contract call method name to call the to-be-called contract; if the call status of the target contract is the called contract status, the contract call bit area is read, and the calling contract uses the read contract call parameters and the contract call method corresponding to the contract call method name to call the target contract.

[0247] The specific implementation of the above operations can be found in the previous embodiments, which will not be described in detail here.

[0248] As can be seen from the above, this embodiment can add a contract call bit area in the target contract, and the contract call bit area records the contract call identifier, the contract call method name, and the contract call parameters; based on the contract call identifier, determine the call status of the target contract in the current contract call; if the call status of the target contract is the call contract status, read the contract call bit area, and make the target contract use the read contract call parameters to use the contract call method corresponding to the contract call method name to call the to-be-called contract; if the call status of the target contract is the called contract status, read the contract call bit area, and make the calling contract use the read contract call parameters to use the contract call method corresponding to the contract call method name to call the target contract. The technical solution of this application can be used to add a contract call bit area to the target contract, so that the contract call identifier, contract call method name, and contract call parameters required for the contract call can be understood according to the contract call bit area, and then the above information can be used to realize the contract call between different types of contracts. Because in the prior art, an intermediate transfer layer is generally inserted between multiple virtual machines to adapt and dock different types of virtual machines. When the contract caller calls the contract, the blockchain system learns the type of virtual machine declared by the contract issuer, and passes the input of the contract caller and the contract code to the specified type of virtual machine for interpretation and execution. The existing technical solutions attempt to establish a universal heterogeneous interaction protocol in various virtual machines, but different virtual machines have their own unique architecture and interaction interface. When it comes to each specific type of virtual machine, whether the solution can be applied remains to be demonstrated in practice. Therefore, the scope of the existing technology is too broad and its feasibility remains to be discussed. The technical solution of the present application can avoid the insertion of the intermediate transfer layer, so that the method and parameters of the contract call can be directly obtained, which greatly simplifies the procedure of the contract call and improves the efficiency of the contract call. In addition, the application of the technical solution of the present application can also obtain the method name and parameters required for the call through the contract call bit area, thereby bypassing the ABI interface and the calldata parameter mechanism, so as to avoid some contracts that use the ABI interface and the calldata parameter mechanism, so that other virtual machines cannot recognize the method and parameters of the call, and thus it is difficult to achieve interconnection between different types of contracts.

[0249] A person of ordinary skill in the art will appreciate that all or part of the steps in the various methods of the above embodiments may be completed by instructions, or by controlling related hardware through instructions. The instructions may be stored in a computer-readable storage medium and loaded and executed by a processor.

[0250] To this end, an embodiment of the present application provides a computer-readable storage medium, which stores multiple instructions, which can be loaded by a processor to execute the steps in any of the contract calling methods provided in the embodiments of the present application. For example, the instructions can execute the following steps:

[0251] A contract call bit area is added to the target contract, and the contract call bit area records the contract call identifier, the contract call method name, and the contract call parameters; based on the contract call identifier, the call status of the target contract in the current contract call is determined; if the call status of the target contract is the calling contract status, the contract call bit area is read, and the target contract uses the read contract call parameters and the contract call method corresponding to the contract call method name to call the to-be-called contract; if the call status of the target contract is the called contract status, the contract call bit area is read, and the calling contract uses the read contract call parameters and the contract call method corresponding to the contract call method name to call the target contract.

[0252] The specific implementation of the above operations can be found in the previous embodiments, which will not be described in detail here.

[0253] The computer-readable storage medium may include: a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0254] Since the instructions stored in the computer-readable storage medium can execute the steps in any contract calling method provided in the embodiments of the present application, the beneficial effects that can be achieved by any contract calling method provided in the embodiments of the present application can be achieved. Please refer to the previous embodiments for details and will not be repeated here.

[0255] According to one aspect of the present application, a computer program product or a computer program is provided, the computer program product or the computer program comprising computer instructions, the computer instructions being stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the methods provided in various optional implementations of the above-mentioned contract call aspect.

[0256] The above is a detailed introduction to a contract calling method and related equipment provided in an embodiment of the present application. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for technical personnel in this field, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A contract calling method, characterized in that: include: Add a contract call bit area in the target contract, wherein the contract call bit area records the contract call identifier, the contract call method name, and the contract call parameters; Based on the contract call identifier, determine the call status of the target contract in the current contract call; If the calling state of the target contract is the calling contract state, read the contract calling bit area, and make the target contract use the read contract calling parameters and the contract calling method corresponding to the contract calling method name to call the contract to be called; If the calling state of the target contract is the called contract state, read the contract calling bit area, and make the calling contract use the read contract calling parameters and the contract calling method corresponding to the contract calling method name to call the target contract.

2. The contract calling method according to claim 1, characterized in that: If the calling state of the target contract is the calling contract state, the contract calling bit area is read, and the target contract uses the read contract calling parameters to call the contract to be called using the contract calling method corresponding to the contract calling method name, including: If the calling state of the target contract is the calling contract state, executing the target contract through the first virtual machine; If it is determined that the current contract call is a heterogeneous call, read the contract call bit area; Based on the read contract calling method name and the contract calling parameters, the contract to be called is called through a second virtual machine corresponding to the contract to be called.

3. The contract calling method according to claim 2, characterized in that: The calling the contract to be called through a second virtual machine corresponding to the contract to be called based on the read contract calling method name and the contract calling parameter includes: Writing the read contract call method name and the contract call parameters into the first virtual machine; Read and parse the contract calling method name and the contract calling parameters from the first virtual machine to obtain the contract calling method and the parsed parameters; Based on the contract calling method and the parsed parameters, the contract to be called is called through a second virtual machine corresponding to the contract to be called.

4. The contract calling method according to claim 3, characterized in that: The calling the contract to be called through a second virtual machine corresponding to the contract to be called based on the contract calling method name and the contract calling parameters includes: Obtain the contract address of the contract to be called, and determine the contract type of the contract to be called based on the contract address; Determining a second virtual machine corresponding to the contract type; Based on the contract calling method name and the contract calling parameters, the contract to be called is called through the second virtual machine.

5. The contract calling method according to claim 4, characterized in that: The reading and parsing the contract calling method name and the contract calling parameters from the first virtual machine to obtain the contract calling method and the parsed parameters includes: Reading the contract calling method name and the contract calling parameters from the first virtual machine; Determine the contract calling method based on the contract calling method name; The contract call parameters are parsed based on the contract type to obtain parsed parameters.

6. The contract calling method according to claim 1, characterized in that: If the calling state of the target contract is the called contract state, reading the contract calling bit area, and making the calling contract use the read contract calling parameters to call the target contract using the contract calling method corresponding to the contract calling method name, including: If the calling state of the target contract is the called contract state, the calling contract is executed by the first virtual machine, and the calling contract carries the contract calling method name and contract calling parameters; If the current contract call is determined to be a heterogeneous call based on the contract type of the calling contract, the operation of calling the target contract is executed through the calling contract based on the contract calling method name and the contract calling parameters.

7. The contract calling method according to claim 6, characterized in that: The operation of calling the target contract through the calling contract execution based on the contract calling method name and the contract calling parameters includes: Writing the contract calling method name and the contract calling parameters into a second virtual machine corresponding to the target contract; Through the distribution function of the target contract, the contract calling method name and the contract calling parameters in the second virtual machine are read, and the target contract is called.

8. The contract calling method according to claim 7, characterized in that: The method of reading the contract calling method name and the contract calling parameters in the second virtual machine through the distribution function of the target contract and calling the target contract includes: Read and parse the contract calling method name and the contract calling parameters in the second virtual machine through the distribution function of the target contract to obtain the contract calling method and the parsed parameters; Based on the parsed parameters and the contract calling method, the target contract is called.

9. The contract calling method according to claim 8, characterized in that: The method of reading and parsing the contract calling method name and the contract calling parameters in the second virtual machine through the distribution function of the target contract to obtain the contract calling method and the parsed parameters includes: Read the contract calling method name in the second virtual machine through the distribution function of the target contract; Determine a contract call method, a contract call parameter number, a contract call parameter order, and a contract call parameter type that matches the contract call method name; Reading, through the distribution function of the second contract, the contract call parameters satisfying the number of the contract call parameters from the second virtual machine; Based on the contract call parameter order and the contract call parameter type, the contract call parameters are parsed to obtain parsed parameters.

10. A contract calling device, characterized in that: include: An area adding unit, used for adding a contract call bit area in the target contract, wherein the contract call bit area records a contract call identifier, a contract call method name, and a contract call parameter; A state determination unit, configured to determine the call state of the target contract in the current contract call based on the contract call identifier; The first execution unit is used for reading the contract calling bit area if the calling state of the target contract is the calling contract state, and making the target contract use the read contract calling parameters and the contract calling method corresponding to the contract calling method name to call the contract to be called; The second execution unit is used to read the contract calling bit area if the calling state of the target contract is the called contract state, and enable the calling contract to use the read contract calling parameters and the contract calling method corresponding to the contract calling method name to call the target contract.

11. An electronic device, characterized in that: It includes a memory and a processor; the memory stores an application program, and the processor is used to run the application program in the memory to execute the operations in the contract calling method described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a plurality of instructions, which are suitable for loading by a processor to execute the steps in the contract calling method described in any one of claims 1 to 9.

13. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instruction is executed by a processor, the steps in the contract calling method described in any one of claims 1 to 9 are implemented.

Images