Blockchain data processing method, server and medium

Abstract

The application is suitable for the technical field of computers, and provides a blockchain data processing method, a server and a medium, wherein the method comprises the following steps: receiving operation request information, the operation request information being used for indicating that a target operation is performed on a target file on a target blockchain; according to the operation request information, a target handle corresponding to the target file is found from a target position, wherein the target handle comprises a target address corresponding to the target file, and the target position comprises any one of the following: an active file and a handle pool group; according to the target handle, the target file is found, and the target operation is performed on the target file. According to the application, the target handle corresponding to the target file can be found from the active file or the handle pool group, the target file can be quickly found through the target handle, the target file to be operated can be quickly and accurately found, and the processing efficiency of the blockchain data is improved.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and in particular relates to a blockchain data processing method, server and medium. Background Technology

[0002] Blockchain is a distributed, shared ledger and database characterized by decentralization, immutability, full traceability, accountability, collective maintenance, and transparency. In practice, a blockchain typically has multiple blockchain nodes, all storing identical data, and each node usually possesses a complete ledger.

[0003] In related technologies, when it is necessary to operate on certain data in the blockchain, the data is usually retrieved by traversing and searching the blockchain, and then processed. However, since the amount of data stored in the blockchain is typically very large, this traversal search method can easily lead to low processing efficiency. Summary of the Invention

[0004] This application provides a blockchain data processing method, server, and medium, aiming to solve the problem in related technologies where, when it is necessary to operate on a certain data in the blockchain, the data is usually found by traversing and searching the blockchain, and then the data on the blockchain is processed, which easily leads to low processing efficiency of the data on the blockchain.

[0005] In a first aspect, embodiments of this application provide a blockchain data processing method, the method comprising: receiving operation request information, wherein the operation request information is used to instruct the execution of a target operation on a target file on a target blockchain;

[0006] Based on the operation request information, find the target handle corresponding to the target file from the target location. The target handle includes the target address corresponding to the target file, and the target location includes any of the following: active file, handle pool group;

[0007] Based on the target handle, locate the target file and perform the target operation on the target file.

[0008] In some embodiments, the method further includes: creating a handle pool group according to a predetermined handle pool size;

[0009] The handle pool group includes two handle pools with different working states, namely active state and idle state. The file handles in each handle pool include file identifier, file address and dynamic reference count. The dynamic reference count is used to record the number of times the corresponding file handle is currently referenced.

[0010] In some embodiments, based on the operation request information, finding the target handle corresponding to the target file from the target location includes:

[0011] If the operation request information matches the file description information of the active file, then the file handle of the active file is determined as the target handle;

[0012] If the operation request information does not match the file description information of the active file, then the file handle that matches the operation request information is searched from the handle pool group, and the found file handle is determined as the target handle.

[0013] In some embodiments, if the handle pool group includes two handle pools with different working states, searching for a file handle that matches the operation request information from the handle pool group, and determining the found file handle as the target handle, includes:

[0014] The target handle is searched from the active handle pool, and / or if the target handle is not found in the active handle pool, the target handle is searched from the idle handle pool.

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

[0016] If the target handle is found in the active handle pool, the dynamic reference count of the corresponding file handle in the active handle pool is increased.

[0017] If the target handle does not exist in the active handle pool, the target handle is created based on the operation request information, and the created target handle is stored in the active handle pool.

[0018] In some embodiments, after finding the target handle corresponding to the target file from the target location based on the operation request information, the method further includes:

[0019] If no target handle corresponding to the target file exists at the target location, the block data stored on the target blockchain is traversed until a target file matching the operation request information is found.

[0020] The file address of the target file obtained from the query is determined as the target address. Based on the file identifier of the target file, the target address and the preset reference count, a target handle corresponding to the target file is created and the target handle is stored in the handle pool that is in an active state.

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

[0022] After performing the target operation on the target file, if a target handle is detected in the idle handle pool, the dynamic reference count of the corresponding file handle in the idle handle pool is reduced; if no target handle is detected in the idle handle pool, the dynamic reference count of the corresponding file handle in the active handle pool is reduced.

[0023] Delete the file handles in the handle pool that are in an idle state and have a corresponding dynamic reference count of zero.

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

[0025] If the handle pool group includes two handle pools with different working states, the working states of the two handle pools will be switched when the preset trigger condition is triggered. The preset trigger condition includes at least one of the following: the preset switching period has been reached and the number of file handles in the active handle pool exceeds a preset number threshold.

[0026] When the active file is full, the active file is stored on the chain, and the file handle of the active file is written to the handle pool that is in an active state. A new file with a corresponding file handle is created, and the new file is switched to the active file.

[0027] Secondly, embodiments of this application provide a blockchain data processing apparatus, the apparatus comprising:

[0028] The information receiving unit is used to receive operation request information, which instructs the execution of a target operation on a target file on the target blockchain.

[0029] The handle lookup unit is used to find the target handle corresponding to the target file from the target location according to the operation request information. The target handle includes the target address corresponding to the target file, and the target location includes any one of the following: active file, handle pool group;

[0030] The operation execution unit is used to locate the target file based on the target handle and to perform target operations on the target file.

