WO2021042733A1 - Blockchain transaction processing method and apparatus, computer device, and storage medium - Google Patents

Abstract

A blockchain transaction processing method and apparatus, a computer device, and a storage medium. The method comprises: receiving blocks to be processed, and storing said blocks in a block queue, wherein each of said blocks corresponds to one block label (S201); concurrently starting a pre-created standby signature verification thread, performing signature verification on said blocks in the block queue to acquire a signature verification result block, and storing the signature verification result block in a cache (S202); detecting, in real time, whether the cache contains the current expected block, and if the cache contains the current expected block, determining at least one continuous signature verification result block, which takes the current expected block as a starting block, to be a target block (S203); and submitting the target block, and updating the current expected block on the basis of the block label corresponding to the last signature verification result block in the target block (S204). According to the method, the verification efficiency of concurrently starting the standby signature verification thread to perform signature verification on said blocks is improved, saving the processing time for signature verification, and facilitating the reduction of system loss.

Description

Block chain transaction processing method, device, computer equipment and storage medium

This application claims the priority of a Chinese patent application filed with the Chinese Patent Office on September 6, 2019 with the application number 201910843124.9 and the invention title "Blockchain transaction processing methods, devices, computer equipment and storage media", and its entire contents Incorporated in this application by reference.

Technical field

This application relates to the field of blockchain technology, and in particular to a blockchain transaction processing method, device, computer equipment and storage medium.

Background technique

Blockchain is generally understood as a distributed ledger, and its essence is also a distributed database. One of the fundamental differences between the alliance blockchain and the ordinary blockchain is the need to provide a privacy protection mechanism. Normally, the privacy protection mechanism is implemented through signature encryption and signature verification and decryption in cryptography. Usually, multiple transactions are packaged into blocks and sent to the nodes on the blockchain. The node unlocks the block, obtains the transactions in the block, first verifies the signature of each transaction, and then all signatures The verified transactions are verified for multi-version concurrency control as a whole, and finally processed for transaction persistence to write the transaction information to the disk. The inventor realizes that since the verification process of multi-version concurrency control needs to be checked according to the sequence of execution between the blocks, therefore, in the current blockchain transaction processing process, each block needs to be sequentially verified by signatures and multiple blocks. Version concurrency control verification and transaction persistence are processed, and the next block is processed after the processing of one block is completed. Among them, the signature verification is to verify the signature corresponding to the transaction data in the block. The verification process involves a large number of mathematical operations and takes a long time.

In the current blockchain, the serial verification method is mainly used to verify the signature of the block. This verification method makes the subsequent blocks only wait for the previous block to be verified before they can be verified, and the system’s computing resources cannot be fully utilized. This leads to a large waste of system resources, resulting in low blockchain transaction processing performance and low transaction processing efficiency.

Summary of the invention

The embodiments of the application provide a blockchain transaction processing method, device, computer equipment, and storage medium, so as to solve the problem of low processing efficiency when using serial verification to verify the signature of the block in the current blockchain transaction processing. And the problem of large waste of computing resources.

A blockchain transaction processing method, including:

Receiving the to-be-processed blocks, storing the to-be-processed blocks in a block queue, and each of the to-be-processed blocks corresponds to a block label;

Concurrently start a pre-created standby signature verification thread, perform signature verification on the block to be processed in the block queue, obtain a signature verification result block, and store the signature verification result block in a cache;

Real-time detection of whether the current desired block is included in the cache, and if the current desired block is included in the cache, at least one continuous verification result block with the current desired block as the starting block is determined Is the target block;

Submit the target block, and update the current desired block based on the block label corresponding to the last verification result block in the target block.

A blockchain transaction processing device, including:

Receiving the to-be-processed blocks, storing the to-be-processed blocks in a block queue, and each of the to-be-processed blocks corresponds to a block label;

Concurrently start a pre-created standby signature verification thread, perform signature verification on the block to be processed in the block queue, obtain a signature verification result block, and store the signature verification result block in a cache;

Real-time detection of whether the current desired block is included in the cache, and if the current desired block is included in the cache, at least one continuous verification result block with the current desired block as the starting block is determined Is the target block;

Submit the target block, and update the current desired block based on the block label corresponding to the last verification result block in the target block.

A computer device comprising a memory, a processor, and a computer program stored in the memory and capable of running on the processor, and the processor implements the steps of the blockchain transaction processing method when the computer program is executed .

A computer-readable storage medium, which stores a computer program, and when the computer program is executed by a processor, realizes the steps of the blockchain transaction processing method described above.

The above-mentioned blockchain transaction processing method, device, computer equipment and storage medium simultaneously start the pre-created standby verification thread to perform signature verification on the block to be processed in the block queue, and obtain the corresponding verification result block to ensure The verification efficiency of signature verification for all pending blocks in the block queue saves the processing time of signature verification, and the standby verification thread does not need to create and destroy threads, which helps to save system loss. Store all verification result blocks in the cache. When the real-time detection cache contains the current desired block, at least one continuous verification result block with the current desired block as the starting block is determined as the target block and submitted The target block is to ensure that the submitted target block contains at least one consecutive signature verification result block to ensure the execution sequence between the blocks.

Description of the drawings

FIG. 1 is a schematic diagram of an application environment of a blockchain transaction processing method in an embodiment of the present application;

Figure 2 is a flowchart of a blockchain transaction processing method in an embodiment of the present application;

Fig. 3 is another flowchart of a blockchain transaction processing method in an embodiment of the present application;

FIG. 4 is another flowchart of a blockchain transaction processing method in an embodiment of the present application;

FIG. 5 is another flowchart of a blockchain transaction processing method in an embodiment of the present application;

Fig. 6 is another flowchart of a blockchain transaction processing method in an embodiment of the present application;

FIG. 7 is another flowchart of a blockchain transaction processing method in an embodiment of the present application;

FIG. 8 is another flowchart of a blockchain transaction processing method in an embodiment of the present application;

FIG. 9 is a schematic diagram of a blockchain transaction processing method in an embodiment of the present application;

Fig. 10 is a schematic diagram of a computer device in an embodiment of the present application.

detailed description

According to the blockchain transaction processing method provided by the embodiment of the present application, the blockchain transaction processing method can be applied to the application environment as shown in FIG. 1. Specifically, the blockchain transaction processing method is applied to a blockchain system. The blockchain system includes multiple blockchain nodes connected by a blockchain network, and each blockchain node corresponds to a blockchain node Each block chain node device is connected to other block chain node devices through the block chain network, so as to realize the parallel processing of the signature verification process, which is computationally intensive and takes a long time in block chain transaction processing, to improve The efficiency of signature verification and saving processing time will help improve the overall efficiency of the entire blockchain transaction processing. Among them, the blockchain node device is a device that can automatically perform numerical calculation and/or information processing in accordance with pre-set or stored instructions. The blockchain node device can be a computer, a single network server, a server group composed of multiple network servers, or a cloud composed of a large number of hosts or network servers based on cloud computing. Cloud computing is a type of distributed computing. A super virtual computer composed of a group of loosely coupled computer sets.

In one embodiment, as shown in FIG. 2, a blockchain transaction processing method is provided. Taking the method applied to the blockchain node device in FIG. 1 as a server as an example for description, the method includes the following steps:

