header-langage
简体中文
繁體中文
English
Tiếng Việt
한국어
日本語
ภาษาไทย
Türkçe
掃碼下載APP

WAGMi Venture:5分鐘了解Arbitrum發展歷史與未來方向

閱讀本文需 26 分鐘
未來,Arbitrum在DeFi層面的發展更加值得期待。
原文來源:WAGMi Venture
原文作者:0xMoonda


隨著 DeFi 與 NFT 的普及,以太坊在過去幾年中已發展成為加密經濟的主要結算層。但受區塊鏈本身屬性限制,其單次可處理的交易數量是有限的。在鏈上交易極度活躍的情況下,用戶之間為了爭奪有限的區塊空間經常使網絡陷入擁堵的狀態。大大降低用戶的體驗——高昂的 gas 費用與長時間的 pending 交易。為解決上述問題,以太坊社區採取了鏈上與鏈下擴容的方法。從 2021 年開始,開發者們開始將焦點轉向鏈下——在以太坊網絡的基礎上創建 L2 rollups,Arbitrum 就是一種這樣的 L2 rollup 技術。


Arbitrum 是如何解決以太坊擴容問題的?


Arbitrum 網絡主要由兩類節點組成:batcher 與 validator。兩類節點共同與以太坊主網交互,以維持獨立鏈的狀態,這條獨立的鏈被稱為 L2。 batcher 負責記錄用戶在 L2 中的交易並將數據提交至 L1。 validator 負責讀取 L1 中的數據,處理交易並更新 L2 的狀態。隨後 validator 會將更新後的 L2 狀態數據發佈到 L1,這樣其它節點就可以對新狀態的有效性進行驗證。整個過程大致如下:


· 用戶將 L2 的交易發送至 batcher,常被稱為 sequencer;


· sequencer 在收到足量的交易後,會將數據打包並發送至 L1;


· validator 會讀取 L1 合約中的交易並對在 L2 狀態下的本地副本進行處理;


· 處理完成後會在本地生成新的 L2 狀態,validator 將新 stateRoot 發送至 L1 的合約中;


· 其它 validator 開始處理同批處於 L2 狀態下的本地副本;


· validator 將 L2 stateRoot 的結果與發送至 L1 合約中的原 stateRoot 進行比對;


· 如果 validator 獲得的 stateRoot 與發布至 L1 的 stateRoot 不同,那麼 validator 會在 L1 中發起 challenge;


· challenge 要求 challenger 與發布原 stateRoot 的 validator 輪流證明正確的 stateRoot 是什麼;


· 無論哪方輸掉 challenge,其質押都會被削減。若原 L2 的 stateRoot 無效,則會被下一個 validator 銷毀,不會保存至 L2 中。


batcher 與 L2 交易數據


batcher 使用兩種不同的 L1 合約發布數據,一個是「delayed inbox」,另一個是「sequencer inbox」。任意節點都可以將交易發送至 delayed inbox,只有 sequencer 可以將交易數據發送至 sequencer inbox。 sequencer inbox 從 delayed inbox 中提取交易數據,並將其與 sequencer 提交的其它 L2 交易混在一起。因此,sequencer inbox 是每個 validator 提取最新 L2 交易數據的主要合約。 batcher 的類型分為三種:forwarder、aggregator、sequencer。用戶可將 L2 的交易發送至三種類型中的任意一種。 forwarder 將 L2 交易發送至另一節點的指定地址。 aggregator 地址作為指定的節點既可以是 sequencer 也可以是 aggregator。


aggregator 接收傳入的 L2 交易並將它們分批處理成單個信息發送至 delayed inbox 當中。 Sequencer 也會接收傳入的 L2 交易並將它們分批處理成單個信息,但它會將信息發送至 sequencer inbox。如果 sequencer 停止向 sequencer inbox 發送交易,那麼任意節點都可以通過智能合約調用要求 sequencer inbox 中包含來自 delayed inbox 的交易。這樣既可以保證 Arbitrum 網絡的可用性,同時又可以抵抗惡意 sequencer。目前,Arbitrum 在主網運行的是自己的獨立 sequencer,未來計劃將 sequencer 實現去中心化。



本質上來說,batcher 的任務是將 L2 交易數據提交至 L1。一旦這些交易在 L2 中被處理並生成新狀態,那麼 validator 也必須將該狀態數據提交至 L1。


validator 與 L2 狀態數據


