🤖 最新推出：《Quicknode 人工智慧實戰手冊》 10 個經過實測的 AI 程式設計食譜agents 。
查看食譜 已通過 SOC 2 Type II 認證 · ISO 27001
// Tags
全節點與存檔節點ethereum 存檔節點
簡而言之：全節點會儲存區塊鏈的當前狀態，並驗證所有新交易與區塊，但會刪除較舊的歷史資料以節省儲存空間。存檔節點除了具備全節點的所有功能外，還會保留從創世區塊開始至今的完整歷史狀態。您需要哪種節點類型，取決於您的應用程式是僅需當前資料，還是需要存取任何時間點的歷史狀態。
簡單的解釋
每個區塊鏈節點都會下載並驗證區塊鏈，但並非每個節點都會儲存相同份量的資料。不妨將其比喻為圖書館與檔案館的差異。全節點就像是圖書館：它擁有目前流通的所有書籍，並能告訴你書架上現有的內容；而存檔節點則如同國家檔案館：它收藏了自創立以來所有曾出版過的書籍、每個版本，以及所有已絕版的文稿。
在Ethereum 上，全節點會儲存所有帳戶、餘額及智慧合約的當前狀態，並保留足夠近期的區塊歷史紀錄，以驗證區塊鏈的完整性。預設情況下，大多數Ethereum 客戶端會將最近 128 個區塊的狀態資料保持在可立即存取的狀態，這大致涵蓋了過去 25 至 30 分鐘的網路活動。 任何比這更舊的資料都會被修剪以節省磁碟空間。從技術上來說，全節點仍可透過重播自創世區塊開始的交易來重建較舊的狀態，但該過程極為緩慢且計算成本極高。
存檔節點完全跳過修剪過程。它會儲存自區塊鏈創建以來，每個區塊的完整區塊鏈狀態快照。這意味著您可以查詢區塊鏈歷史中任何時間點的任何錢包餘額、任何智慧合約的儲存內容，或任何交易的輸出，並立即獲得回應。 無需重播。其代價在於儲存空間。運行 Geth 的完整Ethereum 節點需要約 1TB 的 SSD 空間。運行 Geth 的存檔節點則需要超過 12TB，且這個數字每天都在增長。Erigon 是一款儲存效率更高的客戶端，可將存檔需求降低至約 2TB，但仍遠高於經過修剪的完整節點。
全節點與存檔節點之間有什麼區別？
屬性 | 完整節點 | 存檔節點 |
|---|
歷史狀態 | 在約 128 個區塊後進行刪除 | 源自《創世記》 |
儲存（Ethereum 、Geth） | 約 1TB | 超過 12TB（其中約 2TB 位於 Erigon 上） |
歷史狀態查詢 | 回傳「缺失的 trie 節點」錯誤 | 在任何區塊高度皆可即時完成 |
同步時間 | 數小時至數天 | 數天至數週 |
最適合 | 錢包、去中心化應用程式（dapps）、支付、即時讀取 | 探索工具、分析、稽核、追蹤 |
何時需要全節點
全節點是任何區塊鏈網路的支柱。它們會驗證每個新區塊、執行共識規則、拒絕無效交易，並為不儲存完整區塊鏈的輕量級客戶端提供信任錨點。無論您是開發錢包、僅需當前餘額與近期交易資料的去中心化應用程式（dapp），還是向網路提交交易的服务，全節點都已足夠。
大多數生產環境的應用都屬於此類。去中心化交易所需要掌握當前的代幣餘額，並即時執行兌換操作；支付處理器需要驗證傳入的交易是否有效且已確認；錢包則需要顯示當前餘額並廣播新的交易。這些用例均無需查詢特定帳戶在 500,000 個區塊前的餘額。當前狀態已足夠，而全節點在提供此資訊時，其硬體需求遠低於存檔節點。
全節點在網路健康狀況方面也扮演著關鍵角色。區塊鏈上運行的獨立全節點越多，網路就越去中心化且越具韌性。每個全節點都會獨立驗證區塊鏈，因此沒有任何單一節點或節點群組能夠單方面篡改紀錄。運行全節點是參與並支持區塊鏈安全模型的最直接方式。
何時需要存檔節點
當您的應用程式依賴歷史區塊鏈資料時，存檔節點便變得至關重要。如果您正在建置一個區塊瀏覽器，讓使用者能夠查詢區塊鏈歷史中任何時間點的交易或帳戶狀態，您就需要存檔存取權限。如果您正在執行分析，以追蹤代幣持有量、智慧合約狀態或 DeFi 協議指標隨時間的變化，您同樣需要存檔存取權限。 若您正使用 Hardhat 或 Foundry 等開發工具對mainnet 進行分叉，以模擬過去的狀態進行測試，您也需要存取存檔資料。
某些特定的技術情境也需要存檔節點。若要在歷史區塊號（在大多數客戶端中，即早於最近 128 個區塊的任何區塊）呼叫 eth_getBalance 或 eth_call，便需要存檔資料；若要透過追蹤執行過程來除錯數週前失敗的交易，同樣需要存檔資料。 為了審計清算事件而需重建特定區塊處的借貸協議狀態時，同樣需要存檔資料。若無存檔節點，這些查詢將因資料已被修剪而返回「缺少 trie 節點」錯誤。
存檔節點的受眾範圍雖較窄，卻至關重要：包括區塊鏈分析平台、數位鑑識調查人員、協議審計員、如 The Graph 般的索引服務，以及任何需要解答關於過去（而不僅是現在）問題的應用程式。
為什麼在完整節點上查詢歷史資料會失敗？
全節點會修剪大約最後 128 個區塊之前狀態，因此若在更早的區塊上呼叫 eth_getBalance 或 eth_call，將會傳回「缺失 trie 節點」錯誤。交易記錄仍然存在，但當時的狀態已因節省空間而被刪除。 若要恢復這些資料，需要使用存檔節點或儲存的資料集，這正是存取歷史區塊鏈資料的核心概念。這種修剪機制也是為什麼在大規模查詢區塊鏈資料時，通常需要多於一個全節點的原因。
每種節點類型需要多少儲存空間？
儲存是最大的實際差異，且取決於區塊鏈鏈與客戶端。下表列出了Ethereum 的典型數據。這些數字持續增長，這正是許多團隊選擇透過提供者查詢歷史狀態的原因之一，相關內容已於「即時與歷史區塊鏈數據」一文中詳述。
設定 | 大致的儲存空間 | 註釋 |
|---|
完整節點（Geth） | 約 1TB | 西普倫斯州（舊稱） |
存檔節點 (Geth) | 超過 12TB | 儲存每個狀態快照 |
存檔節點（Erigon） | 約 2TB | 儲存效率更高的客戶端 |
儲存與成本的現實狀況
自行運作一個存檔節點是一項嚴肅的承諾。除了單是「Ethereum 」就需 12TB 以上的儲存空間外，您還需要高性能的 SSD（而非 HDD）才能達到可接受的查詢速度；此外，從頭開始同步一個存檔節點可能需要數週時間，具體取決於您的硬體配置和網路連線狀況。若您的節點在初始同步過程中出現同步失效或當機，您可能需要從頭開始。將此情況乘以您的應用程式所支援的每條區塊鏈，基礎設施的負擔便會迅速增加。
這就是為什麼大多數開發者和團隊都依賴基礎設施供應商，而非自行運行存檔節點。Quicknode 的所有方案均包含存檔資料存取功能，這意味著您無需管理底層儲存或同步流程，即可查詢任何受支援區塊鏈上的歷史狀態。 無論您需要過去 10 分鐘的資料，還是追溯至創世區塊的完整歷史紀錄，Quicknode 的Core API皆可透過相同的 RPC 介面endpoint 進行處理。對於需要專用且隔離式基礎架構的團隊，Quicknode 的 DedicatedClusters服務可提供私有存檔節點存取權限，並附帶保證正常運作時間的 SLA 以及可預測的效能。
一個endpoint 能否同時提供完整資料與存檔資料？
是的。許多服務提供者會透過單一網址，將當前狀態的請求轉發至全節點，而將歷史狀態的請求轉發至存檔節點，因此您無需管理兩套配置。從應用程式端來看，只需一個RPCendpoint即可同時處理近期與歷史的查詢。
延伸閱讀
常見問題
存檔節點與完整節點是一樣的嗎？
不。存檔節點不僅能執行全節點的所有功能，還會保留自創世區塊以來的每份歷史狀態快照。全節點會修剪舊的狀態以節省磁碟空間，因此無法回應任意的歷史狀態查詢。
我的去中心化應用程式（dapp）需要一個存檔節點嗎？
大多數去中心化應用程式（dapps）、錢包和支付應用程式只需當前狀態，因此運行全節點就已足夠。您主要需要存取存檔資料，是用於區塊瀏覽器、分析、稽核、mainnet 分叉，以及追蹤歷史交易。
為什麼在舊區塊上執行 eth_getBalance 會失敗？
由於全節點已對該區塊的狀態進行了修剪，因此此呼叫會傳回「缺失 trie 節點」錯誤。查詢保留所有狀態快照的存檔節點，即可解決此問題。
Ethereum 存檔節點的儲存容量是多少？
在 Geth 上約需 12TB 或更多空間，相較之下，全節點約需 1TB。儲存效率較高的 Erigon 客戶端可將存檔儲存空間減少至約 2TB，而這些數值都會隨時間推移而增加。
存檔節點與索引建立之間有何關聯？
索引器通常會從存檔節點或回填資料集讀取歷史資料，以建立可供查詢的資料庫。關於該層級的運作方式，請參閱「何謂區塊鏈索引」。
