A method, system, device, and medium for processing blockchain consensus data.

Abstract

This application discloses a method, system, device, and medium for processing blockchain consensus data, including: packaging business data generated by a database and sending it to a block-producing node; the block-producing node generating first signature data to be agreed upon based on the business data; sending the business data and the first signature data to a consensus node for consensus processing based on a target compressed data packet structure to obtain consensus data; wherein the target compressed data packet structure includes a target file header, a data area, and a file tail; wherein the target file header includes the original file header and file tail; packaging the consensus-adjusted business data into blocks for on-chain processing and storing the consensus data; when the number of consensus data groups stored in the blockchain blocks reaches a preset threshold, performing backup-based deletion processing on the consensus data. This application can improve consensus efficiency and block generation speed, reduce the storage pressure on nodes, effectively improve the operational stability of the blockchain system, and can be widely applied in the field of blockchain technology.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a method, system, device and medium for processing blockchain consensus data. Background Technology

[0002] A blockchain is a distributed database that uses cryptographic techniques to record and verify transactions. How a blockchain works is that transaction records are stored in a constantly growing list called "blocks." Each block contains one or more transactions, along with a pointer to the previous block. This design makes blockchains very secure because no one can alter transaction records already stored on the blockchain.

[0003] However, nodes in a blockchain need to perform functions such as computation, consensus, and storage. During the consensus process, blockchain nodes need to obtain and save consensus data from other nodes. As the number of nodes increases and the block depth in the blockchain increases, the amount of consensus data that needs to be transmitted between blockchain nodes and the amount of consensus data stored within blockchain nodes continue to grow, leading to reduced consensus efficiency, slower block generation speed, and a surge in data storage pressure at blockchain nodes, affecting the overall setup cost. Summary of the Invention

[0004] The main objective of this application is to propose a method, system, device, and medium for processing blockchain consensus data, aiming to improve the consensus efficiency and block generation speed of blockchain, and alleviate the data storage pressure on blockchain nodes.

[0005] To achieve the above objectives, one aspect of this application proposes a method for processing blockchain consensus data, the method comprising:

[0006] Package the business data generated by the database and send it to the block-producing node;

[0007] The block-producing node generates first signature data to be reached for consensus based on the business data.

[0008] Based on the target compressed data packet structure, the business data and the first signature data are sent to the consensus node for consensus processing to obtain consensus data; wherein, the target compressed data packet structure includes a target file header, a data area, and a file tail; wherein, the target file header consists of the original file header and a copied file tail;

[0009] The consensus-reached business data is packaged into blocks for on-chain processing and stored.

[0010] When the number of consensus data sets stored in a blockchain block reaches a preset threshold, the consensus data is reduced in a backup manner.

[0011] In some embodiments, in the step of packaging and sending the business data generated by the database to the block-producing node, the business data includes at least one of logistics information, commodity transaction data, and upload data from Internet devices.

[0012] In some embodiments, generating first signature data to be agreed upon based on the business data includes:

[0013] The business data is hashed to obtain the first data;

[0014] The first data is signed using the private key of the block-producing node to obtain the first signed data to be reached through consensus.

[0015] In some embodiments, the step of sending the business data and the first signature data to a consensus node for consensus processing based on a target compressed data packet structure to obtain consensus data includes:

[0016] The business data and the first signature data are segmented to obtain data fragments;

[0017] The data segment is compressed to obtain a first compressed data packet; wherein the first compressed data packet includes a file header, a data area, and a file footer;

[0018] Copy the file end and append it to the file header to obtain the second compressed data packet;

[0019] The second compressed data packet is sent to the consensus node.

[0020] In some embodiments, the step of sending the business data and the first signature data to a consensus node for consensus processing based on the target compressed data packet structure to obtain consensus data, and performing consensus processing, includes:

[0021] The second compressed data packet is downloaded in parallel and then decompressed to obtain the service data and the first signature data;

[0022] The public key of the block-producing node is used to verify the signature of the business data;

[0023] When the verification passes, the consensus node uses its own private key to sign, obtaining the second signature data, and then obtains the consensus data; wherein, the consensus data includes the first signature data and the second signature data.

