Execution methods and systems for smart contracts

Abstract

This application discloses a method and system for executing smart contracts. The method includes: receiving a first smart contract and allocating a memory partition for the first smart contract; wherein the memory partition includes preset access permissions, which indicate the types of operations allowed to be executed by the memory partition; encrypting the first smart contract using a quantum-resistant cryptographic algorithm module and storing the encrypted first smart contract in the memory partition; decrypting the first smart contract and executing the decrypted first smart contract in the memory partition according to the preset access permissions. This solution improves data security during execution by storing the encrypted smart contract in a memory partition, ensuring that the contract remains in ciphertext form in memory. Simultaneously, by constraining the contract execution process through preset access permissions, it ensures that the contract is executed only within authorized scope, preventing out-of-bounds access.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and specifically relates to a method and system for executing smart contracts. Background Technology

[0002] Existing smart contract execution environments typically employ sandbox technology to isolate contracts, allowing execution once the contract code is loaded into memory. However, in this approach, once a smart contract is loaded into memory, its execution instructions can access the entire sandbox memory space. This makes it vulnerable to malicious contracts stealing sensitive data from other contracts or tampering with execution logic through out-of-bounds memory access, resulting in low security. Summary of the Invention

[0003] The purpose of this application is to provide a method and system for executing smart contracts in order to improve the security of smart contract execution.

[0004] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part by practice of this application.

[0005] According to one aspect of the embodiments of this application, a method for executing a smart contract is provided, comprising:

[0006] The system receives a first smart contract and allocates a memory partition for the first smart contract; wherein the memory partition includes a preset access permission, which is used to indicate the types of operations allowed to be performed on the memory partition; the types of operations include at least one of read operations, write operations, and code execution operations; The first smart contract is encrypted using a quantum-resistant cryptographic algorithm module, and the encrypted first smart contract is stored in the memory partition; the quantum-resistant cryptographic algorithm module includes a functional module for executing the quantum-resistant cryptographic algorithm. The first smart contract is decrypted, and the decrypted first smart contract is executed in the memory partition according to the preset access permissions.

[0007] According to one aspect of the embodiments of this application, a smart contract execution system is provided, the execution system comprising: Sandbox; The system includes a memory allocation module, an encrypted storage module, and an instruction execution module deployed within the sandbox. The memory allocation module receives a first smart contract and allocates a memory partition for it. The memory partition includes preset access permissions, which indicate the types of operations allowed to be performed within the memory partition. The encrypted storage module encrypts the first smart contract using a quantum-resistant cryptographic algorithm module and stores the encrypted first smart contract in the memory partition. The instruction execution module decrypts the first smart contract and executes the decrypted first smart contract in the memory partition according to the preset access permissions.

[0008] According to one aspect of the embodiments of this application, a computer-readable medium is provided having a computer program stored thereon, which, when executed by a processor, implements the smart contract execution method provided in any embodiment of this application.

[0009] According to one aspect of the embodiments of this application, an electronic device is provided, the electronic device comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor executes the executable instructions to cause the electronic device to execute a smart contract execution method according to any embodiment of the present application.

[0010] According to one aspect of the embodiments of this application, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform the smart contract execution method of any embodiment of this application.

[0011] In the technical solution provided in this application embodiment, a first smart contract is first received, and a memory partition is allocated for the first smart contract. The memory partition includes a preset access permission, which indicates the types of operations allowed to be executed within the memory partition. These operation types include at least one of read, write, and code execution operations. Then, the first smart contract is encrypted using a quantum-resistant cryptographic algorithm module, and the encrypted first smart contract is stored in the memory partition. The quantum-resistant cryptographic algorithm module includes a functional module for executing the quantum-resistant cryptographic algorithm. Finally, the first smart contract is decrypted, and the decrypted first smart contract is executed in the memory partition according to the preset access permission. Thus, by storing the encrypted smart contract in the memory partition, the contract always remains in ciphertext form in memory, improving data security during execution. Simultaneously, by constraining the contract execution process through preset access permissions, it can be ensured that the contract is executed only within the authorized scope, preventing out-of-bounds access.

[0012] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0013] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0014] Figure 1 A schematic diagram of a blockchain system architecture provided in one embodiment of this application is shown.

[0015] Figure 2 A flowchart illustrating the execution method of a smart contract provided in an embodiment of this application is shown schematically.

[0016] Figure 3 A flowchart illustrating the execution method of a smart contract provided in an embodiment of this application is shown schematically.

[0017] Figure 4 A schematic block diagram of a contract execution apparatus provided in one embodiment of this application is shown.

[0018] Figure 5 A schematic diagram of the computer system architecture used to implement the technical solution of this application is shown. Detailed Implementation

[0019] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0020] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0021] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0022] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0023] Figure 1 A schematic diagram of a blockchain system architecture provided in one embodiment of this application is shown.

[0024] like Figure 1 As shown, the blockchain system in this embodiment adopts a layered architecture design, which includes four layers from bottom to top: hardware layer, operating system layer, quantum-resistant cryptographic algorithm layer, and sandbox.

[0025] The hardware layer, located at the bottom of the node, contains physical computing resources such as the central processing unit, system memory, and physical storage devices. The hardware layer provides basic computing power and resource support for the layers above it.

[0026] The operating system layer runs on top of the hardware layer and includes the operating system kernel and the logical volume management module. The operating system kernel is responsible for managing system resources and can implement virtual memory management through its memory management unit. The logical volume management module uses LVM (Logical Volume Manager) technology to divide the physical storage device into independent logical volume partitions to provide persistent and isolated storage space for smart contracts. Each logical volume partition can be mounted, encrypted, and destroyed independently.

[0027] The quantum-resistant cryptographic algorithm layer, as an independent cryptographic service layer, is deployed above the operating system layer and can load and run quantum-resistant cryptographic algorithm modules. These modules specifically include quantum-resistant encryption algorithm modules and quantum-resistant signature algorithm modules. Simultaneously, the quantum-resistant cryptographic algorithm layer can provide a unified cryptographic service interface to the upper-layer sandbox, enabling functions such as quantum-resistant encryption, decryption, signature generation, and signature verification.

