HK1241594B - Service check method and device - Google Patents

Description

A method and device for business verification

Technical Field

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

Background Art

Blockchain technology is also known as distributed ledger technology. The data stored in the blockchain has the characteristics of being tamper-proof and decentralized. Therefore, blockchain technology provides people with a more secure data storage environment and provides more convenience for people's data storage.

Currently, when a blockchain node receives a business request sent by a terminal, it will store the business request in its own business memory. At the same time, the blockchain node will also broadcast the business request to other blockchain nodes in the entire consensus network, so that other blockchain nodes will store the business request in their corresponding business memory after receiving the business request.

Then, the blockchain node will retrieve a set number of business requests from its own business storage, package these business requests into pre-processed blocks and broadcast them to other blockchain nodes in the entire consensus network for consensus to determine whether these business requests need to be stored in the blockchain in the form of blocks.

In actual applications, when a blockchain node in a consortium chain broadcasts a received service request to other blockchain nodes, due to factors such as network failures, some other blockchain nodes in the entire consensus network may not receive the service request broadcast by the blockchain node. In other words, compared to the service requests stored in the service memory of a blockchain node itself, the service memory of other blockchain nodes may be missing some service requests. Blockchain nodes that are missing some service requests will, to a certain extent, have a significant impact on the consensus verification results of the entire consensus network.

For example, suppose there are three blockchain nodes A, B, and C in the entire consensus network, among which blockchain node A stores five business requests #1, #2, #3, #4, and #5, blockchain node B stores four business requests #1, #2, #3, and #4, and blockchain node C stores three business requests #1, #2, and #3. Among them, each business request is stored in the business storage corresponding to each blockchain node. When blockchain node A packages the five business requests #1, #2, #3, #4, and #5 into a pre-processing block and broadcasts it to the other two blockchain nodes for consensus verification of these five business requests, since blockchain nodes B and C are both missing some of the business requests that contain these five business requests, blockchain nodes B and C will directly determine that the pre-processing block containing these five business requests has failed the consensus verification. In this way, since more than half of the blockchain nodes in the entire consensus network determine that the consensus verification of the pre-processing block has failed, the five business requests contained in the pre-processing block will not be able to pass the consensus verification of the entire consensus network, and then these five business requests will not be able to be recorded in the blockchain in the entire consensus network.

Since the reason why the other blockchain nodes determine that the pre-processing block fails the consensus verification is not because some business requests in the pre-processing block are illegally tampered with, but simply because some business requests in the pre-processing block are not stored in the business storage corresponding to the other blockchain nodes themselves, the probability that the pre-processing block will fail to pass the consensus verification of the entire consensus network will be greatly increased. In fact, the business requests contained in the pre-processing block may not have any problems themselves. This makes it very likely that normal business requests will fail to pass the consensus verification of each blockchain node in the existing technology, thereby affecting the business processing accuracy of the entire blockchain business.

Summary of the Invention

The embodiments of the present application provide a method for business verification to solve the problem of low business processing accuracy of blockchain business in the prior art.

This embodiment of the present application provides a service verification method, including:

The first blockchain node receives a service request sent by the terminal;

Storing the service request in a service memory corresponding to the first blockchain node, and broadcasting the service request to each second blockchain node, so that each second blockchain node stores the service request in its corresponding service memory;

At least one business request is retrieved from the business memory, and the retrieved at least one business request is packaged into a pre-processing block and broadcast to each second blockchain node, so that when each second blockchain node determines that its corresponding business memory does not contain some business requests in the pre-processing block, it obtains the part of the business requests from other blockchain nodes, and performs consensus verification on the pre-processing block through the part of the business requests and the business requests stored in its own business memory.

The embodiments of the present application provide a business verification device to solve the problem of low business processing accuracy of blockchain business in the prior art.

The present invention provides a device for verifying a service, including:

Receiving module, receiving service requests sent by the terminal;

a storage module, storing the service request in a service memory corresponding to the device, and broadcasting the service request to each second blockchain node, so that each second blockchain node stores the service request in its corresponding service memory;

The request retrieval module retrieves at least one business request from the business memory, and packages the retrieved at least one business request into a pre-processing block and broadcasts it to each second blockchain node, so that when each second blockchain node determines that its corresponding business memory does not contain some business requests in the pre-processing block, it obtains the part of the business requests from other blockchain nodes, and performs consensus verification on the pre-processing block through the part of the business requests and the business requests stored in its own business memory.

The embodiments of the present application provide a method for business verification to solve the problem of low business processing accuracy of blockchain business in the prior art.

This embodiment of the present application provides a service verification method, including:

The second blockchain node receives the service request broadcast by the first blockchain node;

Storing the service request in a service memory corresponding to the second blockchain node;

receiving a pre-processing block containing at least one service request broadcasted by the first blockchain node, and obtaining the part of the service request from other blockchain nodes when determining that the service memory corresponding to the first blockchain node does not contain part of the service request in the pre-processing block;

The pre-processing block is subjected to consensus verification through the partial business requests and the business requests stored in the corresponding business memory.

