CN115454658A - 检测实时全额结算系统中死锁的方法、设备、装置和介质 - Google Patents

Abstract

本文公开了用于检测实时全额结算系统中死锁的方法、系统和装置，包括存储在计算机可读存储介质上的计算机程序。方法之一包括：指示所述实时全额结算系统的多个用户独立计算他们各自的流动性信息以及针对所述流动性信息的承诺值；从所述多个用户接收所述承诺值；基于所述承诺值验证所述多个用户的所述流动性信息的正确性；以及在所述多个用户的所述流动性信息的所述正确性被验证之后，确定所述实时全额结算系统中是否存在死锁。

Description

检测实时全额结算系统中死锁的方法、设备、装置和介质

技术领域

本文一般涉及计算机技术，更具体地，涉及用于实时全额结算系统中的死锁检测的方法和设备。

背景技术

实时全额结算(Real-Time Gross Settlement，RTGS)系统是其中资金(例如，金钱或证券)实时并基于总值从一方(例如，银行)转账到另一方(例如，另一家银行)的资金转账系统。当资金转账发生结算时，该转账通常是最终的且不可撤销。例如，当付款交易没有受任何等待期限制时，该结算是实时的。例如，当付款交易基于一对一结算而不与其他交易捆绑或轧差(netting)结算时，该结算以总值为基础。RTGS系统可以由一个国家的中央银行运营。

在一些情况下，参与RTGS系统的一方或多方(例如银行)可能没有足够的流动性来结算其付款交易。例如，假设银行A被设置为从银行B接收$15并将$20转账到银行C，并且进一步假设银行A在进行结算之前具有$0的流动性。在这种情况下，除非银行A获得额外的流动性供应，否则银行A无法结算交易。在这种情况下，银行A被认为在RTGS系统中造成了死锁。

当前，运营RTGS系统的中央银行可以检测到可能的死锁。中央银行可以检测到死锁，因为它有权从参与RTGS系统，例如银行，的各方获得流动性和交易信息。然而，随着去中心化计算成为一种趋势，诸如区块链的技术正变得越来越普遍。基于诸如区块链之类的去中心化计算技术实现的现有RTGS系统缺乏检测死锁的能力。

区块链系统，也称为分布式账本系统(DLS)或共识系统，可以使参与的各方安全且不可篡改地存储数据。在不参考任何特定用例的情况下，区块链系统可以包括任何DLS并且可以用于公有区块链网络、私有区块链网络和联盟区块链网络。公有区块链网络向所有实体开放使用系统，并开放参与共识处理。私有区块链网络为特定实体提供，该特定实体集中控制读写权限。联盟区块链网络针对选择的实体组群提供，该实体组群控制共识处理，并且联盟区块链网络包括访问控制层。

使用点对点(peer-to-peer，P2P)网络实现区块链系统，其中节点例如在不需要固定的中央服务器的情况下与彼此直接通信。P2P网络中的每个节点可以发起与P2P网络中的另一节点的通信。区块链系统维护一个或多个区块链。区块链是用于存储诸如交易的数据的数据结构，其可以防止恶意方篡改和操纵数据。

与参与方愿意或被要求向中央银行公开其流动性和交易信息的中央银行运营的RTGS系统不同，区块链系统中的参与方可能不愿意向区块链系统中的其他参与方公开这样的信息。缺乏公开使得基于例如区块链之类的去中心化计算技术实现的RTGS系统难以检测死锁。因此，需要保护隐私的死锁检测方法，以能够在不要求任何参与方公开其流动性和交易信息的情况下检测死锁。还需要这样的方法来验证其计算正确性。

发明内容

在一方面，一种计算机实现的用于检测实时全额结算系统中死锁的方法包括：指示所述实时全额结算系统的多个用户独立计算他们各自的流动性信息以及针对所述流动性信息的承诺值；从所述多个用户接收所述承诺值；基于所述承诺值验证所述多个用户的所述流动性信息的正确性；以及在所述多个用户的所述流动性信息的所述正确性被验证之后，确定所述实时全额结算系统中是否存在死锁。

在另一方面，一种用于检测实时全额结算系统中死锁的设备包括：一个或多个处理器；以及耦接到所述一个或多个处理器并且其上存储有指令的一个或多个计算机可读存储器，所述指令可由所述一个或多个处理器执行以：指示所述实时全额结算系统的多个用户独立计算他们各自的流动性信息以及针对所述流动性信息的承诺值；从所述多个用户接收所述承诺值；基于所述承诺值验证所述多个用户的所述流动性信息的正确性；以及在所述多个用户的所述流动性信息的所述正确性被验证之后，确定所述实时全额结算系统中是否存在死锁。

在再一方面，一种其中存储有指令的非暂态计算机可读介质，当所述指令时由设备的处理器执行，所述指令促使所述设备执行用于检测实时全额结算系统中死锁的方法。所述方法包括：指示所述实时全额结算系统的多个用户独立计算他们各自的流动性信息以及针对所述流动性信息的承诺值；从所述多个用户接收所述承诺值；基于所述承诺值验证所述多个用户的所述流动性信息的正确性；以及在所述多个用户的所述流动性信息的所述正确性被验证之后，确定所述实时全额结算系统中是否存在死锁。