[0028] The sandbox, located at the top layer of the blockchain system, is the actual execution environment for smart contracts. It interacts with the quantum-resistant cryptographic algorithm layer, utilizing its cryptographic services to ensure security throughout the smart contract's lifecycle. Specifically, the sandbox includes the following core functionalities: First, the memory isolation mechanism. The sandbox can establish an instruction-level memory isolation mechanism based on the operating system's memory management capabilities. It pre-divides system memory into instruction execution memory areas, data storage memory areas, and temporary cache areas, and configures preset access permissions for each memory area. When a smart contract is received, the sandbox allocates a dedicated memory partition for each contract from these memory areas to prevent interference from other instructions crossing these partitions.

[0029] Second, contract deployment protection. When deploying smart contracts, the sandbox can call a quantum-resistant cryptographic algorithm layer to verify the digital signature of the smart contract, ensuring that the smart contract's origin is trustworthy and has not been tampered with. After successful verification, it can also call a quantum-resistant cryptographic algorithm to encrypt the smart contract's code and dependent files, and store the encrypted contract in the memory partition allocated to the smart contract.

[0030] Third, instruction-level execution control. When executing a contract, the sandbox executes the contract instructions one by one in the allocated memory partition. When each instruction is executed, it checks whether its access scope complies with the preset access permissions. Only instructions are allowed to access the memory partition bound to their respective contracts, and cross-contract memory access is prohibited.

[0031] Fourth, data encryption is implemented. During the execution of smart contracts, the sandbox can call a quantum-resistant cryptographic algorithm layer to encrypt temporary data, execution instructions, and intermediate computation results generated by the smart contract in real time, ensuring that the data during the execution process always exists in encrypted form in the system memory.

[0032] Fifth, cross-contract call protection. When a smart contract needs to call other smart contracts, the sandbox will use the quantum-resistant signature algorithm in the quantum-resistant cryptographic algorithm layer to generate a dynamic signature for the call request, establish a quantum-resistant encrypted channel between the memory partitions of other smart contracts, and then transmit the call request and signature through the encrypted channel, and encrypt the returned execution result.

[0033] Thus, through the layered architecture design described above, the blockchain nodes in this embodiment construct a comprehensive quantum-resistant security protection system from hardware to application. Specifically, the hardware layer provides the physical foundation, the operating system layer implements resource management and logical volume isolation, the quantum-resistant cryptographic algorithm layer provides cryptographic services, and the sandbox enables isolated execution and security control of smart contracts. In other words, the layers interact through explicit interfaces, jointly ensuring the security, isolation, and reliability of smart contracts under quantum computing attack scenarios.

[0034] The execution method of the smart contract provided in this application will be described in detail below with reference to specific implementation methods.

[0035] Figure 2 A flowchart illustrating a smart contract execution method according to an embodiment of this application is shown schematically. The implementation process of the technical solution of this application will be described below using a terminal device as the execution subject. Figure 2 As shown, the smart contract execution method provided in this embodiment includes steps 210 to 230, as detailed below: Step 210: Receive the first smart contract and allocate a memory partition for the first smart contract; wherein the memory partition includes preset access permissions.

[0036] Specifically, a smart contract is a collection of executable code with specific business logic written by developers and deployed on a blockchain node. The first smart contract is the smart contract to be executed in this application.

[0037] A memory partition refers to a dedicated and isolated memory space within the system memory of a blockchain node, allocated for a single smart contract (i.e., the first smart contract). It serves as the sole execution carrier for that contract. This memory partition is physically isolated from the memory spaces of other smart contracts. Due to its independent preset access permissions and virtual address, it is used solely to store the encrypted data of the first smart contract, execute instructions, and cache temporary computational data. Direct access by other contracts or external processes is not permitted.

[0038] Pre-configured access permissions are a set of permission rules pre-configured in the memory partition. These permissions indicate the types of operations allowed to be performed in the memory partition, such as read operations, write operations, and code execution operations. It should be noted that different access permissions can be configured for different memory partitions in this application; this is not limited here. Storing the first smart contract in the memory partition restricts each execution instruction within the contract to operate only within a specified address range in its dedicated memory partition, prohibiting memory access across partitions, contracts, or the sandbox core area.

[0039] Step 220: Encrypt the first smart contract using the quantum-resistant cryptographic algorithm module, and store the encrypted first smart contract in the memory partition.

[0040] Specifically, the quantum-resistant cryptography algorithm module is a functional module used to execute quantum-resistant cryptography algorithms.

[0041] Encrypting the first smart contract can specifically include using a preset cryptographic algorithm from the quantum-resistant cryptographic algorithm module to encrypt and transform the code, configuration, and state data of the first smart contract. This operation converts the plaintext form of the first smart contract into a ciphertext form that cannot be directly read, preventing the smart contract data from being stolen or tampered with during memory storage or transmission, thereby ensuring the confidentiality and integrity of the contract data. The preset cryptographic algorithm can specifically be a quantum-resistant public-key encryption / key encapsulation algorithm, a quantum-resistant digital signature algorithm, a quantum-resistant hash algorithm, etc.

[0042] Step 230: Decrypt the first smart contract and execute the decrypted first smart contract in the memory partition according to the preset access permissions.

[0043] Specifically, since the first smart contract is stored encrypted in a memory partition, the encrypted first smart contract data must be decrypted before execution to obtain plaintext contract data for actual execution. During instruction execution, the preset access permissions must be strictly followed, and execution can only be performed within the memory partition corresponding to the first smart contract. Execution cannot exceed the memory partition's range to avoid interfering with the execution of other smart contracts in other memory partitions.

[0044] In the technical solution provided in this application embodiment, a first smart contract is first received, and a memory partition is allocated to the first smart contract. The memory partition includes preset access permissions, which indicate the types of operations allowed to be executed within the memory partition. These operation types include at least one of read, write, and code execution operations. Then, the first smart contract is encrypted using a quantum-resistant cryptographic algorithm module, and the encrypted first smart contract is stored in the memory partition. The quantum-resistant cryptographic algorithm module includes a functional module for executing the quantum-resistant cryptographic algorithm. Finally, the first smart contract is decrypted, and the decrypted first smart contract is executed in the memory partition according to the preset access permissions. Thus, by storing the encrypted smart contract in the memory partition, the contract always remains in ciphertext form in memory, improving data security during execution. Simultaneously, by constraining the contract execution process through preset access permissions, it can be ensured that the contract is executed only within the authorized scope, preventing out-of-bounds access.

