TWI727467B - Trustworthiness verification method, system, device and equipment of alliance chain - Google Patents

Abstract

A method, system, device and equipment for verifying the credibility of a consortium chain are disclosed. After the client completes the transaction on-chain certification through the docking node, for the transaction, the client initiates a transaction location query request to multiple nodes in the alliance chain, so as to obtain the respective query results of the multiple nodes for the transaction. Furthermore, the credibility of the consortium chain can be verified based on the consistency of the location query results of multiple nodes, and the user experience can be improved.

Description

Trustworthiness verification method, system, device and equipment of alliance chain

The embodiments of this specification relate to the field of information technology, in particular to a method, system, device, and equipment for verifying the credibility of a consortium chain.

In a consortium chain, there are often multiple nodes with very different functions. For example, a consortium chain for copyright deposit may include a work publishing node, a copyright registration node, a copyright transfer node, a notarization node, and so on. However, based on the different needs of users, it is often only one of the nodes that docks with the user, and this node can be considered as the docking node of the user. For example, a user publishes a transaction through the application APP published by a certain node, and the transaction is deposited on the consortium chain through the docking node, and subsequent verifications are often performed through the docking node. In this process, it is difficult for users to perceive other nodes in the entire consortium chain, and they usually have little interest in other nodes. In the user experience, the completion and verification of transactions seems to be centered on the docking node, and in turn, users will have doubts about the credibility of the docking node and the alliance chain. Based on this, there is a need for a solution that allows users to verify the credibility of the alliance chain.

In view of the problem of poor user experience in the credibility verification of the consortium chain in the prior art, in order to improve the user experience, the embodiments of this specification provide a solution that allows users to verify the credibility of the consortium chain. The first aspect includes a method for verifying the credibility of the consortium chain. After generating a transaction on the client side and storing the transaction on the chain through the docking node, it includes: The client obtains the addresses of multiple nodes in the consortium chain; Sending a transaction location query request to the multiple nodes according to the multiple node addresses, wherein the transaction location query request includes a summary hash of the transaction; Any node receives the location query request, queries the location information of the transaction corresponding to the summary hash in the alliance chain based on the summary hash, and returns the location query result to the client; The client verifies the credibility of the alliance chain containing the transaction information based on the degree of consistency of the location query results returned by the multiple nodes. In the second aspect, the embodiment of this specification also provides a method for verifying the credibility of the consortium chain. After the user generates a transaction and uploads the transaction to the chain through the docking node, the method includes: Obtain the addresses of multiple nodes in the consortium chain; Sending a transaction location query request to the multiple nodes according to the multiple node addresses, wherein the transaction location query request includes a summary hash of the transaction; According to the degree of consistency of the location query results returned by the multiple nodes, the credibility of the alliance chain containing the transaction information is verified.

In the third aspect, the embodiment of this specification also provides a request processing method in the consortium chain. When the node is a node in the consortium chain, the method includes: the node determines the user identity of the user of its own node, wherein the user identity is used for Identify the identity of the user, and to identify the node that is connected to the user; send a whitelist to other nodes in the alliance chain, so that other nodes can determine whether to execute the request sent by the user who is not their own node according to the whitelist, the request It includes a transaction location query request or a simple payment verification SPV request, and the request includes a summary hash of the target transaction.

Corresponding to the first aspect, the embodiment of this specification also provides a credibility verification system for a consortium chain, including a client and a consortium chain network. The consortium chain network includes a plurality of nodes; transactions are generated on the client, and After depositing the transaction on the chain through the docking node, the client obtains multiple node addresses in the alliance chain; according to the multiple node addresses, sends a transaction location query request to the multiple nodes, where the The transaction location query request includes the summary hash of the transaction; any node in the alliance chain network receives the location query request, and based on the summary hash each query the transaction corresponding to the summary hash in the alliance chain And return the location query result to the client; the client verifies the credibility of the alliance chain containing the transaction information based on the degree of consistency of the location query results returned by the multiple nodes.

Corresponding to the second aspect, the embodiment of this specification also provides an alliance The credibility verification device of the chain. After the user generates a transaction and deposits the transaction on the chain through the docking node, the device includes: an acquisition module to acquire the addresses of multiple nodes in the alliance chain; and a sending module , According to the multiple node addresses, send a transaction location query request to the multiple nodes, wherein the transaction location query request includes a summary hash of the transaction; the receiving module receives the multiple nodes respectively The returned location query result; the verification module verifies the credibility of the alliance chain containing the transaction information according to the degree of consistency of the location query result.