[0031] Thirdly, embodiments of this application provide a server, including 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 steps of any of the above-described blockchain data processing methods.

[0032] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of any of the aforementioned blockchain data processing methods.

[0033] Fifthly, embodiments of this application provide a computer program product that, when run on a server, causes the server to execute any of the aforementioned blockchain data processing methods.

[0034] The beneficial effects of this application embodiment compared with related technologies are: since a file handle can usually point to the file address of the corresponding file, the target handle corresponding to the target file can be found from the active file or the handle pool group, and the target file can be found quickly through the target handle. This can achieve the goal of finding the target file that needs to be operated on quickly and accurately, which helps to improve the processing efficiency of blockchain data.

[0035] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0036] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the 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.

[0037] Figure 1 This is a schematic flowchart of a blockchain data processing method provided in an embodiment of this application;

[0038] Figure 2 This is a flowchart illustrating a blockchain data processing method provided in another embodiment of this application;

[0039] Figure 3 This is a flowchart illustrating a blockchain data processing method provided in another embodiment of this application;

[0040] Figure 4 This is a schematic diagram of the structure of a blockchain data processing device provided in an embodiment of this application;

[0041] Figure 5 This is a schematic diagram of the structure of a server provided in one embodiment of this application. Detailed Implementation

[0042] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0043] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0044] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0045] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0046] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0047] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0048] To illustrate the technical solution of this application, the following embodiments will be used for explanation.

[0049] Continue reading Figure 1 This application provides a blockchain data processing method, including:

[0050] Step 101: Receive operation request information.

[0051] The aforementioned operation request information is used to instruct the execution of a target operation on a target file on the target blockchain.

[0052] In practice, operation request information typically includes a file identifier for the target file and an operation description describing the target operation. The file identifier is usually the filename. The target operation can be performed on the entire target file or on one or more data items within the target file. When the target operation involves operating on one or more data items within the target file, the operation request information may also include the data identifier of the data to be operated on. The data in the target file can be transaction data, log data, or other types of data. In practical applications, operations performed on the target file or its data can include, but are not limited to: reset, delete, copy, and restore operations.

[0053] In this embodiment, the executing entity of the above-described blockchain data processing method is typically the target blockchain, specifically, each blockchain node on the target blockchain. In practical applications, each blockchain node can be implemented as either a terminal or a server.

[0054] In practice, the aforementioned execution entity can receive the operation request information from the user terminal of the communication connection, or it can receive the operation request information from other blockchains.

[0055] Step 102: Based on the operation request information, locate the target handle corresponding to the target file from the target location.

[0056] The target handle includes the target address corresponding to the target file. The target location includes any of the following: an active file, or a handle pool group.

[0057] The target handle mentioned above is typically the file handle corresponding to the target file. The target address mentioned above is typically the file address of the target file. The active file mentioned above is typically a file in the blockchain node that has not yet been uploaded to the blockchain and is in a write-to-access state.

[0058] In practice, the aforementioned handle pool group is typically a combination of multiple pre-established handle pools. A handle pool group can contain two or more handle pools. Setting up multiple handle pools allows for independent management of file handles in each pool. For example, some handle pools can be used normally during a certain period, while others can clear file handles that have not been used for a long time. Multiple handle pools working in parallel can promptly clear file handles that have not been used for a long time, thus reducing the need for each handle pool to have a large capacity. This ensures efficient searching for target files while saving storage space occupied by all handle pools. It should be noted that the aforementioned handle pools are typically used to store file handles. Each handle pool in the handle pool group can be implemented as a data queue.

[0059] In practical applications, a handle pool group typically includes two handle pools with different operating states, usually one active and the other idle. The idle handle pool is responsible for promptly clearing file handles that have not been used for a long time. The active handle pool is responsible for adding and referencing new file handles. The operating states of the two handle pools can usually be swapped. For example, after a 2-minute interval, the handle pool that was originally active can be switched to an idle state, and the handle pool that was originally idle can be switched to an active state. This allows for timely and effective clearing of unused file handles, further saving storage space.

[0060] Furthermore, when each file handle in the handle pool includes a file identifier, file address, and dynamic reference count, file handles with a dynamic reference count of zero that are currently idle can be promptly deleted. The dynamic reference count records the number of times the corresponding file handle is currently referenced. For example, if file handle 1 in handle pool A has a dynamic reference count of 5, it indicates that file handle 1 is currently being accessed by 5 requesters. Each file handle supports being accessed by multiple requesters simultaneously, offering high practicality and flexibility. In practical applications, file handles can also include other information, such as the current file status. The current file status can be used to identify the current state of the file corresponding to that file handle. The current file status can include an operational state and an idle state. For example, when an operation is about to be performed on a file, the current file status can be marked as operational; after the operation is performed on the file, the current file status can be marked as idle.

[0061] The aforementioned active files are typically files in a write-to-the-chain state that are not yet stored on the blockchain. Multiple data entries can be written to an active file sequentially. When an active file is full, the executing entity can write the file handle of the active file to the active handle pool. In practice, when the file handle of an active file is written to the active handle pool, the newly added file handle can include the filename of the active file, the file address where the active file is stored on the blockchain, and the initial reference count. The initial reference count is usually a pre-set value. In practice, the initial reference count is typically 0.

