Blockchain transaction pool data processing method and server

Abstract

The application is suitable for the field of computer technology, and provides a blockchain transaction pool data processing method and a server, wherein the method comprises the following steps: when target transaction data is received by a target node, determining the source of the target transaction data, wherein the source comprises a user terminal in communication connection with the target node and other nodes on a target blockchain corresponding to the target node; when the source of the target transaction data is the user terminal, storing the target transaction data in a transaction pool and broadcasting the target transaction data to the other nodes; and when a preset packaging and chaining condition is triggered, packaging and chaining storage is performed on at least part of the transaction data in the transaction pool. According to the application, only transaction data from the user terminal is broadcasted, and transaction data from other nodes is not broadcasted, so that the amount of broadcasted data can be greatly reduced, thereby effectively preventing broadcast storm.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of computers, and particularly relates to a blockchain transaction pool data processing method and a server. BACKGROUND

[0002] A blockchain is a distributed shared ledger and database, and has the characteristics of decentralization, non-tamperability, full traceability, collective maintenance, openness and transparency. In practice, a blockchain usually has multiple nodes, and each node can usually cache transaction data in a transaction pool after receiving the transaction data, and then package the transaction data in the transaction pool to generate a block.

[0003] In related technologies, in order to ensure that each node of the same blockchain has the same and complete ledger, a node usually broadcasts the received transaction data to other nodes on the same blockchain after receiving the transaction data. However, since the amount of transaction data received by each node is usually large, if the node broadcasts the transaction data as soon as it is received, a broadcast storm is likely to occur, causing the entire blockchain network to malfunction. SUMMARY

[0004] The embodiments of the present application provide a blockchain transaction pool data processing method and a server, aiming at solving the problem in related technologies that since the amount of transaction data received by each node is usually large, if the node broadcasts the transaction data as soon as it is received, a broadcast storm is likely to occur, causing the entire blockchain network to malfunction.

[0005] In a first aspect, the embodiments of the present application provide a blockchain transaction pool data processing method, which comprises:

[0006] When the target node receives target transaction data, determining the source of the target transaction data, wherein the source includes: a user terminal in communication connection with the target node, and other nodes on a target blockchain corresponding to the target node;

[0007] When the source of the target transaction data is the user terminal, storing the target transaction data in the transaction pool and broadcasting the target transaction data to the other nodes;

[0008] When a preset packaging and chaining condition is triggered, at least part of the transaction data in the transaction pool is packaged and chained and stored.

[0009] In some embodiments, the method further comprises: when the source of the target transaction data is the other nodes, storing the target transaction data in the transaction pool.

[0010] In some embodiments, storing the target transaction data in the transaction pool comprises: in the case that the target transaction data does not exist in the transaction pool, storing the target transaction data in the transaction pool.

[0011] In some embodiments, the transaction pool comprises a local list for caching transaction data from the user terminal and a global list for caching transaction data to be stored in the transaction pool, and storing the target transaction data in the transaction pool comprises:

[0012] When the source of the target transaction data is the user terminal, storing the target transaction data in the local list and the global list in the transaction pool, and when the source of the target transaction data is another node, storing the target transaction data in the global list in the transaction pool.

[0013] In some embodiments, after storing the target transaction data in the transaction pool, the method further comprises:

[0014] generating a time parameter of the target transaction data based on the source of the target transaction data;

[0015] The time parameter comprises at least one of: a first time parameter indicating the time when the transaction data is stored in the transaction pool, and a second time parameter indicating the time when the transaction data is initiated for broadcast.

[0016] In some embodiments, when each transaction data in the transaction pool corresponds to a first time parameter and / or a second time parameter, the method further comprises:

[0017] When there is to-be-retransmitted data in the local list, broadcasting the to-be-retransmitted data to other nodes, and updating the second time parameter of the to-be-retransmitted data, wherein the to-be-retransmitted data is transaction data whose interval between the time indicated by the second time parameter and the current time is greater than a preset retransmission duration;

[0018] When there is to-be-deleted data in the global list and / or the local list, deleting the to-be-deleted data, wherein the to-be-deleted data is transaction data whose interval between the time indicated by the first time parameter and the current time is greater than a preset deletion duration.

[0019] In some embodiments, the transaction pool further comprises a ready queue for caching transaction data suitable for on-chain storage and an unready queue for caching transaction data unsuitable for on-chain storage; and after storing the target transaction data in the transaction pool, the method further comprises:

[0020] When the target transaction data meets a preset entry condition, storing the target transaction data in the global list in the ready queue;

[0021] When it is detected that there is same-account data belonging to the same account as the target transaction data in the unready queue, and the same-account data meets the preset entry condition, storing the same-account data in the ready queue;

[0022] The same-account data is transaction data belonging to the same account as the target transaction data, and the preset entry condition is that the data identifiers of each transaction data corresponding to the same account are sequentially increased.

[0023] In some embodiments, in the case that the transaction pool further comprises a ready queue, in the case that the preset packaging and chaining condition is triggered, the at least part of the transaction data in the transaction pool is packaged and stored on a chain, comprising:

[0024] In the case that the preset packaging and chaining condition is triggered, a preset number of transaction data are extracted from the ready queue of the transaction pool, and the extracted transaction data are packaged into a block;

[0025] A chaining request is initiated to other nodes on the target blockchain, and in the case that the chaining request is agreed by each of the other nodes, the block is stored on a chain to each node of the target blockchain;

[0026] The preset packaging and chaining condition comprises at least one of the following: the target node is a master node of the target blockchain, and there are a preset number of transaction data in the ready queue.

[0027] In some embodiments, after the preset number of transaction data are extracted from the ready queue of the transaction pool, the method further comprises: storing a transaction set composed of the preset number of transaction data in the packed queue in the form of a key-value pair, wherein the key of the key-value pair is the hash value of the transaction set, and the value of the key-value pair is the transaction set.