附图说明

包含在本文中并构成本文一部分的附图示出了实施例。在下列指定附图的说明中，除非另有所示，不同附图中的相同数字表示相同或类似的元素。

图1是根据实施例的区块链系统的示意图。

图2是根据实施例的用于实现区块链系统中节点的计算设备的示意图。

图3是根据实施例的保护隐私的死锁检测方法的流程图。

图4是根据实施例的用于检测实时全额结算死锁的方法的流程图。

图5是根据实施例的用于检测实时全额结算死锁的装置的框图。

具体实施方式

本文的实施例提供了用于在实时全额结算(RTGS)系统中提供保护隐私的死锁检测的方法和设备。所述方法和设备支持RTGS系统的用户对流动性信息进行本地计算。所述方法和设备还支持多方计算，其中RTGS系统的多个用户可以联合确定最低流动性金额，而无需任何用户公开其自身的流动性信息。所述方法和设备还要求用户计算其本地计算的流动性的承诺值，并将该承诺值提供给区块链系统以进行验证。以这种方式，区块链系统可以使用承诺值验证用户计算的流动性信息的正确性，因此验证所确定的最低流动性金额的正确性，并利用所确定的最低流动性金额来检测RTGS系统中的死锁。

本文中公开的实施例具有一个或多个技术效果。在一些实施例中，所述方法和设备支持RTGS系统的用户对流动性信息进行本地计算。这允许每个用户在本地执行计算，而无需公开用户不希望共享的任何隐私信息。在一些实施例中，所述方法和设备还支持多方计算，可以进行该多方计算而无需任何用户向任何其他用户公开其自身的流动性信息。这允许用户在保留其隐私的同时进行联合计算。此外，在一些实施例中，所述方法和设备还要求用户计算其本地计算的流动性的承诺值，并将该承诺值提供给区块链系统以进行验证。这为区块链系统提供了验证计算正确性的能力，而无需知道用户实际的流动性信息。如果用户在计算期间已经改变了其本地计算的流动性信息，所述方法和设备可以监测到所述改变，并使计算结果无效，从而提高了死锁检测的准确性。

区块链是用于存储诸如交易的数据的数据结构，以此方式可以防止恶意方篡改和操纵数据。以这种方式存储的交易可以是不可变的并且随后被验证的。区块链包括一个或多个区块。每个区块通过包括紧邻其之前的前一区块的加密哈希值(cryptographic hash)链接到该前一区块。每个区块还可以包括时间戳、自身的加密哈希值以及一个或多个交易。通常已经由区块链系统的节点验证的交易可以经哈希处理并编码成例如默克尔(Merkle)树的数据结构。在Merkle树中，叶节点处的数据是经哈希处理的，并且在该树的每个分支中的所有哈希值可以在该分支的根处连接。此过程沿着树持续一直到整个树的根，在整个树的根处存储了代表树中所有数据的哈希值。声称是存储在树中的交易的哈希值可以通过确定其是否与树的结构一致而被快速验证。

区块链系统包括管理、更新和维护一个或多个区块链的计算节点的网络。所述网络可以是公有区块链网络、私有区块链网络或联盟区块链网络。例如，许多实体，诸如数百、数千或甚至数百万实体可以在公有区块链网络中操作，并且每个实体操作公有区块链网络中的至少一个节点。因此，公有区块链网络可被认为是关于参与的实体的公有网络。有时，大多数实体(节点)必须对每个区块签名才能使该区块有效并被添加到区块链网络的区块链中。示例性公有区块链网络包括利用被称为区块链的分布式账本的特定点对点(peer-to-peer)支付网络。

通常，公有区块链网络可以支持公开交易。公开交易为公有区块链网络内的所有节点共享，并存储在全局区块链中。全局区块链是跨所有节点复制的区块链，并且所有节点相对于全局区块链处于完全共识状态。为了达成共识(例如，同意向区块链添加区块)，在公有区块链网络中实施共识协议。共识协议的示例包括工作量证明(POW)(例如，在一些加密货币网络中实现)、权益证明(POS)和权威证明(POA)。

通常，可以为特定实体提供私有区块链网络，该特定实体集中控制读写权限。实体控制哪些节点能够参与到区块链网络中。因此，私有区块链网络通常被称为权限网络，其限制允许谁参与网络，以及它们的参与级别(例如，仅在某些交易中)。可以使用各种类型的访问控制机制(例如，现有参与者投票添加新实体，管理机构可以控制准入)。

通常，联盟区块链网络在参与的实体之间是私有的。在联盟区块链网络中，共识处理由一组被授权的节点控制，一个或多个节点由相应实体(例如，金融机构、保险公司)操作。例如，由十(10)个实体(例如，金融机构、保险公司)组成的联盟可以操作联盟区块链网络，每个实体可以操作联盟区块链网络中的至少一个节点。因此，联盟区块链网络可以被认为是与参与实体相关的私有网络。在一些示例中，每个实体(节点)必须对每个区块签名，以使区块有效并被添加到区块链中。在一些示例中，至少实体(节点)的子集(例如，至少7个实体)必须对每个区块签名，以使区块有效并被添加到区块链中。