Corresponding to the third aspect, an embodiment of this specification also provides a request processing device in a consortium chain, which is located on a node in the consortium chain, and includes: a determination module that determines the user identity of the user of the node of its own The user ID is used to identify the user's identity, and to identify the node that connects with the user; the sending module sends a whitelist to other nodes in the alliance chain, so that other nodes can determine whether to execute non-self-node users according to the whitelist The sent request, the request includes a transaction location query request or a simple payment verification SPV request, and the request includes a summary hash of the target transaction.

In the solution provided by the embodiment of this specification, after the client completes the transaction on-chain deposit certificate through the docking node, for the transaction, the client initiates a transaction location query request to multiple nodes in the alliance chain, so that multiple The node queries the result of the respective position of the transaction. Furthermore, the credibility of the consortium chain can be verified based on the consistency of the location query results of multiple nodes, and the user experience can be improved. It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the embodiments of this specification. In addition, any one of the embodiments of the present specification does not need to achieve all the above-mentioned effects.

In order to enable those skilled in the art to better understand the technical solutions in the embodiments of this specification, the technical solutions in the embodiments of this specification will be described in detail below in conjunction with the drawings in the embodiments of this specification. Obviously, the described implementation The examples are only a part of the embodiments in this specification, not all the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art should fall within the scope of protection. A consortium chain usually contains multiple different functional nodes. At present, an architecture often adopted by the consortium chain is that each functional node faces its own users, and users access the consortium chain through the functional nodes they are interested in. In the nodes in the consortium chain involved in the embodiments of this specification, it can be considered that each node participates in the routing function of the consortium chain network, and can also include other functions. For example, each node can participate in the verification and propagation of transactions and zones. Block information, discover and maintain connections with peer nodes, and can also have a complete alliance chain in the local storage area, and some data related to the alliance chain. As shown in Figure 1, Figure 1 is an architecture involved in the current alliance chain. In Figure 1, the nodes in the alliance chain network may all contain different functions, and because each node provides different functions, the target users are often not the same. In the same alliance chain, each function node also We often develop our own application programs respectively to allow users of our own nodes to register and access. The user usually selects a node to connect to the alliance chain for transaction release and verification. The technical solutions provided by the embodiments of this specification will be described in detail below with reference to the accompanying drawings. The first aspect of the solution of the embodiment of this specification is shown in Figure 2. Figure 2 is a schematic flow diagram of a method for verifying the credibility of a consortium chain in the system aspect of the embodiment of this specification. The transaction is generated on the client and passed After the docking node deposits the transaction on the chain, the process specifically includes the following steps: S201, the client obtains the addresses of multiple nodes in the alliance chain. For the client, the address of the docking node is known, and the addresses of other nodes in the alliance chain can be obtained by requesting the docking node. It can also be obtained through other methods. For example, all nodes in the alliance chain regularly publish their addresses to a public cloud, and the client locally saves a list of addresses, and the client regularly obtains the address pairs of all nodes from the public cloud. The address list is updated, so that several node addresses can be selected from the address list at any time. In this way, the docking node of the client can be bypassed, and the user's trust in the entire consortium chain can be improved. S203: Send a transaction location query request to the multiple nodes according to the multiple node addresses, wherein the transaction location query request includes a summary hash of the transaction. After the user completes the transaction and deposits the certificate on the chain through the docking node, he will receive a notification message about the deposit transaction, which usually includes the digest hash and saves it locally on the client. Therefore, the client can always obtain the digest hash locally and add it to the transaction location query request. On the client side, after receiving the notification message, it can initiate a query request according to the user's instruction; it can also be that receiving the notification message triggers the query request. S205, any node receives the location query request, queries the location information of the transaction corresponding to the summary hash in the alliance chain based on the summary hash, and returns the location query result to the client. A blockchain is composed of multiple blocks, and at the same time, a block usually contains multiple transactions. Therefore, in the embodiment of this specification, the location information specifically refers to which block in the blockchain the transaction is in when the transaction is recorded, and where it is in the block. In the blockchain, there can be multiple ways to identify different blocks, for example, block header hash value or block height (block height). The block header hash value is the hash value obtained by the hash calculation of the block header, which can be used to uniquely and clearly identify a block. In the blockchain, the block height of the first block is usually 0, and the block height is increased by 1 for each additional block in the future. A block usually has a clear block height. Therefore, the block header hash value or the block height can be used as a part of the block metadata and stored in an independent database table in the node for easy indexing and faster retrieval of the block. At the same time, since a block usually contains multiple transactions, the address offset of each transaction in the block can also be used to identify the transactions in the block. Obviously, in the same block, the address offset of each transaction is not the same. Furthermore, after depositing the certificate on the blockchain at the exchange, each node can maintain a form such as (transaction summary hash, block header hash value, address offset), or, (transaction summary hash, The block height, address offset) data table, the corresponding block identifier and the address of the transaction in the block can be obtained through the transaction summary hash query. In other words, the node can determine the position of the transaction in the alliance chain through the summary hash of the transaction. Of course, since the specific format of the block chain can be customized, the content of the location information will be different under different block formats, which does not constitute a limitation to this solution. In addition, it should be noted that the request received by any node may come directly from the client, or it may be a client request forwarded by other nodes in the alliance chain. S207: The client verifies the credibility of the alliance chain containing the transaction information based on the degree of consistency of the location query results returned by the multiple nodes respectively. After the end of the query, each node can return the query result to the client. It should be noted that this process can be an asynchronous processing process, and the client does not need to respond immediately after sending the query request. Therefore, the client can wait for all nodes to return a query result before verifying. Since a transaction can only have a certain position in the consortium chain, the credibility of the consortium chain can be determined based on the consistency of the query results. In theory, the location information returned by each node should be exactly the same. A more stringent verification method is that if all the location query results are consistent, the consortium chain is credible. Of course, due to various network reasons, equipment reasons, etc., certain deviations can be tolerated. For example, according to the degree of agreement of all the returned results, if there is no identical query result that accounts for more than 95% of the returned results, the alliance degree credibility is considered to be 0, otherwise, the account of the same result is considered to be 0. Than as the credibility of the alliance chain. Further, when it is determined that the consortium chain is not credible, an alarm can also be issued. Specifically, the alarm message can indicate the degree of inconsistency between the query results of each node (that is, how many or how many proportions are inconsistent with the majority results), and specify the nodes that are inconsistent with the majority results and the query of this type of node result. In the solution provided in the embodiment of this specification, after the user completes the transaction on-chain deposit certificate through the docking node, for the transaction, the user initiates a transaction location query request to multiple nodes in the alliance chain, so that multiple nodes can obtain The respective query results of the transaction. Furthermore, the credibility of the consortium chain can be verified based on the consistency of the location query results of multiple nodes, and the user experience can be improved. In a specific implementation, the client obtains the addresses of multiple nodes in the consortium chain. The client can randomly obtain the addresses of multiple nodes in the consortium chain. Randomly obtain the node addresses for verification. On the one hand, the verification results can be improved. Fairness, on the other hand, can also make user requests flow evenly to each node, avoiding too heavy load on some nodes with many users. Or, the client obtains multiple node addresses in the alliance chain that include the address of the docking node. In this manner, the user can first select a batch of node addresses, and then add the addresses of the docking node. When a docking node is added for verification, the returned result also includes the verification result of the docking node, which can make the verification more targeted and improve user experience. In a specific implementation manner, the user may also send a simple payment verification SPV request to the multiple nodes according to the multiple node addresses, wherein the SPV request includes a digest hash of the transaction. Based on the digest hash, any node verifies whether the transaction corresponding to the digest hash is in the alliance chain, generates an SPV verification result, and returns the SPV verification result to the client. The client verifies the credibility of the consortium chain containing the transaction information based on the SPV verification results returned by the multiple nodes respectively. In each block of the blockchain, all transactions recorded in the block are included, and can be represented by Merkle trees. All transactions in the block hash the data, and then store the hash value in the corresponding leaf node. A leaf node in the tree represents the existence of a corresponding transaction in the block. In order to prove that there is a specific target transaction in the block, a node only needs to calculate log ₂ N hash values to form a Merkle path from the target transaction to the root of the tree. When a node performs Simplified Payment Verification (SPV), it does not have to save all transactions or download the entire block. The node can only save the block header, and verify whether the target transaction exists in the block through the hash and Merkle path of the target transaction. In other words, the SPV verification result of each node is a binary result, either "yes" or "no". Since a transaction either exists or does not exist in the alliance chain, in theory, when there is no problem with the alliance chain, the SPV verification results returned by each node should be exactly the same. Therefore, a relatively strict way to confirm the credibility is to confirm that the consortium chain is credible if all SPV verification results are consistent with "Yes", otherwise it is not credible. Of course, due to various network reasons, equipment reasons, etc., certain deviations can be tolerated. For example, a threshold is set, and if the degree of agreement of the SPV verification result is "Yes" exceeds the threshold, it is confirmed that the consortium chain is credible. Further, when it is confirmed that the consortium chain is not credible, an alarm can also be issued. Specifically, the alarm message can indicate the degree of inconsistency between the query results of each node (that is, what are the results of "Yes" and "No" respectively), and specify the nodes that are inconsistent with most results and this type of node The result of the query. And, a credibility value can be calculated as a reference based on the degree of inconsistency of all the returned results. For example, if there is no identical query result whose proportion exceeds a certain threshold among the returned results, the alliance degree is considered credible, otherwise, the alliance chain is considered untrustworthy. It should be noted that the foregoing verification scheme based on the consistency of the location query results and the verification scheme based on the consistency of the SPV verification results belong to the schemes that can be performed separately at the same time. In actual operation, the verification results of the two are independent. In other words, the client can choose only one way to perform verification, or it can choose two ways to perform verification at the same time. When two verification schemes are executed at the same time, the results of the two verification schemes need to meet the consistency conditions at the same time before the alliance chain is considered to be acceptable Letter. And, during the verification process, the two schemes are executed in no particular order. Because in the alliance chain, each functional node usually has its own docking client and corresponding docking users. In the solution of the embodiment of this specification, each node often needs to process requests from users who are not their own nodes. In an implementation manner, the node can process query requests or SPV requests sent by any client connected to itself. In another implementation manner, based on the principle of alliance sharing, each node can also provide query services or SPV services to whitelist users. If the identification of the client that sends the request is on the whitelist, processing is performed, otherwise, no processing is performed. The specific method for determining whitelisted users includes: any node in the alliance chain determines its own whitelist, and broadcasts the whitelist to other nodes in the alliance chain, so that other nodes can determine whether to perform query processing according to the whitelist. A common handling method is that any node in the alliance chain confirms its registered user as a whitelist user and broadcasts it. Other nodes can decide whether to perform further processing based on whether the client identifier included in the request is a whitelisted user. The whitelist here can take the node as the smallest unit, or the user as the smallest unit, and the whitelist users saved by each node can be the same or different. The node processes the request only when it receives the request sent by the whitelisted user. For example, suppose there are four nodes A, B, C, and D in the alliance chain. In the above scheme, nodes B, C, and D can confirm the docking user of node A as whitelisted users, and the four nodes can maintain it together; The whitelisted users of node B include users of node A, but the whitelisted users of nodes C and D do not include users of node A. The specific situation can be determined by itself based on the business situation. In a more general situation, the docking user of a node of a government agency (such as a notary office) or a public welfare organization (such as a charity) can be a whitelist user of all other nodes in the alliance chain, and a node user of a business partner node of a node can also Is the whitelisted user of the node. Furthermore, each node can also classify whitelist users' permissions based on the user's source or historical behavior data and other factors (for example, third-party credit evaluation scores). For example, whitelist users with the lowest permissions only have query permissions. , Whitelisted users with higher permissions may also have other permissions and so on. In practical applications, the number of users of each node in a consortium chain is not the same, some nodes have more docking users, and some nodes have fewer docking users. Generally speaking, the number of docking users of those nodes directly facing the market is always more than the number of rear nodes. For example, in a consortium chain used to protect copyright, there are always far more registered users of the work publishing platform facing creators than the registered users of the notary office. In this case, in the solution of the embodiment of this specification, each node in the alliance is not "fair" in handling the request. In other words, nodes with few registered users will always receive more requests than they should be responsible for processing, which is not very beneficial to nodes with few registered users. At this time, an practicable way is that when any node receives the request and decides to process it, it first makes a judgment to determine that the node determines the first processing times of the location query request initiated by users of other nodes, and, Confirm the second processing times of the location query request initiated by the user of the node by other nodes; determine whether to delay processing the location query request according to the first processing times and the second processing times.

