HK1247325B - Data processing method and device - Google Patents

Description

Data processing method and device

Technical Field

The present application relates to the field of computer technology, and in particular to a method and device for data processing.

Background Art

With the continuous development of computer technology, the application scope of blockchain technology has been further expanded. At present, various business models have become more effective and secure due to the introduction of blockchain technology, thereby providing users with more effective business services.

In actual applications, businesses involving blockchain technology can be roughly divided into three stages during business execution:

1. Business Acceptance Phase. During this phase, blockchain nodes receive pending business data (also known as transaction data) sent by users via terminals or clients, and after verifying the business data, store it. Of course, blockchain nodes can also receive pending business data sent by other blockchain nodes via broadcast during this phase and store it in the same manner as described above.

Second, the business consensus phase. During this phase, if the blockchain node is the master node initiating consensus, it can extract a portion of the stored business data, package it into a pre-processed block, and broadcast it to other blockchain nodes for consensus on this pre-processed block. After receiving this pre-processed block, other blockchain nodes in the consensus network can perform consensus verification on the business data contained in the pre-processed block based on their stored business data. Of course, if the blockchain node is not the master node, it can also receive the pre-processed block broadcast by the master node and perform consensus verification on the business requests contained in the pre-processed block using the business requests stored in its own memory.

3. Business Submission Phase. During this phase, after the blockchain node confirms that the pre-processed block processed during the business consensus phase has passed consensus, it can store the business data contained in the pre-processed block on the blockchain. Furthermore, the blockchain node can store this business data in a designated database and release the business data contained in the pre-processed block from its own storage space.

In the existing technology, for the same part of business data, blockchain nodes usually need to complete the business consensus phase before entering the business submission phase. Only after the business submission phase is completed can the blockchain nodes reach consensus on the next pre-processing block to be agreed upon.

However, in the existing technology, the business consensus stage and the business submission stage experienced in the business data processing process are executed serially. The blockchain node can only start the business consensus stage of the next business data processing after completing the business submission stage of one business data processing. This will inevitably increase the time interval between the two business data processing, thereby reducing the business processing efficiency of the entire system.

Summary of the Invention

The embodiments of the present application provide a data processing method to solve the problem of low business processing efficiency in the blockchain technology of the prior art.

The present invention provides a method for processing data, including:

The blockchain node obtains the pre-processed block to be consensused and reaches consensus on the pre-processed block;

If it is determined that the pre-processed block has passed the consensus, the consensus process for the next pre-processed block to be reached is initiated, and data processing is performed on the business data contained in the pre-processed block that has passed the consensus in parallel.

The embodiment of the present application provides a data processing device to solve the problem of low efficiency of business consensus in the prior art.

An embodiment of the present application provides a data processing device, including:

An acquisition module acquires a pre-processed block to be consensus-based and performs consensus on the pre-processed block;

The processing module starts consensus on the next pre-processing block to be agreed upon if it is determined that the pre-processing block has passed the consensus, and concurrently processes the business data contained in the pre-processing block that has passed the consensus.

The embodiment of the present application provides a data processing device to solve the problem of low efficiency of business consensus in the prior art.

An embodiment of the present application provides a data processing device, comprising: a memory and at least one processor, wherein: the memory stores a program and is configured such that the at least one processor executes the following steps:

Obtaining a pre-processed block to be consensused, and performing consensus on the pre-processed block;

If it is determined that the pre-processed block has passed the consensus, the consensus process for the next pre-processed block to be reached is initiated, and data processing is performed on the business data contained in the pre-processed block that has passed the consensus in parallel.

At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects:

In the embodiment of the present application, after the blockchain node determines that the acquired pre-processing block has passed consensus, it uses a parallel processing method to start consensus on the next pre-processing block to be agreed upon, and also processes the business data contained in the pre-processing block that has passed consensus. In other words, the blockchain node implements parallel processing of business data in the business consensus stage and the business submission stage. It can perform data processing in the business submission stage on a portion of business data while performing consensus processing in the business consensus stage on another portion of business data. This can shorten the time interval between the consensus processing in the two business consensus stages, thereby effectively improving the system's business data processing efficiency.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

FIG1 is a schematic diagram of a data processing process provided in an embodiment of the present application;

FIG2 is a schematic diagram of data processing performed by a blockchain node according to an embodiment of the present application;

FIG3 is a schematic diagram of a data processing device provided in an embodiment of the present application.

DETAILED DESCRIPTION

In order to enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