[0062] It should be noted that when the current active file is full and stored on the chain, the aforementioned execution entity can generate a new active file for writing data, and create a corresponding file handle for the new active file, and so on.

[0063] Here, the aforementioned execution entity can use operation request information to find the target handle corresponding to the target file from the target location.

[0064] As an example, the aforementioned execution entity can compare the file identifier included in the operation request information with the file identifier of the active file. If the two match, it can be determined that the current active file is the aforementioned target file. In this case, the file handle corresponding to the active file can be directly determined as the aforementioned target handle.

[0065] As another example, the aforementioned execution entity may use the file identifier included in the operation request information to search for a file handle in the handle pool group whose corresponding file identifier is the same as the file identifier of the target file, and determine the found file handle as the aforementioned target handle.

[0066] Step 103: Locate the target file based on the target handle, and perform the target operation on the target file.

[0067] Here, after obtaining the target handle corresponding to the target file, since the target handle can point to the file address of the target file, the execution entity can directly use the target handle to find the target file and perform the target operation on the target file.

[0068] The method provided in this embodiment, since file handles can usually point to the file address of the corresponding file, can quickly find the target file by searching for the target handle corresponding to the target file from the active file or the handle pool group, thereby improving the efficiency of blockchain data processing.

[0069] Continue to refer to Figure 2 This is a flowchart illustrating a blockchain data processing method provided in an embodiment of this application. Figure 2 The blockchain data processing method shown may include the following steps 201 to 204.

[0070] Step 201: Create a handle pool group according to the predetermined handle pool size.

[0071] The handle pool group comprises two handle pools with different working states. Working states can include active and idle states. Each file handle in the handle pool includes a file identifier, file address, and dynamic reference count. The dynamic reference count records the number of times the corresponding file handle is currently referenced. It should be noted that if the dynamic reference count of a file handle in a handle pool is not 1, it indicates that the file handle is being accessed by multiple requesters. For example, if the dynamic reference count of file handle 1 in handle pool A is 5, it means that file handle 1 is currently being accessed by 5 requesters. Each file handle supports simultaneous access by multiple requesters, offering high practicality and flexibility.

[0072] In practical applications, a handle pool group typically includes two handle pools with different operating states, usually one active and the other idle. The idle handle pool is responsible for promptly clearing file handles that have not been used for a long time. The active handle pool is responsible for adding and referencing new file handles. The operating states of the two handle pools can usually be swapped. For example, after a period of time, the handle pool that was originally active can be switched to an idle state, and the handle pool that was originally idle can be switched to an active state. This allows for timely and effective clearing of unused file handles, further saving storage space.

[0073] Furthermore, if each file handle in the handle pool includes a file identifier, file address, and dynamic reference count, file handles with a dynamic reference count of zero that are in an idle state can be deleted promptly. If each file handle in the handle pool also includes the current file state, file handles with a dynamic reference count of zero and whose corresponding file is currently in an idle state can be deleted promptly.

[0074] The handle pool size mentioned above typically indicates the capacity of the handle pool. In practice, this handle pool size can be entered by the user or set by default. It should be noted that the handle pool capacity usually refers to the number of file handles the handle pool can hold.

[0075] In practice, the handle pools described above are typically used to store file handles. Each handle pool in a handle pool group can be implemented as a data queue.

[0076] Here, the aforementioned execution entity can use the aforementioned handle pool size to create multiple handle pools, thereby obtaining the aforementioned handle pool group. For example, if the handle pool size indicates that the capacity of the handle pool is 100, then the aforementioned execution entity can allocate a storage space that can accommodate 100 file handles, and this storage space is the handle pool.

[0077] It should be noted that each handle pool in the handle pool group is the same size, which facilitates management and maintenance. Additionally, by default, the handle pool is empty; that is, when not in use, the handle pool does not store file handles.

[0078] Step 202: Receive operation request information.

[0079] The operation request information is used to instruct the execution of a target operation on a target file on the target blockchain.

[0080] Step 203: Based on the operation request information, locate the target handle corresponding to the target file from the target location.

[0081] The target handle includes the target address corresponding to the target file, and the target location includes any of the following: active file, handle pool group.

[0082] Step 204: Locate the target file based on the target handle, and perform the target operation on the target file.

[0083] In this embodiment, the specific operations of steps 202-204 are the same as those of... Figure 1 The operations of steps 101-103 in the illustrated embodiments are basically the same, and will not be described in detail here.

[0084] This embodiment creates two handle pools with different operating states: one active and the other idle. The idle handle pool is responsible for promptly clearing file handles that have not been used for a long time. The active handle pool is responsible for adding and referencing new file handles. The two handle pools work in parallel, and their operating states can be switched, ensuring the timely removal of unused file handles. This way, the capacity of each handle pool does not need to be too large, ensuring efficient searching of target files while further saving storage space occupied by all handle pools.

[0085] In some alternative implementations, the above-mentioned method of finding the target handle corresponding to the target file from the target location based on the operation request information may include the following first and second steps.

[0086] The first step is to determine the target handle if the operation request information matches the file description information of the active file.

[0087] The file description information of the aforementioned active files is typically used to describe the active files. In practice, the file description information of active files usually includes the file identifier of the active file.

