区块链与金融IT“联姻”的思路和方案

2017年是区块链的落地年，越来越多的银行经过了区块链的概念验证POC，不断将区块链技术应用到实际生产系统当中。尽管经过一定时间对区块链的研究和实践，很多银行科技团队已对区块链有比较深入的了解，但在实际整合区块链技术的过程中，不少传统银行科技仍旧对区块链是否安全稳定存有很多疑虑。实际上，根据我们的经验，区块链经过几年的发展，技术本身在容量、扩展性、TPS性能指标、稳定性上足已达到商用标准，更多考虑是如何让区块链和传统金融IT在整合上提供完整严密的落地方案和解决思路。以下文章就是在传统银行IT如何落地区块链技术这一领域进行探讨，适用于银行和金融机构的产品经理、系统架构师、开发工程师参照阅读。

为什么要上区块链系统

在应用区块链技术之前，首先要考虑清楚哪些场景和产品适合使用区块链架构实现，哪些不适合。这里参考了段新星在钛坦白的分享实录（http://www.tmtpost.com/2694378.html?from=timeline&isappinstalled=0），文章提出了应用三原则，我觉得点的非常到位，这里我再补充一些我的理解。

“不要拿大炮打蚊子”。区块链技术更适宜于资产网络（Assets Over IP），针对这点，银行本身从事的就是资产相关业务，比较匹配。
使用区块链，一定是要有多方写入数据的需求。在某种角度上，如果把区块链作为一种数据库而言，这里边非常突出的特色就是：它是一个天生去适应多方进行协作的数据库，一个单一的写入者写入数据的数据库可以搞定的，就不需要用区块链。所以，在这里一定有多方协作需求。
区块链产品一定是天然的弱中心化的。区块链做在国内支付基本没有可能，因为中心化平台已经足够强势和足够好的体验，比如支付宝、微信、银联。但用区块链做打通多个不同国家商家、金融机构的跨境汇款、清算结算的成功案例则不少。原因也是很简单，后者在复杂多边市场中，缺乏“中心协调者”，存在严重对手风险的交易困境。比如，信用证就是一个很好的应用场景，今年7月份，中信银行已与民生银行合作推出首个银行业国内信用证区块链应用，为银行拓展国际结算、贸易融资等业务提供支撑。

另外，需要补充的是，在现阶段银行体系使用区块链来解决运营效率、降低运营成本也是一个非常明显的应用点，比如：招商银行通过区块链技术改造的跨境直联清算业务将正式实现商用，实现了总行与海外分行各节点的资金清算，并将交易时间由6分钟缩减至秒级。

典型融合架构

以下为典型的银行IT和区块链的融合架构。部署在银行的区块链节点会在应用层、业务层、数据层和银行现有IT架构发生交互。

图片描述

应用层：银行IT应用层，比较典型的，比如国际结算系统、外汇交易系统、支付系统等等，将会和区块链的连接层发生交互，通过Restful API发起区块链交易或者通过WebSocket机制接受区块链区块和交易结果。

业务层：通常风险控制策略、支付清算规则、AML规则在这一层制定，区块链通过智能合约（或称：链上代码 ChainCode）写入和交易关联方相关的业务规则，比如风控规则、清算分润等都可以通过智能合约写入。

数据层：区块链一般采用K/V数据库，适合区块链实现不间断链式存储和简单信息的存储，并不支持SQL语句复杂查询，当然也无法支撑进一步数据分析、挖掘。比如，在我们在一商业银行落地的区块链项目，基于UTXO的账户模型需要被抽取、初加工，并根据行内的AML规则再加工，实现资金流向监管，实现资金的精准投放。同时，银行数据层通常有更完善的容灾备份策略。所以，区块链架构方案需要配套为关系型数据库（Oracle、DB2、Mysql等等…）提供数据导入功能，一方面作为数据安全存储需要，一方面为数据再加工提供数据源头。

对账模式的变化

以哪个系统账目为准，对账周期怎么设定，在银行IT中一直是一个很原则性的问题，系统融合区块链之后，这点需要重新理解，并使用新的规则来实现。我们在一些落地项目中，需要花费很多精力来让银行IT人员理解并在新模式下实现新的对账模式。

图片描述

为便于理解，我们以基于银联的跨行支付系统为例，来看一下传统对账模式。

