Contract creation method and related equipment
By extending the two-field protocol in the salt-added parameters of the blockchain contract creation instruction, directly parsing the contract type and name, the interaction complexity problem between virtual machines is solved, and the ability to create other types of contracts is realized in solidity contracts is realized, which simplifies the process and Improves user experience and security.
Patent Information
- Application Number
- CN202310776606.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-06-27
- Publication Date
- 2024-12-27
AI Technical Summary
The design of heterogeneous interaction protocols between virtual machines in the blockchain is too broad and difficult to implement in detail, resulting in increased logical complexity, code redundancy, increased development burden, increased security risks, and decreased user experience.
By extending the two-field protocol in the salt-added parameters of the contract creation instruction, the preset bit area of the salt-added parameters is parsed to determine the contract type and contract name, and directly calling the corresponding virtual machine to create the contract, avoiding the introduction of the intermediate API layer.
It realizes the ability to create other types of contracts in solidity contracts, simplifies the contract creation process, reduces logical complexity and code redundancy, and improves user experience and security.
Smart Images

Figure CN119205324A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of computer technology, and in particular to a contract creation 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 the current related technologies, an API layer is generally inserted between multiple virtual machines and world states to connect to various types of virtual machines. On the blockchain consensus node, the consensus module calls the API layer and hands the packaged transaction to the virtual machine for execution; when the virtual machine executes, the read and write of the state is reversely operated on the state data on the node through the callback of the API layer. When the contract publisher creates and publishes a contract, a field is attached to indicate the type of virtual machine that the contract needs to interpret and execute; 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 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 creation method and related equipment. The related equipment may include a contract creation device, an electronic device, a computer-readable storage medium, and a computer program product. By expanding the salting parameters, the solidity contract can heterogeneously create other types of contracts.
[0006] The present application embodiment provides a contract creation method, including:
[0007] Executing a first contract by a first virtual machine, wherein the first contract includes a contract creation instruction;
[0008] Obtain the salt parameter field carried by the contract creation instruction, and parse the first preset bit area of the salt parameter field;
[0009] If the written value of the first preset bit area meets the predefined type rule, determine the contract type of the second contract, and parse the second preset bit area of the salt parameter field;
[0010] Determining a contract name of the second contract according to the second preset bit area;
[0011] According to the contract type and the contract name, a second virtual machine corresponding to the contract type is called through a contract creation interface, and the second contract is created.
[0012] Accordingly, an embodiment of the present application provides a contract creation device, including:
[0013] An execution unit, configured to execute a first contract through a first virtual machine, wherein the first contract includes a contract creation instruction;
[0014] An acquisition unit, used to acquire a salt parameter field carried by the contract creation instruction, and parse a first preset bit area of the salt parameter field;
[0015] A first determining unit, configured to determine the contract type of the second contract if the written value of the first preset bit area meets the predefined type rule, and parse the second preset bit area of the salt parameter field;
[0016] A second determining unit, configured to determine a contract name of the second contract according to the second preset bit region;
[0017] A creation unit is used to call a second virtual machine corresponding to the contract type through a contract creation interface according to the contract type and the contract name, and create the second contract.
[0018] Optionally, in some embodiments of the present application, the first determination unit can be specifically used to perform a first byte conversion on the written value of the first preset bit area to obtain a first written value if the written value of the first preset bit area meets a predefined type rule; determine the contract type of the second contract based on the first written value; and parse the second preset bit area of the salt parameter field.
[0019] Optionally, in some embodiments of the present application, the second determination unit can be specifically used to obtain the write value of the second preset bit area; perform a second byte conversion on the write value of the second preset bit area to obtain a second write value; and determine the contract name of the second contract based on the second write value.
[0020] Optionally, in some embodiments of the present application, the creation unit may include an acquisition subunit, a call subunit, and a creation subunit, as follows:
[0021] The acquisition subunit is used to generate a contract address based on the contract name, and obtain the address of the first contract as the caller address;
[0022] The calling subunit is used to call the contract creation interface and pass the contract type, contract name, contract address, and caller address as parameters into the contract creation interface;
[0023] The creation subunit is used to call the second virtual machine corresponding to the contract type through the contract creation interface and create the second contract.
[0024] Optionally, in some embodiments of the present application, the creation sub-unit can be specifically used to call a second virtual machine corresponding to the contract type through the contract creation interface; start a virtual machine instance of the second virtual machine; call the virtual machine instance to create the second contract.
[0025] Optionally, in some embodiments of the present application, the calling subunit may include a first determining subunit, a second determining subunit, and a generating subunit, as follows:
[0026] The first determining subunit is used to determine the creation type corresponding to the second contract;
[0027] The second determining subunit is used to determine a contract creator of the second contract based on the creation type;
[0028] The generation subunit is used to generate and store a contract instance based on the contract name, the contract address, the contract type, and the contract creator.
[0029] Optionally, in some embodiments of the present application, the generation subunit can be specifically used to generate a contract instance based on the contract name, the contract address, the contract type, and the contract creator; and store the contract instance with the contract name and the contract address as indexes.
[0030] Optionally, in some embodiments of the present application, the generation subunit can be specifically used to store the contract name with the contract address as the first index; and store the contract instance with the contract name as the second index.
[0031] 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 creation method provided in the embodiment of the present application.
[0032] 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 creation method provided in the embodiment of the present application are implemented.
[0033] 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, implement the steps in the contract creation method provided in the embodiment of the present application.
[0034] The embodiment of the present application provides a contract creation method and related equipment, which can execute a first contract through a first virtual machine, wherein the first contract includes a contract creation instruction; obtain a salt parameter field carried by the contract creation instruction, and parse the first preset bit area of the salt parameter field; if the written value of the first preset bit area meets the predefined type rule, determine the contract type of the second contract, and parse the second preset bit area of the salt parameter field; determine the contract name of the second contract according to the second preset bit area; according to the contract type and the contract name, call the second virtual machine of the corresponding contract type through the contract creation interface, and create the second contract. The present application can expand the salt parameter so that the solidity contract can heterogeneously create other types of contracts, and the implementation method of contract creation is clearer and more specific, thereby avoiding the logical complexity brought about by similar solutions such as adding an intermediate API layer in the prior art, as well as the problems of code redundancy, increased development burden, increased security risks, and decreased user experience extended therefrom. In addition, when creating a contract through a contract, the present application can specify the contract name of the contract to be created. Compared with the technical solution in which the virtual machine automatically creates a contract address for the contract to be created, the user can specify the contract name independently, which can make it more convenient for the user to manage the contract, and the contract name is more user-friendly, thereby improving the usage efficiency and user experience. BRIEF DESCRIPTION OF THE DRAWINGS
[0035] 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.
[0036] Figure 1 It is a scenario diagram of the contract creation method provided in the embodiment of the present application;
[0037] Figure 2 is a first flow chart of the contract creation method provided in an embodiment of the present application;
[0038] Figure 3 is a second flow chart of the contract creation method provided in an embodiment of the present application;
[0039] Figure 4 It is a structural diagram of the blockchain system provided in the embodiment of the present application;
[0040] Figure 5 It is another structural schematic diagram of the blockchain system provided in an embodiment of the present application;
[0041] Figure 6 is a third flow chart of the contract creation method provided in the embodiment of the present application;
[0042] Figure 7 It is a structural diagram of a contract creation device provided in an embodiment of the present application;
[0043] Figure 8 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0044] 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.
[0045] The embodiment of the present application provides a contract creation method and related equipment, and the related equipment may include a contract creation device, an electronic device, a computer-readable storage medium, and a computer program product. The contract creation device may be integrated in an electronic device, and the electronic device may be a terminal or a server.
[0046] 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.
[0047] like Figure 1 As shown, a terminal and a server jointly execute a contract creation method as an example. The contract creation 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 creation device can be integrated in the server.
[0048] Among them, the server can be used to: obtain a first contract from a terminal, the first contract includes a contract creation instruction, and then execute the first contract through a first virtual machine; obtain the salt parameter field carried by the contract creation instruction, and parse the first preset bit area of the salt parameter field; if the written value of the first preset bit area meets the predefined type rule, determine the contract type of the second contract, and parse the second preset bit area of the salt parameter field; determine the contract name of the second contract according to the second preset bit area; according to the contract type and the contract name, call the second virtual machine of the corresponding contract type through the contract creation interface, and create the second contract, and return the created second contract to the terminal. 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 creation method or device disclosed in the present application, wherein multiple servers can be composed into a blockchain, and the server is a node on the blockchain.
[0049] The terminal can be used to: obtain a first contract, the first contract includes a contract creation instruction, and the contract creation instruction carries a salt parameter field, wherein the salt parameter field includes information related to the contract type and contract name of the second contract. Then the first contract is transmitted to the server so that the server creates the second contract based on the first contract. The terminal can include a tablet computer, a laptop, or a personal computer (PC). A client can also be set on the terminal, and the client can be an application client or a browser client, etc.
[0050] It should be noted that the contract creation 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.
[0051] Take the distributed system as the blockchain system as an example, see Figure 4 , Figure 4 This 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, and a peer-to-peer (PeerTo Peer, P2P) network is formed between the nodes. The P2P protocol is an application layer protocol running on the Transmission Control Protocol (Transmission Control Protocol, TCP) protocol. 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.
[0052] See also Figure 4The functions of each node in the blockchain system shown include:
[0053] 1) Routing: a basic function of a node, used to support communication between nodes.
[0054] In addition to the routing function, the node can also have the following functions:
[0055] 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.
[0056] See also Figure 5 , Figure 5 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.
[0057] It should be noted that the description order of the following embodiments is not intended to limit the preferred order of the embodiments.
[0058] This embodiment will be described from the perspective of a contract creation device, which can be integrated into an electronic device, such as a server or terminal. It is understood 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 creation method can be as follows:
[0059] 201. Execute a first contract through a first virtual machine, where the first contract includes a contract creation instruction.
[0060] 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 (anti-counterfeiting) and generate the next block.
[0061] 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.
[0062] A smart contract is a computer protocol designed to disseminate, verify or execute a contract in an information-based manner. It is essentially a program executed by a computer. The contract trigger conditions, matters to be executed 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. For example, in the embodiment of the present application, the first contract can refer to the original contract used to create the contract, and the second contract can refer to the contract to be created, that is, the present application can use the first contract to create the second contract.
[0063] Among them, the contract creation instruction in the first contract is an instruction of the Ethereum virtual machine, which is used to create a new contract from the contract code. The address of the created contract will be generated by the Ethereum virtual machine by calculating the hash based on the caller address and the transaction sequence number tag value of the caller's blockchain account. The contract creation instruction also carries a salt parameter field. The caller can pass any 32-byte value to the salt parameter field. When generating the contract address for the contract to be created, the salt parameter will become one of the generation factors.
[0064] In one embodiment, for example, the purpose of the present application is to create a contract through a contract, therefore, the first contract can be an initial contract for creating a contract, and the first contract can be created through a contract creation instruction. Among them, the first virtual machine can be an EVM virtual machine, the first contract can be a solidity contract, and the contract creation instruction can be a create2 instruction, that is, the present application can execute the first contract through the first virtual machine, wherein the first contract includes a contract creation instruction. Among them, the EVM virtual machine is the Ethereum virtual machine, which is an Ethereum blockchain program that resides in an Ethereum node and executes smart contracts. 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.
[0065] 202. Obtain the salt parameter field carried by the contract creation instruction, and parse the first preset bit area of the salt parameter field.
[0066] Among them, the salt parameter is the salt parameter, which is a random value generated by the system when the user registers and is combined with the user password. Salting the user password makes the encrypted ciphertext less likely to be cracked. The salt parameter is a randomly generated set of strings that can include random uppercase and lowercase letters, numbers, characters, etc. For example, the technical solution of the present application can achieve the purpose of customizing the contract type and contract name of the contract to be created by expanding the salt parameter. In the subsequent steps, the salt parameter can be directly applied to obtain the contract type and contract name of the contract to be created.
[0067] The first preset bit area refers to a preset area in the salt parameter field. By parsing the first preset bit area, the contract type corresponding to the contract to be created can be obtained.
[0068] For example, in an embodiment of the present application, the contract creation instruction may be a create2 instruction, and the salting parameter may be a salt parameter. That is, the present application may read the salting parameter from the first virtual machine stack based on the contract creation instruction, and parse the first byte of the salting parameter field as the first preset bit area.
[0069] In one embodiment, the first preset bit area of the salt parameter field is not limited to the first byte of the salt parameter. The location of the first preset bit area of the salt parameter field can also be determined according to actual application conditions and user needs, as long as the contract type of the contract to be created can be obtained based on the written value of the first preset bit area of the salt parameter field.
[0070] 203. If the written value of the first preset bit area meets the predefined type rule, determine the contract type of the second contract, and parse the second preset bit area of the salt parameter field.
[0071] Among them, smart contracts can include multiple contract types, for example, contract types can include solidity contracts, wasm (WebAssembly) contracts, etc. Among them, wasm is a program encoding format, and when the program code is encoded into wasm bytecode, the program can be executed by the wasm virtual machine.
[0072] The second preset bit area refers to a preset area in the salt parameter field. By parsing the second preset bit area, the contract name corresponding to the contract to be created can be obtained.
[0073] For example, if the written value of the first preset bit area meets the predefined type rule, it means that the contract type corresponding to the contract to be created can be obtained by this analysis, and the contract type of the second contract is determined according to the written value of the first preset bit area, wherein the second contract is the contract to be created. After successfully obtaining the contract type of the contract to be created, the second preset bit area of the salt parameter field can be parsed.
[0074] Optionally, in one embodiment, the step of “if the written value of the first preset bit area meets the predefined type rule, determining the contract type of the second contract, and parsing the second preset bit area of the salt parameter field” may include:
[0075] If the written value of the first preset bit region meets the predefined type rule, the written value of the first preset bit region is converted into a first byte to obtain a first written value;
[0076] Determining a contract type of a second contract based on the first written value;
[0077] Parse the second preset bit area of the salt parameter field.
[0078] For example, in the embodiment of the present application, the first virtual machine can be an EVM virtual machine, the contract creation instruction can be a create2 instruction, the salting parameter can be a salt parameter, and the second contract is a contract to be created. Then the present application can modify the contract creation instruction of the first virtual machine. When the contract creation instruction reads the salting parameter from the first virtual machine stack, the first byte of the salting parameter is used as the first preset bit area, and the write value of the first preset bit area is converted to the first byte to obtain the first write value, that is, the write value of the first preset bit area is converted to an integer number, and the integer number is the first write value. If the integer number is within the valid contract type number range, it means that the write value of the first preset bit area meets the predefined type rules. At this time, the contract type of the second contract can be determined according to the number represented by the first write value. After obtaining the contract type, the second preset bit area of the salting parameter field can be further parsed.
[0079] If the integer number is not within the valid contract type number range, it means that the written value of the first preset bit area does not conform to the predefined type rule, then the parsing of the salt parameter is canceled and a message indicating that the contract type parsing failed is returned.
[0080] In one embodiment, the present application is not limited to converting the written value of the first preset bit area into an integer number to determine the contract type of the second contract; the written value of the first preset bit area can also be converted into other types, such as converted into a floating point number, a character, etc., and then the contract type of the second contract is determined; it is even possible not to convert the written value of the first preset bit area, and directly determine the contract type of the second contract based on the written value of the first preset bit area, and so on.
[0081] 204. Determine a contract name of the second contract according to the second preset bit area.
[0082] Among them, the contract name is the name used to identify the contract. The contract name is for ease of use, so it can be expressed as a human-readable string. Compared with the contract address, such a contract name is more readable for users and is easy to remember and write.
[0083] For example, the area where the bytes other than the first byte in the salt parameter field are located can be determined as the second preset bit area. After determining the contract type of the second contract, the written value of the second preset bit area in the salt parameter can be read, and the contract name of the second contract can be determined based on the written value of the second preset bit area.
[0084] Optionally, in one embodiment, the step of “determining the contract name of the second contract according to the second preset bit area” may include:
[0085] Obtaining a written value of a second preset bit area;
[0086] Performing a second byte conversion on the written value of the second preset bit area to obtain a second written value;
[0087] Based on the second written value, a contract name of the second contract is determined.
[0088] For example, after determining the contract type of the second contract, you can then read the written value of the second preset bit area in the salt parameter, and then convert the written value of the second preset bit area into a string, that is, perform a second byte conversion to obtain the second written value. If the conversion is successful, the second written value is determined as the contract name of the second contract, and the contract name is recorded; if the conversion fails or the converted second written value contains garbled characters, the parsing of the salt parameter is canceled, and a message indicating that the parsing of the contract name failed is returned.
[0089] In one embodiment, since the present application is to create a contract, it is necessary to determine the contract type of the contract to be created. If the contract type of the contract to be created cannot be determined, the steps of creating the contract cannot be executed. Therefore, the technical solution of the present application can first determine the contract type of the contract to be created, and then determine the contract name of the contract to be created; if the contract type of the contract to be created cannot be determined, there is no need to execute the step of determining the contract name of the contract to be created.
[0090] For example, in the embodiment of the present application, the first virtual machine may be an EVM virtual machine, the contract creation instruction may be a create2 instruction, the salting parameter may be a salt parameter, the second contract is a contract to be created, the first preset bit area is the first byte of the salting parameter, and the second preset bit area is the other bytes of the salting parameter excluding the first byte. The present application may modify the contract creation instruction of the first virtual machine so that when the salting parameter is read from the first virtual machine stack using the contract creation instruction, the following possible scenarios may be included:
[0091] 1. First, get the first byte of the salt parameter and convert it to an integer. Then check whether the integer is within the valid contract type number range. If the check fails, that is, the integer is not within the valid contract type number range, then cancel the parsing of the salt parameter and return a message that the contract type parsing failed. The step of obtaining the contract type and contract name is terminated.
[0092] 2. First, get the first byte of the salt parameter and convert it to an integer. Secondly, check whether the integer is within the valid contract type number range. If the check passes, that is, the integer is within the valid contract type number range, then the contract type corresponding to the second contract can be obtained according to the number represented by the integer. Then read the remaining bytes of the salt parameter and convert it to a string. If the conversion fails or the string is garbled, cancel the parsing of the salt parameter and return a message that the parsing of the contract name failed. The step of obtaining the contract type and contract name is terminated.
[0093] 3. First, get the first byte of the salt parameter and convert it to an integer. Secondly, check whether the integer is within the valid contract type number range. If the check passes, that is, the integer is within the valid contract type number range, then the contract type corresponding to the second contract can be obtained according to the number represented by the integer. Then read the remaining bytes of the salt parameter and convert them to a string. If the conversion is successful, record the string as the contract name, thereby achieving the steps of obtaining the contract type and contract name of the second contract.
[0094] 205. According to the contract type and the contract name, a second virtual machine corresponding to the contract type is called through a contract creation interface, and a second contract is created.
[0095] For example, Figure 6 As shown, the first virtual machine can call the second virtual machine through the contract creation interface according to the contract type and the contract name, wherein the second virtual machine corresponds to the contract type of the second contract, that is, the operation of creating the second contract can be performed using the second virtual machine.
[0096] Optionally, in one embodiment, the step of “calling a second virtual machine of a corresponding contract type through a contract creation interface according to the contract type and the contract name, and creating a second contract” may include:
[0097] Generate a contract address based on the contract name, and obtain the address of the first contract as the caller address;
[0098] Call the contract creation interface and pass the contract type, contract name, contract address, and caller address as parameters to the contract creation interface;
[0099] The second virtual machine of the corresponding contract type is called through the contract creation interface, and the second contract is created.
[0100] For example, after determining the contract name of the second contract, the contract address of the second contract can be generated according to the contract name, and the address of the current first contract is obtained as the caller address, that is, sender, where sender is a blockchain transaction term, referring to the caller or initiator of the current transaction. Then call the contract creation interface, and pass the contract type, contract name, contract address, and caller address as parameters to the contract creation interface. Then call the second virtual machine of the corresponding contract type through the contract creation interface, and create the second contract.
[0101] Optionally, in one embodiment, the step of “calling a second virtual machine corresponding to the contract type through a contract creation interface and creating a second contract” may include:
[0102] Calling a second virtual machine of the corresponding contract type through a contract creation interface;
[0103] Starting a virtual machine instance of a second virtual machine;
[0104] Call the virtual machine instance to create the second contract.
[0105] For example, the second virtual machine corresponding to the contract type can be found according to the contract type passed in as a parameter, and the virtual machine instance of the second virtual machine can be started. Then the virtual machine instance is called to execute the construction method / initialization method of the second contract. After the execution is completed, the second virtual machine can return the execution result of the method to the caller, that is, the information of the second contract that has been created is returned to the caller. If an error occurs during execution, the second virtual machine can return the execution error information to the caller.
[0106] Optionally, in one embodiment, after the step of “calling the contract creation interface and passing the contract type, contract name, contract address, and caller address as parameters into the contract creation interface”, the following may also be included:
[0107] Determine the creation type corresponding to the second contract;
[0108] Based on the creation type, determining the contract creator of the second contract;
[0109] Generate and store contract instances based on the contract name, contract address, contract type, and contract creator.
[0110] For example, when executing the creation of a contract, you must first determine the creation type corresponding to the second contract. If the creation type is user creation, use the sender obtained in the transaction as the contract creator of the second contract; if the creation type is contract creation, use the sender passed by the parameter as the contract creator of the second contract. After determining the contract creator according to the creation type corresponding to the second contract, you need to generate a contract instance and assign the contract name, contract address, contract type, and contract creator to the contract instance.
[0111] Optionally, in one embodiment, the step of “generating and storing a contract instance based on the contract name, contract address, contract type, and contract creator” may include:
[0112] Generate a contract instance based on the contract name, contract address, contract type, and contract creator;
[0113] Store contract instances using contract name and contract address as indexes.
[0114] For example, after determining the contract creator according to the creation type corresponding to the second contract, it is necessary to generate a contract instance and assign the contract name, contract address, contract type, and contract creator to the contract instance. After the contract instance is generated, the contract name and contract address can be used as indexes to store the contract instance, which is convenient for querying and calling the contract in the future.
[0115] Optionally, in one embodiment, the step of “storing the contract instance with the contract name and the contract address as index” may include:
[0116] Use the contract address as the first index to store the contract name;
[0117] Store the contract instance with the contract name as the second index.
[0118] For example, in a blockchain that supports multiple contract types, the virtual machine types supported by the current blockchain can be numbered, such as 1 for solidity type contracts and 2 for wasm type contracts, to ensure the uniqueness of each virtual machine type number. In the blockchain, the contract creation interface can be modified so that the contract creation interface can not only be called by users to create contracts, but also be called by contracts to create contracts. The modified contract creation interface should meet the following standards:
[0119] 1. The contract creation interface parameters include contract name, contract type, contract code, creation type, caller address, etc.;
[0120] 2. The contract creation interface can obtain the current transaction instance, and can obtain the caller address of the transaction from the current transaction instance;
[0121] 3. The contract instance should include the contract name, contract address, contract type, contract code, and contract creator fields.
[0122] After the first virtual machine determines the contract type and contract name of the second contract, the contract address can be generated according to the contract name. Then, according to the offset parameter and size parameter of the contract creation instruction, the contract code for creating the second contract is read from the memory. The address of the current first contract is obtained as the caller address, and the contract creation interface is called, and the contract name, contract address, contract type, contract code, and caller address are passed in as parameters.
[0123] When creating the second contract, first check the creation type of the second contract. If the creation type of the second contract is user creation, use the sender obtained in the transaction as the contract creator; if the creation type of the second contract is contract creation, use the sender passed by the parameter as the contract creator. After determining the contract creator according to the creation type of the second contract, it is necessary to generate a contract instance. The contract name, contract address, contract type, contract code, and contract creator can be assigned to the contract instance.
[0124] After generating a contract instance, you can store the contract instance with the contract name and contract address as keys, respectively, to facilitate future queries and calls to the contract. Considering that the contract code takes up too much storage space, you can store the contract instance with only the contract name as the second index, and only store the contract name with the contract address as the first index. When a user calls a contract through a contract address, he can first get the contract name based on the contract address, and then get the contract instance based on the contract name. Since the contract name is more friendly to memory and input, and more convenient for users to use, this technical solution of directly calling the contract name and indirectly calling the contract address can save execution time and thus improve efficiency.
[0125] In one embodiment, when a developer develops a contract that can create other types of contracts, he can first prepare a byte stream of 32 bytes. Then, the type number corresponding to the contract type of the contract to be created is converted and written into the first byte of the byte stream, and the contract name of the contract to be created is converted and written into the rest of the byte stream. Finally, the assembly syntax can be used to call the contract creation instruction to create the contract. When calling the instruction, the previously prepared byte stream can be passed in as a salt parameter.
[0126] The present application modifies the contract creation instruction of the first virtual machine, establishes a protocol for the salting parameter, uses the first preset bit area of the salting parameter field to record the contract type of the second contract, and uses the second preset bit area of the salting parameter field to record the contract name of the second contract. In this way, when the first virtual machine executes the contract creation instruction, after obtaining the salting parameter from the virtual machine stack, the first preset bit area of the salting parameter field can be read to determine the contract type of the second contract, and the second preset bit area of the salting parameter field can be read to determine the contract name of the second contract. In this way, the first contract can create and execute other types of contracts based on the contract type and contract name.
[0127] The technical solution of the present application enables solidity contracts to create other types of contracts, so that solidity contracts can create contracts other than solidity contracts; a contract name can also be specified for the contract to be created. Compared with the contract address, the contract name is more user-friendly; in addition, the technical solution of the present application can also be fully compatible with the original solidity contract and the Ethereum virtual machine. The solidity contract written based on the modified Ethereum virtual machine can still be executed normally on the original Ethereum virtual machine.
[0128] In addition, the existing technical solutions attempt to establish a universal heterogeneous interaction protocol in various 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 technical solutions is too broad and its feasibility remains to be discussed. The technical solution of this application only creates other types of contracts for solidity contracts. After obtaining the contract type of the contract to be created through the salting parameter of the contract creation instruction, the virtual machine corresponding to the type can be called to create and execute the contract of this type, which is more targeted and certain to implement.
[0129] Secondly, the existing technical solutions insert a common API layer between various virtual machines and world states, which will significantly increase the redundancy of blockchain code. The more types of virtual machines are adapted, the more redundant API code there is, and the more complex the calling interface is. Correspondingly, the interactive performance decreases and the vulnerability risk increases. However, the technical solution of this application only builds a simple two-field protocol in a 32-byte salt parameter, and the parsing and reading logic is simple, with almost no redundant code added, and the performance will not be reduced or the vulnerability risk will be increased due to the increased code complexity.
[0130] Thirdly, the existing technical solution needs to be accompanied by a field to indicate the type of virtual machine declared by the contract, which may cause compatibility issues in some virtual machine types. For example, in the Ethereum virtual machine, the parameters of the contract creation instruction are fixed. If additional fields are attached, it may be necessary to expand the number of parameters of the contract creation instruction, and the solidity compiler must be modified, which will bring compatibility issues and huge security risks. However, this solution only uses the existing salting parameters of the contract creation instruction, without adding additional fields. The salting parameter is one of the generation factors of the created contract address. After modifying the contract creation instruction of the Ethereum virtual machine, the salting parameter can be used to specify the contract type and contract name, but when executed in the Ethereum virtual machine without rewriting the contract creation instruction, the salting parameter assigned with the contract type and contract name can still be used as a generation factor, and its semantics and functions have not changed, but the functions of the contract type and contract name have not been brought into play.
[0131] As can be seen from the above, the present application can execute the first contract through the first virtual machine, and the first contract includes a contract creation instruction; obtain the salt parameter field carried by the contract creation instruction, and parse the first preset bit area of the salt parameter field; if the written value of the first preset bit area meets the predefined type rule, determine the contract type of the second contract, and parse the second preset bit area of the salt parameter field; determine the contract name of the second contract according to the second preset bit area; according to the contract type and the contract name, call the second virtual machine of the corresponding contract type through the contract creation interface, and create the second contract. The present application can expand the salt parameter so that the solidity contract can heterogeneously create other types of contracts, and the implementation method of contract creation is clearer and more specific, thereby avoiding the logical complexity brought about by similar solutions such as adding an intermediate API layer in the prior art, as well as the problems of code redundancy, increased development burden, increased security risks, and decreased user experience extended therefrom. In addition, when creating a contract through a contract, the present application can specify the contract name of the contract to be created. Compared with the technical solution in which the virtual machine automatically creates a contract address for the contract to be created, the user can specify the contract name independently, which can make it more convenient for the user to manage the contract, and the contract name is more user-friendly, thereby improving the usage efficiency and user experience.
[0132] According to the method described in the previous embodiment, the following will be further described in detail by taking the example of the contract creation device being specifically integrated in the server.
[0133] This application embodiment provides a contract creation method, such as Figure 3 As shown, the specific process of the contract creation method can be as follows:
[0134] 301. The first virtual machine reads the salting parameter from the stack through the contract creation instruction.
[0135] For example, in the embodiment of the present application, the first virtual machine can be an EVM virtual machine, the contract creation instruction can be a create2 instruction, and the salting parameter can be a salt parameter. When the developer wants to develop a contract that can create other types of contracts, he can first prepare a byte stream of 32 bytes in length, and then convert the number corresponding to the contract type of the contract to be created, write the converted content to the first byte of the byte stream, and convert the contract name of the contract to be created, and write the converted content to the remaining part of the byte stream except the first byte. Finally, using assembly syntax, call the create2 instruction to create a contract. When calling, the previously prepared byte stream can be passed in as a salt parameter. Then, on the virtual machine side, the create2 instruction of the EVM virtual machine can be transformed, and the salt parameter can be read from the EVM virtual machine stack through the create2 instruction.
[0136] 302. The first virtual machine parses the salting parameter to obtain the contract type and contract address of the contract to be created.
[0137] For example, after reading the salt parameter, you can get the first byte of the salt parameter and convert it into an integer to check whether the integer is within the valid contract type number range. If the integer is not within the valid contract type number range, it means that the check failed, and you can cancel the parsing of the salt parameter and return a message indicating that the parsing of the contract type failed. If the integer is within the valid contract type number range, it means that the check passed, and you can determine the contract type corresponding to the contract to be created based on the number represented by the integer.
[0138] After determining the contract type corresponding to the contract to be created, the remaining bytes of the salt parameter except the first byte can be read and converted into a string. If the conversion fails or the converted string contains garbled characters, the parsing of the salt parameter is canceled, and a message indicating that the parsing of the contract name failed is returned; if the conversion is successful, the converted string is recorded as the contract name of the contract to be created, and a contract address is generated based on the contract name. Among them, the technical solution of this application introduces the contract name for the convenience of users, because the contract name is more readable for users than the contract address, and is easier to remember and write.
[0139] 303. The first virtual machine obtains the contract code and the current contract address.
[0140] For example, the first virtual machine can read the contract code of the contract to be created from the memory according to the offset parameter and size parameter of the create2 instruction, and obtain the address of the current contract as the sender.
[0141] 304. The first virtual machine calls the contract creation interface and passes the contract name, contract address, contract type, contract code, and current contract address as parameters to the call.
[0142] For example, the first virtual machine can call the contract creation interface and pass the contract name, contract address, contract type, contract code, and sender as parameters to the call.
[0143] 305. Determine the creation type of the contract to be created, and determine the contract creator based on the creation type.
[0144] For example, before creating a contract, you can number the contract virtual machine types supported by the current blockchain to ensure the uniqueness of each virtual machine type number. In the blockchain, modify the contract creation interface so that the contract creation interface can not only be called by users to create contracts, but also be called by contracts to create contracts. The modified contract creation interface meets the following standards:
[0145] 1. The contract creation interface parameters include contract name, contract type, contract code, creation type, and sender.
[0146] 2. The contract creation interface can obtain the current transaction instance, and can obtain the sender of the transaction from the transaction instance.
[0147] 3. The contract instance should include the contract name, contract address, contract type, contract code, and contract creator fields.
[0148] When executing contract creation, first check the creation type of the contract to be created. If the creation type is user creation, the sender obtained in the transaction can be used as the contract creator; if the creation type is contract creation, the sender passed by the parameter can be used as the contract creator.
[0149] In one embodiment, after determining the contract creator according to the creation type of the contract to be created, the contract name, contract address, contract type, contract code, and contract creator may be assigned to the contract instance to generate the contract instance. After the contract instance is generated, the contract instance may be stored with the contract name and contract address as keys, respectively, to facilitate future query and call of the contract.
[0150] In addition, considering that the storage space occupied by the contract code is too large, the contract instance can be stored with the contract name as the key, and the contract address as the key, and only the contract name can be stored. In this way, when the user uses the contract address to call the contract, the contract name can be obtained according to the contract address first, and then the contract instance can be obtained according to the contract name. Among them, the contract name is more friendly to memory and input, and more convenient for users to use. This design of direct calling of the contract name and indirect calling of the contract address can save execution time and improve efficiency.
[0151] 306. According to the contract type passed in by the salt parameter, find the corresponding second virtual machine.
[0152] For example, according to the contract type of the contract to be created passed in as the salt parameter, the second virtual machine corresponding to the contract type can be searched, and the virtual machine instance of the second virtual machine can be started.
[0153] 307. The second virtual machine executes an operation of creating a contract.
[0154] For example, the virtual machine instance of the second virtual machine can be called to execute the construction method or initialization method of the contract to be created. After the execution is completed, the execution result can be returned to the caller; if an error occurs during the execution, the error information can also be returned to the caller.
[0155] As can be seen from the above, in this embodiment, the first virtual machine can read the salting parameters from the stack through the contract creation instruction, parse the salting parameters, obtain the contract type and contract address of the contract to be created, obtain the contract code and the current contract address, call the contract creation interface, pass the contract name, contract address, contract type, contract code, and current contract address as parameters to the call, determine the creation type of the contract to be created, and determine the contract creator based on the creation type, find the corresponding second virtual machine according to the contract type passed in by the salting parameters, and perform the contract creation operation through the second virtual machine. The present application can expand the salting parameters so that the solidity contract can heterogeneously create other types of contracts, and the implementation method of contract creation is clearer and more specific, thereby avoiding the logical complexity brought about by similar solutions such as adding an intermediate API layer in the prior art, as well as the problems of code redundancy, increased development burden, increased security risks, and reduced user experience extended therefrom. In addition, when creating a contract through a contract, the present application can specify the contract name of the contract to be created. Compared with the technical solution in which the virtual machine automatically creates a contract address for the contract to be created, the user can specify the contract name independently, which can make it more convenient for the user to manage the contract, and the contract name is more user-friendly, thereby improving the usage efficiency and user experience.
[0156] In order to better implement the above method, the present application embodiment also provides a contract creation device, such as Figure 7 As shown, the contract creation device may include an execution unit 701, an acquisition unit 702, a first determination unit 703, a second determination unit 704, and a creation unit 705, as follows:
[0157] An execution unit 701 is configured to execute a first contract through a first virtual machine, wherein the first contract includes a contract creation instruction;
[0158] An acquisition unit 702 is used to acquire a salt parameter field carried by the contract creation instruction and parse a first preset bit area of the salt parameter field;
[0159] A first determining unit 703 is configured to determine the contract type of the second contract if the written value of the first preset bit area meets the predefined type rule, and parse the second preset bit area of the salt parameter field;
[0160] A second determining unit 704, configured to determine a contract name of the second contract according to the second preset bit region;
[0161] The creation unit 705 is used to call the second virtual machine corresponding to the contract type through the contract creation interface according to the contract type and the contract name, and create the second contract.
[0162] Optionally, in some embodiments of the present application, the first determination unit can be specifically used to perform a first byte conversion on the written value of the first preset bit area to obtain a first written value if the written value of the first preset bit area meets a predefined type rule; determine the contract type of the second contract based on the first written value; and parse the second preset bit area of the salt parameter field.
[0163] Optionally, in some embodiments of the present application, the second determination unit can be specifically used to obtain the write value of the second preset bit area; perform a second byte conversion on the write value of the second preset bit area to obtain a second write value; and determine the contract name of the second contract based on the second write value.
[0164] Optionally, in some embodiments of the present application, the creation unit may include an acquisition subunit, a call subunit, and a creation subunit, as follows:
[0165] The acquisition subunit is used to generate a contract address based on the contract name, and obtain the address of the first contract as the caller address;
[0166] The calling subunit is used to call the contract creation interface and pass the contract type, contract name, contract address, and caller address as parameters into the contract creation interface;
[0167] The creation subunit is used to call the second virtual machine corresponding to the contract type through the contract creation interface and create the second contract.
[0168] Optionally, in some embodiments of the present application, the creation sub-unit can be specifically used to call a second virtual machine corresponding to the contract type through the contract creation interface; start a virtual machine instance of the second virtual machine; call the virtual machine instance to create the second contract.
[0169] Optionally, in some embodiments of the present application, the calling subunit may include a first determining subunit, a second determining subunit, and a generating subunit, as follows:
[0170] The first determining subunit is used to determine the creation type corresponding to the second contract;
[0171] The second determining subunit is used to determine a contract creator of the second contract based on the creation type;
[0172] The generation subunit is used to generate and store a contract instance based on the contract name, the contract address, the contract type, and the contract creator.
[0173] Optionally, in some embodiments of the present application, the generation subunit can be specifically used to generate a contract instance based on the contract name, the contract address, the contract type, and the contract creator; and store the contract instance with the contract name and the contract address as indexes.
[0174] Optionally, in some embodiments of the present application, the generation subunit can be specifically used to store the contract name with the contract address as the first index; and store the contract instance with the contract name as the second index.
[0175] As can be seen from the above, in this embodiment, the execution unit 701 can execute the first contract through the first virtual machine, and the first contract includes a contract creation instruction; the acquisition unit 702 acquires the salt parameter field carried by the contract creation instruction, and parses the first preset bit area of the salt parameter field; if the written value of the first preset bit area meets the predefined type rule, the first determination unit 703 determines the contract type of the second contract, and parses the second preset bit area of the salt parameter field; the second determination unit 704 determines the contract name of the second contract according to the second preset bit area; the creation unit 705 calls the second virtual machine of the corresponding contract type through the contract creation interface according to the contract type and the contract name, and creates the second contract. The present application can expand the salt parameter so that the solidity contract can heterogeneously create other types of contracts, and the implementation method of contract creation is clearer and more specific, thereby avoiding the logical complexity brought about by similar solutions such as adding an intermediate API layer in the prior art, as well as the problems of code redundancy, increased development burden, increased security risks, and reduced user experience extended therefrom. In addition, when creating a contract through a contract, the present application can specify the contract name of the contract to be created. Compared with the technical solution in which the virtual machine automatically creates a contract address for the contract to be created, the user can specify the contract name independently, which can make it more convenient for the user to manage the contract, and the contract name is more user-friendly, thereby improving the usage efficiency and user experience.
[0176] The present application also provides an electronic device, such as Figure 8 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:
[0177] The electronic device may include components such as a processor 801 with one or more processing cores, a memory 802 with one or more computer-readable storage media, a power supply 803, and an input unit 804. Those skilled in the art will appreciate that Figure 8 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.
[0178] The processor 801 is the control center of the electronic device, which uses various interfaces and lines to connect various parts of the entire electronic device, and executes various functions of the electronic device and processes data by running or executing software programs and / or modules stored in the memory 802, and calling data stored in the memory 802. Optionally, the processor 801 may include one or more processing cores; preferably, the processor 801 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 801.
[0179] The memory 802 can be used to store software programs and modules. The processor 801 executes various functional applications and data processing by running the software programs and modules stored in the memory 802. The memory 802 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 802 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 802 may also include a memory controller to provide the processor 801 with access to the memory 802.
[0180] The electronic device also includes a power supply 803 for supplying power to each component. Preferably, the power supply 803 can be logically connected to the processor 801 through a power management system, so as to manage charging, discharging, power consumption and other functions through the power management system. The power supply 803 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.
[0181] The electronic device may further include an input unit 804, 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.
[0182] 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 801 in the electronic device will load the executable file corresponding to the process of one or more application programs into the memory 802 according to the following instructions, and the processor 801 will run the application program stored in the memory 802, thereby realizing various functions, as follows:
[0183] A first contract can be executed through a first virtual machine, where the first contract includes a contract creation instruction; a salt parameter field carried by the contract creation instruction is obtained, and a first preset bit area of the salt parameter field is parsed; if a written value of the first preset bit area meets a predefined type rule, a contract type of a second contract is determined, and a second preset bit area of the salt parameter field is parsed; a contract name of the second contract is determined according to the second preset bit area; and according to the contract type and the contract name, a second virtual machine of the corresponding contract type is called through a contract creation interface, and a second contract is created.
[0184] The specific implementation of the above operations can be found in the previous embodiments, which will not be described in detail here.
[0185] As can be seen from the above, this embodiment can execute the first contract through the first virtual machine, and the first contract includes a contract creation instruction; obtain the salt parameter field carried by the contract creation instruction, and parse the first preset bit area of the salt parameter field; if the written value of the first preset bit area meets the predefined type rule, determine the contract type of the second contract, and parse the second preset bit area of the salt parameter field; determine the contract name of the second contract according to the second preset bit area; according to the contract type and the contract name, call the second virtual machine of the corresponding contract type through the contract creation interface, and create the second contract. The present application can expand the salt parameter so that the solidity contract can heterogeneously create other types of contracts, and the implementation method of contract creation is clearer and more specific, thereby avoiding the logical complexity brought about by similar solutions such as adding an intermediate API layer in the prior art, as well as the problems of code redundancy, increased development burden, increased security risks, and reduced user experience extended therefrom. In addition, when creating a contract through a contract, the present application can specify the contract name of the contract to be created. Compared with the technical solution in which the virtual machine automatically creates a contract address for the contract to be created, the user can specify the contract name independently, which can make it more convenient for the user to manage the contract, and the contract name is more user-friendly, thereby improving the usage efficiency and user experience.
[0186] 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.
[0187] To this end, an embodiment of the present application provides a computer-readable storage medium, in which a plurality of instructions are stored, and the instructions can be loaded by a processor to execute the steps in any of the contract creation methods provided in the embodiments of the present application. For example, the instructions can execute the following steps:
[0188] A first contract can be executed through a first virtual machine, where the first contract includes a contract creation instruction; a salt parameter field carried by the contract creation instruction is obtained, and a first preset bit area of the salt parameter field is parsed; if a written value of the first preset bit area meets a predefined type rule, a contract type of a second contract is determined, and a second preset bit area of the salt parameter field is parsed; a contract name of the second contract is determined according to the second preset bit area; and according to the contract type and the contract name, a second virtual machine of the corresponding contract type is called through a contract creation interface, and a second contract is created.
[0189] The specific implementation of the above operations can be found in the previous embodiments, which will not be described in detail here.
[0190] 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.
[0191] Since the instructions stored in the computer-readable storage medium can execute the steps in any one of the contract creation methods provided in the embodiments of the present application, the beneficial effects that can be achieved by any one of the contract creation methods 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.
[0192] 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 method provided in various optional implementations of the above-mentioned contract creation aspect.
[0193] The above is a detailed introduction to a contract creation 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 creation method, characterized in that: include: Executing a first contract by a first virtual machine, wherein the first contract includes a contract creation instruction; Obtain the salt parameter field carried by the contract creation instruction, and parse the first preset bit area of the salt parameter field; If the written value of the first preset bit area meets the predefined type rule, determine the contract type of the second contract, and parse the second preset bit area of the salt parameter field; Determining a contract name of the second contract according to the second preset bit area; According to the contract type and the contract name, a second virtual machine corresponding to the contract type is called through a contract creation interface, and the second contract is created.
2. The contract creation method according to claim 1, characterized in that: If the written value of the first preset bit area meets the predefined type rule, determining the contract type of the second contract, and parsing the second preset bit area of the salt parameter field, includes: If the written value of the first preset bit area meets the predefined type rule, performing a first byte conversion on the written value of the first preset bit area to obtain a first written value; Determining a contract type of a second contract based on the first written value; Parse a second preset bit region of the salting parameter field.
3. The contract creation method according to claim 1, characterized in that: The determining the contract name of the second contract according to the second preset bit area includes: Obtaining a written value of the second preset bit area; Performing a second byte conversion on the written value of the second preset bit area to obtain a second written value; Based on the second written value, a contract name of the second contract is determined.
4. The contract creation method according to claim 1, characterized in that: The step of calling a second virtual machine corresponding to the contract type through a contract creation interface according to the contract type and the contract name, and creating the second contract includes: Generate a contract address based on the contract name, and obtain the address of the first contract as the caller address; Call the contract creation interface and pass the contract type, contract name, contract address, and caller address as parameters to the contract creation interface; The second virtual machine corresponding to the contract type is called through the contract creation interface, and the second contract is created.
5. The contract creation method according to claim 4, characterized in that: The calling of the second virtual machine corresponding to the contract type through the contract creation interface and creating the second contract includes: Calling a second virtual machine corresponding to the contract type through the contract creation interface; Starting a virtual machine instance of the second virtual machine; Call the virtual machine instance to create the second contract.
6. The contract creation method according to claim 4, characterized in that: After calling the contract creation interface and passing the contract type, contract name, contract address, and caller address as parameters into the contract creation interface, the following further includes: Determine the creation type corresponding to the second contract; Based on the creation type, determining a contract creator of the second contract; Generate and store a contract instance based on the contract name, the contract address, the contract type, and the contract creator.
7. The contract creation method according to claim 6, characterized in that: The generating and storing a contract instance based on the contract name, the contract address, the contract type, and the contract creator includes: Generate a contract instance based on the contract name, the contract address, the contract type, and the contract creator; The contract instance is stored using the contract name and the contract address as indexes.
8. The contract creation method according to claim 7, characterized in that: The storing of the contract instance by using the contract name and the contract address as indexes includes: Using the contract address as the first index, storing the contract name; The contract instance is stored using the contract name as a second index.
9. A contract creation device, characterized in that: include: An execution unit, configured to execute a first contract through a first virtual machine, wherein the first contract includes a contract creation instruction; An acquisition unit, used to acquire a salt parameter field carried by the contract creation instruction, and parse a first preset bit area of the salt parameter field; A first determining unit, configured to determine the contract type of the second contract if the written value of the first preset bit area meets the predefined type rule, and parse the second preset bit area of the salt parameter field; A second determining unit, configured to determine a contract name of the second contract according to the second preset bit region; A creation unit is used to call a second virtual machine corresponding to the contract type through a contract creation interface according to the contract type and the contract name, and create the second contract.
10. An electronic device, characterized in that: It comprises a memory and a processor; the memory stores an application, and the processor is used to run the application in the memory to perform the operations in the contract creation method described in any one of claims 1 to 8.
11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a plurality of instructions, which are suitable for being loaded by a processor to execute the steps in the contract creation method described in any one of claims 1 to 8.
12. 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 creation method described in any one of claims 1 to 8 are implemented.
