[工信部区块链论坛]钜真金融创始人孙立林：清算结算的失败不光是技术原因 ...

记者：铅笔芯

国内网红级别的初创企业—钜真金融，大家关注区块链圈，大家会知道钜真金融的孙总，令无数初创企业非常羡慕，主要原因是因为他的背景实力是很雄厚的，之前一直是在清算方面绝对是最资深的专家，微众银行在今天早上也讲过的，区块链目前来讲核心解决金融的问题就是清算和结算，孙总下面的内容会给大家一个特别清晰的解释。

孙立林是钜真金融创始人兼CEO，同时也是ChinaLedger分布式账本联盟技术委员会副主任，他认为从客观来说，目前区块链金融阶段稍有一点非常早期的阶段产生的泡沫，在万向峰会上面好多前辈说这个泡沫是每个产业发展正常的泡沫，希望在泡沫当中找一点点经验的积累，跟大家做一个分享。

我们一直觉得目前对这个事情有些过度神化，从技术来说只是一个分布式系统，只是对数据一致性要求更强。正如杜宇介绍的，我们未来的世界是一个全数字化的世界，会全面向分布式架构做迁移，整个基础设施面临重构，我们提出来是在这个领域里面所谓共建金融通天塔，就是一个协议的共识。

我确实很习惯拿这张图来说事，因为不了解这张图，就无法了解今天中国整个清算技术面临的问题，在座干过银行的同事都非常了解，从十多年前的联行系统，非常痛苦，02、03年北京工商银行在上海和杭州工商银行无法取暖，这个系统越来越完备，有越来越多的前置交易被处理，但是越来越被难以处理，越来越碎片化。

在中间上方粉红色这一片就是人民银行的系统，最核心的就是大小额，然后超级网银，就是日常交易要用到的，今天很多人提链上和链上的交易，所以我们无法在今天完整把所有交易过程向前面迁移，这是做不到的，除非将来央行数字货币发行了，才有这个可能。很巧的是10月7日美联储的说法叫分布式账本技术，在支付清算和结算的应用，写得都比较客观，用的词不是区块链，用的词是分布式账本技术。用的领域是支付、清算和结算，这个词也很准确，这是三件事，从来都不是一件事，但是很容易弄混淆。

大家比较熟悉的支付，往往会只走第三方支付系统，其实在右边这个金融市场的支付清算系统也是非常大的，像清算所，中证通，都是体量非常庞大的，美国的DBCC都在这个领域。右边的报告只说两个问题，一个是刚才分散的支付清算系统，现在的问题是随着时间的向前，然后随着整个系统不断复杂，一般来说一个成熟的股份制商业银行，至少有几百个，以百为量级的前置交易系统，这个前置系统越来越复杂了，导致路由和交换也越来越复杂。清算失败带来的损失是270亿，这一点具体到落地的时候，还是要回到金融业务逻辑本身和金融技术本身。

清算失败在银联的业务运作规章里，光是差错都有几十页，上百页，并不是来了一个区块链技术，这些问题都迎刃而解了，这是完全没有可能的。也就是说只看技术，或者只看所谓的性能，清算失败有好多的原因导致的，不完全是技术问题。我们的观点也很紧张，刚才像道和兄介绍的联合贷款，其实都是一个同业登记存托在这个领域去走。

这个也是特别有价值，跟大家分享的，无论业务怎么变化，技术怎么变化，但是金融世界有它的基本的定义，这个东西来自于国际清算银行的工作委员会定的标准，PFMA在开篇的时候就给出了十大基本的原则，下面有小原则，CSD是证券存托系统，你必须最好跟这个原则保持一致，这些原则是无数的前辈赔钱赔出来的失败教训和经验，非常值得借鉴。其实大家可以看到，如果是做区块链技术有一段时间的朋友，应该是有感觉的，我们提到了很多东西在传统金融技术设施规范化都有没有考虑到这些问题，我认为是不可用的，它不是一个解决方案，它是一个玩具。

这里格外可以跟大家多分享一点的，这里提到的很多东西，像这里的Settlement，分得很细，提到了很多关于这个领域必须注意的基本事项和原则。还有监管方的责任，也是全球业内在做联盟链的时候，大家都提出来要引入一个监管节点。十几年前温总理还在的时候，派人到中国来检查了，出了一套，苏行长出了一套书，就是关于这一套检查评估的报告，其实都非常有价值，我们的金融基础设施即便是在目前的架构上面，还有很多的问题需要研究。

