Gavin Wood 演講：JAM 交付情況，以及將 ZK 引入 JAM 的中長期策略！

Bitget App

交易「智」變

Bitget

資訊中心

PolkaWorld2025/11/12 08:47

顯示原文

作者:PolkaWorld

本文為 Gavin Wood 上個月在 Web3 Summit 中的演講中文版！由於該系列內容較多，我們將分為四部分發布，本文為第一部分，主要內容包括：

JAM 的交付情況
ZK 性能雖然進步了，但還遠遠不夠商業化
33 次複算 vs 數學鐵證：兩種安全模式的真實代價
一個 ZK-JAM 節點要花多少錢？答案比你想的貴 10 倍！
ZK 在 JAM 中的短期、中期、長期演進路徑

一起來看看 Gavin 到底分享了什麼精彩觀點吧！

那麼，事不宜遲，我在這次演講中要講些什麼呢？

首先，我想分享一下我對 Polkadot 的整體看法，也就是我目前所處的思考位置，可以理解為一份「現狀快照」。大家可能已經聽說過 JAM ——這是我長期研究的一個項目，與 Polkadot 有著緊密聯繫。我們希望它最終能夠支撐 Polkadot 的下一發展階段。除此之外，我還會聊一些零知識加密技術（ZK），特別是它們在擴展區塊鏈功能方面的應用。

另外，我還會探討 DOT 的代幣經濟模型。接下來，我會介紹我近期在研究的一些新內容，這些探索旨在改進現有能力，甚至為 Polkadot 和更廣泛的 Web3 世界帶來全新的可能性。這部分內容涉及多個方面，有的會比較詳細，有的則會點到為止。好，我們現在正式開始。

目前 JAM 的交付情況

JAM 最初的版本是 0.1，目前正逐步接近 1.0。當它達到 1.0 時，就意味著 JAM 協議已經準備好供 Polkadot 升級使用。隨著協議逐步穩定，我們的重點逐漸轉向優化，尤其是 gas 建模。今年早些時候，我還在布拉格的以太坊大會（East Prague）上專門做過一次相關演講。Gas 建模本身是一個非常有趣、但同時也極其複雜的議題。

JAM 預計今年將啟動協議審計。在 0.7 版本系列中需要完成的工作不多；但在 0.8 版本中，會正式引入 gas 建模，工作量會明顯增加。我預計我們能在今年推進到 0.9 版本，並在那時正式開始審計。

當然，擁有一個核心協議是一回事，能在其上進行開發又是另一回事。你需要 SDK、文件等開發工具。這部分目前還處於早期階段。雖然現在已經能夠在 JAM 上開發軟體，但在 Parity，主要還是由我在推動 SDK 的構建和發布。然而，從現實情況來看，這仍需要未來數月乃至數年的持續投入和打磨。當然，SDK 的開發不會侷限於 Parity。我也預期會有更多團隊加入進來，構建屬於他們自己的 JAM SDK。

我們已經開始制定跨服務消息傳遞的標準，它可以被視作 JAM 版本的 XCM/XCMP。與此同時，CoreVM 在逐漸成為 SDK 的一部分，並將在未來幾個月不斷完善和增強。CoreVM 目前已經支援許多功能，例如音訊輸出、視訊輸出、資料輸入 / 輸出、交易處理、以及即將來臨的內部服務。目前它還不支援 EVM，但這是我們計劃新增的功能。另外，我過去稱之為核心協同調度（coreplay）的機制，也計劃在未來 12–24 個月內實現。

最近在 JAM 的聊天群裡，有人提出了一個很有意思的問題：如何避免讓我本人成為 JAM 的單點風險（single point of failure）？目前 JAM 協議的演進完全依賴於我寫在灰皮書（Gray Paper）裡的內容。這意味著，如果我出現意外，整個項目可能陷入停滯。顯然，這對 JAM 和我本人都不是好事。

因此，我們將灰皮書的內容視為 JAM 的技術規範。最新的灰皮書就是最新的 JAM。如果某個版本的灰皮書已經過審計，那它所定義的 JAM 協議就意味著具備了生產級的成熟度，這一點很直接。