图1示出了根据实施例的区块链系统100的示意图。参考图1，区块链系统100可以包括被配置为在区块链120上操作的多个节点，例如，节点102-110。节点102-110可以形成网络112，例如点对点(P2P)网络。节点102-110中的每一个可以是被配置为存储区块链120的副本的计算设备，例如计算机或计算机系统，或者可以是在计算设备上运行的软件，诸如进程或应用程序。节点102-110中的每一个可以具有唯一标识符。

区块链120可以包括数据区块形式的记录逐渐增加的列表，例如图1中的区块B1-B5。区块B1-B5中的每一个可以包括时间戳、前一块的加密哈希值，以及当前区块的数据，该数据可以是诸如货币交易的交易。例如，如图1所示，区块B5可以包括时间戳、区块B4的加密哈希值和区块B5的交易数据。此外，例如，可以对前一个区块执行哈希操作以生成前一个区块的加密哈希值。哈希操作可以通过诸如SHA-256的哈希算法将各种长度的输入转换为固定长度的加密输出。

节点102-110可以被配置为对区块链120执行操作。例如，当节点(例如，节点102)想要将新数据存储到区块链120上时，该节点可以生成要被添加到区块链120的新区块，并将该新区块广播到网络112中的例如节点104-110的其他节点。基于新区块的合法性，例如，其签名和交易的有效性，其他节点可以确定接受该新区块，使得节点102和其他节点可以将该新区块添加到它们各自的区块链120的副本中。随着该过程重复，可以将越来越多的数据区块添加到区块链120。

图2示出了根据实施例的用于实现区块链系统中节点，例如节点102(图1)的计算设备200的示意图。参考图2，计算设备200可以包括通信接口202、处理器204和存储器206。

通信接口202可以便于计算设备200与用于实现网络中其他节点，例如，节点104-110(图1)，的设备之间的通信。在一些实施例中，通信接口202被配置为支持一个或多个通信标准，例如互联网标准或协议、综合业务数字网(ISDN)标准，等等。在一些实施例中，通信接口202可以包括以下中的一个或多个：局域网(LAN)卡、电缆调制解调器、卫星调制解调器、数据总线、电缆、无线通信信道、基于无线电的通信信道、蜂窝通信信道、基于互联网协议(IP)的通信设备、或用于有线和/或无线通信的其他通信设备。在一些实施例中，通信接口202可以基于公有云基础设施、私有云基础设施、混合公有/私有云基础设施。

处理器204可以包括一个或多个专用处理单元、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或各种其他类型的处理器或处理单元。处理器204与存储器206耦合，并且被配置为执行存储在存储器206中的指令。

存储器206可以存储可由处理器执行的指令和数据，例如区块链120(图1)的副本。存储器206可以包括任何类型的易失性或非易失性存储器设备或其组合，例如静态随机存取存储器(SRAM)、电可擦除可编程只读存储器(EEPROM)、可擦除可编程只读存储器(EPROM)、可编程只读存储器(PROM)、只读存储器(ROM)、磁存储器、闪存或磁盘或光盘。当存储器206中的指令由处理器204执行时，计算设备200可以对区块链120执行操作。

再次参考图1，在一些实施例中，区块链系统100可以被实现为支持各种类型的参与方或用户，包括例如银行、金融机构、信用合作社等。各方可以利用区块链系统100来检索或记录包括例如支付转账信息的信息。通常，记录在区块链系统100上的诸如支付转账的记录由相关方加密。

在一些实施例中，区块链系统100可以被实现为支持实时全额结算(RTGS)。例如，区块链系统100可以实施一种策略，使得所有转账一旦被处理，都是最终的且不可撤销的。区块链系统100还可以实施一种策略，使得提交给区块链系统100的支付交易均不受等待期的影响。区块链系统100可以进一步实施一种策略，使得支付交易基于一对一结算而不与任何其他交易捆绑或轧差结算。

图3示出根据实施例的用于检测在例如区块链系统100(图1)的区块链系统上实现的RTGS系统中的死锁的保护隐私的死锁检测方法300的流程图。保护隐私的死锁检测方法300可以检测死锁而无需任何参与方公开其流动性和交易信息。

在步骤302，可以指示参与RTGS系统的每个参与方，例如，参与方A至N，独立地计算其流动性信息。在一些实施例中，各方可以使用其本地计算资源独立地计算其流动性信息。在一些实施例中，每一方i∈{A，B，...，N}可以计算其当前流动性C_i、要转入该方(应收)的金额T_i、从该方转出(应付)的金额F_i以及转账后流动性P_i，其中P_i＝C_i+T_i-F_i。