FIG1 is a schematic diagram of the data processing process provided in an embodiment of the present application, which specifically includes the following steps:

S101: The blockchain node obtains a pre-processed block to be consensus-based and reaches consensus on the pre-processed block.

In the embodiment of the present application, during the business consensus phase, a blockchain node may obtain a pre-processed block required for a consensus (hereinafter referred to as the pre-processed block obtained for this consensus). The pre-processed block may be generated by the blockchain node based on its own stored business data, or may be obtained from other blockchain nodes.

S102: If it is determined that the pre-processing block has passed the consensus, then starting the consensus process for the next pre-processing block to be reached, and in parallel performing data processing on the business data contained in the pre-processing block that has passed the consensus.

After determining that the pre-processing block to be agreed upon in this consensus has passed the consensus verification, the above-mentioned blockchain node can adopt a parallel processing method to perform data processing in the business submission stage on the pre-processing block that has passed the consensus. In this way, it can effectively achieve the consensus processing of the business consensus stage for the next pre-processing block, and can also synchronously perform data processing in the business submission stage on the pre-processing block that has passed the consensus.

Thus, in the embodiment of the present application, during the processing of business data, the consensus processing in the business consensus phase of the business consensus node and the data processing in the business submission phase are processed synchronously and in parallel. That is, assuming that there are at least two pre-processed blocks to be agreed upon, the technical solution provided by the present application enables the data processing in the business submission phase of the pre-processed blocks that have already passed consensus to be carried out simultaneously and in parallel with the consensus processing in the business consensus phase of the pre-processed blocks that have not yet passed consensus.

It should be noted that, for the pre-processing blocks to be agreed upon in this consensus, when it is determined that the consensus processing of the pre-processing blocks to be agreed upon in this consensus has passed, the consensus processing of the pre-processing blocks to be agreed upon in the next consensus is started, and at the same time, the processing parameters for the pre-processing blocks passed by this consensus are obtained, so that the processor used to implement data processing in the business submission stage during the business data processing process (hereinafter referred to as the preset processor) performs data processing on the pre-processing blocks passed by this consensus based on these processing parameters.

For example, in one case, when starting the consensus processing of the pre-processed block to be agreed upon for the next consensus, the preset processor processes the data of the pre-processed block that has passed the current consensus based on the generated processing parameters. This can be understood as the consensus processing of the pre-processed block to be agreed upon for the next consensus and the data processing of the pre-processed block that has passed the current consensus are processed simultaneously and in parallel, effectively shortening the time interval between the consensus processing of the pre-processed block to be agreed upon for the current consensus and the consensus processing of the pre-processed block to be agreed upon for the next consensus.

Another situation: when starting the consensus processing of the pre-processed block to be agreed upon for the next consensus, the preset processor processes the data of the pre-processed block that has passed the previous consensus. Then the pre-processed block that has passed the current consensus will be stored in the preset queue for waiting. The preset processor processes the data of the pre-processed blocks that have passed the consensus stored in the queue in sequence according to a certain rule (for example, according to the order of consensus completion time, etc.). Here it can be understood that the consensus processing of the pre-processed block to be agreed upon for this consensus and the data processing of the pre-processed block are completed asynchronously.

For example, suppose there are three preprocessing blocks, A, B, and C. These three preprocessing blocks are sent to the blockchain nodes in alphabetical order for consensus. After the blockchain nodes determine that preprocessing block A has passed consensus, they can process the data on preprocessing block A through a preset processor. At the same time, the blockchain nodes can reach consensus on preprocessing block B. After determining that preprocessing block B has passed consensus, if it is discovered that data processing for preprocessing block A has not yet been completed, the blockchain nodes can store the consensus-passing preprocessing block B in a preset queue for waiting, while continuing to reach consensus on preprocessing block C. When data processing for preprocessing block A is determined to be complete, preprocessing block B can be extracted from the preset queue and then processed by the preset processor.

Therefore, for each pre-processed block, the consensus processing and data processing of the pre-processed block are completed in an asynchronous manner. However, for different pre-processed blocks, the consensus processing of one pre-processed block and the data processing of another pre-processed block that has already passed consensus can be processed in a synchronous manner.

After the blockchain node determines that the pre-processed block to be agreed upon in this consensus has passed the consensus verification, in the embodiment of the present application, it includes but is not limited to performing the following two types of operations:

1. First type of operation: Determine the processing parameters corresponding to the pre-processing block that has passed this consensus. The processing parameters include parameters for processing the business data in the pre-processing block, so that the preset processor can process the pre-processing block according to the processing parameters to complete the relevant operations in the business submission phase.

