>[info] 原文地址：https://github.com/hyperledger/fabric/blob/master/proposals/r1/Next-Consensus-Architecture-Proposal.md
本文檔介紹了一個區塊鏈基礎設施的體系結構。這里面一個區塊鏈節點的角色分為peers角色【對等體角色】（維護狀態/賬本），和orderers角色【訂閱者角色】（對于賬本中事務處理順序達成共識者）。在常見的區塊鏈架構中（包括Hyperledger Fabric v0.6及之前版本），這些角色都是統一的（參見：Hyperledger Fabric v0.6中的validating peer【驗證對等體】）。該架構還引入了endorsing peers（即endorsers）【簽名對等體】，作為負責模擬執行和簽名事務（大致對應于在HL Fabric 0.6中處理事務的過程）的特殊類型對等體
該架構相比于那些把peers/orderers/endorsers設計為一個的架構（比如，HL Fabric v0.6），有如下優勢：
* **鏈碼信任的靈活性。** 該架構將鏈碼（區塊鏈上的應用程序）的信任假設與ordering【用于排序】的信任假設區分開來。換句話說，排序服務可以由一系列節點（orderers）提供，并且可以容忍它們中有一些失敗或行為不正確，而且對于每一個鏈碼，endorsers可以不同
* **可擴展性。** 由于負責特定鏈碼的endorser節點，與orderers節點是不相關的【orthogonal，正交的】，所以相對于這些功能都是由同樣的節點來完成的系統，該系統可以具有更好的擴展性。尤其是當不同的鏈碼指定了不相關的endorsers的情況下，在endorsers中引發了鏈碼的分割，這樣就可以允許鏈碼并行執行（endorsement）。此外，那些可能會非常耗時的鏈碼執行，也從ordering服務的關鍵路徑中移除了。
* **保密性。** 對于那些需要內容保密，和事務狀態更新保密的鏈碼，使用該架構可以更方便部署。
* **共識模塊化。** 該架構是模塊化的，并且允許插件式的共識機制實現（比如，ordering service）
這個架構驅動了Hyperledger Fabric v0.6之后版本的開發。下面詳述的部分，有些方面會包含在Hyperledger Fabric v1中，而其它部分會延緩至v1之后的版本中。
#### **目錄**
**第一部分：和Hyperledger Fabric v1相關的架構細節**
1. 系統架構
2. 事務背書【transaction endorsement】的基本工作流
3. 支持策略【Endorsement policies】
**第二部分：v1后續版本的架構細節**
4. 賬本檢查點（剪枝）
* * * * *
**1. 系統架構**
區塊鏈是一個分布式系統，包含了很多節點，他們之間互相通信。區塊鏈上運行的程序被稱為鏈碼，它們維護狀態，和賬本數據，以及處理事務。鏈碼是核心要素，因為事務是在鏈碼上調用的操作。事務必須是“可信的【endorsed】”，并且只有可信的事務才會被提交然后對狀態產生影響。可能存在一個或多個特殊的鏈碼，來管理函數和參數，統稱為系統鏈碼。
**1.1. 事務**
事務可能有2種類型：
* *部署類事務*，產生新的鏈碼，接收一個程序作為參數。當一個部署類事務執行成功，相應的鏈碼就安裝在了區塊鏈上。
* *調用類事務*，在之前部署的鏈碼上下文環境中執行一個操作。一個調用類事務引用一個鏈碼和一個它提供的函數。當調用類事務執行成功時，鏈碼執行特定的函數 -- 可能包含修改對應的狀態，并且返回一個輸出。
后續部分會講解，部署類事務是調用類事務的一個特殊情況，因為一個部署類事務產生了一個新鏈碼，就相當于在一個系統鏈碼上執行一個調用類事務。
>[warning]注意：這份文檔目前假設一個事務要么產生新的鏈碼，要么在一個已經部署的鏈碼上調用一個操作。該文檔沒有描述：a)查詢類事務（只讀）的優化（已包含在v1中），b)跨鏈碼事務支持（v1之后版本的特性）。
**1.2. 區塊鏈數據結構**
**1.2.1. 狀態**
區塊鏈的最新狀態（或者簡單的說，就是狀態）被建模為一個版本控制的key/value存儲結構（KVS），keys是名字，values是任意二進制對象（blobs，binary large objects）。這些條目被運行在區塊鏈上的鏈碼（應用程序），通過```put```和```get```進行操作。狀態將永久存儲，并且會記錄狀態的更新。注意版本控制的KVS被采用作為狀態模型，而實際實現可以使用真正的KVS系統，同時也可以使用RDBMS（關系型數據庫管理系統），或者任何其他解決方案。
更加形式化的表達，狀態s被建模為一個映射元素`K -> (V X N)`。這里：
* `K`是一個keys集合
* `V`是一個values集合
* `N`是一個版本號的無限順序集合。單射函數`next: N -> N`接收一個元素`N`，并且返回下一個版本號。
`V`和`N`都包含一個特殊元素`bot`，它是確保`N`有效的最低元素。最初時，所有的keys都被映射為`(bot, bot)`。對于`s(k)=(v, ver)`，我們使用`s(k).value`代表`v`，使用`s(k).version`代表`ver`。
KVS操作被如下建模：
* `put(k, v)`，對于`k in K `和`v in V`，接收區塊鏈狀態`s`，并且將其改為`s'`，使得對于所有的`k' != k`，都有`s'(k)=(v, next(s(k).version))`，并且`s'(k') = s(k')`
* `get(k)`返回`s(k)`
狀態被peers維護，而不是被orderers和clients維護。
>[warning] **狀態分區。** 在KVS中的Keys可以從他們的名字識別出屬于哪一個特定的鏈碼，從某種角度上來說，只有一個確定鏈碼上的事務才能更改這個鏈碼上的keys。原則上，任意鏈碼都可以讀取其它鏈碼的keys。跨鏈碼事務支持，即可以修改2個或多個鏈碼狀態是v1之后的版本特性。
**1.2.2 賬本**
賬本提供了一個能作證的歷史記錄，包含了所有成功的狀態改變（我們稱之為合法事務），和所有不成功的改變狀態嘗試（我們稱之為不合法事務），當對系統進行操作時記錄。
賬本被ordering服務（見1.3.3節）所構建，是一個關于區塊，關于（合法或不合法）事務的完全有序的哈希鏈。**這個哈希鏈在一個賬本中強制區塊的總順序，并且每一個區塊包含了一系列完全有序的事務。這就強制保證了所有事務的總順序。**
賬本被保存在所有的peers中，可選的，還可以保存在部分orderers中。在一個orderer上下文環境里，我們稱賬本【Ledger】為`OrdererLedger`，而在一個peer上下文環境中，我們稱賬本為`PeerLedger`。`PeerLedger`和`OrdererLedger`有所不同，表現為peer本地會維護一個位掩碼，以區分開合法事務和不合法事務。（詳見XX節）
按照XX節的描述，Peers可能會刪除`PeerLedger`（v1之后版本的特性）。Orderers還會保持`OrdererLedger`，用來容錯和可用性（`PeerLedger`的作用），并且也可能在任何時候刪除它，只要ordering服務（見1.3.3.節）的屬性已被保存。
賬本允許peers回放所有事務的歷史，以重構狀態。因此，1.2.1節中描述的狀態是一個可選的數據結構。
**1.3. 節點【Nodes】**
節點是區塊鏈上的通信實體。一個“節點【node】”僅僅是一個邏輯函數，多個不同類型的節點可以運行在同一個物理服務器上。最重要的是在“信任域”上節點如何分組，以及如何關聯控制它們的邏輯實體。
有3種類型的節點：
1. **Client或者submitting-client**：向endorsers提交一個實際事務調用【transaction-invocation】的客戶端，并且向ordering服務廣播事務提議【transaction-proposals】。
2. **Peer**：提交執行事務，并且維護狀態，以及賬本（見1.2節）的一份拷貝的節點。此外，peers可以擁有一個特殊的**endorser**角色。
3. **Ordering-service-node或者orderer**：運行通信服務的節點，它實現了一個保證性傳輸，比如原子性或者全序廣播。
下面詳述這幾個節點類型。
**1.3.1. Client**
client表示那些代表終端用戶行為的實體。它必須連接到一個peer上才能和區塊鏈通信。client可以連接到它選擇的任何peer上。Clients創建并調用事務。
如第2節詳述的那樣，clients和peers以及ordering服務都會進行通信。
**1.3.2. Peer**
一個peer以區塊的形式從ordering服務中接收有序狀態更新，并維護狀態和賬本。
Peers可以額外從事一個特殊的角色：**endorsing peer**，或者稱作**endorser**。一個endorsing peer的特殊功能與一個特定的鏈碼有關，并且在事務被提交之前對其進行認證【endorsing】。每一個鏈碼都可能會修改擔保策略【endorsement policy】，這可能會涉及到一系列擔保節點【endorsing peers】。該策略定義了一個合法的事務認證過程所需要的必要且足夠的條件（通常是一組認證者的簽名），正如后面第2和3節描述的那樣。在部署性事務安裝新鏈碼這種特殊情況中，（部署）驗證策略就被指定為系統鏈碼的一個驗證策略。（endorse到底翻譯成啥合適，這段太亂了）
**1.3.3. Ordering service nodes（Orderers）**
orderers提供ordering服務，比如一個通信結構提供可靠性傳輸。ordering服務可以通過多種途徑實現：從中心化服務（比如曾經開發測試中使用的），到針對不同網絡和節點故障模型的分布式協議。
Ordering服務為clients和peers提供了一個共享的通信頻道，為包含事務的消息提供了一個廣播服務。Clients連接上頻道，就可以在頻道上廣播消息，這樣就可以被送達所有的peers。頻道支持原子性傳輸所有消息，即，消息通信全部有序，并且可靠（依賴于具體實現）。換句話說，頻道向所有連接上的peers輸出同樣的消息，并且都按照同樣的邏輯順序輸出。**這種原子性的可靠通信，在分布式系統的上下文中，也被稱為全序廣播，原子廣播，或者共識**。通信的消息是用于包含在區塊鏈狀態中的候選事務。
**分隔（ordering服務頻道）。** 有序服務【Ordering service】可能支持多個頻道，類似于出版/訂閱（pub/sub）信息系統中的多個主題。客戶端【Clients】可以連接到一個給定的頻道，然后可以發送消息，并能夠取得抵達的消息。頻道可以想做是分區 -- 連接到一個頻道的客戶端，感覺不到其它頻道的存在，但是客戶端也能夠夠連接到多個頻道上。盡管在Hyperledger Fabric v1版本中，一些有序服務的實現將會支持多頻道，但為了講解簡單，在這篇文檔的余下部分，我們假設有序服務只包含一個頻道/主題。
**有序服務API**。Peers通過有序服務提供的接口，連上頻道。有序服務API包含2個基本的操作（更通常的說是異步事件）：
* `broadcast(blob)`：一個客戶端調用這個方法，在頻道上廣播任一個消息`blob`。這個在BFT上下文中，當向服務發送一個請求時，也被稱為`request(blob)`。
* `deliver(seqno, prevhash, blob)`：有序服務在peer上調用這個方法傳遞消息`blob`，并且攜帶指定的非負實數序列號（`seqno`），以及最近已傳遞的blob消息哈希值（`prevhash`）。換句話說，它是有序服務的一個輸出事件。`deliver()`在出版/訂閱系統上有時被稱為`notify()`，在BFT系統上有時被稱為`commit()`
**賬本和區塊構成**。賬本（見1.2.2節）包含了有序服務的所有數據輸出。簡而言之，它是一個`deliver(seqno, prevhash, blob)`事件序列，根據`prevhash`計算值構成了一個哈希鏈。
多數時候，為了效率考慮，并不輸出單個的事務（blobs），而是由有序服務在一個deliver事件中，向很多區塊批量輸出一組blobs。在這種情況下，有序服務就必須在每一個區塊中，強制傳達blobs的一個確定順序。一個區塊輸出blobs的數量，可以由有序服務的實現動態選擇。
在余下內容中，為了講解簡單，我們定義有序服務的一些屬性（即接下來的內容），并且解釋一下交易背書的工作流（第2節），假定每一個`deliver`事件對應一個blob。這很容易擴展到blocks的情況，假定一個deliver事件一個塊，相當于一組單獨的deliver事件序列，每一個對應一個塊中的一個blob，根據前面提到的確定性順序，對一個塊中得blobs進行排序。
#### Ordering服務屬性【Ordering service properties】
ordering服務的保證（或原子性廣播通道）明確規定了一則廣播消息如何處理，以及傳輸的消息之間存在著怎樣的關系。這些保證如下所示：
1. **安全（一致性保證）**：只要peers連接在channel上的時間足夠長（它們可以斷開連接，或者崩潰掉，但是還會重啟并重新連接），它們可以看到一組完全相同的，發送過的消息`(seqno, prevhash, blob)`。這就意味著輸出（`deliver()`事件）在所有的peers上都是相同的順序，并遵從序列編號【sequence number】，以及對于相同的序列編號，都攜帶完全相同的內容（`blob`和`prevhash`）。注意這只是一個邏輯順序【logical order】，并且在一個peer上的`deliver(seqno, prevhash, blob)`并不要求和其它peer上的相同消息的deliver輸出產生任何實時的關系。換句話說【Put differently】，給定一個`seqno`，任何2個正確的peers，都會傳輸相同的`prevhash`和`blob`值。而且，除非一些客戶端（peer）確實調用了`broadcast(blob)`，否則`blob`值就不會傳輸，理想情況下，每一個廣播的blob都只會傳輸一次。
再者，`deliver()`事件包含了上一個`deliver()`事件數據的加密哈希（即`prevhash`）。當ordering服務實現原子廣播保證時，`prevhash`指的就是`seqno-1`序列號的`deliver()`事件參數的加密哈希。這樣就建立了一條哈希鏈，將所有`deliver()`事件串了起來，可以用來幫助確定ordering服務的輸出完整性和誠實性，正如后面第4節和第5節討論的那樣，在第一個`deliver()`事件這種特殊情況下，`prevhash`有一個默認值。
2. **保活（傳輸性保證）**：ordering服務的保活保證由實際實現具體指定。在架構設計中沒有具體要求。實際的保證可能依賴于網絡，和節點故障模型。
原則上，如果提交客戶端【submitting client】沒有宕機，ordering服務應該保證每一個連入ordering服務的正確peer，最終都能傳輸每一筆提交的交易。
