Contract calling method, device, electronic device and storage medium

Abstract

The embodiments of the present application disclose a contract calling method, device, electronic device and storage medium, the method comprising: obtaining a first address of a first enhanced contract; performing instruction enhancement on a second contract according to the first address to obtain a second enhanced contract, the second contract including the first address; sending the second enhanced contract to a second device so that the second device deploys the second enhanced contract on a blockchain and obtains a second address of the second enhanced contract; sending a call request to the second device according to the second address so that the second device calls the second enhanced contract according to the second address. Using the address of the called first contract, the second contract containing the logic of calling the first contract is enhanced by instruction enhancement, and calling the second enhanced contract based on the second address can realize cross-contract calls between enhanced contracts.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a contract invocation method, device, electronic device and storage medium. Background Art

[0002] Blockchain is a new type of decentralized protocol that can securely store digital currency transactions or other data. The information cannot be forged or tampered with. Transaction confirmation on the blockchain is completed by all nodes on the blockchain, and its consistency is guaranteed by the consensus algorithm. A public ledger is maintained on the blockchain. The public ledger is visible to any node on the storage block, thereby ensuring that it cannot be forged or tampered with.

[0003] Smart contracts are assembly languages ​​programmed on the blockchain. Smart contracts are contracts that can be automatically executed on a computer system when certain conditions are met. Smart contracts written in traditional programming languages ​​lack instructions for operating persistent fields. The enhanced smart contracts can read and write persistent fields on the blockchain ledger through instructions. However, many smart contracts written in traditional programming languages ​​currently have cross-contract call logic, and it is currently impossible to enhance and call instructions for such smart contracts. Summary of the invention

[0004] The embodiments of the present application provide a contract calling method, device, electronic device and storage medium, which can enhance and call instructions on smart contracts that contain cross-contract calling logic.

[0005] An embodiment of the present application provides a contract calling method, which is applied to a first device, and the method includes: obtaining a first address of a first enhanced contract, the first address being the address obtained after the first enhanced contract is deployed on a blockchain; performing instruction enhancement on a second contract according to the first address to obtain a second enhanced contract, the second contract including the first address; sending the second enhanced contract to a second device, so that the second device deploys the second enhanced contract on the blockchain and obtains a second address of the second enhanced contract; and sending a calling request to the second device according to the second address, so that the second device calls the second enhanced contract according to the second address.

[0006] An embodiment of the present application provides a contract calling method, which is applied to a second device, where the second device is a node device in a blockchain. The method includes: receiving a calling request sent by a first device, where the calling request includes a second address; obtaining a bytecode file of a second enhanced contract according to the second address, where the second enhanced contract includes a first address; creating target persistent field information of the second enhanced contract according to the bytecode file and the first address of the second enhanced contract; and executing the second enhanced contract based on the target persistent field information.

[0007] An embodiment of the present application also provides a contract calling device, which is applied to a first device, and the device includes: an acquisition module, used to obtain a first address of a first enhanced contract, the first address is the address obtained after the first enhanced contract is deployed on the blockchain; an enhancement module, used to perform instruction enhancement on a second contract according to the first address to obtain a second enhanced contract, the second contract includes the first address; a deployment module, used to send the second enhanced contract to a second device, so that the second device deploys the second enhanced contract on the blockchain and obtains the second address of the second enhanced contract; a calling module, used to send a calling request to the second device according to the second address, so that the second device calls the second enhanced contract according to the second address.

[0008] An embodiment of the present application also provides a contract calling device, which is applied to a second device, and the second device is a node device in the blockchain. The device includes: a receiving module, which is used to receive a calling request sent by a first device, and the calling request includes a second address; a file acquisition module, which is used to obtain a bytecode file of a second enhanced contract according to the second address, and the second enhanced contract includes a first address; a creation module, which is used to create target persistent field information of the second enhanced contract according to the bytecode file and the first address of the second enhanced contract; and an execution module, which is used to execute the second enhanced contract based on the target persistent field information.

[0009] An embodiment of the present application also provides an electronic device, including a memory storing multiple instructions; the processor loads instructions from the memory to execute the steps in any contract calling method provided in the embodiment of the present application.

[0010] An embodiment of the present application also provides a computer-readable storage medium, which stores multiple instructions, and the instructions are suitable for a processor to load to execute the steps in any contract calling method provided in the embodiment of the present application.

[0011] In the embodiment of the present application, the address of the called first enhanced contract can be used to perform instruction enhancement on the second contract containing the logic of calling the first contract. The call to the second enhanced contract based on the second address can realize cross-contract call between enhanced contracts. When performing instruction enhancement on the second contract, dependency check and security check on the second contract are introduced to further ensure the correctness of the second contract and avoid errors when calling the second enhanced contract. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] 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.

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

[0014] Figure 2 It is a flowchart of the contract calling method provided in the embodiment of the present application;

[0015] Figure 3 It is a flowchart of a contract calling method provided by another embodiment of the present application;

[0016] Figure 4 is a schematic diagram of target persistent field information provided by an embodiment of the present application;

[0017] Figure 5 is a schematic diagram of target persistent field information provided by another embodiment of the present application;

[0018] Figure 6 is a schematic diagram of target persistent field information provided by yet another embodiment of the present application;

[0019] Figure 7 is a schematic diagram of target persistent field information provided by another embodiment of the present application;

[0020] Figure 8 It is a structural diagram of a contract calling device provided in an embodiment of the present application;

[0021] Fig. 9 is a structural diagram of a contract calling device provided by another embodiment of the present application;

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

[0023] 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.

[0024] Embodiments of the present application provide a contract calling method, device, electronic device, and storage medium.

[0025] The contract calling device can be integrated into an electronic device, which can be a terminal, a server, or other devices. The terminal can be a mobile phone, a tablet computer, a smart Bluetooth device, a laptop, or a personal computer (PC), etc. The server can be a single server or a server cluster composed of multiple servers.

