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

Abstract

Disclosed herein are methods, systems, and apparatus, including computer programs stored on computer-readable storage media, for detecting deadlocks in a real-time gross settlement system. One of the methods includes instructing a plurality of users of the real-time gross 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 values, and determining whether a deadlock exists in the real-time gross settlement system after the correctness of the liquidity information of the plurality of users is verified.

Description

Technical Field

[0001] This article generally relates to computer technology, and more specifically, to methods and apparatus for deadlock detection in real-time full settlement systems. Background Technology

[0002] A Real-Time Gross Settlement (RTGS) system is a money transfer system 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 on a gross basis. When a money transfer is settled, the transfer is typically final and irreversible. For example, when a payment transaction is not subject to any waiting period, the settlement is real-time. For example, when a payment transaction is settled on a one-to-one basis without being tied to or netting other transactions, the settlement is on a gross basis. An RTGS system can be operated by a country's central bank.

[0003] In some cases, one or more parties participating in an RTGS system (such as banks) may not have sufficient liquidity to settle their payment transactions. For example, suppose bank A is set up to receive $15 from bank B and transfer $20 to bank C, and further suppose bank A has $0 in liquidity before settlement. In this scenario, bank A cannot settle the transaction unless it receives additional liquidity. In this case, bank A is considered to have caused a deadlock in the RTGS system.

[0004] Currently, central banks operating RTGS systems can detect potential deadlocks. Central banks can detect deadlocks because they have access to liquidity and transaction information from all parties participating in the RTGS system, such as banks. However, as decentralized computing becomes a trend, technologies such as blockchain are becoming increasingly prevalent. Existing RTGS systems based on decentralized computing technologies such as blockchain lack the ability to detect deadlocks.

[0005] A blockchain system, also known as a distributed ledger system (DLS) or consensus system, enables participating parties to store data securely and immutably. Without referring to any specific use case, a blockchain system can include any DLS and can be used in public, private, and consortium blockchain networks. Public blockchain networks are open to all entities for use and participation in consensus processing. Private blockchain networks are provided to specific entities that centrally control read and write permissions. Consortium blockchain networks are provided to a selected group of entities that control consensus processing, and include an access control layer.

[0006] A blockchain system is implemented using a peer-to-peer (P2P) network, where nodes communicate directly with each other, for example, without requiring a fixed central server. Each node in a P2P network can initiate communication with another node in the network. A blockchain system maintains one or more blockchains. A blockchain is a data structure used to store data such as transactions, which can prevent malicious parties from tampering with and manipulating the data.

[0007] Unlike central bank-operated real-time GS (RTGS) systems where participants are willing or required to disclose their liquidity and transaction information to the central bank, participants in blockchain systems may be unwilling to disclose such information to other participants in the blockchain system. This lack of disclosure makes it difficult for RTGS systems based on decentralized computing technologies such as blockchain to detect deadlocks. Therefore, privacy-preserving deadlock detection methods are needed to detect deadlocks without requiring any participant to disclose their liquidity and transaction information. Methods to verify the correctness of computations are also needed. Summary of the Invention

[0008] In one aspect, a computer-implemented method for detecting deadlock in a real-time gross settlement system includes: instructing multiple users of the real-time gross settlement system to independently calculate their respective liquidity information and commitment values ​​for the liquidity information; receiving the commitment values ​​from the multiple users; verifying the correctness of the liquidity information of the multiple users based on the commitment values; and, after the correctness of the liquidity information of the multiple users has been verified, determining whether deadlock exists in the real-time gross settlement system.

[0009] In another aspect, an apparatus for detecting deadlock in a real-time gross settlement system includes: one or more processors; and one or more computer-readable storage devices coupled to the one or more processors and storing instructions thereon, the instructions being executable by the one or more processors to: instruct multiple users of the real-time gross settlement system to independently calculate their respective liquidity information and commitment values ​​for the liquidity information; receive the commitment values ​​from the multiple users; verify the correctness of the liquidity information of the multiple users based on the commitment values; and, after the correctness of the liquidity information of the multiple users has been verified, determine whether deadlock exists in the real-time gross settlement system.

[0010] In another aspect, a non-transitory computer-readable medium storing instructions, which are executed by a processor of a device, cause the device to perform a method for detecting deadlock in a real-time gross settlement system. The method includes: instructing multiple users of the real-time gross settlement system to independently calculate their respective liquidity information and commitment values ​​for the liquidity information; receiving the commitment values ​​from the multiple users; verifying the correctness of the liquidity information of the multiple users based on the commitment values; and, after the correctness of the liquidity information of the multiple users has been verified, determining whether deadlock exists in the real-time gross settlement system. Attached Figure Description

[0011] The accompanying drawings, which are included and form part of this document, illustrate embodiments. In the following description of the drawings, unless otherwise shown, the same numerals in different drawings denote the same or similar elements.

[0012] Figure 1 This is a schematic diagram of a blockchain system according to an embodiment.