The first type of operations is described in detail below.

The processing parameters here may include but are not limited to: storage parameters, release parameters, deletion parameters, chain parameters, etc. The above is just a simple example of some parameters included in the processing parameters. In actual applications, the processing parameters may also include other parameters, and the specific parameters included may be determined by the specific operations performed by the blockchain node during the business submission stage.

For example, the release parameter is used to instruct the pre-processed block that has passed the consensus to release the pre-processed block from the storage space;

The storage parameter indicates that the business data contained in the consensus pre-processing block should be stored in a specified location. The storage parameters are different for different pre-processing blocks. The storage location is included in the storage parameter.

The delete parameter is used to indicate that the messages generated by the pre-processing block that passes the consensus during the business consensus phase (such as the pre-prepare message, prepare message, and confirmation message in the PBFT consensus) will be deleted to reduce storage pressure.

The on-chain parameter is used to indicate that the pre-processed block should be chained to the blockchain where the previous block is located in the form of a block according to the header hash of the previous block contained in the pre-processed block.

Preferably, in an embodiment of the present application, while the blockchain node is reaching consensus on the adjacent pre-processing block to be agreed upon next time, it can also implement parallel operations of processing the business data contained in the pre-processing block that has passed the current consensus through a preset processor.

Assuming that, in the prior art, a blockchain node executes the business consensus and business submission phases of a business data processing process, it can be understood that these two phases are completed through the same thread. The blockchain node must first complete the business consensus phase of the business data processing process through this thread, and then use the same thread to execute the business submission phase of the business data processing process. Obviously, in the prior art, blockchain nodes execute the business consensus and business submission phases involved in a business data processing process in a serial manner, thereby increasing the time interval between two consecutive business data processing operations and reducing business data processing efficiency.

In order to effectively solve the above problems, in an embodiment of the present application, a processor is pre-set in the blockchain node (the processor can work in an asynchronous processing mode, which is not specifically limited here), and the processor can be used to perform operations involved in the business submission phase. In other words, in an embodiment of the present application, the blockchain node can use two threads to respectively implement the consensus processing of the business consensus phase and the data processing of the business submission phase in the business data processing process, that is, one thread is used to perform consensus processing on the pre-processing block to be consensused, and the other thread is used to perform data processing on the pre-processing block that has passed the consensus. In this way, for the same pre-processing block, its consensus processing and its data processing are completed in an asynchronous manner.

In this way, while the blockchain node uses the processor to execute operations involved in the business submission phase, the blockchain node can start the consensus task of the next adjacent pre-processed block to be agreed upon without being affected, that is, start the execution of the next consensus, thereby greatly shortening the time interval between two adjacent consensuses and improving the consensus efficiency.

In the embodiment of the present application, the processing parameters determined by this consensus can be obtained through the processing parameters determined by the previous consensus.

Taking storage parameters as an example, after a blockchain node determines that the pre-processed block to be agreed upon in the current consensus has passed the consensus, it can determine the storage parameters of the pre-processed block for the next consensus based on the storage parameters of the pre-processed block that has passed the consensus in the current consensus, and store them.

For example, suppose the storage parameters corresponding to the pre-processed block that passes the current consensus (which can also be understood as the storage parameters corresponding to this consensus) stipulate that the business data contained in the pre-processed block that passes the current consensus needs to be stored in table a of relational database A. Then, the blockchain node can determine the storage parameters corresponding to the pre-processed block that passes the next consensus according to the alphabetical order of the tables in relational database A: the business data contained in the pre-processed block that passes the current consensus (i.e., the next consensus mentioned above) needs to be stored in table b of relational database A.

The blockchain node can store the determined storage parameters for the next consensus, so that when the preset processor determines that the pre-processing block of the next consensus has passed the consensus, it can determine which table in which database the business data contained in the pre-processing block that has passed the consensus needs to be stored in based on the obtained storage parameters.

Preferably, in an embodiment of the present application, after the blockchain node determines that the pre-processed block to be agreed upon in this consensus has passed the consensus, it can also determine and store the storage parameters of the pre-processed block of the next adjacent consensus based on the pre-processed block and the storage parameters of the pre-processed block.