The embodiments of the present application provide a business verification device to solve the problem of low business processing accuracy of blockchain business in the prior art.

The present invention provides a device for verifying a service, including:

A request receiving module receives a service request broadcasted by the first blockchain node;

a request storage module, storing the service request in a service memory corresponding to the device;

a receiving module configured to receive a pre-processing block including at least one service request broadcast by the first blockchain node, and obtain the service request from other blockchain nodes when determining that the service memory corresponding to the receiving module does not include some service requests in the pre-processing block;

The verification module performs consensus verification on the pre-processing block through the partial business requests and the business requests stored in its own corresponding business memory.

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

In an embodiment of the present application, after receiving the pre-processing block containing various business requests broadcast by the first blockchain node, when the second blockchain node finds that its corresponding business memory does not contain some of the business requests in the pre-processing block, it does not directly determine that the pre-processing block fails the consensus verification on the second blockchain node. Instead, it can obtain this part of the missing business requests from other blockchain nodes in the entire consensus network, and perform consensus verification on the business requests contained in the pre-processing block through the obtained part of the business requests and the business requests stored in its own business memory. In this way, the occurrence of adverse effects on the consensus verification of various business requests due to network failures is greatly reduced, thereby improving the business processing accuracy of the entire blockchain business.

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 service efficiency process provided by an embodiment of the present application;

FIG2 is a schematic diagram of each blockchain node storing received service requests in its corresponding service memory through a preset distributed middleware according to an embodiment of the present application;

FIG3 is a schematic diagram of determining a total eigenvalue to be verified according to an embodiment of the present application;

FIG4 is a schematic diagram of a consensus network according to an embodiment of the present application performing consensus on a pre-processed block sent by a first blockchain node;

FIG5 is a schematic diagram of a service verification device provided in an embodiment of the present application;

FIG6 is a schematic diagram of another service verification device provided in an embodiment of the present application.

DETAILED DESCRIPTION

Currently, the process of business processing by blockchain nodes is roughly as follows: after the terminal sends a business request to the blockchain node, the blockchain node will send the received business request to other blockchain nodes in the form of a broadcast. Other blockchain nodes will store the received business request in their corresponding business storage. Of course, the blockchain node that sends the business request to other blockchain nodes will also store the business request in its own business storage.

In a consensus network composed of blockchain nodes, each blockchain node has the right to initiate consensus requests to other blockchain nodes. The blockchain node can arrange a set number of business requests stored in its own business memory in a certain order to obtain a business request queue and generate a hash value for the business request queue. Then, the blockchain node can package the business request queue and the hash into a pre-processing block and send the pre-processing block to other blockchain nodes in the form of broadcast for consensus verification.

During the consensus verification process, when other blockchain nodes receive the pre-processing block, they will perform asymmetric signature legal verification on each business request contained in the pre-processing block. That is, the blockchain node can parse each business request contained in the pre-processing block based on the public key (or private key, whether the public key or private key depends on whether the private key or public key is used when encrypting each business request) it holds to verify whether each business request is a legal business request.

In addition, since each time a blockchain node receives a service request from a terminal, it broadcasts the service request to other blockchain nodes. Therefore, under normal circumstances, each blockchain node's corresponding service memory should store all service requests received by the entire consensus network. Based on this, after receiving the pre-processing block, other blockchain nodes will perform hash integrity verification on each service request in the pre-processing block. That is, the blockchain node can find each service request contained in the pre-processing block from its own service memory, and arrange the found service requests in the order in which they are arranged in the pre-processing block to obtain a service request queue. The blockchain node can then generate a hash value for the service request queue, and then compare the obtained hash value with the hash value contained in the pre-processing block to confirm whether the content of each service request in the pre-processing block has been illegally tampered with.

Each blockchain node will obtain its own verification result on whether the pre-processed block is legal as a whole based on the asymmetric signature legality verification and hash integrity verification of the pre-processed block, and broadcast its own verification result to other blockchain nodes in the form of broadcast.

Each blockchain node will obtain a comprehensive verification result of whether the pre-processed block has passed by each blockchain node in the entire consensus network based on the verification results sent by other blockchain nodes for the pre-processed block and its own verification results, and broadcast the obtained comprehensive verification result to other blockchain nodes again in the form of broadcast.

After receiving the mutually broadcasted comprehensive verification results, each blockchain node in the consensus network will further determine whether most of the comprehensive verification results obtained by each blockchain node in the consensus network have passed the verification. If so, each business request in the pre-processing block will be stored in its own blockchain in the form of a block. If not, each business request in the pre-processing block will be rejected.

After each blockchain node stores each business request in the preprocessing block in its own blockchain in the form of a block, it can release each business request contained in the preprocessing block from its own business memory so that the released business memory can continue to store each business request received by the blockchain node.