[0045] In one embodiment of this application, the method of allocating memory partitions for the first smart contract includes: validating the digital signature in the first smart contract; if the digital signature is valid, dividing the system memory into three memory areas and allocating a corresponding virtual address and preset access permissions to each memory area; the three memory areas are an instruction execution memory area, a data storage memory area, and a temporary cache area; dividing the first smart contract into corresponding memory partitions from each memory area to obtain an instruction execution memory partition, a data storage memory partition, and a temporary cache partition.

[0046] Specifically, the digital signature of the first smart contract is a unique cryptographic verification identifier generated by the contract developer / deployer using a quantum-resistant cryptographic algorithm. The digital signature can be obtained by the contract developer using their private key to perform cryptographic calculations on the hash value of the first smart contract, and includes contract identity information, developer identity information, and tamper-proof verification information.

[0047] Verifying the validity of the digital signature in the first smart contract involves using a quantum-resistant cryptographic algorithm layer to check the legality and integrity of the digital signature attached to the contract. This verification process calls a pre-loaded quantum-resistant signature verification module, uses the developer's public key to decrypt the digital signature, compares the decrypted hash value with the actual hash value of the contract, and verifies the timestamp, signature holder permissions, and other information to determine the validity of the digital signature. If the decrypted hash value perfectly matches the actual SHA-3 hash value of the contract code, the signature is within its validity period, and the developer has contract deployment permissions, the digital signature is deemed valid, and the contract deployment process begins. Otherwise, it is deemed invalid, and the blockchain system will terminate the contract access process. This includes discarding the contract's code data, ceasing to allocate any system resources (such as memory partitions or computing power), and not recording the contract information in the blockchain node's contract registry. Furthermore, a deployment failure log can be generated and sent back to the submitter, preventing unauthorized or tampered contracts from entering the execution phase at the source.

[0048] For example, if the digital signature of the first smart contract is valid, operations such as code parsing, pre-compilation, contract identifier allocation, and memory partitioning can be performed on the first smart contract to complete the basic configuration before contract execution. That is, firstly, three memory areas are divided from the system memory: an instruction execution memory area, a data storage memory area, and a temporary cache area, and a corresponding virtual address and preset access permissions are allocated to each memory area; then, a corresponding memory partition is partitioned from each memory area for the first smart contract to obtain the instruction execution memory partition, data storage memory partition, and temporary cache partition corresponding to the first smart contract.

[0049] Specifically, system memory refers to the physical random access memory provided by the hardware layer of a blockchain node. It is uniformly managed and allocated by the operating system kernel and serves as a temporary storage medium for instructions and data during smart contract execution. For example, the 16GB DDR4 physical memory on a blockchain node is the system memory of that node. The sandbox can divide it into different memory areas according to functional rules, and then allocate a dedicated memory partition for each smart contract.

[0050] The memory area is a logical memory region with specific functional attributes pre-allocated from system memory, based on the operating system kernel's memory management capabilities. Each memory area has an independent virtual address and preset access permissions, used to categorize and store different types of contract data. Specifically, the instruction execution memory area stores smart contract execution instruction code, and is typically configured to allow only read and code execution operations, while prohibiting write operations to prevent the smart contract code from being tampered with during execution. The data storage memory area stores smart contract runtime state data and persistent data; this area is configured to allow read and write operations, but prohibits any code execution to prevent data from being treated as instructions and causing security risks. The temporary cache area stores temporary variables and intermediate calculation results generated during smart contract execution; this area is configured to allow fast read and write operations, and the data can be released or cleared after contract execution.

[0051] The memory partition is a dedicated sub-region of memory further divided for the first smart contract from the aforementioned memory regions. Each memory partition inherits the functional attributes and access permissions of the memory regions from which it originates and is bound to the contract identifier of the first smart contract, forming a dedicated instruction execution memory partition, data storage memory partition, and temporary cache partition for the first smart contract. The instruction execution memory partition is a dedicated sub-region of memory divided from the instruction execution memory region for the first smart contract, used to store the execution instruction code of the first smart contract. This partition is bound to the contract identifier of the first smart contract and only allows read and code execution operations. The data storage memory partition is a dedicated sub-region of memory divided from the data storage memory region for the first smart contract, used to store the runtime state data and persistent data of the first smart contract; the preset access permissions of the data storage memory partition indicate that only read and write operations by the first smart contract are allowed. The temporary cache partition is a dedicated sub-region of memory divided from the temporary cache region for the first smart contract, used to store temporary variables and intermediate calculation results generated during the execution of the first smart contract. The preset access permissions of the temporary cache partition indicate that only temporary read and write operations by the first smart contract are allowed.

[0052] A contract identifier is an identity identifier used to uniquely identify and locate a smart contract. It can be a contract address, contract ID, or other identifying information that can uniquely distinguish different smart contracts. For example, a contract identifier can be used to establish a mapping relationship between a smart contract and its allocated memory partition.

[0053] A virtual address is a logical address identifier assigned to each memory region in the system memory, and to each memory partition within a memory region. It is an abstract address segment distinct from physical memory addresses. There is a one-to-one mapping between virtual addresses and physical memory addresses, which can only be resolved by the sandbox execution environment. Each memory region / partition's virtual address segment is independent and non-overlapping, used to precisely define the access scope of each memory region and prevent unauthorized access to physical memory across regions. For example, first, a virtual address segment 0x00000000-0x7FFFFFFF is allocated to the 8GB instruction execution memory region. Then, a 32MB instruction execution memory partition is allocated from this partition for the "transfer smart contract," and a sub-virtual address segment 0x00000000-0x01FFFFFF is allocated to it. Thus, this sub-address segment is exclusively for the use of the "transfer smart contract," and other contracts cannot access it.

