Subscribe
关于共识机制
DK
0xC01E
May 11th, 2022
如果将去中心化的区块链技术比作一个生命体,那么共识机制可以说就是它的生命之源。
什么是共识机制?
相信每一位对区块链技术有所了解的人,都或多或少的了解过一个相关的理论——“拜占庭将军问题”,甚至对于很多人而言,拜占庭将军问题是很多人了解区块链技术原理的“第一扇大门”。
“拜占庭将军问题”源自著名图灵奖得主莱斯利·兰波特在其同名论文中提出的分布式对等网络通信容错问题。根据维基百科的解释,拜占庭将军问题即:
在分布式计算中,不同的计算机通过通讯交换信息达成共识,按照同一套协作策略行动。但有時候,系统中的成员计算机可能出错而发送错误的信息,用于传递信息的通讯网络也可能导致信息损坏,使得网络中不同的成员关于全体协作的策略得出不同结论,从而破坏系统一致性。
拜占庭是古代东罗马帝国的首都,由于当时帝国的国土幅员辽阔,为了达到防御的目的,因此每个军队都分散驻守,将军与将军之间只能依靠邮差进行通信。当战争的发生时,所有将军需要达成一致的共识共同出击才能取得成功,否则就会失败。但是军队内部可能存在叛徒或间谍,因此将军们需要一种机制保证所有的将军都对进攻的时间有一个相同的认识,也就是——即使信使真的有奸细,而且他采用了任何他能想到的措施,其余忠诚的将军也可以在不受叛徒的影响下达成一致的协议。
“共识”就是在一个由多方组成的系统中,在某一个步骤中让一个系统中所有的节点对一个值达成一致。
也就是说,在区块链系统中,每一个共识机制都需要回答下面的问题(包括但不限于):
What——下一个区块应包含哪些交易?
Who——下一个区块应该由谁来生成?
When——下一个区块应该何时产生?
Evolution——如何升级共识协议?
Immunity——如何解决交易历史的竞争问题?
共识机制的目标,就是找到这些问题的答案,并确保其健壮性以抵制攻击者试图获得网络的控制权。实际上,获得控制就意味着获得了单方面审查交易的能力。共识机制也应当能健壮地抵御攻击者利用在不同计算机上的数据库状态中的临时不一致性获取好处。
共识机制可以解什么问题?
在回答“共识”究竟能解决什么问题之前,我们必须了解两个在分布式系统中已经被证明的结论:CAP定理和FLP不可能性定理。
CAP定理指的是在一个分布式系统中,在Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性)中,最多只能实现两点,不可三者兼得。
其中,一致性要求在分布式系统中的所有数据,在同一时刻达到同样的值,也就是说所有节点访问同一份最新的数据副本;可用性要求,系统中部分节点出现故障以后,系统整体可以正常响应,不被故障节点影响;分区容错性则要求,系统如果不能在时限内达成数据的一致性,就必须在C和A之间做出选择。
FLP不可能性定理则是指,对于允许节点失效情况下,纯粹异步系统无法确保一致性在有限时间内完成。
FLP不可能性定理已经证明,在一个异步网络中我们永远也达不成一致。而CAP定理,则让我们在设计算法时有所倾向,是使用CP算法(高一致性算法),还是AP算法(高可用算法)。
共识算法本身可以描述为在某一个步骤中让一个系统中所有的节点对一个值达成一致,即使系统中存在故障, 我们也要忽略掉这些故障节点的噪音让整个系统继续正确运行, 而问题的难点就在于在一个异步网络中将这些噪音降到最小。
不得不谈的去中心化
至此,我们可以清晰地看到一些区别所在:
在一个中心化的结构体系中,整个系统的共识可以由中心来决定,各个节点只需要接受中心所下达的“命令”即可,这也是中心化系统运作更加高效的原因所在。而在去中心的体系中,所有参与系统的节点是处于一个平等的地位,当节点之间出现分歧时,就需要依靠设计巧妙的共识机制来使其顺利地运转下去。
因此,共识机制也被很多人称作是去中心化系统的核心灵魂所在,二者相辅相成、缺一不可。只有在保证去中心化的前提下共识才能保持一致,如果确保共识的节点数量较小或者受到中心化的控制,那么就很容易被攻击。
判断一个协议是不是去中心化,需要看这个协议能不能在全部节点都永久性删除后,仅依靠一个节点仍然能够恢复过来正常运作。如同一个菌丝体借助单细胞就能恢复过来一样。我们称之为完全去中心化,但逃脱不了生物学界的一个事实,多细胞生物比单细胞生物更高级,即以损失一定程度的去中心化为代价。
其实,我们在讨论一个项目是不是去中心化的时候,有所争议的往往是此节。比如对于EOS这种DPOS共识机制是否是去中心化的争论:
提问方问的是系统治理的去中心化程度,而回答者则回答其他两者的去中心化程度。如此沟通如何达成一致?因此我们有对去中心化分层的必要,并从以下三个层面来理解去中心化:
首先是系统部署的去中心化。在现实世界中,基于docker(一个开源的应用容器引擎)等虚拟技术和运用这些技术的云计算平台,以下三个问题往往很难拆分:
①系统有多少节点组成?
②部署在几台物理计算机中?
③分布多少个地区?
但是最终我们想实现系统部署去中心化的目的是一样的,就是降低同一时间节点崩溃的数量,例如地震、海啸、云平台安全事件等。
其次是系统逻辑去中心化;在系统的运行流程中,这个系统是由一种角色组成?还是多种角色合作组成?或者说,是由一台完整的单一设备组成,还是多种不同种类的设备组装的小组?举个例子,针对一个系统,我们在任意一个时刻,将系统分成2份,系统都能完整的独立运行下去么?如果以后两部分又合二为一了,系统还能正常运行么?
第三,系统治理去中心化;针对一个区块链项目,有两个重要的权限控制:系统修改权限和系统数据权限。针对系统修改权限,有多少个人或者组织,对组成系统的计算机拥有最终的控制权?针对系统数据权限,权限控制是否亏归属于每个个体?有多少涉及管理,查看非自身数据的权限?以及如何制定权利边界?
其实,我们不仅需要对区块链的去中心化进行分层理解,更重要的是,目前区块链技术已经发展到了2019年,从某种程度上讲,单纯用“中心化”和“去中心化”无法准确的描述我们目前所用到的方案。
Subscribe to DK
Receive the latest updates directly to your inbox.
Subscribe
Subscribe
Verification
This entry has been permanently stored onchain and signed by its creator.
Arweave Transaction
R4pXh2LDs78G6Xz…cG6u9w6f4o0GimI
Author Address
0xC01EFbA3cc4f5b8…3A51CC34A9C780c
Content Digest
Xb6oqNTjeUjr-dK…Ysu5qSAl90Gg7cE