首頁

深入RaaS：Rollup服務模式與獲利方式一覽

閱讀本文需 18 分鐘

RaaS 提供者銷售的產品是什麼，它們如何區分彼此，如何獲利，並分享我們對 RaaS 業務的一些內部觀點。

原文標題：《RaaS: The Key Ingredient to a Rollup-Centric Roadmap》

原文作者：Myles O'Neil

原文來源：TechFlow深潮

介紹

我們一直密切關注的一類公司是Rollup-as-a-Service 提供者（ “RaaS”）。簡單來說，RaaS 供應商透過銷售「現成」的產品（如排序、索引和分析）來幫助應用程式開發者盡快啟動 Rollup。

在本文，我們將快速概述 RaaS 提供者銷售的產品，它們如何區分彼此，如何獲利，並分享一些我們對 RaaS 業務的內部觀點。

RaaS 服務/產品提供

雖然RaaS 服務/產品提供仍處於初級階段，但我們注意到大多數RaaS 供應商銷售類似的一攬子服務和產品。透過與 RaaS 創辦人的交談，我了解到這個一攬子服務大致如下。

服務

與傳統B2B 公司使用的劇本類似，RaaS 提供者通常從銷售服務開始（附註：令人驚訝的是，傳統的「服務轉產品」策略在加密貨幣領域非常有效）。

作為服務提供的一部分，RaaS 提供者通常充當技術顧問的角色，幫助您評估Rollup 堆疊（例如OP Stack、Arbitrum Orbit）並決定哪個堆疊最適合您的應用。

這項服務非常有價值，所以值得詳細介紹。 RaaS 供應商的主要客戶是希望在自己的專用 Rollup 上啟動應用程式的新創公司。對他們來說，最重要的是建立應用程式並增加用戶數量，花費數月的開發時間來熟悉 Rollup 框架並不是他們想要花時間的事情，也不應該花時間。由於 RaaS 提供者的整個業務都基於對 Rollup 框架的理解以及圍繞它們建立開發者工具，他們完全有能力幫助新創公司評估可用的框架選項。

例如，他們可以幫助新創公司回答以下問題：不同框架和 DA 層之間的權衡是什麼？是否有客製化的內容可以改進 Rollup 的應用程式？增加客製化的權衡（例如整合的複雜性增加）是什麼？透過根據與實際客戶的經驗提供指導，可以為應用程式團隊節省數月的開發時間。

基礎設施產品

排序器：運行排序器是一項高風險的工作——如果排序器出現問題，您的Rollup 將無法使用，使用戶非常不滿意。 RaaS 供應商透過冗餘措施提供高可靠性的託管排序服務。如果您的排序器出現問題，他們可以確保有一個快速的故障轉移過程，以便您的 Rollup 可以繼續運行，最小化停機時間。此外，您還需要支付第 1 層的 DA 成本，而抵銷的排序器費用會在您的 Rollup 上累積。對於以太坊上的智能合約 Rollup，7 天的提款期意味著您始終需要至少一周的 ETH 來支付 DA 成本。 RaaS 提供者可以協助您管理這些複雜性，有些甚至會為您在第 1 層上提供 DA 成本所需的流動性。

RPC：不可靠的 RPC 端點也會導致使用者體驗差，就像我們在 Optimism 和 Arbitrum 的空投中看到的那樣。如果使用者透過您的 RPC 節點進行交易、大型查詢或合約調用，RaaS 提供者可以確保自動啟動新節點以滿足需求。

開發者工具

內部工具：由於RaaS 客戶既是Rollup 的經營者又是應用程式的營運商，因此他們能夠存取安全基礎設施，幫助他們保護用於實施軟體升級的多重簽名金鑰。一些提供者還提供控制面板，用於查看分析、活動監控和警報，以便在出現問題時通知您。

其他工具：很難在這個類別中涵蓋所有內容，但至少，Rollup 運營商需要數據索引工具來查詢鏈上信息，標準化接口來執行諸如代幣鑄造和銷毀或其他交易的操作，並能夠訪問離線預言機。

使用者介面工具：至少，Rollup 用戶將需要一種與您的Rollup 橋接的方式，多種錢包選項（包括帳戶抽象基礎設施）以及與第1 層應用程式相符的區塊鏈瀏覽器。

