Data processing method and device, equipment and storage medium

By transferring blockchain state data to cloud storage, the problem of insufficient local disk space caused by the increase in data is solved, achieving efficient utilization of storage resources and stable operation of the blockchain.

CN122431591APending Publication Date: 2026-07-21TENCENT TECHNOLOGY (SHENZHEN) CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
TENCENT TECHNOLOGY (SHENZHEN) CO LTD
Filing Date
2025-01-20
Publication Date
2026-07-21

AI Technical Summary

Technical Problem

As the blockchain operates, the increasing amount of state data reduces the available storage space on the local disk, or even makes storage impossible, causing the blockchain to malfunction.

Method used

The state data is transferred to cloud storage. By obtaining the state data transfer instruction when the task is pending, the target contract identifier is determined. The state data is written to the cloud storage address using the cloud storage write interface, and the data in the local Merkle state tree is deleted.

Benefits of technology

This avoids the problem of local disk storage space gradually decreasing, saves storage costs, improves storage resource utilization, and ensures the normal operation of the blockchain.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122431591A_ABST
    Figure CN122431591A_ABST
Patent Text Reader

Abstract

Embodiments of the present application disclose a data processing method, device and equipment, and a storage medium. The method comprises: in a processing process of a to-be-processed task, when a state data transfer instruction identifier is read, determining first state data corresponding to a target contract identifier of a running smart contract from a target Merkle state tree; determining a first storage address corresponding to the target contract identifier in cloud storage; calling a write interface of the cloud storage to transfer the first state data in the target Merkle state tree to the first storage address of the cloud storage; and deleting the first state data in the target Merkle state tree. The first state data in the target Merkle state tree stored in the local disk is transferred to the cloud storage, avoiding the problem that, as the state data increases, the available storage space of the local disk gradually decreases and even cannot store the state data, saving the storage cost of the local disk, improving the storage resource utilization rate, and ensuring the normal operation of the blockchain.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of blockchain technology, specifically to a data processing method, apparatus, device, and storage medium. Background Technology

[0002] Blockchain is a distributed ledger technology in the field of information technology. It generally consists of consensus, block and state data storage, cryptographic identity security and other components. Because the ledger is stored in a distributed manner and the blocks are agreed upon, it has the characteristics of immutability, traceability and joint maintenance, making it a strong candidate for batch business data processing.

[0003] In related technologies, blockchain operates on or stores a large amount of related data during its operation. This related data is called state data. For example, when blockchain processes a product or logistics, it stores billing information or logistics information.

[0004] However, the current state data is stored on the local disk of the blockchain processing node. As the blockchain continues to run, the amount of state data will increase, causing the available storage space on the local disk to gradually decrease. In fact, when the disk is full, the state data cannot be stored, causing the blockchain to malfunction. Therefore, there is an urgent need to provide a data processing method to solve the above problems. Summary of the Invention

[0005] This application provides a data processing method, apparatus, device, and storage medium that can transfer state data to cloud storage, avoiding the problem that as state data increases, the available storage space on the local disk gradually decreases, or even becomes unusable for storing state data. This saves storage costs on the local disk, improves storage resource utilization, and ensures the normal operation of the blockchain.

[0006] To address the aforementioned technical problems, this application provides the following technical solutions:

[0007] A data processing method, comprising:

[0008] Obtain the task to be processed. When the state data transfer instruction identifier is read during the processing of the task to be processed, determine the target contract identifier of the running smart contract.

[0009] Determine the first state data corresponding to the target contract identifier in the target Merkle state tree, wherein the target Merkle state tree includes the contract identifier of each smart contract and the state data contained in each contract identifier;

[0010] Based on the preset mapping relationship between each storage address and contract identifier in cloud storage, the first storage address corresponding to the target contract identifier is determined;

[0011] The cloud storage's write interface is invoked to write the first state data to the first storage address, and the first state data in the target Merkel state tree is deleted.

[0012] A data processing apparatus, comprising:

[0013] The first acquisition unit is used to acquire the task to be processed. When the state data transfer instruction identifier is read during the processing of the task to be processed, the target contract identifier of the running smart contract is determined.

[0014] The first determining unit is used to determine the first state data corresponding to the target contract identifier in the target Merkel state tree, wherein the target Merkel state tree includes the contract identifier of each smart contract and the state data contained in each contract identifier;

[0015] The second determining unit is used to determine the first storage address corresponding to the target contract identifier based on a preset mapping relationship between each storage address and the contract identifier in cloud storage;

[0016] The first data writing unit is used to call the write interface of the cloud storage, write the first state data to the first storage address, and delete the first state data in the target Merkel state tree.

[0017] In some embodiments, the first data writing unit includes:

[0018] The calling subunit is used to call the write interface of the cloud storage to write the first status data to the first storage address;

[0019] A caching subunit is used to cache the first state data in a local cache area and delete the first state data in the target Merkel state tree;

[0020] The timing subunit is used to start the timing. When the timing duration reaches the first preset duration, the first state data is deleted from the local cache.

[0021] In some embodiments, the first data writing unit further includes:

[0022] The rewrite subunit is used to rewrite the first state data in the local cache back into the target Merkle state tree when it receives a write failure instruction for the first state data sent by the cloud storage.

[0023] In some embodiments, the apparatus further includes:

[0024] The second acquisition unit is used to acquire permission configuration information for state data transfer;

[0025] The first execution unit is used to execute the step of determining the first storage address corresponding to the target contract identifier based on the preset mapping relationship between each storage address and the contract identifier in cloud storage when the permission configuration information indicates that state data transfer is allowed.

[0026] In some embodiments, the apparatus further includes:

[0027] The third acquisition unit is used to acquire the second storage address corresponding to the target contract identifier in the target storage area when the permission configuration information indicates that state data transfer is prohibited.

[0028] The second data writing unit is used to write the first state data to the second storage address and delete the first state data in the target Merkel state tree.

[0029] In some embodiments, the first data writing unit includes:

[0030] The encoding subunit is used to serialize and encode each first state data corresponding to the target contract identifier in the target Merkel state tree to obtain a first encoded byte stream.

[0031] The data writing subunit is used to write the first encoded byte stream to the first storage address.

[0032] In some embodiments, the apparatus further includes:

[0033] The third determining unit is used to determine the target contract identifier of the running smart contract when a state data recovery instruction identifier is read during the processing of the task to be processed.

[0034] The fourth determining unit is used to determine the first storage address corresponding to the target contract identifier based on the preset mapping relationship between each storage address and the contract identifier in cloud storage;

[0035] Extraction unit, used to extract the stored second state data from the first storage address;

[0036] The third data writing unit is used to write the second state data into the target contract identifier in the target Merkel state tree.

[0037] In some embodiments, the extraction unit includes:

[0038] The first acquisition subunit is used to acquire the second encoded byte stream stored in the first storage address;

[0039] The decoding subunit is used to deserialize and decode the second encoded byte stream to obtain the second state data;

[0040] The extraction subunit is used to extract the second state data.

[0041] In some embodiments, the extraction unit further includes:

[0042] The sending subunit is used to send a unfreezing instruction to the cloud storage to unfreeze the second encoded byte stream and to start a timer;

[0043] An execution subunit is used to execute the step of obtaining the second encoded byte stream stored in the first storage address when the timing duration reaches the second preset duration.

[0044] In some embodiments, the third determining unit includes:

[0045] The second acquisition subunit is used to determine the target contract identifier of the running smart contract and to acquire the first block currently on the blockchain.

[0046] The device further includes:

[0047] The fourth acquisition unit is used to acquire the second block currently on the blockchain when a query instruction for the second state data is read during the processing of the task to be processed.

[0048] The fifth determining unit is used to determine a third block that is a preset number of blocks after the first block;

[0049] The generation unit is configured to generate a prompt message when the second block is located between the first block and the third block, and return the prompt message to the client that sent the task to be processed. The prompt message is used to indicate that the query failed.

[0050] In some embodiments, the apparatus further includes:

[0051] The fifth acquisition unit is used to acquire permission configuration information for state data transfer;

[0052] The second execution unit is used to execute the step of determining the first storage address corresponding to the target contract identifier based on the preset mapping relationship between each storage address and the contract identifier in cloud storage when the permission configuration information indicates that state data transfer is allowed.

[0053] In some embodiments, the apparatus further includes:

