正文

PFMI与金融区块链的系统需求：我们是不是预备遇到第2波区块链项目的失败？

蔡维德2018-12-24 06:02:50

在过去几年，我们不断收到信息，区块链技术将会带来金融市场的颠覆。但在2017-2018年，多个国家央行包括欧洲央行、日本央行和加拿大央行的实验却带来不同的信息：使用区块链不能达到银行的性能需求，有安全性问题，甚至可能增加造成系统性风险。不只是这些央行，重要金融机构包括SWIFT和DTCC的实验也带来同样的信息，就是现在的区块链技术离实际应用还有距离。在SWIFT报告出来后，IBM公司也公开承认超级账本(Hyperledger)的设计需要进步。固然后来DTCC发布实验成功的消息（但是没有公布技术细节），但银行和金融机构的这些警告应该得到区块链工作者以及社会的高度关注。

为什么今天一些世界著名的链在这些实验失败？成功和失败的标准是什么？我们有没有从这些实验的失败中得到启示？

我们注意到，这些央行都使用 《金融市场基础设施建设原则》（PFMI [2]）来评估区块链系统。这个原则是世界许多央行（包括人民银行、欧洲央行、日本央行、加拿大央行、英国央行）公认的原则，在2008年世界经济危机后提出来的，由国际清算银行支付结算体系委员会（CPSS）和国际证监会组织（IOSCO）于2012年4月共同发布，是加强和保证金融稳定性的十二个关键标准之一，已经成为当前各国金融基础设施建设的纲领性问题文件。因此，我们推荐：任何人在考虑或计划在金融系统上使用区块链，应该优先考虑PFMI，并且牢记一个重要原则：

区块链的出现不会也不能改变PFMI，反而区块链的设计必须根据PFMI而改变。

区块链从2015年受到传统金融界的重视，起因是华尔街日报在2015年1月的一篇文章“数字货币的革命”[1]，作者称比特币“是一个全新的、分布式的社会交换价值管理系统”，“是近500年来，金融领域里最为伟大的创新之一”。这篇文章震惊了当时的金融界。

后来，在2015年10月，大量投资涌向区块链公司。第一批投资的区块链系统主要是参照比特币或以太坊设计，许多区块链的项目和计划，包括R3 CEV （Corda）、DAH (Digital Asset Holdings)、Chain.com、以及IBM（超级账本），都是金融区块链，不是数字代币的区块链. 两者都用称为区块链的链，但是设计不一样。这些系统大部分是延伸以太坊或是比特币的设计，虽然都声称其系统为现代金融系统设计的，但都没有对标PFMI。后来加拿大银行、欧洲银行、和日本央行实验评估这些系统后，都发现为金融系统设计的区块链有大量缺陷需要弥补，表明这些第一代金融区块链系统离实际应用还有差距。这清楚表面单从技术出发是不足够的，系统设计应该从金融系统需求出发，也就是从PFMI出发。

最近开始了第二批的投资，出现了许多新的区块链系统设计，有些由著名高校大师设计，包括美国、法国数学大师设计的共识算法。有了这些大师的名声，区块链投资又引起一个投资热潮和社会关注，而投资的热点大都是在提高区块链的速度，如共识速度、TPS等。今年8月时，笔者发文谈到“风向变了”[14]，即金融区块链应用的瓶颈不是速度，而是整体系统功能、性能、和安全，尤其是PFMI。笔者曾发表了一篇文章“从PFMI的角度谈区块链”[10]，分析了在优化扩展性设计的同时保证数据透明度的问题，指出这是区块链设计的“一个大坑”。很不幸的是，从目前发布的消息看，第二批投资的区块链系统，例如热门的公链项目Algorand[5]和Dfinity[6]等，均还没有考虑PFMI[7]。可以预见的是，这些系统如不更改设计，今后都会在实际的金融应用中遇到问题。

所以笔者在此再度倡议， 金融区块链的设计需要从最开始就要考虑PFMI原则 ，即下功夫从金融业务的实际需求出发；否则，花了大笔基金和大量人力，以后完成的链还是不能给金融系统使用。

在根据PFMI原则评估区块链技术时，我们会有不同的关注点和优先级。例如，“去中心化”被认为是区块链的一个技术特色。但从PFMI的原则出发，“去中心化”就不是必须满足的设计要求；而数据的透明性、可监管性、交易的效率和可靠性对于金融系统的应用最为重要，为了满足这些要求可以放弃“去中心化”的技术方案。例如，清结算是区块链的一个重要应用，目前各国央行主要采用如RTGS系统，如果采用区块链技术增强、扩展或是替代现有RTGS系统，那就必须满足央行对所有数据的监管要求。加拿大央行在Jasper的报告中明确指出[3]，央行不会放弃任何监管权力，系统可以是分布式的，但需要对交易全程监管，央行需要全部数据，并能在极短时间找到所需数据。正如笔者前面文章所讨论的，这样的需求会对未来区块链设计有重大影响，一些设计如UTXO、数据分片、DAG动态验证模型等，虽然可能提升系统的可扩展性（也有可能降低），但会面临监管的挑战，因此在银行应用困难。这三个技术遇到的PFMI困难在笔者在以前的“坑”系列文章已经分析过[8][9][10]。