[0028] Before the block is stored on a chain to each node of the target blockchain, the method further comprises: receiving a block request sent by a lag node, wherein the lag node is a node corresponding to a block height smaller than that of the master node, the block request comprises a block identifier and a hash value of a transaction set corresponding to the block indicated by the block identifier; and sending the transaction set corresponding to each hash value to the lag node.

[0029] In some embodiments, after the at least part of the transaction data in the transaction pool is packaged and stored on a chain, the method further comprises:

[0030] The packaged and chained transaction data in the transaction pool of the target node are deleted, and the corresponding transaction data in the transaction pool of the other nodes on the target blockchain are deleted.

[0031] In a second aspect, the embodiments of the present application provide a blockchain transaction pool data processing device, which comprises:

[0032] A data receiving unit is configured to determine the source of the target transaction data when the target transaction data is received by the target node, wherein the source comprises: a user terminal in communication connection with the target node, and other nodes on the target blockchain corresponding to the target node.

[0033] a first storing unit, configured to store the target transaction data into the transaction pool and broadcast the target transaction data to other nodes when the source of the target transaction data is a user terminal;

[0034] a data packaging unit, configured to package and store at least part of the transaction data in the transaction pool in a chain when a preset packaging and chain storage condition is triggered.

[0035] In some embodiments, the apparatus further comprises a second storing unit, configured to store the target transaction data into the transaction pool when the source of the target transaction data is other nodes.

[0036] In some embodiments, the storing of the target transaction data into the transaction pool in the first storing unit and / or the second storing unit comprises: storing the target transaction data into the transaction pool when the target transaction data does not exist in the transaction pool.

[0037] In some embodiments, the transaction pool comprises a local list for caching transaction data from the user terminal and a global list for caching each transaction data to be stored into the transaction pool, and the storing of the target transaction data into the transaction pool in the first storing unit and / or the second storing unit comprises:

[0038] storing the target transaction data into the local list and the global list in the transaction pool when the source of the target transaction data is the user terminal, and storing the target transaction data into the global list in the transaction pool when the source of the target transaction data is other nodes.

[0039] In some embodiments, the apparatus further comprises a parameter generating unit, configured to generate a time parameter of the target transaction data based on the source of the target transaction data.

[0040] The time parameter comprises at least one of: a first time parameter for indicating a time when the transaction data is stored into the transaction pool, and a second time parameter for indicating a time when the transaction data is initiated to be broadcasted.

[0041] In some embodiments, when each transaction data in the transaction pool corresponds to the first time parameter and / or the second time parameter, the apparatus further comprises a timeout retransmission unit and an expired deletion unit.

[0042] The timeout retransmission unit is configured to broadcast the to-be-retransmitted data to other nodes and update the second time parameter of the to-be-retransmitted data when the to-be-retransmitted data exists in the local list, wherein the to-be-retransmitted data is transaction data whose interval between the time indicated by the second time parameter and the current time is greater than a preset retransmission time length.

[0043] The overdue deletion unit is configured to delete the to-be-deleted data when the to-be-deleted data exists in the global list and / or the local list, wherein the to-be-deleted data is transaction data whose interval between a time indicated by the first time parameter and a current time is greater than the preset deletion time length.

[0044] In some embodiments, the transaction pool further includes a ready queue for caching transaction data suitable for on-chain storage and a non-ready queue for caching transaction data unsuitable for on-chain storage, and the apparatus further includes a third storage unit and a fourth storage unit.

[0045] The third storage unit is configured to store the target transaction data in the global list into the ready queue when the target transaction data meets a preset entry condition.

[0046] The fourth storage unit is configured to store the same-account data into the ready queue when the same-account data meets the preset entry condition and the same-account data exists in the non-ready queue and belongs to the same account as the target transaction data.

[0047] The same-account data is transaction data belonging to the same account as the target transaction data, and the preset entry condition is that the data identifiers of each transaction data corresponding to the same account are in ascending order.

[0048] In some embodiments, the data packaging unit includes a data packaging module and an on-chain storage module.

[0049] The data packaging module is configured to extract a preset number of transaction data from the ready queue of the transaction pool when a preset packaging and on-chain condition is triggered, and package the extracted transaction data into a block.

[0050] The on-chain storage module is configured to initiate an on-chain request to other nodes on the target blockchain, and store the block on-chain to each node of the target blockchain when the on-chain request is consensus passed by each other node.

[0051] The preset packaging and on-chain condition includes at least one of the following: the target node is a master node of the target blockchain, and a preset number of transaction data exists in the ready queue.

[0052] In some embodiments, after extracting a preset number of transaction data from the ready queue of the transaction pool, the data packaging module further includes: storing a transaction set composed of the preset number of transaction data into the packaged queue in the form of a key-value pair, wherein the key of the key-value pair is the hash value of the transaction set, and the value of the key-value pair is the transaction set.

[0053] In the upper chain storage module, before storing the block in the upper chain to each node of the target block chain, the method further includes: receiving a block request sent by a lag node, wherein the lag node is a node corresponding to a block height smaller than a block height of the master node, the block request includes a block identifier and a hash value of a transaction set corresponding to the block indicated by the block identifier; and sending each hash value to the lag node respectively corresponding transaction set.

[0054] In some embodiments, the apparatus further includes a data deletion unit configured to delete the packaged transaction data in the transaction pool of the target node, and delete corresponding transaction data in the transaction pool of other nodes on the target block chain.

[0055] In a third aspect, an embodiment of the present application provides a server, including a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the steps of any of the block chain transaction pool data processing methods when executing the computer program.

[0056] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, and the computer readable storage medium stores a computer program, and the computer program implements the steps of any of the block chain transaction pool data processing methods when executed by a processor.

[0057] In a fifth aspect, an embodiment of the present application provides a computer program product, when the computer program product is executed on a server, the server executes any of the block chain transaction pool data processing methods.