使 validator 提交與存儲 L2 狀態數據的一系列智能合約被稱為 rollup。 rollup 的本質是由不同區塊連接而成的鏈,也就是說 rollup 其實就是 L2。值得注意的是,在 Arbitrum 的代碼庫中會將這些組成鏈的區塊稱為「節點」。為了防止與上面的 validator 與 batcher 混淆,在下面的闡述中會將 rollup 的「節點」用「區塊」表示。

由於單個區塊中包含 L2 狀態數據的哈希值,所以 validator 可以從 sequencer inbox 中讀取數據與處理交易,然後將更新後的 L2 狀態數據哈希提交至 rollup 智能合約,rollup 將會用更新後的數據創建一個新的區塊並添加至鏈中。當 validator 將 L2 狀態數據提交至 rollup 智能合約時,validator 也會明確說明當前鏈中的哪個區塊是新區塊的父區塊。


為懲罰提交無效狀態數據的 validator,流程中引入了質押系統。為了可以向 rollup 提交新的 L2 狀態數據,validator 必須進行質押,他們必須存入一定數量的 ETH(或者根據 rollup 的要求存入其它代幣)。這樣的話,如果惡意 validator 提交了無效的狀態數據,其它 validator 可以對該區塊發起 challenge,惡意 validator 就會失去質押物。


當 validator 成為 staker 後,可以在不同的區塊上進行質押,質押規則如下:


· staker 必須在他們創建的任意區塊中進行質押;


· 多位 staker 可以在同一個區塊上質押;


· staker 不能在兩個不同的區塊路徑上進行質押。當 staker 在新區塊進行質押時,新區塊必須是之前所質押的區塊的子區塊(除非是 staker 第一次質押);


· staker 在新區塊上進行質押時無需增加新的質押物;


· 若某一區塊在 challenge 中失利,那麼所有在該區塊上有過抵押的 staker 或者該區塊的子區塊有過質押的 staker 的都會失去抵押物。


若某一區塊滿足以下所有條件,那麼該區塊則將會永遠被 L1 接收且不會重置:


· 區塊創建時間超過 7 天


· 沒有被其它區塊 challenge


· 至少有一位 staker 在其上進行質押


若某一區塊滿足以下所有條件,可以被銷毀:


· 其父塊比最新確認的區塊存在時間更長(最新確認的區塊在另一分支上)


· 有 staker 在其兄弟區塊上進行質押


· 無 staker 在此區塊質押 ·自區塊創建之日起超過 7 天


validator 的類型


每個 validator 可以使用不同的策略來保證網絡安全。目前網絡中支持三種類型的驗證策略:Defensive、StakeLatest、MakeBlocks(在代碼庫中被稱為 MakeNodes)。 Defensive validator 負責對 rollup 中的區塊進行監控,尋找分叉或衝突的區塊。一旦檢測到分叉,validator 會切換至 StakeLatest 策略。因此,如果沒有存在衝突的區塊,Defensive validator 也不會有任何質押。


如果區塊中包含有效的 L2 狀態數據,StakeLatest validator 會在 rollup 中的現有區塊上進行質押,並且會盡可能會在鏈中最正確的區塊上進行質押。 StakeLatest validator 通常不會創建新區塊,除非識別出包含錯誤狀態數據的區塊。在這種情況下,validator 會創建一個包含正確數據的新區塊並在新區快上進行強制質押。


MakeBlock validator 也會選擇在 rollup 中最正確的區塊上進行質押。但即便是在沒有無效區塊的情況下,MakeBlock validator 若在鏈的末端進行質押時也會創造新的區塊,它們是負責用新的狀態數據推進鏈發展的重要角色。



L1 的交易與狀態數據存儲


交易數據存儲


綜上所述,aggregator 與 sequencer 接收 L2 的交易並將其提交至 L1 的 delayed inbox 與 sequencer inbox 中,將數據提交到 L1 在 L2 的費用佔有很大的比例。 aggregator 接收用戶在 L2 中的交易,將 calldata 壓縮至字節數組,然後將多個壓縮的 calldata 組合成一系列的字節數組(這些數組被稱為批量交易)。最後,aggregator 將批量交易提交至 delayed inbox。 delayed inbox 將批量交易進行散列處理並將哈希保存至合約中。 sequencer 與 aggregator 的工作流程類似,但 sequencer inbox 中還必須包含 delayed inbox 中消息數量的數據。該數據是 sequencer inbox 保存至合約中的最終哈希值的一部分。



狀態數據存儲