Specifically, if the storage location included in the storage parameter exists in the form of a storage pointer, that is, the location pointed to by the storage pointer is the storage location of the business data in the preprocessing block. After the blockchain node determines that the preprocessing block to be agreed upon in this consensus has passed the consensus, it can use the current location of the storage pointer as the starting point, and move the location of the storage pointer according to the size of the preprocessing block of this consensus. The location of the moved storage pointer is determined as the storage parameter corresponding to the next consensus, that is, the storage parameter of the next adjacent preprocessing block to be agreed upon.

For example, suppose that each consensus processing parameter includes a storage parameter in the form of a storage pointer, basepointer. This storage pointer (i.e., storage parameter) points to the specific storage location of the business data. The initial value of this storage pointer, basepointer, can be set to 0. After each consensus, the blockchain node can determine the specific value of the storage pointer in the processing parameters corresponding to the next consensus based on the size of the preprocessed block that passed the consensus and the storage pointer included in the processing parameters corresponding to the current consensus. In the first consensus, the blockchain node determines that the size of the preprocessed block that passed the consensus is 1024 bytes. Based on the determined preprocessed block size and the initial value of 0 of the storage pointer, the blockchain node can determine that the storage pointer included in the processing parameters corresponding to the second consensus is 1024 and store it. Accordingly, in the second consensus, the blockchain node can use the processor to store the business data contained in the preprocessed block that passed the second consensus in the storage location corresponding to the storage pointer, basepointer = 1024.

In the second consensus, the blockchain node determines that the size of the pre-processed block that passed this consensus is 10 bytes. Based on the determined size of the pre-processed block that passed this consensus and the storage pointer basepointer = 1024 contained in the processing parameters corresponding to the previous consensus (i.e., the first consensus), the blockchain node can determine and store the storage pointer basepointer contained in the processing parameters corresponding to the third consensus as 1034. Accordingly, in the third consensus, the blockchain node can use the processor to store the business data contained in the pre-processed block that passed the third consensus in the storage location corresponding to the storage pointer basepointer = 1034. The subsequent consensus can be deduced in the same way.

It should be noted that in the embodiment of the present application, in addition to determining the storage parameters included in the processing parameters corresponding to the next consensus through the size of the preprocessing block of this consensus, it can also be determined through other information of the preprocessing block. The specific information to be used for determination can be decided by the operation and maintenance personnel of the blockchain node, and examples will not be given one by one here.

It's important to note that for the various parameters included in the processing parameters, the operations performed by blockchain nodes during the business submission phase determine whether these parameters require changes after each consensus. For example, regarding the storage parameters mentioned above, since the business data contained in the preprocessing blocks involved in each consensus cannot be stored in the same storage location, the storage parameters must be changed after each consensus. Regarding the on-chain parameters mentioned above, regardless of which preprocessing block is involved in the consensus, once the preprocessing block passes the consensus network, it must be stored as a block on the blockchain. In other words, regardless of which preprocessing block passes consensus, the processor must perform on-chain operations on that preprocessing block. Therefore, the on-chain parameters do not need to be changed after each consensus, meaning that the on-chain parameters can remain consistent for each consensus.

Preferably, in an embodiment of the present application, the blockchain node may store the obtained processing parameters for the next consensus in a preset queue. For example, the storage parameters of the pre-processing block of the next business consensus are stored in the preset queue.

In this way, the processor can obtain the processing parameters from the preset queue (that is, obtain the processing parameters of the pre-processing block that has passed the consensus), and then store the business data contained in the pre-processing block that has passed the consensus corresponding to the storage parameters according to the storage parameters contained in the processing parameters.

The preset queue mentioned here can be a first-in-first-out queue (FIFO) or other types of queues, which are not specifically limited here. The processor can obtain the processing parameters stored in the FIFO queue, and based on the storage parameters contained in the processing parameters, determine the preprocessing block corresponding to the storage parameters from the stored preprocessing blocks that have passed consensus, and then store the business data contained in the preprocessing block based on the storage parameters.

Specifically, the processor can obtain the storage parameters from the above-mentioned FIFO queue, and then the processor can further determine the pre-processing block to be processed corresponding to the storage parameters. For example: when the blockchain node passes the consensus on the pre-processing block to be agreed upon for this consensus, it generates the storage parameters of the pre-processing block and determines the corresponding relationship between the pre-processing block and the storage parameters. Then, the processor can determine the pre-processing block to be processed corresponding to the storage parameters based on the corresponding relationship. For another example: when the blockchain node passes the consensus on the pre-processing block to be agreed upon for this consensus, it generates the storage parameters of the pre-processing block, determines the first time when the storage parameters are generated, and determines the second time when the consensus on the pre-processing block to be agreed upon for this consensus is passed, and establishes a corresponding relationship between the first time and the second time. Then, the processor can search for the pre-processing block corresponding to the consensus processing end time that meets the set conditions between the generation time of the storage parameters and the generation time. The found pre-processing block can be determined as the pre-processing block to be processed corresponding to the storage parameters. For another example: the processor obtains the storage parameter at the front end of the queue exit from the FIFO queue, then the processor searches the storage space of the blockchain node for the pre-processing block that has passed consensus and has the frontmost storage location, and determines the pre-processing block as the pre-processing block corresponding to the storage parameter.