RaaS GTM 策略

目前市場上至少有六家RaaS 供應商，可以說它們都在爭奪新創公司（在很大程度上）。我們觀察到 RaaS 提供者通常採用三種 GTM 方法來區分他們的產品。

垂直整合（例如Eclipse）

Rollup 框架和RaaS 銷售相關且緊密耦合的產品，因此垂直整合是自然的選擇。除了經濟激勵之外，RaaS 營運商和框架之間還有戰略原因追求垂直整合的產品。

從框架的角度來看，RaaS 產品可以使其更接近客戶。透過這種接近，他們可以創建一個更緊密的回饋循環，以指導產品決策。甚至可能有意將 RaaS 支援擴展到第三方框架，並引入最佳組件來提供產品。

與任何新興和高度競爭的技術類別類似，Rollup 框架面臨的一個重大挑戰是找到一種不會阻礙採用的獲利策略。 RaaS 產品是實現這兩個目標最直接的方式。 RaaS 解決方案可以透過解決重要的痛點來促進框架的採用。同時，RaaS 的選擇性使您可以以不給選擇自己經營 Rollup 的客戶增加任何負擔的方式實現盈利。

這種方法的主要挑戰是資源限制。與建立 Rollup 框架並行建立 RaaS 業務可能會超出您的能力範圍。

與框架合作（例如Conduit）

與特定框架（如OP 或Arbitrum）合作的RaaS 提供者將自己與該框架綁定。透過與現有框架對齊，RaaS 供應商可以獲得巨大的分銷優勢。

例如，透過與 Optimism 合作，Conduit 能夠借助 Optimism 的品牌成為選擇 Optimism 作為框架的新創公司的預設選項。其他提供者（如 Slush）正在與新興的 Rollup 框架（如 Starknet）對齊，以在另一個生態系統中獲得分銷優勢。

除了提高分銷能力，這種方法還允許您將所有資源投入到建立一個真正優秀的產品上。考慮最近的一個案例研究，Aevo 將其 RaaS 解決方案切換到 Conduit。他們之所以這樣做，是因為 Conduit 正在運行最新版本的 Optimism，這極大地改進了他們的產品。透過專注於單一框架，Conduit 可以確保客戶始終在最新版本的程式碼庫上運作。

缺點是單一框架不太可能支援所有用例，因此您可能會在某種程度上限制市場（至少在擴展以支援其他框架之前）。

與框架無關（例如Caldera）

與框架無關的RaaS 提供者支援各種Rollup 框架（如OP、Arbitrum）的RaaS 產品和服務。

如果一個與框架無關的提供者能夠成為新創公司的第一個接觸點，您可以看到底層框架可能只是促進各種用例的技術選擇，而不是品牌對齊的訊號。

與框架無關的方法允許 RaaS 提供者在入職過程中為客戶提供更多選擇。透過在生產中運行多個框架，他們可以看到哪些組件最有價值，並將這些經驗教訓納入向新客戶提供的指導中。

與垂直整合法類似，此方法的挑戰主要與資源限制有關。每個框架都需要大量投資來支持，試圖支持過多的框架可能會導致不成熟的產品。

RaaS 商業模式

目前看來，RaaS 供應商有兩個收入來源：（i）排序費用和（ii）基礎設施和工具。根據我們的觀察，服務組件通常是免費提供的。

排序費用

RaaS 提供者運行排序器，為應用程式排序交易。作為回報，他們收取一定的費用。

我們看到RaaS 提供者收取排序費用的兩種方式：一種是收取收入份額，應用程式與交易費用的最終用戶支付的收入分享一定比例；另一種是收取簡單的按月SaaS 費用，用於託管排序器。

費用動態是一個有趣的問題，讓我們簡單談談這一點。對於 RaaS 提供者來說，運行排序器有固定成本和隨交易數量變化的可變成本。如同上面提到的，一些提供者也承擔了代表其客戶在以太坊上提供 DA 成本的風險。在理想情況下，作為 RaaS 供應商，您可以同時收取每月 SaaS 費用以支付固定營運成本，並收取收入份額以支付可變成本，並從正在快速增長的應用程式中獲得收益。後者非常重要——如果您無法從客戶的成長中獲得收益，營運排序器產品的經濟效益就不會很好。如果您有資本，那麼為了代表客戶提供這些 DA 成本，可以更輕鬆地證明這種收入分享組件的合理性。