[0054] The sixth determining unit is used to determine the second storage address corresponding to the target contract identifier from the target storage area when the permission configuration information indicates that state data transfer is prohibited;

[0055] The fourth data writing unit is used to write the second state data stored in the second storage address into the target contract identifier in the target Merkel state tree.

[0056] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the data processing method described above.

[0057] A computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to execute the data processing method described above.

[0058] A computer program product or computer program includes computer instructions stored in a storage medium. A processor of a computer device reads the computer instructions from the storage medium and executes the computer instructions to implement the data processing method described above.

[0059] This application embodiment obtains a task to be processed. When a state data transfer instruction identifier is read during the processing of the task to be processed, the target contract identifier of the running smart contract is determined. The first state data corresponding to the target contract identifier in the target Merkle state tree is determined. The target Merkle state tree includes the contract identifier of each smart contract and the state data contained in each contract identifier. Based on the preset mapping relationship between each storage address and the contract identifier in cloud storage, the first storage address corresponding to the target contract identifier is determined. The write interface of the cloud storage is called to write the first state data to the first storage address and delete the first state data in the target Merkle state tree.

[0060] Therefore, when a state data transfer instruction identifier is read during the processing of a task, the first state data corresponding to the target contract identifier of the running smart contract is determined from the target Merkle state tree. Based on the target contract identifier, the corresponding first storage address in cloud storage is determined, and the write interface of cloud storage is called to transfer the first state data in the target Merkle state tree to the first storage address in cloud storage. The first state data in the target Merkle state tree is then deleted. Compared with related technologies where state data can only be stored on local disks, this application provides a data transfer technology that transfers the first state data in the target Merkle state tree stored on local disks to cloud storage. This avoids the problem that as state data increases, the available storage space on local disks gradually decreases, or even becomes unusable for storing state data. This saves storage overhead on local disks, improves storage resource utilization, and ensures the normal operation of the blockchain.

[0061] Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objectives and other advantages of this disclosure may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0062] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0063] Figure 1 This is a flowchart illustrating the data processing method provided in an embodiment of this application.

[0064] Figure 2 This is a schematic diagram of the Merkel state tree structure provided in an embodiment of this application.

[0065] Figure 3 This is an interactive diagram illustrating the data processing procedure provided in an embodiment of this application.

[0066] Figure 4 This is an interactive schematic diagram of the state data transfer process provided in an embodiment of this application.

[0067] Figure 5 This is an interactive schematic diagram of the state data recovery process provided in an embodiment of this application.

[0068] Figure 6 This is a schematic diagram of the structure of the data processing apparatus provided in the embodiments of this application.

[0069] Figure 7 A schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0070] To enable those skilled in the art to better understand the solutions of this application, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0071] It should be noted that while some processes described in the specification, claims, and accompanying drawings contain multiple steps that appear in a specific order, it should be clearly understood that these steps may not be performed in the order they appear herein, or may be performed in parallel. The step numbers are merely used to distinguish different steps and do not represent any particular order of execution. Furthermore, descriptions such as "first," "second," or "objective" in this document are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0072] In specific embodiments of this application, data concerning object privacy, such as virtual resource rewards and status data, are involved. When the above embodiments of this application are applied to specific products or technologies, permission or consent from the object is required, and the collection, use, and processing of related data must comply with relevant laws, regulations, and standards. For example, when an embodiment of this application needs to obtain virtual resource rewards or status data, separate permission or consent for the virtual resource rewards or status data can be obtained through pop-ups or redirection to a confirmation page. Only after obtaining separate permission or consent can the necessary related data for the normal operation of the embodiment of this application be obtained.

[0073] Before providing a further detailed description of the embodiments of this disclosure, the terms and concepts used in these embodiments are explained, and they are subject to the following interpretations:

[0074] Smart contracts are computer protocols designed to disseminate, verify, or execute contracts in an informational manner. Smart contracts allow for trusted tasks without a third party; these tasks are tagged and irreversible. While working similarly to traditional contracts, smart contracts are implemented using blockchain technology. They offer the following characteristics and advantages: 1. Automatic execution: Once predetermined conditions are met, smart contracts automatically execute the corresponding operations without human intervention, reducing the possibility of human error. 2. Decentralization: Typically running on a blockchain, they do not rely on a single centralized institution, improving the trustworthiness and fairness of the contract. 3. Immutability: Their code and execution records are stored on the blockchain, making them difficult to tamper with and ensuring the security and reliability of the contract. 4. High efficiency and low cost: They eliminate the cumbersome processes and intermediaries of traditional contracts, reducing costs and improving execution efficiency.

[0075] For example, smart contracts can automatically trigger payments based on the shipping status of goods. Smart contracts have a wide range of applications, including the Internet of Things, digital rights management, supply chain management, and many other fields, bringing greater efficiency and transparency to various business processes.

[0076] Nodes: A node can be a server or other computer device capable of participating in the operation and maintenance of the blockchain network. The functions of a node include: 1. Propagating and receiving transaction information: Broadcasting newly generated transactions to the network and receiving transactions from other nodes. 2. Verifying transactions and blocks: Ensuring the legality of transactions and the validity of blocks. 3. Participating in the consensus mechanism: Jointly determining the state and direction of the blockchain.

[0077] For example, in an enterprise-level blockchain application, servers in different departments can act as nodes to jointly maintain the consistency and immutability of business data.

[0078] Packaging refers to the process of combining transaction data generated within a certain period into a data block. Specifically, when multiple transactions occur, a specific blockchain node or node collects and combines these transactions according to certain rules and algorithms. The main functions of packaging include: 1. Improving efficiency: Processing multiple transactions at once reduces the number of processing steps and time for individual transactions. 2. Ensuring data consistency: Ensuring that transaction data within a block is interconnected and consistent. 3. Participating in the consensus mechanism: Specific blockchain nodes or nodes that successfully package a block receive a reward, which is part of the blockchain consensus mechanism. Packaging is a crucial step in blockchain operation, ensuring the orderly processing of transactions and the continuous growth of the blockchain.

[0079] On-chain recording refers to the process of recording data or information on a blockchain. Once a task is recorded on the chain, it is encrypted and distributed across various nodes of the blockchain, possessing the following characteristics and significance: 1. Immutability: Once data is on the chain, it is very difficult to alter, ensuring the originality and integrity of the data. 2. Traceability: The generation and addition history of data can be clearly viewed, facilitating traceability and auditing. 3. Decentralized storage: Data is not stored on a single centralized server but distributed across multiple nodes, reducing the risk of single points of failure and data loss. 4. Increased trust: Due to the characteristics of blockchain, on-chain data is more likely to gain the trust of all parties.

[0080] For example, in the supply chain field, putting information about the production, transportation, and sales of goods on the blockchain can make the entire supply chain process more transparent and trustworthy. In short, putting data on the blockchain means incorporating data into the blockchain system to achieve secure storage, reliable sharing, and efficient utilization of data.

[0081] Merkle Patricia Tree (MPT): A special data structure, also known as a Merkle prefix tree. It consists of four types of nodes: extension nodes, branch nodes, leaf nodes, and empty nodes. Extension nodes can only have one child node, branch nodes can have multiple child nodes, and leaf nodes have no child nodes. It stores the state of each smart contract's corresponding identifier. The state of each account consists of a key and a value, and these key-value pairs are encoded and stored in the state tree.

[0082] The Merkel state tree is constructed as follows: starting from the leaf nodes, each leaf node's hash value is the hash value of its corresponding data. Then, the hash values ​​of adjacent nodes are combined, their parent node's hash value is calculated, and this process is repeated upwards until the root node is reached. The bottom-level leaf nodes correspond to specific data, such as transaction records, while each non-leaf node is a hash combination of the hash values ​​of its child nodes.

[0083] Cloud storage is a solution that provides storage services over a network. It uses multiple servers and storage devices in a data center to provide scalable, remotely accessible storage resources for objects. Objects can store data on these servers provided by cloud service providers without needing to maintain a large amount of storage hardware locally.

[0084] In this embodiment, the description will be from the perspective of a data processing device, which can be integrated into a computer device that has a storage unit and is equipped with a microprocessor and has computing capabilities.

[0085] Please see Figure 1 , Figure 1 This is a flowchart illustrating the data processing method provided in an embodiment of this application. The data processing method is applied to a computer device with smart contracts deployed to implement the corresponding processing logic of the smart contracts, including:

[0086] In step 201, the task to be processed is obtained. When the state data transfer instruction identifier is read during the processing of the task to be processed, the target contract identifier of the running smart contract is determined.

[0087] The task to be processed is a transaction initiated by the client to a blockchain node via the network, such as a transfer transaction or a product order transaction. Different processing methods will be used depending on the processing logic set by the smart contract for different tasks. When a state data transfer instruction identifier is read during the processing of the task to be processed, it indicates that the task to be processed will cause the addition of state data. The main difference between this application and related technologies is that this application pre-configures the processing logic in the smart contract to archive and store the state data to cloud storage when new state data is added. Therefore, for tasks that cause the addition of state data, the state data transfer instruction identifier can be read during the processing to perform the corresponding state data transfer.

[0088] Specifically, each blockchain node runs multiple smart contracts, and each smart contract is deployed in a different virtual machine (i.e., a computer device on which the smart contract is deployed) running in the blockchain node. When the virtual machine where the smart contract is located executes, it reads the instruction identifier of the corresponding program counter from the instruction stack, and maps the instruction identifier to the corresponding preset instruction according to the instruction mapping table, thereby executing the instruction.

[0089] For state data transfer instructions, taking 0xFE as the state data transfer instruction identifier and the smart contract's contract address ADDR as the contract identifier, the mapping to the corresponding state data transfer instruction SFREEZE is as follows:

[0090] 0xFE→SFREEZE(ADDR);

[0091] When the smart contract virtual machine reads the instruction identifier corresponding to the program counter as 0xFE, it maps it to the corresponding state data transfer instruction template SFREEZE(). If the target contract identifier of the running smart contract is determined to be ADDR, then ADDR is input as a parameter into the state data transfer instruction template SFREEZE(), forming the state data transfer instruction SFREEZE(ADDR) for the smart contract with contract address ADDR. The contract identifier can also be the smart contract number (e.g., 1, 2, 3, 4, etc.), etc., which is not limited here.

[0092] In step 202, the first state data corresponding to the target contract identifier in the target Merkle state tree is determined. The target Merkle state tree includes the contract identifier of each smart contract and the state data contained in each contract identifier.

[0093] Among them, such as Figure 2 As shown, Figure 2This is a schematic diagram of the Merkle state tree structure provided in an embodiment of this application. Different nodes in the blockchain maintain the same Merkle state tree through a consensus mechanism; that is, different nodes store the same Merkle state tree. The Merkle state tree includes the contract identifier of each smart contract and the state data contained in each contract identifier.

[0094] like Figure 2 As shown, the Merkle state tree includes four different smart contract identifiers: Contract Identifier 1, Contract Identifier 2, Contract Identifier 3, and Contract Identifier 4. Each contract identifier includes the state data obtained by the corresponding smart contract during task processing. Each state data consists of a data type (Key) and a corresponding data content (Value).

[0095] For example, when smart contract 1 processes logistics, it records the logistics number and the weight of the item. Smart contract 1 stores the logistics number and the weight under contract identifier 1 in the Merkle state tree, so that contract identifier 1 includes the logistics number and the weight. The logistics number and the weight constitute the state data. During the storage process in the Merkle state tree, the state data is split to form a data type (Key) and a corresponding data content (Value). For example, if the state data is "Logistics Number 123XXX", then the data type is "Logistics Number" and the data content is "123XXX", and it is stored in the Merkle state tree in this way.

[0096] Specifically, the Merkle state tree also includes the hash calculation results obtained by hashing the identifiers of adjacent contracts, and the Merkle state tree root (StateRoot). For example Figure 2 The hash values ​​of contract identifier 1 and contract identifier 2 are calculated to obtain the hash calculation result of the upper-level node (H(1,;)). The hash values ​​of contract identifier 3 and contract identifier 4 are calculated to obtain the hash calculation result of the upper-level node (H(2,;)). The hash values ​​of the hash calculation results (H(1,;)) and (H(2,;)) are calculated to obtain the final Merkle state tree root (StateRoot).

[0097] The target Merkle state tree is the Merkle state tree stored on the blockchain node where the virtual machine running the smart contract is located; it is also the local Merkle state tree. The first state data is the state data in the target Merkle state tree corresponding to the target contract identifier. This is the corresponding state data stored during the processing of the task to be processed.

[0098] In step 203, based on the preset mapping relationship between each storage address and the contract identifier in cloud storage, the first storage address corresponding to the target contract identifier is determined.

[0099] In this system, each smart contract is pre-configured with a corresponding storage address in the cloud storage. Therefore, based on the pre-defined mapping relationship between each storage address and the contract identifier in the cloud storage, the first storage address corresponding to the target contract identifier can be determined. This first storage address is specifically used to store the state data of the smart contract corresponding to the target contract identifier.

[0100] In some implementations, before determining the first storage address corresponding to the target contract identifier based on the preset mapping relationship between each storage address and contract identifier in cloud storage, the method further includes:

[0101] (1) Obtain permission configuration information for state data transfer;

[0102] (2) When the permission configuration information indicates that state data transfer is allowed, the step of determining the first storage address corresponding to the target contract identifier based on the preset mapping relationship between each storage address and the contract identifier in cloud storage is executed.

[0103] For blockchain node administrators, whether to enable state data transfer is optional. For administrators who do not wish to use the data transfer function, permission configuration information needs to be compiled in advance to inform the smart contract whether state data transfer is allowed.

[0104] Therefore, before executing the step of determining the first storage address corresponding to the target contract identifier based on the preset mapping relationship between each storage address and the contract identifier in cloud storage, it is necessary to obtain the permission configuration information of the blockchain node for state data transfer. The permission configuration information is used to indicate whether state data transfer is allowed or prohibited.

[0105] Specifically, when the permission configuration information indicates that state data transfer is allowed, it means that the administrator of the blockchain node allows the state data transfer function to be performed. Then, the first storage address corresponding to the target contract identifier is determined based on the preset mapping relationship between each storage address and the contract identifier in the cloud storage, so as to realize the subsequent state data transfer function.

[0106] In this way, through permission configuration information, administrators can decide whether to transfer state data to cloud storage, providing flexibility for different node operation strategies. For example, some blockchain node administrators may not want to use cloud storage for state data transfer due to cost, security, or performance considerations; they can easily disable this function through permission configuration information. Meanwhile, administrators of other blockchain nodes may enable this function if they need to expand storage capacity, meeting the differentiated needs of different nodes in different operational scenarios.

[0107] In some embodiments, the method further includes:

[0108] (1) When the permission configuration information indicates that state data transfer is prohibited, obtain the second storage address corresponding to the target contract identifier in the target storage area;

[0109] (2) Write the first state data to the second storage address and delete the first state data in the target Merkel state tree.

[0110] Specifically, when the permission configuration information indicates that state data transfer is prohibited, it means that the blockchain node administrator does not want the state data transfer function to be implemented. However, if the smart contract is used to process a task, and it does not transfer the state data to cloud storage, then when the newly added events of the state data are packaged into a block consensus and sent to other blockchain nodes' smart contracts, even if other blockchain nodes allow state data transfer, the first state data will still not be transferred to the first storage address in the cloud storage because it is still in the target Merkle state tree, resulting in state data redundancy. To address this situation, if the permission configuration information indicates that state data transfer is prohibited, then the second storage address in the local target storage area, which is dedicated to storing the state data corresponding to the target contract identifier, is obtained. The first state data is written to the second storage address, and the first state data is deleted from the target Merkle state tree.

[0111] In this way, the first state data is transferred from the target Merkle state tree to the second storage address in the target storage area. After other blockchain nodes transfer the first state data, the transferred Merkle state tree is the same as the target Merkle state tree of the blockchain node that is processing the task to be processed, ensuring the consistency of the Merkle state tree and avoiding the redundancy problem caused by other blockchain nodes not transferring the first state data.

[0112] In step 204, the write interface of the cloud storage is called to write the first state data to the first storage address and delete the first state data from the target Merkel state tree.

[0113] After determining the first storage address in the cloud storage used to store the first state data, the first state data is written to the first storage address by calling the write interface provided by the cloud storage. Since the first state data originally stored in the target Merkel state tree has been transferred to the cloud storage by writing to the first storage address, the first state data in the local target Merkel state tree is deleted to save local storage space.

[0114] And delete the first state data in the target Merkel state tree.

