應用專用Rollups:在連通性和控制權之間的權衡

应用专用Rollups:在连通性和控制权之间的权衡

兩年前,應用開發者在決定在哪個鏈部署應用程式時面臨的選擇相對簡單:乙太坊、Solana、Cosmos,或許還有一些其他的 Layer 1 鏈。 那時,Rollups 尚未投入運行,很少有人聽說過“模組化棧”這個詞。 這些 L1 鏈之間的差異(輸送量、費用等)非常明顯,也相對容易理解。

今天,情況看起來截然不同。 應用開發者面臨著更多的選擇:L1 鏈、通用性 Rollups(包括 op 和 zk)、先進的 IBC 基礎設施、Rollup 即服務提供者、應用鏈等等。 隨著選擇的增多,問題也隨之增加,包括:

  • 團隊應該部署到通用 Rollup 上還是構建特定於應用的 Rollup?
  • 如果選擇通用 Rollup,那麼選擇哪一個?
  • 如果走應用 Rollup 路線,那麼使用哪個 SDK/Rollup 即服務?
  • 選擇哪個資料可用性層?
  • EigenLayer 是否有説明?
  • 如何考慮序列器?
  • 如果選擇 OP Stack 路線,在 Optimism 的 Superchain 生態系統中是否還會有「彩色寶珠表情」?

這一切都令人不知所措!

為了縮小問題範圍,這篇文章將從已經在乙太坊上部署的應用並希望在乙太坊生態系統內擴展的角度出發。 因此,重點將放在應用團隊在決定是否推出自己的 Rollup 時面臨的決策上,哪些類型的應用特別適合這種基礎設施以及我們何時可能達到採用的臨界點。

一個概覽框架

決定是否使用應用專用 Rollup 的核心實際上是一個簡單的問題:如果應用運行在其自己的鏈上,使用者是否還會使用它?這個問題有兩個子問題:

  • 如果應用執行在其自己的鏈上,使用者是否更可能使用它?
  • 如果應用運行在其自己的鏈上,使用者是否仍然有同樣的可能性使用它?

應用專用 Rollup 的好處源於更大的控制權:能夠抽象化 gas 成本、限制由其他應用活動引起的鏈上擁堵、更好地嘗試如何使用代幣、探索不同的經濟結構(例如,對集成提供 gas 回扣)、構建定製執行環境、實施訪問控制(例如,許可權部署)等等。

但這種增加的控制權是以與更大生態系統的連通性為代價的。 在共用/通用鏈上的應用可以享受到該鏈上已有的流動性(例如,無需額外的鏈間橋接)、與其他應用的可組合性,以及用戶已經專注於該鏈的注意力。 在通用鏈上構建也相對於應用運行其自己的鏈,需要更少的內部開發工作。

如果更大的控制權沒有任何成本,那麼它很可能會增強用戶體驗。 因此,核心問題的答案 —— 如果應用運行在其自己的鏈上,使用者是否還會使用它 —— 真正取決於這種控制權與連通性之間的權衡程度

应用专用Rollups:在连通性和控制权之间的权衡

應用可以承受多大程度的連通性損失?

連通性有幾種形式。 最重要的兩種是:**一是注意力,二是資本。 **

注意力是自帶的一種原生吸引。 如果一個團隊的專案是使用者進入生態系統時首先接觸的東西,那麼就有充分的理由認為該應用具有原生的吸引注意力的能力。 控制注意力的應用更適合推出自己的鏈,無論應用存在於哪個鏈上,用戶都會使用它。 在我看來,目前具有原生吸引力的應用示例包括 Mirror、Zora、Manifold、Sound.xyz 和 OnCyber。 還有一個觀點認為,沒有強大吸引能力的應用可能會選擇推出自己的鏈,作為激發利益的努力(儘管如果許多鏈同時採取這種路線,我認為這種做法不太有說服力)。

“連通性”的第二個組成部分是資本。 通常,使用者為一個應用部署的資金是從同一生態系統內的另一個應用中回收的。 我稱之為“共享流動性”,它的影響是真實的。 我們已經看到新應用選擇一個通用 Rollup 而不是另一個,因為有更多的 ETH 被橋接到那個生態系統。 生態系統內的現有資本可以説明消除使用者採用的障礙(相對於試圖說服使用者橋接到一個新的生態系統)。 這些考慮對於任何將某種形式的金融化嵌入其產品的應用都是相關的。 除了純 DeFi 之外的範例可能包括通過 Mirror 收集 NFT 文章、支付以在 Stealcam 上「偷取」圖片,或任何具有產品內小費功能的應用。

失去這種「資本連通性」意味著應用需要說服使用者將期資產存放在鏈上。 一個原因可能是消費者頻繁使用該應用 —— 橋接是痛苦的,因此最簡單的辦法就是在鏈上保持足夠的資本供應。 但比閑置庫存更有說服力的是為使用者提供產生收益的選項。 這可能看起來像是鏈本地的收益形式,應用構建相鄰的提供收益的產品(例如 Blur 的借貸協定),或其他方式。

以上原因 —— 注意力和資本 —— 也是許多人認為鏈上遊戲是應用專用 Rollup 的理想候選者的原因:它們是相當獨立的經濟體,控制著消費者的心理份額,在順序安排和避免擁堵方面對愉悅的用戶體驗非常重要。 換句話說,鏈上遊戲可以從獨立鏈中受益,即使它們被隔離也不會受到嚴重影響。 其他適合應用 Rollup 的應用可能通過補貼交易最大限度地減少使用者的初始資本需求(例如,前幾筆交易免費)或在引導時不要求支付(例如,使用者生成的鏈上內容、某些社交應用、DePIN 網路等)。

