CN110049087B - Credibility verification method, system, device and equipment of alliance chain - Google Patents
Credibility verification method, system, device and equipment of alliance chain Download PDFInfo
- Publication number
- CN110049087B CN110049087B CN201811626394.6A CN201811626394A CN110049087B CN 110049087 B CN110049087 B CN 110049087B CN 201811626394 A CN201811626394 A CN 201811626394A CN 110049087 B CN110049087 B CN 110049087B
- Authority
- CN
- China
- Prior art keywords
- node
- transaction
- request
- nodes
- user
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
Abstract
A method, a system, a device and equipment for verifying credibility of a federation chain are disclosed. After the client finishes the transaction chain deposit through the docking node, the client initiates a transaction location query request to a plurality of nodes in the alliance chain aiming at the transaction, so that respective query results of the plurality of nodes for the transaction can be obtained. Furthermore, the credibility of the alliance chain can be verified based on the consistency degree of the position query results of the nodes, and the user experience is improved.
Description
Technical Field
The embodiment of the specification relates to the technical field of information, in particular to a method, a system, a device and equipment for verifying credibility of a federation chain.
Background
In a federation chain, there are often a plurality of nodes with widely different functions, for example, on a copyright-certified federation chain, there may be a work distribution node, a copyright registration node, a copyright assignment node, a notarization node, and so on. And based on different requirements of users, only one node is usually interfaced with the users, and the node can be regarded as an interfacing node of the users. For example, a user issues a transaction through an application APP issued by a node, and performs federation chain verification on the transaction through the docking node, and then performs verification through the docking node.
In this process, it is difficult for the user to perceive other nodes of the entire federation chain, and it is often of little interest to other nodes. In the user experience, the transaction is completed and verified as if it were a docking node, and the user may be doubtful about the docking node and the trustworthiness of the federation chain.
Based on this, a solution is needed that allows users to verify the trustworthiness of a federation chain.
Disclosure of Invention
Aiming at the problem that the user experiences badly in the credibility verification of the alliance chain in the prior art, in order to improve the user experience, the embodiment of the present specification provides a scheme that the user can verify the credibility of the alliance chain, and a first aspect of the scheme includes a method for verifying the credibility of the alliance chain, wherein after a transaction is generated at a client and the transaction is linked and certified through a docking node, the method includes:
a client acquires a plurality of node addresses in a alliance chain;
sending a transaction position query request to the plurality of nodes according to the plurality of node addresses, wherein the transaction position query request comprises the summary hash of the transaction;
any node receives the position query request, queries the position information of the transaction in the alliance chain corresponding to the digest hash based on the digest hash, and returns the position query result to the client;
and the client verifies the credibility of the alliance chain containing the transaction information based on the consistency degree of the position inquiry results respectively returned by the plurality of nodes.
In a second aspect, an embodiment of the present specification further provides a method for verifying a trustworthiness of a federation chain, where after a user generates a transaction and stores a chain certificate of the transaction through a docking node, the method includes:
acquiring a plurality of node addresses in a alliance chain;
sending a transaction position query request to the plurality of nodes according to the plurality of node addresses, wherein the transaction position query request comprises the summary hash of the transaction;
and verifying the credibility of the alliance chain containing the transaction information according to the consistency degree of the position query results respectively returned by the plurality of nodes.
In a third aspect, an embodiment of the present specification further provides a method for processing a request in a federation chain, where a node is a node in the federation chain, the method includes:
the node determines the user identification of the node user of the node, and determines a white list consisting of the user identification, wherein the user identification is used for identifying the user identity and identifying the node butted with the user;
and sending a white list to other nodes in the alliance chain so that other nodes can determine whether to execute a request sent by a non-self node user according to the white list, wherein the request comprises a transaction position inquiry request or a Simple Payment Verification (SPV) request, and the request comprises the digest hash of the target transaction.
Corresponding to the first aspect, embodiments of the present specification further provide a trust level verification system for a federation chain, including a client and a federation chain network, where the federation chain network includes a plurality of nodes; after a transaction is generated at a client and the transaction is linked and stored through a docking node,
a client acquires a plurality of node addresses in a alliance chain; sending a transaction position query request to the plurality of nodes according to the plurality of node addresses, wherein the transaction position query request comprises the summary hash of the transaction;
any node in the alliance chain network receives the position query request, the position information of the transaction corresponding to the digest hash in the alliance chain is queried based on the digest hash, and the position query result is returned to the client;
and the client verifies the credibility of the alliance chain containing the transaction information based on the consistency degree of the position inquiry results respectively returned by the plurality of nodes.
In accordance with a second aspect, an embodiment of the present specification further provides an apparatus for verifying trust of a federation chain, where after a user generates a transaction and stores a chain certificate of the transaction through a docking node, the apparatus includes:
the acquisition module acquires a plurality of node addresses in a alliance chain;
the sending module is used for sending a transaction position query request to the nodes according to the node addresses, wherein the transaction position query request comprises the abstract hash of the transaction;
the receiving module is used for receiving the position query results respectively returned by the nodes;
and the verification module verifies the credibility of the alliance chain containing the transaction information according to the consistency degree of the position query result.
Corresponding to the third aspect, an embodiment of the present specification further provides a request processing apparatus in a federation chain, where the request processing apparatus is located on a node in the federation chain, and includes:
the determining module is used for determining the user identification of the node user of the determining module and determining a white list consisting of the user identification, wherein the user identification is used for identifying the user identity and identifying the node butted with the user;
and the sending module is used for sending the white list to other nodes in the alliance chain so that other nodes can determine whether to execute a request sent by a non-self node user according to the white list, wherein the request comprises a transaction position inquiry request or a Simple Payment Verification (SPV) request, and the request comprises the digest hash of the target transaction.
In the solution provided in the embodiment of the present specification, after the client completes the transaction chain deposit through the docking node, for the transaction, the client initiates a transaction location query request to a plurality of nodes in the federation chain, so that respective location query results of the plurality of nodes for the transaction can be obtained. Furthermore, the credibility of the alliance chain can be verified based on the consistency degree of the position query results of the nodes, and the user experience is improved.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of embodiments of the invention.
In addition, any one of the embodiments in the present specification is not required to achieve all of the effects described above.
Drawings
In order to more clearly illustrate the embodiments of the present specification or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the embodiments of the present specification, and other drawings can be obtained by those skilled in the art according to the drawings.
FIG. 1 is a schematic diagram of an architecture involved in the current federation chain;
FIG. 2 is a flow diagram illustrating a method for trustworthiness verification of a federation chain in accordance with aspects of the system provided by embodiments of the present specification;
FIG. 3 is a flowchart illustrating a method for verifying trust of a federation chain on the client side according to an embodiment;
FIG. 4 is a flowchart illustrating a method for processing a request in a federation chain according to an embodiment of the present disclosure;
fig. 5 is a schematic structural diagram of a trust verification apparatus provided in an embodiment of the present disclosure;
fig. 6 is a schematic structural diagram of a request processing apparatus according to an embodiment of the present disclosure;
fig. 7 is a schematic diagram of a device for configuring the method of the embodiments of the present description.
Detailed Description
In order to make those skilled in the art better understand the technical solutions in the embodiments of the present specification, the technical solutions in the embodiments of the present specification will be described in detail below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all the embodiments. All other embodiments that can be derived by one of ordinary skill in the art from the embodiments given herein are intended to be within the scope of protection.
A plurality of different functional nodes are usually included in the federation chain, and currently, an architecture commonly adopted in the federation chain is that each functional node faces to each user, and the user accesses the federation chain through the functional node in which the user is interested.
The nodes in the federation chain to which embodiments of the present specification refer may each be considered to participate in the routing functions of the network of the federation chain, and may also include other functions, for example, each node may participate in verifying and propagating transaction and block information, discovering and maintaining connections with peer nodes, and may also have the complete federation chain stored locally, along with some data associated with the federation chain.
As shown in fig. 1, fig. 1 is an architecture involved in the current federation chain. In fig. 1, nodes in a federation chain network may all include different functions, and because each node provides different functions, target users facing each node are often different, and in the same federation chain, each functional node also often develops its own APP to allow its own node user to register and access. And the user usually selects a node from the user to connect with the alliance chain, and the transaction is issued and verified.
The technical solutions provided by the embodiments of the present description are described in detail below with reference to the accompanying drawings. In a first aspect of the solution of the embodiment of the present specification, as shown in fig. 2, fig. 2 is a schematic flowchart of a method for verifying trust of a federation chain in a system aspect provided in the embodiment of the present specification, where after a client generates a transaction and links the transaction with a certificate through a docking node, the process specifically includes the following steps:
s201, the client acquires a plurality of node addresses in the alliance chain.
Known to the client is the address of the docking node, from which other node addresses in the federation chain may request to be obtained. The node address list may also be obtained in other manners, for example, all nodes in the federation chain periodically issue their own addresses to a certain public cloud, the client locally stores an address list, and the client periodically obtains the addresses of all nodes from the public cloud to update the address list, so that a plurality of node addresses may be selected from the address list at any time. By the method, the docking node of the client can be bypassed, and the trust degree of the user on the whole alliance chain is improved.
S203, sending a transaction position query request to the plurality of nodes according to the plurality of node addresses, wherein the transaction position query request comprises the summary hash of the transaction.
Since after the user completes the transaction and connects the certificate to the node, a notification message about the certificate transaction is received, which typically includes the digest hash, and is stored locally at the ue. Therefore, the client can always obtain the digest hash from the local and add it to the transaction location query request.
On the aspect of the client, after receiving the notification message, initiating a query request according to the instruction of the user; alternatively, the query request may be triggered upon receipt of the notification message.
S205, any node receives the position query request, queries the position information of the transaction in the alliance chain corresponding to the digest hash based on the digest hash, and returns the position query result to the client.
A block chain is composed of a plurality of blocks, and a block usually contains a plurality of transactions. Therefore, in the embodiment of the present specification, the location information specifically refers to which block in the block chain the transaction is deposited, and what location in the block.
In a block chain, there are a number of ways to identify different blocks, e.g., block header hash values or block heights (block heights). The block header hash value is a hash value obtained by performing hash calculation on a block header, and can be used for uniquely and definitely identifying one block. In a block chain, the block height of the first block is usually 0, and the block height is increased by 1 every time a block is added later. A block typically has a definite block height. Thus, the chunk header hash value or chunk height may be stored as part of the chunk metadata in a separate database table in the node to facilitate indexing and faster retrieval of the chunk.
Meanwhile, in a block, since a plurality of transactions are usually included, the address offset of each transaction in the block can be used to identify the transaction in the block. Obviously, the address offset of each transaction is not the same in the same block.
Furthermore, after chain deposit of the certificate on the block at the exchange, a data table such as (transaction digest hash, block header hash value, address offset) or (transaction digest hash, block height, address offset) may be maintained in each node, so that the corresponding block identifier and the address of the transaction in the block may be obtained through query of the transaction digest hash. In other words, the node may determine the location of the transaction in the federation chain by the digest hash of the transaction.
Of course, since the specific format of the block chain is customizable, the content of the location information may also be different in different block formats, which does not constitute a limitation to the present solution. In addition, it should be noted that the request received by any node may be directly from the client, or may be a request for receiving a client forwarded by other nodes in the federation chain.
And S207, verifying the credibility of the alliance chain containing the transaction information by the client based on the consistency degree of the position query results respectively returned by the plurality of nodes.
After the query is finished, each node can return the query result to the client. It should be noted that the process may be an asynchronous process, and the client does not need to feed back the result immediately after sending the query request. Therefore, the client can wait for all nodes to return a query result and then verify the query result.
Since a transaction will have only one defined location in the federation chain, the trustworthiness of the federation chain can be based on the degree of agreement of the query results. Theoretically, the position information returned by each node should be identical. A more strict verification method is that if all the location query results are consistent, the federation chain is trusted. Of course, certain deviations may be tolerated for various network reasons, device reasons, and so forth. For example, the degree of agreement is calculated according to all the returned results, if the returned results do not have the same query result with the percentage exceeding 95%, the federation degree reliability is regarded as 0, otherwise, the percentage of the same result is regarded as the reliability of the federation chain.
Further, an alert may also be issued when it is determined that the federation chain is not trusted. Specifically, the alarm message may indicate how much the query results of the nodes are inconsistent (i.e., how many or how many proportions are inconsistent with the majority of the results), and specifically indicate the nodes inconsistent with the majority of the results and the query results of the nodes.
In the solution provided in the embodiment of the present specification, after a user completes an uplink transaction deposit through a docking node, for the transaction, the user initiates a transaction location query request to a plurality of nodes in a federation chain, so that respective query results of the plurality of nodes for the transaction can be obtained. Furthermore, the credibility of the alliance chain can be verified based on the consistency degree of the position query results of the nodes, and the user experience is improved.
In a specific implementation manner, the client acquires the plurality of node addresses in the federation chain, which may be that the client randomly acquires the plurality of node addresses in the federation chain, and on one hand, the randomly acquired node address verification can make the verification result more fair, and on the other hand, can also make the request of the user flow to each node in an average manner, thereby avoiding that the load of some nodes with more users is too heavy. Or, the client obtains a plurality of node addresses including the docking node address in the federation chain, and in this way, the user may first select a batch of node addresses and then add the address of the docking node. When the butt joint node is added for verification, the returned result also contains the verification result of the butt joint node, so that the verification is more targeted, and the user experience is improved.
In a specific embodiment, the user may further send a simple payment verification SPV request to the plurality of nodes according to the plurality of node addresses, where the SPV request includes a digest hash of the transaction. And any node respectively verifies whether the transaction corresponding to the digest hash is in the alliance chain based on the digest hash, generates an SPV verification result and returns the SPV verification result to the client. And the client verifies the credibility of the alliance chain containing the transaction information based on the SPV verification results respectively returned by the nodes.
In each block of the block chain, all transactions recorded in that block are contained and can be represented in the merkel Merkle tree. All transactions in a block hash the data and then store the hash value into the corresponding leaf node. One leaf node in the tree indicates that there is a corresponding transaction in the block. To prove that there is a particular target transaction in a block, a node need only compute log2And forming a Merkle path from the target transaction to the tree root by the N hash values.
Nodes do not have to save all transactions and download entire blocks when performing Simple Payment Verification (SPV). The node may simply save the chunk header and verify whether the target transaction exists in the chunk by its hash and Merkle path. In other words, the SPV verification result of each node is a binary result, either yes or no.
Since a transaction exists or does not exist in the federation chain, theoretically, when there is no problem in the federation chain, the SPV verification results returned by each node should be identical. Therefore, a more strict way to confirm the trustworthiness is to confirm that the federation chain is trustworthy if all SPV verification results are consistent to "yes", and is not trustworthy otherwise. Of course, certain deviations may be tolerated for various network reasons, device reasons, and so forth. For example, a threshold is set, and if the SPV verification result is consistent to a degree of "yes" exceeding the threshold, the federation chain is confirmed to be authentic.
Further, an alert may also be issued when the federation chain is confirmed to be untrustworthy. Specifically, the alarm message may indicate how much the query results of the nodes are inconsistent (i.e., how many the results of "yes" and "no" are respectively), and specifically indicate the nodes and the query results of the type of nodes that are inconsistent with the majority of the results. And, a confidence value may also be calculated for reference based on the degree of inconsistency of all results returned. For example, if the same query result whose percentage exceeds a certain threshold does not exist in the returned results, the federation level is considered to be trusted, otherwise, the federation chain is considered to be untrusted.
It should be noted that the above-mentioned scheme of performing verification based on the consistency of the result of the location query and the scheme of performing verification based on the consistency of the result of the SPV verification belong to 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 may select only one way to perform the authentication, or may select two ways to perform the authentication at the same time, and when the two authentication schemes are performed at the same time, the results of the two authentication schemes are required to satisfy the consistency condition at the same time, and the federation chain is considered to be trusted. And in the verification process, the two schemes are not executed in sequence.
Since in a federation chain, each functional node typically has its own docking client and corresponding docking user. In the solution of the embodiment of the present specification, each node often needs to process a request from a non-self node user.
In one embodiment, a node may process a query request or SPV request sent by any client connected to itself. In another embodiment, based on the principle of federation sharing, each node may further provide a query service or an SPV service to the white list user, and if the client sending the request is identified on the white list, the processing is performed, otherwise, the processing is not performed.
The specific way of determining the white list user includes: any node in the alliance chain determines the white list of the node, and broadcasts the white list to other nodes in the alliance chain, so that the other nodes can determine whether to execute query processing according to the white list. One common processing method is that any node in the federation chain determines its registered user as a white list user and broadcasts the white list user. And other nodes can decide whether to perform further processing according to whether the client identifier contained in the request is a white list user. The white list may use a node as the minimum unit, or may use a user as the minimum unit, and the white list users stored in each node may be the same or different. And the node receives the request sent by the white list user and processes the request.
For example, assuming that there are A, B, C, D four nodes in the federation chain, in the above scheme, the node B, C, D may identify the docking user of the node a as a white list user, and the four nodes are maintained together; the user of node a may also be included in the white-listed users of node B, but not included in the white-listed users of node C, D. The specific situation can be determined on its own based on the traffic situation.
In a more general case, the docking users of government agencies (e.g., notary offices) or public welfare agency (e.g., charity offices) nodes may be white-listed users of other nodes in all federation chains, and the node users of a business partner node of a node may also be white-listed users of that node. Further, the white list users may also be ranked in authority according to the source or historical behavior data of the users and other factors (e.g., third party credit rating score), for example, the white list user with the lowest authority has only inquiry authority, the white list user with higher authority may also have further other authority, and so on.
In practical application, the number of users of each node in one federation chain is different, and there are more nodes and fewer nodes. Generally, the number of docking users of those nodes directly facing the market is always more than the number of some rear nodes. For example, in a federation chain for copyright protection, there are always far more registered users facing the creator's work distribution platform than there are registered users at a notary.
Then in this case, the scheme of the embodiment of the present specification, each node in the federation is not "fair" with respect to request processing. In other words, the nodes with few registered users will always receive more requests than the nodes with few registered users should be responsible for processing, which is not very beneficial for the nodes with few registered users.
At this time, an implementable manner is that when any node receives a request and decides to process, a judgment is made first to determine a first processing frequency of the node for determining a location query request initiated by the user of another node, and to determine a second processing frequency of the user of the node for determining a location query request initiated by the user of the other node; and judging whether the position inquiry request is delayed to be processed or not according to the first processing times and the second processing times.
The first processing number and the second processing number may be periodically cleared in a period of time, for example, every day or every month, or may be a count of the number of the entire history data. The condition for determining whether to delay the processing may be to compare a contribution ratio value Z obtained by calculation according to the first processing time number X and the second processing time number Y with a preset threshold, for example, Z ═ X-Y/Y, or Z ═ X/Y, and the like. The contribution proportion value represents the proportion of self contribution and request others of a node when processing a request, once the contribution proportion value exceeds a certain threshold value, the node indicates that the node has processed more requests, the node can delay processing of the received requests sent by other node users, and the delay processing of the requests can effectively reduce the load of weak nodes (namely, nodes with few registered users and relatively weak processing capacity for large flow). In the solution of the embodiment of the present specification, the client does not need to obtain the verification result immediately, so that the processing of the request by each node may be asynchronous, and the effect of the solution of the embodiment of the present specification is not affected by the delayed processing.
In one embodiment, when the client selects multiple nodes, it may select the same node multiple times continuously, in this way, the client may determine whether the number of times of sending the transaction location query request to the node reaches the threshold, and if so, delay sending the transaction location query request to the node. The statistics of the number of times of transmission may be statistics of the number of times within a period of time, or statistics of all historical times. By the method, continuous requests for another node can be avoided on the client side, and the influence on the load of the other node is reduced.
A second aspect of the solution of the embodiment of the present specification, as shown in fig. 3, fig. 3 is a flowchart illustrating a method for verifying the trustworthiness of a federation chain in a client side provided by the embodiment, where after a user generates a transaction and uploads the transaction with a certificate through a docking node, the method includes:
s301, acquiring a plurality of node addresses in a alliance chain, wherein the specific mode comprises the steps of randomly acquiring the plurality of node addresses in the alliance chain; or acquiring a plurality of node addresses including the docking node address in the alliance chain.
S303, sending a transaction position query request to the plurality of nodes according to the plurality of node addresses, wherein the transaction position query request comprises the summary hash of the transaction;
s305, verifying the credibility of the alliance chain containing the transaction information according to the consistency degree of the position inquiry results respectively returned by the plurality of nodes.
Further, the method also includes sending, to the plurality of nodes, an SPV request for simple payment verification according to the plurality of node addresses, where the SPV request includes a digest hash of the transaction; receiving SPV verification results respectively returned by the plurality of nodes, and verifying the credibility of the alliance chain containing the transaction information.
Further, the sending of the transaction location query request to the plurality of nodes in S303 includes, for any node in the plurality of nodes, determining whether the number of sending times of the transaction location query request to the node reaches a threshold, and if so, delaying sending of the transaction location query request to the node.
A third aspect of the solution in the embodiment of the present specification, as shown in fig. 4, fig. 4 is a flowchart illustrating a method for processing a request of a federation chain according to the embodiment, where after a user generates a transaction and links the transaction with a certificate through a docking node, the method includes:
s401, the node determines the user identification of the node user of the node, and determines a white list consisting of the user identification, wherein the user identification is used for identifying the user identity and identifying the node butted with the user; in the federation chain, the user identifier may include information about the docking node in a format negotiated in advance, for example, a different sequence number is added to the beginning of the user identifier to identify the docking node of the user.
And S403, sending the white list to other nodes in the alliance chain so that other nodes can determine whether to execute a request sent by a non-self node user according to the white list, wherein the request comprises a transaction position query request or a Simple Payment Verification (SPV) request, and the request comprises the digest hash of the target transaction.
Further, the method further includes that the node receives a request sent by any user, and the request also includes a user identifier; and judging whether the user identification is in a white list, if not, not executing the processing to the request.
Further, the method further includes receiving a request sent by any user, where the request further includes a user identifier, and when a user corresponding to the user identifier is not a node user of the user: determining a first processing frequency of the node for the request initiated by the user of the other node, and confirming a second processing frequency of the other node for the request initiated by the user of the node; and judging whether to delay the processing of the request or not according to the first processing times and the second processing times.
Corresponding to the first aspect, embodiments of the present specification further provide a federation chain trust verification system, including a client and a federation chain network, where the federation chain network includes a plurality of nodes; after a transaction is generated at a client and the transaction is linked and stored through a docking node,
a client acquires a plurality of node addresses in a alliance chain; sending a transaction position query request to the plurality of nodes according to the plurality of node addresses, wherein the transaction position query request comprises the summary hash of the transaction;
any node in the alliance chain network receives the position query request, the position information of the transaction corresponding to the digest hash in the alliance chain is queried based on the digest hash, and the position query result is returned to the client;
and the client verifies the credibility of the alliance chain containing the transaction information based on the consistency degree of the position inquiry results respectively returned by the plurality of nodes.
Further, in the system, the client randomly acquires a plurality of node addresses in a alliance chain; or the client acquires a plurality of node addresses including the docking node address in the alliance chain.
Further, in the system, a client sends a Simple Payment Verification (SPV) request to the plurality of nodes according to the plurality of node addresses, wherein the SPV request comprises the digest hash of the transaction; any node respectively verifies whether the transaction corresponding to the digest hash is in the alliance chain based on the digest hash, generates an SPV verification result, and returns the SPV verification result to the client; and the client verifies the credibility of the alliance chain containing the transaction information based on the SPV verification results respectively returned by the nodes.
Further, in the system, before the client acquires the addresses of the plurality of nodes in the federation chain, any node in the federation chain determines a white list of the node and broadcasts the white list to other nodes in the federation chain, so that the other nodes determine whether to execute query processing according to the white list; the transaction location query request including the digest hash of the transaction includes: the transaction position query request comprises the summary hash of the transaction and the client identification; after any node receives the location query request, the method further comprises: and determining whether the client identifier contained in the position query request is in a white list, and if not, not executing query processing.
Further, in the system, the node determines a first processing time of the node for the location query request initiated by the user of the other node, and confirms a second processing time of the other node for the location query request initiated by the user of the node; and judging whether the position inquiry request is delayed to be processed or not according to the first processing times and the second processing times.
Further, in the system, the client determines, for any one of the plurality of nodes, whether the number of times of sending the transaction location query request to the node reaches a threshold, and if so, delays sending the transaction location query request to the node
Corresponding to the second aspect, an embodiment of the present specification further provides a trust verification apparatus for a federation chain, where after a user generates a transaction and links the transaction with a certificate through a docking node, as shown in fig. 5, fig. 5 is a schematic structural diagram of the trust verification apparatus provided in the embodiment of the present specification, where the apparatus includes:
an obtaining module 501, configured to obtain multiple node addresses in a federation chain;
a sending module 503, configured to send a transaction location query request to the plurality of nodes according to the plurality of node addresses, where the transaction location query request includes a digest hash of the transaction;
a receiving module 505, configured to receive location query results returned by the multiple nodes respectively;
and the verification module 507 verifies the credibility of the alliance chain containing the transaction information according to the consistency degree of the position query result.
Further, the obtaining module 501 obtains a plurality of node addresses in a federation chain at random; or acquiring a plurality of node addresses including the docking node address in the alliance chain.
Further, the sending module 503 is further configured to send an SPV request for simple payment verification to the plurality of nodes according to the plurality of node addresses, where the SPV request includes the digest hash of the transaction; the receiving module 505 is configured to receive SPV verification results returned by the nodes respectively; 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 determines, for any node in the plurality of nodes, whether the sending frequency of the transaction location query request to the node reaches a threshold, and if so, delays sending the transaction location query request to the node.
Corresponding to the third aspect, an embodiment of the present specification further provides a request processing apparatus in a federation chain, where the request processing apparatus is located on a node in the federation chain, as shown in fig. 6, and fig. 6 is a schematic structural diagram of the request processing apparatus provided in the embodiment of the present specification, where the apparatus includes:
the determining module 601 is configured to determine a user identifier of a node user of the determining module, and then determine a white list consisting of the user identifiers, where the user identifier is used to identify a user identity and identify a node docked with the user;
the sending module 603 sends the white list to other nodes in the federation chain, so that the other nodes determine whether to execute a request sent by a non-self node user according to the white list, where the request includes a transaction location query request or a simple payment verification SPV request, and the request includes a digest hash of a target transaction.
Further, the apparatus further includes a receiving module 605, configured to receive a request sent by any user, where the request further includes a user identifier; the determining module 607 determines whether the user identifier is in the white list, and if not, does not perform processing on the request.
Further, the receiving module 605 receives a request sent by any user, where the request further includes a user identifier, and when the user corresponding to the user identifier is not a node user of the user, the determining module 601 is further configured to determine a first processing number of times of the node for a request initiated by a user of another node, and determine a second processing number of times of the request initiated by the user of the node for another node; the determining module 607 is further configured to determine whether to delay processing the request according to the first processing frequency and the second processing frequency.
Embodiments of the present specification also provide a computer device including at least a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor, when executing the program, implements the method for verifying trustworthiness of a federation chain as shown in fig. 3.
Embodiments of the present specification also provide a computer device, which at least includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the request processing method in the federation chain shown in fig. 4 when executing the program.
Fig. 7 is a more specific hardware structure diagram of a computing device provided in an embodiment of the present specification, where the device may include: a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050. Wherein the processor 1010, memory 1020, input/output interface 1030, and communication interface 1040 are communicatively coupled to each other within the device via bus 1050.
The processor 1010 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an Application Specific Integrated Circuit (ASIC), or one or more Integrated circuits, and is configured to execute related programs to implement the technical solutions provided in the embodiments of the present disclosure.
The Memory 1020 may be implemented in the form of a ROM (Read Only Memory), a RAM (Random access Memory), a static storage device, a dynamic storage device, or the like. The memory 1020 may store an operating system and other application programs, and when the technical solution provided by the embodiments of the present specification is implemented by software or firmware, the relevant program codes are stored in the memory 1020 and called to be executed by the processor 1010.
The input/output interface 1030 is used for connecting an input/output module to input and output information. The i/o module may be configured as a component in a device (not shown) or may be external to the device to provide a corresponding function. The input devices may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output devices may include a display, a speaker, a vibrator, an indicator light, etc.
The communication interface 1040 is used for connecting a communication module (not shown in the drawings) to implement communication interaction between the present apparatus and other apparatuses. The communication module can realize communication in a wired mode (such as USB, network cable and the like) and also can realize communication in a wireless mode (such as mobile network, WIFI, Bluetooth and the like).
It should be noted that although the above-mentioned device only shows the processor 1010, the memory 1020, the input/output interface 1030, the communication interface 1040 and the bus 1050, in a specific implementation, the device may also include other components necessary for normal operation. In addition, those skilled in the art will appreciate that the above-described apparatus may also include only those components necessary to implement the embodiments of the present description, and not necessarily all of the components shown in the figures.
Embodiments of the present specification also provide a computer-readable storage medium on which a computer program is stored, where the computer program, when executed by a processor, implements the method for verifying trustworthiness of a federation chain as shown in fig. 3.
Embodiments of the present specification also provide another computer-readable storage medium, on which a computer program is stored, which when executed by a processor implements the request processing method in the federation chain shown in fig. 4.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, 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 Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
From the above description of the embodiments, it is clear to those skilled in the art that the embodiments of the present disclosure can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the embodiments of the present specification may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments of the present specification.
The systems, methods, modules or units described in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, as for the method embodiment, since it is substantially similar to the method embodiment, it is relatively simple to describe, and reference may be made to the partial description of the method embodiment for relevant points. The above-described method embodiments are merely illustrative, wherein the modules described as separate components may or may not be physically separate, and the functions of the modules may be implemented in one or more software and/or hardware when implementing the embodiments of the present specification. And part or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.
The foregoing is only a specific embodiment of the embodiments of the present disclosure, and it should be noted that, for those skilled in the art, a plurality of modifications and decorations can be made without departing from the principle of the embodiments of the present disclosure, and these modifications and decorations should also be regarded as the protection scope of the embodiments of the present disclosure.
Claims (28)
1. A method for verifying credibility of a alliance chain comprises the following steps that after a transaction is generated at a client side and the transaction is chain-certified through a docking node, the method comprises the following steps:
a client acquires a plurality of node addresses in a alliance chain;
sending a transaction position query request to the plurality of nodes according to the plurality of node addresses, wherein the transaction position query request comprises the summary hash of the transaction;
any node receives the position query request, queries the position information of the transaction in the alliance chain corresponding to the digest hash based on the digest hash, and returns the position query result to the client;
and the client verifies the credibility of the alliance chain containing the transaction information based on the consistency degree of the position inquiry results respectively returned by the plurality of nodes.
2. The method of claim 1, wherein the client obtains a plurality of node addresses in a federation chain, comprising:
a client randomly acquires a plurality of node addresses in a alliance chain; alternatively, the first and second electrodes may be,
and the client acquires a plurality of node addresses including the docking node address in the alliance chain.
3. The method of claim 1, further comprising:
the client sends a Simple Payment Verification (SPV) request to the plurality of nodes according to the plurality of node addresses, wherein the SPV request comprises the digest hash of the transaction;
any node respectively verifies whether the transaction corresponding to the digest hash is in the alliance chain based on the digest hash, generates an SPV verification result, and returns the SPV verification result to the client;
and the client verifies the credibility of the alliance chain containing the transaction information based on the SPV verification results respectively returned by the nodes.
4. The method of claim 1, prior to the client obtaining the plurality of node addresses in the federation chain, the method further comprising:
any node in the alliance chain determines a white list of the node, and broadcasts the white list to other nodes in the alliance chain, so that the other nodes can determine whether to execute query processing according to the white list;
the transaction location query request including the digest hash of the transaction includes: the transaction position query request comprises the summary hash of the transaction and the client identification;
after any node receives the location query request, the method further comprises: and determining whether the client identifier contained in the position query request is in a white list, and if not, not executing query processing.
5. The method of claim 1, after any node receives the location query request, the method further comprising:
the node determines the first processing times of the node for the position query request initiated by the user of other nodes, and confirms the second processing times of the position query request initiated by the user of the node for other nodes;
and judging whether the position inquiry request is delayed to be processed or not according to the first processing times and the second processing times.
6. The method of claim 1, sending transaction location query requests to the plurality of nodes, comprising:
and aiming at any node in the plurality of nodes, judging whether the sending times of the transaction position query request of the node reaches a threshold value, if so, delaying to send the transaction position query request to the node.
7. A method for verifying credibility of a alliance chain comprises the following steps that after a user generates a transaction and the transaction is chain-certified through a docking node, the method comprises the following steps:
acquiring a plurality of node addresses in a alliance chain;
sending a transaction position query request to the plurality of nodes according to the plurality of node addresses, wherein the transaction position query request comprises the summary hash of the transaction;
and verifying the credibility of the alliance chain containing the transaction information according to the consistency degree of the position query results respectively returned by the plurality of nodes.
8. The method of claim 7, obtaining a plurality of node addresses in a federation chain, comprising:
randomly acquiring a plurality of node addresses in a alliance chain; alternatively, the first and second electrodes may be,
and acquiring a plurality of node addresses including the docking node address in the alliance chain.
9. The method of claim 7, further comprising:
sending a Simple Payment Verification (SPV) request to the plurality of nodes according to the plurality of node addresses, wherein the SPV request comprises the digest hash of the transaction;
receiving SPV verification results respectively returned by the plurality of nodes, and verifying the credibility of the alliance chain containing the transaction information.
10. The method of claim 7, sending transaction location query requests to the plurality of nodes, comprising:
and aiming at any node in the plurality of nodes, judging whether the sending times of the transaction position query request of the node reaches a threshold value, if so, delaying to send the transaction position query request to the node.
11. A request processing method in a federation chain comprises the following steps that when a node is a node in the federation chain:
the node determines the user identification of the node user of the node, and determines a white list consisting of the user identification, wherein the user identification is used for identifying the user identity and identifying the node butted with the user;
sending a white list to other nodes in a alliance chain so that other nodes can determine whether to execute a request sent by a non-self node user according to the white list, wherein the request comprises a transaction position inquiry request or a Simple Payment Verification (SPV) request, and the request comprises the digest hash of a target transaction;
the method comprises the steps that any node in the alliance chain network receiving a request respectively inquires position information of a transaction corresponding to the digest hash in the request in the alliance chain based on the digest hash in the request, and returns a position inquiry result to a client, and the client verifies the credibility of the alliance chain containing the transaction information based on the consistency degree of the position inquiry results returned by the nodes respectively.
12. The request processing method of claim 11, comprising:
a node receives a request sent by any user, wherein the request also comprises a user identifier;
and judging whether the user identification is in a white list, if not, not executing the processing to the request.
13. The method of claim 11, further comprising:
receiving a request sent by any user, wherein the request also comprises a user identifier, and when the user corresponding to the user identifier is not the node user of the user, the method comprises the following steps:
determining a first processing frequency of the node for the request initiated by the user of the other node, and confirming a second processing frequency of the other node for the request initiated by the user of the node;
and judging whether to delay the processing of the request or not according to the first processing times and the second processing times.
14. A credibility verification system of a alliance chain comprises a client and an alliance chain network, wherein the alliance chain network comprises a plurality of nodes; after a transaction is generated at a client and the transaction is linked and stored through a docking node,
a client acquires a plurality of node addresses in a alliance chain; sending a transaction position query request to the plurality of nodes according to the plurality of node addresses, wherein the transaction position query request comprises the summary hash of the transaction;
any node in the alliance chain network receives the position query request, the position information of the transaction corresponding to the digest hash in the alliance chain is queried based on the digest hash, and the position query result is returned to the client;
and the client verifies the credibility of the alliance chain containing the transaction information based on the consistency degree of the position inquiry results respectively returned by the plurality of nodes.
15. The system of claim 14, the client randomly obtains a plurality of node addresses in a federation chain; or the client acquires a plurality of node addresses including the docking node address in the alliance chain.
16. The system of claim 14, wherein the first and second sensors are arranged in a single unit,
the client sends a Simple Payment Verification (SPV) request to the plurality of nodes according to the plurality of node addresses, wherein the SPV request comprises the digest hash of the transaction;
any node respectively verifies whether the transaction corresponding to the digest hash is in the alliance chain based on the digest hash, generates an SPV verification result, and returns the SPV verification result to the client;
and the client verifies the credibility of the alliance chain containing the transaction information based on the SPV verification results respectively returned by the nodes.
17. The system of claim 14, prior to the client obtaining the plurality of node addresses in the federation chain,
any node in the alliance chain determines a white list of the node, and broadcasts the white list to other nodes in the alliance chain, so that the other nodes can determine whether to execute query processing according to the white list;
the transaction location query request including the digest hash of the transaction includes: the transaction position query request comprises the summary hash of the transaction and the client identification;
after any node receives the location query request, the method further comprises: and determining whether the client identifier contained in the position query request is in a white list, and if not, not executing query processing.
18. The system of claim 14, after any node receives the location query request,
the node determines the first processing times of the node for the position query request initiated by the user of other nodes, and confirms the second processing times of the position query request initiated by the user of the node for other nodes;
and judging whether the position inquiry request is delayed to be processed or not according to the first processing times and the second processing times.
19. The system of claim 14, wherein the client determines, for any node of the plurality of nodes, whether the number of times the transaction location query request is sent to the node reaches a threshold, and if so, delays sending the transaction location query request to the node.
20. An apparatus for verifying trust of a federation chain, after a user generates a transaction and installs a chain certificate on the transaction through a docking node, the apparatus comprising:
the acquisition module acquires a plurality of node addresses in a alliance chain;
the sending module is used for sending a transaction position query request to the nodes according to the node addresses, wherein the transaction position query request comprises the abstract hash of the transaction;
the receiving module is used for receiving the position query results respectively returned by the nodes;
and the verification module verifies the credibility of the alliance chain containing the transaction information according to the consistency degree of the position query result.
21. The apparatus of claim 20, the obtaining module randomly obtains a plurality of node addresses in a federation chain; or acquiring a plurality of node addresses including the docking node address in the alliance chain.
22. The apparatus as set forth in claim 20, wherein,
the sending module is further configured to send an SPV request for simple payment verification to the plurality of nodes according to the plurality of node addresses, where the SPV request includes a digest hash of the transaction;
the receiving module receives SPV verification results respectively returned by the nodes;
and the verification module verifies the credibility of the alliance chain containing the transaction information according to the SPV verification result.
23. The apparatus of claim 20, wherein the sending module determines, for any node of the plurality of nodes, whether the number of times the transaction location query request is sent to the node reaches a threshold, and if so, delays sending the transaction location query request to the node.
24. A request processing apparatus in a federation chain, located at a node in the federation chain, comprising:
the determining module is used for determining the user identification of the node user of the determining module and determining a white list consisting of the user identification, wherein the user identification is used for identifying the user identity and identifying the node butted with the user;
the sending module is used for sending the white list to other nodes in the alliance chain so that other nodes can determine whether to execute a request sent by a non-self node user according to the white list, wherein the request comprises a transaction position inquiry request or a Simple Payment Verification (SPV) request, and the request comprises abstract hash of a target transaction;
the method comprises the steps that any node in the alliance chain network receiving a request respectively inquires position information of a transaction corresponding to the digest hash in the request in the alliance chain based on the digest hash in the request, and returns a position inquiry result to a client, and the client verifies the credibility of the alliance chain containing the transaction information based on the consistency degree of the position inquiry results returned by the nodes respectively.
25. The apparatus of claim 24, further comprising:
the receiving module is used for receiving a request sent by any user, and the request also comprises a user identifier;
and the judging module is used for judging whether the user identification is in a white list or not, and if not, the request is not processed.
26. The apparatus of claim 25, wherein the first and second electrodes are,
the receiving module receives a request sent by any user, the request also comprises a user identifier, and when the user corresponding to the user identifier is not the node user of the user, the receiving module:
the determining module is further used for determining a first processing frequency of the node for the request initiated by the user of the other node, and confirming a second processing frequency of the other node for the request initiated by the user of the node;
the judging module is further configured to judge whether to delay processing of the request according to the first processing frequency and the second processing frequency.
27. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of any of claims 7 to 10 when executing the program.
28. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of any one of claims 11 to 13 when executing the program.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811626394.6A CN110049087B (en) | 2018-12-28 | 2018-12-28 | Credibility verification method, system, device and equipment of alliance chain |
| TW108137659A TWI727467B (en) | 2018-12-28 | 2019-10-18 | Trustworthiness verification method, system, device and equipment of alliance chain |
| PCT/CN2019/116149 WO2020134624A1 (en) | 2018-12-28 | 2019-11-07 | Credibility verification method, system, apparatus and device for alliance chain |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811626394.6A CN110049087B (en) | 2018-12-28 | 2018-12-28 | Credibility verification method, system, device and equipment of alliance chain |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110049087A CN110049087A (en) | 2019-07-23 |
| CN110049087B true CN110049087B (en) | 2020-05-05 |
Family
ID=67274044
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811626394.6A Active CN110049087B (en) | 2018-12-28 | 2018-12-28 | Credibility verification method, system, device and equipment of alliance chain |
Country Status (3)
| Country | Link |
|---|---|
| CN (1) | CN110049087B (en) |
| TW (1) | TWI727467B (en) |
| WO (1) | WO2020134624A1 (en) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110022345B (en) * | 2018-12-28 | 2020-03-24 | 阿里巴巴集团控股有限公司 | Method, system, device and equipment for processing request in alliance chain |
| CN110049087B (en) * | 2018-12-28 | 2020-05-05 | 阿里巴巴集团控股有限公司 | Credibility verification method, system, device and equipment of alliance chain |
| CN110889729B (en) * | 2019-11-29 | 2024-03-26 | 腾讯科技（深圳）有限公司 | Data verification method and device based on blockchain network |
| CN111125256B (en) * | 2019-12-24 | 2023-10-31 | 深圳前海乐寻坊区块链科技有限公司 | Human credit authentication method, device, equipment and storage medium based on blockchain |
| CN113177767A (en) * | 2020-01-08 | 2021-07-27 | 福历科技(上海)有限公司 | Equipment data processing method and device based on kungfu chain |
| CN111400752A (en) * | 2020-03-12 | 2020-07-10 | 杭州城市大数据运营有限公司 | Data query method and system based on block chain and electronic equipment |
| CN111553669B (en) * | 2020-04-28 | 2021-09-10 | 腾讯科技（深圳）有限公司 | Transaction routing method, device and computer readable storage medium |
| CN111614646A (en) * | 2020-05-14 | 2020-09-01 | 杭州溪塔科技有限公司 | Malicious transaction deletion method and device for alliance chain and electronic equipment |
| TWI824173B (en) * | 2020-08-26 | 2023-12-01 | 中華電信股份有限公司 | A method of mixing public blockchains with private blockchains and computer readable medium |
| CN112511605B (en) * | 2020-11-17 | 2022-11-22 | 上海万向区块链股份公司 | Management method, system and medium based on equipment asynchronous polling uplink state |
| CN113159936A (en) * | 2021-05-27 | 2021-07-23 | 中国银行股份有限公司 | Block chain-based personal credit investigation method and device |
| CN114647668B (en) * | 2022-05-18 | 2022-09-23 | 南京金宁汇科技有限公司 | Transaction receipt query method and system applied to alliance chain |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107077674A (en) * | 2016-12-29 | 2017-08-18 | 深圳前海达闼云端智能科技有限公司 | Transaction verification processing method and device and node equipment |
| CN107247773A (en) * | 2017-06-07 | 2017-10-13 | 北京邮电大学 | A kind of method that inquiry is traded in distributed data base based on block chain |
| CN108681900A (en) * | 2018-07-18 | 2018-10-19 | 众安信息技术服务有限公司 | The method of light node verification transaction |
| CN108711052A (en) * | 2018-05-18 | 2018-10-26 | 电子科技大学 | A kind of information authentication system based on block chain |
| CN108764909A (en) * | 2018-06-01 | 2018-11-06 | 杭州复杂美科技有限公司 | A kind of block chain data monitoring and managing method |
| EP3413507A1 (en) * | 2017-06-09 | 2018-12-12 | Nokia Technologies Oy | Electronic documents certification |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105719185B (en) * | 2016-01-22 | 2019-02-15 | 杭州复杂美科技有限公司 | The data comparison and common recognition method of block chain |
| CN106503981A (en) * | 2016-10-19 | 2017-03-15 | 江苏通付盾科技有限公司 | Simple payment verification node Transaction Inquiries method and system |
| US20180181953A1 (en) * | 2016-12-22 | 2018-06-28 | Mastercard International Incorporated | Method and system for anonymous directed blockchain transaction |
| CN106850622B (en) * | 2017-02-07 | 2020-03-03 | 杭州秘猿科技有限公司 | User identity management method based on permission chain |
| CN107766542B (en) * | 2017-10-30 | 2020-09-11 | 上海分布信息科技有限公司 | Partitioned block chain network and method for realizing partitioned query thereof |
| CN108876611B (en) * | 2018-05-31 | 2021-05-18 | 中国联合网络通信集团有限公司 | Transaction information processing method and device and block link points |
| CN109064169B (en) * | 2018-07-13 | 2020-11-06 | 杭州复杂美科技有限公司 | Transaction method, apparatus and storage medium |
| CN109003082B (en) * | 2018-07-24 | 2021-11-09 | 电子科技大学 | PHEV energy transaction system based on alliance block chain and transaction method thereof |
| CN108965342B (en) * | 2018-09-28 | 2021-05-28 | 真相网络科技（北京）有限公司 | Authentication method and system for data requester to access data source |
| CN110049087B (en) * | 2018-12-28 | 2020-05-05 | 阿里巴巴集团控股有限公司 | Credibility verification method, system, device and equipment of alliance chain |
-
2018
- 2018-12-28 CN CN201811626394.6A patent/CN110049087B/en active Active
-
2019
- 2019-10-18 TW TW108137659A patent/TWI727467B/en active
- 2019-11-07 WO PCT/CN2019/116149 patent/WO2020134624A1/en active Application Filing
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107077674A (en) * | 2016-12-29 | 2017-08-18 | 深圳前海达闼云端智能科技有限公司 | Transaction verification processing method and device and node equipment |
| CN107247773A (en) * | 2017-06-07 | 2017-10-13 | 北京邮电大学 | A kind of method that inquiry is traded in distributed data base based on block chain |
| EP3413507A1 (en) * | 2017-06-09 | 2018-12-12 | Nokia Technologies Oy | Electronic documents certification |
| CN108711052A (en) * | 2018-05-18 | 2018-10-26 | 电子科技大学 | A kind of information authentication system based on block chain |
| CN108764909A (en) * | 2018-06-01 | 2018-11-06 | 杭州复杂美科技有限公司 | A kind of block chain data monitoring and managing method |
| CN108681900A (en) * | 2018-07-18 | 2018-10-19 | 众安信息技术服务有限公司 | The method of light node verification transaction |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2020134624A1 (en) | 2020-07-02 |
| CN110049087A (en) | 2019-07-23 |
| TW202027456A (en) | 2020-07-16 |
| TWI727467B (en) | 2021-05-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110049087B (en) | Credibility verification method, system, device and equipment of alliance chain | |
| CN110046901B (en) | Credibility verification method, system, device and equipment of alliance chain | |
| CN110022345B (en) | Method, system, device and equipment for processing request in alliance chain | |
| CN110163755B (en) | Block chain-based data compression and query method and device and electronic equipment | |
| CN110855777B (en) | Node management method and device based on block chain | |
| US20210336798A1 (en) | Signature verification for a blockchain ledger | |
| CN110400217B (en) | Rule change processing method and device for intelligent contract | |
| CN110020854B (en) | Data evidence storage method and system based on multiple block chain networks | |
| CN110060153B (en) | Data evidence storage method and system based on multiple block chain networks | |
| CN110020945B (en) | Data reading method and system based on multiple block chain networks | |
| US10790968B2 (en) | Ledger verification method and apparatus, and device | |
| CN112714158A (en) | Transaction processing method, relay network, cross-link gateway, system, medium, and device | |
| JP2022539283A (en) | A method and system for validating blockchain data stored in a storage format different from the blockchain | |
| CN110880147A (en) | Transaction processing method, related equipment and computer storage medium | |
| CN110928952A (en) | Data synchronization method and device based on block chain | |
| CN110060151B (en) | Service execution method and device | |
| CN112181599B (en) | Model training method, device and storage medium | |
| US20200177390A1 (en) | Providing data verification in a blockchain ledger | |
| CN112398924A (en) | Block chain node admission control method, block chain node admission control device, computer equipment and storage medium | |
| US11816714B2 (en) | Service verification method and apparatus | |
| CN109903023B (en) | Resource allocation method and system | |
| JP6088452B2 (en) | Database system and data update method | |
| CN115203676B (en) | Database connection method, database connection device, proxy server and medium | |
| CN115168872B (en) | Decentralized trust-based method for protecting TEE state continuity under public cloud | |
| CN113986915A (en) | Data storage method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20200924 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Patentee after: Innovative advanced technology Co.,Ltd. Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Patentee before: Advanced innovation technology Co.,Ltd. Effective date of registration: 20200924 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Patentee after: Advanced innovation technology Co.,Ltd. Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands Patentee before: Alibaba Group Holding Ltd. |
|
| TR01 | Transfer of patent right |