However, in the prior art, when a blockchain node broadcasts a received business request to other blockchain nodes, due to factors such as network failure, some other blockchain nodes may not receive the business request broadcast by the blockchain node. This causes the subsequent blockchain node to broadcast a pre-processing block containing a set number of business requests to each blockchain node for consensus verification. As a result, some blockchain nodes will directly determine that the pre-processing block has failed the consensus verification in the local blockchain node due to the lack of some business requests in the pre-processing block in their corresponding business memory, thereby greatly increasing the probability that the pre-processing block will fail the consensus verification of the entire consensus network, thereby affecting the business processing accuracy of the entire blockchain business.

Not only that, in actual applications, if the business request fails to pass the consensus verification of the entire consensus network, the blockchain node will return a message to the user terminal indicating that the business request processing failed. Therefore, the occurrence of the above situation will also bring great inconvenience to the user itself.

In order to effectively solve the above problems, in the present application, after receiving the pre-processing block containing various business requests broadcast by the first blockchain node, the second blockchain node finds that its corresponding business memory does not contain some of the business requests in the pre-processing block. In this way, the second blockchain node can obtain these missing business requests from other blockchain nodes in the entire consensus network, and perform consensus verification on each business request contained in the pre-processing block through the obtained business requests and the business requests stored in its own business memory. This greatly reduces the occurrence of adverse effects on the consensus verification of each business request due to network failure, thereby improving the business processing accuracy of the entire blockchain business.

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 a service efficiency process provided by an embodiment of the present application, which specifically includes the following steps:

S101: The first blockchain node receives a service request sent by a terminal.

In an embodiment of the present application, during the business processing process, the user can fill in the corresponding business processing content on the user terminal held by the user, and the terminal will generate a corresponding business request based on the business processing content filled in by the user, and send the business request to the first blockchain node in the entire consensus network. Among them, the terminal mentioned here can be a device such as a computer, a smart phone, etc. Of course, the user can also send a business request to the first blockchain node through the client installed in the terminal, that is, the user fills in the corresponding business processing content in the interface displayed on the terminal in the client, and the client generates a corresponding business request based on the business processing content filled in by the user in the interface, and then sends the business request to the first blockchain node through the terminal.

It should be noted that, in actual applications, the entire consensus network includes multiple blockchain nodes, and the first blockchain node mentioned in the embodiment of the present application refers to the blockchain node that receives the terminal service request, and the other blockchain nodes other than the first blockchain node can be referred to as the second blockchain node in the embodiment of the present application. The first blockchain node and the second blockchain node are relative concepts, that is, the blockchain node that receives the service request from the terminal is the first blockchain node, and the blockchain node that receives the service request sent by the first blockchain node via broadcast is called the second blockchain node. Since each blockchain node in the consensus network can receive the service request sent by the terminal, each blockchain node can actually be the first blockchain node or the second blockchain node, and the division of the first blockchain node and the second blockchain node depends on where the service request is received.

Of course, during the consensus verification process, the division of the first blockchain node and the second blockchain node can also be distinguished by which node initiates the consensus verification, that is, the consensus verification initiator that broadcasts the pre-processed block containing at least one business request to the entire consensus network can be the first blockchain node, and the blockchain node that receives the pre-processed block can be called the second blockchain node.

S102: Storing the business request in a business memory corresponding to the first blockchain node, and broadcasting the business request to each second blockchain node, so that each second blockchain node stores the business request in its corresponding business memory.

During the consensus verification process, the first blockchain node needs to retrieve a portion of business requests from its corresponding business memory, and package these portion of business requests into a pre-processing block and broadcast it to each second blockchain node in the entire consensus network. After each second blockchain node receives the pre-processing block containing this portion of business requests, it needs to verify this portion of business requests in the pre-processing block based on the consensus of each business request matching this portion of business requests contained in its corresponding business memory, and each business request matching this portion of business requests contained in the business memory corresponding to the second blockchain node itself needs to be obtained through the first blockchain node.

Based on this, in an embodiment of the present application, after receiving the business request sent by the terminal, the first blockchain node can store the business request in its own corresponding business memory. At the same time, the first blockchain node can send the business request to each second blockchain node in the entire consensus network in the form of a broadcast, so that each second blockchain node will store the business request in its own corresponding business memory respectively.

In the prior art, a first blockchain node typically stores received service requests in its own cache. Specifically, the service memory in the prior art is the blockchain node's cache. However, due to the limited storage space of the cache, when the cache is full, the first blockchain node cannot continue to receive service requests from the terminal. The node can only use the storage space occupied by the service requests in the cache to continue storing service requests from the terminal after the service requests pass the consensus verification of all blockchain nodes in the consensus network. Therefore, in the prior art, the cache storage space significantly limits the efficiency of blockchain service processing.

To effectively address the issues arising from the prior art, in an embodiment of the present application, blockchain node operators can set up separate business memories in the form of databases for each blockchain node. That is, each blockchain node can correspond to a business memory in the form of a database. In other words, the business memory mentioned in the embodiment of the present application is a database for storing business requests. In this way, when a first blockchain node receives a business request sent by a terminal, it can store the business request in the business memory corresponding to the first blockchain node, and in the subsequent process, perform a consensus check on the business request stored in the business memory.