[0026] In some embodiments, the contract calling device can also be integrated into multiple electronic devices. For example, the contract calling device can be integrated into multiple servers, and the contract calling method of the present application can be implemented by multiple servers.

[0027] In some embodiments, the server may also be implemented in the form of a terminal.

[0028] Please refer to Figure 1 , shows a scenario diagram of the contract calling method. Among them, the first device 101 is an off-chain device, and the second device 102 is a node device in the blockchain. The user can write a second contract containing the calling logic of calling the first enhanced contract on the first device 101, and perform instruction enhancement on the second contract to obtain the second enhanced contract.

[0029] The first device 101 can send the second enhanced contract to the second device 102 in the form of a transaction so as to be deployed on the blockchain and obtain the second address of the second enhanced contract.

[0030] The first device 101 may send a call request carrying the second address to the second device 102 so that the second device 102 calls the second enhanced contract according to the second address.

[0031] As an implementation method, the first device 101 and the second device 102 can be integrated into one electronic device, the function of the first device 101 can be used as an off-chain processing module, and the function of the second device can be used as an on-chain processing module. That is, the terminal device can both enhance the second contract with instructions and call the second enhanced contract according to the second address.

[0032] In some embodiments, the second enhanced contract may be first locally enhanced by an off-chain processing module, and then the second enhanced contract may be uploaded to the blockchain by the off-chain processing module so as to be deployed on the blockchain to obtain a second address and implement the call to the second enhanced contract.

[0033] In some embodiments, a second contract is written through an off-chain processing module, and the second contract is enhanced by instructions through an on-chain processing module to obtain a second enhanced contract, and then the second enhanced contract is deployed on the blockchain to obtain a second address, and the second enhanced contract is called.

[0034] In the embodiment of the present application, the first device 101 and the second device 102 are taken as two different devices for description.

[0035] In this embodiment, a contract calling method is provided, such as Figure 2 As shown, the specific process of the contract calling method can be as follows:

[0036] S110. Obtain a first address of a first enhanced contract, where the first address is an address obtained after the first enhanced contract is deployed on the blockchain.

[0037] The first enhanced contract refers to a smart contract that has been deployed on the blockchain system, and the first address is the contract address obtained after the first enhanced contract is deployed on the blockchain, wherein the first enhanced contract is obtained after the instruction enhancement of the first contract.

[0038] Specifically, the first contract can be a jar package of a Java smart contract written by a contract developer using a contract development framework package. After the first contract is enhanced with instructions, the corresponding first enhanced contract can be obtained. The first enhanced contract can be sent to the second device in the form of a transaction to deploy the contract. The second device can complete the deployment of the first enhanced contract through the Java smart contract execution engine and generate a unique contract address for the first enhanced contract, which is the first address. The second device returns the first address to the first device, so that the first device can obtain the first address.

[0039] S120. Perform instruction enhancement on the second contract according to the first address to obtain a second enhanced contract, wherein the second contract includes the first address.

[0040] The second contract contains the first address, and the first enhanced contract can be called based on the first address. Specifically, the second contract can be a Java smart contract that contains the call logic for calling the first enhanced contract written by the contract developer using the contract development framework package, and the first address of the first enhanced contract is passed into the cross-contract call interface to obtain the instance corresponding to the first enhanced contract. The jar package of the second contract is packaged and generated, and the jar package is the second contract.

[0041] It can be understood that in a Java smart contract, multiple contracts can be called across contracts. For example, there are deployed contracts 1 and 2. The second contract can also include calling logic for calling contracts 1 and 2. The specific settings can be made according to actual needs and are not specifically limited here.

[0042] When the second contract is enhanced by instructions based on the first address to obtain the second enhanced contract, the following steps may be included:

[0043] S121. Decompress the second contract into a preset file, where the preset file includes a bytecode file and metadata, and the bytecode file includes the bytecode file in the first contract obtained based on the first address.

[0044] Among them, the essence of the second contract is a jar package. The second contract can be decompressed to obtain a bytecode file and metadata, and the decompressed bytecode file and metadata are stored in a preset file for subsequent use.

[0045] Since the second contract includes the first address, the bytecode file obtained by decompressing the second contract may also include the bytecode file in the first contract obtained according to the first address.

[0046] In some implementations, if the second contract calls the first enhanced contract through the interface of the first contract, the second contract includes the code of the interface of the first contract, and the contract instance corresponding to the first contract can be obtained by using the interface of the first contract and the first address, and the interface method provided by the interface of the first contract can be called to call the first enhanced contract. Thus, the second contract includes the bytecode files of all classes in the second contract and the bytecode files of the interface of the first contract.

[0047] In some embodiments, if the second contract calls the first enhanced contract through the contract class of the first contract, the second contract includes the code of the contract class of the first contract, uses the contract class of the first contract and the first address to obtain the contract instance corresponding to the contract class of the first contract, calls the method in the contract class of the first contract or operates the public field in the contract instance corresponding to the contract class to call the first enhanced contract. Thus, the second contract includes the bytecode files of all classes in the second contract and the bytecode files of the contract class of the first contract.

[0048] In some embodiments, if the second contract calls the first enhanced contract by referencing the first contract, the second contract can obtain the contract class of the first contract through the first contract, use the contract class of the first contract and the first address to obtain the contract instance of the contract class of the first contract, and call the public field of the contract instance of the contract class to call the first enhanced contract.

[0049] When packaging the second contract, the first contract on which the second contract depends may be packaged together, that is, the second contract includes the bytecode of the contract class of the first contract.

[0050] When packaging the second contract, if the first contract on which the second contract depends is not packaged together, that is, the bytecode of the contract class of the first contract does not exist in the second contract.

[0051] S122. Determine whether the second contract meets preset conditions based on the metadata and the bytecode file.

