區塊鏈最終一致性

1. 區塊鏈 --- 共識演算法

PoW演算法是一種防止分布式服務資源被濫用、拒絕服務攻擊的機制。它要求節點進行適量消耗時間和資源的復雜運算，並且其運算結果能被其他節點快速驗算，以耗用時間、能源做擔保，以確保服務與資源被真正的需求所使用。

PoW演算法中最基本的技術原理是使用哈希演算法。假設求哈希值Hash(r)，若原始數據為r（raw），則運算結果為R（Result）。

R = Hash(r)

哈希函數Hash()的特性是，對於任意輸入值r，得出結果R，並且無法從R反推回r。當輸入的原始數據r變動1比特時，其結果R值完全改變。在比特幣的PoW演算法中，引入演算法難度d和隨機值n，得到以下公式：

Rd = Hash(r+n)

該公式要求在填入隨機值n的情況下，計算結果Rd的前d位元組必須為0。由於哈希函數結果的未知性，每個礦工都要做大量運算之後，才能得出正確結果，而算出結果廣播給全網之後，其他節點只需要進行一次哈希運算即可校驗。PoW演算法就是採用這種方式讓計算消耗資源，而校驗僅需一次。

 

PoS演算法要求節點驗證者必須質押一定的資金才有挖礦打包資格，並且區域鏈系統在選定打包節點時使用隨機的方式，當節點質押的資金越多時，其被選定打包區塊的概率越大。

POS模式下，每個幣每天產生1幣齡，比如你持有100個幣，總共持有了30天，那麼，此時你的幣齡就為3000。這個時候，如果你驗證了一個POS區塊，你的幣齡就會被清空為0，同時從區塊中獲得相對應的數字貨幣利息。

節點通過PoS演算法出塊的過程如下：普通的節點要成為出塊節點，首先要進行資產的質押，當輪到自己出塊時，打包區塊，然後向全網廣播，其他驗證節點將會校驗區塊的合法性。

 

DPoS演算法和PoS演算法相似，也採用股份和權益質押。

但不同的是，DPoS演算法採用委託質押的方式，類似於用全民選舉代表的方式選出N個超級節點記賬出塊。

選民把自己的選票投給某個節點，如果某個節點當選記賬節點，那麼該記賬節點往往在獲取出塊獎勵後，可以採用任意方式來回報自己的選民。

這N個記賬節點將輪流出塊，並且節點之間相互監督，如果其作惡，那麼會被扣除質押金。

通過信任少量的誠信節點，可以去除區塊簽名過程中不必要的步驟，提高了交易的速度。
 

拜占庭問題：

拜占庭是古代東羅馬帝國的首都，為了防禦在每塊封地都駐扎一支由單個將軍帶領的軍隊，將軍之間只能靠信差傳遞消息。在戰爭時，所有將軍必須達成共識，決定是否共同開戰。

但是，在軍隊內可能有叛徒，這些人將影響將軍們達成共識。拜占庭將軍問題是指在已知有將軍是叛徒的情況下，剩餘的將軍如何達成一致決策的問題。

BFT：

BFT即拜占庭容錯，拜占庭容錯技術是一類分布式計算領域的容錯技術。拜占庭假設是對現實世界的模型化，由於硬體錯誤、網路擁塞或中斷以及遭到惡意攻擊等原因，計算機和網路可能出現不可預料的行為。拜占庭容錯技術被設計用來處理這些異常行為，並滿足所要解決的問題的規范要求。

拜占庭容錯系統 ：

發生故障的節點被稱為 拜占庭節點 ，而正常的節點即為 非拜占庭節點 。

假設分布式系統擁有n台節點，並假設整個系統拜占庭節點不超過m台（n ≥ 3m + 1），拜占庭容錯系統需要滿足如下兩個條件：

另外，拜占庭容錯系統需要達成如下兩個指標：

PBFT即實用拜占庭容錯演算法，解決了原始拜占庭容錯演算法效率不高的問題，演算法的時間復雜度是O(n^2)，使得在實際系統應用中可以解決拜占庭容錯問題
 

PBFT是一種狀態機副本復制演算法，所有的副本在一個視圖（view）輪換的過程中操作，主節點通過視圖編號以及節點數集合來確定，即：主節點 p = v mod |R|。v：視圖編號，|R|節點個數，p：主節點編號。

