為什麼開發人員更喜歡 RaaS，而不是使用成熟的 SDK 構建自己的 L3/Rollup ? 本文源自 0xfan 所著文章 《Towards the Multi-rollup Future》，由 Foresight News 編譯、整理。
（前情提要：ZK Rollup的兩個安全性難題：不變性和可升級性 ）
（背景補充：科普｜Rollup分類有幾種？除了Validity、Optimistic之外還有.. ）
TL;DR：
- 一些 Rollup 正在通過提供不同的 SDK 來構建各自的 L2/L3 應用生態系統。然而，採用率的擴張卻並非一帆風順。對此，一種可能的原因是：構建應用程式 Rollup 存在開發摩擦。
- 使用 SDK 構建 Rollup 通常涉及多個階段，這些過程可能會帶來開發摩擦，包括節點服務、安裝除錯、訂製、智慧合約開發和維護。
- 訂製 Rollup（例如整合新的虛擬機器（VM））對於 Rollup 開發團隊來說是一項複雜的工程。它需要全面瞭解每個虛擬機器的工作原理，提取程式碼庫，並將虛擬機器適配到每個 Rollup SDK 提供的各種介面中（例如 Rollkit 的 ABCI 介面）。此外，開發 Rollup 難免遇到各種錯誤和問題，解決這些問題通常耗時費力。
- 構建 Rollup 還需要進行一些權衡，例如平衡去信任性和效率。Rollup 交易的最終性分為三個級別，最終性時間越短，所需的信任級別也就越高。
- 事實上，能夠減輕開發困難並促進相關權衡的中介對於構建應用程式 Rollup 是必不可少的。這正是 RaaS 的用武之地。
- 付費使用的業務模式並不是 RaaS 創造收入的必要條件。不同的策略可能包括提供免費訪問，同時通過捕獲 MEV 和潛在的交易費用來產生收入。另一個可行的選擇是建立一個中央平臺，簡化所有應用程式 Rollup 的橋接、流動性和安全性，從而捕獲其價值。
- 如何識別優質的 RaaS 產品？最關鍵的因素是提供各種虛擬機器的能力。虛擬機器的種類豐富程度比其他服務更重要。在提供任何附加功能之前，RaaS 應優先考慮其作為虛擬機器即服務提供商的角色。
- 此外，具有完善節點和強大節點管理結構的專案也是 RaaS 的可行候選者。例如，Eigenlayer 可能會利用其現有平臺來開發另一種 RaaS 產品。
隨著模組化 Rollup 及其 SDK 的發展，該領域湧現出許多前景廣闊的 Rollup。例如，Optimism 推出了 OP Stack，zkSync 開源了其 zk Stack，Arbitrum 推出了 Abirtrum Nitro，而 Polygon 則開發了以 Rollup 為中心的 2.0 架構。通用區塊空間的可用性不再是主要限制；相反，重點已經轉向便利性和訂製化。
在 上一篇文章 中，我們對現有的 RaaS 專案及其特性進行了比較。然而，還有一個相關的問題仍未得到解答：在每個 Layer 2 網路都有自己的 Layer 3 和 SDK 的多 Rollup 生態系統中，為什麼開發人員更喜歡 RaaS，而不是使用成熟的 SDK 構建自己的 L3/Rollup？
為了回答這個問題，我們可以首先研究一下 Web2 世界，並探討為什麼開發人員可能會選擇 KaaS 而不是自己執行 Kubernetes。
什麼是 Kubernetes 和 Kubernetes 即服務 (KaaS)
容器（Containers）是指一種軟體技術，它支援為部署目的對應用程式進行虛擬打包和隔離。而 Kubernetes（也稱為 K8s）是一個旨在自動化容器化應用程式的部署、擴充套件和管理的開源系統。通過提供一個排程和執行容器的平臺，它為部署流程帶來了結構和組織，同時還自動化了相關的操作職責。
如果比較 KaaS 和 RaaS，我們會發現這樣的關係：
Rollup SDK 和 Kubernetes Cluster 有一個共同點，即兩者都是完全開源且免費使用，它們不太可能在 SDK 層面收取費用。最初，Google 團隊提出將 Kubernetes 作為免費服務，但後來成為第一個提供 KaaS 作為創收服務的團隊。
雖然 Kubernetes 本身是開源且免費的，但管理 Kubernetes 叢集的每個組織都必須承擔一定職責：
- 為團隊提供技術培訓（原因是 Kubernetes 的學習曲線陡峭）；
- 管理和升級多個版本的 Kubernetes；
- 處理 Kubernetes 系統的安裝和升級；
- 在叢集上部署應用程式；
- 管理擴容性和叢集配置；
- 確保叢集配置安全，以防止未經授權的訪問或資料洩露；
此外，管理不同的叢集可能也具有挑戰性，因為它需要一個人跨不同叢集處理各種任務。
當企業考慮戰略實施時，他們最初的目標是自行管理。然而，他們可能很快就會意識到管理多個叢集同時確保每個叢集的穩定性並不容易。自行管理不僅無法為他們提供競爭優勢，而且供應商也可能比他們更擅長管理。
而且，Kubernetes 通過 Pod 執行，Pod 包含支援容器應用程式或多個容器所需的所有儲存資源，以及唯一的網路 IP 和操作設定。然而，Pod 的使用壽命有限，這給使用 Kubernetes 的開發運營團隊帶來了獨特的挑戰。關鍵問題是如何保持必要的「後端」Pod 的穩定性，以確保其相應的「前端」Pod 繼續正常執行。
這就是 KaaS 發揮作用的地方。
同樣，在 Rollup 的世界中，當存在有價值的、免費的 Rollup SDK 時，為什麼我們還需要 RaaS？
使用 Rollup SDK（例如 Rollkit）啟動 Rollup 需要什麼？
以 Celestia 的 Rollkit 為例，要利用 Rollup SDK 並啟動一個新的 Rollup，必須至少完成以下步驟：
節點服務
Rollup 由節點執行。如今，除了在本地執行 Rollup 之外，使用雲端服務進行節點運營是非常普遍的。使用雲端服務進行節點運營可能會產生固定成本。在 KaaS 領域，提供最有效節點服務的 AWS、Google Cloud 等成為了 KaaS 服務提供商。
目前，Vistara Labs 等 RaaS 團隊利用雲端服務為其 RaaS 產品啟動 Kubernetes 叢集。最終，網路參與者有責任確保模組化 Rollup 節點的可靠執行。
安裝除錯
開發人員在啟動 Rollup 時可能會遇到一些問題或錯誤。
例如，當使用 Rollkit 啟動本地 Rollup 時，解決大量錯誤和問題可能會消耗啟動普通 Rollup 所需時間的大約 80%。這是因為，儘管 SDK 提供了操作 Rollup 的抽象方法，但設定環境和依賴項、執行 bash 指令碼以及與 RPC API 互動等任務必須獨立處理，這增加了過程的複雜性。
訂製化
當開發人員打算自定義網路時，他們不能僅僅使用程式碼庫中提供的模板。他們必須理解 SDK 的底層邏輯，這可能有一個陡峭的學習曲線。此外，每個 SDK 都有不同的邏輯和程式語言；例如，Arbitrum Nitro 使用 Go 和 Rust，而 Op Stack 使用 Go 和 Solidity。
在虛擬機器方面，分叉現有專案是不夠的。那些希望將虛擬機器合併到 SDK 中的人必須瞭解每個 VM 的執行方式，提取 VM 初始化和伺服器程式碼庫，然後將 VM 包裝到每個 SDK 提供的不同介面中，例如 Rollkit 的 ABCI 介面和 OP Stack 的 Engine API。因此，將各種虛擬機器與每個 SDK 整合將帶來複雜的組合問題（SDK ↔ 虛擬機器），需要大量的資源、時間和人員。藉助中介來處理這個問題而不是要求開發人員自己做是合理的。
此外，不同型別的 Rollup 設計了不同的 SDK。例如，Sovereign SDK 針對主權 Rollup 進行了優化，而 OP Stack 主要用於智慧合約 Rollup。由於每種型別的 Rollup 都有其獨特性和缺點，因此為開發人員提供一系列可供選擇的 SDK 選項比讓一個 SDK 相容各種型別的 Rollup 更為明智。
智慧合約開發
雖然特定的應用程式 Rollup 可能需要它，但對於建立通用 Rollup 的開發人員來說可能不是必需的。
版本控制
在 KaaS 領域，版本控制對於開發人員來說至關重要。KaaS 有助於管理各種 Kubernetes 版本，實現現有 Kubernetes 工作負載的遷移而不會出現相容性問題。
在 RaaS 領域，如果 Rollup SDK 具有較新的版本，則更新和遷移所有智慧合約或 Rollup 本身可能會具有挑戰性。對於那些使用 SDK 構建彙總的人來說，管理、修補和更新彙總會很複雜。
安全
RaaS 能夠使用預先建立的安全最佳實踐來部署 Rollup。在沒有徹底瞭解程式碼庫的情況下修改 Rollup 可能會導致新的錯誤或問題，從而給使用者和資金帶來風險。
Rollup 訂製的進一步思考
即使在比較 Optimism、Starknet 和 Arbitrum 當前提供的 L3 解決方案時，開發人員也必須選擇或設計某些功能。
排序方案。 排序方案需要進行訂製或調整，以滿足應用程式 Rollup 開發人員的需求。這可能包括 FCFS、PGA 或更復雜的方案，例如已被 Sui 和 Aptos 使用的 Narwhall & Bullshark 或 Hotstuff。開發者可能會選擇第三方提供商（例如共享排序器）來處理此問題，因為獨立管理仍然具有挑戰性。
最終性和去信任性之間的權衡。 zk Rollup 和 Optimistic Rollup 都具有不同程度的最終性。一般來說，最終確定性有三種類型：預確認、軟最終確定性和硬最終確定性。軟最終性取決於對 L1 驗證器者 L2 執行者的信任（例如，Optimistic Rollup 的挑戰者和 zk Rollup 的證明者 / 驗證者），並且最終性時間由排序器批處理時間和 L1 最終性時間確定。相比之下，硬最終性對於 Optimistic Rollup 而言是在 Rollup 交易最終在基礎層上結算之後實現的，並且只需要信任 L2 執行者。對於 zk Rollup，當證明得到驗證時就達到了硬最終性。
共享執行者和自運執行者之間的權衡。 執行者負責執行交易並更新鏈下資料庫，而排序器負責對交易進行排序並將其提交到基礎層。
這個角色有靈活性的設計空間。專用的執行者可以提供更好、更個性化的效能，但這需要應用程式 Rollup 開發人員付出巨大的努力，並且對硬體要求很高。例如，渴望高效能的 GameFi 可能更喜歡擁有專用的執行者。或者，為了方便起見，可以選擇使用基礎層作為執行者。
此外，擁有共享執行者集的 Rollup 之間可以進行原子交易，這可能是一個顯著的優勢。
去中心化和成本之間的權衡。 Web2 遊戲公司可能不會優先考慮 Rollup 的去中心化。 遊戲工作室本身是中心化的，他們簽署希望釋出到鏈上的資料，充當預言機。因此，他們可能不關心 資料可用性層和排序器的去中心化。 對他們而言，DAC 或中心化 DA 節點會更合適，而且更加便宜。
因此，能夠代表使用者處理所有這些功能和流程的中介至關重要，例如包裝到各種 SDK 中的虛擬機器、版本控制、多種 Rollup 型別以及 MEV 保護等增值功能。此外，開發 Rollup 還涉及各種權衡。像 RaaS 這樣的解決方案提供商可以幫助您就這些權衡做出更好的決策。
然而，即使在 KaaS 領域，35% 的開發人員也選擇在內部構建自己的 Kubernetes，而不是使用 KaaS。這主要是由於敏感的資料安全問題或具有挑戰性的本地依賴關係導致，特別是對於艾瑪迪斯和彭博這些大型複雜組織而言。這同樣適用於 RaaS 世界，出於隱私考慮，開發人員可能不會選擇使用 RaaS。
因此，RaaS 通常作為中介來處理開發人員可能難以自行完成的任務。但問題是，誰將成為 RaaS 的贏家？
RaaS 如何創造價值？
除了傳統的訂閱模式之外，還有三種潛在的方式來產生價值：
付費訂閱。 使用者可以通過向 RaaS 支付代幣來建立新的 Rollup。這被認為是最糟糕的商業模式，因為它可能會導致價格戰。
驗證者質押代幣以賺取交易費、MEV 和獎勵。 驗證者，例如 Rollup 排序器和執行者，必須抵押代幣才能發揮作用。RaaS 還可以接收一部分 L1 型別費用（例如 MEV、交易費用、獎勵）作為收入。Eigenlayer 和 Vistara Labs 已採用這種方法。
為所有應用程式 Rollup 構建中心。 為其原生代幣開發中心鏈可以幫助積累價值，因為它充當橋樑、流動性和安全中心。這是 RaaS 生態系統使用的常見方法，其中包括 Optimism、Arbitrum、Polygon 2.0、Eclipse 等。
在我看來，質押代幣和建立中心並不排斥，同時實施兩者可以產生更多價值。
然而，當應用程式 Rollup 得到廣泛採用時，它可能不願意與中心或驗證者分享其部分價值。在這種情況下，推出自己的鏈來捕獲所有價值（類似於 dYdX 所做的），仍然是一種可能性。
RaaS 的主要特點是什麼？
讓我們先看一下 KaaS，它對開發人員最有吸引力的功能是什麼？
EKS 的成功仍然依賴於亞馬遜雲端服務，因為亞馬遜目前在全球雲端服務商市場佔據主導地位。因此，亞馬遜雲端服務的使用者可能會發現選擇 EKS 作為他們的 KaaS 服務，可以獲得對亞馬遜架構的最佳支援。
EKS 允許自帶作業系統選項，幾乎可以使用任何作業系統，而 GKE 在這方面有更多限制。
雖然 EKS 在配置叢集時提供了高度的靈活性，但這也意味著開發人員必須承擔管理負擔。例如，雖然 EKS 支援 Calico CNI 的網路策略，但使用者需要手動安裝和升級。
首先，Google Kubernetes Engine 是一個更好的產品。它始終比市場上的任何競爭對手（包括 EKS）擁有更多的功能。
在功能、支援和易用性方面， GKE 無疑仍然是託管 Kubernetes 的王者。GKE 也是唯一提供完全自動化的主節點和節點升級過程的服務。
總之，EKS 廣泛的客戶群歸功於亞馬遜的雲端服務，它為作業系統和安全性提供了更大程度的訂製。然而，這會導致便利性和自動化之間的權衡。
GKS 提供了最多的功能，並支援降低開發者的使用門檻。然而，它在一定程度上損害了作業系統的安全性和訂製性。
把這個結論放到 RaaS 生態中。
最關鍵的因素是提供商提供各種虛擬機器 (VM) 的能力，更多種類的虛擬機器比其他服務更重要。在提供任何附加功能之前，RaaS 應優先考慮其作為虛擬機器即服務提供商的角色。
具有完善的節點和強大的節點管理結構的專案是 RaaS 的可行候選者。例如，Eigenlayer 可能會利用其現有平臺來開發另一種 RaaS 產品。
確保節點 / 排序器的安全性至關重要且不能受到損害。
現有的 L2 解決方案如何？
Optimism
OP Stack 可供其他人使用，而無需成為 Optimism 的 L3。OP Stack 的收入模式與 Cosmos Hub 類似，與 Optimism 連線的 L3 越多，OP 可以捕獲的價值就越多。如果基於 OP Stack 的 Rollup 選擇不連線到 Optimism，則 OP 將不會捕獲任何值。
例如，opBNB 使用 OP Stack 進行構建，但不使用 Optimism 的排序器，也不與 OP DAO/ 基金會共享交易費用，所有的價值都將被他們自己的專案所捕獲。相比之下，Base 鏈會將一部分交易費用給予 OP，以獎勵 OP 生態中的公共產品，但這不是強制性的。
延伸閱讀：解析Optimism當前現況：生態發展與OP Stack的未來
Arbitrum
為了充分放大 ARB 的價值，必須注意 Arbitrum Orbit 許可證不會自動包含與非 Arbitrum-DAO 管理的鏈相關的鏈。開發人員只能使用 Nitro 在 Arbitrum 鏈之上構建 L3。如果他們想建立一個直接結算到以太坊的 L2，他們必須獲得 Artbitrum DAO 的同意。
值得注意的是，Nitro 僅用於與 EVM 相容的 Rollup。那些想要嘗試與 EVM 不相容的 ZKVM 的人不得不使用 RaaS。
Starknet
Starknet 提出了多 Rollup 宇宙的路線圖。雖然 StarkEx 目前以 L2 解決方案為客戶服務，但會移植到 L3 以進一步降低成本。
除了 StarkEx 之外，構建在 Starknet 之上的特定應用程式的 L3 也會有一席之地。它可以實現比 StarkEx 服務更高級別的訂製和主權。Stakrware 團隊通過構建 Madara 排序器來處理此功能，該排序器允許任何人啟動自己的 Starknet 應用鏈。使用者可以利用 Cairo 的功能，同時保持對自定義應用程式鏈的完全控制。
Madara 基於 Substrate，使用 Cairo VM 來執行 Cairo 程式和 Starknet 智慧合約。在 Kakarot 的幫助下，使用者可以構建 zkEVM Rollup。最終，證明者或證明者市場可以監聽鏈產生的區塊並生成證明。因此，從技術上講，Madara 可以解決任何 L1/L2 問題。
zkSync
zkSync 最近推出了構建獨立零知識鏈的框架。但 ZK Stack 並不適合所有人。如果建立一個通用的 DeFi DApp 或 NFT 專案，將其部署在現有的超鏈（例如 zkSync Era）上將是一個更簡單的方案。
ZK Stack 專注於跨鏈通訊過程，實現共享證明者來聚合不同超鏈的證明。這允許跨鏈訊息的快速確定。生態系統中的超鏈越多，ZkSync Era 捕獲的價值就越少。
延伸閱讀：Matter Labs再釋出ZK Stack，模組化野心鎖定「L2+L3」
Polygon 2.0
Polygon 2.0 的目標是從發散階段過渡到收斂階段，所有 Polygon 鏈將在同一架構下執行。這將包括一個質押層，供驗證者質押 Polygon 的原生代幣併為 Rollup 提供服務。此外，還將有一個統一的互操作層來聚合 zk 證明並促進跨鏈通訊。隨著 Polygon 鏈上活動的增加，Polygon 原生代幣的價值也會增加。
總結
開發應用程式 Rollup 必然會遇到開發摩擦和做出權衡選擇。因此，能夠代表使用者管理所有這些功能和流程的中介機構至關重要。這包括包含在各種 SDK 中的虛擬機器、版本控制、多種 Rollup 型別以及 MEV 保護等增值功能。此外，對於這個中介來說，在構建應用程式 Rollup 時協助做出更好的權衡決策是有益的。到目前為止，RaaS 能夠勝任這一角色。在評估良好的 RaaS 時，所提供的虛擬機器 (VM) 多樣性比其他服務更為重要。在提供任何附加功能之前，RaaS 應優先考慮其作為虛擬機器即服務提供商的角色。