當然,專案希望更多地控制自己的基礎設施還有其他原因。 擁有一個 Rollup 引入了許可部署或實施用戶篩選要求(例如,對鏈擁有/運營的排序器進行 KYC)的能力。 然而,在這些情況下,Rollup 和中心化資料庫之間的界限變得越來越不清晰。

最小化連通性損失

隨著互操作性解決方案的改進,連通性與控制的權衡也變得不那麼嚴重。 橋接和排序器通常是在這一領域討論的關鍵基礎設施。 它們在某種程度上是相似的,因為它們都提供了一種方式,讓一條鏈上的交易影響另一條鏈上的交易。 橋接通過傳遞消息或啟用資產轉移來實現這一點。 共用排序器通過吸收和排序來自多個鏈的交易來實現這一點,創造了一種協調機制,使一個鏈上的行動影響另一個鏈上的行動。 共用排序器和橋接都是原子組合性所必需的 —— 排序器保證了一個區塊中多個(跨域)交易的包含,而橋接通常是執行這些交易所必需的。

Rollup 的單位經濟學是「連通性」影響顯著的另一個領域。 二層(L2)交易費用由兩部分組成: 1) 將 calldata 發佈到 L1 的成本,和 2) 用戶為了被包含而支付的成本。 Rollup 運營商批量處理交易的 calldata,使得發佈成本可以在用戶之間分攤 —— 交易越多,每個使用者的平均成本越低。 這也意味著活動較少的 rollup 可能會延遲將交易發佈到 L1,直到它們有足夠大的批量。 後果是最終確定性時間更慢和用戶體驗更差。 似乎共用排序器越來越多地成為聚合層,其中批量處理來自多個較小 rollup 的交易可以幫助為長尾創建可行的單位經濟學。

我們是否正處於轉捩點?

應用鏈和應用 Rollup 的概念並不新鮮。 然而很長一段時間里,它就像一個在開發中的住宅區:正在建設大量基礎設施,但沒有任何居民。 但在最近幾個月,我們開始看到首批居民慢慢湧入。 Lattice 構建了 OpCraft,一個由其自己的 Rollup 支援的鏈上自治世界。 像 Lit Protocol 和 Synapse 這樣的專案宣佈了他們自己的 Rollup(儘管這兩者都更多地是基礎設施而非應用導向的專案)。 Zora 推出了 Zorachain。 最近與一些成熟應用層團隊,特別是那些考慮他們的二層策略的團隊聊天,我發現他們開始探索應用 Rollup 是否適合他們。

我的假設是,真正的轉捩點將在(至少) 6-12 個月後到來(本文發佈時間為 2023.6.30)。 遊戲和社交應用最明顯地與應用專用 Rollup 相匹配:社交和遊戲都嚴重依賴索引(並且因不必與共享狀態競爭而獲益匪淺),排序在遊戲玩法中尤為重要,定製功能(如無 gas 交易)對於以娛樂為導向的消費產品特別有用。 這些應用團隊中的許多仍在建設中。 特別是遊戲,可能需要數年的時間來完全開發和推出。

我的另一個結論是,對於金融化程度較低的應用來說,擁有注意力是最關鍵的因素。 到目前為止,這篇文章將應用 Rollup 框定為 「每個 Rollup 一個應用」。。 但這種觀點可能過於狹隘。 也許多個應用決定形成一個集體,彙聚他們的“注意力”,並共同推出一條鏈。 同樣,我們可能會看到一個主要應用決定構建自己的鏈,並鼓勵其他應用在其上部署 —— 實際上,利用自己的應用來實踐它想要控制的基礎設施的採用。

最後,我確實相信我們將看到未來有更多的 Rollup 出現。 為應用 Rollup 建設基礎設施服務的專案已經爆炸性增長。 Caldera、Sovereign SDK、Eclipse、Dymension、Conduit、AltLayer 等提供了低門檻的解決方案,供團隊快速啟動自己的 Rollup。 Espresso、Astria 和 Flashbots 的 SUAVE 是排序器領域的早期進入者。 建設成本正在下降,「連通性」權衡的嚴重性也在減少。 這兩點都加強了採用的理由。 但是,大量新的基礎設施供應商的出現也意味著應用團隊可能會花時間瞭解各種選項,並在選擇贏家之前讓這些不同的參與者經受戰鬥的考驗。 因此,雖然跡象指向採用的方向,但我認為真正的轉捩點還有好幾個月的時間。

查看原文
此頁面可能包含第三方內容,僅供參考(非陳述或保證),不應被視為 Gate 認可其觀點表述,也不得被視為財務或專業建議。詳見聲明
  • 讚賞
  • 留言
  • 轉發
  • 分享
留言
0/400
暫無留言
交易,隨時隨地
qrCode
掃碼下載 Gate App
社群列表
繁體中文
  • بالعربية
  • Português (Brasil)
  • 简体中文
  • English
  • Español
  • Français (Afrique)
  • Bahasa Indonesia
  • 日本語
  • Português (Portugal)
  • Русский
  • 繁體中文
  • Українська
  • Tiếng Việt