跳到正文
Financial Context Wiki

全節點

以驗證為核心介紹全節點、以太坊執行與共識用戶端、同步檢查點、目前與歷史狀態、修剪、RPC 隱私、最終確定性及營運容量規劃。

更新於

僅供教育參考，不構成投資或資安建議。全節點仍仰賴正確的軟體、鏈與檢查點設定、運作正常的對等節點、即時升級、本機安全、儲存空間及網路可用性。

直接答案

全節點下載所屬協定需要的資料，依本機共識與執行規則驗證區塊和狀態轉換，跟隨這些規則選定的鏈，並能在不將判斷外包給 RPC 供應商的情況下拒絕無效的對等節點資料。「全」描述的是驗證責任，不代表永久保存每個歷史狀態、參與出塊或質押、對外提供 API，也不表示不受軟體與設定錯誤影響。

在權益證明以太坊上，可用的全節點由執行用戶端與共識用戶端搭配運作。執行用戶端驗證交易與執行承載內容、維護目前執行狀態並提供 JSON-RPC；共識用戶端驗證共識物件、套用分叉選擇，並追蹤論證與最終確定。驗證者用戶端是選用元件，只有質押驗證者需要提議和證明區塊時才使用。

運作機制

  1. 確定驗證目標與網路快照：協定、鏈與創世識別、分叉時程、預期 chainId、目前及已最終確定的區塊雜湊、用戶端版本、同步模式、檢查點來源、修剪模式、RPC 方法、歷史狀態範圍和所需可用性。全節點的具體要求因鏈而異。
  2. 安裝從獨立管道取得且驗證過的用戶端版本，並配對協定所需元件。在目前的以太坊上，透過經驗證的本機 Engine API 連接一個執行用戶端與一個共識用戶端；只有質押時才加入驗證者。資料目錄、P2P 連接埠、RPC 暴露面以及簽署者或驗證者金鑰應分開管理。
  3. 從預定的信任錨啟動。創世完整同步從創世區塊開始向前驗證；執行層 snap sync 從較新的已驗證狀態建構並修復狀態，共識層檢查點同步則從弱主觀性檢查點開始，之後驗證後續區塊。信任資料庫前，應透過獨立管道交叉核對創世資訊、檢查點根、鏈 ID、分叉摘要與已最終確定的鏈頭。
  4. 同時監控兩條流程。確認執行與共識對等節點、鏈頭和最終確定落後幅度、Engine API 健康狀態、狀態根一致性、時鐘同步、磁碟成長、輸入／輸出、記憶體、CPU、資料庫錯誤及分叉準備情況。「已同步」必須表示所需用戶端對目標鏈達成一致，並持續匯入有效資料。
  5. 讓保留政策符合查詢需求。經修剪的全節點保留目前狀態及驗證所需的區塊、收據與快照資料，但可能要重建舊狀態，或拒絕舊狀態查詢；封存設定則具體保存歷史狀態，以便快速進行時點查詢。狀態修剪、區塊與收據歷史、共識資料庫、blob 可用期間及鏈下索引是彼此獨立且取決於用戶端與設定的範圍。輕量用戶端驗證較窄的承諾路徑並請求其他資料，並非只是較小的全節點。
  6. 僅開放必要的 RPC 介面。將管理 API 與 Engine API 綁定於本機、驗證用戶端身分、設定主機防火牆並限制應用程式 RPC 速率；沒有管控時，不要公開 debug、trace、帳戶或交易池方法。針對目標節點測試 latest、safe 與 finalized 標籤、歷史呼叫、日誌及交易提交；僅容錯移轉到經獨立核驗的端點。
  7. 對帳並演練復原。與第二種用戶端或獨立節點比較區塊雜湊、狀態根與最終確定檢查點；演練正常關機、快照與還原、資料庫重建、用戶端升級、分叉啟用、磁碟更換、對等節點中斷及 RPC 容錯移轉。保留日誌與設定，同時將節點驗證過的輸出和前端、預言機、跨鏈橋及應用程式的主張分開。