[0024] In some embodiments, the step of performing a backup-based deletion process on the consensus data when the number of consensus data sets stored in a blockchain block reaches a preset threshold includes:

[0025] Retrieve the consensus data currently stored in the deleted node and use it as the current consensus data;

[0026] A hash calculation is performed on the current consensus data to obtain a set of hash values;

[0027] The hash value is digitally signed using the private key of the deleted node to obtain a snapshot;

[0028] The digital signature is sent to other nodes for consensus processing to obtain a consensus result;

[0029] If the consensus result is that consensus is complete, the snapshot will be distributed to all blockchain nodes for storage.

[0030] Identify a backup node and notify the blockchain nodes other than the backup node to delete the current consensus data.

[0031] In some embodiments, the step of determining the backup node includes:

[0032] Backup nodes are determined based on the batch of consensus data.

[0033] Alternatively, detect the current available storage capacity of each blockchain node and determine the node with the largest available storage capacity as the backup node.

[0034] To achieve the above objective, another aspect of this application proposes a blockchain consensus data processing system, the system comprising:

[0035] The first module is used to package the business data generated by the database and send it to the block-producing node.

[0036] The second module is used by the block-producing node to generate first signature data to be reached for consensus based on the business data.

[0037] The third module is used to send the business data and the first signature data to the consensus node for consensus processing based on the target compressed data packet structure to obtain consensus data; wherein, the target compressed data packet structure includes a target file header, a data area and a file tail; wherein, the target file header consists of the original file header and a copied file tail;

[0038] The fourth module is used to package the consensus-reached business data into blocks for on-chain processing and to store the consensus data.

[0039] The fifth module is used to perform a backup-based deletion process on the consensus data when the number of consensus data groups stored in the blockchain blocks reaches a preset threshold.

[0040] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described above.

[0041] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods described above.

[0042] The embodiments of this application include at least the following beneficial effects: This application provides a method, system, device, and medium for processing blockchain consensus data. When transmitting consensus data between blockchain nodes, the consensus data is compressed by improving the compressed data packet format of the file header before transmission. This allows consensus nodes to obtain consensus data efficiently, improving consensus efficiency and block generation speed, and enhancing the data processing performance of the blockchain. Moreover, within the blockchain node, global consensus is achieved on the consensus data itself, and then the consensus data stored in the blockchain node is reduced, thereby reducing the data storage pressure at the blockchain node and improving the operational stability of the blockchain system. Attached Figure Description

[0043] The accompanying drawings are used to provide a further understanding of the technical solutions of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of this application and do not constitute a limitation on the technical solutions of this application.

[0044] Figure 1 This is a schematic diagram illustrating the application of blockchain provided in the embodiments of this application;

[0045] Figure 2 This is a flowchart illustrating a method for processing blockchain consensus data provided in an embodiment of this application;

[0046] Figure 3 This is a flowchart of steps S310 to S340 provided in the embodiments of this application;

[0047] Figure 4 This is a flowchart of steps S350 to S370 provided in the embodiments of this application;

[0048] Figure 5 This is a flowchart of steps S510 to S560 provided in the embodiments of this application;

[0049] Figure 6This application provides a schematic diagram of the ZIP compressed data packet format in an embodiment.

[0050] Figure 7 This is a schematic diagram illustrating the reconstruction of the compressed data packet format provided in an embodiment of this application;

[0051] Figure 8 This is a schematic diagram of parallel decompression of data segments provided in an embodiment of this application;

[0052] Figure 9 This is a schematic diagram of blockchain data uploading provided in an embodiment of this application;

[0053] Figure 10 This is a schematic diagram of the structure of a blockchain consensus data processing system provided in an embodiment of this application;

[0054] Figure 11 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0055] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0056] Although functional modules are divided in the system diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the system or the order in the flowchart. The terms "first / S100," "second / S200," etc., in the specification, claims, and the aforementioned figures are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0057] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”

[0058] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.

[0059] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0060] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0061] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0062] (1) Blockchain: Reference Figure 1 Blockchain is a distributed database that uses cryptographic techniques to record and verify transactions. How does a blockchain work? It stores transaction records in a constantly growing list called "blocks." Each block contains one or more transactions, along with a pointer to the previous block. This design makes blockchains very secure because no one can alter transaction records already stored on the blockchain.