S201: Receive a block to be processed, and store the block to be processed in a block queue, and each block to be processed corresponds to a block label.

Among them, the block to be processed is the block that needs to be processed sent to the node to be processed on the blockchain. Among them, the node to be processed is a blockchain node on the blockchain network that needs to process data. Each block to be processed includes at least one transaction to be processed, and the transaction to be processed is a transaction that requires subsequent processing. Understandably, the server can obtain the to-be-processed block from the to-be-processed node of the blockchain for subsequent processing of the three links of signature verification, multi-version concurrency control verification, and transaction persistence processing in the to-be-processed block .

The block queue is a pre-created queue in the system for caching the to-be-processed blocks that need to be processed. The block queue can manage all the to-be-processed blocks in the queue in a first-in first-out order.

The block label is the label information corresponding to the block stored in the block to be processed. In this embodiment, the block label corresponding to each block to be processed includes the block serial number (i.e. Number), the current block hash value (i.e. DataHash) and the previous block hash value (i.e. PreviousHash), so as to be based on The current block hash value and the previous block hash value determine the execution order of different blocks to be processed. Among them, the block serial number is a serial number used to uniquely identify a certain block. The current block hash value is a hash pointer value used to point to the current block. The previous block hash value is the hash pointer value used to point to the previous block of the current block. Therefore, the execution sequence between the two blocks to be processed can be determined based on the hash value of the current block and the hash value of the previous block. Understandably, if the block serial number is named according to a specific block serial number naming rule, that is, when the block serial number named according to the block serial number naming rule has a sequence corresponding to the execution order between the blocks, it can be Determine the execution sequence between different blocks to be processed according to the block number.

In this embodiment, each block to be processed includes a block header area (ie, Block Header), a block data area (ie, Block Data), and a metadata area (Metadata). The block header area (i.e. Block Header) is an area used to record block attributes, specifically including the block number (i.e. Number), the previous block hash value (i.e. PreviousHash) and the current block hash value. (Ie DataHash) and other block attributes. The block data area (ie, Block Data) is an area used to record transaction data in the block and signature data corresponding to the transaction data. Understandably, the block data area (i.e., Block Data) of each block to be processed can store transaction data and signature data corresponding to one transaction to be processed, or it can store at least two transaction data and transaction data corresponding to the transaction to be processed. Its signature data. That is to say, each block to be processed includes at least one transaction to be processed, and the transaction data and signature data corresponding to at least one transaction to be processed are sequentially recorded in the block data area (i.e., Block Data), during the process of blockchain transaction processing , It is necessary to perform signature verification on the signature data corresponding to each transaction to be processed in the block data block to ensure the security of the transaction data corresponding to the transaction to be processed. Metadata, also known as intermediary data or relay data, is data describing data (data about data), mainly information describing data properties, used to support such as indicating storage location, historical data, and resource search And file recording and other functions. Metadata can be regarded as an electronic catalog. In order to achieve the purpose of cataloging, it is necessary to describe and collect the content or characteristics of the data, and then achieve the purpose of assisting data retrieval. The block signature recorded in the metadata area (Metadata) can be verified based on the block signature. Among them, the block signature is a digital signature corresponding to the block to be processed. Understandably, the metadata area (Metadata) is also provided with a to-be-filled area for recording the signature verification result, and the to-be-filled area is a blank area before the signature verification of the block to be processed is performed.

S202: Concurrently start the pre-created standby signature verification thread, perform signature verification on the block to be processed in the block queue, obtain the signature verification result block, and store the signature verification result block in the cache.

Among them, the standby verification thread is a thread pre-allocated by the system for signature verification. The standby verification thread performs signature verification when it is working, and enters a sleep state when it is not working. It does not need to create and destroy threads, which is helpful Save system loss. The signature verification algorithm adopted in the standby verification thread matches the signature encryption algorithm used in advance in the transaction to be processed, that is, the decryption algorithm and the encryption algorithm are mutually used to ensure the feasibility of signature verification.

In this embodiment, after detecting that there is a block to be processed in the block queue, the server can concurrently start a pre-created standby verification thread according to the number of blocks to be processed in the block queue. The standby verification thread is used to perform signature verification on each block to be processed in the block queue, and the verification result block corresponding to the pending block is obtained. When the standby verification thread is created in advance, there is no need to wait for the creation of verification. The signature thread can directly process the block to be processed to ensure the verification efficiency of signature verification for all blocks to be processed in the block queue and save the processing time of signature verification. Understandably, according to the first-in-first-out order in the block queue, a corresponding standby verification thread can be assigned to each block to be processed in turn, so that the standby verification thread is used to perform signature verification on the block to be processed. The signature verification process that uses multiple standby verification threads to execute concurrently can make full use of the system's CPU and memory performance, give full play to the advantages of multi-core CPUs, increase the throughput of the entire block processing, reduce processing delays, and improve processing efficiency.

The signature verification result block is the block containing the signature verification result obtained after the block to be processed is verified by the signature. The signature verification result includes two results: the signature is valid and the signature is invalid. After the standby verification thread performs signature verification on at least one pending transaction in each pending block, the signature verification result of each pending transaction is stored in In the metadata area (Metadata) of the block to be processed, the signature verification result is specifically filled in the area to be filled corresponding to the metadata area (Metadata) to form a signature verification result block. That is, the finally formed signature verification result block not only includes all the contents of the block to be processed, but also includes the signature verification result obtained after the signature verification, so as to perform subsequent verification processing based on the signature verification result.

The cache is a space for storing the verification result blocks after signature verification in the server in advance to ensure that there is a sequence between all verification result blocks submitted to the next processing link (that is, the multi-version concurrency control verification link). The order of execution to ensure that the multi-version concurrency control verification link can be executed according to the corresponding execution order, and the overall processing efficiency is improved.

In this embodiment, the server concurrently starts the standby verification thread to perform signature verification on each block to be processed in the block queue to obtain the corresponding verification result block, and store the verification result block in In the cache, multiple standby verification threads can be simultaneously used to perform signature verification on multiple blocks to be processed. No matter which standby verification thread completes the signature verification process first, the corresponding verification result block can be stored In the cache, there is no need to wait for the signature verification of the block to be processed in the first execution order to complete the signature verification of the block to be processed in the subsequent execution order, so that the signature verification process is not affected by the execution order between the blocks to be processed. It is helpful to improve the signature verification efficiency of all pending blocks in the block queue, improve the overall processing efficiency of all pending blocks, make full use of the server's system computing resources, and avoid resource waste. Since the standby verification thread is created in advance, starting the standby verification thread to perform the signature verification process of the block to be processed does not need to wait for the thread to be created, which can further save the time of the signature verification process and improve the efficiency of signature verification.

S203: Detect in real time whether the current desired block is included in the cache, and if the current desired block is included in the cache, at least one consecutive signature verification result block with the current desired block as the starting block is determined as the target block.