The first processing times and the second processing times can be a period of time, for example, every day or every month, and can be cleared regularly, or they can be statistics of all historical data. The condition for judging whether to delay processing can be calculated according to the first processing times X and the second processing times Y to obtain a contribution ratio value Z to compare with a preset threshold, for example, Z=(XY)/Y, or Z=X /Y Wait. The contribution ratio value represents the ratio of a node's "self contribution" and "request others" when processing requests. Once the contribution ratio value exceeds a certain threshold, it means that the node has processed more requests, and the node can delay Processing received requests sent by users of other nodes, delaying the processing of requests can effectively reduce the load of weak nodes (that is, nodes with few registered users and generally have relatively weak processing capabilities for large traffic). Since in the solution of the embodiment of this specification, the client does not need to obtain the verification result immediately, the processing of the request by each node may be asynchronous, and the delayed processing will not affect the effect of the solution of the embodiment of this specification.

In one embodiment, when the client selects multiple nodes, it may select the same node multiple times in succession. In this way, the client can determine whether the number of times the node's transaction location query request has been sent has reached the threshold. If yes, delay sending the transaction location query request to the node. The statistics of sending times can count the times within a period of time, or all the historical times. Through the above method, the client side can avoid continuously requesting another node and reduce the impact on the load of another node.