[0013] Figure 2 This is a schematic diagram of a computing device for implementing nodes in a blockchain system, according to an embodiment.

[0014] Figure 3 This is a flowchart of a privacy-protecting deadlock detection method according to an embodiment.

[0015] Figure 4 This is a flowchart of a method for detecting real-time full settlement deadlock according to an embodiment.

[0016] Figure 5 This is a block diagram of an apparatus for detecting real-time full settlement deadlock according to an embodiment. Detailed Implementation

[0017] This document provides methods and apparatus for providing privacy-preserving deadlock detection in Real-Time Gross Settlement (RTGS) systems. The methods and apparatus support local computation of liquidity information by users within the RTGS system. They also support multi-party computation, where multiple users of the RTGS system can jointly determine a minimum liquidity amount without any user disclosing their own liquidity information. Furthermore, the methods and apparatus require users to compute a commitment value for their locally computed liquidity and provide this commitment value to a blockchain system for verification. In this way, the blockchain system can use the commitment value to verify the correctness of the liquidity information computed by the users, thus verifying the correctness of the determined minimum liquidity amount, and using the determined minimum liquidity amount to detect deadlocks in the RTGS system.

[0018] The embodiments disclosed herein have one or more technical effects. In some embodiments, the methods and apparatus support local computation of liquidity information by users of the RTGS system. This allows each user to perform computation 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 computation, which can be performed without any user disclosing their own liquidity information to any other user. This allows users to perform joint computation while preserving their privacy. Furthermore, in some embodiments, the methods and apparatus also require users to compute a commitment value of their locally computed liquidity and provide this commitment value to the blockchain system for verification. This provides the blockchain system with the ability to verify the correctness of the computation without knowing the user's actual liquidity information. If a user has changed their locally computed liquidity information during computation, the methods and apparatus can detect the change and invalidate the computation result, thereby improving the accuracy of deadlock detection.

[0019] A blockchain is a data structure used to store data such as transactions, preventing malicious parties from tampering with and manipulating the data. Transactions stored in this way can be immutable and subsequently verified. A blockchain consists of one or more blocks. Each block is linked to the preceding block by including its own cryptographic hash. Each block may also include a timestamp, its own cryptographic hash, and one or more transactions. Transactions that have typically been verified by nodes in the blockchain system can be hashed and encoded into a data structure such as a Merkle tree. In a Merkle tree, the data at the leaf nodes is hashed, and all hashes in each branch of the tree can be concatenated at the root of that branch. This process continues along the tree to the root, where hashes representing all the data in the tree are stored. The hashes of transactions claimed to be stored in the tree can be quickly verified by determining whether they are consistent with the tree's structure.

[0020] A blockchain system comprises a network of computing nodes that manage, update, and maintain one or more blockchains. This network can be a public blockchain network, a private blockchain network, or a consortium blockchain network. For example, many entities, such as hundreds, thousands, or even millions, can operate in a public blockchain network, and each entity operates at least one node in the public blockchain network. Therefore, a public blockchain network can be considered a public network concerning the participating entities. Sometimes, a majority of entities (nodes) must sign each block for it to be valid and added to the blockchain of the blockchain network. Exemplary public blockchain networks include specific peer-to-peer payment networks that utilize a distributed ledger called a blockchain.

[0021] Typically, public blockchain networks support public transactions. Public transactions are shared by all nodes within the public blockchain network and stored in the global blockchain. The global blockchain is a blockchain replicated across all nodes, and all nodes are in a state of full consensus relative to the global blockchain. To achieve consensus (e.g., agreeing to add blocks to the blockchain), consensus protocols are implemented in public blockchain networks. Examples of consensus protocols include Proof-of-Work (PoW) (e.g., implemented in some cryptocurrency networks), Proof-of-Stake (PoS), and Proof-of-Authority (PoA).

[0022] Typically, a private blockchain network can be provided for a specific entity, which centrally controls read and write permissions. The entity controls which nodes can participate in the blockchain network. Therefore, private blockchain networks are often referred to as permissioned networks, which restrict who is allowed to participate in the network and their level of participation (e.g., only in certain transactions). Various types of access control mechanisms can be used (e.g., existing participants vote to add new entities, and a governing body can control access).

[0023] Typically, consortium blockchain networks are private among the participating entities. In a consortium blockchain network, consensus processing is controlled by a set of authorized nodes, one or more of which are operated by their respective entities (e.g., financial institutions, insurance companies). For example, a consortium of ten (10) entities (e.g., financial institutions, insurance companies) can operate a consortium blockchain network, with each entity operating at least one node within the network. Therefore, a consortium blockchain network can be considered a private network associated with the participating entities. In some examples, each entity (node) must sign each block for the block to be valid and added to the blockchain. In some examples, at least a subset of the entities (nodes) (e.g., at least seven entities) must sign each block for the block to be valid and added to the blockchain.

