Corda需要共识机制吗?(二)

2. 为什么要共识

理解了notary的交易确认机制,会不会产生一个感觉:挺完美的嘛——半信任中介方式,加上各种规则的严防死守,感觉把双花攻击都杜绝了啊,还需要共识机制吗?在给出这个问题的答案之前,我们先兜个圈子,介绍一些更基本的概念,不仅对后续讨论Corda的共识机制有帮助,也有利于更深入地理解去中心化数据库的一些关键概念。

只许州官放火,不许百姓点灯

首先我们探讨notary模式下节点间的信任关系:notary是两个交易者之间的第三方,这是与交易者不同的一种角色,因此Corda系统节点间的信任关系相对于比特币的节点间关系要复杂得多,无法做到全都是相互不信任的对等节点那么简单的模型。(当然,比特币其实也会有全功能节点和SPV的关系,但性质上跟notary和交易节点的关系还是有本质差别的)。我们可以用一张图来表示Corda系统中节点间信任关系的模型(暂时排除了Oracle等其他角色的节点,因为对共识这个主题不产生实质性影响):

notary.png

我们逐个看一下不同角色之间的几种信任关系:

  • 黑色连线的“互不信任”,是所有交易系统的固有特征,也是区块链/类区块链系统要解决的问题,这方面Corda与其他类型的系统没有区别
  • 红色连线的“信任”,是基于notary的机制“强加”给我们的,是Corda区别于普通区块链的根本特点。当然, 这种信任也不是无条件的,各种密码学手段、联盟机制也会有所控制。不过,毕竟这成为了Corda模式的前提之一,因此对这种信任关系的讨论超出了本文的范围,只能作为讨论的前提
  • 蓝色连线的“不信任”,则是本文第一部分所讨论并解决的问题,也就是通过notary机制来防止双花,从而使得“互不信任”的交易双方通过notary可以进行交易
  • 最后剩下的就是notary之间的黄色连线:这种“互不信任”的关系,也就是R3一直强调的,notary可以是一些mutually distrusting的节点,这应该也是现实世界的特点。如果系统无法处理这个互不信任的关系,则会导致文章第一部分所说的情况:整个网络被notary划分成若干相互隔绝的子网,Corda这套体系恐怕也就没什么意义了。因此,系统必须有机制能够让这些notary在一起“合作”,相信读者已经能够猜出来:解决这个问题的,就是本文的主题——共识机制

简单地总结一下:Corda系统中,强制引入了交易者对notary的信任关系,除此之外都是与其他区块链系统类似的,只是因为多了一种角色而更加复杂。听起来有点“只许州官放火,不许百姓点灯”的意味——你必须信任notary,而notary不信任你,并且它们之间也不互相信任。没办法,这种模式的根本特点就是这样,不得不说是所有讨论的一个略显遗憾的前提。不过,从后面共识机制的讨论可以看到,对于一个体系而言,这个模式还是有一定价值的,至少可以防止风险的扩散。

UTXO vs. STXO

本文一开头说到:“听到R3的企业产品部门负责人Mike Ward简介Corda的时候,受到相关概念的启发”,这个相关概念,就是指STXO(Spent Transaction Object)。STXO这个概念并不新鲜,但是Mike Ward说:“Notary就是STXO的database”,这就有些与众不同了。我想大部分人都能感受到,采用交易对象(“TXO”)模型的系统,如比特币、Corda,一般人都只针对UTXO这个概念进行讨论,STXO则基本上是个附属品——经常和UTXO成对出现,但默认不需要解释。STXO DB这个提法,更是鲜见——不仅在其他UTXO模型的区块链系统中没有看到过,在R3 Corda其他相关文档中也从未出现。

很明显,对于“TXO”模型的系统,下面这个等式成立:TXO = STXO + UTXO,也就是说,TXO是一个全集,STXO和UTXO则互为“补集”。针对这种关系,有一个很容易推导出的结论:当你能访问整个TXO集合的时候,用UTXO还是用STXO来判断一个交易对象的状态是等价的——你想知道一个交易对象是否UTXO,可以在UTXO的集合中进行搜索,能搜到则是UTXO,搜不到就不是;反过来也可以在STXO集合中搜索,搜到了就不是UTXO,搜不到就

理论上听起来没毛病,实践中我们先看一下比特币是怎么做的:比特币(0.8版以上)的数据中,有一个chainstate目录,其下放的就是UTXO数据库。这是个levelDB数据库,比特币的全功能节点需要对它进行维护:在确认一个区块时,首先要检索所有交易的输入项,如果发现没有对应的UTXO,应该要拒绝。确认区块的时候,要把所有交易的输入项在这个数据库中删除,并且把输出项插入。由此可见,这是比特币交易确认的过程中非常重要的一步,融合在比特币交易确认的复杂流程中,这个处理的正确性决定了确保数据准确以实现防止双花的能力,是比特币节点的重要功能之一。

比特币的这个实现模式有很合理的原因:随着交易的不断进行,越来越多的对象被“花掉”,因此STXO是一个有历史积累的集合,数量只增不减,越积越多。UTXO则有增有减——虽然比特币可以分解,但除非所有交易都是一进多出,否则增减总量相对还是有匹配的,这样可以保证UTXO的增长速度没有那么快。既然如此,作为交易验证过程中必须查询的数据,显然选择数据量小的那部分是合理的,虽然需要不断增删,付出一定维护一致性的代价,总还是好过每一次查询时间越来越长的问题。总之,这是个系统设计的取舍问题,而非原理上的区别。