[0058] Compared with the related art, the beneficial effects of the embodiments of the present application are that each node receives transaction data, only broadcasts transaction data from the user end, and does not broadcast transaction data from other nodes, which can greatly reduce the amount of broadcast data, and can effectively prevent broadcast storm.

[0059] It can be understood that the beneficial effects of the above-mentioned second aspect to fifth aspect can be referred to the related description in the first aspect, and will not be repeated here. BRIEF DESCRIPTION OF DRAWINGS

[0060] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments or related technical description. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0061] Figure 1 is a flowchart of a block chain transaction pool data processing method provided by an embodiment of the present application;

[0062] Figure 2 is a flowchart of a process for managing transaction data in a transaction pool according to an embodiment of the present application;

[0063] Figure 3 is a flowchart of a process for managing transaction data in a transaction pool according to another embodiment of the present application;

[0064] Figure 4 is a structural diagram of a blockchain transaction pool data processing apparatus according to an embodiment of the present application;

[0065] Figure 5 is a structural diagram of a server according to an embodiment of the present application. DETAILED DESCRIPTION

[0066] In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular sequences of steps, techniques, etc., in order to provide a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application can be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known methods, devices, and circuits are omitted so as not to obscure the description of the present application with unnecessary detail.

[0067] It is to be understood that the terminology “includes,” “has,” “holds,” “contains” and / or “comprising,” when used in this specification, including the accompanying claims, includes the presence of stated features, integers, steps, operations, elements, and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0068] It is also to be understood that the terminology “and / or” when used in this specification, including the accompanying claims, refers to at least one of the items, or any combination of the items, listed after the term in the list of potential combinations.

[0069] As used in this specification and the appended claims, the term “if’ can be interpreted as meaning “when” or “once” or “in response to a determination” or “in response to detecting” depending on the context. Similarly, the phrase “if it is determined” or “if [a described condition or event] is detected” can be interpreted as meaning “once it is determined” or “in response to a determination” or “once [the described condition or event] is detected” or “in response to detecting [the described condition or event]” depending on the context.

[0070] In addition, in the description of the specification and the appended claims, the terms “first,” “second,” “third,” etc. are used only to distinguish descriptions, and cannot be understood as indicating or implying relative importance.

[0071] Reference throughout this application to "one embodiment" or "some embodiments" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the application. Thus, the appearances of the phrases "in one embodiment" or "in some embodiments" in various places throughout this specification are not necessarily all referring to the same embodiment, but can refer to one or more but not all embodiments. The terms "including," "comprising," "featuring," and variations thereof are meant to encompass the items listed thereafter, but do not exclude other items from being present. Unless otherwise indicated, the terms "including" and / or "comprising" shall not be construed so as to exclude additional nont recited elements or limit the scope of the application.

[0072] To illustrate the technical solutions of the present application, the following examples are used to illustrate the technical solutions of the present application.

[0073] Continuing to refer to Figure 1 , the embodiment of the present application provides a blockchain transaction pool data processing method, comprising:

[0074] Step 101, when the target transaction data is received by the target node, determining the source of the target transaction data.

[0075] Among them, the source includes: a user terminal in communication connection with the target node, other nodes on the target blockchain corresponding to the target node. The above-mentioned user terminal can be realized as a terminal or as a server. The above-mentioned user terminal can have one or more. In practical applications, the above-mentioned user terminal usually has multiple.

[0076] Among them, the above-mentioned target node can be any node on the target blockchain. The above-mentioned target blockchain can be various blockchains. In practice, the above-mentioned target blockchain is usually a relay chain.

[0077] The above-mentioned target transaction data is usually the transaction data received by the target node at the current time.

[0078] In this embodiment, the execution subject of the above-mentioned blockchain transaction pool data processing method is usually the above-mentioned target blockchain, and can be each node on the above-mentioned target blockchain, such as the above-mentioned target node. In practical applications, each node can be realized as a terminal or as a server.

[0079] In practice, the target node can receive the target transaction data through the network. Upon receiving the target transaction data, the target node can determine the source of the target transaction data by judging the data interface through which the target transaction data is received. In actual applications, if the data interface through which the target transaction data is received is an API interface (Application Programming Interface), the target node can determine that the source of the target transaction data is the user end. If the data interface through which the target transaction data is received is a node synchronization interface, the target node can determine that the source of the target transaction data is another node on the target blockchain. Each node on the target blockchain can have an API interface and a node synchronization interface, the API interface being used for data interaction with the user end, and the node synchronization interface being used for data interaction with other nodes on the same blockchain.

[0080] It should be noted that, in the case where the target transaction data carries source information indicating the source of the data, the target node can directly use the source information carried by the target transaction data to determine the source of the target transaction data.

[0081] In practice, after determining the source of the target transaction data, the target node can generate a source label for the target transaction data. As an example, if the source of the target transaction data is the user end, a source label corresponding to a value of "true" can be generated for the target transaction data. If the source of the target transaction data is another node, a source label corresponding to a value of "false" can be generated for the target transaction data. In this way, the transaction data in the transaction pool with different sources can be accurately processed subsequently, which helps to further improve the processing efficiency of the transaction pool data.

[0082] Step 102: in the case where the source of the target transaction data is the user end, storing the target transaction data in the transaction pool and broadcasting the target transaction data to other nodes.

[0083] Here, in the case where the target transaction data comes from the user end, the target node can store the target transaction data in the transaction pool of the target node.

[0084] In addition, after storing the target transaction data from the user end in the transaction pool, the target node can timely broadcast the target transaction data to other nodes on the same blockchain. In this way, other nodes on the same blockchain can perform corresponding synchronization data processing after receiving the broadcasted target transaction data.