[0054] In one embodiment of this application, after dividing the memory into partitions for the first smart contract, a first encryption key can be generated for the first smart contract based on a quantum-resistant cryptographic algorithm module; then, the contract code and initial configuration data of the first smart contract are encrypted according to the first encryption key; finally, the encrypted contract code is stored in the instruction execution memory partition in the memory partition, and the encrypted initial configuration data is stored in the data storage memory partition in the memory partition.

[0055] Specifically, the first encryption key is a quantum-resistant encryption key generated exclusively for the first smart contract by the quantum-resistant cryptographic algorithm module within the sandbox. It has uniqueness and resistance to quantum attacks. It is only suitable for the static data encryption scenario of the first smart contract. Its core purpose is to encrypt the contract code and initial configuration data of the first smart contract. It is also the only key for decrypting such encrypted static data in the subsequent execution phase.

[0056] Contract code is the fundamental carrier for the first smart contract to implement its preset business logic. It is the static code compiled before the smart contract is deployed, specifically containing all the contract's business execution instructions, logical judgment rules, and operation execution processes. Initial configuration data refers to the basic static data pre-configured by the first smart contract before deployment and execution. This data may include contract-specific identification information, basic deployment parameters, business operation thresholds, initial permission configurations, and basic interaction association information, but does not include dynamic data generated during contract execution.

[0057] For example, the process of encrypting and storing the first smart contract can be as follows: First, the CRYSTALS-Kyberv3.0 encryption module in the pre-loaded quantum-resistant cryptographic algorithm layer within the sandbox is invoked to generate a first encryption key in combination with a pre-initialized 2048-bit key parameter. Then, the complete code, initial configuration data, and all other contents of the first smart contract are fully encrypted using the first encryption key, converting the plaintext contract into ciphertext. Next, according to the functional partitioning rules of memory partitions, the encrypted contract code is precisely stored in the instruction execution memory partition allocated to it, and the encrypted initial configuration data of the contract is stored in the corresponding data storage memory partition, thereby completing the targeted storage of the ciphertext contract in a dedicated memory partition.

[0058] This embodiment employs a dual design of "hierarchical memory partitioning + encrypted contract data storage." First, based on the functional attributes of smart contract execution, the system memory of the blockchain node is divided into three global memory areas: instruction execution, data storage, and temporary cache. Each memory area is assigned an independent virtual address and preset access permissions matching functional requirements, thus constructing a standardized global memory functional foundation. Then, based on this foundation, a corresponding dedicated memory partition is partitioned for the first smart contract from each global memory area as needed, forming a complete memory space containing the three sub-partitions that uniquely corresponds to the first smart contract. Simultaneously, the first smart contract is encrypted and stored in each of the corresponding dedicated memory partitions, making the contract the sole authorized access subject to that memory space. In this way, on the one hand, by functionally separating and layering global memory, the memory operations of instruction execution, data storage, and temporary caching are each performed in their own way, thus avoiding security risks such as tampering and illegal execution caused by the mixed storage of instructions and data from the bottom layer; on the other hand, by using encrypted storage of smart contracts, the memory space of the first smart contract is completely isolated, ensuring that the first smart contract can only access its own bound memory partition, strictly preventing illegal memory access across contracts and regions, building a solid memory isolation security barrier for contract execution, and further improving the security and stability of smart contract execution.

[0059] In one embodiment of this application, the process of executing the decrypted first smart contract in a memory partition according to a preset access permission includes: executing the execution instructions in the first smart contract one by one in the memory partition, and during the execution of each execution instruction, verifying whether the access operation corresponding to the execution instruction belongs to the operation type in the preset access permission; if the access operation corresponding to the execution instruction belongs to the operation type in the preset access permission, then the access operation corresponding to the execution instruction is executed in the memory partition; if the access operation corresponding to the execution instruction does not belong to the operation type in the preset access permission, then the execution of the execution instruction is stopped.

[0060] Specifically, an execution instruction is the smallest executable unit that constitutes the business logic of the first smart contract, including data access instructions, computation instructions, flow control instructions, and other types. Each execution instruction in the first smart contract corresponds to a specific access operation, which refers to the specific operation behavior initiated by the execution instruction on the memory partition of the first smart contract, specifically including read operations, write operations, code execution operations, and other operation types.

[0061] For example, the operation type verification method can be as follows: First, parse the operation semantics of the execution instruction to clarify the specific operation type to be executed and the memory partition address range of the operation target; then, query in real time the preset access permissions bound to the memory partition corresponding to the first smart contract, and extract the set of allowed operation types as the judgment benchmark; next, compare the actual operation type of the execution instruction with the operation type benchmark set of the memory partition one by one to determine whether the actual operation type is included in the allowed operation type range, and at the same time compare whether the access address of the operation is strictly limited to the virtual address range of the exclusive memory partition of this contract. If the comparison results are consistent and the address range is valid, it is determined that the preset access permission requirements are met. At this time, the current execution instruction is allowed to complete all computation logic, and after the execution is completed, the next execution instruction is loaded and started, and the process of "running + verification" continues until all instructions of the contract are executed or the termination condition is triggered. When the comparison result is "does not meet the preset access permissions", the sandbox will immediately interrupt the execution of the current instruction, release the memory resources occupied by the instruction, and stop loading any subsequent execution instructions. At the same time, it will generate an unauthorized access log (recording the instruction content, the illegal access address, timestamp, etc.) to block illegal unauthorized operations from the execution stage.

[0062] This embodiment strictly limits the execution of instructions to only run within the contract's dedicated memory partition by synchronously verifying the access scope and preset access permissions throughout the entire instruction execution process. Once unauthorized access is detected, the instruction execution is immediately terminated. This not only eliminates illegal memory access across contracts and regions at the execution stage, but also ensures the compliance and security of smart contract instruction execution.

[0063] For example, during the execution of the above instructions, a second encryption key can be generated for the first smart contract through the quantum-resistant cryptographic algorithm module; then, based on the second encryption key, the temporary data, executed instructions and intermediate results generated during the execution of the first smart contract are encrypted; then, the encrypted temporary data, executed instructions and intermediate results are stored in the temporary cache partition in the memory partition.