[0115] In some implementations, the step of calling the cloud storage's write interface to write the first state data to the first storage address and deleting the first state data from the target Merkel state tree includes:

[0116] (1) Call the write interface of the cloud storage to write the first status data to the first storage address;

[0117] (2) Cache the first state data in the local cache and delete the first state data in the target Merkel state tree;

[0118] (3) Start timing. When the timing duration reaches the first preset duration, delete the first state data from the local cache.

[0119] To avoid data transfer anomalies caused by cloud storage downtime or upgrades, after writing the first state data to the first storage address, the first state data is cached in a local cache to achieve cache backup during the data transfer process, and the first state data is deleted from the target Merkle state tree. A maximum write duration is set, namely the first preset duration. The purpose of this duration is that when the timer reaches the first preset duration, it is assumed that the state data has been written to the first storage address in the cloud storage and no data transfer anomaly has occurred, in which case the first state data in the local cache is deleted.

[0120] In this way, after writing the initial state data to the first storage address in the cloud storage, the data is cached in the local cache, avoiding the risk of data transfer failure due to abnormal situations such as cloud storage downtime or upgrades. If cloud storage fails, the data can still be found in the local cache, providing additional security for the data transfer process and ensuring that state data is not lost due to unexpected circumstances.

[0121] In some implementations, before caching the first state data in a local cache and deleting the first state data from the target Merkel state tree, the method further includes:

[0122] (1) Get the current storage amount of a specified local storage area;

[0123] (2) When the current storage amount is greater than or equal to the preset storage amount threshold, the step of caching the first state data in the local cache area and deleting the first state data in the target Merkel state tree is executed.

[0124] (3) When the current storage amount is less than the preset storage amount threshold, the first state data is written to the local designated storage area.

[0125] Specifically, when backing up the first-state data, the backup location of the first-state data is determined by obtaining the current storage amount of the designated local storage area and comparing it with a preset storage threshold. If the current storage amount is greater than or equal to the preset storage threshold, it means that the designated local storage area does not have enough storage to store the first-state data, and the first-state data is stored in the local cache first. If the current storage amount is less than the preset storage threshold, it means that the designated local storage area has enough storage to store the first-state data, and the first-state data is stored in the designated local storage area first, so as to avoid the problem of buffer resource shortage caused by caching the first-state data in the local cache.

[0126] Therefore, by comparing the current storage capacity of the designated local storage area with a preset storage capacity threshold, this method can make flexible storage decisions based on the actual storage resources. When the storage capacity of the designated local storage area is sufficient (i.e., the current storage capacity is less than the preset storage capacity threshold), the first-state data is directly stored in the designated local storage area, avoiding unnecessary caching operations and maximizing the utilization of local storage resources.

[0127] In some implementations, prior to deleting the first state data from the local cache, the method further includes:

[0128] When a write failure instruction for the first state data is received from the cloud storage, the first state data in the local cache is rewritten back into the target Merkel state tree.

[0129] If a write failure instruction for the first state data is received from the cloud storage during the timing period, it indicates that the cloud storage has encountered a data transfer anomaly. In order to avoid the loss of the first state data during the data transfer process, the first state data previously stored in the local cache needs to be rewritten back to the target Merkle state tree, and then transferred to the first storage address of the cloud storage along with other tasks that will cause the state data to be added when the smart contract is running.

[0130] Therefore, when cloud storage sends a write failure command, the first state data in the local cache is rewritten back to the target Merkle state tree, effectively preventing data loss during the transfer process. Since state data is crucial information in the blockchain system, ensuring its integrity is paramount. Through this mechanism, even if cloud storage encounters problems, data will not be lost and can be retried in subsequent operations, guaranteeing the integrity and reliability of the entire blockchain system's data.

[0131] In some implementations, writing the first state data to the first storage address includes:

[0132] (1) Serialize and encode each first state data corresponding to the target contract identifier in the target Merkel state tree to obtain a first encoded byte stream;

[0133] (2) Write the first encoded byte stream to the first storage address.

[0134] Specifically, during the process of writing the first state data to the first storage address, the first state data is serialized and encoded using the following code:

[0135] KVRLP = RLP_ENCODE( <Key i Value i >[]);

[0136] RLP_ENCODE() is a function that performs recursive length prefix serialization (RLP) on the parameter within parentheses. KVRLP is the first encoded byte stream obtained after serialization and encoding, which is then written to the first storage address.

[0137] Therefore, by serializing and encoding the first state data in the target Merkle state tree to obtain the first encoded byte stream, the complex data structure is converted into a byte stream, which is more conducive to storage and transmission. Byte streams are more efficient in terms of storage and transmission because they occupy relatively little space and can be processed more easily on storage media and networks.

[0138] In some implementations, after clearing the first state data from the target Merkel state tree, the method further includes:

[0139] (1) Obtain the first encoding length of the first encoded byte stream, and obtain the management client of the blockchain processing node;

[0140] (2) Determine the product of the first encoding length and the first preset coefficient to obtain the first virtual resource reward;

[0141] (3) Send the first virtual resource reward to the management client.

[0142] After clearing the first state data from the target Merkle state tree and serializing it into a first encoded byte stream, it is necessary to obtain the length of this byte stream. The specific method for obtaining this length can be found in the following code:

[0143] Length = Len(KVRLP);

[0144] Here, Len() is a function to obtain the first encoded length. The formula is to obtain the first encoded length Length of the first encoded byte stream KVRLP using the Len() function. To incentivize the administrators of blockchain nodes that use state data transfer, the first virtual resource reward can be determined based on the first encoded length and sent to the management client of the blockchain processing node.

[0145] The method for determining the first virtual resource reward can be referenced in the following code:

[0146] State.BalanceOf[SENDER]+=Length*X;

[0147] Here, SENDER is the management client, X is the first preset coefficient, and the first virtual resource reward is obtained by calculating the product of the first encoding length Length and the first preset coefficient X. State.BalanceOf[] is a function or array used to manage the remaining virtual resource rewards of the client, so as to send the first virtual resource reward to the management client SENDER.

[0148] Thus, an economic incentive mechanism is established by determining the first virtual resource reward based on the length of the first encoded byte stream and a first preset coefficient, and sending this reward to the management client. This encourages the management client of the blockchain processing node to actively participate in state data transfer. Since the first virtual resource reward is proportional to the length of the first encoded byte stream, the management client will tend to transfer more state data. This helps optimize the storage resources of the blockchain system, as more state data can be transferred out of local storage, reducing the pressure on local storage and allowing it to be stored in an external storage area more suitable for long-term preservation.

[0149] The state data transfer process only proceeds when a state data transfer instruction identifier is read. To prevent non-smart contract administrators from maliciously transferring state data by sending state data transfer instruction identifiers to the smart contract's virtual machine, smart contract developers can write relevant permission control code before the instruction is executed to ensure that contract storage is not maliciously archived.

[0150] For example, before determining the target contract identifier of the smart contract to be executed, the following is also included:

[0151] Obtain the sender identifier of the state data transfer instruction identifier;

[0152] If the sender identifier is not in the preset identifier set, the step of determining the target contract identifier of the smart contract to be run is prohibited.

[0153] The preset identifier set is a set of manager identifiers pre-set by the smart contract manager. If the sender identifier is not in the preset identifier set, it means that the state data transfer instruction identifier is a state data transfer identifier sent by a non-manager, which may cause malicious transfer of state data. Therefore, the subsequent state data transfer process is prohibited to improve the security of state data.

[0154] Therefore, by checking the sender's identifier of the state data transfer instruction and comparing it with a preset identifier set (a set of manager identifiers pre-set by the smart contract's manager), it is possible to effectively prevent non-smart contract managers from sending state data transfer instruction identifiers. This mechanism avoids malicious or unauthorized users from maliciously transferring state data by sending instruction identifiers, ensuring the security of state data and preventing malicious users from transferring state data to inappropriate locations or performing unauthorized operations, thereby protecting the integrity and security of smart contract storage.

[0155] In some embodiments, the method further includes:

[0156] (1) When the status data recovery instruction identifier is read during the processing of the task to be processed, the target contract identifier of the running smart contract is determined.

[0157] (2) Based on the preset mapping relationship between each storage address and contract identifier in cloud storage, determine the first storage address corresponding to the target contract identifier;

[0158] (3) Extract the stored second state data from the first storage address;

[0159] (4) Write the second state data into the target contract identifier in the target Merkel state tree.