[0085] In the optional implementation of each embodiment, the storing of the target transaction data in the transaction pool comprises: in the case where the target transaction data does not exist in the transaction pool, storing the target transaction data in the transaction pool.

[0086] Here, the target node can analyze whether the target transaction data already exists in the transaction pool of the target node before storing the target transaction data into the transaction pool. If not, the target node can store the target transaction data into the transaction pool. If yes, the target node can discard the target transaction data.

[0087] It should be noted that storing the same transaction data only once can avoid resource waste and potential double-spending problem caused by repeated storage, thereby ensuring efficient and orderly processing of the data in the transaction pool, and thus helping to improve the processing efficiency of the data in the transaction pool.

[0088] Step 103: In a case where a preset packaging and on-chain storage condition is triggered, at least part of the transaction data in the transaction pool is packaged and stored on a chain.

[0089] The preset packaging and on-chain storage condition is usually a condition preset for triggering packaging and on-chain storage of the transaction data in the transaction pool.

[0090] In practice, the preset packaging and on-chain storage condition can include, but is not limited to, at least one of the following: the target node is a master node of the target blockchain, the amount of the transaction data in the transaction pool that is currently suitable for on-chain storage is greater than a preset number, etc. The preset number is usually a preset value, for example, 10.

[0091] Here, in a case where the preset packaging and on-chain storage condition is met, the target node can package part or all of the transaction data in the transaction pool into a block, and store the packaged block on a chain.

[0092] The method provided in this embodiment can greatly reduce the amount of data to be broadcast, and can effectively prevent broadcast storm, because each node broadcasts only the transaction data from the user end when receiving the transaction data, and does not broadcast the transaction data from other nodes.

[0093] In some optional implementations of this embodiment, the blockchain transaction pool data processing method can further include the following step: in a case where the target transaction data is from other nodes, storing the target transaction data into the transaction pool.

[0094] Here, when the target transaction data is from other nodes, the target node can store the target transaction data from other nodes into the transaction pool. After storing the target transaction data from other nodes into the transaction pool, the target node does not need to broadcast the target transaction data, and can avoid broadcast storm. In practice, the target node usually first analyzes whether the target transaction data already exists in the transaction pool. If not, the target node can store the target transaction data into the transaction pool, and if so, the target node can discard the target transaction data. In this way, resource waste caused by repeated storage and potential double-spending problems can be avoided.

[0095] In some optional implementations of the embodiment, the transaction pool of each node on the blockchain can simultaneously include a local list for caching transaction data from the user end and a global list for caching each transaction data that needs to be stored in the transaction pool.

[0096] At this time, the target node can store the target transaction data into the transaction pool in the following way: when the source of the target transaction data is the user end, the target transaction data is stored into the local list and the global list in the transaction pool, and when the source of the target transaction data is other nodes, the target transaction data is stored into the global list in the transaction pool.

[0097] Here, the target node can store the target transaction data into the transaction pool according to the source of the target transaction data. Specifically, if the source of the target transaction data is the user end, the target transaction data is stored into the local list and the global list in the transaction pool, and if the source of the target transaction data is other nodes, the target transaction data is stored into the global list in the transaction pool.

[0098] It should be noted that when the source of a certain transaction data is the user end, if the target node receives the transaction data, the target node is the node that receives the transaction data earliest on the entire target blockchain, and in order to ensure that the transaction data is timely stored on the chain, the target node needs to timely notify other nodes of the transaction data.

[0099] Here, the target node additionally stores the target transaction data corresponding to the source of the user end into the local list, which can facilitate timely and effective management of transaction data from the user end. The local list is mainly responsible for timely notifying other nodes of transaction data from the user end, and the global list is mainly responsible for timely storing each source of transaction data in the transaction pool on the chain. The local list and the global list are parallel, which helps to further improve the processing efficiency of the transaction pool data.

[0100] In some optional implementations of the present embodiment, after the target transaction data is stored in the transaction pool, the blockchain transaction pool data processing method can further include the following step: generating a time parameter of the target transaction data based on the source of the target transaction data.

[0101] The time parameter includes at least one of the following: a first time parameter indicating the time when the transaction data is stored in the transaction pool, and a second time parameter indicating the time when the transaction data is initiated for broadcasting.

[0102] In practice, when the source of the target transaction data is a user terminal, the target node can generate the first time parameter and the second time parameter for the target transaction data. When the source of the target transaction data is another node, the target node can only generate the first time parameter for the target transaction data.

[0103] Generating the time parameter for the target transaction data stored in the transaction pool can facilitate timely processing of the target transaction data, and help improve the processing efficiency of the transaction pool data. In addition, since the target node does not need to broadcast the target transaction data from other nodes, only the first time parameter for the target transaction data from other nodes can save storage space.

[0104] In some optional implementations of the present embodiment, when each transaction data in the transaction pool corresponds to a first time parameter and / or a second time parameter, the blockchain transaction pool data processing method can further include the following steps 201-202.

[0105] Figure 2 A flowchart for managing transaction data in a transaction pool is provided for the embodiments of the present application.

[0106] Step 201: When there is pending retransmission data in the local list, the pending retransmission data is broadcast to other nodes, and the second time parameter of the pending retransmission data is updated.

[0107] The pending retransmission data is transaction data whose interval between the time indicated by the second time parameter and the current time is greater than a preset retransmission duration. The preset retransmission duration is usually a pre-set time value. For example, it can be 3 minutes.

[0108] Here, the target node can check whether there is pending retransmission data in the local list in time, and if so, broadcast the pending retransmission data to other nodes in time. When the pending retransmission data is broadcast to other nodes, the target node can update the second time parameter of the pending retransmission data based on the time of the present broadcast. For example, if the time of the present broadcast is June 24, 2022, 14:20:30, the updated second time parameter of the pending retransmission data can be 20220624142030.

[0109] When the transaction data in the local list is broadcast, the second time parameter of the broadcast transaction data is updated in time, so that the next broadcast of the transaction data can be implemented in time and effectively.

