IC的P2P層如何實作安全可擴展性

Internet Computer使開發者可以開發Canisters組成面向C端用戶的Dapp，任何開發者都可以在IC上重新構想去中心化網路服務、DeFi、社交Dapp、NFT、游戲等應用，因此在Internet Computer在最初設計時就考慮到自身承載泛平臺所需的安全、可靠、和可拓展性，

可拓展性一直是一個非常重要的因素，它主要依賴于IC網路中的訊息分發的效率，網路越大，承載的Dapp越多，分發的訊息就越多，為此Internet Computer采用分片技術將網路劃分為多個子網，每個子網都可以被視為是一個IC區塊鏈，它們通過選定節點組成子網運行組成Dapp的Canisters，IC P2P層是同一子網節點之間實作安全、可靠、可擴展通行的Layer，

Internet Computer協議有四個主要Layer組成：

• 執行管理層用于確定性軟體訊息的安全環境；

• 訊息路由層在子網之間的路由用戶和系統生成的訊息，管理應用程式的輸入和輸出佇列，并調度訊息以供執行；

• 共識層選擇和排序從用戶和不同子網接收的訊息，以創建可以在竄地到訊息路由層之前進行公正和最終確定的區塊；

• 點對點（P2P）層從用戶以及同一子網中的其他節點收集和發布訊息，P2P層將接收到的訊息廣播到子網的其他節點，以確保平臺的安全、可靠和彈性，

IC P2P層要實作的是安全性、性能和可擴展性：Internet Computer的設計是即使是存在惡意節點時也能確保安全運行，因此IC P2P層和協議皆在確保即使存在最多有三分之一惡意節點的情況下也能保持運行，IC P2P層與其他傳統區塊鏈的P2P層設計不同，IC 的P2P層增加了復雜性和性能的權衡，在以下會說到IC P2P層如何以最小的性能開銷實作安全目標，同時使子網能夠擴展，

此外IC P2P層為訊息提供了獨特的優先級機制，這樣不僅可以更快的傳送重要訊息，并通過不發送不需要的訊息來節省帶寬，

在這篇博文中，將涉及IC P2P層的以下幾個方面：

• 要求；

• 基本原則；

• 與Dapp程式組件的互動；

• 資料結構；

• Gossip分布式協議；

• 寬帶和記憶體注意事項，

IC P2P層負責發送上面Layer（例如共識）創建的Artifacts，并負責接受、驗證、處理和分發來自同一子網中其他節點以及來自用戶的Artifacts，IC P2P層保證，如果有正確節點想其對點節點發送Artifacts，則該Artifacts最終被子網中需要它的所有正確節點接收，這可以看作是可靠廣播的一種特殊情況，這是為IC共識演算法量身定制的，具有優先級，在某些網路假設下，它提供限時交付，

Dfinity希望IC P2P層在以下要求下提供這種保證：

• 盡管存在拜占庭故障，但保證限時/最終交付；

• 為不同的Dapp程式組件/對點保留資源；

• 有界資源（包括CPU、記憶體、硬碟）；

• 不同Artifacts的優先級；

• 高效率；

• DOS/垃圾郵件彈性；

• 加密、真實性和完整性；

IC P2P層使用Gossip分布式機制在子網中分發訊息，gossip協議的原理就是將收到的訊息或創建的訊息發送給子網中的對點方，P2P中的對點方由覆寫網路拓撲（組成網路之間設備的分布情況以及連接狀態）確定，一切都保證在O（diameter）hops中傳遞，如果覆寫是無向連接的，則所有節點遵循協議，并且不會丟棄任何訊息，

IC P2P層被設計為在即使在拜占庭節點存在的情況下也具有容錯能力，IC P2P層在設計時就考慮了在子網中會出現此類節點的可能性，所以IC P2P層保證即使子網中多大三分之一的節點是拜占庭節點也能正確有效的運行：如果一個節點表現出惡意（不遵守協議、試圖傷害其他節點或用戶）或者如果它表現出一些錯誤行為（不回應、不分發Artifacts，遭受嚴重的網路延遲），基于IC P2P層的容錯能力只要不超過三分之一的是拜占庭節點該子網也能正確有效運行，