The second aspect of the solution of the embodiment of this specification is shown in Fig. 3. Fig. 3 is a schematic flow diagram of a method for verifying the credibility of a consortium chain on the client side provided by the embodiment in this specification. The user generates a transaction, And through After the docking node puts the transaction on the chain and deposits the certificate, it includes: S301, obtain the addresses of multiple nodes in the alliance chain, and the specific method includes randomly obtaining the addresses of multiple nodes in the alliance chain; or, obtain the addresses of the nodes in the alliance chain. A plurality of node addresses including the address of the docking node.

S303: Send a transaction location query request to the multiple nodes according to the multiple node addresses, where the transaction location query request includes a summary hash of the transaction; S305, return according to the multiple nodes respectively The degree of consistency of the location query results verifies the credibility of the alliance chain containing the transaction information.

Further, the above method further includes, according to the multiple node addresses, sending a simple payment verification SPV request to the multiple nodes, wherein the SPV request includes a digest hash of the transaction; receiving the multiple The SPV verification results returned by the nodes respectively verify the credibility of the alliance chain containing the transaction information.

Further, the sending of the transaction location query request in S303 to the multiple nodes includes, for any node of the multiple nodes, judging whether the number of times the transaction location query request for the node has been sent has reached a threshold, if yes , The node delays sending the transaction location query request.