[0063] (2) Consensus mechanism: In a blockchain network, all nodes agree on the mechanism of blocks. The consensus mechanism is the foundation of the operation of the blockchain network and an important means to ensure the integrity and security of the blockchain network.

[0064] (3) Hash processing: This refers to the process of converting input data of arbitrary length into output data of fixed length using a hash function. Hash processing is an important data processing technique, widely used in cryptography, data integrity verification, data indexing, and other fields.

[0065] (4) ZIP: A file compression format that can compress multiple files or folders into a single ZIP file, thereby reducing file storage space and transmission time.

[0066] Currently, nodes in a blockchain need to perform functions such as computation, consensus, and storage. During the consensus process, blockchain nodes need to obtain and save consensus data from other nodes. As the number of nodes increases and the block depth in the blockchain deepens, the amount of consensus data that needs to be transmitted between blockchain nodes and the amount of consensus data stored within blockchain nodes are constantly increasing. This leads to a decrease in consensus efficiency, a slower block generation speed, and a surge in data storage pressure at blockchain nodes, affecting the overall setup cost.

[0067] In view of this, this application provides a method, system, device, and medium for processing blockchain consensus data. When transmitting consensus data between blockchain nodes, the method compresses the consensus data based on a constructed target compressed data packet structure before transmission. This allows consensus nodes to efficiently obtain consensus data through parallel decompression, improving consensus efficiency and block generation speed, and enhancing the data processing performance of the blockchain. Furthermore, within the blockchain node, global consensus is achieved on the consensus data itself, and then the consensus data stored on the blockchain node is reduced, thereby decreasing the data storage pressure at the blockchain node and improving the operational stability of the blockchain system.

[0068] This application provides a method for processing blockchain consensus data, relating to the field of blockchain technology. This method can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or in-vehicle terminal, but is not limited thereto. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing a blockchain consensus data processing method, but is not limited to the above forms.

[0069] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0070] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirection to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data required for the proper functioning of these embodiments acquired.

[0071] Figure 2 This is an optional flowchart of a blockchain consensus data processing method provided in an embodiment of this application. Figure 1 The method may include, but is not limited to, steps S100 to S500.

[0072] Step S100: Package the business data generated by the database and send it to the block-producing node;

[0073] Step S200: The block-producing node generates first signature data to be reached for consensus based on the business data;

[0074] Step S300: Based on the target compressed data packet structure, the business data and the first signature data are sent to the consensus node for consensus processing to obtain consensus data; wherein, the target compressed data packet structure includes a target file header, a data area, and a file tail; wherein, the target file header consists of the original file header and a copied file tail;

[0075] Step S400: Package the consensus-reached business data into blocks for on-chain processing and store the consensus data;

[0076] Step S500: When the number of consensus data groups stored in the blockchain blocks reaches a preset threshold, the consensus data is reduced with backup.

[0077] Steps S100 to S500 as illustrated in this embodiment enable blockchain nodes to compress consensus data during transmission by improving the compressed data packet format of the file header. This allows consensus nodes to obtain consensus data efficiently, improving consensus efficiency and block generation speed, and enhancing the data processing performance of the blockchain. Furthermore, within the blockchain node, global consensus is achieved on the consensus data itself, and then the consensus data stored in the blockchain node is reduced, thereby reducing the data storage pressure at the blockchain node and improving the operational stability of the blockchain system.

[0078] In step S100 of some embodiments, the business data may include any content, such as logistics information, commodity transactions, or data uploaded by IoT devices or corresponding data hash values, etc., and is not limited to these. For some privacy transactions, algorithms such as homomorphic encryption or zero-knowledge proofs are required to encrypt the transaction data to obtain the business data.

[0079] In some embodiments, step S200 may include, but is not limited to, steps S210 to S220:

[0080] Step S210: Hash the business data to obtain the first data;

[0081] Step S220: Sign the first data using the private key of the block-producing node to obtain the first signed data to be reached through consensus.

[0082] Step S200 obtains the first signature data to be reached for consensus, preparing for subsequent data consensus.

[0083] Please see Figure 3 In some embodiments, step S300 may include, but is not limited to, steps S310 to S340, which involve sending the business data and the first signature data to the consensus node:

[0084] Step S310: Perform fragmentation processing on the business data and the first signature data to obtain data fragments;

[0085] Step S320: Compress the data segment to obtain a first compressed data packet; wherein the first compressed data packet includes a file header, a data area, and a file footer;

[0086] Step S330: Copy the file tail and append the file tail to the file header to obtain the second compressed data packet;

[0087] Step S340: Send the second compressed data packet to the consensus node.

[0088] Through steps S310 to S340, consensus data is compressed and transmitted using an improved compressed data packet structure, enabling consensus nodes to efficiently obtain consensus data through parallel decompression, thereby improving data processing efficiency.

[0089] In some embodiments, refer to Figure 4 Step S300 may also include, but is not limited to, steps S350 to S370, which involve consensus processing:

[0090] Step S350: Download the second compressed data packet in parallel and decompress the second compressed data packet to obtain the service data and the first signature data;

[0091] Step S360: Verify the signature of the business data using the public key of the block-producing node;

[0092] Step S370: When the verification is successful, the consensus node uses its own private key to sign, obtains the second signature data, and then obtains the consensus data; wherein, the consensus data includes the first signature data and the second signature data.

[0093] Through steps S350 to S370, consensus nodes that only support sequential downloads can quickly obtain the file end of the compressed data packet, thereby enabling parallel decompression of the compressed packet and shortening the verification and decompression time.

[0094] In some embodiments, after reaching a consensus on the business data, step S400 packages the business data into blocks and uploads them to the blockchain, and saves the consensus data corresponding to the business data, which facilitates later verification.

[0095] Reference Figure 5 In some embodiments, step S500 may also include, but is not limited to, steps S510 to S560, which involve backing up and reducing the consensus data:

[0096] Step S510: Retrieve the consensus data currently stored in the deleted node and use it as the current consensus data;

[0097] Step S520: Perform hash calculation on the current consensus data to obtain a set of hash values;

[0098] Step S530: Use the private key of the deleted node to digitally sign the hash value to obtain a snapshot;

[0099] Step S540: Send the digital signature to other nodes for consensus processing to obtain a consensus result;

[0100] Step S550: If the consensus result is that consensus is complete, distribute the snapshot to all blockchain nodes for storage;

[0101] Step S560: Determine the backup node and notify the blockchain nodes other than the backup node to delete the current consensus data.

[0102] Steps S510 to S560 can reduce the storage pressure on the blockchain and improve the stability of the blockchain system.

[0103] In some embodiments, the step of determining the backup node in step S500 may include, but is not limited to:

[0104] Step S570: Determine backup nodes based on the batch of consensus data;

[0105] Alternatively, in step S580, detect the current available storage capacity of each blockchain node and determine the node with the largest available storage capacity as the backup node.

[0106] The backup nodes determined by step S570 or step S580 can be adapted to different needs, reducing the construction cost of the blockchain system without affecting the normal consensus storage record of the blockchain.

[0107] The following section provides a detailed introduction and explanation of the solution in this application embodiment, using specific examples of blockchain consensus data processing scenarios:

[0108] This application provides a method for processing blockchain consensus data, which can be applied in the field of blockchain technology. Its main process steps are as follows:

[0109] 1. Send the business data generated by the database to the blockchain node for processing.

[0110] After business data is generated in the database, it is packaged and sent to nodes in the blockchain. This business data can include any content, such as logistics information, product transactions, data uploaded by IoT devices, or the hash values ​​of corresponding data. For some privacy-sensitive transactions, algorithms such as homomorphic encryption or zero-knowledge proofs are used to encrypt the transaction data to obtain the business data.

[0111] 2. Blockchain nodes generate data for consensus purposes.

[0112] At the blockchain nodes, consensus is reached on business data, achieved through digital signatures. The block-producing node (the node that processes the business data) hashes the data and then signs it using its private key, obtaining the first signature data to be agreed upon. This first signature data is then sent to the other nodes, which become the consensus nodes in this process. Generally, blockchain consensus mechanisms can employ the majority rule, meaning that when more than half of the nodes confirm the data is correct, the business data is considered to have reached consensus and can be added to the blockchain for processing.

[0113] 3. The block-producing node sends the data used for consensus to the consensus node.

