以太坊輕客戶端Helios：無需信任的鏈上數據訪問

11月8日，一家知名風投機構推出了以太坊輕客戶端Helios。這款基於Rust語言編寫的客戶端，旨在提供完全無需信任的以太坊訪問。

區塊鏈技術的一大優勢在於無需信任第三方。通過區塊鏈，用戶可以自主掌控自己的財富和數據。以太坊等區塊鏈在大多數情況下確實實現了這一承諾：我們的資產真正歸屬於我們自己。

然而，爲了追求便利，我們也做出了一些妥協。其中之一就是使用中心化的RPC（遠程調用）服務器。用戶通常會通過中心化提供商訪問以太坊。這些公司在雲服務器上運行高性能節點，幫助用戶輕鬆獲取鏈上數據。當錢包查詢代幣餘額或檢查待處理交易是否已被打包時，幾乎都會用到這些中心化提供商的服務。

當前系統的問題在於用戶需要信任這些提供商，而無法驗證查詢結果的準確性。

Helios是一款基於Rust的以太坊輕客戶端，能夠提供完全無需信任的以太坊訪問。它利用了以太坊轉向PoS後實現的輕客戶端協議，可以將來自不受信任的中心化RPC提供商的數據轉換爲安全可驗證的本地RPC。結合中心化RPC，Helios無需運行完整節點就能驗證數據的真實性。

難以兼顧便捷性與去中心化是一個普遍存在的痛點。這款新型客戶端（開放給公衆繼續開發）能在約兩秒內完成同步，且無需存儲空間，用戶可通過任何設備（包括手機和瀏覽器插件）安全地訪問鏈上數據。那麼，依賴中心化基礎設施究竟有哪些潛在風險呢？本文將詳細探討這些風險，介紹Helios的設計方案，並提供一些建議，幫助開發者爲代碼庫貢獻力量。

中心化基礎設施的潛在風險：以太坊生態中的理論威脅

在以太坊生態中潛伏着一種理論上的威脅。它不是在交易內存池（Mempool）中尋找目標，而是通過模仿我們依賴的中心化基礎設施來設置陷阱。落入這種陷阱的用戶並沒有做錯什麼：他們只是像往常一樣訪問熟悉的DEX，設置了合理的滑點，並進行代幣交易......他們的操作沒有任何問題，卻可能遭遇一種新型的三明治攻擊，這是一種精心布置在以太坊生態入口處——RPC提供商——的陷阱。

在詳細說明之前，我們先來看看DEX是如何處理交易的。用戶進行代幣兌換時，會向智能合約提供幾個參數：要兌換的代幣、兌換金額，以及最關鍵的，用戶願意接受的最小代幣數量。最後一項參數確定了兌換必須達到的"最小產出"，否則交易將被撤銷。這通常被稱爲"滑點"，因爲它有效地限制了從交易發送至內存池到被打包進區塊期間可能出現的最大價格波動。如果滑點設置過低，用戶可能只能獲得較少的代幣。這種情況也可能導致三明治攻擊，攻擊者可能會將用戶的交易夾在兩個惡意交易之間。這些交易會推高現貨價格，迫使用戶以不利的價格成交。隨後，攻擊者會立即出售代幣，獲取小額利潤。

只要最小產出參數設置在合理範圍內，用戶就不會受到三明治攻擊的影響。但如果RPC提供商沒有提供DEX智能合約的準確報價呢？這種情況下，用戶可能會被誤導，以較低的最小產出參數簽署兌換交易。更糟糕的是，用戶可能會將交易直接發送給惡意的RPC提供商。提供商可以選擇不將這筆交易廣播到公共內存池（那裏有大量機器人在競相進行三明治攻擊），而是私下保留並將被攻擊的交易包直接發送給特定平台，以從中牟利。

這種攻擊的根本原因在於信任他人來幫助獲取區塊鏈狀態。爲了解決這個問題，有經驗的用戶通常會選擇運行自己的以太坊節點。這需要投入大量時間和資源，至少需要一臺持續在線的設備、數百GB的存儲空間，以及大約一天的時間來從頭開始同步。盡管這個過程比以前簡化了許多，一些團隊一直在努力幫助用戶通過低成本硬件（如帶外接硬盤的樹莓派）運行節點。但即便要求大幅降低，對於大多數用戶來說，尤其是使用移動設備的用戶，運行節點仍然是一項艱巨的任務。

需要注意的是，雖然中心化RPC提供商的攻擊完全可能發生，但目前還只是理論上的風險，實際上還未出現過。盡管主流提供商的過往記錄值得信賴，但在將不熟悉的RPC提供商添加到錢包之前，仍然建議進行充分的調研。

Helios簡介：完全無需信任的以太坊訪問

以太坊推出的輕客戶端協議爲快速的區塊鏈交互和通過最低硬件要求驗證RPC端點開闢了令人興奮的可能性。合並後的一個月內，多個相互獨立的輕客戶端相繼出現，它們採用不同的方法，但都爲了實現同一目標：無需信任的高效訪問，且不必使用完整節點。

Helios是一款以太坊輕客戶端，可在大約兩秒內完成同步，不需要存儲空間，並提供完全無需信任的以太坊訪問。與所有以太坊客戶端一樣，Helios由執行層和共識層組成。但與大多數其他客戶端不同，Helios將這兩層緊密結合，用戶只需安裝和運行單個軟件即可。