Among them, the current desired block refers to a block that can be submitted to the next processing link (that is, the multi-version concurrency control verification link) determined according to the execution sequence of different to-be-processed blocks in the blockchain. The target block refers to a continuous block formed by at least one continuous verification result block with the current expected block as the starting block according to the processing sequence between different blocks to be processed in the blockchain. That is, the target block may include only one verification result block, at this time, the verification result block is the current desired block; it may also include at least two verification result blocks, and at least two verification result areas A block is a continuous verification result block with the current desired block as the starting block, and at least one continuous verification result block containing the current desired block after the signature verification is completed is determined as the target block. The target block is submitted to the next processing link (i.e. multi-version concurrency control verification link), so that the next processing link (i.e. multi-version concurrency control verification link) contains the verification result area contained in all target blocks received The blocks are sorted according to their execution order, so that they are executed in order, which improves the processing efficiency of the next processing link (that is, the multi-version concurrency control verification link).

In this embodiment, the block header area (i.e. Block Header) of each verification result block is recorded with the block serial number (i.e. Number) and the previous block hash value ( That is, PreviousHash) and the current block hash value (ie, DataHash). Since the next processing link (i.e., multi-version concurrency control verification link), the sequence of all submitted verification result blocks must be guaranteed, and the order of all verification result blocks can be determined by the block sequence number. It can be determined based on the hash pointers between different pointers, specifically based on the sequence of the previous block's hash value and the current block's hash value. Therefore, it is possible to detect whether the newly stored signature verification result block in the cache is the current expected block in real time. If the latest signature verification result block is the current expected block, it can be based on all the signature verification results stored in the cache The block number or hash pointer value of the block (including the hash value of the previous block and the hash value of the current block) will be determined by at least one verification result block that is continuous with the current expected block as the starting block It is a target block that can be submitted to the next processing link. In this embodiment, the sliding window technology can be used to determine the current desired block and all consecutive verification result blocks as the target block, that is, the sliding window is used to determine at least one continuous verification with the current desired block as the starting block. Check the result block to determine the target block.

In this embodiment, it is detected in real time whether the current desired block is contained in the cache, and if the current desired block is contained in the cache, at least one continuous verification result block with the current desired block as the starting block is determined as the target area Block in order to subsequently submit the target block as a whole to the next processing link, so that the next processing link processes all the verification result blocks in sequence. Correspondingly, if the current expected block is not contained in the cache, all verification result blocks are sorted according to the current block hash value or block serial number of all verification result blocks in the cache, so that all verification result blocks are sorted. The result block is stored in the cache according to the current block hash value or the sequence of the block serial number, so as to ensure the efficiency of subsequent determination of the target block.

S204: Submit the target block, and update the current desired block based on the block label corresponding to the last verification result block in the target block.

Specifically, the server determines at least one consecutive signature verification result block with the current desired block as the starting block as the target block, and submits the target block to the next processing link. After the submission is successful, the target block is not Stored in the cache, other verification result blocks that are not continuous with the target block are still stored in the cache. Understandably, when the target block is submitted to the next processing link, the current desired block in the cache needs to be updated in real time, so that when the cache receives a new verification result block, the steps S203 and S204 can be executed smoothly. step.

In this embodiment, when the target block is submitted to the next processing link, the current desired block needs to be updated based on the block label corresponding to the last verification result block in the target block. Since the target block is a continuous block formed by at least one continuous verification result block, and the last verification result block in the target block is the end block, the next block after the end block is the update The current desired block of, so as to repeat step S203 and step S204 based on the updated current desired block.

In the blockchain transaction processing method provided in this embodiment, the pre-created standby verification thread is concurrently started to perform signature verification on the block to be processed in the block queue, and the corresponding verification result block is obtained to ensure the block The verification efficiency of signature verification for all pending blocks in the queue saves the processing time of signature verification, and the standby verification thread does not need to create and destroy threads, which helps to save system loss. Store all verification result blocks in the cache. When the real-time detection cache contains the current desired block, at least one continuous verification result block with the current desired block as the starting block is determined as the target block and submitted The target block is to ensure that the submitted target block contains at least one consecutive signature verification result block to ensure the execution sequence between the blocks.

In one embodiment, as shown in FIG. 3, the real-time detection of whether the current desired block is contained in the cache in step S203 specifically includes the following steps:

S301: Detect the block label corresponding to the verification result block in the cache in real time, and determine whether the block label matches the block guide information recorded in the cache in real time.

Specifically, the server may use a cache monitoring program to monitor whether there is incremental data change in the cache, so as to detect in real time whether the cache receives a new verification result block. That is, if the cache monitoring program monitors that there is an incremental change in the data in the cache, it means that the cache has received the newly stored signature verification result block, and it needs to detect in real time whether the newly stored signature verification result structure is the current desired block.

In this embodiment, when the server detects that the cache receives the newly stored signature verification result block, it parses the signature verification result block to obtain the signature verification result block corresponding to the signature verification result block from the block header area of the signature verification result block. The block label of the block label can include the block serial number, and can also include the current block hash value and the previous block hash value.

S302: If the block label matches the block guide information, the signature verification result block corresponding to the block label is the current expected block.

Among them, the block guide information is information used to guide the determination of the current desired block corresponding to the cache. The block guide information can be stored in a sliding window, an array or other forms, so that when a new verification result block is detected to be added to the cache, the block label of the new verification result block and the block guide information are used Matching is performed to determine whether the new verification result block is the current expected block.

The block guide information can be the desired block serial number, which is the block serial number corresponding to the current desired block, and the desired block serial number can correspond to the last verification result block in the newly submitted target block The ending block sequence number is the next block sequence number determined by processing the ending block sequence number using the block sequence number naming rule. Among them, the last verification result block in the newly submitted target block can be understood as the end block in the target block, and the end block sequence number is the block sequence number in the end block. The block sequence number naming rule is a naming rule used to assign unique block sequence numbers to different blocks in a certain event. The block sequence numbers determined by naming according to the block sequence number naming rule are sequential, so that according to the block The naming determines whether at least two verification result blocks are consecutive blocks. Correspondingly, by detecting whether the block sequence number of the newly stored signature verification result block in the cache is the expected block sequence number, it can be detected in real time whether the current expected block is contained in the cache. That is, if the block sequence number of the newly stored verification result block is the same as the expected block sequence number, the verification result block is the current expected block; if the block sequence number of the newly stored verification result block is the same as the expected area If the sequence numbers of the blocks are not the same, the verification result block is not the current expected block.

The block guide information can also be the expected block pointer value, and the expected block pointer value can be the current block hash value corresponding to the last verification result block in the newly submitted target block, that is, the expected block pointer The value is the current block hash value of the ending block. Correspondingly, it is possible to check whether the previous block hash value of the newly stored verification result block in the cache is the same as the expected block pointer value; if the same, the verification result block is the current expected block; if not If it is the same, the verification result block is not the current expected block.

For example, when the block label of the verification result block is the hash value of the previous block, and the block guide information is the expected block pointer value, the expected block pointer value is specifically the last submitted target block The current block hash value of the last verification result block. The specific process of real-time detection of whether the current desired block is contained in the cache includes the following steps: (1) First determine whether the verification result block pointed to by the hash value of the previous block is a system configuration block, and the system configuration block Refers to the block pre-configured by the system administrator to record information such as event information of an event and information of both parties to the transaction. Generally speaking, the system configuration block is the first current desired block corresponding to an event. Directly submitted as the target block to the next processing link. (2) If the signature verification result block pointed to by the hash value of the previous block is a system configuration block, then the signature verification result block is the current desired block, so that it can be submitted to the next block based on the current desired block. The target block of the processing link. (3) If the verification result block pointed to by the hash value of the previous block is not a system configuration block, it is determined whether the hash value of the previous block matches the expected block pointer value; if it matches, then The verification result block is the current expected block; if it does not match, the verification result block is not the current expected block. Since the target block submitted each time contains at least one continuous verification result block with the current expected block in the cache as the starting block, the current area of the last verification result block in the target block The block hash value can indicate the next current expected block after the target block submitted this time.