Since the storage space of the business memory in the form of a database is much larger than the storage space of the cache, when the first blockchain node performs consensus verification on some business requests in the business memory through the entire consensus network, the first blockchain node can still continue to receive business requests sent by the terminal, that is, there is no need to use the storage space occupied by some business requests that have passed the consensus verification to receive business requests sent by the terminal. Compared with the existing technology, the first blockchain node greatly meets the demand for the continuous increase in business volume of the blockchain business and improves the business processing efficiency of the blockchain business.

Furthermore, in the prior art, since each blockchain node in the entire consensus network stores each service request in its own cache (i.e., the service memory in the prior art is the cache), when a blockchain node experiences a failure such as downtime, the service requests stored in its own cache will also disappear. In the embodiments of the present application, each service request is stored in the service memory in the form of a database corresponding to the blockchain node. Therefore, even if a blockchain node experiences a failure such as downtime, the service requests stored in the service memory in the form of a database will not disappear, thereby further ensuring the security of each service request.

In an embodiment of the present application, data transmission can be achieved between each blockchain node and each business memory in the entire consensus network through a preset distributed middleware. That is, after the first blockchain node receives the business request sent by the terminal, it can send the business request to the distributed middleware. The distributed middleware can send the business request to the business memory corresponding to the first blockchain node for storage based on the node identifier of the first blockchain node. Similarly, after the second blockchain node receives the business request broadcast by the first blockchain node, it can send the business request to the distributed middleware. The distributed middleware can also send the business request to the business memory corresponding to the second blockchain node for storage based on the node identifier of the second blockchain node, as shown in Figure 2.

Figure 2 is a schematic diagram of each blockchain node provided by an embodiment of the present application storing received business requests in its own corresponding business memory through a preset distributed middleware.

Taking transaction business as an example, when a user needs to transfer money, he can select the transfer object and enter the transfer amount in the terminal he holds. The terminal will generate a corresponding transaction request based on the user's input and send this transaction request to the first blockchain node.

After the first blockchain node receives the transaction request (i.e., business request) sent by the terminal, it can send the transaction request to the preset distributed middleware, so that the preset distributed middleware can store the transaction request in the business memory corresponding to the first blockchain node according to the node identifier of the first blockchain node.

Then, when the first blockchain node receives the transaction request, it can send the transaction request in the form of a broadcast to other blockchain nodes in the entire consensus network, that is, each second blockchain node. After receiving the transaction request, each second blockchain node can also send the transaction request to the preset distributed middleware, so that the preset distributed middleware can store the transaction request in the business storage corresponding to each second blockchain node according to the node identifier of each second blockchain node.

It should be noted that when the second blockchain node receives the service request sent by the first blockchain node, it can also broadcast the service request to other blockchain nodes in the entire consensus network. The purpose of this is that for a normal and legitimate service request, the entire consensus network actually hopes that the service request can pass the consensus verification of each blockchain node. Therefore, the entire consensus network actually hopes that the service request can exist in the service storage corresponding to each blockchain node before the consensus verification.

However, in actual applications, network communications between blockchain nodes often experience problems such as network disconnection and network jitter. If the service request is only broadcast by the first blockchain node, and other blockchain nodes (i.e., the second blockchain nodes) do not broadcast the service request again, then when the network communication between the first blockchain node and one or some second blockchain nodes fails, these second blockchain nodes will not be able to receive the service request, thereby affecting the consensus verification of the service request in the subsequent process.

To minimize the occurrence of this situation, in an embodiment of the present application, after receiving the service request sent by the first blockchain node, the second blockchain node can broadcast the service request to other blockchain nodes in the entire consensus network. When other blockchain nodes receive the service request, they can first determine whether they have received the service request before. If so, they will ignore the service request. If not, they can store the service request in their corresponding service memory through the preset distributed middleware.

For example, in Figure 2, when a network communication failure occurs between the first blockchain node and the second blockchain node 3, the second blockchain node 3 can still receive the transaction request through the second blockchain node 2 and the second blockchain node 4. This ensures that when the transaction request is a normal and legal transaction request, the transaction request will be stored in the business storage of each blockchain node in the entire consensus network as much as possible.

In an embodiment of the present application, when storing the business request, the first blockchain node may first determine the business type corresponding to the business request, and sort the business request with the previously received business requests according to the preset priority order of each business type.

The purpose of this is that in actual applications, different businesses require different processing delays. For example, for transaction businesses, such businesses usually have higher requirements for business processing delays, that is, they hope that the entire consensus network can quickly complete the processing of the business. For public welfare businesses, such businesses have relatively low requirements for business processing delays, that is, even if the entire consensus network processes the business after a long time, it will not have a major impact on the business.

Based on this, in an embodiment of the present application, when the first blockchain node stores the service request in the service memory corresponding to the first blockchain node, the service request may be sorted in the service memory according to the priority order of each service, thereby generating a service queue containing the service request. In this service queue, service requests with higher latency requirements are placed relatively early, while service requests with lower latency requirements are placed relatively late. The specific sorting method is determined by the priority order of each service type preset by the operation and maintenance personnel.

