当我们做区块链时，我们在做什么

长话短说，我们在建链。

区块链

关于区块链是什么，网上的解释多如牛毛。这里，我从需求的角度总结一下：当做记录保存（身份存证）时，它是分布式账本；当做交易或支付（跨境支付）时，它是信任机器。虽然这两种分类方法并不正交，但是对于理解区块链的应用方向有很大的好处。

区块链需求分类

区块链是什么

不论是分布式账本，还是信任机器，以及底层的特性——不可篡改、透明、可追溯以及去中心化，最终导向的目的只有一个，那就是信任。人与人之间的信任关系很复杂，通常两个陌生人想达成交易之前，会找一位权威的第三方中介做公证，交易双方的信任问题依然存在，只是他们都相信了中介的权威性。类似的，区块链也不会解决信任问题，它只要让大家相信自己就足够了，这个问题就规约成怎么保证区块链自己是可信任的？

区块链为什么是可信任的呢？因为人类相信数学。数学理论和加密学实践可以确保了链上数据和所有权的可信程度。其次，区块的确认基于多数人的共识，这在某种程度上肯定了群体智慧，即大多数觉得正确的才是正确的。再次，精妙的算法和不可变数据结构，Merkle tree可以快速证明交易是否存在于区块中，Hash pointer决定了当前区块的前趋区块不可篡改，进而保证前向区块链的完整性。最后是经济博弈和人心，因为加密货币的加持，凡是以破坏整个网络的为目的手段，最可能导致整个网络里的加密货币价值归零，那么单纯以攻击为乐的算力威胁是失去理性的标识，理性经济人是区块链网络里的人心假设。这4条相辅相成的设计决策是比特币的最负盛名的优雅创造！

Merkle tree & Hash pointer

然而，企业间的联盟区块链，它的信任更多地依赖于发起者品牌的背书。在允许这样的背书之下，联盟链的设计就变得相当灵活，比如最先腰斩的就是代币。

区块链的行业应用

在工信部最新发表的《2018 年中国区块链产业白皮书》中，区块链产业生态分成了产业应用，包含金融和实体领域；基础设施和平台，如公有链和BaaS；行业服务，如媒体。而我们的关注点集中在产业应用当中。

区块链产业生态地图

金融领域由于本身数字化程度比较高，在证券化和以及ABS交易所等方向都有落地案例。在实体产业当中，供应链溯源，身份存证等也多有应用。再加上区块链本身具有“信任穿透”的神奇功效，对于供应链金融构建征信体系，改善小微企业的融资困境也很有帮助。

总得来说，区块链技术几乎在所有的产业场景都能落地应用。因为几乎所有的产业场景都涉及交易，都有降成本、提效率、优化产业诚信环境的需求。

我们在干什么

我们区块链小分队在不遗余力地建链。现在在建某著名车厂的汽车（金融）联盟链。

汽车金融

汽车金融中的核心资产是汽车。汽车金融始终围绕车的生命周期发生金融活动。从零配件的生产，到主机厂制造整车，然后通过各个区域的销售公司，比如欧洲区、北美区、大中华区等等的销售公司，将整车卖给各区域内的经销商。实际上在中国，经销商还可以分为不同层级的二三级经销商，最后才到顾客手中。而一旦新车完成销售，就迈入了后市场的广阔天地，以及二手车三手车的再销售。

从汽车零配件的生产运输和组装到车卖给经销商，这些环节所涉及到的金融活动叫做供应链金融，而顾客通过金融活动来买车，不管是新车还是二手车，都属于消费金融的范畴。

供应链金融和消费金融

汽车金融公司的业务模式比较简单清晰，参考下图，1、2、3是汽车的批发，4、5是汽车的零售。金融公司参与给授信经销商提供贷款进行车辆的批发交易，零售的过程中，金融公司又继续给消费者提供消费金融贷款或融资租赁等服务，缓解用户购车的资金压力，促进汽车销售。因为两次贷款交易，我们可以看到这两条方向相反的资金线，财务上我们管这个叫轧差，也就是债务的互相抵消，而这两次贷款行为的轧差让金融公司以较低的净现金赚取了批发环节和零售环节的两次利息收入。