[0160] In this application, when a state data recovery instruction identifier is read during the processing of a task, it indicates that the task involves changes to existing state data, and the target Merkle state tree lacks corresponding state data due to the transfer of state data to cloud storage. Therefore, state data recovery is required. The main difference between this application and related technologies lies in the fact that this application pre-configures processing logic within the smart contract to restore the state data stored in cloud storage to the target Merkle state tree when state data changes. Therefore, for tasks that cause changes to state data, a state data transfer instruction identifier can be read during processing to perform the corresponding state data transfer.

[0161] For state data recovery instructions, taking 0xFF as the state data recovery instruction identifier and the smart contract's contract address ADDR as the contract identifier, the mapping to the corresponding state data recovery instruction SUNFREEZE is as follows:

[0162] 0xFF → SUNFREEZE (ADDR);

[0163] When the smart contract virtual machine reads the instruction identifier corresponding to the program counter as 0xFF, it maps it to the corresponding state data recovery instruction template SUNFREEZE(). If the target contract identifier of the running smart contract is determined to be ADDR, then ADDR is input as a parameter into the state data recovery instruction template SUNFREEZE(), forming the state data recovery instruction SUNFREEZE(ADDR) for the smart contract with contract address ADDR. The contract identifier can also be the smart contract number (e.g., 1, 2, 3, 4, etc.), etc., which is not limited here.

[0164] Specifically, since cloud storage pre-configures a corresponding storage address for each smart contract's identifier, the first storage address corresponding to the target contract identifier can be determined based on the preset mapping relationship between each storage address and the contract identifier in cloud storage. This first storage address is dedicated to storing the state data of the smart contract corresponding to the target contract identifier. Since no second state data requiring modification was found in the target Merkle state tree, indicating it had already been transferred to the first storage address, the stored second state data is extracted from the first storage address and written into the target contract identifier within the target Merkle state tree. This process restores the second state data from cloud storage to the target Merkle state tree.

[0165] The method of writing the second state data into the target contract identifier in the target Merkel state tree can be implemented as follows:

[0166] State.StorageOf[ADDR][Key i ] = Value i ;

[0167] Here, `State.StorageOf[]` is an object or data structure used to manage state data storage. The second state data includes `i` sets of data types (Keys) and their corresponding data content (Values). For each data type Key... i Value of the corresponding data i Write it to the contract identified as ADDR in the target Merkel state tree.

[0168] Therefore, when processing tasks involve changes to state data, and the corresponding state data has been transferred to cloud storage, the state data recovery instruction identifier and the corresponding state data recovery instruction provide an effective data recovery mechanism. This ensures that if existing state data needs to be changed and is not in the target Merkle state tree (because it has been transferred to cloud storage), it can be recovered from cloud storage, thus guaranteeing data integrity.

[0169] In some implementations, retrieving the stored second state data from the first storage address includes:

[0170] (1.1) Obtain the second encoded byte stream stored in the first storage address;

[0171] (1.2) Deserialize and decode the second encoded byte stream to obtain the second state data;

[0172] (1.3) Extract the second state data.

[0173] In the process of transferring state data, the state data is serialized and encoded into an encoded byte stream for storage. Correspondingly, in the data recovery process, the second state data obtained from the first storage address of the cloud storage is also serialized and encoded into a second encoded byte stream. Therefore, it is necessary to deserialize and decode the second encoded byte stream to obtain the second state data.

[0174] The code for retrieving the second encoded byte stream from the first storage address in cloud storage can be referenced in the following form:

[0175] KVRLP′=COS.Read(BUCKET+ADDR);

[0176] KVRLP′ is the second encoded byte stream, and COS.Read() is the read function provided by cloud storage. In cloud storage, each storage address is distinguished by a hash bucket, and one hash bucket is one storage address.

[0177] The code for deserialization and decoding can be referenced as follows:

[0178] <Key i Value i >[]=RLP_DECODE(KVRLP′)

[0179] RLP_DECODE() is a deserialization decoding function. This function can be used to obtain second-state data, which includes i sets of data types (Key) and their corresponding data content (Value), and then extract the second-state data.

[0180] Therefore, by using serialization encoding for state data during storage and deserialization decoding during recovery, the system can adopt a unified data processing flow. This approach ensures data consistency during storage and recovery, allowing the same encoding and decoding rules to be used regardless of the node or point in time where storage and recovery operations occur. Using a unified serialization and deserialization mechanism for different virtual machines improves system compatibility and interoperability. Different virtual machines can easily recover state data stored in cloud storage and correctly understand and use the recovered data without errors caused by incompatible data formats.

[0181] In some embodiments, before deserializing and decoding the second encoded byte stream to obtain the second state data, the method further includes:

[0182] (1.1) Call the query interface of the cloud storage to query the second encoding length of the second encoded byte stream stored in the first storage address;

[0183] (1.2) Determine the product of the second encoding length and the second preset coefficient to obtain the second virtual resource reward;

[0184] (1.3) Obtain the remaining reward from the management client of the blockchain processing node;

[0185] (1.4) When the remaining reward is greater than or equal to the second virtual resource reward, the second virtual resource reward is deducted from the remaining reward, and the step of deserializing and decoding the second encoded byte stream to obtain the second state data is performed.

[0186] Specifically, regarding the scheme that provides virtual resource rewards to administrators during state data transfer, if the state data needs to be retrieved from cloud storage and restored subsequently, a certain amount of the virtual resource reward needs to be deducted. The specific value of the deducted virtual resource reward is also related to the encoding length of the encoded byte stream corresponding to the state data. Therefore, the encoding length needs to be obtained first.

[0187] Specifically, taking the reading of the status data recovery instruction identifier during the processing of the task as an example, the method for obtaining the second encoding length of the second encoded byte stream can be referred to in the following code:

[0188] Length′=COS.SizeOf(BUCKET+ADDR);

[0189] Where Length′ is the second encoding length, and COS.SizeOf() is a function to query the size of the object's stored file. COS.SizeOf(BUCKET+ADDR) queries the size of the file stored in the hash bucket corresponding to the contract identifier ADDR of the target contract in the cloud storage, thereby obtaining the second encoding length of the second encoded byte stream stored in the first storage address.

[0190] After obtaining the second encoding length, the second virtual resource reward to be deducted is determined using the following code:

[0191] Length ′ *Y;

[0192] Where Y is the second preset coefficient, and the second virtual resource reward is obtained by calculating the product of the second encoding length Length′ and the second preset coefficient Y.

[0193] When deducting the second virtual resource reward, it is first necessary to determine whether the remaining reward of the blockchain processing node's management client is sufficient to deduct the second virtual resource reward, that is, whether the remaining reward is greater than or equal to the second virtual resource reward. The code for this determination step can be found below:

[0194] State.BalanceOf[SENDER]≥Length′*Y;

[0195] Here, State.BalanceOf[SENDER] represents the remaining virtual resource reward obtained from the SENDER management client. If State.BalanceOf[SENDER] ≥ Length′*Y, it means that the remaining virtual resource reward is greater than or equal to the second virtual resource reward Length′*Y.

[0196] Specifically, when the remaining virtual resource reward is greater than or equal to the second virtual resource reward Length1*Y, the remaining virtual resource reward is deducted using the following code:

[0197] State.BalanceOf[SENDER]-=Length′*Y;

[0198] This code deducts the second virtual resource reward Length′*Y from the remaining virtual resource reward State.BalanceOf[SENDER].

[0199] Therefore, by deducting corresponding virtual resource rewards during data recovery, administrators are encouraged to be more cautious and rationally consider cost-effectiveness when transferring state data. When state data needs to be recovered from cloud storage, a certain amount of virtual resource rewards will be deducted, which can prevent administrators from transferring data indiscriminately without considering the subsequent recovery costs.

[0200] In some embodiments, before obtaining the second encoded byte stream stored in the first storage address, the method further includes:

[0201] (1.1) Send a defreezing instruction to the cloud storage to defreeze the second encoded byte stream and start a timer;

[0202] (1.2) When the timing duration reaches the second preset duration, the step of obtaining the second encoded byte stream stored in the first storage address is executed.