For example, if there are 10 pending blocks that need to be processed in the block queue, and their block numbers are 1-10, 10 standby verification threads can be started concurrently to process the 10 pending blocks separately. To obtain the corresponding verification result blocks respectively, and store the verification result blocks in the cache, suppose the order of the completion of the processing of the 10 blocks to be processed is 6, 8, 2, 3, 4, 5, 1 ,7,9,10, and before the system starts to process the 10 blocks to be processed, the block guide information in the cache can be determined using the expected block number, which is set to 1. Specifically, when the cache receives the first verification result block, its block sequence number is 6. Since its block sequence number is not the expected block sequence number (ie 1), the block sequence number is 6 in the verification result area The block is not the current expected block, save it in the cache. When the cache receives the second verification result block, its block sequence number is 8. Since its block sequence number is not the expected block sequence number (ie 1), the verification result block with the block sequence number 6 is not The current expected block is sorted according to the block sequence numbers corresponding to all the verification result blocks in the cache, so that the verification result block No. 6 is stored in front of the verification result block No. 8... and so on, the cache is cached in the receiving To the seventh verification result block, when the block sequence number is 1, since its block sequence number is the current expected sequence number (ie 1), the verification result block with the block sequence number 1 is the current expected sequence number, then All consecutive verification result blocks starting with the first verification result block are regarded as a target block, that is, the first, second, third, fourth, fifth and sixth verification result blocks will be checked in sequence. The signature result block is determined to be a target block. Since the signature verification result block No. 8 and the signature verification result block No. 6 in the cache are not continuous, the signature verification result block No. 8 is not determined as one of the target blocks. Check result block. At this time, the signature verification result block No. 6 is the end block in the target block. After submitting the target block formed by the verification result blocks 1 to 6 to the next processing link, the current desired block needs to be updated based on the block label corresponding to the last verification result block in the target block. That is, based on the block label corresponding to the block No. 6 verification result (such as the block number or the current block hash value), the block guide information corresponding to the new current desired block in the cache is updated, that is, the new current block in the cache is updated. The desired block serial number corresponding to the desired block, and the desired block serial number is specifically the next block serial number after the end block serial number, that is, the 7th serial number. Understandably, after submitting the target block formed by the signature verification result block No. 1-6, the newly determined expected block sequence number is 7; when the cache receives the eighth verification result block, because of its block The serial number is 7, which is the same as the expected block serial number, so the 7th verification result block is the current desired block, based on the 7th verification result block in the cache and its consecutive verification result blocks (that is, the 8th verification result block) Result block) form a new target block and submit it to the next processing link...and so on to submit all verification result blocks to the next processing link.

In the blockchain transaction processing method provided in this embodiment, the block label of the verification result block in the cache is detected in real time, and a certain verification result area can be quickly determined according to whether the block label and the block guidance information match. Whether the block is the current desired block, in order to improve the efficiency of determining the current desired block, thereby helping to improve the overall processing efficiency of the event.

In an embodiment, if the number of standby verification threads created by the system in advance is too small, it may not be able to ensure that the efficiency of the signature verification processing is maximized, and system resources may be wasted; if the number of standby verification threads is too large, It may affect the efficiency of the system in processing other tasks besides signature verification. Therefore, it is necessary to balance the pre-created standby verification threads. As shown in FIG. 4, before step S201, that is, before receiving the block to be processed and storing the block to be processed in the block queue, the blockchain transaction processing method further includes the following steps:

S401: Obtain the number of cores of the blockchain system.

Among them, the number of cores of the blockchain system is specifically the number of cores of the CPU (Central Processing Unit, central processing unit) in the server, that is, the number of processors. In this embodiment, the process of obtaining the number of cores of the blockchain system is based on the prior art. For example, the user can view the number of processors corresponding to the number of cores of the blockchain system in the task manager, or it can be executed in sequence. Start menu" -> "Run" -> "Enter cmd" -> "Enter wmic" -> "Enter cpu get" These operations get the number of cores of each server in the blockchain system.

S402: Determine the target number based on the number of cores and the target ratio range, and create a signature verification thread pool. The signature verification thread pool includes standby verification threads corresponding to the target number.

The target ratio range is a preset ratio range, which can be 1.5-3 times. The target number is specifically the product of the number of cores and the target ratio range. Generally speaking, when the target number is twice the number of cores, that is, when the target ratio range is 2, the cost of thread switching in the CPU of the blockchain system is less, which is more conducive to reducing the loss of the signature verification system.

In the blockchain transaction processing method provided in this embodiment, after the target number is determined based on the number of cores and the target ratio range, a signature verification thread pool is created on the server of the blockchain system, and the signature verification thread pool includes the target number The corresponding standby verification thread is used to subsequently use the standby verification thread corresponding to the target number to perform signature verification on the pending block in the block queue that needs to be processed. The standby verification thread performs signature verification when it is working, and enters a dormant state when it is not working, without thread creation and destruction, which reduces CPU usage and helps reduce system loss. The number of standby verification threads in the verification thread pool matches the target number, which can maximize the processing efficiency of signature verification, avoid waste of system resources, and avoid excessive numbers that affect other tasks except signature verification. Processing efficiency.

In one embodiment, as shown in FIG. 5, in step S202, concurrently starting the pre-created standby verification thread includes the following steps:

S501: Monitor the number of blocks corresponding to the blocks to be processed in the block queue in real time.

Specifically, a counter is provided on the server, and the counter is used to monitor the number of blocks corresponding to the blocks to be processed in the block queue in real time. For example, if a newly added block to be processed is added to the block queue, the counter is increased by 1. ; If a block to be processed in the block queue is allocated to the standby verification thread for signature verification processing, the counter is reduced by 1, so as to realize the real-time monitoring of the number of blocks to be processed in the block queue through the counter.

S502: If the number of blocks is greater than zero, a wake-up instruction is triggered, and based on the wake-up instruction, the standby verification thread in the dormant state in the verification thread pool is concurrently awakened, and the pending block in the block queue is allocated to the corresponding standby verification Sign thread.

Among them, the wake-up instruction is an instruction used to wake up the standby verification thread in the dormant state. Specifically, if the number of blocks is greater than zero, it means that there are pending blocks that need to be processed in the block queue. At this time, the server triggers a standby verification thread that matches the number of blocks in the verification thread pool. The system thread is used to allocate the to-be-processed block in the block queue to the corresponding signature verification thread for signature verification processing.

For example, if the number of blocks is greater than zero, the triggered wake-up instruction can wake up all the standby verification threads in the dormant state in the verification thread pool, and determine the corresponding standby verification threads according to the CPU scheduling situation. The block to be processed is allocated to the corresponding standby verification thread, and the other standby verification threads enter the dormant state again. For another example, if the number of blocks is greater than zero, the triggered wake-up instruction can randomly wake up the standby signature verification thread in the dormant state, and allocate the pending block in the block queue to the corresponding standby signature verification thread.

