1.Hyperledger基礎學習

HyperLedger基礎

本文是參考資料1的學習記錄。

1、概述

1 區塊鏈的特徵

1. 一樣的商業參與方，並非脫媒的遊戲

2. 共識（CONSENSUS）– 全部的參與方認同交易的有效性

3. 可證實性（PROVENANCE）– 每一個參與方瞭解資產從哪裏來，其全部權是如
   何改變的。

4. 永恆性（IMMUTABILITY）– 每一個參與方一旦交易被贊成發生則沒法篡改。
   若是交易是錯誤的，必須由新交易衝正並全可跟蹤

5. 權威性（FINALITY）– 只有一個地方來決定資產的歸屬權及交易的完整性。
   這就是共享帳本的做用

2 hyperledger項目

圖1 hyperledger項目

超級帳本項目主要包括如下幾個項目：

1. hyperledger fabric。區塊鏈技術實現項目，採用golang語言實現，是目前幾個子項目中最成熟的。項目狀態：active。

2. sawtoothlake。高度模塊化分佈式帳本平臺,採用python實現。結合intel芯片功能，實現poet consensus,提供transaction template。

3. iroha。輕量級分佈式帳本，側重於在移動端。採用c++實現，實現sumeragi consensus。

4. blockchain explorer。展現和查詢區塊鏈塊、事務和相關數據的web應用。採用node.js實現,實際上是一個ui。

5. cello。Baas的工具集，幫助建立、管理、終止區塊鏈。採用python、javascript實現。服務封裝
   支持多種底層架構，支持容器化，區塊鏈即服務

6. fabric sdk項目。爲開發者提供fabric的調用。

2、HyperLedger架構

（一） v0.6架構

v0.6邏輯架構

v0.6網絡結構

v0.6運行時架構

（二） v1.0架構

目標：可伸縮性、性能、安全隔離、可插拔性、可操做性。

新增功能：多通道、事務隔離（子帳本）、可插拔組件（db、ca、共識算法等）、更多類型chainCode。。。

1 邏輯架構

1.0邏輯架構同0.6，可是網絡拓撲圖不同了。0.6版本至少須要4個validate point，而在1.0中進行了拆分。在原來的0.6中，進行vp節點的擴展是很困難的（緣由todo）；而通過1.0拆分後，新加盟的聯盟節點能夠是endorse或commit，難度大大下降。以下圖：

2 運行時架構

下圖爲兩個版本的運行時架構區別。右側是1.0中將原0.6的peer節點拆分紅了幾個邏輯單元。之後的圖中，通常E表明Endorser，C表示Committer，O表明o-service

3 多鏈與通道

v1.0支持多鏈，鏈將參與者和數據（包含chaincode） 進行隔離。鏈=Peers + Ledger + Ordering Channel。一個Peer節點能夠參與多個鏈，因此須要考慮按照什麼業務邏輯去進行劃分鏈。支持鏈的做用是，一部分數據的影響能夠限制在本身的鏈中，而不影響其餘數據。

Channel（通道）提供一種通信機制，將peer和orderer鏈接在一塊兒， 造成一個個具備保密性的通信鏈路（虛擬）。Fabric的區塊鏈網絡缺省包含一個帳本（稱爲：系統帳本） 和一個通道。子帳本能夠被建立， 並綁定到一個通道。

4 事務

一次事務的執行：

transaction proposal.應用向一個或多個peer節點發送對事務的背書請求；

chaincode。 背書節點執行cc，但並不將結果提交到本地帳本，只是將結果返回給應用；

Endorse - Order - validate。應用收集全部背書節點的結果後，將結果廣播給orderers。

store in ledger。Orderers執行共識工程，生成block，經過消息通道批量的將block發佈給peer節點。

每一個ChainCode在部署時， 都需 要和背書（ESCC）和驗證（VSCC）的系統ChainCode關聯。ESCC決定如何對proposal進行背書；VSCC決定事務的有效性（包括背書的正確性）。

5 ledger

Block結構：文件系統存儲。State狀態： KV數據庫維護。

6 運行

推薦的運行模式，各個類型的節點統一運行在docker容器（輕量級容器）中，便於統一發布、部署。

3、ChainCode

chaincode是部署在fabric區塊鏈網絡節點上的一個接口的實現代碼，是與fabric區塊鏈交互的惟一渠道。cc是生成Transaction的惟一來源。

語言：go、java。推薦go，須要依賴shim模塊。

兩種運行模式：

通常模式，運行在docker容器中。開發調試繁瑣。

開發模式，-peer-chaincodedev;運行在本地，開發調試較爲容易。

p7 運行原理。開發註冊過程，屢次與peer界面交互

