原創主題配圖: 鏈觀 BTC866 原創主題圖解 · ChainView BTC866 Editorial · CC BY 4.0
兩種客戶端分別驗證什麼
在以太坊權益證明架構中，執行客戶端處理交易、執行智能合約並驗證狀態轉換，共識客戶端負責共識消息、鏈選擇與最終性相關邏輯。驗證者簽名功能又有自己的密鑰和運行要求，不能把所有進程統稱為一個節點後忽略依賴。畫出交易進入、執行結果、共識選擇和對外查詢的數據流，能夠判斷問題位於哪層。執行層看似持續運行，並不代表共識層已經同步；錢包能查詢舊餘額，也不說明節點提供的是最新規範鏈狀態。
引擎接口與信任邊界
兩層通過引擎接口交換執行負載與鏈頭信息，接口需要按官方文檔配置認證和網絡訪問。認證令牌用於組件間身份驗證，並不意味著接口適合公開到互聯網；仍應限制監聽地址、端口和訪問來源。普通 JSON RPC、共識 API 與引擎 API 的用途和權限不同，反向代理也要分開處理。檢查日誌時保留錯誤碼與請求時間，但不要將認證秘密放進公開工單；僅憑接口返回成功無法證明整個網絡健康。
兼容矩陣與同步檢查
升級前核對執行與共識客戶端的兼容版本、網絡參數、數據庫遷移和已知問題，不能只更新其中一個包就宣稱升級完成。監控執行高度、共識槽位、對等連接、最終性延遲與資源佔用，並與獨立來源比較。系統時間錯誤、磁盤不足或防火牆配置都可能造成表面像協議問題的異常。若運行驗證者，還要檢查職責執行與防重復簽名措施；恢復備份時複製同一密鑰到兩台同時在線設備可能引入懲罰風險。
用分層證據定位故障
假設查詢交易的 RPC 正常，但最終性長期不前，應分別檢查共識同步、客戶端連接和網絡整體狀態，而不是不斷重發交易。記錄兩層版本、配置摘要、最近高度與時間，先保護日誌和密鑰，再按支持文檔採取措施。不要把數據庫降級或重建當成默認第一步，這些操作會延長恢復並可能丟失證據。維護記錄應說明哪項檢查恢復正常、哪項仍未知，讓後來接手者能夠復現判斷，而不只看到已重啓的結論。
