知识库 | 共识机制演绎:paxos的拜占庭化

Posted Unitimes

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了知识库 | 共识机制演绎:paxos的拜占庭化相关的知识,希望对你有一定的参考价值。

unitimes.media

全球视角,独到见解


“我们将一个2f+1的paxos算法拜占庭化,推导出3f+1的拜占庭paxos算法——Leslie Lamport”


知识库 | 共识机制演绎(3):paxos的拜占庭化


前文所述paxos及raft尽管在折衷活跃性(liveness)的前提下达成了共识一致,但是并没有考虑到节点作恶的处置问题。事实上,非拜占庭容错的共识算法解决和优化的只是关于“两将军悖论(Two Generals Paradox)1,2”的问题。


1975年,E.A. Akkoyunlu,K. Ekanadham和R.V. Huber三人在其论文《网络通信设计的一些限制与折衷(Some Constraints and Trade-offs in the Design of Network Communications)》 中首次提及“黑帮问题”。这一问题在1978年由Jim Gary发表的文章3中被重新阐述为“两将军悖论”。在故事中,两位将军A和B分别处于敌军的两侧,他们决定派发一名信使以告知发动攻击的时间。由于敌军实力比较特殊,如果在同一时间内双方不能同时发起攻击,那么必然意味着发起攻击的单方将面临覆灭。但是派遣信使也有一个问题:如果信使中途被敌军抓获,那么他就会被处决,在这种情况下,两位将军能否就发动攻击的时间达成一致呢?


假设将军A派遣了信使X去把进攻的时间告知给将军B。将军B在收到X的信息后要求X把自己的答复传达给A,以保证A知道自己已经知晓了进攻的时间。在这个等待的过程中,A首先需要明确B是否已经知晓了进攻时间了呢?信使X有可能在寻找B的路上被敌军杀害,那么此时A就不应该进攻;如果X在回来的路上被杀害,那么A就应该进攻。对于B来说,信使X回去以后,他也同样面临着两难的抉择:如果信使X在寻找A的路上被杀害,那么意味着A并不知道自己已经同意了发动进攻的时间,此时他不应该进攻;如果信使X已经告知A自己同意了进攻时间,那么他就应该进攻。


进一步的问题来了,B怎么确定A知道了自己已经知晓了进攻的时间?也许A应该派一位信使过来告知自己A已经知道B知道了进攻的时间,但这时便会进一步引起关于“B也要知道A已经知道B已经知道A的进攻时间”的问题,由此进入死循环。


如果此间节点允许作恶,那么问题就更加棘手了。


1982年,Leslie Lamport发表了著名的《拜占庭将军问题4》。所谓“拜占庭将军问题”,是指信息在传达的过程中不仅可能遭遇网络故障,更有可能遭遇恶意删改的问题。由此可见,“拜占庭将军问题”实际上描述了信息网络中更一般化的状况。


然而,在现实使用中,要顺利解决上述问题并不容易(甚至可以说无解)。无论是“两将军悖论”还是“拜占庭将军”问题,我们都只能将其置于特定场景下以寻找最优解。


在进一步了解后续拜占庭容错算法前,我们先来引入并理解两个重要的概念:


首先是“安全性(Saftty)”,即系统最终一定会就唯一且正确的结果达成一致。


其次是“活跃性(Liveness)”,即算法不会无休止地进行下去,其最终一定能够达成共识。 


1985年,M.J.Fischer,N.A.Lynch和M.S.Paterson发表了著名的“FLP不可能性5(FLP impossibility)”定理。该定理指出,在网络可靠但存在节点失效(即使只有一个)的最小异步模型系统中,不存在一个可以解决一致性问题的确定性算法。这意味着,在异步网络中,分布式系统的安全性与活跃性无法同时得到保证。


“FLP不可能性”定理不仅终结了科学家们关于异步网络是否存在两全其美的共识算法的争论,更为共识算法的设计与实现提供了明确的思路——共识算法的最佳实现是基于实际应用场景所进行的最优折衷。


我们重回到爱琴海上的paxos小岛。在本系列的第(1)部分中,我们讲述了paxos议会的制度(即paxos算法6)是如何诞生的。总结而言,paxos算法分为两个阶段:


第一阶段,提案节点a(proposer)选择一个全局唯一的编号X,并向超过半数的接收节点(acceptor)发送编号为X的准备(prepare)请求,该请求记为1a信息。如果接收节点b收到的编号X比其之前接收到的所有准备请求的编号都大,那么b将把自己所表决过的编号最大的提案的值(或者“空”)返回给a,并承诺不再接收任何编号小于X的准备请求;但如果接收节点b已经接收过编号大于X的准备请求,那么其将拒绝a的请求,并将该请求告知a。此阶段b对a的响应记为1b信息。


第二阶段,如果提案节点a收到半数以上接收节点对其发出的编号为X的准备请求的响应,那么它就会发送一个关于(X,V)的接收(accept)请求给半数以上的接收节点,该请求记作2a信息。注意,此处的V就是提案节点收到的响应中编号最大的提案的内容(值);如果响应中不包含任何提案,那么V就由提案节点自己决定。