[0203] During the state data transfer process, to preserve large amounts of state data long-term, cloud storage typically stores state data on relatively inexpensive storage media. These media have slower access speeds and higher latency. Furthermore, state data is often stored at lower access frequency layers. Therefore, during the recovery of the second state data from cloud storage, if the data cannot be immediately retrieved, a defreezing command must first be sent to the cloud storage to inform it that the second encoded byte stream needs to be defreezed and a timer should begin. A maximum defreezing duration, i.e., a second preset duration, is set. When the timer reaches the second preset duration, it is assumed that the cloud storage has defreezed the second encoded byte stream, and then the step of retrieving the second encoded byte stream stored in the first storage address is executed.

[0204] Specifically, the unfreezing process for cloud storage involves transferring data from low-cost, low-performance storage media to higher-performance storage media, enabling instant access. When a user requests to read a file in archive storage, the service provider needs to retrieve the file from tape or other storage devices and move it to a storage device (such as a hard drive) that allows for fast access.

[0205] By sending a unfreezing command to cloud storage and initiating a timer, while simultaneously setting a second preset duration, the orderly and operable nature of data recovery is ensured. The system can wait for the unfreezing process to complete according to the set procedure, avoiding disorderly and frequent queries to cloud storage and improving system operational efficiency. When the timer reaches the second preset duration, the system assumes the data has been unfrozen and subsequent operations can proceed, making the data recovery process more orderly and controllable. This avoids operational failures or anomalies caused by unfrozen data and ensures the stability of the entire data recovery process.

[0206] In some implementations, the target contract identifier for determining the running smart contract includes:

[0207] Determine the target contract identifier of the running smart contract and obtain the first block currently on the blockchain;

[0208] After writing the second state data under the target contract identifier in the target Merkel state tree, the method further includes:

[0209] (1) When a query instruction for the second state data is read during the processing of the task to be processed, the second block currently on the blockchain is obtained;

[0210] (2) Determine the third block that is a preset number of blocks after the first block;

[0211] (3) When the second block is between the first block and the third block, a prompt message is generated and returned to the client that sent the task to be processed. The prompt message is used to indicate that the query failed.

[0212] While the blockchain processing node running the smart contract restores the second state data to its local target Merkle state tree, it does not immediately share this restored second state data with other blockchain processing nodes. To prevent different nodes from reading different states and compromising the consistency of the blockchain system by allowing immediate access to the second state data, a maximum synchronization duration needs to be set. Only when the maximum synchronization duration is reached is it assumed that all blockchain nodes have synchronized the second state data to their respective Merkle state trees. This maximum synchronization duration is reflected by a preset number of blocks.

[0213] Therefore, upon reading the state data recovery instruction identifier, the target contract identifier of the running smart contract is determined, and the first block currently on the blockchain is retrieved. This first block records the time point when the state data recovery instruction identifier is read. After writing the second state data to the target contract identifier in the local target Merkle state tree, if a query instruction for the second state data is read, it indicates that the second state data needs to be queried during the processing of the task to be processed. To avoid inconsistencies in state data caused by other blockchain nodes not recovering the second state data in a timely manner, it is necessary to retrieve the second block currently on the blockchain, i.e., record the query time point for the second state data. The third block is the preset number of blocks after the first block, i.e., the timer starts from the time point when the state data recovery instruction identifier is read. When the timer reaches the third preset time (preset number of blocks), it is assumed that all other blockchain nodes have recovered the second state data, i.e., the third block has been reached.

[0214] Specifically, if the second block is located between the first block and the third block, it means that the query for the second state data was executed at a time when other blockchain nodes had not yet recovered the second state data. To avoid the problem of inconsistent state data, the query for the second state data is rejected, and a prompt message is sent to the client of the pending task to indicate that the query failed.

[0215] Therefore, by setting a maximum synchronization time (represented by a preset number of blocks), it is possible to effectively avoid different blockchain nodes reading different state data. After the second state data is restored to the local target Merkle state tree, but before its consensus is shared with other blockchain nodes, the problem of state data inconsistency between different blockchain nodes may occur.

[0216] In some implementations, before determining the first storage address corresponding to the target contract identifier based on the preset mapping relationship between each storage address and contract identifier in cloud storage, the method further includes:

[0217] (1) Obtain permission configuration information for state data transfer;

[0218] (2) When the permission configuration information indicates that state data transfer is allowed, the step of determining the first storage address corresponding to the target contract identifier based on the preset mapping relationship between each storage address and the contract identifier in cloud storage is executed.

[0219] In particular, since there is a possibility that the transfer of state data to cloud storage may be prohibited by the permission configuration information during the state data transfer process, it is necessary to obtain the permission configuration information for state data transfer. The permission configuration information is used to determine whether the state data was stored in the local target storage area or in cloud storage when it was transferred.

[0220] Specifically, if the permission configuration information indicates that state data transfer is allowed, it means that the transferred second state data is stored in cloud storage. Therefore, the step of determining the first storage address corresponding to the target contract identifier is executed based on the preset mapping relationship between each storage address and the contract identifier in the cloud storage.

[0221] Therefore, by obtaining the permission configuration information for state data transfer, the system can accurately manage the storage location of state data based on this information. This avoids data storage chaos caused by ambiguous permissions, ensuring that the storage location of state data is determined according to the permission configuration information, thereby improving the efficiency of state data retrieval.

[0222] In some embodiments, the method further includes:

[0223] (1) When the permission configuration information indicates that state data transfer is prohibited, determine the second storage address corresponding to the target contract identifier from the target storage area;

[0224] (2) Write the second state data stored in the second storage address into the target contract identifier in the target Merkel state tree.

[0225] If the permission configuration information indicates that state data transfer is prohibited, it means that the transferred second state data is stored in the local target storage area. Therefore, the second storage address corresponding to the target contract identifier is determined in the target storage area, so that the second state data stored in the second storage address is written into the target contract identifier in the target Merkle state tree to realize the recovery of the second state data.

[0226] Therefore, the source of data recovery is determined based on the permission configuration information, ensuring that the system operation follows established rules and strategies. When the permission configuration information indicates that state data transfer is prohibited, the system will perform data recovery from the local target storage area, avoiding data operation problems caused by violating permission configuration requirements.

[0227] As described above, this embodiment of the application obtains a task to be processed. When a state data transfer instruction identifier is read during the processing of the task to be processed, the target contract identifier of the running smart contract is determined. The first state data corresponding to the target contract identifier in the target Merkle state tree is determined. The target Merkle state tree includes the contract identifier of each smart contract and the state data contained in each contract identifier. Based on the preset mapping relationship between each storage address and the contract identifier in cloud storage, the first storage address corresponding to the target contract identifier is determined. The write interface of the cloud storage is called to write the first state data to the first storage address and delete the first state data in the target Merkle state tree.

[0228] Therefore, when a state data transfer instruction identifier is read during the processing of a task, the first state data corresponding to the target contract identifier of the running smart contract is determined from the target Merkle state tree. Based on the target contract identifier, the corresponding first storage address in cloud storage is determined, and the write interface of cloud storage is called to transfer the first state data in the target Merkle state tree to the first storage address in cloud storage. The first state data in the target Merkle state tree is then deleted. Compared with related technologies where state data can only be stored on local disks, this application provides a data transfer technology that transfers the first state data in the target Merkle state tree stored on local disks to cloud storage. This avoids the problem that as state data increases, the available storage space on local disks gradually decreases, or even becomes unusable for storing state data. This saves storage overhead on local disks, improves storage resource utilization, and ensures the normal operation of the blockchain.

[0229] Please see Figure 3 , Figure 3 This is an interactive diagram illustrating the priority data processing procedure provided in this application embodiment. The client sends a task to be processed to blockchain node A. When a state data transfer instruction identifier is read during processing, and blockchain node A allows state data transfer, the first state data in Merkel state tree A is transferred to cloud storage. After processing, blockchain node A packages the dequeue result and corresponding state data into block N and uploads it to the chain, enabling blockchain nodes B and C to obtain block N from the chain to achieve consensus synchronization of state data. For cases where blockchain node C prohibits state data transfer, the first state data is transferred from Merkel state tree C to blockchain node C's local storage area. When the smart contract deployed on the virtual machine in blockchain node B reads a state data recovery instruction identifier, it retrieves the second state data to be recovered from cloud storage and restores the second state data from cloud storage to Merkel state tree B. The ledger program in each blockchain node is responsible for recording the transaction information involved in the task to be processed sent by the client. When blockchain nodes (such as A, B, and C) process tasks, the ledger program receives and records the details of these transactions, including key information such as the parties involved, the transaction amount, and the transaction time.