In this embodiment, based on the wake-up instruction, concurrently waking the standby verification threads in the dormant state in the signature verification thread pool, specifically refers to: comparing the number of blocks with the number of threads in the dormant state in the verification thread pool. ; If the number of blocks is less than or equal to the number of threads, based on the wake-up instruction, wake up the standby verification thread that matches the number of blocks; if the number of blocks is greater than the number of threads, wake up the standby that matches the number of threads based on the wake-up instruction The signature verification thread wakes up all the standby verification threads that are in the dormant state. Understandably, based on the comparison result of the number of blocks and the number of threads, the number of standby verification threads that need to be awakened is determined, so as to realize the unified management of the standby verification threads.

Further, if the number of blocks is greater than zero, and there is no standby verification thread in the dormant state in the verification thread pool, the working status of each standby verification thread is monitored in real time, and the block is processed in any standby verification thread Perform signature verification, obtain the verification result block, and store the verification result block in the cache, then determine the standby verification thread as an idle wake-up thread to send the pending block in the block queue to the corresponding Idle wake up thread. Among them, the idle wake-up thread refers to the standby verification thread waiting to receive a new block to be processed for processing within a preset time after the end of the working state; if a new block to be processed is received within the preset time, Then the idle wake-up thread enters the working state again; if no new block to be processed is received within the preset time, the idle wake-up thread enters the sleep state. Understandably, the standby verification thread is determined to be an idle wake-up thread, which can be placed in waiting to receive a new block to be processed within a preset time, avoiding directly entering the sleep state and requiring additional wake-up operations, which helps to reduce system overhead .

In the blockchain transaction processing method provided in this embodiment, a wake-up instruction is triggered based on the number of blocks corresponding to the blocks to be processed in the block queue to wake up the standby verification threads in the dormant state in the verification thread pool, and The block to be processed is allocated to the corresponding standby verification thread, which can make the standby verification thread in the dormant state enter the working state. To process the processing block, only the thread wake-up operation is required, and the thread creation and destruction are not required. To reduce the CPU usage and reduce system consumption.

In one embodiment, as shown in FIG. 6, step S201, which is to receive a block to be processed, and store the block to be processed in a block queue, includes:

S601: Receive a block to be processed, perform a legality check on the block to be processed, and obtain a legality check result.

Among them, the legality check refers to the process of checking whether the received block to be processed is a block sent by a legal blockchain node. Specifically, after receiving the block to be processed, the server performs legality verification on the block signature recorded in the metadata area of the block to be processed, and if the signature verification is passed, the legality verification result that has passed the verification is obtained; if If the signature verification fails, the legality verification result that the verification fails is obtained. Understandably, each legal blockchain node in the blockchain system will record its own digital signature in the metadata area of each block to be processed, and this digital signature is the The block signature of the block to be processed. After receiving each block to be processed, the server obtains the block signature from the metadata area, and then uses the signature verification method corresponding to the signature encryption algorithm corresponding to the digital signature to perform legality verification, and obtain the legality verification result.

S602: If the result of the validity check is that the check is passed, store the block to be processed in the block queue.

Specifically, if the received legality check result of the block to be processed is that the check is passed, the block to be processed is stored in the block queue, so that the standby verification thread is used to subsequently check the pending block in the block queue. Process the block for signature verification; if the received legality check result of the block to be processed is that the check fails, then the block to be processed is directly discarded to avoid subsequent pending processing that fails the legality check Block processing, so as to avoid the waste of system resources, in order to achieve the purpose of reducing system loss.

In the blockchain transaction processing method provided in this embodiment, by performing a legality check on each received block to be processed, only the block to be processed whose legality check result is verified is stored in In the block queue, to avoid adding the to-be-processed block whose legality check result is not passed into the block queue for subsequent processing, so as to avoid the waste of system resources and achieve the purpose of reducing system loss.

In one embodiment, because there is a specific execution sequence between different blocks to be processed, the transaction processing of the blockchain needs to be performed according to the execution sequence; and each block to be processed contains at least one block to be processed Transaction, if there are a large number of pending transactions in any pending block, the waiting time for the signature verification thread to process the pending block is longer, and the execution order is the other after the pending block It takes a long time for the block to be processed to form the target block and submit it to the next processing link, which affects the processing efficiency of the entire blockchain event processing process. As shown in Figure 7, step S202, which is to perform signature verification on the block to be processed in the block queue, to obtain the verification result block, includes the following steps:

S701: Detect the number of transactions corresponding to all transactions to be processed in each block to be processed.

Wherein, the number of transactions refers to the number of all transactions to be processed in the block to be processed, and specifically refers to the number corresponding to all transaction data recorded in the block data area of the block to be processed. Understandably, each transaction data recorded in the block data area corresponds to a pending transaction.

S702: If the number of transactions is greater than the preset number threshold, the number of sub-threads is determined according to the number of transactions, and an auxiliary signature verification sub-thread matching the number of sub-threads is created.

Among them, the preset number threshold is a preset threshold used to evaluate whether the number of transactions reaches a standard recognized as a larger threshold. Specifically, if the number of transactions corresponding to all pending transactions in any to-be-processed block is greater than the preset number threshold, it means that the number of transactions corresponding to pending transactions in the to-be-processed block is too large. If only the standby verification thread is used Processing may result in too long processing time. Therefore, an auxiliary signature verification sub-thread needs to be created to process the pending transactions in the processing block. Among them, the auxiliary signature verification sub-thread is a thread created by the system to assist the standby signature verification thread to process a block to be processed with a large number of transactions, and is destroyed after the block to be processed is processed.

In this embodiment, the number of sub-threads is determined according to the number of transactions, and creating an auxiliary signature verification sub-thread matching the number of sub-threads specifically includes: rounding down the quotient of the number of transactions and a preset number threshold to obtain the number of sub-threads, And create an auxiliary sign verification sub-thread that matches the number of sub-threads. That is, the number of child threads can be determined using the following formula:

Among them, N is the auxiliary signature verification sub-thread, A is the number of transactions, and B is the preset number threshold.

S703: Use the standby signature verification thread and the auxiliary signature verification subthread to perform signature verification on the transaction to be processed, and obtain a signature verification result.

Specifically, the server uses the standby verification thread and the auxiliary verification sub-thread matching the number of sub-threads to perform concurrent signature verification on all pending transactions in the pending block, so as to quickly obtain the correspondence of all pending transactions in the pending block. The result of signature verification to improve the efficiency of signature verification of the block to be processed with more transactions to be processed. That is, in this embodiment, N+1 threads may be used to perform signature verification on all pending transactions in a pending block, and the corresponding signature verification results may be quickly obtained.

S704: Store the signature verification result in the metadata area of the block to be processed, obtain the signature verification result block, release the standby signature verification thread, and destroy the auxiliary signature verification subthread.