从PFMI出发设计区块链，本质上是从系统需求出发，系统设计和分析的方法。 在区块链设计中，从数据结构、共识算法、分布式架构、业务流程等多个方面，会有不同的优化视角。系统工程的一个重要原则是“多目标优化”，即综合权衡有可能相互冲突的多个优化参数。这不同于目前区块链设计的单目标优化，多半只重视速度。

本文中根据PFMI原则，分析金融区块链的若干系统设计问题。

一、 可靠性和容错性

促进金融稳定性是央行的核心职能，为此，金融基础设施的可靠性是PFMI的主旨。金融基础设施作为资金的通道、金融的管道，如果功能不当，不仅诱发风险，而且容易扩散风险，造成系统性风险。因此，基于区块链的支付、清算、结算等金融基础设施系统，可靠性设计至关重要。

系统可靠性不仅是降低系统出错的概率，还包括在系统出错时可纠错和恢复正常运行的能力，即系统的容错能力 [8]。ACM图灵奖获得者，著名的计算机科学家 E.W. Dijkstra在1974年曾经提出分布式系统的自稳定性（self-stabilization）的概念，即系统无论起始于任何状态（包括正常或是出错的状态），都能保证最后系统会达到一个合法的稳态。这不是容易完成的。区块链也需要具有自稳定性，就是系统在任何时候，能及时检测异常交易，排除错误，阻断错误（风险）传播，恢复到稳定的状态；即使在恢复过程中，系统又出现同样或是不同的问题，不论恢复过程中出现多少次问题，系统最后还是回到一个稳定的状态。

E. W. Dijkstra 一直被认为是软件工程之父，图灵奖获得者

目前区块链可靠性设计中，多仅限于账本的冗余备份，尚缺少考虑运行过程中对于账本数据或是操作错误的容错能力、对于交易错误的检测与系统修复机制。这些都需要自稳定性。这点在笔者2018年3月出的文章里面提的这观点[12]。

二、可扩展性

扩展性一直是区块链的痛点，也是研究的热点[9]。这里需要重视的是，从PFMI的角度考量，提高系统处理速度、增大数据量、提升吞吐量等性能改进，并不一定满足对于金融交易业务能力可扩展性的需求。例如，央行需要能监管所有数据和交易，相关交易必须能达到所有节点的共识。随机选取的部分节点、或是对于部分数据的共识机制虽速度快，不会满足PFMI的需求因为他们不满足监管的需求--这些机制造成监管困难，因为监管节点必须在许多节点里面寻找验证节点，加拿大央行在2017年就以这个观点批评Corda[3]。因此，需要将“ 满足金融共识需求的可扩展性 ”作为研究的主要目标，而金融共识不同于一般共识，是支持监管的共识机制，即监管节点能够快速的发现账号，验证节点，以及验证流程的记录，再加上可扩展性。单单解决可扩展性是不行的。

三、账户查询

数据透明性是PFMI的一个重要原则，央行及监管部门需要能随时高效查询到所有的账户及其金融信息 。加拿大央行在Jasper项目报告[3]中就提到，Corda区块链由于没有共享所有信息的账本，账户查询需要跨越分布在不同节点上的账本，难以满足在很短时间内、用很少的步骤就定位任一账户信息的需求，缺少数据透明性，这是其未能通过实验验证的主要原因之一。

笔者在前面的报告中也分析过[10]，目前几种典型的区块链数据结构数据透明性的问题。例如，UTXO模型中，每个交易都有一个临时账户，而不是银行的用户账户，大量的账户和交易难以审计；不是银行的余额账户，即交易不直接记录账户的余额信息，查询余额需要提取所有相关的记录块和交易。这两点也造成UTXO模型数据透明性差，对银行应用造成巨大困难。鉴于此，笔者曾于2016年9月就预测[13]，英国央行的RSCoin数字法币模型不会是英国央行最后的版本，因为RSCoin采用UTXO模型，不符合于央行对于数字法币的需求。2018年英国央行放弃这项目。

四、 清结算

清结算一直是PFMI的重要应用场景。可有两种清结算区块链设计：

1）使用区块链的账本系统；

2）数字货币+钱包+账本。

采用第一种设计，传统的清结算还需保留，但清结算的流程设计会改变。北京天德（2017）、DTCC（2017和2018）、SWIFT（2018）、等在过去两年验证了第一种清结算区块链设计的可行性，但需改变现有的金融系统基础结构。

