一、拜占庭問題起源

拜占庭曾經(jīng)是東羅馬帝國的首都，由于當(dāng)時拜占庭羅馬帝國國土遼闊，為了防御目的，因此每個軍隊都分隔很遠，將軍與將軍之間只能靠信差傳遞消息。

在戰(zhàn)爭的時候，拜占庭軍隊內(nèi)所有將軍和副官必需達成一致的共識，決定是否有贏的機會才去攻打敵人的陣營。但是，在軍隊內(nèi)有可能存有叛徒和敵軍的間諜，左右將軍們的決定擾亂整體軍隊的秩序。所以在進行共識時，結(jié)果并不代表大多數(shù)人的意見。

這時候，在已知有成員謀反的情況下，其余忠誠的將軍如何不受叛徒的影響達成一致的協(xié)議，拜占庭問題就此形成。

拜占庭問題就是在存在消息丟失的不可靠信道上如何通過消息傳遞的方式達到一致性。

二、實用拜占庭算法PBFT

PBFT全稱為Practical Byzantine Fault Tolerance，中文名稱為實用拜占庭容錯算法，該算法是Miguel Castro (卡斯特羅)和Barbara Liskov（利斯科夫）在1999年提出來的，解決了原始拜占庭容錯算法效率不高的問題，將算法復(fù)雜度由指數(shù)級降低到多項式級，使得拜占庭容錯算法在實際系統(tǒng)應(yīng)用中變得可行。

三、算法簡介

PBFT是一種基于消息傳遞一致性的共識算法，算法經(jīng)過幾個階段達成一致性，這些階段可能因為失敗而重復(fù)進行。

剛才我們提到，消息可能丟失，信道可能不可靠，在這樣的情況下，假設(shè)我們能容忍錯誤節(jié)點的個數(shù)是f個，那么PBFT算法就能夠在全部節(jié)點大于3f的情況下，保證系統(tǒng)的安全性和活性，也就是說，

所有節(jié)點個數(shù) > 3*容錯節(jié)點數(shù)，或者所有節(jié)點個數(shù) = 3*容錯節(jié)點數(shù)+1。

在超級賬本Fabric0.6中主要使用的就是PBFT算法，一次完整的共識需要經(jīng)歷請求（request）、預(yù)準備（pre-prepare）、準備(prepare)、提交(commit)、回復(fù)(reply)五個階段。

四、算法工作流程

算法中主要涉及幾個概念：客戶端、主節(jié)點、副本節(jié)點和失效節(jié)點。其中客戶端指的是能發(fā)送交易請求的終端；主節(jié)點和副本節(jié)點用于參與共識，在整個共識過程中，節(jié)點的主節(jié)點身份和副本節(jié)點身份一直在輪換；失效節(jié)點指的是失效不能正常參與共識的節(jié)點。

我們剛才提到輪換，解釋一下，在PBFT算法中，所有的過程在一個被稱為視圖（View）的輪換過程中運作。在某個視圖中，一個節(jié)點作為主節(jié)點（primary），其它的作為副本（backups）。那么哪個節(jié)點是主節(jié)點呢？主節(jié)點由公式 v mod |R|計算得到，這里v是視圖編號，|R|是節(jié)點個數(shù)。所有節(jié)點都通過三段式協(xié)議進行共識，當(dāng)主節(jié)點失效的時候就需要啟動視圖更換（view change）過程。每更換一次，視圖編號加一。這樣就實現(xiàn)了一個節(jié)點在主節(jié)點身份和副本節(jié)點身份之間的切換。

這次的介紹就到這里，下次我會深入講解算法的工作流程。