transaction，一次chaincode函數的運行。world state：全部變量的值的集合

說明：world state能夠用來存儲真正的業務數據，包括存證信息、用戶操做記錄等；transaction能夠用來執行用戶的存證的流程，設置對應的state；

0.6底層採用的是kv，不支持table的操做，因此這類api有性能損失。注意接口中的參數廣義適配性。

channel，通道、子鏈。同一peer能夠加入不一樣channel。cc操做基於channel進行。同一channel上的peer節點同步其上執行的結果。

endorser，模擬執行chaincode。分離計算任務，減輕consensus節點負擔。支持endorsement policy。

orderer，對cc執行結果consensus。solo/kafaka/sbft

committer，將cc執行結果寫入ledger。

4、共享帳本

區塊鏈是一種容許網絡成員查看記錄的共享帳本技術。

（一）帳本

Block ledger

• File system based, only new Blocks appending。基於文件系統，只能添加新區塊。

• Blocks are stored on all committers and optional subset of ordering service nodes。在因此c節點存儲，o節點也可能存儲。

State ledger

• World/Ledger state holds current value of smart contract data。世界狀態反映了當前的合約狀態，如vehicleOwner=Daisy

• KVS hidden from developer by chaincode APIs
  e.g. GetState(), PutState(), GetStateByRange(), etc...。經過cc api訪問kv值。

• Stored on all committers。全部c節點存儲

History ledger

• Holding historic sequence of all chain code transactions
  e.g. updateOwner(from=John, to=Anthony); updateOwner (from=Anthony, to=Daisy);etc。全部cc事務

• Index stored in KVS and hidden from developer by chaincode APIs e.g. GetHistoryForKey()

• Stored on all committers

（二）事務生命週期

transaction事務是資產的轉移操做。contract合約是事務發生的條件。

readwriteset的邏輯結構

Block{ Transac`ons [

{

"Id" : txUUID2

"Invoke" : 「Method(arg1, arg2,..,argN)"

「TxRWSet" : [

{ 」Chaincode」 : 「ccId」

「Reads」:[{"key" : 「key1", "version」 : 「v1」 }]

「Writes」:[{"key" : 「key1", 」value" : bytes1}]

} // end chaincode RWSet ] // end TxRWSet

}, // end transac`on with "Id" txUUID2

{ // another transacon }, ] // end Transacons

}// end Block

5、共識機制

1 machine fault

(1) Crash faults (CFT): A machine simply stops execuUon and halts，即簡單的停機不響應。對應算法：Paxos, RAFT, Zookeeper AB,...

(2) Non-crash (a.k.a. ByzanUne) faults (BFT) .有內奸！可能會有做假節點

2 區塊鏈的意義：從一個企業內的it治理建設，帶到企業間的it治理建設。

3 分佈式系統沒有全局時鐘

4 超級帳本與比特幣、以太坊的不同之處：

（1）比特幣會先記帳，那麼有分叉的產生

（2）此處提出的算法，不是先記帳，而是先取得共識。共識的工做節點先作完該作的運算，而後你們比較結果，而後再把承認的結果寫進帳本。不會產生分叉。

（3）此處的記帳節點，也是比較穩定的，可是同時須要注意，記帳的是一個節點集合，你們共同記帳。先對當前的操做集合的數量、內容、順序達成一致，而後再同時記帳。由於以前的帳本一致，而本次的操做順序也一致，那麼新的狀態必然一致。

（4）這裏看，和咱們設計的隨機記帳的方式還不大同樣。

5 pbft其中存在一個validating leader，經過leader來協調你們的一直狀態。

7 可能的影響一致性的因素

不肯定的value

leader選舉

傳輸慢

從新配置困難

8 p16.endorsement policies:channel互不影響;ordering service排序是很重要的工做;加入一個odering節點很困難；新加入節點的時候，不是ordering節點則困難不大。

6、隱私與安全

1 數字證書採用公鑰體制:

數字證書是」 公鑰+證書名稱信息+簽發機構對證書的數字簽名」 、 匹配的私鑰

數字證書聽從X.509國際標準

2 由交易「提交方」 使用本身的「數字證書」 對每一個交易作 「數字簽名」 來確保交易沒法僞造

3 利用數字簽名，僞造一個他人的單個交易很是困難，除非可以得到他人數字證書的私鑰。分佈式帳本能夠防止以下類型的篡改：刪除歷史交易；僞造本身的歷史交易。

4 對稱加密和公鑰加密

應用

參考數據架構。這個一個過渡期的架構。

參考資料

1. HyperLedger Fabric系列微講堂

2. HyperLedger Docs