在步骤304，每一方i可以被指示基于承诺方案(commitment scheme)独立地计算C_i、T_i、F_i和P_i的承诺值。每一方i可以被进一步指示将所述承诺值comm(C_i)、comm(T_i)、comm(F_i)和comm(P_i)提交到区块链系统100以进行记录。所述承诺方案可以包括允许各方承诺特定值同时向其他方隐藏所述值的加密原语(cryptographic primitive)。以这种方式，各方仅需要将承诺值comm(C_i)、comm(T_i)、comm(F_i)和comm(P_i)提交到区块链系统100，在步骤306中，区块链系统100可以利用这些承诺值验证每一方i对流动性信息的计算正确性。例如，区块链系统100中的节点确定任何一方在执行保护隐私的死锁检测方法300期间是否已经改变了其流动性信息C_i、T_i、F_i和P_i。如以下更详细描述的，如果例如i方的一方在执行保护隐私的死锁检测方法300期间改变了其流动性信息C_i、T_i、F_i或P_i，区块链系统100将能够检测该改变并报告错误。

在一些实施例中，所述承诺方案可以是佩德森(Pedersen)承诺方案，例如，如公开在《密码学研究进展-CRYPTO 91会议记录：计算机科学讲座笔记》(1991)第576卷：第129-140页中的Torben Pryds Pedersen的“非交互性和信息理论性安全可验证秘密共享”，其通过引用整体并入本文。佩德森承诺方案是加法同态(additively homomorphic)，这意味着一旦i方承诺使用针对C_i的特定值以及针对T_i的特定值(这些承诺是i方在步骤304将承诺值comm(C_i)和comm(T_i)提交到区块链系统100时进行的)，承诺方案提供

等于comm(C_i+T_i)，其中

表示一种可以对comm(C_i)和comm(T_i)执行的代数运算(例如，加法或乘法)。使用佩德森承诺作为示例，佩德森承诺的专有特性提供了comm(C_i)+comm(T_i)等于comm(C_i+T_i)。

类似地，一旦i方承诺使用针对F_i的特定值和针对P_i的特定值(这些承诺是i方在步骤304将承诺值comm(F_i)和comm(P_i)提交到区块链系统100时进行的)，承诺方案提供

等于comm(F_i+P_i)。使用佩德森承诺作为示例，佩德森承诺的专有特性提供了comm(F_i)+comm(P_i)等于comm(F_i+P_i)。

此外，因为P_i＝C_i+T_i-F_i，这意味着C_i+T_i＝F_i+P_i。承诺方案提供了

应该等于

因此，当i方被指示将承诺值comm(C_i)、comm(T_i)、comm(F_i)和comm(P_i)提交到区块链系统100以进行记录时，区块链系统100可以确定

是否确实等于

如果区块链系统100确定

不等于

区块链系统100可以推断i方在执行保护隐私的死锁检测方法300期间已经改变了C_i、T_i、F_i和P_i中的一个或多个值。在一些实施例中，当确定

不等于

时，区块链系统100可以报告错误。

应当理解，上述的佩德森承诺仅作为示例并且不旨在作为限制。可以推测出其他可以利用其他承诺方案以代替(或附加到)佩德森承诺。在一些实施例中，所选择的承诺方案可以是加法同态。还应理解要对承诺值进行的

运算可以根据所利用的承诺方案而变化。

在一些实施例中，区块链系统100可以实施一个或多个智能合约，并利用智能合约确定

是否等于

智能合约是以计算机代码形式实施的计算机协议，其被纳入到区块链120(图1)中，以促进、验证或施行合约的协商或执行。例如，区块链系统100的用户可以使用诸如C++、Java、Solidity、Python等编程语言将商定的条款编程为智能合约，并且当满足该条款时，可以由区块链系统100自动执行该智能合约，例如执行任务。又例如，智能合约可以包括多个子例程或函数，每个子例程或函数可以是执行专用任务的一系列程序指令。智能合约可以是在完全或部分没有人工交互的情况下执行的操作代码。在一些实施例中，区块链系统可以实施智能合约，该智能合约被编程为针对每一方i，i∈{A，B，...，N}，确定

是否等于

在步骤308，如果区块链系统100，例如通过智能合约，针对每一方i，i∈{A，B，...，N}，确定了

等于

则区块链系统100可以指示A方至N方的各方联合进行多方计算以确定最低流动性金额P_min＝min_{i∈{A，B，...，N}}{P_i}。在一些实施例中，A方至N方可以联合进行多方计算而无需公开其流动性信息，包括其转账后流动性P_i。以这样的方式，A方至N方可以联合确定P_min并保护他们的隐私。在一些实施例中，A方至N方可以联合执行公开在《密码学杂志》(2010)23:373–401中的GaganAggarwal等人的“中位数(以及指定排名的其他元素)的安全计算”中的多方计算协议，其通过引用整体并入本文。例如，A方至N方可以联合执行如下定义的多方计算协议：

1：为每一方提供由RTGS设置的初始值α和β，该初始值α足够小以表示可能的最低转账后流动性并且该初始值β足够大以表示可能的最高转账后流动性。

2：重复直到“完成”：

3：设置

4：指示每一方i∈{A，B，...，N}对P_i与m进行比较；如果P_i严格小于m，设置l_i＝1和g_i＝0；否则，如果P_i严格大于m，设置l_i＝0和g_i＝1。

