Fabric 2.0 之賬本(Ledger)

  參考資料（官方文檔）:Ledger

Ledger

  在Hyperledger Fabric裏面,賬本由兩個不同但相關的部分組成:世界狀態(world state)和區塊鏈(blockchain).
  世界狀態數據庫保存了賬本中最新的值，世界狀態使程序可以直接訪問當前狀態數據庫的值，無需遍歷所有的交易日誌。世界狀態可以頻繁更改（創建/更新/刪除）
  而區塊鏈中記錄當前世界狀態的所有更改的交易日誌，交易是附加到區塊內部的，可追溯。區塊鏈的數據結構與世界狀態不同，一旦寫入無法修改。

  實際網絡中，通過共識維護了一個賬本的多個副本。

世界狀態（World State）

  世界狀態維護了對象的最新值，這是很有用的。無需遍歷整個區塊鏈來計算當前的值，從世界狀態獲取即可。

  世界狀態都會有個版本號，版本號初始爲0，每次狀態更改時都會遞增，同時每次更新時都需要做版本校驗。有一點需要注意，當首次創建賬本時，世界狀態爲空，因爲任何代表世界狀態有效改變的交易都記錄在區塊鏈上，意味着隨時可以從區塊鏈生成世界狀態。例如當節點創建/重啓時自動生成世界狀態。

區塊鏈（Blockchain）

  區塊鏈通過區塊互聯順序記錄日誌，其中每個區塊都會包含一系列交易（世界狀態的查詢或是更新）。每個區塊的頭均包含該區塊交易的哈希值，以及前一個區塊的頭的哈希值。

  與使用數據庫的世界狀態相反，區塊鏈通過文件實現。這是一個明智的設計選擇，因爲每次追加到區塊鏈的末尾是主要操作，而查詢是相對不頻繁的操作。

  如上圖所示，區塊鏈中的第一個塊稱爲創世塊（genesis block）。 儘管它不包含任何用戶交易，但它是賬本的開始。

區塊（Block）

  如下圖所示，每個區塊主要包含三個部分：
  區塊頭：包含三個字段，伴隨區塊創建寫入。

1. 區塊號（Block number）：從0（創世塊）開始的整數，每次新生成區塊時加1
2. 當前區塊哈希（Current Block Hash）：當前區塊所有交易的哈希
3. 上一區塊哈希（Previous Block Header Hash）：上一個區塊頭的哈希
   

  區塊數據（Block Data）：按順序排列的交易（下節介紹）列表。

  區塊元數據：包含塊創建者的證書和簽名，用於通過網絡節點驗證塊。 隨後，塊提交者將每個事務的有效/無效指示符添加到也駐留在塊元數據中的位圖中，以及直到（包括）該塊爲止的累積狀態更新的哈希，以檢測狀態派生。 與塊數據和區塊頭字段不同，此部分不是塊哈希計算的輸入。

交易（Transaction）

  下圖爲交易的結構：

  主要包括以下五部分：

1. Header：包含交易的一些元數據，例如鏈碼的名稱及版本
2. Signature：包含由客戶端應用程序創建的加密簽名。 此字段用於檢查交易明細是否未被篡改，因爲它需要應用程序的私鑰來生成它。
3. Proposal：應用程序提供給智能合約進行模擬賬本執行的輸入參數的數據結構。
4. Response： 它是智能合約的輸出，如果交易成功通過驗證，將更新世界狀態，包含了讀寫集等信息。
5. Endorsements：各個組織的背書籤名，每個組織的簽名的都是特定的，當背書籤名數量不足，視爲無效交易。

世界狀態數據庫選擇

  LevelDB是默認的狀態數據庫，LevelDB是節點內嵌數據庫，適合簡單的key-value形式的數據。

  當數據爲JSON格式時，CouchDB是一個特別合適的選擇，因爲CouchDB支持富查詢。在實現方面，CouchDB在單獨的操作系統進程中運行。
  關於啓用CouchDB參考:Fabric啓用CouchDB

通道

  前文我們將賬本呈現爲一個單一的世界狀態和單個區塊鏈，但這還是有點過分簡化了。 實際上，每個鏈碼都有自己的世界狀態，該世界狀態與所有其他鏈碼是分開的。 世界狀態位於命名空間（namespace）中，因此只有相同鏈代碼內的智能合約才能訪問給定的命名空間。

  在Hyperledger Fabric中，每個通道都有一個完全獨立的賬本。 這意味着完全獨立的區塊鏈，以及完全獨立的世界狀態，包括名稱空間。 應用程序和智能合約可以在通道之間進行通信，以便可以在它們之間訪問賬本信息。