hyperledger區塊鏈報錯

⑴ 區塊鏈 --- 共識演算法

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使用了一種稱為兩階段的方法來更改集群成員身份。 因此，在這種方法中，集群在實現新的成員身份配置之前首先更改為中間狀態（稱為聯合共識）。 聯合共識使系統即使在配置之間進行轉換時也可用於響應客戶端請求，它的主要目的是提升分布式系統的可用性。

⑵ 所謂「區塊鏈」是什麼

可以說，2020年是產業區塊鏈元年。隨著區塊鏈技術的不斷發展，積極布局區塊鏈的企業數量呈指數級增長。然而，區塊鏈還處在一個很早期的發展階段，區塊鏈應用落地仍需要不斷探索。
近十多年，區塊鏈技術已經在全球范圍內產生了廣泛的影響。相比誕生之初，區塊鏈行業的面貌發生了天翻地覆的變化。
前幾年的區塊鏈市場更像是2000年之前的互聯網，2000年之前的互聯網經歷了躁動期，也遇到過起起伏伏，然後大浪淘沙，真正有實力的企業才發展起來。
在參加Cointelegraph中文的活動時，Avalanche亞洲生態合夥人Wilson表示：「在2018年的時候，區塊鏈生態和現在完全不一樣，那個時候更多是概念式的。去年開始，區塊鏈行業發生了很大的差異。越來越多靠譜的項目誕生。」
的確，除了最初局限於在數字貨幣領域應用，如今區塊鏈技術已經逐漸成為不同傳統行業的基礎設施。經過十多年的探索與研發，區塊鏈也已經發現了更多能夠凸顯其價值的應用場景。
增長之勢不減，但仍未實現大規模應用
可以說，2020年是產業區塊鏈元年。隨著區塊鏈技術的不斷發展，積極布局區塊鏈的企業數量呈指數級增長。在新冠肺炎疫情爆發的大背景下，區塊鏈技術也展現出其巨大的待開發潛力。
在過去的一年，全球區塊鏈企業繼續呈增長趨勢，但是速度有所減緩。根據中國信息通信研究院的《區塊鏈白皮書（2020年）》數據顯示，截止至2020年9月，全球共有3709家區塊鏈企業，並主要分布在美國和中國，其中美國佔27%，中國佔24%。
顯而易見，隨著全球各個國家不斷出台向好的區塊鏈政策，推動區塊鏈技術賦能實體經濟，區塊鏈行業泡沫出凈，行業也回歸至理性。越來越多的企業跑步入場，積極利用區塊鏈技術拓展業務。
即使目前區塊鏈相關企業如雨後春筍般出現，但區塊鏈還處在一個很早期的發展階段。從最底層的協議層來說，離成熟和完整的狀態還很早。中間件層可能離成熟也非常遠，而中間件層可能是未來區塊鏈與真實的世界和實體經濟結合所需要的很重要的基礎設施。
當這些東西都已經逐漸走向標准化成熟的時候，我們才會迎來一個區塊鏈走向主流和大爆發的階段。
對於整個區塊鏈技術的發展狀況，Helium中國Managing Director高原指出：「現在各種區塊鏈應用的用戶體驗還不是很好，中間件的發展和用戶端的成熟，是實現大規模應用的關鍵點。最終區塊鏈能夠落地、能夠成為實體經濟的一部分，需要監管層面上的成熟和清晰的狀態。」
然而，區塊鏈應用落地仍需要不斷探索。如果區塊鏈底層基礎設施的性能不提高，未來的商業化大規模應用是很難實現的。那麼，大量區塊鏈應用沒有成功落地的原因是什麼呢？Polygon中國區負責人Charlie Hu認為：
一是對開發者不夠友好；
二是擴容性能有限；
三是缺乏互操作性，其核心邏輯就是未來區塊鏈世界不是只有一條鏈，是多鏈共存的。基於不同的商業應用有不同的鏈存在，跨鏈互操作性是很重要的。
為什麼互操作性對於不同區塊鏈至關重要？
區塊鏈的「互操性」，是指不同的區塊鏈網路之間能夠輕易實現相互通信，共享信息。互操作主要指應用層互操作、鏈間互操作、鏈下數據互操作。
IOHK首席執行官和Cardano創始人Charles Hoskinson在接受福布斯采訪時稱，區塊鏈的互操作性將帶來從一個系統到另一個系統的輕松遷移。
在區塊鏈行業中，一個能夠滿足用戶需求、並且運轉高效的區塊鏈是必需品，其地位舉重若輕。雖然以太坊創新的創造出智能合約技術，並構建了包含各式應用的超級生態系統，但它遠遠未能滿足商業需求，至少在以太坊2.0完全推出之前是這樣。
為什麼區塊鏈的互操性如此重要？隨著區塊鏈技術自身的不斷擴張以及在不同行業的應用拓展，不同鏈之間的難以互操作、不同應用之間的難以對接、鏈上鏈下的難以可信交互，這些問題在很大程度上限制了區塊鏈的大規模應用。
不同的區塊鏈之間的場景需求可能有所不同，而在這些不同需求下就需要產生大量交互。針對互操作性，Edge & Node 亞洲商務戰略負責人Iris表示：「如果鏈和鏈之間是孤島，就沒有辦法交互，這樣就會大大地影響應用。互操作性跨鏈是有不同層面的，從資產到數據，再到更底層的共識。很多項目已經實現了資產跨鏈，下一步比較難的就是數據跨鏈。」
只實現不同區塊鏈之間的互操作是遠遠不夠的。在雷兔科技創始人知縣看來，互操作性不應局限於區塊鏈生態內部，只有打通區塊鏈與互聯網之間的互操作性，才能實現用戶基數的最大化。
跨鏈技術是實現互操作性的關鍵。目前，跨鏈技術包括公證人機制、側鏈/中繼鏈、哈希時間鎖定和分布式私鑰控制等。
針對交互過程中的數據可信、安全問題，O3Labs 產品VP Tim認為，不同鏈的互操作性可能會有一些挑戰。他補充道：
第一，用戶體驗。產品做出來要面向更多的用戶，不管在企業中、機構中還是消費者，都會考慮到用戶體驗問題。即使在技術方面可以實現，但是也要在體驗方面能夠實現。
第二，安全性。不同鏈上會需要調一些鏈下的數據。不同鏈的方式不一樣，保證數據的准確很重要。因為這會變成一個基礎，如果未來在這個鏈上有很多應用的話，這些數據的准確性和速度等等就必須要很一致。
與傳統互聯網中注重隱私保護一樣，不同鏈之間以及鏈上鏈下交互過程中也要注重隱私保護問題。每一次交互都應避免交互過程中的隱私泄露。Suterusu CTO林煌對此表示，目前，跨鏈方面項目太多，可以看到有很多這方面的產品。然而，考慮支持多鏈的隱私保護的產品是比較少的，Suterusu現在已經做了很多隱私保護方面的工作，接下來會部署在一些鏈上。
區塊鏈的未來——多鏈並存
區塊鏈行業一直處在不斷的進化之中。除以太坊之外，還有很多抱有和以太坊一樣願景的區塊鏈涌現，比如EOS、Polkadot、Cosmos、Avalanche、Polygon等。
各個行業的發展競爭和合作是必然的，區塊鏈行業也是如此。只有競爭，才能不斷地創新。
未來，以太坊不會是「一超多強」，勢必會形成多鏈並存的局面。不同的公鏈以及不同的基礎設施會有一些差異化的競爭，最後通過跨鏈技術將這些不同鏈連接在一起。
在被問及區塊鏈的未來發展時，BSN發展聯盟常務理事兼北京紅棗科技有限公司CEO何亦凡展望：
3至5年後，特別是操作系統層越來越成熟的情況下，區塊鏈技術技術應該變成一個常規技術。如果開發者連傳統資料庫都不會使用，根本就不用工作了。3至5年後，每一個開發者應該會用區塊鏈技術搭建基本的應用。

