WO2020134624A1 - 一种联盟链的可信度验证方法、系统、装置及设备 - Google Patents

一种联盟链的可信度验证方法、系统、装置及设备 Download PDF

Info

Publication number
WO2020134624A1
WO2020134624A1 PCT/CN2019/116149 CN2019116149W WO2020134624A1 WO 2020134624 A1 WO2020134624 A1 WO 2020134624A1 CN 2019116149 W CN2019116149 W CN 2019116149W WO 2020134624 A1 WO2020134624 A1 WO 2020134624A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
transaction
alliance chain
request
nodes
Prior art date
Application number
PCT/CN2019/116149
Other languages
English (en)
French (fr)
Inventor
杨新颖
Original Assignee
阿里巴巴集团控股有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 阿里巴巴集团控股有限公司 filed Critical 阿里巴巴集团控股有限公司
Publication of WO2020134624A1 publication Critical patent/WO2020134624A1/zh

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

Definitions

  • the embodiments of the present specification relate to the field of information technology, and in particular, to a method, system, device, and device for verifying the reliability of the alliance chain.
  • a consortium chain there are often multiple nodes with very different functions.
  • a consortium chain for copyright deposit it may include work publishing nodes, copyright registration nodes, copyright transfer nodes, and notary nodes.
  • a user publishes a transaction through an application APP published by a node, and the alliance node deposits the transaction through the docking node, which is often performed through the docking node when verifying it later.
  • the embodiment of this specification provides a solution that allows users to verify the credibility of the alliance chain.
  • the first aspect of the solution includes a method for verifying the credibility of the alliance chain. After generating a transaction on the client and depositing the transaction on the chain through a docking node, it includes:
  • the client obtains the addresses of multiple nodes in the alliance chain
  • Any node receives the location query request, queries the location information of the transaction corresponding to the digest hash in the alliance chain based on the digest 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 consistency of the location query results returned by the multiple nodes.
  • the embodiment of the present specification also provides a method for verifying the credibility of a consortium chain. After a user generates a transaction and deposits the transaction on the chain through a docking node, it includes:
  • the credibility of the alliance chain containing the transaction information is verified according to the consistency of the location query results returned by the multiple nodes.
  • the embodiments of the present specification also provide a request processing method in the alliance chain.
  • the method includes:
  • the node determines the user ID of the user of its own node, and determines a white list composed of the user ID, wherein the user ID is used to identify the user identity, and is used to identify the node docked with the user;
  • the request includes a transaction location query request or a simple payment verification SPV request. Contains the digest hash of the target transaction.
  • the embodiment of the present specification also provides a credibility verification system of a consortium chain, including a client and a consortium chain network, the consortium chain network includes multiple nodes; a transaction is generated on the client terminal, and passed After the docking node deposits the transaction on the chain,
  • 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 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 digest hash in the alliance chain based on the digest hash, and returns the location query result to Client
  • the client verifies the credibility of the alliance chain containing the transaction information based on the consistency of the location query results returned by the multiple nodes.
  • the embodiment of the present specification also provides an alliance chain credibility verification device.
  • the device After a user generates a transaction and deposits the transaction on the chain through a docking node, the device includes:
  • Acquisition module to acquire multiple node addresses in the alliance chain
  • the sending module sends a transaction location query request to the plurality of nodes according to the multiple node addresses, where the transaction location query request includes a digest hash of the transaction;
  • a receiving module receiving the location query results respectively returned by the multiple nodes
  • the verification module verifies the credibility of the alliance chain containing the transaction information according to the consistency of the location query results.
  • an embodiment of the present specification also provides a request processing device in an alliance chain, which is located on a node in the alliance chain and includes:
  • the determining module determines the user ID of the user of the own node, and determines a white list composed of the user ID, wherein the user ID is used to identify the user identity, and is used to identify the node docked with the user;
  • the sending module sends 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.
  • the request includes a transaction location query request or a simple payment verification SPV request.
  • the request contains the digest hash of the target transaction.
  • the client after the client completes the transaction on-chain deposit certificate through the docking node, the client initiates a transaction location query request to multiple nodes in the alliance chain for the transaction, thereby obtaining multiple The node queries the results of the respective positions of the transaction. Furthermore, the credibility of the alliance chain can be verified based on the consistency of the location query results of multiple nodes, and the user experience can be improved.
  • 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 an alliance chain in terms of systems provided by embodiments of the present specification
  • FIG. 3 is a schematic flow chart of a method for verifying the credibility of a consortium chain provided by an embodiment of the client in 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 present specification.
  • FIG. 6 is a schematic structural diagram of a request processing apparatus provided by an embodiment of the present specification.
  • FIG. 7 is a schematic structural diagram of a device for configuring a method of an embodiment of this specification.
  • the alliance chain usually contains multiple different functional nodes.
  • an architecture commonly adopted by the alliance chain is that each functional node faces its own user, and the user accesses the alliance chain through the functional nodes they are interested in.
  • the nodes in the alliance chain involved in the embodiments of this specification can be considered that each node participates in the routing function of the alliance chain network, and can also include other functions, for example, each node can participate in the verification and propagation of transactions and blocks Information, find and maintain connections with peer nodes, and can also store a complete alliance chain locally, and some data related to the alliance chain.
  • Figure 1 is an architecture involved in the current alliance chain.
  • the nodes in the alliance chain network may all contain different functions, and because each node provides different functions, the target users are often different.
  • each functional node is often Develop their own application APP to allow their own node users to register and access. The user usually selects a node to connect to the alliance chain for transaction publishing and verification.
  • FIG. 2 is a schematic flow chart of a method for verifying the credibility of the alliance chain in the system aspect provided by the embodiment of this specification. After depositing the transaction on the chain through the docking node, the process specifically includes the following steps:
  • the client obtains addresses of multiple nodes in the alliance chain.
  • the address of the docking node is known, and the addresses of other nodes in the alliance chain can be obtained from 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, the client locally saves an address list, and the client periodically obtains the addresses 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, you can bypass the client's docking node and increase the user's trust in the entire alliance chain.
  • S203 Send a transaction location query request to the multiple nodes according to the multiple node addresses, where the transaction location query request includes a digest hash of the transaction.
  • the client After the user completes the transaction and deposits the certificate through the docking node, he will receive a notification message about the certificate transaction, which usually includes the digest hash and is stored locally on the client. Therefore, the client can always obtain the digest hash from the local and add it to the transaction location query request.
  • the query request may be initiated according to the user's instruction after receiving the notification message; or the query request may be triggered upon receiving the notification message.
  • Any node receives the location query request, queries the location information of the transaction corresponding to the digest hash in the alliance chain based on the digest 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 the present specification, the location information specifically refers to which block in the blockchain and where the block is located in the block when the transaction is deposited.
  • block header hash value is the hash value obtained by hash calculation of the block header, and can be used to uniquely and clearly identify a block.
  • the first block has a block height of 0, and for each additional block, the block height increases by 1.
  • a block usually has a clear block height. Therefore, the block header hash value or block height can be stored as a part of the block metadata in a separate database table in the node to facilitate indexing and faster retrieval of the block.
  • each node can maintain a form (transaction summary hash, block header hash value, address offset), or, (transaction summary ha Hope, block height, address offset) data table, you can get the corresponding block identification and transaction address in the block by querying the transaction summary hash.
  • the node can determine the position of the transaction in the alliance chain through the digest hash of the transaction.
  • the request received by any node may come directly from the client, or it may receive the client request forwarded by other nodes in the alliance chain.
  • the client verifies the credibility of the alliance chain containing the transaction information based on the consistency of the location query results returned by the multiple nodes.
  • each node After each node finishes the query, it can return the query result to the client. It should be noted that this process may be an asynchronous processing process, and the client does not need immediate feedback results after sending the query request. Therefore, the client can wait for all nodes to return a query result before verifying.
  • the credibility of the alliance chain can be determined based on the consistency of the query results.
  • the position information returned by each node should be exactly the same.
  • a stricter verification method is that if all location query results are consistent, the alliance chain is credible. Of course, due to various network reasons, equipment reasons, etc., a certain deviation can be tolerated. For example, based on the calculation of the consistency degree of all the returned results, if there is no same query result that accounts for more than 95% in the returned result, the alliance degree credibility is considered to be 0, otherwise, the same result is accounted for Than the credibility of the alliance chain.
  • the alert message can indicate the degree of inconsistency of the query results of each node (that is, how many or how many proportions are inconsistent with the majority of results), and, specifically give the nodes that are inconsistent with the majority of results and the query of such nodes result.
  • the user after the user completes the transaction on-chain deposit certificate through the docking node, the user initiates a transaction location query request to multiple nodes in the alliance chain for the transaction, so that multiple nodes can be obtained
  • the respective query results of the transaction Furthermore, the credibility of the alliance chain can be verified based on the consistency of the location query results of multiple nodes, and the user experience can be improved.
  • the client obtains the addresses of multiple nodes in the alliance chain, which may be
  • the client randomly obtains multiple node addresses in the alliance chain. Randomly obtaining the node address verification can make the verification result more fair on the one hand, and on the other hand, it can also make the user's request flow to each node evenly, avoiding certain users.
  • the node load is too heavy.
  • the client obtains multiple node addresses in the alliance chain that include the address of the docking node. In this way, the user can first select a batch of node addresses, and then add the address 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 the user experience.
  • the user may also send a simple payment verification SPV request to the multiple nodes according to the multiple node addresses, where the SPV request includes the digest hash of the transaction.
  • the SPV request includes the digest hash of the transaction.
  • 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 alliance chain containing the transaction information.
  • Each block of the blockchain contains all the transactions recorded in the block, and can be represented by the Merkle Merkle tree. 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 indicates that there is 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 2 N hash values to form a Merkle path from the target transaction to the root of the tree.
  • SPV verification result of each node is a binary result, either "yes" or "no".
  • the alert message can indicate the degree of inconsistency of the query results of each node (that is, the results of "yes” and “no” respectively), as well as specific nodes and nodes of this type that are inconsistent with most results.
  • Query results can indicate the degree of inconsistency of all returned results. For example, if there is no same query result whose proportion exceeds a certain threshold in the returned result, the alliance degree is considered credible; otherwise, the alliance chain is considered untrustworthy.
  • the above scheme for verifying based on the consistency of the location query result and the scheme for verifying based on the consistency of the SPV verification result belong to a scheme that can be performed separately.
  • the verification results of the two are independent.
  • the client can choose only one way to perform the verification, or it can choose two ways to perform the verification at the same time.
  • the two verification schemes are executed at the same time, the results of the two verification schemes need to meet the consistency condition at the same time. Credible. And, in the verification process, the two schemes are executed in no particular order.
  • each functional node usually has its own docking client and corresponding docking user.
  • each node often needs to process requests from users who are not its own nodes.
  • the node can process the query request or SPV request sent by any client connected to itself. In another embodiment, based on the principle of alliance sharing, each node can also provide a query service or SPV service to whitelist users. If the client identifier that sends the request is on the whitelist, it will be processed, otherwise, it will not be processed .
  • the specific method for determining whitelist 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 determine whether to perform query processing according to the whitelist.
  • a common processing 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 proceed further based on whether the client ID included in the request is a whitelist user.
  • the white list here may use the node as the minimum unit or the user as the minimum unit.
  • the users of the white list stored in each node may be the same or different. The node only processes the request sent by the whitelisted user.
  • nodes B, C, and D can confirm the docking users of node A as whitelist users, and the four nodes are maintained together; Node B's white list users include node A's users, but node C and D's white list users do not include node A's users.
  • the specific situation can be determined based on the business situation.
  • the docking users of the nodes of government agencies (such as notaries) or public welfare organizations (such as charities) can be whitelisted users of all other nodes in the alliance chain, and node users of business partners of a node can also Is the whitelisted user of the node.
  • the whitelist users can be graded according to the user's source or historical behavior data and other factors (for example, third-party credit evaluation scores). For example, the whitelist users with the lowest authority only have query rights, which is higher Whitelist users with permissions may also have further permissions and so on.
  • 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.
  • the number of docking users of nodes directly facing the market is always more than the number of rear nodes.
  • each node in the alliance is not "fair" in request processing. In other words, nodes with few registered users will always receive more requests than they should be responsible for, which is not very beneficial for nodes with few registered users.
  • an implementable 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 its first processing times for location query requests initiated by users of other nodes, and To confirm the second processing times of the location query request initiated by the user of the node by other nodes; according to the first processing times and the second processing times, determine whether to delay processing the location query request.
  • the first processing times and the second processing times may be based on a period of time, for example, daily or monthly, and be periodically cleared, or may be the statistics of all historical data.
  • the contribution ratio value represents the proportion of a node's "self contribution” and "request others" when processing a request.
  • 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 (ie, nodes with few registered users, which generally have relatively weak processing capacity for large flows). Since in the solution of the embodiment of the present 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 the present specification.
  • the client when the client selects multiple nodes, it is possible to select the same node multiple times in succession. In this way, the client can determine whether the number of transaction location query requests sent to the node has arrived The threshold, if it is, delays sending the transaction location query request to the node.
  • the statistics of sending times can count the times within a period of time, or count all the historical times. In this way, the client can avoid continuously requesting another node and reduce the impact on the load of another node.
  • FIG. 3 is a schematic flow chart of a method for verifying the credibility of a consortium chain provided by the embodiment on the client side. , And after depositing the transaction on the chain through the docking node, including:
  • 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 digest hash of the transaction;
  • S305 Verify the credibility of the alliance chain containing the transaction information according to the consistency of the location query results returned by the multiple nodes.
  • the above method further includes sending 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; receiving the multiple The SPV verification results returned by the nodes respectively verify the credibility of the alliance chain containing the transaction information.
  • sending the transaction location query request to the plurality of nodes in S303 includes, for any one of the nodes, determining whether the number of transaction location query requests sent to the node reaches a threshold, and if so , Delay sending the transaction location query request to the node.
  • FIG. 4 is a schematic flowchart of a method for processing a consortium chain provided by an embodiment.
  • a user When a user generates a transaction, the After the transaction is listed on the chain, including:
  • the node determines the user ID of the user of its own node, and determines a white list composed of the user ID, wherein the user ID is used to identify the user identity, and is used to identify the node docked with the user; alliance
  • the user identification contains the information of the docking node through a format negotiated in advance. For example, a different sequence number is added at the beginning of the user identification to identify the user's docking node.
  • the request includes a transaction location query request or a simple payment verification SPV request.
  • the request contains the digest hash of the target transaction.
  • the above method further includes that the node receives a request sent by any user, and the request further includes a user ID; it is determined whether the user ID is in the white list, and if not, the request is not processed.
  • the above method further includes receiving a request sent by any user, where the request also includes a user ID, and when the user corresponding to the user ID is not a user of the own node: determining that the node initiated the other node user The first processing times of the request of, and the second processing times of confirming the request initiated by the other node to the user of the node; according to the first processing times and the second processing times, determine whether to delay processing the request.
  • the embodiment of the present specification also provides a credibility verification system of the alliance chain, including the client and the alliance chain network, the alliance chain network includes multiple nodes; the client generates a transaction, and passes After the docking node deposits the transaction on the chain,
  • 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 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 digest hash in the alliance chain based on the digest hash, and returns the location query result to Client
  • the client verifies the credibility of the alliance chain containing the transaction information based on the consistency of the location query results returned by the multiple nodes.
  • the client randomly obtains multiple node addresses in the alliance chain; or, the client obtains multiple node addresses including the docking node address in the alliance chain.
  • 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; either 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 The SPV verification results returned by each node respectively verify the credibility of the alliance chain containing the transaction information.
  • any node in the alliance chain determines its own white list, and broadcasts the white list to other nodes in the alliance chain, so that other The node determines whether to execute the query processing according to the white list;
  • the transaction location query request includes the digest hash of the transaction, including: the transaction location query request includes the digest hash of the transaction and the client identifier
  • any node receives the location query request, it also includes: determining whether the client ID included in the location query request is in the white list, and if not, not performing query processing.
  • the node determines the first processing times of its own location query requests initiated by users of other nodes, and confirms the second processing times of other node's location query requests initiated by users of the node; According to the first and second processing times, it is determined whether to delay processing the location query request.
  • the client for any one of the plurality of nodes, judges whether the number of transaction location query requests sent to the node reaches a threshold, and if so, delays sending transactions to the node Location query request
  • the embodiment of the present specification also provides an alliance chain credibility verification device.
  • 5 is a schematic structural diagram of a credibility verification device provided by an embodiment of the present specification.
  • the device includes:
  • the obtaining module 501 obtains multiple node addresses in the alliance chain
  • the sending module 503 sends a transaction location query request to the plurality of nodes according to the multiple node addresses, where the transaction location query request includes a digest hash of the transaction;
  • the receiving module 505 receives the location query results respectively returned by the multiple nodes
  • the verification module 507 verifies the credibility of the alliance chain containing the transaction information according to the consistency of the location query results.
  • the obtaining module 501 randomly obtains multiple node addresses in the alliance chain; or, obtains multiple node addresses in the alliance chain including the docking node addresses.
  • 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 respectively returned by the multiple nodes;
  • the verification module 507 verifies the credibility of the alliance chain containing the transaction information according to the SPV verification results.
  • the sending module 503 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.
  • an embodiment of the present specification also provides a request processing device in the alliance chain, which is located on a node in the alliance chain, as shown in FIG. 6, and FIG. 6 is a Schematic diagram of a request processing device, the device includes:
  • the determining module 601 determines the user ID of the user of the own node, and determines a white list composed of the user ID, wherein the user ID is used to identify the user identity, and is used to identify the node docked with the user;
  • the sending module 603 sends 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, the request includes a transaction location query request or a simple payment verification SPV request, The request contains the digest hash of the target transaction.
  • the device further includes a receiving module 605, which receives a request sent by any user, and the request also includes a user ID; a determining module 607, determines whether the user ID is in the white list, if not, it is incorrect Request to perform processing.
  • the receiving module 605 receives a request sent by any user, and the request further includes a user ID.
  • the determining module 601 is further used to To determine the first processing times of the node for requests initiated by other node users, and to confirm the second processing times of other nodes for requests initiated by the node user; the judgment module 607 is further used for One processing times and the second processing times determine whether to delay processing the request.
  • Embodiments of this specification also provide a computer device, which includes at least a memory, a processor, and a computer program stored on the memory and executable on the processor, where the processor implements the program to implement the alliance shown in FIG. 3 Chain credibility verification method.
  • Embodiments of this specification also provide a computer device, which includes at least a memory, a processor, and a computer program stored on the memory and executable on the processor, where the processor implements the program to implement the alliance shown in FIG. 4 Request processing method in the chain.
  • 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 among the devices through the bus 1050.
  • the processor 1010 may be implemented by a general-purpose 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. Programs to implement the technical solutions provided by the embodiments of this specification.
  • the memory 1020 may be implemented in the form of ROM (Read Only Memory, Read Only Memory), RAM (Random Access Memory, Random Access Memory), static storage devices, and dynamic storage devices.
  • the memory 1020 may store an operating system and other application programs. When the technical solutions provided by the embodiments of the present specification are implemented by software or firmware, related program codes are stored in the memory 1020 and are called and executed by the processor 1010.
  • the input/output interface 1030 is used to connect an input/output module to realize information input and output.
  • the input/output/module can be configured as a component in the device (not shown in the figure), or can be externally connected to the device to provide corresponding functions.
  • the input device may include a keyboard, mouse, touch screen, microphone, various sensors, etc.
  • the output device may include a display, a speaker, a vibrator, an indicator light, and the like.
  • the communication interface 1040 is used to connect a communication module (not shown in the figure) to implement communication interaction between the device and other devices.
  • the communication module can implement communication through a wired method (such as USB, network cable, etc.), and can also implement communication through a wireless method (such as mobile network, WIFI, Bluetooth, etc.).
  • the bus 1050 includes a path for transferring 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).
  • the device may also include the necessary to achieve normal operation Other components.
  • the above-mentioned device may also include only the components necessary to implement the solutions of the embodiments of the present specification, rather than including all 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, and when the program is executed by a processor, a method for verifying the credibility of the alliance chain shown in FIG. 3 is implemented.
  • 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 including permanent and non-permanent, removable and non-removable media, can store information by any method or technology.
  • the information may be computer readable instructions, data structures, modules of programs, 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 technologies, read-only compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, Magnetic tape cassettes, magnetic tape magnetic disk 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.
  • computer-readable media does not include temporary computer-readable media (transitory media), such as modulated data signals and carrier waves.
  • the system, method, module or unit explained in the above embodiments may be specifically implemented by a computer chip or entity, or implemented by a product having a certain function.
  • a typical implementation device is a computer, and the specific form of the computer may be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email sending and receiving device, and a game control Desk, tablet computer, wearable device, or any combination of these devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Development Economics (AREA)
  • Technology Law (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Information Transfer Between Computers (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

公开了一种联盟链的可信度验证方法、系统、装置及设备。在客户端通过对接节点完成交易上链存证之后，针对该交易，客户端向联盟链中的多个节点发起交易位置查询请求，从而可以得到多个节点对于该交易的各自的查询结果。进而，可以基于多个节点的位置查询结果的一致程度去验证该联盟链的可信度，提高用户体验。

Description

一种联盟链的可信度验证方法、系统、装置及设备 技术领域
本说明书实施例涉及信息技术领域，尤其涉及一种联盟链的可信度验证方法、系统、装置及设备。
背景技术
在联盟链中，常常存在功能差异很大的多个节点，例如，在一条著作权存证的联盟链上，可能包括作品发布节点、版权登记节点、版权转让节点以及公证节点等等。而基于用户的不同需求，和用户对接的往往只是其中的一个节点，该节点可以认为是该用户的对接节点。例如，用户通过某节点所发布的应用程序APP发布了一项交易，并通过该对接节点将该交易进行了联盟链存证，以后再进行验证时也往往是通过该对接节点进行。
在这个过程中，用户本身难以感知整个联盟链的其它节点，通常也对于其它节点并无多大兴趣。在用户体验中，交易的完成和验证仿佛是对接节点为中心的，进而，用户就会对该对接节点以及联盟链的可信度产生疑虑。
基于此，需要一种可以让用户对联盟链的可信度进行验证的方案。
发明内容
针对现有技术中用户在对于联盟链的可信验证中，体验不佳的问题，为提高用户体验，本说明书实施例提供一种可以让用户对联盟链的可信度进行验证的方案，该方案的第一方面，包括一种联盟链的可信度验证方法，在客户端生成交易，并通过对接节点将所述交易上链存证后，包括：
客户端获取联盟链中的多个节点地址；
根据所述多个节点地址，发送交易位置查询请求至所述多个节点，其中，所述交易位置查询请求中包含所述交易的摘要哈希；
任一节点接收所述位置查询请求，基于所述摘要哈希各自查询所述摘要哈希所对应的交易在所述联盟链中的位置信息，并返回所述位置查询结果至客户端；
客户端基于所述多个节点分别返回的位置查询结果的一致程度，验证包含所述交易 信息的联盟链的可信度。
第二方面，本说明书实施例还提供一种联盟链的可信度验证方法，在用户生成交易，并通过对接节点将所述交易上链存证后，包括：
获取联盟链中的多个节点地址；
根据所述多个节点地址，发送交易位置查询请求至所述多个节点，其中，所述交易位置查询请求中包含所述交易的摘要哈希；
根据所述多个节点分别返回的位置查询结果的一致程度，验证包含所述交易信息的联盟链的可信度。
第三方面，本说明书实施例还提供一种联盟链中的请求处理方法，在节点为联盟链中的节点时，包括:
所述节点确定自身节点用户的用户标识，并从确定出由用户标识组成的白名单，其中，所述用户标识用于标识用户身份，以及，用于标识和该用户对接的节点；
发送白名单至联盟链中的其它节点，以便其它节点根据所述白名单确定是否执行非自身节点用户所发送的请求，所述请求包括交易位置查询请求或者简单支付验证SPV请求，所述请求中包含目标交易的摘要哈希。
与第一方面对应的，本说明书实施例还提供一种联盟链的可信度验证系统，包括客户端和联盟链网络，所述联盟链网络包括多个节点；在客户端生成交易，并通过对接节点将所述交易上链存证后，
客户端获取联盟链中的多个节点地址；根据所述多个节点地址，发送交易位置查询请求至所述多个节点，其中，所述交易位置查询请求中包含所述交易的摘要哈希；
联盟链网络中的任一节点接收所述位置查询请求，基于所述摘要哈希各自查询所述摘要哈希所对应的交易在所述联盟链中的位置信息，并返回所述位置查询结果至客户端；
客户端基于所述多个节点分别返回的位置查询结果的一致程度，验证包含所述交易信息的联盟链的可信度。
与第二方面对应的，本说明书实施例还提供一种联盟链的可信度验证装置，在用户生成交易，并通过对接节点将所述交易上链存证后，所述装置包括：
获取模块，获取联盟链中的多个节点地址；
发送模块，根据所述多个节点地址，发送交易位置查询请求至所述多个节点，其中，所述交易位置查询请求中包含所述交易的摘要哈希；
接收模块，接收所述多个节点分别返回的位置查询结果；
验证模块，根据所述位置查询结果的一致程度，验证包含所述交易信息的联盟链的可信度。
与第三方面对应的，本说明书实施例还提供一种联盟链中的请求处理装置，位于所述联盟链中的节点上，包括:
确定模块，确定自身节点用户的用户标识，并从确定出由用户标识组成的白名单，其中，所述用户标识用于标识用户身份，以及，用于标识和该用户对接的节点；
发送模块，发送白名单至联盟链中的其它节点，以便其它节点根据所述白名单确定是否执行非自身节点用户所发送的请求，所述请求包括交易位置查询请求或者简单支付验证SPV请求，所述请求中包含目标交易的摘要哈希。
本说明书实施例所提供的方案中，在客户端通过对接节点完成交易上链存证之后，针对该交易，客户端针向联盟链中的多个节点发起交易位置查询请求，从而可以得到多个节点对于该交易的各自的位置查询结果。进而，可以基于多个节点的位置查询结果的一致程度去验证该联盟链的可信度，提高用户体验。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本说明书实施例。
此外，本说明书实施例中的任一实施例并不需要达到上述的全部效果。
附图说明
为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。
图1为当前联盟链中所涉及的一种架构示意图；
图2是本说明书实施例提供的系统方面的一种联盟链的可信度验证方法的流程示意图；
图3为本说明书是实施例所提供的客户端方面的一种联盟链的可信度验证方法的流程示意图；
图4为本说明书是实施例所提供的一种联盟链中的请求处理方法的流程示意图；
图5为本说明书实施例所提供的一种可信度验证装置的结构示意图；
图6为本说明书实施例所提供的一种请求处理装置的结构示意图；
图7是用于配置本说明书实施例方法的一种设备的结构示意图。
具体实施方式
为了使本领域技术人员更好地理解本说明书实施例中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本说明书的一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于保护的范围。
在联盟链中通常包含了多个不同的功能节点，在当前，联盟链常采用的一种架构为，各功能节点分别面向各自的用户，用户通过他们感兴趣的功能节点接入联盟链。
在本说明书实施例所涉及的联盟链中的节点，可以认为每个节点都参与联盟链网络的路由功能，同时也可以包含其他功能，例如，每个节点都可以参与验证并传播交易及区块信息，发现并维持与对等节点的连接，以及还可以在本地存储有完整的联盟链，和一些与联盟链相关的数据。
如图1所示，图1为当前联盟链中所涉及的一种架构。在图1中，联盟链网络中的节点可能都包含有不同的功能，以及，各节点由于提供不同的功能，面向的目标用户也常常并不相同，在同一联盟链中，各功能节点还经常分别开发自己的应用程序APP让自身节点用户进行注册并接入。而用户则通常从中选取一个节点对接联盟链，进行交易发布以及验证。
以下结合附图，详细说明本说明书各实施例提供的技术方案。本说明书实施例的方案的第一方面，如图2所示，图2是本说明书实施例提供的系统方面的一种联盟链的可信度验证方法的流程示意图，在客户端生成交易，并通过对接节点将所述交易上链存证后，该流程具体包括如下步骤：
S201，客户端获取联盟链中的多个节点地址。
对客户端而言，已知的是对接节点的地址，联盟链中的其它节点地址可以向对接节点请求获得。也可以通过其它方式获取，例如，联盟链中的所有节点定时将自己的地址发布至某公开云端，客户端本地保存一张地址列表，并且客户端定期从该公开云端获取所有节点的地址对该地址列表进行更新，从而，可以从该地址列表中随时选取若干节点地址。通过该方式，可以绕开客户端的对接节点，提高用户对于整个联盟链的信任程度。
S203，根据所述多个节点地址，发送交易位置查询请求至所述多个节点，其中，所述交易位置查询请求中包含所述交易的摘要哈希。
由于在用户完成交易并通过对接节点上链存证之后，就会收到一个关于该存证交易的通知消息，通常其中就包括摘要哈希，并保存于客户端本地。因此，客户端总是可以从本地中获取该摘要哈希，并将其加入交易位置查询请求中。
在客户端方面，可以是在收到该通知消息后，根据用户的指令发起查询请求；也可以是，接收到该通知消息即触发查询请求。
S205，任一节点接收所述位置查询请求，基于所述摘要哈希各自查询所述摘要哈希所对应的交易在所述联盟链中的位置信息，并返回所述位置查询结果至客户端。
一个区块链由多个区块组成，同时，一个区块中通常包含多个交易。因此，在本说明书实施例中，所述的位置信息具体指的是该交易被存证时，处于区块链中的哪个区块上，以及，在该区块中的什么位置。
在区块链中，可以有多种方式用来标识不同的区块，例如，区块头哈希值或者区块高度(block height)。区块头哈希值即为区块头进行哈希计算而得到的哈希值，可以用于唯一、明确地标识一个区块。在区块链中，通常第一个区块其区块高度为0，以后每增加一个区块，区块高度加1。一个区块通常有一个明确的区块高度。因此，区块头哈希值或者区块高度可以作为区块元数据的一部分，被存储在节点中一个独立的数据库表中，以便于索引和更快地检索到该区块。
同时，在一个区块中，由于通常包含了多个交易，因此，还可以用各交易在该区块中的地址偏移量来分别标识区块中的交易。显而易见，在同一个区块中，各交易的地址偏移量并不相同。
进而，可以在交易所处的区块上链存证以后，各节点中可以通过维护一张形如(交易摘要哈希，区块头哈希值，地址偏移量)，或者，(交易摘要哈希，区块高度，地址偏移量)的数据表，就可以通过交易的摘要哈希查询得到对应的区块标识以及交易在区 块中的地址。换言之，节点可以通过交易的摘要哈希确定该交易在联盟链中的位置。
当然，由于区块链的具体格式是可以自定义的，在不同的区块格式下，位置信息的内容也会有所不同，这并不构成对本方案的限定。此外，需要说明的是，任一节点接收到的请求可以是直接来自于客户端，也可以是接收联盟链中其它节点所转发的客户端请求。
S207，客户端基于所述多个节点分别返回的位置查询结果的一致程度，验证包含所述交易信息的联盟链的可信度。
每个节点在查询结束之后，即可以将查询结果返回客户端。需要说明的是，该过程可以是一个异步处理过程，客户端在发送完查询请求之后，并不需要即时的反馈结果。因此，客户端可以等待所有的节点都返回一个查询结果再进行验证。
由于一个交易在联盟链中只会有一个确定的位置，因此，联盟链的可信度可以基于查询结果的一致程度而定。理论上，各节点所返回的位置信息应该完全相同。一个较为严格的验证方式即为，若所有位置查询结果均一致，则该联盟链为可信的。当然，由于各种网络原因、设备原因等等，可以容许一定的偏差。例如，根据返回的所有结果的对一致程度进行计算，若返回的结果中不存在占比超过95％的相同查询结果，则认为联盟度可信度为0，否则，将所述相同结果的占比作为该联盟链的可信度。
进一步地，当确定联盟链不可信时，还可以发出警报。具体的，警报消息中可以指出各节点的查询结果不一致的程度是多少(即有多少个或者多少比例与多数结果不一致)，以及，具体的给出与多数结果不一致的节点和该类节点的查询结果。
本说明书实施例所提供的方案中，在用户通过对接节点完成交易上链存证之后，针对该交易，用户针向联盟链中的多个节点发起交易位置查询请求，从而可以得到多个节点对于该交易的各自的查询结果。进而，可以基于多个节点的位置查询结果的一致程度去验证该联盟链的可信度，提高用户体验。
在一种具体的实施方式下，客户端获取联盟链中的多个节点地址，可以是
客户端随机获取联盟链中的多个节点地址，随机获取节点地址验证一方面可以使得验证结果更加公正，另一方面，也可以使得用户的请求平均的流向向各节点，避免某些用户多的节点负荷太重。又或者，客户端获取联盟链中包含所述对接节点地址的多个节点地址，在这种方式下，用户可以首先选取一批节点地址，然后再将对接节点的地址加入即可。加入对接节点进行验证时，在返回的结果中也包含对接节点的验证结果，可以 使得验证更具有针对性，提高用户体验。
在一种具体的实施方式下，用户还可以根据所述多个节点地址，发送简单支付验证SPV请求至所述多个节点，其中，所述SPV请求中包含所述交易的摘要哈希。任一节点基于所述摘要哈希，各自验证所述摘要哈希所对应的交易是否是处于所述联盟链中，生成SPV验证结果，并返回所述SPV验证结果至客户端。客户端基于所述多个节点分别返回的SPV验证结果，验证包含所述交易信息的联盟链的可信度。
在区块链的每个区块中，包含了记录于该区块的所有交易，并且可以默克尔Merkle树表示。区块中所有的交易将数据哈希化，然后将哈希值存储至相应的叶子节点中。树中的一个叶子节点表征区块中存在一笔对应的交易。为了证明区块中存在某个特定的目标交易，一个节点只需要计算log 2N个哈希值，形成一条从目标交易到树根的Merkle路径即可。
节点在进行简单支付验证(Simplified Payment Verification，SPV)时，不必保存所有交易也不必下载整个区块。节点可以仅仅保存区块头，并通过目标交易的哈希和Merkle路径来验证目标交易是否存在于该区块中。换言之，各节点的SPV验证结果是一个二值结果，要么为“是”，要么为“否”。
由于一个交易在联盟链中要么存在，要么不存在，理论上，当联盟链没有问题时，各节点所返回的SPV验证结果应该完全相同。因此，一个较为严格的可信度确认方式为，若所有SPV验证结果均一致为“是”，则确认该联盟链是可信的，否则是不可信的。当然，由于各种网络原因、设备原因等等，可以容许一定的偏差。例如，设定一个阈值，若SPV验证结果的一致为“是”的程度超过该阈值，则确认该联盟链是可信的。
进一步地，当确认该联盟链不可信时，还可以发出警报。具体的，警报消息中可以指出各节点的查询结果不一致的程度是多少(即“是”和“否”的结果分别是多少)，以及，具体的给出与多数结果不一致的节点和该类节点的查询结果。以及，还可以根据返回的所有结果的不一致的程度计算一个可信度数值作为参考。例如，若返回的结果中不存在占比超过一定阈值的相同查询结果，则认为联盟度可信，否则，则认为联盟链不可信。
需要说明的是，上述基于位置查询结果的一致性进行验证的方案，和基于SPV验证的结果的一致性进行验证的方案，属于可以同时分开进行的方案。在实际操作中，二者的验证结果是分别独立的。换言之，客户端可以只选择一种方式执行验证，也可以同时 选择两种方式执行验证，在同时执行两种验证方案时，需要二种验证方案的结果同时满足一致性条件，才认为联盟链是可信的。以及，在验证的过程中，两种方案的执行不分先后。
由于在联盟链中，各功能节点通常会有自己的对接客户端以及对应的对接用户。在本说明书实施例的方案中，各节点经常需要处理来自于非自身节点用户的请求。
在一种实施方式下，节点可以对于任意连接自己的客户端所发送的查询请求或者SPV请求进行处理。在另一种实施方式下，基于联盟共享的原则，各节点还可以提供查询服务或者SPV服务给白名单用户，如果发送请求的客户端标识在白名单上，则进行处理，否则，不进行处理。
确定白名单用户的具体方式包括：联盟链中的任一节点确定自身的白名单，并广播白名单至联盟链中的其它节点，以便其它节点根据所述白名单确定是否执行查询处理。一种常见的处理方式即为，联盟链中的任一节点将自身的注册用户确认为白名单用户并进行广播。而其它节点则可以根据请求所包含的客户端标识是否是白名单用户，来决定是否进行进一步的处理。此处的白名单可以以节点为最小单元，也可以以用户为最小单元，各节点所保存的白名单用户可以相同，也可以不同。节点接收到白名单用户所发送的请求时才进行处理。
例如，假设联盟链中存在A、B、C、D四个节点，在上述方案中，可以B、C、D节点将A节点的对接用户确认为白名单用户，四个节点共同维护；也可以在B节点的白名单用户中包括A节点的用户，但是C、D节点的白名单用户中不包括A节点的用户。具体的情形可以基于业务情形自行确定。
在较为一般的情形中，政府机构(例如公证处)或者公益机构(例如慈善机构)节点的对接用户可以是所有联盟链中其它节点的白名单用户，一个节点的业务伙伴节点的节点用户也可以是该节点的白名单用户。进一步，在各节点中还可以根据用户的来源或者历史行为数据以及其它因素(例如，第三方信用评估分)，对白名单用户进行权限分级，例如，最低权限的白名单用户只有查询权限，更高权限的白名单用户可能还可以拥有进一步的其它权限等等。
在实际应用中，一个联盟链中各节点的用户数量情形并不相同，有的节点的对接用户多，有的节点的对接用户少。通常而言，那些直接面对市场的节点的对接用户的数量总是多余一些后方节点的数量。例如，在一个用于保护著作权的联盟链中，面对创作者 的作品发布平台的注册用户，总是远多于公证处的注册用户。
那么在这种情形下，本说明书实施例的方案中，联盟中的各节点在对于请求处理上并不是“公平”的。换言之，注册用户少的节点总是会接收到超出本身本应负责处理的请求数量，这对于注册用户少的节点并不是很有利。
此时，一种可实施的方式为，任一节点在接收到请求并决定处理时，首先做一个判断，确定该节点确定自身对于其它节点用户所发起的位置查询请求的第一处理次数，以及，确认其它节点对于该节点用户所发起的位置查询请求的第二处理次数；根据所述第一处理次数和第二处理次数，判断是否延迟处理所述位置查询请求。
第一处理次数和第二处理次数可以以一段时间为周期，例如，每天或者每月，定期进行清零，也可以是全部历史数据的数量统计。判断是否延迟处理的条件，可以是根据第一处理次数X和第二处理次数Y计算获得一个贡献比例值Z与预设阈值进行比较，例如，Z＝(X-Y)/Y，或者，Z＝X/Y等等。贡献比例值表征了一个节点在处理请求时的“自身贡献”和“请求他人”的比例，一旦贡献比例值超过了一定阈值，则表示该节点已经处理了较多的请求，则该节点可以延迟处理接收到的其它节点用户所发送的请求，延迟处理请求可以有效降低弱节点(即注册用户少的节点，一般对于大流量的处理能力相对弱)的负荷。由于在本说明书实施例的方案中，客户端并不需要即时得到验证结果，因此各节点对于请求的处理可以是异步的，延迟处理并不会影响本说明书实施例的方案的效果。
在一种实施方式下，客户端在选取多个节点时，有可能连续多次选到同一个节点，在这种方式下，客户端可以判断对该节点的交易位置查询请求的发送次数是否到达阈值，若是，对该节点延迟发送交易位置查询请求。发送次数的统计可以统计一段时间内的次数，也可以统计所有的历史次数。通过上述方式，在客户端方面即可以避免连续的请求另一节点，降低对另一节点的负荷的影响。
本说明书实施例的方案的第二方面，如图3所示，图3为本说明书是实施例所提供的客户端方面的一种联盟链的可信度验证方法的流程示意图，在用户生成交易，并通过对接节点将所述交易上链存证后，包括：
S301，获取联盟链中的多个节点地址，具体的方式包括，随机获取联盟链中的多个节点地址；或者，获取联盟链中包含所述对接节点地址的多个节点地址。
S303，根据所述多个节点地址，发送交易位置查询请求至所述多个节点，其中，所 述交易位置查询请求中包含所述交易的摘要哈希；
S305，根据所述多个节点分别返回的位置查询结果的一致程度，验证包含所述交易信息的联盟链的可信度。
进一步地，上述方法还包括，根据所述多个节点地址，发送简单支付验证SPV请求至所述多个节点，其中，所述SPV请求中包含所述交易的摘要哈希；接收所述多个节点分别返回的SPV验证结果，验证包含所述交易信息的联盟链的可信度。
进一步，所述S303中的发送交易位置查询请求至所述多个节点，包括，针对所述多个节点中的任一节点，判断对该节点的交易位置查询请求的发送次数是否到达阈值，若是，对该节点延迟发送交易位置查询请求。
本说明书实施例的方案的第三方面，如图4所示，图4为本说明书是实施例所提供的一种联盟链的请求处理方法的流程示意图，在用户生成交易，并通过对接节点将所述交易上链存证后，包括：
S401，所述节点确定自身节点用户的用户标识，并从确定出由用户标识组成的白名单，其中，所述用户标识用于标识用户身份，以及，用于标识和该用户对接的节点；联盟链中可以通过事先协商好的格式，在用户标识中包含有对接节点的信息，例如，在用户标识开头加上不同的序号用以标识该用户的对接节点。
S403，发送白名单至联盟链中的其它节点，以便其它节点根据所述白名单确定是否执行非自身节点用户所发送的请求，所述请求包括交易位置查询请求或者简单支付验证SPV请求，所述请求中包含目标交易的摘要哈希。
进一步的，上述方法还包括，节点接收任一用户所发送的请求，所述请求中还包括用户标识；判断所述用户标识是否处于白名单中，若否，不对请求执行处理。
进一步的，上述方法还包括，接收任一用户所发送的请求，所述请求中还包括用户标识，当所述用户标识所对应的用户非自身节点用户时：确定该节点对于其它节点用户所发起的请求的第一处理次数，以及，确认其它节点对于该节点用户所发起的请求的第二处理次数；根据所述第一处理次数和第二处理次数，判断是否延迟处理所述请求。
与第一方面对应的，本说明书实施例还提供一种盟链的可信度验证系统，包括客户端和联盟链网络，所述联盟链网络包括多个节点；在客户端生成交易，并通过对接节点将所述交易上链存证后，
客户端获取联盟链中的多个节点地址；根据所述多个节点地址，发送交易位置查询请求至所述多个节点，其中，所述交易位置查询请求中包含所述交易的摘要哈希；
联盟链网络中的任一节点接收所述位置查询请求，基于所述摘要哈希各自查询所述摘要哈希所对应的交易在所述联盟链中的位置信息，并返回所述位置查询结果至客户端；
客户端基于所述多个节点分别返回的位置查询结果的一致程度，验证包含所述交易信息的联盟链的可信度。
进一步地，在所述系统中，所述客户端随机获取联盟链中的多个节点地址；或者，客户端获取联盟链中包含所述对接节点地址的多个节点地址。
进一步地，在所述系统中，客户端根据所述多个节点地址，发送简单支付验证SPV请求至所述多个节点，其中，所述SPV请求中包含所述交易的摘要哈希；任一节点基于所述摘要哈希，各自验证所述摘要哈希所对应的交易是否是处于所述联盟链中，生成SPV验证结果，并返回所述SPV验证结果至客户端；客户端基于所述多个节点分别返回的SPV验证结果，验证包含所述交易信息的联盟链的可信度。
进一步地，在所述系统中，在客户端获取联盟链中的多个节点地址之前，联盟链中的任一节点确定自身的白名单，并广播白名单至联盟链中的其它节点，以便其它节点根据所述白名单确定是否执行查询处理；所述交易位置查询请求中包含所述交易的摘要哈希，包括：所述交易位置查询请求包含所述交易的摘要哈希和所述客户端标识；任一节点接收所述位置查询请求之后，还包括：确定所述位置查询请求所包含的客户端标识是否处于白名单中，若否，不执行查询处理。
进一步地，在所述系统中，该节点确定自身对于其它节点用户所发起的位置查询请求的第一处理次数，以及，确认其它节点对于该节点用户所发起的位置查询请求的第二处理次数；根据所述第一处理次数和第二处理次数，判断是否延迟处理所述位置查询请求。
进一步地，在所述系统中，所述客户端，针对所述多个节点中的任一节点，判断对该节点的交易位置查询请求的发送次数是否到达阈值，若是，对该节点延迟发送交易位置查询请求
与第二方面对应的，本说明书实施例还提供一种联盟链的可信度验证装置，在用户生成交易，并通过对接节点将所述交易上链存证后，如图5所示，图5为本说明书实施例所提供的一种可信度验证装置的结构示意图，所述装置包括：
获取模块501，获取联盟链中的多个节点地址；
发送模块503，根据所述多个节点地址，发送交易位置查询请求至所述多个节点，其中，所述交易位置查询请求中包含所述交易的摘要哈希；
接收模块505，接收所述多个节点分别返回的位置查询结果；
验证模块507，根据所述位置查询结果的一致程度，验证包含所述交易信息的联盟链的可信度。
进一步地，所述获取模块501，随机获取联盟链中的多个节点地址；或者，获取联盟链中包含所述对接节点地址的多个节点地址。
进一步地，所述发送模块503还用于，根据所述多个节点地址，发送简单支付验证SPV请求至所述多个节点，其中，所述SPV请求中包含所述交易的摘要哈希；所述接收模块505，接收所述多个节点分别返回的SPV验证结果；所述验证模块507，根据所述SPV验证结果，验证包含所述交易信息的联盟链的可信度。
进一步地，所述发送模块503，针对所述多个节点中的任一节点，判断对该节点的交易位置查询请求的发送次数是否到达阈值，若是，对该节点延迟发送交易位置查询请求。
与第三方面对应的，本说明书实施例还提供一种联盟链中的请求处理装置，位于所述联盟链中的节点上，如图6所示，图6为本说明书实施例所提供的一种请求处理装置的结构示意图，所述装置包括：
确定模块601，确定自身节点用户的用户标识，并从确定出由用户标识组成的白名单，其中，所述用户标识用于标识用户身份，以及，用于标识和该用户对接的节点；
发送模块603，发送白名单至联盟链中的其它节点，以便其它节点根据所述白名单确定是否执行非自身节点用户所发送的请求，所述请求包括交易位置查询请求或者简单支付验证SPV请求，所述请求中包含目标交易的摘要哈希。
进一步地，所述装置还包括，接收模块605，接收任一用户所发送的请求，所述请求中还包括用户标识；判断模块607，判断所述用户标识是否处于白名单中，若否，不对请求执行处理。
进一步地，所述接收模块605，接收任一用户所发送的请求，所述请求中还包括用户标识，当所述用户标识所对应的用户非自身节点用户时，所述确定模块601还用于， 确定该节点对于其它节点用户所发起的请求的第一处理次数，以及，确认其它节点对于该节点用户所发起的请求的第二处理次数；所述判断模块607还用于，根据所述第一处理次数和第二处理次数，判断是否延迟处理所述请求。
本说明书实施例还提供一种计算机设备，其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行所述程序时实现图3所示的联盟链的可信度验证方法。
本说明书实施例还提供一种计算机设备，其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行所述程序时实现图4所示的联盟链中的请求处理方法。
图7示出了本说明书实施例所提供的一种更为具体的计算设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。
处理器1010可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。
存储器1020可以采用ROM(Read Only Memory，只读存储器)、RAM(Random Access Memory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。
输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。
通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。
总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。
需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。
本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现图3所示的联盟链的可信度验证方法。
本说明书实施例还提供另一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现图4所示的联盟链中的请求处理方法。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本说明书实施例可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本说明书实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本说明书实施例各个实施例或者实施例的某些部分所述的方法。
上述实施例阐明的系统、方法、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设 备或者这些设备中的任意几种设备的组合。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于方法实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的方法实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本说明书实施例方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上所述仅是本说明书实施例的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本说明书实施例原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本说明书实施例的保护范围。

Claims (28)

  1. 一种联盟链的可信度验证方法，在客户端生成交易，并通过对接节点将所述交易上链存证后，包括：
    客户端获取联盟链中的多个节点地址；
    根据所述多个节点地址，发送交易位置查询请求至所述多个节点，其中，所述交易位置查询请求中包含所述交易的摘要哈希；
    任一节点接收所述位置查询请求，基于所述摘要哈希各自查询所述摘要哈希所对应的交易在所述联盟链中的位置信息，并返回所述位置查询结果至客户端；
    客户端基于所述多个节点分别返回的位置查询结果的一致程度，验证包含所述交易信息的联盟链的可信度。
  2. 如权利要求1所述的方法，客户端获取联盟链中的多个节点地址，包括：
    客户端随机获取联盟链中的多个节点地址；或者，
    客户端获取联盟链中包含所述对接节点地址的多个节点地址。
  3. 如权利要求1所述的方法，还包括：
    客户端根据所述多个节点地址，发送简单支付验证SPV请求至所述多个节点，其中，所述SPV请求中包含所述交易的摘要哈希；
    任一节点基于所述摘要哈希，各自验证所述摘要哈希所对应的交易是否是处于所述联盟链中，生成SPV验证结果，并返回所述SPV验证结果至客户端；
    客户端基于所述多个节点分别返回的SPV验证结果，验证包含所述交易信息的联盟链的可信度。
  4. 如权利要求1所述的方法，在客户端获取联盟链中的多个节点地址之前，所述方法还包括：
    联盟链中的任一节点确定自身的白名单，并广播白名单至联盟链中的其它节点，以便其它节点根据所述白名单确定是否执行查询处理；
    所述交易位置查询请求中包含所述交易的摘要哈希，包括：所述交易位置查询请求包含所述交易的摘要哈希和所述客户端标识；
    任一节点接收所述位置查询请求之后，还包括：确定所述位置查询请求所包含的客户端标识是否处于白名单中，若否，不执行查询处理。
  5. 如权利要求1所述的方法，在任一节点接收所述位置查询请求之后，所述方法还包括：
    该节点确定自身对于其它节点用户所发起的位置查询请求的第一处理次数，以及， 确认其它节点对于该节点用户所发起的位置查询请求的第二处理次数；
    根据所述第一处理次数和第二处理次数，判断是否延迟处理所述位置查询请求。
  6. 如权利要求1所述的方法，发送交易位置查询请求至所述多个节点，包括：
    针对所述多个节点中的任一节点，判断对该节点的交易位置查询请求的发送次数是否到达阈值，若是，对该节点延迟发送交易位置查询请求。
  7. 一种联盟链的可信度验证方法，在用户生成交易，并通过对接节点将所述交易上链存证后，包括：
    获取联盟链中的多个节点地址；
    根据所述多个节点地址，发送交易位置查询请求至所述多个节点，其中，所述交易位置查询请求中包含所述交易的摘要哈希；
    根据所述多个节点分别返回的位置查询结果的一致程度，验证包含所述交易信息的联盟链的可信度。
  8. 如权利要求7所述的方法，获取联盟链中的多个节点地址，包括：
    随机获取联盟链中的多个节点地址；或者，
    获取联盟链中包含所述对接节点地址的多个节点地址。
  9. 如权利要求7所述的方法，还包括：
    根据所述多个节点地址，发送简单支付验证SPV请求至所述多个节点，其中，所述SPV请求中包含所述交易的摘要哈希；
    接收所述多个节点分别返回的SPV验证结果，验证包含所述交易信息的联盟链的可信度。
  10. 如权利要求7所述的方法，发送交易位置查询请求至所述多个节点，包括：
    针对所述多个节点中的任一节点，判断对该节点的交易位置查询请求的发送次数是否到达阈值，若是，对该节点延迟发送交易位置查询请求。
  11. 一种联盟链中的请求处理方法，在节点为联盟链中的节点时，包括:
    所述节点确定自身节点用户的用户标识，并从确定出由用户标识组成的白名单，其中，所述用户标识用于标识用户身份，以及，用于标识和该用户对接的节点；
    发送白名单至联盟链中的其它节点，以便其它节点根据所述白名单确定是否执行非自身节点用户所发送的请求，所述请求包括交易位置查询请求或者简单支付验证SPV请求，所述请求中包含目标交易的摘要哈希。
  12. 如权利要求11所述的请求处理方法，包括：
    节点接收任一用户所发送的请求，所述请求中还包括用户标识；
    判断所述用户标识是否处于白名单中，若否，不对请求执行处理。
  13. 如权利要求11所述的方法，还包括：
    接收任一用户所发送的请求，所述请求中还包括用户标识，当所述用户标识所对应的用户非自身节点用户时：
    确定该节点对于其它节点用户所发起的请求的第一处理次数，以及，确认其它节点对于该节点用户所发起的请求的第二处理次数；
    根据所述第一处理次数和第二处理次数，判断是否延迟处理所述请求。
  14. 一种联盟链的可信度验证系统，包括客户端和联盟链网络，所述联盟链网络包括多个节点；在客户端生成交易，并通过对接节点将所述交易上链存证后，
    客户端获取联盟链中的多个节点地址；根据所述多个节点地址，发送交易位置查询请求至所述多个节点，其中，所述交易位置查询请求中包含所述交易的摘要哈希；
    联盟链网络中的任一节点接收所述位置查询请求，基于所述摘要哈希各自查询所述摘要哈希所对应的交易在所述联盟链中的位置信息，并返回所述位置查询结果至客户端；
    客户端基于所述多个节点分别返回的位置查询结果的一致程度，验证包含所述交易信息的联盟链的可信度。
  15. 如权利要求14所述的系统，所述客户端随机获取联盟链中的多个节点地址；或者，客户端获取联盟链中包含所述对接节点地址的多个节点地址。
  16. 如权利要求14所述的系统，
    客户端根据所述多个节点地址，发送简单支付验证SPV请求至所述多个节点，其中，所述SPV请求中包含所述交易的摘要哈希；
    任一节点基于所述摘要哈希，各自验证所述摘要哈希所对应的交易是否是处于所述联盟链中，生成SPV验证结果，并返回所述SPV验证结果至客户端；
    客户端基于所述多个节点分别返回的SPV验证结果，验证包含所述交易信息的联盟链的可信度。
  17. 如权利要求14所述的系统，在客户端获取联盟链中的多个节点地址之前，
    联盟链中的任一节点确定自身的白名单，并广播白名单至联盟链中的其它节点，以便其它节点根据所述白名单确定是否执行查询处理；
    所述交易位置查询请求中包含所述交易的摘要哈希，包括：所述交易位置查询请求包含所述交易的摘要哈希和所述客户端标识；
    任一节点接收所述位置查询请求之后，还包括：确定所述位置查询请求所包含的客户端标识是否处于白名单中，若否，不执行查询处理。
  18. 如权利要求14所述的系统，在任一节点接收所述位置查询请求之后，
    该节点确定自身对于其它节点用户所发起的位置查询请求的第一处理次数，以及，确认其它节点对于该节点用户所发起的位置查询请求的第二处理次数；
    根据所述第一处理次数和第二处理次数，判断是否延迟处理所述位置查询请求。
  19. 如权利要求14所述的系统，所述客户端，针对所述多个节点中的任一节点，判断对该节点的交易位置查询请求的发送次数是否到达阈值，若是，对该节点延迟发送交易位置查询请求。
  20. 一种联盟链的可信度验证装置，在用户生成交易，并通过对接节点将所述交易上链存证后，所述装置包括：
    获取模块，获取联盟链中的多个节点地址；
    发送模块，根据所述多个节点地址，发送交易位置查询请求至所述多个节点，其中，所述交易位置查询请求中包含所述交易的摘要哈希；
    接收模块，接收所述多个节点分别返回的位置查询结果；
    验证模块，根据所述位置查询结果的一致程度，验证包含所述交易信息的联盟链的可信度。
  21. 如权利要求20所述的装置，所述获取模块，随机获取联盟链中的多个节点地址；或者，获取联盟链中包含所述对接节点地址的多个节点地址。
  22. 如权利要求20所述的装置，
    所述发送模块还用于，根据所述多个节点地址，发送简单支付验证SPV请求至所述多个节点，其中，所述SPV请求中包含所述交易的摘要哈希；
    所述接收模块，接收所述多个节点分别返回的SPV验证结果；
    所述验证模块，根据所述SPV验证结果，验证包含所述交易信息的联盟链的可信度。
  23. 如权利要求20所述的装置，所述发送模块，针对所述多个节点中的任一节点，判断对该节点的交易位置查询请求的发送次数是否到达阈值，若是，对该节点延迟发送交易位置查询请求。
  24. 一种联盟链中的请求处理装置，位于联盟链中的节点上，包括:
    确定模块，确定自身节点用户的用户标识，并从确定出由用户标识组成的白名单，其中，所述用户标识用于标识用户身份，以及，用于标识和该用户对接的节点；
    发送模块，发送白名单至联盟链中的其它节点，以便其它节点根据所述白名单确定是否执行非自身节点用户所发送的请求，所述请求包括交易位置查询请求或者简单支付 验证SPV请求，所述请求中包含目标交易的摘要哈希。
  25. 如权利要求24所述的装置，还包括：
    接收模块，接收任一用户所发送的请求，所述请求中还包括用户标识；
    判断模块，判断所述用户标识是否处于白名单中，若否，不对请求执行处理。
  26. 如权利要求24所述的装置，
    所述接收模块，接收任一用户所发送的请求，所述请求中还包括用户标识，当所述用户标识所对应的用户非自身节点用户时：
    所述确定模块还用于，确定该节点对于其它节点用户所发起的请求的第一处理次数，以及，确认其它节点对于该节点用户所发起的请求的第二处理次数；
    所述判断模块还用于，根据所述第一处理次数和第二处理次数，判断是否延迟处理所述请求。
  27. 一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如权利要求7至10任一项所述的方法。
  28. 一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如权利要求11至13任一项所述的方法。
PCT/CN2019/116149 2018-12-28 2019-11-07 一种联盟链的可信度验证方法、系统、装置及设备 WO2020134624A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201811626394.6A CN110049087B (zh) 2018-12-28 2018-12-28 一种联盟链的可信度验证方法、系统、装置及设备
CN201811626394.6 2018-12-28

Publications (1)

Publication Number Publication Date
WO2020134624A1 true WO2020134624A1 (zh) 2020-07-02

Family

ID=67274044

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/116149 WO2020134624A1 (zh) 2018-12-28 2019-11-07 一种联盟链的可信度验证方法、系统、装置及设备

Country Status (3)

Country Link
CN (1) CN110049087B (zh)
TW (1) TWI727467B (zh)
WO (1) WO2020134624A1 (zh)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110022345B (zh) * 2018-12-28 2020-03-24 阿里巴巴集团控股有限公司 联盟链中的请求处理方法、系统、装置及设备
CN110049087B (zh) * 2018-12-28 2020-05-05 阿里巴巴集团控股有限公司 一种联盟链的可信度验证方法、系统、装置及设备
CN110889729B (zh) * 2019-11-29 2024-03-26 腾讯科技（深圳）有限公司 一种基于区块链网络的数据验证方法和装置
CN111125256B (zh) * 2019-12-24 2023-10-31 深圳前海乐寻坊区块链科技有限公司 基于区块链的用人信用认证方法、装置、设备、存储介质
CN113177767A (zh) * 2020-01-08 2021-07-27 福历科技(上海)有限公司 基于功夫链的设备数据处理方法及装置
CN111400752A (zh) * 2020-03-12 2020-07-10 杭州城市大数据运营有限公司 一种基于区块链的数据查询方法、系统及电子设备
CN111553669B (zh) * 2020-04-28 2021-09-10 腾讯科技（深圳）有限公司 一种交易路由方法、装置及计算机可读存储介质
CN111614646A (zh) * 2020-05-14 2020-09-01 杭州溪塔科技有限公司 一种联盟链的恶意交易删除方法、装置及电子设备
TWI824173B (zh) * 2020-08-26 2023-12-01 中華電信股份有限公司 一種公有區塊鏈混合私有區塊鏈的方法及電腦可讀媒介
CN112511605B (zh) * 2020-11-17 2022-11-22 上海万向区块链股份公司 基于设备异步轮询上链状态的管理方法、系统及介质
CN113159936A (zh) * 2021-05-27 2021-07-23 中国银行股份有限公司 基于区块链的个人征信查询方法及装置
CN114647668B (zh) * 2022-05-18 2022-09-23 南京金宁汇科技有限公司 应用于联盟链的交易回执查询方法及系统

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106503981A (zh) * 2016-10-19 2017-03-15 江苏通付盾科技有限公司 简单支付验证节点交易查询方法及系统
CN107247773A (zh) * 2017-06-07 2017-10-13 北京邮电大学 一种基于区块链的在分布式数据库中进行交易查询的方法
CN107766542A (zh) * 2017-10-30 2018-03-06 上海分布信息科技有限公司 一种分区的区块链网络及其实现分区查询的方法
US20180181953A1 (en) * 2016-12-22 2018-06-28 Mastercard International Incorporated Method and system for anonymous directed blockchain transaction
CN108876611A (zh) * 2018-05-31 2018-11-23 中国联合网络通信集团有限公司 交易信息处理方法、装置及区块链节点
CN108965342A (zh) * 2018-09-28 2018-12-07 真相网络科技（北京）有限公司 数据请求方访问数据源的鉴权方法及系统
CN110049087A (zh) * 2018-12-28 2019-07-23 阿里巴巴集团控股有限公司 一种联盟链的可信度验证方法、系统、装置及设备

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105719185B (zh) * 2016-01-22 2019-02-15 杭州复杂美科技有限公司 区块链的数据对比及共识方法
WO2018119930A1 (zh) * 2016-12-29 2018-07-05 深圳前海达闼云端智能科技有限公司 交易验证处理方法、装置及节点设备
CN106850622B (zh) * 2017-02-07 2020-03-03 杭州秘猿科技有限公司 一种基于许可链的用户身份管理方法
EP3413507B1 (en) * 2017-06-09 2022-05-04 Nokia Technologies Oy Electronic documents certification
CN108711052B (zh) * 2018-05-18 2021-04-30 电子科技大学 一种基于区块链的信息验证系统
CN108764909A (zh) * 2018-06-01 2018-11-06 杭州复杂美科技有限公司 一种区块链数据监管方法
CN109064169B (zh) * 2018-07-13 2020-11-06 杭州复杂美科技有限公司 交易方法、设备和存储介质
CN108681900A (zh) * 2018-07-18 2018-10-19 众安信息技术服务有限公司 轻节点验证交易的方法
CN109003082B (zh) * 2018-07-24 2021-11-09 电子科技大学 基于联盟区块链的phev能量交易系统及其交易方法

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106503981A (zh) * 2016-10-19 2017-03-15 江苏通付盾科技有限公司 简单支付验证节点交易查询方法及系统
US20180181953A1 (en) * 2016-12-22 2018-06-28 Mastercard International Incorporated Method and system for anonymous directed blockchain transaction
CN107247773A (zh) * 2017-06-07 2017-10-13 北京邮电大学 一种基于区块链的在分布式数据库中进行交易查询的方法
CN107766542A (zh) * 2017-10-30 2018-03-06 上海分布信息科技有限公司 一种分区的区块链网络及其实现分区查询的方法
CN108876611A (zh) * 2018-05-31 2018-11-23 中国联合网络通信集团有限公司 交易信息处理方法、装置及区块链节点
CN108965342A (zh) * 2018-09-28 2018-12-07 真相网络科技（北京）有限公司 数据请求方访问数据源的鉴权方法及系统
CN110049087A (zh) * 2018-12-28 2019-07-23 阿里巴巴集团控股有限公司 一种联盟链的可信度验证方法、系统、装置及设备

Also Published As

Publication number Publication date
TW202027456A (zh) 2020-07-16
CN110049087B (zh) 2020-05-05
TWI727467B (zh) 2021-05-11
CN110049087A (zh) 2019-07-23

Similar Documents

Publication Publication Date Title
WO2020134624A1 (zh) 一种联盟链的可信度验证方法、系统、装置及设备
WO2020134627A1 (zh) 联盟链的可信度验证方法、系统、装置及设备
WO2020134616A1 (zh) 联盟链中的请求处理方法、系统、装置及设备
US20210160068A1 (en) Data sharing method, apparatus, and system, and electronic device
WO2020052372A1 (zh) 一种基于区块链的版权事件存证方法及系统
TW201935384A (zh) 資產管理方法及裝置、電子設備
TW201935375A (zh) 資產管理方法及裝置、電子設備
TW202011240A (zh) 一種基於區塊鏈的版權事件代理存證方法及系統
CN110741400A (zh) 区块链网络交互控制器
TW201822033A (zh) 資源處理方法及裝置
WO2020015406A1 (zh) 一种基于区块链对版权使用者进行信用评价的方法及装置
TWI706663B (zh) 基於多個區塊鏈網路的資料存證方法及系統
TWI719422B (zh) 基於區塊鏈存證的識別雙方證據真實性的方法及裝置
TWI706664B (zh) 基於多個區塊鏈網路的資料存證方法及系統
TWI700606B (zh) 基於區塊鏈存證的識別證據真實性的方法、裝置及電腦設備
WO2018126344A1 (zh) 一种数据处理方法及相关设备
CN109873839B (zh) 数据访问的方法、服务器与分布式系统
WO2020108052A1 (zh) 一种基于多个区块链网络的数据读取方法及系统
WO2020024648A1 (zh) 数据处理方法和装置、客户端、服务器
WO2023165226A1 (zh) 一种应用资源的备份方法、装置、电子设备及存储介质
TWI721548B (zh) 業務執行方法及裝置
WO2020108055A1 (zh) 一种基于多个区块链网络的数据读取方法及系统
CN111125246A (zh) 一种物品转移存证方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19905902

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19905902

Country of ref document: EP

Kind code of ref document: A1