[0052] The preset condition may include a first condition and a second condition, wherein the first condition is used to perform a dependency check on the metadata, and the second condition is used to perform a security check on the bytecode file.

[0053] When determining whether the second contract meets the preset conditions based on the metadata and the bytecode file, the metadata may be parsed to determine whether the contract development framework package meets the first condition; if the contract development framework package meets the first condition, the classes in the contract development framework package and the development toolkit are stored in the basic class pool; the classes in the bytecode file are parsed and stored in the contract class pool, and it is determined whether the contract classes in the contract class pool meet the second condition; if the classes in the bytecode file meet the second preset condition and the contract development framework package meets the first condition, it is determined whether the second contract meets the preset condition.

[0054] Specifically, the metadata may be parsed to obtain version information of the contract development framework package that the second contract depends on, and based on the version information, it may be determined whether the contract development framework package is supported. If supported, it may be determined that the contract development framework package meets the first condition; if not supported, it may be determined that the contract development framework package does not meet the first condition.

[0055] If the contract development framework package does not meet the first condition, an error can be reported so that the second contract can be modified. If the contract development framework package meets the first condition, the classes in the contract development framework package and the development tool kit (JDK) can be stored in the basic class pool, that is, the basic class pool stores the classes in the contract development framework package and JDK.

[0056] Parse the bytecode file in the second contract and store the classes in the bytecode file in the contract class pool, that is, the classes stored in the contract class pool are the classes in the bytecode file. Determine whether the classes in the contract class pool, that is, the classes in the bytecode file, meet the second condition.

[0057] Specifically, in smart contracts, there are usually two classes, one is the contract class and the other is the ordinary class. The contract class needs to inherit the contract abstract class. The class name of the contract class will be declared in the metadata. Therefore, it can be determined whether the contract class in the contract class pool inherits the contract abstract class in the contract development package, whether the package name and class name comply with the naming specifications, whether there is any conflict with the class in the basic class pool, etc.

[0058] When the second contract satisfies both the first condition and the second condition, it can be determined that the second contract satisfies the preset condition.

[0059] If the second contract has packaging errors or contract development framework package version errors, it is difficult to discover in the early stage. Usually, errors can only be discovered when the contract is executed. By performing dependency checks and security checks on the second contract under preset conditions, the correctness of the second contract can be ensured and execution errors can be avoided.

[0060] S123. If the second contract meets the preset condition, parse the persistent field information of the contract class based on the bytecode file, the contract class is a class that inherits the contract abstract class in the bytecode file, and the persistent field information includes the persistent fields in the contract class.

[0061] If the second contract meets the preset conditions, it indicates that the second contract is correct and no exception will occur during execution. The persistent field information of the contract class can continue to be parsed based on the bytecode file.

[0062] The contract class refers to the class that inherits the contract abstract class in the bytecode file, that is, the contract class refers to the class that inherits the contract abstract class in the contract class pool. The fields of the contract class are parsed. If there is a persistent field identifier in the field, the field can be considered as a persistent field and the persistent field is used as persistent field information.

[0063] It is understandable that if multiple fields in the contract class have persistent field identifiers, multiple persistent fields can be determined, and the multiple persistent fields constitute persistent field information.

[0064] S124. Based on the persistent field information, replace the preset bytecode instructions in the contract class with preset enhanced instructions to obtain target bytecode, and the preset bytecode instructions and the preset enhanced instructions have a one-to-one correspondence.

[0065] The contract class may include at least one Java method, each Java method includes bytecode instructions, and the preset bytecode instructions refer to the instructions of the preset fields. When there are multiple preset bytecode instructions, each preset bytecode instruction corresponds to a preset enhanced instruction. For example, the preset bytecode instructions include instruction 1, instruction 2, and instruction 3, then instruction 1 corresponds to enhanced instruction 1, instruction 2 corresponds to enhanced instruction 2, and instruction 3 corresponds to enhanced instruction 3.

[0066] The target bytecode is a bytecode instruction obtained by replacing the preset bytecode instruction with the enhanced instruction.

[0067] Based on the persistent field information, the preset bytecode instructions in the contract class are replaced with preset enhanced instructions to obtain the target bytecode, which may be bytecode instructions for traversing the methods in the contract class; when the bytecode instruction is the preset bytecode instruction, it is determined whether the declaration class of the operation field exists in the basic class pool or the contract class pool, and the operation field is the field operated by the bytecode instruction; if the declaration class of the operation field exists in the basic class pool or the contract class pool, it is determined whether the operation field exists in the persistent field information; if the operation field exists in the persistent field information, the bytecode instruction is replaced with the preset enhanced instruction.

[0068] Specifically, the bytecode instructions in each Java method in the contract class can be traversed. If the bytecode instruction is a preset bytecode instruction, the declaration class of the field operated by the bytecode instruction is obtained, that is, the declaration class of the operation field is obtained, and it is determined whether the declaration class exists in the basic class pool or the contract class pool. The preset bytecode instruction can refer to instructions for accessing class fields, such as getstatic and putstatic, and can also refer to instructions for instance fields, such as getfield and putfield.

[0069] If the declaration class exists in the basic class pool or the contract class pool, it is further determined whether the operation field exists in the persistent field information, that is, it is further determined whether the operation field is a persistent field.

[0070] If the declared class does not exist in the base class pool or the contract class pool, it can be considered that the instruction enhancement has failed.

[0071] If it is determined that the operation field exists in the persistent field information, the bytecode instruction is replaced with a preset enhanced instruction.

[0072] That is to say, when a bytecode instruction is a preset bytecode instruction, and the declaration class field of the field operated by the bytecode instruction exists in the basic class pool or the contract class pool, and the field operated is a persistent field, the bytecode instruction can be replaced with a preset enhanced instruction. Specifically, the replacement can be performed according to the corresponding relationship shown in Table 1:

[0073] Table 1

[0074] Preset bytecode instructions Preset Enhanced Commands getstatic getstaticpro putstatic putstaticpro getfield getfieldpro putfield putfieldpro