⑶ 《區塊鏈項目開發指南》讀書筆記

ethash

答：在DAPP中，沒有一個中心伺服器來協調節點，或者決定什麼是對，什麼是錯，因此應對這個挑戰確實不容易，一致性協議（concensus protocol）可用於解決這個問題。
補充：共識演算法的核心就是解決拜占庭將軍問題（分布式網路一致性問題）。

答：修改bug或者更新DAPP很困難。

如果我需要從一個中心化應用抓取數據，如車輛違章信息，怎麼保證抓取的數據是真實有效的？
答：為了訪問中心化的API，可以使用Oraclize服務可以作為中間人，Oraclize為從中心化服務智能合約中抓取的數據提供TLSNotary驗證。

中心化應用的所有者需要有盈利才能長期維護應用的運行，而DAPP雖然沒有所有者，但是跟中心化應用一樣，DAPP節點需要硬體和網路資源才能維持運行。DAPP節點需要一些有用的回報來維持運行，於是內部貨幣登場了。大多數DAPP都有內置內部貨幣，或者可以說最成功的DAPP都有內置內部貨幣。如以太幣

授權的DAPP不對所有人開放。授權的DAPP繼承了免許可權DAPP的全部屬性，但需要許可權才能參與到網路中去。授權的DAPP與免許可權的DAPP的共識協議是不同的。授權的DAPP沒有內部貨幣。
超級賬本（Hyperledger）項目致力於開發創建授權的DAPP技術。

為什麼少數國家認定比特幣是非法的，大部分國家對此還沒有做出決定呢？原因如下：

星際文件存儲系統（InterPlanetary File System）是一個去中心化的文件系統。

目標是通過使交易幾乎瞬間完成，並隱藏交易賬戶的信息，還可以防止他人用ISP追蹤所有者。

