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

Abstract

This document discloses methods, systems, and apparatus for detecting deadlock in real-time gross settlement systems, including a computer program stored on a computer-readable storage medium. One method includes: instructing multiple users of the real-time gross settlement system to independently calculate their respective liquidity information and perform a joint calculation to determine the total liquidity within the real-time gross settlement system; receiving the calculation results from the multiple users and calculating the total liquidity based on the received calculation results; verifying the correctness of the liquidity information of the multiple users based on the calculated total liquidity; and determining whether deadlock exists in the real-time gross settlement system after the correctness of the liquidity information of the multiple users has been 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 for specific entities that centrally control read and write permissions. Consortium blockchain networks are provided for 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 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 perform a joint calculation to determine the total liquidity within the real-time gross settlement system; receiving the calculation results from the multiple users and calculating the total liquidity based on the received calculation results; verifying the correctness of the liquidity information of the multiple users based on the calculated total liquidity; and determining whether deadlock exists in the real-time gross settlement system after the correctness of the liquidity information of the multiple users has been verified.

[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 perform a joint calculation for determining the total liquidity within the real-time gross settlement system; receive the calculation results of the joint calculation from the multiple users and calculate the total liquidity based on the received calculation results; verify the correctness of the liquidity information of the multiple users based on the calculated total liquidity; 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, when 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 perform a joint calculation to determine the total liquidity within the real-time gross settlement system; receiving the calculation results from the multiple users and calculating the total liquidity based on the received calculation results; verifying the correctness of the liquidity information of the multiple users based on the calculated total liquidity; 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, enabling users of the RTGS system to perform local computations on liquidity information. The methods and apparatus 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 support multi-party computation, where multiple users of the RTGS system can perform joint computations to determine the total liquidity within the RTGS system and provide the computation results to a blockchain system to determine the total liquidity. In this way, the blockchain system can compare the calculated total liquidity with the known total liquidity existing in the RTGS system. The blockchain system can use the comparison results to verify the correctness of users' liquidity information, thereby 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 of the minimum liquidity amount, 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 support multi-party summation, which can be performed to calculate the total liquidity within the RTGS system and provided 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 the calculated total liquidity does not match the total liquidity known to exist in the RTGS system, the methods and apparatus can detect the mismatch and invalidate the determined minimum liquidity amount, 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 may be 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 1 Blocks 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 1A copy of ), memory 206 may include any type of volatile or non-volatile memory device or 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 may 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 can be implemented to support Real-Time Gross Settlement (RTGS). For example, the blockchain system 100 can implement a strategy that ensures all transfers, once processed, are final and irrevocable. The blockchain system 100 can also implement a strategy that ensures payment transactions submitted to the blockchain system 100 are not affected by waiting periods. The blockchain system 100 can 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, such as participants A through 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... Its current liquidity can be calculated. The amount to be transferred to this party (accounts receivable) Amount transferred (payable) from that party and liquidity after the transfer ,in .

[0035] In step 304, the parties, namely parties A through N, may be instructed to perform joint calculations to determine the total liquidity within the RTGS system through, for example, further calculations. The total liquidity to be calculated may include the current total liquidity. and / or total liquidity after transfer .

[0036] In some embodiments, parties A through N may be instructed to use a multi-party summation process to calculate total liquidity. In some embodiments, the multi-party summation process utilized may allow parties to calculate total liquidity without disclosing their liquidity information to each other. 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., Proceedings of the 24th International Conference on Distributed Computing Systems (2004), pp. 600-607, or in “Providing Auditing While Protecting Privacy” by L. Jean Camp et al., Information Society, 10(1), pp. 59-72, 1998, both of which are incorporated herein by reference in their entirety. Parties A through N may also implement other types of multi-party summation processes to perform step 304.

[0037] In some embodiments, parties A to N can operate in conjunction with blockchain system 100 to perform multi-party summation processing. For example, blockchain system 100 can instruct each party... In step 304, a share of the total liquidity is calculated, and in step 306, the result is submitted to the blockchain system 100. The blockchain system 100 can merge the results submitted by all parties to determine the total liquidity in step 308 without receiving actual liquidity information from each party.

[0038] In one embodiment, parties A through N can operate with blockchain system 100 to perform the multi-party summation process, and in step 304, each party can be instructed... Their liquidity information is masked using a polynomial. For illustrative purposes, assume there are three parties, A, B, and C, and their current liquidity values. They are 100, 200, and 300 respectively. Each unit... It may be instructed to select for second-order polynomials. Two random integers and The constants in the polynomial Set to represent the current liquidity value of this party. (or liquidity after the transfer) It depends on whether the parties are instructed to calculate the current total liquidity. Or total liquidity after transfer Assume that all parties are instructed to calculate the current total liquidity. Party A can choose, for example and This means that Party A defines its polynomial as Party A can do so by... , and The current liquidity value is masked by using a polynomial to compute the masked value. Parties B and C can choose their random integers. and Perform similar operations to mask their own liquidity value.

[0039] It is also possible to further instruct each party One party retains one of the values ​​of its mask and shares the remaining values ​​of its mask with the other parties to calculate the total flow. Continuing with the three-party example above, party A can retain the value using a polynomial. exist The calculated mask value is shared with side B using a polynomial. exist The value of the calculated mask is shared with C using a polynomial. exist Calculate the value of another mask. Parties B and C can perform similar operations on the values ​​of their masks.

[0040] Then, each side A party's share of the total liquidity can be calculated based on the value of the mask it reserves for itself and the values ​​of the masks it receives from other parties. Continuing with the three-party example above, party A can calculate its share based on the value of the mask it reserves (e.g., party A using its own polynomial in...). (Calculated), the value of the mask received from Party B (e.g., Party B using Party B's polynomial in...) (Calculated) and the mask value received from C (e.g., C uses C's polynomial). The sum can be calculated using the formula (in the calculation). Party B can calculate the sum based on the value of its reserved mask (e.g., Party B uses its own polynomial in the calculation). (Calculated), the value of the mask received from Party A (e.g., Party A using Party A's polynomial in...) (Calculated) and the mask value received from C (e.g., C uses C's polynomial in) The sum can be calculated using the formula (C). C can be based on the value of its reserved mask (e.g., C uses its own polynomial in C). (Calculated), the value of the mask received from Party A (e.g., Party A using Party A's polynomial in...) (Calculated) and the value of the mask received from Party B (e.g., Party B using Party B's polynomial in) (Calculated) to calculate the sum.

[0041] In step 306, each party, namely parties A through N, may submit its calculation results to the blockchain system 100 for recording. In step 308, the blockchain system 100 may implement one or more smart contracts and use the smart contracts to merge the results submitted by the parties to calculate the total liquidity within the RTGS system.

[0042] Smart contracts are computer protocols implemented in the form of computer code, which are incorporated into Blockchain 120 (Blockchain 120). Figure 1 In a smart contract, the agreed terms are used to facilitate, verify, or enforce the negotiation or execution of a contract. For example, users of a blockchain system 100 can use programming languages ​​such as C++, Java, Solidity, and Python to program agreed terms into a smart contract, and when those terms are met, the blockchain system 100 can automatically execute the smart contract, 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 that perform a specific task. A smart contract can be operational code that executes without any human interaction, either fully or partially.

[0043] In some embodiments, the blockchain system 100 may implement a smart contract programmed to calculate the total liquidity within the RTGS system based on the results submitted by parties A through N. The smart contract may combine the results submitted by parties A through N and solve equations to determine a sum representing the combined value of all constants used in these polynomials. Note that because each party uses constants in its polynomials... Let $\frac{ ... This means that the sum of the combined values ​​of all the constants used in these polynomials equals If each party uses a constant in their polynomial to represent the post-transfer liquidity value. This means that the sum of the combined values ​​of all the constants used in these polynomials equals In this way, in step 308, the blockchain system 100 can determine the current total liquidity based on the results submitted by parties A to N. and / or total liquidity after transfer This does not require either party to disclose their liquidity information.

[0044] It should be understood that although the examples described above use quadratic polynomials to facilitate the masking of values ​​provided by the three parties, 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 computational processes to facilitate the calculation of total liquidity.

[0045] In some embodiments, in step 308, the blockchain system 100 may use the calculated total liquidity to verify the correctness of the liquidity information calculation for each party. For example, the blockchain system 100 may do so on blockchain 120 ( Figure 1 Maintaining overall liquidity The records. The total liquidity of the records. It can reflect the total known liquidity in the RTGS system. Blockchain system 100 can provide the total liquidity when the RTGS system was initially configured on blockchain system 100. The records are kept. For example, blockchain system 100 could be a consortium blockchain system provided for a group of entities, including, for example, banks, financial institutions, credit unions, etc. When entities decide to participate in the RTGS system, they can also decide how much the initial amount of total liquidity in the RTGS system should be. This initial amount can be provided to blockchain system 100 and recorded on blockchain 120 as the recorded total liquidity. Furthermore, the total recorded liquidity can be updated when additional liquidity is added to the RTGS system or excessive liquidity is removed from the RTGS system. Otherwise, record the total liquidity. It can remain unchanged. If the blockchain system 100 determines, for example, the calculated current total liquidity by executing a smart contract... Total liquidity of records Unlike traditional blockchain systems, blockchain system 100 can identify mismatches and report them as errors. Similarly, if blockchain system 100 determines the calculated total liquidity after the transfer... Total liquidity of records Unlike other systems, blockchain systems can identify mismatches and report them as errors.

[0046] If a blockchain system 100 determines, for example, by executing a smart contract... and Blockchain system 100 can then determine that the calculations performed so far are correct. Then, in step 310, blockchain system 100 can instruct parties A to N to jointly perform multi-party calculations to determine the minimum liquidity amount. In some embodiments, parties A to N may jointly perform multi-party calculations without disclosing their liquidity information, including their post-transfer liquidity. In this way, parties A through N can jointly determine... And protect their privacy. In some embodiments, parties A to N may jointly perform a multi-party computation protocol disclosed in “Secure computation of the median (and other elements specifying rank)” by GaganAggarwal 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:

[0047] 1: Provide each party with initial values ​​set by RTGS. and The initial value Small enough to represent the minimum possible liquidity after a transfer and this initial value Large enough to represent the highest possible post-transfer liquidity.

[0048] 2: Repeat until "Completed":

[0049] 3: Settings .

[0050] 4: Instruct each party right and Compare; if Strictly less than ,set up and Otherwise, if Strictly greater than ,set up and .

[0051] 5: Calculation and .

[0052] 6: If and ,Will The report is Then proceed to "Complete".

[0053] 7: If ,set up (meaning) Less than ,so (Should be reduced).

[0054] 8: If ,set up (meaning) Greater than ,so (Should be increased).

[0055] 9: Completed

[0056] Note that the aforementioned multi-party calculation protocol allows parties A to N to calculate the minimum liquidity amount. without revealing 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 310.

[0057] It can also be conceivable that, in some embodiments, parties A to N can be calculated using multi-party summation. and Thus, A through N can be calculated. and without requiring each party to disclose their own and This further protects the privacy of parties A to N. For example, in some embodiments, parties A to N can, for instance, mask their privacy settings. and The values ​​are used to jointly perform a multi-party summation process similar to the one described above. For illustrative purposes, assume there are three parties, namely party A, party B, and party C, and their... and The values ​​are respectively , , and , , It can instruct each party. Choose two random integers and For use in second-order polynomials The constants in the polynomial This indicates that the party's value or the value of the party The value depends on the parties being instructed to calculate. still Assume that each party is instructed to calculate Party A can choose, for example and This means that Party A defines its polynomial as Party A can use in , and The polynomial calculation at the point is masked by the value of the mask. Value. Parties B and C can choose their random integers. and Perform similar operations to mask your own value.

[0058] It is also possible to further instruct each party Retain one of its mask values ​​and share the remaining mask values ​​with other parties to calculate Continuing with the three-party example above, Party A can retain the use of polynomials. exist The calculated mask value is shared with side B using a polynomial. exist The value of the calculated mask is shared with C using a polynomial. exist Calculate the value of another mask. Parties B and C can perform similar operations on the values ​​of their masks.

[0059] Then, each side Its value can be calculated based on the mask value it reserves for itself and the mask value it receives from other parties. The share in. Continuing the three-party example above, Party A can base its share on the value of the mask it retains (e.g., Party A using its own polynomial in...). (Calculated), the value of the mask received from Party B (e.g., Party B using Party B's polynomial in...) (Calculated) and the mask value received from C (e.g., C uses C's polynomial). The sum can be calculated using the formula (in the calculation). Party B can calculate the sum based on the value of its reserved mask (e.g., Party B uses its own polynomial in the calculation). (Calculated), the value of the mask received from Party A (e.g., Party A using Party A's polynomial in...) (Calculated) and the masked value received from C (e.g., C uses C's polynomial in) The sum can be calculated using the formula (C). C can be based on the value of its reserved mask (e.g., C uses its own polynomial in C). (Calculated), the masked value received from Party A (e.g., Party A using Party A's polynomial in (Calculated) and the masked value received from Party B (e.g., Party B using Party B's polynomial in) (Calculated) to calculate the sum.

[0060] Then, the results from A to N can be combined to calculate... and If each party uses constants in a polynomial to represent their... The value represents the sum of the combined values ​​of all the constants used in these polynomials, which equals Similarly, if the parties use constants in a polynomial to represent their... The value represents the sum of the combined values ​​of all the constants used in these polynomials, which equals In this way, parties A through N can be calculated. and without requiring each party to disclose their own and This further protects the privacy of parties A through N.

[0061] 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... and The calculation. Optionally, in some embodiments, parties A to N can be calculated. and This eliminates the need for multi-party computation. It should also be understood that regardless of how parties A through N choose to compute... and This calculation is only a sub-step of step 310. As mentioned above, the ultimate goal of step 310 is to facilitate the minimum liquidity amount. The calculation can be performed without requiring any party to disclose its post-transfer liquidity information. .

[0062] In step 312, parties A through N can be instructed to submit the minimum liquidity amount to the blockchain system 100. For recording purposes. In some embodiments, the blockchain system 100 may utilize a consensus protocol for verification. The value. If no consensus is reached, the blockchain system can reject it. 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. It is then merged into blockchain system 100 without additional verification.

[0063] In step 314, the blockchain system 100 can be based on The value of determines whether a deadlock exists. In some embodiments, if 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 The blockchain system 100 can determine that the RTGS system is not deadlocked 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 still To determine if a deadlock exists.

[0064] 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.

[0065] 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 ).

[0066] In step 408, node 102 may instruct, for example, the participating parties Each participant independently calculates its liquidity information, including current liquidity. Pending transfer to this party (Amount receivable) , to be from that side Amount transferred out (payable) and liquidity after the transfer In some embodiments, node 102 may send instructions to the participants via wired or wireless communication channels.

[0067] In step 410, node 102 can instruct the participants Perform joint calculations to determine (e.g., further calculate) the total liquidity within the RTGS system. The total liquidity to be calculated may include the current total liquidity. and / or total liquidity after transfer Node 102 can instruct participants to submit their computation results to blockchain system 100 for recording. Node 102 can also execute smart contracts to calculate the total liquidity within the RTGS system based on the results submitted by the participants, without receiving actual liquidity information from each participant. In some embodiments, participants can communicate with each other and with blockchain system 100 via wired or wireless communication channels.

[0068] In step 412, node 102 can verify the correctness of the liquidity calculation based on the calculated total liquidity. For example, node 102 can obtain the total liquidity indicating a known existing RTGS system. The record. Node 102 can compare the calculated total liquidity with the recorded total liquidity. The comparison is performed to determine if any mismatch exists. If the calculated total liquidity includes the current total liquidity... And node 102 determines the current total liquidity. and If they are different, then node 102 can and A mismatch between these criteria is identified as an error. Similarly, if the calculated total liquidity includes total liquidity after the transfer... Furthermore, node 102 determines the total liquidity after the transfer. and If they are different, then node 102 can and The mismatch is identified as an error. In some embodiments, node 102 may require the calculated total liquidity to include and Both. In such an embodiment, and All should be related to the total liquidity of the records. If the match is correct, then node 102 verifies that the liquidity calculation is correct.

[0069] After the correctness is verified, in step 414, as described in step 310 above, node 102 can instruct the parties to jointly perform multi-party calculations to determine the minimum liquidity amount. In step 416, node 102 can instruct the parties to transfer the minimum liquidity amount after the transaction. Submitted to blockchain system 100 for recording. After receiving the minimum liquidity amount after the transfer, in step 418, node 102 can base its decision on... still To determine if a deadlock exists.

[0070] 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.

[0071] 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 use a commitment scheme to compute a commitment value of their independently computed liquidity information and submit the commitment value to the blockchain system 100 for recording. Such a commitment scheme may include cryptographic primitives that allow parties to submit a specific value while hiding that value from other parties. In this way, parties may submit only commitment values ​​(relative to their computed liquidity information) to the blockchain system 100, which can use these commitment values ​​to verify the correctness of the liquidity information during the execution of the privacy-preserving deadlock detection method 300. If someone changes their liquidity information during the execution of the privacy-preserving deadlock detection method 300, a node in the blockchain system 100, such as node 102, can detect the change and invalidate the computational result of method 300. In this case, node 102 may invoke method 300 again or report an error.

[0072] 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.

[0073] It should be understood that by performing one or more of these verification steps, blockchain system 100 can ensure that the parties participating in the RTGS system do not misbehave and that deadlocks can be correctly detected. Blockchain system 100 can also ensure that each party... The correct liquidity value will be used. and Used for liquidity calculation. Blockchain system 100 can further ensure that no party can change its liquidity value during deadlock detection processing without being detected by blockchain system 100.

[0074] Figure 5A block diagram of a deadlock detection device 500 according to an embodiment is shown. Device 500 may be a software-processed implementation and may 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.

[0075] 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.

[0076] Instruction module 504 can provide instructions to parties participating in the RTGS system. For example, instruction module 504 can instruct participants to independently calculate their liquidity information. In some embodiments, each party Its current liquidity can be calculated. The amount to be transferred to that party (accounts receivable) The amount to be transferred (paid) from that party and liquidity after the transfer ,in .

[0077] Instruction module 504 can also instruct participating parties. Perform joint calculations to determine the total liquidity within the RTGS system. The total liquidity to be calculated may include the current total liquidity. and / or total liquidity after transfer The instruction module 504 can also instruct the participants to submit the joint calculation results to the receiving module 506.

[0078] Instruction module 504 can further instruct participants to perform multi-party calculations to determine the minimum post-transfer liquidity amount. Instruction module 504 can further instruct participants to transfer the minimum liquidity amount after the transaction. Submit to receiving module 506.

[0079] 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 and value of the participants' liquidity information calculation. And after the correctness of the calculation is verified, based on 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 uses programmed smart contracts to determine The correctness of the calculation. Smart contracts can be based on... and Between and / or and Whether there is a mismatch is used to confirm the correctness of the calculation of the liquidity information of the transaction participants, thereby determining... The accuracy of the calculation. In some embodiments, if and Between and / or and If a mismatch exists, the smart contract can report an error. In some embodiments, the blockchain system can utilize this smart contract or another smart contract, based on... This is to determine if a deadlock exists. Smart contracts can be based on... still Determine if a deadlock exists.

[0080] 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.

[0081] 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.

[0082] 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.

[0083] 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.

[0084] 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).

[0085] 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 a mechanism for carrying out the methods described above.

[0086] 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.

[0087] 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.

Claims

1. A computer-implemented method for detecting deadlocks in a real-time gross settlement system, said real-time gross settlement system being implemented using a blockchain system, the method comprising: The system instructs multiple users of the real-time gross settlement system to independently calculate their respective liquidity information and perform a joint calculation to determine the total liquidity within the real-time gross settlement system. The system receives the calculation results of the joint calculation from the multiple users and calculates the total liquidity based on the received calculation results. The accuracy of the liquidity information of the multiple users is verified based on the calculated total liquidity; as well as After verifying the correctness of the liquidity information of the multiple users, it is determined whether there is a deadlock in the real-time full settlement system; Determining whether a deadlock exists in the real-time full settlement system includes: The system instructs the multiple users to jointly perform multi-party calculations to determine the minimum post-transfer liquidity, wherein the minimum post-transfer liquidity is determined jointly based on the liquidity information of each of the multiple users, without requiring the multiple users to disclose their liquidity information to each other; the liquidity information includes receivables and payables; Receive the jointly determined minimum post-transfer liquidity; and Determine whether a deadlock exists based on the liquidity after the minimum transfer.

2. The method as described in claim 1, wherein, Instructing the multiple users of the real-time gross settlement system to independently calculate their respective liquidity information includes: Instruct each of the plurality of users Its liquidity information is calculated independently, and the liquidity information also includes current liquidity. and liquidity after the transfer .

3. The method as described in claim 2, wherein, Instructing the multiple users to perform a joint calculation to determine the total liquidity within the real-time gross settlement system includes: Instruct the multiple users Execution is used to determine the current total liquidity. The joint calculation, wherein the current total liquidity It is calculated without receiving their respective liquidity information from the multiple users.

4. The method of claim 2, wherein, Instructing the multiple users to perform a joint calculation to determine the total liquidity within the real-time gross settlement system includes: Instruct the multiple users Execution is used to determine total liquidity after the transfer. The joint calculation, wherein the total liquidity after the transfer It is calculated without receiving their respective liquidity information from the multiple users.

5. The method of claim 3, wherein, Verifying the correctness of the liquidity information of the multiple users based on the calculated total liquidity includes: The calculated total liquidity is compared with the recorded total liquidity, which reflects the amount of total liquidity known to exist in the real-time gross settlement system.

6. The method of claim 4, wherein, Verifying the correctness of the liquidity information of the multiple users based on the calculated total liquidity includes: The calculated total liquidity is compared with the recorded total liquidity, which reflects the amount of total liquidity known to exist in the real-time gross settlement system.

7. The method of claim 5, further comprising: An error is reported if the calculated total liquidity does not match the total liquidity recorded.

8. The method of claim 6, further comprising: An error is reported if the calculated total liquidity does not match the total liquidity recorded.

9. The method of claim 1, 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.

10. The method of claim 9, further comprising: The total liquidity is determined by combining the calculation results submitted by the multiple users through the smart contract.

11. A device for detecting deadlock in a real-time full payment system includes: 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 10.

12. 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 10.

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

Images