The third aspect of the solution of the embodiment of this specification is shown in Figure 4. Figure 4 is a schematic flow diagram of a request processing method for alliance chain provided by the embodiment in this specification. The user generates a transaction and transfers all transactions through the docking node. After the transaction is recorded on the chain, it includes: S401, the node determines the user ID of the user of its own node, where the user ID is used to identify the user's identity, and is used to identify the node connecting with the user; in the alliance chain The information of the docking node can be included in the user ID through a pre-negotiated format, for example, a different serial number is added to the beginning of the user ID to identify the docking node of the user. S403: Send a whitelist to other nodes in the alliance chain, so that other nodes can determine whether to execute a request sent by a user other than their own node according to the whitelist. The request includes a transaction location query request or a simple payment verification SPV request. The request contains a summary hash of the target transaction. Further, the above method further includes that the node receives a request sent by any user, and the request further includes a user identification; judging whether the user identification is in a whitelist, and if not, not performing processing on the request. Further, the above method further includes receiving a request sent by any user, the request also including a user identification, and when the user corresponding to the user identification is not a user of the own node: determining that the node initiates a request for other node users The first processing times of the request, and the second processing times of confirming other nodes for requests initiated by users of the node; according to the first processing times and the second processing times, it is determined whether to delay processing the request. Corresponding to the first aspect, the embodiment of this specification also provides a credibility verification system for the alliance chain, which includes a client and an alliance chain network, the alliance chain network includes a plurality of nodes; transactions are generated on the client, and After depositing the said transaction on the chain through the docking node, The client obtains multiple node addresses in the alliance chain; according to the multiple node addresses, sends a transaction location query request to the multiple nodes, wherein the transaction location query request includes a summary hash of the transaction; Any node in the alliance chain network receives the location query request, queries the location information of the transaction corresponding to the summary hash in the alliance chain based on the summary hash, and returns the location query result to the customer end; The client verifies the credibility of the alliance chain containing the transaction information based on the degree of consistency of the location query results returned by the multiple nodes. Further, in the system, the client randomly obtains multiple node addresses in the consortium chain; or, the client obtains multiple node addresses in the consortium chain that include the address of the docking node. Further, in the system, the client sends a simple payment verification SPV request to the multiple nodes according to the multiple node addresses, wherein the SPV request includes a digest hash of the transaction; any Based on the digest hash, each node verifies whether the transaction corresponding to the digest hash is in the alliance chain, generates an SPV verification result, and returns the SPV verification result to the client; the client is based on the multiple nodes The SPV verification results returned respectively verify the credibility of the alliance chain containing the transaction information. Further, in the system, before the client obtains the addresses of multiple nodes in the alliance chain, any node in the alliance chain determines its own whitelist, and broadcasts the whitelist to other nodes in the alliance chain, so that Other nodes determine whether to perform query processing according to the whitelist; the transaction location query request includes the transaction summary hash, including: the transaction location query request includes the transaction summary hash and the client identifier; After any node receives the location query request, it further includes: determining whether the client identifier included in the location query request is in the white list, and if not, no query processing is performed.

