长话短说，我们在建链。

区块链是什么

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

不论是分布式账本，还是信任机器，其底层的特性——不可篡改、透明、可追溯以及去中心化，最终导向的目的都只有一个，那就是信任。

区块链的可信度来自于人类对数学逻辑严密性的信任，数学理论和加密学实践可以确保链上数据和所有权的可靠程度。区块的确认基于共识算法、不可变的数据结构，再通过 Merkle Tree、Hash Pointer（哈希指针） 保证前向区块链的完整性，再加上经济、人心的博弈、理性经济人假设，共同构成一套完整的信任系统。

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

区块链的行业应用

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

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

总体来说，几乎各种产业场景都能应用区块链技术，因为这些场景里都有提升效率，降低成本，优化征信体系的诉求。

汽车金融区块链应用

汽车金融

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

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

汽车的生命周期和金融公司的参与环节：

它们的业务模式长这样：

通过分析现有业内的业务模式，我们发现：

财务对账成本高昂，且效率不高。这里的财务成本并非某家公司的财务成本，而是整个系统内的财务总成本。仅在中国区可能就有多家销售公司和金融公司，以及几百家经销商，即使每家公司只有两名财务和审计人员，那么财务审计人员都超过一千，更别提全球销售范围内了。

传统的对账方式是怎样的呢？

不同类型的机构进行在对账时，往往要从信息系统中导出电子表格，并用邮件发送。甚至需要打印表格、盖章后邮寄，对方收到后再与系统数据进行比对。

整个业务流程并不复杂，但是消耗了很多人力物力，且中心化的服务还由于对授权机制（多主体之间不太信任或者叫做弱信任）和信息安全等方面的考虑，而导致建设成本高昂，且制约了业务运行效率和用户体验的提升。区块链作为分布式账本，意味着任何机构之间互相发生债务往来的信息都是数据一致的，那么就可以近实时地进行对账。

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

怎么建链

我们把这次建链过程大体总结为5个步骤：识别上链数据，智能合约设计，API设计，部署单元和网络拓扑架构。

• 识别上链数据指的是识别将哪些交易记在链上；
• 智能合约设计，指的是买卖车及其相关金融活动如何通过可编程的方式自动完成；
• API设计，考虑如何对外暴露平台能力，同时限制控制主体；
• 部署单元和网络部署架构属于实施范围，旨在解答分布式账本如何真正运行在企业当中。

整体技术架构是基于Corda这个分布式账本技术展开的，Corda准确来说不是区块链，而是一种受区块链启发的DLT，即分布式账本技术，它是由金融区块链联盟R3开发和维护的。

上链数据识别

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

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

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

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

智能合约设计

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

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

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

API设计

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

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

部署单元

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

网络拓扑

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

回顾

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

推荐阅读

• 麦肯锡报告翻译：《超越狂欢：区块链的商业战略价值是什么？》
• 技术简史的思考

更多精彩洞见，请关注微信公众号思特沃克

着相是佛家用语，指的是执着于外相偏离了本质。

仙剑奇侠传中有一个故事。讲的是一个成精了的佛珠。想要让更多的人向佛，于是施法，让这些人失去了记忆，只想一心礼佛。使人向佛，本来是好事，但强人所难，脱离了本质，便是着了相，也可以说反而是入了魔。

这个小故事告诉我们，在认知的世界里，我们很容易被表象所欺骗，忽略了本质。为此，佛家发明了这么一个名词来专门指出这种现象。

复用也是一样。复用本来是通过消除重复的方式。得到一系列可以复用的组件。从而在未来的开发工作中，更快速的响应需求变化，也就是所谓的提升响应力。

然而很多复用的结果，会造成代码是变少了，改起来却更难了。复用是增加了，可读性却下降了。考虑到软件开发是一个团队协作的工作，而我们这个行业的离职率又能到百分之二十之多。难以学习的代码确实是难以维护的，尽管你可以抱怨接手的人无能，但总之是降低了响应力，也就违背了复用的本质。

