從實時證明到原生 Rollup:ZK 驅動下的以太坊擴容終局

作者:imToken

編者按:以太坊正在邁向 1 萬 TPS 的擴容新時代,而零知識證明(ZK)技術正成爲關鍵驅動力,本文是我們整理的《以太坊 1萬 TPS 路線圖》第二篇,將聚焦於實時證明的技術難點、Prover 的參與邏輯、L1 切換過程中的安全挑戰,以及「原生 Rollup」如何成爲 ZK 擴容的終極形態。

如果說 ZK 化是以太坊技術重構的起點,那麼「實時證明」與「原生 Rollup」則是這場擴容革命的核心落地環節。

本篇我們將繼續深入探討以太坊主網上如何實現 12 秒級的 ZK 實時證明、成爲 Prover 的硬件門檻與激勵機制是怎樣的、原生 Rollup 將如何改寫以太坊 L2 的格局。

01、實時證明:以太坊擴容的關鍵拼圖

在以太坊邁向 1 萬 TPS 的路線圖上,有一個不可或缺的技術突破點:實時證明(real-time proving)。

Succinct 聯合創始人 Uma Roy 如此解釋:「實時證明,指的是能夠在不到 12 秒內,對以太坊主網的一個區塊完成 ZK 證明的生成過程」。

這意味着什麼?一旦實現實時證明,以太坊就能將其區塊驗證邏輯納入協議本身,並在不犧牲可驗證性的前提下,幾乎「任意」地提高 Gas 上限,從而實現 L1 的大規模擴容(編者注:以太坊主網每個區塊的生成時間爲 12 秒,因此「實時」是指在每個區塊週期內完成證明)。

不過要實現實時證明,僅靠 zkVM 技術本身還不夠,還需要對以太坊協議層進行變更。

以太坊基金會的 Ladislaus 指出,預計將在明年 Glamsterdam 升級中引入一個關鍵機制——「區塊驗證與立即執行的解耦」,這將爲 Prover(證明者)提供更充裕的時間,在一個完整 slot 內生成 zkEVM 證明,從而實現真正意義上的實時處理。

技術實現方面,Succinct 已發布其最新的 SP1 Hypercube zkVM,在 200 張 GPU 的集羣下,能夠對 1 萬個主網區塊中的 93% 實時生成證明。

Roy 表示他們有信心在今年年底前,將這個成功率提升到 99%。盡管一些難以處理的區塊仍可能導致極少數區塊無法及時生成證明,但協議設計中已考慮容錯機制,例如允許跳過該區塊,進入下一個區塊繼續處理。

更進一步,以太坊還在考慮將區塊時間從 12 秒縮短至 6 秒(作爲 Glamsterdam 的另一潛在提案),這將顯著提升用戶體驗和交易確認速度,但這也給 ZK Prover 帶來了額外壓力——對於證明者來說,任務的難度增加了一倍。

不過 Roy 並不擔心,畢竟 ZK 技術每年性能都能提升 10 倍,就算區塊時間減半,也能應對。

6 月 Linea 也宣布其網路上已能實現 100% 的鏈上活動由 ZK 證明覆蓋,雖然 Linea 當前 TPS 僅爲 2,但這並非性能限制,而是受限於使用需求。

值得注意的是,Linea 區塊間隔僅 2 秒,ZK 證明通過智能合約上傳至以太坊 L1 驗證,這一模型,或許正是未來主網「ZK 化」的先行版本。

02、以太坊 ZK 證明者的硬件門檻高麼?

想要實時生成 ZK 證明,當然離不開強大的計算資源。

以太坊基金會目前爲 Prover 設定的初步技術目標是:硬件成本控制在 10 萬美元以內,電力消耗低於 10 千瓦,大約相當於一臺特斯拉 Powerwall 家用電池的耗電水平。

這個數字聽起來並不「輕量」,以太坊批評者 Justin Bons(Cyber Capital 創始人)就稱其爲「遠超 Solana 驗證節點的瘋狂硬件要求」,但這其實是混淆了兩種完全不同的角色。

以太坊基金會協議協調團隊的 Ladislaus 指出:Prover 和 Validator(驗證者)的職責不同,不能混爲一談——驗證者運行節點,參與共識;而 Prover 的任務是生成 ZK 證明,一旦某筆交易的 ZK 證明被正確生成,網路中只需驗證該證明是否正確即可,而不需要重復執行交易。

正因爲此,Ladislaus 表示樂觀,「只要能找到一個滿足硬件條件的誠實證明者,以太坊就能繼續安全運行,我們故意將門檻壓在數據中心以下,甚至即使不是大型機構或數據中心,只要是有技術能力的個人開發者,也能在家中運行 Prover」。

目前這個 10 萬美元的硬件配置只是初始目標,以太坊基金會研究員 Sophia Gold 預計,到今年 11 月 Devconnect 阿根廷開發者大會之前,主流 Prover 有望達標。

Succinct 聯合創始人 Roy 預計到明年初,可以將 GPU 需求降低至 16 張顯卡左右,總成本也將控制在 1 萬至 3 萬美元之間。