任何人都可以成為以太坊網路中的礦工。每個礦工獨自解決問題，第一個解決問題的礦工是勝利者，它得到的回報是5個以太幣和該區塊中全部交易的交易費。區塊鏈中有多少個區塊沒有限制，可以生成的以太幣總數也沒有限制。

網路中的任何節點都可以檢查區塊鏈是否合法，首先檢查交易在區塊鏈中是否合法以及時間戳的驗證情況，然後檢查區塊的目標值和隨機數是否合法、礦工是否得到合法的回報等。

節點是如何發現網路中的其他節點的呢？
以太坊的節點發現協議：Kadelima，在這種協議中，有一種特殊節點Bootstrap節點。它保存了一段時間內與它連接的所有節點列表，但其本身不保存區塊鏈。
當對等節點連接到以太坊網路時，它們首先連接到Bootstrap節點。
可以有多種以太坊實例，也就是說，不同的網路每個都有自己的網路ID。
兩種主要的以太坊網路是主網和測試網。以太幣在主網上交易，而測試網供開發人員測試。

一個去中心化的通信協議，它支持廣播、用戶到用戶、加密信息等，但不用於傳輸大數據。

一個去中心化的文件系統。

geth為其他應用提供了與其通信的JSON-RPC API。使用HTTP、WebSocket和其他協議服務於JSON-RPC API。
JSON-RPC API提供的API分成如下類型：

以太坊網路中的節點默認用 30303 埠通信。

--networkid 用於指定網路ID，1代表主網網路ID，預設默認值為1，2代表測試網路ID
--dev 標記運行一個私有網路
--etherbase 指定挖礦賺取的回報存入的錢包地址
--unlock 解鎖一個或者多個賬戶

以太坊錢包與geth捆綁在一起。運行以太坊時，它會嘗試發現一個本地geth實例並與之連接；如果它不能發現geth正在運行，它就啟動自己的geth節點。以太坊錢包使用IPC與geth通信。geth支持以文件為基礎的IPC。

以太坊下一個主要更新的名字。Serenity把共識協議改為casper，並將整合狀態通道和分片。

Casper 實施了一個進程，使得它可以懲罰所有的惡意因素。這就是權益證明在Casper下是如何工作的：
驗證者押下一定比例的他們擁有的以太幣作為保證金。然後，他們將開始驗證區塊。也就是說，當他們發現一個可以他們認為可以被加到鏈上的區塊的時候，他們將以通過押下賭注來驗證它。
如果該區塊被加到鏈上，然後驗證者們將得到一個跟他們的賭注成比例的獎勵。但是，如果一個驗證者採用一種惡意的方式行動、試圖做「無利害關系」的事，他們將立即遭到懲罰，他們所有的權益都會被砍掉。正如你可以看到的，Casper被設計成可以在一個無需信任的系統上工作，並且是更加拜占庭容錯的。

支付通道 功能允許將兩個以上向另一個賬戶發送以太幣的交易合並成兩個交易。其工作原理為：假設X是一個視頻網站老闆，Y是個用戶。X每分鍾收費1個以太幣。現在X想讓Y看視頻期間每分鍾交一次錢。當然，Y可以每分鍾廣播交易，但是這里有些問題，例如X不得不等待確認，所以視頻就會中斷一會。支付通道可以解決這個問題。使用支付通道，Y可以廣播一個鎖定交易，為X把一些以太幣（比如100個以太幣）鎖定一段時間（比如24小時）。現在每看完一分鍾視頻，Y將發送一個簽名記錄表示可以解鎖，一個以太幣就進入X的賬戶，其餘的進入Y的賬戶。再過一分鍾，Y將發送一個簽名記錄表示可以解鎖，兩個以太幣就進入X的賬戶，其餘的進入Y的賬戶。Y觀看X網站的視頻過程中，該過程將持續。現在假設Y看完了100小時視頻或者24小時時間到了，X將向網路廣播最後的簽名記錄，以把錢收到自己的賬戶里。如果X沒有在24小時內提款，全款會返還給Y。所以在區塊鏈中，我們將看到lock和unlock兩種交易。

Sybil攻擊
51%攻擊
補充：不能存儲較大數據，目前有Swarm與IPFS等分布式存儲方式可供選擇

把所有東西都存在內存里，因此，節點一旦重啟，將丟失以前的狀態。
默認監聽埠：8545

⑷ 淺析 Fabric Peer 節點

Hyperledger Fabric，也稱之為超級賬本，是由 IBM 發起，後成為 Linux 基金會 Hyperledger 中的區塊鏈項目之一。

Fabric 是一個提供分布式賬本解決方案的平台，底層的賬本數據存儲使用了區塊鏈。區塊鏈平台通常可以分為公有鏈、聯盟鏈和私有鏈。公有鏈典型的代表是比特幣這些公開的區塊鏈網路，誰都可以加入到這個網路中。聯盟鏈則有準入機制，無法隨意加入到網路中，聯盟鏈的典型例子就是 Fabric。