那麼，未來如果灰皮書的更新不再完全由我決定，它將如何演進呢？

我的設想是成立一個編輯委員會。初始成員將由那些真正參與過灰皮書撰寫、對其理解深入並做出實質性貢獻的人組成。我期望這些成員能在 JAM 的實現中保持高水平的技術參與。我本人不會完全退出，仍會擔任主編，但我希望能減少自己的工作量，並賦予他人提出、審查和合併修改的權力。

隨著 JAM 超越 1.0 版本，這個編輯委員會將承擔更高層次的責任：

不僅是處理一些小改動，而是決定 JAM 的發展方向與優先級；
在不同意見出現時，委員會的集體判斷應當成為最有分量的聲音。

我計劃任命一位副手，在我不在場、休假或其他情況時接手工作。長遠來看，副手們還將負責選擇、邀請和決定新的編輯委員會成員，以確保整個機制能夠自我運轉。最終，我希望這一治理體系能夠逐步獨立，甚至吸納一些外部組織的參與，例如 Polkadot Fellowship。

我確實計劃將灰皮書置於一種開放許可協議之下，具體採用哪一種還未最終決定，但很有可能會選擇 copyleft 協議，並加入一些防止專利濫用的條款。

至於 Polkadot 的治理，它完全有權決定自己運行哪一種協議。Polkadot 是一個主權協議，而治理機制正是這種主權的體現。目前，Polkadot 治理已經基本明確表態：它希望採用 JAM。這很好。與此同時，其他網路同樣可以選擇使用 JAM，因為 JAM 是一個開放協議。

未來如果 JAM 持續演進，Polkadot 可以選擇保持同步，繼續跟隨最新版本；如果它對 JAM 的發展方向不滿意，也完全可以固定在某個版本，甚至修改核心協議或直接分叉灰皮書。這說明 JAM 本身是一個獨立存在的體系，而我個人也希望它能與 Polkadot 長期保持互利共生的關係。當然，如果有一天它們各自分道揚鑣，獨立發展，也是完全可行的。

只要雙方保持一致，我預期 Polkadot 治理會積極參與並支持灰皮書編輯委員會的運作。而如果未來有其他協議採用 JAM，我同樣希望它們能以類似的方式參與其中。

好了，這就是 JAM 目前的進展，或者說它即將達到的階段。接下來，我想談談零知識證明（ZK）。

ZK 性能雖然進步了，但還遠遠不夠商業化

很多人都會問我這個問題：ZK（零知識證明）到底什麼時候能真正商用？

以太坊對 ZK 非常熱衷，他們的路線圖幾乎全都圍繞 ZK 展開。而在 JAM 裡，其實我們只是在區塊構建的某些特殊共識機制中用到了一點 ZK，整體並不依賴它。但即便如此，這仍然是一個必須認真思考的問題：

ZK 什麼時候能成為一種真正能用來擴展計算能力、並且在商業上可行的技術？
它現在到了嗎？
如果還沒到，還需要多久？

如果你去看以太坊生態裡的資料（比如 ethprovers.com），會看到一些很驚人的數字，聲稱 ZK 已經在經濟上可行了。但我們調查過，發現這些數字並不真實。好消息是，雖然還沒完全可行，但和 18 個月前相比，差距已經大大縮小。

舉個例子：目前 JAM 的虛擬機 PVM（相當於 JAM 版的 EVM）在運行程式碼時比原生執行要慢，大概 34% 的差距。換句話說，如果原生環境跑一個程式需要 34 分鐘，那麼在 PVM 上跑需要大約 100 分鐘。

這個成績其實已經相當不錯了，我們對結果很滿意，而且還有提升空間。

當然，在一些情況下差距會更大，比如 50% 或以上。尤其是在 SHA-1 雜湊這種任務裡，PVM 的執行就比較慢。這可能是因為原生環境下編譯器能用 SIMD 指令集或者其他優化手段，而 PVM 暫時做不到。

接下來我們看另一個關鍵數字：這是在用目前我們能找到的最好的證明器 Succinct SP1 時，生成執行證明的成本 —— 也就是相比直接在 PVM 上運行，多出來的額外開銷。注意，這裡對比的對象是 PVM，而不是原生環境。PVM 本身已經比原生慢了大約 34%。