[0075] You can replace getstatic with getstaticpro, putstatic with putstaticpro, getfield with getfieldpro, and putfield with putfieldpro.

[0076] As mentioned above, if the second contract calls the first enhanced contract by referencing the first contract, but the second contract does not include the bytecode of the contract class of the first contract. When enhancing the second contract, the persistent field information of the contract class in the second contract can be scanned. When enhancing the operation instructions, if it is detected that there are instructions to operate the fields of the contract class of the first contract, it can be determined whether the contract class of the first contract exists in the basic class pool or the contract class pool. If not, the enhancement fails.

[0077] In some implementations, after replacing the preset bytecode instructions with the preset enhanced instructions, an enhanced identifier may be added to the contract class in the contract pool class. The contract with the enhanced identifier may be considered as an enhanced contract.

[0078] S125. Replace the corresponding bytecode file in the preset file with the target bytecode, and package the preset file to obtain the second enhanced contract.

[0079] By replacing the preset bytecode instructions with the preset enhanced instructions, the target bytecode can be obtained, and by replacing the corresponding bytecode file in the preset file with the target bytecode, and repackaging the preset file, the second enhanced contract can be obtained.

[0080] S130. Send the second enhanced contract to a second device so that the second device deploys the second enhanced contract on the blockchain and obtains a second address of the second enhanced contract.

[0081] After obtaining the second enhanced contract, the second enhanced contract can be sent to the second device in the form of a transaction for contract deployment. The second device can complete the contract deployment through the Java smart contract execution engine and generate a unique contract address for the second enhanced contract, which is the second address. Thus, the first device can obtain the second address.

[0082] S140. Send a call request to the second device according to the second address, so that the second device calls the second enhanced contract according to the second address.

[0083] When the second enhanced contract needs to be called, the first device can send a call request to the second device, wherein the call request may include the second address, so that the second device can execute the second enhanced contract according to the second address and return the execution result to the first device.

[0084] The contract calling method provided by the embodiment of the present application can use the address of the called first enhanced contract to perform instruction enhancement on the second contract containing the logic of calling the first contract, and the call to the second enhanced contract based on the second address can realize the cross-contract call between enhanced contracts. And when performing instruction enhancement on the second contract, the dependency check and security check of the second contract are introduced to further ensure the correctness of the second contract and avoid errors during the call.

[0085] In this embodiment, a contract calling method is provided, such as Figure 3 As shown, the contract calling method can be applied to the second device, which is a node device in the blockchain. The specific process can be as follows:

[0086] S210. Receive a calling request sent by a first device, where the calling request includes a second address.

[0087] S220. Obtain a bytecode file of a second enhanced contract according to the second address, where the second enhanced contract includes the first address.

[0088] When the second enhanced contract needs to be called, the first device may send a call request to the second device, where the call request carries the second address, so that the second device may obtain the second address.

[0089] The second device obtains the bytecode file and contract information of the second enhanced contract from the blockchain account book through the second address. The enhanced identifier in the contract information can be used to determine that the called contract is an enhanced contract.

[0090] S230. Create target persistent field information of the second enhanced contract according to the bytecode file of the second enhanced contract and the first address.

[0091] When the second device obtains the bytecode file of the second enhanced contract, it can create a first state table and a contract instance table corresponding to the second enhanced contract. When executing the logic of calling the first enhanced contract, it can obtain the first contract instance corresponding to the first enhanced contract, create a second state table based on the first contract instance, and update the contract instance table based on the first contract instance. The target persistent field information includes the first state table, the second state table, and the contract instance table. Specifically, the process may include the following steps:

[0092] S231. Create a second contract instance of the contract class based on the bytecode file of the second enhanced contract.

[0093] The second device can load the second enhanced contract bytecode based on the second address, find the contract class through the metadata of the second enhanced contract, and create a second contract instance corresponding to the contract class.

[0094] S232. Determine the persistent field in the contract class corresponding to the second contract instance as the second target field, store the second target field and the status information correspondingly, and obtain a second status table corresponding to the second contract instance.

[0095] S233. Create a contract instance table according to the second contract instance;

[0096] S234. When the first enhanced contract is called, the first contract instance of the first enhanced contract is obtained according to the first address in the second enhanced contract.

[0097] During the execution of the second enhanced contract, if the interface method of the first enhanced contract is called, the first contract instance corresponding to the first enhanced contract can be obtained through the first address.

[0098] As an implementation method, if the first contract instance is not obtained through the first address, the first contract instance can be created. Specifically, the second device can obtain the bytecode file and contract class information of the first enhanced contract according to the first address, and create the first contract instance based on the bytecode file. This ensures that the first contract instance can be obtained based on the first address.

[0099] S235. Determine the persistent field in the contract class corresponding to the first contract instance as the first target field, store the first target field and the status information correspondingly, and obtain a first status table corresponding to the first contract instance.

[0100] The persistent field in the contract class corresponding to the second contract instance is determined as the second target field, and the second target field and the state information are stored in correspondence as a second state table. Specifically, the state information of the second target field may be set to be loaded.

[0101] Since the second enhanced contract includes the logic of calling the first enhanced contract, when the second device executes the logic of calling the first enhanced contract, it can obtain the first contract instance according to the first address and create a first state table corresponding to the first contract instance. Specifically, the persistent field in the contract class corresponding to the first contract instance can be determined as the first target field, and the first target field and the state information can be stored in the first state table. Specifically, the state information corresponding to the first target field can be set to be loaded.

[0102] For example, the first enhanced contract is contract A1, and the second enhanced contract is contract B. The contract class corresponding to contract B is ClassB. The second contract instance obtained by creating a contract instance of ClassB is InstanceB1. Scan the field information of ClassB. Assuming that ClassB has two persistent fields FieldB1 and FieldB2, the state table corresponding to InstanceB1 can be obtained, that is, the second state table. For details, please refer to Figure 4 .