Fabric 不需要發幣來激勵參與方，也不需要挖礦來防止有人作惡，所以 Fabric 有著更好的性能。在Fabric 網路中，也有著諸多不同類型的節點來組成網路。其中 Peer 節點承載著賬本和智能合約，是整個區塊鏈網路的基礎。在這篇文章中，會詳細分析 Peer 的結構及其運行方式。

在本文中，假設讀者已經了解區塊鏈、智能合約等概念。

本文基於 Fabric1.4 LTS。

區塊鏈網路是一個分布式的網路，Fabric 也是如此，由於 Fabric 是聯盟鏈，需要准入機制，所以在網路結構上會復雜很多，下面是一個簡化的 Fabric 網路：

各個元素的含義如下：

對於 Fabric 網路，外部的用戶需要通過客戶端應用，也就是圖中的 A1、A2 或者 A3 來訪問網路，客戶端應用需要通過 CA 證書表明自己的身份，這樣才能訪問到 Fabric 網路中有許可權訪問的部分。

在上面的網路中，共有四個組織，R1、R2、R3 和 R4。其中 R4 是整個 Fabric 網路的創建者，網路是根據 NC4 配置的。

在 Fabric 網路中，不同的組織可以組成聯盟，不同的聯盟之間數據通過 Channel 來隔離。Channel 中的數據只有該聯盟中的組織才能訪問，每一個新的 Channel 都可以認為是一條新的鏈。與其他的區塊鏈網路中通常只有一條鏈不一樣，Fabric 可以通過 Channel 在網路中快速的搭建出一個新的區塊鏈。

上面 R1 和 R2 組成了一個聯盟，在 C1 上交易。R2 同時又和 R3 組成了另外一個聯盟，在 C2 上交易。R1 和 R2 在 C1 上交易時，對 R3 是不可見的，R2 和 R3 在 C2 上交易時，對 R1 是不可見的。Channel 機制提供了很好的隱私保護能力。

Orderer 節點是整個 Fabric 網路共有的，用來為所有的交易排序、打包。比如上面網路中 O4 節點。本文不會對 Orderer 節點進行詳細說明，可以把這個功能理解為比特幣網路中的挖礦過程。

Peer 節點表示網路中的節點，通常一個 Peer 就表示一個組織，Peer 是整個區塊鏈網路的基礎，是智能合約和賬本的載體，Peer 也是本文討論的重點。

一個 Peer 節點可以承載多套賬本和智能合約，比如 P2 節點，既維護了 C1 的賬本和智能合約，也維護了 C2 的賬本和智能合約。

為了可以更深入了解 Peer 節點的作用，先了解一下 Fabric 整體的交易流程。整體的交易流程圖如下：

Peer 節點按照功能來分可以分為 背書節點 和 記賬節點 。

客戶端會提交交易請求到背書節點，背書節點開始模擬執行交易，在模擬執行之後，背書節點並不會去更新賬本數據，而是把這個交易進行加密和簽名，然後返回給客戶端。

客戶端收到這個響應之後就會把響應提交到 Orderer 節點，Orderer 節點會對這些交易進行排序，並打包成區塊，然後分發到記賬節點，記賬節點就會對交易進行驗證，驗證結束之後，就會把交易記錄到賬本裡面。

一筆交易是否能成功是根據背書策略來指定的，每一個智能合約都會指定一個背書策略。

Peer 節點代表著聯盟鏈中的各個組織，區塊鏈網路也是由 Peer 節點來組成的，而且也是賬本和智能合約的載體。

通過對上面交易過程的了解可以知道，Peer 節點是主要的參與方。如果用戶想要訪問賬本資源，都必須要和 peer 節點進行交互。在一個 Peer 節點中，可以同時維護多個賬本，這些賬本屬於不同的 Channel 。每個 Peer 節點都會維護一套冗餘賬本，這樣就避免了單點故障。

Peer 節點根據在交易中的不同角色，可以分成背書節點（Endorser）和記賬節點（Committer），背書節點會對交易進行模擬執行，記賬節點才會真正將數據存儲到賬本中。

賬本可以分成兩個部分，一部分是區塊鏈，另一部分是 Current State，也被稱之為 World State。

區塊鏈上只能追加，不能對過去的數據進行修改，鏈上也包含兩部分信息，一部分是通道的配置信息，另一部分是不可修改，序列化的記錄。每一個區塊記錄前一個區塊的信息，然後連成鏈，如下圖所示：

第一個區塊被稱之為 genesis block，其中不存儲交易信息。每個區塊可以被分為 區塊頭 、 區塊數據 和 區塊元數據 。區塊頭中存儲著當前區塊的區塊號、當前區塊的 hash 值和上一個區塊的 hash 值，這樣才能把所有的區塊連接起來。區塊數據中包含了交易數據。區塊元數據中則包括了區塊寫入的時間、寫入人及簽名。

