dApp 變得龐大、臃腫且過於複雜不可避免,因此協處理器的普及也是必然。 這隻是時間和採用曲線的問題。

作者:Hill

封面:Uniswap

本文為 SevenX 研究團隊原創,僅供交流學習,不構成任何投資參考。 如需引用,請註明來源。

原版英文報告於 2023 年 6 月發表於 SevenX 的 Mirror 平臺。

近期,Uniswap v4 發佈,儘管功能尚不完備,但我們希望社區能夠廣泛探索前所未有的可能性。 考慮到可能會有大量文章介紹 Uniswap v4 在 DeFi 領域的巨大影響力,因此本文將探討 Uniswap v4 如何激發新型區塊鏈基礎架構:協處理器(Coprocessor)。

Uniswap v4 簡介

正如其白皮書所述,Uniswap v4 主要有 4 項改進:

  • 鉤子(Hook):鉤子是外部部署型合約,在池子執行期間的指定點執行開發者定義的邏輯。 通過這些鉤子,集成者能夠創建靈活且可自定義執行的集中流動性池。
  • 單例(Singleton):Uniswap v4 採用單例設計模式,其中所有池均由單個合約管理,使池部署成本降低了 99% 。
  • 閃電記帳(Flash Accounting):每個操作都會更新一個內部凈餘額,也稱為增量,僅在鎖定結束時進行外部划轉。 閃電記賬簡化了複雜的池操作,例如原子交換和添加。
  • 原生 ETH:支援 WETH 和 ETH 交易對。

節省的大部分 gas 費得益於后 3 項改進,但毫無疑問,最令人興奮的新特性肯定是本文一開始提到的全新亮點:鉤子。

鉤子讓流動性池更加複雜、更加強大

Uniswap v4 的主要增強功能圍繞著鉤子解鎖的可程式設計性。 此特性讓流動性池更加複雜、更加強大,使其比以往任何時候都更加靈活、可自定義程度更高。 與 Uniswap v3 的集中流動性(Uniswap v2 的凈升級)相比,Uniswap v4 的鉤子為流動性池的運行方式提供了更廣泛的可能性。

此版本可以視為 Uniswap v3 的凈升級,但在實際實施時可能並非如此。 與 Uniswap v2 池相比,Uniswap v3 池始終是種升級,因為在 Uniswap v3 中可以執行的 “最差” 升級就是將流動性 “集中” 在整個價格範圍內,其運行原理與 Uniswap v2 相同。 然而,在 Uniswap v4 中,流動性池的可程式設計程度可能不會帶來良好的交易或流動性提供體驗,可能會出現錯誤,並且會出現新的攻擊媒介。 由於流動性池的運行方式發生了諸多變化,希望利用鉤子特性的開發者必須謹慎行事。 他們需要徹底瞭解其設計選擇對池功能的影響以及流動性提供者的潛在風險。

Uniswap v4 中引入鉤子意味著代碼在區塊鏈上的執行方式發生了重大轉變。 傳統上,區塊鏈代碼以預定的順序方式來執行。 然而,鉤子允許更靈活的執行順序,以確保某些代碼在其他代碼之前執行。 此特性將複雜的計算推向堆疊的邊緣,而不是在單個堆疊中加以解決。 從本質上來說,鉤子支援在 Uniswap 原生合約之外執行更複雜的計算。 雖然在 Uniswap v2 和 Uniswap v3 中, 可以通過 Uniswap 之外的手動計算並通過其他智慧合約等外部啟動器觸發來實現此特性,但 Uniswap v4 將鉤子直接集成到了流動性池的智能合約中。 與之前的手動流程相比,這種集成使流程更加透明、可驗證且去信任。

鉤子帶來的另一個好處是可擴展性。 Uniswap 現在不再需要依賴新的智慧合約(需要流動性遷移)或分叉來部署創新。 鉤子現在可直接實現新功能,讓舊流動性池煥然一新。

Uniswap v4 引領 dApp 升級

Uniswap v4 流動性池的今天,就是其他 dApp 的明天。

據我預計,會有越來越多的 dApp 像 Uniswap v4 一樣將計算推到自己的智慧合約之外。

Uniswap v4 如今的運行方式是允許在任何步驟拆分流動性池執行,可以插入任意條件,並觸發 Uniswap v4 合約之外的計算。 到目前為止,唯一類似的情況是閃電貸,如果未在同一區塊內歸還貸款,則恢復執行。 只是計算仍然發生在閃電貸合約中。

