深入浅出Corda(一)概述

此篇文章将主要就 Corda 一些背景和设计原则做简单的介绍和翻译,具体可以参考Corda 相关的技术白皮书:Read the updated intro white paper & Read the technical white paperRead the Corda introduction在线文档。 这里主要涉及我们的应用背景对相关的架构和技术细节做概述, 具体详情后续再分章节阐述。

漂亮点封面

背景概述

关于区块链(Blockchain) 网上有太多的介绍,这里不再详述,简言之:“区块链是各方间交易的共享数据库,旨在提升安全性、透明度和效率”:

区块链是一种全新的数据库技术,在应对一系列独特挑战方面最为有效。数据库过去被用作数据存储中心以支持交易处理及计算。但出于各种技术和安全考虑,数据库信息很少在组织间分享。区块链是各方间交易的共享分布式数据库,旨在提升透明度、安全性和效率。

Corda 官方解释Corda 从开始就是为商业目的设计的区块链项目(背后的R3联盟), Corda 允许你在一个相对私有的环境里进行区块链操作,Corda 的智能合约可以帮助商业机构之间直接进行价值交换(做交易了)。

Corda is an open source blockchain project, designed for business from the start. Only Corda allows you to build interoperable blockchain networks that transact in strict privacy. Corda’s smart contract technology allows businesses to transact directly, with value.

更确切的说Corda 是为金融机构, 特别是银行打造的一个系统, 当然理论在其他行业, 保险业、医疗行业都适用(比较怀疑?区块链在工业界的应用是种“病态”!), 可能这部分也是现在绝大部分的所谓区块链项目的一个弊端, 也就是所谓 带着解决方案找问题(solutions looking for problems); 所以Corda 最开始的定位也是:

Corda is a distributed ledger platform designed and built from the ground up for the recording and automation of legal agreements between identifiable parties. It is heavily influenced by the requirements of the financial industry but we believe the community will find the underlying architecture will lend itself to a broad range of applications.

Corda 专门为金融行业设计

注意:是在可信赖、互相都识别的对方, 参考标的是金融领域的解决方案, 所以Corda 不是一个大而全的通用解决方案, 所以Corda 的设计有别于一般的Bitcoin或者Ethereum, 定位金融解决方案是Corda 首要角色, 金融领域的业务模型,其实通过若干年的积累,特别是焊接不同的行业是非常的复杂, Corda 基于一个大胆的抽象, 也就是把复杂的金融业务抽象成一个合约组成的网络。 比如我们往银行里面存款是一个简单的IOU 合约代表银行欠我们多少钱, 参与一个CDS(Credit Default Swap) 合约, 这个合约里面写着我们各自的义务和权利。 这些信息被保存在各个组织各个系统中, 公司花费大量的财力物力来保持他们一致。

不管在组织内部还是组织之间, 这样的信息校验不仅仅是花费资源, 还会带来比较大业务上的风险, 笔者先前在摩根post-trade office 有很大一部分的人力花费在校验(Reconciliation)双方的交易信息上面, 更有甚者还有使用纸质、或者传真交易协议, 就需要人肉校验,所以有大量的人在做这个非常枯燥的工作,即使是这个样子还是不能保证不出错(参考)。

一个集中的中央第三方可能解决此问题, 比如结算清算领域专门做此服务的 Depository Trust & Clearing Corporation(DTCC) 和 Continuous Linked Settlement Group (CLS);帮助增加组织之间共享信息的完整性和一致性, 但是即使有DTCC这样的机构存在, 在交易得以处理和结算之前,仍然需要用人工在客户、经纪商、DTCC 和信托银行之间进行协调和确认。在整个清算和结算过程中,有许多环节有待改进:

  1. 交易存在多个版本。当多方参与一项交易时,在各方使用的不同系统间可能存在多个版本的交易记录。这引发了不确定性,当参与方对交易细节存在异议时,可能需要人工方式干预。
  2. 结算过程耗时较长。虽然美国股票交易可以在瞬息间完成,但是结算过程可能需要三天(到
    2017 年有望改善至两天),这造成了资本金和流动性的占用。
  3. 账户信息/指令经常变化。账户信息和结算指令会随着时间推移而发生变化,例如账户新开或
    关闭、账户数量调整、托管调整等,这带来了信息陈旧的问题(特别是对于标准结算指令而
    言),进而需要增加沟通和人工干预。
  4. 操作风险。企业在交易结算过程中面临额外的操作风险,而通过区块链技术进行的交易前检查可以化解这一问题。