[0064] Specifically, the second encryption key is generated by the anti-quantum cryptography algorithm module in the sandbox relying on the anti-quantum cryptography algorithm layer. It is uniquely bound to the first smart contract, and is only compatible with the dynamic data encryption and decryption operations of this contract. It is not shared with other smart contracts and has uniqueness, exclusivity and timeliness. It will be destroyed immediately after the contract is executed or terminated.

[0065] Temporary data refers to auxiliary data that is temporarily generated and not persistently stored during the execution of instructions by the first smart contract. It is only used to support the calculation and execution of the current instruction, has no long-term storage value, and will be cleared when the instruction is completed or the contract is terminated. Executed instructions are those that have already been executed in the first smart contract. Encrypting executed instructions can effectively prevent malicious entities from illegally stealing and reverse-analyzing them when they are stored in plaintext in the first smart contract's dedicated memory partition (especially the temporary cache partition). This prevents the leakage of key information such as the contract's core business logic and execution process, and avoids targeted cracking or malicious attacks on the contract. Intermediate results are the stage-wise calculation data generated by the first smart contract when executing computational instructions, before the final result is generated. They are intermediate data connecting the original data and the final execution result, and only exist during the contract execution process. They need to be encrypted in real time as the execution progresses to prevent data leakage or tampering.

[0066] This embodiment encrypts all temporary data, execution instructions, and intermediate results generated during contract execution, ensuring that the dynamic data of the contract exists in encrypted form throughout the entire process. This avoids the security risks of the dynamic data being stolen or tampered with during transmission and caching. Combined with the aforementioned memory partitioning isolation and access control, it forms a full lifecycle encryption protection system from data generation to use, further enhancing the confidentiality and integrity of data during contract execution.

[0067] In one embodiment of this application, the execution efficiency of the first smart contract can also be monitored during instruction execution; if the number of execution instructions completed by the first smart contract within a unit time is lower than a first preset threshold, or the execution time of each execution instruction is higher than a second preset threshold, then the execution of the first smart contract is stopped.

[0068] Specifically, execution efficiency reflects the running speed and performance level of a smart contract during execution, which may include the number of execution instructions completed per unit time or the execution time of each instruction.

[0069] The first preset threshold is a pre-configured minimum compliance threshold for the number of executed instructions completed per unit time, which is pre-set by the sandbox based on factors such as the business type, contract complexity, and system resource configuration of the first smart contract. The second preset threshold is a pre-configured maximum compliance threshold for the execution time of each executed instruction.

[0070] For example, if the number of execution instructions completed by the first smart contract within a unit of time is less than a first preset threshold, or the execution time of each instruction is greater than a second preset threshold, it is considered an execution anomaly. In this case, a forced termination instruction needs to be sent to the instruction execution module, simultaneously blocking the loading and execution of subsequent instructions. Upon receiving the termination instruction, the instruction execution module will immediately interrupt the currently running instructions and stop the scheduling and execution of all subsequent instructions for that contract, ensuring the immediate halt of the contract execution process. Simultaneously, the system can also trigger a memory resource release operation, encrypting and cleaning up the temporarily cached dynamic data and intermediate computation results in the dedicated memory partition corresponding to the smart contract, and releasing the system memory and computing resources occupied during instruction execution and data storage to prevent inefficient execution from continuously consuming resources and affecting the operation of other contracts. Finally, an execution termination log is automatically generated, fully recording information such as the contract identifier, termination time, inefficiency judgment criteria, and resource usage, and the termination result is fed back to the contract management module of the blockchain node, completing the entire shutdown process.

[0071] In one embodiment of this application, if the execution instruction of the first smart contract needs to call the second smart contract, a call request is generated according to the execution instruction; a call signature is generated according to the call request and the first smart contract, and the call signature and the call request are sent to the memory partition corresponding to the second smart contract.

[0072] Specifically, the second smart contract refers to another smart contract deployed in the blockchain system sandbox environment that needs to be invoked by the first smart contract during the execution of instructions due to business logic requirements. The memory partition of the second smart contract is different from that of the first smart contract.

[0073] The call request is a business execution application data body generated by the first smart contract based on the cross-contract call instruction to be executed and sent to the second smart contract. It contains essential information such as the contract identifier / address of the second smart contract, the name / identifier of the function to be called, the function input parameter information, and the execution context of the caller.

[0074] A call signature is a quantum-resistant identifier generated by the blockchain system based on the information of the first smart contract initiating the call and the call request, relying on a quantum-resistant cryptographic algorithm layer. It can be obtained by encrypting the hash value of "first smart contract identifier + call request" using the exclusive encryption key of the first smart contract stored in the system. It has uniqueness and is not forgeable. It is used by the second smart contract to verify the legality of the call request and confirm the identity of the caller.

[0075] For example, the call signature and call request can be sent to the memory partition of the second smart contract by first establishing a quantum-resistant cryptographic channel between the memory partition of the first smart contract and the memory partition of the second smart contract through a quantum-resistant cryptographic algorithm module; the quantum-resistant cryptographic channel is used to encrypt the transmission of the call signature and call request; then, the call signature and call request are encrypted and sent to the memory partition of the second smart contract through the cryptographic channel.

[0076] Specifically, the quantum-resistant encryption channel is a point-to-point dedicated encrypted data transmission link built upon the quantum-resistant cryptographic algorithm module in the quantum-resistant cryptographic algorithm layer. This link is isolated from the transmission links between other contracts and is used only to carry interactive data such as call signatures, call requests, and execution results between the first and second smart contracts. It possesses the characteristics of exclusivity, isolation, and end-to-end encryption, with no third-party access rights. For example, the channel can rely on the built-in quantum-resistant encryption algorithm to perform real-time end-to-end encryption operations on call signatures and call requests during transmission. Encryption is completed before the data is sent from the memory partition of the first smart contract, and it can only be decrypted by a dedicated key after arriving at the memory partition of the second smart contract and written to the authorized memory address range (such as a temporary cache partition) preset by the second smart contract. In this way, the data during transmission always exists in encrypted form, which can prevent the interactive data from being stolen, tampered with, or intercepted.