其中每一筆交易的結構如下，在 Header 中，包含了 ChainCode 的名稱、版本信息。Signature 就是交易發起用戶的簽名。Proposal 中主要是一些參數。Response 中是智能合約執行的結果。Endorsements 中是背書結果返回的結果。

WorldState中維護了賬本的當前狀態，數據以 Key-Value 的形式存儲，可以快速查詢和修改，每一次對 WorldState 的修改都會被記錄到區塊鏈中。WorldState 中的數據需要依賴外部的存儲，通常使用 LevelDB 或者 CouchDB。

區塊鏈和 WorldState 組成了一個完整的賬本，World State 保證的業務數據的靈活變化，而區塊鏈則保證了所有的修改是可追溯和不可篡改的。

在交易完成之後，數據已經寫入賬本，就需要將這些數據同步到其他的 Peer，Fabric 中使用的是 Gossip 協議。Gossip 也是 Channel 隔離的，只會在 Channel 中的 Peer 中廣播和同步賬本數據。

智能合約需要安裝到 Peer 節點上，智能合約是訪問賬本的唯一方式。智能合約可以通過 Go、Java 等變成語言進行編寫。

智能合約編寫完成之後，需要打包到 ChainCode 中，每個 ChainCode 中可以包含多個智能合約。ChainCode 需要安裝，ChainCode 需要安裝到 Peer 節點上。安裝好了之後，ChainCode 需要在 Channel 上實例化，實例化的時候需要指定背書策略。

智能合約在實例化之後就可以用來與賬本進行交互了，流程圖如下：

用戶編寫並部署實例化智能合約之後，就可以通過客戶端應用程序來向智能合約提交請求，智能合約會對 WorldState 中數據進行 get、put 或者 delete。其中 get 操作直接從 WorldState 中讀取交易對象當前的狀態信息，不會去區塊鏈上寫入信息，但 put 和 delete 操作除了修改 WorldState，還會去區塊鏈中寫入一條交易信息，且交易信息不能修改。

區塊鏈上的信息可以通過智能合約訪問，也可以在客戶端應用通過 API 直接訪問。

Event 是客戶端應用和 Fabric 網路交互的一種方式，客戶端應用可以訂閱 Event，當 Event 發生時，客戶端應用就會接受到消息。

事件源可以兩類，一類是智能合約發出的 Event，另一類是賬本變更觸發的 Event。用戶可以從 Event 中獲取到交易的信息，比如區塊高度等信息。

在這篇文章中，首先介紹了 Fabric 整體的網路架構，通過對 Fabric 交易流程的分析，討論了 peer 節點在交易中的作用，然後詳細分析了 peer 節點所維護的賬本和智能合約，並分析了 peer 節點維護賬本以及 peer 節點執行智能合約的流程。

文 / Rayjun

[1] https://hyperledger-fabric.readthedocs.io/zh_CN/release-1.4/whatis.html

[2] https://developer.ibm.com/zh/technologies/blockchain/series/os-academy-hyperledger-fabric/

[3] https://en.wikipedia.org/wiki/Gossip_protocol

⑸ 區塊鏈論文精讀——Pixel: Multi-signatures for Consensus

論文主要提出了一種針對共識機制PoS的多重簽名演算法Pixel。

所有基於PoS的區塊鏈以及允許的區塊鏈均具有通用結構，其中節點運行共識子協議，以就要添加到分類賬的下一個區塊達成共識。這樣的共識協議通常要求節點檢查阻止提議並通過對可接受提議進行數字簽名來表達其同意。當一個節點從特定塊上的其他節點看到足夠多的簽名時，會將其附加到其分類帳視圖中。

由於共識協議通常涉及成千上萬的節點，為了達成共識而共同努力，因此簽名方案的效率至關重要。此外，為了使局外人能夠有效地驗證鏈的有效性，簽名應緊湊以進行傳輸，並應快速進行驗證。已發現多重簽名對於此任務特別有用，因為它們使許多簽名者可以在公共消息上創建緊湊而有效的可驗證簽名。

補充知識： 多重簽名
是一種數字簽名。在數字簽名應用中，有時需要多個用戶對同一個文件進行簽名和認證。比如，一個公司發布的聲明中涉及財務部、開發部、銷售部、售後服務部等部門，需要得到這些部門簽名認可，那麼，就需要這些部門對這個聲明文件進行簽名。能夠實現多個用戶對同一文件進行簽名的數字簽名方案稱作多重數字簽名方案。
多重簽名是數字簽名的升級，它讓區塊鏈相關技術應用到各行各業成為可能。 在實際的操作過程中，一個多重簽名地址可以關聯n個私鑰，在需要轉賬等操作時，只要其中的m個私鑰簽名就可以把資金轉移了，其中m要小於等於n，也就是說m/n小於1，可以是2/3, 3/5等等，是要在建立這個多重簽名地址的時候確定好的。

