Fluffy 客戶端：以太坊的極輕客戶端
我們該如何設計網絡，才能讓客戶端只需為網絡貢獻少量數據，就讓整個網絡（這些貢獻）具有很大的意義呢？
—— Piper Merriam
我們很高興地宣布，Nimbus 將加入以太坊基金會的“門戶網絡” 團隊，作為門戶網絡的啟動客戶端之一。
一句話總結：“門戶網絡” 是一個開發中的跨客戶端項目，為的是重新構想以太坊的輕客戶端，並開發出一套可用且實用的輕客戶端體驗。
直接引用這份規範的表述：
“門戶網絡” 是一個還在開發的項目，為了讓資源有限的設備也能輕量地訪問協議。
“門戶” 一詞的含義是，這些網絡可以觀察到協議運行的現狀，但對核心的以太坊協議的運行又無關緊要。
門戶網絡將由一個或多個去中心化的點對點網絡組成，這些網絡共同提供暴露標準的JSON-RPC API 所需的數據和功能.
這些網絡是經過專門設計的,為了保證參與這些客戶端只需付出最小化的網絡帶寬、CPU、RAM 和機械硬盤資源即可加入。
“門戶網絡” 一詞也用來描述參與這些網絡並暴露標準的JSPN-PRC API 的軟件.
特別地，我們的目標是與EF 一道，圍繞已有的以太坊協議，開發出一組新的以太坊協議，能專門服務於這種獲取以太坊數據的新方法。
總體目標是為以太坊提供一個操作模式，能夠服務於常見的使用模式，而不是實時追踪完整的狀態（當前的客戶端就是這麼做的）。
我們正在討論要開發的是一個用於錢包的完美客戶端，一個極輕客戶端，可以給網絡作貢獻，但又不要求同步區塊鏈（也即是可以在離線之後重啟即用，安裝之後立即可用）。
這也沒有聽起來那麼困難。我想像大部分錢包都直接嵌入輕客戶端，比如@ethstatus 將集成一個@ethnimbus 輕客戶端。所以可能出現這樣一種情況：大部分用戶都在不知不覺中就開始運行輕客戶端了。
May 24, 2021
背景
背景
背景
門戶網絡根植於開發者Piper Merriam 以及Trinity 團隊的初始目標：在現有的網絡上開發一個輕量級的客戶端。它的誕生是因為他們意識到了，現有的網絡對於他們所設想的客戶端類型來說不夠靈活。
用Piper 的話來說：
當我們開始開發Trinity 客戶端時，我們的目標是開發一個輕量級的客戶端。但花了接近三年時間深入了解協議、探索開發我們所設想的客戶端的途徑之後，我們最終得出一個結論：它在現有的網絡上是做不出來的。
一級標題
一級標題
動機（輕客戶端視角）
現有的DevP2P LES 網絡在設計上採用了客戶端/服務器架構，輕客戶端作為客戶端，而全節點作為服務器端（到今天為止，“輕客戶端” 這個術語指的都是現有DevP2P LES網絡的一個客戶端）。
因為這種架構把所有的負載都交給全節點來承擔，而全節點的運營成本已經很高了，所以節點運營者就不願意打開這個功能。
所以，雖然當前的網絡設計很好地實現了其初始目標，但從輕客戶端的視角來看，它是嚴重的失敗。
一級標題
一級標題
設計
一個輕客戶端友好的網絡，必須設計得節點只需付出少量存儲空間、少許工作量，就能參與網絡並為網絡做貢獻，而不是要求每個節點都必須承擔很高的負載（即：在內存裡保存區塊鏈的完整歷史）。
換句話來說，這樣一個網絡必須允許輕客戶端在實際上為網絡做出貢獻，使得每當有額外的客戶端加入網絡，都會增強網絡的容量。
具體來說，這意味著要提出一種網絡設計，可以減少你的偶發請求的數據的驗證開銷，並降低在網絡中傳遞消息的基本開銷。
門戶網絡的目標是通過將以太坊協議的整體結構為三個獨立的網絡：Gossip（事務和區塊）狀態以及歷史，來實現這一點；最開始的開發重心是狀態網絡。
這些網絡將與ETH 協議共存—— 但不像ETH 協議，它們不必是完全無懈可擊的，但它們需要能幾乎不間斷工作。
願望是這些新的網絡，可以隨著時間的推移，與現有的網絡更加緊密地結合在一起。舉個例子，我們可以設想這樣一個世界：全功能客戶端可以使用歷史門戶網絡來為節點運營者提供額外的選擇，僅存儲他們關心的歷史（可能也就200 MB）而不是整條區塊鏈（大於200 GB）。狀態數據也是如此。
一級標題
一級標題
中文譯本
中文譯本中文譯本）：大部分錢包，包括我們的，在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
如果我們進一步梳理實現錢包功能的必要組件，我們可以得到如下更底層的需求：
一級標題
一級標題
項目現狀
我們已經開始為Nimbus 開發一種操作模式，一開始命名為nlpn ，但現在重命名為fluffy ，會與以太坊1 的客戶端同時存在、運行。
fluffy 將使nimbus-eth1 客戶端可以作為網絡中的一個極輕客戶端節點來運行。
下一步
下一步
下一步
下一步是通過Portal Wire 協議來傳輸數據。我們正在處理狀態數據。
資源
一級標題
資源
Nimbus 門戶網絡客戶端（nlpn）可以在我們的nimbus-eth1 代碼庫中找到： https://github.com/status-im/nimbus-eth1/tree/master/fluffy
Portal 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/36795f5deae7d02ce1785e9c7d501e53
Piper Merriam 撰寫的系列博文：The winding road to functional light clients
有關這個主題的一個視頻演講
注：方便的是，所有實現功能性輕客戶端所必須的基礎設施也會自然延伸到無狀態客戶端上，所以會跟無狀態以太坊有很多交叉。實際上，讓無狀態客戶端能夠服務於絕大部分JSON-PRC API 是門戶網絡的諸多動機中最核心的一個。