[0077] In one embodiment of this application, after receiving the call signature and call request in the memory partition of the second smart contract, the validity of the call signature is verified; if the call signature is valid, the second smart contract is executed according to the call request, and the execution result is sent to the memory partition of the first smart contract through an encrypted channel; if the call signature is invalid, the call request is rejected.

[0078] Specifically, the validity verification operation of the call signature can be to extract the core information of the call signature, and decrypt and parse the signature in combination with the public key / exclusive verification parameters of the first smart contract. At the same time, the hash matching degree of the signature and the call request and the compliance of the caller's identity are compared to determine whether the call signature is legally generated and has not been tampered with.

[0079] If the verification result indicates that the call signature is valid, the corresponding business logic is executed according to the received call request, and the final business processing data (execution result) is generated. This data may include the request processing result, business feedback information, compliance judgment identifier, etc. After execution, the execution result is encrypted again in real time through the quantum-resistant encryption channel established between the first and second smart contracts and transmitted to the dedicated memory partition of the first smart contract, ensuring that only the first smart contract can decrypt and read it, thereby ensuring the confidentiality and directionality of the returned data. If the verification result indicates that the call signature is invalid, the received call signature and call request are discarded directly, no corresponding business logic is executed, and no execution result is generated. At the same time, a call rejection log is generated and fed back to the blockchain system to block illegal cross-contract call behavior from the callee level.

[0080] This embodiment first establishes a point-to-point quantum-resistant encrypted channel for the dedicated memory partitions of the first and second smart contracts. Then, based on the first smart contract and the call request, it generates a unique, unforgeable call signature. This signature and request are then transmitted via the encrypted channel to the memory partition of the second smart contract. The corresponding logic is only executed after the second smart contract verifies the validity of the call signature; otherwise, the request is directly rejected. This design achieves end-to-end encryption protection for the call data at the transmission level through the encrypted channel, eliminating the risk of data leakage and tampering. At the verification level, the call signature verification ensures the legitimacy of the caller's identity and the authenticity of the request, intercepting illegal cross-contract calls at the source. Furthermore, the entire call process strictly adheres to memory isolation and access control rules, with call data flowing only between the dedicated memory partitions of both parties, avoiding memory access violations caused by cross-contract calls.

[0081] Figure 3 A flowchart illustrating the execution method of a smart contract provided in an embodiment of this application is shown schematically. Figure 3 As shown, the smart contract execution method provided in this embodiment specifically includes steps 501 to 3.

[0082] Step 301: Initialize the sandbox. Start the underlying logical volume management module of the operating system to prepare for the persistent and isolated storage of smart contracts; start the quantum-resistant cryptographic algorithm layer, loading the pre-integrated quantum-resistant cryptographic algorithm module, including quantum-resistant encryption and quantum-resistant signature algorithms; the quantum-resistant cryptographic algorithm layer automatically completes the initialization configuration of quantum-resistant encryption parameters, such as configuring the key length of the Kyber algorithm to 2048 bits and the signature length of the Dilithium algorithm to 832 bits; start the instruction-level memory isolation mechanism, based on the memory management capabilities of the operating system kernel, dividing the system memory into independent instruction execution memory areas, data storage memory areas, and temporary cache areas for the sandbox, and completing the virtual address mapping and hierarchical access permission configuration for each memory area.

[0083] Step 302: Receive the first smart contract and verify its digital signature. Receive the first smart contract to be deployed or executed. This contract contains contract code, dependency files, initial configuration data, and a digital signature generated by the contract deployer. Call the quantum-resistant cryptographic algorithm layer to verify the validity of the digital signature carried by the contract using the contract deployer's public key. If the digital signature is valid, it indicates that the contract's origin is trustworthy and has not been tampered with, and the subsequent deployment process continues; if the digital signature is invalid, the deployment of the contract is directly rejected.

[0084] Step 303: After successful verification, partition the memory for the first smart contract. Partition the instruction execution memory area from the pre-defined instruction execution memory area in step 301, partition the data storage memory area, and partition the temporary cache area.

[0085] Step 304: Encrypt the first smart contract and store the encrypted first smart contract in the memory partition. Call the CRYSTALS-Kyberv3.0 encryption module in the pre-loaded quantum-resistant cryptography algorithm layer within the sandbox, and generate the first encryption key using the pre-initialized 2048-bit key parameters. Then, use the first encryption key to fully encrypt all content of the first smart contract, including its complete code and initial configuration data. Next, accurately store the encrypted contract code in the allocated instruction execution memory partition, and store the encrypted initial configuration data in the corresponding data storage memory partition.

[0086] Step 305: Begin executing the first smart contract in the memory partition. Execute the instructions in the first smart contract one by one in the memory partition. During the execution of each instruction, verify in real time whether the access scope of the instruction complies with the preset access permissions, ensuring that the instruction can only access the instruction execution memory partition, data storage memory partition, and temporary cache partition allocated to its contract. If the instruction access scope complies with the preset access permissions, execution is allowed to continue; otherwise, execution is stopped immediately. Simultaneously, during execution, a quantum-resistant cryptographic algorithm layer is invoked to encrypt the temporary data generated by the contract, execution instructions, and intermediate computation results in real time.

[0087] Step 306: The first smart contract generates a call request to invoke the second smart contract. During the execution of the first smart contract, when an instruction requiring the invocation of the second smart contract is encountered, a call request is generated based on that instruction. The call request includes at least the contract identifier / address of the second smart contract, the name / identifier of the function to be called, the function input parameter information, and the execution context of the caller.

[0088] Step 307: Generate a call signature based on the call request. Using the private key of the first smart contract, perform a signature operation on the call request packet and the identity information of the first smart contract to generate a unique dynamic signature. This signature is unique and dynamic, and the call signature generated for each cross-contract call is different.

[0089] Step 308: Send the call request and call signature through the encrypted channel. A quantum-resistant cryptographic algorithm layer is invoked to establish a quantum-resistant encrypted channel. Then, the memory partition of the first smart contract sends the generated call request and call signature to the memory partition of the second smart contract through this encrypted channel.