Specifically, the server stores the signature verification results corresponding to all pending transactions in the metadata area of the pending block to form a verification result block containing the signature verification result, which can ensure the efficiency of obtaining the verification result block. After obtaining the signature verification result block, the standby signature verification thread needs to be released so that the standby signature verification thread can process other pending blocks. After the standby signature verification thread is released, the standby signature verification thread will be used within a preset time. The thread is an idle wake-up thread; if a new block to be processed is received within the preset time, the idle wake-up thread re-enters the working state; if a new block to be processed is not received within the preset time, it is idle Wake up the thread to enter the sleep state. Since the auxiliary signature verification sub-thread is temporarily created by the system to assist the standby verification thread to process the block to be processed with a large number of transactions, after the processing of the pending block is completed, the auxiliary signature verification sub-thread needs to be destroyed. Avoid too many threads in the system to affect the processing efficiency of each thread.

In the blockchain transaction processing method provided in this embodiment, when the number of transactions of all pending transactions in the block to be processed is greater than a preset number threshold, an auxiliary signature verification subthread and a standby verification subthread are created concurrently for these pending transactions Perform signature verification processing to improve the signature verification efficiency of the block to be processed, thereby ensuring the overall processing efficiency. After the signature verification is completed and the verification result block is obtained, the standby verification thread needs to be released and the auxiliary verification subthread is destroyed, which can effectively save system losses and ensure system processing efficiency.

In one embodiment, as shown in FIG. 8, after step S204, that is, after submitting the target block, the blockchain transaction processing method further includes the following steps:

S801: In the process of multi-version concurrency control verification, sequentially identify the signature verification result of each verification result block in the target block.

Among them, the multiple version concurrent control (MVCC) verification process is mainly used to verify whether the transaction state when the transaction (that is, the transaction corresponding to the verification result block) is submitted is the current state when the transaction is generated process. In the process of multi-version concurrency control verification, sequentially identify the signature verification results recorded in the metadata area of each verification result block in the target block to determine whether the corresponding signature verification result is valid or invalid . Understandably, due to the multi-version concurrency control verification process, the check result corresponding to any verification result block depends on the previous verification result block, that is, the previous verification result block may modify the current state of the system. It will affect the validity judgment of the subsequent verification result blocks, that is, the order of the verification result blocks may cause the final state of the entire blockchain to be inconsistent. Therefore, each verification result in the target block needs to be sequentially checked. The signature verification result of the block is identified.

S802: If the signature verification result is that the signature is valid, the transaction status corresponding to the signature verification result block is compared with the current state, and the transaction status is consistent with the current state, then an operation is performed on the signature verification result block to obtain valid transaction data.

Specifically, when the signature verification result corresponding to the verification result block is the signature valid, the transaction state corresponding to the verification result block is compared with the current state, and if the transaction state is consistent with the current state, the verification result block is compared Perform an execution operation to perform an operation on the verification result block to obtain valid transaction data; if the transaction status is inconsistent with the current state, the transaction data corresponding to the verification result block is determined to be invalid transaction data. Among them, the transaction state corresponding to the verification result block refers to the state recorded by the transaction data in the verification result block; the current state corresponding to the verification result block refers to the system corresponding to the transaction data in the verification result block status.

For example, if A finds that the account balance of the bank card is 100 yuan at time T0, a transaction of 100 yuan transferred to B is submitted at time T1 after a period of time after checking the account balance to form the first transaction data, that is, the system The transaction will be received and processed at time T1. If A's friend C uses the secondary card of the bank card or online banking and other other methods to swipe 100 yuan in other places during the period from A's checking of the account balance to the submission of the transaction, that is, T0-T1, then A at this time The submitted transfer transaction of 100 yuan will fail because the transaction status (account balance is 100 yuan, the transfer transaction can be executed) when the transaction is generated, and the current state before the transaction is executed by the system (the account balance is 0 yuan) makes the transaction status Inconsistent with the current status, the transaction data corresponding to this 100 yuan transfer transaction is directly determined as invalid transaction data. Correspondingly, if in the period from A’s checking of the account balance to the submission of the transaction, that is, within T0-T1, no one else uses the secondary card of the bank card or online banking to conduct transactions in other places, then the transaction occurred when the transaction occurred. If the transaction status (account balance is 100 yuan) and the current status before the transaction is executed (account balance is 100 yuan), if the two are consistent, the transaction data corresponding to this 100 yuan transfer transaction is determined as valid transaction data. Understandably, whether the transaction status corresponding to the verification result block is consistent with the current status mainly depends on the time difference in the transaction process.

S803: If the signature verification result is that the signature is invalid, the transaction data corresponding to the signature verification result block is determined to be invalid transaction data.

Specifically, when the signature verification result corresponding to the verification result block is that the signature is invalid, the transaction data corresponding to the verification result block is directly determined as invalid transaction data, without the need to perform subsequent operations of verifying the transaction state and the current state. It helps to reduce the process of multi-version concurrency control verification and improve processing efficiency.

S804: Perform transaction persistence processing based on valid transaction data and invalid transaction data.

Among them, transaction persistence is also called transaction commit (Commit) refers to the process of committing transaction data obtained after signature verification and multi-version concurrency control verification in a block, and writing it to disk. Generally speaking, in the process of transaction persistence, if the transaction data corresponding to a verification result block is valid transaction data, the corresponding current state in the blockchain is modified based on the valid transaction data; if a verification result is If the transaction data corresponding to the block is invalid transaction data, the invalid transaction data will not be adopted. Therefore, there is no need to modify the current state in the blockchain and perform transaction persistence processing on invalid transaction data to facilitate traceability.

In the blockchain transaction processing method provided in this embodiment, in the multi-version concurrency control verification process, the signature verification results of each verification result block in the target block are sequentially identified, so that the execution order is first The verification result block is verified first, and the verification result block with the subsequent execution sequence is verified later, so that the verification of the verification result block with the subsequent execution sequence can rely on the verification result block with the previous execution sequence The verification results are changed. The valid transaction data and invalid transaction data determined by the multi-version concurrency control verification process can be subjected to transaction persistence processing to ensure the security of these valid transaction data and invalid transaction data and avoid tampering.

It should be understood that the size of the sequence number of each step in the foregoing embodiment does not mean the order of execution. The execution sequence of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application.

In one embodiment, a blockchain transaction processing device is provided, and the blockchain transaction processing device corresponds to the blockchain transaction processing method in the above-mentioned embodiment one-to-one. As shown in FIG. 9, the blockchain transaction processing device includes a block receiving module 901 to be processed, a signature verification processing module 902, a target block determination module 903, and a target block submission module 904. The detailed description of each functional module is as follows:

The to-be-processed block receiving module 901 is configured to receive the to-be-processed blocks and store the to-be-processed blocks in a block queue, and each to-be-processed block corresponds to a block label.

The signature verification processing module 902 is configured to concurrently start a pre-created standby verification thread, perform signature verification on the block to be processed in the block queue, obtain the verification result block, and store the verification result block in the cache.

The target block determination module 903 is used for real-time detection of whether the current desired block is contained in the cache, and if the current desired block is contained in the cache, at least one continuous verification result block with the current desired block as the starting block will be used Determined as the target block.

The target block submission module 904 is used to submit the target block and update the current desired block based on the block label corresponding to the last verification result block in the target block.

Preferably, the target block determining module 903 includes:

The block label matching processing unit is used to detect the block label corresponding to the verification result block in the cache in real time, and determine whether the block label matches the block guide information recorded in the cache in real time.

