共識演算法（二）—— DPoS（股份授權證明）、PBFT（實用拜占庭容錯）
DPoS簡介
DPoS（Delegated-Proof-of-Stake）即股份授權證明，目的是解決PoS和PoW的不足，DPoS是由被社群選取的可信賬戶（受託人，得票數為所有委託人得前101位）來建立區塊，為了成為正式委託人，使用者要去社群拉票，獲得足夠多的使用者信任，使用者根據自己持有的加密貨幣數量佔有總量的百分比來進行投票。它就像一個股份制公司，普通員工進不去董事會，但可以推選代表（受託人）代他們做決策。這前101位受託人可以理解為101個礦池，而這101個礦池彼此的權力是相等的，那些擁有加密貨幣的使用者可以隨時更換這些礦池。
代幣
EOS
優點
-
能耗底
-
更加的去中心化
-
更快的確認速度。
缺點
-
投票的積極性不高
-
社群選舉可能存在網路安全問題。
PBFT簡介
PBFT(Practical Byzantine Fault Tolerance),即實用拜占庭容錯演算法，是解決拜占庭將軍問題的一種方案。比起最開始的BFT演算法，PBFT額外要求網路封閉，即節點數目確定並提前互通，但將複雜度從指數級降低到多項式級，使得BFT系列演算法真正具有可行性。。PBFT演算法的核心理論是 y>=3x+1，y是系統的總節點數，x是允許出現故障的節點數，換句話說如果整個系統擁有x個節點是出錯了，那麼，這個系統必須包含y個節點，才能解決故障。
PBFT4個階段：
request：client請求階段（有些說法不包括這個階段）。總司令給軍長下命令。
預準備（pre-prepare）：主節點向所有backup節點發送預準備訊息，其中包括當前檢視編號，client請求以及請求摘要，簽名是否一致等。軍長對各位師長說：現在是我的時代（檢視），我是軍長，你們都是師長，所有人都得聽我的。現在公佈總司令的命令（先說說總司令是誰，命令摘要）。
準備(prepare)：包括主節點在內的所有副本節點在收到準備訊息之後，對訊息的簽名是否正確，檢視編號是否一致，以及訊息序號是否滿足水線限制這三個條件進行驗證，如果驗證通過則把這個準備訊息寫入訊息日誌中。backup節點核對簽名信息，比如其他師長聽到總司令的名字，說對，總司令就是這個人沒錯，然後核對總司令曾經任命這傢伙當軍長，好吧，那就聽他的吧。
確認(commit)：每個副本接受確認訊息的條件是：1）簽名正確；2）訊息的檢視編號與節點的當前檢視編號一致；3）訊息的序號n滿足水線條件，在h和H之間。一旦確認訊息的接受條件滿足了，則該副本節點將確認訊息寫入訊息日誌中。每個師長都經過上述核對，確認無誤，就會接受命令進行執行。
回覆（reply）：結果反饋。
代幣
NEO
優點
與POW、POS等大家耳熟能詳的共識不同，BFT系列的共識不需要“Proof”，亦即不需要節點投入算力或其他資源來確權，因此不需要代幣激勵便可完成共識。
缺點
原始的BFT效率太低，只能存在於理論而無法應用。而改進的PBFT雖然效率大大提高，卻對節點數量和狀態提出了要求，導致合格的記帳節點太少，並且也只能維持在少數，過多的節點會拖慢網路速度。