深入解析Based Booster Rollup：背景、實踐與展望

原文作者：jolestar（X： @jolestar ）

看到幾位朋友在聊Based Rollup，大多是從安全角度來聊，我從L1 與L2 的關係，以及應用程式的建置角度，聊聊對Based Booster Rollup 的看法。

Based Rollup 的想法其實很簡單，就是用戶直接把L2 的交易提交到L1，由L1 排序打包，但L1 不校驗交易的有效性，只保證交易的順序以及可用性，而L2 是個純粹的執行器，執行打包在L1 上的L2 交易。看到這裡大家是不是覺得很眼熟？這不就是銘文(Inscription) 模式麼。是的，銘文的Indexer 就可以理解成這裡的L2。這個我觀點我在《銘文是個bug 還是feature》一文裡說過。

Booster Rollup 則從另一個角度出發，如何在L2 上透過合約直接讀取到L1 的狀態？想法其實也不複雜，既然Based Rollup 已經在執行L1 上的L2 交易了，那要不順便把L1 的交易也執行一下呢？這樣L1 和L2 的狀態就在一個大的狀態樹裡，L2 的合約就可以直接讀取L1 的狀態了。

於是也有專案把Based Rollup 和Booster Rollup 合在一起，叫做Based Booster Rollup(BBR)，例如taiko。

BBR 的背景

BBR 從提出，到現在受到市場關注，主要的大背景是當前Ethereum 主流的L2 方案帶來的割裂問題，L1 與L2 的割裂，以及L2 之間的割裂。現在的L2 方案，提供的功能，無論從開發者角度，還是用戶角度，和一個Alt-L1 並沒有太大的差異，讀取L1 資料還依賴Oracle，資產還是要橋，錢包也得切換網路。而這種割裂也帶來了另外一個問題，L1 和L2 的綁定並沒有那麼緊密，L2 隨時可以增加一套共識機制變成一條Alt-L1，“自立為王”，並且可以讓開發者和使用者基本無感。目前主要的綁定關係來自於EF 對正統性的約束： L2 必須將L1 作為DA，但明顯這個約束並不牢靠。

那如果把現在的L2 方案都換成Based Rollup 方案問題是不是就解決了呢？估計Optimism 和Arbitrum 要跳出來說了，換Based Rollup 不很容易麼？現在主要的L2 方案都有Force Inclusion 機制，L2 直接把Sequencer 給去掉， 讓用戶都透過Force Inclusion 向L1 發交易不就實現了Based Rollup？

但這能解決割裂問題嗎？不能。雖然Arb 和Op 都即時把交易提交到L1，由L1 打包排序了，但它們還是割裂的，因為各自只認自己的交易。到這裡大家應該明白Based Rollup 要想解決割裂問題的關鍵是要有可以在L2 之間共享的交易或數據，而這種數據格式要求：

• 它必須是和平台和實現無關的，在L1 上定義的格式。不同的L2 的帳戶，虛擬機器有差異，各自的交易肯定沒辦法直接共用。

• 它需要在L2 之間達成共識，多個L2 都支持。

所以它必須是協議先行，先設計公開的協議和數據格式，鏈上只保存協議必須的數據，執行和校驗在鏈下，不同的L2 各自實現支持方案。但要做到這兩點其實挺難，首先Ethereum 生態的開發者一般透過智能合約設計協議，並沒有直接基於數據格式設計協議的習慣。這個方向主要的嘗試還是上次銘文熱的時候的Ethscriptions。而第二點就更難了，需要實踐和時間來驗證。

從BBR 到BBSR，Stackable L2

說完了資料共享的問題，再說說使用者體驗的問題。明顯如果所有交易都由使用者直接發給L1，體驗就和使用L1 差不多，無論是Gas 還是確認時間。於是開始有人設計Based Rollup 的預確認協議了，但如果預確認協議能真正運作，需要所有的交易都先通過預先確認協議，那不就是Sequencer 了麼？這部白折騰聊一圈麼？

之所以會產生這種矛盾是因為大家混淆了幾種交易類型：

1. 用戶直接提交到L1 並由L1 執行和驗證的交易，也就是L1 交易。

2. 使用者直接提交到L1，但L1 不直接驗證執行，L2 之間共享協議的資料交易，可以叫L1.5 交易。

3. 用戶直接提交給L2 Sequencer，由Sequencer 預先確認並執行的交易，某個L2 的專用交易。

而Based Rollup 只和1 ， 2 有關係， 3 是現在的Sequencer Rollup 的工作方式，二者完全可以結合。

假如有這樣一個Rollup 方案：

1. Sequencer 會自動同步所有的L1（包括L1.5） 交易，並按照L1 的給定的順序執行。

2. Sequencer 同時接收L2 交易，和L1 交易混在一起排序並執行。

透過1 ， 它實現了Based 和Booster，透過2 它實現了L2 交易的快速確認，也不損失用戶體驗。如果按照前面的命名方案，這種應該叫做BBSR(Based Booster Sequencer Rollup)，但有點長，不容易理解，所以我把它叫做Stackable L2，堆疊式L2，顧名思義就是在L1 上堆疊了L2，L2 包含了L1 的所有交易和狀態。這就是@RoochNetwork的解決方案。

如何保證L2 的交易的DA？ Rollup or Rollout?