这个是我们自己总结的一个基本原则，做金融交易和一般的在线其他交易是不一样的，金融交易格外看重对于风险的控制和安全。性能这件事情我反而觉得优先级在其后，特别是对于新技术，这两年为什么性能大家提得这么多，确实是这几年从商业银行来说，我们去本行化，把跨行交易打开了，包括支付宝每年双十一据前置交易系统有冲击，这个时候性能会出现问题。确实这一点来说，很多传统商业银行的架构都落后，DPS确实低到大家都无法想象的，因为原来没有那么大的量，现在有这个需求。

但是我想对于一个新技术来说，这还不是第一个需要追逐的事情，目前第一步还是要不整个业务逻辑在链上先实现，这个过程会很长，只有你业务先跑通了，我觉得其他的问题会有办法解决。这些要素不可能全部满足，我不认为有一个系统可以同时满足所有的要素，第一它是一个演进模式，第二个你满足若干要素的时候，就一定要牺牲别的，比如说对安全和风险控制的性能一定会掉下来。所以我在这边提到，我们目前在做底层的开发，以及跟很多金融机构的合作来看，优先级我觉得是安全和审计，然后才是性能+存储。

第二，我们觉得还是要面向服务和运营来考虑架构设计，不是简单只交付了一个产品，一个软件，一旦面临着运营服务了以后，确实是金融机构的人比较擅长一点，因为你每天要处理大量的清算，可能会出现对账的差错。

从我们的观点来看，我们从来不追求去中心化，我们认为应该是分布式，而不是去中心化。本质上我们认为目前只是一个工程问题，底层做得再好的共识算法，和其他协议的共识，或者是密码的算法，在我们测试环境跑完之前，其实有大量的坑需要填，在代码没有写完之前，其他都是空谈。

这个其实是我们理解对联盟链的基本架构，安全、隐私保护、监管和治理，安全其实就不用说了，对节点的准入，还有节点各种交易权限的控制。隐私保护我们现在跟国内，还有全球的一些领先学术机构做过很多交流和合作，大家熟悉的ZK这些算法，单独是可以的，一旦把它打包成一个标准的密码协议，不是密码算法，来上生产系统，可以说全球目前为止我认为是没有成功案例的。我不认为目前有成熟的解决方案，这一条路还需要很长时间的探索。

目前我们能做的事情，实际上是做了一个杂凑，我们把各种基础的算法整合成新的协议来适配，但是会发现很多算法是有内生性的冲突，当你放在一个场景下面互相不匹配，所以这个很麻烦。大家说的同态加密，同态对性能的损耗是不可计量的。我们上生产的时候，是不是要用这些听起来很高大上的算法，不见得，传统的金融机构走下来，有一套很成熟的工程做法，来解决这个问题。

我们一向认为最理想的情况下，是能够在链上的交易，都是可以被监管者神的眼睛可以随时看见每一笔交易，以前我在银联管支付公司，我们经常会碰到人民银行检查，各个司局的检查，我只能把服务器所有的代码和内容的数据报送，或者是财务数据报送，实际上无法做到像智能合约这样自动生成审计，这是他做不到的。分布式账本技术这个大话术的逻辑下面，核心还是智能合约。

工程上的实践可以做一个简单的分享，目前用的共识算法还是用的PBFT。我们要把链上的交易和链外的交易要分开，这里要设一些监听和调度，一些事件的流程引擎来做处理。屏幕的下方还是传统的很熟悉的账户体系和交易系统。美国也一样，所有的系统能不能进入到美联储的系统里面是很关键的，我们在美国见过很多区块链这样的公司，有一家公司我印象非常深刻，它是直联进入了美联储，在中国来说类似于没有一家牌照的公司，能够连人民银行。

在链上来看，定义了非法节点，会员节点还有记账节点，还有治理节点，就是需要有很强中心化的机构，要么是中国银联，要么是交易所，要么是登记存托机构，才能处理这样的事情，所以去中心化的事情，在实际交易中，我们认为是一个（将为）的使用，你不需要这么强牌照处理下的一个机构来做，但是必须要有一个治理节点，来做业务上的运营和技术上的维护。

前面介绍了很多，后面给到我的任务是来介绍一下开发的实践，这个就是我们在智能合约的写法当中，对所谓资产端的一个定义，大家可以看到左下方，是对资产登记录入，还有对资产交割的整个过程。为了让整个系统更可用，所以我们并没有允许各个类之间来直接做交易，其实还是要定义接口来做调用，这一块是很具体的工程实践。右下方是会员节点的管理，这里也要做一些相应事件上的部署。