针对汽车金融公司的应用场景，我们可以简单总结业务痛点：

第一，提升资金利用率是业务关键。金融服务商以提供资金融通服务进行盈利，汽车金融公司的资金很大一部分是来源于汽车集团的财务公司，财务公司需要对现金流进出进行精准预测，以提高资金的利用率。传统的财务记账方式，无法实时透明地彰显资金的实时利用情况：比如有多少现金流即将产生，有多少资金出现了低效的浪费（重复贷款），造成了多少潜在损失（坏账）等等。

第二，财务对账主体数量较多，且效率不高。仅在中国区域内可能就有多家销售公司和金融公司，以及几百家经销商。从会计和审计角度，即使每家公司只有两名财务和审计人员，那么财务审计人员都超过一千名，更别提全球范围内了。

第三，信任主体的审核门槛较高。因为金融贷款要控制风险需要信贷审核，而金融服务机构的信审资源有限，审核流程繁杂且周期较长，经销商的销售网络又比较混乱，因此中小型经销商很容易成为“照顾不过来”的对象，造成经销商融资困难，同时也导致汽车金融公司的业务扩张受限。

汽车金融业务模式

我们能用区块链要做的事情，一言以蔽之，就是汽车资产上链以及围绕汽车所发生的金融活动而产生债务的记录。所以不难发现，分布式账本和信任机器在这个场景下都有涉及。

怎么建链

建链也是有套路的，我们大体总结成5个步骤，分别是识别上链数据，智能合约涉及，API设计，部署单元和网络拓扑架构。识别上链数据指的是如何识别哪些交易的事实值得记在链上；智能合约设计，指的是买卖车及其相关金融活动如何通过可编程的方式自动完成；API设计则是如何对外暴露平台能力，同时限制控制主体；部署单元和网络部署架构属于实施范围，旨在解答分布式账本如何真正运行在企业当中。整体技术架构是基于Corda这个分布式账本技术展开的，Corda准确来说不是区块链，而是一种受区块链启发的DLT，即分布式账本技术，它是由R3这个世界顶级金融区块链联盟开发和维护的。

上链数据识别

我们要分析清楚的问题是车在什么时候转移，车在什么参与方之间转移，车在转移的过程中伴随了什么数据的变化。在分析这块业务的时候，我们尝试了事件风暴，分析了在各个法律参与实体之间发生车转移的业务事件，然后进行了事件排序，通过事件析出数据，包括交易参与方，车的详细信息，车的所有权和占有权以及债等等。这部分数据有一定的取舍，比如订单就不在我们的核心资产当中，所以不上链。

Blockstorming

我们开始进行数据建模，在此之前，有必要介绍一下Corda的编程模型——State，因为它会直接影响我们后续的模型设计。Corda中核心概念之一就是State，State是分布式账本上的事实，它代表了交易参与方达成共识的结果。以IOU这个欠条为例，State其实就是欠条关键属性的集合，包含借款方，欠款方，金钱数量，还款截止日期。当欠款部分归还时，这个欠条的内容就会发生变化，变化的方式就是将老的欠条标记成历史的，进而生成包含新内容的欠条。

State is a fact

在我们应用场景中，核心的State就是车和债，因为Corda是运行在JVM上，开发首选语言是kotlin，所以这里我们直接拿kotlin中data class对车和债进行建模，而且统一继承了Corda内置的LinearState，LinearState拥有全局唯一ID，在数据演化的过程中不会发生改变。如果有人了解DDD相关概念的话，应该能自动映射到实体概念上。除此之外，Corda中还有一个核心State叫做Fungiable Asset，可以类比成值对象，例如：Cash。

State category

State建模完成之后该怎么演化呢？这就不得不提一个UTXO的概念，UTXO全称 unspent transaction ouput，最开始是比特币网络引入的，它有很多好处，比如可以追溯到每一笔输出的源头，帮助验证是否存在双花现象，Corda一样继承了类似的好处。销售公司把车批发给经销商时，就会将所有权归属自己的车作为交易的输入，产生输出，输出中包含了所有权的变更以及债务的生成。而作为输入的车就会被标记成历史的。这笔交易本身也必须获取到交易双方的签名才能成立。