與此同時,Succinct 已經在測試網上搭建了一個由「數百個 Prover」組成的去中心化網路,累計生成了數百萬份證明。

這個系統的核心邏輯是競爭式證明,即所有 Prover 參與競標,每輪選擇一個中標者來執行 zk 證明,目標是讓時間更短、成本更低的參與者勝出,形成類算力競價機制。

這意味着,在 ZK 驅動的以太坊未來中,礦工精神將以另一種形式重現——只是角色從算區塊,變成了算證明。

03、主網切爲 ZK 架構:一場高難度系統遷移

將以太坊 L1 主網切換爲零知識證明(ZK)架構,是繼 2022 年從工作量證明(PoW)過渡到權益證明(PoS)之後,又一次幾乎同等級別的技術挑戰,整個過程不僅需要對協議層進行重構,還必須嚴密考慮各種潛在的邊緣場景和安全風險,以防網路運行中斷。

在今年 7 月的一次 EthProofs 會議中,研究員 Justin Drake 就提到了多個可能的風險隱患。例如惡意攻擊者可能會向區塊中插入所謂的「prover killer(證明者殺手)」,從而導致整個網路驗證機制失效;又或者網路活躍度驟降,產生的交易手續費收入不足以支付生成 ZK 證明的成本,從而影響網路可持續性。

以太坊基金會協議協調團隊的 Ladislaus 表示,整個過渡過程可能需要幾年時間,尤其要關注安全方面的隱患。ZK 虛擬機(zkVM)作爲一項仍處於早期階段的復雜技術,極有可能會出現各種漏洞。但隨着生態成熟,我們可以通過引入多樣化的證明系統(proof diversity)、激勵機制的完善、以及形式化驗證等手段,逐步提升其在以太坊 L1 上的可行性與魯棒性。

與此同時,以太坊還計劃對其共識層進行根本性的架構重構,即構建名爲「Beam Chain」的新型結構,目標是在設計之初就爲 ZK 優化友好,Drake 甚至表示,未來整個以太坊的數據驗證工作將可以在一臺普通筆記本電腦的 CPU 上完成。

04、主網「Snark 化」:原生 Rollup 要來了

在以太坊主網集成 zkEVM 的同時,另一個長期設想也開始逐步浮現:原生 Rollup(Native Rollup)。

目前的 Rollup(無論是 Optimistic 還是 ZK 類型)都採用獨立的證明系統,其安全性依賴於自身的驗證者或排序器機制,與以太坊主網之間存在一定的信任假設。

而「原生 Rollup」的願景則是完全不同的——通過將 zkEVM 集成至主網,讓以太坊 L1 驗證者直接驗證 Rollup 的狀態轉換證明,從而實現真正由主網驗證、主網保障安全的 L2。

這需要在以太坊 L1 客戶端中新增一段關鍵代碼「execute precompile」,允許驗證者直接校驗 L2 生成的 ZK 狀態轉移證明,正如以太坊基金會協議協調員 Ladislaus 所說,「L1 驗證者將消費這些 Rollup 的執行證明,並驗證其正確性」。

換句話說,如果原生 Rollup 成真,那麼未來無論是一筆發生在 L1 的交易,還是一筆發生在原生 Rollup 上的交易,其最終結算與安全性都由同一組以太坊驗證者保障,信任級別將完全等同。

這意味着在原生 Rollup 上存入 1000 萬美元,其安全性將等同於直接存入以太坊主網。

Linea 項目負責人 Declan Fox 表示,他們的長期目標就是成爲一個原生 Rollup,他認爲這是 ETH 2.0 分片方案的「升級版」——不再是硬性運行 64 個結構相同的分片鏈,而是以高度可編程、可定制的方式構建異構 Rollup 系統,服務不同場景與用戶需求。

與過去 ETH 2.0 的同構分片架構不同,原生 Rollup 可以是異構的,爲最終用戶提供更多樣化和差異化的應用體驗。

盡管原生 Rollup 尚未正式寫入以太坊路線圖,但隨着 zkEVM 正式啓動、L1 架構逐步重構,爲其預設接口與預編譯邏輯,顯然已經成爲可預見的技術趨勢。

Ladislaus 總結道,「在將 EVM Snark 化(即集成 ZK 證明能力)與推進原生 Rollup 上,以太坊存在高度的技術協同,因爲這兩者共享底層 ZK 技術堆棧」,當然這一進程仍需通過以太坊社區治理,形成 EIP(以太坊改進提案),並最終在一次硬分叉中落地部署。

樂觀預期的話,如果一切順利,也許年底就能提交相關 EIP,並在 Glamsterdam 升級後的分叉中上線。

不過這一時間表仍具有高度不確定性,需謹慎看待。

ZK5.52%
ETH7.42%
查看原文
此頁面可能包含第三方內容,僅供參考(非陳述或保證),不應被視為 Gate 認可其觀點表述,也不得被視為財務或專業建議。詳見聲明
  • 讚賞
  • 留言
  • 轉發
  • 分享
留言
0/400
暫無留言
交易,隨時隨地
qrCode
掃碼下載 Gate APP
社群列表
繁體中文
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)