[0088] Here, the executing entity can compare the file identifier of the target file included in the operation request information with the file identifier included in the file description information of the active file. If they match, the active file can be considered the target file to be found. In this case, the file handle corresponding to the active file can be determined as the target handle.

[0089] The second step is to search for a file handle that matches the operation request information from the handle pool group if the operation request information does not match the file description information of the active file, and to identify the found file handle as the target handle.

[0090] Here, if the operation request information does not match the file description information of the active file, it indicates that the target file to be searched is not the currently active file. In this case, the executing entity can use the file identifier included in the operation request information to continue searching the handle pool group for a file handle whose file identifier matches the target file's file identifier. If a file handle with the same file identifier as the target file is found in the handle pool group, the found file handle can be identified as the target handle.

[0091] In this implementation, the target handle is first searched for from the active file. If the file handle of the active file is not the target handle, the target handle is then searched from the handle pool group. This allows for an ordered search from multiple locations, which helps improve search efficiency.

[0092] In some alternative implementations, the second step described above, which involves searching for a file handle that matches the operation request information from the handle pool group and identifying the found file handle as the target handle, may include: searching for the target handle from the active handle pool, and / or searching for the target handle from the idle handle pool if the target handle is not found in the active handle pool.

[0093] Here, the handle pool group includes two handle pools with different operating states. In this case, the aforementioned execution entity can either search for the target handle only from the active handle pool, or first search for the target handle from the active handle pool. If the target handle is not found in the active handle pool, then it will search for the target handle from the idle handle pool.

[0094] When searching for the target handle solely from the active handle pool, if the target handle is not found in the active handle pool, the executing entity can assume that no target handle corresponding to the target file exists at the target location. In this case, the executing entity can find the target file and the file address used to store the target file by traversing the block data stored on the blockchain, and create a target handle for the found target file. Since the idle handle pool is responsible for promptly clearing file handles that have not been used for a long time, and the active handle pool is responsible for adding and referencing new file handles, searching for the target handle solely from the active handle pool simplifies the operation by ensuring that the two handle pools work efficiently in parallel, with no overlap in their tasks.

[0095] It should be noted that since the target handle may exist in multiple handle pools simultaneously, prioritizing searches in active handle pools allows for more efficient and orderly information retrieval, further improving search efficiency. Additionally, since the primary responsibility of idle handle pools is to promptly clean up unused file handles, prioritizing searches in active handle pools ensures that both handle pools can work in parallel more efficiently.

[0096] In some optional implementations of embodiments, if the handle pool group includes two handle pools with different working states, the execution entity typically follows the following search order when using operation request information to find the target handle corresponding to the target file from the target location: First, the target handle is searched from the file handle of the active file. Then, if the file handle of the active file is not the target handle, the target handle is searched from the handle pool that is in an active state. Finally, if the target handle does not exist in the handle pool that is in an active state, the target handle is searched from the handle pool that is in an idle state.

[0097] Furthermore, if the target handles do not exist at any of the target locations, the executing entity can locate the target file and its storage address by traversing the block data stored on the blockchain. In this case, the executing entity can create a target handle for the found target file and store it in an active handle pool. This way, when the target file needs to be operated on again, it can be quickly located using its corresponding file handle, thereby improving blockchain data processing efficiency.

[0098] In the optional implementations of various embodiments, if the handle pool group includes two handle pools with different working states, and the file handles in each handle pool include file identifiers, file addresses, and dynamic reference counts, then the above blockchain data processing method may further include the following steps one and two.

[0099] Step 1: If the target handle is found in the active handle pool, increase the dynamic reference count of the corresponding file handle in the active handle pool.

[0100] Here, if the target handle exists in an active handle pool, when the target handle is found, the aforementioned execution entity can increase the dynamic reference count of the corresponding file handle in the active handle pool according to a pre-defined increment method. This increment method can be 1, 2, or other methods. In practice, it is usually 1 increment.

[0101] For example, if the target handle exists in an active handle pool A, specifically file handle 1 in handle pool A, then when the target handle is found, the dynamic reference count of file handle 1 in handle pool A can be increased by 1.

[0102] Step 2: If the target handle does not exist in the active handle pool, the target handle is created according to the operation request information, and the created target handle is stored in the active handle pool.

[0103] Here, when searching for the target handle only from the pool of active handles, if the target handle is not found in the pool, the executing entity can assume that no target handle corresponding to the target file exists at the target location. In this case, the executing entity can create the target handle as follows: traverse the block data stored on the blockchain to find the target file matching the operation request information and the file address used to store the target file; then, create the target handle using the file address, file identifier, and a preset number of references. The preset number of references is usually a pre-defined number. In practice, the preset number of references is usually 1.

[0104] Furthermore, if the target handle can be searched from two handle pools sequentially, and the target handle does not exist in the active handle pool but exists in the idle handle pool, the execution entity can create the target handle as follows: It searches for a target handle matching the operation request information in the idle handle pool, and then creates the target handle based on the found target handle and a preset reference count. The newly created target handle typically has a preset dynamic reference count.