計算範例

  • 頻寬模型。 假設某鏈每 12 seconds 產生一個區塊，下載的平均區塊本體加所需旁帶資料為 150 kB。節點每天處理 86,400 / 12 = 7,200 blocks/day，按十進位單位下載 7,200 * 150 kB = 1,080,000 kB = 1.08 GB/day，尚未計入 P2P 額外負荷、重試、共識流量、快照或上傳。這些是規劃假設，不是即時以太坊常數。
  • 磁碟餘裕。 某修剪節點初始占用 1.20 TB，實測資料庫每月成長 18 GB/month。經過 30 months，模型用量為 1,200 + 18 * 30 = 1,740 GB。在預測值之上預留 25%，所需容量為 1,740 * 1.25 = 2,175 GB，即十進位 2.175 TB。用戶端變更、修剪與分叉都可能使線性模型失效。
  • 營運可用性。 在 30 days = 720 hours 內，執行用戶端維護耗時 2 hours，共識用戶端故障耗時 3 hours，另有一次不重疊的共同停電耗時 1 hour。停機共 6 hours，觀測可用性為 (720 - 6) / 720 = 99.1666666667%。程序仍可能在運作時過時、遭網路分割或位於錯誤鏈上，因此僅看程序上線時間並不充分。
  • 歷史狀態重建。 某修剪用戶端在區塊 18,000,000 有可用快照，需要查詢區塊 18,250,000 的狀態，因此必須重播 250,000 blocks。若實測速度為 500 blocks/second，理想計算時間為 250,000 / 500 = 500 seconds = 8.3333333333 minutes，未計狀態讀取、收據、重組處理與快取未命中。封存節點以更多儲存空間換取更快的歷史狀態直接存取。

風險

  • 連到錯誤的鏈、創世設定、分叉時程或 chainId。
  • 信任惡意、過時或未充分交叉核驗的同步檢查點。
  • 在網路升級期間執行過時用戶端。
  • 共識與執行用戶端意見不一致或失去 Engine API 連線。
  • 用戶端實作缺陷導致接受、拒絕或提供錯誤資料。
  • 用戶端單一化使節點與網路暴露於相關性故障。
  • 對等節點過少、遭日蝕攻擊、帶有惡意或缺乏多樣性。
  • 時鐘偏移破壞共識職責、時間戳記或對等節點行為。
  • 磁碟耗盡、儲存過慢、檔案系統故障或資料庫損毀。
  • 將程序上線時間誤當成已同步、位於規範鏈且已最終確定。
  • 在重組期間混淆鏈頭、安全與最終確定狀態。
  • 誤以為修剪全節點能立即回答每個歷史狀態查詢。
  • 誤以為封存節點會保存所有鏈下索引、追蹤資料或應用程式標籤。
  • 暴露未經驗證的 Engine、admin、debug、trace 或交易池 API。
  • RPC 日誌洩漏錢包位址、查詢、中繼資料或交易意圖。
  • RPC 過載、無界查詢或阻斷服務排擠區塊驗證資源。
  • 備份或快照還原產生過時或內部不一致的資料。
  • 驗證者或簽署金鑰因與節點服務部署不當而遺失。
  • 將本機驗證的鏈上資料當成前端、預言機或跨鏈橋誠實的證明。
  • 將以太坊的雙用戶端、修剪或弱主觀性模型套用到其他鏈。

常見迷思

  • 每個全節點都是永久保存所有歷史狀態的封存節點。
  • 執行全節點會自動使營運者成為驗證者或出塊者。
  • 節點顯示「已同步」，就必定位於預期的規範鏈與最終確定鏈上。
  • 自行代管 RPC 可以消除所有信任、隱私、軟體與營運風險。
  • 僅憑更多磁碟、對等節點或上線時間，就能證明驗證正確和網路安全。

相關主題

來源

導覽

搜尋知識庫...