清分Clearing一般发生在T日日终（比如23:00），银联完成清分后，向各个成员机构下发清分文件，各个成员银行根据中心的清分文件来对账，注意哦，一定要以银联为准。

PS：淸分Clearing是指对交易日志中记录的成功交易，逐笔计算交易本金及交易费用（手续费、分润等），然后按清算对象汇总轧差形成应收或应付金额。简言之，就是搞清楚今天应该向谁要多少钱？应该给谁多少钱？

相比现有中心机构模式，基于区块链模式下，每隔一段时间（一般几秒到十几秒之间）会生成区块（Block）的生成，这个区块中的交易明细已经在各个参与方节点的共识过程中形成一致性账本，意味着对账时时刻刻都在进行。所以，新的对账模式应调整为：

1、日终对账变为实时对账
2、以跨行转接机构（比如：银联）为准转变为以区块链一致性账本为准。

由此可以看出，显而易见的好处是：效率提高了，配合以良好的交易机制（在下一章节提到），可以将差错账发生率较低到几乎为零。

解决事务一致性

我们在某银行的一个区块链项目中，探讨一个场景，这个场景要求先从区块链进行数字资产交易，同时在银行本地账务系统进行电子账户相关账务操作，这两个动作要求实现事务一致性。

在银行现有系统架构中，事务一致性保证有一些传统做法，最简单的是通过本地关系数据库的强一致性来实现本地事务的一致性；或者是通过设计一些冲正交易模式来进行交易回滚；再者通过两阶段提交协议（2PC）来实现。

针对区块链交易以上均无法支持，原因很明显

一、区块链节点是独立应用，无法通过本地事务实现；
二、区块链使用的数据库是NoSQL数据库，这些非关系型数据库无法支持2PC；三、区块链没有交易回滚（Rollback）机制，只要区块上的交易，无法通过冲正交易回滚。

解决思路是从微服务架构中寻找事务一致性的解决方案。其实区块链应用节点就是一个独立微服务。微服务的实现事务一致性的模式有三种，可靠事件模式、业务补偿模式、TCC模式。其中最适合的是可靠实现模式，某种情况下可以使用业务补偿模式。原因是：TCC模式，要求支持Cancel操作，区块链均不适合。综上，我们建议使用基于外部事件系统的可靠事件模式来保证交易一致性。

具体方案设计如下：

图片描述

外部事件系统记录事件消息全流程状态，从上图可以看出，从1-5是正常交易流程，其中可能发生异常情况：

区块链交易失败
区块链交易成功，但没有通知到事件系统
账户系统交易失败（可能没有收到，也可能处理失败）
账户系统交易成功，没有通知到事件系统

对账处理进程定时从事件系统库中找出A）已经登记的，但没有收到交易出块通知的交易 B）账户系统未置“完成”的交易。

针对A，对账处理进程从区块链中进行查询（包括对比区块，是不是已经过了超过2个以上区块），如果区块链没有完成交易，则将事件置“取消”，解决第一种异常；如果区块链交易成功，则更新事件状态为“待账务系统处理”，并送入消息队列，解决第二种异常；

针对B，再次通知账户系统，触发账户系统再次处理（本操作可以根据情况，设置多次），解决第三种和第四种异常。

PS：账户系统同时需要实现幂等性，不能因为重复收到事件而多次重复记账！

补充说明，账户系统对于记账失败可以反交易处理，在其他场景，我们也可以设计事务补偿的模式。平台亦可使用服务编排的方式降低这种模式的开发复杂度。

身份实名化及密钥管理

在公有区块链最初当中，均不需要进行身份实名，密钥管理也是交给个人自行管理。对于金融行业应用区块链，显然既不符合监管，也没法满足银行商用标准，所以，针对银行联盟链来说，最重要需要实现两个目标：

1、链上身份实名化
2、数字资产控制密钥的可管理，包括挂失、找回这样的异常管理

对此，我们建议的方案如下：

1、对于身份实名，基于银行已有成熟验证通道，我们建议借助银行现有的二、三类账户验证模式和KYC，比如银行卡四要素的认证方式。
2、鉴于用户对银行的信任度很高，密钥管理方案建议采用“可选托管方案”，用户可以选择自行生成和管理密钥，或者在用户许可下，由银行为用户托管密钥，并通过安全方式下发给用户终端，这样用户可以通过自己实名身份进行挂失、找回等。具体如下说明。

图片描述