The current desired block determining unit is configured to, if the block label matches the block guide information, the verification result block corresponding to the block label is the current desired block.

Preferably, before the to-be-processed block receiving module 901, the blockchain transaction processing device further includes:

The number of cores determining unit is used to obtain the number of cores of the blockchain system.

The verification thread creation unit is used to determine the target number based on the number of cores and the target ratio range, and create a verification thread pool. The verification thread pool includes the standby verification threads corresponding to the target number.

Preferably, the signature verification processing module 902 includes:

The block quantity monitoring unit is used for real-time monitoring of the block quantity corresponding to the to-be-processed block in the block queue.

The thread wakeup allocation unit is used to trigger a wake-up instruction if the number of blocks is greater than zero. Based on the wake-up instruction, it concurrently wakes up the standby verification threads in the verification thread pool and allocates the pending blocks in the block queue Give the corresponding standby verification thread.

Preferably, the block receiving module 901 to be processed includes:

The legality check unit is used to receive the block to be processed, perform legality check on the block to be processed, and obtain the legality check result.

The block storage unit is used to store the to-be-processed block in the block queue if the result of the legality check is passed.

Preferably, the signature verification processing module 902 includes:

The transaction quantity detection unit is used to detect the transaction quantity corresponding to all pending transactions in each pending block.

The auxiliary thread creation unit is used to determine the number of child threads according to the number of transactions if the number of transactions is greater than the preset number threshold, and create an auxiliary sign verification child thread that matches the number of child threads.

The signature verification processing unit is used to use the standby verification thread and the auxiliary verification sub-thread to perform signature verification on the transaction to be processed, and obtain the signature verification result.

The signature verification result block acquisition unit is used to store the signature verification result in the metadata area of the block to be processed, obtain the signature verification result block, release the standby signature verification thread and destroy the auxiliary signature verification subthread.

Preferably, after the target block submission module 904, the blockchain transaction processing device further includes:

The signature verification result identification unit is used to sequentially identify the signature verification result of each verification result block in the target block in the multi-version concurrency control verification process.

The valid transaction data determining unit is used to compare the transaction state corresponding to the verification result block with the current state if the signature verification result is valid, and the transaction state is consistent with the current state, then perform operations on the verification result block To obtain valid transaction data.

The invalid transaction data determining unit is configured to determine the transaction data corresponding to the verification result block as invalid transaction data if the signature verification result is that the signature is invalid.

The transaction persistence processing unit is used to perform transaction persistence processing based on valid transaction data and invalid transaction data.

For the specific limitation of the blockchain transaction processing device, please refer to the above limitation on the blockchain transaction processing method, which will not be repeated here. Each module in the above-mentioned blockchain transaction processing device can be implemented in whole or in part by software, hardware, and a combination thereof. The above-mentioned modules may be embedded in the form of hardware or independent of the processor in the computer equipment, or may be stored in the memory of the computer equipment in the form of software, so that the processor can call and execute the operations corresponding to the above-mentioned modules.

In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. 10. The computer equipment includes a processor, a memory, a network interface, and a database connected through a system bus. Among them, the processor of the computer device is used to provide calculation and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database of the computer device is used to execute the data adopted or formed in the process of the blockchain transaction processing method in the foregoing embodiment. The network interface of the computer device is used to communicate with an external terminal through a network connection. The computer program is executed by the processor to realize a blockchain transaction processing method.

In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored on the memory and capable of running on the processor. The processor executes the blockchain transaction processing in the above embodiment when the processor executes the computer program. The steps of the method, such as steps S201-S204 shown in FIG. 2, or the steps shown in FIG. 3 to FIG. 8, are not repeated here to avoid repetition. Or, when the processor executes the computer program, the function of each module/unit in the embodiment of the blockchain transaction processing device is realized, for example, the block receiving module 901, the signature verification processing module 902, and the target area shown in FIG. 9 The functions of the block determination module 903 and the target block submission module 904 are not repeated here in order to avoid repetition.

In one embodiment, a computer-readable storage medium is provided, and a computer program is stored on the computer-readable storage medium. When the computer program is executed by a processor, it realizes the steps of the blockchain transaction processing method in the above-mentioned embodiment, as shown in FIG. Steps S201-S204 shown in 2 or the steps shown in FIG. 3 to FIG. 8 are not repeated here in order to avoid repetition. Or, when the computer program is executed by the processor, the function of each module/unit in the embodiment of the blockchain transaction processing device is realized, for example, the to-be-processed block receiving module 901 and the signature verification processing module 902 shown in FIG. 9 The functions of the target block determining module 903 and the target block submitting module 904 are not repeated here in order to avoid repetition.