After determining the pre-processing block to be processed corresponding to the storage parameter, the processor may store the service data included in the pre-processing block to be processed in a storage location specified by the storage parameter according to the storage parameter.

It should be noted that in the embodiment of the present application, in addition to using the FIFO queue described above to store various processing parameters, the blockchain node can also use other queues for storage, such as double-ended queues, etc., which will not be explained one by one here.

In addition to storing the business data contained in the pre-processing block to be processed corresponding to the storage parameter contained in the acquired processing parameter, the processor can also perform other operations on the pre-processing block to be processed according to other parameters contained in the processing parameter.

For example, the processor can release the business data contained in the pending pre-processing block from the storage space based on the release parameter in the processing parameters. For another example, the processor can delete messages such as pre-prepare messages, prepare messages, and confirmation messages generated during the business consensus phase of the current consensus based on the delete parameter in the acquired processing parameters to save storage space on the blockchain node. Of course, the processor can also perform other operations based on other parameters in the processing parameters, which will not be fully illustrated here.

2. The second type of operation: Based on the consensus parameters corresponding to the current consensus, the consensus parameters corresponding to the next consensus are updated. In other words, the blockchain node can determine the consensus parameters corresponding to the pre-processed block that has passed the current consensus, and based on the determined consensus parameters, obtain the consensus parameters corresponding to the next pre-processed block to be agreed upon.

It should be noted that in the embodiments of the present application, after the blockchain node determines that the pre-processed block required for the current consensus has passed consensus verification, in addition to obtaining and storing the processing parameters corresponding to the next consensus based on the processing parameters corresponding to the current consensus, the blockchain node can also update the consensus parameters corresponding to the next consensus based on the consensus parameters corresponding to the current consensus. In other words, the blockchain node can determine the consensus parameters corresponding to the pre-processed block that has passed the current consensus, and based on the determined consensus parameters, obtain the consensus parameters corresponding to the next adjacent pre-processed block to be agreed upon.

The consensus parameters mentioned here can be understood as the attribute information corresponding to a consensus. For example, in the PBFT consensus process, each consensus is typically associated with a view number v, which uniquely identifies this consensus. During a consensus, regardless of which blockchain node in the consensus network serves as the master node, the header hash of the previous block included in the preprocessed block it generates is typically the header hash of the last block currently on the blockchain. The view number v and the header hash of the previous block mentioned here can be referred to as the consensus parameters corresponding to this consensus.

Of course, in addition to the view number v and the header Hash of the previous block described above, the consensus parameters can also contain other information. For different consensus methods, the content contained in the consensus parameters also varies to a certain extent, so I will not explain them in detail.

After determining that the pre-processing block of this consensus has passed the consensus verification, the blockchain node can further determine the consensus parameters corresponding to this consensus, and then obtain the consensus parameters corresponding to the next consensus by updating the consensus parameters, that is, obtain the consensus parameters corresponding to the next adjacent pre-processing block to be agreed upon.

Taking PBFT consensus as an example, assume that the consensus parameters for the current consensus include the view number v and the previous block's header hash. For example, view number v is 16, and the previous block's header hash is 0929d9sldom23oix239xed. After the blockchain node determines that the preprocessed block involved in the current consensus has passed consensus verification, it can update view number 16 to 17 and, based on the preprocessed block's header hash: 679xx9a9a8dfa23389xx34, update the header hash of the block used for the next consensus to 679xx9a9a8dfa23389xx34. Therefore, the consensus parameters for the next consensus should be: view number v: 17, previous block's header hash: 679xx9a9a8dfa23389xx34.

Since blockchain nodes can obtain the consensus parameters for the next consensus based on the consensus parameters corresponding to the current consensus, the blockchain node can then initiate consensus on the adjacent pre-processed blocks to be agreed upon based on the consensus parameters corresponding to the next consensus. The consensus parameters mentioned here can be stored in memory, in the database corresponding to the blockchain node, or in the form of global variables.