PBFT演算法的共識過程如下：客戶端（Client）發起消息請求（request），並廣播轉發至每一個副本節點（Replica），由其中一個主節點（Leader）發起提案消息pre-prepare，並廣播。其他節點獲取原始消息，在校驗完成後發送prepare消息。每個節點收到2f+1個prepare消息，即認為已經准備完畢，並發送commit消息。當節點收到2f+1個commit消息，客戶端收到f+1個相同的reply消息時，說明客戶端發起的請求已經達成全網共識。

具體流程如下 ：

客戶端c向主節點p發送<REQUEST, o, t, c>請求。o: 請求的具體操作，t: 請求時客戶端追加的時間戳，c：客戶端標識。REQUEST: 包含消息內容m，以及消息摘要d(m)。客戶端對請求進行簽名。

主節點收到客戶端的請求，需要進行以下交驗：

a. 客戶端請求消息簽名是否正確。

非法請求丟棄。正確請求，分配一個編號n，編號n主要用於對客戶端的請求進行排序。然後廣播一條<<PRE-PREPARE, v, n, d>, m>消息給其他副本節點。v：視圖編號，d客戶端消息摘要，m消息內容。<PRE-PREPARE, v, n, d>進行主節點簽名。n是要在某一個范圍區間內的[h, H]，具體原因參見 垃圾回收 章節。

副本節點i收到主節點的PRE-PREPARE消息，需要進行以下交驗：

a. 主節點PRE-PREPARE消息簽名是否正確。

b. 當前副本節點是否已經收到了一條在同一v下並且編號也是n，但是簽名不同的PRE-PREPARE信息。

c. d與m的摘要是否一致。

d. n是否在區間[h, H]內。

非法請求丟棄。正確請求，副本節點i向其他節點包括主節點發送一條<PREPARE, v, n, d, i>消息, v, n, d, m與上述PRE-PREPARE消息內容相同，i是當前副本節點編號。<PREPARE, v, n, d, i>進行副本節點i的簽名。記錄PRE-PREPARE和PREPARE消息到log中，用於View Change過程中恢復未完成的請求操作。

主節點和副本節點收到PREPARE消息，需要進行以下交驗：

a. 副本節點PREPARE消息簽名是否正確。

b. 當前副本節點是否已經收到了同一視圖v下的n。

c. n是否在區間[h, H]內。

d. d是否和當前已收到PRE-PPREPARE中的d相同

非法請求丟棄。如果副本節點i收到了2f+1個驗證通過的PREPARE消息，則向其他節點包括主節點發送一條<COMMIT, v, n, d, i>消息，v, n, d, i與上述PREPARE消息內容相同。<COMMIT, v, n, d, i>進行副本節點i的簽名。記錄COMMIT消息到日誌中，用於View Change過程中恢復未完成的請求操作。記錄其他副本節點發送的PREPARE消息到log中。

主節點和副本節點收到COMMIT消息，需要進行以下交驗：

a. 副本節點COMMIT消息簽名是否正確。

b. 當前副本節點是否已經收到了同一視圖v下的n。

c. d與m的摘要是否一致。

d. n是否在區間[h, H]內。

非法請求丟棄。如果副本節點i收到了2f+1個驗證通過的COMMIT消息，說明當前網路中的大部分節點已經達成共識，運行客戶端的請求操作o，並返回<REPLY, v, t, c, i, r>給客戶端，r：是請求操作結果，客戶端如果收到f+1個相同的REPLY消息，說明客戶端發起的請求已經達成全網共識，否則客戶端需要判斷是否重新發送請求給主節點。記錄其他副本節點發送的COMMIT消息到log中。
 

如果主節點作惡，它可能會給不同的請求編上相同的序號，或者不去分配序號，或者讓相鄰的序號不連續。備份節點應當有職責來主動檢查這些序號的合法性。

如果主節點掉線或者作惡不廣播客戶端的請求，客戶端設置超時機制，超時的話，向所有副本節點廣播請求消息。副本節點檢測出主節點作惡或者下線，發起View Change協議。

View Change協議 ：

副本節點向其他節點廣播<VIEW-CHANGE, v+1, n, C , P , i>消息。n是最新的stable checkpoint的編號， C 是 2f+1驗證過的CheckPoint消息集合， P 是當前副本節點未完成的請求的PRE-PREPARE和PREPARE消息集合。

當主節點p = v + 1 mod |R|收到 2f 個有效的VIEW-CHANGE消息後，向其他節點廣播<NEW-VIEW, v+1, V , O >消息。 V 是有效的VIEW-CHANGE消息集合。 O 是主節點重新發起的未經完成的PRE-PREPARE消息集合。PRE-PREPARE消息集合的選取規則：

