分布式系统CAP定理与区块链不可能三角

注:本文由网络整理而来,首发于微信公众号:硬币研究院。

一、CAP定理

分布式系统CAP理论的三个特性:

● 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)

● 可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性)

● 分区容错性(P):以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。

CAP原则又称CAP定理,指的是在一个分布式系统中,Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可兼得。

CAP理论就是说在分布式存储系统中,最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题,所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡,没有NoSQL系统能同时保证这三点。

当前的区块链 技术也存在“不可能三角”,即无法同时达到“高效低能(环保)”、“去中心化”、以及“安全”这三个要求,具体来看:


(一)追求“去中心化”和“安全”则无法达到“高效低能”, 比特币区块链技术便是一种极致追求“去中心化”和“安全”的技术组合。 

从数据结构上看,它采用拥有时间戳的“区块+链”的结构,在可追溯、防篡改上具备安全优势,也易于分布式系统中的数据同步,但是若需要对信息进行查询、验 证,则涉及到对链的遍历操作,而遍历是较为低效率的查询方式。

在数据存储上,它的每一个节点都下载和存储所有数据包,利用强冗余性获得强容错、强纠错能力,使得网络可以民主自治,但同时也带来了巨大的校验成本和存 储空间损耗。它并不像分布式数据库那样随着节点的增加可以通过分布式存储提高整体存储能力,而只是简单地增加副本。未来随着区块链技术所承载的内容增 多,单个节点的存储空间将是个问题。

在并发处理上,比特币区块链技术最终只允许一个 “矿工”获得记账权建立一个交易区块,这种机制可以有 效保证一个民主网络运行的安全和稳健,但其实质上是拥有所有数据的整个“链条”在进行串行的“写”操作。 相比关系数据库将数据分为若干表,仅仅根据操作涉及 的数据锁定若干表或表中的记录、其他表仍能并发处理 相比,比特币区块链技术的串行操作效率远低于普通数据库。

在对内容的验证上,比特币区块链让每个节点都拥 有所有的内容,同时对区块内的所有内容进行哈希,这 增强了民主性和安全性。但是这种整体哈希的设计思 路则意味着不能以地址引用的方式存储数据,否则由于 所引用地址上所存储的信息由于并未进行哈希校验而 可能存在篡改。

因此,比特币区块链技术缺乏高效的可 扩展性,在对大型内容的处理上存在效率问题。

(二)追求“高效低能”和“安全”则无法完全实现“去中心化”

从“共识机制”角度看,为了在确保“安全”的前提下解决比特币区块链技术所采用的工作量证明方式的低 效性,权益证明(Proof of Stake)、股份授权证明(Dele⁃ gate Proof of Stake)等机制被采用。

但是无论是基于网 络权益代表的权益证明,还是利用101 位受委托人通过 投票实现的股份授权证明,实际上都是对“去中心化”的 退让,形成了部分中心化。

同样在区块链技术的演化上,除了以比特币为代表 的公有链技术外,又衍生了联盟链技术和私有链技术。

联盟链技术只允许预设的节点进行记账,加入的节点都 需要申请和身份验证,这种区块链技术实质上是在确保 安全和效率的基础上进行的“部分去中化”或“多中心 化”的妥协。

而私有链技术的区块建立则掌握在一个实 体手中,且区块的读取权限可以选择性开放,它为了安 全和效率已经完全演化成为一种“中心化”的技术。

(三)追求“高效低能”和“去中心化”则必须牺牲“安全”

一个极端的案例便是基于 P2P(Peer-to-Peer)的视 频播放软件。

以往当在线观看人数增多时,基于中央服 务器设计的视频服务器会因承载压力变大而速度缓 慢。为了提高效率,P2P 视频播放软件的设计使得一个 节点在下载观看视频文件的同时也不断将数据传输给 别人,每个节点不仅是下载者同时也是服务器,资源的分享形成不再依赖于中央服务器的“去中心化”模式。

同时,由于视频一秒有24 帧,少量图片的局部数据 损坏并不影响太多的视觉感官,但是用于数据校验而出 现的图像延迟则是不可接受的。于是 P2P 视频播放软 件牺牲了“安全”性,允许传输的数据出现少量错误。

在 这种去中心化的网络中,参与的节点越多,数据的传播 越快,传播的效率越高。当然这对于严谨的金融业来说,数据的错误是不可接受的,安全也是金融业所首要 考虑的问题。

总之,从当前的技术条件来看尚无法实现“高效低 能”、“去中心化”和“安全”三者皆得的区块链技术。但是若对其一个或若干个要求进行妥协,所产生的新技术 集合由于更符合实际需求,有可能它对实际应用的吸引力反而增强。

二、为什么比特币这么慢?


你可能会听人说过,BTC转账太慢、技术落后,要被淘汰了等等一些话。但是如果你明白了CAP定理,你就会知道,BTC的慢,是有它的道理的。

区块链是一个分布式系统,分布式系统中就一定存在CAP定理,因此BTC也满足CAP原理。

这里着重说一下 P , 就是分区容忍性。这个分区容忍性什么意思?所谓分区指的是网络分区的意思,详细一点解释,比如你有A B两台服务器,它们之间是有通信的,突然,不知道为什么,它们之间的网络链接断掉了。好了,那么现在本来AB在同一个网络现在发生了网络分区,变成了A所在的A网络和B所在的B网络。所谓的分区容忍性,就是说一个数据服务的多台服务器在发生了上述情况的时候,依然能继续提供服务。所以显而易见的,P是大前提,如果P发生了,咱们的数据服务直接不服务了,还谈个毛的可用性和一致性呢。

