Blockchain contract processing method and apparatus, electronic device, and storage medium

Abstract

The present disclosure provides a blockchain contract processing method and device, electronic equipment and storage medium, comprising: loading N candidate smart contracts in batches from the to-be-processed smart contracts; in response to identifying that the candidate smart contract needs to perform a target external data read-write operation, judging whether the target external data exists in the local cache; in response to the target external data not existing in the local cache, performing saving processing on the first execution context data of the candidate smart contract, and determining a target contract from the to-be-processed smart contracts except the N candidate smart contracts; replacing the target contract with the candidate smart contract, and loading the target contract to the execution slot of the execution memory corresponding to the candidate smart contract, and executing the target contract. When it is found that the candidate smart contract needs to wait for the database to return, the context is saved and the execution is switched, avoiding the idling of the execution unit, improving the hardware utilization rate, and at the same time, by supporting batch preloading, the cache hit rate and execution continuity are improved.

Description

Technical Field

[0001] This disclosure relates to the field of blockchain technology, and in particular to a blockchain contract processing method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the continuous development and maturation of blockchain technology, smart contracts on the blockchain are finding increasingly wider applications. Blockchain can be viewed as a special shared database, characterized by data or information stored within it that is unforgeable, traceable, and collectively maintained. Building a digital "trust" foundation based on blockchain technology and incorporating it into future digital infrastructure can provide a solid "trust" platform for digital entities, construct reliable "cooperation" mechanisms, and, combined with specific applications across various industries, has broad prospects for application.

[0003] Traditionally, data in a blockchain is stored using LevelDB, accessed via key-value pairs. LevelDB typically uses a Log Structured-Merge Tree (LSM) implementation. The core idea of ​​LSM is to sacrifice some read performance for maximum write capability. The reason for LSM's extremely high write performance can be simply explained by minimizing random writes. For each write operation, instead of directly storing the latest data on disk, it is split into a sequential write to the log file and a data insertion into memory. Summary of the Invention

[0004] This disclosure aims to at least partially address one of the technical problems in the related art.

[0005] Therefore, one objective of this disclosure is to propose a blockchain contract processing method.

[0006] The second objective of this disclosure is to propose a blockchain contract processing device.

[0007] The third objective of this disclosure is to propose an electronic device.

[0008] The fourth objective of this disclosure is to provide a non-transitory computer-readable storage medium.

[0009] The fifth objective of this disclosure is to provide a computer program product.

[0010] To achieve the above objectives, a first aspect of this disclosure provides a blockchain contract processing method, comprising: in response to batch processing of smart contracts, loading N candidate smart contracts from a pool of pending smart contracts and loading the N candidate smart contracts into execution memory; for any candidate smart contract, in response to identifying that the candidate smart contract needs to perform target external data read / write operations, determining whether the target external data exists in a local cache; in response to the target external data not existing in the local cache, saving the first execution context data of the candidate smart contract and determining a target contract from the pending smart contracts other than the N candidate smart contracts; replacing the candidate smart contract with the target contract and loading it into the execution slot of the execution memory corresponding to the candidate smart contract, and executing the target contract.

[0011] According to one embodiment of this disclosure, the process of saving the first execution context data of the candidate smart contract includes saving the CPU state, heap pointer, stack pointer and data space of the candidate smart contract.

[0012] According to one embodiment of this disclosure, after saving the first execution context data of the candidate smart contract, the method further includes: performing read and write operations on the target external data.

[0013] According to one embodiment of this disclosure, determining the target contract from the pending smart contracts other than the N candidate smart contracts includes: determining whether a first contract exists from the pending smart contracts other than the N candidate smart contracts, wherein the first contract does not require external data read / write operations; and in response to the existence of at least one first contract, selecting a target first contract from the first contracts as the target contract.

[0014] According to one embodiment of this disclosure, the method further includes: in response to the absence of the first contract among the pending smart contracts other than the N candidate smart contracts, determining whether a second contract exists among the pending smart contracts other than the N candidate smart contracts, wherein the external data of the second contract is stored in the local cache; and in response to the existence of at least one second contract, selecting a target second contract from the second contracts as the target contract.

[0015] According to one embodiment of this disclosure, a target contract is selected from a pool of candidate contracts, wherein the candidate contract is either the first contract or the second contract. When the candidate contract is the first contract, the target contract is the target first contract. When the candidate contract is the second contract, the target contract is the target second contract. This includes selecting the candidate contract with the longest waiting time or the candidate contract with the highest execution priority as the target contract.

