--- title: "無狀態性、狀態過期與歷史記錄過期" description: "歷史記錄過期與無狀態以太坊的解釋" lang: zh-tw template: roadmap --- 在普通硬體上運行 [以太坊](/) 節點的能力對於真正的去中心化至關重要。這是因為運行節點讓使用者能夠透過獨立執行密碼學檢查來驗證資訊，而不是信任第三方提供資料。運行節點允許使用者直接將交易提交到以太坊點對點網路，而無需信任中介機構。如果這些好處只提供給擁有昂貴硬體的使用者，去中心化是不可能的。相反，節點應該能夠在極低的處理和記憶體要求下運行，以便它們可以在手機、微型電腦上運行，或者在家庭電腦上無感地運行。 如今，高磁碟空間要求是阻礙節點普及的主要障礙。這主要是因為需要儲存大量以太坊的狀態資料。這些狀態資料包含正確處理新區塊和交易所需的關鍵資訊。在撰寫本文時，建議使用快速的 2TB SSD 來運行完整的以太坊節點。對於不修剪任何舊資料的節點，儲存需求以每週約 14GB 的速度增長，而儲存自創世區塊以來所有資料的歸檔節點正接近 12 TB（在撰寫本文時，即 2023 年 2 月）。 可以使用較便宜的硬碟來儲存舊資料，但它們的速度太慢，無法跟上新產生的區塊。保持客戶端目前的儲存模型，同時讓資料變得更便宜、更容易儲存，只是解決問題的暫時且部分的方案，因為以太坊的狀態增長是「無上限的」，這意味著儲存需求只會不斷增加，而技術改進將始終必須跟上持續的狀態增長。相反，客戶端必須找到驗證區塊和交易的新方法，而不依賴從本地資料庫中尋找資料。 ## 減少節點的儲存空間 {#reducing-storage-for-nodes} 有幾種方法可以減少每個節點必須儲存的資料量，每種方法都要求對以太坊核心協定進行不同程度的更新： - **歷史記錄過期**：使節點能夠丟棄早於 X 個區塊的狀態資料，但不改變以太坊客戶端處理狀態資料的方式。 - **狀態過期**：允許不常使用的狀態資料變為非活躍狀態。非活躍資料可以被客戶端忽略，直到它被復活。 - **弱無狀態性**：只有區塊生產者需要存取完整的狀態資料，其他節點可以在沒有本地狀態資料庫的情況下驗證區塊。 - **強無狀態性**：沒有節點需要存取完整的狀態資料。 ## 資料過期 {#data-expiry} ### 歷史記錄過期 {#history-expiry} 歷史記錄過期是指客戶端修剪掉它們不太可能需要的舊資料，因此它們只儲存少量的歷史資料，並在新資料到達時丟棄舊資料。客戶端需要歷史資料有兩個原因：同步和提供資料請求服務。最初，客戶端必須從創世區塊開始同步，驗證每個連續的區塊是否正確，一直到鏈的頂端。如今，客戶端使用「弱主觀性檢查點」來引導它們到達鏈的頂端。這些檢查點是受信任的起點，就像擁有一個接近現在的創世區塊，而不是以太坊的最開始。這意味著客戶端可以丟棄最近的弱主觀性檢查點之前的所有資訊，而不會失去同步到鏈頂端的能力。客戶端目前透過從其本地資料庫中抓取歷史資料來提供（透過 JSON-RPC 到達的）請求服務。然而，隨著歷史記錄過期，如果請求的資料已被修剪，這將是不可能的。提供這些歷史資料正是需要一些創新解決方案的地方。 一個選項是客戶端使用諸如波特爾網路等解決方案向對等節點請求歷史資料。波特爾網路是一個開發中的點對點網路，用於提供歷史資料，其中每個節點儲存以太坊歷史的一小部分，使得整個歷史記錄分散存在於整個網路中。透過尋找儲存相關資料的對等節點並向它們請求來提供請求服務。或者，由於通常是應用程式需要存取歷史資料，因此儲存它可能成為它們的責任。在以太坊領域中也可能有足夠的利他主義者願意維護歷史檔案。它可能是一個為了管理歷史資料儲存而成立的去中心化自治組織 (DAO)，或者理想情況下，它將是所有這些選項的結合。這些提供者可以透過多種方式提供資料，例如在 torrent、FTP、Filecoin 或 IPFS 上。 歷史記錄過期有些爭議，因為到目前為止，以太坊一直隱含地保證任何歷史資料的可用性。從創世區塊進行完整同步一直作為標準是可能的，即使它依賴於從快照重建一些舊資料。歷史記錄過期將提供此保證的責任移到了以太坊核心協定之外。如果最終由中心化組織介入提供歷史資料，這可能會引入新的審查風險。 EIP-4444 尚未準備好發布，但正在積極討論中。有趣的是，EIP-4444 的挑戰與其說是技術上的，不如說主要是社群管理上的。為了發布此功能，需要社群的認可，這不僅包括同意，還包括來自可信實體儲存和提供歷史資料的承諾。 這次升級並沒有從根本上改變以太坊節點處理狀態資料的方式，它只是改變了存取歷史資料的方式。 ### 狀態過期 {#state-expiry} 狀態過期是指如果最近沒有存取過，則從個別節點中移除狀態。有幾種方法可以實現這一點，包括： - **按租金過期**：向帳戶收取「租金」，並在租金降至零時使其過期 - **按時間過期**：如果在一段時間內沒有對該帳戶進行讀取/寫入，則使帳戶變為非活躍狀態 按租金過期可能是直接向帳戶收取租金，以將它們保留在活躍狀態資料庫中。按時間過期可能是從最後一次帳戶互動開始倒數計時，或者可能是所有帳戶的定期過期。也可能有結合基於時間和租金模型元素的機制，例如，如果個別帳戶在基於時間的過期之前支付少量費用，則它們會持續處於活躍狀態。關於狀態過期，需要注意的是，非活躍狀態**不會被刪除**，它只是與活躍狀態分開儲存。非活躍狀態可以復活為活躍狀態。 這種運作方式可能是為特定時間段（大約 1 年）建立一個狀態樹。每當一個新時期開始時，就會產生一個全新的狀態樹。只有目前的狀態樹可以被修改，所有其他的都是不可變的。以太坊節點只被要求保留目前的狀態樹和下一個最近的狀態樹。這需要一種方法來為地址加上其存在時期的時間戳記。有[幾種可能的方法](https://ethereum-magicians.org/t/types-of-resurrection-metadata-in-state-expiry/6607)可以做到這一點，但主要選項要求[加長地址](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485)以容納額外資訊，其附加好處是較長的地址更安全。執行此操作的路線圖項目稱為[地址空間擴展](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485)。 與歷史記錄過期類似，在狀態過期下，儲存舊狀態資料的責任從個別使用者身上移除，並推給其他實體，例如中心化提供者、利他主義的社群成員或更具未來感的去中心化解決方案（如波特爾網路）。 狀態過期仍處於研究階段，尚未準備好發布。狀態過期很可能發生在無狀態客戶端和歷史記錄過期之後，因為這些升級使大多數驗證者能夠輕鬆管理龐大的狀態大小。 ## 無狀態性 {#statelessness-2} 無狀態性這個詞有點用詞不當，因為它並不意味著「狀態」的概念被消除，但它確實涉及以太坊節點處理狀態資料方式的改變。無狀態性本身有兩種形式：弱無狀態性和強無狀態性。弱無狀態性透過將狀態儲存的責任交給少數節點，使大多數節點能夠實現無狀態。強無狀態性完全消除了任何節點儲存完整狀態資料的需求。弱無狀態性和強無狀態性都為一般驗證者提供以下好處： - 幾乎即時的同步 - 能夠不按順序驗證區塊 - 節點能夠在極低的硬體要求下運行（例如，在手機上） - 節點可以在便宜的硬碟上運行，因為不需要磁碟讀取/寫入 - 相容於以太坊密碼學的未來升級 ### 弱無狀態性 {#weak-statelessness} 弱無狀態性確實涉及以太坊節點驗證狀態變更方式的改變，但它並沒有完全消除網路上所有節點對狀態儲存的需求。相反，弱無狀態性將狀態儲存的責任交給區塊提案者，而網路上的所有其他節點在不儲存完整狀態資料的情況下驗證區塊。 **在弱無狀態性中，提案區塊要求存取完整的狀態資料，但驗證區塊不要求任何狀態資料** 為了實現這一點，必須已經在以太坊客戶端中實作了[沃克爾樹](/roadmap/verkle-trees/)。沃克爾樹是一種用於儲存以太坊狀態資料的替代資料結構，它允許將資料的小型、固定大小的「見證」在對等節點之間傳遞，並用於驗證區塊，而不是對照本地資料庫來驗證區塊。還要求[提案者與建構者分離 (PBS)](/roadmap/pbs/)，因為這允許區塊建構者成為擁有更強大硬體的專門節點，而這些節點正是要求存取完整狀態資料的節點。 無狀態性依賴於區塊建構者維護完整狀態資料的副本，以便他們可以產生可用於驗證區塊的見證。其他節點不需要存取狀態資料，驗證區塊所需的所有資訊都可以在見證中找到。這造成了一種情況：提案區塊是昂貴的，但驗證區塊是便宜的，這意味著較少的營運者將運行區塊提案節點。然而，只要盡可能多的參與者能夠獨立驗證他們提案的區塊是有效的，區塊提案者的去中心化就不是至關重要的。 閱讀更多 Dankrad 的筆記 區塊提案者使用狀態資料來建立「見證」——證明區塊中交易正在更改的狀態值的最小資料集。其他驗證者不持有狀態，他們只儲存狀態根（整個狀態的雜湊）。他們接收一個區塊和一個見證，並使用它們來更新他們的狀態根。這使得驗證節點變得極其輕量。 弱無狀態性處於進階研究階段，但它依賴於提案者與建構者分離和沃克爾樹的實作，以便小型見證可以在對等節點之間傳遞。這意味著弱無狀態性距離以太坊主網可能還有幾年的時間。 [用於第一層 (L1) 驗證的 zkEVM](/roadmap/zkevm/) 是一項互補技術，可以進一步增強無狀態驗證。驗證者不僅可以檢查見證，還可以驗證整個區塊正確執行的零知識證明——在不重新執行交易的情況下提供密碼學上的確定性。 ### 強無狀態性 {#strong-statelessness} 強無狀態性消除了任何節點儲存狀態資料的需求。相反，交易與見證一起發送，這些見證可以由區塊生產者聚合。然後，區塊生產者只負責儲存為相關帳戶產生見證所需的狀態。狀態的責任幾乎完全轉移給了使用者，因為他們發送見證和「存取清單」來宣告他們正在與哪些帳戶和儲存金鑰互動。這將實現極其輕量的節點，但存在權衡，包括使與智能合約的交易變得更加困難。 研究人員已經對強無狀態性進行了調查，但目前預計它不會成為以太坊路線圖的一部分——更可能的情況是，弱無狀態性足以滿足以太坊的擴展需求。 ## 目前進展 {#current-progress} 弱無狀態性、歷史記錄過期和狀態過期都處於研究階段，預計將在幾年後發布。無法保證所有這些提案都會被實作，例如，如果首先實作狀態過期，可能就不需要再實作歷史記錄過期。還有其他路線圖項目，例如[沃克爾樹](/roadmap/verkle-trees)和[提案者與建構者分離](/roadmap/pbs)，需要首先完成。 ## 延伸閱讀 {#further-reading} - [什麼是無狀態以太坊？](https://stateless.fyi/) - [Vitalik 無狀態性 AMA](https://www.reddit.com/r/ethereum/comments/o9s15i/impromptu_technical_ama_on_statelessness_and/) - [狀態大小管理理論](https://hackmd.io/@vbuterin/state_size_management) - [最小化復活衝突的狀態邊界](https://ethresear.ch/t/resurrection-conflict-minimized-state-bounding-take-2/8739) - [通往無狀態性和狀態過期的路徑](https://hackmd.io/@vbuterin/state_expiry_paths) - [EIP-4444 規範](https://eips.ethereum.org/EIPS/eip-4444) - [Alex Stokes 談 EIP-4444](https://youtu.be/SfDC_qUZaos) - [為什麼實現無狀態如此重要](https://dankradfeist.de/ethereum/2021/02/14/why-stateless.html) - [最初的無狀態客戶端概念筆記](https://ethresear.ch/t/the-stateless-client-concept/172) - [更多關於狀態過期的資訊](https://hackmd.io/@vbuterin/state_size_management#A-more-moderate-solution-state-expiry) - [更多關於狀態過期的進階資訊](https://hackmd.io/@vbuterin/state_expiry_paths#Option-2-per-epoch-state-expiry) - [無狀態以太坊資訊頁面](https://stateless.fyi)