POW工作量證明的流程如下:
從流程圖中可以看出，POW工作量證明的流程主要經歷三步:
· 生成Merkle根雜湊
· 組裝區塊頭
· 計算出工作量證明的輸出
在這裡，我們以虛擬碼的形式去理解工作量證明的輸出:
i. 工作量證明的輸出 = SHA256(SHA256(區塊頭 + 變更的隨機數))
ii. if (工作量證明的輸出 >= 目標值),變更隨機數，遞迴i的邏輯，繼續與目標值比對。
iii. if (工作量證明的輸出 >= 目標值),變更隨機數，遞迴i的邏輯，繼續與目標值比對。
最後，生成的符合難度的區塊，將透過P2P傳遞到比特幣的全網路節點並接收，新增到原有區塊鏈的尾部。
由此，我們可以看到POW主要是透過CPU的算力來保證全網的共識安全。
權益證明POS
POS(Proof of Stake)即權益證明機制，最早出現在點點幣的白皮書中，其核心思想是將貨幣持有人的數 目和持有的時間累計作為被選為共識節點的資本。
POS權益證明的運作主要包含兩部分:
驗證
在整個區塊鏈網路中，參與者會把他們的代幣投給他們認為有效的區塊，如果他們跟網路中的大部分參與者達成一致，就可以獲得和他們代幣成正比的獎勵；而試圖作弊則要冒著失去保證金的⻛險，例如同時給兩個不同的區塊投票。
在POS中，金錢即力量；POS要求參與者將他們的網路代幣作為安全保證金，使其與網路利益達成一致， 而不是透過消耗電能來加固網路安全。
下圖為驗證的過程:
節點之間會透過接收、簽名、傳送訊息來達成區塊的共識。這種權益和節點基礎設施的組合通常被稱作驗證者。透過這種方式註冊的權益數量決定了相關驗證者在共識過程中的影響力、以及驗證者因工作而獲得的獎勵。
委託
將自己的代幣拖尾給驗證者，以換取獲得獎勵的份額。通常委託人會將代幣存放在智慧合約之中，指定他們想要委託的驗證者。這樣當該驗證者獲得驗證獎勵的時候，委託人也能獲得與其委託代幣數量成正 比的獎勵。整個過程如下:
授權股權證明DPOS
授權股權證明機制(Delegated Proof of Stake)最早由Daniel Larimer提出，BitShares是第一個提出並採用DPOS的分散式賬本。簡單來說，DPOS的工作原理類似於董事會投票，給持幣者一把可以開啟他們所持股份對應的表決權鑰匙，而不是給他們一把能夠挖礦的鏟子。
DPOS引入了⻅證人的概念，⻅證人可以生成區塊，每個持股人都可以投票選舉⻅證人。得到總票數前N(通常為101)的候選者，可以當選⻅證人。⻅證人的候選者名單每個維護週期(通常為1天)更新一次。
在BitShares的設計中，利益相關者可以選舉一定數量的⻅證人來生成區塊。每個賬戶允許對⻅證人投一票，這個投票過程被稱為"批准投票"。選擇出來的N個⻅證人被認為是對至少50%的投票利益相關者的代表。每次⻅證人產生一個區塊，⻅證人將得到一定的出塊獎勵，如果⻅證人因為違規來沒有生成區塊，將不能得到獎勵，並且會加入到"黑名單"，從而再次成為⻅證人的機會會大大降低。
每組被選舉出來的⻅證人的活躍狀態在每一個週期將會被更新，隨後這組⻅證人將會被解散。每個⻅證人給一個2秒的流轉機會用來出塊，當所有的⻅證人都流轉完成後，該組⻅證人也會被解散。如果一個⻅證人在它的時間週期內沒有產生區塊，它的時間機會將會被錯過，下一個⻅證人將產生下一個區塊。任何節點都可以透過觀察證人的參與率來監控網路的健康狀況。歷史上BitShares曾經維持了99%的⻅證參與。
所有的⻅證人會成為特權賬戶的共同簽署者，該賬戶有權提出對網路引數的更改。這個賬戶被稱為起源賬戶。這些引數包括從交易費用到塊大小，⻅證支付和出塊間隔等。在大多數的⻅證人批准了一項擬議的變更後，利益相關者將獲得2周的審查期間，在此期間，他們可以對代表進行投票，並根據建議變更或者取消。選擇這種設計是為了確保代表在技術上不具有直接的權利，所有對網路引數的更改最終都得 到利益相關者的批准。在DPOS中，我們可以說，行政的權利是由使用者掌握，而不是代表或者證人。
拜占庭共識機制PBFT
PBFT(Practical Byzantine Fault Tolerance)，意為實用拜占庭容錯演算法，是目前最常用的BFT演算法之一。最早由Miguel Castro和Barbara Liskov在1999年提出，解決了原始拜占庭容錯演算法效率不高的問題，將演算法複雜度由指數級降低到多項式級。
PBFT演算法中主要有以下一些引數的定義:
client: 客戶端，發出呼叫請求的實體
view:檢視，內容為連續的編號
replica:網路節點
primary:主節點，負責生成訊息序列號
backup:支撐節點，輔助整體共識過程
state:節點狀態
PBFT演算法要求整個系統流程要在同一個檢視(view)下完成，所有節點採取一致的行動。一個客戶端會傳送請求
<REQUEST,o,t,c>給replicas，其中，o表示具體的操作，t表示timestamp，給每一個請求加上時間戳， 這樣後來的請求會有高於簽名的時間戳。Replicas接收到請求後，如果驗證透過，他就會將其寫入自己的log中。在此請求執行完成後，replicas會返回client一個回覆<REPLY,v,t,c,i,r>,其中:
v是當前的view序號
t是對應請求的時間戳
i是replica節點的編號
r是執行結果
每一個replica會與每一個處於active狀態的client共享一份金鑰。金鑰所佔據空間較少，加上會限制active client的數量，所以不必擔心以後出現的擴充套件性問題。
PBFT採用三階段提交協議來廣播請求給replicas，分別是pre-parpare、prepare，commit。pre- prepare階段和prepare階段用來把在同一個view裡傳送的請求排序，然後讓各個replicas節點都認可這 個序列，照序執行prepare階段和commit階段用來確保那些已經達到commit狀態的請求，即使在發生檢視改變後，在新的view裡依然保持原有的序列不變，比如一開始在view 0中有req 0，req 1，req 2三個請求依次進入了commit階段，假設沒有惡意階段，那麼這四個replicas即將要依次執行者三條請求並返回給client。但這時主節點問題導致view change的發生，view 0變成view 1，在新的view裡，原本的req 0，req 1，req 2三條請求的序列將被保留。但是處於pre-prepare和prepare階段的請求在view change發生後，在新的view裡都將被遺棄。
下圖是三階段提交協議的時序圖:
小結
本篇中主要講解了區塊鏈的主流共識演算法，下篇中我們將講解與區塊鏈相關的密碼學理論。敬請期待~
