无链之链：R3 Corda带来的新视角（三）：网络结构简述、应用开发 CorDapp

作者简介：
王玮
“中关村20周年突出贡献奖”获得者，北京微志科技有限公司创始人。主持过世界上最大的基于开放平台和分布式技术的银行账务系统的设计与开发，曾任国家“核高基”国产化中间件应用示范项目副组长等。目前从事区块链技术在金融等领域应用的研究、开发和推广工作。

责编：景琦，欢迎关于区块链领域的技术投稿、约稿、给文章纠错，请发送邮件至jingqi@csdn.net

本文将重点介绍下R3 Corda在网络结构简述、应用开发方面的相关内容。

网络结构简述

正如开头提到过的，Corda的实现与运行体系带有鲜明的Java生态环境的特点——最典型的就是一些（相对成熟的）开源框架与组件的组合。具体体现为：Corda网络通讯基于activemq的一个子项目artemis；节点的存储则直接支持通过JPA将交易等数据结构存储到数据库中；节点的管理直接自带了一个Web应用。这些特性使得Corda在企业中的运用变得相对简单，是Corda的主要优势之一。

网络通讯

P2P网络的节点功能当中，通讯机制是很重要的组成部分，准确地说主要包括两部分，一个是通讯本身的功能，如通讯协议、消息结构、序列化等；另一部分可以称为P2P协议，涉及节点发现、加入与退出，离线时的机制等。

首先说网络通讯本身，Corda的通讯协议基于AMQP/1.0，采用TLS作为加密协议。Corda目前的（参考）实现简单而清晰——内嵌了Artemis，这是Apache ActiveMQ的一个子项目，是一个支持AMQP/1.0（也支持JMS）的全功能的消息中间件，并且适合于嵌入式应用。通过这个手段，通讯本身的功能都得到了覆盖，既包括基本的网络通讯协议的支持（Artemis的通讯功能基于Netty）、消息格式解析，又包括消息持久化（提升可靠性）、队列管理（简化内部消息处理流程）等高级特性。从这个实现就可以看出基于Java生态环境的解决方案带来的好处：能够在短时间内解决重要的基础设施需求。

说到P2P协议部分，Corda采用了很简单的NetworkMapCache服务的概念，字面上理解起来比较容易，就是每个节点包含一个整个网络Map的缓存。这个缓存自然是分布式维护的，网络变动会通知到各个节点，更新Map，每个节点也都对外提供发现、注册等服务，并且要求一定的身份验证。具体到实现模式，文档中并没有详细说明，从代码当中也看不到对于某一种P2P网络库的引用和自动发现功能的实现。同时，代码注释中提到，未来希望采用Raft/Paxos模式的选举方式实现网络初始Map的产生，因此目前的Corda应该在启动阶段采用简单的初始/种子节点的方式，这也是正常的模式。

总体而言，Corda的网络通讯层面的功能，还是直接利用了现有Java生态环境中的成熟组件，实现了较为快速的开发，同时拥有了完备的基本能力。

数据存储

Corda数据存储方面的架构可真是Java程序员的福音——支持通过ORM的方式，将交易数据存储到标准（关系型）数据库中，并且是通过标准JPA接口。具体实现方面，Corda节点内置一个H2数据库，同时允许通过配置JDBC连接到任何标准数据库上。

从底层架构的角度看，Corda基本就是为了方便企业应用，完全开放了底层数据结构。一个金融机构完全可以通过把Corda的数据和自身业务数据放在一个数据库里的方式，实现数据层面的直接打通——通过SQL JOIN的方式对两部分数据进行统一查询。Corda的技术白皮书中对这种数据整合方式也是完全支持和鼓励的，明显是作为系统设计的一个目标，这与Corda的总体目标确实是一致的，也说明Corda的设计者们对于企业在采纳一个新的系统时所关注的应用整合场景非常了解。

例如：Corda当中的“钱包”称为Vault（保险箱），就是存储了所有交易的实际资产信息的地方。如上所述，保险箱作为节点的一部分，也是完全基于这个JPA机制实现数据存储的。这样做的好处就是上面所说的，企业完全可以在数据层面将内部信息系统与Corda的保险箱打通，通过各种成熟的SQL查询模式，来实现应用整合，提升整个业务流程的开发效率，降低数据转移、核对等成本。当然，笔者建议这样做的时候一定要注意安全性、可靠性，否则一旦出现破坏Corda节点的数据库，恢复难度肯定比一般数据库要大得多。

节点管理

Corda的节点自带一个Node Explorer，这是一个Web应用，主要完成两类功能：

节点管理，包括查看当前节点状态的dashboard，能够查看与配置节点的基本参数，以及可以浏览全局网络的基本状况等。