在这个阶段中,如果接收节点b收到一个编号为X的提案的接收请求,只要b没有对编号大于X的准备请求作出过响应,它就接受该提案,并作出回应,该回应我们记作2b信息。


我们首先定义一个关于“在某处安全(safe at)”的概念。如果在任何编号小于X的提案中,只有值v被选中了,那么我们就称v在提案X中是安全的。根据这一要求,我们不妨进一步拓展两个限制:


P1. 只有当v在提案X中是安全的,接收节点才能够对v进行表决;


P2. 同一提案中,不同的接收节点不能表决不同的值。


我们假设网络中共有N个节点,其中,有f个是恶意节点。需要注意的是,没有人能提前获知谁是诚实节点,谁是恶意节点。此外,为了证明拜占庭化的paxos能够容忍f个节点作恶,不妨假设网络中作恶的节点数正好是f个。


我们用拜占庭接收节点(byzacceptors)来表示任意诚实或恶意的接收节点,用拜占庭法定集合(byzquorum)来表示包含超过半数接收节点(即接收节点法定集合)的集合。假设接收节点法定集合内包含q个节点,那么拜占庭法定集合内节点的个数将为q+f。


在原来的paxos中,一旦节点接收到超过半数以上的2b信息,它便能获知值v已经被选上。而在拜占庭化paxos中,节点需要收到与拜占庭法定集合数量相当的类似信息,才能确定值v已经被选上。


Paxos共识的关键步骤在于领导节点(即提案节点)如何挑选提案的内容(值)。在原有paxos算法中,领导节点只要从众多提案中选出编号最大的提案的值就可以了。而在拜占庭paxos算法中,挑选提案值v是一个大麻烦。如果说来自拜占庭法定集合的1b信息内都为“空”,那么领导节点可以挑选任意值,这时问题迎刃而解;但是如果来自拜占庭法定集合的1b信息包含有拜占庭接收节点此前表决过的提案信息,那么领导节点将无法判断提案值的真假。


有人可能会说,只要有f+1个节点(因为作恶节点只有f个,当中一定有1个节点是诚实的)提议同一个编号最大的提案不就可以了吗?是的,但在接收节点法定集合内的节点数q未确定的情况下,我们无法保证算法的活跃性。


一种可行的解决方案是,网络中总节点数N至少要满足N>3f。这样的话,任意两个法定集合都至少有f+1个公共节点(根据法定集合的概念,不重合的节点数为[3f/2]=f,其中[N]表示取小于N的最大整数。那么,公共集合的节点数将为N-2f。假设N=3f+1,那么公共节点数为f+1)。此时,领导节点选取提案值v的机制相应更改为:


1. 如果超过f+1个节点都没有对编号小于X的提案进行表决,所有值在提案X内都是安全的。


2. 如果有超过f+1个接收节点对某一提案U(U<X)进行了表决,那么U中的提案值u在提案X内是安全的。


但是第2项要求将导致网络内节点的数量至少大于4f(因为有f个节点作恶,还需要应对paxos中有f个节点宕机的状况,那么在保证活跃性的前提下,还需要有f个节点来保证f+1个接收节点表决提案U)。


这里还有一个问题,如果第1项要求得到满足,那么恶意的领导节点将可能同时发送两条带有不同提案值的2a信息,并导致后续的表决中有两个不同的提案值被选中。


解决这个问题的思路是,让领导节点和接收节点共同完成挑选提案值的流程,我们把相应的信息记为2av信息(对照2a信息)。当领导节点把值为v的2av信息发送给拜占庭接收节点时,接收节点会把自己关于挑选值v的回应发送给所有拜占庭接收节点。当然,接收节点不会随意做出回应,除非(i)它觉得这一条2av信息是合理的,并且(ii)它并没有处理过编号为X的提案。只有当接收节点收到来自拜占庭法定集合的同样是选择值v的2av信息时,才会继续执行2b流程。


我们现在对paxos算法进行一些改变,不妨称之为PCon算法。在原paxos算法中,关于提案X的2a信息主要有两个作用:第一,证明某个值在提案X中是安全的;第二,指导接收节点支持提案X中的值。而在PCon算法中(需要注意的是,该算法类似paxos,不考虑恶意节点),我们引入1c信息来完成第一项任务。此外,我们还允许领导节点发送多个1c信息来声明多个值是安全的。如此,上述paxos的流程便修改为:


第一阶段,在收到来自接收节点法定集合的1b信息以后,领导节点选出一组在提案X中安全的值,并为这些值分别发送对应的1c信息。而在第二阶段,领导节点将发送一条囊括所有上述1c信息对应的值的2a信息。


那么1c信息里面的值是如何挑选的呢?当领导节点接收到来自接收节点法定集合的1b信息以后,它将判断:


1. 如果接收节点法定集合内的节点没有为编号小于X的提案进行表决,那么所有值在提案X都是安全的。