Further, in the system, the node determines the first processing times of location query requests initiated by users of other nodes by itself, and confirms the second processing times of location query requests initiated by users of the node by other nodes; According to the first processing times and the second processing times, it is determined whether to delay processing the location query request.

Further, in the system, the client, for any one of the multiple nodes, determines whether the number of times the transaction location query request for the node has reached a threshold, and if so, delays sending the transaction to the node Location query request.

Corresponding to the second aspect, the embodiment of this specification also provides a credibility verification device for the alliance chain. After the user generates a transaction and uploads the transaction to the chain through the docking node, as shown in Figure 5, Figure 5 This is a schematic structural diagram of a credibility verification device provided by the embodiment of this specification. The device includes: an acquisition module 501, which acquires the addresses of multiple nodes in the alliance chain; and a sending module 503, according to the multiple nodes Address, sending a transaction location query request to the multiple nodes, where the transaction location query request includes a summary hash of the transaction; a receiving module 505, receiving location query results returned by the multiple nodes respectively; The verification module 507, according to the degree of consistency of the location query results, Verify the credibility of the alliance chain containing the transaction information.

Further, the obtaining module 501 randomly obtains the addresses of multiple nodes in the alliance chain; or, obtains the addresses of multiple nodes in the alliance chain that include the addresses of the docking nodes.

Further, the sending module 503 is further configured to send a simple payment verification SPV request to the multiple nodes according to the multiple node addresses, wherein the SPV request includes a digest hash of the transaction; The receiving module 505 receives the SPV verification results returned by the multiple nodes, and the verification module 507 verifies the credibility of the alliance chain containing the transaction information according to the SPV verification result.

Further, the sending module 503 judges whether the number of times of sending the transaction location query request of the node reaches a threshold for any node among the multiple nodes, and if so, delays sending the transaction location query request to the node.