本文提出了Pixel簽名方案，這是一種基於配對的前向安全多簽名方案，可用於基於PoS的區塊鏈，可大幅節省帶寬和存儲要求。為了支持總共T個時間段和一個大小為N的委員會，多重簽名僅包含兩個組元素，並且驗證僅需要三對配對，一個乘冪和N -1個乘法。像素簽名幾乎與BLS多重簽名一樣有效，而且還滿足前向安全性。此外，就像在BLS多簽名中一樣，任何人都可以非交互地將單個簽名聚合到一個多簽名中。

有益效果：
為了驗證Pixel的設計，將Pixel的Rust實施的性能與以前的基於樹的前向安全解決方案進行了比較。展示了如何將Pixel集成到任何PoS區塊鏈中。接下來，在Algorand區塊鏈上評估Pixel，表明它在存儲，帶寬和塊驗證時間方面產生了顯著的節省。我們的實驗結果表明，Pixel作為獨立的原語並在區塊鏈中使用是有效的。例如，與一組128位安全級別的N = 1500個基於樹的前向安全簽名（對於T = 232）相比，可以認證整個集合的單個Pixel簽名要小2667倍，並且可以被驗證快40倍。像素簽名將1500次事務的Algorand塊的大小減少了約35％，並將塊驗證時間減少了約38％。

對比傳統BLS多重簽名方案最大的區別是BLS並不具備前向安全性。

對比基於樹的前向安全簽名，基於樹的前向安全簽名可滿足安全性，但是其構造的簽名太大，驗證速度有待提升。 本文設計減小了簽名大小、降低了驗證時間。

補充知識： 前向安全性
是密碼學中通訊協議的安全屬性，指的是長期使用的主密鑰泄漏不會導致過去的會話密鑰泄漏。前向安全能夠保護過去進行的通訊不受密碼或密鑰在未來暴露的威脅。如果系統具有前向安全性，就可以保證在主密鑰泄露時歷史通訊的安全，即使系統遭到主動攻擊也是如此。

構建基於分層身份的加密（HIBE）的前向安全簽名，並增加了在同一消息上安全地聚合簽名以及生成沒有可信集的公共參數的能力。以實現：
1、生成與更新密鑰
2、防止惡意密鑰攻擊的安全性
3、無效的信任設置

對於常見的後攻擊有兩種變體：
1、短程變體：對手試圖在共識協議達成之前破壞委員會成員。解決：通過假設攻擊延遲長於共識子協議的運行時間來應對短距離攻擊。
2、遠程變體：通過分叉選擇規則解決。
前向安全簽名為這兩種攻擊提供了一種干凈的解決方案，而無需分叉選擇規則或有關對手和客戶的其他假設。（說明前向安全簽名的優勢）。

應用於許可的區塊鏈共識協議（例如PBFT）也是許多許可鏈（例如Hyperledger）的核心，在這些區塊鏈中，只有經過批準的方可以加入網路。我們的簽名方案可以類似地應用於此設置， 以實現前向保密性，減少通信帶寬並生成緊湊的塊證書。

傳統Bellare-Miner 模型，消息空間M的前向安全簽名方案FS由以下演算法組成：
1、Setup
pp ←Setup(T), pp為各方都同意的公共參數，Setup(T)表示在T時間段內對於固定參數的分布設置。

2、Key generation
(pk,sk1) ←Kg
簽名者在輸入的最大時間段T上運行密鑰生成演算法，以為第一時間段生成公共驗證密鑰pk和初始秘密簽名密鑰sk1。

3、Key update
skt+1←Upd(skt) 簽名者使用密鑰更新演算法將時間段t的秘密密鑰skt更新為下一個周期的skt + 1。該方案還可以為任何t0> t提供 「快速轉發」更新演算法 skt0←$ Upd0（skt，t0），該演算法比重復應用Upd更有效。

4、Signing
σ ←Sign(skt,M),在輸入當前簽名密鑰skt消息m∈M時，簽名者使用此演算法來計算簽名σ。

5、Verification
b ← Vf(pk,t,M,σ)任何人都可以通過運行驗證演算法來驗證消息M在公共密鑰pk下的時間段t內的簽名M的簽名，該演算法返回1表示簽名有效，否則返回0。

1、依靠非對稱雙線性組來提高效率，我們的簽名位於G2×G1中而不是G2 ^2中。這樣，就足以給出公共參數到G1中（然後我們可以使用散列曲線實例化而無需信任設置），而不必生成「一致的」公共參數（hi，h0 i）=（gxi 1，gxi 2）∈G1× G2。

2、密鑰生成演算法，公鑰pk更小，參數設置提升安全性。

除了第3節中的前向安全簽名方案的演算法外，密鑰驗證模型中的前向安全多重簽名方案FMS還具有密鑰生成，該密鑰生成另外輸出了公鑰的證明π。
新增Key aggregation密鑰匯總、Signature aggregation簽名匯總、Aggregate verification匯總驗證。滿足前向安全的多重簽名功能的前提下也證明了其正確性和安全性。