[0114] Since the amount of business data involved in consensus data can be large, and consensus data transmission needs to be executed across multiple nodes, the consensus data can be packaged into compressed data packets for transmission between nodes to improve the efficiency of consensus data transmission between blockchain nodes. In this embodiment, a fragmented compression method can be applied, that is, the compressed data packet is processed into multiple fragments. This allows for parallel decompression processing during the download process, enabling rapid restoration of the data in the compressed packet.

[0115] Reference Figure 6 The current compressed data packet format is generally a header-data area-tail file structure. For example, the zip structure includes a source file data storage area (which stores multiple compressed data segments, each data segment being a data area, preceded by a header), a central directory area, and a central directory end marker (these two parts constitute the tail). The header and tail identify the type and structure of the compressed file and provide information about it.

[0116] The file header typically contains information about the compressed file, such as the file type, compression algorithm, and compression level. This information helps decompression software identify the type and structure of the compressed file and use the correct algorithm and level to decompress it. The file footer typically contains information about the compressed file, such as the file offset and modification time. This information helps verify the integrity and consistency of the compressed file and ensures that the file has not been modified during transmission or storage. The file header and footer may vary depending on the compression format, but generally, their function is to identify the type and structure of the compressed file and provide information about it for proper decompression and verification.

[0117] Some of the node servers mentioned earlier may only support sequential downloads. This means that when decompressing a received compressed data package, these servers can only download each data segment in the compressed package sequentially and then decompress it. This presents a problem where parallel decompression processing cannot be supported, as the end of the file needs to be downloaded before each data segment can be correctly verified and decompressed.

[0118] To address the issue that some node servers may only support sequential downloads, meaning they can only download all data from beginning to end according to the compressed data packet format, this application proposes an improved compressed data packet format.

[0119] Reference Figure 7 In this embodiment, the compressed data packet format is reconstructed to obtain the target compressed data packet format. The working principle is as follows: First, the data is compressed to obtain a compressed data packet, which includes a file header, a data area, and a file footer. A copy of the file footer information of this compressed data packet is copied and appended to the file header of the obtained compressed data packet. Then, the resulting file is used as the new file header, thus obtaining a new compressed data packet. The advantage of this approach is that even servers that only support sequential downloads can quickly obtain the file footer of the compressed data packet, thereby enabling parallel decompression of the compressed data packet.

[0120] Reference Figure 8 In this application, in the consensus node, the data segments in the compressed data can be downloaded, verified, and decompressed in parallel. For example, when the first data segment is being verified, the second data segment can be downloaded. Compared with the traditional method of sending and then downloading all data segments, and then verifying and decompressing them, the verification and decompression time can be shortened, thereby improving the data transmission efficiency, and thus improving the consensus efficiency and block generation speed.

[0121] For example, suppose a set of data to be transmitted is first segmented. Based on the data size, such as 100MB, it is divided into 5 segments, with each segment's size controlled within a reasonable range, ideally balanced (e.g., between 15-25MB). This results in 5 data segments. For each segment, a compression algorithm (such as ZIP compression) is used to compress it, resulting in a corresponding compressed data packet. Here, the data is segmented first, then compressed, not compressed and then segmented (because compression results in a complete data packet file, which is difficult to further segment). Then, for example, consensus node A sends the data to consensus node B. Consensus node B can download these compressed data packets from consensus node A. After downloading one, it can download another, simultaneously performing verification and decompression on the downloaded packets. Verification and decompression are existing technologies. The key point here is that the verification and decompression of downloaded compressed data packets can be performed concurrently with the download of other compressed data packets. If they are downloaded together, verification and decompression can only be performed after all packets have been downloaded, which takes longer. For each compressed data packet, decompression restores the original data, which, when combined, represents the complete data before segmentation.

[0122] After adopting the improved compressed file format of this application embodiment, for each compressed data package, the decompression process can be performed normally once the new file header is downloaded, because the new file header contains the information required for decompression. The original format, which only supports sequential download, requires downloading from the file header to the file footer, obtaining all content before decompression can begin. For example, in a file 1-2-3-4-5-6-7, where 1 is the file header, 7 is the file footer, and 2 to 6 are the file data, sequential download requires obtaining all content from 1 to 7 before decompression can begin. In this application embodiment, the file is 8-2-3-4-5-6-7, where 8 includes the file header 1 and the file footer 7. After downloading 8, the content of 2 can be verified and decompressed immediately after downloading, without waiting for 3-4-5-6-7 to be completely downloaded.

