IOSG Ventures：ZK協處理器從0到1， 它究竟能做什么？

原文作者： IOSG Ventures

感謝 Celer Network 和 Brevis 的 Mo Dong 老師關於 ZK 協處理器核心概念和用例的深入討論，這些思考激發了本系列文章的創作靈感。

ZK 協處理器是區塊鏈領域一項激動人心的創新。它由 Brevis、 Axiom 、 Lagrange 和 Herodotus 等項目率先推出，有望徹底革新我們在區塊鏈上开發應用的方式。有了 ZK 協處理器，开發人員可以創建數據驅動的 dApps，可以利用 omnichain 數據的歷史記錄來執行復雜的計算，而不需要依賴任何額外的信任假設。更為重要的是，它引領了一種新的开發模式：異步應用架構，這為 Web 3.0 軟件框架帶來了前所未有的效率和可擴展性。

在本系列文章中，我們將揭示 ZK 協處理器的神祕面紗。無論您是對其理念、實際應用、基礎機制、面臨的挑战，還是市場策略感興趣，或是想要比較不同的項目，我們希望這些文章都能給您帶來新的啓發。

DEX 上缺少 VIP 交易員計劃的案例

要理解 ZK 協處理器的基本思想，我們需要從現實世界中的激勵性實例开始。

中心化交易所（CEX）和去中心化交易所（DEX）之間的一個明顯區別是存在基於交易量的收費標准，也就是通常所說的「VIP 交易員忠誠度計劃」。這些計劃是留住交易者、提高流動性並最終增加交易所收入的有力工具。

有趣的是，雖然每個 CEX 都擁有至少一個這樣的項目，但 DEX 卻完全沒有。為什么呢？

這是因為在 DEX 中實現這一功能要比在 CEX 中更具挑战性，成本也更高。

在 CEX 中，實施忠誠度項目需要：

• 在中心化數據庫中記錄所有用戶的交易歷史——這是一項便於降低未來查詢成本的任務。

• 每月在高性能的中心化數據庫中執行一次直接查詢，根據歷史數據確定每個用戶的交易量和費用等級。

然而，DEX 在嘗試遵循相同步驟時面臨着重大挑战：

• 由於區塊鏈的存儲成本過高，在智能合約中直接存儲每個用戶的交易歷史並不可行。實施這種邏輯意味着用戶每筆交易的手續費要高出 4 倍。

• 即使我們進行了交易記錄的數據存儲，但對這些數據進行統計查詢和計算的成本更高。例如，計算單個用戶 10 K 筆交易的交易量數據將花費 156 M Gas（對！我們計算過）。

你可能會說「等等，你到底在說什么？在區塊鏈上，每個用戶的每筆交易都已自動存儲（因為它是區塊鏈！）。」在區塊鏈上土生土長的智能合約，應該可以隨時訪問所有這些數據，對吧？

很遺憾，不對！

區塊鏈存儲的數據和區塊鏈虛擬機內智能合約可訪問的數據完全是兩碼事。

對於區塊鏈的完整 / 存檔節點來說，它們存儲了區塊鏈歷史上的大量數據。通過這些節點，您可以輕松訪問：

• 歷史上任何給定時間內整個區塊鏈的狀態（例如，誰是 Cryptopunk 的第一個所有者）。

• 歷史上任何給定時間內的交易和因交易而產生的事件（例如，Charlie 將 $ 1, 000 兌換成 0.5 ETH）。

事實上，流行的鏈外數據索引或分析工具（如 Nansen 和 Dune Analytics ）可利用這一廣泛的數據集進行深入分析。

然而，對於嵌入區塊鏈虛擬機的智能合約來說，數據訪問的限制要大得多。它們不能使用鏈外索引解決方案生成的數據，因為這會給這些外部且通常是中心化的索引解決方案帶來額外的信任問題。

事實上，智能合約只能輕松且無需信任地訪問以下數據:

• 虛擬機狀態中存儲的數據（不包括交易或事件數據）。

• 最新區塊中的數據（歷史數據訪問是受限的）。

• 通過「查看」功能公开的其他智能合約的數據（不包括私有或內部合約數據）。

上述說法的一個關鍵細微差別在於「輕松」一詞。

智能合約並非完全不知道區塊鏈上的全部數據。在 EVM 中，智能合約可以訪問最新 256 個區塊的區塊頭哈希值。這些區塊頭囊括了區塊鏈上截至當前區塊的所有活動，並通過默克爾樹和 Keccak 哈希值濃縮成 32 字節的哈希值。

壓縮過的東西可以解壓縮...只是並不容易 ?