It should be noted that, in the embodiment of the present application, the consensus parameters may also be stored in the above-mentioned preset queue in correspondence with the processing parameters. In this way, the processor for consensus processing can obtain the consensus parameters from the preset queue and start a new consensus process based on the consensus parameters; the processor for data processing can obtain the processing parameters from the preset queue and, based on the obtained processing parameters, start data processing of the business data contained in the pre-processing block corresponding to the processing parameters.

For example, suppose the processor obtains a processing parameter and a corresponding consensus parameter from the FIFO queue, and the consensus parameter includes a view number v. In this way, the processor can determine the pre-processing block to be processed corresponding to the view number v from the storage space of the blockchain node itself, and then process the pre-processing block to be processed according to the obtained processing parameter.

Of course, in the embodiment of the present application, the processing parameters may not exist in the preset queue mentioned above. For example, the processing parameters may be stored in the blockchain node's own memory, or in a database corresponding to the blockchain node, or in other locations of the blockchain node. Examples are not given here one by one.

As can be seen from the above method, after the blockchain node determines that the acquired pre-processing block has passed consensus, it uses parallel processing to initiate consensus on the next adjacent pre-processing block to be reached, and then processes the business data contained in the pre-processing block that has passed consensus. In other words, the blockchain node implements parallel processing of business data in the business consensus stage and the business submission stage. It can simultaneously perform data processing in the business submission stage on a portion of business data while simultaneously performing consensus processing in the business consensus stage on another portion of business data. This shortens the time interval between consensus processing in two adjacent business consensus stages, thereby effectively improving the system's business data processing efficiency.

In order to further illustrate the data processing method mentioned in this application, the various processes involved in the data processing method will be briefly described in detail below, as shown in Figure 2.

FIG2 is a schematic diagram of data processing performed by a blockchain node provided in an embodiment of the present application.

During the business acceptance stage, users can send business data to the blockchain node through the client installed in the terminal, and the blockchain node can verify the received business data and store the verified business data in its own corresponding storage space for storage.

During the business consensus phase, blockchain nodes can obtain pre-processed blocks to be agreed upon in this consensus. If the blockchain node is the master node initiating this consensus, it can retrieve a portion of business data from its own storage space and package this data into pre-processed blocks. At this time, the blockchain node will obtain the pre-processed blocks that need to be agreed upon in this consensus. At the same time, the blockchain node needs to broadcast this pre-processed block to other blockchain nodes in the consensus network so that other blockchain nodes can verify the consensus of the pre-processed block.

If the blockchain node is not the master node that initiated this consensus, it can obtain the pre-processed block that needs to be agreed upon in this business consensus from the master node that initiated this consensus, and then perform consensus verification on the pre-processed block.

After determining that the pre-processed block has passed consensus verification, the blockchain node can update the consensus parameters corresponding to the next consensus (i.e., the consensus parameters corresponding to the next pre-processed block to be reached) based on the consensus parameters corresponding to the current consensus (i.e., the consensus parameters corresponding to the pre-processed block), in preparation for the next consensus. Furthermore, the blockchain node can also obtain the processing parameters corresponding to the next consensus (i.e., the processing parameters corresponding to the next pre-processed block to be reached) based on the pre-processed block and the processing parameters corresponding to the current consensus (i.e., the processing parameters corresponding to the pre-processed block that has passed the current consensus), and store the obtained processing parameters corresponding to the next consensus in the FIFO queue.

When a blockchain node obtains the consensus parameters and processing parameters for the next consensus, it can initiate the business consensus phase of the next consensus. This means it can initiate consensus on the pre-processed blocks for the next consensus. During this phase, the blockchain node can use its processor to execute operations in parallel with the business submission phase of the current consensus.

In other words, the blockchain node hands over the operations involved in the business submission phase to the processor to complete, while it can itself perform the next adjacent consensus, thereby achieving parallel processing of the business consensus phase and the business submission phase in one consensus, shortening the time interval between two adjacent consensuses, and thus improving consensus efficiency.

The processor can obtain the processing parameters corresponding to this consensus from the FIFO queue, and then store the pre-processed block that passes this consensus in the form of a block in the blockchain according to the on-chain parameters contained in the processing parameters; the processor can release the business data contained in the pre-processed block from the storage space of the blockchain node itself according to the whether parameter and storage parameter contained in the processing parameters, and store the released business data in the corresponding storage location according to the provisions of the storage parameters; the processor can delete the pre-prepare messages, prepare messages, confirmation messages, etc. generated in the business consensus stage, such as PBFT consensus, according to the deletion parameters contained in the processing attributes, to save the storage space of the blockchain node.

