跳至主要内容

頁面上次更新: 2024年7月24日

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

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

現在，對於硬碟空間的高要求是妨礙節點存取普及化的主要障礙。 這主要是因為需要儲存大量以太坊狀態資料。 此狀態資料中包含處理新區塊和交易所需的關鍵資訊。 截至本文撰寫時止，推薦使用 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 樹及提交者-建置者分離）需要先行完成。

了解更多

這篇文章對你有幫助嗎？