MakeBlock validator 從 sequencer inbox 中讀取與處理 L2 交易後,會將更新後的 L2 狀態數據提交至 rollup 智能合約。然後 rollup 智能合約對狀態數據進行散列處理並將哈希保存到合約中。



檢索交易與狀態數據


即便只有交易哈希與狀態數據保存在合約當中,其它節點也可以通過檢索從以太全節點提交至 L1 的數據的交易 calldata 來查看原始數據。發送至 delayed inbox 或 sequencer inbox 的交易 calldata 包含所有經過 aggregator 與 sequencer 批量處理的 L2 交易數據。發送至 rollup 的交易 calldata 中包含了所有與 L2 相關的狀態數據,對於 validator 來說有充足的時間來判斷它們是否有效。為了使查詢交易更加便捷,智能合約會向以太坊日誌發送一個事件,允許任何節點可以檢索 L2 交易數據或狀態數據。


由於智能合約只需在其存儲中保存哈希而非完整的交易或狀態數據,因此節省了大量的 gas。 Rollup 的主要成本來自將此數據存儲至 L1 當中。因此,這種存儲機制可以大幅降低 gas 費用。


Arbitrum 的技術更新與進展


Arbitrum Nitro


Nitro 是對 Arbitrum 的重大升級,在以下幾方面進行了改進:


· 優化 calldata 的壓縮方式:減少發布至 L1 的數據量從而降低在 Arbitrum 的交易成本;


· 將常規執行與錯誤性證明隔離:提高 L1 的節點性能,減少 gas 費用;


· 與以太坊 L1 的 gas 兼容:使 EVM 操作的定價及核算與以太坊完全一致;


· 增加與 L1 的互操作性:如與 L1 區塊編號更加緊密地保持同步,支持對以太坊 L1 進行預編譯;


· 保證 retryable ticket 的安全性:消除無法創建 retryable ticket 的故障模式;


· Geth 追踪:支持更大範圍的調試。


Arbitrum Nova


Nova 是基於 AnyTrust 技術開發的新鏈,與 EVM 完全兼容,通過將數據發送至 DAC(Data Availability Committee)的方式大幅降低成本,只有在 DAC 未能完成處理的情況下才會將退回的數據放到鏈上。 Nova 在處理交易數據的過程中添加了最小的信任假設——假設至少有兩名 DAC 成員是誠實的。它用將數據與 DAC 進行共享的方式來替代由 sequencer 批量處理與發送 calldata 到 L1 的方法。 DAC 為批量交易簽署數據可用性證書(DACerts),只有證書會被發送到 L1,這樣就大幅降低了對 L1 存儲空間的要求。為保證數據的可用性,DAC 負責運行數據可用性服務器(Data Availability Server),開放 REST API 允許通過哈希來獲取數據批次。因此,Nova 是為遊戲、社交以及一些對 gas 成本較為敏感的應用而設計的。


Arbitrum Virtual Machine(AVM)


由於 Arbitrum 的 L2 交易不在 L1 中執行,所以不必遵循與 EVM 完全相同的規則進行計算。因此,Arbitrum 團隊構建了自己的虛擬機 Arbitrum Virtual Machine(AVM)。 AVM 與 EVM 非常相似,目的是支持 EVM 編譯智能合約的兼容性,但也有不同。區別是 AVM 必須支持 Arbitrum 的 challenge。 challenge 要求交易執行的步驟必須是可證明的,所以 AVM 引入了代碼點。當代碼執行時,指令保存在一維數組中,程序計數器指向當前指令。使用程序計數器是為了找出哪一條執行指令需要對數時間,然後其將時間複雜度降低至恆定時間。數組中的每條指令都有代碼點,這樣 AVM 可以立即顯示出在程序計數器上正在執行的指令。代碼點雖然增加了 AVM 的複雜性,但 Arbitrum 系統只有在需要對交易執行進行證明時才會使用。一般情況下還是會使用普通的程序計數器。


ArbOS


ArbOS 是 Arbitrum 的操作系統,負責管理與跟踪代碼執行期間所使用的智能合約資源。 ArbOS 有一個賬戶表,用於跟踪每個賬戶的狀態,還為參與 rollup 協議的 validator 運行資金模型。 AVM 的內置指令提升了 ArbOS 運行及其跟踪資源的性能。 AVM 對 ArbOS 的支持使 ArbOS 可以在 L2 中運行某些規則,不一定非要到 L1 中去執行,因為任何從 L1 到 L2 的計算都會花費大量 gas,這樣可以節省大量成本。