[0103] The contract class corresponding to contract A1 is ClassA, and the first contract instance is InstanceA1. Scan the field information of ClassA. Assuming that ClassA has three persistent fields FieldA1, FieldA2, and StaticFieldA3, you can get the state table corresponding to InstanceA1, that is, the first state table. For details, please refer to Figure 4 .

[0104] S236. Update the contract instance table based on the first contract instance.

[0105] After obtaining the second contract instance, a contract instance table can be created. After obtaining the first contract instance, the contract instance table can be updated based on the first contract instance. As described in the previous example, the first contract instance is InstanceA1, and the second contract instance is InstanceB1. InstanceB1 is obtained first, and then InstanceA1 is obtained. Then, a contract instance table can be constructed based on the contract class name and the corresponding contract instance. For details, please refer to Figure 4 .

[0106] It should be noted that the second state table and the contract instance table (at this time, there is only InstanceB1 in the contract instance table) can be constructed in sequence according to the execution order. When the logic of calling the first enhanced contract is executed, the first state table can be constructed, and InstanceA1 can be added to the contract instance table to update the contract instance table to obtain the final contract instance table.

[0107] That is, the target persistent field information includes the constructed state table and contract instance table, where there can be multiple state tables.

[0108] S240. Execute the second enhanced contract based on the target persistent field information.

[0109] When executing the second enhanced contract based on the target persistent field information, the second enhanced contract can be executed based on the aforementioned first state table, second state table and contract instance table, and the first enhanced contract called by the second enhanced contract. The process may include: if the preset enhanced instruction is executed, obtaining the declaration class of the target field operated by the preset enhanced instruction; based on the declaration class, determining from the contract instance table that the last contract instance corresponding to the declaration class name is the target contract instance; in the state table corresponding to the target contract instance, determining the state information corresponding to the target field; and executing the second enhanced contract according to the state information corresponding to the target field.

[0110] As mentioned above, the preset enhanced instructions may include enhanced instructions for accessing class fields (getstaticpro, putstaticpro) and enhanced instructions for accessing instance fields (getfieldpro, putfieldpro).

[0111] In some embodiments, if the preset enhanced instruction executed is getstaticpro, the status information of the target field operated by getstaticpro can be found, and the status information can be loaded or to be loaded. If the status information of the target field is to be loaded, the value of the target field is read from the blockchain account book using the address of the target contract instance and the name of the target field, and the status information of all target fields in the target persistent field information is set to loaded, and then the read value of the target field is inserted into the top of the operand stack. If the status information of the target field is loaded, the value of the target field is inserted into the top of the operation stack.

[0112] In some implementations, if the executed preset enhancement instruction is putstaticpro, a value is taken from the top of the operand stack and set as the value of the target field. If the state information of the target field is to be loaded, the state information of all target fields in the target persistent field information is set to loaded.

[0113] In some embodiments, if the preset enhanced instruction executed is getfieldpro. If the status information of the target field found is to be loaded, the value of the target field is read from the blockchain account book using the address of the target contract instance and the name of the target field, and the status information of the target field in the target contract instance is set to loaded, and then the read value of the target field is inserted into the top of the operand stack. If the status information of the target field is loaded, the value of the target field is inserted into the top of the operation stack.

[0114] In some implementations, if the preset enhanced instruction executed is putfieldpro, a value may be taken from the top of the operand stack and set as the value of the target field. If the status information of the target field is to be loaded, the status information of the target field in the status table of the target contract instance is set to loaded.

[0115] See also Figure 4 , if the getfieldpro instruction of FieldA1 of InstanceA1 is executed, the target field is FieldA1, the declaration class of the target field is ClassA, and the target contract instance is InstanceA1. Query the status table corresponding to InstanceA1, and get the status information of the target field FieldA1 as pending. Therefore, the value of FieldA1 at the address corresponding to InstanceA1 can be obtained from the blockchain account book according to the first address and FieldA1. And set the status information of FieldA1 in InstanceA1 to loaded, that is, Figure 4 The status information of FieldA1 in InstanceA1 is loaded.

[0116] When the putfieldpro instruction for operating FieldB2 of InstanceB1 is executed, the state table corresponding to InstanceB1 can be queried to obtain the state information of the target field FieldB2 as pending. Therefore, the top value in the operand stack can be assigned to FieldB2, and the state information of FieldB2 in InstanceB1 is set to loaded. That is, at this time Figure 4 The status information of FieldB2 in InstanceB1 is loaded.

[0117] The above process is a common cross-contract calling process. In some implementations, there may be cross-contract calls to the same contract, but the contract addresses are different. The following will use a specific example to explain the call in this case in detail.

[0118] Using the above example, if there is an enhanced contract A2, the contents of enhanced contract A1 and enhanced contract A2 are the same, but they have different addresses, that is, enhanced contract A1 corresponds to address A1, and enhanced contract A2 corresponds to address A2, that is, although enhanced contract A1 and enhanced contract A2 have the same execution logic, their ledger data are not interoperable. Enhanced contract B cross-contract calls enhanced contract A1 and enhanced contract A2.

[0119] When calling enhanced contract B, you can get the state table corresponding to the contract instance InstanceB1 corresponding to enhanced contract B. For details, please refer to Figure 5. And add the contract instance InstanceB1 corresponding to ClassB in the contract instance table.

[0120] When executing the logic of cross-contract call enhancement contract A1, assuming that FieldA1 has been operated, create the state table corresponding to InstanceA1, and add the contract instance InstanceA1 corresponding to ClassA to the contract instance table. The target persistent field information constructed at this time can be found in Figure 5 .

