Decentralized application-oriented intelligent contract program generation method

Abstract

The invention discloses a decentralized application-oriented smart contract program generation method, device and equipment and a storage medium, and belongs to the field of block chain smart contracts, and the method comprises the steps of persisting an executable code and state data of a fragmented smart contract in block data; in response to a calling instruction for the fragmented smart contract, extracting the executable code and the state data persisted in the block data to execute the fragmented smart contract, and updating the state data persisted in the block data according to execution of the fragmented smart contract; and in response to a reconstruction instruction for the fragment smart contract in execution, extracting persistent executable codes and state data from the block data, and reconstructing the fragment smart contract in execution through the extracted executable codes and state data. The problems of complex cross-fragment calling, low execution speed and difficult fault recovery of the smart contract are solved, and the performance and stability of the block chain system in decentralized application processing are improved.

Description

Technical Field

[0001] The present application belongs to the field of blockchain smart contracts, and specifically relates to a method, device, equipment and storage medium for generating smart contract programs for decentralized applications. Background Art

[0002] With the development of blockchain technology, more and more decentralized applications are developed and deployed based on blockchain platforms. Decentralized applications use smart contracts to implement distributed trust mechanisms to ensure the transparency and immutability of transactions. Smart contracts exist in the form of code on the blockchain and can automatically execute predetermined logical operations.

[0003] In order to improve the performance of the blockchain system, the existing technology has proposed blockchain sharding technology. Blockchain sharding technology divides the entire blockchain network into several sub-blockchains (shards) running in parallel, and each shard is responsible for processing a part of the transactions, thereby improving the transaction throughput of the overall system.

[0004] However, although the existing smart contract sharding technology can improve the transaction throughput of the blockchain system to a certain extent, the complexity and inefficiency of cross-shard calls of smart contracts lead to slow transaction execution and affect the response speed of decentralized applications. At the same time, since the smart contract calling mechanism in the existing technology needs to specify the shards involved at runtime, it is impossible to prepare in advance when submitting transactions, which increases the risk of errors. Summary of the invention

[0005] The present application aims to provide a method, apparatus, device and storage medium for generating a smart contract program for decentralized applications, which at least solves the problem of slow response of smart contract calls in sharded blockchains.

[0006] In a first aspect, the present application embodiment discloses a method for generating a smart contract program for decentralized applications, including: Persisting the executable code and state data of the sharded smart contract in block data respectively; the block data corresponds to the network shard where the sharded smart contract is located; In response to a call instruction to the shard smart contract, extract the executable code and state data persisted in the block data to execute the shard smart contract, and update the state data persisted in the block data according to the execution of the shard smart contract; In response to a reconstruction instruction for the executing shard smart contract, the persistent executable code and state data are extracted from the block data, and the executing shard smart contract is reconstructed using the extracted executable code and state data.

[0007] In a second aspect, the present application embodiment further discloses a method for generating a smart contract program for decentralized applications, including: A persistence module, used to persist the executable code and state data of the sharded smart contract in block data respectively; the block data corresponds to the network shard where the sharded smart contract is located; An execution module, configured to extract executable code and state data persisted in the block data in response to a call instruction to the shard smart contract, so as to execute the shard smart contract, and update the state data persisted in the block data according to the execution of the shard smart contract; A reconstruction module is used to extract persistent executable code and status data from the block data in response to a reconstruction instruction for the executing shard smart contract, and to reconstruct the executing shard smart contract through the extracted executable code and status data.

[0008] In a third aspect, an embodiment of the present application further discloses an electronic device, comprising a processor and a memory, wherein the memory stores programs or instructions that can be run on the processor, and when the program or instructions are executed by the processor, the steps of the method described in the first aspect are implemented.

[0009] In a fourth aspect, an embodiment of the present application further discloses a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the steps of the method described in the first aspect are implemented.

[0010] In summary, in the embodiments of the present application, by persisting the executable code and status data of the sharded smart contract in the block data, the stable existence of the code and status data of the smart contract in the shard is ensured, and data loss caused by node failure or network fluctuation is avoided. At the same time, the persistent executable code and status data enable the smart contract to be quickly extracted and executed in the shard, thereby improving the robustness and data security of the system; and by extracting the persistent executable code and status data from the block data after receiving the call instruction for the sharded smart contract to execute the smart contract, the code and status data of the smart contract do not need to be obtained from the outside, thereby reducing the delay in the calling process, and at the same time, according to the execution of the smart contract, the persistent status data is updated, so that the status of the smart contract can be updated in time after each call, thereby ensuring the consistency and reliability of the data; further, by extracting the persistent executable code and status data from the block data, the executing smart contract is rebuilt, and its status and function can be quickly rebuilt, thereby improving the availability and stability of the system. Therefore, based on the method of the embodiment of the present application, by persistently storing the executable code and state data of the smart contract in the block data, the smart contract state can be efficiently extracted and restored during the call and reconstruction process, reducing the complexity and inefficiency of cross-shard calls of smart contracts, improving the response speed of smart contract calls, enhancing the performance and user experience of decentralized applications, and at the same time reducing data loss and downtime caused by failures, and improving the stability and reliability of the system. The problems of complex cross-shard calls, slow execution speed and difficult fault recovery of smart contracts in the prior art are solved, and the performance and stability of the blockchain system when processing decentralized applications are improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In the attached picture: Figure 1 It is a flowchart of a method for generating a smart contract program for decentralized applications provided in an embodiment of the present application; Figure 2 This is another method for generating a smart contract program for decentralized applications provided in an embodiment of the present application; Figure 3 It is the interactive process of the asynchronous call mechanism provided by the embodiment of the present application; Figure 4 It is the merging process of the sequencer provided in the embodiment of the present application; Figure 5 It is a process of executing an asynchronous call according to the sequencer provided in the embodiment of the present application; Figure 6 It is a data interaction process provided according to an embodiment of the present application; Figure 7It is a block diagram of a smart contract program generation device for decentralized applications provided in an embodiment of the present application; Figure 8 is a block diagram of an electronic device according to an embodiment of the present application; Fig. 9 It is a block diagram of an electronic device of another embodiment provided by the embodiments of the present application. DETAILED DESCRIPTION

[0012] 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 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 ordinary technicians in this field without creative work are within the scope of protection of this application.

[0013] The terms "first", "second", etc. in the specification and claims of the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described here, and the objects distinguished by "first", "second", etc. are generally of one type, and the number of objects is not limited. For example, the first object can be one or more. In addition, "and / or" in the specification and claims represents at least one of the connected objects, and the character " / " generally indicates that the objects associated with each other are in an "or" relationship.

[0014] Figure 1 This is a method for generating a smart contract program for decentralized applications provided in this embodiment.

[0015] The method may include the following steps: Step 101, respectively persist the executable code and status data of the sharded smart contract in the block data.

[0016] Among them, the block data corresponds to the network shard where the shard smart contract is located.