Arbitrum 生態發展數據


協議收入


該數據衡量的是用戶在一段時間內支付總交易費用的美元價值。自 8 月完成 Nitro 升級之後,Arbitrum 的協議收入為升級前的 2 倍,達到 4 萬美元。 10 月末迎來高峰至 7.5 萬美元。目前受宏觀經濟與 FTX 事件影響回落至 3 萬美元左右,下降約 60%。



獨立地址


自主網上線以來,Arbitrum 的獨立地址數增長顯著。進入 10 月日均新增地址為 6000 左右;11 月後日均新增地址突破 1 萬關口,約為 10 月的 2 倍,新增最高點在 10 月 24 日,日均新增為 1.7 萬,且呈持續上升趨勢。



日活躍用戶


9 月至 10 月間,Arbitrum 的活躍用戶數維持在 3 萬左右。進入 10 月後出現爆發式增長,推測主要與搏取空投交互相關。近幾日達到年內高點日活躍用戶數超 6.4 萬。



TVL


進入 9 月 Arbitrum 的 TVL 一直在 9.3 億美金上下浮動,11 月 8 日達階段性高點超 10 億美金。 FTX 事件發生後之後下跌至 8.9 億美金,目前處於回升狀態。



鏈上應用


Arbitrum 生態中 TVL 排名前十的應用分別是:GMX、Stargate、Uniswap V3、Curve、Sushi、Synapse、AAVE V3、Radiant、Vesta Finance、Beefy。值得注意的是,GMX 的 TVL 占前十位應用總 TVL 的 48.73%,達 3.94 億美元。 GMX 是一個現貨與永續合約交易的 DEX 平台,聚焦於衍生品業務,前身為 BSC 上的 Gambit,後遷移至 Arbitrum 同時支持 Avalanche。



跨鏈


目前,使用 Arbitrum 進行跨鏈的用戶約為 45.4 萬人,跨鏈總金額為 19.8 萬枚 ETH(按市價折算約為 2.3 億美元);截止至 11 月 21 日,7 日內存款人數為 2 萬人,7 日內跨鏈總金額接近 2 萬枚 ETH。與其它 L2 協議 Optimism、zkSync、StarkNet 相比,除 Optimism 在 7 日內存款人數為 10 萬之外,其餘三個維度的數據均處於領先位置。



Gas


從 gas 費用來看,Arbitrum 在眾多 L2 協議中轉賬費用排名第三,比以太坊 L1 的轉賬成本低了 93%。 Swap 的費用在 L2 協議中排名第二,比在以太坊 L1 進行 swap 的成本低 96%。 (注:下圖中所顯示的費用是浮動的,但變化幅度相對較小)



NFT


以 Opensea 為例,30 天內 Arbitrum 中排名前 5 的 NFT 總交易額為 1025 ETH,比同為 L2 擴容方案的 Optimism 高出 103%。 NFT 最高地板價格為 0.38 ETH,是 Optimism 生態中 NFT 最高地板價格的 38 倍。



Arbitrum 未來展望


綜上所述,Arbitrum 很好的繼承了以太坊的 DeFi 基因,眾多 DeFi OG 項目遷移至 Arbitrum 進行持續建設,它們的存在為生態帶來了穩定的用戶基礎;Arbitrum 與以太坊 L1 保持高度兼容,支持任何 EVM 語言為開發者帶極大便利,同時可以共享以太坊生態龐大的開發者社區資源;比以太主網低超 90% 的 gas 增加了用戶對鏈上交易的接受度,以上幾方面為孕育 DeFi 創新應用創造了一個包容度很高的環境。其次,為適應遊戲與社交的高頻交互需要 Arbitrum 開發了新鏈 Nova 作為解決方案,與其 DeFi 生態隔離開也是一次不錯的嘗試,不過與 Polygon 目前已經相對成熟的遊戲、社交生態相比還存在一定差距。從這個角度看,未來 Arbitrum 在 DeFi 層面的發展更加值得期待。


*本文以上內容均為觀點闡述,非投資建議。


原文鏈接


歡迎加入律動 BlockBeats 官方社群:

Telegram 訂閱群:https://t.me/theblockbeats

Telegram 交流群:https://t.me/BlockBeats_App

Twitter 官方帳號:https://twitter.com/BlockBeatsAsia

举报 糾錯/舉報
選擇文庫
新增文庫
取消
完成
新增文庫
僅自己可見
公開
保存
糾錯/舉報
提交