It should be noted that in this embodiment of the present application, in addition to determining the order of service requests in the service queue based on the priority of each service type, the first blockchain node may also comprehensively determine the order of service requests in the service memory based on the storage time of the service requests in the service memory. In other words, if a service request in the service memory has been stored in the service memory for an excessively long time, even if the latency requirement for the service request is relatively low, the service request may be promoted to the front of the entire service queue.

S103: Retrieve at least one business request from the business memory, and package the at least one business request into a pre-processing block and broadcast it to each second blockchain node, so that when each second blockchain node determines that its corresponding business memory does not contain some business requests in the pre-processing block, it obtains the part of the business requests from other blockchain nodes, and performs consensus verification on the pre-processing block through the part of the business requests and the business requests stored in its own business memory.

In this embodiment of the present application, the first blockchain node needs to reach consensus on the service request stored in its corresponding service memory through the entire consensus network to complete the processing of the service request. To this end, the first blockchain node can retrieve at least one service request from its corresponding service memory and, in the subsequent process, reach consensus on these service requests through the entire consensus network.

Among them, the first blockchain node can retrieve each business request in the business memory whose business type is higher than the set priority. For example, the first blockchain node can use a certain business type as a boundary and retrieve each business request whose business type priority is above the business type from the business memory.

Of course, the first blockchain node can also retrieve a set number of business requests from the business memory. For example, when the storage form of each business request in the business memory is stored in the form of the above-mentioned business queue, the first blockchain node can retrieve a set number of business requests from the business queue. Furthermore, if the set number is represented by N, the first blockchain node can retrieve the first N business requests from the business queue.

In addition to retrieving business requests based on a set number of requests, the first blockchain node may also retrieve business requests based on other criteria. For example, the first blockchain node may retrieve business requests that have been stored in the business memory for longer than a set period of time. Alternatively, when the first blockchain node reaches consensus on the business requests through the entire consensus network, it may select a business and retrieve the business requests corresponding to that business from the business memory. The first blockchain node may select the business randomly or in a certain order. Of course, the first blockchain node may also retrieve business requests based on other criteria, which will not be discussed in detail here.

After the first blockchain node retrieves a set number of business requests, it can determine the sub-feature values corresponding to each business request through a preset feature value determination rule. For example, when the preset feature value determination rule is a Hash algorithm, the first blockchain node can determine the sub-Hash values corresponding to each business request. When the preset feature value determination rule is the Message Digest Algorithm (MD5), the first blockchain node can determine the sub-MD5 values corresponding to each business request.

After the first blockchain node determines the sub-feature values corresponding to each business request, it can determine the unique feature value to be verified corresponding to each business request based on the determined feature values and the arrangement order of each business request in the business memory.

The feature value to be verified uniquely corresponds to each service request as a whole. That is, when the content of a service request in each service request changes, the feature value to be verified will also change. The method for the first blockchain node to determine the feature value to be verified is shown in Figure 3.

FIG3 is a schematic diagram of determining a characteristic value to be verified provided in an embodiment of the present application.

In Figure 3, the first blockchain node uses a hash algorithm to determine the characteristic value. Assume that the first blockchain node retrieves a set number of four business requests from its corresponding business memory. The order of these four business requests in the business queue is shown in Figure 3. After the first blockchain node determines the four hash values corresponding to these four business requests, it can place these four hash values on the four leaf nodes of the Merkle tree from left to right according to the order of these four business requests in the business queue. This is used to determine the non-leaf nodes and the root node of the Merkle tree. The first blockchain node can then determine the root node Hash7 of the Merkle tree as the unique characteristic value to be verified corresponding to these four business requests.

It should be noted that the method for determining the characteristic value to be verified described above is not unique. The first blockchain node may also adopt other methods. It only needs to ensure that the characteristic value to be verified uniquely corresponds to each business request in a certain order.

After determining the unique characteristic value to be verified corresponding to each business request (i.e., at least one business request retrieved from the business memory), the first blockchain node can package the characteristic value to be verified and each business request into a preprocessing block, wherein the preprocessing block includes each business request and the characteristic value to be verified. At the same time, the business requests are arranged in the preprocessing block according to the arrangement order of the business requests in the business memory.

The first blockchain node can send the determined pre-processing block to other blockchain nodes (i.e., each second blockchain node) in the entire consensus network in the form of a broadcast, and then reach a consensus on the business requests contained in the pre-processing block through the entire consensus network, as shown in Figure 4.

Figure 4 is a schematic diagram of the consensus network provided in an embodiment of the present application performing consensus on the pre-processed block sent by the first blockchain node.

In Figure 4, the first blockchain node can broadcast the pre-processing block to each second blockchain node in the entire consensus network. For each second blockchain node, when receiving the pre-processing block sent by the first blockchain node, the second blockchain node can parse the pre-processing block to determine the business requests contained in the pre-processing block and the above-mentioned feature values to be verified.

Then, for each second blockchain node, after parsing each business request from the preprocessing block, the second blockchain node needs to perform asymmetric signature legal verification on each parsed business request to verify whether these business requests are all legal business requests.