[0024] Figure 1 A schematic diagram of a blockchain system 100 according to an embodiment is shown. (Reference) Figure 1 The blockchain system 100 may include multiple nodes configured to operate on the blockchain 120, such as nodes 102-110. Nodes 102-110 may form a network 112, such as a peer-to-peer (P2P) network. Each of nodes 102-110 may be a computing device, such as a computer or computer system, configured to store a copy of the blockchain 120, or software, such as a process or application, running on the computing device. Each of nodes 102-110 may have a unique identifier.

[0025] Blockchain 120 can include a progressively increasing list of records in the form of data blocks, for example Figure 1Blocks B1-B5 in the block. Each of blocks B1-B5 may include a timestamp, the cryptographic hash of the previous block, and the data of the current block, which could be transactions such as currency transactions. For example, ... Figure 1 As shown, block B5 may include a timestamp, the cryptographic hash of block B4, and the transaction data of block B5. Furthermore, for example, a hash operation can be performed on the previous block to generate the cryptographic hash of the previous block. Hash operations can convert inputs of various lengths into fixed-length cryptographic outputs using hash algorithms such as SHA-256.

[0026] Nodes 102-110 can be configured to perform operations on blockchain 120. For example, when a node (e.g., node 102) wants to store new data on blockchain 120, it can generate a new block to be added to blockchain 120 and broadcast this new block to other nodes in network 112, such as nodes 104-110. Based on the validity of the new block, such as the validity of its signature and transactions, other nodes can determine to accept the new block, allowing node 102 and other nodes to add the new block to their respective copies of blockchain 120. As this process is repeated, more and more data blocks can be added to blockchain 120.

[0027] Figure 2 The following is illustrated: a node for implementing a blockchain system, such as node 102, according to an embodiment. Figure 1 A schematic diagram of the computing device 200. (See reference) Figure 2 The computing device 200 may include a communication interface 202, a processor 204, and a memory 206.

[0028] Communication interface 202 facilitates communication between computing device 200 and other nodes in the network, such as nodes 104-110. Figure 1 This refers to communication between devices. In some embodiments, the communication interface 202 is configured to support one or more communication standards, such as Internet standards or protocols, Integrated Services Digital Network (ISDN) standards, etc. In some embodiments, the communication interface 202 may include one or more of the following: a local area network (LAN) card, a cable modem, a satellite modem, a data bus, a cable, a wireless communication channel, a radio-based communication channel, a cellular communication channel, an Internet Protocol (IP) based communication device, or other communication devices for wired and / or wireless communication. In some embodiments, the communication interface 202 may be based on public cloud infrastructure, private cloud infrastructure, or a hybrid public / private cloud infrastructure.

[0029] Processor 204 may include one or more dedicated processing units, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or various other types of processors or processing units. Processor 204 is coupled to memory 206 and configured to execute instructions stored in memory 206.

[0030] Memory 206 can store instructions and data that can be executed by a processor, such as blockchain 120. Figure 1 A copy of ), memory 206 may include any type of volatile or non-volatile memory device or a combination thereof, 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 storage, flash memory, or magnetic disk or optical disk. When instructions in memory 206 are executed by processor 204, computing device 200 can perform operations on blockchain 120.

[0031] Refer again Figure 1 In some embodiments, the blockchain system 100 can be implemented to support various types of participants or users, including, for example, banks, financial institutions, credit unions, etc. Parties can utilize the blockchain system 100 to retrieve or record information, including, for example, payment transfer information. Typically, records such as payment transfers stored on the blockchain system 100 are encrypted by the relevant parties.

[0032] In some embodiments, the blockchain system 100 may be implemented to support Real-Time Gross Settlement (RTGS). For example, the blockchain system 100 may implement a strategy that ensures all transfers, once processed, are final and irrevocable. The blockchain system 100 may also implement a strategy that ensures payment transactions submitted to the blockchain system 100 are not affected by waiting periods. The blockchain system 100 may further implement a strategy that ensures payment transactions are settled on a one-to-one basis without being tied to or netted with any other transactions.

