CN111580981A

CN111580981A - Method, apparatus, device and medium for detecting deadlock in real-time full settlement system

Info

Publication number: CN111580981A
Application number: CN202010312264.6A
Authority: CN
Inventors: 方晖; 袁园; 曹圣皎
Original assignee: Alibaba Group Holding Ltd
Current assignee: Advanced New Technologies Co Ltd; Advantageous New Technologies Co Ltd
Priority date: 2019-07-31
Filing date: 2020-04-20
Publication date: 2020-08-25
Anticipated expiration: 2040-04-20
Also published as: PH12020000031A1; CN115454658A; CN111580981B

Abstract

Methods, systems, and apparatus, including computer programs stored on a computer-readable storage medium, for detecting deadlocks in a real-time full settlement system are disclosed. One of the methods comprises the following steps: instructing a plurality of users of the real-time total settlement system to independently calculate their respective liquidity information and a commitment value for the liquidity information; receiving the commitment values from the plurality of users; verifying correctness of the liquidity information of the plurality of users based on the commitment value; and determining whether there is a deadlock in the real-time full settlement system after the correctness of the liquidity information of the plurality of users is verified.

Description

Method, apparatus, device and medium for detecting deadlock in real-time full settlement system

Technical Field

This document relates generally to computer technology and, more particularly, to a method and apparatus for deadlock detection in a real-time full settlement system.

Background

Real-Time Gross Settlement (RTGS) systems are funds transfer systems in which funds (e.g., money or securities) are transferred from one party (e.g., a bank) to another party (e.g., another bank) in Real-Time and based on total value. When a settlement occurs for a transfer of funds, the transfer is typically final and irrevocable. For example, the settlement is in real time when the payment transaction is not subject to any hold period restrictions. For example, when payment transactions are based on one-to-one settlement without binding or netting with other transactions, the settlement is based on a total value. The RTGS system may be operated by a central bank of a country.

In some cases, one or more parties (e.g., banks) participating in the RTGS system may not have sufficient liquidity to settle their payment transactions. For example, assume that bank a is set to receive $15 from bank B and transfer $20 to bank C, and further assume that bank a has a liquidity of $0 before making a settlement. In this case, bank a cannot settle the transaction unless it obtains an additional liquidity supply. In this case, bank a is considered to cause a deadlock in the RTGS system.

Currently, a central bank operating the RTGS system can detect possible deadlocks. The central bank may detect the deadlock because it has the right to obtain liquidity and transaction information from the parties participating in the RTGS system, e.g., the bank. However, as decentralized computing is a trend, techniques such as blockchains are becoming more prevalent. Existing RTGS systems implemented based on decentralized computing techniques such as blockchains lack the ability to detect deadlocks.

A blockchain system, also known as a Distributed Ledger System (DLS) or consensus system, can allow participating parties to store data securely and non-tamperproof. Without reference to any particular use case, the blockchain system may include any DLS and may be used for public, private, and federated blockchain networks. The public blockchain network opens all entities to use the system and participate in consensus processing. The private blockchain network is provided for a specific entity which centrally controls read and write permissions. A federated blockchain network is provided for a selected entity group that controls the consensus process, and the federated blockchain network includes an access control layer.

The blockchain system is implemented using a peer-to-peer (P2P) network in which nodes communicate directly with each other, e.g., without the need for a fixed central server. Each node in the P2P network may initiate communication with another node in the P2P network. The blockchain system maintains one or more blockchains. Blockchains are data structures used to store data, such as transactions, that may prevent malicious parties from tampering with and manipulating the data.

Unlike RTGS systems operated by central banks where participants are willing or required to disclose their liquidity and transaction information to the central bank, participants in the blockchain system may be reluctant to disclose such information to other participants in the blockchain system. The lack of disclosure makes it difficult for RTGS systems implemented based on decentralized computing techniques, such as blockchains, to detect deadlocks. There is therefore a need for a privacy preserving deadlock detection method that can detect deadlocks without requiring any party to disclose its liquidity and transaction information. There is also a need for such a method to verify its computational correctness.

Disclosure of Invention

In one aspect, a computer-implemented method for detecting deadlock in a real-time full settlement system includes: instructing a plurality of users of the real-time total settlement system to independently calculate their respective liquidity information and a commitment value for the liquidity information; receiving the commitment values from the plurality of users; verifying correctness of the liquidity information of the plurality of users based on the commitment value; and determining whether there is a deadlock in the real-time full settlement system after the correctness of the liquidity information of the plurality of users is verified.

In another aspect, an apparatus for detecting deadlock in a real-time full settlement system includes: one or more processors; and one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon, the instructions executable by the one or more processors to: instructing a plurality of users of the real-time total settlement system to independently calculate their respective liquidity information and a commitment value for the liquidity information; receiving the commitment values from the plurality of users; verifying correctness of the liquidity information of the plurality of users based on the commitment value; and determining whether there is a deadlock in the real-time full settlement system after the correctness of the liquidity information of the plurality of users is verified.

