我們該如何設計網絡，才能讓客戶端只需為網絡貢獻少量數據，就讓整個網絡（這些貢獻）具有很大的意義呢？ —— Piper Merriam
我們很高興地宣布，Nimbus 將加入以太坊基金會的“門戶網絡” 團隊，作為門戶網絡的啟動客戶端之一。
一句話總結：“門戶網絡” 是一個開發中的跨客戶端項目，為的是重新構想以太坊的輕客戶端，並開發出一套可用且實用的輕客戶端體驗。
直接引用這份規範的表述：
“門戶網絡” 是一個還在開發的項目，為了讓資源有限的設備也能輕量地訪問協議。 “門戶” 一詞的含義是，這些網絡可以觀察到協議運行的現狀，但對核心的以太坊協議的運行又無關緊要。門戶網絡將由一個或多個去中心化的點對點網絡組成，這些網絡共同提供暴露標準的JSON-RPC API 所需的數據和功能.這些網絡是經過專門設計的,為了保證參與這些客戶端只需付出最小化的網絡帶寬、CPU、RAM 和機械硬盤資源即可加入。 “門戶網絡” 一詞也用來描述參與這些網絡並暴露標準的JSPN-PRC API 的軟件.
特別地，我們的目標是與EF 一道，圍繞已有的以太坊協議，開發出一組新的以太坊協議，能專門服務於這種獲取以太坊數據的新方法。
總體目標是為以太坊提供一個操作模式，能夠服務於常見的使用模式，而不是實時追踪完整的狀態（當前的客戶端就是這麼做的）。
我們正在討論要開發的是一個用於錢包的完美客戶端，一個極輕客戶端，可以給網絡作貢獻，但又不要求同步區塊鏈（也即是可以在離線之後重啟即用，安裝之後立即可用）。
這也沒有聽起來那麼困難。我想像大部分錢包都直接嵌入輕客戶端，比如 @ethstatus 將集成一個 @ethnimbus 輕客戶端。所以可能出現這樣一種情況：大部分用戶都在不知不覺中就開始運行輕客戶端了。 May 24, 2021
因此，我們的一個最終目標是，將這種客戶端直接敲入到Status app 中。
它有潛力能提升我們用戶的安全性和隱私性（我們也不再需要依賴Infura 了），同時提高以太坊的可靠性，因為更多用戶可以為網絡的健康作貢獻。
背景
門戶網絡根植於開發者Piper Merriam 以及Trinity 團隊的初始目標：在現有的網絡上開發一個輕量級的客戶端。它的誕生是因為他們意識到了，現有的網絡對於他們所設想的客戶端類型來說不夠靈活。
用Piper 的話來說：
當我們開始開發Trinity 客戶端時，我們的目標是開發一個輕量級的客戶端。但花了接近三年時間深入了解協議、探索開發我們所設想的客戶端的途徑之後，我們最終得出一個結論：它在現有的網絡上是做不出來的。這就是門戶網絡的初衷。我們要回到我們想要的客戶端形態，然後設計出其運行所必需的網絡功能。 Trinity 客戶端不會再開發下去了，我們正在開發一個獨立的門戶客戶端，叫做“Trin”，用Rust 語言編寫，將是門戶網絡的啟動客戶端之一。
動機（輕客戶端視角）
現有的DevP2P LES 網絡在設計上採用了客戶端/服務器架構，輕客戶端作為客戶端，而全節點作為服務器端（到今天為止，“輕客戶端” 這個術語指的都是現有DevP2P LES網絡的一個客戶端）。
因為這種架構把所有的負載都交給全節點來承擔，而全節點的運營成本已經很高了，所以節點運營者就不願意打開這個功能。
所以，雖然當前的網絡設計很好地實現了其初始目標，但從輕客戶端的視角來看，它是嚴重的失敗。
我們如何解決這個問題呢？就像Piper 的Trinity 團隊發現的那樣，現實表明這個問題沒有簡單的解決方案。現有的網絡不夠靈活，無法做出高效的輕客戶端設計。
修復這個問題需要我們回到一張白紙，重新設計協議的核心。
設計
一個輕客戶端友好的網絡，必須設計得節點只需付出少量存儲空間、少許工作量，就能參與網絡並為網絡做貢獻，而不是要求每個節點都必須承擔很高的負載（即：在內存裡保存區塊鏈的完整歷史）。
換句話來說，這樣一個網絡必須允許輕客戶端在實際上為網絡做出貢獻，使得每當有額外的客戶端加入網絡，都會增強網絡的容量。
具體來說，這意味著要提出一種網絡設計，可以減少你的偶發請求的數據的驗證開銷，並降低在網絡中傳遞消息的基本開銷。
門戶網絡的目標是通過將以太坊協議的整體結構為三個獨立的網絡：Gossip（事務和區塊）狀態以及歷史，來實現這一點；最開始的開發重心是狀態網絡。
這些網絡將與ETH 協議共存—— 但不像ETH 協議，它們不必是完全無懈可擊的，但它們需要能 幾乎 不間斷工作。
願望是這些新的網絡，可以隨著時間的推移，與現有的網絡更加緊密地結合在一起。舉個例子，我們可以設想這樣一個世界：全功能客戶端可以使用歷史門戶網絡來為節點運營者提供額外的選擇，僅存儲他們關心的歷史（可能也就200 MB）而不是整條區塊鏈（大於200 GB）。狀態數據也是如此。
總而言之，這個模塊化的架構—— 其中數據（狀態和區塊鏈歷史）以P2P 的模式來分享，而事務和區塊則靠gossip 來傳播—— 使得輕客戶端可以自己選擇存儲/服務多少狀態數據和歷史數據。
當他們需要訪問本地沒有的數據時，他們可以在相關網絡提出ad hoc 請求（以一種類似於BitTorrent 的方式，一個 DHT 用來發現這些被請求的數據）。
JSON RPC 備註
借用Piper 的精彩文章“設計可用的輕客戶端part 1”（中文譯本）：大部分錢包，包括我們的，在 JSON RPC API 上都是標準化的.
Status 錢包的正確運行需要下列 JSON RPC 端點:
eth_blockNumber 用於跟踪鏈的頂端eth_getBalance 以及 eth_getTransactionCount用於獲得賬戶信息eth_call 用於讀取合約信息eth_estimateGas 以及 eth_gasPrice 用於估計gas 費eth_sendRawTransaction 用於發送用戶的交易eth_getTransactionReceipt 在交易上鍊後獲取回執
如果我們進一步梳理實現錢包功能的必要組件，我們可以得到如下更底層的需求：
訪問賬戶以及合約存儲項（狀態），以支持：eth_call、eth_estimateGas、eth_getBalance 以及 eth_getTransactionCount訪問gossip 網絡（Gossip）以跟踪鏈的頂端以及 eth_sendRawTransaction訪問鏈的歷史（歷史），用於 eth_getTransactionReceipt
若可開啟對狀態、Gossip 和歷史的輕量級訪問，門戶網絡就打開了可嵌入錢包的輕客戶端的大門，它們可以滿足這些需求，而且不需要同步區塊鏈，也不必犧牲隱私性和安全性。
這對現狀來說是個很大的提升，現在我們不得不依賴於Infura 來發起確定的JSON PRC 調用（例如eth_gasPrice ）並發送交易—— 無法訪問狀態，我們就無法服務大部分JSON PRC API，也無法發送交易，因為我們無法參與交易gossip。
項目現狀
我們已經開始為Nimbus 開發一種操作模式，一開始命名為nlpn ，但現在重命名為fluffy ，會與以太坊1 的客戶端同時存在、運行。 fluffy 將使nimbus-eth1 客戶端可以作為網絡中的一個極輕客戶端節點來運行。
初步的工作是開發Portal Wire 協議，這是一個建立在Node Discovery v5.1 協議基礎上的次級協議。我們已經實現了對該協議的基本支持，並且幾週以前，我們就已成功實現了與其它客戶端的握手，包括ddht 客戶端（一個用Python 編寫的門戶網絡客戶端原型）和Trin 客戶端。
下一步
下一步是通過Portal Wire 協議來傳輸數據。我們正在處理狀態數據。這需要“橋節點” 為門戶網絡輸入狀態數據。當前的措施是使用一個Nethermind 客戶端插件作為定制化JSON-PRC API 來給願意充當橋節點的門戶節點提供數據。這一工作已經開始（規範草案在此）。
最終我們的極輕客戶端將支持以太坊JSON-PRC API 的一個子集，所以錢包可以直接集成這種客戶端。
資源
Nimbus 門戶網絡客戶端（nlpn）可以在我們的nimbus-eth1 代碼庫中找到： https://github.com/status-im/nimbus-eth1/tree/master/fluffyPortal Wire 協議已加入nim-eth 代碼庫，作為節點發現協議v5.1 的次級協議：https://github.com/status-im/nim-eth規範：https://github.com/ethereum/stateless-ethereum-specs/網站：https: //www.ethportal.net/一些有關與ddht 和trin 的第一次Portal Wire 協議測試的資料：https://gist.github.com/kdeme/36795f5deae7d02ce1785e9c7d501e53Piper Merriam 撰寫的系列博文：The winding road to functional light clients有關這個主題的一個視頻演講
注：方便的是，所有實現功能性輕客戶端所必須的基礎設施也會自然延伸到無狀態客戶端上，所以會跟無狀態以太坊有很多交叉。實際上，讓無狀態客戶端能夠服務於絕大部分
JSON-PRC API 是門戶網絡的諸多動機中最核心的一個。
加入我們
如果你想為門戶網絡的設計和實現作貢獻，請加入Ethereum R&D discord 的#portal-network 頻道，有許多討論正在進行中。還有一個每週的會議，安排在UTC 時間每週二的下午3 點，會討論最新的開發進度和開放問題。
如果你想加入Nimbus 的開發中，我們歡迎你加入我們的discord。
本文中的所有圖片都應歸功於 Piper Merriam，都是從他的精彩演講“民主化以太坊/以太坊核心協議：整體分解” 中取出來的。
（完）
（文內有許多超鏈接，可點擊左下”閱讀原文“ 從EthFans 網站上獲取）
原文鏈接:
https://our.status.im/nimbus-fluffly/
作者: 0xmiel
翻譯: 阿劍
APP 