这个是实际生成的一个页面，可以接大家做一个分享，回到刚才我提到的一个观点，就是我们是面向运营级的服务来交互我们的研究，或者是产品，而不是仅仅交互一个代码，大家怎么理解这个事情，对于金融行业的运营人员来说，他看到的是这几个页面，而不是上一个页面的代码，是无感，底层是区块链还是别的什么，跟他没有关系。我们要做的是把每天处理的清算交易，或者整个结算过程中面临的问题要解决掉，这个是面向运营提供的服务。从实际的交易系统来说，即便像银联这样的高频小额交易的网络，实际上TPS两三百前置交易就足够用了，像双十一的峰值是很少出现的，不必追逐这个指标，并不能保证这个产品是实际可用的。

这个是验签的，无非就是买方记账，卖方确认，还是倒过来，这个取决于具体的场景，定位有不同，所以无法做普世的事情。

开发中遇到的问题，就像我一开始说的，我认为今天整个区块链世界，或者分布式账本世界，整个社区还相当早期，这处于95年我们还在玩mard游戏的时候也许还在那个时代。即便遇到了很多的问题，比如说支付的操作，都能满足，我们在工程实践的时候，这些东西都要尝试，是要重写才能用。

下面的问题更严重，接口内变量数限制，EVM限制，单接口内总变量数不能超过指定数目，因为实际交易真的无法满足了，现在做的做法，我们的解决方案是没有办法，就得折腾一下，因为变量常用的方式，或者不断拆接口，会导致整个系统的难度会提升，导致并不是那么方便。

还有提到了Solidity函数不能返回struct和二维数组，这个高级语言真的不错的，设计起来是很有诚意，但是使用起来还是很多坑，c++也引进过很多的版本。

跨合约的时候不行，合约之外就不行，合约间的交互就搞不定了，合约之间只能各自定一个接口，今天管技术的老总，今天很多的年轻人解决问题的能力相对弱一点，经常出现这种差错，前些年这些支付公司一拥而上很多，系统经常会崩溃，第一是对金融业务逻辑不理解，第二个是这种技术的编码能力。

合约升级，目前以太坊不能升级合约代码，只能创建新合约，升级管理合约记录合约版本和地址，旧合约保留足够的数据到处的接口。

我们也是在探索，在这里发现的问题，你要非常小心外部合约调用，如果没有一个强中心，或者金融机构来审核上线的代码，就会遇到这样的问题，比如说黑合约，或者是恶意的合约就会出问题。可能直接把钱转走了，这样代付循环调用。

失败处理也是一个问题，发生错误时，停止合约，一定要测试充分，如果大家基于目前的开源社区的测试充分式的必备，在金融机构受过训练的，会略有一些不一样，我们见过非金融行业来做，我们建议是保持合约的简洁，还有模块化。

我们想在这里跟大家分享的，交给我的任务是开发实践的经验，我觉得目前的实践，我们的姿态是拿来主义，就是只要有利于整个最后生产系统的可用性，我们都可以用，我们并不会拘泥在某种代码，是以太坊，还是其他的代码，其实我们都抱着开放的心态，去学习研究和使用。当然也会给社区做回馈，做回报。

从目前的情况来看，我们的体会是没有觉得有一个完备的工具可以支撑的，这是今天的实际情况。

最后做一个我们公司小小的介绍，我们其实就是在管这一端，借用华为的词，虽然还叫云管端，这个管我们认为是做清算，支付的本质实际上是全球所有的央行发行出来的货币，它的一个重要属性就是流动性，流动性面临着摩擦和阻力，摩擦阻力两个主要的要素，第一个是价格要素，像比如说我们做转接的时候；第二个阻力是因为资金有流动性，流动性每一个环节从央行到商业银行，都会有这样IT设施的投入，前置的建设，会造成及时设计投入无限的放大，难度较大??我们不能保证每一个水平和经验能够足够承担，因此一定会出错。在会出错的情况下，我们不会认为分布式账本就不会出错，出错的还是人。我们定位在中间，技术服务和业务流程的运营服务，这是我们非常看中的事情，我们并不直接提供这样的软件或者是简单的开发，我们其实是面向运营来看整个清算和整个流动性的问题，这是我们的定位。

跟大家分享一个感受，虽然说了很多听起来很悲观，很负面的，我最近在看《无事说》这本书，走这条路，相信技术可以改变未来的，就是尼采说的超人，我们要走超人这条路，一定要树立坚定的理想，这个技术未来我们要相信在逻辑上是高度自洽，或者是可以自足，并且未来的路会很长，所以希望跟同道中的人一起交流，

卢道和：孙总从账本的本质到清算，也是我们这几个人唯一把代码展示的一个演讲嘉宾。