5：计算∑_{i∈{A，B，...，N}}l_i和∑_{i∈{A，B，...，N}}g_i。

6：如果∑_{i∈{A，B，...，N}}l_i≤0和∑_{i∈{A，B，...，N}}g_i≤N-1，将m报告为min(P_A，P_B，...，P_N)，然后进行“完成”。

7：如果∑_{i∈{A，B，...，N}}l_i≥1，设置β＝m-1(意思是min(P_A，P_B，...，P_N)小于m，所以m应该减少)。

8：如果∑_{i∈{A，B，...，N}}g_i≥N，设置α＝m+1(意思是min(P_A，P_B，...，P_N)大于m，所以m应该增加)。

9：完成

注意到上述多方计算协议可以允许A方至N方计算最低流动性金额P_min，而不透露P_A，P_B，...，P_N。然而，应理解，上述多方计算协议仅作为示例提供，并不意味着限制。可以预期，A方至N方可以实施其他类型的多方计算技术来进行步骤308。

还可以想到，在一些实施例中，A方至N方可以利用多方求和处理来计算∑_{i∈{A，B，...，N}}l_i和∑_{i∈{A，B，...，N}}g_i。这样，A方至N方可以计算∑_{i∈{A，B，...，N}}l_i和∑_{i∈{A，B，...，N}}g_i，而无需各方彼此公开自己的l和g，从而进一步保护了A方至N方的隐私。例如，在一些实施例中，A方至N方可以联合执行在《第24届分布式计算系统国际会议论文集》(2004)600-607中的Yiping Shen等人的“关于分布式计算系统的机密审核”中公开的多方求和处理，或在“《信息社会》，10(1)，第59-72页，1998年”中L.Jean Camp等人的“在保护隐私的同时提供审核”中公开的多方求和处理，两者均通过引用整体并入本文。

在一些实施例中，A方至N方可以通过掩码其l和g值来联合执行多方求和处理。出于说明目的，假设有三方，即A方、B方和C方，并且他们的l和g值分别是l_A、l_B，、l_C和g_A、g_B、g_C。可以指示每一方i选择两个随机整数a和b，以用于二阶多项式ax²+bx+c，其中多项式中的常数c表示该方的l值或该方的g值，这取决于各方被指示计算∑_{i∈{A，B，...，N}}l_i还是∑_{i∈{A，B，...，N}}g_i。假设各方被指示计算∑_{i∈{A，B，...，N}}l_i，A方可以选择例如a＝25和b＝83，这意味着A方将其多项式定义为25x²+83x+l_A。A方可以通过使用在x＝1、x＝2和x＝3处的多项式计算被掩码的值来掩码其l值。B方和C方可以选择他们的随机整数a和b进行类似的操作，以掩码自己的l值。

还可以进一步指示每一方i保留其掩码的值之一，并与其他方共享他的其余掩码的值，以计算∑_{i∈{A，B，...，N}}l_i。继续上面的三方示例，A方可以保留使用多项式25x²+83x+l_A在x＝1计算的掩码的值，与B方共享使用多项式25x²+83x+l_A在x＝2计算的掩码的值，并与C方共享使用多项式25x²+83x+l_A在x＝3计算的另一个掩码的值。B方和C方可对他们掩码的值进行类似的操作。

然后，每一方i可以基于其保留给自己的掩码的值和从其他方接收到的掩码的值来计算其在∑_{i∈{A，B，...，N}}l_i中的份额。继续上面的三方示例，A方可以基于其保留的掩码的值(例如A方使用A方自身的多项式在x＝计算的)、从B方接收到的掩码的值(例如，B方使用B方的多项式在x＝1计算的)以及从C方接收到的掩码的值(例如，C方使用C方的多项式x＝1在计算的)来计算总和。B方可以基于其保留的掩码的值(例如B方使用B方自身的多项式在x＝2计算的)、从A方接收到的掩码的值(例如，A方使用A方的多项式在x＝2计算的)以及从C方接收到的掩盖的值(例如，C方使用C方的多项式在x＝2计算的)来计算总和。C方可以基于其保留的掩码的值(例如C方使用C方自身的多项式在x＝3计算的)、从A方接收到的掩盖的值(例如，A方使用A方的多项式在x＝3计算的)以及从B方接收到的掩盖的值(例如，B方使用B方的多项式在x＝3计算的)来计算总和。

然后，A方至N方可以合并所述结果,以计算∑_{i∈{A，B，...，N}}l_i和∑_{i∈{A，B，...，N}}g_i。如果各方使用多项式中的常数表示他们的l值，表示这些多项式中使用的所有常数的组合值的总和将等于∑_{i∈{A，B，...，N}}l_i。同样地，如果各方使用多项式中的常数表示他们的g值，表示这些多项式中使用的所有常数的组合值的总和将等于∑_{i∈{A，B，...，N}}g_i。以这种方式，A方至N方可以计算∑_{i∈{A，B，...，N}}l_i和∑_{i∈{A，B，...，N}}g_i，而无需各方彼此公开自己的l和g，从而进一步保护了A方至N方的隐私。