In yet another aspect, a non-transitory computer readable medium having instructions stored therein, the instructions when executed by a processor of a device, cause the device to perform a method for detecting deadlocks in a real-time full settlement system. The method comprises the following steps: instructing a plurality of users of the real-time total settlement system to independently calculate their respective liquidity information and a commitment value for the liquidity information; receiving the commitment values from the plurality of users; verifying correctness of the liquidity information of the plurality of users based on the commitment value; and determining whether there is a deadlock in the real-time full settlement system after the correctness of the liquidity information of the plurality of users is verified.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments. In the following description of the designated drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated.

Fig. 1 is a schematic diagram of a blockchain system according to an embodiment.

Fig. 2 is a schematic diagram of a computing device for implementing a node in a blockchain system, according to an embodiment.

Fig. 3 is a flow diagram of a deadlock detection method that protects privacy, according to an embodiment.

FIG. 4 is a flow diagram of a method for detecting real-time full settlement deadlocks, according to an embodiment.

FIG. 5 is a block diagram of an apparatus for detecting real-time full settlement deadlocks, according to an embodiment.

Detailed Description

Embodiments herein provide methods and apparatus for providing privacy-preserving deadlock detection in a real-time full settlement (RTGS) system. The method and the equipment support the user of the RTGS system to locally calculate the mobility information. The method and apparatus also supports multi-party computing where multiple users of the RTGS system can jointly determine a minimum liquidity amount without any user disclosing their own liquidity information. The method and apparatus also requires that the user calculate a commitment value for liquidity that is calculated locally by the user and provide the commitment value to the blockchain system for validation. In this manner, the blockchain system may use the commitment value to verify the correctness of the liquidity information calculated by the user, and thus verify the correctness of the determined minimum liquidity amount, and utilize the determined minimum liquidity amount to detect deadlocks in the RTGS system.

The embodiments disclosed herein have one or more technical effects. In some embodiments, the methods and apparatus support local computation of mobility information by users of the RTGS system. This allows each user to perform computations locally without disclosing any private information that the user does not wish to share. In some embodiments, the methods and apparatus also support multi-party computing, which can be done without any user disclosing their own liquidity information to any other user. This allows users to do joint computations while preserving their privacy. In addition, in some embodiments, the methods and apparatus also require the user to calculate a commitment value for liquidity that is calculated locally by the user and provide the commitment value to the blockchain system for validation. This provides the ability for the blockchain system to verify the correctness of the computation without knowing the actual liquidity information of the user. If the user has changed the mobility information of his local computation during the computation, the method and apparatus can monitor the change and invalidate the computation result, thereby improving the accuracy of deadlock detection.

Blockchains are data structures used to store data, such as transactions, in such a way that malicious parties can be prevented from tampering with and manipulating the data. Transactions stored in this manner may be immutable and subsequently verified. A block chain includes one or more blocks. Each block is linked to the immediately preceding block by a cryptographic hash value (cryptographical hash) that includes the immediately preceding block. Each tile may also include a timestamp, its own cryptographic hash value, and one or more transactions. Transactions that have been generally verified by nodes of a blockchain system may be hashed and encoded into a data structure such as a merkel (Merkle) tree. In a Merkle tree, data at leaf nodes is hashed, and all hash values in each branch of the tree may be joined at the root of the branch. This process continues down the tree up to the root of the entire tree where hash values representing all of the data in the tree are stored. The hash value of a transaction purportedly stored in the tree can be quickly verified by determining whether it is consistent with the structure of the tree.

The blockchain system includes a network of computing nodes that manage, update, and maintain one or more blockchains. The network may be a public blockchain network, a private blockchain network, or a federated blockchain network. For example, many entities, such as hundreds, thousands, or even millions of entities, may operate in a public blockchain network, and each entity operates at least one node in the public blockchain network. Thus, a public blockchain network may be considered a public network with respect to participating entities. Sometimes, most entities (nodes) must sign each chunk in order for the chunk to be valid and added to the blockchain of the blockchain network. Exemplary public blockchain networks include peer-to-peer (peer-to-peer) payment networks that utilize distributed ledgers referred to as blockchains.

Typically, public blockchain networks may support open transactions. The open transaction is shared by all nodes within the public blockchain network and stored in the global blockchain. A global blockchain is a blockchain that is replicated across all nodes, and all nodes are in a fully-consensus state with respect to the global blockchain. To achieve consensus (e.g., agree to add blocks to a blockchain), a consensus protocol is implemented in a public blockchain network. Examples of consensus protocols include proof of work (POW) (e.g., implemented in some cryptocurrency networks), proof of rights (POS), and proof of authority (POA).

Typically, a private blockchain network may be provided for a particular entity that centrally controls read and write permissions. The entity controls which nodes can participate in the blockchain network. Thus, private blockchain networks are often referred to as authority networks, which limit who is allowed to participate in the network, as well as their level of participation (e.g., only in certain transactions). Various types of access control mechanisms may be used (e.g., existing participants vote to add a new entity, and regulatory agencies may control admission).