Specifically, since when a terminal sends a service request to a blockchain node, it usually uses its own private key (of course, it can also be a public key) to encrypt (or sign) the service request, when the second blockchain node performs asymmetric signature legal verification on each service request contained in the above-mentioned preprocessing block, it needs to use the public key (or when the terminal encrypts with the public key, the second blockchain node decrypts the service request with its own private key) to parse the service request and verify the parsed content.

For example, when the second blockchain node performs asymmetric signature verification on a transaction request (i.e., a business request) in the pre-processing block, it can decrypt the transaction request using its own public key to obtain the account addresses of the two parties involved in the transaction request, thereby verifying whether the account addresses of the two parties are legitimate. If it is determined that the account addresses of the two parties involved in the transaction request are both legitimate accounts, and the amount in the account of the transaction initiator is greater than or equal to the transfer amount involved in the transaction request, then the transaction request is determined to have passed the asymmetric signature verification. Otherwise, the transaction request is determined to have failed the asymmetric signature verification.

When the second blockchain node determines that all business requests contained in the above-mentioned preprocessing block have passed the legal verification of the asymmetric signature, it can further determine the sub-feature values corresponding to these business requests through the preset feature value determination rules, wherein the feature value determination regulations adopted by the second blockchain node are the same as those of the first blockchain node.

After the second blockchain node determines the sub-feature values corresponding to each business request, it can determine a unique feature value corresponding to each business request as a whole based on the arrangement order of each business request in the preprocessing block and the sub-feature values, and then compare the feature value with the feature value to be verified in the preprocessing block. When these two feature values are the same, it can be determined that the content of these business requests that the first blockchain node wants to reach consensus on has not changed, that is, it is determined that these business requests have passed the hash integrity verification.

After each second blockchain node performs asymmetric signature legal verification and hash integrity verification on the pre-processing block according to the above method, it can obtain its own local verification results for the pre-processing block (wherein, only when each business request in the pre-processing block passes the asymmetric signature legal verification and hash integrity verification, the local verification result of the pre-processing block will be passed, otherwise as long as one verification fails, the local verification result of the pre-processing block will be failed). Subsequently, each second blockchain node can send its own verification results in the form of broadcast to other blockchain nodes in the entire consensus network to enter the consensus verification process of the entire consensus network. After each blockchain node in the entire consensus network receives the mutually broadcasted verification results, it can obtain the comprehensive verification result of whether each blockchain node in the entire consensus network has passed the verification for each business request contained in the pre-processing block through the received verification results and its own verification results, and broadcast the obtained comprehensive verification result to other blockchain nodes in the entire consensus network again.

After receiving the mutually broadcasted comprehensive verification results, each blockchain node in the entire consensus network can further determine whether most of the comprehensive verification results obtained by each blockchain node in the entire consensus network have passed the verification. If so, the business requests contained in the pre-processing block are written into a block for storage, and the block is further written into the blockchain saved by itself in time sequence; if not, the business requests are rejected.

The consensus verification process of the entire consensus network described above is only a rough consensus verification process. In the embodiment of the present application, the process of consensus verification of a set number of business requests by the entire consensus network will also involve more complex consensus algorithms, such as Practical Byzantine Fault Tolerance (PBFT), Raft, Paxos, etc. The process involving the consensus algorithm in the embodiment of the present application is the same as that in the prior art, and will not be described in detail here.

After the blockchain node (the blockchain node mentioned here can be either the first blockchain node or the second blockchain node) stores the business requests in the form of blocks in the blockchain, the storage space occupied by these business requests in their respective business memories can be released, and these business requests can be transferred to a database for storing historical business requests.

It should be noted that although each second blockchain node will rebroadcast the business request broadcast by the first blockchain node, due to the influence of network conditions, some blockchain nodes in the entire consensus network may still not be able to effectively receive the business request. Therefore, during the consensus stage, when a second blockchain node does not find some of the business requests in the above-mentioned pre-processing block from its corresponding business storage, the second blockchain node can send an inquiry message to other blockchain nodes through the preset distributed middleware to obtain this part of the business request. After receiving the inquiry message, the other blockchain nodes can determine whether their corresponding business storage contains this part of the business request. If so, a response message is returned to the second blockchain node. If not, the response message is not returned to the second blockchain node.

After receiving the response message, the second blockchain node can obtain this part of the business request from the business memory corresponding to the blockchain node that sent the response message through the preset distributed middleware. Then, the second blockchain node can perform asymmetric signature legal verification on this part of the business request, and when it is determined that this part of the business request has passed the asymmetric signature legal verification, it will store this part of the business request in its own corresponding business memory. Among them, the second blockchain node can store this part of the business request in its own corresponding business memory according to the order of arrangement of each business request in the pre-processing block. If the second blockchain node determines that this part of the business request has not passed the asymmetric signature legal verification, it will not store this part of the business request, and will determine that the pre-processing block sent by the first blockchain node has not passed the local (i.e., the second blockchain node) consensus verification.

If the second blockchain node receives this part of the business request from other blockchain nodes and still receives this part of the business request from other blockchain nodes, the second blockchain node can ignore this part of the business request received subsequently, and there is no need to perform asymmetric signature legal verification and storage on this part of the business request received subsequently.

