如果要求你只用一句話來向一個非技術或是開發人員講清楚協處理器,你會如何描述?

作者:KrisLaobaiABCDECapitalMo DongCeler Network

封面:Photo by Sebastian Kanczok on Unsplash

隨著近幾個月協處理器概念的火熱,這一新的 ZK 用例開始得到越來越多人的關注。

然而我們發現,大多數人對於協處理器概念還是相對陌生,尤其是對於協處理器的精準定位 — 協處理器是什麼,又不是什麼,還比較模糊。 而對於市面上幾家協處理器賽道的技術方案對比,尚未有人系統的整理過,這篇文希望能夠給市場和使用者一個關於協處理賽道更加清晰的認識。

一. 協處理器 Co-Processor 是什麼,又不是什麼

如果要求你只用一句話來向一個非技術或是開發人員講清楚協處理器,你會如何描述?

我想董沫博士的這句可能非常接近標準答案 — 協處理器說白了就是 “ 賦予智慧合約 Dune Analytics 的能力”。

這句話該如何拆解?

想像一下我們使用 Dune 的場景 — 你想要去 Uniswap V3 做 LP 賺點手續費,於是乎你打開 Dune,找到最近 Uniswap 上各種交易對的交易量,手續費近 7 天的 APR,主流交易對的上下波動區間等等...

又或者 StepN 火了那會,你開始炒鞋,不確定什麼時候該脫手,於是你每天盯著 Dune 上面 StepN 的數據,每日交易量,新增用戶數,鞋子地板價...... 打算一旦出現增長放緩或是下跌趨勢就趕緊跑。

當然,可能不僅你在盯著這些數據,Uniswap 和 StepN 的開發團隊也同樣關注這些數據。

這些數據非常有意義 — 它不僅可以幫助判斷趨勢的變化,還可以以此玩出更多的花樣,正如互聯網大廠常用的 “大數據” 打法。

比如根據使用者經常買賣的鞋子風格與價格,推薦類似的鞋子。

比如根據使用者持有創世鞋子的時長,推出一個「用戶忠誠獎勵計劃」,給予忠誠使用者更多的空投或是福利。

比如根據 Uniswap 上面 LP 或是 Trader 提供的 TVL 或是交易量推出一個類似 Cex 的 VIP 方案,給予 Trader 交易手續費減免或是 LP 手續費份額增加的福利

......

這時問題來了 — 互聯網大廠玩大數據+AI,基本是個黑箱,想怎麼弄怎麼弄,使用者看不到,也不在乎。

但在 Web3 這邊,透明,去信任是咱們天然的政治正確,拒絕黑箱!

於是乎當你想要實現上述場景之時,會面臨一個兩難之境 — 要麼你通過中心化的手段去實現,“後台手動” 用 Dune 統計完這些索引數據,然後去部署實施; 要麼你寫一套智慧合約,自動去鏈上抓取這些數據,完成計算,自動部署分。

前者會讓你陷入「政治不正確」的信任問題。

後者在鏈上產生的 Gas 費用會是個天文數位,你(專案方)的錢包承受不起。

這時候就是協處理器登場的時候了,把剛才那兩種手段結合一下,同時把 “後台手動” 這個步驟通過技術手段 “自證清白”,換句話說,通過 ZK 技術把鏈外 “索引+計算” 這一塊 “自證清白” 了,然後喂給智慧合約,這樣信任問題解決,海量的 Gas 費用也不見了,完美!

為什麼會叫做「協處理器」呢? 其實這是來源於 Web2.0 發展歷史中的「GPU」。 GPU 之所以在當時被引入作為一個單獨的計算硬體,獨立於 CPU 存在,是因為他的設計架構能夠處理一些 CPU 從根本上就難以處理的計算,比如大規模的並行重複計算,圖形計算等等。 正是有了這種「協處理器」的架構,我們今天才有了精彩的 CG 電影,遊戲,AI 模型等等,所以這種協處理器的架構實際上是計算計體系架構的一次飛躍。 現在各家協處理器團隊也是希望將這種架構引入 Web3.0,在這裡區塊鏈就類似於 Web3.0 的 CPU,不論是 L1 還是 L2,都天生不適應這類「重數據」和「複雜計算邏輯」的任務,所以引入一個區塊鏈協處理器,來幫助處理這類計算,從而極大拓展區塊鏈應用的可能性。

所以協處理器做的事情歸納一下就是兩件事:

  1. 從區塊鏈上拿數據,並通過 ZK 證明我拿的數據是真的,沒摻假;
  2. 根據剛才拿到的數據做出相應的計算,並再次通過 ZK 證明我算的結果也是真的,沒摻假,計算結果就可以被智慧合約「低費用+Trustless」的調用了。