[0230] In some implementations, please refer to Figure 4 , Figure 4This is an interactive diagram illustrating the state data transfer process provided in this application embodiment. When the virtual machine of smart contract 2 reads the state data transfer instruction identifier, it executes the smart contract's state data transfer instruction. It searches the target Merkle state tree for the first state data (state data is in the form of key-value pairs of data type and corresponding data content) included in contract identifier 2 corresponding to smart contract 2. The first state data is written to the first storage address corresponding to contract identifier 2 in cloud storage. After writing the first state data to the first storage address, the state data is deleted, and the first virtual resource reward is sent to the blockchain node processing the pending task. Then, the amount of space released by the state data transfer is determined using the following code, and the amount of space is returned to the top of the stack for use by other subsequent code:

[0231] STACK_TOP = PUSH(Length);

[0232] Here, PUSH() is the instruction to add an element to the virtual machine's stack, and STACK_TOP is the content added to the top of the stack.

[0233] In some implementations, please refer to Figure 5 , Figure 5 This is an interactive schematic diagram of the state data recovery process provided in this application embodiment. When the virtual machine of smart contract 2 reads the state data recovery instruction identifier, it executes the state data recovery instruction of the smart contract, reads the size of the second encoded byte stream stored in the first storage address corresponding to contract identifier 2 in cloud storage and calculates the second virtual resource reward for deduction, unfreezes the second encoded byte stream, and after the unfreezing reaches the second preset time, it obtains the stored second encoded byte stream, deserializes it to obtain the second state data and writes it into the Merkle state tree.

[0234] For details on the implementation of each of the above steps, please refer to the previous examples, which will not be repeated here.

[0235] To facilitate better implementation of the data processing method provided in the embodiments of this application, the embodiments of this application also provide an apparatus based on the above-described data processing method. The meanings of the terms used are the same as in the data processing method described above, and specific implementation details can be found in the descriptions within the method embodiments.

[0236] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application. The data processing device is applied to a computer device. The data processing device may include a first acquisition unit 401, a first determination unit 402, a second determination unit 403, and a first data writing unit 404, etc.

[0237] The first acquisition unit 401 is used to acquire the task to be processed. When the state data transfer instruction identifier is read during the processing of the task to be processed, the target contract identifier of the running smart contract is determined.

[0238] The first determining unit 402 is used to determine the first state data corresponding to the target contract identifier in the target Merkel state tree. The target Merkel state tree includes the contract identifier of each smart contract and the state data contained in each contract identifier.

[0239] The second determining unit 403 is used to determine the first storage address corresponding to the target contract identifier based on the preset mapping relationship between each storage address and the contract identifier in the cloud storage;

[0240] The first data writing unit 404 is used to call the write interface of the cloud storage, write the first state data to the first storage address, and delete the first state data in the target Merkel state tree.

[0241] In some embodiments, the first data writing unit 404 includes:

[0242] The calling subunit is used to call the write interface of the cloud storage to write the first status data to the first storage address;

[0243] A caching subunit is used to cache the first state data in a local cache area and delete the first state data in the target Merkel state tree;

[0244] The timing subunit is used to start the timing. When the timing duration reaches the first preset duration, the first state data is deleted from the local cache.

[0245] In some embodiments, the first data writing unit 404 further includes:

[0246] The rewrite subunit is used to rewrite the first state data in the local cache back into the target Merkle state tree when it receives a write failure instruction for the first state data sent by the cloud storage.

[0247] In some embodiments, the apparatus further includes:

[0248] The second acquisition unit is used to acquire permission configuration information for state data transfer;

[0249] The first execution unit is used to execute the step of determining the first storage address corresponding to the target contract identifier based on the preset mapping relationship between each storage address and the contract identifier in cloud storage when the permission configuration information indicates that state data transfer is allowed.

[0250] In some embodiments, the apparatus further includes:

[0251] The third acquisition unit is used to acquire the second storage address corresponding to the target contract identifier in the target storage area when the permission configuration information indicates that state data transfer is prohibited.

[0252] The second data writing unit is used to write the first state data to the second storage address and delete the first state data in the target Merkel state tree.

[0253] In some embodiments, the first data writing unit 404 includes:

[0254] The encoding subunit is used to serialize and encode each first state data corresponding to the target contract identifier in the target Merkel state tree to obtain a first encoded byte stream.

[0255] The data writing subunit is used to write the first encoded byte stream to the first storage address.

[0256] In some embodiments, the apparatus further includes:

[0257] The third determining unit is used to determine the target contract identifier of the running smart contract when a state data recovery instruction identifier is read during the processing of the task to be processed.

[0258] The fourth determining unit is used to determine the first storage address corresponding to the target contract identifier based on the preset mapping relationship between each storage address and the contract identifier in cloud storage;

[0259] Extraction unit, used to extract the stored second state data from the first storage address;

[0260] The third data writing unit is used to write the second state data into the target contract identifier in the target Merkel state tree.

[0261] In some embodiments, the extraction unit includes:

[0262] The first acquisition subunit is used to acquire the second encoded byte stream stored in the first storage address;

[0263] The decoding subunit is used to deserialize and decode the second encoded byte stream to obtain the second state data;

[0264] The extraction subunit is used to extract the second state data.

[0265] In some embodiments, the extraction unit further includes:

[0266] The sending subunit is used to send a unfreezing instruction to the cloud storage to unfreeze the second encoded byte stream and to start a timer;

[0267] An execution subunit is used to execute the step of obtaining the second encoded byte stream stored in the first storage address when the timing duration reaches the second preset duration.

[0268] In some embodiments, the third determining unit includes:

[0269] The second acquisition subunit is used to determine the target contract identifier of the running smart contract and to acquire the first block currently on the blockchain.

[0270] The device further includes:

[0271] The fourth acquisition unit is used to acquire the second block currently on the blockchain when a query instruction for the second state data is read during the processing of the task to be processed.

[0272] The fifth determining unit is used to determine a third block that is a preset number of blocks after the first block;

[0273] The generation unit is configured to generate a prompt message when the second block is located between the first block and the third block, and return the prompt message to the client that sent the task to be processed. The prompt message is used to indicate that the query failed.

[0274] In some embodiments, the apparatus further includes:

[0275] The fifth acquisition unit is used to acquire permission configuration information for state data transfer;

[0276] The second execution unit is used to execute the step of determining the first storage address corresponding to the target contract identifier based on the preset mapping relationship between each storage address and the contract identifier in cloud storage when the permission configuration information indicates that state data transfer is allowed.

[0277] In some embodiments, the apparatus further includes:

[0278] The sixth determining unit is used to determine the second storage address corresponding to the target contract identifier from the target storage area when the permission configuration information indicates that state data transfer is prohibited;

[0279] The fourth data writing unit is used to write the second state data stored in the second storage address into the target contract identifier in the target Merkel state tree.

[0280] As described above, in this embodiment, the first acquisition unit 401 acquires the task to be processed. When a state data transfer instruction identifier is read during the processing of the task to be processed, the target contract identifier of the running smart contract is determined. The first determination unit 402 determines the first state data corresponding to the target contract identifier in the target Merkle state tree. The target Merkle state tree includes the contract identifier of each smart contract and the state data contained in each contract identifier. The second determination unit 403 determines the first storage address corresponding to the target contract identifier based on the preset mapping relationship between each storage address and the contract identifier in the cloud storage. The first data writing unit 404 calls the writing interface of the cloud storage to write the first state data to the first storage address and deletes the first state data in the target Merkle state tree.

[0281] Therefore, when a state data transfer instruction identifier is read during the processing of a task, the first state data corresponding to the target contract identifier of the running smart contract is determined from the target Merkle state tree. Based on the target contract identifier, the corresponding first storage address in cloud storage is determined, and the write interface of cloud storage is called to transfer the first state data in the target Merkle state tree to the first storage address in cloud storage. The first state data in the target Merkle state tree is then deleted. Compared with related technologies where state data can only be stored on local disks, this application provides a data transfer technology that transfers the first state data in the target Merkle state tree stored on local disks to cloud storage. This avoids the problem that as state data increases, the available storage space on local disks gradually decreases, or even becomes unusable for storing state data. This saves storage overhead on local disks, improves storage resource utilization, and ensures the normal operation of the blockchain.

[0282] The specific implementation of each of the above units can be found in the previous embodiments, and will not be repeated here.