[0017] In some embodiments of the present application, the executable code and status data of the smart contract are respectively persisted in the block data. Persistence refers to the permanent storage of data in a storage system to ensure that the data will not be lost due to system failure or restart. Block data refers to the data stored in each block in the blockchain network, including transaction records, status information, etc. In this step, by persisting the executable code and status data of the smart contract in the block data, the stable existence of the smart contract in the shard is ensured. This process protects the data of the smart contract in the blockchain network and avoids data loss due to node failure or network fluctuations. In addition, such persistent storage also improves the execution efficiency of smart contracts in shards, because smart contracts can be quickly extracted from block data when they need to be called.

[0018] For example, in the blockchain sharding technology based on smart contracts, developers design a decentralized application that contains multiple smart contracts. The code and state data of each smart contract need to be persistently stored in the shard. Suppose there is a smart contract A, whose code and state data are persisted to the block data when deployed. Specifically, the code of smart contract A may include a function for processing transactions, and its state data may include the current account balance, transaction history, etc. In the sharding network, the code and state data of smart contract A are stored in a block of the blockchain. During the operation of the system, even if a node fails or the network fluctuates, since the code and state data of smart contract A have been persistently stored in the block data, the system can still quickly restore the code and state of smart contract A from other nodes to ensure the stability and availability of smart contract A.

[0019] Step 102, in response to the call instruction of the sharding smart contract, extract the executable code and state data persisted in the block data to execute the sharding smart contract, and update the state data persisted in the block data according to the execution of the sharding smart contract.

[0020] In some embodiments of the present application, the system will respond to the call instruction of the sharded smart contract and extract the persistent executable code and state data from the block data to execute the smart contract. This means that when a smart contract call request arrives, the system will load the code and state of the smart contract from the pre-persistently stored block data in order to execute the smart contract. During the execution process, the code of the smart contract runs according to the parameters in the call instruction and operates on the state data of the contract. After the execution is completed, the system will persist the updated state data to the block data again, thereby ensuring that the latest state of the smart contract is saved. This process reduces the delay in the smart contract call process and ensures the consistency and reliability of the smart contract state.

[0021] For example, suppose there is a smart contract B whose function is to process the user's transfer request. The user sends a transfer request to the shard network through the client, which triggers the call to smart contract B. After receiving the call instruction, the system extracts the executable code and current status data (such as account balance, etc.) of smart contract B from the block data. Smart contract B executes the transfer operation, deducts the transfer amount in the call instruction from the sender's account, and adds it to the receiver's account. After the execution is completed, the status data of smart contract B (i.e., account balance) is updated and re-persisted in the block data. This mechanism ensures the efficient execution of transfer operations and data consistency, and can quickly respond to user operation requests even in high concurrency.

[0022] Step 103, in response to the reconstruction instruction of the executing shard smart contract, extract the persistent executable code and state data from the block data, and rebuild the executing shard smart contract through the extracted executable code and state data.

[0023] In some embodiments of the present application, when the system receives a reconstruction instruction for a sharded smart contract in execution, it extracts the persistent executable code and status data from the block data, and then uses the extracted data to rebuild the sharded smart contract in execution. The reconstruction instruction can be triggered when a failure or anomaly occurs during the execution of the smart contract, or it can be actively issued during system upgrades or maintenance. By extracting the persistent executable code and status data from the block data, it is ensured that the reconstruction process of the smart contract can be restored to the previous execution state, avoiding data loss and execution interruption. The reconstructed smart contract can continue to execute from the last interruption, improving the availability and stability of the system.

[0024] For example, suppose that in a decentralized application, smart contract C is processing a complex transaction. During the transaction execution, the system encounters an unexpected failure, which causes the execution of smart contract C to be interrupted. After receiving the reconstruction instruction, the system extracts the executable code of smart contract C and the state data saved during its execution from the block data. With these extracted data, the system reloads smart contract C to restore it to the state before the failure. Then, smart contract C continues to execute the remaining transaction operations and finally completes the entire transaction process. In this way, although the system fails in the middle, due to the existence of the reconstruction mechanism, the transaction can be successfully completed, ensuring the stable operation of the decentralized application and the consistency of the data.

[0025] In summary, in the embodiments of the present application, by persisting the executable code and status data of the sharded smart contract in the block data, the stable existence of the code and status data of the smart contract in the shard is ensured, and data loss caused by node failure or network fluctuation is avoided. At the same time, the persistent executable code and status data enable the smart contract to be quickly extracted and executed in the shard, thereby improving the robustness and data security of the system; and by extracting the persistent executable code and status data from the block data after receiving the call instruction for the sharded smart contract to execute the smart contract, the code and status data of the smart contract do not need to be obtained from the outside, thereby reducing the delay in the calling process, and at the same time, according to the execution of the smart contract, the persistent status data is updated, so that the status of the smart contract can be updated in time after each call, thereby ensuring the consistency and reliability of the data; further, by extracting the persistent executable code and status data from the block data, the executing smart contract is rebuilt, and its status and function can be quickly rebuilt, thereby improving the availability and stability of the system. Therefore, based on the method of the embodiment of the present application, by persistently storing the executable code and state data of the smart contract in the block data, the smart contract state can be efficiently extracted and restored during the call and reconstruction process, reducing the complexity and inefficiency of cross-shard calls of smart contracts, improving the response speed of smart contract calls, enhancing the performance and user experience of decentralized applications, and at the same time reducing data loss and downtime caused by failures, and improving the stability and reliability of the system. The problems of complex cross-shard calls, slow execution speed and difficult fault recovery of smart contracts in the prior art are solved, and the performance and stability of the blockchain system when processing decentralized applications are improved.

[0026] Figure 2 This is another method for generating a smart contract program for decentralized applications provided in an embodiment of the present application.

[0027] The method may include the following steps: Step 201, generate a deployment plan for the sharded smart contract based on the executable code of the sharded smart contract, or obtain a deployment plan for the sharded smart contract based on the deployment operation of the sharded smart contract code.

[0028] Among them, the deployment plan has corresponding network sharding nodes; the network sharding nodes are used to call and execute sharding smart contracts.

[0029] In some embodiments of the present application, the system will generate a corresponding deployment plan based on the executable code of the sharded smart contract. A deployment plan refers to the specific plan and steps for deploying the smart contract code into the network shard. Generating a deployment plan can be an automatic process or can be obtained based on the developer's deployment operation. Specifically, the deployment plan includes the allocation of network shard nodes, which will be responsible for executing the call and processing of the sharded smart contract. By generating or obtaining a deployment plan, the system ensures that the smart contract can run on the correct shard node, providing a stable and efficient execution environment.

[0030] For example, suppose there is a decentralized application that needs to deploy smart contract D in the blockchain network. The executable code of smart contract D has been written. The system generates a deployment plan based on the executable code of smart contract D. The deployment plan specifies which network shard nodes smart contract D will be deployed to. Each node will hold the code and state data of smart contract D and will be responsible for performing the corresponding operations when receiving a call instruction. By generating this deployment plan, the system ensures that smart contract D can balance the load on multiple nodes, improve execution efficiency and system stability. Users can optimize execution performance by specifying the resource configuration of certain nodes during the deployment process, further improving the user experience of decentralized applications.