[0121] When the getstaticpro instruction for StaticFieldA3 of ClassA is executed, the last instance InstanceA1 corresponding to ClassA is obtained from the enhanced contract instance mapping table. After checking the enhanced contract status information of InstanceA1, it is found that the status of StaticFieldA3 is to be loaded. Therefore, the Java smart contract engine obtains the value of StaticFieldA3 under the address A1 corresponding to InstanceA1 from the account book, and sets the status of StaticFieldA3 of all instances in ClassA to loaded. That is, Figure 5 The status information of StaticFieldA3 changes from "to be loaded" to "loaded".

[0122] When the cross-contract call to enhance the logic of contract A2 is executed, the state table corresponding to InstanceA2 is created, and the state information of the target field is set to be loaded. For class fields, the state information of the target field also needs to be set to be loaded in the state tables of other instances of the current class. That is, the state information of StaticFieldA3 is set to be loaded in the state table of InstanceA1. At this time, the state information of StaticFieldA3 in the state table of InstanceA1 changes from loaded to loaded again.

[0123] Add contract instance InstanceA2 to the contract instance table, that is, add InstanceA2 to the contract instance corresponding to ClassA. The target persistent field information obtained at this time can be referred to Figure 6 .

[0124] When the getstaticpro instruction for StaticFieldA3 of ClassA is executed again, the last instance InstanceA2 corresponding to ClassA is obtained from the contract instance table. Check that the status information of StaticFieldA3 in InstanceA2 is to be loaded. Therefore, the value of StaticFieldA3 under address A2 corresponding to InstanceA2 is obtained from the blockchain account book, and the status of StaticFieldA2 in the status table of all instances in ClassA is set to loaded, that is, Figure 6 The status information of StaticFieldA3 in the status table of InstanceA2 and the status table of InstanceA1 are both changed to loaded.

[0125] When the getfieldpro instruction of FieldA2 of InstanceA2 is executed, the status information of FieldA2 in the status table corresponding to InstanceA1 is checked to be to be loaded. Therefore, the second device can obtain the value of FieldA2 under the address corresponding to InstanceA2 from the blockchain account book. And set the status of FieldA2 in InstanceA2 to loaded. At this time, the target persistent field information obtained can refer to Figure 7 .

[0126] Thus, the second device can call the second enhanced contract containing the cross-contract call logic in the above manner, and return the execution result obtained by executing the second enhanced contract to the first device, so that the first device knows the result obtained by calling the second enhanced contract. It should be noted that the above process can be executed by the Java smart contract execution engine in the second device.

[0127] From the above, it can be seen that in the contract calling method provided in the embodiment of the present application, the second device can obtain the second enhanced contract based on the second address, and obtain the first contract instance called by the second enhanced contract according to the first address in the second enhanced contract, and create target persistent field information based on the second enhanced contract and the first contract instance to execute the second enhanced contract, thereby realizing the call of the second enhanced contract containing cross-contract calling logic.

[0128] In order to better implement the above method, the embodiment of the present application also provides a contract calling device, which is applied to the first device. Figure 8 As shown, the contract calling device 300 may include an acquisition module 310, an enhancement module 320, a deployment module 330 and a calling module 340.

[0129] The acquisition module 310 is used to obtain the first address of the first enhanced contract, where the first address is the address obtained after the first enhanced contract is deployed on the blockchain; the enhancement module 320 is used to perform instruction enhancement on the second contract according to the first address to obtain a second enhanced contract, where the second contract includes the first address; the deployment module 330 is used to send the second enhanced contract to the second device, so that the second device deploys the second enhanced contract on the blockchain and obtains the second address of the second enhanced contract; the calling module 340 is used to send a calling request to the second device according to the second address, so that the second device calls the second enhanced contract according to the second address.

[0130] In some embodiments, the first enhanced contract is obtained by performing instruction enhancement on the first contract, and the enhancement module 320 is further used to: decompress the second contract to a preset file, the preset file includes a bytecode file and metadata, and the bytecode file includes the bytecode file in the first contract obtained based on the first address; based on the metadata and the bytecode file, determine whether the second contract meets the preset conditions; if the second contract meets the preset conditions, parse the persistent field information of the contract class based on the bytecode file, the contract class is a class that inherits the contract abstract class in the bytecode file, and the persistent field information includes the persistent fields in the contract class; based on the persistent field information, replace the preset bytecode instructions in the contract class with preset enhancement instructions to obtain the target bytecode, and the preset bytecode instructions and the preset enhancement instructions have a one-to-one correspondence; replace the corresponding bytecode file in the preset file with the target bytecode, and package the preset file to obtain the second enhanced contract.

[0131] In some embodiments, the preset condition includes a first condition and a second condition, and the enhancement module 320 is also used to: parse the metadata to determine whether the contract development framework package satisfies the first condition; if the contract development framework package satisfies the first condition, store the classes in the contract development framework package and the development toolkit in the basic class pool; parse the classes in the bytecode file and store them in the contract class pool, and determine whether the contract classes in the contract class pool meet the second condition; if the classes in the bytecode file meet the second preset condition and the contract development framework package meets the first condition, determine that the second contract meets the preset condition.

[0132] In some embodiments, the enhancement module 320 is also used to: traverse the bytecode instructions of the methods in the contract class; when the bytecode instruction is the preset bytecode instruction, determine whether the declaration class of the operation field exists in the basic class pool or the contract class pool, and the operation field is the field operated by the bytecode instruction; if the declaration class of the operation field exists in the basic class pool or the contract class pool, determine whether the operation field exists in the persistent field information; if the operation field exists in the persistent field information, replace the bytecode instruction with the preset enhancement instruction.

[0133] In order to better implement the above method, the embodiment of the present application also provides a contract calling device, which is applied to the second device. Fig. 9 As shown, the contract calling device 400 may include a receiving module 410, a file acquisition module 420, an instance acquisition module 430, a creation module 430 and an execution module 440.

[0134] The receiving module 410 is configured to receive a call request sent by the first device, wherein the call request includes a second address;

