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 倍。

• 即使我們進行了交易記錄的數據存儲，但對這些數據進行統計查詢和計算的成本更高。例如，計算單個用戶 10K 筆交易的交易量數據將花費 156M 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，這在以前是根本不可能實現的。