应当理解，尽管上面描述的示例使用二次多项式来讨论以促进掩码三个参与方提供的值，但是这些示例仅出于说明性目的而示出，并不意味着限制。应当理解，额外的参与方可以参与上述的多方求和处理。还应理解，各方可以实施其他类型的多方计算处理以促进∑_{i∈{A，B，...，N}}l_i和∑_{i∈{A，B，...，N}}g_i的计算。可选地，在一些实施例中，A方至N方可以计算∑_{i∈{A，B，...，N}}l_i和∑_{i∈{A，B，...，N}}g_i而无需使用多方计算。还应理解，无论A方至N方选择如何计算∑_{i∈{A，B，...，N}}L_i和∑_{i∈{A，B，...，N}}g_i，该计算只是步骤308的一个子步骤。如上所述，步骤308的最终目标是促进最低流动性金额P_min的计算，而无需各方透露其转账后流动性信息P_A，P_B，...，P_N。

在步骤310，可以指示A方至N方向区块链系统100提交最低流动性金额P_min以用于记录。在一些实施例中，区块链系统100可以利用共识协议来验证P_min的值。如果没有达成共识，区块链系统100可以拒绝P_min。在一些实施例中，区块链系统100可以利用其他验证技术来验证所提交的值的有效性。在一些实施例中，区块链系统100可以接受所提交的值P_min并将其合并进入区块链系统100，而无需额外验证。

在步骤312，区块链系统100可以基于P_min的值确定是否存在死锁情况。在一些实施例中，如果P_min＜0，区块链系统100可以确定存在死锁情况。区块链系统100可以通知A方至方N中的一个或多个需要额外的流动性供应以解决死锁情况。另一方面，如果P_min≥0，区块链系统100可以确定RTGS系统没有死锁，并报告不需要额外的流动性。在一些实施例中，区块链系统100可以实施智能合约，该智能合约被编程为基于P_min＜0还是P_min≥0来确定是否存在死锁情况。

在一些实施例中，区块链系统100可以追踪RTGS系统中的等待交易的总数，并且当等待交易的总数达到预定阈值时，调用保护隐私的死锁检测方法300。图4示出了根据实施例的用于调用保护隐私的死锁检测方法300的方法400的流程图。方法400可以由维护区块链的区块链系统中的一个或多个节点执行，例如由区块链系统100中的节点102-110(图1)来执行。

在步骤402，如节点102的节点可以确定区块链系统100上的等待执行的交易的数量。例如，多个交易可以被包括在区块链系统100要接受的新区块中。这些交易仍在区块链系统100上等待执行。节点102可以在步骤402中确定这种交易的数量。在步骤404，节点102可以确定区块链系统100上等待执行的交易的数量是否已经超过预定阈值。在步骤406，响应于确定区块链系统100上等待执行的交易的数量已经超过预定阈值，节点102可以调用保护隐私的死锁检测方法300(图3)。

在步骤408，节点102可以指示例如i方的每个参与方，i∈{A，B，...，N}，独立计算其流动性信息，该流动性信息包括当前流动性C_i、待转入i方(应收)的金额T_i、待从i方转出(应付)的金额F_i、以及转账后流动性P_i。在一些实施例中，节点102可以经由有线或无线通信信道向参与方发送指令。

在步骤410，节点可以指示每个参与方i基于承诺方案独立计算C_i、T_i、F_i和P_i的承诺值并将承诺值comm(C_i)、comm(T_i)、comm(F_i)和comm(P_i)提交到区块链系统100以进行记录。在一些实施例中，参与方可以经由有线或无线通信信道将承诺值提交到区块链系统100。

在步骤412，节点102可以基于参与方i提交的承诺值验证每个参与方i的流动性信息的正确性。例如，节点102可以执行智能合约以确定流动性信息C_i、T_i、F_i和P_i是否发生改变。在一些实施例中，如果节点102确定

不等于

则节点102可以推断i方已经改变了C_i、T_i、F_i和P_i中的一个或多个值。在一些实施例中，当确定

不等于

时，节点102可以报告错误。

在步骤414，如果节点102针对所有方i∈{A，B，...，N}，都确定了

等于

则节点102可以指示各方联合进行如以上步骤308所描述的多方计算以确定最低流动性金额P_min＝min_{i∈{A，B，...，N}}{P_i}。在步骤416，节点102可以指示各方将最低转账后流动性金额P_min提交到区块链系统100以进行记录。在步骤418，在接收到最低转账后流动性金额后，节点102可以基于P_min＜0还是P_min≥0来确定是否存在死锁情况。

在一些实施例中，例如A方至N方的每一方可以追踪该特定方的等待处理的交易的数量。当一特定方的等待处理的交易的数量达到该方建立的阈值时，该特定方可以指示其意图以调用保护隐私的死锁检测方法300。在一些实施例中，如果A方至N方达成应调用保护隐私的死锁检测方法300的共识，则可以调用保护隐私的死锁检测方法300。一旦达成共识，例如节点102的节点，可以执行如上所述的步骤408-418。