Typically, a federated blockchain network is private between the participating entities. In a federated blockchain network, the consensus process is controlled by a set of authorized nodes, one or more of which are operated by respective entities (e.g., financial institutions, insurance companies). For example, a federation of ten (10) entities (e.g., financial institutions, insurance companies) may operate a federated blockchain network, and each entity may operate at least one node in the federated blockchain network. Thus, a federated blockchain network can be considered a private network associated with the participating entities. In some examples, each entity (node) must sign each chunk in order for the chunk to be valid and added to the chain of chunks. In some examples, at least a subset of the entities (nodes) (e.g., at least 7 entities) must sign each tile in order for the tile to be valid and added to the tile chain.

Fig. 1 shows a schematic diagram of a blockchain system 100 according to an embodiment. Referring to fig. 1, a blockchain system 100 may include a plurality of nodes, e.g.,

node

102 and 110, configured to operate on a blockchain 120. Nodes 102-110 may form a network 112, such as a point-to-point (P2P) network. Each of

nodes

102 and 110 may be a computing device, such as a computer or computer system, configured to store a copy of block chain 120, or may be software, such as a process or application, running on the computing device. Each of the

nodes

102 and 110 may have a unique identifier.

Block chain 120 may include a progressively increasing list of records in the form of data blocks, such as blocks B1-B5 in FIG. 1. Each of tiles B1-B5 may include a timestamp, a cryptographic hash value of a previous tile, and data of the current tile, which may be a transaction such as a monetary transaction. For example, as shown in fig. 1, chunk B5 may include a timestamp, a cryptographic hash value for chunk B4, and transaction data for chunk B5. Further, for example, a hash operation may be performed on a previous chunk to generate a cryptographic hash value for the previous chunk. The hash operation may convert inputs of various lengths into fixed-length encrypted outputs by a hash algorithm such as SHA-256.

Node 102-110 may be configured to perform operations on blockchain 120. For example, when a node (e.g., node 102) wants to store new data onto blockchain 120, the node may generate a new block to be added to blockchain 120 and broadcast the new block to other nodes in network 112, such as

node

104 and 110. Based on the validity of the new tile, e.g., its signature and transaction validity, other nodes may determine to accept the new tile so that node 102 and other nodes may add the new tile to their respective copies of blockchain 120. As this process repeats, more and more data chunks may be added to blockchain 120.

Fig. 2 illustrates a schematic diagram of a computing device 200 for implementing a node, such as node 102 (fig. 1), in a blockchain system, according to an embodiment. Referring to fig. 2, computing device 200 may include a communication interface 202, a processor 204, and a memory 206.

The communication interface 202 may facilitate communication between the computing device 200 and devices used to implement other nodes in the network, such as node 104 and 110 (FIG. 1). In some embodiments, communication interface 202 is configured to support one or more communication standards, such as an internet standard or protocol, an Integrated Services Digital Network (ISDN) standard, and so on. In some embodiments, the communication interface 202 may include one or more of the following: a Local Area Network (LAN) card, cable modem, satellite modem, data bus, cable, wireless communication channel, radio-based communication channel, cellular communication channel, Internet Protocol (IP) based communication device, or other communication device for wired and/or wireless communication. In some embodiments, the communication interface 202 may be based on a public cloud infrastructure, a private cloud infrastructure, a hybrid public/private cloud infrastructure.

The processor 204 may include one or more special-purpose processing units, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), or various other types of processors or processing units. The processor 204 is coupled to the memory 206 and is configured to execute instructions stored in the memory 206.

Memory 206 may store instructions and data that are executable by the processor, such as a copy of blockchain 120 (fig. 1). The memory 206 may include any type or combination of volatile or non-volatile memory devices, such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, or a magnetic or optical disk. When the instructions in memory 206 are executed by processor 204, computing device 200 may perform operations on blockchain 120.

Referring again to fig. 1, in some embodiments, the blockchain system 100 may be implemented to support various types of parties or users, including, for example, banks, financial institutions, credit unions, and the like. Parties may utilize the blockchain system 100 to retrieve or record information including, for example, payment transfer information. Typically, records such as payment transfers recorded on the blockchain system 100 are encrypted by the interested party.

In some embodiments, blockchain system 100 may be implemented to support real-time full settlement (RTGS). For example, the blockchain system 100 may implement a policy such that all transfers, once processed, are final and irrevocable. The blockchain system 100 may also implement a policy such that payment transactions submitted to the blockchain system 100 are unaffected by the wait period. The blockchain system 100 may further implement a policy such that payment transactions are settled on a one-to-one basis without binding or netting any other transactions.

Fig. 3 illustrates a flow diagram of a privacy preserving deadlock detection method 300 for detecting a deadlock in an RTGS system implemented on a blockchain system, such as blockchain system 100 (fig. 1), according to an embodiment. The privacy preserving deadlock detection method 300 may detect deadlocks without requiring any party to disclose its liquidity and transaction information.

In step 302, each party participating in the RTGS system, e.g., parties A through N, may be instructed to independently calculate their liquidity information_iThe amount of money T to be transferred to the party (receivable)_iThe amount F transferred (payable) from the party_iAnd post transfer liquidity P_iIn which P is_i＝C_i+T_i-F_i。

