长话短说,我们在建链。
关于区块链是什么,网络上的解释多如牛毛。这里,我从通常需求的角度总结一下:在记录保存(身份存证)时,它是分布式账本(分布式数据库);在交易或支付(跨境支付)时,它是信任机器。虽然这两种分类方法并不正交,但是对于理解区块链的应用领域有很大的好处。
不论是分布式账本,还是信任机器,其底层的特性——不可篡改、透明、可追溯以及去中心化,最终导向的目的都只有一个,那就是信任。
区块链的可信度来自于人类对数学逻辑严密性的信任,数学理论和加密学实践可以确保链上数据和所有权的可靠程度。区块的确认基于共识算法、不可变的数据结构,再通过 Merkle Tree、Hash Pointer(哈希指针) 保证前向区块链的完整性,再加上经济、人心的博弈、理性经济人假设,共同构成一套完整的信任系统。
然而,企业间的联盟区块链有一些不同,它的信任更多地依赖于发起者品牌的背书。在这样的大环境下,联盟链的设计就变得相当灵活,比如最先腰斩的就是代币。
在工信部最新发表的《2018 年中国区块链产业白皮书》中,区块链产业生态分成了产业应用(包含金融和实体领域),基础设施和平台(如公有链和BaaS),行业服务(如媒体)。而我们的关注点集中在产业应用当中。
金融领域由于本身数字化程度比较高,在证券化以及ABS交易所等方向都有落地案例。在实体产业当中,供应链溯源,身份存证等也多有应用。再加上区块链本身具有“信任穿透”的神奇功效,对于构建供应链金融征信体系,改善小微企业的融资困境也很有帮助。
总体来说,几乎各种产业场景都能应用区块链技术,因为这些场景里都有提升效率,降低成本,优化征信体系的诉求。
汽车金融中的核心资产是汽车。汽车金融始终围绕车的生命周期发生金融活动。从零配件的生产,到主机厂制造整车,然后通过各个区域的销售公司将整车卖给各区域内的经销商。实际上在中国,经销商还可以分为不同层级的二三级经销商,最后才到顾客手中。而一旦新车完成销售,就迈入了后市场的广阔天地,以及二手车、三手车的再销售。
从汽车零配件的生产运输和组装到车卖给经销商,这些环节所涉及到的金融活动叫做供应链金融,而顾客通过金融活动来买车,不管是新车还是二手车,都属于消费金融的范畴。
汽车的生命周期和金融公司的参与环节:
它们的业务模式长这样:
通过分析现有业内的业务模式,我们发现:
财务对账成本高昂,且效率不高。这里的财务成本并非某家公司的财务成本,而是整个系统内的财务总成本。仅在中国区可能就有多家销售公司和金融公司,以及几百家经销商,即使每家公司只有两名财务和审计人员,那么财务审计人员都超过一千,更别提全球销售范围内了。
传统的对账方式是怎样的呢?
不同类型的机构进行在对账时,往往要从信息系统中导出电子表格,并用邮件发送。甚至需要打印表格、盖章后邮寄,对方收到后再与系统数据进行比对。
整个业务流程并不复杂,但是消耗了很多人力物力,且中心化的服务还由于对授权机制(多主体之间不太信任或者叫做弱信任)和信息安全等方面的考虑,而导致建设成本高昂,且制约了业务运行效率和用户体验的提升。区块链作为分布式账本,意味着任何机构之间互相发生债务往来的信息都是数据一致的,那么就可以近实时地进行对账。
而我们区块链要做的事情,一言以蔽之,汽车资产上链以及围绕汽车所发生的金融活动而产生的债务的记录。所以不难发现,分布式账本和信任机器在这个场景下都有涉及。
我们把这次建链过程大体总结为5个步骤:识别上链数据,智能合约设计,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的理念。
有了智能合约之后,我们就得考虑如何暴露平台的合约能力了。换句话说,从消费者的角度,我们该怎么利用平台提供的能力完成自己的业务。所以这里我们利用了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,更有可能打造出一个完整的供应链生态。
推荐阅读
文/ThoughtWorks鄢倩 赵正阳
更多精彩洞见,请关注微信公众号思特沃克