Corresponding to the third aspect, the embodiment of this specification also provides a request processing device in the consortium chain, which is located on a node in the consortium chain, as shown in FIG. 6, which is a request provided by the embodiment of the specification. A schematic diagram of the structure of the processing device. The device includes: a determining module 601 to determine a user identity of a user of its own node, wherein the user identity is used to identify the user identity and the node that is connected to the user; and the sending module Group 603: Send a white list to other nodes in the alliance chain, so that other nodes can determine whether to execute a request sent by a user other than their own node based on the white list. The request includes a transaction location query request or a simple payment verification SPV request. The request contains a summary hash of the target transaction. Further, the device further includes a receiving module 605, which receives a request sent by any user, and the request also includes a user identification; a judgment module 607, which judges whether the user identification is in the whitelist, if not , Does not perform processing on the request. Further, the receiving module 605 receives a request sent by any user, and the request also includes a user identification. When the user corresponding to the user identification is not a user of its own node, the determining module 601 also It is used to determine the first processing times of requests initiated by users of other nodes by the node, and to confirm the second processing times of requests initiated by users of this node by other nodes; the judgment module 607 is also used to, according to The first processing times and the second processing times determine whether to delay processing the request. The embodiment of this specification also provides a computer device, which at least includes a memory, a processor, and a computer program stored on the memory and capable of running on the processor, wherein the processor executes the program as shown in FIG. 3 The credibility verification method of the alliance chain. The embodiments of this specification also provide a computer device, which at least includes a memory, a processor, and a computer program stored on the memory and running on the processor, wherein the processor executes the program as shown in FIG. 4 The request processing method in the alliance chain. FIG. 7 shows a more specific hardware structure diagram of a computing device provided by an embodiment of this specification. The device may include: a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050 . The processor 1010, the memory 1020, the input/output interface 1030, and the communication interface 1040 realize the communication connection between each other in the device through the bus 1050. The processor 1010 may be implemented by a general CPU (Central Processing Unit, central processing unit), a microprocessor, an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits, etc., for Execute related programs to realize the technical solutions provided in the embodiments of this specification. The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the related program codes are stored in the memory 1020 and called and executed by the processor 1010. . The input/output interface 1030 is used to connect input/output modules to realize information input and output. The input/output/module can be configured in the device as a component (not shown in the figure), or it can be connected to the device to provide corresponding functions. The input device may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output device may include a display, a speaker, a vibrator, an indicator light, and so on. The communication interface 1040 is used to connect a communication module (not shown in the figure) to realize the communication interaction between the device and other devices. The communication module can realize communication through wired means (such as USB, network cable, etc.), or through wireless means (such as mobile network, WIFI, Bluetooth, etc.). The bus 1050 includes a path for transmitting information between various components of the device (for example, the processor 1010, the memory 1020, the input/output interface 1030, and the communication interface 1040). It should be noted that although the above device only shows the processor 1010, the memory 1020, the input/output interface 1030, the communication interface 1040, and the bus 1050, in the specific implementation process, the device may also include a place for normal operation. Other necessary components. In addition, those skilled in the art can understand that the above-mentioned equipment may also include only the components necessary to implement the solutions of the embodiments of the present specification, and not necessarily include all the elements shown in the figures. The embodiment of this specification also provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the credibility verification method of the alliance chain shown in FIG. 3 is realized. The embodiment of the present specification also provides another computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the request processing method in the alliance chain shown in FIG. 4 is implemented. Computer-readable media include permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology. 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), and other types of random access memory (RAM) , Read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital multi-function Optical discs (DVD) or other optical storage, magnetic cassettes, magnetic tape storage or other magnetic storage devices, or any other non-transmission media, can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves. From the description of the above embodiments, those skilled in the art can clearly understand that the embodiments of this specification can be implemented by means of software plus a necessary universal hardware platform. Based on this understanding, the technical solutions of the embodiments of this specification can be embodied in the form of software products, which can be stored in storage media, such as ROM/RAM, magnetic A disc, an optical disc, etc., include a number of instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute the methods described in the various embodiments or some parts of the embodiments of this specification. The systems, methods, modules, or units explained in the above embodiments may be implemented by computer chips or entities, or implemented by products with certain functions. A typical implementation device is a computer. The specific form of the computer can be a personal computer, a laptop computer, a mobile phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, and a game control A desktop, a tablet, a wearable device, or a combination of any of these devices. The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, as for the method embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for related parts, please refer to the part of the description of the method embodiment. The method embodiments described above are only illustrative, and the modules described as separate components may or may not be physically separated. When implementing the solutions of the embodiments of this specification, the functions of the modules may be Implemented in the same one or more software and/or hardware. Some or all of the modules can also be selected according to actual needs to achieve the objectives of the solutions of the embodiments. Those of ordinary skill in the art can understand and implement it without creative work. The above are only specific implementations of the embodiments of this specification. It should be pointed out that for those of ordinary skill in the art, without departing from the principle of the embodiments of this specification, several improvements and modifications can be made. These Improvement and retouching should also be regarded as the protection scope of the embodiments of this specification.

501: Obtain the module 503: send module 505: receiving module 507: Verification Module 601: Confirm module 603: Sending Module 605: receiving module 607: Judgment Module 1010: processor 1020: memory 1030: input/output interface 1040: Communication interface 1050: Bus

In order to more clearly describe the technical solutions in the embodiments of this specification or the prior art, the following will briefly introduce the drawings that need to be used in the description of the embodiments or the prior art. Obviously, the drawings in the following description are merely present For some of the embodiments described in the embodiments of the specification, for those of ordinary skill in the art, other drawings may be obtained based on these drawings. Figure 1 is a schematic diagram of an architecture involved in the current alliance chain; FIG. 2 is a schematic flowchart of a method for verifying the credibility of a consortium chain in the system aspect provided by an embodiment of the present specification; FIG. 3 is a schematic flowchart of a method for verifying the credibility of a consortium chain on the client side provided by an embodiment of this specification; FIG. 4 is a schematic flowchart of a request processing method in an alliance chain provided by an embodiment of this specification; FIG. 5 is a schematic structural diagram of a credibility verification device provided by an embodiment of the specification; 6 is a schematic structural diagram of a request processing apparatus provided by an embodiment of this specification; Fig. 7 is a schematic structural diagram of a device for configuring the method of the embodiment of this specification.