[0031] In some embodiments of the present application, the situation where a smart contract synchronously calls another smart contract is called a dependency relationship between contracts, that is, the caller depends on the callee. In order to support synchronous calls between smart contracts, it is necessary to analyze the dependencies between contracts and merge the smart contract shards with dependencies. The use of smart contracts by decentralized applications can be divided into three modes: The leader-member model is a common usage model in decentralized applications. In this model, the smart contract call transaction starts with an entry smart contract (called the leader), and then calls other smart contracts (members). Therefore, in decentralized applications with the leader-member model, smart contract calls usually have a deeper call stack. In the leader-member model, the leader smart contract is obviously dependent on the member smart contracts. When deploying, the member smart contracts must be deployed and configured on the same batch of nodes first, and then the leader smart contract must be deployed and configured to enable the decentralized application to run normally.

[0032] The equal mode is the simplest of the three usage modes. Developers deploy multiple smart contracts and then integrate their functions on the front end. Therefore, there is no need to perform special processing on the decentralized applications in the equal mode. They can be deployed as ordinary decentralized applications supported by a single smart contract.

[0033] The factory pattern is quite special, consisting of a factory smart contract and a series of product smart contracts. Developers first deploy the factory smart contract, and then generate several similar product smart contracts by calling the factory smart contract. Because the product smart contract is generated by the call of the factory smart contract, the factory smart contract usually has full control over the product smart contract. Although no usage pattern was created for the case where there are smart contracts created by smart contract accounts and calls between smart contracts in the empirical analysis, and no such cases were found in the data analysis, if the factory smart contract also has control requirements for the product smart contract, it must also be supported by calls between smart contracts. Therefore, it can be considered that the factory smart contract depends on the product smart contract. When deploying a decentralized application that conforms to the factory pattern, first deploy the factory smart contract. Later, when calling the factory smart contract, deploy the product smart contract and the factory smart contract on the same batch of nodes and merge their transaction sequencers.

[0034] Since the dependencies between contracts in the above three modes are different, it is necessary to classify and discuss these three modes. Table 1 summarizes the deployment schemes of decentralized applications that meet the three different usage modes: Table 1- Deployment scheme of decentralized applications supported by smart contracts

[0035] Step 202: deploy the shard smart contract in the network shard node corresponding to the shard smart contract according to the deployment plan.

[0036] In some embodiments of the present application, the system will deploy the sharded smart contract to the corresponding network shard nodes according to the previously generated deployment plan. The deployment process includes transferring the executable code and initial state data of the smart contract to the specified shard nodes and performing necessary initialization operations on these nodes. By deploying the smart contract to multiple shard nodes, the distributed operation of the smart contract in the network is ensured, thereby improving the execution efficiency of the smart contract and the fault tolerance of the system.

[0037] For example, based on the deployment plan generated previously, smart contract D needs to be deployed in some network shard nodes. According to the deployment plan, the system sends the executable code and initial state data of smart contract D to the network shard nodes and performs initialization operations on these nodes. The specific operations include creating an instance of smart contract D on each node, loading the code of the smart contract, and persistently storing the initial state data in the block data. Through such deployment, smart contract D runs simultaneously on multiple nodes, can efficiently process call requests from users, and improve the overall performance and reliability of the system.

[0038] Step 203, respectively persist the executable code and state data of the sharded smart contract in the block data; the block data corresponds to the network shard where the sharded smart contract is located.

[0039] The method shown in this step has been explained in step 101 and will not be repeated here.

[0040] Optionally, step 203 includes the following sub-steps: Sub-step 2031, compile the source code of the sharded smart contract to obtain executable code, and persist the compiled executable code in the block data.

[0041] In some embodiments of the present application, the system compiles the source code of the sharded smart contract to generate executable code. Compilation refers to the process of converting source code written in a high-level programming language into binary code that can be directly executed by a machine. The compiled executable code can be run directly on the nodes of the blockchain network to execute the logical operations of the smart contract. After the executable code is generated, the system stores it persistently in the block data. Persistent storage refers to permanently saving data in a storage system to ensure that the data is not lost due to system failure or restart. By persisting the compiled executable code in the block data, the system ensures the stable existence of the smart contract code in the shard and can be quickly loaded and executed when needed.

[0042] For example, a developer writes a smart contract F, which is used to implement the functions of a decentralized trading market. The source code of smart contract F is written in a high-level programming language, and contains logic such as defining trading rules and processing trading requests. The system will compile the source code of smart contract F and convert it into executable code in binary form. After compilation, the system will persist the executable code of smart contract F in the block data. In this way, when a node in the network needs to execute smart contract F, it can directly load and run the executable code of the contract from the block data, which improves the efficiency and stability of smart contract execution.

[0043] Sub-step 2032, based on the execution of the initialization code in the persistent executable code, obtain the initial state data of the sharded smart contract, and persist the initial state data in the block data.

[0044] In some embodiments of the present application, the system will execute the smart contract according to the initialization code in the persistent executable code to obtain the initial state data of the sharded smart contract. The initialization code refers to the code logic used by the smart contract to set the initial state when it is deployed, such as defining initial variable values, allocating initial resources, etc. By executing the initialization code, the system can generate the initial state data of the smart contract, which reflects the state of the smart contract when it is just deployed. After the initialization is completed, the system will store these initial state data persistently in the block data to ensure that the initial state data of the smart contract is protected in the blockchain network and can be quickly restored when needed.

[0045] For example, assume that in the previous step, the executable code of smart contract F has been persistently stored in the block data. The initialization code of smart contract F includes logic such as setting the initial account balance and defining transaction limits. The system executes the initialization code of smart contract F and generates initial state data, such as user A's initial balance of 100 tokens, user B's initial balance of 50 tokens, and the transaction limit of a maximum transfer of 10 tokens per time. After execution, these initial state data are persistently stored in the block data. In this way, the initial state data of smart contract F is saved in the blockchain network, ensuring that the initial state of the smart contract can be quickly restored and executed on any node.

[0046] Step 204, in response to the call instruction of the sharding smart contract, extract the executable code and state data persisted in the block data to execute the sharding smart contract, and update the state data persisted in the block data according to the execution of the sharding smart contract.

[0047] The method shown in this step has been explained in step 102 and will not be repeated here.

[0048] Optionally, the calling instruction includes a synchronous calling instruction. In order to respond to the calling instruction of the sharded smart contract, the executable code and state data persisted in the block data are extracted to execute the sharded smart contract. Step 204 includes the following sub-steps: Sub-step 2041, when the calling instruction is a synchronous calling instruction, obtain the executable code of the sharding smart contract recorded in the synchronous calling instruction from the synchronous calling instruction.

[0049] In some embodiments of the present application, when the call instruction is a synchronous call instruction, the system obtains the executable code of the sharded smart contract from the synchronous call instruction. The synchronous call instruction refers to an instruction that directly triggers the execution of the smart contract, requiring the smart contract to be executed immediately in the same transaction and return the result. By extracting the executable code from the synchronous call instruction, the system can ensure that the accurate code version is used when making a smart contract call and reduce the delay in the call process. The obtained executable code will be used in the subsequent smart contract execution steps.