At step 304, each party i may be instructed to independently calculate C based on a commitment scheme (commitment scheme)_i、T_i、F_iAnd P_iThe commitment value of (a). Each party i may be further instructed to commit said commitment value comm (C)_i)、comm(T_i)、comm(F_i) And comm (P)_i) Submitted to the blockchain system 100 for recording. The commitment scheme may include cryptographic primitives (cryptographic primitives) that allow parties to commit a particular value while hiding the value from other parties. In this way, each party only needs to commit the commitment value comm (C)_i)、comm(T_i)、comm(F_i) And comm (P)_i) Submitted to the blockchain system 100, in step 306, the blockchain system 100 can verify the correctness of the calculation of the mobility information by each party i by using the commitment values. For example, a node in the blockchain system 100 determines whether any party has changed its liquidity information C during execution of the privacy preserving deadlock detection method 300_i、T_i、F_iAnd P_i. As described in more detail below, if a party, such as party i, changes during the execution of the deadlock detection method 300 to protect privacyChanges its fluidity information C_i、T_i、F_iOr P_iThe blockchain system 100 will be able to detect the change and report an error.

In some embodiments, the commitment scheme may be a petersen (Pedersen) commitment scheme, for example, as disclosed in cryptology research progress-crypt 91 conference record: computer science lecture notes (1991) volume 576: torben Pryds Pedersen, pages 129-140, "non-interactive and information-theoretic security verifiable secret sharing," which is incorporated herein by reference in its entirety. The peterson commitment scheme is additionlike (additivy homomorphic), which means that once i-party commitments use for C_iAnd for T_iIs determined (these commitments are that party i will commit the commitment value comm (C) at step 304_i) And comm (T)_i) Performed at the time of submission to the blockchain system 100), commitment scheme provisioning

Is equal to comm (C)_i+T_i) Wherein

Indicates a kind of correspondence to comm (C)_i) And comm (T)_i) An algebraic operation (e.g., addition or multiplication) is performed. Using the Peterson promise as an example, the proprietary nature of the Peterson promise provides comm (C)_i)+comm(T_i) Is equal to comm (C)_i+T_i)。

Similarly, once i commits to use for F_iAnd for P_iIs determined (these commitments are that party i will commit the commitment value comm (F) at step 304_i) And comm (P)_i) Performed at the time of submission to the blockchain system 100), commitment scheme provisioning

Is equal to comm (F)_i+P_i). Using the Peterson promise as an example, the proprietary nature of the Peterson promise provides comm (F)_i)+comm(P_i) Is equal to comm (F)_i+P_i)。

Furthermore, because P_i＝C_i+T_i-F_iThis means C_i+T_i＝F_i+P_i. The commitment scheme provides

Should be equal to

Therefore, when party i is instructed to commit the commitment value comm (C)_i)、comm(T_i)、comm(F_i) And comm (P)_i) When submitted to the blockchain system 100 for recording, the blockchain system 100 can determine

Whether or not it is indeed equal to

If the blockchain system 100 determines

Is not equal to

The blockchain system 100 may infer that party i has changed C during execution of the privacy preserving deadlock detection method 300_i、T_i、F_iAnd P_iOne or more values of (a). In some embodiments, when determining

Is not equal to

The blockchain system 100 may report errors.

It should be understood that the peterson commitment described above is by way of example only and is not intended as limiting. It is surmised that other commitment schemes could be utilized instead of (or in addition to) the peterson commitment. In some embodiments, the selected commitment scheme may be additively homomorphic. It should also be understood that the commitment values are to be performed

The operations may vary depending on the commitment scheme utilized.

In some embodiments, the blockchain system 100 may implement one or more intelligent contracts and determine using the intelligent contracts

Whether or not equal to

For example, a user of blockchain system 100 may use a programming language such as C + +, Java, Solidity, Python, etc. to program an agreed-upon term into a smart contract, and when the term is satisfied, the smart contract may be automatically executed by blockchain system 100, e.g., to perform a task

Whether or not equal to

At step 308, if the blockchain system 100 determines, for each party i, i ∈ { a, B

Is equal to

The blockchain system 100 may instruct parties a through N to jointly perform a multiparty computation to determine the minimum liquidity amount P_min＝min_{i∈{A，B，...，N}}{P_i}. In some embodiments, parties A to N may jointly perform multi-party computations without disclosing liquidity information, including post-transfer liquidity P thereof_i. In this manner, parties A to N may jointly determine P_minAnd protect their privacy. In some embodiments, parties a to N may jointly execute a procedure disclosed in journal of cryptography (2010) 23: the multiparty computing protocol in "secure computation of median (and other elements specifying rank)" by Gagan Aggarwal et al in 373-401, which is incorporated herein by reference in its entirety. For example, parties a to N may jointly execute a multi-party computing protocol defined as follows:

1: each party is provided with initial values a and β set by the RTGS, the initial value a being small enough to represent the lowest post-transfer liquidity possible and the initial value β being large enough to represent the highest post-transfer liquidity possible.

2: repeat until "complete":

3: is provided with

4: indicating that each party i ∈ { a, B.,n pair of P_iComparing with m; if P is_iStrictly less than m, set at_i1 and g_i0; otherwise, if P_iStrictly greater than m, set at l_i0 and g_i＝1。

5 calculation ∑_{i∈{A，B，...，N}}l_iAnd ∑_{i∈{A，B，...，N}}g_i。

6 if ∑_{i∈{A，B，...，N}}l_iNot more than 0 and ∑_{i∈{A，B，...，N}}g_iN-1 or less, and m is reported as min (P)_A，P_B，...，P_N) Then, the "completion" is performed.

7 if ∑_{i∈{A，B，...，N}}l_iNot less than 1, setting β ═ m-1 (meaning min (P)_A，P_B，...，P_N) Less than m, so m should be reduced).