在考慮拜占庭節點時，Dfinity希望避免幾個問題，第一種是所謂的eclipse攻擊，其中某個節點的所有對點方是惡意或是有故障的，惡意節點可以串通并選擇正確節點看到的Artifacts，并將該節點與網路的其余部分斷開，因為會驗證訊息的真實性，惡意節點無法用欺騙訊息欺騙誠實節點，但連接性問題仍然存在，為了避免這種情況，必須使用覆寫來保證與足夠多的對點節點的連接，一個節點可以連接子網中的所有其他節點，形成一個完整的圖，從而提供完美的eclipse攻擊保護，對于較大的子網，例如托管NNS的子網采用稀疏覆寫，

因為想保證在一定時間內所有依賴它們的節點都收到Artifacts，所以gossip分布式協議需要確保這些Artifacts被交付，盡管可能存在故障鏈接和節點問題，但是gossip分布式協議通常基于傳播模式會導致帶寬的亢余和浪費，因此減少這些開銷的方式設計此類協議非常重要，

Artifacts可能會很大，如果這些Artifacts從多個對點多次發送，則會導致嚴重的帶寬浪費，這類似于不得不從多個朋友那里一遍又一遍的聽到相同的謠言，在這個比喻中，你的朋友可以先問你是否聽說過最新訊息，而不是告訴你謠言，在背景關系中，這對應于發送廣告，廣告是小訊息，僅包含Artifacts的元資料和一些驗證它們的方法，但不包含其內容，每個節點從至少一個對點方請求它需要的Artifacts，在IC的設計中，將從詢問一個對點開始，但是如果遇到問題，可能會向另一個對點詢問相同的Artifacts，這可能會重復，直到找到一個沒有故障的誠實對點節點，

廣告包括由gossip分布式協議及其應用程式組件用于完整性驗證（完整性哈希）和用于決策（幫助組件對Artifacts進行優先級排序的屬性）的欄位，

一個節點可能會收到多個廣告，因此必須選擇首先請求哪些Artifacts，每個廣告都包含一些創建它客戶端組件提供的屬性，例如共識Artifacts包含一個height屬性，它告訴相應Artifacts的區塊高度，共識還為gossip提供了優先功能，它接受一個廣告（及其屬性）并回傳一個優先級值（最低的是 drop，這意味著不需要這個Artifacts，最高的是ftch now，這意味著最高優先級的Artifacts），如果現在共識現在處于高度10，它可能更喜歡該高度10的Artifacts而不是高度11和12的Artifacts，這取決于它們的型別以及可能的其他狀態引數（作為一般規則，它更喜歡相同高度而不是不同的高度），IC的P2P層采用這些優先級值來確定應該首先請求哪個Artifacts，

P2P商店在Artifacts中接收Artifacts，它通知共識和其他客戶端組件有關Artifacts池中的更改，然后應用程式組件確定其關于Artifacts池內容的下一步操作，Artifacts池中包含每一個應用程式組件的所有可用Artifacts，

通過將Artifacts分類為已驗證或未驗證，后一類用于尚未驗證的Artifacts，驗證意味著由客戶端組件檢查Artifacts，例如通過驗證簽名，如果需要可以將客戶端的Artifacts池持久化到非易失性存盤中，這樣做的目的是為了共識Artifacts，

在上面可以看到一個節點為gossip分布式協議保存了哪些資料結構，左側是Artifacts池，它分為已驗證和未驗證部分，未驗證部分包含那些尚未驗證的Artifacts，每個未驗證部分的大小是有界的，以防阻止惡意節點填滿Artifacts池從而導致資源泄漏和拒絕服務攻擊，但足夠大以確保協議在正常情況下正確運行，

此外對于每個對點，維護其背景關系，這有助于跟蹤了收到了哪些廣告，向誰請求了哪些廣告：

• 廣告佇列是從該對點方接收到的所有廣告的優先佇列，它們按照優先級排序；

• 請求的集合包含已經從該對點請求相應Artifacts的所有廣告；

• 接收檢查快取用于阻止對最近收到的Artifacts的請求，

以下是gossip分布式協議處理的主要事件：

• Artifacts池中的新Artifacts（由客戶端組件在本地添加）；

• 處理從對點方收到的新廣告；

• 處理從對點方收到的新Artifacts；

• 恢復和重新連接問題，

Artifact池中的新工件（由客戶端組件在本地添加）：

當一個節點從客戶端組件接收到一個新的Artifacts時，它會為它創建一個廣告，并將這個廣告發送給它所有的對點方，

處理從對點方收到的新廣告：