The above is the data processing method provided in the embodiment of the present application. Based on the same idea, the embodiment of the present application also provides a data processing device, as shown in Figure 3.

FIG3 is a schematic diagram of a data processing device provided in an embodiment of the present application, specifically comprising:

An acquisition module 301 acquires a pre-processed block to be consensus-based and performs consensus on the pre-processed block;

Processing module 302, if it is determined that the pre-processing block has passed the consensus, starts consensus on the next pre-processing block to be agreed upon, and concurrently processes the business data contained in the pre-processing block that has passed the consensus.

The processing module 302 processes the business data contained in the pre-processing block that has passed the consensus in parallel through a preset processor.

The processing module 302 performs the following operations for the pre-processing block that has passed consensus: calling a processor to obtain storage parameters, where the storage parameters include a storage location; determining a pre-processing block to be processed corresponding to the storage parameters based on the storage parameters, and storing the business data included in the determined pre-processing block to be processed in the storage location.

After determining that the pre-processed block has passed the consensus, the acquisition module 301 determines the storage parameters of the next consensus pre-processed block based on the pre-processed block and the storage parameters of the pre-processed block, and stores them.

The acquisition module 301 stores the storage parameters of the pre-processing block adjacent to the next consensus in a first-in-first-out (FIFO) queue.

The processing module 302 calls the processor to obtain storage parameters from the FIFO queue.

The acquisition module 301 determines the consensus parameters corresponding to the pre-processing block if it is determined that the pre-processing block has passed the consensus, and obtains the consensus parameters corresponding to the next adjacent pre-processing block to be agreed upon based on the determined consensus parameters corresponding to the pre-processing block. The consensus parameters are used to instruct the blockchain nodes to reach a consensus on the pre-processing block to be agreed upon.

The processing module 302, when obtaining the consensus parameters corresponding to the adjacent pre-processed block to be agreed upon next time, starts consensus on the adjacent pre-processed block to be agreed upon next time based on the obtained consensus parameters.

Based on the same idea, the embodiment of the present application also provides another data processing device, specifically including:

A memory and at least one processor, wherein the memory stores a program and is configured to cause the at least one processor to execute the following steps:

Obtaining a pre-processed block to be consensused, and performing consensus on the pre-processed block;

If it is determined that the pre-processed block has passed the consensus, the consensus process for the next pre-processed block to be reached is initiated, and data processing is performed on the business data contained in the pre-processed block that has passed the consensus in parallel.

The specific operations performed by the processor through the program stored in the memory can refer to the contents recorded in the above embodiments, which will not be repeated here.

In an embodiment of the present application, after determining that the acquired pre-processing block has passed the consensus, the blockchain node can start the consensus on the next pre-processing block to be agreed upon, so as to perform data processing on the business data contained in the pre-processing block that has passed the consensus in a parallel manner. Because the blockchain node adopts a parallel processing method after determining that the acquired pre-processing block has passed the consensus, it starts the consensus on the next pre-processing block to be agreed upon, and processes the business data contained in the pre-processing block that has passed the consensus. In other words, the blockchain node realizes the parallel processing of business data in the business consensus stage and the business submission stage, and can perform data processing in the business submission stage on a part of the business data, and at the same time perform consensus processing in the business consensus stage on another part of the business data. This can shorten the time interval between the consensus processing in the two business consensus stages, thereby effectively improving the business data processing efficiency of the system.

In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD through their own programming, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

For the convenience of description, the above devices are described as being divided into various units according to their functions. Of course, when implementing this application, the functions of each unit can be implemented in the same or multiple software and/or hardware.

It will be understood by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

The present invention is described with reference to the flowcharts and/or block diagrams of the methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and/or box in the flowchart and/or block diagram, as well as the combination of processes and/or boxes in the flowchart and/or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

The present application may 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. The present application may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

The various embodiments in this specification are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the system embodiments are generally similar to the method embodiments, so the description is relatively simple. For relevant parts, refer to the description of the method embodiments.

The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included within the scope of the claims of the present application.

Claims (13)