試想一下，如果想利用最近的區塊頭，無需信任地訪問上一個區塊中的特定數據。這種方法包括從存檔節點獲取鏈外數據，然後構建默克爾樹和區塊有效性證明，以確定數據在區塊鏈中的真實性。然後，EVM 對有效性證明進行處理，以進行驗證和解釋。這樣的操作既繁瑣又艱巨，僅僅為了檢索過去的幾個代幣余額，就可能消耗數千萬 Gas。

這一挑战的根源在於，區塊鏈虛擬機本身不具備處理數據量大和密集型計算（如上述解壓縮任務）的能力。

ZK 協處理器架構

（資料來源: Brevis 在 ETHSG 的演示幻燈片）

如果有一種魔法，能讓區塊鏈委托進行這種數據密集型的繁瑣計算，並以低成本迅速獲得結果，而且不需要任何額外的信任假設，那就再理想不過了。

朋友，這正是 ZK 協處理器的用途所在。

「協處理器」這一名稱的靈感來源於計算機架構的發展史。例如，GPU 作為 CPU 的協處理器被引入，是因為 CPU 必須將某些昂貴且自身難以運行的重要計算任務（如圖形計算或人工智能訓練）下放給「輔助處理器」，即 GPU。

但是，ZK 協處理器中的「ZK」又是什么意思呢？在深入探討復雜的技術細節之前，讓我們先來了解一下這項創新技術的廣泛意義和潛力。

我們需在 Web 3.0 中數據驅動的 dApps

交易費返還就是一個很好的例子。按照這一思路，有了 ZK 協處理器，就可以在衆多 DeFi 協議中無縫引入各種忠誠度計劃。

然而，這遠不止 DeFi 忠誠度計劃。您現在也許可以看到，Web 3.0 的其他領域也存在同樣的問題。仔細想想，所有現代 Web 2.0 應用程序都是數據驅動的，而 Web 3.0 應用程序卻無一例外。要想打造「殺手級應用」，讓用戶體驗與傳統互聯網應用相媲美，這種數據驅動方法是不可或缺的。

讓我們看看 DeFi 領域的另一個例子：通過重新設計流動性挖礦獎勵機制來提高流動性效率。

目前，AMM DEX 上的流動性激勵機制採用「現收現付」模式。在這種模式下，當 LP 貢獻流動性時，Farming 獎勵即刻分配給 LP。然而，這種模式遠非最佳。專業 Farmer 在感覺到市場波動時，可以迅速撤回流動資金，以避免無常損失。這樣一來，他們為協議提供的價值微乎其微，但仍能獲得可觀的回報。

理想的 AMM 流動性激勵機制會對 LP 的堅定性進行追溯評估，尤其是在市場大幅波動期間。那些在這種情況下始終支持資金池的人應該獲得最高獎勵。然而，獲取對這一模型至關重要的 LP 歷史行為數據，在今天仍然是不可行的。

要做到這一點，你需要 ZK 協處理器。

在 DeFi 領域，我們可以舉出很多類似的例子，無論是使用預定算法和規則進行主動 LP 頭寸管理，使用非代幣流動性頭寸建立信貸額度，還是根據過去的還款行為確定貸款的動態清算偏好。

然而，ZK 協處理器的潛力不僅限於 DeFi。

利用 ZK 協處理器打造具有出色用戶體驗的鏈上遊戲

Web 2.0 遊戲實時操作功能示例

當你進入一款新安裝的 Web 2.0 遊戲時，你的一舉一動都會被詳細記錄下來。這些數據不會被闲置，而是會很大程度影響你的遊戲之旅。它決定何時為你提供遊戲內購买選項，何時推出獎勵遊戲，何時向你發送措辭經過精心設計的推送通知，以及與你匹配的對手等等。這些都是遊戲行業所說的實時運營（LiveOps）的組成部分，是提高玩家參與度和收入流的基石。

要使完全鏈上遊戲的用戶體驗與 Web 2.0 經典遊戲相媲美，就需要這些 LiveOps 功能。這些功能應基於玩家與遊戲智能合約的歷史互動和交易。

遺憾的是，在區塊鏈遊戲中，這類功能要么完全缺失，要么仍由中心化解決方案驅動。原因與 DEX 的例子如出一轍：難以在區塊鏈上挖掘和計算歷史遊戲數據。

是的，同樣，你需要 ZK 協處理器來實現這一點。

Web 3.0 社交和身份識別應用是另一個沒有 ZK 協處理器支持就無法運行的領域。

在區塊鏈世界中，您的數字身份是由您過去的行為編織而成的一張網。