8 if ∑_{i∈{A，B，...，N}}g_iN, set α ═ m +1 (meaning min (P)_A，P_B，...，P_N) Greater than m, so m should increase).

9: complete the process

Note that the multi-party computing protocol described above may allow parties A to N to calculate a minimum liquidity amount P_minWithout exposing P_A，P_B，...，P_N. However, it should be understood that the multi-party computing protocol described above is provided as an example only and is not meant to be limiting. It is contemplated that parties a through N may implement other types of multi-party computing techniques to perform step 308.

It is also contemplated that in some embodiments, parties A through N may utilize a multiparty summation process to calculate ∑_{i∈{A，B，...，N}}l_iAnd ∑_{i∈{A，B，...，N}}g_iThus, parties A through N may calculate ∑_{i∈{A，B，...，N}}l_iAnd ∑_{i∈{A，B，...，N}}g_iWithout the parties disclosing their own l and g to each other, thereby further protecting the privacy of parties a to N. For example, in some embodiments, parties A to N may be jointly executing a set of International meeting papers at 24 th distributed computing SystemThe multiparty summation process disclosed in Yiping Shen et al, "confidential review for distributed computing System," in 600-607, or the multiparty summation process disclosed in "information society," 10(1), pages 59-72, 1998, "L.Jean Camp et al," provide review while protecting privacy, "both of which are incorporated herein by reference in their entirety.

In some embodiments, parties a to N may jointly perform a multiparty summation process by masking their i and g values. For illustration purposes, it is assumed that there are three parties, namely party A, party B and party C, and that their l and g values are l, respectively_A、l_B，、l_CAnd g_A、g_B、g_C. Each party i may be instructed to select two random integers, a and b, for the second order polynomial ax²+ bx + c, where the constant c in the polynomial represents the value of l for the party or the value of g for the party, depending on whether the party is instructed to calculate ∑_{i∈{A，B，...，N}}l_iOr ∑_{i∈{A，B，...，N}}g_iAssume that the parties are instructed to calculate ∑_{i∈{A，B，...，N}}l_iParty a may choose, for example, a-25 and b-83, meaning that party a defines its polynomial as 25x²+83x+l_A. Party a may mask its value of/by calculating the masked value using polynomials at x ═ 1, x ═ 2, and x ═ 3. Parties B and C may choose their random integers a and B to operate similarly to mask their own value of/.

Each party i may be further instructed to retain one of its masked values and share its remaining masked values with the other parties to calculate ∑_{i∈{A，B，...，N}}l_i. Continuing the three-party example above, party A may remain using polynomial 25x²+83x+l_ASharing the value of the mask calculated when x is 1 with party B using polynomial 25x²+83x+l_AThe value of the mask calculated at x-2 and shared with party C using polynomial 25x²+83x+l_AAnother mask value is calculated at x-3. Parties B and C may operate similarly on the values of their masks.

Each party i may then base its own reservation of the value of the mask and the slaveThe value of the mask received by the other party is calculated ∑_{i∈{A，B，...，N}}l_iThe fraction of (1). Continuing with the three-party example above, party a may compute a sum based on the values of its retained mask (e.g., party a computed at x ═ 1 using the polynomial of party a itself), the values of the mask received from party B (e.g., party B computed at x ═ 1 using the polynomial of party B), and the values of the mask received from party C (e.g., party C computed using the polynomial of party C, x ═ 1). Party B may compute a sum based on the value of its retained mask (e.g., party B computed at x ═ 2 using the polynomial of party B itself), the value of the mask received from party a (e.g., party a computed at x ═ 2 using the polynomial of party a), and the masked value received from party C (e.g., party C computed at x ═ 2 using the polynomial of party C). Party C may compute a sum based on the value of its retained mask (e.g., party C computed at x-3 using the polynomial of party C itself), the masked value received from party a (e.g., party a computed at x-3 using the polynomial of party a), and the masked value received from party B (e.g., party B computed at x-3 using the polynomial of party B).