[0105] It should be noted that the primary responsibility of the active handle pool is to add and reference new file handles. If a target handle does not exist in the active handle pool but does exist in the idle handle pool, creating the target handle based on the target handle found in the idle handle pool and placing it into the active handle pool ensures timely creation of the target handle in the active handle pool, allowing the two handle pools to work more efficiently in parallel.

[0106] In some alternative implementations, the above-mentioned blockchain data processing method may also include steps three and four as follows.

[0107] Step 3: After performing the target operation on the target file, reduce the dynamic reference count of the corresponding file handle in the target handle pool based on the existence of the target handle in the idle handle pool. The target handle pool can include both idle and active handle pools.

[0108] In practice, the above-mentioned reduction of the dynamic reference count of the corresponding file handle in the idle handle pool based on the existence of the target handle in the idle handle pool includes: if the target handle is detected to exist in the idle handle pool, then the dynamic reference count of the corresponding file handle in the idle handle pool is reduced. If the target handle is detected not to exist in the idle handle pool, then the dynamic reference count of the corresponding file handle in the active handle pool is reduced.

[0109] Here, after performing the target operation on the target file, the execution entity can determine whether the target handle still exists in the idle handle pool. If it does, the execution entity can reduce the dynamic reference count of the corresponding file handle in the idle handle pool. If it does not exist, the execution entity can reduce the dynamic reference count of the corresponding file handle in the active handle pool. This allows for timely and effective management of both handle pools, saving storage space while ensuring more efficient parallel operation of the two handle pools.

[0110] It should be noted that the way to increase the dynamic reference count of a file handle can correspond to, or not correspond to, the way to decrease the dynamic reference count of a file handle.

[0111] For example, when a target handle is found, the dynamic reference count of the corresponding file handle in the active handle pool can be increased by 1, and when the operation on the target file is completed, the dynamic reference count of the corresponding file handle in the idle handle pool can be decreased by 1. Alternatively, when a target handle is found, the dynamic reference count of the corresponding file handle in the active handle pool can be increased by 2, and when the operation on the target file is completed, the dynamic reference count of the corresponding file handle in the idle handle pool can be decreased by 1. In practice, the way the dynamic reference count of a file handle is increased usually corresponds to the way the dynamic reference count of a file handle is decreased, and usually both the increase and decrease are by 1. This provides a relatively clear indication of the number of times each file handle is currently being accessed simultaneously.

[0112] In practice, after performing the target operation on the target file, if the dynamic reference count of the corresponding file handle in the target handle pool decreases, and it is detected that the target handle is not found in either handle pool, the aforementioned execution entity can issue an error message. This error message indicates that the target handle to be returned cannot be found. Timely reporting of program errors allows staff to promptly identify and resolve problems.

[0113] Step four: Delete the file handles in the handle pool that are in an idle state and have a corresponding dynamic reference count of zero.

[0114] Here, the aforementioned execution entity can promptly clear unused file handles from the idle handle pool, thus saving storage space.

[0115] It should be noted that the primary responsibility of the idle handle pool is to promptly clean up unused file handles. When the target handle still exists in the idle handle pool, reducing the dynamic reference count of the corresponding file handle in the idle handle pool after the target operation is completed helps to more quickly reduce the dynamic reference count of duplicate file handles from the idle handle pool, thereby promptly clearing these duplicate file handles. This saves storage space and ensures that the two handle pools can work more efficiently in parallel. The aforementioned duplicate file handles typically refer to file handles that exist simultaneously in both the idle and active handle pools.

[0116] In some optional implementations of the embodiments, if the handle pool group includes two handle pools with different working states, and the file handles in each handle pool include file identifiers, file addresses, and dynamic reference counts, then after finding the target handle corresponding to the target file from the target location according to the operation request information, the above blockchain data processing method may further include the following steps.

[0117] First, if no target handle corresponding to the target file exists at the target location, the block data stored on the target blockchain is traversed until a target file matching the operation request information is found.

[0118] Here, if the target handle does not exist at any of the target locations, the executing entity can find the target file and the file address used to store the target file by traversing the block data stored on the blockchain. Then, it can perform the target operation on the target file.

[0119] Then, the file address of the target file obtained from the query is determined as the target address, and a target handle corresponding to the target file is created based on the file identifier of the target file, the target address and the preset reference count, and the target handle is stored in the handle pool that is in an active state.

[0120] The aforementioned preset citation count is usually a pre-set number. In practice, the preset citation count is usually 1.

[0121] Here, when retrieving the target file and its file address from the blockchain, the aforementioned execution entity can use the target file's file identifier, file address, and preset reference count to generate a target handle corresponding to the target file. This target handle can then be stored in an active handle pool. Thus, the next time the target file needs to be operated on, it can be quickly located using its corresponding file handle, thereby improving blockchain data processing efficiency.

[0122] In some optional implementations of the embodiments, the above-mentioned blockchain data processing method may further include the following steps: if the handle pool group includes two handle pools with different working states, then when a preset triggering condition is triggered, the working states of the two handle pools are swapped.

[0123] The preset triggering conditions include at least one of the following: the number of file handles in the active handle pool exceeds a preset threshold after a preset swap period has been reached. These preset triggering conditions are typically pre-set conditions used to trigger a swapping of the working states of two handle pools. The preset swapping period is typically a pre-set period value, such as 5 minutes. The preset threshold is typically a pre-set number value, such as 50. It should be noted that the preset triggering conditions may also include other conditions besides the two listed above.