[0050] For example, in a decentralized financial application, a user sends a synchronous call instruction to query the current account balance of a smart contract H. The synchronous call instruction records the executable code and related information of smart contract H. After receiving the instruction, the system first parses the synchronous call instruction and extracts the executable code of smart contract H from it. This code contains the logic for calculating and returning the current account balance. By extracting this executable code, the system is prepared for the subsequent execution of smart contract H, ensuring that the call can be carried out efficiently and accurately.

[0051] Sub-step 2042, extracts the target function code in the executable code according to the function name of the target function code in the executable code recorded in the synchronous call instruction, and extracts the target parameter in the executable code according to the parameter name of the target parameter in the executable code recorded in the synchronous call instruction.

[0052] In some embodiments of the present application, the system will extract the target function code in the executable code according to the function name of the target function code recorded in the synchronous call instruction. At the same time, the system also extracts the target parameter in the executable code according to the parameter name of the target parameter recorded in the synchronous call instruction. The target function code refers to a specific logical function in the smart contract, which implements a specific operation or calculation. The target parameter is the input value passed to the target function and is used for logical operations when the function is executed. By extracting the target function code and target parameters, the system can accurately locate and execute specific logic in the smart contract, ensuring the accuracy and efficiency of the calling process.

[0053] For example, in a decentralized application, a user sends a synchronous call instruction to query the transaction history of a smart contract I. The synchronous call instruction contains the function name of the target function code "getTransactionHistory" of smart contract I and the parameter name of the target parameter "accountID". After receiving the instruction, the system extracts the "getTransactionHistory" function code from the executable code, which defines how to retrieve the transaction history. Then, the system extracts the actual parameter value, such as "accountID=12345", based on the "accountID" parameter name recorded in the synchronous call instruction. By obtaining these target function codes and parameters, the system can execute the "getTransactionHistory" function in smart contract I and return the transaction history of the specified account, ensuring the accuracy and efficiency of the query operation.

[0054] Sub-step 2043, executing the target parameters according to the target function code.

[0055] In some embodiments of the present application, the system will execute the smart contract according to the target function code and target parameters extracted previously. Specifically, the system calls the target function code and passes the extracted target parameters as input to the function. This process ensures that the smart contract is executed according to the predetermined logic and completes the corresponding operations or calculations based on the input parameters. The results of the execution process will be generated and may be returned to the caller, or the status data of the smart contract will be updated. By executing the target function code, the logic of the smart contract can be correctly triggered in the system to complete the expected function.

[0056] For example, in a decentralized application, a user sends a synchronous call instruction to query the account balance of a smart contract J. In the previous step, the system has extracted the target function code "getBalance" and the target parameter "accountID=67890" from the synchronous call instruction. In sub-step 2043, the system calls the "getBalance" function and passes "accountID=67890" as an input parameter to the function. The target function "getBalance" performs a balance query operation based on the provided account ID and returns the balance information of the corresponding account. The system returns the query result to the user, completing the smart contract call operation. Through such an execution process, the system ensures the accurate call of the smart contract and the realization of the expected function.

[0057] like Figure 3As shown, in some embodiments of the present application, an asynchronous call mechanism is introduced to separate the changes in status on different shards, so that the changes in the status of other shards involved in the transaction are delayed, reducing the complexity of the cross-shard call mechanism of the smart contract and improving the success rate. The asynchronous call request will be identified in the process of the execution unit executing the transaction. No matter how many asynchronous call transactions are performed, they will be returned to the contract manager along with the return of the execution result if the transaction is successfully executed. For each inter-contract asynchronous call request, the contract manager will use the key pair of the smart contract to sign and publish a new smart contract call transaction, and then call the new transaction. If this inter-contract asynchronous call request contains a callback to the caller's smart contract method, the called smart contract will create another smart contract call transaction to execute the callback after the execution is completed. Based on the above process, for the asynchronous call instruction, there is the following process: Optionally, the calling instruction includes an asynchronous calling instruction. In order to respond to the calling instruction of the sharded smart contract, the executable code and state data persisted in the block data are extracted to execute the sharded smart contract. Step 204 includes the following sub-steps: Sub-step 2044, when the call instruction is an asynchronous call instruction, obtain the executable code of the sharded smart contract from the executing sharded smart contract according to the contract name and / or contract tag of the sharded smart contract recorded in the asynchronous call instruction.

[0058] In some embodiments of the present application, when the call instruction is an asynchronous call instruction, the system will obtain its executable code from the currently executing sharded smart contract according to the contract name and / or contract tag of the sharded smart contract recorded in the asynchronous call instruction. Asynchronous call instructions refer to instructions that allow smart contract calls to be executed at different time points without immediately returning results. By obtaining executable code from the executing sharded smart contract according to the contract name and / or contract tag, the system can locate and extract the specific code logic of the smart contract that needs to be executed, thereby ensuring the accuracy and effectiveness of the asynchronous call operation.

[0059] For example, in a decentralized application for supply chain management, a user sends an asynchronous call instruction to update the inventory information of a smart contract K. The asynchronous call instruction records the contract name "InventoryContract" and the contract tag "UpdateStock" of smart contract K. After receiving the instruction, the system searches for the executable code of smart contract K in the currently executing shard smart contract based on the contract name "InventoryContract" and the contract tag "UpdateStock". After finding contract K, the system extracts its executable code so that the inventory update operation can be performed in subsequent steps. This process ensures that the asynchronous call of the smart contract can correctly locate and extract the code to be executed to meet the business needs of decentralized applications.

[0060] Sub-step 2045, extracts the target function code in the executable code according to the function name of the target function code in the executable code recorded in the asynchronous call instruction, and extracts the target parameter in the executable code according to the parameter name of the target parameter in the executable code recorded in the asynchronous call instruction.

[0061] In some embodiments of the present application, the system will extract the target function code in the executable code according to the function name of the target function code recorded in the asynchronous call instruction. At the same time, the system also extracts the target parameter in the executable code according to the parameter name of the target parameter recorded in the asynchronous call instruction. The target function code is a specific logic function in the smart contract, which is used to implement a specific operation or calculation of the smart contract. The target parameter is the input value passed to the target function, and these input values ​​are used for logical operations when the function is executed. By extracting the target function code and target parameters, the system can accurately locate and execute specific logic in the smart contract, ensuring the accuracy and efficiency of the asynchronous call process.

[0062] For example, in a decentralized application of supply chain management, a user sends an asynchronous call instruction to update the inventory information of a smart contract L. The asynchronous call instruction records the function name of the target function code "updateInventory" of smart contract L and the parameter names of the target parameters "itemID" and "newQuantity". After receiving the instruction, the system extracts the "updateInventory" function code from the executable code, which defines how to update the inventory information. Then, the system extracts the actual parameter values, such as "itemID=98765" and "newQuantity=150", based on the target parameter names recorded in the asynchronous call instruction. By obtaining these target function codes and parameters, the system can execute the "updateInventory" function in smart contract L and update the inventory information of the specified commodity, ensuring the accuracy and efficiency of asynchronous operations.