The A-party to N-party may then combine the results to calculate ∑_{i∈{A，B，...，N}}l_iAnd ∑_{i∈{A，B，...，N}}g_iIf the parties represent their value of l using constants in polynomials, the sum of the combined values representing all constants used in these polynomials will be equal to ∑_{i∈{A，B，...，N}}l_iSimilarly, if parties use constants in polynomials to represent their g values, the sum of the combined values representing all constants used in these polynomials will be equal to ∑_{i∈{A，B，...，N}}g_iIn this way, the A-side to N-side may calculate ∑_{i∈{A，B，...，N}}l_iAnd ∑_{i∈{A，B，...，N}}g_iWithout the parties disclosing their own l and g to each other, thereby further protecting the privacy of parties a to N.

It should be appreciated that although the examples described above are discussed using quadratic polynomials to facilitate masking values provided by three participants, these examples are shown for illustrative purposes only and are not intended to be limitingIt should be appreciated that additional parties may participate in the multiparty summation process described above, it should also be appreciated that other types of multiparty computing processes may be implemented by the parties to facilitate ∑_{i∈{A，B，...，N}}l_iAnd ∑_{i∈{A，B，...，N}}g_iOptionally, in some embodiments, parties a through N may calculate ∑_{i∈{A，B，...，N}}l_iAnd ∑_{i∈{A，B，...，N}}g_iWithout the use of multi-party computation it should also be understood that ∑ is computed regardless of the A-to N-party selection_{i∈{A，B，...，N}}l_iAnd ∑_{i∈{A，B，...，N}}g_iThe calculation is only a sub-step of step 308. As described above, the ultimate goal of step 308 is to promote a minimum liquidity amount P_minWithout each party disclosing its post-transfer liquidity information P_A，P_B，...，P_N。

In step 310, the A-party to N-party blockchain system 100 may be instructed to submit the minimum liquidity amount P_minFor recording. In some embodiments, the blockchain system 100 may utilize a consensus protocol to verify P_minThe value of (c). If no consensus is achieved, the blockchain system 100 can reject P_min. In some embodiments, the blockchain system 100 may utilize other validation techniques to validate the submitted values. In some embodiments, the blockchain system 100 may accept the submitted value P_minAnd merge them into the blockchain system 100 without additional verification.

In step 312, the blockchain system 100 may be based on P_minDetermines whether a deadlock condition exists. In some embodiments, if P_min< 0, the blockchain system 100 can determine that a deadlock condition exists. The blockchain system 100 may notify one or more of party a to party N that additional liquidity is needed to resolve the deadlock situation. On the other hand, if P_min≧ 0, the blockchain system 100 can determine that the RTGS system is free of deadlocks and report that no additional liquidity is required. In some embodiments, the blockchain system 100 may implement intelligent contracts that are programmed to be based on P_minWhether it is < 0 or P_min≧ 0 to determine whether a deadlock condition exists.

In some embodiments, the blockchain system 100 may track the total number of pending transactions in the RTGS system and invoke the deadlock detection method 300 that protects privacy when the total number of pending transactions reaches a predetermined threshold. FIG. 4 illustrates a flow diagram of a method 400 for invoking the deadlock detection method 300 for privacy protection, according to an embodiment. The method 400 may be performed by one or more nodes in a blockchain system that maintains blockchains, such as node 102 and 110 (fig. 1) in the blockchain system 100.

At step 402, a node, such as node 102, may determine the number of transactions waiting to be performed on the blockchain system 100. For example, multiple transactions may be included in a new tile to be accepted by the blockchain system 100. These transactions are still waiting to be performed on the blockchain system 100. Node 102 may determine the number of such transactions in step 402. At step 404, the node 102 may determine whether the number of transactions waiting to be performed on the blockchain system 100 has exceeded a predetermined threshold. At step 406, in response to determining that the number of transactions waiting to be performed on the blockchain system 100 has exceeded a predetermined threshold, the node 102 may invoke the deadlock detection method 300 (fig. 3) that protects privacy.

At step 408, node 102 may indicate each participant, e.g., party i, i ∈ { A, B.., N }, to independently compute its liquidity information, including the current liquidity C_iAmount T to be transferred to party i (receivable)_iAmount F to be transferred out (payable) from party i_iAnd post-transfer liquidity P_i. In some embodiments, the node 102 may send instructions to the participants via a wired or wireless communication channel.

At step 410, the node may instruct each participant i to independently compute C based on the commitment scheme_i、T_i、F_iAnd P_iAnd the commitment value comm (C)_i)、comm(T_i)、comm(F_i) And comm (P)_i) Submitted to the blockchain system 100 for recording. In some embodiments, the participants may communicate via wired or wireless communicationThe channel submits the commitment value to the blockchain system 100.

At step 412, node 102 may verify the correctness of each participant's liquidity information based on the commitment value submitted by participant i. For example, node 102 may execute an intelligent contract to determine mobility information C_i、T_i、F_iAnd P_iWhether a change has occurred. In some embodiments, if node 102 determines that it is not available, then node 102 determines that it is available

Is not equal to

Node 102 may conclude that party i has changed C_i、T_i、F_iAnd P_iOne or more values of (a). In some embodiments, when determining

Is not equal to

The node 102 may report the error.