然而，RaaS 提供者是否能夠在穩定狀態下收取收入份額將取決於應用程式對 RaaS 提供者的定價影響力。目前來看，還為時過早，無法確定誰擁有定價影響力。（如果非要說，類似於支付行業的運作方式，我們的感覺是大型應用程式將對 RaaS 提供者俱有定價影響力，而小型應用程式則沒有）。

基礎設施、工具和其他

RaaS 供應商可以為各種關鍵基礎設施服務收取SaaS 費用。透過擁有客戶關係，他們比現有提供者更有優勢，可以捕捉到最高價值的服務，並提供捆綁銷售折扣（例如，使用我們的RPC 服務而不是Alchemy 的服務，我們將為您提供其他服務的折扣）。此外，RaaS 提供者可能比現有提供者俱有成本優勢，因為他們的架構使他們能夠輕鬆地擴展支援新的鏈。

由於資源限制，RaaS 供應商通常需要與外部公司合作，以滿足其客戶的所有需求。例如，Conduit 最近推出了其整合計劃，Caldera 也宣布了許多類似的合作夥伴關係。作為這些合作夥伴的通路，RaaS 的位置非常適合建立一個市場或轉售商業模式，非常類似於 AWS 及其第三方「外掛程式」。

其他想法

有幾個我想討論但不適合放在前面章節的事情，所以我決定把它們都放在這個抓包部分。

RaaS 與框架

雖然RaaS 提供者和框架目前在相對友好的關係上，但我認為它們將不可避免地進行競爭，特別是為了佔領排序市場。如果競爭加劇，我認為 RaaS 提供者最有可能從中受益。以下是一些原因：

正如我們已經開始看到的，大多數這些新創公司直接轉向 RaaS 供應商外包部署 Rollup 的複雜性。如果這種情況持續下去，RaaS 供應商將擁有頂部的銷售管道，因此也擁有客戶關係。如果事情確實發展成這樣，RaaS 提供者可能會將底層框架僅視為促進各種用例的技術選擇。

然而，框架也有可能反擊 RaaS 提供者。在這方面，以下是我們討論的一些問題：

框架是否能夠向應用程式收費使用其框架？（雖然框架採用的網路效應非常強大，但我認為僅僅依靠框架本身很難實現盈利。不過，這仍然是一個有趣的問題值得思考）。

RaaS 供應商支援的每個框架都需要他們投入大量資源（主要是開發時間）。在這一點上，一個 RaaS 提供者不太可能能夠支援市場上的每個框架並為其設計客製化產品。那麼，框架是否可以透過提供解決其堆疊獨特痛點的關鍵服務來與 RaaS 提供者競爭？例如，ZK Rollup 框架可以透過聚合來自 Rollup 的需求並路由到一組證明系統和營運商的方式，為證明提供更好的定價。

跨Rollup 的MEV

目前的共識認為，Rollup 將具有可觀的MEV，而跨Rollup 的MEV 將成為一個蜜罐。基於這個假設，大多數人認為共享排序器最有可能捕捉這個價值。我認為這個假設仍然是一個非常開放的問題，我甚至會對這個假設的結果提出質疑。

如果跨鏈MEV 確實成為市場的重要組成部分，RaaS 提供者將不得不決定是與共享排序器合作夥伴進行整合，還是推出自己的共用排序器產品。讓我們假設一下，將來RaaS 提供者將為大多數新的Rollup 運行排序器，而這項服務將佔據他們收入的大部分（並且還提供了使用其服務的每個Rollup 的記憶體池的視圖）。在那種情況下，我認為 RaaS 供應商更有可能推出自己的共享排序器產品，而不是與外部供應商合作。

此外，RaaS 提供者可以利用他們對所有這些記憶體池的觀察，提供訂單流程拍賣，並利用他們對排序器的控制權，為結算提供區塊頂部拍賣。這將使搜尋者能夠查看有價值的交易、填充它們，並同時在支援的鏈上結算。