[0123] At the consensus node, the compressed data packet is decompressed to obtain business data and the block-producing node's signature data. The block-producing node's public key can be used to verify the signature of the business data. Upon successful verification, the node uses its own private key to sign the data, obtaining a second signature, which is then returned to the block-producing node. After consensus on the business data is achieved, the business data is packaged into a block and uploaded to the blockchain, and the corresponding consensus data is saved for later verification. Overall, the blockchain data upload diagram of this application can be referred to... Figure 9 As shown.

[0124] 4. Processing of deleting consensus data in blockchain nodes;

[0125] Each node stores consensus data corresponding to the business data in each block. As the blockchain becomes deeper, the amount of consensus data increases significantly, while the data storage capacity of blockchain nodes is limited. Excessive consensus data increases the data storage pressure on the blockchain, affecting the operational stability of the blockchain system. This application provides a targeted consensus data reduction scheme. The consensus data corresponding to the blockchain can be numbered according to the corresponding blocks. For example, if the blockchain includes 100 blocks, they can be numbered 1-100 from smallest to largest. The consensus data corresponding to the business data within each block can also be divided into 100 groups, resulting in 100 groups of consensus data.

[0126] When storing consensus data, a threshold for the number of consensus data sets can be set. When this threshold is reached, the consensus data can be processed. The processing procedure is as follows:

[0127] 1) Retrieve the consensus data currently stored in the node (denoted as the deleted node);

[0128] 2) Perform hash calculation on this part of the consensus data to obtain a set of hash values, and then use the private key of the removed node to digitally sign it to form a snapshot;

[0129] 3) The digital signature is sent to other nodes for consensus. Other nodes decrypt the digital signature using the public key of the node being decrypted, then hash the consensus data, compare the calculated digest value with the decrypted digest value, and if they match, the verification is successful. Other nodes then return their own digital signatures for the snapshot.

[0130] 4) Once more than half of the digital signatures in the snapshot are obtained, the consensus of the consensus data is considered complete (these processes are similar to the consensus process for business data, and the compressed transmission method mentioned above can also be used); otherwise, the consensus of the consensus data is considered to have failed, indicating that the consensus data at the deleted node has been tampered with or is incorrect.

[0131] 5) After the consensus data is reached, a snapshot of the global consensus is distributed to all nodes for storage. The global snapshot includes the hash value corresponding to the consensus data and the consensus signature of each node, as well as the block number corresponding to this batch of consensus data.

[0132] 6) Select one node from all nodes as a backup node; here, the backup node can be randomly selected from non-malicious nodes with good behavior.

[0133] 7) Notify all nodes except the backup node to delete the consensus data that has passed the global consensus.

[0134] In this application, apart from backup nodes, all blockchain nodes will only store a global snapshot corresponding to the current batch of consensus data. This global snapshot proves that the current batch of consensus data has been agreed upon by the blockchain nodes and is correct. Furthermore, the consensus data itself proves that the business data in the corresponding block number has been agreed upon by the blockchain nodes and is correct. Therefore, the global snapshots of the consensus data stored by all blockchain nodes can indirectly prove the correctness of the business data within the blockchain. Moreover, a large amount of consensus data can be deleted from the blockchain nodes; only the snapshot after global consensus needs to be stored, significantly reducing the amount of data that needs to be stored. Additionally, this application selects backup nodes to store the current batch of consensus data for easy retrieval when needed. Since all nodes possess a global snapshot, it can be used to verify whether the consensus data within the backup nodes has been tampered with, thus improving data security.

[0135] 5. Optimization of backup node selection.

[0136] Optimization 1: In this application, different batches of consensus data can be constrained to correspond to different backup nodes. This prevents a situation where a backup node still needs to store the full (or a large amount) of the consensus data.

[0137] The above processing flow is illustrated in detail below:

[0138] Assume that the consensus data is pruned every 20 blocks. The current block number is checked, and when the block number is a multiple of 20, such as 20, 40, etc., the consensus data for the current batch is obtained. For example, if the current block number is 60, the current processing batch is the 3rd batch (1-20, 21-40, ...), and the consensus data corresponding to blocks 41-60 is obtained.

[0139] Consensus is reached on this portion of the data to obtain a global snapshot, and corresponding backup nodes are determined. For example, in a total of 50 blockchain nodes, node A is selected as the first batch of backup nodes, and node B is selected as the second batch. Node A stores the consensus data corresponding to blocks 1-20, and node B stores the consensus data corresponding to blocks 21-40. From the nodes other than A and B, one node is randomly selected as the backup node for the third batch of blocks, such as node C. Then, all nodes except node C are notified to delete the consensus data corresponding to blocks 41-60. Here, generally, the number of nodes is large enough to support a large number of blocks. If all nodes are selected as backup nodes, their selection records are cleared, and the process starts again.

[0140] Optimization 2: In this application, when selecting backup nodes, the current available storage capacity of each node can be detected, and then the node with the largest capacity can be selected as the backup node. This allows the storage task of consensus data to be assigned to nodes that still have storage space, thereby balancing the data storage pressure on each node. Moreover, since this application processes consensus data in batches, when a node becomes a backup node, its available storage capacity decreases, and it may not be selected in the next batch of backup node selection, thus preventing insufficient node storage space.

[0141] The above processing steps can significantly reduce the amount of consensus data that needs to be stored within blockchain nodes without affecting the normal consensus storage records of the blockchain. This can alleviate data storage pressure and reduce the construction cost of the blockchain system.

[0142] In summary, the embodiments of this application have at least the following beneficial effects:

[0143] (1) In this application, a new compressed data structure is constructed, which can support nodes that download sequentially to decompress compressed data in parallel.

[0144] (2) In this application, by downloading, verifying and decompressing each data segment in the compressed data in parallel, compared with the traditional method of downloading all data after sending and then verifying and decompressing, the verification and decompression time can be shortened, thereby improving the data transmission efficiency, and thus improving the consensus efficiency and block generation speed.

[0145] (3) In this application, a large amount of consensus data can be deleted within the blockchain node. Only a snapshot after global consensus needs to be saved, which greatly reduces the amount of data to be stored, alleviates data storage pressure, and reduces the construction cost of the blockchain system.

[0146] (4) In this application, backup nodes are selected to store consensus data of each batch, so that it can be retrieved and used when needed. Since all nodes have a global snapshot, it can be used to verify whether the consensus data in the backup nodes has been tampered with, which can improve the security of the data.

[0147] Please refer to Figure 10 This application also provides a blockchain consensus data processing system, which can implement the above-mentioned blockchain consensus data processing method. The system includes:

[0148] The first module is used to package the business data generated by the database and send it to the block-producing node.

[0149] The second module is used by the block-producing node to generate first signature data to be reached for consensus based on the business data.

[0150] The third module is used to send the business data and the first signature data to the consensus node for consensus processing based on the target compressed data packet structure to obtain consensus data; wherein, the target compressed data packet structure includes a target file header, a data area and a file tail; wherein, the target file header consists of the original file header and a copied file tail;

[0151] The fourth module is used to package the consensus-reached business data into blocks for on-chain processing and to store the consensus data.

[0152] The fifth module is used to perform a backup-based deletion process on the consensus data when the number of consensus data groups stored in the blockchain blocks reaches a preset threshold.

[0153] It is understood that the content of the above method embodiments is applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0154] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned method for processing blockchain consensus data. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0155] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0156] Please see Figure 11 , Figure 11 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes:

[0157] The processor 201 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0158] The memory 202 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 202 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 202 and is called and executed by the processor 201 to execute a blockchain consensus data processing method according to an embodiment of this application.

[0159] Input / output interface 203 is used to implement information input and output;

[0160] The communication interface 204 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0161] Bus 205 transmits information between various components of the device (e.g., processor 201, memory 202, input / output interface 203, and communication interface 204);

[0162] The processor 201, memory 202, input / output interface 203 and communication interface 204 are connected to each other within the device via bus 205.

[0163] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned method for processing blockchain consensus data.