At step 414, if node 102 determines for all parties i ∈ { a, B

Is equal to

Node 102 may instruct the parties to jointly perform a multi-party calculation as described above in step 308 to determine the minimum liquidity amount P_min＝min_{i∈{A，B，...，N}}{P_i}. At step 416, node 102 may instruct the parties to transfer the minimum post-transfer liquidity amount P_minSubmitted to the blockchain system 100 for recording. At step 418, upon receiving the minimum post-transfer liquidity amount, the node 102 may base the P-based liquidity amount on_minWhether it is < 0 or P_min≧ 0 to determine whether a deadlock condition exists.

In some embodiments, for example, each of the parties a through N may track the number of transactions waiting to be processed by that particular party. When the number of transactions waiting to be processed by a particular party reaches a threshold established by that party, that particular party may indicate its intent to invoke the deadlock detection method 300 for privacy protection. In some embodiments, the deadlock detection method 300 may be invoked if parties a through N agree that the deadlock detection method 300 should be invoked. Once the consensus is reached, the node, such as node 102, may perform

steps

408 and 418 as described above.

In some embodiments, the node 102 may perform additional verification steps to verify the computational correctness of the privacy preserving deadlock detection method 300. For example, in some embodiments, node 102 may instruct the participants to implement a mobility-based authentication technique. Such liquidity-based verification techniques may instruct the parties to calculate an overall liquidity and compare the calculated overall liquidity to an overall liquidity known to exist in the RTGS system. If the calculated total mobility is not equal to the total mobility known to exist in the RTGS system, a node, such as node 102, in the blockchain system 100 may determine that an error has occurred and invalidate the calculation result of the method 300.

Additionally or alternatively, in some embodiments, the node 102 may instruct the parties to implement transaction-based authentication techniques. Such transaction-based verification techniques may indicate that the parties calculate the amount due and the amount paid in the RTGS system. If the amount due is not equal to the amount due, a node, such as node 102, in the blockchain system 100 may determine that an error has occurred and invalidate the calculation of method 300.

Fig. 5 shows a block diagram of a deadlock detection apparatus 500 according to an embodiment. Apparatus 500 may be an embodiment of a software process and may correspond to method 300 (fig. 3) and/or method 400 (fig. 4). Referring to fig. 5, apparatus 500 may include a determination module 502, an indication module 504, a reception module 506, and a detection module 508.

The determination module 502 may determine whether deadlock detection to protect privacy is invoked in the RTGS system. In some embodiments, the determination module 502 may make the determination based on the number of transactions waiting to be executed in the RTGS system. Alternatively or additionally, the parties participating in the RTGS system may track the number of transactions waiting locally and invoke a deadlock detection that protects privacy based on whether the parties agree, thereby determining whether to invoke a deadlock detection that protects privacy in the RTGS system.

In some embodiments, each party i ∈ { A, B.,. N } may calculate its current liquidity C_iThe amount of money T to be transferred to the party (receivable)_iThe amount F to be transferred out (due) from the party_iAnd post-transfer liquidity P_iIn which P is_i＝C_i+T_i-F_i。

Indication module 504 may further indicate to each participant i, i ∈ { a, B.., N }, that C is independently calculated based on the commitment scheme_i、T_i、F_iAnd P_iAnd the commitment value comm (C)_i)、comm(T_i)、comm(F_i) And comm (P)_i) Submitted to the receiving module 506.

Indication module 504 may further instruct the participants to perform a multi-party calculation to determine a minimum post-transfer liquidity amount P_min＝min_{i∈{A，B，...，N}}{P_i}. The indication module 504 may further indicate to the participant that the minimum post-transfer liquidity amount P is to be provided_minSubmitted to the receiving module 506.

The receiving module 506 may receive information provided by the participant and provide the received information to the detecting module 508. The detection module 508 may verify the computational correctness of the liquidity information of the participants, i.e., P_minAnd is based on P after the calculation correctness is verified_minIt is determined whether a deadlock condition exists. In some embodiments, the detection module 508 may communicate with a blockchain system, such as the blockchain system 100 (fig. 1), that utilizes a system programmed to determine P_minThe intelligent contract may be established by a computer program that calculates the correctness of the intelligent contract by, for each party i, i ∈ a, B,.., N }, confirmation

Is equal to

To confirm P_minThe accuracy of the calculation of (2). In some embodiments, the blockchain system may utilize the intelligent contract or another intelligent contract based on P_minTo determine if a deadlock condition exists. Intelligent contracts may be based on P_minWhether it is < 0 or P_min≧ 0 to determine whether a deadlock condition exists.

Each of the above modules may be implemented as software or hardware, or a combination of software and hardware. For example, each of the above modules may be implemented using a processor executing instructions stored in a memory. Also, for example, each of the above-described modules may be implemented using one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), controllers, micro-controllers, microprocessors, or other electronic components to perform the described methods. Further, each of the above modules may be implemented by using a computer chip or an entity, or by using a product having a specific function, for example. In one embodiment, the apparatus 500 may be a computer, and the computer may be a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email messaging device, a gaming console, a tablet, a wearable device, or any combination of these devices.

For the implementation of the functions and roles of each module in the apparatus 500, reference may be made to the corresponding steps in the above-described method. Details are omitted here for simplicity.

