Hyperledger Fabric架構 — Gossip協議

8 min readOct 21, 2022

Hyperledger Fabric 讓交易在執行（背書和寫入）對等節點和交易排序節點之間劃分工作負載來優化區塊鏈網路效能、安全性和可擴展性。這種網路操作的解耦(decouple)需要一個安全、可靠和可擴展的資料傳播協議，以確保資料的完整性和一致性。為了滿足這些要求，Fabric 使用了gossip 資料傳播協議。

Gossip協議

對等節點使用gossip以可擴展的方式廣播帳本和渠道資料。 Gossip 訊息是連續性的，渠道上的每個對等節點都在不斷地從多個對等節點接收最新且一致的帳本資料。每個 Gossip 訊息都經過簽名，這讓參與者發送偽造的訊息很容易被識別，並且可以防止將訊息發送給不需要的對等節點。受網路延遲、網路分區(Network partitions)或其他導致遺失區塊的原因影響的對等節點最終還是可以在上線後從其他線上的其他對等節點取得最新的帳本狀態。

基於 gossip 的資料傳播協議在 Fabric 網路上執行三個主要功能：

通過不斷探索區塊鏈網路上可用的對等節點並偵測已離線的對等節點來管理對等節點和渠道成員。稱為Peer Discovery。
在渠道上的所有對等節之間傳播帳本資料。渠道中其他的節點會去檢查自己資料不同步的部分。若有，則會去複製自己遺失的區塊資料。
通過允許帳本資料的點對點狀態傳輸更新，使新上線的對等點節加速其同步狀態。

基於 Gossip 的廣播通過對等節點從渠道上的其他對等節點接收訊息，然後將這些訊息轉發到渠道上的許多的對等節點來運作，而其節點是隨機選擇的，這個隨機數是一個可配置的常數。對等節點也可以使用pull機制，而不是等待訊息的傳遞。這個循環會一直重複，得以讓渠道成員、帳本和狀態訊息不斷保持最新和同步。對於新區塊的傳播，渠道上的領導節點(leader peer)從排序服務中擷取資料，並向自己組織中的節點發起Gossip傳播。

選舉領導節點

領導節點選舉機至用於為每個對等組織選(peer organization)舉一個節點，該節點將保持與排序服務的連線，並在其自身組織的節點之間開始傳播新的區塊。用這種方式才部會把排序服務的網路打爆。領導節點選舉模式有兩種運作模式：

Static(靜態) — 人為指定。系統管理員手動設定組織中的一個節點為領導節點。
Dynamic(動態) —節點之間會執行一個領導者選舉程序以選擇組織中的一個節點成為領導者。

靜態領導節點

這種方式允許我們手動將組織內的一個或多個節點定義為領導節點。但是請注意，連線到排序服務的節點過多可能會把排序服務的網路打爆。靜態節點的設定，請在 core.yaml 部分中配置以下參數：

peer:
    # Gossip related configuration
    gossip:
        useLeaderElection: false
        orgLeader: true

或者，可以使用環境變量來配置或覆寫參數：

export CORE_PEER_GOSSIP_USELEADERELECTION=false
export CORE_PEER_GOSSIP_ORGLEADER=true

但如果把第二行的參數改為false，則這個對等點會保持在stand-by模式，部會嘗試變成領導節點。將第一行與第二行參數設為 true 會導致錯誤，因為系統不知道到底要用靜態還是動態。而在靜態配置中，管理員（也就是我們）負責為領導節點提供高可用性，以防出現故障或崩潰。

動態領導節點

動態領導節點選舉使組織節點能夠選舉出一個節點，該節點將連接到排序服務並取得(pull)新區塊。該領導節點是為組織內的節點獨立選舉產生的。

動態選舉產生的領導節點會有一個heartbeat messages發送給其他對等節點，作為還活著的證據。如果一個或多個對等節點在設定的時間區間內沒有收到hearbeat更新，他們就會選出一個新的領導節點。

在網路分區(Network partition)這種最壞的情況下，組織將有一個以上還活著的領導節點來保證韌性和可用性，以允許組織的節點繼續取得新區塊。網路分區修復後，其中一位領導節點將放棄其領導權。在沒有網路分區問題的穩定狀態下，將只有一個活著領導者會連線到排序服務。

以下配置控制領導者heartbeat messages的頻率：

peer:
    # Gossip related configuration
    gossip:
        election:
            leaderAliveThreshold: 20s

為了啟用動態領導節點選舉，我們需要在 core.yaml 中配置以下參數：

peer:
    # Gossip related configuration
    gossip:
        useLeaderElection: true
        orgLeader: false

或者，可以使用環境變量來配置或覆寫參數：

export CORE_PEER_GOSSIP_USELEADERELECTION=true
export CORE_PEER_GOSSIP_ORGLEADER=false