2. 如果曾经存在过一个提案U(U<X),它的值为v,那么(i)如果法定集合内的接收节点没有为编号大于U且小于X的提案进行表决,且(ii)有接收节点曾经为值为v的提案U表决过,那么v在提案X内是安全的。


事实上,1c信息只是一个逻辑构想,并不需要真正地发送出去。当领导节点发送2a信息的时候,就已经意味着必要的1c信息已经发送出去。同理,当接收节点向领导节点反馈关于提案U的1b信息时,也意味着与提案U相关的1c信息过去也发送过。既然这样的话,1c信息到底有什么意义呢?


在原文中,作者提到了“重配置”的概念。所谓重配置,就是网络中接收节点的数量不是固定的,而是动态的。如果在某个时刻有一个新的接收节点接进来,而旧的接收节点退出了(假设是对提案U表决的节点),那么新的接收节点无需依赖旧的接收节点来获取提案信息,只要根据1c信息就可以获知网络的最新动态。


在PCon的基础上,我们引入f个拜占庭节点,并称之为BPCon算法。在BPCon算法中,2a信息的概念将被弱化,即2a信息不再由领导节点发送,而是由接受节点共同完成。当接收节点收到关于值v的1c信息以后,它们将发送关于值v的2av信息。


由于拜占庭共识算法还需要容忍领导节点作恶的问题,我们不妨假设领导节点可以发送任意内容的1a和1c信息。这时,接收节点将一直忽视这些信息,直到该信息是有效的。


那么接收节点该如何判别信息的有效性呢?我们知道,1c信息的确定是遵循PCon中的判断要求的。在BPCon中,我们要求每一个接收节点的1b信息都必须包含它曾经表决过的编号最大且值为v的提案(比如提案U)的2av信息,以便确认相关的1c信息曾经存在过(因为每一条2av信息都对应于一条有效的1c信息)。


 为此,PCon对1c信息的判断要求修改为:


1′. 如果拜占庭法定集合内的节点没有为编号小于X的提案进行表决,那么所有值在提案X都是安全的。


2′. 如果曾经存在过一个提案U(U<X),它的值为v,那么(i)如果拜占庭法定集合内的接收节点没有为编号大于U的提案进行表决,并在提案U的表决中支持了值v,并且(ii)有f+1条来自拜占庭接收节点的1b信息(这些1b信息不一定是该拜占庭法定集合的,也有可能是接收节点收集的其它节点的1b信息)声明它们曾经发送过包含值v的提案U的2av信息,那么v在提案X内是安全的。


如果接收节点收到满足法定集合数量且相同的2av信息,那么它们将选择一个有效的值v,并将执行相应的2b流程。


至此,我们关于拜占庭化paxos算法的简要推导就到此结束了。相信此刻不少读者朋友的心里都是这样的:


但可能也有耐心的读者已经发现:这算法越看越像PBFT呀!如果把拜占庭接收节点换作副本节点(replicas),把领导节点换作主节点(primary),那么其他拜占庭接收节点就是备份节点(backups)了!就连Leslie Lamport在文末也不禁感慨:PBFT让BPCon变得更美丽呀!


1999年,Miguel Castro和Barbara Liskov在操作系统设计与实现国际会议(OSDI99)上发表了名为《实用拜占庭容错算法7》的论文,由此掀开了商用拜占庭容错共识算法的序幕。下一节,我们将为您介绍:BFT和它的xBFT们。



参考文献


[1] E. A. Akkoyunlu, K. Ekanadham, R.V. Huber. Some Constraints and Trade-offs in the Design of Network Communications[J]//Acm Sigops Operating System    

Review, 1975, 9(5):67-74


[2] Wikipedia. Two Generals’ Problem[EB/OL]//https://en.wikipedia.org/wiki/

Two_Generals%27_Problem


[3] Jim Gary. Notes on Database Operating Systems[J]//Operating Systems, An 

Advanced Course, 1982,7:Vol. 4, No. 3.


[4] Leslie Lamport. The Byzantine Generals Problem[J]//ACM Transactions on    Programming Languages and Systems, 1978, 60:393-481


[5] M.J.Fischer, N.A.Lynch, M.S.Paterson.Impossibility of Distributed Consensus with One Faulty Process[J]/Journal of the ACM, 1985,32(2):374-382


[6] Leslie Lamport. Byzantizing Paxos by Refinement[J]//Springer Berlin Heidelberg, 2011, 6950:11-224


[7] Miguel Castro, Barbara Liskov. Practical Byzantine Fault Tolerance and proactive recovery [J]// ACM Transactions on Computer Systems, 2002, 20(4):398–461


国际金融科技新媒体和社区平台

UNITIMES

网址 : unitimes.media

新浪微博:@Unitimes


以上是关于知识库 | 共识机制演绎:paxos的拜占庭化的主要内容,如果未能解决你的问题,请参考以下文章

共识算法演绎 :从 paxos 小岛说起

从Paxos到拜占庭容错,兼谈区块链的共识协议

PBFT共识算法的个人见解

共识算法:Raft

区块链快速入门——CFT(非拜占庭容错)共识算法

分布式环境RAFT一致性共识算法解读