跳至主要内容

頁面上次更新: 2024年2月20日

無狀態、狀態過期及歷史記錄過期

能在一般硬體上運行以太坊節點對實現真正的去中心化非常重要。 這是因為運行節點讓使用者可以透過獨立執行加密檢查來驗證資訊,而不是信任第三方為他們提供資料。 透過運行節點,使用者可以將交易直接提交到以太坊對等網路,而不必信任中介。 如果只有擁有昂貴硬體的使用者能夠使用這些功能,去中心化不可能實現。 相反,節點對於處理和記憶體的要求應該非常適度,如此才能在行動電話、微型電腦或家用電腦上運行。

現在,對於硬碟空間的高要求是妨礙節點存取普及化的主要障礙。 這主要是因為需要儲存大量以太坊狀態資料。 此狀態資料中包含處理新區塊和交易所需的關鍵資訊。 截至本文撰寫時止,推薦使用 2TB 的固態硬碟運行以太坊全節點。 對於不刪除任何舊資料的節點,儲存需求以每週大約 14GB 的速率增長,儲存自創世以來所有資料的存檔節點已達到接近 12 TB(截至 2023 年 2 月本文撰寫時止)。

便宜的硬碟可以用來儲存一些較舊的資料,但相較於新區塊的產生速度還是太慢了。 為用戶端保留目前的儲存模型,同時使資料儲存更便宜和容易只是暫時性的解決方案,只能解決一部分問題,因為以太坊的狀態資料增長速度是「無限的」,也就是說儲存需求只增不減,且技術進步必須持續跟上狀態資料增長的速度。 相反,用戶端必須找到新的方法來驗證區塊和交易,而不依賴從本地資料庫查詢資料。

減少節點儲存空間

有幾種方法可以減少每個節點必須儲存的資料量,每種方法都要求對以太坊的核心協定進行不同程度的更新:

  • 歷史記錄過期:允許節點丟棄早於第 X 個區塊的狀態資料,但不改變以太坊用戶端處理狀態資料的方式。
  • 狀態過期:允許將不常用的狀態資料設定為不活動狀態。 用戶端可以忽略不活動的資料,直到其恢復為止。
  • 弱無狀態:只有區塊提交者需要存取完整的狀態資料,其他節點可以在沒有本地資料庫的情況下驗證區塊。
  • 強無狀態:所有節點都不需要存取完整的狀態資料。

資料過期

歷史記錄過期

歷史記錄過期指用戶端刪除不太可能需要的舊資料,只儲存少量歷史資料,並在新資料到達時刪除舊資料。 節點之所以需要歷史資料,原因有二:同步和滿足資料請求。 最初,用戶端必須從初始區塊同步,驗證一直到鏈頭為止每個連續的區塊皆正確無誤。 如今,用戶端使用「弱主觀性檢查點」來啟動到鏈頭。 這些檢查點是受信任的起始點,如同初始區塊接近現在,而非以太坊的最開始。 這表示用戶端可以刪除最近的弱主觀性檢查點之前的所有資訊,不失去同步到鏈頭的能力。 目前,用戶端透過從本機資料庫取得歷史資料來滿足相關請求(透過 JSON-RPC 傳送)。 然而,隨著歷史記錄過期,如果請求的資料已被刪除,這將無法實現。 提供這些歷史資料也需要一些創新的解決方案。

選項之一是用戶端透過門戶網路向對等節點請求歷史資料。 門戶網路是處於開發階段的對等網路,用於提供歷史資料,其中每個節點儲存一小部分以太坊歷史記錄,整個歷史記錄分佈在整個網路。 滿足請求的方式是,尋找儲存有相應資料的對等節點,並向它們索取資料。 或者,由於請求存取歷史資料的通常是應用程式,因此儲存歷史資料可能變成它們的責任。 以太坊上有足夠多的利他主義者願意維護歷史資料存檔。 這可能會是一個用於管理歷史資料儲存檔的去中心化自治組織,理想情況下將是所有這些選項的組合。 這些提供者可以透過多種方式提供資料,例如透過 Torrent、FTP、Filecoin 或星際檔案系統。

歷史記錄過期是有爭議的,因為截至目前,以太坊一直隱式保證歷史資料的可用性。 創世以來的完全同步始終可以作為標準,即使它依賴從快照重建一些較舊的資料。 歷史記錄過期將提供這種保證的責任轉移到以太坊核心協定之外。 如果中心化組織最終介入提供歷史資料,可能引發新的審查危機。

EIP-4444 尚未準備好上線,但正在積極討論當中。 有趣的是,EIP-4444 面臨的挑戰並不在於技術,而主要在於社群管理。 為了實現這一點,我們需要社群的支援,不僅包括協定,還包括可信實體對於歷史資料的儲存及提供方面的承諾。

這個升級並沒有從根本上改變以太坊節點處理狀態資料的方式,只是改變了歷史資料的存取方式。

狀態過期