Uniswap v4 的設計帶來了許多在 Uniswap v3 中無法實現或實現效果不佳的優勢。 例如,現在可以使用嵌入式預言機,從而減少對經常引入潛在攻擊媒介的外部預言機的依賴。 這種嵌入式設計增強了價格資訊的安全性和可靠性,這是 DeFi 協定得以運行的關鍵因素所在。

此外,以前必須從外部觸發的自動化現在可以直接嵌入到流動性池中。 這種集成不僅緩解了安全問題,還解決了與外部觸發器相關的可靠性問題。 此外,還讓流動性池能夠更加流暢且高效地運行,增強了其整體性能和用戶體驗。

最後,通過 Uniswap v4 中引入的鉤子,可以直接在流動性池中實現更多樣化的安全功能。 過去,流動性池採用的安全措施主要是審計、漏洞獎勵和購買保險。 借助 Uniswap v4,開發者現在可以直接在池子的智慧合約中設計和實施各種失效安全機制和低流動性警告。 這一發展不僅增強了池子的安全性,還為流動性提供者提供了更高的透明度和控制力。

與傳統手機相比,智慧手機的優勢在於可程式設計性。 智慧合約長期以來一直生活在「持久腳本」的陰影之下。 如今,藉助 Uniswap v4 的優勢,流動性池智能合約得到了全新的可程式設計升級,變得「更智慧」。。 我想不通,既然有機會從諾基亞升級到 iPhone,為什麼不是所有 dApp 都想朝著這個方向升級。 由於諾基亞比 iPhone 更可靠,因此我能理解一些智能合約希望保持現狀,但我說的是 dApp 未來的發展方向。

dApp 使用鉤子的擴展問題

dApp 希望使用自己的「鉤子」,這就存在擴展問題。

想像一下將其應用於所有其他 dApp,我們可以在其中插入要觸發的條件,然後在原始交易序列之間插入任意計算。 這聽起來像是 MEV 的運行原理,但 MEV 並不是面向 dApp 開發者的開放設計空間。 這更像是一次未知的黑暗森林徒步,充其量也就是尋求外部 MEV 保護,然而卻只能寄希望於最好的結果。

假設 Uniswap v4 的靈活性激發了新一代 dApp(或從現有 dApp 升級)採用類似的理念,使其執行序列具有更高的可程式設計性。 由於這些 dApp 通常僅部署在一條鏈(L1 或 L2)上,因此我們預計大多數狀態更改都在該鏈上運行。

  • 在 dApp 狀態更改過程中插入的額外計算可能過於複雜且繁瑣,無法在該鏈上運行。 我們可能很快就會超出 Gas 限制,或者根本就難以實現。 此外,還會帶來諸多挑戰,特別是在安全性和可組合性方面的挑戰。
  • 並非所有計算都是平等的。 dApp 對預言機和自動化網路等外部協議的依賴就證明瞭這一點。 然而這種依賴可能會帶來安全風險。

總結一下問題:將所有計算都整合到一條單鏈上的更改狀態的智慧合約執行里來,遠非最佳方式。

解決方案提示

為了解決新一代 dApp 帶來的這個問題(可能很大程度上受到 Uniswap v4 的啟發),我們必須深入研究問題的核心:這一條單鏈。 區塊鏈運行方式如同分散式計算機,用一個 CPU 處理所有任務。 在個人電腦上,現代 CPU 已經在解決這一問題上取得了長足的進步。

正如計算機從單核單片 CPU 過渡到由多個效率核心、性能核心、GPU 和 NPU 組成的模組化設計。

dApp 計算也可以以類似的方式進行擴展。 通過將處理器專業化並結合其成果,將一些計算外包到主處理器之外,即可實現靈活性、最優性、安全性、可擴展性和可升級性。

實際解決方案

實際上只有兩類協處理器:

  • 外部協處理器
  • 嵌入式協處理器

外部協處理器

外部協處理器類似雲端 GPU,很好用、很強大,但是 CPU 和 GPU 通信之間存在額外的網路延遲。 此外,GPU 最終並非由你來控制,因此你就必須相信它正在正確地完成工作。

以 Uniswap v4 為例,假設在最後 5 分鐘 TWAP 時將一些 ETH 和 USDC 添加到流動性池中,如果 TWAP 計算在 Axiom 中完成,則 Uniswap v4 基本上是使用乙太坊作為主處理器,Axiom 作為協處理器。   

Axiom   

Axiom 是以太坊的 ZK 協處理器,它為智能合約提供對所有鏈上數據的去信任訪問以及對數據進行任意運算式計算的能力。