[0110] In actual application, a certain transaction data usually only needs a very short time, such as 3 seconds, from entering the transaction pool to being chained, and if there is a certain transaction data with a longer retention time in the local list in the transaction pool, it is highly possible that the transaction data has not been broadcast to the main node responsible for initiating the chain in time. The target node re-broadcasts the data to be retransmitted to other nodes, which can avoid the situation that the transaction data cannot be packaged and chained in time due to data loss in a certain broadcast process, and helps to ensure that the transaction data is stored in time.

[0111] Step 202, when there is to-be-deleted data in the global list and / or the local list, deleting the to-be-deleted data.

[0112] Among them, the to-be-deleted data is the transaction data whose interval between the time indicated by the first time parameter and the current time is greater than the preset deletion duration. The above-mentioned preset deletion duration is usually a pre-set time value. For example, it can be 30 minutes. In practice, the preset retransmission duration is usually less than the preset deletion duration.

[0113] Here, the target node can timely check whether there is to-be-deleted data in the global list or the local list, and if there is, the to-be-deleted data is deleted in time, so as to delete the transaction data that may have problems or is invalid in time, and avoid that the transaction data that may have problems or is invalid occupies the storage resources of the transaction pool for a long time.

[0114] In this embodiment, the local list is mainly responsible for timely notifying the transaction data from the user end to other nodes, and the global list is mainly responsible for timely chaining the transaction data from various sources in the transaction pool, timely re-broadcasting the transaction data that has been stored in the local list for a long time, and timely deleting the transaction data that has been stored in the local list and the global list for too long. While ensuring that the transaction data is stored in time, the transaction data that may have problems or is invalid can be deleted in time, which helps to further improve the processing efficiency of the transaction pool data.

[0115] In some optional implementation manners of this embodiment, the transaction pool of each node of the block chain can further include a ready queue for buffering the transaction data suitable for being chained and stored, and an unready queue for buffering the transaction data unsuitable for being chained and stored. The above-mentioned transaction data suitable for being chained and stored usually refers to the transaction data meeting the preset entry condition.

[0116] At this time, after the target transaction data is stored into the transaction pool, the blockchain transaction pool data processing method can further include the following steps 301-302.

[0117] Figure 3 A flowchart for managing transaction data in a transaction pool is provided for the embodiments of the present application.

[0118] Step 301: When the target transaction data meets the preset entry condition, the target transaction data in the global list is stored into the ready queue.

[0119] The preset entry condition is usually a condition preset for triggering the storage of transaction data in the global list into the ready queue.

[0120] In practice, the preset entry condition is usually that the data identifiers of each transaction data corresponding to the same account are sequentially increased.

[0121] The data identifier is usually the transaction nonce of the transaction data. In actual application, the nonce of the transaction data can indicate the corresponding account and the order of the transaction data. For example, the nonce of a certain transaction data can be A1, indicating the first transaction data of the A account.

[0122] For example, if the nonce of the target transaction data is A9, indicating the ninth transaction data of the A account, and the nonce of the transaction data stored into the ready queue in the last time is A7, it indicates that the data identifiers of the transaction data of the A account are not sequentially increased, and the eighth transaction data is missing. At this time, the target node does not store the target transaction data into the ready queue.

[0123] Here, the target node can analyze whether the target transaction data meets the preset entry condition, and if so, the target transaction data can be stored into the ready queue.

[0124] In practice, when the target transaction data does not meet the preset entry condition, the target node usually first stores the target transaction data into the unready queue.

[0125] For example, if the nonce of the target transaction data is A9, indicating the ninth transaction data of the A account, and the nonce of the transaction data stored into the ready queue in the last time is A7, it indicates that the data identifiers of the transaction data of the A account are not sequentially increased, and the eighth transaction data is missing. At this time, the target node does not store the target transaction data into the ready queue, but stores the target transaction data into the unready queue for waiting.

[0126] At step 302, when it is detected that there is same-account data belonging to the same account as the target transaction data in the unready queue, and the same-account data meets the preset enqueuing condition, the same-account data is stored into the ready queue.

[0127] The same-account data is transaction data belonging to the same account as the target transaction data.

[0128] Here, after the target node stores the target transaction data into the ready queue, it can continue to detect whether there is same-account data belonging to the same account as the target transaction data in the unready queue. If there is, the target node can store the same-account data in the unready queue that meets the preset enqueuing condition into the ready queue.

[0129] For example, if the nonce of the target transaction data is A8, indicating the 8th transaction data of account A, if the nonce of the latest transaction data of account A stored into the ready queue is A7, it indicates that the data identifiers of the transaction data of account A can be sequentially incremented. At this time, the target node can store the target transaction data into the ready queue. In addition, after the target node stores the target transaction data into the ready queue, if it is detected that there is same-account data belonging to the same account as the target transaction data in the unready queue, and the nonce of the same-account data is A9, since the nonce of the latest transaction data of account A stored into the ready queue is A8, it indicates that the data identifiers of the transaction data of account A can be sequentially incremented. At this time, the target node can store the same-account data of the target transaction data into the ready queue.

[0130] It should be noted that in the cross-chain transaction scenario, a cross-chain transaction usually includes two parties, namely the source chain and the destination chain. In order to ensure the state consistency of the source chain and the destination chain, the transaction execution order of the destination chain needs to strictly follow the order in which the account transactions of the source chain are generated. As a hub between the source chain and the destination chain, the relay chain is usually difficult to ensure that each transaction data generated on the source chain reaches the relay chain in order. If the relay chain does not sort each transaction data received, it is easy to cause each transaction data to reach the destination chain out of order. In this way, the transaction execution order of the destination chain may not strictly follow the order in which the account transactions of the source chain are generated, resulting in transaction failures. Therefore, sorting each transaction data in the transaction pool in a manner that the data identifiers of each transaction data corresponding to the same account are sequentially incremented can ensure that each transaction data of the same account is sequentially incremented after being stored on the chain, that is, arranged according to the generation order, which can ensure that each transaction data of the same account is executed in order, thereby ensuring the safety and reliability of the entire blockchain system.