不仅仅整个系统效率不高, 而且花费不菲,仅仅在美股股票这一块(来自高盛全球投资研究):

我们估算,2015 年美国股票交易的年佣金收入约为110 亿美元,全球整体股票交易收入池约470亿美元。采用业内常见的20%的税前利润率,这意味着美国股票交易业务的费用支出约为88 亿美元。采用业内35%的平均薪酬收入比,则我们估算整体薪酬支出约为40 亿美元。剩余的费用支出包括约10 亿美元的IT/技术相关支出(我们采用IDC 的2015 年整体银行业IT 支出数据并估算占比为5%)以及约40 亿美元的销售及管理费用/其它支出

对于其他更庞大的OTC产品,相信这部分的花费更多, 所以对于一个区块链的基本功能需求:安全、透明、高效的分享信息。

DLT

Corda 模块

Corda 区别于其他一般区块链的解决方案, 所以一般意义可以称他为DLT(Distributed Ledger Technology); 所以里面没有代币机制, 也就是不能ICO(理论)了, 一个最简单的共识机制(Notary下面介绍),利用现有的被证实的技术和架构: 比如语言是最普遍的JVM 上语言Koltin, 加密是基础的PKIX, 消息通讯是Apache ActiveMQ 下的 Artemis等, 所以可以尽可能多的使用现有的组织资产,特别是现有的金融公司技术堆栈,代入可以说比较平滑。

点对点

点对点通讯

P2P 通讯基本是所有分布式网络最基础的设置, 这里技术上乏陈可述, 这里点对点更是业务上, 无需一个中央的基本比如DTCC, 保证只有交易关系方(可能多余两个)之间直接进行通讯。应用成熟的加密技术(PKIX), 使用分布式账本, 和智能合约; 不需要一个中央的route 角色几个参与这个流程。

分布式账本

账本是交易双方交易过程中所有信息、关联合约、transaction、状态等在信息系统的记录, 这些信息在Corda 节点的 Vault 中保存(对于数据库一个表), 这些信息作为本地的一个存根,具体每个节点以何种介质存储,看具体的实现。同时所有的transaction 历史记录也都保存在本地, 以方便以后校验、证明等。

智能合约

智能合约里面封装了关于一个transaction 处理的所有业务逻辑。 主要是整对一个交易里面涉及的所有信息进行校验, 比如input/output 交易双方,交易的内容; Contract 是以一个原子方式进行的, 保证像 DVP(Delivery-versus-payment) 能够正确的执行, 这个也是Corda Distributed Applications。

共识Consensus

共识算法

不管是POW/POS/POW/DPOS 等等方式在Corda 限定的业务场景都不太合适, 一个是效率上面, 一个transaction 多长时间被确认, 另外一个是对最终结果的界定, 因为大部分金融业务需要强事务。 无论是比特币还是以太坊都是基于在对方不确认的基础上, 而Corda 是基于信任的对方也就是你知道对手是谁,所以更更简单的共识解决方案。

Notary

Corda 网络中Notary(或有多个), 担任其共识服务的角色, Notary 保证交易的唯一性, 比如一个Input 是否多次消费, 但是目前Notary 简单Validating 模式下这个保证比较弱, 需要交易在同一个Notary 上面, 换Notary 需要额外的步骤同步Notary 上面的信息。 还有其他的算法保证一致性, BFT-SMaRT, Raft等。

隐私

  1. 点点通讯通过SSL
  2. 随机Key 生成 rotation, 管理匿名交易 Refer
  3. Merkle 树 mask 不必要的信息
  4. 借助Intel Software Guard Extensions (SGX)--更强加密防护

业务场景

这里根据 The Corda Way of Thinking, 简单通俗易懂的解释 Corda 里面各种模块的关系和角色, 这里简单的解释下, 对后续理解会有一定帮助。

DLT 需要解决什么?
在和不同人之间进行交易合作中, 我们希望协议、合同、互相关系等能够很好归档,理解清晰,记录一致。

DLT 保有我们各自的信息, 同时当这些记录被合法的改变后能精确的保持彼此同步!

然后想象在一个只有纸张、复印机、和邮局的世界里面如何实现一个DLT.