副本節點收到主節點的NEW-VIEW消息，驗證有效性，有效的話，進入v+1狀態，並且開始 O 中的PRE-PREPARE消息處理流程。
 

在上述演算法流程中，為了確保在View Change的過程中，能夠恢復先前的請求，每一個副本節點都記錄一些消息到本地的log中，當執行請求後副本節點需要把之前該請求的記錄消息清除掉。

最簡單的做法是在Reply消息後，再執行一次當前狀態的共識同步，這樣做的成本比較高，因此可以在執行完多條請求K（例如：100條）後執行一次狀態同步。這個狀態同步消息就是CheckPoint消息。

副本節點i發送<CheckPoint, n, d, i>給其他節點，n是當前節點所保留的最後一個視圖請求編號，d是對當前狀態的一個摘要，該CheckPoint消息記錄到log中。如果副本節點i收到了2f+1個驗證過的CheckPoint消息，則清除先前日誌中的消息，並以n作為當前一個stable checkpoint。

這是理想情況，實際上當副本節點i向其他節點發出CheckPoint消息後，其他節點還沒有完成K條請求，所以不會立即對i的請求作出響應，它還會按照自己的節奏，向前行進，但此時發出的CheckPoint並未形成stable。

為了防止i的處理請求過快，設置一個上文提到的 高低水位區間[h, H] 來解決這個問題。低水位h等於上一個stable checkpoint的編號，高水位H = h + L，其中L是我們指定的數值，等於checkpoint周期處理請求數K的整數倍，可以設置為L = 2K。當副本節點i處理請求超過高水位H時，此時就會停止腳步，等待stable checkpoint發生變化，再繼續前進。
 

在區塊鏈場景中，一般適合於對強一致性有要求的私有鏈和聯盟鏈場景。例如，在IBM主導的區塊鏈超級賬本項目中，PBFT是一個可選的共識協議。在Hyperledger的Fabric項目中，共識模塊被設計成可插拔的模塊，支持像PBFT、Raft等共識演算法。
 

 

Raft基於領導者驅動的共識模型，其中將選舉一位傑出的領導者(Leader)，而該Leader將完全負責管理集群，Leader負責管理Raft集群的所有節點之間的復制日誌。
 

下圖中，將在啟動過程中選擇集群的Leader（S1），並為來自客戶端的所有命令/請求提供服務。 Raft集群中的所有節點都維護一個分布式日誌（復制日誌）以存儲和提交由客戶端發出的命令（日誌條目）。 Leader接受來自客戶端的日誌條目，並在Raft集群中的所有關注者（S2，S3，S4，S5）之間復制它們。

在Raft集群中，需要滿足最少數量的節點才能提供預期的級別共識保證， 這也稱為法定人數。 在Raft集群中執行操作所需的最少投票數為 (N / 2 +1) ，其中N是組中成員總數，即 投票至少超過一半 ，這也就是為什麼集群節點通常為奇數的原因。 因此，在上面的示例中，我們至少需要3個節點才能具有共識保證。

如果法定仲裁節點由於任何原因不可用，也就是投票沒有超過半數，則此次協商沒有達成一致，並且無法提交新日誌。

 

數據存儲：Tidb/TiKV

日誌：阿里巴巴的 DLedger

服務發現：Consul& etcd

集群調度：HashiCorp Nomad
 

只能容納故障節點(CFT)，不容納作惡節點

順序投票，只能串列apply，因此高並發場景下性能差
 

Raft通過解決圍繞Leader選舉的三個主要子問題，管理分布式日誌和演算法的安全性功能來解決分布式共識問題。

當我們啟動一個新的Raft集群或某個領導者不可用時，將通過集群中所有成員節點之間協商來選舉一個新的領導者。 因此，在給定的實例中，Raft集群的節點可以處於以下任何狀態: 追隨者(Follower)，候選人(Candidate)或領導者(Leader)。

系統剛開始啟動的時候，所有節點都是follower，在一段時間內如果它們沒有收到Leader的心跳信號，follower就會轉化為Candidate；

如果某個Candidate節點收到大多數節點的票，則這個Candidate就可以轉化為Leader，其餘的Candidate節點都會回到Follower狀態；

一旦一個Leader發現系統中存在一個Leader節點比自己擁有更高的任期(Term)，它就會轉換為Follower。