[0131] As an example, if the amount of transaction data included in each block stored in the blockchain is 10, the nonce of each transaction data in a certain block can be: A1-B1-A2-A3-B2-A4-B3-B4-B5-B6. Among them, the nonce of each transaction data is sequentially increased for the A account, and the nonce of each transaction data is sequentially increased for the B account.

[0132] In some optional implementations of the embodiment, in the case that the transaction pool further includes a ready queue, the step 103 of packaging and storing on-chain at least part of the transaction data in the transaction pool when the preset packaging on-chain condition is triggered can include the following step one and step two.

[0133] Step one, extracting a preset number of transaction data from the ready queue of the transaction pool when the preset packaging on-chain condition is triggered, and packaging the extracted transaction data into a block.

[0134] Among them, the preset packaging on-chain condition can include but is not limited to at least one of the following: the target node is a master node of the target blockchain, and there are a preset number of transaction data in the ready queue. The master node is usually a node with the right to initiate on-chain.

[0135] Among them, the preset number is usually a preset number. For example, it can be 10, or it can be 20.

[0136] Here, when the target node is the master node, the target node can extract a preset number of transaction data from the ready queue of the transaction pool, and package the extracted transaction data into a block.

[0137] Step two, initiating an on-chain request to other nodes on the target blockchain, and storing the block on-chain to each node of the target blockchain when the on-chain request is consensus passed by each other node.

[0138] Here, the target node can initiate an on-chain request to other nodes after packaging the extracted transaction data into a block, so that each other node can participate in consensus, and if each other node consensus passes, the block can be stored on-chain to each node.

[0139] It should be noted that the target node can initiate an on-chain request once for each block it generates to store the block on-chain. In practice, the target node usually initiates an on-chain request once after generating multiple blocks to store multiple blocks on-chain.

[0140] In some optional implementations, after extracting the preset number of transaction data from the ready queue of the transaction pool in step one, the method further includes: storing a transaction set composed of the preset number of transaction data in the packed queue in the form of a key-value pair. The key of the key-value pair is the hash value of the transaction set, and the value of the key-value pair is the transaction set. The packed queue is used to cache the packed transaction data.

[0141] Here, when the target node extracts the preset number of transaction data from the ready queue, the target node can store a transaction set composed of the preset number of transaction data in the packed queue in the form of a key-value pair. The key of the key-value pair can be the hash value of the transaction set, and the value of the key-value pair can be the transaction set.

[0142] In the case where the target node initiates a chain request after generating a plurality of blocks to implement the storage of the plurality of blocks on the chain, each transaction set stored in the packed queue in the form of a key-value pair can facilitate the synchronization of blocks between nodes.

[0143] Correspondingly, before storing the blocks on the chain to each node of the target blockchain in step two, the method further includes: receiving a block request sent by a lagging node. The lagging node is a node corresponding to a block height smaller than that of the main node. The block request includes a block identifier and a hash value of a transaction set corresponding to the block indicated by the block identifier. Each transaction set corresponding to each hash value is sent to the lagging node.

[0144] Here, the target node can receive a block request sent by a lagging node. The lagging node is a node corresponding to a block height smaller than that of the main node. The block request includes a block identifier and a hash value of a transaction set in the block indicated by the block identifier. Then, each transaction set corresponding to each hash value is sent to the lagging node.

[0145] Here, when the target node initiates a chain request to other nodes on the target blockchain, since the block heights of the nodes can be inconsistent, the lagging node can request the missing block data from the main node, so as to realize consistent data saved on each node on the chain.

[0146] For example, if the main node initiates a chain request, the block height of the main node is 20, and the block height of a certain lagging node is 11. At this time, the lagging node can initiate a block request to synchronize the block height from 11 to 20, which can carry each block identifier and the hash value of the transaction set corresponding to each block. The main node can receive the block request, then read the corresponding transaction set from the packed queue, and send the transaction set corresponding to each block 11-20 to the lagging node in a peer-to-peer manner.

[0147] In some optional implementations of the embodiment, after the at least part of the transaction data in the transaction pool is packaged and stored on the chain, the blockchain transaction pool data processing method can further include:

[0148] deleting the packaged and stored transaction data in the transaction pool of the target node, and deleting the corresponding transaction data in the transaction pool of the other nodes on the target blockchain.

[0149] For example, after the transaction data A in the transaction pool is stored on the chain, the target node can delete the transaction data A in its own transaction pool, and can notify the other nodes to delete A in the transaction pool of the other nodes. Even if the stored transaction data on the chain is deleted from the transaction pool of each node, the storage space of the transaction pool can be released in time, and the space utilization rate can be improved.

[0150] In practice, when the transaction pool includes one or more of the global list, the local list, the ready queue, the unready queue, and the packaged queue, deleting a certain transaction data in the transaction pool usually means deleting the transaction data in each queue in the transaction pool.

[0151] Corresponding to the blockchain transaction pool data processing method of the above embodiment one, Figure 4 a structure block diagram of a blockchain transaction pool data processing apparatus 400 provided by the embodiment is shown. For ease of illustration, only parts related to the embodiment are shown.

[0152] Referring to Figure 4 The apparatus includes:

[0153] The data receiving unit 401 is configured to determine the source of the target transaction data when the target node receives the target transaction data, wherein the source includes a user terminal in communication connection with the target node and other nodes on the target blockchain corresponding to the target node.

[0154] The first storage unit 402 is configured to store the target transaction data in the transaction pool and broadcast the target transaction data to the other nodes when the source of the target transaction data is the user terminal.