如果採用上面的方案，L2 再次把自己的交易打包提交到L1 就會有點奇怪，因為L2 會再次把打包自己交易的L1 交易也讀取下來重新執行，有點像自己的輸出同時也成了自己的輸入。所以Rooch 的方案是Rollout 而不是Rollup。因為長遠來看L1 的區塊空間非常珍貴，多個L2 的交易搶佔L1 的空間是一種「內捲」模式，L1 的空間應該留給L1 和L1.5 交易，L2 應用層級的交易應該尋求更低廉的區塊空間，透過「外卷」拓展新的區塊空間，這樣也有利於整個產業生態的發展。

Bitcoin 生態的BBSR/Stackable L2 實踐

前面的描述都是從Ethereum 角度來描述，而Rooch 作為Bitcoin 的首個BBSR 或Stackable L2 實踐，這裡聊聊Bitcoin 生態上的差異。

Bitcoin L2 上沒有圖靈完備的智能合約，Based Rollup 模式下反轉成為一種優勢。因為Based Rollup 本來就不需要L1 來執行和驗證交易，只要保證Permission Less 以及DA。這同時也逼迫Bitcoin 生態的專案從很早以前就開始設計基於資料結構的協議，無論是染色幣，還是後來的RGB，Taproot Assets，Ordinals Inscription，Atomicals，Runs 等，都是這個範疇下的嘗試，可以包含在廣義的CSV（Client-side Validation）協議概念下，它們的交易都是典型的L1.5 交易。如果Ethereum 生態的專案想實踐Based L2，設計出多個L2 之間共享的協議，大體上會和上面的協議差不多。

以下以Rooch 為例，說明Bitcoin 上的BBSR 的工作模式：

1. 使用者會直接提交L1 以及L1.5 交易給Bitcoin，因為協議是公開的，所以入口可以是任何應用。

2. Rooch 會同步所有的L1 交易，處理其中的UTXO，同時會發現是否攜帶了額外的協議訊息，然後用對應的Move 模組去處理。例如被辨識為Inscription 的交易會由ord 模組處理，而Babylon Staking 的交易會由bbn 模組處理。

3. 使用者直接將L2 交易提交給Rooch 的Sequencer 節點處理。上面三種交易的執行結果會產生一個完整的狀態樹，應用合約可以充分利用到L1 以及L1.5 交易產生的狀態。

這種模式下的應用可以設計兩種交易，一種是公共協議交易（Based 部分，在L1 上），一種是應用交易，（由Sequencer 排序），二者可以透過Booster 模式互相配合，保證Permission Less 的同時，也能確保使用者體驗。

如同前面所提到的，公共協議的設計需要時間和實踐來驗證以及達成共識，而Rooch 能提供的是這樣一個方便的試驗環境：如果想設計一個新的Bitcoin 上的應用或資產協議，只需要定義好協議格式，然後部署對應的Move 合約模組去處理，就可以透過建構應用場景去試驗。

當然，Bitcoin 生態在這個路線也上存在一些挑戰：

1. Bitcoin 設計之初並沒有給這種DA 場景留下足夠的擴展空間，所以透過什麼形式將數據寫到Bitcoin 上，是前面各種協議嘗試探索的方向之一，例如OP_RETURN 嵌入數據，透過Witness，甚至透過簽名，目前還缺少標準化的解決方案。

2. Bitcoin 生態對鏈上嵌入資料的價值並沒有達成廣泛的共識，這也是從上次銘文熱一來，我一直持續呼籲的方向，Bitcoin 生態應該重視Bitcoin 作為一個全球的公共數據總線（Data Bus）的價值。

L1 作為全球公共資料匯流排的價值

從DeFi summer 之後,整個Crypto 領域一直在探索DeFi 以外的新型應用。無論是Bitcoin 的銘文熱潮，還是最近的Based Rollup 熱議，都可以理解為L1 作為資料匯流排價值的重新發現。從分散式系統的角度來看，透過資料匯流排可以實現系統之間的解耦，而係統之間的解耦是實現Permission less 的關鍵前提之一。例如，Crypto 生態中的去中心化交易所，就充分利用了區塊鏈這個Data Bus 實現了「去中心化」的對接，這在傳統金融體系中是很難直接實現的。如果要支援更複雜的應用，只需要將簡單的轉帳交易升級為應用程式協定交易，就可以實現應用程式層面的Permission less，而這種方式對現有應用的侵入性最小。

本文主要從生態和應用角度探討BBR，關於BBR 模式的安全，以及BBR 模式下的L1，L1.5 ，L2 狀態的互通性的問題，留在後面的文章中再詳細探討。後面附加上一些相關鏈接，有我的歷史文章，也有推友從不同角度對Based Rollup 的闡述。

相關連結：
1. Stackable L2 — 新的區塊鏈擴充方案https://rooch.network/zh-CN/blog/stackable-l2

2. Bitcoin 的Layer 2 該怎麼做？ https://x.com/jolestar/status/1717358817992995120我從L2 如何利用Bitcoin L1 上的狀態和資料設計的最初方案，評論中有朋友提到了Booster 的方案，最後實踐中採用了Booster 的方案。

3. 銘文是個Bug 還是Feature？ https://x.com/jolestar/status/1732711942563959185從L2 的建構方式角度闡述銘文的價值，包括L1 和L2 的激勵相容難題。

4. 減法理論出發探討Based Rollup @kerne l1 983 https://web3 caff.com/zh/archives/108241

5. @jason_chen 998 關於Based Rollup 的文章https://x.com/jason_chen998/status/1799692331635048697

6. Based Rollup 賽道研究報告https://research.web3 caff.com/zh/archives/22719

原文連結