隨著因特網的發展，其用戶規模、應用數量以及帶寬都在快速增長。在過去的幾年中，智能設備這種新的用戶載體已進入因特網世界。它形式多樣、由簡入繁，可以簡單至冰箱、空調或微波爐，也可以像無人機或自動駕駛車輛一樣精密。這些智能設備統稱為物聯網（IoT）設備，用於掌控實用程序的功能和聯網運作。有足夠多的案例證明，攻擊者正在利用物聯網設備發起一些稱為分佈式拒絕服務（DDoS）攻擊的大規模網絡攻擊。在本章中，你將了解 DDoS 攻擊，學習區塊鏈幫助企業組織抵禦如此大規模的網絡攻擊的部署操作。
DDoS 攻擊具有惡意企圖，通過來自地理位置分散的系統發送大量請求來擾亂伺服器的合法流量，阻礙正常用戶訪問。現在，讓我們首先了解拒絕服務（DoS）攻擊的工作原理。在 DoS 攻擊期間，攻擊者通過大量請求轟炸目標計算機，導致伺服器資源耗盡，從而導致合法用戶的請求失敗。在 DoS 攻擊中，攻擊者使用單台機器進行攻擊來耗盡目標伺服器資源。相比之下，DDoS 攻擊威力更強勁，因為可以使用多至數百萬台計算機來使目標伺服器應接不暇。
越來越多的企業組織正在將自己的應用服務遷移到具有大量基礎設施的雲端，以滿足其海量客戶的實時需求。企業可以構建自己龐大的雲伺服器基礎設施，也可以遷移到雲服務提供商提供的伺服器上。今天，攻擊者更喜歡用 DDoS 攻擊方法來破壞目標服務，因為他們可以生成 GB 甚至 TB 級的隨機數據來轟炸目標受害者，並且目標安全團隊也難以識別和攔截每個攻擊源，因為它們在數量上可能是數百萬計的。
此外，攻擊者永遠不會合法地控制他們的攻擊源機器，而是通過一些精心設計的惡意軟件感染全球數百萬台計算機，獲得完全訪問權限然後控制其發動大規模 DDoS 攻擊。這些受感染的計算機的集合稱為殭屍網絡（botnet），而單個受感染計算機被稱為殭屍節點（bot）。
雖然難以明確追溯到世界上的首次 DDoS 攻擊事件，但第一次引人注目的 DDoS 攻擊發生在 1999 年，針對的是明尼蘇達大學。它影響了 220 多個系統，並使整個網絡設施宕機了好幾天。
2016 年 10 月 21 日星期五，整個世界目睹了針對 Dyn（托管 DNS 提供商）的最複雜的 DDoS 攻擊的發生。Dyn 確認 Mirai 殭屍網絡是惡意攻擊流量的主要來源。這次攻擊開啟了對因特網安全和威脅態勢的新關注。
要發起 DDoS 攻擊，黑客可以自行構建整個殭屍網絡，也可以從暗網租用殭屍網絡資源。一旦攻擊者準備好武器，他們只需要去發現易受攻擊的站點、主機或者整個網絡。
洛克希德–馬丁公司（Lockheed-Martin）的一位計算機科學家提出了名為網絡殺傷鏈的術語，它闡述了從偵察到最終攻擊目標開始的整個網絡攻擊階段。這些階段包括：
・偵察：攻擊者識別目標設備並開始搜索其中的漏洞。
・武器化：攻擊者使用遠程工具包和惡意軟件（病毒或蠕蟲）來針對漏洞發起行動。
・惡意代碼傳播：攻擊者通過發送網絡釣魚郵件、秘密下載、USB 設備、內部人員協助等多種方法將攻擊代碼注入受害者網絡。
・漏洞利用：惡意代碼用於觸發攻擊，對目標網絡採取措施以利用漏洞。
・安裝：惡意軟件自動安裝在受害者計算機中。
・命令與控制：惡意軟件給予遠程攻擊者訪問受害者機器的控制權限。
為了從 DDoS 角度理解每個階段，了解殭屍網絡基礎設施及其構建方式對我們來說非常重要。
1. 構建殭屍網絡
DDoS 攻擊的分佈式特性需要利用全球數百萬台受感染的計算機。今天，攻擊者可以利用暗網租用或購買那些隨時可用的殭屍網絡資源。有一些工具，如 Jumper、Dirt 和 Pandore，實際上是降低甚至消除了攻擊者構建這些殭屍網絡的技術障礙。
下圖描述了殭屍網絡的整個生命周期：
2. 偵察
遭受偵查的目標系統可以大到一整個數據中心，或小到一台計算機。在這兩種情況下，殭屍網絡的構建需要識別一些具有惡意軟件可以攻擊利用的漏洞的主機。攻擊者查找與其目標直接或間接相關的信息，以非法訪問那些受到保護的資產。攻擊者會嘗試所有可能的方法繞過現有的安全系統，包括防火牆、入侵防禦系統（IPS）、Web 應用防火牆和終端保護系統。
3. 武器化
通過使用眾多的開源軟件資源，攻擊者能夠有效避免在構建惡意代碼過程中遇到的技術障礙。如果程序員具有惡意企圖並開發代碼，就可能會開發出新的惡意軟件，而安全系統最初很難檢測到這些新的惡意軟件。
以下是一些用於進行 DDoS 攻擊的常用工具列表：
・低軌道離子炮（LOIC）：這是黑客組織 anonymous 最喜歡使用的工具之一。它是一個簡單的泛洪工具，可以生成大量的 TCP、UDP 或 HTTP 流量來擁塞目標伺服器。它最初是為測試伺服器性能的吞吐量而開發的。然而，anonymous 組織使用這個開源工具來發起複雜的 DDoS 攻擊。該工具後來又增強了 IRC 功能，允許用戶通過 IRC 控制連接系統。
・高軌道離子炮（HOIC）：在有效使用 LOIC 幾年後，
2. 偵察
遭受偵查的目標系統可以大到一整個數據中心，或小到一台計算機。在這兩種情況下，殭屍網絡的構建需要識別一些具有惡意軟件可以攻擊利用的漏洞的主機。攻擊者查找與其目標直接或間接相關的信息，以非法訪問那些受到保護的資產。攻擊者會嘗試所有可能的方法繞過現有的安全系統，包括防火牆、入侵防禦系統（IPS）、Web 應用防火牆和終端保護系統。
3. 武器化
通過使用眾多的開源軟件資源，攻擊者能夠有效避免在構建惡意代碼過程中遇到的技術障礙。如果程序員具有惡意企圖並開發代碼，就可能會開發出新的惡意軟件，而安全系統最初很難檢測到這些新的惡意軟件。
以下是一些用於進行 DDoS 攻擊的常用工具列表：
・低軌道離子炮（LOIC）：這是黑客組織 anonymous 最喜歡使用的工具之一。它是一個簡單的泛洪工具，可以生成大量的 TCP、UDP 或 HTTP 流量來擁塞目標伺服器。它最初是為測試伺服器性能的吞吐量而開發的。然而，anonymous 組織使用這個開源工具來發起複雜的 DDoS 攻擊。該工具後來又增強了 IRC 功能，允許用戶通過 IRC 控制連接系統。
下載到被新攻破的受害者系統中。下載完成後，腳本會自動在這個新的殭屍節點上啟動新的攻擊過程。整個攻擊機制使用 HTTP、FTP 和遠程過程調用（RPC）協議。在這種方法中，攻擊者操作受害者機器，被攻破的系統會連接到攻擊者的中央存儲庫，進而通過總中央庫中下載惡意代碼。如下圖所示：
・反向鏈接傳播：在此方法中，攻擊者將工具包移植到新受感染的主機上。這個工具包被精心打造以接受來自受感染系統的文件傳輸請求。同時，反向通道文件複製的過程可以由一個端口偵聽程序使用普通文件傳輸協議（TFTP）完成。與中央源傳播方法不同，攻擊者將漏洞利用和攻擊代碼一起傳輸到被攻陷的主機。如下圖所示。
・自動傳播：在這種機制中，當攻擊者入侵系統時，他們的工具包將被拷貝到受感染的主機。這種機制在傳輸方法層面有所不同，因為攻擊工具包首先僅由攻擊者植入受感染的主機。在這種方法中，攻擊者首先傳輸漏洞利用的攻擊，然後傳輸來自他自己的代碼，而非來自任何中央存儲庫。如下圖所示：
5. 漏洞利用
一旦惡意程序進入網絡中，它就會發起對各種漏洞（包括未修補的軟件漏洞、有缺陷的軟件編程實踐或用戶疏忽）的利用。通常，網絡中存在大量的漏洞，而它們的可利用性，使得漏洞本身更加致命。
6. 安裝
在安裝階段，惡意軟件會錨定在目標系統中，從而允許遠程攻擊者訪問它。在安裝過程中，惡意軟件可以植入系統的用戶空間或內核空間中。安裝在用戶空間的惡意軟件很容易被檢測到。但是，內核空間中的惡意軟件很少被安全系統（包括終端保護、終端檢測和響應平台等系統）檢測到。
7. 命令與控制（C2）
在成功安裝了入侵工具後，目標主機就完全由攻擊者的遠程中央系統控制。這些被入侵操控的設備的網絡稱為殭屍網絡，被攻擊者隨意擺布。但是，殭屍網絡節點在被攻擊者激活之前一直保持休眠狀態。在公共的對等網絡上，甚至存在一些加密過的殭屍主機之間的通信。
8. 對目標採取行動
一旦建立了 C2 通道，攻擊者就可以對目標發起 DDoS 攻擊。在此階段，攻擊者運行腳本以激活整個殭屍網絡中的所有殭屍主機。攻擊者還要配置殭屍網絡，從而得知需要生成什麼類型的攻擊流量。
區塊鏈是一個去中心化的網絡，允許獨立的各方在沒有任何第三方參與的情況下進行通信。為了保護網絡免受 DDoS 攻擊，企業服務可以分佈在多個伺服器節點中，提供高彈性並消除單點故障。使用區塊鏈的兩個主要優點如下：
・區塊鏈技術可用於部署分佈式賬本來存儲列入黑名單的 IP。
・區塊鏈技術消除了單點故障的風險。
區塊鏈的 DDoS 防禦平台，首先需要使用以太坊區塊鏈的 Node.js 和 Truffle 來準備測試環境。我們將使用一個現有的區塊鏈項目來保護網絡免受 DDoS 攻擊。該項目可以在鏈接https://github.com/gladiusio/gladius-contracts 下找到。
我們需要按照以下步驟為 Gladius 項目準備基礎設施：
1）首先，我們將在系統環境中安裝 Node.js，鏈接地址為https://nodejs.org/uk/download/package-manager/#arch-linux。
2）我們需要在測試環境中安裝 truffle：
3）在命令行中執行如下命令：
4）現在在命令行中執行如下命令來啟動測試網絡：
以下屏幕截圖顯示了運行上述命令的輸出內容：
5）在此終端窗口中，我們可以看到測試區塊鏈網絡中的所有交易。現在，我們必須打開一個新的終端窗口，並需要跳轉到工作目錄。
要進行項目配置，請按照以下說明操作：
1）在https://github.com/gladiusio/gladius-contracts 網頁中找到.zip 文件並下載，然後將文件解壓到你指定的路徑。
2）用下面的代碼替換 truffle.js 裡的代碼：
3）我們將進入名稱為 gladius-contracts-master 的文件夾並使用以下命令編譯合約：
以下屏幕截圖顯示了運行上述命令的輸出內容：
4）現在，我們可以執行下面的命令將合約發布到 ganache-cli 的本地區塊鏈上：
以下屏幕截圖顯示了運行上述命令的輸出內容：
5）現在，我們必須使用 truffle test 命令啟動單元測試，以確保智能合約正常運行：
7）接下來，我們在終端中找到 gladius-control-daemon-master 文件夾並鏈接合約應用程序二進制接口（ABI）。ABI 是兩個程序模塊之間的接口，其中一個程序模塊位於機器代碼級別：
以下屏幕截圖顯示了運行上述命令的輸出內容：
8）下一步，我們可以執行 npm install 命令安裝所需依賴：
9）然後，我們可以執行 node index.js 命令啟動腳本：
10）打開一個新終端窗口，執行 gladius-networkd 命令：
11）下一步，我們需要再打開一個新的終端，執行 gladius-controld 命令：
12）為了啟動你的節點，你需要在新終端中執行下面的命令：
以下屏幕截圖顯示了運行上述命令的輸出內容：
13）我們可以將數據提交到特定的池，允許它接受或拒絕成為池的一部分：
14）完成節點創建後，我們可以使用管理應用程序檢查它的狀態。這顯示了區塊鏈中的節點信息：
現在只需將 Gladius 客戶端下載到你的計算機並訪問系統即可。
激活 Gladius 後，所有節點都會處理連續的請求流，以校驗網站連接並阻止惡意活動。Gladius 積極致力於解決系統中的若干問題並實現穩定的系統。
區塊鏈可以在以下場景中使用：
・衝突情況：區塊鏈網絡不僅連接可信方，還連接不可信方。因此，關注衝突情況並無縫地解決問題至關重要。區塊鏈使用共識機制來確認交易和構建區塊。不同的區塊鏈使用不同的共識模型，例如工作量證明（PoW），權益證明（PoS）等，但目的是相同的，即避免衝突並使交易成功。
・共享公共數據庫：如果企業組織在其員工（管理員或非 IT 人員）、承包商或第三方之間共享公共數據庫，則許可鏈可以真正符合要求。當集中式數據庫在不同方之間共享時，會增加使用特權升級的訪問控制的風險。當使用許可鏈時，它確保只有提交的對等方有權對數據庫進行更改，而交易背書可以由任何預先選擇的參與者完成。
・交易業務規則需求：如果業務模型要求你有一個簡單或複雜的邏輯策略來執行任何交易，那麼區塊鏈可以通過其邏輯策略提供很好的保證，例如以太坊的智能合約或超級賬本的鏈碼。業務策略將始終在節點軟件中定義，該軟件將強制節點按照定義的規則工作。
・系統透明性需求：如果組織的業務模型要求其對整個供應鏈的客戶或供應商必須保持透明性，那麼分佈式賬本技術可以更好地提供供應鏈運營管理系統的端到端可視性。在一個沒有權限控制的區塊鏈網絡中，允許每個節點讀寫區塊鏈賬本，因此也變得透明。然而，在有權限的環境中，企業則更傾向於只有預選的節點參與區塊鏈計算過程和賬本管理。
・數據不變性的需求：如果企業組織需要開發高度安全的僅用於數據追加的數據庫，則加密哈希和數字簽名可以幫助構建這種高度安全的賬本。
追加的數據庫，則加密哈希和數字簽名可以幫助構建這種高度安全的賬本。在構建每個塊時使用前一個塊的哈希值，因此一旦創建了數據庫，就不可能修改或重新排列它們。
區塊鏈是業界所見過的最強大技術之一，但它並不總是適用於所有工作。這使得評估階段在各個方面都非常關鍵。在理解了它最適合的業務之後，讓我們看一些區塊鏈不適合的情況：
・存儲相當大的數據：由於其分佈式和分散性，整個數據庫與區塊鏈網絡中的每個節點一起存儲（在基於權限的賬本情況下，只允許預先選擇的參與者讀取和存儲數據，因此，複製數據庫將花費很長時間並且速度緩慢）。有一些解決方案是為了完成這個目的而建立的，我們可以快速了解一下。
・交易規則經常更改：如果設置並啟動了智能合約策略，則不會更改執行路徑。頻繁更改業務流程和操作的組織不建議使用基於區塊鏈的應用程序。區塊鏈網絡內的每個子系統和子過程必須是確定的。
・區塊鏈必須從外部數據源獲取數據：構建區塊鏈智能合約不是為了從外部數據源獲取信息。即使將其配置為在區塊鏈和可信數據庫之間進行通信，它也將作為常規數據庫操作進行操作。而且，在這種情況下，區塊鏈智能合約不會從外部數據庫中提取條目。相反，可信數據庫必須將數據推送到區塊鏈上。
區塊鏈正在為我們帶來一些偉大的技術和商業機會，它正在促進不同組織之間的協作。領導者目前正在體驗和尋找區塊鏈技術用於其業務運營的用武之地，以便能夠跟上不斷變化的市場需求。讓我們聚焦到落實區塊鏈計劃中的一些重要問題：
・誰是我的行業中最值得信賴的區塊鏈技術領導者？
・我的競爭對手對區塊鏈有什麼看法？
・哪些業務部門最容易受到干擾？
・我們的區塊鏈部署對誰的影響最大？他們可能會有什麼反應？
・區塊鏈可能的商業案例是什麼？我們如何才能實現更好、更可持續的商業模式？
・部署中涉及的總成本因素是什麼？
・目前的規章制度對區塊鏈應用的影響是什麼？
・我們如何協同監管機構向市場推出區塊鏈應用來實現雙贏？
・我們如何將安全控制應用於區塊鏈應用程序？
在將區塊鏈應用程序投入市場之前，預計會進行一系列頭腦風暴，但建議明確項目的範圍並與合適的利益相關者結盟。
懶惰和好奇，是創新與進步的源泉。
比特幣、以太坊等公有區塊鏈平台的實驗，充分論證了區塊鏈技術在支持去中心化交易方面的巨大優勢。
越來越多的企業也開始關注區塊鏈技術，嘗試將其引入商業場景中，以提高進行複雜商業交易的效率，降低多方合作的成本。超級賬本 Fabric 項目應運而生。Fabric 作為超級賬本社區的早期項目之一，集合了來自科技界和金融界的最新成果，首次提供了面向聯盟鏈場景的分佈式賬本平台實現。
本章將帶領讀者學習如何從源碼開始本地編譯和安裝 Fabric 環境，以及在多伺服器環境下如何部署一個典型的 Fabric 網絡。同時，還將介紹如何使用容器方式在單機環境下快速啟動完整的 Fabric 網絡環境。接下來，講解鏈碼和應用通道的相關操作和 SDK 支持。最後，本章對在生產環境中部署 Fabric 網絡的有關注意事項進行探討。
Fabric 從 1.0 版本開始，在架構上進行了重新設計，解耦了節點的角色，同時在安全性、性能、可擴展性和可插拔性方面都有了不少改進。在將交易發送到網絡中之前，需要先向背書節點收集足夠多的背書支持，同時採用專門的排序節點來負責整個網絡中十分核心的排序環節。
目前，網絡中存在以下 4 種不同種類的服務節點，彼此協作完成整個區塊鏈系統的功能。對網絡中節點角色進行解耦是 Fabric 設計中的一大創新，這也是聯盟鏈場景下的特殊需求和環境所決定的：
・背書節點（Endorser）：負責對交易的提案（proposal）進行檢查和背書，計算交易執行結果；
・確認節點（Committer）：負責在接受交易結果前再次檢查合法性，接受合法交易對賬本的修改，並寫入區塊鏈結構；
・排序節點（Orderer）：對所有發往網絡中的交易進行排序，將排序後的交易按照配置中的約定整理為區塊，之後提交給確認節點進行處理；
・證書節點（CA）：負責對網絡中所有的證書進行管理，提供標準的 PKI 服務。
另外，網絡中支持多通道的特性。使用一條獨立的系統通道（system channel）負責管理網絡中的各種配置信息，並完成對其他應用通道（application channel，供用戶發送交易使用）的創建。
目前，要啟動一個 Fabric 網絡，需要遵循如下的主要步驟
1）預備網絡內各項配置，包括網絡中成員的組織結構和對應的身份證書（使用 cryptogen 工具完成）；生成系統通道的初始配置區塊文件，新建應用通道的配置更新交易文件以及可能需要的錨節點配置更新交易文件（使用 configtxgen 工具完成）。
2）使用系統通道的初始配置區塊文件啟動排序節點，排序節點啟動後自動按照指定配置創建系統通道。
3）不同的組織按照預置角色分別啟動 Peer 節點。這個時候網絡中不存在應用通道，Peer 節點也並沒有加入網絡中。
4）使用新建應用通道的配置更新交易文件，向系統通道發送交易，創建新的應用通道。
5）讓對應的 Peer 節點加入所創建的應用通道中，此時 Peer 節點加入網絡，可以準備接收交易了。
6）用戶通過客戶端向網絡中安裝註冊鏈碼（相關定義參見後面 9.5 節），鏈碼容器啟動成功後用戶即可對鏈碼進行調用，將交易發送到網絡中。
後續章節將詳細介紹各個步驟的操作順序及方法
動手能力較強的讀者，建議通過本地編譯安裝來部署超級賬本 Fabric 網絡，以便對相關組件有更深入的理解。
超級賬本 Fabric 基於 Go 語言實現，本地編譯推薦配置 Golang 1.7 或更高版本的環境。下面將講解如何編譯生成 fabric-peer、fabric-orderer 和 fabric-ca 等組件的二進制文件，以及如何安裝一些配置和開發相關的工具。
常見的 Linux 發行版（包括 Ubuntu、Redhat、CentOS 等）和 MacOS 等都可以原生支持 Fabric 編譯和運行。
操作系統推薦 Linux 內核 3.10 + 版本，支持 64 位環境。另外，作為 Fabric 節點，物理內存建議至少為 2GB，如果有較多的鏈碼則需要更多容器；預留足夠硬盤空間（一般建議 20GB 或更多）以存儲區塊文件。在生產環境中對性能和穩定性要求高的場景下，甚至要預留更多的物理資源。
下面將默認以 Ubuntu 16.04 操作系統為例進行操作。
提示 運行 Fabric 節點需要的資源並不苛刻，作為實驗，Fabric 節點甚至可以在樹莓派（Raspberry Pi）上正常運行
. 安裝 Go 語言環境
Go 語言環境可以自行訪問 golang.org 網站下載二進制壓縮包安裝。注意不推薦通過包管理器安裝，版本往往比較舊。
如下載 Go 1.8 版本，可以採用如下命令
$ curl -O https://storage.googleapis.com/golang/go1.8.linux-amd64.tar.gz
下載完成後，解壓目錄，並移動到合適的位置（推薦為 /usr/local 下）：
$ tar -xvf go1.8.linux-amd64.tar.gz
$ sudo mv go /usr/local
安裝完成後記得配置 GOPATH 環境變量：
export GOPATH=YOUR_LOCAL_GO_PATH/Go
export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin
此時，可以通過 go version 命令驗證安裝是否成功：
$ go version
go version go1.8 linux/amd64
2. 安裝依賴包
編譯 Fabric 相關代碼，需要一些依賴包，可以通過如下命令安裝：
通過如下命令可以獲取 fabric-peer 和 fabric-orderer 組件編譯所需要的代碼，兩者目前在同一倉庫中
$ git clone http://gerrit.hyperledger.org/r/fabric
啟動 Fabric 網絡是一個比較複雜的過程，主要步驟包括計劃拓撲、準備相關配置文件、啟動 Orderer 節點、啟動 Peer 節點和操作網絡等。這裡以 Fabric 代碼中自帶的示例為基礎講解相關的操作步驟。
啟動的 Fabric 網絡中包括一個 Orderer 節點和四個 Peer 節點，以及一個管理節點生成相關啟動文件，在網絡啟動後作為操作客戶端執行命令。
四個 Peer 節點分屬於同一個管理域（example.com）下的兩個組織 Org1 和 Org2，這兩個組織都加入同一個應用通道（business-channel）中。每個組織中的第一個節點（peer0 節點）作為錨節點與其他組織進行通信，所有節點通過域名都可以相互訪問，整體網絡拓
Fabric 網絡在啟動之前，需要提前生成一些用於啟動的配置文件，主要包括 MSP 相關文件（msp/）、TLS 相關文件（tls/）、系統通道初始區塊（orderer.genesis.block）、新建應用通道交易文件（businesschannel.tx）、錨節點配置更新交易文件 Org1MSPanchors.tx 和 Org2MSPanchors.tx）等。各個文件的功能
注意，本小節主要描述如何生成這些啟動配置文件，關於這些配置更詳細的講解可以參考後續相關章節。
1. 生成組織關係和身份證書
Fabric 網絡提供的是聯盟鏈服務，聯盟由多個組織構成，組織中的成員提供了節點服務來維護網絡，並且通過身份來進行權限管理。
因此，首先需要對各個組織和成員的關係進行規劃，分別生成對應的身份證書文件，並部署到其對應的節點上。
用戶可以通過 PKI 服務（如使用 fabric-ca）或者 OpenSSL 工具來手動生成各個實體的證書和私鑰。但當組織結構比較複雜時，這種手動生成的方式容易出錯，並且效率不高。
Fabric 項目提供了 cryptogen 工具（基於 crypto 標準庫）實現自動化生成。這一過程首先依賴 crypto-config.yaml 配置文件。
crypto-config.yaml 配置文件的結構十分簡單，支持定義兩種類型（OrdererOrgs 和 PeerOrgs）的若干組織。每個組織中又可以定義多個節點（Spec）和用戶（User）。
一個示例的 crypto-config.yaml 配置文件內容如下，其中定義了一個 OrdererOrgs 類型的組織 Orderer（包括一個節點 orderer.example.com），以及兩個 PeerOrgs 類型的組織 Org1 和 Org2（分別包括 2 個節點和 1 個普通用戶）
OrdererOrgs:
- Name: Orderer
Domain: example.com
Specs:
- Hostname: orderer
CommonName: orderer.example.com
PeerOrgs:
- Name: Org1
Domain: org1.example.com
Template:
Count: 2
Users:
Count: 1
- Name: Org2
Domain: org2.example.com
Template:
Count: 2
Users:
Count: 1
使用該配置文件，通過如下命令可以為 Fabric 網絡生成指定拓撲結構的組織和身份文件，存放到 crypto-config 目錄下：
$ cryptogen generate --config=./crypto-config.yaml --output ./crypto-config
查看 crypto-config 目錄結構，按照示例 crypto-config.yaml 中的定義進行生成：
$ tree -L 4 crypto-config
crypto-config
|-- ordererOrganizations
| `-- example.com
| |-- ca
| | |-- 293def0fc6d07aab625308a3499cd97f8ffccbf9e9769bf4107d6781f5e8072b_sk
| | `-- ca.example.com-cert.pem
| |-- msp
| | |-- admincerts
| | |-- cacerts
| | `-- tlscacerts
| |-- orderers
| | `-- orderer.example.com
| |-- tlsca | |-- 2be5353baec06ca695f7c3b04ca0932912601a4411939bfcfd44af18274d5a65_sk
| | `-- tlsca.example.com-cert.pem
| `-- users
| `-- [email protected]
`-- peerOrganizations
|-- org1.example.com
| |-- ca
| | |-- 501c5f828f58dfa3f7ee844ea4cdd26318256c9b66369727afe8437c08370aee_sk
| | `-- ca.org1.example.com-cert.pem
| |-- msp
| | |-- admincerts
| | |-- cacerts
| | `-- tlscacerts
| |-- peers
| | |-- peer0.org1.example.com
| | `-- peer1.org1.example.com
| |-- tlsca
| | |-- 592a08f84c99d6f083b3c5b9898b2ca4eb5fbb9d1e255f67df1fa14c123e4368_sk
| | `-- tlsca.org1.example.com-cert.pem
| `-- users
| |-- [email protected]
| `-- [email protected]
`-- org2.example.com
|-- ca
| |-- 86d97f9eb601868611eab5dc7df88b1f6e91e129160651e683162b958a728162_sk
| `-- ca.org2.example.com-cert.pem
|-- msp
| |-- admincerts
| |-- cacerts
| `-- tlscacerts
|-- peers
| |-- peer0.org2.example.com
| `-- peer1.org2.example.com
|-- tlsca
| |-- 4b87c416978970948dffadd0639a64a2b03bc89f910cb6d087583f210fb2929d_sk
| `-- tlsca.org2.example.com-cert.pem
`-- users
|-- [email protected]
`-- [email protected]
按照 crypto-config.yaml 中的定義，所生成的 crypto-config 目錄下包括多級目錄結構。其中 ordererOrganizations 下包括構成 Orderer 組織（1 個 Orderer 節點）的身份信息；peerOrganizations 下為所有的 Peer 節點組織（2 個組織，4 個節點）的相關身份信息。其中最關鍵的是 msp 目錄，代表了實體的身份信息。
對於 Orderer 節點來說，需要將 crypto-config/ordererOrganizations/example.com/orderers/orderer.example.com 目錄下的內容（包括 msp 和 tls 兩個子目錄）複製到 Orderer 節點的 /etc/hyperledger/fabric 路徑（與 Orderer 自身配置一致）下。
對於 Peer 節點來說，則需要複製 peerOrganizations 下對應的身份證書文件。以 org1 的 peer0 為例，將 crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com 目錄下的內容（包括 msp 和 tls）複製到 Peer0 節點的 /etc/hyperledger/fabric（與 Peer 自身配置一致）路徑下。
對於客戶端節點來說，為了方便操作，可將完整的 crypto-config 目錄複製到 /etc/hyperledger/fabric（與 configtx.yaml 中配置一致）路徑下。
注意 目前，組織結構一旦生成，如果要進行修改，只能手動對證書進行調整，因此需要提前做好聯盟的規劃。未來會支持對組織結構和節點身份進行動態在線調整。
2. 生成 Ordering 服務啟動初始區塊
Orderer 節點在啟動時，可以指定使用提前生成的初始區塊文件作為系統通道的初始配置。初始區塊中包括了 Ordering 服務的相關配置信息以及聯盟信息。初始區塊可以使用 configtxgen 工具進行生成。生成過程需要依賴 /etc/hyperledger/fabric/configtx.yaml 文件。configtx.yaml 配置文件定義了整個網絡中的相關配置和拓撲結構信息。
編寫 configtx.yaml 配置文件可以參考 Fabric 代碼中（如 examples/e2e_cli 路徑下或 sampleconfig 路徑下）的示例。這裡採用如下內容進行生成：
Profiles:
TwoOrgsOrdererGenesis:
Orderer:
<<: *OrdererDefaults
Organizations:
- *OrdererOrg
Consortiums:
SampleConsortium:
Organizations:
- *Org1
- *Org2
TwoOrgsChannel:
Consortium: SampleConsortium
Application:
<<: *ApplicationDefaults
Organizations:
- *Org1
- *Org2
Organizations:
- &OrdererOrg
Name: OrdererOrg
ID: OrdererMSP
MSPDir: crypto-config/ordererOrganizations/example.com/msp
BCCSP:
Default: SW
SW:
Hash: SHA2
Security: 256
FileKeyStore:
KeyStore:
- &Org1
Name: Org1MSP
ID: Org1MSP
MSPDir: crypto-config/peerOrganizations/org1.example.com/msp
BCCSP:
Default: SW
SW:
Hash: SHA2
Security: 256
FileKeyStore:
KeyStore:
AnchorPeers:
- Host: peer0.org1.example.com
Port: 7051
- &Org2
Name: Org2MSP
ID: Org2MSP
MSPDir: crypto-config/peerOrganizations/org2.example.com/msp
BCCSP:
Default: SW
SW:
Hash: SHA2
Security: 256
FileKeyStore:
KeyStore:
AnchorPeers:
- Host: peer0.org2.example.com
Port: 7051
Orderer: &OrdererDefaults
OrdererType: solo
Addresses:
- orderer.example.com:7050
BatchTimeout: 2s
BatchSize:
MaxMessageCount: 10
AbsoluteMaxBytes: 99 MB
PreferredMaxBytes: 512 KB
Kafka:
Brokers:
- 127.0.0.1:9092
Organizations:
Application: &ApplicationDefaults
Organizations:
該配置文件定義了兩個模板：TwoOrgsOrdererGenesis 和 TwoOrgsChannel，其中前者可以用來生成 Ordering 服務的初始區塊文件。
通過如下命令指定使用 configtx.yaml 文件中定義的 TwoOrgsOrdererGenesis 模板，來生成 Ordering 服務系統通道的初始區塊文件。注意這裡排序服務類型採用了簡單的 solo 模式，生產環境中可以採用 kafka 集群服務：