1.Client節點
client代表由最終用戶操作的實體，它必須連接到某一個peer節點或者orderer節點上與區塊鏈網絡通信。客戶端向endorser提交交易提案，當收集到足夠背書后，向排序服務廣播交易，進行排序，生成區塊。但是該節點的故障不會影響區塊鏈網絡的正常運行。
2.CA節點
CA節點是hyperledger 1.0的證書頒發機構，由服務器（fabric-ca-service）和客戶端組件（fabric-ca-client）組成。CA節點接收客戶端的注冊申請，返回注冊密碼用於用戶登入，以便獲取身份證書，在區塊鏈網絡上所有的操作都會驗證用戶的身份。因此該節點的故障只會影響到用戶的注冊申請。
3.Orderer節點
orderer負責接收包含背書簽名的交易，對未打包的交易進行排序生成區塊，廣播給peer節點。排序服務可以采用集中式服務（solo，不適合實際生產環境），也可以采用分布式協議（目前正是發布的版本只支持Apache Kafka集群，只能實現崩潰故障容錯）。BFT（拜占庭容錯）的排序服務會在1.x周期內發布。我們也可以為fabric寫一個共識實現，一個共識插件需要實現consensus package中定義的Consenter和Chain接口，我們可以來研究已經針對這些接口構建的plugin（solo和kafka）為自己提供線索。
我們分析下現有的基於kafka的排序服務安全性。
首先不用擔心排序服務里插入數據帶來的安全問題，因為最終記賬還需要經過多重檢查，比如消息類型的檢查和簽名驗證、記賬節點對背書策略的驗證和交易內容的驗證。但是其他的惡意節點攻擊的問題還是無法避免的，比如拒絕服務（丟掉交易）。
kafka集群至少要四個節點，可以保證在1一個節點宕機后還能繼續提交交易和排序，並且創建新的通道。zookeeper節點數選擇3、5、7都可以。奇數個節點可以避免腦裂，1個節點會存在單點問題，7個以上就太多了。
值得一提的是，官方的example的在kafka集群和orderer之間都是沒有安全傳輸的，切不可直接投入生產環境。我們可以通過使用openssl為kafka集群生成秘鑰，增加orderer和kafka的配置以使用基於TLS的安全傳輸。
4.Peer節點
首先所有的peer節點都是committer（記賬節點），而又有可能擔任的角色有endorser（背書節點）、Leader（主節點）、Anchor（錨節點）。
Committer
記賬節點使用基於Gossip的p2p數據分發，節點會定期跟其他節點交換信息。如果在這個過程中有節點發生故障，則會從存活的節點中刪除這個節點的信息。對於故障節點，還會定時檢查是否已經恢復，恢復存活的節點會更新到存活節點列表中。如果有新加入的節點，也能通過節點信息的交換獲取到，添加到存活列表中，廣播給其他節點。由於超級賬本采用基於反熵的狀態同步，每個節點周期性的和鄰居節點交換保存的數據，然后對比本地數據和鄰居節點所保存的數據，檢查是否有缺失或者過期的數據，然后更新本地節點的數據為最新的數據，因此故障的節點重新連接到網絡時會自動恢復數據。這些都能通過Gossip協議學習到，自動調整網絡的拓撲結構，適應網絡節點的變化，保證整個網絡正常運行。並且協議能正確工作的概率不會因為錯誤數超過f（可靠的廣播協議中存在一個f，錯誤數超過這個值就會出現異常，協議的可靠性等於不超過f個錯誤的概率）時就快速地降低。（優雅降級）
Leader
主節點連接到排序服務，負責把接受到的批量區塊轉發給其他節點。因此主節點與排序服務的穩定連接至關重要。可以強制設置為主節點，也可以動態選舉產生。主節點選舉的用處是，判斷在相同的組織中哪個節點可以作為代表連接排序服務。選舉過程在Gossip層實現，一個節點啟動的時候它先等網絡穩定再開始參與主節點選舉，一次主節點選舉的有效時間是10s。這樣可以有效避免強制設置主節點出現的發生故障無法分發區塊的問題。
Endorser
背書節點為動態的角色與具體的chaincode綁定，背書節點的故障對網絡的影響取決於chaincode對應的背書策略，例如背書策略指定只要3個組織其中的2個組織的成員完成背書，該交易就是有效的，那么只有一個組織的成員節點出現故障對交易完成沒有影響。
Anchor
錨節點是在一個channel上可以被所有其他peer發現的peer，channel上的每個成員都有一個anchor Peer(或多個anchor peer 來防止單點故障)，允許屬於不同成員的peer發現channel上的所有現有peer。錨節點的配置文件可以通過configtxgen工具生成。