開發者可以對 Axiom 進行查詢,並在其智能合約中以去信任方式使用鏈上經過零知識(ZK)驗證的結果。 要完成查詢,Axiom 會執行三個步驟:

  • 讀取:Axiom 使用零知識證明,以去信任方式更正任何歷史乙太坊區塊中的區塊頭、狀態、交易和收據的讀取數據。 所有乙太坊鏈上數據都以其中一種形式進行編碼,這意味著 Axiom 可以存檔節點可訪問的任何數據。
  • 計算:獲取數據后,Axiom 就會據此應用經過驗證的計算基元。 這包括從基本分析(求和、計數、最大值、最小值)到加密(簽名驗證、金鑰聚合)和機器學習(決策樹、線性回歸、神經網路推理)的各種操作。 每一次計算的有效性都將在零知識證明中得到驗證。
  • 驗證:Axiom 為每個查詢的結果附帶零知識有效性證明,證明(1)已從鏈上正確獲取輸入數據,並且(2)已正確應用計算。 該零知識證明在 Axiom 智慧合約中進行鏈上驗證,然後最終結果以去信任方式供所有下游智能合約使用。

Warp 合約(通過 RedStone)

Warp 合約是最常見的 SmartWeave 實現,該體系結構旨在在 Arweave 上創建可靠、快速的生產就緒型智慧合約平臺/引擎。 實質上,SmartWeave 是 Arweave 交易的有序數位,受益於 Arweave 上交易區塊收錄(Block Inclusion)費用市場的缺失。 這些獨特的屬性允許無限的交易數據,除了存儲成本之外,無需額外費用。

SmartWeave 採用一種稱為「惰性評估」的獨特方法,將執行智慧合約代碼的責任從網路節點轉移給智慧合約的使用者。 從本質上講,這意味著交易驗證的計算被推遲到需要時為止,減少了網路節點的工作負載,並能夠更有效地處理交易。 通過這種方法,用戶可以根據需要執行盡可能多的計算,而不會產生額外費用,從而提供其他智慧合約系統無法實現的功能。 顯然,嘗試在使用者的 CPU 上評估具有數千次交互的合約終究是徒勞的。 為了克服這一挑戰,開發了一個抽象層,例如 Warp 的 DRE。 該抽象層由處理合約計算的分散式驗證器網路組成,最終可顯著縮短響應時間,改善用戶體驗。

此外,SmartWeave 的開放式設計使開發者能夠用任何程式設計語言編寫邏輯,為常常僵化的 Solidity 代碼庫提供了一種全新的替代方案。 通過將某些高成本或高輸送量的操作委託給 Warp,無縫的 SmartWeave 集成可增強基於 EVM 鏈構建的現有社交圖譜協議,從而充分利用這兩種技術的優勢。

Hyper Oracle 

Hyper Oracle 是專為區塊鏈設計的 ZK 預言機網路。 目前,ZK 預言機網路僅面向乙太坊區塊鏈運行。 它使用 zkPoS 從區塊鏈的每個區塊檢索數據,並將其作為數據源,同時使用在 zkWASM 上運行的可程式設計 zkGraph 處理數據,所有這些操作都以去信任且安全的方式進行。

開發者可以使用 JavaScript 定義自定義鏈下計算,將這些計算部署到 Hyper Oracle 網路,並利用 Hyper Oracle Meta Apps 來索引和自動化其智慧合約。

Hyper Oracle 的索引和自動化 Meta Apps 完全可自定義且十分靈活。 可以定義任何計算,並且所有計算(甚至機器學習計算)都將通過生成的零知識證明來加以保護。

  • 乙太坊區塊鏈是 ZK 預言機的原始鏈上數據源,但將來任何網路都可以使用。
  • Hyper Oracle ZK 預言機節點包含兩個主要元件:zkPoS 和 zkWASM。 - zkPoS 通過使用零知識來證明乙太坊的共識,獲取乙太坊區塊鏈的區塊頭和數據根。 零知識證明生成過程可以外包給去中心化的證明者網路。 zkPoS 充當 zkWASM 的外部環路。 - zkPoS 將區塊頭和數據根提供給 zkWASM。 zkWASM 將此數據作為運行 zkGraph 的基本輸入。 - zkWASM 運行自定義的數據映射或 zkGraph 定義的任何其他計算,並生成這些操作的零知識證明。 ZK 預言機節點的操作員可以選擇他們希望運行的 zkGraph 數量(從一個到全部已部署的 zkGraph)。 零知識證明生成過程可以外包給去中心化的證明者網路。
  • ZK 預言機輸出的是鏈下數據,開發者可通過 Hyper Oracle Meta Apps 使用該鏈下數據(將在後續章節中介紹)。 該數據還附帶證明其有效性和計算情況的零知識證明。