前段時間 Starkware 那邊火了一個概念,叫做 Storage Proof,也叫 State Proof,基本上做的就是步驟 1,代表是,Herodotus,Langrage 等等,許多基於 ZK 技術的跨鏈橋的技術重點也在步驟 1 上。

協處理器無非也就是步驟 1 完事兒之後再加一個步驟 2,免信任提取數據之後再做個免信任計算就 OK 了。

所以用一個相對技術一點的話來精確形容,協處理器應該是 Storage Proof/State Proof 的超集,是 Verfiable Computation(可驗證計算)的一個子集。

要注意的一點是,協處理器不是 Rollup。

從技術上講,Rollup 的 ZK 證明類似於上述步驟 2,而步驟 1“拿數據” 這個過程,是通過 Sequencer 直接實現的,即便是去中心化 Sequencer,也只是通過某種競爭或是共識機制去拿,而非 Storage Proof 這種 ZK 的形式。 更重要的是 ZK Rollup 除了計算層之外,還要實現一個類似 L1 區塊鏈的存儲層,這個存儲是永久存在的,而 ZK Coprocessor 則是 “無狀態” 的,進行完計算之後,不需要保留所有狀態。

從應用場景來講,協處理器可以看做所有 Layer1/Layer2 的一個服務型外掛程式,而 Rollup 則是自己重新起一個執行層,幫助結算層擴容。

二. 為什麼非得用 ZK,用 OP 行不行?

看完上面,你可能會有一個疑惑,協處理器,非得用 ZK 來做嗎? 聽起來怎麼這麼像是一個「加了 ZK 的 Graph」,而我們似乎對於 Graph 上面的結果也沒有什麼「大的懷疑」。

說是這麼說,那是因為平常你用 Graph 的時候基本上不怎麼牽扯真金白銀,這些索引都是服務 off-chain services 的,你在前端使用者介面上看到的,交易量,交易歷史等等數據,可以通過 graph,Alchemy,Zettablock 等多家數據索引提供者來提供,但這些數據沒法塞回到智慧合約裡面, 因為一旦你塞回去就是去增加了額外的對這個索引服務的信任。 當數據跟真金白銀,尤其是那種大體量的 TVL 進行聯動之時,這種額外的信任就變得重要起來,想像下一個朋友問你借 100 塊,你可能眼都不眨說給就給了,問你借 1 萬,甚至 100 萬的時候呢?

但話又說回來,是不是協處理上面所有的場景真的都得用 ZK 來做呢? 畢竟 Rollup 裡面我們就有 OP 和 ZK 兩條技術路線,最近流行的 ZKML,也有相應分支路線的 OPML 概念提出,那麼協處理器這事兒,是不是也有個 OP 的分支,比如說 OP-Coprocessor?

其實還真的有 — 不過在此我們先對具體的細節保密,很快我們將會發佈更細節的信息出來。

三. 協處理器哪家強 — 市面上常見的幾家協處理器技術方案對比

2.Brevis:

Brevis 的架構由三個元件組成:zkFabric、zkQueryNet 和 zkAggregatorRollup。

如下是一個 Brevis 的架構圖:

zkFabric: 從所有連接的區塊鏈中收集區塊頭,並生成證明這些區塊頭有效性的 ZK 共識證明。 通過 zkFabric, Brevis 實現了對多鏈可互操作的協處理器,也就是能夠讓一個區塊鏈訪問另外一個區塊鏈的任意歷史數據。

zkQueryNet: 一個開放的 ZK 查詢引擎市場,可接受來自 dApp 的數據查詢,並對其進行處理。 數據查詢使用來自 zkFabric 的經過驗證的區塊頭處理這些查詢,並生成 ZK 查詢證明。 這些引擎既有高度專業化的功能,也有通用化的查詢語言,可滿足不同的應用需求。

zkAggregatorRollup: 一個 ZK 卷積區塊鏈,充當 zkFabric 和 zkQueryNet 的聚合和存儲層。 它驗證來自這兩個元件的證明,存儲經過驗證的數據,並將其經過 zk 驗證的狀態根提交到所有連接的區塊鏈上。

ZK Fabric 作為為區塊頭生成 proof 的關鍵部分,保證這一部分的安全是非常重要的,如下為 zkFabric 的架構圖:

zkFabric 基於零知識證明(ZKP)的輕用戶端使其完全免於信任,無需依賴任何外部驗證實體。 無需依賴任何外部驗證實體,因為其安全性完全來自於因為其安全性完全來自於底層區塊鏈和數學上可靠的證明。

zkFabric Prover 網路為每個區塊鏈的 lightclient 協議實現電路,該網路為區塊頭生成有效性證明。 證明者可利用 GPU、FPGA 和 ASIC 等加速器,最大限度地減少證明時間和成本。