In some embodiments, the computer program product may include a non-transitory computer-readable storage medium having stored thereon computer-readable program instructions for causing a processor to perform the above-described method.

The computer readable storage medium may be a tangible device that may store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a Static Random Access Memory (SRAM), a portable compact disc read-only memory (CD-ROM), a Digital Versatile Disc (DVD), a memory stick, a floppy disk, a mechanical coding device such as a punch card or a raised pattern in a recess having instructions recorded thereon, and any suitable combination of the foregoing.

The computer-readable program instructions for performing the methods described above may be assembly instructions, Instruction Set Architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including an object oriented programming language and a conventional procedural programming language. The computer-readable program instructions may execute entirely on the computing device as a stand-alone software package, or may execute partially on a first computing device and partially on a second computing device remote from the first computing device. In the latter case, the second remote computing device may be connected to the first computing device over any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN).

The computer-readable program instructions may be provided to a processor of a general purpose or special purpose computer or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the methods described above.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments herein. In this regard, the blocks in the flowchart or block diagrams may represent software programs, segments, or portions of code, which comprise one or more executable instructions for implementing the specified functions. It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the diagrams and/or flowchart illustration, and combinations of blocks in the diagrams and flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

It is appreciated that certain features of the specification, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the disclosure that are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination, or as suitable in any other described embodiment herein. Unless otherwise specified, certain features described in the context of various embodiments are not essential features of those embodiments.

Although the present disclosure has been described in conjunction with specific embodiments, it is evident that many alternatives, modifications, and variations will be apparent to those skilled in the art. Accordingly, the following claims are intended to embrace all such alternatives, modifications and variances which fall within the scope of the claims.

Claims

1. A computer-implemented method for detecting deadlocks in a real-time full settlement system, the method comprising:

instructing a plurality of users of the real-time total settlement system to independently calculate their respective liquidity information and a commitment value for the liquidity information;

receiving the commitment values from the plurality of users;

verifying correctness of the liquidity information of the plurality of users based on the commitment value; and

determining whether a deadlock exists in the real-time full settlement system after the correctness of the liquidity information of the plurality of users is verified.

2. The method of claim 1, wherein determining whether a deadlock exists in the real-time full settlement system comprises:

instructing the plurality of users to jointly determine a minimum post-transfer liquidity, wherein the minimum post-transfer liquidity is jointly determined based on the liquidity information of each of the plurality of users without each of the plurality of users disclosing their liquidity information to each other;

receiving a minimum post-transfer liquidity determined by the federation; and

determining whether a deadlock exists based on the minimum post transfer liquidity.

3. The method of claim 1, wherein indicating the plurality of users comprises:

instructing each user i of the plurality of users to independently calculate its liquidity information, the liquidity information including a current liquidity C_iAmount of money to be charged T_iAmount due F_iAnd post transfer liquidity P_i。

4. The method of claim 3, wherein indicating the plurality of users further comprises:

instructing each user i to independently compute for the current liquidity C based on a commitment scheme_iThe amount T to be collected_iThe amount due F_iAnd said post transfer liquidity P_iTo generate a commitment value comm (C)_i)、comm(T_i)、comm(F_i) And comm (P)_i)。

5. The method of claim 4, wherein the commitment scheme is an additively homomorphic commitment scheme.

6. The method of claim 4 or 5, wherein receiving the commitment values from the plurality of users comprises:

receiving the commitment value comm (C) from each user i_i)、comm(T_i)、comm(F_i) And comm (P)_i)。

7. The method of claim 6, wherein verifying the correctness of the liquidity information for the plurality of users comprises:

based on the received commitment value comm (C)_i)、comm(T_i)、comm(F_i) And comm (P)_i) And determining whether the liquidity information of any one of the plurality of users is changed.

8. The method of claim 7, wherein determining whether the liquidity information of any one of the plurality of users has changed comprises:

for each user i, determining

Whether or not equal to

Wherein the content of the first and second substances,

is an algebraic operation.

9. The method of any preceding claim, wherein the real-time wholesale settlement system is implemented using a blockchain system.

10. The method of claim 9, further comprising:

executing an intelligent contract recorded on a blockchain of the blockchain system to verify correctness of the liquidity information of the plurality of users.

11. The method of any of claims 2 to 10, further comprising:

verifying the computational correctness of the jointly determined minimum post-transfer liquidity based on the liquidity totals involved in the real-time full settlement system.

12. The method of any of claims 2 to 11, further comprising:

verifying the computational correctness of the jointly determined minimum post-transfer liquidity based on the amount due and the amount due involved in the real-time full settlement system.

13. An apparatus for detecting deadlock in a real-time full settlement system, comprising:

one or more processors; and

one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executable by the one or more processors to perform the method of any of claims 1-12.

14. An apparatus for detecting deadlocks in a real-time full settlement system, the apparatus comprising a plurality of modules for performing the method of claims 1 to 12.

15. A non-transitory computer readable medium having stored thereon instructions that, when executed by a processor of a device, cause the device to perform the method of any of claims 1-12.