錨定節點(Anchor peers)

Gossip使用錨定節點來確保不同組織中的節點知道彼此。

當一個包含對錨定節點更新的配置區塊被提交時，對等節點會聯繫錨定節點並從它們那裡了解錨定節點已知的所有對等節點(也就是取得網路中的節點清單)。一旦來自每個組織中的至少一個對等節點聯繫了錨定節點，錨定節點就會知道渠道中的每個對等節點。由於 gossip 通訊是持續不斷的，並且因為節點總是要知道新節點的存在，所以可以為渠道建立一個共同的成員視圖。

例如，假設我們在渠道中有三個組織 — — A、B、C — — 和一個為組織 C 定義的錨定節點 — — peer0.orgC。當 peer1.orgA（來自組織 A）聯繫 peer0.orgC 時，它將告知peer0.orgA。稍後當 peer1.orgB 聯繫 peer0.orgC 時，後者會告訴前者有關 peer0.orgA 的訊息。從那時起，組織 A 和 B 將開始直接交換成員信息，而無需 peer0.orgC 的任何幫助。

由於跨組織的通訊依賴於 gossip 才能正常運作，因此必須在渠道配置中定義至少一個錨定節點。但強烈建議每個組織都提供自己的一群錨定節點，以實現高可用性和冗餘。另外錨定節點不需要與領導節點相同。

內部與外部的端點(Endpoints)

為了讓 gossip 有效工作，節點需要能夠獲取自己組織中的節點以及其他組織中節點的端點訊息。

當節點在開機過程中時，它將使用 core.yaml 中的 peer.gossip.bootstrap 來廣播自己並交換成員訊息，從而構建其組織內所有可用節點的視圖。

節點的core.yaml 內的peer.gossip.bootstrap 屬性用於引導組織內的 gossip。如果我們使用 gossip，我們通常會將組織中的所有對等節點配置成指向初始引導對等點群(bootstrap peers)。內部端點通常由對等節點本身自動計算，或者只是通過 core.yaml 中的 core.peer.address 來明定。如果需要覆寫此參數值，可以將 CORE_PEER_GOSSIP_ENDPOINT 導出為環境變量。

建立跨組織的通訊同樣需要引導訊息(Bootstrap information)。初始跨組織引導訊息是通過上述“錨定節點點”設置提供的。如果我們想讓組織中的其他節點被其他組織知道，我們需要在節點的 core.yaml 中設置 peer.gossip.externalendpoint。如果沒設定，該節點的端點訊息將不會廣播給其他組織的節點。

設定指令如下：

export CORE_PEER_GOSSIP_BOOTSTRAP=<a list of peer endpoints within the peer's org>
export CORE_PEER_GOSSIP_EXTERNALENDPOINT=<the peer endpoint, as known outside the org>

Gossip訊息傳播

處於線上的對等節點通過持續廣播“還活著”訊息來說明它們的可用性，每個訊息都包含PKI(public key infrastructure) ID 和訊息中發送者的簽名。對等節點通過收集這些訊息來維護渠道成員的狀態；如果沒有對等節點從特定對等節點接收到活著的訊息，則這個“掛掉”的對等節點最終會從渠道成員資格中清除。因為“活著”的訊息是經過加密簽名，駭客永遠無法冒充其他對等節點，因為它們缺少由Root CA 授權的簽名密鑰。

除了自動轉發接收到的訊息之外，狀態協調過程還會在每個渠道上的對等節點之間同步world state。每個對等節點不斷地從渠道上的其他對等節點拉取區塊，以便在發現差異時修復自己的狀態。由於不需要固定的連線來維持基於Gossip的資訊傳播，因此該過程可靠地為共享帳本提供資料的一致性和完整性，包括對有節點掛掉的容忍度。

由於渠道是隔離的，一個渠道上的對等節點不能在任何其他渠道上發送或共享不屬於該渠道的訊息。儘管任何對等節點都可以同時屬於多個渠道，但分區訊息(partitioned messaging)傳遞通過套用基於對等節點的渠道訂閱的訊息路由政策(routing policies)來防止區塊被傳播到不在渠道中的對等節點。

另外， point-to-point messages的安全性由對等 TLS 層處理，不需要簽名。對等節點通過其憑證進行身份驗證，這些憑證由 CA 分配。儘管也使用了 TLS 憑證，但在 gossip 層中驗證的是對等節點的憑證。帳本的區塊由排序服務簽名，然後通過渠道傳遞給領導節點。

而身份驗證由對等節點的MSP管理。當對等節點第一次連接到渠道時，TLS session與成員身份綁定。這等同於在區塊鏈網路與渠道中對每個會互相連接的對等節點做相互的身分驗證。