[0135] A file acquisition module 420, configured to acquire a bytecode file of a second enhanced contract according to the second address, wherein the second enhanced contract includes the first address;

[0136] A creation module 430, configured to create target persistent field information of the second enhanced contract according to the bytecode file of the second enhanced contract and the first address;

[0137] The execution module 440 is used to execute the second enhanced contract based on the target persistent field information.

[0138] In some embodiments, the creation module 430 is also used to: create a second contract instance of the contract class based on the bytecode file of the second enhanced contract; determine the persistent field in the contract class corresponding to the second contract instance as the second target field, store the second target field and status information accordingly, and obtain a second status table corresponding to the second contract instance; create a contract instance table according to the second contract instance; when calling the first enhanced contract, obtain the first contract instance of the first enhanced contract according to the first address in the second enhanced contract; determine the persistent field in the contract class corresponding to the first contract instance as the first target field, store the first target field and status information accordingly, and obtain a first status table corresponding to the first contract instance; update the contract instance table based on the first contract instance.

[0139] In some embodiments, the execution module 440 is also used to: if a preset enhancement instruction is executed, obtain the declaration class of the target field operated by the preset enhancement instruction; based on the declaration class, determine from the contract instance table that the last contract instance corresponding to the declaration class name is the target contract instance; in the status table corresponding to the target contract instance, determine the status information corresponding to the target field; and execute the second enhanced contract according to the status information corresponding to the target field.

[0140] In specific implementation, the above modules can be implemented as independent entities, or can be arbitrarily combined and implemented as the same or several entities. The specific implementation of the above modules can be found in the previous method embodiments, which will not be repeated here.

[0141] The contract calling device provided in the embodiment of the present application can use the address of the called first enhanced contract to perform instruction enhancement on the second contract containing the logic of calling the first contract, and the call to the second enhanced contract based on the second address can realize the cross-contract call between enhanced contracts. And when performing instruction enhancement on the second contract, the dependency check and security check on the second contract are introduced to further ensure the correctness of the second contract and avoid errors when calling the second enhanced contract.

[0142] Correspondingly, an embodiment of the present application also provides an electronic device, which may be a terminal or a server, and the terminal may be a smart phone, a tablet computer, a laptop computer, a touch screen, a game console, a personal computer, a personal digital assistant (PDA), or other terminal devices.

[0143] like Fig.10 As shown, Fig.10 The schematic diagram of the structure of the electronic device provided in the embodiment of the present application, the electronic device 500 includes a processor 501 with one or more processing cores, a memory 502 with one or more computer-readable storage media, and a computer program stored in the memory 502 and executable on the processor. The processor 501 is electrically connected to the memory 502. It can be understood by those skilled in the art that 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.

[0144] The processor 501 is the control center of the electronic device 500. It uses various interfaces and lines to connect various parts of the entire electronic device 500, executes various functions of the electronic device 500 and processes data by running or loading software programs and / or modules stored in the memory 502, and calling data stored in the memory 502, thereby monitoring the electronic device 500 as a whole.

[0145] In the embodiment of the present application, the processor 501 in the electronic device 500 will load instructions corresponding to the processes of one or more application programs into the memory 502 according to the following steps, and the processor 501 will run the application programs stored in the memory 502 to implement various functions:

[0146] Obtaining a first address of a first enhanced contract, where the first address is an address obtained after the first enhanced contract is deployed on the blockchain;

[0147] Performing instruction enhancement on a second contract according to the first address to obtain a second enhanced contract, where the second contract includes the first address;

[0148] Sending the second enhanced contract to a second device so that the second device deploys the second enhanced contract on a blockchain and obtains a second address of the second enhanced contract;

[0149] A call request is sent to the second device according to the second address, so that the second device calls the second enhanced contract according to the second address.

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

[0151] although Fig.10 Not shown, the electronic device 500 may also include an input unit, a power supply, a radio frequency circuit, an audio circuit, a camera, a sensor, a wireless fidelity module, a Bluetooth module, etc., which are not described in detail here.

[0152] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0153] 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.

[0154] To this end, an embodiment of the present application provides a computer-readable storage medium, in which multiple computer programs are stored, and the computer program 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 computer program can execute the following steps:

[0155] Obtaining a first address of a first enhanced contract, where the first address is an address obtained after the first enhanced contract is deployed on the blockchain;

[0156] Performing instruction enhancement on a second contract according to the first address to obtain a second enhanced contract, where the second contract includes the first address;

[0157] Sending the second enhanced contract to a second device so that the second device deploys the second enhanced contract on a blockchain and obtains a second address of the second enhanced contract;

[0158] A call request is sent to the second device according to the second address, so that the second device calls the second enhanced contract according to the second address.

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

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

[0161] Since the computer program stored in the 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.

[0162] The above is a detailed introduction to a contract calling method, device, storage medium and electronic device provided in the embodiments 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 ideas of the present application, there will be changes in the specific implementation methods 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: Applied to a first device, the method includes: Obtaining a first address of a first enhanced contract, where the first address is an address obtained after the first enhanced contract is deployed on the blockchain, and the first enhanced contract is obtained by performing instruction enhancement on the first contract; Performing instruction enhancement on a second contract according to the first address to obtain a second enhanced contract, where the second contract includes the first address; Sending the second enhanced contract to a second device so that the second device deploys the second enhanced contract on a blockchain and obtains a second address of the second enhanced contract; Sending a call request to the second device according to the second address, so that the second device calls the second enhanced contract according to the second address; The step of enhancing the second contract according to the first address to obtain the second enhanced contract includes: Decompressing the second contract into a preset file, wherein the preset file includes a bytecode file and metadata, and the bytecode file includes the bytecode file in the first contract obtained based on the first address; Based on the metadata and the bytecode file, determining whether the second contract satisfies a preset condition; If the second contract meets the preset condition, the persistent field information of the contract class is parsed based on the bytecode file, the contract class is a class that inherits the contract abstract class in the bytecode file, and the persistent field information includes the persistent fields in the contract class; Based on the persistent field information, the preset bytecode instructions in the contract class are replaced with preset enhanced instructions to obtain target bytecode, wherein the preset bytecode instructions and the preset enhanced instructions have a one-to-one correspondence; The corresponding bytecode file in the preset file is replaced with the target bytecode, and the preset file is packaged to obtain the second enhanced contract.