如采用第二种设计，清结算一次交易完成，但由于引入了数字法币的设计，会改变金融模型，引发其他的问题，如可回滚性、数字钱包的安全性、以及监管等。第二种设计目前尚未有成功案例，但近期IBM公司、Gemini等发行稳定币的研究，是在朝这个方向努力。数字法币会影响整个金融生态系统，建立新的以数字法币为基础的金融模型，对金融基础设施的变化巨大、更复杂，是一个需要深入研究的课题。

五、 金融效率

区块链科技人员努力提升通信速度、处理速度、算法速度，但实际上，金融业务对于速度的要求并没有那么高； 相比于计算速度，金融业务更需要的是业务效率和效力（PFMI原则21），而且是能降级金融风险、保证业务可靠性的效率和效力 [11]。例如，根据一些央行在报告里面提的实际数据，加拿大银行间交易系统平均每秒1.11笔交易，日本央行平均每秒处理3.26笔交易，虽然频率不高，但是这些央行交易都比数字代币的交易复杂的多。在我们的实验里面，我们遇到1:5到1:20的复杂度。

区块链的自动合同执行程序如果存在错误和安全漏洞，一旦触发，可能迅速传播，引发系统风险；如果缺乏有效的管控机制，区块链速度越高，风险越大。

金融系统的效率更强调系统满足最低服务水平、风险管理预期、业务优先级、定期评估机制等度量的、可实现的目标。这也应该是目前的区块链性能设计需要优先考虑的因素。

六、 可监管性

可监管性是一个重要的课题。在一般的区块链设计中，公链难于监管，甚至设计是为逃避监管；而联盟链是为了支持监管。但如何实现有效和实时的监管，其方法和机制的相关研究非常少。PFMI原则中对监管有着明确而严格的规定，例如，透明度的原则规定（1）规则、关键程序和市场数据都需要提供充分的信息，公开披露，供参与者能够准确了解；（2）需根据有关管理部门和公共各自的的需求，及时准确地提供各种交易数据库市场数据。

GDPR和Open Banking也提出现代金融系统的新要求。例如，资产拥有者拥有数据，而非金融机构拥有数据。所以，资产拥有者可将数据转给第三方；不只是监管单位，公司和个人都有权利审查和使用自己的数据、追踪哪些人和单位使用过这些数据。这些都会使区块链的设计有全新的方向，不只是不可篡改性，还有数据的溯源能力的需求。这些都不会因为项目方使用区块链而改变。这好像PFMI不会因为金融机构使用区块链而改变其原则。

因此，金融区块链的设计，在保证数据安全隐私的同时，要具备足够的数据透明性，以满足现代金融系统金融审计的需求。

七、 可回滚性

现代金融系统允许参与交易者在交易后回滚，可能资金未到位或资金来源或资产有问题，回滚时间有期限（金融系统的要求），但现在区块链中许多交易不能回滚，一旦交易成功，记录就不可修改。

八、总结

综上所述，下图总结了本文讨论的几个区块链系统设计问题。笔者建议，区块链的理论研究在应用中，需要具有系统设计的思想，充分考虑以PFMI为代表的金融系统的需求；并鼓励从系统需求出发，优化区块链的数据结构、共识算法、分布式体系架构、以及业务流程。

我们在2017-2018年已经遇到了第一波的区块链失败，这些失败大都是根据PFMI评估出来的。而且在这些央行实验中遇到的问题不是化妆式(cosmetic)的问题，而是结构性(structural)的问题。结构性的问题不是一两天就能解决，也不是一两个月就能够解决，结构性的问题可能一两年都无法解决，而且解决方案有可能是重新做一个系统，因为原来系统结构不能匹配PFMI原则。

软件工程大师一直教导大家，系统结构如果不能和应用系统需求匹配，系统结构很可能会有巨大改变，甚至需要重做。第一代金融区块链系统已经遇到了这样的困难。我们再次提出已经提到的重要原则：

区块链的出现不会也不能改变PFMI，反而区块链的设计必须根据PFMI而改变。

最近又有新的一波区块链投资做下一代的区块链系统，但是令人担忧的是他们仍然没有考虑PFMI，是不是我们预备两三年后再度遇到第二波的区块链系统实验失败的消息？PFMI 不会改变，等到下一代区块链系统出来的时候，PFMI还是会被各国央行使用来评估这些系统。

参考文献

[1].Michael J. Casey, “The Revolutionary Power of Digital Currency”. 2015.1.24.

[2].CPSS and IOSCO，“Principles for Financial Market Infrastructures: Disclosure Framework and Assessment Methodology”, 2012.

[3].Bank of Canada, Project Jasper: Are Distributed Wholesale Payment System Feasible Yet?, Financial System Review, June 2017.

[4]. https://www.wsj.com/articles/the-revolutionary-power-of-digital-currency-1422035061

[5]. https://www.algorand.com/.

[6]. https://dfinity.org/

[7]. https://www.8btc.com/article/299241.

[8].蔡维德等，“区块链技术的几个重要的坑（上）”. 2018.6.14.