[0124] Here, the aforementioned execution entity can promptly switch the working states of the two handle pools when a preset trigger condition is met. Specifically, it can switch the handle pool that was originally in an active state to an idle state, and switch the handle pool that was originally in an idle state to an active state. This allows for the timely and effective clearing of unused file handles in the idle handle pool, further saving storage space.

[0125] Furthermore, the two handle pools operate in parallel, and their operating states can be interchanged. One pool ensures that data processing tasks proceed in an orderly manner, while the other ensures the timely removal of unused file handles. This way, the capacity of each handle pool does not need to be too large, ensuring efficient searching of target files while further conserving storage space across all handle pools.

[0126] In some optional implementations of the embodiments, the above-described blockchain data processing method may further include the following steps: when the active file is full, storing the active file on the chain and writing the file handle of the active file into the handle pool that is in an active state, creating a new file with a corresponding file handle, and switching the new file to the active file.

[0127] The aforementioned active files are typically files in a blockchain node that are not yet stored on the chain and are in a write-to-write state. Multiple data entries can be written to an active file sequentially. When an active file is full, the aforementioned executing entity can write the file handle of the active file to a handle pool that is in an active state.

[0128] In practical applications, when a file handle of an active file is written to the active handle pool, the newly added file handle can include the filename of the active file, the file address where the active file is stored on the blockchain, and the initial reference count. The initial reference count is usually a pre-set value. In practice, the initial reference count is typically 0.

[0129] It should be noted that when the current active file is full and stored on the chain, the aforementioned execution entity can generate a new active file for writing data and create a corresponding file handle for the new active file.

[0130] Continue to refer to Figure 3 This is a flowchart illustrating a blockchain data processing method provided in an embodiment of this application. Figure 3The blockchain data processing method shown may include steps 301 to 313. It should be noted that the executing entity for steps 301 to 313 is the target blockchain, specifically each blockchain node on the target blockchain. In practical applications, each blockchain node can be implemented as either a terminal or a server.

[0131] Step 301: Receive file read request.

[0132] Here, the file read request mentioned above is conceptually the same as the operation request information described earlier. Here, the file read request instructs the execution of a file read operation on the target file. Here, the target operation is a file read operation, and the target file is the file to be read.

[0133] Step 302: Verify whether the file read request is valid.

[0134] If the file read request is valid, step 303 can be executed; otherwise, step 313 should be executed.

[0135] Step 303: Determine whether a handle is found in an active file.

[0136] Here, the filename included in the file read request can be compared with the filename of the active file to determine if the active file is the target file. If the active file is the target file, its file handle can be used as the target file's file handle. For ease of description, the target file's file handle can be referred to as the target handle. When the active file is also the target file, finding the handle within the active file is equivalent to finding the target handle within the active file.

[0137] If the target handle is found in the active file, step 306 can be executed. Otherwise, if the target handle does not exist in the active file, step 304 can be executed.

[0138] It should be noted that the handle to be searched mentioned in steps 301-313 usually refers to the target handle, that is, the file handle corresponding to the target file.

[0139] Step 304: Determine whether a handle is found in the active handle pool.

[0140] The aforementioned active handle pool refers to the handle pool that is currently in an active state.

[0141] Here, if the target handle does not exist in the active file, the filename included in the file read request can be used to search for a file handle corresponding to that filename in the active handle pool. If found, it can be confirmed that a handle has been found in the active handle pool, that is, the target handle has been found in the active handle pool.

[0142] If the target handle is found in the active handle pool, step 307 can be executed. Otherwise, if the target handle does not exist in the active handle pool, step 305 can be executed.

[0143] Step 305: Create a handle corresponding to the read request in the active handle pool.

[0144] Here, if the target handle does not exist in the active handle pool, the search continues to look for it in the idle handle pool. If it exists, the target handle can be created in the active handle pool based on the target handle in the idle handle pool. If it does not exist, the target file and its storage address can be found by traversing the block data stored on the blockchain. A target handle can then be created for the found target file and stored in the active handle pool. The aforementioned idle handle pool refers to the handle pool that is currently in an idle state.

[0145] Step 306: Perform file reading operations based on the obtained handle.

[0146] Here, the target file can be located based on the file address of the target file pointed to by the target handle, and a file read operation can be performed on the target file.

[0147] Step 307: Increment the handle reference count in the handle pool by 1.

[0148] Here, the reference count mentioned above is the same as the concept of dynamic reference count described earlier. If the target handle is found in the active handle pool, the dynamic reference count of the corresponding file handle in the active handle pool can be incremented by 1.

[0149] Step 308: File reading operation complete.

[0150] Step 309: When the handle corresponding to the read request comes from the handle pool, proceed with the handle pool operation.

[0151] Here, if the target handle comes from the active handle pool or the idle handle pool, the above-mentioned execution entity can continue to execute steps 310-312.

[0152] Alternatively, if the target handle comes from an active file, step 313 can be performed.

[0153] Step 310: Determine whether a handle can be found in the idle handle pool.

[0154] Here, if the target handle exists in the idle handle pool, step 312 can be executed on the idle handle pool.

