开源分布式账本 R3 Corda 技术揭秘：基于 JVM 开发

Corda 使用 Kotlin 作为开发语言，合约可以使用Java、Kotlin或者其他基于JVM的语言来编写。选择Kotlin的原因是：

• 相比其他目前区块链流行的语言，比如C++或Golang，Java系有最强大的生态支持，和成熟的基础设施积累。
• 因为是面向金融行业，应用技术栈也以Java为主（因为主导企业IBM、Oracle等为主），进而使得adoption cost尽可能小，开发更容易。
• 对于金融行业这样有着厚重历史积累（技术包袱），以及各种异构系统，Java（JVM）平台有更成熟和强大的集成能力（比如数据仓库、离线计算等）。

除此之外，相比Java以及JVM平台的其他语言（Clojure、Scala、Ceylon等），Kotlin又平衡了语言灵活性和健壮性（相比Java提供了更多语言层面的改进，比Clojure、Scala又具备更平滑的学习曲线，同时IntelliJ官方对Kotlin的支持更强大）。

共识

• 共识粒度小
• 共识范围小

相比BTC或Ethereum这样的Permissionless网络，Corda提供一个更可信任的Permissioned P2P网络，所有transaction参与这都是authenticated和authorized。

所以Corda的共识机制舍弃了BTC或Ethereum这样的账本范围的全局共识，只要求transaction的所有参与者对于transaction达成共识。

因为舍弃了对账本的全网广播，舍弃了所有节点都需要验证所有的transaction，进而极大得提高了transaction的吞吐。

不像Ethereum的基于account的状态机模型，Corda采用了和BTC类似的基于transaction的UTXO模型，逻辑上完全对应金融系统的复式记账。

• Notary

Corda中引入了Notary的概念，Notary负责确保UTXO模型中的“输入”的有效性，比如防止“double-spent”攻击。它是所有transaction验证和确认（verify和validate）的基础，本质上可以认为是Corda这个“半信任网络”中的“可信任中介”。逻辑上看是“中心化的角色”，但实际上Notary可以是一个网络，甚至可以是另一个基于某种共识的公链。

Command，合约和Flow

• Command

因为面向金融行业，Corda最重要的设计目标是支撑现实世界的各种金融活动（交易行为），所以Corda从transaction的设计，到智能合约以及Flow的能力，都是为了描述自然世界的交易行为/动作，比如转账、存入/提现、开票/兑付等。

所以Corda在transaction中设计了command这个概念，command由transaction参与方来约定（含义），同时通过强制包含所有参与方的公钥来做验证（验证签名）。

为了映射自然世界中各种复杂的多方交易，Corda中引入了“复合公钥”（composite-keys）。其中的公钥以树结构组织：所有的叶子节点就是各个参与方的key，上层节点则约定阈值。

比如下面这个例子中，三人的公钥权重默认都是1，那么整个command有效的条件是：“alice和bob都要签名”或“只要charlie签名”。

• 金融合约

Corda中另一核心特点就是它的合约系统，相比跑在EVM上的Ethereum的智能合约，Corda的合约本质上就是一个实现了Contract interface的Java class。这个接口只有一个用于验证transaction的方法verify和一个annotation。

@CordaSerializable
@LegalProseReference(uri: String)
interface Contract {

    @Throws(IllegalArgumentException::class)
    fun verify(tx: LedgerTransaction)
}

其中@LegalProseReference这个annotation是最有价值的特性，它关联了现实世界中真实的具有法律意义的合约！这样Contract接口的设计就满足了：

1. 描述现实世界的合约。
2. 对所有根据合约执行的transaction进行特定验证。

• Flow

Flow是Corda中另一个重要的特性，本质上来说Flow就是一系列复杂的Command指令的编排，用来描述自然世界里涉及多方、多环节、有条件的复杂交易流程。因为Corda的共识是transaction级别参与方范围的，同时transaction的通信都是点对点的，所以flow的设计和实现非常直观和简单。

因为面向金融行业，Corda内置了大量开箱即用的Flow template（在net.corda.flows包），基本涵盖了金融领域主要交易流程。同时Flow支持组合和继承，方便自定义和编排。

Flow的底层实现是基于Quasar的，是JVM平台上实现了actor模型的纤程/轻线程库（Akka也是，但主要面向Scala）。通过Quasar的bytecode注入，可以实现flow的挂起、恢复等调度，这能进一步提高Corda系统的伸缩能力和并发能力。

数据存储

• JPA
• RDB

Corda的数据存储支持标准JPA规范，可以通过多种ORM库将数据持久化到关系型数据库。目前Corda实现里是内置了一个H2数据库。由于标准的JPA规范，这使得Corda节点可以非常容易得集成/复用金融行业使用广泛（几乎是唯一）的企业级RDB系统，比如DB2或OracleDB。

数据层面这种开放架构，使得企业客户完全能够将Corda的数据和自身业务数据无缝集成。比如通过SQL Join来统一查询，或输入到Hadoop进行离线计算等。

网络通信

• AMQP over TLS

Corda借助ActiveMQ这个流行的消息中间件中的Artemis项目，以AMQP作为其网络通信协议，包括消息结构、序列化格式、加密方式等。

Artemis本身是个高性能、非阻塞的（基于Netty）支持多种协议的（AMQP、MQTT等）轻量级消息中间件。

• NetworkMapCache

P2P网络部分，Corda通过NetworkMapCache使得每个节点都缓存一份网络拓扑，网络的变化会通知到所有节点。节点本身具备动态发现、注册和认证的能力。

目前的实现中，是简单得通过seed nodes的方式来初始化整个网络，代码注释里提到未来会集成Paxos或Raft来选举初始网络。

CorDapp

• Plugin机制
• REST
• Fatjar

类似Hyperledger Fabric，Corda也采用了plugin机制来支持CorDapp。每个CorDapp需要扩展CordaPluginRegistry这个接口来注册自己，并通过REST API来向外提供服务。

CorDapp中的逻辑是通过声明或使用flow来实现的，客观上提高了安全性。CorDapp会打包成Fatjar的形式，上传并部署到Corda节点的JVM中。

系统集成及其他

利用Corda支持的JPA/JDBC，AMQP，REST等等这些数据层面、通信协议以及CorDapp接口，提供了非常开放易于集成的能力。

Corda节点内置一个web app，用来管理节点状态、网络状况和Dapp，比如交易记录等。

架构设计

下图是Corda的逻辑架构

2017年低，Corda和微软Azure达成合作，将Corda平台搬到Azure云上，推广更易使用的“分布式账本技术即服务”。

总结

本质上，Corda并不是去创建新的区块链（公链），而是致力于提供专门服务于泛金融行业“去中心化的ledger（数据库）”。相比其他区块链系统，由于针对金融行业的定位，做了一些方面的取舍和改进：

• （在Permissioned网络环境下）降低了共识的范围和级别
• 缩小了数据可见性
• （所以间接）具备较高的吞吐
• （强化了特定合约描述能力）提供了与自然世界法律/金融的映射

加上JVM强大生态、完善成熟的基础设施、大量开箱即用的工具，以及内置对金融行业领域的支持。

来自：高可用架构