在一些实施例中，节点102可以执行附加的验证步骤以验证保护隐私的死锁检测方法300的计算正确性。例如，在一些实施例中，节点102可以指示参与方实施基于流动性的验证技术。这种基于流动性的验证技术可以指示各方计算总流动性，并将计算出的总流动性与已知存在于RTGS系统中的总流动性进行比较。如果计算出的总流动性不等于已知存在于RTGS系统中的总流动性，区块链系统100中的例如节点102的节点可以确定已经发生错误并使方法300的计算结果无效。

附加地或替代地，在一些实施例中，节点102可以指示参与方实施基于交易的验证技术。这种基于交易的验证技术可以指示各方计算RTGS系统中的应收总额和应付总额。如果应收总额不等于应付总额，则区块链系统100中的例如节点102的节点可以确定已经发生错误并使方法300的计算结果无效。

图5示出了根据实施例的死锁检测装置500的框图。装置500可以是软件处理的实施方式，并且可以对应于方法300(图3)和/或方法400(图4)。参见图5，装置500可以包括确定模块502、指示模块504、接收模块506和检测模块508。

确定模块502可以确定是否在RTGS系统中调用保护隐私的死锁检测。在一些实施例中，确定模块502可以基于RTGS系统中的等待执行的交易的数量做出决定。替代地或附加地，参与RTGS系统的各方可以追踪本地等待交易的数量，并基于各方是否达成共识来调用保护隐私的死锁检测，从而确定是否在RTGS系统中调用保护隐私的死锁检测。

指示模块504可以向参与RTGS系统的各方提供指示。例如，指示模块504可以指示参与方独立计算其流动性信息。在一些实施例中，每一方i∈{A，B，...，N}可以计算其当前流动性C_i、待转入该方(应收)的金额T_i、待从该方转出(应付)的金额F_i、以及转账后流动性P_i，其中P_i＝C_i+T_i-F_i。

指示模块504可以进一步指示每个参与方i，i∈{A，B，...，N}，基于承诺方案独立计算C_i、T_i、F_i和P_i的承诺值，并将承诺值comm(C_i)、comm(T_i)、comm(F_i)和comm(P_i)提交到接收模块506。

指示模块504可以进一步指示参与方进行多方计算以确定最低转账后流动性金额P_min＝min_{i∈{A，B，...，N}}{P_i}。指示模块504可以进一步指示参与方将最低转账后流动性金额P_min提交到接收模块506。

接收模块506可以接收由参与方提供的信息并将接收到的信息提供给检测模块508。检测模块508可以验证参与方的流动性信息的计算正确性，即P_min的值，并在计算正确性被验证之后基于P_min确定是否存在死锁情况。在一些实施例中，检测模块508可以与例如区块链系统100(图1)的区块链系统通信，该区块链系统利用被编程为确定P_min的计算正确性的智能合约。该智能合约可以通过针对每一方i，i∈{A，B，...，N}，确认

等于

来确认P_min的计算正确性。在一些实施例中，区块链系统可以利用该智能合约或另一智能合约基于P_min来确定是否存在死锁情况。智能合约可以基于P_min＜0还是P_min≥0来确定是否存在死锁情况。

上述模块中的每一个可以实现为软件或硬件，或软件和硬件的组合。例如，可以使用执行存储在存储器中的指令的处理器来实施上述模块中的每一个。而且，例如，每个上述模块可以使用一个或多个专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子组件来实施以执行所描述的方法。进一步地，例如，上述模块中的每一个可以通过使用计算机芯片或实体来实施，或者通过使用具有特定功能的产品来实施。在一个实施例中，装置500可以是计算机，并且计算机可以是个人计算机、膝上型计算机、蜂窝电话、照相手机、智能手机、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板电脑、可穿戴设备或这些设备的任何组合。

对于装置500中每个模块的功能和角色的实施过程，可以参考上述方法中的相应步骤。为简单起见，这里省略了细节。

在一些实施例中，计算机程序产品可以包括非暂态计算机可读存储介质，其上存储有用于促使处理器执行上述方法的计算机可读程序指令。

计算机可读存储介质可以是有形设备，其可以存储供指令执行设备使用的指令。所述计算机可读存储介质可以是，例如，但不限于电子存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或前述的任何合适组合。计算机可读存储介质的更具体示例的非详尽列表包括以下内容：便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM)、静态随机存取存储器(SRAM)、便携式光盘只读存储器(CD-ROM)、数字通用光盘(DVD)、记忆棒、软盘、例如在其上记录有指令的凹槽中的穿孔卡或凸起结构的机械编码设备，以及前述的任何合适的组合。