[0090] Step 309: The second smart contract receives and executes the call request. The second smart contract's dedicated memory partition receives the encrypted call request and call signature, and invokes a quantum-resistant cryptographic verification algorithm. Using the first smart contract's public key, it decrypts and parses the call signature, comparing the hash match between the signature and the call request, verifying the caller's identity and compliance, and completing the validity check of the call signature. If the check is invalid, the call request and signature are discarded, the call is rejected, and the process is fed back to the first smart contract and terminated. If the check is successful, the call request is executed. Within its dedicated memory partition, the second smart contract, based on the specific business instructions and parameters in the call request, completes the corresponding business operation according to its own execution logic. The execution process also follows the relevant rules of memory isolation, permission verification, and dynamic data encryption, ultimately generating an execution result containing the request processing result and business feedback information.

[0091] Step 310: The execution result is sent back to the memory partition of the first smart contract via an encrypted channel. After the second smart contract completes its execution, it encapsulates the execution result and then sends it back to the memory partition of the first smart contract via a quantum-resistant encryption channel. After the sandbox of the first smart contract receives and decrypts the execution result, it continues to execute subsequent instructions until execution is complete.

[0092] This application's technical solution constructs a full-chain security protection system for smart contracts through a comprehensive design encompassing sandbox initialization, contract signature verification, dedicated memory partitioning, instruction execution control, and encrypted cross-contract calls. It eliminates issues such as unauthorized contract deployment, unauthorized access, and data leakage through digital signature verification, memory partitioning isolation, and dynamic encryption. Furthermore, it achieves secure cross-contract interaction through dedicated encrypted channels and call signature verification. This effectively addresses the pain points of traditional smart contract execution, such as memory sharing, easy data leakage, and high risks associated with cross-contract calls, balancing contract execution security, standardization, and system resource utilization.

[0093] It should be noted that although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0094] The following describes an embodiment of the apparatus of this application, which can be used to execute the system interface update method in the above embodiments of this application. Figure 4 A schematic block diagram of the contract execution device provided in an embodiment of this application is shown. Figure 4 As shown, the contract execution device provided in this application embodiment includes: The memory allocation module 410 is used to receive a first smart contract and allocate a memory partition for the first smart contract; wherein, the memory partition includes a preset access permission, which is used to indicate the types of operations that are allowed to be performed by the memory partition; The encrypted storage module 420 is used to encrypt the first smart contract using a quantum-resistant cryptographic algorithm module and store the encrypted first smart contract in the memory partition; the quantum-resistant cryptographic algorithm module includes a functional module for executing the quantum-resistant cryptographic algorithm. The instruction execution module 430 is used to decrypt the first smart contract and execute the decrypted first smart contract in the memory partition according to the preset access permissions.

[0095] In one embodiment of this application, the memory allocation module 410 is specifically used for: Verify the validity of the digital signature in the first smart contract; If the digital signature is valid, three memory areas are allocated from the system memory, and each memory area is assigned a corresponding virtual address and preset access permissions; the three memory areas are the instruction execution memory area, the data storage memory area, and the temporary cache area. From each memory region, corresponding memory partitions are divided for the first smart contract to obtain an instruction execution memory partition, a data storage memory partition, and a temporary cache partition. The preset access permissions for the instruction execution memory partition indicate that read and code execution operations are allowed. The preset access permissions for the data storage memory partition indicate that read and write operations are allowed. The preset access permissions for the temporary cache partition indicate that temporary read and write operations are allowed.

[0096] In one embodiment of this application, the encrypted storage module 420 is specifically used for: The first encryption key is generated for the first smart contract based on the quantum-resistant cryptographic algorithm module; The contract code and initial configuration data of the first smart contract are encrypted using the first encryption key. The encrypted contract code is stored in the instruction execution memory partition of the memory partition, and the encrypted initial configuration data is stored in the data storage memory partition of the memory partition.

[0097] In one embodiment of this application, the instruction execution module 430 is specifically used for: The execution instructions in the first smart contract are executed one by one within the memory partition, and during the execution of each execution instruction, it is verified whether the access operation corresponding to the execution instruction belongs to the operation type in the preset access permissions. If the access operation corresponding to the execution instruction belongs to the operation type in the preset access permissions, then the access operation corresponding to the execution instruction is executed in the memory partition; If the access operation corresponding to the execution instruction does not belong to the operation type in the preset access permissions, then the execution instruction will be stopped.

[0098] In one embodiment of this application, the instruction execution module 430 is specifically used for: The quantum-resistant cryptographic algorithm module generates a second encryption key for the first smart contract. The temporary data, execution instructions, and intermediate calculation results generated during the execution of the first smart contract are encrypted using the second encryption key. The encrypted temporary data, executed instructions, and intermediate results of the operation are stored in the temporary cache partition in the memory partition.

[0099] In one embodiment of this application, the instruction execution module 430 is specifically used for: Monitor the execution efficiency of the first smart contract; the execution efficiency includes the number of execution instructions completed per unit time or the execution time of each execution instruction; If the number of execution instructions completed by the first smart contract within a unit of time is less than a first preset threshold, or the execution time of each execution instruction is greater than a second preset threshold, then the execution of the first smart contract will be stopped.

[0100] In one embodiment of this application, the instruction execution module 430 is specifically used for: If the execution instruction in the first smart contract needs to call the second smart contract, a call request is generated based on the execution instruction; the call request includes information about the second smart contract to be called by the execution instruction. A call signature is generated based on the call request and the first smart contract, and the call signature and the call request are sent to the memory partition corresponding to the second smart contract.

[0101] In one embodiment of this application, the instruction execution module 430 is specifically used for: The quantum-resistant cryptographic algorithm module establishes a quantum-resistant encryption channel between the memory partitions of the first smart contract and the second smart contract; the quantum-resistant encryption channel is used to encrypt and transmit the call signature and the call request. The call signature and the call request are encrypted and sent to the memory partition of the second smart contract through the encrypted channel.

[0102] In one embodiment of this application, the instruction execution module 430 is specifically used for: After receiving the call signature and the call request in the memory partition of the second smart contract, the validity of the call signature is verified. If the call signature is valid, the second smart contract is executed according to the call request, and the execution result is sent to the memory partition of the first smart contract through the encrypted channel; If the call signature is invalid, the call request will be rejected.