首先让我们想象,我(Richard) 有一个文件柜里面有很多表格,每个表格都题写了一些我需要和至少一个其他人共享的信息, 可能是一个贷款,或者交易信息,其他任何可以记录的信息。

你有一个装满表格的文件柜, 每个人都有一个自己的柜子, 每个表格都被标上数字以便识别。

如果两个人之间分享信息, 那么每个人的文件柜里都有个相同数字标志的表格, 里面有一模一样的信息。

Richard 和 Albert 共有记录 #128, Albert和Harrison 共有 #140 他们都有 #132

每个人的文件夹只包含和自己相关的信息, 比如上面的Harrison 没有记录#128, #128 是Richard 和Albert 之间的交易, 和Harrison 没有关系。现在的世界(很简单):

  1. 我有一个满是标志好的表格的文件柜
  2. 每个人都有一个存储标志好的表格的文件柜
  3. 每个表格表示一个合约、协议、交易或者任何其他信息
  4. 共享的表格,共享方各自有一个一模一样的拷贝

记录 #128. 这个是我 (Richard) 和 Albert 共同享有的记录:

#128 文件详情

是一个关于Richard 和 Albert 之间的打赌, 
如果星期四下雨, Albert 欠 Richard $10,  
反之 Richard 欠 Albert $10

证明:
当天的报纸

是不是很简单, 当然现实的应用场景比这个复杂, 会有更多的协议细则,和更多的参与方。

所以现在双发都达成了共识,都有一个这个协议的完整的拷贝(如何共识后续讲), 后续就是等周四下不下雨了。

每人一份拷贝

时光飞逝,如白驹过隙,一晃周四过了, 是时候兑现对赌的时候了,昨天(这个时候周五了)到底是下雨了还是没有下,我们需要对此事实达成共识,这个决定谁欠谁$10, 而且我们需要更新我们的记录, 以准确完整的记录当时的情况。

WOO 我(Richard)赢了,不是我自己说的, 有今天的华尔街日报作证,因为协议上面明确规定需要赢家提供证明。

报纸证明

下一步,就需要更新我们的表格, 以记录既定的事实,也就是对赌的结果,外界的证明条件(报纸)等信息---这个报纸是个核心的信息,让双方对结果达成共识。

现在需要根据我们达成一致的对赌协议进行下一步, 既然是下雨天, 我需要对方知道这个现实,而且欠我的钱。

自然而然的我们可能想到, 在原来的协议上面再加上一行内容,但是不,我们拿一张崭新的表格, 来替代以前的老表格。

这个是因为在复杂的交易中, 会有大量的时间和更新时间, 如果我们不停的修改以前的表格, 可能导致信息非常混论,无法区分修改的历史记录(参考Event source 设计手法)。

反正无所谓,纸张也便宜,所以重新题写一份新的表格不会太费力。

所以我要做的,就是用一个新的表格题写所有关于那个对赌的更新信息, 这里我们的难点是,需要保证新的更新信息更新到所有这笔对赌的关系人哪里, 这里是我和Alert, 可能还有其他人,比如监管部门, 或者一个会计师哪里。

更新记录

我已经知道周四是下雨的,所以我赢得了比赛, 我需要将我们共享的记录#128, 更新为最新的 #156 记录, 哪里包含了最新的信息:


Richard 和 Albert 打赌周四会下雨
周四确实下了, 由附件的报纸证明
所以Alert 欠Richard钱 $10
这个记录用来替换原来记录  #128

首先, 我自己会从我自己的文件夹里面拿出 #128 号记录, 然后打个大大的红X, 标志这个文件可以备份处理, 然后我写了封信给Albert。信里我说:

“
Hello Albert!  
我是Richard !
记得我们的打赌?你可以在你文件柜里发现他, 也就是 #128 号文件。
也许你知道这个打赌关于昨天(星期四)伦敦的天气,知道吗,昨天伦敦下雨了!
随件我附上了当天的报纸哦,
不好意思老兄,你欠我$10, 
同时我也打印了一份新的表单,
里面记录我们对赌的详情和结果,和证明, 确实下雨了,你欠我$10的事实。
我想你应该遵守我们既定的对赌规则协议: 也就是你必须把你的老的 #128 文件更新为我附上的最新记录 #156
我已经替换完了,至于 $10 周一上班请我吃饭吧!
拜拜 
Richard  签署”

我需要快递个包裹给Albert包括

  1. 一封信
  2. 一张报纸
  3. 最新的记录
