掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务

新一代开源分布式账本项目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强大生态、完善成熟的基础设施、大量开箱即用的工具,以及内置对金融行业领域的支持。

230-640.jpg.jpg

原文来自:高可用架构

声明:所有来源为“聚合数据”的内容信息,未经本网许可,不得转载!如对内容有异议或投诉,请与我们联系。邮箱:marketing@think-land.com

0512-88869195
数 据 驱 动 未 来
Data Drives The Future