1、PoS在後繼損壞中得到保護
後繼損壞：後驗證的節點對之前的共識驗證狀態進行攻擊破壞。
在許多用戶在同一條消息上傳播許多簽名（例如交易塊）的情況下，可以將Pixel應用於所有這些區塊鏈中，以防止遭受後繼攻擊並潛在地減少帶寬，存儲和計算成本。

2、Pixel整合
為了對區塊B進行投票，子協議的每個成員使用具有當前區塊編號的Pixel簽署B。當我們看到N個委員會成員在同一塊B上簽名的集合時，就達成了共識，其中N是某個固定閾值。最後，我們將這N個簽名聚合為單個多重簽名Σ，而對（B，Σ）構成所謂的 區塊證書 ，並將區塊B附加到區塊鏈上。

3、注冊公共密鑰
希望參與共識的每個用戶都需要注冊一個參與簽名密鑰。用戶首先採樣Pixel密鑰對並生成相應的PoP。然後，用戶發出特殊交易（在她的消費密鑰下簽名）， 注冊新的參與密鑰 。交易包括PoP。選擇在第r輪達成協議的PoS驗證者，檢查（a）特殊交易的有效性和（b）PoP的有效性。如果兩項檢查均通過，則 使用新的參與密鑰更新用戶的帳戶 。從這一點來看，如果選中，則用戶將使用Pixel登錄塊。
即不斷更換自己的參與密鑰，實現前向安全性。

4、傳播和聚集簽名
各個委員會的簽名將通過網路傳播，直到在同一塊B上看到N個委員會成員的簽名為止。請注意，Pixel支持非互動式和增量聚合：前者意味著簽名可以在廣播後由任何一方聚合，而無需與原始簽名者，而後者意味著我們可以將新簽名添加到多重簽名中以獲得新的多重簽名。實際上，這意味著傳播的節點可以對任意數量的委員會簽名執行中間聚合並傳播結果，直到形成塊證書為止。或者，節點可以在將塊寫入磁碟之前聚合所有簽名。也就是說，在收到足夠的區塊證明票後，節點可以將N個委員會成員的簽名聚集到一個多重簽名中，然後將區塊和證書寫入磁碟。

5、密鑰更新
在區塊鏈中使用Pixel時，時間對應於共識協議中的區塊編號或子步驟。將時間與區塊編號相關聯時，意味著所有符合條件的委員會成員都應在每次形成新區塊並更新輪回編號時更新其Pixel密鑰。

在Algorand 項目上進行實驗評估，與Algorand項目自帶的防止後腐敗攻擊的解決方案BM-Ed25519以及BLS多簽名解決方案做對比。

存儲空間上：

節省帶寬：
Algorand使用基於中繼的傳播模型，其中用戶的節點連接到中繼網路（具有更多資源的節點）。如果在傳播過程中沒有聚合，則中繼和常規節點的帶寬像素節省來自較小的簽名大小。每個中繼可以服務數十個或數百個節點，這取決於它提供的資源。

節省驗證時間

⑹ 通俗易懂的講清楚什麼是區塊鏈