目前的測試結果是這樣的：我們使用了最新版本的軟體，並且假設只用一塊 GPU（因為公開的程式碼庫只能支援單 GPU）。如果是閉源的商業版本，可能能擴展到 GPU 集群，但在開源環境下，就只能這樣。測試的內容和之前一樣，依舊是 SHA-1 雜湊，保證對比一致。

那麼變化在哪裡呢？

在 18 個月前，我們做過類似實驗，當時的數據大得多，大概在 6000 萬到 6400 萬的量級。現在的成本明顯降了很多。

原因大概有兩個：

一方面，GPU 租賃價格變便宜了；
另一方面，軟體本身有了巨大的優化，可能提升了一個數量級甚至更多。

需要補充的是，18 個月前我們用的證明器不是 SP1，而是 RISC-0。但無論如何，結果都說明一點：前沿技術正在快速進步，而且進步的幅度相當可觀。

截至 2025 年 7 月，用 SP1（Succinct 的證明器）去生成一段執行軌跡（execution trace）的證明，比直接在 PVM 裡安全執行同樣的計算，要貴 306,451 倍。在過去的 18 個月裡，證明成本已經降低了大約 200 倍，但這個數值依然很大。ZK 技術確實在快速進步，但依然遠遠比直接執行要昂貴。

接下來我們來說 Gas 計量。

程式碼跑得快是一回事，但關鍵是你要能信任它。如果有人故意寫了一段「拖慢速度」的程式碼怎麼辦？在共識機制裡，如果系統必須在規定時間內達成一致，而這段程式碼卻被惡意設計成慢吞吞的，那整個系統就可能被卡住甚至癱瘓。

在 Polkadot 上，這個問題沒那麼突出，因為我們有平行鏈插槽拍賣。也就是說，能往系統裡提交程式碼的人身份基本是清楚的，他們花了真金白銀買到插槽，所以大概率不會幹損人不利己的破壞行為。

但如果我們把場景放大到一個更開放、更通用的環境，那問題就嚴重了。

解決辦法是什麼呢？

就是要能提前大致估算一段程式碼的執行時間上限——也就是最壞情況下會跑多久。然後確保無論如何，它的運行時間絕不會比這個最壞情況更慢。否則，如果有人能把程式碼搞得比我們預估的還慢 10 倍，那就是大麻煩。

那麼我們的最壞情況估算現在做到什麼程度？

以 SHA-1 雜湊為例，目前的結果是：為了保證安全，我們得假設它可能會比正常情況慢 4.5 倍。也就是說，假如一段程式碼正常只需要 1 秒，我們在最壞情況估算裡要把它當成 4.5 秒。這樣才能確保再惡意的攻擊者也沒法把它拖得更慢。

這種「多算幾倍保險」的方法，正是我們在有時間約束的共識機制下保證安全所必須的。

未來，這個倍數應該還能下降，也就是估算會變得更精準、更高效。現在 4.5 倍是我們花了一兩週努力後得到的最好結果。樂觀來看，也許未來能降到 3 倍左右，但不會再低很多了。

33 次複算 vs 數學鐵證：兩種安全模式的真實代價

在 Polkadot 和 JAM 裡，我們用了一種叫 elves 的協議來保證計算的安全。它的作用就是讓我們能夠確定：某一段計算，確實是被正確執行了。

從本質上看，elves 和零知識證明（ZK）有點像：

ZK 用的是數學證明，直接給你一個「鐵證」；
而 elves 更像是一個加密經濟學的遊戲：參與者用簽名和一些規則來證明結果是對的，前提是假設「壞人不超過三分之一」。

在運行 elves 的時候，計算會被重複執行。參與者會隨機決定自己是否去做這次「複算」。

結果是：在這個模式下，工作平均會被重做大約 33 次。所以它的成本差不多是正常執行的 33 倍。

這樣一來，我們就能算出 ZK 和 elves 的成本差距。答案是：ZK 比 elves 大約貴 4000 倍。換句話說，用零知識證明來驗證正確性，成本要比用 elves 這個加密經濟學系統貴得多。你可以把它想像成是不同 Rollup 方案的成本對比。