其他值得一提的專案

如果您決定採用這種方式,還有一些專案可以用作外部協處理器。 只是這些專案在區塊鏈基礎架構的其他垂直領域有所重合,沒有被單獨地歸類為協處理器。

  • RiscZero:如果 dApp 使用 RiscZero 計算鏈上代理的機器學習任務,並將結果提供給 StarkNet 上的遊戲合約,則會使用 StarkNet 作為主處理器,使用 RiscZero 作為協處理器。
  • IronMill:如果 dApp 在 IronMill 中運行 zk 環路,但在乙太坊上部署智慧合約,則會使用乙太坊作為主處理器,使用 IronMill 作為協處理器。

外部協處理器的潛在用例

  • 治理和投票:歷史鏈上數據可以説明去中心化自治組織(DAO)記錄每個成員擁有的投票權數量,這對投票來說必不可少。 如果沒有這些數據,成員可能無法參與投票過程,這可能會阻礙治理。
  • 承銷:歷史鏈上數據可以幫助資產管理人評估其管理人除利潤之外的業績。 他們可以查看所承受的風險水準和所經歷的回撤類型,這有助於他們在補償或潛在獎勵減少時做出更明智的決策。
  • 去中心化交易所:鏈上的歷史價格數據可以説明去中心化交易所根據過去的趨勢和模式進行交易,可能為用戶帶來更高的利潤。 此外,歷史交易數據可説明交易所改進演算法和用戶體驗。
  • 保險產品:保險公司可以使用歷史鏈上數據來評估風險,併為不同類型的保單設定保費。 例如,在為 DeFi 專案設定保費時,保險公司可能會查看過去的鏈上數據。

請注意,以上所有用例都是異步用例,因為客戶 dApp 在區塊 N 中觸發時需要調用外部協處理器的智能合約。 當協處理器返回計算結果時,必須至少在下一個區塊(即 N+ 1)中以某些形式接受或驗證結果。 這樣一來,至少得到下一個觸發區塊才能利用協同處理結果。 這種模式真的很像雲端 GPU。 它可以很好地運行您的機器學習模型,但由於延遲,您無法在上面愉快地玩快節奏遊戲。

嵌入式協處理器

嵌入式協處理器類似個人電腦主機板上的 GPU,位於 CPU 旁邊。 GPU 與 CPU 的通信延遲非常小。 而且 GPU 完全受您控制,因此您可以非常確定它沒有被篡改。 只是要讓它像雲端 GPU 一樣迅速地運行機器學習,需要付出高昂的成本。

仍以 Uniswap v4 為例。 假設在最後 5 分鐘 TWAP 時將一些 ETH 和 USDC 添加到 Artela 上部署的流動性池中,如果該池部署在 Artela 上的 EVM 中,並且 TWAP 計算在 Aretla 上的 WASM 中完成,則該池基本上是使用 Artela 的 EVM 作為主處理器,Artela 的 WASM 作為協處理器。 Artela

Artela 是使用 Tendermint BFT 構建的 L1。 它提供了一個框架,支援任意執行層的動態擴展,以實現鏈上自定義功能。 每個 Artela 全節點同時運行兩個虛擬機。

  • EVM,存儲和更新智慧合約狀態的主處理器。
  • WASM,存儲和更新 Aspect 狀態的協處理器。

Aspects 代表開發者希望在不觸及智慧合約狀態的情況下運行的任意計算。 可將其視為一個 Rust 腳本,為 dApp 提供超出智慧合約原生可組合性的自定義功能。

如果這一點不好理解,可以試試從以下兩個角度來看:

從區塊鏈體系結構的角度,

  • Aspect 是新的執行層。
  • 在 Artela 中,區塊鏈同時運行兩個執行層——一個用於智慧合約,一個用於其他計算。
  • 這個新的執行層不會引入新的信任假設,因此不會影響區塊鏈本身的安全性。 兩個虛擬機均由運行相同共識的同一組節點保護。

從應用程式運行時的角度,

  • Aspects 是與智慧合約協同工作的可程式設計模組,支援添加自定義功能和獨立執行。
  • 它在幾個方面比單一智能合約更具優勢:- 非侵入性:無需修改智慧合約代碼,即可在合約執行前後進行干預。 - 同步執行:支援鉤子邏輯貫穿整個交易生命週期,允許精細化自定義。 - 直接存取全域狀態和基礎層配置,支援系統級功能。 - 彈性區塊空間:為交易輸送量要求較高的 dApp 提供有協定保障的獨立區塊空間。 - 與靜態預編譯相比,支援 dApp 在運行時實現動態和模組化升級,以平衡穩定性和靈活性。