A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer readable storage. In the medium, it can also be stored in a volatile storage medium. When the computer program is executed, it may include the processes of the above-mentioned method embodiments. Wherein, any reference to memory, storage, database or other media used in the embodiments provided in this application may include non-volatile and/or volatile memory. Non-volatile memory may include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. As an illustration and not a limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous chain Channel (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

Claims (20)

1. A blockchain transaction processing method, including:

   Receiving the to-be-processed blocks, storing the to-be-processed blocks in a block queue, and each of the to-be-processed blocks corresponds to a block label;

   Concurrently start a pre-created standby signature verification thread, perform signature verification on the block to be processed in the block queue, obtain a signature verification result block, and store the signature verification result block in a cache;

   Real-time detection of whether the current desired block is included in the cache, and if the current desired block is included in the cache, at least one continuous verification result block with the current desired block as the starting block is determined Is the target block;

   Submit the target block, and update the current desired block based on the block label corresponding to the last verification result block in the target block.
2. The blockchain transaction processing method of claim 1, wherein the real-time detection of whether the current desired block is contained in the cache includes:

   Real-time detection of the block label corresponding to the verification result block in the cache, and determining whether the block label matches the block guide information recorded in the cache in real time;

   If the block label matches the block guide information, the verification result block corresponding to the block label is the current expected block.
3. The blockchain transaction processing method according to claim 1, before the receiving the block to be processed and storing the block to be processed in the block queue, the block chain transaction processing method further comprises:

   Get the number of cores of the blockchain system;

   Based on the number of cores and the target ratio range, the target number is determined, and a signature verification thread pool is created. The signature verification thread pool includes a standby verification thread corresponding to the target number.
4. The blockchain transaction processing method according to claim 1, wherein said concurrently starting a pre-created standby verification thread comprises:

   Real-time monitoring of the number of blocks corresponding to the blocks to be processed in the block queue;

   If the number of blocks is greater than zero, a wake-up instruction is triggered, and based on the wake-up instruction, the standby verification thread in the dormant state in the verification thread pool is concurrently awakened, and the pending block in the block queue Assigned to the corresponding standby verification thread.
5. The blockchain transaction processing method of claim 1, wherein the receiving the block to be processed and storing the block to be processed in a block queue comprises:

   Receiving a block to be processed, performing a legality check on the block to be processed, and obtaining a legality check result;

   If the result of the legality check is that the check is passed, the block to be processed is stored in the block queue.
6. 5. The blockchain transaction processing method according to claim 1, wherein said performing signature verification on said block to be processed in said block queue to obtain a signature verification result block comprises:

   Detecting the number of transactions corresponding to all pending transactions in each of the pending blocks;

   If the number of transactions is greater than the preset number threshold, the number of sub-threads is determined according to the number of transactions, and an auxiliary signature verification sub-thread that matches the number of sub-threads is created;

   Using the standby signature verification thread and the auxiliary signature verification subthread to perform signature verification on the pending transaction, and obtain a signature verification result;

   The signature verification result is stored in the metadata area of the block to be processed, the signature verification result block is obtained, the standby signature verification thread is released, and the auxiliary signature verification subthread is destroyed.
7. The blockchain transaction processing method according to claim 1, after the submission of the target block, the blockchain transaction processing method further comprises:

   In the process of multi-version concurrency control verification, sequentially identify the signature verification result of each verification result block in the target block;

   If the signature verification result is that the signature is valid, the transaction state corresponding to the verification result block is compared with the current state, and the transaction state is consistent with the current state, then the verification result block is performed Perform operations to obtain valid transaction data;

   If the signature verification result is that the signature is invalid, the transaction data corresponding to the signature verification result block is determined to be invalid transaction data;

   Perform transaction persistence processing based on the valid transaction data and the invalid transaction data.
8. A blockchain transaction processing device, including:

   The block to be processed receiving module is used to receive the block to be processed, and store the block to be processed in a block queue, and each block to be processed corresponds to a block label;

   The signature verification processing module is used to concurrently start a pre-created standby verification thread, perform signature verification on the to-be-processed block in the block queue, obtain the verification result block, and transfer the verification result block Store in the cache;

   The target block determination module is used to detect in real time whether the current desired block is included in the cache, and if the current desired block is included in the cache, the current desired block will be a continuous starting block. At least one verification result block is determined as the target block;

   The target block submission module is configured to submit the target block and update the current desired block based on the block label corresponding to the last verification result block in the target block.
9. A computer device includes a memory, a processor, and a computer program stored in the memory and capable of running on the processor. The processor implements a blockchain transaction processing method when the processor executes the computer program: receiving waiting Processing blocks, storing the blocks to be processed in a block queue, and each block to be processed corresponds to a block label;

   Concurrently start a pre-created standby signature verification thread, perform signature verification on the block to be processed in the block queue, obtain a signature verification result block, and store the signature verification result block in a cache;

   Real-time detection of whether the current desired block is included in the cache, and if the current desired block is included in the cache, at least one continuous verification result block with the current desired block as the starting block is determined Is the target block;

   Submit the target block, and update the current desired block based on the block label corresponding to the last verification result block in the target block.
10. The computer device according to claim 9, wherein the real-time detection of whether the current desired block is contained in the cache includes:

    Real-time detection of the block label corresponding to the verification result block in the cache, and determining whether the block label matches the block guide information recorded in the cache in real time;

    If the block label matches the block guide information, the verification result block corresponding to the block label is the current expected block.
11. The computer device according to claim 9, before the receiving the block to be processed and storing the block to be processed in the block queue, the blockchain transaction processing method further comprises:

    Get the number of cores of the blockchain system;

    Based on the number of cores and the target ratio range, the target number is determined, and a signature verification thread pool is created. The signature verification thread pool includes a standby verification thread corresponding to the target number.
12. 8. The computer device according to claim 9, wherein said concurrently starting a pre-created standby signature verification thread comprises:

    Real-time monitoring of the number of blocks corresponding to the blocks to be processed in the block queue;

    If the number of blocks is greater than zero, a wake-up instruction is triggered, and based on the wake-up instruction, the standby verification thread in the dormant state in the verification thread pool is concurrently awakened, and the pending block in the block queue Assigned to the corresponding standby verification thread.
13. The computer device according to claim 9, wherein said receiving the block to be processed and storing the block to be processed in a block queue comprises:

    Receiving a block to be processed, performing a legality check on the block to be processed, and obtaining a legality check result;

    If the result of the legality check is that the check is passed, the block to be processed is stored in the block queue.
14. The computer device according to claim 9, wherein said performing signature verification on said block to be processed in said block queue to obtain a signature verification result block comprises:

    Detecting the number of transactions corresponding to all pending transactions in each of the pending blocks;

    If the number of transactions is greater than the preset number threshold, the number of sub-threads is determined according to the number of transactions, and an auxiliary signature verification sub-thread that matches the number of sub-threads is created;

    Using the standby signature verification thread and the auxiliary signature verification subthread to perform signature verification on the pending transaction, and obtain a signature verification result;

    The signature verification result is stored in the metadata area of the block to be processed, the signature verification result block is obtained, the standby signature verification thread is released, and the auxiliary signature verification subthread is destroyed.
15. The computer device according to claim 9, after the submission of the target block, the blockchain transaction processing method further comprises:

    In the process of multi-version concurrency control verification, sequentially identify the signature verification result of each verification result block in the target block;

    If the signature verification result is that the signature is valid, the transaction state corresponding to the verification result block is compared with the current state, and the transaction state is consistent with the current state, then the verification result block is performed Perform operations to obtain valid transaction data;

    If the signature verification result is that the signature is invalid, the transaction data corresponding to the signature verification result block is determined to be invalid transaction data;

    Perform transaction persistence processing based on the valid transaction data and the invalid transaction data.
16. A computer-readable storage medium, the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of a blockchain transaction processing method are realized:

    Receiving the to-be-processed blocks, storing the to-be-processed blocks in a block queue, and each of the to-be-processed blocks corresponds to a block label;

    Concurrently start a pre-created standby signature verification thread, perform signature verification on the block to be processed in the block queue, obtain a signature verification result block, and store the signature verification result block in a cache;

    Real-time detection of whether the current desired block is included in the cache, and if the current desired block is included in the cache, at least one continuous verification result block with the current desired block as the starting block is determined Is the target block;

    Submit the target block, and update the current desired block based on the block label corresponding to the last verification result block in the target block.
17. The computer-readable storage medium according to claim 16, wherein the real-time detection of whether the current desired block is contained in the cache includes:

    Real-time detection of the block label corresponding to the verification result block in the cache, and determining whether the block label matches the block guide information recorded in the cache in real time;

    If the block label matches the block guide information, the verification result block corresponding to the block label is the current expected block.
18. The computer-readable storage medium according to claim 16, before the receiving the block to be processed and storing the block to be processed in a block queue, the blockchain transaction processing method further comprises:

    Get the number of cores of the blockchain system;

    Based on the number of cores and the target ratio range, the target number is determined, and a signature verification thread pool is created. The signature verification thread pool includes a standby verification thread corresponding to the target number.
19. 15. The computer-readable storage medium according to claim 16, wherein the concurrently starting a pre-created standby verification thread comprises:

    Real-time monitoring of the number of blocks corresponding to the blocks to be processed in the block queue;

    If the number of blocks is greater than zero, a wake-up instruction is triggered, and based on the wake-up instruction, the standby verification thread in the dormant state in the verification thread pool is concurrently awakened, and the pending block in the block queue Assigned to the corresponding standby verification thread.
20. The computer-readable storage medium according to claim 16, wherein said receiving the block to be processed and storing the block to be processed in a block queue comprises:

    Receiving a block to be processed, performing a legality check on the block to be processed, and obtaining a legality check result;

    If the result of the legality check is that the check is passed, the block to be processed is stored in the block queue.

Images