[0033] Figure 3 This illustrates an embodiment for detecting in, for example, a blockchain system 100 (… Figure 1 The flowchart illustrates a privacy-preserving deadlock detection method 300 implemented on a blockchain-based RTGS system. This privacy-preserving deadlock detection method 300 can detect deadlocks without any participant disclosing their liquidity and transaction information.

[0034] In step 302, each participant in the RTGS system, e.g., participants A to N, may be instructed to independently calculate their liquidity information. In some embodiments, each party may independently calculate its liquidity information using its local computing resources. In some embodiments, each party i∈{A, B, ..., N} may calculate its current liquidity C. i The amount T to be transferred to this party (accounts receivable) i The amount F transferred (payable) from this party i And liquidity P after the transfer i , where P i =C i +T i -F i .

[0035] In step 304, each party i can be instructed to independently calculate C based on the commitment scheme. i T i F i and P i The commitment value. Each party i can be further instructed to commit the commitment value comm(C). i ), comm(T) i ), comm(F i ) and comm(P i The commitment is submitted to the blockchain system 100 for recording. The commitment scheme may include cryptographic primitives that allow parties to commit to a specific value while hiding that value from other parties. In this way, each party only needs to submit the commitment value comm(C) to the blockchain system 100. i ), comm(T) i ), comm(F i ) and comm(P i The commitments are submitted to blockchain system 100. In step 306, blockchain system 100 can use these commitment values ​​to verify the correctness of each party's calculation of the liquidity information. For example, nodes in blockchain system 100 determine whether any party has changed its liquidity information C during the execution of the privacy-preserving deadlock detection method 300. i T i F i and P i As described in more detail below, if, for example, one party changes its liquidity information C during the execution of the privacy-preserving deadlock detection method 300... i T i F i or P i The blockchain system 100 will be able to detect the change and report the error.

[0036] In some embodiments, the commitment scheme may be a Pedersen commitment scheme, for example, Torben Pryds Pedersen’s “Non-interactive and Information-theoretical Secure Verifiable Secret Sharing”, published in *Advances in Cryptography Research - Proceedings of CRYPTO 91: Lecture Notes on Computer Science* (1991), Vol. 576, pp. 129-140, which is incorporated herein by reference in its entirety. The Pedersen commitment scheme is additively homomorphic, meaning that once party i commits to using C… i Specific values ​​and for T i Specific values ​​(these commitments are the commitment values ​​comm(C) that the i party will commit in step 304) i ) and comm(T i (This is done when the proposal is submitted to the blockchain system at time 100), and the commitment scheme provides... equals comm(C) i +T i ),in This indicates a type that can be used for comm(C) i ) and comm(T i The algebraic operations (e.g., addition or multiplication) performed by the Pedersen commitment. Using the Pedersen commitment as an example, its proprietary feature provides comm(C)... i )+comm(T i ) equals comm(C i +T i ).

[0037] Similarly, once i commits to using F i Specific values ​​and for P i Specific values ​​(these commitments are the commitment values ​​comm(F) that the i party will commit in step 304) i ) and comm(P i (This is done when the proposal is submitted to the blockchain system at time 100), and the commitment scheme provides... equals comm(F) i +P i Using Pedersen commitments as an example, the proprietary property of Pedersen commitments provides comm(F) i )+comm(P i ) equals comm(F i +P i ).