[0164] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0165] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0166] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0167] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0168] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0169] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0170] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

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

[0172] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of the units described above 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 an indirect coupling or communication connection through some interfaces, apparatuses, or units, and may be electrical, mechanical, or other forms.

[0173] The units described above 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.

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

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

[0176] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for processing blockchain consensus data, characterized in that, include: Package the business data generated by the database and send it to the block-producing node; The block-producing node generates first signature data to be reached for consensus based on the business data. Based on the target compressed data packet structure, the business data and the first signature data are sent to the consensus node for consensus processing to obtain consensus data; wherein, the target compressed data packet structure includes a target file header, a data area, and a file tail; wherein, the target file header consists of the original file header and a copied file tail; The consensus-reached business data is packaged into blocks for on-chain processing and stored. When the number of consensus data sets stored in a blockchain block reaches a preset threshold, the consensus data is reduced in a backup manner.

2. The method according to claim 1, characterized in that, In the step of packaging and sending the business data generated by the database to the block-producing node, the business data includes at least one of logistics information, commodity transaction data, and data uploaded by Internet devices.

3. The method according to claim 1, characterized in that, Generate the first signature data to be agreed upon based on the business data, including: The business data is hashed to obtain the first data; The first data is signed using the private key of the block-producing node to obtain the first signed data to be reached through consensus.

4. The method according to claim 1, characterized in that, The step of sending the business data and the first signature data to the consensus node for consensus processing based on the target compressed data packet structure to obtain consensus data includes: The business data and the first signature data are segmented to obtain data fragments; The data segment is compressed to obtain a first compressed data packet; wherein the first compressed data packet includes a file header, a data area, and a file footer; Copy the file end and append it to the file header to obtain the second compressed data packet; The second compressed data packet is sent to the consensus node.

5. The method according to claim 4, characterized in that, The step of sending the business data and the first signature data to the consensus node for consensus processing based on the target compressed data packet structure to obtain consensus data includes: The second compressed data packet is downloaded in parallel and then decompressed to obtain the service data and the first signature data; The public key of the block-producing node is used to verify the signature of the business data; When the verification passes, the consensus node uses its own private key to sign, obtaining the second signature data, and then obtains the consensus data; wherein, the consensus data includes the first signature data and the second signature data.

6. The method according to claim 1, characterized in that, In the step of performing a backup-based reduction process on the consensus data when the number of consensus data sets stored in a blockchain block reaches a preset threshold, the backup-based reduction process on the consensus data includes: Retrieve the consensus data currently stored in the deleted node and use it as the current consensus data; A hash calculation is performed on the current consensus data to obtain a set of hash values; The hash value is digitally signed using the private key of the deleted node to obtain a snapshot; The digital signature is sent to other nodes for consensus processing to obtain a consensus result; If the consensus result is that consensus is complete, the snapshot will be distributed to all blockchain nodes for storage. Identify a backup node and notify the blockchain nodes other than the backup node to delete the current consensus data.

7. The method according to claim 6, characterized in that, The steps for determining the backup node include: Backup nodes are determined based on the batch of consensus data. Alternatively, detect the current available storage capacity of each blockchain node and determine the node with the largest available storage capacity as the backup node.

8. A blockchain consensus data processing system, characterized in that, include: The first module is used to package the business data generated by the database and send it to the block-producing node. The second module is used by the block-producing node to generate first signature data to be reached for consensus based on the business data. The third module is used to send the business data and the first signature data to the consensus node for consensus processing based on the target compressed data packet structure to obtain consensus data; wherein, the target compressed data packet structure includes a target file header, a data area and a file tail; wherein, the target file header consists of the original file header and a copied file tail; The fourth module is used to package the consensus-reached business data into blocks for on-chain processing and to store the consensus data. The fifth module is used to perform a backup-based deletion process on the consensus data when the number of consensus data groups stored in the blockchain blocks reaches a preset threshold.

9. An electronic device, characterized in that, Including the processor and memory; The memory is used to store programs; The processor executes the program to implement the method as described in any one of claims 1 to 7.

10. A computer storage medium storing a processor-executable program, characterized in that, The processor-executable program, when executed by the processor, is used to implement the method as described in any one of claims 1 to 7.

Images