致謝:感謝來自 EF 的 Piper Merriam、Polychain 的 Karthik Raju、EthStorage 的 Qiang 對本文提供的反饋。
2023 年 10 月 22 日,著名的 Go-Ethereum(Geth)開發負責人 Péter Szilágyi 在 Twitter 上表達了他的深切擔憂。他指出,雖然 Geth 客戶端保留了所有歷史數據,但 Nethermind 和 Besu 等其他以太坊客戶端可以配置刪除某些歷史以太坊數據(例如歷史區塊和塊頭)。這使得所有客戶端的行爲不一致,並對 Geth 不公平。這引發了圍繞以太坊路線圖中以太坊存儲問題的激烈討論和辯論。
爲什麼 Nethermind 和 Besu 選擇停止存儲歷史數據? 這一決定背後的問題是什麼? 從我們的角度來看,有兩個主要原因:
第一個原因源於運行以太坊客戶端不斷上升的存儲需求。 爲了深入了解具體需求,下面的餅圖展示了截至 2023 年 12 月 13 日第 18,779,761 塊時一個新 Geth 節點的存儲分布情況。
如圖所示:
第二個原因是缺乏存儲歷史區塊的協議內激勵或懲罰。 雖然該協議要求節點存儲所有歷史數據,但卻未能提供任何機制來鼓勵存儲或懲罰違規的行爲。 節點存儲和共享歷史數據變得純粹出於利他主義,客戶端運行者可以自由地刪除或修改所有歷史數據,而不會受到任何懲罰。 相比之下,Validator 節點必須在本地維護並更新完整的狀態,以防止因提議 / 投票支持無效區塊而導致的 Slash。
因此,當存儲成本成爲節點的重大負擔時,一些節點運營商選擇刪除歷史數據就不足爲奇。 在沒有歷史數據的情況下,節點客戶端可以顯著降低存儲成本,將其從大約 1TB 減少到 300GB 左右。
圖示:Nethermined 配置運行沒有歷史區塊的節點 — 目前可節省約 460GB 的存儲成本
隨着即將到來的以太坊數據可用性(DA)升級,存儲挑戰將會加劇。 全面擴容以太坊 DA 的道路始於 DenCun 升級中的 EIP-4844,它引入了一個固定大小的二進制大對象 (BLOB) ,和一個被稱爲 blobGasPrice 的獨立費用模型。 每個 BLOB 設置爲 128KB,EIP-4844 允許每個區塊最多包含 6 個 BLOB。 爲了對數據吞吐量進行擴容,以太坊計劃採用 1D Reed-Solomon 代碼,最初允許每個區塊有 32 個 BLOB,並在完全擴容時達到每個區塊 256 個 BLOB。
如果以太坊 DA 以全容量運行(每個塊 256 個 BLOB),以太坊 DA 網路預計一年將接收大約 80 TB 的 DA 數據,該數字遠遠超出大多數節點的存儲能力。
Vitalik 發布的以太坊路線圖推文,提到了 Purge 主要涉及存儲方面的內容
不斷上升的存儲成本引起了以太坊生態研究人員的關注。 爲了解決這個問題並確保所有客戶端的一致性,研究人員正在制定一些提案來明確刪除歷史的存儲。 兩個主要提案是:
刪除所有客戶端的歷史數據會產生什麼後果? 主要的一個問題是新節點無法通過「full sync」模式來同步到最新狀態,「full sync」是一種將交易從創世區塊執行到最新區塊的同步。 相應地,我們必須採取「snap sync」或「state sync」來直接同步來自以太坊節點的最新狀態。 這種方法已在 Geth 中實現,並作爲默認同步運行。
同樣地,這個後果也適用於所有 L2,即 L2 的新節點無法通過重放 L2 創世到最新的 L2 區塊,來完全同步以太坊 L2 創世的最新狀態。 此外,由於 L1 節點不維護 L2 狀態,L2 的「snap sync」方法無法從 L1 中派生出最新的 L2 狀態,這違反了繼承以太坊安全保證的重要 L2 假設。 預計的解決方案將依賴 Infura / Etherscan / L2 項目本身等第三方服務來存儲歷史 L2 數據或狀態副本。這是通過協議外、間接激勵實現的中心化的解決方案。
我們要探討的核心問題是:
以太坊 Portal 網路是一個輕量級、去中心化的訪問網路,用於連接到以太坊協議。它提供例如 eth_call,eth_getBlockByNumber 等以太坊 JSON-RPC 接口,它將 JSON-RPC 請求轉換爲對分布式哈希表(DHT) 的 P2P 請求,類似於 FIL 網路。 與允許存儲任何數據類型且容易受到垃圾數據影響的 FIL 不同,Portal P2P 網路專門托管以太坊數據,如歷史區塊頭和區塊交易數據。 這是通過 Portal 網路內置的輕客戶端驗證技術來實現的。
Portal 網路的一個重要特性是其輕量級運行設計以及與資源受限設備的兼容性。 它可以運行在具有幾兆存儲空間和低內存的節點之上,從而促進去中心化。 即使是手機或 Raspberry Pi 設備也有可能加入網路並有爲以太坊數據的可用性做出貢獻。
Portal 網路的開發與以太坊客戶端多樣性理念相一致,客戶端採用 Rust、JavaScript 和 Nim 編寫。 信標網路和歷史網路已可供使用,而狀態網路正在積極開發中。 值得注意的是,Portal 網路並不爲數據存儲提供直接激勵 — — 網路中的所有節點都是利他的方式運行的。
圖示:具有 100MB 存儲限制的 Portal 網路 Rust 客戶端 (Trin) 在運行中
EthStorage 網路是一個去中心化的激勵存儲網路,專門用於存儲 EIP-4844 BLOB,並獲得 ESP 項目的資助。
從模塊化區塊鏈的角度來看,EthStorage 充當以太坊存儲 L2,但它收取的是存儲費而不是交易費。 通過在鏈上索引 BLOB 哈希,EthStorage 是一個以太坊模塊化存儲層,提升存儲可擴展性及降低成本(目標約爲 1000 倍)。
在開發方面,EthStorage 已經與以太坊 Sepolia 測試網上的 EIP-4844 集成。我們已對 EthStorage 和以太坊 Sepolia 測試網進行壓力測試,包括將大約數百 GB 的 BLOB 寫入 EthStorage。 超過 100 名社區參與者加入網路並成功證明了他們的本地存儲。
EthStorage 網路的主要優勢在於在以太坊之上提供去中心化的直接激勵 — — 就我們目前的知識而言,這是一項開創性的功能。 然而,該網路的局限性在於它是專門爲固定大小的 BLOB 而設計的。
EthStorage 上以太坊 Sepolia 測試網的看板
盡管以太坊存儲還未受到主要關注,但其在以太坊生態系統中具有重要意義。 隨着以太坊網路的快速增長,以太坊數據的存儲和可訪問性成爲關鍵挑戰。 Portal 網路和 EthStorage 網路還處於早期階段,還有很多重要的長期的發展方向需要關注:
在我們的追求中,我們希望通過這些努力,共同爲以太坊路線圖做出貢獻,爲未來以太坊生態系統的去中心化存儲解決方案奠定基礎。
本文轉載自[tech flow深潮)],原文標題“以太坊存儲路線圖:挑戰與機遇 ”,著作權歸屬原作者[EthStorage],如對轉載有異議,請聯系Gate Learn團隊,團隊會根據相關流程盡速處理。
免責聲明:本文所表達的觀點和意見僅代表作者個人觀點,不構成任何投資建議。
文章其他語言版本由Gate Learn團隊翻譯, 在未提及Gate.io的情況下不得復制、傳播或抄襲經翻譯文章。
致謝:感謝來自 EF 的 Piper Merriam、Polychain 的 Karthik Raju、EthStorage 的 Qiang 對本文提供的反饋。
2023 年 10 月 22 日,著名的 Go-Ethereum(Geth)開發負責人 Péter Szilágyi 在 Twitter 上表達了他的深切擔憂。他指出,雖然 Geth 客戶端保留了所有歷史數據,但 Nethermind 和 Besu 等其他以太坊客戶端可以配置刪除某些歷史以太坊數據(例如歷史區塊和塊頭)。這使得所有客戶端的行爲不一致,並對 Geth 不公平。這引發了圍繞以太坊路線圖中以太坊存儲問題的激烈討論和辯論。
爲什麼 Nethermind 和 Besu 選擇停止存儲歷史數據? 這一決定背後的問題是什麼? 從我們的角度來看,有兩個主要原因:
第一個原因源於運行以太坊客戶端不斷上升的存儲需求。 爲了深入了解具體需求,下面的餅圖展示了截至 2023 年 12 月 13 日第 18,779,761 塊時一個新 Geth 節點的存儲分布情況。
如圖所示:
第二個原因是缺乏存儲歷史區塊的協議內激勵或懲罰。 雖然該協議要求節點存儲所有歷史數據,但卻未能提供任何機制來鼓勵存儲或懲罰違規的行爲。 節點存儲和共享歷史數據變得純粹出於利他主義,客戶端運行者可以自由地刪除或修改所有歷史數據,而不會受到任何懲罰。 相比之下,Validator 節點必須在本地維護並更新完整的狀態,以防止因提議 / 投票支持無效區塊而導致的 Slash。
因此,當存儲成本成爲節點的重大負擔時,一些節點運營商選擇刪除歷史數據就不足爲奇。 在沒有歷史數據的情況下,節點客戶端可以顯著降低存儲成本,將其從大約 1TB 減少到 300GB 左右。
圖示:Nethermined 配置運行沒有歷史區塊的節點 — 目前可節省約 460GB 的存儲成本
隨着即將到來的以太坊數據可用性(DA)升級,存儲挑戰將會加劇。 全面擴容以太坊 DA 的道路始於 DenCun 升級中的 EIP-4844,它引入了一個固定大小的二進制大對象 (BLOB) ,和一個被稱爲 blobGasPrice 的獨立費用模型。 每個 BLOB 設置爲 128KB,EIP-4844 允許每個區塊最多包含 6 個 BLOB。 爲了對數據吞吐量進行擴容,以太坊計劃採用 1D Reed-Solomon 代碼,最初允許每個區塊有 32 個 BLOB,並在完全擴容時達到每個區塊 256 個 BLOB。
如果以太坊 DA 以全容量運行(每個塊 256 個 BLOB),以太坊 DA 網路預計一年將接收大約 80 TB 的 DA 數據,該數字遠遠超出大多數節點的存儲能力。
Vitalik 發布的以太坊路線圖推文,提到了 Purge 主要涉及存儲方面的內容
不斷上升的存儲成本引起了以太坊生態研究人員的關注。 爲了解決這個問題並確保所有客戶端的一致性,研究人員正在制定一些提案來明確刪除歷史的存儲。 兩個主要提案是:
刪除所有客戶端的歷史數據會產生什麼後果? 主要的一個問題是新節點無法通過「full sync」模式來同步到最新狀態,「full sync」是一種將交易從創世區塊執行到最新區塊的同步。 相應地,我們必須採取「snap sync」或「state sync」來直接同步來自以太坊節點的最新狀態。 這種方法已在 Geth 中實現,並作爲默認同步運行。
同樣地,這個後果也適用於所有 L2,即 L2 的新節點無法通過重放 L2 創世到最新的 L2 區塊,來完全同步以太坊 L2 創世的最新狀態。 此外,由於 L1 節點不維護 L2 狀態,L2 的「snap sync」方法無法從 L1 中派生出最新的 L2 狀態,這違反了繼承以太坊安全保證的重要 L2 假設。 預計的解決方案將依賴 Infura / Etherscan / L2 項目本身等第三方服務來存儲歷史 L2 數據或狀態副本。這是通過協議外、間接激勵實現的中心化的解決方案。
我們要探討的核心問題是:
以太坊 Portal 網路是一個輕量級、去中心化的訪問網路,用於連接到以太坊協議。它提供例如 eth_call,eth_getBlockByNumber 等以太坊 JSON-RPC 接口,它將 JSON-RPC 請求轉換爲對分布式哈希表(DHT) 的 P2P 請求,類似於 FIL 網路。 與允許存儲任何數據類型且容易受到垃圾數據影響的 FIL 不同,Portal P2P 網路專門托管以太坊數據,如歷史區塊頭和區塊交易數據。 這是通過 Portal 網路內置的輕客戶端驗證技術來實現的。
Portal 網路的一個重要特性是其輕量級運行設計以及與資源受限設備的兼容性。 它可以運行在具有幾兆存儲空間和低內存的節點之上,從而促進去中心化。 即使是手機或 Raspberry Pi 設備也有可能加入網路並有爲以太坊數據的可用性做出貢獻。
Portal 網路的開發與以太坊客戶端多樣性理念相一致,客戶端採用 Rust、JavaScript 和 Nim 編寫。 信標網路和歷史網路已可供使用,而狀態網路正在積極開發中。 值得注意的是,Portal 網路並不爲數據存儲提供直接激勵 — — 網路中的所有節點都是利他的方式運行的。
圖示:具有 100MB 存儲限制的 Portal 網路 Rust 客戶端 (Trin) 在運行中
EthStorage 網路是一個去中心化的激勵存儲網路,專門用於存儲 EIP-4844 BLOB,並獲得 ESP 項目的資助。
從模塊化區塊鏈的角度來看,EthStorage 充當以太坊存儲 L2,但它收取的是存儲費而不是交易費。 通過在鏈上索引 BLOB 哈希,EthStorage 是一個以太坊模塊化存儲層,提升存儲可擴展性及降低成本(目標約爲 1000 倍)。
在開發方面,EthStorage 已經與以太坊 Sepolia 測試網上的 EIP-4844 集成。我們已對 EthStorage 和以太坊 Sepolia 測試網進行壓力測試,包括將大約數百 GB 的 BLOB 寫入 EthStorage。 超過 100 名社區參與者加入網路並成功證明了他們的本地存儲。
EthStorage 網路的主要優勢在於在以太坊之上提供去中心化的直接激勵 — — 就我們目前的知識而言,這是一項開創性的功能。 然而,該網路的局限性在於它是專門爲固定大小的 BLOB 而設計的。
EthStorage 上以太坊 Sepolia 測試網的看板
盡管以太坊存儲還未受到主要關注,但其在以太坊生態系統中具有重要意義。 隨着以太坊網路的快速增長,以太坊數據的存儲和可訪問性成爲關鍵挑戰。 Portal 網路和 EthStorage 網路還處於早期階段,還有很多重要的長期的發展方向需要關注:
在我們的追求中,我們希望通過這些努力,共同爲以太坊路線圖做出貢獻,爲未來以太坊生態系統的去中心化存儲解決方案奠定基礎。
本文轉載自[tech flow深潮)],原文標題“以太坊存儲路線圖:挑戰與機遇 ”,著作權歸屬原作者[EthStorage],如對轉載有異議,請聯系Gate Learn團隊,團隊會根據相關流程盡速處理。
免責聲明:本文所表達的觀點和意見僅代表作者個人觀點,不構成任何投資建議。
文章其他語言版本由Gate Learn團隊翻譯, 在未提及Gate.io的情況下不得復制、傳播或抄襲經翻譯文章。