[0283] Reference Figure 7 , Figure 7This is a partial structural block diagram of a computer device 110 implementing an embodiment of the present disclosure. The computer device 110 can vary significantly due to different configurations or performance characteristics, and may include one or more central processing units (CPUs) 622 (e.g., one or more processors) and a memory 632, and one or more storage media 630 (e.g., one or more mass storage devices) storing application programs 642 or data 644. The memory 632 and storage media 630 may be temporary or persistent storage. The program stored in the storage media 630 may include one or more modules (not shown in the figure), each module including a series of instruction operations on the computer device 600. Furthermore, the central processing unit 622 may be configured to communicate with the storage media 630 and execute the series of instruction operations in the storage media 630 on the computer device 600.

[0284] Computer device 110 may also include one or more power supplies 626, one or more wired or wireless network interfaces 650, one or more input / output interfaces 658, and / or one or more operating systems 641, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0285] The central processing unit 622 in the computer device 110 can be used to execute the data processing method of the embodiments of this disclosure, for example:

[0286] Obtain the task to be processed. When the state data transfer instruction identifier is read during the processing of the task to be processed, determine the target contract identifier of the running smart contract.

[0287] Determine the first state data corresponding to the target contract identifier in the target Merkle state tree, wherein the target Merkle state tree includes the contract identifier of each smart contract and the state data contained in each contract identifier;

[0288] Based on the preset mapping relationship between each storage address and contract identifier in cloud storage, the first storage address corresponding to the target contract identifier is determined;

[0289] The cloud storage's write interface is invoked to write the first state data to the first storage address, and the first state data in the target Merkel state tree is deleted.

[0290] This disclosure also provides a computer-readable storage medium for storing program code for executing the data processing methods of the foregoing embodiments.

[0291] This disclosure also provides a computer program product comprising a computer program. A processor of a computer device reads and executes the computer program, causing the computer device to perform the data processing method described above. For example:

[0292] Obtain the task to be processed. When the state data transfer instruction identifier is read during the processing of the task to be processed, determine the target contract identifier of the running smart contract.

[0293] Determine the first state data corresponding to the target contract identifier in the target Merkle state tree, wherein the target Merkle state tree includes the contract identifier of each smart contract and the state data contained in each contract identifier;

[0294] Based on the preset mapping relationship between each storage address and contract identifier in cloud storage, the first storage address corresponding to the target contract identifier is determined;

[0295] The cloud storage's write interface is invoked to write the first state data to the first storage address, and the first state data in the target Merkel state tree is deleted.

[0296] Furthermore, the terms “comprising” and “including”, and any variations thereof, are intended to cover non-exclusive inclusion, such that a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product, or apparatus.

[0297] It should be understood that in this disclosure, "at least one item" means one or more, and "more than one" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0298] It should be understood that in the description of the embodiments disclosed herein, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0299] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0300] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0301] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0302] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0303] It should also be understood that the various implementation methods provided in this disclosure can be combined arbitrarily to achieve different technical effects.

[0304] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0305] The above is a detailed description of the embodiments of this disclosure. However, this disclosure is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this disclosure. All such equivalent modifications or substitutions are included within the scope defined by the claims of this disclosure.

Claims

1. A data processing method, characterized in that, include: Obtain the task to be processed. When the state data transfer instruction identifier is read during the processing of the task to be processed, determine the target contract identifier of the running smart contract. Determine the first state data corresponding to the target contract identifier in the target Merkle state tree, wherein the target Merkle state tree includes the contract identifier of each smart contract and the state data contained in each contract identifier; Based on the preset mapping relationship between each storage address and contract identifier in cloud storage, the first storage address corresponding to the target contract identifier is determined; The cloud storage's write interface is invoked to write the first state data to the first storage address, and the first state data in the target Merkel state tree is deleted.

2. The data processing method according to claim 1, characterized in that, The step of calling the cloud storage's write interface to write the first state data to the first storage address and deleting the first state data from the target Merkel state tree includes: Call the write interface of the cloud storage to write the first status data to the first storage address; The first state data is cached in the local cache area, and the first state data is deleted from the target Merkel state tree; Start the timer. When the timer reaches the first preset duration, delete the first state data from the local cache.

3. The data processing method according to claim 2, characterized in that, Before deleting the first state data from the local cache, the method further includes: When a write failure instruction for the first state data is received from the cloud storage, the first state data in the local cache is rewritten back into the target Merkel state tree.

4. The data processing method according to claim 1, characterized in that, Before determining the first storage address corresponding to the target contract identifier based on the preset mapping relationship between each storage address and contract identifier in cloud storage, the method further includes: Obtain permission configuration information for state data transfer; When the permission configuration information indicates that state data transfer is allowed, the step of determining the first storage address corresponding to the target contract identifier based on the preset mapping relationship between each storage address and the contract identifier in cloud storage is executed.

5. The data processing method according to claim 4, characterized in that, The method further includes: When the permission configuration information indicates that state data transfer is prohibited, obtain the second storage address corresponding to the target contract identifier in the target storage area; Write the first state data to the second storage address and delete the first state data from the target Merkel state tree.

6. The data processing method according to any one of claims 1 to 5, characterized in that, The step of writing the first state data to the first storage address includes: Each first state data corresponding to the target contract identifier in the target Merkel state tree is serialized and encoded to obtain a first encoded byte stream; Write the first encoded byte stream to the first storage address.

7. The data processing method according to claim 1, characterized in that, The method further includes: When a status data recovery instruction identifier is read during the processing of the task to be processed, the target contract identifier of the running smart contract is determined. Based on the preset mapping relationship between each storage address and contract identifier in cloud storage, the first storage address corresponding to the target contract identifier is determined; Extract the stored second state data from the first storage address; Write the second state data under the target contract identifier in the target Merkel state tree.

8. The data processing method according to claim 7, characterized in that, The step of retrieving the stored second state data from the first storage address includes: Obtain the second encoded byte stream stored in the first storage address; The second encoded byte stream is deserialized and decoded to obtain the second state data; Extract the second state data.

9. The data processing method according to claim 8, characterized in that, Before obtaining the second encoded byte stream stored in the first storage address, the method further includes: Send a defreezing command to the cloud storage to defreeze the second encoded byte stream, and start a timer; When the timing duration reaches the second preset duration, the step of obtaining the second encoded byte stream stored in the first storage address is executed.

10. The data processing method according to claim 7, characterized in that, The target contract identifier for determining the running smart contract includes: Determine the target contract identifier of the running smart contract and obtain the first block currently on the blockchain; After writing the second state data under the target contract identifier in the target Merkel state tree, the method further includes: When a query instruction for the second state data is read during the processing of the task to be processed, the second block currently on the blockchain is obtained. Determine the third block, which is a preset number of blocks following the first block; When the second block is located between the first block and the third block, a prompt message is generated and returned to the client that sent the task to be processed. The prompt message is used to indicate that the query failed.

11. The data processing method according to claim 7, characterized in that, Before determining the first storage address corresponding to the target contract identifier based on the preset mapping relationship between each storage address and contract identifier in cloud storage, the method further includes: Obtain permission configuration information for state data transfer; When the permission configuration information indicates that state data transfer is allowed, the step of determining the first storage address corresponding to the target contract identifier based on the preset mapping relationship between each storage address and the contract identifier in cloud storage is executed.

12. The data processing method according to claim 11, characterized in that, The method further includes: When the permission configuration information indicates that state data transfer is prohibited, the second storage address corresponding to the target contract identifier is determined from the target storage area; Write the second state data stored in the second storage address into the target contract identifier in the target Merkel state tree.

13. A data processing apparatus, characterized in that, include: The first acquisition unit is used to acquire the task to be processed. When the state data transfer instruction identifier is read during the processing of the task to be processed, the target contract identifier of the running smart contract is determined. The first determining unit is used to determine the first state data corresponding to the target contract identifier in the target Merkel state tree, wherein the target Merkel state tree includes the contract identifier of each smart contract and the state data contained in each contract identifier; The second determining unit is used to determine the first storage address corresponding to the target contract identifier based on a preset mapping relationship between each storage address and the contract identifier in cloud storage; The first data writing unit is used to call the write interface of the cloud storage, write the first state data to the first storage address, and delete the first state data in the target Merkel state tree.

14. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the data processing method according to any one of claims 1 to 12.

15. A computer storage medium comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the data processing method according to any one of claims 1 to 12.