Raft使用基於心跳的RPC機制來檢測何時開始新的選舉。 在正常期間， Leader 會定期向所有可用的 Follower 發送心跳消息（實際中可能把日誌和心跳一起發過去）。 因此，其他節點以 Follower 狀態啟動，只要它從當前 Leader 那裡收到周期性的心跳，就一直保持在 Follower 狀態。

當 Follower 達到其超時時間時，它將通過以下方式啟動選舉程序：

根據 Candidate 從集群中其他節點收到的響應，可以得出選舉的三個結果。

共識演算法的實現一般是基於復制狀態機（Replicated state machines），何為 復制狀態機 ：

簡單來說： 相同的初識狀態 + 相同的輸入 = 相同的結束狀態 。不同節點要以相同且確定性的函數來處理輸入，而不要引入一下不確定的值，比如本地時間等。使用replicated log是一個很不錯的注意，log具有持久化、保序的特點，是大多數分布式系統的基石。

有了Leader之後，客戶端所有並發的請求可以在Leader這邊形成一個有序的日誌（狀態）序列，以此來表示這些請求的先後處理順序。Leader然後將自己的日誌序列發送Follower，保持整個系統的全局一致性。注意並不是強一致性，而是 最終一致性 。

日誌由有序編號（log index）的日誌條目組成。每個日誌條目包含它被創建時的任期號（term），和日誌中包含的數據組成，日誌包含的數據可以為任何類型，從簡單類型到區塊鏈的區塊。每個日誌條目可以用[ term, index, data]序列對表示，其中term表示任期， index表示索引號，data表示日誌數據。

Leader 嘗試在集群中的大多數節點上執行復制命令。 如果復製成功，則將命令提交給集群，並將響應發送回客戶端。類似兩階段提交(2PC)，不過與2PC的區別在於，leader只需要超過一半節點同意（處於工作狀態）即可。

leader 、 follower 都可能crash，那麼 follower 維護的日誌與 leader 相比可能出現以下情況

當出現了leader與follower不一致的情況，leader強制follower復制自己的log， Leader會從後往前試 ，每次AppendEntries失敗後嘗試前一個日誌條目（遞減nextIndex值）， 直到成功找到每個Follower的日誌一致位置點（基於上述的兩條保證），然後向後逐條覆蓋Followers在該位置之後的條目 。所以丟失的或者多出來的條目可能會持續多個任期。
 

要求候選人的日誌至少與其他節點一樣最新。如果不是，則跟隨者節點將不投票給候選者。

意味著每個提交的條目都必須存在於這些伺服器中的至少一個中。如果候選人的日誌至少與該多數日誌中的其他日誌一樣最新，則它將保存所有已提交的條目，避免了日誌回滾事件的發生。

即任一任期內最多一個leader被選出。這一點非常重要，在一個復制集中任何時刻只能有一個leader。系統中同時有多餘一個leader，被稱之為腦裂（brain split），這是非常嚴重的問題，會導致數據的覆蓋丟失。在raft中，兩點保證了這個屬性：

因此， 某一任期內一定只有一個leader 。
 

當集群中節點的狀態發生變化（集群配置發生變化）時，系統容易受到系統故障。 因此，為防止這種情況，Raft使用了一種稱為兩階段的方法來更改集群成員身份。 因此，在這種方法中，集群在實現新的成員身份配置之前首先更改為中間狀態（稱為聯合共識）。 聯合共識使系統即使在配置之間進行轉換時也可用於響應客戶端請求，它的主要目的是提升分布式系統的可用性。

2. 區塊鏈的核心技術是什麼

