支付系统：分布式账本环境中的流动性节约机制

　　本文专注于分布式账本技术及Stella项目的运行效果。分布式账本技术（DLT）是一套记录数据的工具，如资产持有量或金融交易，允许计算机网络在没有单一中央管理系统的情况下进行验证和存储更新。在2016年12月，日本银行（BOJ）和欧洲中央银行（ECB）宣布启动了一个名为 “Stella ”的联合研究项目用以评估DLT的适用性及解决方案在金融市场基础设施领域的适用性。本报告是双方合作的第一个成果，Stella项目对正在进行的关于DLT在金融市场基础设施中的可用性的广泛讨论做出了贡献，这项联合研究旨在促进更安全、更快速和更经济的金融交易。该项目在所述的有限范围内具有探索性质，目前只注重于实际测试，而成本效率、市场整合和监督等领域留待未来研究。

　　联合分析的主要结果

　　本报告详细介绍了联合分析的主要结果，归纳如下：

　　1. 基于DLT的解决方案可以满足实时全额支付系统（RTGS）的性能需求：

　　分析发现，在欧元区和日本地区，DLT应用可与流向RTGS系统的请求量相媲美。考虑到这两个集中式支付系统的平均流量（每秒约10至70吞吐量（RPS））以及交易的处理时间平均不到一秒。然而当RPS增加到250时，分析证实了流量和性能之间的权衡是不可忽视的。更广泛地说，测试证明了在DLT环境中实施标准LSM的处理逻辑（排队和双边冲销）和在DLT环境中的可行性。

　　2. DLT的性能受到网络规模和节点之间距离的影响：

　　该分析证实了众所周知的网络规模和性能之间的权衡。增加节点的数量导致了支付执行时间的增加。此外，节点之间的距离对性能的影响取决于网络配置：只要达到共识所需的最小节点数（法定人数）足够接近，那么在网络的其他部分的分散对延迟的影响是有限的。尽管如此，网络外围的节点仍可能会产生与法定人数不一致的情况。如果法定人数足够分散，对延迟的影响就会更大。

　　3. DLT解决方案有可能加强复原力和可靠性:

　　该分析虽然并不详尽，但表明DLT网络有经受住问题考验的能力，如验证节点故障及不正确的数据格式。关于节点故障，据观察，只要共识算法所需的节点数量是可操作的，系统的可用性就不会受到影响。测试还证实，无论停机时间长短，验证节点都能恢复。

　　然而，也应该考虑到所选择的DLT设置包括一个单一认证机构。这是一个单点故障可能会破坏分布式验证的优势。此外，使用不正确的数据格式的测试表明，该系统能够检测到不正确的数据格式而不影响整体性能。

　　有关效率的研究结果

　　1. 网络规模对效率的影响：

　　我们进行了测试以验证增长的验证节点对性能的影响，并分别在简单智能合约（即在没有LSM的情况下进行支付转移）和LSM智能合约（即在有LSM的情况下进行支付转移）的情况下，进行了测试。

　　基于简单智能合约的结果如下：

　　图1

　　基于LSM智能合约的结果如下：

　　图2

　　2. 节点之间的距离对效率的影响：

　　我们进行了测试，以评估验证节点在以下情况下的性能（即导致它们之间的通信需要更长的时间），并探讨了两种情况，每种情况都基于四个节点。

　　图3

　　图4

　　在集中的情况下得到的结果（见图3与图4）表明由于节点之间的距离越近，性能受到的影响较小；在各节点间测得的延迟与没有延迟的基线方案相当。然而，在这种情况下，与其他节点分开的节点则显示出大的延迟（比基线方案高112%）或者在没有参与的情况下出现赶不上其他节点的迹象，分散的情况下显示出了更高的延迟。这是由于各组节点之间的距离较长，与基线方案相比延迟增加了67%。而从这两个场景中得出的结果表明，平均而言，当需要进行交互的结点时共识的形成会更快当节点分开，需要远处的节点参与以达成共识则需要更多的时间。

　　对安全问题的潜在影响

　　1. 验证节点失败：

　　由于内部故障或网络断开，一个或多个验证节点无法参与共识的形成，因此需要制定程序让重新连接的节点能够赶上其他验证节点的状态。

　　我们进行了测试以评估假设一个验证节点失败的后果。具体来说，总共四个节点中的一个被关闭了一定的时间 ，然后重新启动并测量该节点赶上其他节点所需的时间与其他节点的时间。

　　2. 证书授权失败：

　　对参与者和交易进行注册和认证是确保系统安全的关键。系统的安全。Fabric通过一个证书授权机构（CA）来确保这一点。尽管交易验证在设计上是分布式的，但Fabric会给系统引入了一个单点故障。为了确定Fabric如何处理CA不可用的情况，我们停止了CA 然后再重新启动，同时验证节点继续发送和处理交易的能力。

　　测试结果显示，只要CA不可用，交易就会被拒绝，提醒发送方注意Fabric的不可用的情况。一旦CA再次可用，交易处理就开始启动，没有任何其他系统干预的预警发出。

　　3. 对不正确格式的请求的复原力：

　　确保DLT系统弹性的挑战之一是确保在提交大量格式不正确的交易请求时，它能够继续运作。例如，存在系统中的参与者的无意行为，这些格式不正确的信息触发了智能合约中嵌入的错误检测机制。测试表明，无论格式不正确的信息比例如何，系统在处理具有正确格式的交易时都没有困难。

　　总结与结论

　　欧洲央行和日本央行，作为重要市场基础设施服务的运营商，决定进行深入的实验，以确定其各自支付系统的特定现有功能是否可以在DLT环境中运行。

　　有关效率的研究结果表明，就目前测试的RTGS服务的具体方面而言，基于DLT的解决方案可以满足当前大额支付系统的性能需求。鉴于DLT的性质，其中验证交易和达成共识的过程比集中式系统更复杂，这是令人鼓舞的结论。该项目还证实了众所周知的网络规模和性能之间的权衡：增加验证节点的数量会导致支付执行时间的增加。此外，验证节点之间的距离对性能也有影响：处理交易所需的时间随着验证节点组之间的距离而增加。

　　测试结果还表明，在设计DLT安排时，需要考虑到一系列的节点配置和系统参数。正如本报告所讨论的，节点的数量以及这些节点之间的距离对性能有着至关重要的影响。同样地，系统参数，如在一个区块中分组的交易数量和创建一个新区块所需的最小间隔(超时)都可能影响整体的延迟。节点配置和参数也应考虑在内。这取决于应用程序的需求。