In an embodiment of the present application, the entire consensus network can be a consensus network of a consortium chain, and each blockchain node can be each blockchain node in the consortium chain. In this embodiment of the present application, the first blockchain node can be a leader node in the consortium chain consensus algorithm, and the second blockchain node can be a non-leader node in the consortium chain consensus algorithm.

It can be seen from the above method that after receiving the business requests broadcast by the first blockchain node, when the second blockchain node finds that its corresponding business memory does not contain some of the business requests, it does not directly determine that these business requests fail the consensus verification on the second blockchain node. Instead, it can obtain these missing business requests from other blockchain nodes in the entire consensus network, and perform consensus verification on each business request received from the first blockchain node through the obtained business requests and the business requests stored in its own business memory. This greatly reduces the occurrence of adverse effects on the consensus verification of each business request due to network failure, thereby improving the business processing accuracy of the entire blockchain business.

Moreover, since, in the embodiment of the present application, the business memory used by each blockchain node to store business requests exists in the form of a database, compared to the prior art method in which each blockchain node stores each business request through its own cache, the business memory in the form of a database provided in the embodiment of the present application greatly improves the storage capacity of business requests. Moreover, when the blockchain node performs consensus verification on some business requests in the business memory through the entire consensus network, the blockchain node can still continue to receive business requests sent by the terminal, that is, there is no need to use the storage space occupied by some business requests that have passed the consensus verification to receive business requests sent by the terminal, thereby further improving the business processing efficiency of the blockchain business.

The above is the service verification method provided in the embodiment of the present application. Based on the same idea, the embodiment of the present application also provides two service verification devices, as shown in Figures 5 and 6.

FIG5 is a schematic diagram of a service verification device provided in an embodiment of the present application, specifically comprising:

Receiving module 501, receiving a service request sent by a terminal;

The storage module 502 stores the service request in a service memory corresponding to the device, and broadcasts the service request to each second blockchain node, so that each second blockchain node stores the service request in its corresponding service memory;

The request retrieval module 503 retrieves at least one business request from the business memory, and packages the retrieved at least one business request into a pre-processing block and broadcasts it to each second blockchain node, so that when each second blockchain node determines that its corresponding business memory does not contain some business requests in the pre-processing block, it obtains the part of the business requests from other blockchain nodes and performs consensus verification on the pre-processing block through the part of the business requests and the business requests stored in its own business memory.

The service memory is a database for storing service requests.

The storage module 502 stores the service request in the service memory through a preset distributed middleware.

The request retrieval module 503 retrieves a set number of service requests whose service types are higher than a set priority from the service memory.

The storage module 502 stores the service request in the service memory according to the service type of the service request and the preset priority order of each service type.

The device is a leader node in the alliance chain consensus algorithm, and the second blockchain node is a non-leader node in the alliance chain consensus algorithm.

FIG6 is a schematic diagram of another service verification device provided in an embodiment of the present application, specifically comprising:

A request receiving module 601 receives a service request broadcast by a first blockchain node;

A request storage module 602 stores the service request in a service memory corresponding to the device;

The receiving module 603 receives a pre-processing block containing at least one service request broadcast by the first blockchain node, and when determining that a service memory corresponding to the receiving module 603 does not contain some service requests in the pre-processing block, obtains the some service requests from other blockchain nodes;

The verification module 604 performs consensus verification on the pre-processing block through the partial business requests and the business requests stored in its own corresponding business memory.

The receiving module 603, when determining that the business memory does not contain some business requests in the preprocessing block, sends an inquiry message to the other second blockchain node or the first blockchain node to obtain the said part of the business request; receives a response message returned by the other second blockchain node or the first blockchain node, wherein the response message indicates that the said part of the business request is stored in the business memory corresponding to the other second blockchain node or the first blockchain node that sent the response message; and obtains the said part of the business request from the business memory corresponding to the second blockchain node that sent the response message or the first blockchain node.

In an embodiment of the present application, after a first blockchain node packages at least one business request retrieved from its own business memory into a pre-processing block and broadcasts it to each second blockchain node, if the second blockchain node finds that its corresponding business memory does not contain some of the business requests in the pre-processing block, it can obtain the said part of the business requests from other blockchain nodes and perform consensus verification on the business requests contained in the pre-processing block using the said part of the business requests and the business requests stored in its own business memory. Since the second blockchain node does not directly determine that the pre-processing block has failed the consensus verification on the second blockchain node when it receives the pre-processing block broadcast by the first blockchain node and finds that its corresponding business memory does not contain some of the business requests in the pre-processing block, it can obtain the missing business requests from other blockchain nodes in the entire consensus network and perform consensus verification on the pre-processing block using the obtained part of the business requests and the business requests stored in its own business memory. This greatly reduces the possibility that the consensus verification of each business request will be adversely affected by network failures, thereby improving the accuracy of business processing of the entire blockchain business.

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 (16)