[0155] The data packaging unit 403 is configured to package and store on the chain at least part of the transaction data in the transaction pool when a preset packaging and chain storage condition is triggered.

[0156] In some embodiments, the apparatus further includes a second storage unit configured to store the target transaction data in the transaction pool when the source of the target transaction data is the other node.

[0157] In some embodiments, the first storing unit 402 and / or the second storing unit stores the target transaction data into the transaction pool, including: storing the target transaction data into the transaction pool in the case that the target transaction data does not exist in the transaction pool.

[0158] In some embodiments, the transaction pool includes a local list for caching transaction data from the user terminal and a global list for caching each transaction data needing to be stored into the transaction pool, and the first storing unit 402 and / or the second storing unit stores the target transaction data into the transaction pool, including:

[0159] In the case that the source of the target transaction data is the user terminal, the target transaction data is stored into the local list and the global list in the transaction pool, and in the case that the source of the target transaction data is another node, the target transaction data is stored into the global list in the transaction pool.

[0160] In some embodiments, the apparatus further includes a parameter generating unit. The parameter generating unit is configured to generate a time parameter of the target transaction data based on the source of the target transaction data.

[0161] The time parameter includes at least one of: a first time parameter indicating a time when the transaction data is stored into the transaction pool, and a second time parameter indicating a time when the transaction data is initiated to be broadcasted.

[0162] In some embodiments, in the case that each transaction data in the transaction pool corresponds to the first time parameter and / or the second time parameter, the apparatus further includes a timeout retransmission unit and an expired deletion unit.

[0163] The timeout retransmission unit is configured to broadcast, to other nodes, to-be-retransmitted data in the local list and update the second time parameter of the to-be-retransmitted data, wherein the to-be-retransmitted data is transaction data whose interval between the time indicated by the second time parameter and the current time is greater than a preset retransmission duration.

[0164] The expired deletion unit is configured to delete to-be-deleted data in the global list and / or the local list, wherein the to-be-deleted data is transaction data whose interval between the time indicated by the first time parameter and the current time is greater than a preset deletion duration.

[0165] In some embodiments, in the case that the transaction pool further includes a ready queue for caching transaction data suitable for on-chain storage and an unready queue for caching transaction data unsuitable for on-chain storage, the apparatus further includes a third storing unit and a fourth storing unit.

[0166] The third storing unit is configured to store target transaction data in the global list into the ready queue in the case that the target transaction data meets a preset queue-in condition.

[0167] A fourth storage unit is configured to store the same-account data into the ready queue when it is detected that the same-account data belonging to the same account as the target transaction data exists in the unready queue and the same-account data satisfies the preset enqueuing condition.

[0168] The same-account data is transaction data belonging to the same account as the target transaction data, and the preset enqueuing condition is that the data identifiers of the transaction data corresponding to the same account are sequentially increasing.

[0169] In some embodiments, the data packaging unit includes a data packaging module and an on-chain storage module.

[0170] The data packaging module is configured to extract a preset number of transaction data from the ready queue of the transaction pool when a preset packaging and on-chain condition is triggered, and package the extracted transaction data into a block.

[0171] The on-chain storage module is configured to initiate an on-chain request to other nodes on the target blockchain, and store the block on the chain to each node of the target blockchain when the on-chain request is agreed by each other node.

[0172] The preset packaging and on-chain condition includes at least one of the following: the target node is a master node of the target blockchain, and the ready queue includes a preset number of transaction data.

[0173] In some embodiments, the data packaging module further includes, after extracting the preset number of transaction data from the ready queue of the transaction pool: storing a transaction set composed of the preset number of transaction data into a packaged queue in the form of a key-value pair, wherein the key of the key-value pair is the hash value of the transaction set, and the value of the key-value pair is the transaction set.

[0174] The on-chain storage module further includes, before storing the block on the chain to each node of the target blockchain: receiving a block request sent by a lag node, wherein the lag node is a node corresponding to a block height smaller than that of the master node, the block request includes a block identifier and a hash value of a transaction set corresponding to the block indicated by the block identifier; and sending the transaction set corresponding to each hash value to the lag node.

[0175] In some embodiments, the apparatus further includes a data deletion unit configured to delete the packaged and on-chain transaction data in the transaction pool of the target node, and delete the corresponding transaction data in the transaction pool of the other nodes on the target blockchain.

[0176] The apparatus provided in the embodiment can greatly reduce the amount of broadcasted data and effectively prevent broadcast storm, because each node receives transaction data and only broadcasts transaction data from the user end, without broadcasting transaction data from other nodes.

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

[0178] 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 of 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 transaction pool 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 transaction pool 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 data receiving unit 401 to the data packaging unit 403 shown are illustrated.

[0179] 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 a data receiving unit, a first storage unit, and a data packaging unit. The specific functions of each unit have been described in the above embodiments and will not be repeated here.

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

[0181] The processor 501 can be a central processing unit (CPU), and can also be other general-purpose processors, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor.

[0182] The memory 502 can be an internal storage unit of the server 500, for example, a hard disk or a memory of the server 500. The memory 502 can also be an external storage device of the server 500, for example, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. Further, the memory 502 can also include both the internal storage unit and the external storage device 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.

[0183] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above functional units and modules is taken as an example for illustration, and in actual application, the above functions can be completed by different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above. Each functional unit and module in the embodiment can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit, and the integrated unit can be realized in the form of hardware or in the form of software. In addition, the specific names of each functional unit and module are only for easy distinction, and do not limit the protection scope of the present application. The specific working process of the units and modules in the above system can refer to the corresponding process in the foregoing method embodiments, which will not be described here.

[0184] In the above embodiments, the description of each embodiment has its own emphasis, and the parts not described or recorded in detail in a certain embodiment can be referred to the relevant description of other embodiments.

[0185] Those skilled in the art can understand that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are realized 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 the present application.