2. The method according to claim 1, characterized in that: The preset condition includes a first condition and a second condition, and determining whether the second contract satisfies the preset condition based on the metadata and the bytecode file includes: Parsing the metadata to determine whether the contract development framework package meets the first condition; If the contract development framework package meets the first condition, storing the classes in the contract development framework package and the development toolkit into the basic class pool; Parsing the classes in the bytecode file and storing them in a contract class pool, and determining whether the contract classes in the contract class pool meet the second condition; If the class in the bytecode file satisfies the second preset condition, and the contract development framework package satisfies the first condition, it is determined that the second contract satisfies the preset condition.

3. The method according to claim 2, characterized in that The step of replacing the preset bytecode instructions in the contract class with preset enhanced instructions based on the persistent field information to obtain the target bytecode includes: Traverse the bytecode instructions of the methods in the contract class; When the bytecode instruction is the preset bytecode instruction, determining whether the declaration class of the operation field exists in the basic class pool or the contract class pool, the operation field being the field operated by the bytecode instruction; If the declaration class of the operation field exists in the basic class pool or the contract class pool, determine whether the operation field exists in the persistent field information; If the operation field exists in the persistent field information, the bytecode instruction is replaced with a preset enhanced instruction.

4. A contract calling method, characterized in that: Applied to a second device, where the second device is a node device in a blockchain, the method includes: receiving a call request sent by the first device, wherein the call request includes a second address; Acquire a bytecode file of a second enhanced contract according to the second address, where the second enhanced contract includes the first address; Creating target persistent field information of the second enhanced contract according to the bytecode file of the second enhanced contract and the first address; Executing the second enhanced contract based on the target persistent field information; The executing the second enhanced contract based on the target persistent field information includes: If a preset enhancement instruction is executed, obtaining a declaration class of a target field operated by the preset enhancement instruction; Based on the declaration class, determine from the contract instance table the last contract instance corresponding to the declaration class name as the target contract instance; In the status table corresponding to the target contract instance, determine the status information corresponding to the target field; Execute the second enhanced contract according to the status information corresponding to the target field.

5. The method according to claim 4, characterized in that The step of creating target persistent field information of the second enhanced contract according to the bytecode file of the second enhanced contract and the first address includes: Create a second contract instance of the contract class based on the bytecode file of the second enhanced contract; Determine a persistent field in the contract class corresponding to the second contract instance as a second target field, store the second target field and the state information in correspondence, and obtain a second state table corresponding to the second contract instance; Create a contract instance table according to the second contract instance; When the first enhanced contract is called, a first contract instance of the first enhanced contract is obtained according to the first address in the second enhanced contract; Determine a persistent field in a contract class corresponding to the first contract instance as a first target field, store the first target field and state information in correspondence, and obtain a first state table corresponding to the first contract instance; The contract instance table is updated based on the first contract instance.

6. A contract calling device, characterized in that: Applied to a first device, the apparatus comprises: An acquisition module, used to acquire a first address of a first enhanced contract, where the first address is an address obtained after the first enhanced contract is deployed on the blockchain, and the first enhanced contract is obtained by performing instruction enhancement on the first contract; an enhancement module, configured to enhance the second contract according to the first address to obtain a second enhanced contract, wherein the second contract includes the first address; A deployment module, configured to send the second enhanced contract to a second device, so that the second device deploys the second enhanced contract on a blockchain and obtains a second address of the second enhanced contract; a calling module, configured to send a calling request to the second device according to the second address, so that the second device calls the second enhanced contract according to the second address; Wherein, the enhancement module is specifically used for: Decompressing the second contract into a preset file, wherein the preset file includes a bytecode file and metadata, and the bytecode file includes the bytecode file in the first contract obtained based on the first address; Based on the metadata and the bytecode file, determining whether the second contract satisfies a preset condition; If the second contract meets the preset condition, the persistent field information of the contract class is parsed based on the bytecode file, the contract class is a class that inherits the contract abstract class in the bytecode file, and the persistent field information includes the persistent fields in the contract class; Based on the persistent field information, the preset bytecode instructions in the contract class are replaced with preset enhanced instructions to obtain target bytecode, wherein the preset bytecode instructions and the preset enhanced instructions have a one-to-one correspondence; The corresponding bytecode file in the preset file is replaced with the target bytecode, and the preset file is packaged to obtain the second enhanced contract.

7. A contract calling device, characterized in that: Applied to a second device, where the second device is a node device in a blockchain, the apparatus comprises: A receiving module, configured to receive a call request sent by the first device, wherein the call request includes a second address; A file acquisition module, used to acquire a bytecode file of a second enhanced contract according to the second address, where the second enhanced contract includes the first address; A creation module, used to create target persistent field information of the second enhanced contract according to the bytecode file of the second enhanced contract and the first address; An execution module, configured to execute the second enhanced contract based on the target persistent field information; Wherein, the execution module is specifically used for: If a preset enhancement instruction is executed, obtaining a declaration class of a target field operated by the preset enhancement instruction; Based on the declaration class, determine from the contract instance table the last contract instance corresponding to the declaration class name as the target contract instance; In the status table corresponding to the target contract instance, determine the status information corresponding to the target field; Execute the second enhanced contract according to the status information corresponding to the target field.

8. An electronic device, characterized in that: It comprises a processor and a memory, wherein the memory stores a plurality of instructions; the processor loads instructions from the memory to execute the steps in the contract calling method as described in any one of claims 1 to 5.

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

Images