撰文：Taiko
編譯：Frank，Foresight News
不久前，我們分享了一篇題為《為什麼 multi-prover 很重要》的詳細文章，解釋了多重證明（Multi-Proofs）的重要性，並將 SGX 作為多重證明的選擇之一。
這篇文章的靈感來自於我們與 Vitalik 的 X Space 和他隨後發表的博客文章，其中介紹了 Taiko 關於多重證明的總體路線圖：它與以太坊終局的關係，我們的願景是什麼，以及我們將如何實現。
我們認為，ZK 中的 multi-proof 可以轉化為使用 multi-SNARKs + multi-Client，即使用多種 ZK-SNARK 證明多種不同的以太坊節點，這將為未來以太坊 L1 中的 SNARKed 節點多樣性奠定基礎。
為了為多重證明提供一個非常簡單的理由，我們應該提到兩點：
- 多重證明可以對沖節點實施和證明系統中的漏洞和風險，因此在出現漏洞的情況下，即使一個證明被破壞，其他證明也不太可能允許完全相同的漏洞被利用；
- 以太坊的終局，是假設使用零知識證明（ZL）來驗證 L1；
與以太坊的多節點實現類似，這種方法已經多次拯救了網路免於崩潰，證明了 L1 區塊需要採用多重驗證的方法。對於 ZK 和非 ZK 場景來說，這意味著需要使用多個節點和不同的證明系統。
Multi-Client 系統和 L1 終局
正如 Vitalik 在他的文章《What might an「enshrined ZK-EVM」look like?》中描述的那樣，Multi-Client 系統有兩種方法：「開放式」和「封閉式」。
- 在一個封閉式的 Multi-Client 系統中，協定內已知一組固定的證明，並將其列入「白名單」以生成證明。而根據 Vitalik 的分類，所有 ZK L2 都是封閉式的，因為它們只接受自己實現的證明；
- 在一個開放式的 Multi-Client 系統中，證明被放置在「區塊之外」，並由各個節點分別進行驗證，任一用戶都可以使用任何他們想要的節點來驗證區塊；
如果使用者需要驗證某區塊，在最簡單的實現即直接運行相應的節點重新執行該區塊，或者向已知的 Prover 請求有效性證明。如果收到了一定數量符合「白名單」標準的證明，則認為該區塊合法。然而，如果沒有符合「白名單」標準的零知識證明（ZKP），並且我們想避免重新執行，我們應該使用哪種零知識證明呢？
根據 Vitalik 的願景，這是在協議之外透過進行社會（或加密經濟）共識來解決這個問題：
在共識層上，我們添加了一個驗證規則：只有當節點對區塊中每個狀態變化都看到了有效的證明時，才接受該區塊。該證明必須是一個 ZK-SNARK 證明，用於證明 transaction_and_witness_blobs 的連接是 (Block, Witness) 對的序列化，並且基於 pre_state_root 和 Witness（i）執行區塊是有效的，並且（ii）輸出正確的 post_state_root。潛在地，節點可以選擇等待多種類型的 M-of-N 證明。
想像一下，一個誠實的 Builder 擁有一種 type-1 的區塊，他希望提供有效性；L2 層已經提供了幾個選擇，例如 Polygon、ZkSync 和 Scroll。
假設他們的 ZK-EVMs 已經發展到了 type-1，並且信譽良好且經過實戰檢驗，然後 Builder 將從這些可用的證明系統中進行選擇，而驗證他的區塊的人將運行相應的驗證軟體，最好是創建多種類型的證明，並透過多次驗證。鑒於相同的 L1 鏈規範，如果有任何一個驗證者不同意，區塊驗證就成為了一個共識問題，開放式的系統將透過共識來達成驗證結果的一致性。
證明系統將透過說服使用者信任它們而獲得影響力，而不是透過說服協議治理過程。
根據 Vitalik 的說法，這意味著 ZKP 生態系統正在開放，以實現直接市場化。如果有激勵措施，現有的 L2 實現可能會參與 L1 證明市場的競爭。
Taiko 在多重證明方面的可行性
在 Taiko 協議中，Proposer 必須找到一個 Prover 來提出一個區塊，並且被指定的 Prover，將存入 TKO 作為保證金，以確保自己交付的證明沒有問題。Taiko 協議並沒有規定 Proposer 如何找到和補償 Prover，所以他們甚至可以親自見面，並用現金進行交易。
因此我們的供應鏈運作就像一個自由市場一樣，Proposer 可以選擇任何他們喜歡的 Prover。
除了經濟優勢之外，還有一些技術特性使得 Taiko 成為 Multi-Client 系統的理想選擇：
- Taiko 是一種 type-1 的 ZK-EVM ，具有兩個好處：首先，在執行多樣性方面，現有的 EVM 實現（如 Geth、Besu、Reth 等）可以直接應用於 L2；其次，為了測試基於 L1 設計的可行性，我們需要一個標準化的 ZK-EVM 來進行開放式 Multi-Client 驗證，因為驗證者需要根據相同的轉換來達成共識並驗證結果。在這種情況下，type-1 ZK-EVM 將是最合適的選擇，因為它明確遵循以太坊規範。對於 Rollup 特定邏輯方面，Vitalik 也提到了如何透過預編譯支援修改 ZK-EVM，並且利用這些預編譯就足以支援 Taiko 的 BBR（Based Booster Rollup）設計；
- Taiko 將資料可用性發佈在以太坊上，而不像一些 L2 探索替代的資料可用性選項。只要資料被發佈到 L1，Taiko 可以輕鬆適應 Vitalik 的實施提案，該提案介紹了 ZKEVMClaimTransaction 來覆蓋狀態轉換、證明和資料可用性；
Taiko 在多個證明系統上運作，現有的測試網路已經支援 PSE 的 ZK-EVM、SGX 和 Reth。基礎設施被配置為適應多個執行節點和證明系統，這將在最後一節中討論。建立在這個基礎設施之上，Taiko 在零知識證明方面將圍繞模組化編譯展開。
一個模組化和開放性的路線圖
模組化
在零知識證明（ZKP）的背景下，考慮到 Multi-Client，Taiko 利用現代編譯器獲得萬用群組件，如 Risc-V 或 WASM。然後將這些指令轉換為各種證明系統（AIR 或 PIL）的算術化表示，並最終使用不同的 SNARKs 對算術化執行軌跡進行編碼。
簡而言之，這個流程是在一個 multi-proof 系統中最可行的方法，因為它充分利用了兩方面的優勢。在節點編譯過程中，現代編譯器給我們帶來以下好處：
- 節點升級與證明無關，因為無需為最新 EIPs 或硬分叉實施電路，只需要保持原始程式碼更新即可；
- 可以從像 LLVM 這樣的工具鏈中免費獲得代碼優化；
- 交叉編譯產生更多多樣性；以上述示例為例，Taiko 有 Geth 或 Reth 編譯成 RICS-V 或 WASM 指令集，已經具備四套證明；
SNARKs 編譯是 Taiko 未來發展重點。請注意，在 PLONK 和 R1CS 等算術化方法與 Halo2、eSTARK 或 Supernova 等後端進行編碼時，並不限制於單一 ZK 協議；而整體式 ZK-VM/EVM 則針對特定 ZKP 進行後端實現。隨著越來越多專案採用彼此元件以提高性能，整體技術棧可能會變得模組化。
由於 ZKP 研究領域發展迅速，在靈活性方面比直接實施最新結果更重要。為了保持靈活性，在 Powdr Labs 和 Risc Zero 等專案上合作開展交叉編譯流水線工作，並盡可能實現模組化。
對於技術精通讀者來說，請參考以下具體好處：
- 我們可以透過優化編譯器以針對不同後端目標進行優化，例如偏愛「高度門控」（high-degree gates）或使用更多查找參數；
- 像 Keccak 和 Poseidon 雜湊函數這樣的加速電路可以作為庫來實現；
- 我們可以逐步將 ZK 功能（如 LogUp）添加到語言中，並啟用相應的後端支援；
- 整合新的 ZK 後端框架以變得更加快速，在一些研究導向的 ZK 專案中，只有概念驗證是以代碼形式開發的，這使得它們在生產環境中使用起來具有挑戰性。透過讓編譯器承擔重要工作，我們可以輕鬆地應用早期階段的框架；
- 現有的後端電路，例如使用 Halo2 編寫的 PSE ZK-EVM 元件，仍然可以透過直接調用進行重複使用；
在合作努力下，Taiko 已經在開發過程中整合了 Risc Zero 的 zeth 和 ZK-VM，並為其開發了一個額外的 SGX 後端。Taiko 工程師還將把 Powdr 整合到多證明系統中、開發 PIL 語言和庫、優化編譯、增加更多後端，並進行一般低級別加速處理。在硬體層面上，Taiko 的零知識加速層（ZAL）旨在標準化證明系統（Halo2、Arkworks、Risc Zero、Polygon 等）與加速庫（CPU、GPU、FPGA 等）之間的協作關係。
開放性
節點、證明系統和整合後端越多，開放性就越好，因此 Taiko 努力將整個社群聚集在一起，Taiko 團隊與其他項目有著悠久的合作歷史，例如，在 ZK-EVM 和 Risc Zero 上與 PSE 合作。
現在透過構建更模組化的 ZK 堆疊，Taiko 可以有效地對 API 進行抽象，以實現更好的普及和整合。Taiko 將作為一個平台，在生產中運送證明系統，並在鏈上進行實戰測試。Taiko 真誠邀請所有專案加入，共同打造更好的零知識技術。
Taiko Stack
一個可擴展、靈活的基礎設施對於 Taiko 的 multi-proof 範式至關重要。
ZK 有效性證明的來源是節點的狀態日誌（Execution Trace）和存儲證明 (Storage Proofs)，這些用於構建見證資料（witnesses）和公共輸入。需要注意的是，witnesses 是特定於證明的，而公共輸入則與協議相關。擁有強大的基礎設施來處理 witnesses 生成非常重要。因此，我們使用一個羽量級主機從 Multi-Client 進行狀態日誌，並將其轉換成多種 witness 提供給相應的證明系統。
在證明端，該設計支援模組化和整體式堆疊，同時我們從目標節點（當前為 Geth）中提取相同的公共輸入。
在未來，如果狀態日誌格式相容的話，Geth 作為 Taiko 節點可以被另一個節點替代。此外，運行在證明系統上（目前是 Reth）的輕節點也可以被編譯成可接受組合語言的任何實現所替代。
關鍵要點
- Taiko 相信多重證明=Multi-Client + 多 SNARKs（以及像 SGX 這樣的 TEE）；
- Taiko 協定非常適合 Multi-Client 系統，因為它有一個開放的 multi-proof 供應鏈，具有 type-1 執行，在 L1 上發佈資料可用性；
- Taiko 設想了一個具有模組化和開放性的 multi-proof 架構，與 Powdr Labs 合作利用節點和 ZKP 的交叉編譯，並與 Risc Zero 合作，在他們的 ZK-VM 和 TEEs 上實現 Taiko 的執行，Taiko 還將繼續努力與 PSE 改進 ZK-EVM 專案；
- Taiko 的靈活基礎設施包括模組化和單片式 ZKP 堆疊；
【免責聲明】市場有風險，投資需謹慎。本文不構成投資建議，用戶應考慮本文中的任何意見、觀點或結論是否符合其特定狀況。據此投資，責任自負。
*原文內容及圖片來源: https://foresightnews.pro/article/detail/52115