用于执行上述方法的计算机可读程序指令可以是汇编指令、指令集架构(ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据或者以一种或多种编程语言的任意组合编写的源代码或目标代码，该编程语言包括面向对象的编程语言和传统的过程编程语言。计算机可读程序指令可以完全在计算设备上作为独立软件包执行，或者部分在第一计算设备上执行、部分在远离第一计算设备的第二计算设备上执行。在后一种情况下，第二远程计算设备可以通过包括局域网(LAN)或广域网(WAN)的任何类型的网络连接到第一计算设备。

计算机可读程序指令可以被提供给通用或专用计算机的处理器或其他可编程数据处理装置以产生机器，使得指令经由计算机的处理器或其他可编程数据处理装置执行，创建用于实施上述方法的机构。

附图中的流程图和框图示出了根据本文的各种实施例的设备、方法和计算机程序产品的可能实现的架构、功能和操作。在这方面，流程图或框图中的框可以表示软件程序、代码的段或部分，其包括用于实现特定功能的一个或多个可执行指令。还应注意，在一些可选实施例中，框中提到的功能可以不按图中所示的顺序发生。例如，连续示出的两个框实际上可以基本上同时执行，或者这些框有时可以以相反的顺序执行，这取决于所涉及的功能。还应注意，图和/或流程图的每个框以及图和流程图中的框的组合可以由执行指定功能或动作的专用目的的基于硬件的系统来实施，或由专用目的的硬件和计算机指令的组合来实施。

应当理解，为了清楚起见，在单个实施例的上下文中描述的说明书的某些特征也可以在单个实施例中组合提供。相反，为了简洁起见，在单个实施例的上下文中描述的本文的各种特征也可以单独提供或者以任何合适的子组合提供，或者在本文的任何其他描述的实施例中合适地提供。除非另有说明，否则在各种实施例的上下文中描述的某些特征不是那些实施例的必要特征。

尽管已经结合具体实施例描述了本文，但是许多替换、修改和变体对于本领域技术人员而言将是显而易见的。因此，以下权利要求包含落入权利要求的范围内的所有这些替代、修改和变体。

Claims (15)

1.一种计算机实现的用于检测实时全额结算系统中死锁的方法，所述方法包括：

指示所述实时全额结算系统的多个用户独立计算各自的流动性信息；

指示所述多个用户联合进行多方计算确定最低转账后流动性，其中，所述多方计算用于在所述多个用户中的每个用户不向彼此公开其流动性信息的情况下，联合确定所述最低转账后流动性；

基于所述最低转账后流动性确定是否存在死锁。

2.如权利要求1所述的方法，所述指示所述多个用户联合进行多方计算确定最低转账后流动性，包括：

指示所述实时全额结算系统的多个用户独立计算针对所述流动性信息的承诺值；

针对所述流动性信息的承诺值，从所述多个用户接收所述承诺值；

基于所述承诺值验证所述多个用户的所述流动性信息的正确性；以及

在所述多个用户的所述流动性信息的所述正确性被验证之后，指示所述多个用户联合进行多方计算确定最低转账后流动性。

3.如权利要求1所述的方法，其中，指示所述多个用户包括：

指示所述多个用户中的每个用户i独立计算其流动性信息，所述流动性信息包括当前流动性C_i、应收金额T_i、应付金额F_i以及转账后流动性P_i。

4.如权利要求3所述的方法，其中，指示所述多个用户还包括：

指示每个用户i基于承诺方案独立计算针对所述当前流动性C_i、所述应收金额T_i、所述应付金额F_i以及所述转账后流动性P_i的承诺值，以生成承诺值comm(C_i)、comm(T_i)、comm(F_i)和comm(P_i)。

5.如权利要求4所述的方法，其中，所述承诺方案是加法同态承诺方案。

6.如权利要求4或5所述的方法，其中，从所述多个用户接收所述承诺值包括：

从每个用户i接收所述承诺值comm(C_i)、comm(T_i)、comm(F_i)和comm(P_i)。

7.如权利要求6所述的方法，其中，验证所述多个用户的所述流动性信息的正确性包括：

基于所接受到的承诺值comm(C_i)、comm(T_i)、comm(F_i)和comm(P_i)，确定所述多个用户中的任意一个用户的所述流动性信息是否发生改变。

8.如权利要求7所述的方法，其中，确定所述多个用户中的任意一个用户的所述流动性信息是否发生改变包括：

针对每个用户i，确定

是否等于

其中，

是一种代数运算。

9.如权利要求1所述的方法，其中，所述实时全额结算系统是利用区块链系统实现的。

10.如权利要求9所述的方法，还包括：

执行记录在所述区块链系统的区块链上的智能合约来验证所述多个用户的所述流动性信息的正确性。

11.如权利要求1所述的方法，还包括：

基于所述实时全额结算系统中涉及的流动性总额来验证联合确定的最低转账后流动性的计算正确性。

12.如权利要求1所述的方法，还包括：

基于所述实时全额结算系统中涉及的应收总额和应付总额来验证联合确定的最低转账后流动性的计算正确性。

13.一种用于检测实时全额结算系统中死锁的设备，包括：

一个或多个处理器；以及

一个或多个计算机可读存储器，所述计算机可读存储器耦接到所述一个或多个处理器并且其上存储有指令，所述指令能够由所述一个或多个处理器执行以执行权利要求1至11中任一项所述的方法。

14.一种用于检测实时全额结算系统中死锁的装置，所述装置包括用于执行权利要求1至12中任一项所述的方法的多个模块。

15.一种存储有指令的非暂态计算机可读介质，当所述指令由设备的处理器执行时，所述指令促使所述设备执行权利要求1至12中任一项所述的方法。

Images