• 想證明自己是 NFT OG？你得證明你是 Cryptopunk 的原始礦工之一。

• 吹噓自己是個大交易員？向我證明你在 DEX 上支付了超過 100 萬美元的交易費。

• 和 Vitalik 關系密切？向我證明他的地址向你的地址發送過資金。

鏈下系統，無論是人類還是 Web 2.0 應用程序，都可以輕松生成這種證明，因為就像交易量的例子一樣，它們可以訪問包含所有這些數據的存檔節點。

基於這種直接數據訪問的身份證明需要強大的錢包地址關聯，因此也需要承擔其犧牲隱私的缺點，但它確是可行的。

然而，就像在交易量的例子中一樣，如果你想讓智能合約相信你的 OG 身份，並在不引入額外信任證明的情況下搶先體驗一些新玩意，其實根本就沒有什么好辦法。

有了 ZK 協處理器，您就可以編織出一個可靠的身份證明，一個您過去行為的證明，一個任何智能合約都會毫無疑問地接受的證明。您在不同應用程序甚至不同區塊鏈上的互動都可以巧妙地合並起來，形成這一證明。

更吸引人的是 ZK 固有的隱私性。您的錢包地址不必與您的身份公开關聯。例如，你可以證明自己擁有 Cryptopunk NFT，而無需透露具體的錢包地址。或者，你可以證明在 Uniswap 上執行過 10, 000 次交易，但不透露具體數字。

ZK 協處理器為數據驅動的 dApp 構建开闢了一個全新的領域，但它的意義遠不止於此。

超越數據驅動範式：用 ZK 協處理器开創 Web 3.0 異步模式

數據驅動的 dApp 模式雖然很吸引人，但只是冰山一角。

ZK 協處理器的出現將徹底改變我們對區塊鏈計算的看法，开創一個異步處理成為 Web 3.0 標准的時代。這種轉變重新定義了任務的處理方式，專門的處理器可以獨立運行，從而提高效率。

讓我們先來了解一下什么是異步處理。

想象一下，在一家同步餐廳裏，一個人同時扮演廚師和服務員的角色。你點了菜，他就开始准備，讓你等着。他只能在為您上完菜後，再去招呼另一位客人。雖然這種設置可能會滿足你的需求，但對其他人來說卻很難提高效率。

相比之下，在異步餐廳中，不同的廚師和不同的服務員協同工作。服務員在接受您的訂單後，會迅速將訂單轉交給廚師，同時為其他顧客提供服務。菜餚完成後，廚師向服務員發出信號，服務員隨即為您上菜。

在計算機系統中：

同步架構就像第一家餐廳一樣，一個人等待每項任務完成後再繼續。這種架構簡單明了，但速度可能較慢，因為它一次只處理一項任務。而且，這個人可能是個好服務員，但不是個好廚師。

異步架構就像第二家餐廳，其中有一些解耦和專門的系統組件，它們相互發送信息和任務，作為一種協調方式。這允許每個組件同時管理自己的任務线。雖然可能需要更復雜的管理方法，但這種架構速度更快，效率更高。

每一個現代互聯網應用程序都是基於異步架構構建的，以提高效率和可擴展性，我們認為 Web 3.0 也應如此。

ZK 協處理器將成為這一變革的先驅。對於 dApp 开發者來說，區塊鏈就像我們異步餐廳裏的服務員。它主要處理直接改變區塊鏈狀態的計算，如或有資產所有權變更。所有其他計算都應交由穩健的 ZK 協處理器處理，它們就像精通廚藝的廚師一樣，通過異步處理的強大功能，高效地烹飪出結果並發送給服務員。

具體來說，如果區塊鏈應用中的計算符合以下兩個「可行條件」之一，就應考慮使用 ZK 協處理器。

ZK 協處理器可執行條件：

• 鏈上計算成本 >（鏈外 ZK 協處理器計算（包括證明生成）+ 鏈上驗證成本）

• 鏈上計算延遲 > （鏈外 ZK 協處理器計算（包括證明生成）+ 鏈上驗證延遲）

即使它們只符合其中之一，也值得考慮！

現在你就可以看到，它不僅僅是數據驅動的 dApps！它是一種將 ML 等高水准通用計算引入區塊鏈的全新方式，但更重要的是，它引入了改變模式的異步架構來構建 dApp，這在以前是根本不可能實現的。

下一篇章….

如果我們已經成功地讓您相信 ZK 協處理器是一個將產生深遠影響的想法，那么現在也許是時候談談它們是如何工作的了。在下一篇博客中，我們將探討 ZK 協處理器的關鍵架構，並討論該領域仍然存在的最大技術挑战。

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。