它的工作原理是這樣的：Helios共識層使用一個已知的信標鏈區塊哈希，並連接一個不受信任的RPC，以可驗證的方式同步到當前區塊。Helios執行層將這些經過驗證的信標鏈區塊與不受信任的執行層RPC結合，以驗證有關鏈上狀態的各種信息，例如帳戶餘額、合約存儲、交易收據和智能合約調用結果。這些組件協同工作，爲用戶提供完全無需信任的RPC，且無需運行完整節點。

共識層

共識層輕客戶端遵循信標鏈輕客戶端規範，並利用了信標鏈的同步委員會（在合並前的Altair硬分叉中引入）。同步委員會是由隨機選擇的512個驗證者組成的子集，服務週期約爲27小時。

驗證者進入同步委員會後會簽署他們看到的所有信標鏈區塊頭。如果超過三分之二的委員會成員簽署了一個區塊頭，那麼該區塊極有可能位於規範信標鏈中。如果Helios了解當前同步委員會的構成，它可以通過向不受信任的RPC查詢最近的同步委員會籤名，以高度確信地追蹤鏈頭。

得益於BLS籤名聚合，只需一次查詢即可完成對新區塊頭的驗證。只要籤名有效且超過三分之二的委員會成員完成籤名，就可以保證區塊已包含在鏈中（當然，它也可能被重組出鏈，而追蹤區塊的最終性可提供更強的保證）。

但這個策略中顯然缺少了一個環節：如何找到當前的同步委員會。首先需要獲取一個稱爲弱主觀性檢查點的信任根。這只是一個可以保證在過去某個時刻被納入鏈中的舊區塊哈希。關於檢查點確切的存在時間，背後有一些有趣的數學計算：最壞情況分析顯示大約有兩周，而更實際的估計表明有數月之久。

如果檢查點太舊，理論上存在可以誘騙節點跟隨錯誤鏈的攻擊。此時，獲取弱主觀性檢查點就超出了協議的能力範圍。Helios的解決方案是提供一個初始檢查點，將其硬編碼到代碼庫中（很容易被覆蓋），它會在本地保存最新的最終區塊哈希，以便在節點同步時用作檢查點。

通過哈希操作，信標鏈區塊可以方便地生成唯一的信標區塊哈希。這樣就可以輕鬆向節點查詢完整的信標區塊，然後通過對其進行哈希操作並與已知的區塊哈希進行比較，來證明區塊內容的有效性。Helios利用這一特性來獲取和驗證弱主觀性檢查點區塊內的某些字段，包括兩個至關重要的字段：當前同步委員會和下一個同步委員會。最關鍵的是，輕客戶端可以利用這種機制快速檢查區塊鏈歷史。

有了弱主觀性檢查點後，我們就可以獲取和驗證當前和下一個同步委員會。如果當前的鏈頭和檢查點都在同一個同步委員會週期內，我們可以立即開始使用已籤名的同步委員會頭來驗證新區塊。如果我們的檢查點落後於幾個同步委員會，那麼我們可以：

1. 使用檢查點之後的下一個同步委員會來獲取和驗證將在未來生成一個同步委員會的區塊。

2. 使用這個新區塊獲取下一個同步委員會。

3. 如果檢查點還在後面，返回步驟1。

通過這個過程，我們能夠以27小時爲單位，快速檢查該區塊鏈的歷史，從過去的任何區塊哈希開始，一直同步到當前的區塊哈希。

執行層

執行層輕客戶端的目標是將經過共識層驗證的信標區塊頭與不受信任的執行層RPC結合使用，提供經過驗證的執行層數據。然後可以通過Helios在本地托管的RPC服務器訪問這些數據。

讓我們以獲取帳戶餘額爲例，簡單介紹一下以太坊如何存儲狀態。每個帳戶包含幾個字段，如合約代碼哈希、隨機數、存儲哈希和餘額。這些帳戶存儲在一個經過修改的大型Merkle-Patricia樹中，稱爲狀態樹。只要知道狀態樹的根，就可以驗證Merkle證明，來證明樹中是否存在任何帳戶。這種證明是無法僞造的。

Helios從共識層獲得了經過驗證的狀態根。通過將這個狀態根和Merkle證明請求應用於不受信任的執行層RPC，Helios可以在本地驗證所有存儲在以太坊上的數據。

我們使用不同的技術來驗證執行層使用的各種數據，通過這種方式，我們可以驗證來自不受信任的RPC的所有數據。不受信任的RPC可以拒絕提供數據訪問，但無法提供錯誤的結果。

在復雜環境中使用Helios

難以兼顧便捷性與去中心化是一個普遍存在的問題。通過輕量級的Helios，用戶可以從任何設備（包括手機和瀏覽器插件）安全地訪問鏈上數據。這將使更多人能夠無需信任地訪問以太坊數據，不受硬件限制。用戶可以在某些錢包中將Helios設置爲RPC提供商，實現無需信任地訪問各種DApp，整個過程無需任何其他更改。

此外，Rust對WebAssembly的支持使應用開發人員可以輕鬆將Helios嵌入JavaScript應用程序（如錢包和DApp）中。這些集成將提升以太坊的安全性，減少我們對中心化基礎設施的依賴。

社區對此的反應令人期待。有多種方式可以爲Helios做出貢獻，除了爲代碼庫添磚加瓦外，還可以構建集成Helios的軟件，以利用其優勢。以下是一些令人興奮的想法：

• 支持直接從P2P網路（而非RPC）獲取輕客戶端數據
• 實現一些尚未支持的RPC方法
• 開發可編譯爲WebAssembly的Helios版本
• 將Helios直接集成到錢包軟件中
• 構建網路儀表板來查看代幣餘額，將Helios嵌入使用WebAssembly的網站中以獲取數據
• 部署引擎API，將Helios共識層連接到現有執行層的全節點上