zkFabric 依賴於區塊鏈和底層加密協定的安全假設和底層加密協定的安全假設。 不過,要確保 zkFabric 的有效性,至少需要一個誠實的中繼器來同步正確的 fork。 因此,zkFabric 採用了去中心化的中繼網路而不是單個中繼器來優化 zkFabric 的有效性。 這種中繼網路可以利用現有的結構,如 Celer 網路中的狀態監護網路。

證明者分配: 證明者網路是一個分散的 ZKP 證明者網路、需要為每個證明生成任務選擇一個證明者,並向這些證明者支付費用。

目前的部署:

目前為各種區塊鏈(包括乙太坊 PoS、Cosmos Tendermint 和 BNB Chain)實現的輕用戶端協議作為示例和概念驗證。

Brevis 目前已經跟 uniswap hook 開展合作,hook 大大添加了自定義 uniswap 池,但與 CEX 相比,UnisWap 仍然缺乏有效的數據處理功能來創建依賴大型使用者交易數據(例如基於交易量的忠誠度計劃)的功能。

在 Brevis 的説明下,hook 解決了挑戰。 hook 現在可以從使用者或 LP 的完整歷史鏈數據中讀取,並以完全無信任的方式運行可自定義的計算。

2. Herodotus

Herodotus 是一個強大的數據訪問中間件,它為智能合約提供如下跨乙太坊層同步訪問當前和歷史鏈上數據的功能:

L1 states from L2s

L2 states from both L1s and other L2s

L3/App-Chain states to L2s and L1s

Herodotus 提出存儲證明這個概念,存儲證明融合了包含證明(確認數據的存在)和計算證明(驗證多步驟工作流的執行),以證明大型數據集(如整個乙太坊區塊鏈或 rollup)中一個或多個元素的有效性。

區塊鏈的核心是資料庫,其中的數據使用 Merkle 樹、Merkle Patricia 樹等數據結構進行加密保護。 這些數據結構的獨特之處在於,一旦數據被安全地提交給它們,就可以產生證據來確認數據包含在結構內。

Merkle 樹和 Merkle Patricia 樹的使用增強了乙太坊區塊鏈的安全性。 通過在樹的每個級別對數據進行加密散列,幾乎不可能在不被發現的情況下更改數據。 對數據點的任何更改都需要更改樹上相應的哈希值到根哈希值,這在區塊鏈標頭中公開可見。 區塊鏈的這一基本特徵提供了高水平的數據完整性和不變性。

其次,這些樹可以通過包含證明進行有效的數據驗證。 例如,當驗證交易的包含或合約的狀態時,無需搜索整個乙太坊區塊鏈,只需驗證相關 Merkle 樹內的路徑即可。

Herodotus 定義的存儲證明是以下內容的融合:

  • 包含證明:這些證明確認加密數據結構(例如 Merkle 樹或 Merkle Patricia 樹)中特定數據的存在,確保相關數據確實存在於數據集中。
  • 計算證明:驗證多步驟工作流程的執行,證明廣泛數據集中一個或多個元素的有效性,例如整個乙太坊區塊鏈或匯總。 除了指示數據的存在之外,它們還驗證應用於該數據的轉換或操作。
  • 零知識證明:簡化智慧合約需要交互的數據量。 零知識證明允許智慧合約在不處理所有基礎數據的情況下確認索賠的有效性。

Workflow :

1. 獲得區塊哈希

區塊鏈上的每個數據都屬於特定的區塊。 區塊哈希作為該區塊的唯一標識符,通過區塊頭來總結其所有內容。 在存儲證明的工作流程中,首先需要確定和驗證包含我們感興趣的數據的區塊的區塊哈希,這是整個過程中的首要步驟。

2. 獲得區塊頭

一旦獲得了相關的區塊散列,下一步就是訪問區塊頭。 為此,需要與上一步獲取的區塊哈希值相關聯的區塊頭進行哈希處理。 然後,將提供的區塊頭的哈希值與所得的區塊哈希值進行比較:

取得哈希的方式有兩種:

(1)使用 BLOCKHASH opcode 來檢索

(2)從 Block Hash Accumulator 來查詢歷史中已經被驗證過的區塊的哈希

這一步驟可確保正在處理的區塊頭是真實的。 該步驟完成後,智慧合約就可以訪問區塊頭中的任何值。

3. 確定所需的根(選擇)

有了區塊頭,我們就可以深入研究它的內容,特別是:

stateRoot: 區塊鏈發生時整個區塊鏈狀態的加密摘要。

receiptsRoot: 區塊中所有交易結果(收據)的加密摘要。

事務根(transactionsRoot): 區塊中發生的所有交易的加密摘要。

跟可以被解碼,使得能夠核實區塊中是否包含特定帳戶、收據或交易。

4. 根據選取根來驗證資料(選擇)

