拜占庭將軍問題（Byzantine Generals Problem）是Leslie Lamport（2013年的圖靈獎得主）用來為描述分布式系統(tǒng)一致性問題（Distributed Consensus）在論文中抽象出來一個著名的例子。
拜占庭將軍問題簡易的非正式描述如下：
拜占庭帝國想要進(jìn)攻一個強(qiáng)大的敵人，為此派出了10支軍隊去包圍這個敵人。這個敵人雖不比拜占庭帝國，但也足以抵御5支常規(guī)拜占庭軍隊的同時襲擊。基于一些原因，這10支軍隊不能集合在一起單點突破，必須在分開的包圍狀態(tài)下同時進(jìn)攻。他們?nèi)我恢к婈爢为氝M(jìn)攻都毫無勝算，除非有至少6支軍隊同時襲擊才能攻下敵國。他們分散在敵國的四周，依靠通信兵相互通信來協(xié)商進(jìn)攻意向及進(jìn)攻時間。困擾這些將軍的問題是，他們不確定他們中是否有叛徒，叛徒可能擅自變更進(jìn)攻意向或者進(jìn)攻時間。在這種狀態(tài)下，拜占庭將軍們能否找到一種分布式的協(xié)議來讓他們能夠遠(yuǎn)程協(xié)商，從而贏取戰(zhàn)斗？這就是著名的拜占庭將軍問題。
拜占庭將軍問題中并不去考慮通信兵是否會被截獲或無法傳達(dá)信息等問題，即消息傳遞的信道絕無問題。Lamport已經(jīng)證明了在消息可能丟失的不可靠信道上試圖通過消息傳遞的方式達(dá)到一致性是不可能的。所以，在研究拜占庭將軍問題的時候，假定信道是沒有問題的，然后去做一致性和容錯性相關(guān)研究。
拜占庭問題前，就已經(jīng)存在兩將軍問題(Two Generals Paradox):兩個將軍要通過信使來達(dá)成進(jìn)攻還是撤退的約定，但信使可能迷路或被敵軍阻攔(消息丟失或偽造)，如何達(dá)成一致?
根據(jù)FLP不可能原理，兩將軍問題無通用解。
BFT（Byzantine Fault Tolerance），即拜占庭容錯，是分布式計算領(lǐng)域的容錯技術(shù)，拜占庭容錯來源于拜占庭將軍問題。拜占庭將軍問題是對現(xiàn)實世界的模型化，由于硬件錯誤、網(wǎng)絡(luò)擁塞或中斷以及遭到惡意***等原因，計算機(jī)和網(wǎng)絡(luò)可能出現(xiàn)不可預(yù)料的行為。拜占庭容錯技術(shù)被設(shè)計用來處理現(xiàn)實存在的異常行為，并滿足所要解決的問題的規(guī)范要求。
區(qū)塊鏈網(wǎng)絡(luò)環(huán)境符合拜占庭將軍問題模型，有運(yùn)行正常的服務(wù)器（忠誠的拜占庭將軍），有故障的服務(wù)器，還有破壞者的服務(wù)器（叛變的拜占庭將軍）。共識算法的核心是在正常的節(jié)點間形成對網(wǎng)絡(luò)狀態(tài)的共識。
通常，發(fā)生故障的節(jié)點被稱為拜占庭節(jié)點，而正常的節(jié)點為非拜占庭節(jié)點。
拜占庭容錯系統(tǒng)是一個擁有n臺節(jié)點的系統(tǒng)，整個系統(tǒng)對于每一個請求，滿足以下條件：
A、所有非拜占庭節(jié)點使用相同的輸入信息，產(chǎn)生同樣的結(jié)果；
B、如果輸入的信息正確，那么所有非拜占庭節(jié)點必須接收這個信息，并計算相應(yīng)的結(jié)果。
拜占庭系統(tǒng)普遍采用的假設(shè)條件包括：
A、拜占庭節(jié)點的行為可以是任意的，拜占庭節(jié)點之間可以共謀；
B、節(jié)點之間的錯誤是不相關(guān)的；
C、節(jié)點之間通過異步網(wǎng)絡(luò)連接，網(wǎng)絡(luò)中的消息可能丟失、亂序并延時到達(dá)，但大部分協(xié)議假設(shè)消息在有限的時間里能傳達(dá)到目的地；
D、服務(wù)器之間傳遞的信息，第三方可以嗅探到，但是不能篡改、偽造信息的內(nèi)容和驗證信息的完整性。
原始的拜占庭容錯系統(tǒng)由于需要展示其理論上的可行性而缺乏實用性。另外，還需要額外的時鐘同步機(jī)制支持，算法的復(fù)雜度也是隨節(jié)點增加而指數(shù)級增加。
PBFT（Practical Byzantine Fault Tolerance），即實用拜占庭容錯算法，由Miguel Castro和Barbara Liskov在1999年發(fā)表的論文《Practical Byzantine Fault Tolerance and Proactive Recovery》中提出。PBFT算法可以工作在異步環(huán)境中，并且通過優(yōu)化解決了原始拜占庭容錯算法效率不高的問題，將算法復(fù)雜度由指數(shù)級降低到多項式級，使得拜占庭容錯算法在實際系統(tǒng)應(yīng)用中變得可行，目前已得到廣泛應(yīng)用。PBFT算法可以在失效節(jié)點不超過總數(shù)1/3的情況下同時保證Safety和Liveness。
PBFT 算法采用密碼學(xué)相關(guān)技術(shù)(RSA 簽名算法、消息驗證編碼和摘要)確保消息傳遞過程無法被篡改和破壞。
PBFT是一種狀態(tài)機(jī)副本復(fù)制算法，即服務(wù)作為狀態(tài)機(jī)進(jìn)行建模，狀態(tài)機(jī)在分布式系統(tǒng)的不同節(jié)點進(jìn)行副本復(fù)制。每個狀態(tài)機(jī)的副本都保存了服務(wù)的狀態(tài)，同時也實現(xiàn)了服務(wù)的操作。將所有的副本組成的集合使用大寫字母R表示，使用0到|R|-1的整數(shù)表示每一個副本。為了描述方便，通常假設(shè)故障節(jié)點數(shù)為f個，整個服務(wù)節(jié)點數(shù)為|R|=3f+1個，f是有可能失效的副本的大個數(shù)。盡管可以存在多于3f+1個副本，但額外的副本除了降低性能外不能提高可靠性。
所有的副本在一個被稱為視圖（View）的輪換過程中運(yùn)作。在某個視圖中，一個副本作為主節(jié)點（primary），其它的副本節(jié)點作為備份節(jié)點（backups）。視圖是連續(xù)編號的整數(shù)。主節(jié)點由公式p = v mod |R|計算得到，v是視圖編號，p是副本編號，|R|是副本集合的個數(shù)。當(dāng)主節(jié)點失效的時候就需要啟動視圖輪換過程。
PBFT算法實現(xiàn)流程如下：
（1）REQUEST
客戶端C向主節(jié)點p發(fā)送
重慶分公司
重慶分公司
請求。
o:請求的具體操作
t:請求時客戶端追加的時間戳
c：客戶端標(biāo)識。
REQUEST: 包含消息內(nèi)容m，以及消息摘要d(m)。
客戶端對請求進(jìn)行簽名。
（2）PRE-PREPARE
主節(jié)點收到客戶端的請求，需要對客戶端請求消息簽名是否正確進(jìn)行校驗。
非法請求則丟棄。正確請求，分配一個編號n，編號n主要用于對客戶端的請求進(jìn)行排序。然后廣播一條
<,? m> 消息給其它副本節(jié)點。
v：視圖編號
d客戶端消息摘要
m：消息內(nèi)容
進(jìn)行主節(jié)點簽名。
n是要在某一個范圍區(qū)間內(nèi)的[h, H]。
（3）PREPARE
副本節(jié)點i收到主節(jié)點的PRE-PREPARE消息，需要進(jìn)行以下校驗：
A、主節(jié)點PRE-PREPARE消息簽名是否正確。
B、當(dāng)前副本節(jié)點是否已經(jīng)收到了一條在同一v下并且編號也是n，但是簽名不同的PRE-PREPARE信息。
C、d與m的摘要是否一致。
D、n是否在區(qū)間[h, H]內(nèi)。
非法請求則丟棄。正確請求，副本節(jié)點i向其它節(jié)點包括主節(jié)點發(fā)送一條
消息, v, n, d, m與上述PRE-PREPARE消息內(nèi)容相同，i是當(dāng)前副本節(jié)點編號。
進(jìn)行副本節(jié)點i的簽名。記錄PRE-PREPARE和PREPARE消息到log中，用于視圖輪換過程中恢復(fù)未完成的請求操作。
PREPARE階段如果發(fā)生視圖輪換會導(dǎo)致丟棄PREPARE階段的請求。
（4）COMMIT
主節(jié)點和副本節(jié)點收到PREPARE消息，需要進(jìn)行以下校驗：
A、副本節(jié)點PREPARE消息簽名是否正確。
B、當(dāng)前副本節(jié)點是否已經(jīng)收到了同一視圖v下的n。
C、 n是否在區(qū)間[h, H]內(nèi)。
D、d是否和當(dāng)前已收到PRE-PPREPARE中的d相同
非法請求則丟棄。如果副本節(jié)點i收到了2f+1個驗證通過的PREPARE消息，表明網(wǎng)絡(luò)中的大多數(shù)節(jié)點已經(jīng)收到同意信息，則向其它節(jié)點包括主節(jié)點發(fā)送一條
消息，v, n, d,? i與上述PREPARE消息內(nèi)容相同。
進(jìn)行副本節(jié)點i的簽名。記錄COMMIT消息到日志中，用于視圖輪換過程中恢復(fù)未完成的請求操作。記錄其它副本節(jié)點發(fā)送的PREPARE消息到log中。
COMMIT階段用來確保網(wǎng)絡(luò)中大多數(shù)節(jié)點都已經(jīng)收到足夠多的信息來達(dá)成共識，如果COMMIT階段發(fā)生視圖輪換，會保存原來COMMIT階段的請求，不會達(dá)不成共識，也不會丟失請求編號。
（5）REPLY
主節(jié)點和副本節(jié)點收到COMMIT消息，需要進(jìn)行以下校驗：
A、副本節(jié)點COMMIT消息簽名是否正確。
B、當(dāng)前副本節(jié)點是否已經(jīng)收到了同一視圖v下的n。
C、d與m的摘要是否一致。
D、n是否在區(qū)間[h, H]內(nèi)。
非法請求則丟棄。如果副本節(jié)點i收到了2f+1個驗證通過的COMMIT消息，說明當(dāng)前網(wǎng)絡(luò)中的大部分節(jié)點已經(jīng)達(dá)成共識，運(yùn)行客戶端的請求操作o，并返回
給客戶端，r：是請求操作結(jié)果，客戶端如果收到f+1個相同的REPLY消息，說明客戶端發(fā)起的請求已經(jīng)達(dá)成全網(wǎng)共識，否則客戶端需要判斷是否重新發(fā)送請求給主節(jié)點。記錄其它副本節(jié)點發(fā)送的COMMIT消息到log中。
3、PBFT算法的垃圾回收為了確保在視圖輪換的過程中，能夠恢復(fù)先前的請求，每一個副本節(jié)點都記錄一些消息到本地的log中，當(dāng)執(zhí)行請求后副本節(jié)點需要把之前該請求的記錄消息清除掉。最簡單的做法是在Reply消息后，再執(zhí)行一次當(dāng)前狀態(tài)的共識同步，但成本比較高，因此可以在執(zhí)行完多條請求K（例如：100條）后執(zhí)行一次狀態(tài)同步。狀態(tài)同步消息就是CheckPoint消息。
副本節(jié)點i發(fā)送
給其它節(jié)點，n是當(dāng)前節(jié)點所保留的最后一個視圖請求編號，d是對當(dāng)前狀態(tài)的一個摘要，該CheckPoint消息記錄到log中。如果副本節(jié)點i收到了2f+1個驗證過的CheckPoint消息，則清除先前日志中的消息，并以n作為當(dāng)前一個stable checkpoint。
實際中，當(dāng)副本節(jié)點i向其它節(jié)點發(fā)出CheckPoint消息后，其它節(jié)點還沒有完成K條請求，所以不會立即對i的請求作出響應(yīng)，還會按照自己的節(jié)奏，向前行進(jìn)，但此時發(fā)出的CheckPoint并未形成stable，為了防止i的處理請求過快，設(shè)置一個上文提到的高低水位區(qū)間[h, H]來解決問題。低水位h等于上一個stable checkpoint的編號，高水位H = h + L，其中L是指定的數(shù)值，等于checkpoint周期處理請求數(shù)K的整數(shù)倍，可以設(shè)置為L = 2K。當(dāng)副本節(jié)點i處理請求超過高水位H時，此時就會停止腳步，等待stable checkpoint發(fā)生變化，再繼續(xù)前進(jìn)。
如果主節(jié)點作惡，可能會給不同的請求編上相同的序號，或者不去分配序號，或者讓相鄰的序號不連續(xù)。備份節(jié)點應(yīng)當(dāng)有職責(zé)來主動檢查這些序號的合法性。如果主節(jié)點掉線或者作惡不廣播客戶端的請求，客戶端設(shè)置超時機(jī)制，超時的話，向所有副本節(jié)點廣播請求消息。副本節(jié)點檢測出主節(jié)點作惡或者下線，發(fā)起視圖輪換協(xié)議。
副本節(jié)點向其它節(jié)點廣播
消息。n是最新的stable checkpoint的編號，C是2f+1驗證過的CheckPoint消息集合，P是當(dāng)前副本節(jié)點未完成的請求的PRE-PREPARE和PREPARE消息集合。
當(dāng)主節(jié)點p = v + 1 mod |R|收到2f個有效的VIEW-CHANGE消息后，向其它節(jié)點廣播
消息。V是有效的VIEW-CHANGE消息集合。O是主節(jié)點重新發(fā)起的未經(jīng)完成的PRE-PREPARE消息集合。PRE-PREPARE消息集合的選取規(guī)則如下：
A、選取V中最小的stable checkpoint編號min-s，選取V中prepare消息的大編號max-s。
B、在min-s和max-s之間，如果存在P消息集合，則創(chuàng)建
<, m> 消息。否則創(chuàng)建一個空的PRE-PREPARE消息，即：
<, m(null)> , m(null)為空消息，d(null)為空消息摘要。
副本節(jié)點收到主節(jié)點的NEW-VIEW消息，驗證有效性，有效的話，進(jìn)入v+1狀態(tài)，并且開始O中的PRE-PREPARE消息處理流程。
PBFT算法的優(yōu)點:
PBFT算法具有高交易通量和吞吐量，高可用性，易于理解。
PBFT算法的缺點:
A、計算效率依賴于參與協(xié)議的節(jié)點數(shù)量，由于每個副本節(jié)點都需要和其它節(jié)點進(jìn)行P2P的共識同步，因此隨著節(jié)點的增多，性能會下降的很快，但在較少節(jié)點的情況下可以有不錯的性能，并且分叉的幾率很低，不適用于節(jié)點數(shù)量過大的區(qū)塊鏈，擴(kuò)展性差。
B、系統(tǒng)節(jié)點是固定的，無法應(yīng)對公有鏈的開放環(huán)境，只適用于聯(lián)盟鏈或私
有鏈環(huán)境。
C、PBFT算法要求總節(jié)點數(shù)n>=3f+1(其中，f代表作惡節(jié)點數(shù))。系統(tǒng)的失效節(jié)點數(shù)量不得超過全網(wǎng)節(jié)點的1/3，容錯率相對較低。
PBFT算法的節(jié)點數(shù)量是固定的，節(jié)點身份提前確定，無法動態(tài)添加或刪除，只能適用于節(jié)點數(shù)目固定的聯(lián)盟鏈或私有鏈場景中。
PBFT在很多場景都有應(yīng)用，在區(qū)塊鏈場景中，一般適合于對強(qiáng)一致性有要求的私有鏈和聯(lián)盟鏈場景，但如果能夠結(jié)合DPOS節(jié)點代表選舉規(guī)則，也可以應(yīng)用于公有鏈，并且可以在一個不可信的網(wǎng)絡(luò)里解決拜占庭容錯問題。在Hyperledger Fabric項目中，共識模塊被設(shè)計成可插拔的模塊，支持像PBFT、Raft等共識算法。
POW（Proof of Work），即工作量證明，也稱挖礦。工作量證明通過計算來猜測一個數(shù)值(nonce)，使得拼湊上交易數(shù)據(jù)后內(nèi)容的Hash值滿足規(guī)定的上限。由于Hash難題在目前計算模型下需要大量的計算，可以保證在一段時間內(nèi)，系統(tǒng)中只能出現(xiàn)少數(shù)合法提案。如果能夠提出合法提案，證明提案者確實已經(jīng)付出了一定的工作量。
哈?，F(xiàn)金是一種工作量證明機(jī)制，是Adam Back在1997年發(fā)明的，用于抵抗郵件的拒絕服務(wù)***及垃圾郵件網(wǎng)關(guān)濫用。
工作量證明的主要特征是客戶端需要做一定難度的工作得出一個結(jié)果，驗證方卻很容易通過結(jié)果來檢查出客戶端是不是做了相應(yīng)的工作。工作量證明方案的一個核心特征是不對稱性：工作對于請求方是適中的，對于驗證方則是易于驗證的。
給定一個基本字符串，在基本字符串后面添加一個叫做nonce的整數(shù)值，對變更后（添加nonce)的字符串進(jìn)行SHA256哈希運(yùn)算，如果得到的哈希結(jié)果（以16進(jìn)制的形式表示）是以某個字符串（如"0000"）開頭的，則驗證通過。為了達(dá)到工作量證明的目標(biāo)，需要不停的遞增nonce值，對得到的新字符串進(jìn)行SHA256哈希運(yùn)算。
由于給定的基本字符串在不同的場合并不確定，對于不同的基本字符串和nonce的組合，要使用SHA256計算得到某個字符串開頭Hash值的計算次數(shù)并不確定，但會是一個符合統(tǒng)計學(xué)規(guī)律的概率事件。
按照規(guī)則，預(yù)期大概要進(jìn)行2^16 次嘗試（哈希值的偽隨機(jī)特性可以做概率估算），才能得到4個前導(dǎo)0的哈希散列。
比特幣區(qū)塊由區(qū)塊頭和該區(qū)塊所包含的交易列表組成。區(qū)塊頭大小為80字節(jié)，其構(gòu)成包括：
4字節(jié)：版本號
32字節(jié)：上一個區(qū)塊的哈希值
32字節(jié)：交易列表的Merkle根哈希值
4字節(jié)：當(dāng)前時間戳
4字節(jié)：當(dāng)前難度值
4字節(jié)：隨機(jī)數(shù)Nonce值
80字節(jié)長度的區(qū)塊頭，即為比特幣Pow算法的輸入字符串。
交易列表附加在區(qū)塊頭之后，其中第一筆交易為礦工獲得獎勵和手續(xù)費的特殊交易。
工作量證明過程，即為不斷調(diào)整Nonce值，對區(qū)塊頭做雙重SHA256哈希運(yùn)算，使得結(jié)果滿足給定數(shù)量前導(dǎo)0的哈希值的過程，其中前導(dǎo)0的個數(shù)，取決于挖礦難度，前導(dǎo)0的個數(shù)越多，挖礦難度越大。
每創(chuàng)建2016個塊后將計算新的難度，此后的2016個塊使用新的難度。計算步驟如下：
A、找到前2016個塊的第一個塊，計算生成這2016個塊花費的時間。
即最后一個塊的時間與第一個塊的時間差。時間差不小于3.5天，不大于56天。
B、計算前2016個塊的難度總和，即單個塊的難度x總時間。
C、計算新的難度，即2016個塊的難度總和/14天的秒數(shù)，得到每秒的難度值。
D、要求新的難度，難度不低于參數(shù)定義的最小難度。
POW算法的優(yōu)點：
A、完全去中心化
B、節(jié)點自由進(jìn)出
C、安全性高
POW算法的缺點：
A、記賬權(quán)向資本集中
B、挖礦造成大量的資源浪費。
C、網(wǎng)絡(luò)性能太低，需要等待多個確認(rèn)，容易產(chǎn)生分叉，區(qū)塊的確認(rèn)共識達(dá)成的周期較長，不適合商業(yè)應(yīng)用。
POW共識機(jī)制用在了大部分挖礦的區(qū)塊鏈項目，比如BTC、ETH、LTC。
四、POS算法 1、POS算法簡介POS（Proof of Stake），即權(quán)益證明，是POW的一種升級共識機(jī)制，根據(jù)每個節(jié)點所占代幣的比例和時間，等比例的降低挖礦難度，從而加快找隨機(jī)數(shù)的速度。
鑒于POW的缺陷，2012年Sunny King提出了POS，并基于POW和POS的混合機(jī)制發(fā)布了點點幣PPCoin。
POS原理的核心概念為幣齡，即持有貨幣的時間。例如有10個幣、持有90天，即擁有900幣天的幣齡。
使用幣即意味著幣齡的銷毀。
在POS中有一種特殊的交易稱為利息幣，即持有人可以消耗幣齡獲得利息，同時獲得為網(wǎng)絡(luò)產(chǎn)生區(qū)塊以及POS造幣的優(yōu)先權(quán)。
POW通過算力證明自己有資格寫區(qū)塊鏈，而PoS通過擁有的幣齡來證明自己有資格寫區(qū)塊鏈。
POS算法的優(yōu)點：
A、不消耗大量算力挖礦，節(jié)省能耗。
B、在一定程度上縮短了共識達(dá)成的時間
C、防作弊。
POS算法的缺點：
A、本質(zhì)仍然需要挖礦，未解決商業(yè)應(yīng)用的痛點
B、極端的情況下會帶來中心化的結(jié)果
點點幣的POS證明計算公式為：
proofhash < 幣齡x目標(biāo)值
展開如下：
hash(nStakeModifier + txPrev.block.nTime + txPrev.offset + txPrev.nTime + txPrev.vout.n + nTime) < bnTarget x bnCoinDayWeight
其中proofhash，對應(yīng)一組數(shù)據(jù)的哈希值，即hash(nStakeModifier + txPrev.block.nTime + txPrev.offset + txPrev.nTime + txPrev.vout.n + nTime)。
幣齡即bnCoinDayWeight，即幣天，即持有的幣數(shù)乘以持有幣的天數(shù)，此處天數(shù)大值為90天。
目標(biāo)值，即bnTarget，用于衡量POS挖礦難度。目標(biāo)值與難度成反比，目標(biāo)值越大、難度越小；反之亦然。
因此，持有的幣天越大，挖到區(qū)塊的機(jī)會越大。
DPOS（Delegated Proof of Stake），即股份授權(quán)證明算法，是在POW及POS基礎(chǔ)上誕生的一種新型共識算法，2014年4月由Bitshares的首席開發(fā)者Dan Larimer (現(xiàn)為EOS CTO)提出并應(yīng)用。DPOS既能解決POW在挖礦過程中產(chǎn)生的DPOS大量能源過耗的問題，也能避免POS權(quán)益分配下可能產(chǎn)生的信任天平偏頗的問題。
DPOS是由被社區(qū)選舉的可信賬戶（超級節(jié)點，比如得票數(shù)前101位可以成為）來創(chuàng)建區(qū)塊。比如選出101個超級節(jié)點，即101個礦池，超級節(jié)點之間的權(quán)利是完全相等的。普通的持幣者可以隨時通過投票更換超級節(jié)點（礦池），DPOS的去中心化不是每個持幣者就有直接的股份權(quán)益，而是需要間接的投票權(quán)力，來保證被推選出來的超級節(jié)點不作惡，同時也可以自己拉選票成為超級節(jié)點或者備用超級節(jié)點。
DPOS算法的基本原則：
A、持股人依據(jù)所持股份行使表決權(quán)，而不是依賴挖礦競爭記賬權(quán)。
B、大化持股人的盈利。
C、最小化維護(hù)網(wǎng)絡(luò)安全的費用。
D、?大化網(wǎng)絡(luò)的效能。
E、?最小化運(yùn)行網(wǎng)絡(luò)的成本 (帶寬、CPU等)，在不浪費大量電力的情況下實現(xiàn)網(wǎng)絡(luò)的安全穩(wěn)定。
在DPOS共識算法中，區(qū)塊鏈的正常運(yùn)轉(zhuǎn)依賴于超級節(jié)點，超級節(jié)點的職責(zé)主要有：
A、提供一臺服務(wù)器節(jié)點，保證節(jié)點的正常運(yùn)行；
B、節(jié)點服務(wù)器收集網(wǎng)絡(luò)里的交易；
C、節(jié)點驗證交易，把交易打包到區(qū)塊；
D、節(jié)點廣播區(qū)塊，其它節(jié)點驗證后把區(qū)塊添加到自己的數(shù)據(jù)庫；
E、帶領(lǐng)并促進(jìn)區(qū)塊鏈項目的發(fā)展；
DPOS算法運(yùn)行機(jī)制如下：
A、所有持幣者先選出超級節(jié)點負(fù)責(zé)簽署區(qū)塊
B、DPOS的規(guī)則是最長鏈勝出，每個超級節(jié)點必須按照生產(chǎn)排程，輪流產(chǎn)生區(qū)塊。假設(shè)排程排定A、Ｂ、Ｃ分別輪流生產(chǎn)區(qū)塊，在一定時間內(nèi)產(chǎn)生的區(qū)塊如下：
C、如果惡意節(jié)點生產(chǎn)了分叉區(qū)塊，假設(shè)Ａ、Ｃ都是誠實的節(jié)點，只有B節(jié)點是惡意的，由于B產(chǎn)生區(qū)塊的速度（每個周期生產(chǎn)一個區(qū)塊）慢于A、Ｃ合力產(chǎn)生區(qū)塊的速度（每個周期生產(chǎn)一個區(qū)塊），根據(jù)最長鏈勝出的規(guī)則，誠實的節(jié)點還是會勝出。
D、同一個節(jié)點要產(chǎn)生重復(fù)兩個區(qū)塊的速度也要慢于誠實節(jié)點合作產(chǎn)生區(qū)塊的速度，所以最長鏈勝出規(guī)則會保證誠實節(jié)點的鏈會勝出。
E、如果A，B，C三個超級節(jié)點的網(wǎng)絡(luò)出現(xiàn)碎片化，各自為政的情況。在短期內(nèi)的確可能三鏈并行，但一旦網(wǎng)絡(luò)連接恢復(fù)，短鏈自然會向最長鏈回歸。超級節(jié)點數(shù)量為奇數(shù)，所以兩大派系勢均力敵僵持不下的情況不會維持太久，最終勢必會有其中一方的鏈更長。
注冊成為候選超級節(jié)點需要支付一筆保證金（約10 XTS)，通常擔(dān)任超級節(jié)點約兩周后才可達(dá)到損益平衡，因此促進(jìn)了受托人的穩(wěn)定性，確保至少會挖滿兩周的礦。
DPOS對惡意節(jié)點的懲罰為：不按排程產(chǎn)生區(qū)塊的超級節(jié)點將在下一輪被投票剔除，被沒收繳納的保證金。
惡意節(jié)點在短期內(nèi)是能夠作惡的，惡意的區(qū)塊只是短時間保留而已，很快超級節(jié)點之間會回歸誠實節(jié)點達(dá)成的共識，制造出最長鏈，向沒有作惡區(qū)塊的最長鏈回歸。
DPOS算法的優(yōu)點：
A、能耗優(yōu)勢，網(wǎng)絡(luò)運(yùn)行成本低。
B、理論上更加去中心化。
C、較快的確認(rèn)速度。出塊速度秒級，交易確認(rèn)分鐘級。
DPOS算法的缺點：
A、壞節(jié)點不能被及時處理，只有經(jīng)過選舉才能清除壞節(jié)點。
B、小散投票積極性不高。
C、依賴代幣
比特股（Bitshare）是一類采用DPOS機(jī)制的密碼貨幣，通過引入一個技術(shù)民主層來減少中心化的負(fù)面影響。
DPOS系統(tǒng)任然存在中心化，但中心化是受到控制的，超級節(jié)點由普通持幣者選舉產(chǎn)生。DPOS通過保留持幣者的控制權(quán)，從而使系統(tǒng)去中心化。