區塊鏈在某種意義上可以理解為一種資料庫系統。區塊鏈發展到現今可以劃分為1.0和2.0
1.0以比特幣為代表，主要應用已虛擬貨幣或者說數字貨幣應用。此時的區塊鏈只能用於簡單的數字貨幣交易。
2.0以現在比較流行的ethereum(以太坊）和即將問世的hyperledger為代表。這個階段的區塊鏈不僅能滿足對應的數字貨幣交易，還可以利用 智能合約 自定義的貨幣或者資產的交易。如果還以資料庫做類比的話，智能合約的出現可以理解為允許用戶在資料庫中定義函數（function）或者存儲過程（procere），並調用執行了。

和傳統的資料庫不同的是，區塊鏈的內部引入了共識機制，激勵機制，p2p（網路），hash等一些特定的元素，讓它具備了 公開、去中心化、不可篡改的特性。

⑺ 《深度探索區塊鏈：Hyperledger技術與應用》pdf下載在線閱讀，求百度網盤雲資源

《深度探索區塊鏈：Hyperledger技術與應用》（張增駿）電子書網盤下載免費在線閱讀

資源鏈接：

鏈接:

提取碼: swv1

書名：深度探索區塊鏈：Hyperledger技術與應用

作者：張增駿

豆瓣評分：6.0

出版社：機械工業出版社

出版年份：2018-2-1

頁數：308

內容簡介：

本書由超級賬本執行董事Brian Behlendorf領銜推薦，區塊鏈一線落地實踐團隊、Hyperleger會員智鏈骨幹團對撰寫。深入講解Hyperledger Fabric 1.0的架構、執行邏輯、核心功能實現、從零部署，並以票據案例為例，講解具體開發實踐，穿插開發所需的*佳實踐和遇到的問題解決。

本書分三篇，共12章內容。

准備篇（第1～2章），高度濃縮、信息量大的第1章，揭示區塊鏈的價值、核心理念、演進、主流平台、商用場景。第2章進入實踐環節，涵蓋安裝、部署與調試，讓讀者初步直觀感受區塊鏈，培養學習和實踐的興趣。

核心篇（第3～9章），先從Fabric1.0架構開始講解，方便讀者了解整體結構與運作邏輯，帶著問題與輪廓去閱讀，事半功倍。第4～9章講解內部實現機制，該篇並不點到為止，而是深入到底層實現原理層面，讓讀者透徹了解Fabric的設計與實現細節，該篇是理解區塊鏈設計與實現的關鍵所在，也是日後做好應用開發的基礎，有了問題可以自己動手解決。

涵蓋以下幾個方面：

區塊鏈架構、組件關系與運行機制總覽；

Gossip協議與P2P數據分發機制；

分布式賬本數據相關的存儲技術；

共識機制及其可插拔的架構設計；

如何實現數據隔離的多鏈與多通道；

基於數字證書的成員管理服務實現與使用；

智能合約實現、交互，以及有限狀態機。

應用篇（10～12章），從安裝部署、開發模型和應用開發的角度，以一個票據背書的案例講解如何基於Hyperledger Fabric 1.0開發區塊鏈應用，以完整地掌握區塊鏈應用開發，動手實踐具體的項目。

作者簡介：

張增駿 智鏈ChainNova技術總監和架構師。十餘年軟體開發和項目管理經驗，設計並實現了多個區塊鏈項目，帶領團隊獲得「2017可信區塊鏈峰會」唯*非金融類*佳案例獎。中國信通院可信區塊鏈專家委員會成員，參與討論並推動可信區塊鏈測試標準的制定，多次受邀到高校與企業分享與推動區塊鏈落地工作。曾任綠盟科技PDT經理，帶領團隊研發的遠程安全評估系統（RSAS）連續多年國內排名*一，廣泛應用於多個重點領域。目前關注區塊鏈、網路安全、大數據、雲計算和人工智慧等領域。

董寧 智鏈 ChainNova科技公司CEO，北京大學（天津濱海）新一代信息技術研究院金融科技研究中心主任。曾任IBM大中華區IT經濟學負責人，參與過數家商業銀行和金融機構核心系統的設計建設，具有多年金融行業的商業洞察。畢業於北京大學信息科學技術學院智能科學系。

朱軒彤 清華大學碩士，中國社會科學院數量經濟與技術經濟研究所博士生，專注於技術經濟研究。在政府及國際組織有豐富的工作經驗。

陳劍雄 智鏈ChainNova首席科學家，原金山雲技術VP，中科院計算與通信工程學院碩士。多年大規模集群系統研發經驗，參與多個區塊鏈核心系統設計和應用。

⑻ 如何通俗的理解ibm區塊鏈技術hyperledger-fabric中的共識演算法pbft

1、區塊鏈的技術是什麼? 如果我們把資料庫假設成一本賬本，讀寫資料庫就可以看做一種記賬的行為，區塊鏈技術的原理就是在一段時間內找出記賬最快最好的人，由這個人來記賬，然後將賬本的這一頁信息發給整個系統里的其他所有人。

⑼ 如何學習區塊鏈技術

1、技術語言

Python和Go這兩門語言是眾多公司招聘都提到的技術語言。需要優先學習。而且這兩種語言在區塊鏈之外的技術方向也有很大的應用。比如Go用在大並發系統的後台構築，Python用於人工智慧系統構築。所以學習這兩門語言是優先考慮的問題。

2、技術框架

掌握Bitcoin、ETH和Hyperledger的一種或多種。BTC就不用說了，底層是C++寫的，大量的貨幣類項目，如萊特幣，dash，門羅，zcash等都使用比特幣的技術進行二次開發。

ETH則是區塊鏈2.0的代表，可以在ETH網路上構建各種各樣的應用類Dapp。現在大量的應用類區塊鏈項目都是使用ETH平台開發的。

Hyperledger fabric則是IBM力推的區塊鏈開發平台，主要用於聯盟鏈的開發，是目前普及度最高的聯盟鏈開發平台。

3、演算法

POW（工作量證明演算法），POS（權益證明演算法），PBFT（拜占庭容錯演算法）等都是區塊鏈中密碼學部分的重要組成，對於這些演算法有充分的了解，有利於你參加區塊鏈項目底層開發時能夠對密碼學的部分有更好的理解。

(9)hyperledger區塊鏈報錯擴展閱讀：

區塊鏈技術就是一種分布式記賬技術，它的特點就是去中心化、公開透明，讓每個人都可以參與資料庫建立，而且每個建立的數據又是不可篡改的，大家都參與了，陌生人之間的信任問題也就解決了。

區塊鏈技術出現了，它是個全民參與的記賬技術，AB之間的交易信息和數據公布於眾，而且是不可篡改的，大家都知道有這個事情的發生，那麼這里就不需要什麼權威的第三方C了，或者說系統里的每一個都是充當了C的角色，這也叫做去中心化。