[0016] According to one embodiment of this disclosure, executing the target contract includes: determining whether the target contract has saved second execution context data; and executing the target contract based on the second execution context data in response to the existence of saved second execution context data.

[0017] According to one embodiment of this disclosure, the smart contract is executed in a hardware virtual machine, which is implemented using an FPGA or an ASIC.

[0018] To achieve the above objectives, a second aspect of this disclosure provides a blockchain contract processing apparatus, comprising: a loading module, configured to, in response to batch processing of smart contracts, batch load N candidate smart contracts from a pool of smart contracts to be processed, and load the N candidate smart contracts into execution memory; a judging module, configured to, for any candidate smart contract, in response to identifying that the candidate smart contract requires a target external data read / write operation, judge whether the target external data exists in a local cache; a processing module, configured to, in response to the target external data not existing in the local cache, save the first execution context data of the candidate smart contract, and determine a target contract from the pool of smart contracts to be processed other than the N candidate smart contracts; and an execution module, configured to replace the candidate smart contracts with the target contract, load the target contract into the execution slot of the execution memory corresponding to the candidate smart contract, and execute the target contract.

[0019] To achieve the above objectives, a third aspect of this disclosure provides an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to implement the blockchain contract processing method as described in the first aspect of this disclosure.

[0020] To achieve the above objectives, a fourth aspect of this disclosure provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to implement the blockchain contract processing method as described in the first aspect of this disclosure.

[0021] To achieve the above objectives, a fifth aspect of this disclosure provides a computer program product, including a computer program that, when executed by a processor, implements the blockchain contract processing method as described in the first aspect of this disclosure.

[0022] Therefore, when a candidate smart contract is found to need to wait for the database to return, the context is saved and execution is switched to avoid the execution unit running idle, improve hardware utilization, and at the same time improve cache hit rate and execution continuity by supporting batch preloading. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of a blockchain contract processing method according to one embodiment of the present disclosure;

[0024] Figure 2 This is a schematic diagram of another blockchain contract processing method according to one embodiment of the present disclosure;

[0025] Figure 3 This is a schematic diagram of another blockchain contract processing method according to one embodiment of the present disclosure;

[0026] Figure 4 This is a schematic diagram of another blockchain contract processing method according to one embodiment of the present disclosure;

[0027] Figure 5 This is a schematic diagram of another blockchain contract processing method according to one embodiment of the present disclosure;

[0028] Figure 6 This disclosure presents an architecture diagram of a smart contract execution system;

[0029] Figure 7 This is a schematic diagram illustrating the overall process of a blockchain contract processing method disclosed herein.

[0030] Figure 8 This is a schematic diagram of a blockchain contract processing device according to one embodiment of the present disclosure;

[0031] Figure 9 This is a schematic diagram of an electronic device according to one embodiment of the present disclosure. Detailed Implementation

[0032] Embodiments of this disclosure are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this disclosure, and should not be construed as limiting this disclosure.

[0033] The acquisition, storage, use, and processing of data in this disclosed technical solution all comply with the relevant provisions of relevant laws and regulations.

[0034] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0035] In current technology, the key factor affecting blockchain performance is the execution speed of smart contracts. Traditional smart contract execution is achieved through smart contract virtual machines (VMs). However, because these VMs use software interpretation or simulation, they suffer from slow speed and low execution efficiency. Therefore, the current trend is towards using hardware VMs to improve contract execution efficiency. This is achieved by deploying multiple hardware VMs to execute smart contracts in parallel, thereby improving overall efficiency.

[0036] When executing contracts on a blockchain, it's often necessary to read the blockchain's state database, write the execution results, and record state updates. Traditionally, retrieving data from the blockchain is recorded as a GetState operation, while recording data or state on the blockchain is recorded as a PutState operation. Furthermore, it's also necessary to perform permission authentication or provide authorization based on user attributes. Therefore, interaction with the blockchain's main chain data is an indispensable step in the execution process.

[0037] In traditional blockchain execution, the response time from issuing a key-value (KV) request from the hardware virtual machine (VM) to obtaining the corresponding block data is typically more than 1ms. During this time, the execution unit of the hardware VM is blocked and waiting for data until the blockchain data is returned, resulting in low contract execution efficiency.

