以太坊輕客戶端Helios：實現無需信任的區塊鏈訪問

11月8日，一款新的以太坊輕客戶端Helios正式推出。該客戶端基於Rust語言開發,旨在提供完全無需信任的以太坊訪問。

使用區塊鏈的主要目的之一是實現無需信任。通過區塊鏈,我們可以自主掌控自己的財富和數據。多數情況下,以太坊等區塊鏈確實兌現了這一承諾:我們的資產真正屬於我們自己。

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

當前系統的問題在於用戶需要信任這些提供商,無法驗證查詢結果是否正確。

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

該客戶端能在約兩秒內完成同步,且無需存儲,用戶可通過任何設備(包括手機和瀏覽器插件)安全訪問鏈上數據。但依賴中心化基礎設施到底有哪些潛在風險?接下來將分析這些風險,介紹Helios的設計方案,並提供一些思路幫助完善代碼庫。

中心化基礎設施的潛在風險

一種理論上的攻擊方式潛伏在以太坊"黑暗森林"中。它不是在交易內存池中尋找目標,而是通過模仿我們依賴的中心化基礎設施來設置陷阱。用戶即便沒有犯錯也可能落入陷阱:他們只是像往常一樣在DEX上交易,設定了合理的滑點......但仍可能遭遇一種新型三明治攻擊,這是一種精心設置在RPC提供商處的陷阱。

去中心化交易所處理交易時,用戶需要向智能合約提供幾個參數:要兌換的代幣、兌換金額,以及最重要的,用戶願意接受的最小代幣數量。最後一項參數指明了兌換必須達到的"最小產出",否則交易會被撤銷。這通常被稱爲"滑點",它有效設定了從發送交易到交易上鏈之間可能出現的最大價差。如果滑點設置過低,用戶可能只能獲得較少代幣,還可能遭受三明治攻擊。

只要最小產出參數設置在合理範圍內,就不會受到三明治攻擊。但如果RPC提供商沒有提供DEX智能合約的準確報價呢?這可能導致用戶被誤導,以較低的最小產出參數簽署兌換交易。更糟的是,用戶還可能將交易直接發送給惡意的RPC提供商。提供商可以不將交易廣播至公共內存池,而是私下扣留並將被攻擊的交易包直接發送給特定機構以牟利。

造成這種攻擊的根本原因是信任他人來獲取區塊鏈狀態。爲解決該問題,有經驗的用戶通常會運行自己的以太坊節點,但這需要耗費大量時間和資源,至少需要一臺持續在線的設備、數百GB存儲空間,以及大約一天時間從頭開始同步。雖然現在運行節點的門檻已經降低,但對於多數用戶來說仍然很困難,尤其是使用移動設備的用戶。

需要注意的是,中心化RPC提供商攻擊雖然完全可能發生,但通常只是簡單的釣魚攻擊,我們描述的那種攻擊尚未發生。盡管主流提供商的過往記錄值得信賴,但在使用不熟悉的RPC提供商之前,多做一些研究仍然是明智之選。

Helios:實現無需信任的以太坊訪問

以太坊推出輕客戶端協議,爲快速的區塊鏈交互和通過最低硬件需求驗證RPC端點開闢了新的可能性。The Merge後的一個月裏,多個獨立的輕客戶端相繼推出,它們採用不同方法,但目標一致:在不運行完整節點的情況下實現高效的無需信任訪問。

Helios是一個以太坊輕客戶端,可在約兩秒內完成同步,無需存儲,並提供完全無需信任的以太坊訪問。與所有以太坊客戶端一樣,Helios包含執行層和共識層。但與多數客戶端不同,Helios將兩層緊密耦合,用戶只需安裝和運行單個軟件即可。

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

共識層

共識層輕客戶端遵循信標鏈輕客戶端規範,利用了信標鏈的同步委員會。同步委員會是隨機選擇的512個驗證者構成的子集,服務週期約27小時。

驗證者進入同步委員會後會簽署所有看到的信標鏈區塊頭。如果超過2/3的委員會成員簽署了一個區塊頭,則該區塊極可能位於規範信標鏈中。如果Helios了解當前同步委員會的組成,它可以通過查詢最近的同步委員會籤名來可靠地追蹤鏈頭。

得益於BLS籤名聚合,只需一次查詢即可完成對新區塊頭的驗證。只要籤名有效且超過2/3的委員會成員完成籤名,即可保證區塊已包含在鏈中。當然,追蹤區塊的最終性可提供更強的保證。

這個策略中還需要解決如何找到當前同步委員會的問題。首先要獲取一個稱爲弱主觀性檢查點的信任根。它表示一個可以保證在過去某個時刻被納入鏈中的舊區塊哈希。關於檢查點的存在時間,理論分析顯示最壞情況約爲兩周,而實際估計可能長達數月。

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

通過哈希操作,信標鏈區塊可方便地產生唯一的信標區塊哈希。這樣可以輕鬆查詢完整的信標區塊,然後通過哈希比對來證明區塊內容的有效性。Helios利用此屬性來獲取和驗證弱主觀性檢查點區塊內的關鍵字段,包括當前同步委員會和下個同步委員會。最關鍵的是,輕客戶端可利用該機制快速檢閱區塊鏈歷史。

有了弱主觀性檢查點後,我們就可以獲取和驗證當前及下個同步委員會。如果當前的鏈頭和檢查點都在同一個同步委員會週期內,我們可以立即使用已籤名的同步委員會header來驗證新區塊。如果檢查點排在若幹同步委員會之後,則可以:

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

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

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

通過上述流程,我們能以27小時爲單位,快速檢閱該區塊鏈的歷史,從過去的任一區塊哈希開始,一直同步至當前的區塊哈希。

執行層

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

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

Helios從共識層獲得經過驗證的狀態根。通過對不受信任的執行層RPC應用這一狀態根和Merkle證明請求,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共識層連接至現有執行層的全節點