1. A data processing method, comprising: Blockchain nodes obtain preprocessed blocks to be reached in consensus and reach a consensus on the preprocessed blocks; If the preprocessing block is determined to have passed consensus, then the consensus parameters corresponding to the preprocessing block are determined, and the consensus parameters corresponding to the next preprocessing block to be reached are obtained based on the consensus parameters corresponding to the preprocessing block. Consensus is initiated for the next preprocessing block to be reached based on the consensus parameters corresponding to the preprocessing block to be reached. At the same time, the processing parameters for the preprocessing blocks that have passed consensus are obtained, and the business data contained in the preprocessing blocks that have passed consensus are processed in parallel by a preset processor based on the processing parameters. 2. The method as described in claim 1, wherein the business data contained in the preprocessing block that has passed consensus is processed in parallel by a preset processor, specifically including: For the preprocessing block that has passed consensus, perform the following operations: The processor is invoked to obtain storage parameters, which include the storage location. Based on the storage parameters, a preprocessing block to be processed corresponding to the storage parameters is determined, and the business data contained in the determined preprocessing block to be processed is stored in the storage location. 3. The method according to any one of claims 1 to 2, further comprising: After the preprocessing block passes consensus, the storage parameters of the next adjacent preprocessing block for consensus are determined and stored based on the preprocessing block and its storage parameters. 4. The method as described in claim 3, wherein storing the storage parameters of the preprocessing block for the next consensus iteration specifically includes: The storage parameters of the preprocessed blocks for the next consensus are stored in a first-in-first-out (FIFO) queue. 5. The method as described in claim 4, wherein calling the processor to obtain storage parameters specifically includes: The processor is invoked to retrieve storage parameters from the FIFO queue. 6. The method as described in claim 1, initiating consensus on the next preprocessing block to be reached, comprising: Upon obtaining the consensus parameters corresponding to the next adjacent preprocessing block to be reached, consensus is initiated for the next adjacent preprocessing block to be reached based on the obtained consensus parameters. 7. A data processing apparatus, comprising: The acquisition module acquires the preprocessed block to be consensus-reached and performs consensus-reaching on the preprocessed block; The processing module determines the consensus parameters corresponding to the preprocessing block if it is determined that the preprocessing block has passed consensus. Based on the consensus parameters corresponding to the preprocessing block, it obtains the consensus parameters corresponding to the next preprocessing block to be reached for consensus. Based on the consensus parameters corresponding to the preprocessing block to be reached for consensus, it initiates consensus on the next preprocessing block to be reached for consensus. At the same time, it obtains the processing parameters for the preprocessing blocks that have passed consensus. Based on the processing parameters, the preset processor performs parallel data processing on the business data contained in the preprocessing blocks that have passed consensus. 8. The apparatus of claim 7, wherein the processing module performs the following operations on the preprocessing block that has passed consensus: calling the processor to obtain storage parameters, the storage parameters including a storage location; determining the preprocessing block to be processed corresponding to the storage parameters according to the storage parameters, and storing the business data contained in the determined preprocessing block to be processed in the storage location. 9. The apparatus according to any one of claims 7 to 8, wherein the acquisition module, after determining that the preprocessing block has passed consensus, determines the storage parameters of the next adjacent preprocessing block for consensus based on the preprocessing block and the storage parameters of the preprocessing block, and stores them. 10. The apparatus of claim 9, wherein the acquisition module stores the storage parameters of the preprocessing block of the next consensus in a first-in-first-out (FIFO) queue. 11. The apparatus of claim 10, wherein the processing module calls the processor to obtain storage parameters from the FIFO queue. 12. The apparatus of claim 7, wherein the processing module, upon obtaining the consensus parameters corresponding to the next adjacent preprocessing block to be reached for consensus, initiates consensus processing for the next adjacent preprocessing block to be reached for consensus based on the obtained consensus parameters. 13. A data processing apparatus, comprising: a memory and at least one processor, wherein: the memory stores a program and is configured to be executed by the at least one processor of the following steps: Obtain the preprocessed block to be consensused, and reach a consensus on the preprocessed block; If the preprocessing block is determined to have passed consensus, then the consensus parameters corresponding to the preprocessing block are determined, and the consensus parameters corresponding to the next preprocessing block to be reached are obtained based on the consensus parameters corresponding to the preprocessing block. Consensus is initiated for the next preprocessing block to be reached based on the consensus parameters corresponding to the preprocessing block to be reached. At the same time, the processing parameters for the preprocessing blocks that have passed consensus are obtained, and the business data contained in the preprocessing blocks that have passed consensus are processed in parallel by a preset processor based on the processing parameters.