狀態過期指將最近未存取過的單一節點的狀態移除。 有幾種方式可以實現這點,包括:

  • 依租金過期:向帳戶收取「租金」,並在租金達到零時將帳戶設為過期
  • 依時間過期:如果一段時間內沒有對一個帳戶執行讀取/寫入操作,則將該帳戶設定為不活動狀態

依租金過期可以是直接向帳戶收取租金,以將其保留在活動狀態資料庫中。 依時間過期可以是從上次帳戶互動開始的倒數計時,也可以是所有帳戶的定期過期。 也可能存在將基於時間和基於租金的模型結合起來的機制,例如:若個人帳戶在基於時間的過期之前支付一些小額費用,則該等帳戶會持續處於活動狀態。 在狀態過期下,需要注意的是,不活動狀態不會刪除,只是與活動狀態分開儲存而已。 不活動狀態可以恢復為活動狀態。

其作用原理可能是針對特定時間週期(可能約一年)建立狀態樹。 每個新的週期開始時,都建立全新的狀態樹。 只有目前的狀態樹可以修改,其他的狀態樹都不可變。 以太坊節點應儲存目前的狀態樹和下一個最近的狀態樹。 這需要一種方法來為地址新增其存在的時間週期的時間戳。 有幾種方式(opens in a new tab)可以做到這點,但主要方案需要加長地址(opens in a new tab)以容納額外資訊,同時地址越長也越安全。 開發藍圖上,這個部分被稱為地址空間擴展(opens in a new tab)

與歷史記錄過期相似,在狀態過期下,儲存舊資料的責任將從個人使用者處卸去,並交棒給其他實體,如中心化提供者、利他的社群成員或更具未來性的去中心化解決方案(例如門戶網路)。

狀態過期仍在研究階段,且尚未準備好上線。 狀態過期很可能晚於無狀態用戶端和歷史記錄過期,因為這些升級使得大多數驗證者可以輕鬆管理大型狀態。

無狀態

無狀態這個詞有點用詞不當,因為它並不意味著「狀態」的概念被消除,但確實涉及以太坊節點對狀態資料處理方式的改變。 無狀態本身有兩種類型:弱無狀態和強無狀態。 弱無狀態會將狀態儲存的職責交給少數節點,因此多數節點可以達到無狀態化。 強無狀態完全消除了所有節點儲存完整狀態資料的需求。 弱/強無狀態兩者都為一般驗證者提供了以下好處:

  • 接近即時的同步速度
  • 不需按順序驗證區塊
  • 運行節點的硬體需求極低(例如在手機上運行)
  • 由於不需要進行硬碟讀寫,節點可以在便宜的硬碟上運行
  • 與以太坊未來的加密技術升級相容

弱無狀態

弱無狀態涉及變更以太坊節點處理狀態資料的方式,但並沒有完全消除網路上所有節點的狀態儲存需求。 但是,弱無狀態將狀態儲存的責任交棒給了區塊提交者,而網路上的所有其他節點都會驗證區塊而不儲存完整的狀態資料。

在弱無狀態中,提出區塊需要存取完整的狀態資料,但驗證區塊不需要狀態資料。

為此,必須先在以太坊用戶端中實作沃克爾樹。 沃克爾樹是儲存以太坊狀態資料的替代資料結構,允許小型、固定大小的「證據」在節點間傳遞,並用於驗證區塊,而不是根據本地資料庫驗證區塊。 提交者-建置者分離也是必要的,因為這讓區塊建置者成為有更強大硬體的特殊化節點,這些節點需要存取完整的狀態資料。

區塊提交者使用狀態資料來建立「證據」,即證明區塊中的交易正在更改的狀態值的最小資料集。 其他驗證者不儲存狀態,只儲存狀態根(整個狀態的的雜湊值)。 他們會接收區塊和證據,然後用其更新自己的狀態根。 這使得驗證節點的工作變得極輕量。

弱無狀態正處於進階研究階段,但它依賴提交者-建置者分離策略和沃克爾樹的實作,因而小的證據才能在節點間傳遞。 這表示弱無狀態大概還要幾年才會在以太坊主網上發佈。

強無狀態

強無狀態消除了所有區塊儲存狀態資料的需求。 取而代之的是,交易會和證據一起傳送,區塊建置者可以匯集這些證據。 接著,區塊生產者負責僅儲存為相關帳戶產生證據所需的狀態。 儲存狀態的責任幾乎完全交給使用者了,因為他們會傳送證據和「存取清單」以宣告他們在和哪些帳戶及儲存金鑰互動。 這會啟用極輕量節點,不過也需要權衡,因為這會使其與智慧型合約互動更加困難。

研究者已經研究過強無狀態,但目前預計其不會成為以太坊開發藍圖的一部分。比較可能的狀況是,弱無狀態對以太坊的擴容需求來說已經足夠。

目前進度

弱無狀態、歷史記錄過期和狀態過期目前都處於研究階段,預計幾年後才會上線。 我們並不保證所有提案都會實作,舉例來說,如果已經先實作狀態過期,可能就不需要再實作歷史記錄過期了。 還有其他開發藍圖事項(如 Verkle 樹提交者-建置者分離)需要先行完成。

了解更多

這篇文章對你有幫助嗎?