簡單來說，區塊鏈是一個提供了拜占庭容錯、並保證了最終一致性的分布式資料庫；從數據結構上看，它是基於時間序列的鏈式數據塊結構；從節點拓撲上看，它所有的節點互為冗餘備份；從操作上看，它提供了基於密碼學的公私鑰管理體系來管理賬戶。
或許以上概念過於抽象，我來舉個例子，你就好理解了。
你可以想像有 100 台計算機分布在世界各地，這 100 台機器之間的網路是廣域網，並且，這 100 台機器的擁有者互相不信任。
那麼，我們採用什麼樣的演算法（共識機制）才能夠為它提供一個可信任的環境，並且使得：
節點之間的數據交換過程不可篡改，並且已生成的歷史記錄不可被篡改；
每個節點的數據會同步到最新數據，並且會驗證最新數據的有效性；
基於少數服從多數的原則，整體節點維護的數據可以客觀反映交換歷史。
區塊鏈就是為了解決上述問題而產生的技術方案。
二、區塊鏈的核心技術組成
無論是公鏈還是聯盟鏈，至少需要四個模塊組成：P2P 網路協議、分布式一致性演算法（共識機制）、加密簽名演算法、賬戶與存儲模型。
1、P2P 網路協議
P2P 網路協議是所有區塊鏈的最底層模塊，負責交易數據的網路傳輸和廣播、節點發現和維護。
通常我們所用的都是比特幣 P2P 網路協議模塊，它遵循一定的交互原則。比如：初次連接到其他節點會被要求按照握手協議來確認狀態，在握手之後開始請求 Peer 節點的地址數據以及區塊數據。
這套 P2P 交互協議也具有自己的指令集合，指令體現在在消息頭（Message Header) 的 命令（command）域中，這些命令為上層提供了節點發現、節點獲取、區塊頭獲取、區塊獲取等功能，這些功能都是非常底層、非常基礎的功能。如果你想要深入了解，可以參考比特幣開發者指南中的 Peer Discovery 的章節。
2、分布式一致性演算法
在經典分布式計算領域，我們有 Raft 和 Paxos 演算法家族代表的非拜占庭容錯演算法，以及具有拜占庭容錯特性的 PBFT 共識演算法。
如果從技術演化的角度來看，我們可以得出一個圖，其中，區塊鏈技術把原來的分布式演算法進行了經濟學上的拓展。
在圖中我們可以看到，計算機應用在最開始多為單點應用，高可用方便採用的是冷災備，後來發展到異地多活，這些異地多活可能採用的是負載均衡和路由技術，隨著分布式系統技術的發展，我們過渡到了 Paxos 和 Raft 為主的分布式系統。
而在區塊鏈領域，多採用 PoW 工作量證明演算法、PoS 權益證明演算法，以及 DPoS 代理權益證明演算法，以上三種是業界主流的共識演算法，這些演算法與經典分布式一致性演算法不同的是，它們融入了經濟學博弈的概念，下面我分別簡單介紹這三種共識演算法。
PoW： 通常是指在給定的約束下，求解一個特定難度的數學問題，誰解的速度快，誰就能獲得記賬權（出塊）權利。這個求解過程往往會轉換成計算問題，所以在比拼速度的情況下，也就變成了誰的計算方法更優，以及誰的設備性能更好。
PoS： 這是一種股權證明機制，它的基本概念是你產生區塊的難度應該與你在網路里所佔的股權（所有權佔比）成比例，它實現的核心思路是：使用你所鎖定代幣的幣齡（CoinAge）以及一個小的工作量證明，去計算一個目標值，當滿足目標值時，你將可能獲取記賬權。
DPoS： 簡單來理解就是將 PoS 共識演算法中的記賬者轉換為指定節點數組成的小圈子，而不是所有人都可以參與記賬。這個圈子可能是 21 個節點，也有可能是 101 個節點，這一點取決於設計，只有這個圈子中的節點才能獲得記賬權。這將會極大地提高系統的吞吐量，因為更少的節點也就意味著網路和節點的可控。
3、加密簽名演算法
在區塊鏈領域，應用得最多的是哈希演算法。哈希演算法具有抗碰撞性、原像不可逆、難題友好性等特徵。
其中，難題友好性正是眾多 PoW 幣種賴以存在的基礎，在比特幣中，SHA256 演算法被用作工作量證明的計算方法，也就是我們所說的挖礦演算法。
而在萊特幣身上，我們也會看到 Scrypt 演算法，該演算法與 SHA256 不同的是，需要大內存支持。而在其他一些幣種身上，我們也能看到基於 SHA3 演算法的挖礦演算法。以太坊使用了 Dagger-Hashimoto 演算法的改良版本，並命名為 Ethash，這是一個 IO 難解性的演算法。
當然，除了挖礦演算法，我們還會使用到 RIPEMD160 演算法，主要用於生成地址，眾多的比特幣衍生代碼中，絕大部分都採用了比特幣的地址設計。
除了地址，我們還會使用到最核心的，也是區塊鏈 Token 系統的基石：公私鑰密碼演算法。
在比特幣大類的代碼中，基本上使用的都是 ECDSA。ECDSA 是 ECC 與 DSA 的結合，整個簽名過程與 DSA 類似，所不一樣的是簽名中採取的演算法為 ECC（橢圓曲線函數）。
從技術上看，我們先從生成私鑰開始，其次從私鑰生成公鑰，最後從公鑰生成地址，以上每一步都是不可逆過程，也就是說無法從地址推導出公鑰，從公鑰推導到私鑰。
4、賬戶與交易模型
從一開始的定義我們知道，僅從技術角度可以認為區塊鏈是一種分布式資料庫，那麼，多數區塊鏈到底使用了什麼類型的資料庫呢？
我在設計元界區塊鏈時，參考了多種資料庫，有 NoSQL 的 BerkelyDB、LevelDB，也有一些幣種採用基於 SQL 的 SQLite。這些作為底層的存儲設施，多以輕量級嵌入式資料庫為主，由於並不涉及區塊鏈的賬本特性，這些存儲技術與其他場合下的使用並沒有什麼不同。
區塊鏈的賬本特性，通常分為 UTXO 結構以及基於 Accout-Balance 結構的賬本結構，我們也稱為賬本模型。UTXO 是「unspent transaction input/output」的縮寫，翻譯過來就是指「未花費的交易輸入輸出」。
這個區塊鏈中 Token 轉移的一種記賬模式，每次轉移均以輸入輸出的形式出現；而在 Balance 結構中，是沒有這個模式的。