[0103] The specific details of the address mapping device provided in the various embodiments of this application have been described in detail in the corresponding method embodiments, and will not be repeated here.

[0104] Figure 5 A schematic diagram of the computer system architecture used to implement the technical solution of this application is shown.

[0105] It should be noted that, Figure 5 The computer system 500 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0106] like Figure 5As shown, the computer system 500 includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 502 or programs loaded from storage section 507 into random access memory (RAM). The random access memory 503 also stores various programs and data required for system operation. The CPU 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output interface 505 (I / O interface) is also connected to the bus 504.

[0107] The following components are connected to the input / output interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a local area network card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the input / output interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 510 as needed so that computer programs read from it can be installed into the storage section 508 as needed.

[0108] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0109] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0110] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0111] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0112] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0113] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for executing a smart contract, characterized in that, include: The system receives a first smart contract and allocates a memory partition for the first smart contract; wherein the memory partition includes a preset access permission, which is used to indicate the types of operations allowed to be performed on the memory partition; the types of operations include at least one of read operations, write operations, and code execution operations; The first smart contract is encrypted using a quantum-resistant cryptographic algorithm module, and the encrypted first smart contract is stored in the memory partition; the quantum-resistant cryptographic algorithm module includes a functional module for executing the quantum-resistant cryptographic algorithm. The first smart contract is decrypted, and the decrypted first smart contract is executed in the memory partition according to the preset access permissions.

2. The method for executing a smart contract according to claim 1, characterized in that, The process of allocating a memory partition for the first smart contract includes: Verify the validity of the digital signature in the first smart contract; If the digital signature is valid, three memory areas are allocated from the system memory, and each memory area is assigned a corresponding virtual address and preset access permissions; the three memory areas are the instruction execution memory area, the data storage memory area, and the temporary cache area. From each memory region, corresponding memory partitions are divided for the first smart contract to obtain an instruction execution memory partition, a data storage memory partition, and a temporary cache partition. The preset access permissions for the instruction execution memory partition indicate that read and code execution operations are allowed. The preset access permissions for the data storage memory partition indicate that read and write operations are allowed. The preset access permissions for the temporary cache partition indicate that temporary read and write operations are allowed.

3. The method for executing a smart contract according to claim 2, characterized in that, The step of encrypting the first smart contract using a quantum-resistant cryptographic algorithm module and storing the encrypted first smart contract in the memory partition includes: The first encryption key is generated for the first smart contract based on the quantum-resistant cryptographic algorithm module; The contract code and initial configuration data of the first smart contract are encrypted using the first encryption key. The encrypted contract code is stored in the instruction execution memory partition of the memory partition, and the encrypted initial configuration data is stored in the data storage memory partition of the memory partition.

4. The method for executing a smart contract according to claim 1, characterized in that, The execution of the decrypted first smart contract in the memory partition according to the preset access permissions includes: The execution instructions in the first smart contract are executed one by one within the memory partition, and during the execution of each execution instruction, it is verified whether the access operation corresponding to the execution instruction belongs to the operation type in the preset access permissions. If the access operation corresponding to the execution instruction belongs to the operation type in the preset access permissions, then the access operation corresponding to the execution instruction is executed in the memory partition; If the access operation corresponding to the execution instruction does not belong to the operation type in the preset access permissions, then the execution instruction will be stopped.

5. The method for executing a smart contract according to claim 1, characterized in that, During the execution of the decrypted first smart contract in the memory partition according to the preset access permissions, the method further includes: The quantum-resistant cryptographic algorithm module generates a second encryption key for the first smart contract. The temporary data, execution instructions, and intermediate calculation results generated during the execution of the first smart contract are encrypted using the second encryption key. The encrypted temporary data, executed instructions, and intermediate results of the operation are stored in the temporary cache partition in the memory partition.

6. The method for executing a smart contract according to claim 1, characterized in that, During the execution of the decrypted first smart contract in the memory partition according to the preset access permissions, the method further includes: Monitor the execution efficiency of the first smart contract; the execution efficiency includes the number of execution instructions completed per unit time or the execution time of each execution instruction; If the number of execution instructions completed by the first smart contract within a unit of time is less than a first preset threshold, or the execution time of each execution instruction is greater than a second preset threshold, then the execution of the first smart contract will be stopped.

7. The method for executing a smart contract according to claim 1, characterized in that, During the execution of the decrypted first smart contract in the memory partition according to the preset access permissions, the method further includes: If the execution instruction in the first smart contract needs to call the second smart contract, a call request is generated based on the execution instruction; the call request includes information about the second smart contract to be called by the execution instruction. A call signature is generated based on the call request and the first smart contract, and the call signature and the call request are sent to the memory partition corresponding to the second smart contract.

8. The method for executing a smart contract according to claim 7, characterized in that, Sending the call signature and the call request to the memory partition of the second smart contract includes: The quantum-resistant cryptographic algorithm module establishes a quantum-resistant encryption channel between the memory partitions of the first smart contract and the second smart contract; the quantum-resistant encryption channel is used to encrypt and transmit the call signature and the call request. The call signature and the call request are encrypted and sent to the memory partition of the second smart contract through the encrypted channel.

9. The method for executing a smart contract according to claim 7, characterized in that, After sending the call signature and the call request to the memory partition of the second smart contract, the method further includes: After receiving the call signature and the call request in the memory partition of the second smart contract, the validity of the call signature is verified. If the call signature is valid, the second smart contract is executed according to the call request, and the execution result is sent to the memory partition of the first smart contract through the encrypted channel; If the call signature is invalid, the call request will be rejected.

10. A smart contract execution system, characterized in that, include: Sandbox; The system also includes a memory allocation module, an encrypted storage module, and an instruction execution module deployed within the sandbox. The memory allocation module receives a first smart contract and allocates a memory partition for it. The memory partition includes preset access permissions, which indicate the types of operations allowed to be performed on the memory partition. The encrypted storage module is used to encrypt the first smart contract using a quantum-resistant cryptographic algorithm module and store the encrypted first smart contract in the memory partition; the instruction execution module is used to decrypt the first smart contract and execute the decrypted first smart contract in the memory partition according to the preset access permissions.

Images