[0063] Sub-step 2046, executes the target parameters according to the target function code, and returns the execution result of the shard smart contract to the program where the return function is located when the return function name of the return function is included in the asynchronous call instruction.

[0064] In some embodiments of the present application, the system executes the target parameters according to the extracted target function code. Specifically, the system calls the target function code, passes the extracted target parameters to the function as input, and executes it in the smart contract. If the asynchronous call instruction contains the return function name of the return function, the system will return the execution result to the program where the specified return function is located after executing the target function. This process ensures that the asynchronous call can be executed correctly according to the predetermined logic, and the results are fed back to the caller when necessary, thereby achieving efficient collaboration between smart contracts.

[0065] For example, in a decentralized application of supply chain management, a user sends an asynchronous call instruction to update the inventory information of a smart contract M. In the previous step, the system has extracted the target function code "updateStock" and the target parameters "itemID=24680" and "newQuantity=200". Then the system can call the "updateStock" function and pass "itemID=24680" and "newQuantity=200" as input parameters to the function. Smart contract M performs the inventory update operation and updates the inventory quantity of the specified product to 200. If the asynchronous call instruction contains the return function name "notifyUpdate", the system will return the execution result (for example, information on successful operation) to the program where the "notifyUpdate" function is located after completing the inventory update operation. Through such an execution process, the system ensures the accuracy of the asynchronous call and the effective transmission of the execution result.

[0066] In order to help developers achieve communication and collaboration between different smart contracts, the smart contract programming model also provides a list of interfaces (Application Programming Interface, API) for calling between smart contracts. Table 2 provides descriptions of some specific APIs for calling between smart contracts provided by the smart contract programming model under the method of the embodiment of the present application: Table 2 - Smart contract calling interface parameters provided by the smart contract programming model

[0067] According to the above definition, the following provides a specific calling code: contract Example address callee; function constructor(){ } function handler(args){ } public function a(operation,args){ var result=executeContract(callee,operation,args); return result; } public function b(_contract,operation,args){ executeContractAsync(_contract,operation,args,handler); return "success"; } public function c() view { return "isView"; } } The contract declares a callee (callee) that needs to be called synchronously, and five methods. Methods identified by the public keyword can be specified in subsequent smart contract call transactions. Methods without the public keyword, except for the constructor, can be called in any method. The method constrcutor is a special constructor that will only be called once during the entire life cycle of the smart contract to initialize the state of the smart contract. If the method is not declared, a default empty constructor will be added during compilation.

[0068] Methods a and b both call other smart contracts. In method a, executeContract synchronously calls the method operation of the smart contract callee, and then saves the return value in the temporary variable result, which is returned as the result of this smart contract call transaction at the end of execution. The temporary variable result only exists in the memory of the executor and will be destroyed after the execution.

[0069] Method b synchronously calls the method operation of smart contract _contract through executeContractAsync, and provides the method handler as a callback to smart contract _contract. Although the handler method does not have the public keyword, it can be specified in the smart contract call transaction. However, when the executor receives the transaction, it will check whether a transaction has been issued with the target as the initiator of the transaction to ensure that the method can only be used in the callback of the asynchronous call.

[0070] Step 205, in response to the reconstruction instruction of the executing shard smart contract, extract the persistent executable code and state data from the block data, and rebuild the executing shard smart contract through the extracted executable code and state data.

[0071] The method shown in this step has been explained in step 103 and will not be repeated here.

[0072] Based on the method provided in the embodiment of the present application, since the merging of smart contract shards is not simply to make all execution units in a smart contract shard responsible for the execution of multiple merged smart contracts at the same time, this goes against the original intention of the developer to split the functions of the decentralized application into multiple parts. Therefore, the execution units of different smart contracts always run independently, and the merging of smart contract shards is mainly reflected in the merging of transaction sequencers. Therefore, the following process is designed: Optionally, the shard smart contract includes a first shard smart contract and a second shard smart contract, the reconstruction instruction includes a merging instruction for the first shard smart contract and the second shard smart contract, and step 205 includes the following sub-steps: Sub-step 2051, in response to the merge instruction, extracting the first executable code and the first state data from the first block data corresponding to the first shard smart contract, and extracting the second executable code and the second state data from the second block data corresponding to the second shard smart contract.

[0073] In some embodiments of the present application, when the system receives a merge instruction, it extracts the first executable code and the first state data corresponding to the first shard smart contract from the first block data, and extracts the second executable code and the second state data corresponding to the second shard smart contract from the second block data. The first block data and the second block data respectively store all persistent information related to the first shard smart contract and the second shard smart contract, including code and state data. By extracting these executable codes and state data, the system prepares for the subsequent shard smart contract merge operation to ensure that the merged smart contract can be accurately restored and run.

[0074] For example, Figure 4As shown in the figure, in a decentralized financial application, there are two shard smart contracts A and B, which are used to process different types of transactions. Assume that due to business needs, the two shard smart contracts need to be merged into a new smart contract. After receiving the merge instruction, the system first extracts the executable code a, b, c and state data p1, p2, p3 of smart contract A from the first block data. The executable code of smart contract A may contain the logic for processing transaction type A, and the state data records the relevant information of the current transaction. Then, the system extracts the executable code m, l, n and state data p4, p5, p6 of smart contract B from the second block data. The executable code of smart contract B may contain the logic for processing transaction types, and the state data records other transaction information. Through these extraction operations, the system lays the foundation for the subsequent merging of the two smart contracts, ensuring that the merged smart contract can correctly execute the functions of the two shard smart contracts.

[0075] Sub-step 2052: Generate a merged sequencing code of the merged shard smart contract based on the first sequencing code in the first executable code and the second sequencing code in the second executable code, and run the merged sequencing code to generate an operation sequence.

[0076] In some embodiments of the present application, the system will generate a merged sequencing code for the merged sharded smart contract based on the first sequencing code in the first executable code and the second sequencing code in the second executable code. The sequencing code refers to the code logic used to determine the order of operations in the smart contract. By merging the sequencing codes of multiple smart contracts, the system can create a unified merged sequencing code for coordinating the execution order of multiple smart contracts. After generating the merged sequencing code, the system runs the code to generate an operation sequence for the merged smart contract. The operation sequence refers to the order of operations that the smart contract needs to follow during execution to ensure that the logical operations between different smart contracts can be coordinated and consistent to avoid conflicts and errors.

[0077] For example, Figure 4As shown, in the previous steps, the system has extracted the executable code and status data of the first smart contract A and the second smart contract B. Assume that the sequencing code of smart contract A defines the operation sequence for processing transaction type A, and the sequencing code of smart contract B defines the operation sequence for processing transaction type B. Then the system can generate a merged sequencing code based on the sequencing codes of smart contracts A and B, which contains the operation sequence of transaction types A and B. After generating the merged sequencing code, the system runs the code to generate an operation sequence containing the two transaction types. For example, the merged operation sequence may first execute the operation of transaction type A, and then execute the operation of transaction type B, to ensure that the operation sequence of the two smart contracts can be correctly coordinated and executed. Through this process, the system lays the foundation for the subsequent merging and execution of smart contracts.