3. 區塊鏈的共識機制

1. 網路上的交易信息如何確認並達成共識？ 

雖然經常提到共識機制，但是對於共識機制的含義和理解卻並清楚。因此需要就共識機制的相關概念原理和實現方法有所理解。 

區塊鏈的交易信息是通過網路廣播傳輸到網路中各個節點的，在整個網路節點中如何對廣播的信息進行確認並達成共識 最終寫入區塊呢？  如果沒有相應的可靠安全的實現機制，那麼就難以實現其基本的功能，因此共識機制是整個網路運行下去的一個關鍵。

共識機制解決了區塊鏈如何在分布式場景下達成一致性的問題。區塊鏈能在眾多節點達到一種較為平衡的狀態也是因為共識機制。那麼共識機制是如何在在去中心化的思想上解決了節點間互相信任的問題呢？ 

當分布式的思想被提出來時，人們就開始根據FLP定理和CAP定理設計共識演算法。 規范的說，理想的分布式系統的一致性應該滿足以下三點：

1.可終止性（Termination）：一致性的結果可在有限時間內完成。

2.共識性(Consensus)：不同節點最終完成決策的結果應該相同。

3.合法性(Validity)：決策的結果必須是其他進程提出的提案。

但是在實際的計算機集群中，可能會存在以下問題:

1.節點處理事務的能力不同，網路節點數據的吞吐量有差異

2.節點間通訊的信道可能不安全

3.可能會有作惡節點出現

4.當非同步處理能力達到高度一致時，系統的可擴展性就會變差（容不下新節點的加入）。

科學家認為，在分布式場景下達成 完全一致性 是不可能的。但是工程學家可以犧牲一部分代價來換取分布式場景的一致性，上述的兩大定理也是這種思想，所以基於區塊鏈設計的各種公式機制都可以看作犧牲那一部分代價來換取多適合的一致性，我的想法是可以在這種思想上進行一個靈活的變換，即在適當的時間空間犧牲一部分代價換取適應於當時場景的一致性，可以實現靈活的區塊鏈系統，即可插拔式的區塊鏈系統。今天就介紹一下我對各種共識機制的看法和分析，分布式系統中有無作惡節點分為拜占庭容錯和非拜占庭容錯機制。

FLP定理即FLP不可能性，它證明了在分布式情景下，無論任何演算法，即使是只有一個進程掛掉，對於其他非失敗進程，都存在著無法達成一致的可能。

FLP基於如下幾點假設：

僅可修改一次 ：  每個進程初始時都記錄一個值（0或1）。進程可以接收消息、改動該值、並發送消息，當進程進入decide state時，其值就不再變化。所有非失敗進程都進入decided state時，協議成功結束。這里放寬到有一部分進程進入decided state就算協議成功。

非同步通信 ：  與同步通信的最大區別是沒有時鍾、不能時間同步、不能使用超時、不能探測失敗、消息可任意延遲、消息可亂序。

通信健壯： 只要進程非失敗，消息雖會被無限延遲，但最終會被送達；並且消息僅會被送達一次（無重復）。

Fail-Stop 模型： 進程失敗如同宕機，不再處理任何消息。

失敗進程數量 ： 最多一個進程失敗。