应用管理，包括查看当前交易的记录，尤其是包含了现金这种内置交易的部分功能，能够查看所有现金交易的情况，以及真正发起一个最基本的现金交易，如图所示。

由此可见，Corda的节点内置了很多应用层面的功能，既方便使用者开箱即用，又可以作为应用开发的例子，供使用者进行学习和在此基础上扩充。笔者认为这也是Java生态环境的优势之一，毕竟底层系统也运行在JVM上，使得上层应用的开发和部署成本都有所降低。

网络节点小结

综合上面三个主要特性，基本上可以认为一个Corda节点就是一个标准的Java企业应用，存储、通讯、管理三个核心维度都是满足企业对于一个典型的Java应用的期待。对于金融机构、企业而言，采用Corda实现业务目标的阻力相对而言要小得多，使用过程中与自身的业务整合可以说毫无压力，从这个角度讲Corda的节点设计是完全能够支撑其市场目标的。

应用开发 —— CorDapp

去中心化应用（decentralized app，缩写为Dapp）的概念，应该是以太坊最早提出的。Corda特意将系统的应用写成“CorDapp”，可见是在呼应这个概念。很显然，CorDapp作为运行在去中心化数据库上的应用，当然可以称得上去中心化应用。

CorDapp是一个plugin形态的应用，通过实现CordaPluginRegistry抽象类，给出自己调用的flow（显然这是安全机制的考虑）、对外提供的API（rest形态）、标准Web接口等，最终形成一个jar，运行在corda的节点上。前面在讲flow的时候已经提到过，本质上corda的应用才对应着以太坊和HyperLedger的“智能合约”，从运行机制上看，大家本质上也都是plugin形态，并没有太大差别。

Corda为应用开发提供了一个模板：cordapp-template，这是一个独立的工程，可以用来作为开发一个新App的样板。如果要了解更多的App功能，还是应该自己去运行并学习corda工程中的samples里面所带的例子。尤其是用IDEA去开发corda时，各个例子可以直接在IDE中快速启动，便于开发者快速了解一下corda应用的运行结果。

由于Corda的文档也一再强调应用开发层面的机制还在快速变化当中，因此本文仅就其基本的插件模型作出上述介绍，其他详细内容读者可以在开发过程中跟踪最新的代码和手册。

总结

应有一席之地

结合上述对比、背景介绍和本文所述的内容，笔者认为可以得出一些结论。首先，Corda的根本目标是一个“去中心化数据库”，这既是他与其他区块链/类区块链系统最直接的关系，又是与所有“真正的”区块链系统最大的区别。其次，Corda的设计与实现，是在参考了成熟的区块链系统的一些标准概念和做法的同时，结合自身的目标定位做出了相应的取舍、改进和创新。第三，Corda所实现的新型的去中心化数据库，基本达到了其所宣称的三个主要目标：

1. 信息适度可见
2. 较高的系统性能
3. 与现实世界的连接

除此之外，Corda对于在企业内的开发、部署和管理考虑的比较周全，因此我们相信其足以成为类区块链系统在企业应用领域占有一席之地的基础平台。

理想很丰满，现实很骨感

客观地说，Corda也存在一些问题，主要有两个方面：

第一是过度考虑现实世界需求的倾向——Corda当中模拟现实世界多重角色、体系结构中各种与现实世界的接口，有时候甚至让人产生一种“根据很多客户提出需求进行设计”的感觉。这种设计理念往往是“成也萧何，败也萧何”，可能会因为外部环境的变化而失去生命力，开发过程中也容易纠结于无法统一各种复杂情况而陷入停滞，优劣参半。

另一方面的问题是：相对于其宏伟的蓝图，Corda很多具体实现的细节层面还略显初级——“理想很丰满，现实很骨感”。当然，我们了解，除了以太坊之外，其他的类区块链系统的实现也都还处于非常初级的阶段，并不一定比Corda更完善。但是，由于Corda在去中心化数据库的核心理念——共识机制方面的“创新”，使得其这方面的实现必然更加为人们所关注。遗憾的是，笔者认为这方面的设计和实现，Corda还都有未解决的问题，不得不说在创新之路上任重而道远。

最后，笔者认为，一个好的类区块链/去中心化数据库系统，应该适度设计，具有一定的简单性：最主要的是将P2P网络、交易签名验证、拜占庭容错与补偿等核心机制进行整合，形成一个边界清晰的系统。在此基础上，如果特别关心性能、信息适度可见等特性，则可以引入Corda或者其他系统在这方面的设计理念进行扩充。重要的是，将上述特性在系统内部给出完善的实现（如果允许可插拔的实现机制，要有精确的接口和操作流程定义），并对外提供简单清晰的API。通过这样的方式，将可以构建出新一代面向价值转移的互联网基础设施，将分布式计算的能力发挥到一个新的层次。