[0078] Sub-step 2053, running the first executable code and the second executable code according to the running sequence.

[0079] In some embodiments of the present application, the system will run the first executable code and the second executable code in sequence according to the run sequence generated in the previous step. The run sequence defines the order of operations of different smart contracts, ensuring that each operation is executed in a predetermined order to avoid logical conflicts. The system executes the operations of the first smart contract in sequence according to the run sequence, and then executes the operations of the second smart contract, ensuring that the merged smart contract can correctly implement all the functions of the two original smart contracts.

[0080] For example, Figure 4 As shown in the figure, the system generates an operation sequence based on the previous steps, defining the operation order of smart contract A and smart contract B. At this time, the operation sequence is as shown in the figure: Aa(p1)→Bm(p4)→…→Bn(p6)→Ac(p3). Then the system will first run a(p1) in smart contract A according to the operation sequence to complete the processing of transaction type A, and then run the Bm(p4) operation in smart contract B to complete the processing of transaction type B. By following the predetermined operation sequence, the system ensures that the operations of smart contracts A and B can be properly coordinated, avoid logical conflicts, and ensure that the merged smart contract can be executed stably and accurately.

[0081] like Figure 5As shown in the figure, after the smart contracts are merged, the sequencers of the two original smart contract shards can run independently, respectively collecting smart contract call transactions targeting smart contracts A and B, and sequencing a series of transactions through the consensus process, saving them in the form of blocks, which is also the output of the sequencer. The merged sequencer must collect the call transactions of smart contracts A and B at the same time and sequence them uniformly, so the determined transaction sequence in the generated block is also composed of the call transactions of the two smart contracts. In this way, on each node in the shard, the two execution units will execute transactions in the order in the block. Assuming that there is no call between contracts, when one execution unit executes a transaction, the other execution unit will be suspended, which returns to the execution process of blocks when multiple smart contracts are deployed in the existing blockchain technology.

[0082] Optionally, in some embodiments of the present application, the rebuild instruction is also used to restart the smart contract with execution error. In this case, the method further includes the following additional steps: Step 206, in response to an error reporting instruction for the executing sharded smart contract, generates a reconstruction instruction for the sharded smart contract.

[0083] In some embodiments of the present application, when the system detects an error in a sharded smart contract being executed, a reconstruction instruction for the smart contract is generated. An error reporting instruction is an instruction automatically triggered by a smart contract when an exception or error occurs during execution. After receiving the error reporting instruction, the system immediately generates a reconstruction instruction to restore the normal operation of the smart contract. The reconstruction instruction is used to reinitialize the state of the smart contract and reload its executable code to ensure that the smart contract can recover from the error state and continue to execute unfinished operations. By generating reconstruction instructions, the system can effectively reduce execution interruptions caused by errors and improve the reliability and stability of smart contracts.

[0084] For example, on a decentralized trading platform, smart contract N is responsible for processing user transaction requests. Assume that when executing a transaction, an abnormal error occurs in smart contract N, resulting in execution interruption. The system detects the error and generates an error report instruction. In response to the error report instruction, the system generates a reconstruction instruction for smart contract N. The reconstruction instruction includes the operation of reinitializing the state of smart contract N and reloading its executable code. The system executes the reconstruction instruction, restores smart contract N to a normal state, and continues to process unfinished transactions from the interruption point. In this way, the system ensures the continuity and stability of the trading platform and avoids transaction failures and user dissatisfaction caused by execution errors.

[0085] like Figure 6 As shown, it is a specific embodiment provided by the present application, which introduces the main process of the present solution through steps S1 to S4: Step S1: Compile smart contract source code: The compiler compiles the source code of the smart contract into executable code. The source code of the smart contract is usually written in a high-level programming language and contains the logic and function definitions of the contract. The compilation process converts these high-level language codes into executable code in binary form, which can be directly executed on the blockchain node. The compiled executable code ensures that the logic of the smart contract can be executed correctly and provides the required functions.

[0086] For example, suppose a developer writes a smart contract X that implements some transaction processing logic. The compiler compiles the source code of smart contract X into executable code, and the converted code can be run on nodes in the blockchain network.

[0087] Step S2: Storing the persistent smart contract: The system stores the compiled executable code of smart contract X in the block data. Persistent storage means permanently saving data in the storage system to ensure that the data will not be lost due to system failure or restart. By persistently storing the executable code of smart contract X in the block data, the system can quickly load and execute the contract code when needed, ensuring the stable existence of the smart contract in the blockchain network.

[0088] For example, the system stores the compiled executable code of smart contract X into block data, which will be recorded in a block of the blockchain, ensuring that the code of smart contract X is protected in the shard.

[0089] Step S3: Execute Smart Contract: The Smart Contract Executor is responsible for executing Smart Contract X. The Smart Contract Executor extracts the persistent executable code and status data from the block data and executes the smart contract according to the user's call instructions. During the execution process, the logic function of the smart contract is triggered, the predetermined operation or calculation is completed, and the status data is updated. The execution results will be recorded on the blockchain to ensure the transparency and immutability of the contract execution.

[0090] Step S4: Deployment of smart contracts: The Deployment Tool deploys smart contract X to different shards of the decentralized application (such as shard 1 and shard 2 in the figure). The deployment process includes transferring the executable code and state data of smart contract X to the specified shard nodes and performing necessary initialization operations on these nodes. By deploying smart contracts to different shards, the system can run contracts in parallel on multiple nodes, improving execution efficiency and system fault tolerance.

[0091] In summary, in the embodiments of the present application, by persisting the executable code and status data of the sharded smart contract in the block data, the stable existence of the code and status data of the smart contract in the shard is ensured, and data loss caused by node failure or network fluctuation is avoided. At the same time, the persistent executable code and status data enable the smart contract to be quickly extracted and executed in the shard, thereby improving the robustness and data security of the system; and by extracting the persistent executable code and status data from the block data after receiving the call instruction for the sharded smart contract to execute the smart contract, the code and status data of the smart contract do not need to be obtained from the outside, thereby reducing the delay in the calling process, and at the same time, according to the execution of the smart contract, the persistent status data is updated, so that the status of the smart contract can be updated in time after each call, thereby ensuring the consistency and reliability of the data; further, by extracting the persistent executable code and status data from the block data, the executing smart contract is rebuilt, and its status and function can be quickly rebuilt, thereby improving the availability and stability of the system. Therefore, based on the method of the embodiment of the present application, by persistently storing the executable code and state data of the smart contract in the block data, the smart contract state can be efficiently extracted and restored during the call and reconstruction process, reducing the complexity and inefficiency of cross-shard calls of smart contracts, improving the response speed of smart contract calls, enhancing the performance and user experience of decentralized applications, and at the same time reducing data loss and downtime caused by failures, and improving the stability and reliability of the system. The problems of complex cross-shard calls, slow execution speed and difficult fault recovery of smart contracts in the prior art are solved, and the performance and stability of the blockchain system when processing decentralized applications are improved.