整个要快递包裹内容

在同城快递下,很快下午Albert 收到了这个包裹, 他打开了包裹:

  1. 打开它的文件夹,找到了#128 文件
  2. 比对了#128 号文件和 #156 文件的记录
  3. 确认更新是遵守Rule book
  4. 在#128 文件上画了大大的红叉,等待备份
  5. 把#156 文件放到他的文件柜下
替换文件

最终我和Albert 都在我们的文件夹保存了一份一致的文件,由于我们先前已经协商好一致的rule book, 同时我也提供了当日的报纸作为证据, 所以这个协议能够没有争议的执行。这个导致我们可以步调一致的执行文件更新, 和后续的协议Albert用$10请我吃饭。

这里我们仅仅使用一个快递包裹解决了这个事情, 但是现实可能很复杂, Alert 可能需要咨询其他的人比如他的律师, 第三方公证,才能确认用新的文件去替代以前的文件。 这些就是corda 帮我们做的。

上面我们接触到的概念可以一一对应到corda 的相关模块上:

文件表格 vs State

文件柜里面的每个文件表格

State 可以代表任何的信息, 交易、合约、合同、资产负债表、IOU、贷款

文件柜 vs Vault

文件柜

保存最新文件,表格, 或者最新的合约交易IOU 等信息。

包裹 vs Transaction

包裹

想象那封发送给相关第三方邮件, 用来提醒其他干系人: 用最新附上的文件替换老的的文件, 和更新需要遵循我们先前统一的规则。

邮局 vs P2P 网络

提供快递服务把包裹在不同节点之间传输。

RuleBook vs Contract

想象成, 你在接收到一个邮件, 让你删除(失效)先前每个文档, 用一个全新的文档来替代;你需要检查的规则, 这波操作是否合规? 是否符合我们先前的约定? 这也是Corda 达成共识的基础架构。

上面的这个例子就是一个最简单的DLT 解决方案, 最大限度的保证了完整性,私密性,和性能, 但是在正在corda 的世界里面可能有更多的问题。

类比

延伸?

分布式数据库,分布式账本(DLT)? Log, Event Source 和其他, 这些东西多多少少有些许关联, 不管什么样的IT 系统,其实都是关于数据的处理: 生产、传输、存储;

现有大部分IT 系统大家对数据库、分布式数据库都有比较直观的认识, 在解决数据高可用性和一致性也有成熟的解决方案。一个分布式数据库和分布式账本有何区分 Corda 里面有 探讨, 下面两个图简单解释,具体请阅读原文:

分布式数据库
分布式账本

“Distributed ledgers – or decentralised databases – are systems that enable parties who don’t fully trust each other to form and maintain consensus about the existence, status and evolution of a set of shared facts”

To repeat, because this distinction is utterly fundamental: nodes of a distributed database trust each other and collaborate with each other to present a consistent, secure face to the rest of the world. By contrast, Corda nodes can not trust each other and so must independently verify data they receive from each other and only share data they are happy to be broadly shared.

关于这点在他的 技术白皮书 有更多探讨和解释。

由于探讨分布式数据库, 必然又想到 Log 和 Event source 的设计(参考笔者以前的文章)。关于Log The Log: What every software engineer should know about real-time data's unifying abstraction 值得一读。

不管数据库replicate 方式, 或者我们现有系统采用DDD Event source 设计方案, 在对于系统核心数据事件流的处理, 都有很多类似相同的地方。 只不过换了另外一种说法, 加了些许其他调料,结果适用一个不一样的场景, 真的是蛮有意思的!

后续的章节会具体分析每个corda 里面技术实现要点和在我们业务场景中的应, 不定期更新。

参考

  1. Corda: An Introduction
  2. Read the technical white paper
  3. Read the updated intro white paper
  4. On distributed databases and distributed ledgers
  5. The Log: What every software engineer should know about real-time data's unifying abstraction
  6. I Heart Logs Event Data, Stream Processing, and Data Integration Or Buy
  7. The Corda Way of Thinking
  8. 区块链在工业界的应用是种“病态”!
  9. Blockchain The new technology of trust
  10. R3 Corda: What Makes It Different
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,080评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,422评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,630评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,554评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,662评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,856评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,014评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,752评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,212评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,541评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,687评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,347评论 4 331
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,973评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,777评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,006评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,406评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,576评论 2 349

推荐阅读更多精彩内容