未花费的交易输出 - 口袋里的零钱

智能合约设计

上面我们聊到的都是链上的数据以及数据演化过程，不过这些过程都不是自动执行的。对于复杂的金融合约，往往会涉及到多种state的变化，这个时候我们就必须使用自动化的流程封装这些变化，封装这些变化的东西其实就是智能合约。还是以经销商批发车为例，一个可能的合约模板就是规定车转移的同时产生一笔债，以及对应的还款截止日期。这个合约强制state改变时，交易双方必须参与签名。

在进入智能合约实现之前，我们得先了解一下Corda中flow和contract的概念。Flow是Corda中控制参与节点如何更新State的自动化流程，它对如何获取交易对手方的签名进行了封装。一个标准的flow流程包括获取链上数据，创建一笔交易，自签名之后发送到对手方进行交易验证，再签名，最终在双方的账本上分别提交事务。而Contract则是在交易验证环节提供验证所用的脚本。

Smart Contract

在我们的应用场景中，智能合约长成这样，在flow中，先从链上取出原有车的数据，拷贝得到一个新的所有权发生转移的车以及对应一笔债；然后通过 txBuilder构建一笔交易，交易的输入是原车，而输出即是新车和债；最后就是验证和签名以及事务提交的过程。细心的听众可能已经注意到txBuilder中有个firstNotary的参数，这里提一下notary的概念，notary在corda中是一类特殊的节点，专门用于防止资产双花的问题。所以理论上，每笔交易都需要notary节点参与，并对交易进行签名。在交易验证环节中，我们定义的contract会被执行，这个contract非常简单，简单到只有一个叫做verify的纯函数。它的作用就是断言每一个state的更新是否符合要求。

Smart Contract in Corda

API设计

有了智能合约之后，我们就得考虑如何暴露平台的合约能力了。换句话说，从消费者的角度，我们该怎么利用平台提供的能力完成自己的业务。所以这里我们利用了REST api设计的思路，抽象出平台的能力作为资源呈现，定义以车为中心的URI，然后选择合适的HTTP动词，得出 REST api。

API design

从数据上链识别，到智能合约设计，再到API设计，我们在不同层次利用Corda这个分布式账本技术。最底层的分布式账本记录每笔交易发生的事实，不可篡改可追溯；中间的智能合约层提供了合约抽象，甚至可以和现实中的合约一一对应；最上层的REST api以资源的方式呈现了平台的金融活动能力。

Platform hierarchy

部署单元

这样一个汽车金融平台是怎么跑起来的呢？借助docker，我们把一个物理部署单元打包成了一个镜像，底层是一个全功能的Corda节点，所有的智能合约和state都以jar包的方式部署在这个节点上；同时利用springboot通过RPC的方式连接到Corda节点，调用智能合约，对外暴露REST api；而Corda节点之间则通过messaging的方式互相通信。

Deployment unit

网络拓扑

打包成docker镜像之后，就可以部署到运行环境中，形成一个分布式账本的网络。这里有2个节点需要留意，最左边的 permission service 是用于对每个入网节点进行证书签发，给予每个参与实体一个身份。中间的Network map类似于微服务中的 service discovery，Corda中节点的互相发现并不是通过广播的方式发生，而是通过注册Network map获取其它节点的信息，从而实现找到对方。

Network topology

回顾

最后，我们回顾一下先前提到的三层架构，用价值的视角重新评估一下整个平台。传统的平台，通过api的方式暴露服务从而获得价值输入，但是区块链平台的核心资产其实在最底层的账本中。基于这些交易事实和债务或者支付记录，我们可以很方便清算各个法律实体的数字资产，计算实时的债务信息，进行车辆的价值溯源，而且未来结合大数据分析和AI，更有可能打造出一个完整的供应链生态。

Blockchain finance platform