[0092] refer to Figure 7 , which shows a smart contract program generation device 30 for decentralized applications provided in an embodiment of the present application, including: The persistence module 301 is used to persist the executable code and state data of the sharded smart contract in the block data respectively; the block data corresponds to the network shard where the sharded smart contract is located; An execution module 302, for extracting executable code and state data persisted in the block data in response to a call instruction to the sharding smart contract, so as to execute the sharding smart contract, and updating the state data persisted in the block data according to the execution of the sharding smart contract; The reconstruction module 303 is used to respond to the reconstruction instruction of the executing shard smart contract, extract the persistent executable code and status data from the block data, and rebuild the executing shard smart contract through the extracted executable code and status data.

[0093] Optionally, the persistence module 301 includes: The compilation submodule is used to compile the source code of the sharded smart contract to obtain executable code, and persist the compiled executable code in the block data; The initialization submodule is used to obtain the initial state data of the sharded smart contract according to the execution of the initialization code in the persistent executable code, and persist the initial state data in the block data.

[0094] Optionally, the calling instruction includes a synchronous calling instruction, and the execution module 302 includes: A synchronous extraction submodule, used to obtain the executable code of the sharded smart contract recorded in the synchronous call instruction from the synchronous call instruction when the call instruction is a synchronous call instruction; A synchronous access submodule, used to extract the target function code in the executable code according to the function name of the target function code in the executable code recorded in the synchronous call instruction, and to extract the target parameter in the executable code according to the parameter name of the target parameter in the executable code recorded in the synchronous call instruction; The synchronous execution submodule is used to execute the target parameters according to the target function code.

[0095] Optionally, the calling instruction includes an asynchronous calling instruction, and the execution module 302 includes: An asynchronous extraction submodule, used for obtaining the executable code of the shard smart contract from the executing shard smart contract according to the contract name and / or contract tag of the shard smart contract recorded in the asynchronous call instruction when the call instruction is an asynchronous call instruction; The asynchronous access submodule is used to extract the target function code in the executable code according to the function name of the target function code in the executable code recorded in the asynchronous call instruction, and to extract the target parameter in the executable code according to the parameter name of the target parameter in the executable code recorded in the asynchronous call instruction; The asynchronous execution submodule is used to execute the target parameters according to the target function code, and when the return function name of the return function is included in the asynchronous call instruction, the execution result of the shard smart contract is returned to the program where the return function is located.

[0096] Optionally, the device 30 further includes: A deployment acquisition module is used to generate a deployment plan for a sharded smart contract according to the executable code of the sharded smart contract, or to acquire a deployment plan for the sharded smart contract according to the deployment operation of the sharded smart contract code; the deployment plan has a corresponding network sharding node; the network sharding node is used to call and execute the sharded smart contract; The deployment module is used to deploy the sharding smart contract in the network sharding node corresponding to the sharding smart contract according to the deployment plan.

[0097] Optionally, the shard smart contract includes a first shard smart contract and a second shard smart contract, the reconstruction instruction includes a merging instruction for the first shard smart contract and the second shard smart contract, and the reconstruction module 303 includes: A merge and extract submodule, configured to extract, in response to a merge instruction, a first executable code and a first state data from a first block data corresponding to a first shard smart contract, and a second executable code and a second state data from a second block data corresponding to a second shard smart contract; A merging and sequencing submodule, used to generate a merging and sequencing code of the merged shard smart contract according to the first sequencing code in the first executable code and the second sequencing code in the second executable code, and run the merging and sequencing code to generate an operation sequence; The merge execution submodule is used to execute the first executable code and the second executable code according to the execution sequence.

[0098] Optionally, the device 30 further includes: The reconstruction initiation module is used to generate a reconstruction instruction for the sharded smart contract in response to an error reporting instruction for the executed sharded smart contract.

[0099] In summary, in the embodiments of the present application, by persisting the executable code and status data of the sharded smart contract in the block data, the stable existence of the code and status data of the smart contract in the shard is ensured, and data loss caused by node failure or network fluctuation is avoided. At the same time, the persistent executable code and status data enable the smart contract to be quickly extracted and executed in the shard, thereby improving the robustness and data security of the system; and by extracting the persistent executable code and status data from the block data after receiving the call instruction for the sharded smart contract to execute the smart contract, the code and status data of the smart contract do not need to be obtained from the outside, thereby reducing the delay in the calling process, and at the same time, according to the execution of the smart contract, the persistent status data is updated, so that the status of the smart contract can be updated in time after each call, thereby ensuring the consistency and reliability of the data; further, by extracting the persistent executable code and status data from the block data, the executing smart contract is rebuilt, and its status and function can be quickly rebuilt, thereby improving the availability and stability of the system. Therefore, based on the method of the embodiment of the present application, by persistently storing the executable code and state data of the smart contract in the block data, the smart contract state can be efficiently extracted and restored during the call and reconstruction process, reducing the complexity and inefficiency of cross-shard calls of smart contracts, improving the response speed of smart contract calls, enhancing the performance and user experience of decentralized applications, and at the same time reducing data loss and downtime caused by failures, and improving the stability and reliability of the system. The problems of complex cross-shard calls, slow execution speed and difficult fault recovery of smart contracts in the prior art are solved, and the performance and stability of the blockchain system when processing decentralized applications are improved.

[0100] Reference Figure 8 , the electronic device 500 may include one or more of the following components: a processing component 502 , a memory 504 , a power component 506 , a multimedia component 508 , an audio component 510 , an input / output (I / O) interface 512 , a sensor component 514 , and a communication component 516 .

[0101] The processing component 502 generally controls the overall operation of the electronic device 500, such as operations associated with display, phone calls, data communications, camera operations, and recording operations. The processing component 502 may include one or more processors 520 to execute instructions to complete all or part of the steps of the above-mentioned method. In addition, the processing component 502 may include one or more modules to facilitate the interaction between the processing component 502 and other components. For example, the processing component 502 may include a multimedia module to facilitate the interaction between the multimedia component 508 and the processing component 502.

[0102] The memory 504 is used to store various types of data to support the operation of the electronic device 500. Examples of such data include instructions for any application or method operating on the electronic device 500, contact data, phone book data, messages, pictures, multimedia, etc. The memory 504 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0103] The power supply component 506 provides power to the various components of the electronic device 500. The power supply component 506 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the electronic device 500.

[0104] The multimedia component 508 includes an interface that provides an output interface between the electronic device 500 and the user. In some embodiments, the interface may include a liquid crystal display (LCD) and a touch panel (TP). If the interface includes a touch panel, the interface may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundaries of the touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 508 includes a front camera and / or a rear camera. When the electronic device 500 is in an operating mode, such as a shooting mode or a multimedia mode, the front camera and / or the rear camera may receive external multimedia data. Each front camera and rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