全局 vs. 局部

那么,对于notary模式的系统而言,是不是应该采用与比特币相同的模式呢,即:随时记录/更新UTXO的信息,验证交易的时候查询一个对象是否UTXO?我们先给出答案,也就是上面提到的:notary是STXO数据库——它是通过保存/查询STXO来实现相关功能的。

在论证这个方案的合理性之前,又要谈谈概念了:notary的数据是“局部”的,每个notary只掌握经过自己公证的交易,这也是Corda“信息部分可见”特性的根本保障。所以,严格来说UTXO和STXO这两个概念对于notary而言,存在局部性和全局性双重含义:从局部看,UTXO表示“没有在我这里花过”,而STXO则表示“在我这里花过”;从全局看,UTXO表示“在整个Corda网络中没有花过”,而STXO则表示“在整个Corda网络中花过”。这样一对比就很明显了:在我这里花过,则在整个Corda网络中花过;没在我这里花过,不代表没在别处花过。反过来,要在整个网络中没花过,必须在所有notary那里都没花过;而在整个网络中花过,只需要在任何一个notary那里花过就可以了。因此:某种意义上说,STXO的概念是绝对的,无范围限制的,而UTXO的概念是相对的,局部的

从实践的角度,我们首先看单一notary的情况:对于单个notary而言,他可以保存所有“经过”他公证的交易记录,从而拥有一切他处理过的交易的TXO记录,因此对于一个notary而言,UTXO和STXO仍然是补集关系,采用保存哪一部分的方式来实现双花检测,从实现的角度看都是没问题的。也就是说,虽然概念上STXO比UTXO更具有绝对性,但实践上却因为两者都被限定在一个局部,因而用哪一类对象做判定依据仍然是等价的。

再看多个notary,并且出现对象notary变更的情况(如果没有notary变更,任何交易对象的状态变化仍然被永久限定在某个notary局部,等同于单notary)。根据前面的介绍,notary变更是交易者将一个对象通过当前notary跟自己做一个交易,形成一个新的UTXO,其notary是新notary;原对象则变成了STXO。此时,新的UTXO是针对新notary的,对于系统中其他notary而言,没有什么意义——由于UTXO概念的局部性,这个新的UTXO对象在他们那里“既非UTXO,也非STXO”。原对象的STXO是针对原notary的,但是由于STXO的全局性,其实对于整个Corda网络的所有notary而言,这应该都是一个STXO。

讨论到这里,我们可以给出本文最重要的结论:对于一个基于notary机制的系统而言,当有多个notary可能会关心一个TXO的状态时,STXO是对所有notary都有意义的,UTXO则只对未来会处理到他的notary才有意义。

共识

说完了所有这些概念,终于可以讲讲共识了。为了简化讨论,我们只设想一个场景:不管出于什么原因,比如程序bug、网络通讯故障、甚至notary蓄意欺骗等等,一个对象的当前notary对它执行了两次notary变更,分别将其notary属性变更为notary A、notary B,如果系统可以允许这种情况的发生,不就出现了双花吗?这也印证了上面讨论过的前提——notary之间相互应该是不信任的,对变更notary这件事,由于涉及一个对象可以在其他notary那里进行交易的问题,因此必须有机制保证一个对象变更两次notary的行为受到阻止。唯一的办法显然就是notary变更必须要所有notary节点都达成共识——这也就是Corda系统中需要共识机制的根本原因,相信读者非常容易理解和证明。

那么,从实践角度而言,系统的“notary们”需要针对什么达成共识,又如何达成共识呢?相信真正理解了前面几个概念的读者,已经有个大概的思路了:由于对象状态的判断要作为全系统notary达成一致的结论,就应该使用全系统一致的概念来进行处理,而根据前面的结论,STXO自然是应该使用的概念。因此,notary作为STXO DB的模式,就自然而然地成为共识机制的解决方案了。具体设计和实现方面的建议,我们就放到下一节再讲。

小结

本节主要是一些概念的深入讨论,首先是信任关系问题:基于notary的系统,信任关系要复杂一些,notary之间互不信任,应该是共识机制存在的大前提。其次,UTXO和STXO在信息全局可见的系统中互为补集,因此实践中使用哪个作为防止双花的依据都是可以的,只需要根据系统设计的优化方案来考虑。然而,对于notary模式的系统而言,UTXO和STXO在局部和全局的意义是不同的,这将导致无论从概念上还是实践上,使用STXO作为交易确认的依据更具有一致性,不过这一特点只在发生notary变更的情况下才会体现出来。综合上述三点可以得出结论:Corda确实是需要共识机制的,共识应该针对状态的notary变更,并且可以基于notary作为STXO DB的模式来实现。

此外,作为本节的结束,我顺便提一个有意思的问题供读者思考:基于TXO模式的系统,共识是针对TXO的状态的(不管是UTXO还是STXO),那基于账户模型的系统,共识机制是针对什么的呢,或者说应该是怎样一个模式呢?

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,684评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,143评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,214评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,788评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,796评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,665评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,027评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,679评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 41,346评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,664评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,766评论 1 331
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,412评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,015评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,974评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,203评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,073评论 2 350
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,501评论 2 343

推荐阅读更多精彩内容