[0038] To address the aforementioned issues, this disclosure proposes a blockchain contract processing method. Figure 1 This is a schematic diagram of a blockchain contract processing method according to one embodiment of the present disclosure, as shown below. Figure 1 As shown, this blockchain contract processing method includes the following steps:

[0039] S101, in response to batch processing of smart contracts, loads N candidate smart contracts from the pending smart contracts and loads the N candidate smart contracts into the execution memory.

[0040] The blockchain contract processing method of this application embodiment can be applied to the scenario of batch processing of blockchain contracts. The execution subject of the blockchain contract processing of this application embodiment can be the blockchain contract processing device of this application embodiment, which can be installed on an electronic device.

[0041] In this embodiment of the disclosure, when the system detects that there are multiple contracts to be executed and the number of contracts to be executed exceeds the judgment value, the "batch execution mode" is triggered, which loads N candidate smart contracts from storage into execution memory at one time, reducing I / O overhead.

[0042] In this embodiment of the disclosure, an independent memory region is allocated to each candidate smart contract to ensure that the execution of each candidate smart contract is isolated and the state is independent.

[0043] It should be noted that candidate smart contracts refer to contracts that have been selected from the pending queue and are ready for execution or are being scheduled. In this embodiment of the disclosure, candidate smart contracts may be randomly selected from the pending smart contracts, or they may be selected according to certain rules; no limitations are made here. For example, N candidate smart contracts may be selected according to execution priority, or N candidate smart contracts may be selected according to whether they can be executed quickly, etc.

[0044] S102, for any candidate smart contract, in response to the identification that the candidate smart contract needs to perform target external data read / write operations, determine whether the target external data exists in the local cache.

[0045] It should be noted that target external data refers to state data required for the execution of the candidate smart contract but not in the current context. For example, target external data can be account balance, contract storage items, etc.

[0046] Local caching is a temporary data area located in memory or high-speed storage, used to accelerate key-value database access. If the target external data exists in the local cache, network or disk I / O waits can be avoided, reducing response time from milliseconds to microseconds or even nanoseconds. At the same time, it can avoid duplicate queries and reduce the load on the backend key-value database (such as LevelDB).

[0047] If the target external data does not exist in the local cache, it needs to be read and written from the local solid state drive (SSD) / KV database, which is limited by disk I / O and LSM tree lookup.

[0048] S103, in response to the fact that the target external data does not exist in the local cache, the first execution context data of the candidate smart contract is saved, and the target contract is determined from the pending smart contracts other than the N candidate smart contracts.

[0049] In current technology, during blockchain execution, the response time from when the hardware VM sends a key-value request to when the corresponding block data is obtained is typically more than 1ms. During this time, the execution unit of the hardware VM is in a blocked waiting state for data until the blockchain data is returned.

[0050] The above methods are limited by the number of I / O read / write operations and I / O performance. When a contract exists... Each external read / write operation takes a time of [time value missing]. If the mode of not exiting and directly waiting for I / O results is adopted, the waiting time is [time value missing]. If an unbuffered execution is used, the program will exit and wait for I / O data to be obtained before re-execution. In this case, the program needs to be run again. Therefore, traditional smart contracts have a relatively slow execution time and are limited by the number of I / O read and write operations.

[0051] After determining that the target external data does not exist in the local cache, this disclosure saves the corresponding candidate smart contract and selects a new target contract to replace it for execution.

[0052] It should be noted that the first execution context data of the candidate smart contract is saved for subsequent restoration. This execution context may include various types of data, such as program counter, stack pointer, heap state, etc.

[0053] S104: Replace the candidate smart contract with the target contract and load it into the execution slot of the execution memory corresponding to the candidate smart contract, and execute the target contract.

[0054] In this embodiment of the disclosure, by loading the target contract into the execution slot of the execution memory corresponding to the candidate smart contract, the execution slot can be reused, eliminating the need to pre-allocate memory for each contract, while ensuring that there are always tasks running in the execution memory, thus improving utilization.

