语言
Corda 使用 Kotlin 作为开发语言, 合约可以使用 JavaKotlin 或者其他基于 JVM 的语言来编写选择 Kotlin 的原因是:
相比其他目前区块链流行的语言, 比如 C++ 或 Golang,Java 系有最强大的生态支持, 和成熟的基础设施积累
因为是面向金融行业, 应用技术栈也以 Java 为主(因为主导企业 IBMOracle 等为主), 进而使得 adoption cost 尽可能小, 开发更容易
对于金融行业这样有着厚重历史积累 (技术包袱), 以及各种异构系统, Java(JVM) 平台有更成熟和强大的集成能力(比如数据仓库离线计算等)
除此之外, 相比 Java 以及 JVM 平台的其他语言(ClojureScalaCeylon 等),Kotlin 又平衡了语言灵活性和健壮性(相比 Java 提供了更多语言层面的改进, 比 ClojureScala 又具备更平滑的学习曲线, 同时 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 接口的设计就满足了:
描述现实世界的合约
对所有根据合约执行的 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) 支持多种协议的 (AMQPMQTT 等) 轻量级消息中间件
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 强大生态完善成熟的基础设施大量开箱即用的工具, 以及内置对金融行业领域的支持
来源: https://sdk.cn/news/8141