[0105] The audio component 510 is used to output and / or input audio signals. For example, the audio component 510 includes a microphone (MIC), and when the electronic device 500 is in an operation mode, such as a call mode, a recording mode, and a voice recognition mode, the microphone is used to receive an external audio signal. The received audio signal can be further stored in the memory 504 or sent via the communication component 516. In some embodiments, the audio component 510 also includes a speaker for outputting audio signals.

[0106] The input / output I / O interface 512 provides an interface between the processing component 502 and the peripheral interface module, which may be a keyboard, a click wheel, buttons, etc. These buttons may include but are not limited to: a home button, a volume button, a start button, and a lock button.

[0107] The sensor assembly 514 includes one or more sensors for providing various aspects of status assessment for the electronic device 500. For example, the sensor assembly 514 can detect the open / closed state of the electronic device 500, the relative positioning of components, such as the display and keypad of the electronic device 500, and the sensor assembly 514 can also detect the position change of the electronic device 500 or a component of the electronic device 500, the presence or absence of user contact with the electronic device 500, the orientation or acceleration / deceleration of the electronic device 500, and the temperature change of the electronic device 500. The sensor assembly 514 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor assembly 514 may also include an optical sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 514 may also include an accelerometer, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0108] The communication component 516 is used to facilitate wired or wireless communication between the electronic device 500 and other devices. The electronic device 500 can access a wireless network based on a communication standard, such as WiFi, a carrier network (such as 2G, 3G, 4G or 5G), or a combination thereof. In an exemplary embodiment, the communication component 516 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 516 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0109] In an exemplary embodiment, the electronic device 500 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to implement the methods provided in the embodiments of the present application.

[0110] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 504 including instructions, and the instructions can be executed by a processor 520 of an electronic device 500 to perform the above method. For example, the non-transitory storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0111] Fig. 9FIG. 6 is a block diagram of an electronic device 600 according to another embodiment of the present invention. For example, the electronic device 600 may be provided as a server.

[0112] Reference Fig. 9 , the electronic device 600 includes a processing component 622, which further includes one or more processors, and a memory resource represented by a memory 632, for storing instructions that can be executed by the processing component 622, such as an application. The application stored in the memory 632 may include one or more modules, each corresponding to a set of instructions. In addition, the processing component 622 is configured to execute instructions to perform the method provided in the embodiment of the present application.

[0113] The electronic device 600 may also include a power supply component 626 configured to perform power management of the electronic device 600, a wired or wireless network interface 650 configured to connect the electronic device 600 to a network, and an input / output (I / O) interface 658. The electronic device 600 may operate based on an operating system stored in the memory 632, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™ or the like.

[0114] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the application disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present disclosure. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0115] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A method for generating a smart contract program for decentralized applications, characterized in that: include: Persist the executable code and status data of the sharded smart contract in the block data respectively; The block data corresponds to the network shard where the shard smart contract is located; In response to a call instruction to the shard smart contract, extract the executable code and state data persisted in the block data to execute the shard smart contract, and update the state data persisted in the block data according to the execution of the shard smart contract; In response to a reconstruction instruction for the executing shard smart contract, the persistent executable code and state data are extracted from the block data, and the executing shard smart contract is reconstructed using the extracted executable code and state data.

2. The method according to claim 1, characterized in that The method of respectively persisting the executable code and status data of the sharded smart contract in the block data includes: Compile the source code of the shard smart contract to obtain the executable code, and persist the compiled executable code in the block data; According to the execution of the initialization code in the persistent executable code, the initial state data of the sharded smart contract is obtained, and the initial state data is persisted in the block data.

3. The method according to claim 1, characterized in that The calling instruction includes a synchronous calling instruction, and the response to the calling instruction of the shard smart contract is to extract the executable code and state data persisted in the block data to execute the shard smart contract, including: In the case where the calling instruction is a synchronous calling instruction, obtaining the executable code of the sharding smart contract recorded in the synchronous calling instruction from the synchronous calling instruction; Extracting the target function code in the executable code according to the function name of the target function code in the executable code recorded in the synchronous call instruction, and extracting the target parameter in the executable code according to the parameter name of the target parameter in the executable code recorded in the synchronous call instruction; The target parameters are executed according to the target function code.

4. The method according to claim 1, characterized in that The calling instruction includes an asynchronous calling instruction, and the response to the calling instruction of the shard smart contract is to extract the executable code and state data persisted in the block data to execute the shard smart contract, including: In the case where the calling instruction is an asynchronous calling instruction, obtaining the executable code of the sharding smart contract from the executing sharding smart contract according to the contract name and / or contract tag of the sharding smart contract recorded in the asynchronous calling instruction; Extracting the target function code in the executable code according to the function name of the target function code in the executable code recorded in the asynchronous call instruction, and extracting the target parameter in the executable code according to the parameter name of the target parameter in the executable code recorded in the asynchronous call instruction; The target parameters are executed according to the target function code, and when the return function name of the return function is included in the asynchronous call instruction, the execution result of the shard smart contract is returned to the program where the return function is located.

5. The method according to claim 1, characterized in that The method further comprises: Generate a deployment plan for the sharded smart contract according to the executable code of the sharded smart contract, or obtain a deployment plan for the sharded smart contract according to the deployment operation of the sharded smart contract code; the deployment plan has a corresponding network sharding node; the network sharding node is used to call and execute the sharded smart contract; According to the deployment plan, the sharding smart contract is deployed in the network sharding node corresponding to the sharding smart contract.

6. The method according to claim 1, characterized in that The shard smart contract includes a first shard smart contract and a second shard smart contract, the reconstruction instruction includes a merging instruction for the first shard smart contract and the second shard smart contract, and the response to the reconstruction instruction for the executing shard smart contract, extracting the persistent executable code and state data from the block data, and reconstructing the executing shard smart contract by using the extracted executable code and the state data, including: In response to the merge instruction, extracting a first executable code and a first state data from a first block data corresponding to the first shard smart contract, and extracting a second executable code and a second state data from a second block data corresponding to the second shard smart contract; Generate a merged sequencing code of the merged shard smart contract according to the first sequencing code in the first executable code and the second sequencing code in the second executable code, and run the merged sequencing code to generate an operation sequence; The first executable code and the second executable code are executed according to the execution sequence.

7. The method according to claim 1, characterized in that The method further comprises: In response to an error reporting instruction for the sharded smart contract being executed, a reconstruction instruction for the sharded smart contract is generated.

8. A smart contract program generation device for decentralized applications, characterized in that: include: The persistence module is used to persist the executable code and status data of the sharded smart contract in the block data respectively; The block data corresponds to the network shard where the shard smart contract is located; An execution module, configured to extract executable code and state data persisted in the block data in response to a call instruction to the shard smart contract, so as to execute the shard smart contract, and update the state data persisted in the block data according to the execution of the shard smart contract; A reconstruction module is used to extract persistent executable code and status data from the block data in response to a reconstruction instruction for the executing shard smart contract, and to reconstruct the executing shard smart contract through the extracted executable code and status data.

9. An electronic device, characterized in that: include: A processor, a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform the method as claimed in any one of claims 1 to 7.

Images