[0055] In this embodiment, in response to batch processing of smart contracts, N candidate smart contracts are loaded from the list of smart contracts to be processed and loaded into the execution memory. Then, for any candidate smart contract, in response to the detection that the candidate smart contract needs to perform target external data read / write operations, it is determined whether the target external data exists in the local cache. If the target external data does not exist in the local cache, the first execution context data of the candidate smart contract is saved. The target contract is then determined from the list of smart contracts to be processed other than the N candidate smart contracts. Finally, the target contract replaces the candidate smart contract and is loaded into the execution slot of the execution memory corresponding to the candidate smart contract, and the target contract is executed. Thus, when it is found that a candidate smart contract needs to wait for the database to return, the context is saved and execution is switched, avoiding idle execution units and improving hardware utilization. At the same time, by supporting batch preloading, the cache hit rate and execution continuity are improved.

[0056] In the above embodiments, the first execution context data of the candidate smart contract is saved, and this can also be achieved through... Figure 2 To further explain, the method includes:

[0057] S201 saves the CPU state, heap pointer, stack pointer, and data space of the candidate smart contract.

[0058] In this embodiment, the CPU state, heap pointer, stack pointer, and data space of the candidate smart contract can be stored in memory space, or in a cache or on-chip cache. In another possible implementation, they can also be stored on a disk or SSD. The specific configuration can be determined according to actual design needs, and no limitations are imposed here.

[0059] In this embodiment of the disclosure, after saving the first execution context data of the candidate smart contract, read and write requests are made to the database (such as LevelDB) to obtain the required target external data.

[0060] In the above embodiments, the target contract can be determined from the unprocessed smart contracts other than the N candidate smart contracts, or by means of... Figure 3 To further explain, the method includes:

[0061] S301, determine whether a first contract exists from the pending smart contracts other than N candidate smart contracts, wherein the first contract does not require external data read / write operations.

[0062] It should be noted that, firstly, the current execution phase of this contract does not depend on external state and can be executed immediately.

[0063] S302, in response to the existence of at least one first contract, select a target first contract from the first contracts as the target contract.

[0064] In this embodiment of the disclosure, when the first contract is not found among the pending smart contracts other than the N candidate smart contracts, the target contract is determined, and this can also be achieved through... Figure 4 To further explain, the method includes:

[0065] S401, in response to the absence of a first contract among the pending smart contracts other than the N candidate smart contracts, determine whether a second contract exists among the pending smart contracts other than the N candidate smart contracts, wherein the external data of the second contract is stored in a local cache.

[0066] It should be noted that the second contract refers to the fact that its dependent data is already cached locally and can be quickly loaded and executed.

[0067] S402, in response to the existence of at least one second contract, select a target second contract from the second contracts as the target contract.

[0068] In this embodiment of the disclosure, when there are multiple first contracts or second contracts, a target contract can be selected from multiple first contracts or second contracts according to preset rules.

[0069] In this embodiment of the disclosure, a target contract is selected from the contract to be selected. The contract to be selected is either a first contract or a second contract. When the contract to be selected is a first contract, the target contract to be selected is the target first contract. When the contract to be selected is a second contract, the target contract to be selected is the target second contract. The contract to be selected with the longest waiting time or the contract to be selected with the highest execution priority can be used as the target contract to be selected.

[0070] In the above embodiments, the target contract can also be executed through... Figure 5 To further explain, the method includes:

[0071] S501, Determine whether the target contract has saved second execution context data.

[0072] S502, in response to the existence of a saved second execution context data in the target contract, execute the target contract based on the second execution context data.

[0073] In this embodiment of the disclosure, if the target contract is a smart contract whose execution context has been saved in the preceding order, the second execution context data saved by the smart contract is read, and then the second execution context data is written into the execution engine, such as writing to the program counter, stack pointer, heap pointer, etc., and the memory space is remapped. Finally, the execution jumps to the instruction pointed to by the program counter and continues to execute.

[0074] In this embodiment of the disclosure, the smart contract executes in a hardware virtual machine, which is implemented using a Field-Programmable Gate Array (FPGA) or an Application-Specific Integrated Circuit (ASIC). Figure 6 As shown, Figure 6 This disclosure presents an architecture diagram of a smart contract execution system that utilizes a hardware virtual machine (HVM) to accelerate the execution of smart contracts.

[0075] The smart contract execution system includes a smart contract scheduling CPU and a hardware VM.

[0076] The smart contract scheduler CPU is responsible for managing and scheduling the execution of all smart contracts.

[0077] The hardware virtual machine (VM) consists of multiple hardware virtual machine instances (VM0, VM1, ..., VMM), each of which is responsible for executing a batch of smart contract tasks.

