WO2020134616A1 - 联盟链中的请求处理方法、系统、装置及设备 - Google Patents

联盟链中的请求处理方法、系统、装置及设备 Download PDF

Info

Publication number
WO2020134616A1
WO2020134616A1 PCT/CN2019/115856 CN2019115856W WO2020134616A1 WO 2020134616 A1 WO2020134616 A1 WO 2020134616A1 CN 2019115856 W CN2019115856 W CN 2019115856W WO 2020134616 A1 WO2020134616 A1 WO 2020134616A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
request
client
processing
user
Prior art date
Application number
PCT/CN2019/115856
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 阿里巴巴集团控股有限公司
Priority to EP19903200.4A priority Critical patent/EP3817333B1/en
Priority to SG11202100899YA priority patent/SG11202100899YA/en
Publication of WO2020134616A1 publication Critical patent/WO2020134616A1/zh
Priority to US17/163,342 priority patent/US20210158353A1/en

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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • 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
    • G06Q30/00—Commerce
    • G06Q30/018—Certifying business or products
    • 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0609—Buyer or seller confidence or verification
    • 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
    • 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
    • H04L67/104—Peer-to-peer [P2P] networks
    • 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/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • 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
    • G06Q2220/00—Business processing using cryptography
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • the embodiments of the present specification relate to the field of information technology, and in particular, to a request processing method, system, device, and equipment in an alliance chain.
  • 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.
  • the number of users connected to different nodes varies. Some are more, some are less.
  • nodes in the alliance chain In some business scenarios, for example, when the client needs to verify the trustworthiness of the alliance chain, when users in the alliance chain need to send business requests to other nodes (non-docking nodes), it will cause more nodes. Nodes with few users are often requested, causing nodes in the alliance chain to process requests unevenly.
  • the embodiments of the present specification provide a request processing scheme in the alliance chain. Aspects include a request processing method in the alliance chain. After a transaction is generated on the client and the transaction is registered on the chain through a docking node, it includes:
  • the client sends a request to multiple nodes in the alliance chain, the request includes a transaction location query request and/or a simple payment verification SPV request, and the request includes a summary hash of the transaction;
  • Any node receives the request and determines whether the client is a user of its own node or a user of another node;
  • the client When the client is a user of another node, determine the first processing times of the own node's requests for other node users, and confirm the second processing times of other nodes' requests for the own node users;
  • processing the request includes: delaying processing the request sent by the client, or transferring the request to another node for processing;
  • the client verifies the credibility of the alliance chain containing the transaction information based on the consistency of the request results returned by multiple nodes.
  • the embodiment of the present specification also provides a method for verifying the credibility of the alliance chain. After the user generates a transaction and deposits the transaction on the chain through the docking node, the transaction includes:
  • any one of the plurality of nodes Before sending the request, for any one of the plurality of nodes, determine whether the number of requests sent to the node reaches a threshold, and if so, delay sending the request to the node;
  • the request includes a transaction location query request or a simple payment verification SPV request, and the request includes a digest hash of the target transaction.
  • the embodiments of the present specification also provide a request processing method in an alliance chain. After a user generates a transaction and deposits the transaction on the chain through a docking node, it includes:
  • Receive a request sent by the client the request includes a transaction location query request or a simple payment verification SPV request, and the request includes a digest hash of the target transaction;
  • the client When the client is a user of another node, determine the first processing times of the own node's requests for other node users, and confirm the second processing times of other nodes' requests for the own node users;
  • processing the request includes: delaying processing the request sent by the client, or transferring the request to another node for processing.
  • the embodiments of the present specification also provide a request processing system in an alliance chain. After generating a transaction on the client terminal and depositing the transaction on the chain through the docking node, including:
  • the client sends a request to multiple nodes in the alliance chain, the request includes a transaction location query request and/or a simple payment verification SPV request, and the request includes a summary hash of the transaction;
  • Any node receives the request and determines whether the client is a user of its own node or a user of another node;
  • the client When the client is a user of another node, determine the first processing times of the own node's requests for other node users, and confirm the second processing times of other nodes' requests for the own node users;
  • processing the request includes: delaying processing the request sent by the client, or transferring the request to another node for processing;
  • the client verifies the credibility of the alliance chain containing the transaction information based on the consistency of the request results returned by multiple nodes.
  • the embodiments of the present specification also provide a credibility verification device of an alliance chain. After a user generates a transaction and deposits the transaction on the chain through a docking node, the transaction includes:
  • the obtaining module obtains multiple node addresses in the alliance chain to send a request
  • the judgment module before sending the request, for any one of the plurality of nodes, judges whether the number of times of sending the request to the node reaches a threshold, and if so, delays sending the request to the node;
  • a receiving module receiving the request result returned by the multiple node addresses
  • the verification module verifies the credibility of the alliance chain according to the consistency of the multiple request results
  • the request includes a transaction location query request or a simple payment verification SPV request, and the request includes a digest hash of the target transaction.
  • the embodiment of the present specification also provides a request processing device in a consortium chain, which is located on a node in the consortium chain, generates a transaction at a user, and deposits the transaction on the chain through a docking node Later, the device includes:
  • the receiving module receives a request sent by a client, the request includes a transaction location query request or a simple payment verification SPV request, and the request includes a digest hash of the target transaction;
  • An identity determination module to determine whether the client is a user of its own node or a user of another node
  • a processing times determining module when the client is a user of another node, determines the first processing times of the own node's requests for other node users, and confirms the second processing times of other nodes' requests for the own node users;
  • the judgment module executes the processing of the request according to the first processing frequency and the second processing frequency, the processing includes: delaying processing the request sent by the client, or transferring the request to another node for processing;
  • the sending module sends the request processing result to the client.
  • the first processing times for processing the user requests of other nodes for itself in the node, and other nodes processing their own users The second processing times of the request, and calculate it, and then determine whether the result needs to delay the request or forward it to another node for processing, so that the request can be more balanced between the nodes of the alliance chain deal with.
  • Figure 1 is a schematic diagram of an architecture involved in the current alliance chain
  • FIG. 2 is a schematic flowchart of a request processing method in 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 of an alliance chain provided by an embodiment of this 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 a schematic diagram of 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.
  • the number of connected users varies from node to node.
  • Some nodes have a large number of users, such as node A in Figure 1, some nodes have a small number of users, such as node C in Figure 1, and some nodes Perhaps because of the need to keep the public secret, there are no registered users at all as nodes E and F in Figure 1.
  • nodes E and F there are no registered users at all as nodes E and F in Figure 1.
  • the embodiments of the present specification provide a request processing method in an alliance chain to achieve balanced processing of user requests in the alliance.
  • FIG. 2 is a schematic flowchart of a request processing method in an alliance chain provided by an embodiment of this specification.
  • the transaction is generated on the client and passed After the docking node deposits the transaction on the chain, the process includes the following steps:
  • the client sends a request to multiple nodes in the alliance chain.
  • the request includes a transaction location query request and/or a simple payment verification SPV request, and the request includes a summary 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.
  • the client can send a location query request and/or a simple payment verification SPV request in order to verify the credibility of the alliance chain.
  • Any node receives the request and determines whether the client is a user of its own node or a user of another node.
  • the determination method can be confirmed through the client identification or the user ID and so on.
  • each node can agree on a set of mutually agreed protocols in advance to identify the client or node user of each node.
  • each node is marked with a serial number, and each serial number corresponds to a node.
  • the serial number is carried in the request, and when any node receives the request, it can confirm which node's docking user the request comes from.
  • each node may add a header identifier to each node user ID when providing user registration for each node, and carry the user ID when the user sends a request, so that any node can parse the header of the user ID when receiving the request Know which node's docking user the request comes from.
  • the node If the node is a user of its own node, it can be processed directly. When the node is a user of another node, further judgment is required. Specifically, a table can be jointly maintained between each node of the alliance chain to record the number of requests of any other node processed by each node, so that for any node, its own node can be obtained from this table The first processing times for requests of other node users and the second processing times of requests for other node users by other nodes.
  • 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.
  • S207 Perform processing on the request according to the first processing frequency and the second processing frequency, the processing includes: delaying processing the request sent by the client, or transferring the request to another node for processing.
  • the contribution value characterizes the difference between a node's "self contribution” and "request others" when processing a request. Once the contribution value exceeds a certain threshold, it means that the node has made more contributions, and the node can delay the processing of reception Requests sent by users to other nodes, or forwarded requests sent by other nodes.
  • the preset contribution value condition is not met, it can still be processed locally.
  • nodes E and F have no registered users, and their contribution ratio is infinite, followed by node C.
  • nodes with few registered users do not need to handle large-scale services, and their processing capacity for large traffic is relatively weak (such nodes can be called weak nodes, such as node E in Figure 1). , F and C). Delaying the processing of requests can effectively reduce the load on weak nodes. Because in the solution of the embodiment of the present specification, the client does not need to obtain the verification result immediately, so the processing of the request by each node can be asynchronous, and the delayed processing does not affect the client's verification effect on the credibility of the alliance chain .
  • one possible implementation is to perform the delay or transfer process as soon as the contribution threshold condition is reached, and another possible implementation is to further distinguish whether the user is its own node user or other after reaching the contribution threshold condition Node user, and delay or transfer the request of other node users.
  • a node When a node forwards a request, in one embodiment, it can forward randomly. At this time, when another node receives the request, it can still perform delay judgment or request judgment. In the solution provided by the embodiment of the present specification, in order to improve the credibility of the verification result, when the request is randomly transferred to another other node, the other other node does not include the docking node of the client.
  • the contribution value of each node is determined according to the table maintained jointly by the alliance chain, and the request is preferentially forwarded to the node with the smallest contribution value. It should be noted that the delayed processing or forwarding request is not not processed. When the delay processing time limit is reached, you should continue to process this type of request and return the processing result to the client.
  • the requests involved in the embodiments of this specification include transaction location query requests and/or simple payment verification SPV requests, which can be used in scenarios where users verify the credibility of the alliance chain.
  • a block For location query requests, since a blockchain is composed of multiple blocks, 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.
  • 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.
  • 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 specific format of the blockchain can be customized, the content of the location information will be different in different block formats, which does not constitute a limitation on this solution.
  • each block of the blockchain contains all transactions recorded in the block, and can be represented by Merkle Merkle tree. All transactions in the block hash the data, and then store the hash value in the corresponding leaf node. Each leaf node in the tree represents a transaction. A leaf node in the tree indicates that there is a corresponding transaction in the block.
  • a node 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 Simple Payment Verification
  • the node can simply save the block header and verify whether the target transaction exists in the block through the hash and Merkle path of the target transaction. In other words, the SPV verification result of each node is a binary result, either "yes" or "no".
  • the client verifies the credibility of the alliance chain containing the transaction information based on the consistency of the request results returned by multiple nodes.
  • 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 SPV verification request because a transaction exists or does not exist in the alliance chain, in theory, when there is no problem in the alliance chain, the SPV verification results returned by each node should be exactly the same. Therefore, a stricter credibility confirmation method is that if all SPV verification results are consistent with "yes", then the alliance chain is confirmed to be credible, otherwise it is not credible. Of course, due to various network reasons, equipment reasons, etc., a certain deviation can be tolerated. For example, a threshold is set, and if the degree of consistency of the SPV verification result is "yes" exceeding the threshold, it is confirmed that the alliance chain is credible.
  • 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.
  • the alert message can indicate the degree of inconsistency of the request results of each node (for example, what are the "yes” and "no" results in each SPV result), and, specifically give the inconsistency with most results The request result of the node and this type of node.
  • a credibility value can also be calculated as a reference based on 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 first processing times for processing the user requests of other nodes for itself in the node, and other nodes processing their own users The second processing times of the request, and calculate it, and then determine whether the result needs to delay the request or forward it to another node for processing, so that the request can be more balanced between the nodes of the alliance chain deal with.
  • the client obtains multiple node addresses in the alliance chain, which may be that the client randomly obtains multiple node addresses in the alliance chain. Randomly obtaining node address verification can make the verification result more fair, and at the same time, It will also make the user's request flow to each node evenly.
  • 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 the 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 node can process the query request or SPV request sent by any client connected to itself.
  • each node may also provide a query service or SPV service to whitelist users, and the node may confirm that the user type of the client is an illegal user or a legal user according to the whitelist, and further Distinguish legal users and confirm whether they are own node users or other node users. If the client is determined to be an illegal user according to the white list, no processing will be performed.
  • the illegal users here can be regarded as unregistered users, or users whose time limit has expired, or users with limited rights, etc.
  • the node can confirm that the client sending the request is an illegal user, a legitimate user of its own node, or a non-legal user of its own node according to the white list.
  • the node processes the request only when the client is a legitimate user.
  • 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 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 requests to the node has reached the threshold, if it is , Delay sending a 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 the above manner, on the client side, it is possible to avoid consecutive requests for the same node and 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:
  • S301 Acquire multiple node addresses in the alliance chain to send a request; wherein the request includes a transaction location query request or a simple payment verification SPV request, and the request includes a digest hash of the target transaction;
  • S303 Before sending the request, for any one of the plurality of nodes, determine whether the number of times of sending the request to the node reaches a threshold, and if so, delay sending the request to the node;
  • acquiring multiple node addresses in the alliance chain includes randomly acquiring multiple node addresses in the alliance chain; or acquiring multiple node addresses in the alliance chain including the docking node addresses.
  • FIG. 4 is a schematic flowchart of a request processing method in an alliance chain provided by the embodiment.
  • the user generates a transaction and passes the docking node. After depositing the transaction on the chain, it includes:
  • S401 Receive a request sent by a client, where the request includes a transaction location query request or a simple payment verification SPV request, and the request includes a digest hash of the target transaction;
  • S403 Determine whether the client is a user of its own node or a user of another node
  • S405 When the client is a user of another node, determine the first processing times of the own node's request for other node users, and confirm the second processing times of the other node's requests for the own node user;
  • S407 Perform processing on the request according to the first and second processing times, the processing includes: delaying processing the request sent by the client, or transferring the request to another node for processing.
  • the above method further includes: determining a whitelist user of the own node, the whitelist is used to confirm that the user type of the client is an illegal user or a legal user, and the legal user Including own node users or other node users; send white lists to other nodes in the alliance chain, so that other nodes receive and store the white lists.
  • the above method further includes, when receiving the request, determining whether the client is a legitimate user, and if not, not processing the request.
  • transferring the request to another node for processing includes randomly transferring the request to another other node, and the other other node does not include the docking node of the client.
  • the embodiments of this specification also provide a request processing system in an alliance chain, including a client and an alliance chain network, where the alliance chain network includes multiple nodes; a transaction is generated on the client and connected through docking After the node deposits the transaction on the chain,
  • the client sends a request to multiple nodes in the alliance chain, the request includes a transaction location query request and/or a simple payment verification SPV request, and the request includes a summary hash of the transaction;
  • Any node receives the request and determines whether the client is a user of its own node or a user of another node;
  • the client When the client is a user of another node, determine the first processing times of the own node's requests for other node users, and confirm the second processing times of other nodes' requests for the own node users;
  • processing the request includes: delaying processing the request sent by the client, or transferring the request to another node for processing;
  • the client verifies the credibility of the alliance chain containing the transaction information based on the consistency of the request results returned by multiple nodes.
  • the client randomly obtains multiple node addresses in the alliance chain and sends a request to the multiple nodes in the alliance chain; or, the client obtains the address of the docking node in the alliance chain Multiple node addresses, sending requests to the multiple nodes in the alliance chain.
  • the node randomly transfers the request to another other node, which does not include the docking node of the client.
  • any node determines a whitelist user of its own node, and the whitelist is used to confirm that the user type of the client is illegal Users or legal users, the legal users include their own node users or other node users; send a white list to other nodes in the alliance chain, so that other nodes receive and store the white list.
  • the client determines whether the number of times the request for the node is sent reaches a threshold, and if so, delays sending the request to the node.
  • 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 for an alliance chain provided by an embodiment of the present specification.
  • the device includes:
  • the obtaining module 501 obtains multiple node addresses in the alliance chain to send a request
  • the judgment module 503 before sending the request, for any one of the plurality of nodes, judges whether the number of times of sending the request to the node reaches the threshold, and if so, delays sending the request to the node; of course, if the threshold is not reached, Then send the request normally;
  • the receiving module 505 receives the request result returned by the multiple node addresses
  • the verification module 507 verifies the credibility of the alliance chain according to the consistency of the multiple request results
  • the request includes a transaction location query request or a simple payment verification SPV request, and the request includes a digest hash of the target transaction.
  • 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.
  • FIG. 6 is a schematic structural diagram of a request processing apparatus provided by an embodiment of the present specification.
  • the apparatus includes:
  • the receiving module 601 receives a request sent by a client, the request includes a transaction location query request or a simple payment verification SPV request, and the request includes a digest hash of the target transaction;
  • the identity determination module 603 determines whether the client is a user of its own node or a user of another node;
  • the processing times determining module 605 when the client is a user of another node, determines the first processing times of the own node's requests for other node users, and confirms the second processing times of other nodes' requests for the own node users;
  • the judgment module 607 executes the processing of the request according to the first and second processing times, the processing includes: delaying processing the request sent by the client, or transferring the request to another node for processing.
  • the sending module 609 after any node finishes processing, it will send the result to the client.
  • the device further includes a whitelist marking module 611, which determines a whitelist user of its own node, and the whitelist is used to confirm that the user type of the client is an illegal user or a legal user, and the legal user includes its own node user Or users of other nodes; the sending module 609 sends the white list to other nodes in the alliance chain, so that other nodes receive and store the white list.
  • a whitelist marking module 611 which determines a whitelist user of its own node, and the whitelist is used to confirm that the user type of the client is an illegal user or a legal user, and the legal user includes its own node user Or users of other nodes; the sending module 609 sends the white list to other nodes in the alliance chain, so that other nodes receive and store the white list.
  • the judgment module 607 is further configured to judge whether the client is a legal user according to the white list when receiving the request, and if not, not to perform processing on the request.
  • the sending module is further used to randomly transfer the request to another other node, which does not include the docking node of the client.
  • 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 realize communication through wired mode (such as USB, network cable, etc.), or through wireless mode (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.

Abstract

公开了联盟链中的请求处理方法、系统、装置及设备。本说明书实施例所提供的方案，在客户端需要向联盟链中的其它节点发送业务请求的场景下，通过在节点中对于自身处理其它节点用户请求的第一处理次数，和其它节点处理自身用户请求的第二处理次数，并进行计算，进而得出判断结果是否需要对该请求进行延迟处理还是转发至另一节点进行处理。从而可以在联盟链的各节点之间对请求实现更为平衡的处理。

Description

联盟链中的请求处理方法、系统、装置及设备 技术领域
本说明书实施例涉及信息技术领域，尤其涉及联盟链中的请求处理方法、系统、装置及设备。
背景技术
在联盟链中，常常存在功能差异很大的多个节点，例如，在一条著作权存证的联盟链上，可能包括作品发布节点、版权登记节点、版权转让节点以及公证节点等等。而基于用户的不同需求，和用户对接的往往只是其中的一个节点，该节点可以认为是该用户的对接节点。不同的节点所对接的用户数量各不相同。有的多，有的少。
在某些业务场景下，例如，客户端需要对联盟链进行可信度验证时，此时联盟链中的用户需要向其它节点(非对接节点)发出业务请求时，则会造成用户多的节点经常会请求到用户少的节点，造成联盟链中的节点对于请求的处理不平衡。
基于此，需要一种对联盟链中的请求进行处理的方案。
发明内容
针对现有联盟链中的请求处理不平衡的问题，为在联盟链的各节点中对请求实现更平衡的处理，本说明书实施例提供一种联盟链中的请求处理方案，该方案的第一方面，包括一种联盟链中的请求处理方法，在客户端生成交易，并通过对接节点将所述交易上链存证后，包括：
客户端发送请求至联盟链中的多个节点，所述请求包括交易位置查询请求和/或简单支付验证SPV请求，所述请求中包含所述交易的摘要哈希；
任一节点接收所述请求，确定所述客户端是自身节点用户还是其它节点用户；
当所述客户端为其它节点用户时，确定自身节点对于其它节点用户的请求的第一处理次数，以及，确认其它节点对于自身节点用户请求的第二处理次数；
根据所述第一处理次数和第二处理次数，执行对请求的处理，所述处理包括：延迟处理所述客户端所发送的请求，或者，转移所述请求至其它节点处理；
客户端基于多个节点分别返回的请求结果的一致程度，验证包含所述交易信息的联盟链的可信度。
第二方面，本说明书实施例还提供一种联盟链的可信度验证方法，在用户生成交易，并通过对接节点将所述交易上链存证后，包括:
获取联盟链中的多个节点地址以发送请求；
在发送请求前，针对所述多个节点中的任一节点，判断对该节点的请求的发送次数是否到达阈值，若是，对该节点延迟发送请求；
接收所述多个节点地址返回的请求结果；
根据所述多个请求结果的一致程度，验证所述联盟链的可信度；
其中，所述请求包括交易位置查询请求或者简单支付验证SPV请求，所述请求中包含目标交易的摘要哈希。
第三方面，本说明书实施例还提供一种联盟链中的请求处理方法，在用户生成交易，并通过对接节点将所述交易上链存证后，包括:
接收客户端所发送的请求，所述请求包括交易位置查询请求或者简单支付验证SPV请求，所述请求中包含目标交易的摘要哈希；
确定所述客户端是自身节点用户还是其它节点用户；
当所述客户端为其它节点用户时，确定自身节点对于其它节点用户的请求的第一处理次数，以及，确认其它节点对于自身节点用户请求的第二处理次数；
根据所述第一处理次数和第二处理次数，执行对请求的处理，所述处理包括：延迟处理所述客户端所发送的请求，或者，转移所述请求至其它节点处理。
与第一方面对应的，本说明书实施例还提供一种联盟链中的请求处理系统，在客户端生成交易，并通过对接节点将所述交易上链存证后，包括:
客户端发送请求至联盟链中的多个节点，所述请求包括交易位置查询请求和/或简单支付验证SPV请求，所述请求中包含所述交易的摘要哈希；
任一节点接收所述请求，确定所述客户端是自身节点用户还是其它节点用户；
当所述客户端为其它节点用户时，确定自身节点对于其它节点用户的请求的第一处理次数，以及，确认其它节点对于自身节点用户请求的第二处理次数；
根据所述第一处理次数和第二处理次数，执行对请求的处理，所述处理包括：延迟处理所述客户端所发送的请求，或者，转移所述请求至其它节点处理；
客户端基于多个节点分别返回的请求结果的一致程度，验证包含所述交易信息的联盟链的可信度。
与第二方面对应的，本说明书实施例还提供一种联盟链的可信度验证装置，在用户生成交易，并通过对接节点将所述交易上链存证后，包括:
获取模块，获取联盟链中的多个节点地址以发送请求；
判断模块，在发送请求前，针对所述多个节点中的任一节点，判断对该节点的请求的发送次数是否到达阈值，若是，对该节点延迟发送请求；
接收模块，接收所述多个节点地址返回的请求结果；
验证模块，根据所述多个请求结果的一致程度，验证所述联盟链的可信度；
其中，所述请求包括交易位置查询请求或者简单支付验证SPV请求，所述请求中包含目标交易的摘要哈希。
与第三方面对应的，本说明书实施例还提供一种联盟链中的请求处理装置，位于所述联盟链中的节点上，在用户生成交易，并通过对接节点将所述交易上链存证后，所述装置包括:
接收模块，接收客户端所发送的请求，所述请求包括交易位置查询请求或者简单支付验证SPV请求，所述请求中包含目标交易的摘要哈希；
身份确定模块，确定所述客户端是自身节点用户还是其它节点用户；
处理次数确定模块，当所述客户端为其它节点用户时，确定自身节点对于其它节点用户的请求的第一处理次数，以及，确认其它节点对于自身节点用户请求的第二处理次数；
判断模块，根据所述第一处理次数和第二处理次数，执行对请求的处理，所述处理包括：延迟处理所述客户端所发送的请求，或者，转移所述请求至其它节点处理；
发送模块，发送请求处理结果至所述客户端。
本说明书实施例所提供的方案，在客户端需要向联盟链中的其它节点发送业务请求的场景下，通过在节点中对于自身处理其它节点用户请求的第一处理次数，和其它节点 处理自身用户请求的第二处理次数，并进行计算，进而得出判断结果是否需要对该请求进行延迟处理还是转发至另一节点进行处理，从而可以在联盟链的各节点之间对请求实现更为平衡的处理。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本说明书实施例。
此外，本说明书实施例中的任一实施例并不需要达到上述的全部效果。
附图说明
为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。
图1为当前联盟链中所涉及的一种架构示意图；
图2是本说明书实施例提供的系统方面的一种联盟链中的请求处理方法的流程示意图；
图3为本说明书是实施例所提供的客户端方面的一种联盟链的可信度验证方法的流程示意图；
图4为本说明书是实施例所提供的一种联盟链中的请求处理方法的流程示意图；
图5为本说明书实施例所提供的一种联盟链的可信度验证装置的结构示意图；
图6为本说明书实施例所提供的一种请求处理装置的结构示意图；
图7是用于配置本说明书实施例方法的一种设备的结构示意图。
具体实施方式
为了使本领域技术人员更好地理解本说明书实施例中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本说明书的一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于保护的范围。
在联盟链中通常包含了多个不同的功能节点，在当前，联盟链常采用的一种架构为， 各功能节点分别面向各自的用户，用户通过他们感兴趣的功能节点接入联盟链。
在本说明书实施例所涉及的联盟链中的节点，可以认为每个节点都参与联盟链网络的路由功能，同时也可以包含其他功能，例如，每个节点都可以参与验证并传播交易及区块信息，发现并维持与对等节点的连接，以及还可以在本地存储有完整的联盟链，和一些与联盟链相关的数据。
如图1所示，图1为当前联盟链中所涉及的一种架构示意图。在图1中，联盟链网络中的节点可能都包含有不同的功能，以及，各节点由于提供不同的功能，面向的目标用户也常常并不相同，在同一联盟链中，各功能节点还经常分别开发自己的应用程序APP让自身节点用户进行注册并接入。而用户则通常从中选取一个节点对接联盟链，进行交易发布以及验证。
在这种方式下，各节点的对接用户的数量各不相同，有些节点的用户数量多，如图1中的A节点，有些节点的用户数量少，如图1中的C节点，而有些节点则可能由于需要对公众保密，则完全没有注册用户如图1中的E、F节点。在一些业务场景下，当用户需要向其它节点(非对接节点)发送请求时，各节点之间对于请求的处理就显的很不平衡，注册用户少的节点总是会接收到超出本身本应负责处理的请求数量。因此，本说明书实施例提供一种联盟链中的请求处理方法，实现在联盟中对用户请求的平衡处理。
以下结合附图，详细说明本说明书各实施例提供的技术方案。本说明书实施例的方案的第一方面，如图2所示，图2是本说明书实施例提供的系统方面的一种联盟链中的请求处理方法的流程示意图，在客户端生成交易，并通过对接节点将所述交易上链存证后，该流程具体包括如下步骤：
S201，客户端发送请求至联盟链中的多个节点，所述请求包括交易位置查询请求和/或简单支付验证SPV请求，所述请求中包含所述交易的摘要哈希。
由于在用户完成交易并通过对接节点上链存证之后，就会收到一个关于该存证交易的通知消息，通常其中就包括摘要哈希，并保存于客户端本地。因此，客户端总是可以从本地中获取该摘要哈希，并将其加入交易位置查询请求中。
在客户端方面，可以是在收到该通知消息后，根据用户的指令发起查询请求；也可以是，接收到该通知消息即触发查询请求。
在用户通过对接节点接入联盟链进行交易处理时，交易的完成和验证仿佛是对接节点为中心的，进而，用户就会对该对接节点以及联盟链的可信度产生疑虑。因此，在这 种业务场景下，客户端可以发送位置查询请求和/或简单支付验证SPV请求，目的是为了对联盟链的可信度进行验证。
S203，任一节点接收所述请求，确定所述客户端是自身节点用户还是其它节点用户。
确定的方式可以是通过客户端标识或者用户ID等等方式来确认。在联盟链中，各节点可以事先约定好一套互相认可的协议，用于识别各节点的客户端或者节点用户。
例如，给各节点所提供的客户端进行序号标记，每个序号对应一个节点，在请求中携带该序号，任一节点接收到请求时即可确认该请求来自于哪个节点的对接用户。
又例如，各节点可以在提供各节点用户注册时，对各节点用户ID分别加入头部标识，在用户发送请求是携带该用户ID，从而任一节点接收到请求时可以解析用户ID的头部得知该请求来自于哪个节点的对接用户。
S205，当所述客户端为其它节点用户时，确定自身节点对于其它节点用户的请求的第一处理次数，以及，确认其它节点对于自身节点用户请求的第二处理次数。
若节点为自身节点用户，则直接进行处理即可。在节点为其它节点用户时，则需要进行进一步的判断。具体而言，可以在联盟链各节点之间共同维护一张表格，用以记载各节点所处理的任一其它节点的请求的次数，从而，对于任一节点，可以通过该表得出自身节点对于其它节点用户的请求的第一处理次数，以及，确认其它节点对于自身节点用户请求的第二处理次数。
第一处理次数和第二处理次数可以以一段时间为周期，例如，每天或者每月，定期进行清零，也可以是全部历史数据的数量统计。
S207，根据所述第一处理次数和第二处理次数，执行对请求的处理，所述处理包括：延迟处理所述客户端所发送的请求，或者，转移所述请求至其它节点处理。
判断是否延迟处理或者转发的条件，可以是根据第一处理次数X和第二处理次数Y计算获得一个贡献值Z与预设阈值进行比较，例如，Z＝(X-Y)/Y，或者，Z＝X/Y，或者Z＝(X-Y)等等。贡献值表征了一个节点在处理请求时的“自身贡献”和“请求他人”的差异，一旦贡献值超过了一定阈值，则表示该节点已经做出了较多贡献，则该节点可以延迟处理接收到的其它节点用户所发送的请求，或者将其它节点所发送的请求转发出去。当然，如果不满足预设的贡献值条件，则依然在本地进行处理即可。
基于联盟共享的原则，若任一用户在选取节点发送请求时随机选取的情形下，容易 理解，总是那些自身注册用户少的节点会接收到更多的请求。如图1中的架构下，节点E和F因为没有注册用户，其贡献比例值为无穷大，其次则为C节点。而在实际运用中，注册用户少的节点，因为其一般无需处理较大规模的业务，其一般对于大流量的处理能力相对弱(可称此类节点为弱节点，例如图1中的节点E、F和C)。对请求进行延迟处理请求可以有效降低弱节点的负荷。由于在本说明书实施例的方案中，客户端并不需要即时得到验证结果，因此各节点对于请求的处理可以是异步的，延迟处理并不会影响客户端对于联盟链的可信度的验证效果。
在延迟或者转移请求时，一种可实施方式为只要到达了贡献阈值条件即执行延迟或者转移处理，另一种可实施方式为，到达了贡献阈值条件之后，进一步区分用户是自身节点用户还是其它节点用户，并将其它节点用户的请求执行延迟或者转移处理。
对于延迟处理而言，一般而言，可以设置一个时间阈值，将接收到的请求推迟3个小时处理；或者，确定处理次数阈值为1000，如果自身的贡献值Z＝(X-Y)超过了该阈值，则延迟处理之后的所有请求。
而节点在转发请求时，在一种实施方式下，可以随机进行转发，此时，在另一节点接收到该请求时，仍然可以进行延迟判断或者请求判断。在本说明书实施例所提供的方案中，为提高验证结果的可信度，在将请求随机转移所述请求至另一其它节点时，所述另一其它节点不包括所述客户端的对接节点。
在另一种实施方式下，也可以根据上述的贡献值进行转发。例如，根据联盟链之间共同维护的表格确定出各节点的贡献值，将请求优先转发至贡献值最小的节点。需要说明的是，延迟处理或者转发请求并非不处理，在延迟处理时限到达时，则应继续处理该类请求，并将处理结果返回至客户端。
本说明书实施例所涉及的请求包括交易位置查询请求和/或简单支付验证SPV请求，均可用在用户对于联盟链的可信度进行验证的场景下。
对于位置查询请求而言，由于一个区块链由多个区块组成，同时，一个区块中通常包含多个交易。因此，在本说明书实施例中，所述的位置信息具体指的是该交易被存证时，处于区块链中的哪个区块上，以及，在该区块中的什么位置。在区块链中，可以有多种方式用来标识不同的区块，例如，区块头哈希值或者区块高度(block height)。区块头哈希值即为区块头进行哈希计算而得到的哈希值，可以用于唯一、明确地标识一个区块。在区块链中，通常第一个区块其区块高度为0，以后每增加一个区块，区块高度 加1。一个区块通常有一个明确的区块高度。因此，区块头哈希值或者区块高度可以作为区块元数据的一部分，被存储在节点中一个独立的数据库表中，以便于索引和更快地检索到该区块。同时，在一个区块中，由于通常包含了多个交易，因此，还可以用各交易在该区块中的地址偏移量来分别标识区块中的交易。显而易见，在同一个区块中，各交易的地址偏移量并不相同。
进而，可以在交易所处的区块上链存证以后，各节点中可以通过维护一张形如(交易摘要哈希，区块头哈希值，地址偏移量)，或者，(交易摘要哈希，区块高度，地址偏移量)的数据表，就可以通过交易的摘要哈希查询得到对应的区块标识以及交易在区块中的地址。换言之，节点可以通过交易的摘要哈希确定该交易在联盟链中的位置。当然，由于区块链的具体格式是可以自定义的，在不同的区块格式下，位置信息的内容也会有所不同，这并不构成对本方案的限定。
而对于SPV验证而言，在区块链的每个区块中，包含了记录于该区块的所有交易，并且可以默克尔Merkle树表示。区块中所有的交易将数据哈希化，然后将哈希值存储至相应的叶子节点中。树中的每个叶子节点表征了一个交易。树中的一个叶子节点表征区块中存在一笔对应的交易。为了证明区块中存在某个特定的目标交易，一个节点只需要计算log 2N个哈希值，形成一条从目标交易到树根的Merkle路径即可。节点在进行简单支付验证(Simplified Payment Verification，SPV)时，不必保存所有交易也不必下载整个区块。节点可以仅仅保存区块头，并通过目标交易的哈希和Merkle路径来验证目标交易是否存在于该区块中。换言之，各节点的SPV验证结果是一个二值结果，要么为“是”，要么为“否”。
S209，客户端基于多个节点分别返回的请求结果的一致程度，验证包含所述交易信息的联盟链的可信度。
对于位置查询请求而而言，由于一个交易在联盟链中只会有一个确定的位置，因此，联盟链的可信度可以基于查询结果的一致程度而定。理论上，各节点所返回的位置信息应该完全相同。一个较为严格的验证方式即为，若所有位置查询结果均一致，则该联盟链为可信的。当然，由于各种网络原因、设备原因等等，可以容许一定的偏差。例如，根据返回的所有结果的对一致程度进行计算，若返回的结果中不存在占比超过95％的相同查询结果，则认为联盟度可信度为0，否则，将所述相同结果的占比作为该联盟链的可信度。
而对于SPV验证请求而言，由于一个交易在联盟链中要么存在，要么不存在，理论 上，当联盟链没有问题时，各节点所返回的SPV验证结果应该完全相同。因此，一个较为严格的可信度确认方式为，若所有SPV验证结果均一致为“是”，则确认该联盟链是可信的，否则是不可信的。当然，由于各种网络原因、设备原因等等，可以容许一定的偏差。例如，设定一个阈值，若SPV验证结果的一致为“是”的程度超过该阈值，则确认该联盟链是可信的。
需要说明的是，上述基于位置查询结果的一致性进行验证的方案，和基于SPV验证的结果的一致性进行验证的方案，属于可以同时分开进行的方案。在实际操作中，二者的验证结果是分别独立的。换言之，客户端可以只选择一种方式执行验证，也可以同时选择两种方式执行验证，在同时执行两种验证方案时，需要二种验证方案的结果同时满足一致性条件，才认为联盟链是可信的。以及，在验证的过程中，两种方案的执行不分先后。
进一步地，当确认该联盟链不可信时，还可以发出警报。具体的，警报消息中可以指出各节点的请求结果不一致的程度是多少(例如，各SPV结果中“是”和“否”的结果分别是多少)，以及，具体的给出与多数结果不一致的节点和该类节点的请求结果。以及，还可以根据返回的所有结果的不一致的程度计算一个可信度数值作为参考。例如，若返回的结果中不存在占比超过一定阈值的相同查询结果，则认为联盟度可信，否则，则认为联盟链不可信。
本说明书实施例所提供的方案，在客户端需要向联盟链中的其它节点发送业务请求的场景下，通过在节点中对于自身处理其它节点用户请求的第一处理次数，和其它节点处理自身用户请求的第二处理次数，并进行计算，进而得出判断结果是否需要对该请求进行延迟处理还是转发至另一节点进行处理，从而可以在联盟链的各节点之间对请求实现更为平衡的处理。
在一种具体的实施方式下，客户端获取联盟链中的多个节点地址，可以是客户端随机获取联盟链中的多个节点地址，随机获取节点地址验证可以使得验证结果更加公正，同时，也会使得用户的请求平均的流向各节点。又或者，客户端获取联盟链中包含所述对接节点地址的多个节点地址，在这种方式下，用户可以首先选取一批节点地址，然后再将对接节点的地址加入即可。加入对接节点进行验证时，在返回的结果中也包含对接节点的验证结果，可以使得验证更具有针对性，提高用户体验。
在一种实施方式下，节点可以对于任意连接自己的客户端所发送的查询请求或者SPV请求进行处理。在另一种实施方式下，基于联盟共享的原则，各节点还可以提供查 询服务或者SPV服务给白名单用户，节点可以根据白名单确认所述客户端的用户类型为非法用户或者合法用户，以及进一步地对合法用户进行区分，确认是自身节点用户还是其它节点用户，如果根据白名单判断客户端是非法用户，则不进行处理。此处的非法用户可以认为是没有注册过的用户，或者时限到期的用户，或者权限受限的用户等等。换言之，节点可以根据白名单确认发送请求的客户端是非法用户、自身节点合法用户或者非自身节点合法用户，客户端是合法用户时节点才对请求进行处理。
确定白名单用户的具体方式包括：联盟链中的任一节点确定自身的白名单，并广播白名单至联盟链中的其它节点，以便其它节点根据所述白名单确定是否执行查询处理。一种常见的处理方式即为，联盟链中的任一节点将自身的注册用户确认为白名单用户并进行广播。而其它节点则可以根据请求所包含的客户端标识是否是白名单用户，来决定是否进行进一步的处理。此处的白名单可以以节点为最小单元，也可以以用户为最小单元，各节点所保存的白名单用户可以相同，也可以不同。节点接收到白名单用户所发送的请求时才进行处理。
例如，假设联盟链中存在A、B、C、D四个节点，在上述方案中，可以B、C、D节点将A节点的对接用户确认为白名单用户，四个节点共同维护；也可以在B节点的白名单用户中包括A节点的用户，但是C、D节点的白名单用户中不包括A节点的用户。具体的情形可以基于业务情形自行确定。
在较为一般的情形中，政府机构(例如公证处)或者公益机构(例如慈善机构)节点的对接用户可以是所有联盟链中其它节点的白名单用户，一个节点的业务伙伴节点的节点用户也可以是该节点的白名单用户。进一步，在各节点中还可以根据用户的来源或者历史行为数据以及其它因素(例如，第三方信用评估分)，对白名单用户进行权限分级，例如，最低权限的白名单用户只有查询权限，更高权限的白名单用户可能还可以拥有进一步的其它权限等等。
在一种实施方式下，客户端在选取多个节点时，有可能连续多次选到同一个节点，在这种方式下，客户端可以判断对该节点的请求的发送次数是否到达阈值，若是，对该节点延迟发送请求。发送次数的统计可以统计一段时间内的次数，也可以统计所有的历史次数。通过上述方式，在客户端方面即可以避免连续的请求同一节点，避免对另一节点的负荷的影响。
本说明书实施例的方案的第二方面，如图3所示，图3为本说明书是实施例所提供的客户端方面的一种联盟链的可信度验证方法的流程示意图，在用户生成交易，并通过 对接节点将所述交易上链存证后，包括:
S301，获取联盟链中的多个节点地址以发送请求；其中，所述请求包括交易位置查询请求或者简单支付验证SPV请求，所述请求中包含目标交易的摘要哈希；
S303，在发送请求前，针对所述多个节点中的任一节点，判断对该节点的请求的发送次数是否到达阈值，若是，对该节点延迟发送请求；
S305，接收所述多个节点地址返回的请求结果；
S307，根据所述多个请求结果的一致程度，验证所述联盟链的可信度。
进一步地，所述方法中S301中，获取联盟链中的多个节点地址，包括随机获取联盟链中的多个节点地址；或者，获取联盟链中包含所述对接节点地址的多个节点地址。
本说明书实施例的方案的第三方面，如图4所示，图4为本说明书是实施例所提供的一种联盟链中的请求处理方法的流程示意图，在用户生成交易，并通过对接节点将所述交易上链存证后，包括：
S401，接收客户端所发送的请求，所述请求包括交易位置查询请求或者简单支付验证SPV请求，所述请求中包含目标交易的摘要哈希；
S403，确定所述客户端是自身节点用户还是其它节点用户；
S405，当所述客户端为其它节点用户时，确定自身节点对于其它节点用户的请求的第一处理次数，以及，确认其它节点对于自身节点用户请求的第二处理次数；
S407，根据所述第一处理次数和第二处理次数，执行对请求的处理，所述处理包括：延迟处理所述客户端所发送的请求，或者，转移所述请求至其它节点处理。
进一步地，在接收客户端所发送的请求之前，上述方法还包括：确定自身节点的白名单用户，所述白名单用于确认所述客户端的用户类型为非法用户或者合法用户，所述合法用户包括自身节点用户或者其它节点用户；发送白名单至联盟链中的其它节点，以便其它节点接收并存储所述白名单。
进一步的，上述方法还包括，接收到请求时，判断所述客户端是否为合法用户，若否，不对请求执行处理。
进一步的，所述步骤S407中的，转移所述请求至其它节点处理，包括随机转移所述请求至另一其它节点，所述另一其它节点不包括所述客户端的对接节点。
与第一方面对应的，本说明书实施例还提供一种联盟链中的请求处理系统，包括客户端和联盟链网络，所述联盟链网络包括多个节点；在客户端生成交易，并通过对接节点将所述交易上链存证后，
客户端发送请求至联盟链中的多个节点，所述请求包括交易位置查询请求和/或简单支付验证SPV请求，所述请求中包含所述交易的摘要哈希；
任一节点接收所述请求，确定所述客户端是自身节点用户还是其它节点用户；
当所述客户端为其它节点用户时，确定自身节点对于其它节点用户的请求的第一处理次数，以及，确认其它节点对于自身节点用户请求的第二处理次数；
根据所述第一处理次数和第二处理次数，执行对请求的处理，所述处理包括：延迟处理所述客户端所发送的请求，或者，转移所述请求至其它节点处理；
客户端基于多个节点分别返回的请求结果的一致程度，验证包含所述交易信息的联盟链的可信度。
进一步地，在所述系统中，客户端随机获取联盟链中的多个节点地址，发送请求至联盟链中的所述多个节点；或者，客户端获取联盟链中包含所述对接节点地址的多个节点地址，发送请求至联盟链中的所述多个节点。
进一步地，在所述系统中，所述节点随机转移所述请求至另一其它节点，所述另一其它节点不包括所述客户端的对接节点。
进一步地，在所述系统中，在客户端发送请求至联盟链中的多个节点之前，任一节点确定自身节点的白名单用户，所述白名单用于确认所述客户端的用户类型为非法用户或者合法用户，所述合法用户包括自身节点用户或者其它节点用户；发送白名单至联盟链中的其它节点，以便其它节点接收并存储所述白名单。
进一步地，在所述系统中，在确定自身节点对于其它节点用户的请求的第一处理次数之前，任一节点接收到请求时，根据白名单判断所述客户端是否为合法用户，若否，不对请求执行处理。
进一步地，在所述系统中，客户端针对所述多个节点中的任一节点，判断对该节点的请求的发送次数是否到达阈值，若是，对该节点延迟发送请求。
与第二方面对应的，本说明书实施例还提供一种联盟链的可信度验证装置，在用户生成交易，并通过对接节点将所述交易上链存证后，如图5所示，图5为本说明书 实施例所提供的一种联盟链的可信度验证装置的结构示意图，所述装置包括：
获取模块501，获取联盟链中的多个节点地址以发送请求；
判断模块503，在发送请求前，针对所述多个节点中的任一节点，判断对该节点的请求的发送次数是否到达阈值，若是，对该节点延迟发送请求；当然，如果没有达到阈值，则正常发送请求；
接收模块505，接收所述多个节点地址返回的请求结果；
验证模块507，根据所述多个请求结果的一致程度，验证所述联盟链的可信度；
其中，所述请求包括交易位置查询请求或者简单支付验证SPV请求，所述请求中包含目标交易的摘要哈希。
进一步地，所述获取模块501，随机获取联盟链中的多个节点地址；或者，获取联盟链中包含所述对接节点地址的多个节点地址。
与第三方面对应的，本说明书实施例还提供一种联盟链中的请求处理装置，位于所述联盟链中的节点上，在用户生成交易，并通过对接节点将所述交易上链存证后，如图6所示，图6为本说明书实施例所提供的一种请求处理装置的结构示意图，所述装置包括：
接收模块601，接收客户端所发送的请求，所述请求包括交易位置查询请求或者简单支付验证SPV请求，所述请求中包含目标交易的摘要哈希；
身份确定模块603，确定所述客户端是自身节点用户还是其它节点用户；
处理次数确定模块605，当所述客户端为其它节点用户时，确定自身节点对于其它节点用户的请求的第一处理次数，以及，确认其它节点对于自身节点用户请求的第二处理次数；
判断模块607，根据所述第一处理次数和第二处理次数，执行对请求的处理，所述处理包括：延迟处理所述客户端所发送的请求，或者，转移所述请求至其它节点处理。
发送模块609，任一节点在处理完之后，即将发送结果至所述客户端。
进一步地，所述装置还包括白名单标记模块611，确定自身节点的白名单用户，所述白名单用于确认所述客户端的用户类型为非法用户或者合法用户，所述合法用户包括自身节点用户或者其它节点用户；发送模块609，发送白名单至联盟链中的其它节点，以便其它节点接收并存储所述白名单。
进一步地，所述判断模块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 (26)

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

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP19903200.4A EP3817333B1 (en) 2018-12-28 2019-11-06 Method and system for processing requests in a consortium blockchain
SG11202100899YA SG11202100899YA (en) 2018-12-28 2019-11-06 Methods, systems, apparatuss, and devices for processing request in consortium blockchain
US17/163,342 US20210158353A1 (en) 2018-12-28 2021-01-29 Methods, systems, apparatuses, and devices for processing request in consortium blockchain

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201811626391.2A CN110022345B (zh) 2018-12-28 2018-12-28 联盟链中的请求处理方法、系统、装置及设备
CN201811626391.2 2018-12-28

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/163,342 Continuation US20210158353A1 (en) 2018-12-28 2021-01-29 Methods, systems, apparatuses, and devices for processing request in consortium blockchain

Publications (1)

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

Family

ID=67188704

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/115856 WO2020134616A1 (zh) 2018-12-28 2019-11-06 联盟链中的请求处理方法、系统、装置及设备

Country Status (6)

Country Link
US (1) US20210158353A1 (zh)
EP (1) EP3817333B1 (zh)
CN (1) CN110022345B (zh)
SG (1) SG11202100899YA (zh)
TW (1) TWI718714B (zh)
WO (1) WO2020134616A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112333159A (zh) * 2020-10-22 2021-02-05 北京梆梆安全科技有限公司 基于区块链的移动物联网终端访问控制方法、装置及系统

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110022345B (zh) * 2018-12-28 2020-03-24 阿里巴巴集团控股有限公司 联盟链中的请求处理方法、系统、装置及设备
CN110620776B (zh) * 2019-09-24 2021-11-26 腾讯科技（深圳）有限公司 一种数据转移信息传输方法及其装置
CN111125737B (zh) * 2019-12-25 2022-07-19 河北先河环保科技股份有限公司 基于区块链的环境监测系统
CN113032735B (zh) * 2021-05-21 2021-08-17 浙江数秦科技有限公司 基于区块链技术的数字资产存证及侵权监测系统和方法

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160316003A1 (en) * 2015-04-27 2016-10-27 Microsoft Technology Licensing Llc Balancing resources in distributed computing environments
CN106452785A (zh) * 2016-09-29 2017-02-22 财付通支付科技有限公司 区块链网络、分支节点及区块链网络应用方法
CN107077674A (zh) * 2016-12-29 2017-08-18 深圳前海达闼云端智能科技有限公司 交易验证处理方法、装置及节点设备
US20180101560A1 (en) * 2016-10-07 2018-04-12 International Business Machines Corporation Establishing overlay trust consensus for blockchain trust validation system
CN108681900A (zh) * 2018-07-18 2018-10-19 众安信息技术服务有限公司 轻节点验证交易的方法
CN110022345A (zh) * 2018-12-28 2019-07-16 阿里巴巴集团控股有限公司 联盟链中的请求处理方法、系统、装置及设备
CN110049087A (zh) * 2018-12-28 2019-07-23 阿里巴巴集团控股有限公司 一种联盟链的可信度验证方法、系统、装置及设备
CN110046901A (zh) * 2018-12-28 2019-07-23 阿里巴巴集团控股有限公司 联盟链的可信度验证方法、系统、装置及设备

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103095727B (zh) * 2013-02-07 2015-10-21 北京邮电大学 P2p资源定位方法
US10812274B2 (en) * 2015-05-07 2020-10-20 Blockstream Corporation Transferring ledger assets between blockchains via pegged sidechains
JP2018525729A (ja) * 2015-07-14 2018-09-06 エフエムアール エルエルシー 計算上効率的な移転処理、監査及びサーチ装置、方法及びシステム
CN107067262A (zh) * 2015-09-30 2017-08-18 阿里巴巴集团控股有限公司 业务处理方法、系统及用户终端
WO2017127620A1 (en) * 2016-01-20 2017-07-27 Al-Masoud Mezyad M Systems and methods for managing a talent based exchange
CN106789089B (zh) * 2017-02-23 2019-10-08 腾讯科技（深圳）有限公司 管理证书的方法、装置、和系统以及服务器
CN110430064B (zh) * 2017-03-30 2020-12-04 腾讯科技（深圳）有限公司 区块链系统、消息处理方法及存储介质
WO2018201147A2 (en) * 2017-04-28 2018-11-01 Neuromesh Inc. Methods, apparatus, and systems for controlling internet-connected devices having embedded systems with dedicated functions
CN107506997B (zh) * 2017-08-04 2021-12-10 苏州缓流科技有限公司 基于区块链技术的用户移动终端上主动扫码的支付方法
CN107948283A (zh) * 2017-11-24 2018-04-20 中钞信用卡产业发展有限公司杭州区块链技术研究院 一种联盟链大文件存储及校验的方法及系统
TWM561279U (zh) * 2018-02-12 2018-06-01 林俊良 用於處理金融資產之策略模型腳本之區塊鏈系統與節點伺服器
CN108650270B (zh) * 2018-05-16 2020-10-23 苏宁易购集团股份有限公司 基于联盟链和激励机制的数据共享方法及系统
CN109087204B (zh) * 2018-07-27 2023-04-14 杭州复杂美科技有限公司 跨链交易校验方法、设备和存储介质
CN108989052B (zh) * 2018-08-28 2021-04-13 中国联合网络通信集团有限公司 交易请求处理方法及系统
CN109063426A (zh) * 2018-09-20 2018-12-21 新华智云科技有限公司 一种基于联盟区块链的版权存证共享方法及系统

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160316003A1 (en) * 2015-04-27 2016-10-27 Microsoft Technology Licensing Llc Balancing resources in distributed computing environments
CN106452785A (zh) * 2016-09-29 2017-02-22 财付通支付科技有限公司 区块链网络、分支节点及区块链网络应用方法
US20180101560A1 (en) * 2016-10-07 2018-04-12 International Business Machines Corporation Establishing overlay trust consensus for blockchain trust validation system
CN107077674A (zh) * 2016-12-29 2017-08-18 深圳前海达闼云端智能科技有限公司 交易验证处理方法、装置及节点设备
CN108681900A (zh) * 2018-07-18 2018-10-19 众安信息技术服务有限公司 轻节点验证交易的方法
CN110022345A (zh) * 2018-12-28 2019-07-16 阿里巴巴集团控股有限公司 联盟链中的请求处理方法、系统、装置及设备
CN110049087A (zh) * 2018-12-28 2019-07-23 阿里巴巴集团控股有限公司 一种联盟链的可信度验证方法、系统、装置及设备
CN110046901A (zh) * 2018-12-28 2019-07-23 阿里巴巴集团控股有限公司 联盟链的可信度验证方法、系统、装置及设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3817333A4 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112333159A (zh) * 2020-10-22 2021-02-05 北京梆梆安全科技有限公司 基于区块链的移动物联网终端访问控制方法、装置及系统
CN112333159B (zh) * 2020-10-22 2022-09-23 北京梆梆安全科技有限公司 基于区块链的移动物联网终端访问控制方法、装置及系统

Also Published As

Publication number Publication date
US20210158353A1 (en) 2021-05-27
TW202027458A (zh) 2020-07-16
SG11202100899YA (en) 2021-03-30
EP3817333A1 (en) 2021-05-05
CN110022345B (zh) 2020-03-24
CN110022345A (zh) 2019-07-16
EP3817333A4 (en) 2021-09-08
EP3817333B1 (en) 2023-03-08
TWI718714B (zh) 2021-02-11

Similar Documents

Publication Publication Date Title
TWI727467B (zh) 聯盟鏈的可信度驗證方法、系統、裝置及設備
WO2020134616A1 (zh) 联盟链中的请求处理方法、系统、装置及设备
TWI712972B (zh) 聯盟鏈的可信度驗證方法、系統、裝置及設備
WO2020029631A1 (zh) 一种基于中心化结算与区块链存证的交易方法及系统
WO2021143497A1 (zh) 一种基于存证区块链的侵权存证方法、装置及设备
WO2020029629A1 (zh) 一种基于中心化结算与区块链存证的交易方法及系统
TW201935375A (zh) 資產管理方法及裝置、電子設備
WO2021036172A1 (zh) 一种区块链交易查询方法及系统
WO2021036170A1 (zh) 一种区块链交易处理方法及装置
TWI719422B (zh) 基於區塊鏈存證的識別雙方證據真實性的方法及裝置
TWI700606B (zh) 基於區塊鏈存證的識別證據真實性的方法、裝置及電腦設備
TWI706663B (zh) 基於多個區塊鏈網路的資料存證方法及系統
US20210336798A1 (en) Signature verification for a blockchain ledger
WO2020233051A1 (zh) 跨网段互连的区块链网络实现方法、装置、系统及介质
WO2021036171A1 (zh) 一种区块链交易处理方法及装置
TWI706664B (zh) 基於多個區塊鏈網路的資料存證方法及系統
WO2018126344A1 (zh) 一种数据处理方法及相关设备
WO2020134620A1 (zh) 一种受理区块链存证交易的方法及系统
WO2020108052A1 (zh) 一种基于多个区块链网络的数据读取方法及系统
TWI721548B (zh) 業務執行方法及裝置
WO2020108055A1 (zh) 一种基于多个区块链网络的数据读取方法及系统
JP2021121886A (ja) クラウド監視・修復方法、クラウド監視・修復システム及びプログラム
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: 19903200

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019903200

Country of ref document: EP

Effective date: 20210126

NENP Non-entry into the national phase

Ref country code: DE