CAP是分布式系統、特別是分布式存儲領域中被討論最多的理論。CAP由Eric Brewer在2000年PODC會議上提出，是Eric Brewer在Inktomi期間研發搜索引擎、分布式web緩存時得出的關於數據一致性(consistency)、服務可用性(availability)、分區容錯性(partition-tolerance)的猜想：

數據一致性 (consistency)：如果系統對一個寫操作返回成功，那麼之後的讀請求都必須讀到這個新數據；如果返回失敗，那麼所有讀操作都不能讀到這個數據，對調用者而言數據具有強一致性(strong consistency) (又叫原子性 atomic、線性一致性 linearizable consistency)[5]

服務可用性 (availability)：所有讀寫請求在一定時間內得到響應，可終止、不會一直等待

分區容錯性 (partition-tolerance)：在網路分區的情況下，被分隔的節點仍能正常對外服務

在某時刻如果滿足AP，分隔的節點同時對外服務但不能相互通信，將導致狀態不一致，即不能滿足C；如果滿足CP，網路分區的情況下為達成C，請求只能一直等待，即不滿足A；如果要滿足CA，在一定時間內要達到節點狀態一致，要求不能出現網路分區，則不能滿足P。

C、A、P三者最多隻能滿足其中兩個，和FLP定理一樣，CAP定理也指示了一個不可達的結果(impossibility result)。

4. 區塊鏈的共識機制是什麼

如何讓去中心化網路達成共識？
在區塊鏈系統當中，沒有一個像銀行一樣的中心化記賬機構，保證每一筆交易在所有記賬節點上的一致性，即讓全網達成共識至關重要。共識機制解決的就是這個問題。
目前主要的共識機制有工作量證明機制PoW和權益證明機制PoS。
PoW通過評估你的工作量來決定你獲得記賬權的機率，工作量越大，就越有可能獲得此次記賬機會。
PoS通過評估你持有代幣的數量和時長來決定你獲得記賬權的機率。這就類似於股票的分紅制度，持有股權相對多的人能夠獲得更多的分紅。
DPOS與POS原理相似，只是選了一些「人大代表」。 與PoS的主要區別在於節點選舉若干代理人，由代理人驗證和記賬。
隨著技術的發展，未來可能還會誕生更先進的共識機制。

5. 區塊鏈具有哪些特點

據報道，區塊鏈具有去中心化、去信任和不可篡改等優勢特點。

而相比於互聯網，Cosmos所構想的區塊鏈網路在信息交互的同時，也實現了資產價值傳遞。通過IBC跨鏈協議，基於Cosmos的Tendermint Core開發的區塊鏈之間能實現代幣的跨鏈轉移，而對於類似於以太坊一類的基於PoW共識機制生成的公有鏈，可以使用Pegged Zone橋接。

文章來源：比特110網

6. 區塊鏈技術能解決什麼樣的問題

區塊鏈技術能解決什麼樣的問題？

區塊鏈技術可以用相對更低的成本解決信任問題，這對現在強調的減輕實體經濟包袱，使交易成本降低等方面起著重要作用，具有較大的社會價值。同時，針對區塊鏈技術本身，還需要有不斷探索，相信未來可以將自主可控的知識產權和專利與該技術融合在一起。
未來的金窩窩將著力於以區塊鏈技術促進大數據的合法流通和商業應用。

區塊鏈技術到底能解決什麼樣的問題？

金窩窩分析區塊鏈技術能解決的問題如下：
區塊鏈最重要的是解決了中介信用問題。在過去，兩個互不認識和信任的人要達成協作是難的，必須要依靠第三方。
比如支付行為，在過去任何一種轉賬，必須要有銀行或者支付寶這樣的機構存在。
但是通過區塊鏈技術，是人類第一次實現在沒有任何中介機構參與的情況下，完成雙方可以互信的轉賬行為。這是區塊鏈的重大突破。

金窩窩區塊鏈技術能解決什麼樣的問題？

重慶金窩窩分析：區塊鏈最重要的是解決了中介信用問題。
在過去，兩個互不認識和信任的人要達成協作是難的，必須要依靠第三方。

金窩窩區塊鏈技術的應用能解決什麼樣的問題？

重慶金窩窩分析區塊鏈技術的應用解決的問題如下：
區塊鏈最重要的是解決了中介信用問題，在過去，兩個互不認識和信任的人要達成協作是很難的，必須要藝考第三方。
通過區塊鏈技術，可以實現沒有任何中介機構參與下，完成雙方可以互相信任的行為，這就是區塊鏈技術中去中介化（去中心化）解決的問題。

區塊鏈技術的出現解決了什麼樣的問題？