[0078] The smart contract scheduling CPU communicates with various hardware VMs through a "hardware VM channel" to allocate tasks and receive results. Each hardware VM maintains a "contract execution batch" containing multiple smart contract tasks to be executed (Task0, Task1, ..., TaskN).

[0079] Each hardware VM maintains a "contract execution batch" containing multiple smart contract tasks (Task0, Task1, ..., TaskN) to be executed. Each task corresponds to a specific smart contract.

[0080] Once the current task is completed, the system automatically switches to the next task, forming a loop.

[0081] The smart contract scheduling CPU sends tasks to the hardware VM through the hardware VM channel and controls the allocation and scheduling of tasks. After execution, the hardware VM returns the results to the smart contract scheduling CPU.

[0082] Parallel processing and polling execution of smart contracts are achieved through multiple hardware VM instances, thereby improving system throughput and performance. The smart contract scheduling CPU is responsible for overall scheduling and management, ensuring the reasonable allocation of tasks and the collection of execution results.

[0083] In this embodiment of the disclosure, given that key-value storage systems such as LevelDB based on LSM tree structure have higher I / O throughput efficiency under batch read and write operations, this system is configured with multiple hardware execution units running in parallel, and data access requests from each execution unit are aggregated through a unified access proxy; when the requests accumulate to a preset threshold or meet the time window conditions, they are merged into a batch operation and submitted to LevelDB, thereby significantly reducing random access overhead and improving the overall database access efficiency and system throughput (TPS).

[0084] Figure 7 This is a schematic diagram of the overall process of a blockchain contract processing method disclosed herein, as follows: Figure 7 As shown.

[0085] The host agent, acting as the interface between the system and the outside world, receives data requests or instructions from the outside and sends the processed results or responses.

[0086] The host computer and hardware accelerator link is used to connect the host computer and the hardware acceleration unit to realize data transmission, pass read requests downwards, and pass the read data results upwards.

[0087] The acceleration unit host access agent (Card Agent) is responsible for managing and scheduling tasks within the hardware acceleration unit, and includes two functional modules:

[0088] Packet assembly and transmission: Multiple read requests are packaged into a batch request and sent to the hardware acceleration unit via the link.

[0089] Receive-Unpack: Receive data results from the hardware acceleration unit, unpack them, and then transmit them to the host computer.

[0090] The smart contract acceleration processing array comprises multiple VM Cores, each responsible for executing specific smart contract tasks. Each VM Core contains multiple Tasks, and each Task corresponds to a smart contract instance. Each VM Core maintains a "contract request data result pool" to store the data results returned by read requests initiated by that Core.

[0091] A First In, First Out (FIFO) queue is used to temporarily store pending read requests, ensuring they are submitted to the corresponding VM Cores in sequence. The Card Agent distributes received read requests into the appropriate FIFO queue. The VM Core retrieves the read request from its corresponding FIFO queue and executes it.

[0092] The smart contract execution process is as follows:

[0093] Each processing unit loads N smart contracts in batch processing.

[0094] During contract execution, data requests to access the blockchain are submitted to the acceleration unit host access proxy.

[0095] The acceleration unit access agent collects all access requests by opening M FIFOs and periodically reports them to the host computer blockchain access agent. If the data contained in the FIFO exceeds a certain threshold, it will immediately start reporting and send it to the host computer.

[0096] After receiving a batch processing request, the host computer blockchain access agent will access LevelDB in batch form and finally obtain the blockchain access request results in batches.

[0097] After the host computer obtains the batch access request results, it encapsulates the batch and submits it to the acceleration unit host access agent, which then unpacks and depacks the request.

[0098] After the acceleration unit host access proxy unpacks and depacks the data, it submits the data to the contract request data pool of each processing unit in sequence, according to the status of the hardware contract acceleration processing unit.

[0099] Therefore, when a candidate smart contract is found to need to wait for the database to return, the context is saved and execution is switched to avoid the execution unit running idle, improve hardware utilization, and at the same time improve cache hit rate and execution continuity by supporting batch preloading.

[0100] Corresponding to the blockchain contract processing methods provided in the above embodiments, one embodiment of this disclosure also provides a blockchain contract processing device. Since the blockchain contract processing device provided in this disclosure corresponds to the blockchain contract processing methods provided in the above embodiments, the implementation methods of the above blockchain contract processing methods are also applicable to the blockchain contract processing device provided in this disclosure, and will not be described in detail in the following embodiments.

