來源：a16z crypto Research｜原始發表日期：2026 年 5 月 9 日
證明一台電腦真的跑過
不必重做每一步證明一台電腦
真的跑過
不必重做每一步
Twist 與 Shout 是兩種互動式證明協議。Justin Thaler 的研究講座想處理的不是「算得對不對」而已，而是如何讓外部驗證者用較少成本確認大量運算與記憶體讀寫真的依規則發生。
SCROLL ↓
來源：a16z crypto Research｜原始發表日期：2026 年 5 月 9 日
Twist 與 Shout 是兩種互動式證明協議。Justin Thaler 的研究講座想處理的不是「算得對不對」而已，而是如何讓外部驗證者用較少成本確認大量運算與記憶體讀寫真的依規則發生。
SCROLL ↓
PART 1｜驗證不是重算
可驗證運算要解決的場景很直接：一個 prover 執行很大的程式，另一個 verifier 想確認結果正確，但不想付出同樣的運算成本。SNARK 是常見工具，能把「我知道一個符合條件的計算過程」壓縮成短證明。
問題在於，許多通用做法會把程式翻成算術電路。這套路徑很強，但對某些工作負載代價很高，尤其是同一個函數要被大量評估、或程式要反覆讀寫記憶體時。Thaler 的講座從這個工程痛點開始，而不是宣稱所有運算都該用同一種證明系統。
PART 2｜Shout｜重複工作可共享前置成本
Shout 針對的是 batch evaluation：同一個函數在大量不同輸入上重複求值。講座中的關鍵想法是，若計算有重複結構，prover 可以先支付一次較小的前置成本，再把每次評估的邊際成本降下來。
這不等於 verifier 放棄檢查，而是雙方改變協議的分工。prover 仍得受到可檢查的約束，verifier 則取得足以確認批次關係的訊號。研究者關心的指標因此不只是一個總時間，而是初始化、證明大小、驗證時間與不同批次規模下的成本曲線。
它不是略過驗證，而是把重複工作改寫成可共享的證明協議。
PART 3｜Twist｜真正麻煩的是記憶體
一般程式不只做純函數計算，還會讀、寫、覆寫記憶體。對 verifier 而言，不能只檢查每個 CPU cycle 看起來合理，還要確認每一次 read 都對應到正確的歷史 write。這使可驗證記憶體成為 zkVM 的難題之一。
Twist 延伸 Shout 的方向來處理 read/write memory。講座把它描述為能支援更有效率的可驗證 CPU 執行：證明者不必完全依賴傳統電路編碼，也不必用遞迴 SNARK 當作唯一組合方式。這是協議與實作仍在演進的研究主張，不是所有虛擬機都已採用的現成結論。
核心不是把記憶體搬進證明，而是讓時間順序與讀寫關係可被檢查。
PART 4｜zkVM 的取捨
Thaler 在問答裡反覆比較不同路徑：直接用電路、使用預編譯、遞迴、以及讓 prover 在 VM 抽象之外做更多工作。每條路都會移動成本與信任邊界。某個方案讓特定操作更快，也可能要求更複雜的編譯、硬體、記憶體模型或安全假設。
因此，zkVM 的比較不能只看一個 benchmark。要問的是執行什麼程式、證明者的記憶體是否受限、驗證者需要多快得到答案、系統是否允許特殊操作，以及每個優化是否仍讓外部人理解自己驗證了什麼。
PART 5｜研究離產品還有一段工程
講座提到工程團隊與實習生正在實作 Twist 與 Shout。這正好標出研究與部署的界線：協議分析可以顯示一條有前景的成本路徑，實作則要回答編譯器、資料布局、硬體、失敗處理與真實工作負載。
對使用者來說，最實用的問題不是「它是否神奇」，而是「它替哪一種重複工作省下什麼成本，又新增了什麼條件」。可驗證運算的價值來自可檢查性；若優化讓系統更快，仍應能清楚說出驗證者到底檢查了哪些主張。
可驗證運算的目標不是讓人相信一個結果，而是讓人不用重做全部工作，也能檢查它。
Twist 與 Shout 的切入點，是把重複計算與記憶體關係變成更省成本的可檢查協議。
選擇你的檢查起點
Justin Thaler 以 SNARK、批次評估、記憶體檢查與 zkVM 為主線說明 Twist 與 Shout。來源：a16z crypto，2026 年 5 月 9 日。
閱讀完整文章 →