Fluffy客戶端:以太坊的極輕客戶端

我們該如何設計網路,才能讓客戶端只需為網路貢獻少量數據,就讓整個網路(這些貢獻)具有很大的意義呢? —— Piper Merriam 我們很高興地宣布, Nimbus 將加入以太坊基金會的 「門戶

Fluffy客戶端:以太坊的極輕客戶端

我們該如何設計網路,才能讓客戶端只需為網路貢獻少量數據,就讓整個網路(這些貢獻)具有很大的意義呢?

—— 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 團隊發現的那樣,現實表明這個問題沒有簡單的解決方案。現有的網路不夠靈活,無法做出高效的輕客戶端設計。

修復這個問題需要我們回到一張白紙,重新設計協議的核心。

設計

一個輕客戶端友好的網路,必須設計得節點只需付出少量存儲空間、少許工作量,就能參與網路並為網路做貢獻,而不是要求每個節點都必須承擔很高的負載(即:在內存里保存區塊鏈的完整歷史)。

換句話來說,這樣一個網路必須允許輕客戶端在實際上為網路做出貢獻,使得每當有額外的客戶端加入網路,都會增強網路的容量。

具體來說,這意味著要提出一種網路設計,可以減少你的偶發請求的數據的驗證開銷,並降低在網路中傳遞消息的基本開銷。

Fluffy客戶端:以太坊的極輕客戶端

門戶網路的目標是通過將以太坊協議的整體結構為三個獨立的網路:Gossip(事務和區塊)狀態以及歷史,來實現這一點;最開始的開發重心是狀態網路。

Fluffy客戶端:以太坊的極輕客戶端

這些網路將與 ETH 協議共存 —— 但不像 ETH 協議,它們不必是完全無懈可擊的,但它們需要能?幾乎?不間斷工作。

Fluffy客戶端:以太坊的極輕客戶端

願望是這些新的網路,可以隨著時間的推移,與現有的網路更加緊密地結合在一起。舉個例子,我們可以設想這樣一個世界:全功能客戶端可以使用歷史門戶網路來為節點運營者提供額外的選擇,僅存儲他們關心的歷史(可能也就 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/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 是門戶網路的諸多動機中最核心的一個。

—-

編譯者/作者:以太坊愛好者

玩幣族申明:玩幣族作為開放的資訊翻譯/分享平台,所提供的所有資訊僅代表作者個人觀點,與玩幣族平台立場無關,且不構成任何投資理財建議。文章版權歸原作者所有。

0

發表迴響