1. A method for business verification, characterized in that it includes: The first blockchain node receives the business request sent by the terminal; The service request is stored in the service storage corresponding to the first blockchain node, and the service request is broadcast to each of the second blockchain nodes, so that each of the second blockchain nodes stores the service request in its respective service storage. At least one business request is retrieved from the business storage corresponding to the first blockchain node, and the retrieved at least one business request is packaged into a preprocessing block and broadcast to each second blockchain node. This allows each second blockchain node to obtain the partial business request from other blockchain nodes when it determines that its corresponding business storage does not contain the partial business request in the preprocessing block, and to perform consensus verification on the preprocessing block using the partial business request and the business requests stored in its own business storage. 2. The method as described in claim 1, wherein the service storage is a database for storing service requests. 3. The method as described in claim 2, characterized in that storing the business request in the business storage corresponding to the first blockchain node specifically includes: The service request is stored in the service storage via a pre-defined distributed middleware. 4. The method according to any one of claims 1 to 3, characterized in that retrieving at least one service request from the service storage specifically includes: Retrieve a set number of service requests whose service type is higher than the set priority from the service storage. 5. The method as described in claim 4, characterized in that storing the business request in the business storage corresponding to the first blockchain node specifically includes: The service request is stored in the service memory according to the service type of the service request and the preset priority order of each service type. 6. The method as described in claim 1, wherein the first blockchain node is a leader node in the consortium blockchain consensus algorithm, and the second blockchain node is a non-leader node in the consortium blockchain consensus algorithm. 7. A method for business verification, characterized in that it includes: The second blockchain node receives the business request broadcast by the first blockchain node; The business request is stored in the business storage corresponding to the second blockchain node; The system receives a preprocessing block broadcast by the first blockchain node, which contains at least one business request. If it determines that its corresponding business storage does not contain part of the business request in the preprocessing block, it obtains the part of the business request from other blockchain nodes. Consensus verification is performed on the preprocessing block using the aforementioned partial service requests and the service requests stored in its corresponding service storage. 8. The method as described in claim 7, characterized in that, when it is determined that the corresponding business storage does not contain a portion of the business requests in the preprocessing block, the portion of the business requests is obtained from other blockchain nodes, specifically including: If it is determined that the service storage does not contain a portion of the service requests in the preprocessing block, an inquiry message to obtain the portion of the service requests is sent to other second blockchain nodes or the first blockchain node. Receive a response message returned by the other second blockchain node or the first blockchain node, wherein the response message indicates that the business storage corresponding to the other second blockchain node or the first blockchain node that sent the response message stores the part of the business request; The partial service request is obtained from the service storage corresponding to the second blockchain node that sent the response message or the first blockchain node. 9. A device for business verification, characterized in that it comprises: The receiving module receives service requests sent by the terminal; The storage module stores the service request in the service memory corresponding to the device and broadcasts the service request to each second blockchain node, so that each second blockchain node stores the service request in its respective service memory. The request retrieval module retrieves at least one service request from the service memory corresponding to the device, and packages the retrieved at least one service request into a preprocessing block and broadcasts it to each second blockchain node. This allows each second blockchain node to obtain the partial service request from other blockchain nodes when it determines that its corresponding service memory does not contain the partial service request in the preprocessing block, and to perform consensus verification on the preprocessing block using the partial service request and the service requests stored in its own service memory. 10. The apparatus as described in claim 9, wherein the service storage is a database for storing service requests. 11. The apparatus as described in claim 10, wherein the storage module stores the service request in the service memory via a preset distributed middleware. 12. The apparatus according to any one of claims 9 to 11, wherein the request retrieval module retrieves a set number of service requests whose service type is higher than a set priority from the service memory. 13. The apparatus of claim 12, wherein the storage module stores the service request in the service memory according to the service type of the service request and a preset priority order of each service type. 14. The apparatus as described in claim 9, wherein the apparatus is a leader node in a consortium blockchain consensus algorithm, and the second blockchain node is a non-leader node in the consortium blockchain consensus algorithm. 15. A device for business verification, characterized in that it comprises: The request receiving module receives business requests broadcast by the first blockchain node. The request storage module stores the service request in the service memory corresponding to the device; The receiving module receives a preprocessing block broadcast by the first blockchain node, which contains at least one business request. When it determines that its own corresponding business storage does not contain part of the business request in the preprocessing block, it retrieves the part of the business request from other blockchain nodes. The business request in the preprocessing block is retrieved from the business storage corresponding to the first blockchain node. The verification module performs consensus verification on the preprocessing block using the aforementioned partial service requests and the service requests stored in its corresponding service storage. 16. The apparatus of claim 15, wherein the receiving module, upon determining that the service memory does not contain a portion of the service requests in the preprocessing block, sends an inquiry message to other second blockchain nodes or the first blockchain node to request the partial service requests; receives a response message returned by the other second blockchain nodes or the first blockchain node, the response message indicating that the service memory corresponding to the other second blockchain node or the first blockchain node that sent the response message contains the partial service requests; and retrieves the partial service requests from the service memory corresponding to the second blockchain node or the first blockchain node that sent the response message.