在這篇文章中,我們將了解最近流行的 zkCoprocessor 和 zkOracle 概念,併比較它們的差異。
當一個術語被創造出來時,它的真正含義併不是由它本身定義的。我們在區塊鏈的例子中已經看到了很多這樣的情況。
我們在 zkCoprocessor 一詞中看到了類似的現象。每個人都使用這個詞,但是它們不一定指相衕的事物。
所以我們想錶達項目本身對 zkCoprocessor 的看法,社區對 zkCoprocessor 的理解,以及從我們的角度來看 zkCoprocessor 的真正含義和作用。
Axiom 的定義 1:zkCoprocessor 在鏈上證明歷史數據。
zkCoprocessor 的概念由 Axiom 推廣,最初將其設想爲 zkAttestor。從 Axiom 的想法來看,zkCoprocessor 代錶了“在鏈上證明歷史數據併在智能合約中不可信地使用該數據”的組件。
請註意,Brevis 團隊錶示,這種類型的 zkCoprocessor 本質上是底層 zk 電路之上的 API/DSL 層。所以這是不可編程的。
RISC Zero 的定義 2:zkCoprocessor 將計算從鏈上卸載到鏈下。
RISC Zero 也經常將自己稱爲 zkCoprocessor。從他們的角度來看,他們將 zkCoprocessor 視爲一個更廣泛的概念,“一種使用 ZKP 將計算從鏈上卸載到鏈下的工具”。
Peteris的定義(衕1):zkCoprocessor可以訪問歷史鏈上狀態。
Aera Finance 的 Peter相信 zkCoprocessor 的行爲非常像一個狀態預言機,主要功能是訪問歷史數據。與此衕時,他和來自 BananaHQ 的 Rishabh 認爲定義2的描述更像是zkVM而不是zkCoprocessor的子類。
Messari、Modular Media 和 Kobi 的定義(與 2 相衕):zkCoprocessor 將計算從鏈上卸載到鏈下。
Messari也給出了自己對zkCoprocessor的定義。梅薩裡 (Messari) 研究員薩米 (Sami)相信 zkCoprocessor 使智能合約開髮人員能夠輕鬆地將覆雜的邏輯卸載到鏈下,而無需新的信任假設。模塊化媒體還給出了相衕的概念。幾何中的科比將 rollup 與協處理器進行比較,Brevis補充説zkCoprocessor權衡維護永久狀態存儲的成本與超提升的性能,Taiko 提出了這樣的設計助推器彙總 進一步探討了 Rollup 協處理器的思想。這些與 RISC Zero 的定義相衕。
綜上所述,我們得出實際中zkCoprocessor有兩種類型,分別如下:
Hyper Oracle 爲我們提供了 Oracle 的解釋爲以太坊定義 zkOracle。
Oracle 實際上總結了任何區塊鏈空間中的“基礎設施”,如比協處理器更好的定義。
如果基礎設施/預言機的輸入是鏈外數據併且輸出是鏈上數據,則它是輸入預言機(例如 Chainlink Price Feed)。相反,它是一個輸出預言機(例如 The Graph)。如果輸出預言機在前,然後是輸入預言機,則它是 I/O 預言機(例如 Gelato Network)。
總之,oracle與協處理器的概念非常相似,但衕時具有數據訪問和計算的特點。
以Hyper Oracle爲例,兩者之間是什麽關繫?zkOracle 和 zkCoprocessor?
爲以太坊定義 zkOracle 中討論的 zkOracle 實際上具有兩個 zkCoprocessor 的功能。
例如,Hyper Oracle 等 zkOracle:
當我們直接將兩種類型的zkCoprocessor與zkOracle進行比較時,我們可以看到zkOracle衕時具有zkCoprocessor的所有功能:
通過直接比較,zkOracle是一個更加端到端的解決方案,可以爲開髮者提供更加完整的技術棧。
這兩個 zkCoprocessor 在各自的垂直領域進行了擴展,例如,數據訪問 zkCoprocessor 解鎖了跨鏈場景,而 zkVM Compute zkCoprocessor 代錶了基於 zkVM 的 zk rollup。
建造時選擇哪一種?
按照一步一步的順序,我們可以做出一些關於構建應用程序的決定。
首先,智能合約的純 Solidity 實現仍然是一個非常好的選擇。雖然純粹的智能合約不能提供一些最好的新穎功能,但它們仍然足夠了在某些場景下。此外,Arbitrum Stylus 的當前可用性還通過純智能合約解鎖了許多新應用程序。
在許多情況下,開髮人員可能希望使用數據訪問 zkCoprocessor 或 zkOracle 進行智能合約來訪問更豐富的數據源。
在這種場景下,如果單獨使用數據訪問zkCoprocessor,計算仍然在智能合約中處理。 zkCoprocessor的作用是降低傳統方式穫取數據的覆雜度,而不是讓智能合約的計算能力更強。
在這個場景中,我們看到了很多與數據相關的小型項目,而不是傳統意義上成熟的 DApp:
通常,一些覆雜的算法無法直接在鏈上計算,對於游戲來説,計算邏輯非常覆雜,例如etherquake和GameOfLife,運行一步需要花費2k美元。或者與機器學習相關的覆雜算法。或者與機器學習相關的覆雜算法不可能在鏈上運行。因此,我們需要 zkVM zkCoprocessor 或 zkOracle 在鏈下運行計算,然後以 ZKP 的形式提交到鏈上。
在這個例子中,我們可以看到它們的一些無限的計算潛力:
最後,我們討論了隻能使用 zkOracle 構建的應用程序。以 DeFi 應用爲例,一個完整的 DeFi 是非常覆雜的。下一代 DeFi 應用,即 DeFi 3.0去中心化應用程序, 將需要:
我們已經討論了 zkOracle 如何共享兩個 zkCoprocessors 的功能,衕時滿足前兩個功能要求。 zkOracle 如何實現自治功能,而 zkCoprocessor 如何不實現自治功能?
那麽 zkCoprocessor 缺乏自主性意味著什麽:
因此,對於像 DeFi 這樣的完整應用程序來説,zkOracle 是一個完美且充分的選擇。
值得註意的是,Hooks 還可以處理 zkCoprocessor 缺失的一些功能,但僅限於 DeFi 等場景,而不是普遍適用。
在這篇文章中,我們將了解最近流行的 zkCoprocessor 和 zkOracle 概念,併比較它們的差異。
當一個術語被創造出來時,它的真正含義併不是由它本身定義的。我們在區塊鏈的例子中已經看到了很多這樣的情況。
我們在 zkCoprocessor 一詞中看到了類似的現象。每個人都使用這個詞,但是它們不一定指相衕的事物。
所以我們想錶達項目本身對 zkCoprocessor 的看法,社區對 zkCoprocessor 的理解,以及從我們的角度來看 zkCoprocessor 的真正含義和作用。
Axiom 的定義 1:zkCoprocessor 在鏈上證明歷史數據。
zkCoprocessor 的概念由 Axiom 推廣,最初將其設想爲 zkAttestor。從 Axiom 的想法來看,zkCoprocessor 代錶了“在鏈上證明歷史數據併在智能合約中不可信地使用該數據”的組件。
請註意,Brevis 團隊錶示,這種類型的 zkCoprocessor 本質上是底層 zk 電路之上的 API/DSL 層。所以這是不可編程的。
RISC Zero 的定義 2:zkCoprocessor 將計算從鏈上卸載到鏈下。
RISC Zero 也經常將自己稱爲 zkCoprocessor。從他們的角度來看,他們將 zkCoprocessor 視爲一個更廣泛的概念,“一種使用 ZKP 將計算從鏈上卸載到鏈下的工具”。
Peteris的定義(衕1):zkCoprocessor可以訪問歷史鏈上狀態。
Aera Finance 的 Peter相信 zkCoprocessor 的行爲非常像一個狀態預言機,主要功能是訪問歷史數據。與此衕時,他和來自 BananaHQ 的 Rishabh 認爲定義2的描述更像是zkVM而不是zkCoprocessor的子類。
Messari、Modular Media 和 Kobi 的定義(與 2 相衕):zkCoprocessor 將計算從鏈上卸載到鏈下。
Messari也給出了自己對zkCoprocessor的定義。梅薩裡 (Messari) 研究員薩米 (Sami)相信 zkCoprocessor 使智能合約開髮人員能夠輕鬆地將覆雜的邏輯卸載到鏈下,而無需新的信任假設。模塊化媒體還給出了相衕的概念。幾何中的科比將 rollup 與協處理器進行比較,Brevis補充説zkCoprocessor權衡維護永久狀態存儲的成本與超提升的性能,Taiko 提出了這樣的設計助推器彙總 進一步探討了 Rollup 協處理器的思想。這些與 RISC Zero 的定義相衕。
綜上所述,我們得出實際中zkCoprocessor有兩種類型,分別如下:
Hyper Oracle 爲我們提供了 Oracle 的解釋爲以太坊定義 zkOracle。
Oracle 實際上總結了任何區塊鏈空間中的“基礎設施”,如比協處理器更好的定義。
如果基礎設施/預言機的輸入是鏈外數據併且輸出是鏈上數據,則它是輸入預言機(例如 Chainlink Price Feed)。相反,它是一個輸出預言機(例如 The Graph)。如果輸出預言機在前,然後是輸入預言機,則它是 I/O 預言機(例如 Gelato Network)。
總之,oracle與協處理器的概念非常相似,但衕時具有數據訪問和計算的特點。
以Hyper Oracle爲例,兩者之間是什麽關繫?zkOracle 和 zkCoprocessor?
爲以太坊定義 zkOracle 中討論的 zkOracle 實際上具有兩個 zkCoprocessor 的功能。
例如,Hyper Oracle 等 zkOracle:
當我們直接將兩種類型的zkCoprocessor與zkOracle進行比較時,我們可以看到zkOracle衕時具有zkCoprocessor的所有功能:
通過直接比較,zkOracle是一個更加端到端的解決方案,可以爲開髮者提供更加完整的技術棧。
這兩個 zkCoprocessor 在各自的垂直領域進行了擴展,例如,數據訪問 zkCoprocessor 解鎖了跨鏈場景,而 zkVM Compute zkCoprocessor 代錶了基於 zkVM 的 zk rollup。
建造時選擇哪一種?
按照一步一步的順序,我們可以做出一些關於構建應用程序的決定。
首先,智能合約的純 Solidity 實現仍然是一個非常好的選擇。雖然純粹的智能合約不能提供一些最好的新穎功能,但它們仍然足夠了在某些場景下。此外,Arbitrum Stylus 的當前可用性還通過純智能合約解鎖了許多新應用程序。
在許多情況下,開髮人員可能希望使用數據訪問 zkCoprocessor 或 zkOracle 進行智能合約來訪問更豐富的數據源。
在這種場景下,如果單獨使用數據訪問zkCoprocessor,計算仍然在智能合約中處理。 zkCoprocessor的作用是降低傳統方式穫取數據的覆雜度,而不是讓智能合約的計算能力更強。
在這個場景中,我們看到了很多與數據相關的小型項目,而不是傳統意義上成熟的 DApp:
通常,一些覆雜的算法無法直接在鏈上計算,對於游戲來説,計算邏輯非常覆雜,例如etherquake和GameOfLife,運行一步需要花費2k美元。或者與機器學習相關的覆雜算法。或者與機器學習相關的覆雜算法不可能在鏈上運行。因此,我們需要 zkVM zkCoprocessor 或 zkOracle 在鏈下運行計算,然後以 ZKP 的形式提交到鏈上。
在這個例子中,我們可以看到它們的一些無限的計算潛力:
最後,我們討論了隻能使用 zkOracle 構建的應用程序。以 DeFi 應用爲例,一個完整的 DeFi 是非常覆雜的。下一代 DeFi 應用,即 DeFi 3.0去中心化應用程序, 將需要:
我們已經討論了 zkOracle 如何共享兩個 zkCoprocessors 的功能,衕時滿足前兩個功能要求。 zkOracle 如何實現自治功能,而 zkCoprocessor 如何不實現自治功能?
那麽 zkCoprocessor 缺乏自主性意味著什麽:
因此,對於像 DeFi 這樣的完整應用程序來説,zkOracle 是一個完美且充分的選擇。
值得註意的是,Hooks 還可以處理 zkCoprocessor 缺失的一些功能,但僅限於 DeFi 等場景,而不是普遍適用。