所以其实并不是三选二,而是二选一。P是必然的,然后或者选择一致性,或者选择可用性。

所以大家首先要明白,比特币,就是因为选择了一致性,所以放弃了可用性。简单说,就是慢。

所以,分布式系统天生就慢。这种慢,更像是迟钝,原因很简单:分布式系统范围一大,节点间的通信耗时就长。


我们拿银行的ATM举例,再理解下 CAP。

银行设计ATM时,强一致性是必然选择,因为算不清楚钱对银行来说是件很严重的事情。可实际场景中,对可用性的渴求却超越了一致性,银行的理由很直白:更高的可用性意味着更高的收入。

我们知道,ATM机有三个基本功能:存钱、取钱和查余额。不管怎么折腾,银行有一条底线规则必须遵守:用户借记卡余额不得小于零。我们看存款和查余额,都不破坏这条规则,于是在这两种的设计上,就可以放弃一直性,照顾更多的可用性。

所以你可以随时存款,尽管存款后的余额不可能立即传遍全网;随时能查余额,尽管屏幕显示的余额未必最新鲜准确。

只有取款,被另外设计了一下。

我们知道,在通讯网络故障,或者延迟的情况下,分布式系统会产生分区现象。银行本来是可以在发生分区的时候,禁止你取款的。但是这样,你就会觉得不舒服,ATM用起来,也不便利。所以银行为了照顾用户的感情,权衡之后,只能选择可用性。银行做了两件事:

一是提升内部通信速度,压缩节点间的通信时长

二是设置限额,比如单次取款最高5000。每日最高2万元。

这个大家都遇到过吧,是不是以前觉得这条规则特别烦人???但是这是银行为了考虑把自己的损失降低到最小设计的,这是放弃用户随时取到借记卡内所有余额的可用性,转身捕捉另一种可用性:能随时取出小额现金,因为后一种可用性在双方看来价值都更高。

因为会出现这种情况:

比如你账户余额5000元。银行的网络产生了分区,而此时,你的老婆,用存折在柜台取出了1000元,此时你账户余额应该是4000。但是因为分区,数据并没有形成一致,而你正好在ATM提款,你发现账户里面是5000,你全部取了出来。这样银行实际上,损失了1000元,这就是银行的风险。但是1000元的风险,对于银行来讲是可控的,因为概率非常小,但是是存在的。银行会通知你还钱,即使你不还,银行的损失也可以接受。

比特币,就是慢。慢到大家都接受不了,但是这种慢,是有道理的。

道理就是CAP定理:为了在一个分布式系统内追求全网账本的严苛一致,可用性理所当然地被牺牲,所以只能闷等,直到交易信息被深深刻进链上。速度方面,比特币的用户体验低落到极致,但以此为代价能坚守全网账本信息一致,最终保证系统安全,那这点慢就忍了吧。而其他的币,为了解决比特币这种慢,八仙过海,各显其能。

有的拓宽渠道,好比原来双车道改成八车道,这样单位时间内能承载更多的信息流,比特币现金就是这样。

有的采取离线交易的方式,比如闪电网络。矿工忙的时候不会例会压箱底的那堆小额交易,这是因为手续费激励不足导致的动力不够,那高频小额交易就由“小银行”帮你划转了吧,你就省钱省心吧。

BTC、BCH和闪电网络三者都没有违背CAP原理,后两者在比特币原有的严格一致性上给予用户更多可用性,但在更大交易量的冲击下,可用性和安全性是否会变形,还要让时间去考验它们。

保证比特币一致性的共识算法是POW,起点思路在于追求完美的一致性,于是只能牺牲很多的可用性。POW发动全网矿工边记账边猜数,猜到才能奖到,于是猜数字的算力逐渐演化为系统内的权力,最终这种格局牢不可破。

ETH要改的POS共识算法,要股权证明。是系统挑出一些区块生产者,去掉POW的猜随机数环节,产生的区块交给符合条件的持币者验证上链。

这大大降低了达成一致所需的时间,可代价却藏在另外的角落里。一些POS算法会产生一个反直觉的结果:一个块可以在其后的块都最终确定后,依然处于未确认的状态,这样可能会折损系统层面的安全或稳定。当然,这些都是需要时间来验证的。

还有EOS,EOS的DPOS,所有持币者天然都有等比例的投票权,以此选出一定数量的区块生产者,不称职的生产者可被投出局,以此确保全系统的高效安全稳定。

从Steemit和Bitshares两个分布式应用顺利运行一到三年的结果来看,DPOS是当前扩展区块链最出色的共识算法。但是再快的DPOS也无法在当下瞬间反馈全网其他节点的最新状态。

一致性永远是相对的。所以,我们总结一下。 

CAP定理的存在,宣判了分布式系统天生的残缺性,但是在实际应用中,我们可以通过努力,让一般用户感觉不到这种残缺。实际场景中需要思考的是:牺牲的一致性能获得多大的可用性。

所以到底哪种算法才是最好的?我没法判断,只能说,没有最好的,只有最适合的。

这就是今天想分享的内容,让大家明白一下,为什么BTC慢,EOS快。但是有得必须有舍, 跟网速没关系的, 币王所有的设计,都是完美的, 其他币种所谓的技术进步,其实都是为了商业服务而已,本身就改变了BTC的初衷。

加助手微信:li879949137,一起学习区块链。

扫码关注我们的公众号:

我们的小密圈:

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念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

推荐阅读更多精彩内容