有了我們所選的根,並考慮到乙太坊採用的是 Merkle-Patricia Trie 結構,我們就可以利用 Merkle 包含證明來驗證樹中是否存在數據。 驗證步驟將根據數據和區塊內數據的深度而有所不同。

目前支援的網路:

From Ethereum to Starknet

From Ethereum Goerli* to Starknet Goerli*

From Ethereum Goerli* to zkSync Era Goerli*

3. Axiom

Axiom 提供了一種方式可以讓開發人員從乙太坊的整個歷史記錄中查詢區塊頭,帳戶或存儲值。 AXIOM 引入了一種基於密碼學的連結的新方法。 Axiom 傳回的所有結果均通過零知識證明在鏈上驗證,這意味著智慧合約可以在沒有其他信任假設的情況下使用它們。

Axiom 最近發佈了 Halo2-repl ,是一個基於瀏覽器的用 Javascript 編寫的 halo2 REPL。 這使得開發人員只需使用標準的 Javascript 就能編寫 ZK 電路,而無需學習 Rust 等新語言、安裝證明庫或處理依賴關係。

Axiom 由兩個主要技術元件組成:

AxiomV1 — 乙太坊區塊鏈緩存,從 Genesis 開始。

AxiomV1Query — 執行針對 AxiomV1 查詢的智能合約。

(1)在 AxiomV1 中緩存區塊哈希值:

AxiomV1 智慧合約以兩種形式緩存自創世區塊以來的乙太坊區塊哈希:

首先, 快取了連續 1024 個區塊哈希的 Keccak Merkle 根。 這些 Merkle 根通過 ZK 證明進行更新,驗證區塊頭哈希是否形成以 EVM 直接可訪問的最近 256 個區塊之一或已存在於 AxiomV1 緩存中的區塊哈希為結束的承諾鏈。

其次。 Axiom 從創世區塊開始存儲這些 Merkle 根的 Merkle Mountain Range。 該 Merkle Mountain Range 是在鏈上構建的,通過對緩存的第一部分 Keccak Merkle 根進行更新。

(2)在 AxiomV1Query 中履行查詢:

AxiomV1Query 智慧合約用於批量查詢,以實現對歷史乙太坊區塊頭、帳戶和帳戶存儲的任意數據的無信任訪問。 查詢可以在鏈上進行,並且通過針對 AxiomV1 緩存的區塊哈希進行的 ZK 證明來在鏈上完成。

這些 ZK 證明檢查相關的鏈上數據是否直接位於區塊頭中,或者位於區塊的帳戶或存儲 Trie 中,通過驗證 Merkle-Patricia Trie 的包含(或不包含)證明來實現。

4. Nexus

Nexus 試圖利用零知識證明為可驗證的雲計算搭建一個通用平臺。 目前是 machine archetechture agnostic 的,對 risc 5/ WebAssembly/ EVM 都支援。 Nexus 利用的是 supernova 的證明系統,團隊測試生成證明所需的記憶體為 6GB,未來還會在此基礎上優化使得普通的用戶端設備電腦可以生成證明。

確切的說,架構分為兩部分:

Nexus zero:由零知識證明和通用 zkVM 支援的去中心化可驗證雲計算網路。

Nexus: 由多方計算、狀態機複製和通用 WASM 虛擬機驅動的分散式可驗證雲計算網路。

Nexus 和 Nexus Zero 應用程式可以用傳統程式設計語言編寫,目前支援 Rust,以後將會支援更多的語言。

Nexus 應用程式在去中心化雲計算網路中運行,該網路本質上是一種直接連接到乙太坊的通用「無伺服器區塊鏈」。 因此,Nexus 應用程式並不繼承乙太坊的安全性,但作為交換,由於其網路規模縮小,可以獲得更高的計算能力(如計算、存儲和事件驅動 I/O)。 Nexus 應用程式在專用雲上運行,該雲可達成內部共識,並通過乙太坊內部可驗證的全網閾值簽名提供可驗證計算的 “證明”(而非真正的證明)。

Nexus Zero 應用程式確實繼承了乙太坊的安全性,因為它們是帶有零知識證明的通用程式,可以在 BN-254 橢圓曲線上進行鏈上驗證。

由於 Nexus 可在複製環境中運行任何確定性 WASM 二進位檔,預計它將被用作證明生成應用的有效性/分散性/容錯性來源,包括 zk-rollup 排序器、樂觀的 rollup 排序器和其他證明器,如 Nexus Zero 的 zkVM 本身。

免責聲明:作為區塊鏈資訊平臺,本站所發佈文章僅代表作者及嘉賓個人觀點,與 Web3Caff 立場無關。 文章內的資訊僅供參考,均不構成任何投資建議及要約,並請您遵守所在國家或地區的相關法律法規。