PolkaWorld 註：可以想像 elves 就像班級裡有 33 個同學都抄一遍作業，最後對答案，確認沒有問題； ZK 則像請一個數學博士給你寫一份「絕對不會錯的證明」，但是博士寫這份證明可能要幾天。

4000 倍這個差距非常大，要想讓 ZK 在實際應用中變得划算，它的成本必須大幅下降。當然，我們也還可以繼續優化 elves，讓它變得更高效。

不過，成本問題不僅僅是硬體。還有幾個關鍵點：

運維成本（sysadmin）：無論你跑什麼硬體，運維人員的工資差不多一樣。而且在很多情況下，運維成本甚至比硬體更貴。
質押成本：為了保證壞人不超過三分之一，系統需要一個過濾機制。在 Polkadot 裡，這就是通過「質押 + 懲罰機制」來實現的。也就是說，參與者必須抵押一部分資金（風險資本），這樣才能把大概率的「好驗證人」和可能的「壞驗證人」區分開。

問題是：質押本身也很貴，這又是一筆額外的成本（我稍後會展開講）。

相比之下，ZK 本身沒有質押的負擔。ZK 的邏輯很簡單：要麼證明正確，要麼錯誤，一眼就能看出來。

但問題是，ZK 生成證明太慢了。如果用單塊 GPU 來跑，可能需要幾個小時；而在 PVM（或者普通 CPU）上直接執行同樣的計算，只需要幾毫秒到幾秒鐘。差距非常明顯。

不過，已經有人展示過，可以通過 GPU 集群並行化來縮短延遲。如果有足夠多的 GPU 互相連接，就能把延遲降下來。但問題在於：

並行化的效率係數不透明：也就是說，成本會增加多少，目前並不清楚。做過實驗的人沒有公開這部分數據，他們可能也不想公開。所以我們要麼自己偷偷設計實驗去測量，要麼自己開發程式碼實現，或者看看有沒有未被發現的相關研究。

除此之外，還有驗證和結算的問題。

比如在以太坊 L1 上進行驗證，目前的成本甚至比生成證明還貴。我們估算過，生成一個證明大約花 1 美元到 1.20 美元，但在以太坊 L1 上驗證卻要 1.25 美元。當然，如果有自己的鏈，驗證成本可能會便宜很多，但你依然需要：

驗證（verification）
結算（settlement）
最終性（finality）
儲存（storage）

這些環節 ZK 並不能消除。所以最終，你依然需要確保惡意參與者不超過三分之一，也就是說還是要回到質押機制，就像以太坊 L1、Polkadot 以及大多數鏈一樣。

一個 ZK-JAM 節點要花多少錢？答案比你想的貴 10 倍！

好，現在我們換個角度思考：假設有一個 ZK-JAM 的擔保節點（guarantor node），它的運行成本大概是多少？

先簡單解釋一下：在 JAM 裡，有一類角色叫擔保人（guarantors），他們就像系統的「門衛」。所有交易或任務先交給他們處理，他們會先做運算、把結果打包，再交給其他驗證人。驗證人可能會複查他們的結果，但也可能不查。

現在我們假設一個場景：

去掉複查環節（不再要求別人重複檢查擔保人的工作）；
降低質押要求（因為不需要完全依賴擔保人的信用）；
但強制擔保人運行 GPU 集群，用 ZK 生成證明。

那麼，這樣做的成本是多少呢？

根據估算：生成一個 ZK 證明的成本大約是 1.18 美元（以 SHA-1 為例，相當於 6 秒的計算量、12MB 的 I/O）。這大概等於一個 JAM core 在一個 slot 內能完成的工作。JAM 總共有 341 個 core，而這是單個 core 的成本。

當然，這只是一個粗略估算。不同的任務成本會有所浮動：如果是別的計算，可能比 1.18 美元貴，也可能便宜，但大概就是這個量級。

如果我們把它年化來看：一個 core 一年的成本大約 950 萬美元。

這裡假設 GPU 集群的並行化會帶來 50% 的額外開銷，主要是為了降低延遲。不過，這個 50% 只是一個猜測，現實中可能只有 5%，也可能高達 200%。可以確定的是——肯定會有額外開銷，而且可能不小。