[0186] In the embodiments provided in the present 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 schematic, for example, the division of the modules or units is only a logical function division, and there can be another division manner in actual implementation, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some interface, device or unit, and can be electrical, mechanical or other forms.

[0187] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, that is, they can be located in one place, or can be distributed on a plurality of network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiments.

[0188] In addition, each functional unit in each embodiment of the present application can be integrated into a processing unit, or each unit can exist physically independently, or two or more units can be integrated into one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0189] The integrated module, if implemented in the form of a software functional unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, all or part of the processes in the above-mentioned embodiment methods can also be completed by a computer program instructing related hardware, and the computer program can be stored in a computer readable storage medium. When the computer program is executed by a processor, the steps of the above-mentioned various method embodiments can be implemented. The computer program includes computer program code, which can be in the form of source code, object code, executable files or some intermediate forms. The computer readable medium can include any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content included in the computer readable medium can be appropriately increased or decreased 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.

[0190] The above embodiments are only used to illustrate the technical solutions of the present application, rather than limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacements for part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A method for processing data of a blockchain transaction pool, characterized in that, The method comprises: Upon receiving target transaction data at a target node, determining a source of the target transaction data, wherein the source comprises: a user terminal in communication connection with the target node, and other nodes on a target blockchain corresponding to the target node; In a case where the source of the target transaction data is the user terminal, storing the target transaction data in a transaction pool, and broadcasting the target transaction data to the other nodes; In a case where a preset packaging and on-chain storage condition is triggered, packaging and on-chain storing at least part of the transaction data in the transaction pool; The transaction pool comprises a local list for caching transaction data from the user terminal and a global list for caching each transaction data to be stored in the transaction pool, and the storing of the target transaction data in the transaction pool comprises: In a case where the source of the target transaction data is the user terminal, storing the target transaction data in the local list and the global list in the transaction pool, and in a case where the source of the target transaction data is the other nodes, storing the target transaction data in the global list in the transaction pool; Generating a time parameter of the target transaction data based on the source of the target transaction data; The time parameter comprises at least one of: a first time parameter indicating a time when the transaction data is stored in the transaction pool, and a second time parameter indicating a time when the transaction data is initiated for broadcasting; in a case where the source of the target transaction data is the user terminal, the target node generates the first time parameter and the second time parameter based on the target transaction data; in a case where the source of the target transaction data is the other nodes, the target node generates the first time parameter based on the target transaction data; The transaction pool further comprises a ready queue for caching transaction data suitable for on-chain storage and a non-ready queue for caching transaction data unsuitable for on-chain storage; and after the storing of the target transaction data in the transaction pool, the method further comprises: In a case where the target transaction data satisfies a preset entry condition, storing the target transaction data in the global list in the ready queue; In a case where it is detected that there is same-account data belonging to a same account as the target transaction data in the non-ready queue, and the same-account data satisfies the preset entry condition, storing the same-account data in the ready queue; The same-account data is transaction data belonging to a same account as the target transaction data, and the preset entry condition is that data identifiers of each transaction data corresponding to the same account are in ascending order. 2.The method of claim 1, wherein, The method further comprises: In a case where the source of the target transaction data is the other nodes, storing the target transaction data in the transaction pool. 3.The method of Claim 1, wherein, The storing of the target transaction data in the transaction pool comprises: In a case where the target transaction data does not exist in the transaction pool, storing the target transaction data in the transaction pool. 4.The method of Claim 1, wherein, In a case where each transaction data in the transaction pool corresponds to a first time parameter and / or a second time parameter, the method further comprises: when there is to-be-retransmitted data in the local list, broadcasting the to-be-retransmitted data to the other nodes, and updating a second time parameter of the to-be-retransmitted data, wherein the to-be-retransmitted data is transaction data whose interval between a time indicated by a second time parameter and a current time is greater than a preset retransmission duration; when there is to-be-deleted data in the global list and / or the local list, deleting the to-be-deleted data, wherein the to-be-deleted data is transaction data whose interval between a time indicated by a first time parameter and a current time is greater than a preset deletion duration. 5.The method of Claim 1, wherein, In a case where the transaction pool further comprises a ready queue, the packing and on-chain storage of at least part of the transaction data in the transaction pool in a case where the preset packing and on-chain storage condition is triggered comprises: In a case where the preset packing and on-chain storage condition is triggered, extracting a preset number of transaction data from the ready queue of the transaction pool, packing the extracted transaction data into a block; initiating an on-chain request to other nodes on the target blockchain, and in a case where each other node consensus passes the on-chain request, storing the block on-chain to each node of the target blockchain; wherein the preset packing and on-chain storage condition comprises at least one of the following: the target node is a master node of the target blockchain, and the preset number of transaction data exists in the ready queue. 6.The method of claim 5, wherein, After the preset number of transaction data is extracted from the ready queue of the transaction pool, the method further comprises: storing a transaction set composed of the preset number of transaction data in the form of a key-value pair in a packed queue, wherein the key of the key-value pair is a hash value of the transaction set, and the value of the key-value pair is the transaction set. Before the block is stored on-chain to each node of the target blockchain, the method further comprises: receiving a block request sent by a lagging node, wherein the lagging node is a node whose block height is less than the block height of the master node, the block request comprises a block identifier and a hash value of a transaction set corresponding to the block indicated by the block identifier; and sending each hash value corresponding transaction set to the lagging node. 7.The method of any one of claims 1-6, wherein, After the packing and on-chain storage of at least part of the transaction data in the transaction pool, the method further comprises: deleting the packed and on-chain stored transaction data in the transaction pool of the target node, and deleting the corresponding transaction data in the transaction pool of the other nodes on the target blockchain.

8. A server comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor implements the method of any one of claims 1 to 7 when executing the computer program. The processor implements the method of any one of claims 1 to 7 when executing the computer program.

Images