通過引入這種嵌入式協處理器,Artela 取得了令人興奮的突破:如今,任意擴展模組 Aspects 可以通過與智慧合約相同的交易來執行。 開發者可以將其智慧合約綁定到 Aspects,並讓調用智慧合約的所有交易都由 Aspects 來處理。

此外,與智慧合約一樣,Aspects 在鏈上存儲數據,支援智慧合約和 Aspects 讀取彼此的全域狀態。

這兩個特性極大提升了智能合約和 Aspects 之間的可組合性和互操作性。

  • Aspect 功能
  • 與智能合約相比,Aspects 提供的功能主要側重在交易前和交易后執行。 Aspects 不會取代智能合約,而是對其進行補充。 與智能合約相比,Aspects 為應用程式提供了以下獨特功能:
  • – 自動將可靠的交易插入到顛倒的區塊中(例如,用於計劃的任務)。
  • – 交易引起的狀態數據變化的反轉(只有授權的合約交易才可以反轉)。
  • – 讀取靜態環境變數。
  • – 將臨時執行狀態傳遞到下游的其他 Aspects。
  • – 讀取從上游 Aspect 傳遞的臨時執行狀態。
  • – 動態和模組化的可升級性。
  • Aspect 和智慧合約的區別
  • Aspect 與智能合約的區別在於:
  • – 智慧合約是帶有代碼的帳戶,而 Aspect 是區塊鏈的原生擴展。
  • – Aspect 可以在交易和區塊生命週期的不同點運行,而智能合約僅在固定點執行。
  • – 智慧合約可以訪問自己的狀態和區塊的有限上下文,而 Aspect 則可以與全域處理上下文和系統級 API 進行交互。
  • – Aspect 的執行環境是為接近原生速度而設計。 Aspect 只是代碼邏輯片段,與賬戶無關,因此無法:
  • – 寫入、修改或刪除合約狀態數據。
  • – 創建新合約。
  • – 划轉、銷毀或持有原生代幣。

這些 Aspect 使 Artela 成為一個獨特的平臺,可以擴展智慧合約的功能,並提供更全面、可自定義程度更高的開發環境。

*請注意,嚴格來說,上述 Aspect 也稱為 “內置”Aspect,它是由 Artela Chain 全節點運行的嵌入式協處理器。 dApp 還可以部署自己的異構 Aspect,由外部協處理器運行。 這些外部協處理器可以在外部網路上執行,也可以由另一個共識中的節點子集執行。 它更加靈活,因為 dApp 開發者實際上可以用它執行任何想執行的操作,只要這種操作是安全且合理的。 目前仍在探索之中,具體細節尚未公佈。   

嵌入式協處理器的潛在用例

  • 新 DeFi 專案中涉及的複雜計算(例如複雜的博弈論機制)可能需要嵌入式協處理器具有靈活性和反覆運算性更高的即時計算能力。
  • 針對各類 dApp 更靈活的訪問控制機制。 目前,訪問控制通常僅限於基於智慧合約許可權的黑名單或白名單。 嵌入式協處理器可以解鎖即時且精細的訪問控制級別。
  • 全鏈遊戲(FOCG)中的某些複雜功能。 FOCG 長期以來一直受到 EVM 的限制。 如果 EVM 保留划轉 NFT 和代幣等更簡單的功能,而其他邏輯和狀態更新由協處理器來計算,那麼情況可能會更簡單。
  • 安全機制。 dApp 可以引入自己的主動安全監控和失效安全機制。 例如,流動性池可以阻止每 10 分鐘超過 5% 的提現。 如果協處理器檢測到其中一筆提現,智慧合約可以停止並觸發一些警報機制,例如在某個動態價格範圍內注入緊急流動性。

結束語

dApp 變得龐大、臃腫且過於複雜不可避免,因此協處理器的普及也是必然。 這隻是時間和採用曲線的問題。

運行外部協處理器可以讓 dApp 留在自己的舒適區:無論以前位於哪條鏈上。 然而,對於尋找可部署執行環境的新 dApp 開發者來說,嵌入式協處理器就像個人電腦上的 GPU。 如果自稱高性能個人電腦,就必須擁有像樣的 GPU。

遺憾的是,上述專案尚未在主網上線。 我們無法真正進行基準測試,無法展示哪一個專案更適合哪種用例。 然而,有一件事毋庸置疑,那就是技術呈螺旋式上升。 看起來我們是在原地兜圈子,但請記住,從側面看,歷史將見證技術真的在發展。

可擴展性不可能三角萬歲,協處理器萬歲。

END

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