當節點從對點節點收到廣告時，它首先檢查相應Artifacts是否已由節點本身下載或創建，如果不是，此廣告的優先級高于 drop ，則會將廣告添加到發送它的對點方的廣告佇列中，如果Artifacts池的未驗證部分中有足夠的空間供對點方使用，會專門為此對點方i呼叫一個名為 download_next(i)的函式，該函式獲取最高優先級的廣告（基于優先級函式分配的優先級別），并從該對點方請求相應的Artifacts，因此，沒有必要請求剛剛收到廣告的Artifacts，只請求具有最高優先級的Artifacts，

請求Artifacts后，相應的廣告會從廣告佇列移動到向其請求Artifacts的對點方的請求集合，

可能在多個對點方的廣告佇列中會擁有相同的廣告，因為多個對點方可能發送了相同的廣告，廣告將會保留在其他對點方的廣告佇列中，直到收到實際的Artifacts件為止，在Artifacts請求上設定超時是為了防止無回應或緩慢的對點方，這有助于保證有限的時間交付，我們將避免從我們已經提出請求的對點請求Artifacts，因為它可能行為不端，在這種情況下，我們可以看到其他對點方是否已經發布了相同的Artifacts，如果是，我們將在嘗試無回應的對點方之前嘗試從它們哪里獲取它，

處理從對點方收到的新Artifacts：

當我們從對點方收到Artifacts時，我們首先通過檢查相應的廣告是否在對點方的請求集中來確保它是被請求的，然后我們使用相應的完整性哈希驗證其完整性，如果這些檢查中的任何一項失敗，則意味著該對等方行為不端，最終，我們從所有廣告佇列和請求的集合中洗掉該廣告，我們將Artifacts添加到發送它的對點方的未驗證池中，我們將把它留在那里讓客戶端組件檢查和驗證它，我們還將工件的散列添加到稱為接收檢查的小快取中，每個對點維護，以忽略同一Artifacts的進一步廣告，這樣做是為了應用程式組件提供一些寬限期來更新它們的優先級函式，這樣即使Artifacts從Artifacts池中的未驗證部分中洗掉，它們也不會再次請求相同的廣告，如果我們在未經驗證的Artifacts池中仍有空間供此對點體使用，我們將根據優先級使用 download_next(i) 函式從中請求下一個Artifacts，

傳輸和連接管理：

在 gossip 組件下方，有一個傳輸組件，用于維護對點之間的實際網路連接，傳輸組件負責保持連接穩定，對于瞬態連接問題和擁塞情況，它有自己的緩沖區，它有一個內部機制來確保連接不會掛起并檢測比平常更長的延遲，這對于提供限時交付很重要，具有自己的第 7 層標頭的傳輸幀gossip訊息，其中包含一些由傳輸組件用于維護流和報告錯誤的元資料欄位，目前，傳輸在對點之間使用多個 TCP 流，

傳輸以適應這種分布式對點網路的方式使用 TLS 1.3，沒有證書頒發機構層次結構作為信任根，相反，信任根是為節點提供自簽名證書的注冊表，以便節點可以對其對點方進行身份驗證，

如果 TCP 連接中斷，Transport 會定期嘗試重新連接（只要相應的對點方仍在節點分配的覆寫層上），當重新建立連接時，我們會清空相應的傳輸佇列并開始接收新訊息，

由于所有資料結構都有大小限制，這也適用于傳輸緩沖區，如果這樣的緩沖區已滿，或者如果我們一直在等待重新連接，傳輸最侄訓通知接收器gossip組件潛在的訊息丟失，然后接收方可以發送重傳請求，重傳請求是gossip分布式協議的訊息，它有一個過濾器來告訴接收者請求的發送者看到的最新Artifacts，可能是在發送此請求時其它對點已經成功發送了相同的廣告，因此節點可能不需要在它錯過的所有訊息上趕上相應的對點，

收到重傳請求后，發送方節點根據請求中包含過濾器發送所有相關廣告，傳輸這些廣告發送給接收者，如果在此程序中佇列再次變滿，則會將發送剩余廣告的另一個重傳請求，

總而言之，IC P2P層保證了子網中Artifacts的有限交付，它使用廣告-請求-Artifacts模式和覆寫拓撲來減少帶寬開銷，并為客戶端組件提供優先級 API，以確保首先交付最高優先級的Artifacts，該協議具有容錯性，并且考慮到了拒絕服務攻擊和其他威脅，