什么情况下会出现这样的场景呢？主要是因为视角的单一，只从自己单一的视角看到了重复而不是在做全局优化。这个说法可能稍微有些抽象，那我说几个相对具体的情况。

当我们只关注功能视角的时候

需求有很多的描述视角，可以只在功能角度描述，比如“网站要有任务卡，任务卡上有文字版学习内容，视频讲解、也有作业题。”也可以加入业务视角，比如“学生要报名特训营，才能参加特训营。学生进入特训营后，就看到了任务卡列表。学生在任务卡上阅读学习资料，阅读完学习资料后做题来验证他是否学到，做完后提交交由助教审阅。”当我们只看功能视角的时候，可能会忽视业务上的不同，变的在功能角度过分抽象，最后当业务变化的时候，反而响应速度比较弱。

一个简单的后台，我们看起来所有东西长得都一样，不过是列表页面，添加页面修改页面，再加点儿删除什么的功能。说穿了都是crud，干脆我把这事弄成一一个组件好了，每个页面只需要简单配置一下，就可以出来自己的一套增删改查页面。

这种视角完全没有考虑到，不同的实体，它们其实所在的业务是不一样的，关心它们的人也是不一样的。最后，彼此的演化方向也总会出现一些不同，你把它定义成一种东西，对于我每做一个修改，都要背负着其他所有实体的特异性。于是就逐渐拖慢了我改变的速度，降低了响应能力。

无谓的自动化

有追求的程序员一定会考虑提升工作效率，通过一些自动化的手段来缩短流程，提高效率。不过有时候，这种追求也会有害。

在我们的系统里有一个面包屑功能，就是典型的“页面A / 页面B / 页面C”那种面包屑。团队成员提出，一个个页面写面包屑好烦啊，干脆做一个根据URL生成面包屑的功能吧。乍一看好像提高了效率，但实际上URL上的名词和你想显示在面包屑上的名字是可能出现不同的。

比如在我们的场景里，我们提供一个任务卡的预览功能，你的面包屑可能是“xx后台 / xx 训练营管理界面 / xx卡预览”，而学生正式使用任务卡的时候，他可能是 “ 学习中心 / xx 训练营 / xx卡 ”。而他们的url里可能都会出现’/programs/$pid/tasks/$tid’。同样的program、task翻译出来的文字完全不同。你为了支持这点不同，又要扩展一些额外功能来做这种区分，做来做去，可能还不如直接写来的方便，至多抽几个常量来简单的消除一下重复。

当我们只从代码上看重复性的时候

这个我就不举例子了，其实很多犯这个错误的人都是重构的支持者，不过学艺不太精。因为如果你仔细看的话，重构里好多怀味道都有一个跟他对立的怀味道，比如发散式变化和霰弹式修改。如果我们只看代码就会违背复用的本质——更好的响应变化。

这个跟我说的第一个场景，只关注功能视角是类似的问题，这个可能更具象一点，只关注代码。

无视上下文的时候

这个可以看作是只有功能视角的一种情况，很多功能我们觉得有重复性，提升成一个概念，然而其实根本是两个东西，他们只是刚好叫一个名字。

比如过去很多软件里，是有一个统一的用户组概念，不管你在哪个业务上下文里，你都需要扩展这个用户组的概念来管理用户的权限。这个带来的结果就是用户组变得越来越臃肿，每次修改都要改一下别的组的功能。在我们的网校数字平台里，学生学习有学习小组，老师出题有出题小组，这两个小组业务完全不一样，这个时候如果都用统一的用户组来管理的话，那就势必会造成无谓的耦合，损害响应力。

这些故事告诉我们，我们不是在真空里去做复用。我们做的软件都是有它的商业目的。我们的工程实践也都是为商业目的服务的。当我们说tech@core的时候，让我们说技术就是业务的时候。诚然，他给技术人员带来了更多的权利，然而权利越大，责任也越大。技术人员也需要跳出技术，具备更多的业务视角和体验视角。而不仅仅是沉浸在技术得自high当中。才能真正的发挥出各种实践的价值。

更多精彩洞见，请关注微信公众号：思特沃克