[0101] Figure 8 Figure 8 is a schematic diagram of a blockchain contract processing device according to one embodiment of the present disclosure. As shown in Figure 8, the blockchain contract processing device 800 includes: a loading module 810, a judgment module 820, a processing module 830, and an execution module 840.

[0102] The loading module 810 is configured to load N candidate smart contracts in batches from the smart contracts to be processed in response to batch processing of smart contracts, and load the N candidate smart contracts into the execution memory.

[0103] The judgment module 820 is used to determine whether the target external data exists in the local cache when it is recognized that the candidate smart contract needs to perform target external data read / write operations.

[0104] The processing module 830 is configured to, in response to the fact that the target external data does not exist in the local cache, save the first execution context data of the candidate smart contracts and determine the target contract from the pending smart contracts other than the N candidate smart contracts.

[0105] The execution module 840 is used to replace the candidate smart contract with the target contract and load it into the execution slot of the execution memory corresponding to the candidate smart contract to execute the target contract.

[0106] According to one embodiment of this disclosure, the process of saving the first execution context data of the candidate smart contract includes saving the CPU state, heap pointer, stack pointer and data space of the candidate smart contract.

[0107] According to one embodiment of this disclosure, after saving the first execution context data of the candidate smart contract, the method further includes: performing read and write operations on the target external data.

[0108] According to one embodiment of this disclosure, determining the target contract from the pending smart contracts other than the N candidate smart contracts includes: determining whether a first contract exists from the pending smart contracts other than the N candidate smart contracts, wherein the first contract does not require external data read / write operations; and in response to the existence of at least one first contract, selecting a target first contract from the first contracts as the target contract.

[0109] According to one embodiment of this disclosure, the apparatus is further configured to: in response to the absence of the first contract among the pending smart contracts other than the N candidate smart contracts, determine whether a second contract exists among the pending smart contracts other than the N candidate smart contracts, wherein the external data of the second contract is stored in the local cache; and in response to the existence of at least one second contract, select a target second contract from the second contracts as the target contract.

[0110] According to one embodiment of this disclosure, a target contract is selected from a pool of candidate contracts, wherein the candidate contract is either the first contract or the second contract. When the candidate contract is the first contract, the target contract is the target first contract. When the candidate contract is the second contract, the target contract is the target second contract. This includes selecting the candidate contract with the longest waiting time or the candidate contract with the highest execution priority as the target contract.

[0111] According to one embodiment of this disclosure, executing the target contract includes: determining whether the target contract has saved second execution context data; and executing the target contract based on the second execution context data in response to the existence of saved second execution context data.

[0112] According to one embodiment of this disclosure, the smart contract is executed in a hardware virtual machine, which is implemented using an FPGA or an ASIC.

[0113] To implement the above embodiments, this disclosure also proposes an electronic device 900. Figure 9 This is a schematic diagram of an electronic device according to one embodiment of the present disclosure, such as... Figure 9 As shown, the electronic device 900 includes: a processor 901 and a memory 902 communicatively connected to the processor. The memory 902 stores instructions executable by at least one processor. The instructions are executed by at least one processor 901 to achieve the functions described in this disclosure. Figures 1-7 A blockchain contract processing method as described in this embodiment.

[0114] To implement the above embodiments, this disclosure also proposes a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to implement the present disclosure. Figures 1-7 A blockchain contract processing method as described in this embodiment.

[0115] To implement the above embodiments, this disclosure also proposes a computer program product, including a computer program, which, when executed by a processor, implements the features of this disclosure. Figures 1-7 A blockchain contract processing method as described in this embodiment.

[0116] It should be noted that personal information collected from users should be used for legitimate and reasonable purposes and should not be shared or sold outside of these legitimate uses. Furthermore, such collection / sharing should only be conducted after receiving the user's informed consent, including but not limited to notifying the user to read the user agreement / user notice and sign an agreement / authorization that includes authorization of relevant user information before the user uses the function. In addition, any necessary steps must be taken to protect and safeguard access to such personal information data and ensure that others with access to personal information data comply with their privacy policies and procedures.