Claims (12)

A method for verifying the credibility of a consortium chain. After generating a transaction on the client and storing the transaction on the chain through a docking node, the method includes: the client obtains the addresses of multiple nodes in the consortium chain; and according to the multiple node positions Send a transaction location query request to the multiple nodes, where the transaction location query request includes a summary hash of the transaction; any node receives the location query request, and each query the summary hash corresponding to the summary hash based on the summary hash The location information of the transaction in the consortium chain, and the location query result is returned to the client; the client verifies the credibility of the consortium chain containing the transaction information based on the consistency of the location query results returned by the multiple nodes . According to the method described in claim 1, the client acquiring multiple node addresses in the alliance chain includes: the client randomly acquires multiple node addresses in the alliance chain; or, the client acquires the location of the docking node included in the alliance chain Multiple node addresses of the address. The method according to claim 1, further comprising: the client sends a simple payment verification SPV request to the multiple nodes according to the multiple node addresses, wherein the SPV request includes a digest hash of the transaction; Based on the digest hash, each node verifies whether the transaction corresponding to the digest hash is in the consortium chain, generates an SPV verification result, and returns the SPV verification result to the client; the client returns respectively based on the multiple nodes The SPV verification result verifies the credibility of the consortium chain containing the transaction information. As described in claim 1, before the client obtains the addresses of multiple nodes in the consortium chain, the method further includes: any node in the consortium chain determines its own whitelist, and broadcasts the whitelist to the consortium chain The transaction location query request contains the summary hash of the transaction, including: the transaction location query request contains the summary hash of the transaction and the client ID; any After a node receives the location query request, it further includes: determining whether the client identifier included in the location query request is in the white list, and if not, no query processing is performed. For the method described in claim 1, after any node receives the location query request, the method further includes: the node determines the first processing times of the location query requests initiated by users of other nodes by the node, and confirms that other nodes are The second processing times of the location query request initiated by the user of the node; according to the first processing times and the second processing times, it is judged whether it is delayed Process the location query request. According to the method of claim 1, sending a transaction location query request to the multiple nodes includes: for any node in the multiple nodes, determining whether the number of times the transaction location query request for the node has been sent has reached a threshold If yes, delay sending the transaction location query request to the node. A credibility verification system for a consortium chain, including a client and a consortium chain network, the consortium chain network includes multiple nodes; after generating a transaction on the client, and storing the transaction on the chain through the docking node, the client Obtain multiple node addresses in the alliance chain; send a transaction location query request to the multiple nodes according to the multiple node addresses, wherein the transaction location query request includes a summary hash of the transaction; the alliance chain network Any node in the network receives the location query request, queries the location information of the transaction corresponding to the digest hash in the alliance chain based on the summary hash, and returns the location query result to the client; the client is based on the multiple The consistency of the location query results returned by the nodes respectively verifies the credibility of the alliance chain containing the transaction information. For the system described in claim 7, the client randomly obtains multiple node addresses in the alliance chain; or, the client obtains multiple node addresses in the alliance chain that include the address of the docking node. For the system described in claim 7, the client sends a simple payment verification SPV request to the multiple nodes according to the multiple node addresses, wherein the SPV request includes a digest hash of the transaction; any node is based on The digest hash, each verifies whether the transaction corresponding to the digest hash is in the consortium chain, generates an SPV verification result, and returns the SPV verification result to the client; the client is based on the SPV verification results returned by the multiple nodes, respectively , To verify the credibility of the consortium chain containing the transaction information. For the system described in claim 7, before the client obtains the addresses of multiple nodes in the alliance chain, any node in the alliance chain determines its own whitelist, and broadcasts the whitelist to other nodes in the alliance chain so that Other nodes determine whether to perform query processing according to the whitelist; the transaction location query request includes the transaction summary hash, including: the transaction location query request packet, the transaction summary hash and the client ID; any node receives the location After the query request, it also includes: determining whether the client identifier included in the location query request is in the white list, and if not, no query processing is performed. In the system described in claim 7, after any node receives the location query request, The node determines the first processing times for location query requests initiated by users of other nodes, and confirms the second processing times for location query requests initiated by users of this node by other nodes; according to the first processing times and the second processing times Processing times to determine whether to delay processing the location query request. For the system described in claim 7, the client, for any node among the multiple nodes, determines whether the number of times the transaction location query request for the node has been sent has reached a threshold, and if so, delays sending the transaction location to the node Inquiry request.

Images