[0038] Furthermore, because P i =C i +T i -F i This means C i +Ti =F i +P i The commitment plan provides It should equal Therefore, when i is instructed to commit the value comm(C) i ), comm(T) i ), comm(F i ) and comm(P i When submitted to blockchain system 100 for recording, blockchain system 100 can determine Is it really equal to If the blockchain system is 100% certain Not equal to Blockchain system 100 can infer that party i has changed C during the execution of privacy-preserving deadlock detection method 300. i T i F i and P i One or more values ​​from [the set]. In some embodiments, when determining [the value]... Not equal to At that time, the blockchain system 100 can report errors.

[0039] It should be understood that the Pedersen commitment described above is merely illustrative and not intended to be limiting. Other commitment schemes can be deduced to replace (or be attached to) the Pedersen commitment. In some embodiments, the chosen commitment scheme may be an additive homomorphism. It should also be understood that the commitment value will be... The computation can vary depending on the commitment scheme used.

[0040] In some embodiments, the blockchain system 100 may implement one or more smart contracts and utilize the smart contracts to determine Is it equal to Smart contracts are computer protocols implemented in the form of computer code, which are incorporated into blockchain 120 (…). Figure 1In a blockchain system 100, the agreed terms can be programmed into a smart contract to facilitate, verify, or enforce the negotiation or execution of a contract. For example, users of the blockchain system 100 can use programming languages ​​such as C++, Java, Solidity, and Python to program agreed terms into a smart contract, which can be automatically executed by the blockchain system 100 when the terms are met, for example, to perform a task. As another example, a smart contract can include multiple subroutines or functions, each of which can be a series of program instructions for performing a specific task. A smart contract can be operational code that executes without any human interaction, either fully or partially. In some embodiments, the blockchain system can implement a smart contract that is programmed to determine, for each party i, i∈{A, B, ..., N}, ... Is it equal to

[0041] In step 308, if the blockchain system 100, for example through a smart contract, determines for each party i, i∈{A, B, ..., N}... equal Then, blockchain system 100 can instruct parties A to N to jointly perform multi-party calculations 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 calculations without disclosing their liquidity information, including their post-transfer liquidity P. i In this way, parties A through N can jointly determine P. min And protect their privacy. In some embodiments, parties A to N may jointly perform a multi-party computation protocol as described in “Secure computation of the median (and other elements specifying the rank)” by Gagan Aggarwal et al., published in the Journal of Cryptography (2010) 23:373–401, which is incorporated herein by reference in its entirety. For example, parties A to N may jointly perform a multi-party computation protocol as defined below:

[0042] 1: Provide each party with initial values ​​α and β set by RTGS, where α is small enough to represent the lowest possible post-transfer liquidity and β is large enough to represent the highest possible post-transfer liquidity.

[0043] 2: Repeat until "Completed":

[0044] 3: Settings

[0045] 4: Indicate each side i∈{A, B, ..., N} for P i Compare with m; if P iStrictly less than m, set l i =1 and g i =0; otherwise, if P i Strictly greater than m, set l i =0 and g i =1.

[0046] 5: Calculate ∑ i∈{A，B，...，N} l i and ∑ i∈{A，B，...，N} g i .

[0047] 6: If ∑ i∈{A，B，...，N} l i ≤0 and ∑ i∈{A，B，...，N} g i ≤N-1, report m as min(P) A P B , ..., P N Then proceed to "Complete".

[0048] 7: If ∑ i∈{A，B，...，N} l i ≥1, set β=m-1 (meaning min(P) A P B , ..., P N () is less than m, so m should be reduced).

[0049] 8: If ∑ i∈{A，B，...，N} g i ≥N, set α=m+1 (meaning min(P) A P B , ..., P N () is greater than m, so m should be increased).

[0050] 9: Completed

[0051] Note that the aforementioned multi-party calculation protocol allows parties A through N to calculate the minimum liquidity amount P. min without revealing P A P B , ..., P N However, it should be understood that the above multi-party computation protocol is provided as an example only and is not intended to be limiting. It is anticipated that parties A through N can implement other types of multi-party computation techniques to perform step 308.

[0052] It can also be conceivable that, in some embodiments, parties A to N can be calculated using multi-party summation processing to calculate ∑. i∈{A，B，...，N} l i and ∑ i∈{A，B，...，N} g i Thus, ∑ can be calculated from A to N. i∈{A，B，...，N} l iand ∑ i∈{A，B，...，N} g i This further protects the privacy of parties A through N without requiring each party to disclose their l and g. For example, in some embodiments, parties A through N may jointly perform the multi-party summation process disclosed in “Confidential Auditing of Distributed Computing Systems” by Yiping Shen et al. in Proceedings of the 24th International Conference on Distributed Computing Systems (2004) 600-607, or the multi-party summation process disclosed in “Providing Auditing While Protecting Privacy” by L. Jean Camp et al. in Information Society, 10(1), pp. 59-72, 1998, both of which are incorporated herein by reference in their entirety.

[0053] In some embodiments, parties A through N can jointly perform multi-party summation by masking their l and g values. For illustrative purposes, assume there are three parties, namely parties A, B, and C, and their l and g values ​​are l, b, and c respectively. A l B , l C and g A g B g C Each side i can be instructed to choose two random integers a and b for the second-order polynomial ax. 2 +bx+c, where the constant c in the polynomial represents the l-value or g-value of the square, depending on which square is instructed to calculate ∑. i∈{A，B，...，N} l i Or ∑ i∈{A，B，...，N} g i Assume that each party is instructed to calculate ∑ i∈{A，B，...，N} l i Player A can choose, for example, a = 25 and b = 83, which means that Player A defines its polynomial as 25x. 2 +83x+l A Player A can mask its l value by using a polynomial to compute the masked value at x=1, x=2, and x=3. Players B and C can choose their random integers a and b to perform a similar operation to mask their own l values.

[0054] It can also be further instructed that each party i retains one of the values ​​of its mask and shares the values ​​of its remaining mask with the other parties to calculate ∑ i∈{A，B，...，N} l i Continuing with the three-party example above, party A can retain the use of polynomial 25x. 2 +83x+l A The mask value calculated at x=1 shares the polynomial 25x with side B. 2 +83x+l A The mask value is calculated at x=2, and the polynomial 25x is shared with C.2 +83x+l A The value of another mask is calculated when x = 3. Parties B and C can perform similar operations on the values ​​of their masks.

[0055] Then, each party i can calculate its position in ∑ based on the value of the mask it reserves for itself and the value of the mask it receives from the other parties. i∈{A，B，...，N} l i The share in the equation. Continuing the three-party example above, Party A can calculate the sum based on the value of its reserved mask (e.g., calculated by Party A using its own polynomial at x=1), the value of the mask received from Party B (e.g., calculated by Party B using its own polynomial at x=1), and the value of the mask received from Party C (e.g., calculated by Party C using its own polynomial at x=1). Party B can calculate the sum based on the value of its reserved mask (e.g., calculated by Party B using its own polynomial at x=2), the value of the mask received from Party A (e.g., calculated by Party A using its own polynomial at x=2), and the value of the mask received from Party C (e.g., calculated by Party C using its own polynomial at x=2). C can calculate the sum based on the value of its reserved mask (e.g., C calculates it using its own polynomial at x=3), the mask value received from A (e.g., A calculates it using A's polynomial at x=3), and the mask value received from B (e.g., B calculates it using B's polynomial at x=3).

[0056] Then, the results from A to N can be combined to calculate ∑. i∈{A，B，...，N} l i and ∑ i∈{A，B，...，N} g i If each party uses constants in a polynomial to represent their l-value, then the sum of the combined values ​​of all constants used in these polynomials will equal ∑ i∈{A，B，...，N} l i Similarly, if each party uses constants in polynomials to represent their g values, the sum of the combined values ​​of all the constants used in these polynomials will equal ∑ i∈{A，B，...，N} g i In this way, ∑ can be calculated from A to N. i∈{A，B，...，N} l i and ∑ i∈{A，B，...，N} g i This further protects the privacy of parties A through N without requiring each party to disclose their l and g values ​​to each other.

[0057] It should be understood that although the examples described above use quadratic polynomials to facilitate the values ​​provided by the three parties involved in the mask, these examples are shown for illustrative purposes only and are not intended to be limiting. It should be understood that additional parties may participate in the multi-party summation process described above. It should also be understood that parties may implement other types of multi-party computation processes to facilitate ∑ i∈{A，B，...，N} l i and ∑ i∈{A，B，...，N} g i The calculation. Optionally, in some embodiments, A to N can be calculated as ∑ i∈{A，B，...，N} l i and ∑ i∈{A，B，...，N} g i This eliminates the need for multi-party computation. It should also be understood that regardless of how parties A through N choose to compute ∑... i∈{A，B，...，N} L i and ∑ i∈{A，B，...，N} g i This calculation is only a sub-step of step 308. As mentioned above, the ultimate goal of step 308 is to facilitate the minimum liquidity amount P. min The calculation, without requiring any party to disclose its post-transfer liquidity information P A P B , ..., P N .

[0058] In step 310, parties A through N can be instructed to submit a minimum liquidity amount P to the blockchain system 100. min For recording purposes. In some embodiments, the blockchain system 100 may utilize a consensus protocol to verify P. min The value. If no consensus is reached, the blockchain system can reject P. min In some embodiments, the blockchain system 100 may utilize other verification technologies to verify the validity of the submitted value. In some embodiments, the blockchain system 100 may accept the submitted value P. min It is then merged into blockchain system 100 without additional verification.

[0059] In step 312, the blockchain system 100 can be based on P min The value of P determines whether a deadlock exists. In some embodiments, if P min If P < 0, blockchain system 100 can determine that a deadlock exists. Blockchain system 100 can notify one or more of parties A to N that additional liquidity is needed to resolve the deadlock. On the other hand, if P min If the value is ≥0, the blockchain system 100 can determine that the RTGS system has no deadlock and report that no additional liquidity is needed. In some embodiments, the blockchain system 100 can implement smart contracts that are programmed to be based on P. min<0 or P min A value greater than or equal to 0 is used to determine whether a deadlock exists.

[0060] In some embodiments, the blockchain system 100 can track the total number of waiting transactions in the RTGS system, and when the total number of waiting transactions reaches a predetermined threshold, invoke a privacy-preserving deadlock detection method 300. Figure 4 A flowchart of method 400 for invoking a privacy-preserving deadlock detection method 300 according to an embodiment is shown. Method 400 can be executed by one or more nodes in a blockchain system that maintains the blockchain, such as nodes 102-110 in blockchain system 100. Figure 1 ) to execute.

