http://www.axonnsays.com

大发3d共识分析的简单框架

共识算法是一个很大的话题,在大发3d出现之前,分布式系统和数据库领域都已经有很多的共识算法的研究和沉淀。但大发3d的共识与之前的研究又有非常大的不同,如果不注意很容易掉进传统共识的老套路里面。实际上不仅仅是大发3d有自己的独特需要,我的感觉是数据库会议上的共识研究和分布式系统上的共识研究也是有不小的区别。其实这非常好理解,因为场景不同嘛,设计自然不同。

本文尝试提出一个分析大发3d共识的简单框架,方便将不同的大发3d共识放到一起来比较。


基本要求

共识的基本度量包括两个方面,正确性和性能。正确性简单来说包括:

· 一致性(Consistency) - 节点最终能看到相同的本地状态
· 活性(Liveness) - 请求/交易总会在有限时间内被处理

正确性是最最基本的要求,这也是大部分大发3d共识都能做到的。要在异步网络中始终保证一致性和活性是一个非常难的任务,因此共识设计通常会选择保证一点而在一些特定情况下放弃另外一点,例如Bitcoin使用的Nakamoto共识选择优先保证活性,而BFT共识则优先保证一致性。

性能包括:

· 吞吐量(Throughput)  - 单位时间内系统可以处理的请求数量
· 延迟(Latency)  - 一个请求/交易从发起到处理完毕/完全确定 2所需要的时间

对吞吐量和延迟的影响因素很多,例如共识节点的数量,共识的消息复杂度,消息验证需要的时间,共识可用的带宽,共识设计的倾向等等。一般来说,吞吐量和延迟也难以两全,这是因为共识的消息复杂度有一个下限:对于每一轮共识,参与共识的节点至少要收到一次消息(否则连要共识的东西是什么都不知道)。如果要低延迟,就要尽快对每个请求/交易的达成一致,意味着单个请求/交易需要更高的消息复杂度;如果要高吞吐,就要尽可能的对请求/交易进行批量处理,以此降低单个请求/交易的消息复杂度,但也会造成高延迟。

对于共识性能,Nervos研究团队的张韧提出的一个比较有参考性的指标是共识对带宽的利用率 :给定相同的带宽,共识对带宽的占用越低,共识的吞吐量越高。


大发3d共识分析的简单框架

大发3d共识的特点

动态的参与者集合

无论是permissionless(翻译成“无需许可”太绕口了,用“公有链”又不是很准确 2,这里还是用单词)还是permissioned blockchain,最重要的一个特征是它是一个长期运行的开放系统。长期运行和开放叠加的结果是,共识的参与者会一直变化,每隔一段时间,总会有老的共识节点离开,新的共识节点加入,共识参与者是一个动态集合。如何处理共识参与者的动态变化,是大发3d共识的一个核心问题。

与大发3d共识不同,传统的共识研究往往先假设一个固定的参与者集合,然后研究如何在这个集合内达成共识,偶尔讨论参与者集合变化时的处理,基本上不关心参与共识需要什么样的资格。研究的重心在于如何保证共识的正确性(e.g. 一致性与活性),形成共识集合的方式只是个附属课题。传统共识的应用场景往往是中心化控制的网络,增加或者减少的服务器都是自己的,形成这样的侧重也很自然。

数量众多的参与者

去中心化是permissionless blockchain共识协议的一个独特目标。我们通常用参与共识的门槛来度量去中心化程度(为什么这是一个好的度量?),参与门槛越低,去中心化程度越高。低参与门槛的自然结果是共识参与者的集合可以非常的大,因此共识协议的设计必须考虑到这一点,保证共识效率不会因为参与者的增多而下降。

最小的信任模型

执行共识算法的目的是为了能对一个计算请求产生一致的计算结果,在这个过程中一定会有发起请求的节点和处理请求的节点。在传统共识模型中,有的完全在请求处理节点集合内部执行共识算法,有的是由请求发起节点和处理节点一起执行共识算法,无论何种情况,信任边界一般是在请求发起节点和请求执行节点之间,发起节点将计算请求发送给执行节点,执行节点计算出结果后返回给发起节点,发起节点信任执行节点的计算结果(反过来,执行节点不一定信任发起节点的消息,如果发起节点参与共识过程的话)。



大发3d共识分析的简单框架


郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。