區塊鏈解決了信任的問題，信任是一切問題的根源。
維基鏈是一個支持圖靈完備的智能合約平台。維基鏈採用 dpos 的共識機制，共設置 11 個投票節點，每 10 秒產生一個新的區塊。通過智能合約維基鏈可以實現資產發行、競猜應用、版權溯源、互助保險、去中心化交易所、跨境結算等豐富的應用場景。
但這些場景最重要的還是信任，是要公開透明。

區塊鏈技術能解決哪些問題？

基於分布式記賬、集體合約和智能共識等機制，區塊鏈技術呈現出去中心化、開放共享、真實可靠等信息處理特性，引發了金融領域、特別是互聯網金融領域的日益重視與研究應用。區塊鏈系統開發公司不少，像人人鏈這些的區塊鏈技術開發企業是比較靠譜的，區塊鏈方案可以參考一下。
第1點：首先要解你所選擇的區塊鏈技術服務提供商的技術實力，包括區塊鏈底層實力和團隊技術實力；開發過哪些成功案例。索要已開發項目，對方會把之前做過的成功案例拿出來分析。
第2點：要看對方現有底層區塊鏈架構和項目開發經驗。
第3點：可以問下身邊的朋友是否有了解和推薦。個人知道在綜合實力不錯的是人人鏈區塊鏈BaaS平台，開放的雲平台上能夠快速構建自己的 IT基礎設施和區塊鏈服務。當然還有一些其它的，選擇適合自己企業的平台。還有沒提到的需要關注的問題，希望他人幫忙補充~

區塊鏈技術在版權領域能解決什麼問題？

區塊鏈類似「公開賬本」，每一個區塊即是一個「賬本頁」，當人們在區塊鏈上進行交易時，交易數據會公開給區塊鏈中的每一個節點，並被記錄在「賬本頁」上，永久存儲，不可篡改。鑒於區塊鏈的這種去中心化、開放性及信息不可篡改的特點，每個錄入區塊鏈版權登記系統的作品都會生成唯一的不可篡改的數字指紋。
用戶只需通過小犀版權鏈平台身份認證授權，成功認證「我是我」後，提交作品到版權鏈，後台審核通過後會生成數據寫入區塊鏈，生成證書。申請版權保護中心的紙質證書，需點擊「版權證申請」，然後按照步驟填寫資料、交費，等待審核……這樣看來，區塊鏈+版權的模式，真是安全、省時、省力。
說到法律保護，不得不提到「侵權」版權作為無形資產，若創作者維權意識缺失，作品就可能面臨被侵權的處境。這一點小犀版權鏈在業界做得比較好。這個平台之所以成為國內第一家基於區塊鏈的智能維權平台，也是和重慶公證處的支持分不開的。基於區塊鏈的數字化文件存證技術，得到了公證處的認可，能夠實現公證申請內容的不可篡改，為公證服務的數字化、網路化、信息化提供了幫助。公證當事人能夠通過小犀平台，在線提交「保全證據」公證，讓權利人對作品的所有權更具司法效力，有效面對侵權行為，提升風險應對能力。
區塊鏈這種新型信用評價體系，為公證處的服務改革提供了新的技術支撐。小犀版權鏈將重慶公證處的部分業務搬上區塊鏈平台，堪稱區塊鏈在公證書業務領域的革新。在公證書的辦理過程中，材料審查及核實是最為關鍵和重要的一環。「區塊鏈+公證」後台的流程設計一改以往需人工到各部門查證核實的環節，公證員只需在線審核用戶提供的材料，便可快速完成審查核實工作，大幅提升了辦事效率。

區塊鏈技術真的能解決信任問題嗎

區塊鏈技術的分布式架構和不可篡改等特性，有助於解決票據真實性和信息不透明等問題。當參與方需要檢驗票據是否已經被篡改或轉讓時，區塊鏈就可以提供無可爭議的一致性證明。
數字貨幣也是利用了區塊鏈的這種特性，普銀就是基於區塊鏈技術開發出來的一種茶本位數字貨幣。

區塊鏈技術的價值互聯網解決了什麼樣的問題？

重慶金窩窩分析：
第一，區塊鏈通過在數字貨幣領域的應用，提供了資金流（或者叫資本流）信息在互聯網的流動的解決方案。
第二，區塊鏈通過加密和分布式賬本的引用，解決了在交易過程中的確權問題。
第三，區塊鏈通過共識機制的技術，確定了數字資產的交換問題。