應用開發新範式？一文揭示ZK協處理器的神秘面紗

有了 ZK 協處理器，開發人員可以創建數據驅動的 dApps，可以利用 omnichain 數據的曆史記錄來執行複雜的計算，而不需要依賴任何額外的信任假設。

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 位元組的雜湊值。

壓縮過的東西可以解壓縮…隻是不容易😂

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

這項挑戰的根源在於，區塊鏈虛擬機器本身不具備處理資料量大和密集型運算（如上述解壓縮任務）的能力。

 ZK 協處理器架構

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

朋友，這正是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 協處理器的關鍵架構，並討論該領域仍存在的最大技術挑戰。