[0155] If the target handle is not available in the idle handle pool, then step 311 can be executed.

[0156] Step 311: Find the handle in the active handle pool.

[0157] If the target handle corresponding to the read request comes from the handle pool and the target handle does not exist in the idle handle pool, it means that the target handle exists in the active handle pool. In this case, the target handle can be found in the active handle pool. If the target handle is found in the active handle pool, step 312 can be executed on the active handle pool.

[0158] Step 312: Decrement the handle reference count in the handle pool by 1.

[0159] Here, if the target handle corresponding to the read request comes from the handle pool, and the target handle comes from the idle handle pool, then the dynamic reference count of the corresponding file handle in the idle handle pool is decremented by 1.

[0160] If the target handle corresponding to the read request comes from the handle pool, and the target handle comes from the active handle pool, then the dynamic reference count of the corresponding file handle in the active handle pool is decremented by 1.

[0161] Step 313: End the execution of the above blockchain data processing method.

[0162] The method provided in this embodiment, since file handles can usually point to the file address of the corresponding file, can quickly find the target file by searching for the target handle corresponding to the target file from the active file or the handle pool group, thereby improving the efficiency of blockchain data processing.

[0163] Corresponding to the blockchain data processing method in Embodiment 1 above, Figure 4 A structural block diagram of a blockchain data processing device 400 provided in an embodiment of this application is shown. For ease of explanation, only the parts related to the embodiment of this application are shown.

[0164] Reference Figure 4 The device includes:

[0165] Information receiving unit 401 is used to receive operation request information, which is used to instruct the target file on the target blockchain to perform a target operation;

[0166] The handle lookup unit 402 is used to look up the target handle corresponding to the target file from the target location according to the operation request information. The target handle includes the target address corresponding to the target file, and the target location includes any one of the following: active file, handle pool group;

[0167] The operation execution unit 403 is used to locate the target file based on the target handle and to perform target operations on the target file.

[0168] In some embodiments, the apparatus further includes an information creation unit. The information creation unit is configured to: create a handle pool group according to a predetermined handle pool size. The handle pool group includes two handle pools with different operating states, including an active state and an idle state. Each handle pool contains a file handle with a file identifier, a file address, and a dynamic reference count, wherein the dynamic reference count records the number of times the corresponding file handle is currently referenced.

[0169] In some embodiments, the handle lookup unit 402 includes a first lookup module and a second lookup module. The first lookup module is configured to determine the file handle of the active file as the target handle if the operation request information matches the file description information of the active file. The second lookup module is configured to search for a file handle matching the operation request information from the handle pool group if the operation request information does not match the file description information of the active file, and to determine the found file handle as the target handle.

[0170] In some embodiments, the second search module searches for a file handle that matches the operation request information from the handle pool group, and determines the found file handle as the target handle, including: searching for the target handle from the handle pool that is in an active state, and / or if the target handle is not found in the handle pool that is in an active state, searching for the target handle from the handle pool that is in an idle state.

[0171] In some embodiments, the apparatus further includes a first update unit and a second update unit. The first update unit is configured to, if a target handle is found in the active handle pool, increase the dynamic reference count of the corresponding file handle in the active handle pool. The second update unit is configured to, if the target handle does not exist in the active handle pool, create a target handle based on operation request information, and store the created target handle in the active handle pool.

[0172] In some embodiments, the apparatus further includes a file search unit and a handle creation unit. The file search unit is configured to, if no target handle corresponding to the target file exists at the target location, traverse the block data stored on the target blockchain until a target file matching the operation request information is found. The handle creation unit is configured to determine the file address of the found target file as the target address, and create a target handle corresponding to the target file based on the target file's file identifier, target address, and preset reference count, and store the target handle in an active handle pool.

[0173] In some embodiments, the apparatus further includes a third update unit and a fourth update unit. The third update unit is configured to, after performing a target operation on a target file, reduce the dynamic reference count of the corresponding file handle in the idle handle pool if a target handle is detected to still exist in the idle handle pool; and reduce the dynamic reference count of the corresponding file handle in the active handle pool if no target handle is detected in the idle handle pool. The fourth update unit is configured to delete file handles in the idle handle pool whose corresponding dynamic reference count is zero.

[0174] In some embodiments, the apparatus further includes a state switching unit and a file switching unit. The state switching unit is configured to switch the working states of two handle pools with different working states when a preset trigger condition is triggered if the handle pool group includes two handle pools with different working states. The preset trigger condition includes at least one of the following: reaching a preset switching period, the number of file handles in the active handle pool exceeds a preset threshold. The file switching unit is configured to store the active file on the chain and write the file handle of the active file into the active handle pool when the active file is full, creating a new file with a corresponding file handle, and switching the new file to the active file.

[0175] The device provided in this embodiment can quickly and accurately locate the target file that needs to be operated on by searching for the target handle corresponding to the target file from the active file or handle pool group. This helps to improve the processing efficiency of blockchain data.

[0176] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiment 1 of this application. For details on their specific functions and technical effects, please refer to the method embodiment section, which will not be repeated here.