那麼，這跟 Polkadot 目前的質押機制相比呢？

在現行機制下，如果要提供相當於 elves（或大約 80% 的 elves 安全性）安全性的保障，每個 core 的成本大約不到 100 萬美元。

這裡說的 80% 是因為：即使換用 ZK，你還是需要一定的質押，來保證其他關鍵部分的安全，比如：

主鏈正常運行
結算
最終性
儲存

這些都很重要，但計算正確性才是最核心的，而它大約佔質押成本的 80%。

假設我們運行 341 個 core，並保持當前 Polkadot 的質押經濟模型，成本就是這樣。如果 core 數量減少，單個 core 的成本反而會上升，因為質押的「總盤子」不變，但要分攤的人變少了。

所以總結一下：目前 ZK 的成本大概是 elves 的 10 倍左右。

當然，如果我們能把安全成本降下來（我認為這是有可能的），比如從 916 萬美元降到 270 萬，甚至結合我們正在研發的新機制，進一步降到 144 萬。那時，ZK 和 elves 的成本差距就會縮小。但要注意，144 萬已經是一個相對樂觀的估計值。

那麼，最終的結論是什麼呢？

ZK 的成本確實在逐漸降低，但即使如此，它現在仍然比 elves 貴大約 10 到 100 倍。而且，還有一些額外的不確定成本，比如結算、儲存和最終性——這些 JAM 已經內建支援，或者 elves 可以順帶利用，而 ZK 並不能。

另外，elves 有一個優勢：它能超線性擴展。意思是說，可以把多個 JAM 網路連接起來，讓它們共享同一套驗證人（validator set），這樣整體效率會更高。而 ZK 沒這個能力，它只能線性增長——如果要為另一個 core 生成證明，就必須重新花一次同樣的成本，無法合併或複用。

ZK 在 JAM 中的短期、中期、長期演進路徑

所以，從戰略角度來說，該走哪條路，還要看具體情況。

我認為一個合理的策略是：

降低證明成本：至少還要再下降 1–2 個數量級才行。按以往的經驗，這可能需要 18 個月到 5 年。
需要有開源工具：能在 GPU 集群上高效分布式生成證明。目前並沒有成熟的工具，或者說還不是最快最好的。如果沒有這樣的工具，我們現在的成本估算也站不住腳。
Core 的價格問題：如果 core 的市場價格已經落在一個讓 elves 模式合理的區間，那麼 ZK 的優勢就不復存在。
安全性選擇：市場需要能區分兩種安全性：ZK 提供的是「完美安全」，而 elves 提供的是「在經濟約束下的安全」。問題是，市場是否真的在乎用哪一種，還不確定。
去掉高額質押依賴：我們必須能在不依賴大規模質押的情況下，完成 JAM / elves 所負責的其他任務，比如儲存、結算、最終性。如果還得像現在一樣依靠大量質押，那就沒有任何優勢，只會讓 ZK 方案更貴。

基於這些，我建議的 ZK 戰略是：

先從容易嘗試的方向入手：比如開發一個 ZK-JAM 服務框架，但依舊利用現有 JAM 的加密經濟學機制（elves）來提供安全性。
利用 JAM 的優勢：一個 JAM core 擁有很強的計算能力（CPU）和不錯的 I/O（12MB），而且 PVM 的執行效率也很高。這意味著我們完全可以在 JAM core 裡直接做大量 ZK 驗證，不必走外部那種昂貴又複雜的證明流程。
優化證明環節：傳統的 ZK 證明過程通常分好幾個階段，最後還有一步「證明壓縮」，讓證明變小、方便驗證。但在 JAM core 內，因為算力足夠強，可能根本不需要這一步，能省下成本。
優先攻克儲存證明：因為 JAM core 的計算能力很強，但 I/O 相對不足，而儲存證明正好能彌補這個弱點，讓系統可以快速處理大量交易。
其他簡單的任務：比如簽名驗證，本來就很容易完成，不是瓶頸。

換句話說，真正的難點在於保證交易所依賴的數據是正確的。這才是我們要重點解決的問題。