[0061] In step 402, node 102 can determine the number of transactions awaiting execution on blockchain system 100. For example, multiple transactions may be included in a new block to be accepted by blockchain system 100. These transactions are still awaiting execution on blockchain system 100. Node 102 can determine the number of such transactions in step 402. In step 404, node 102 can determine whether the number of transactions awaiting execution on blockchain system 100 has exceeded a predetermined threshold. In step 406, in response to determining that the number of transactions awaiting execution on blockchain system 100 has exceeded the predetermined threshold, node 102 can invoke the privacy-preserving deadlock detection method 300. Figure 3 ).

[0062] In step 408, node 102 may instruct, for example, each participant i ∈ {A, B, ..., N}, to independently compute its liquidity information, which includes the current liquidity C. i The amount T to be transferred to party i (accounts receivable) i The amount F to be transferred (paid) from party i i And liquidity P after the transfer i In some embodiments, node 102 may send instructions to the participants via wired or wireless communication channels.

[0063] In step 410, the node can instruct each participant i to independently calculate C based on the commitment scheme. i T i F i and P i The commitment value and the commitment value comm(C) i ), comm(T) i ), comm(F i ) and comm(P i The commitment value is submitted to the blockchain system 100 for recording. In some embodiments, the participants may submit the commitment value to the blockchain system 100 via a wired or wireless communication channel.

[0064] In step 412, node 102 can verify the correctness of the liquidity information of each participant i based on the commitment value submitted by participant i. For example, node 102 can execute a smart contract to determine the liquidity information C. i T i F i and P i Whether a change occurs. In some embodiments, if node 102 is determined... Not equal to Then node 102 can infer that i has changed C. i T i F i and P i One or more values ​​from [the set]. In some embodiments, when determining [the value]... Not equal to At that time, node 102 can report an error.

[0065] In step 414, if node 102 is determined for all sides i∈{A, B, ..., N}... equal Then node 102 can instruct the parties to jointly perform a multi-party calculation as described in step 308 above to determine the minimum liquidity amount P. min =min i∈{A，B，...，N} {P i In step 416, node 102 can instruct the parties to transfer the minimum post-transfer liquidity amount P. min Submitted to blockchain system 100 for recording. In step 418, after receiving the minimum liquidity amount after the transfer, node 102 can base its transaction on P. min <0 or P min A value greater than or equal to 0 is used to determine whether a deadlock exists.

[0066] In some embodiments, each of parties A through N can track the number of pending transactions for that particular party. When the number of pending transactions for a particular party reaches a threshold established by that party, that particular party can indicate its intention to invoke the privacy-preserving deadlock detection method 300. In some embodiments, if parties A through N reach a consensus that the privacy-preserving deadlock detection method 300 should be invoked, then the privacy-preserving deadlock detection method 300 can be invoked. Once a consensus is reached, for example, node 102 can execute steps 408-418 as described above.

[0067] In some embodiments, 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 participants to implement a liquidity-based verification technique. This liquidity-based verification technique may instruct parties to calculate the total liquidity and compare the calculated total liquidity with the total liquidity known to exist in the RTGS system. If the calculated total liquidity is not equal to the total liquidity known to exist in the RTGS system, a node in the blockchain system 100, such as node 102, may determine that an error has occurred and invalidate the computational result of method 300.

[0068] Additionally or alternatively, in some embodiments, node 102 may instruct participants to implement transaction-based verification techniques. Such transaction-based verification techniques may instruct parties to calculate the total amount receivable and payable in the RTGS system. If the total amount receivable does not equal the total amount payable, a node in the blockchain system 100, such as node 102, may determine that an error has occurred and invalidate the calculation result of method 300.

[0069] Figure 5 A block diagram of a deadlock detection apparatus 500 according to an embodiment is shown. Apparatus 500 can be a software-processed implementation and can correspond to method 300. Figure 3 ) and / or method 400 ( Figure 4 See also Figure 5 The device 500 may include a determining module 502, an indicating module 504, a receiving module 506, and a detection module 508.

[0070] The determining module 502 can determine whether to invoke privacy-preserving deadlock detection in the RTGS system. In some embodiments, the determining module 502 can make the decision based on the number of transactions waiting to be executed in the RTGS system. Alternatively or additionally, parties participating in the RTGS system can track the number of locally waiting transactions and determine whether to invoke privacy-preserving deadlock detection in the RTGS system based on whether the parties reach a consensus.

[0071] Instruction module 504 can provide instructions to the parties participating in the RTGS system. For example, instruction module 504 can instruct the participants to independently calculate their liquidity information. In some embodiments, each party i∈{A, B, ..., N} can calculate its current liquidity C. i The amount T to be transferred to this party (accounts receivable) i The amount F to be transferred (paid) from that party i And liquidity P after the transfer i , where P i =C i +Ti -F i .

[0072] Instruction module 504 can further instruct each participant i, i∈{A, B, ..., N}, to independently calculate C based on the commitment scheme. i T i F i and P i The commitment value, and the commitment value comm(C i ), comm(T) i ), comm(F i ) and comm(P i Submit to receiving module 506.

[0073] Instruction module 504 can further instruct participants to perform multi-party calculations to determine the minimum post-transfer liquidity amount P. min =min i∈{A，B，...，N} {P i Instruction module 504 can further instruct participants to transfer the minimum post-transfer liquidity amount P. min Submit to receiving module 506.

[0074] The receiving module 506 can receive information provided by the participants and provide the received information to the detection module 508. The detection module 508 can verify the correctness of the calculation of the participants' liquidity information, i.e., P. min The value, and after the correctness of the calculation is verified, based on P. min Determine if a deadlock condition exists. In some embodiments, the detection module 508 may be integrated with, for example, a blockchain system 100 (…). Figure 1 ) communicates with a blockchain system that utilizes a blockchain system programmed to determine P min A smart contract that verifies the correctness of computation. This smart contract can confirm the correctness of computation for each party i, i∈{A, B, ..., N}. equal To confirm P min The accuracy of the calculation. In some embodiments, the blockchain system may utilize this smart contract or another smart contract based on P. min To determine if a deadlock exists. Smart contracts can be based on P min <0 or P min A value greater than or equal to 0 is used to determine whether a deadlock exists.

[0075] Each of the above modules can be implemented as software or hardware, or a combination of software and hardware. For example, each of the above modules can be implemented using a processor that executes instructions stored in memory. Furthermore, each of the above modules can 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, microcontrollers, microprocessors, or other electronic components to perform the described methods. Further, for example, each of the above modules can be implemented using a computer chip or entity, or by using a product with specific functionality. In one embodiment, device 500 can be a computer, and the computer can be a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email transceiver, game console, tablet computer, wearable device, or any combination of these devices.

[0076] For the implementation process of the function and role of each module in device 500, please refer to the corresponding steps in the above method. For simplicity, details are omitted here.

[0077] In some embodiments, a 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 methods described above.

[0078] Computer-readable storage media can be tangible devices that store instructions for use by an instruction execution device. Such computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), portable optical disc read-only memory (CD-ROM), digital versatile optical disc (DVD), memory sticks, floppy disks, mechanical encoding devices such as punched cards or raised structures with instructions recorded thereon, and any suitable combination thereof.

[0079] The computer-readable program instructions used to perform the above methods can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​and traditional procedural programming languages. The computer-readable program instructions can be executed entirely as a standalone software package on the computing device, or partially on the first computing device and partially on a second computing device located remotely from the first computing device. In the latter case, the second remote computing device can be connected to the first computing device via any type of network, including a local area network (LAN) or a wide area network (WAN).

[0080] 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 are executed via the processor of the computer or other programmable data processing apparatus to create an apparatus for carrying out the methods described above.

[0081] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this document. In this regard, the boxes in the flowcharts or block diagrams may represent segments or portions of software programs or code, which include one or more executable instructions for implementing a particular function. It should also be noted that in some alternative embodiments, the functions mentioned in the boxes may not occur in the order shown in the figures. For example, two boxes shown consecutively may actually be executed substantially simultaneously, or these boxes may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each box in the figures and / or flowcharts, as well as combinations of boxes in the figures and flowcharts, may be implemented by a hardware-based system for a special purpose performing a specified function or action, or by a combination of special-purpose hardware and computer instructions.

[0082] It should be understood that, for clarity, certain features of the specification described in the context of a single embodiment may also be provided in combination in that single embodiment. Conversely, for brevity, various features described herein in the context of a single embodiment may also be provided individually or in any suitable sub-combination, or suitably provided in any other described embodiment herein. Unless otherwise stated, certain features described in the context of various embodiments are not essential features of those embodiments.

[0083] Although this document has been described in conjunction with specific embodiments, many substitutions, modifications, and variations will be apparent to those skilled in the art. Therefore, the following claims encompass all such substitutions, modifications, and variations that fall within the scope of the claims.

Claims

1. A computer-implemented method for detecting deadlock in a real-time full payment system, the method comprising: The system instructs multiple users of the real-time full settlement system to independently calculate their respective liquidity information; wherein, the liquidity information includes post-transfer liquidity; post-transfer liquidity refers to the cash balance after completing accounts receivable and accounts payable transfers; and instructs the multiple users to jointly perform multi-party calculations to determine the minimum post-transfer liquidity, wherein the multi-party calculations are used to jointly determine the minimum post-transfer liquidity without each user disclosing their liquidity information to each other; wherein, the minimum post-transfer liquidity refers to the minimum value among the post-transfer liquidity of the multiple users. The existence of deadlock is determined based on whether the liquidity after the minimum transfer is less than 0.

2. The method of claim 1, wherein instructing the plurality of users to jointly perform multi-party calculations to determine the minimum post-transfer liquidity includes: The system instructs multiple users of the real-time gross settlement system to independently calculate the commitment value for the liquidity information. The commitment value for the liquidity information is received from the plurality of users; The accuracy of the liquidity information of the multiple users is verified based on the commitment value; as well as After the correctness of the liquidity information of the multiple users is verified, the multiple users are instructed to jointly perform multi-party calculations to determine the minimum post-transfer liquidity.

3. The method as described in claim 1, wherein, The indicated multiple users include: Instruct each of the plurality of users i Its liquidity information is calculated independently, including current liquidity. Accounts Receivable Amount Payable and liquidity after the transfer .

4. The method of claim 3, wherein, The instructions for the multiple users also include: Instruct each user i Based on the commitment scheme, an independent calculation is performed for the current liquidity. The amount receivable The amount payable and the liquidity after the transfer The commitment value, to generate the commitment value. , and .

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

6. The method as described in claim 4 or 5, wherein, Receiving the commitment value from the plurality of users includes: From each user i Receive the commitment value , and .

7. The method of claim 6, wherein, Verifying the correctness of the liquidity information of the multiple users includes: Based on the value of the accepted commitment , and To determine whether the liquidity information of any one of the multiple users has changed.

8. The method of claim 7, wherein, Determining whether the liquidity information of any one of the plurality of users has changed includes: For each user i, determine Is it equal to ,in, It is a type of algebraic operation.

9. The method of claim 1, wherein, The real-time full settlement system is implemented using a blockchain system.

10. The method of claim 9, further comprising: Execute a smart contract recorded on the blockchain of the blockchain system to verify the correctness of the liquidity information of the multiple users.

11. The method of claim 1, further comprising: The accuracy of the calculation of the minimum post-transfer liquidity determined jointly is verified based on the total liquidity involved in the real-time full settlement system.

12. The method of claim 1, further comprising: The accuracy of the calculation of the jointly determined minimum post-transfer liquidity is verified based on the total receivables and payables involved in the real-time full settlement system.

13. A device for detecting deadlock in a real-time full payment system, comprising: One or more processors; as well as One or more computer-readable storage devices coupled to the one or more processors and storing instructions thereon that can be executed by the one or more processors to perform the method of any one of claims 1 to 12.

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

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

Images