[0177] Figure 5 This is a schematic diagram of the structure of a server 500 provided in one embodiment of this application. Figure 5 As shown, the server 500 in this embodiment includes: at least one processor 501 ( Figure 5 The diagram shows only one processor, memory 502, and a computer program 503 stored in memory 502 and executable on at least one processor 501, such as a blockchain data processing program. When processor 501 executes computer program 503, it implements the steps in any of the above-described method embodiments. When processor 501 executes computer program 503, it implements the steps in the embodiments of the above-described blockchain data processing methods. When processor 501 executes computer program 503, it implements the functions of each module / unit in the above-described device embodiments, such as... Figure 4 The functions of the information receiving unit 401 to the operation execution unit 403 are shown.

[0178] For example, computer program 503 can be divided into one or more modules / units, one or more of which are stored in memory 502 and executed by processor 501 to complete this application. One or more modules / units can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of computer program 503 in server 500. For example, computer program 503 can be divided into an information receiving unit, a handle lookup unit, and an operation execution unit. The specific functions of each unit have been described in the above embodiments and will not be repeated here.

[0179] Server 500 can be a computing device such as a server, desktop computer, tablet computer, cloud server, and mobile terminal. Server 500 may include, but is not limited to, a processor 501 and a memory 502. Those skilled in the art will understand that... Figure 5 This is merely an example of server 500 and does not constitute a limitation on server 500. It may include more or fewer components than shown in the figure, or combine certain components, or different components. For example, a server may also include input / output devices, network access devices, buses, etc.

[0180] The processor 501 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0181] The memory 502 can be an internal storage unit of the server 500, such as the server 500's hard drive or memory. The memory 502 can also be an external storage device of the server 500, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card equipped on the server 500. Furthermore, the memory 502 can include both internal and external storage units of the server 500. The memory 502 is used to store computer programs and other programs and data required by the server. The memory 502 can also be used to temporarily store data that has been output or will be output.

[0182] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0183] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0184] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0185] In the embodiments provided in this application, it should be understood that the disclosed apparatus / server and method can be implemented in other ways. For example, the apparatus / server embodiments described above are merely illustrative. For instance, the division of modules or 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; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0186] 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.

[0187] Furthermore, the functional units in the various embodiments of this application 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.

[0188] If an integrated module 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, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electrical carrier signals and telecommunication signals.

[0189] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A blockchain data processing method, characterized in that, The method includes: Receive operation request information, the operation request information being used to instruct the execution of a target operation on a target file on a target blockchain; Based on the operation request information, a target handle corresponding to the target file is located from the target location. The target handle includes the target address corresponding to the target file, and the target location includes active files and a handle pool group. The handle pool group includes two handle pools with different working states, namely, an active state and an idle state. The file handles in each handle pool include a file identifier, a file address, and a dynamic reference count. The dynamic reference count is used to record the number of times the corresponding file handle is currently referenced. Based on the target handle, locate the target file and perform the target operation on the target file; The method further includes: If the target handle is found in the active handle pool, the dynamic reference count of the corresponding file handle in the active handle pool is increased. If the target handle does not exist in the active handle pool, the target handle is created according to the operation request information, and the created target handle is stored in the active handle pool. 2.The blockchain data processing method of claim 1, wherein, The method further includes: creating the handle pool group according to a predetermined handle pool size. 3.The blockchain data processing method of claim 1, wherein, The step of finding the target handle corresponding to the target file from the target location based on the operation request information includes: If the operation request information matches the file description information of the active file, then the file handle of the active file is determined as the target handle; If the operation request information does not match the file description information of the active file, then the file handle that matches the operation request information is searched from the handle pool group, and the found file handle is determined as the target handle. 4.The method of claim 3, wherein, The step of searching for a file handle that matches the operation request information from the handle pool group, and determining the found file handle as the target handle, includes: The target handle is located in the pool of active handles. 5.The method of claim 1, wherein, The step of creating the target handle according to the operation request information and storing the created target handle in an active handle pool includes: Traverse the block data stored on the target blockchain until the target file that matches the operation request information is found; The file address of the target file obtained from the query is determined as the target address, and a target handle corresponding to the target file is created based on the file identifier of the target file, the target address and the preset reference count, and the target handle is stored in the handle pool that is in an active state. 6.The method of claim 1, wherein, The method further includes: After performing the target operation on the target file, if it is detected that the target handle still exists in the handle pool in the idle state, the dynamic reference count of the corresponding file handle in the handle pool in the idle state is reduced; if it is detected that the target handle does not exist in the handle pool in the idle state, the dynamic reference count of the corresponding file handle in the handle pool in the active state is reduced. Delete the file handles in the handle pool that are in an idle state and have a corresponding dynamic reference count of zero. 7.The blockchain data processing method of any one of claims 1-6, wherein, The method further includes: When a preset trigger condition is triggered, the working states of the two handle pools are switched. The preset trigger condition includes at least one of the following: the preset switching period has been reached and the number of file handles in the active handle pool exceeds a preset number threshold. When the active file is full, the active file is stored on the chain and the file handle of the active file is written to the handle pool that is in an active state. A new file with a corresponding file handle is created and the new file is switched to the active file.

8. A server 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 method as described in any one of claims 1 to 7.

9. A computer readable storage medium, the storage medium having stored thereon a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 7.

Images