[0117] This application is intended to provide an implementation scheme for users to selectively prevent the use or access to their personal information data. Specifically, this disclosure is intended to provide hardware and / or software to prevent or block access to such personal information data. Once personal information data is no longer needed, risks can be minimized by restricting data collection and deleting data. Furthermore, where applicable, such personal information is de-identified to protect user privacy.

[0118] In the foregoing descriptions of the embodiments, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0119] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0120] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0121] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that contains, stores, communicates, propagates, or transmits programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0122] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0123] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0124] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0125] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A blockchain contract processing method, characterized in that, include: In response to batch processing of smart contracts, N candidate smart contracts are loaded from the smart contracts to be processed, and the N candidate smart contracts are loaded into the execution memory of the hardware virtual machine; wherein, an independent memory region is allocated for each candidate smart contract. For any candidate smart contract, in response to the identification that the candidate smart contract needs to perform target external data read / write operations, it is determined whether the target external data exists in the local cache; In response to the fact that the target external data does not exist in the local cache, the first execution context data of the candidate smart contract is saved, and the target contract is determined from the pending smart contracts other than the N candidate smart contracts according to preset rules; wherein, the pending smart contracts other than the N candidate smart contracts include multiple first contracts and multiple second contracts. The first contracts do not need to perform external data read and write operations, and the external data of the second contracts is stored in the local cache. The first contracts have a higher priority than the second contracts. Replace the candidate smart contract with the target contract and load it into the execution slot of the execution memory corresponding to the candidate smart contract; determine whether the target contract has saved second execution context data, and in response to the existence of saved second execution context data, execute the target contract based on the second execution context data.

2. The method according to claim 1, characterized in that, The process of saving the first execution context data of the candidate smart contract includes: The CPU state, heap pointer, stack pointer, and data space of the candidate smart contract are saved.

3. The method according to claim 1 or 2, characterized in that, After saving the first execution context data of the candidate smart contract, the process further includes: Perform read and write operations on the target external data.

4. The method according to claim 1, characterized in that, The step of determining the target contract from the pending smart contracts other than the N candidate smart contracts according to preset rules includes: Determine whether a first contract exists from the pending smart contracts other than the N candidate smart contracts; In response to the existence of at least one first contract, a target first contract is selected from the first contracts as the target contract.

5. The method according to claim 4, characterized in that, The method further includes: In response to the absence of the first contract among the pending smart contracts other than the N candidate smart contracts, determine whether a second contract exists among the pending smart contracts other than the N candidate smart contracts; In response to the existence of at least one second contract, a target second contract is selected from the second contracts as the target contract.

6. The method according to claim 4 or 5, characterized in that, Selecting a target contract from the candidate contracts, wherein the candidate contract is either the first contract or the second contract, wherein when the candidate contract is the first contract, the target candidate contract is the target first contract, and when the candidate contract is the second contract, the target candidate contract is the target second contract, includes: The contract with the longest waiting time or the contract with the highest execution priority will be selected as the target contract.

7. The method according to claim 1, characterized in that, The smart contract is executed in a hardware virtual machine, which is implemented using an FPGA or ASIC.

8. A blockchain contract processing device, characterized in that, include: A loading module is configured to, in response to batch processing of smart contracts, batch load N candidate smart contracts from the smart contracts to be processed, and load the N candidate smart contracts into the execution memory of the hardware virtual machine; wherein, an independent memory region is allocated for each candidate smart contract; The judgment module is used to determine whether the target external data exists in the local cache when it is detected that the candidate smart contract needs to perform target external data read / write operations for any candidate smart contract. The processing module is configured to, in response to the fact that the target external data does not exist in the local cache, save the first execution context data of the candidate smart contracts, and determine the target contract from the pending smart contracts other than the N candidate smart contracts according to preset rules; wherein, the pending smart contracts other than the N candidate smart contracts include multiple first contracts and multiple second contracts, the first contracts do not require external data read and write operations, the external data of the second contracts are stored in the local cache, and the first contracts have a higher priority than the second contracts; An execution module is configured to replace the candidate smart contract with the target contract and load it into the execution slot of the execution memory corresponding to the candidate smart contract; determine whether the target contract has saved second execution context data; and, in response to the existence of saved second execution context data in the target contract, execute the target contract based on the second execution context data.

9. An electronic device, characterized in that, Including memory and processor; The processor reads executable program code stored in the memory to run a program corresponding to the executable program code, so as to implement the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

Images