前言

自 2020 年底以來，以太坊採用以 Rollup 為中心的擴展策略，以實現更快、更低成本的交易。然而，這一模式也帶來了生態碎片化的問題，導致用戶和流動性分散在多個 Rollup 之間。這種碎片化影響整個以太坊生態，影響了統一的用戶體驗。

本文將深入剖析碎片化問題的根源，並重點探討 Rollup 互操作性所面臨的關鍵挑戰——雙重提交（equivocation）。同時，我們將對不同的互操作性解決方案進行分類，並分析其權衡取捨，以展望更緊密互聯的 Rollup 未來。

碎片化問題

Rollup 生態的碎片化會導致用戶體驗下降、資金效率降低，以及原生可組合性缺失：

• 用戶體驗：碎片化迫使用戶頻繁切換網絡、管理多份相同代幣，並在多個錢包之間切換，增加了交互摩擦和複雜度。例如，Alice 的資金存放在 Rollup A，但她想要購買僅在 Rollup B 上流通的代幣。她無法直接點擊“購買”，而是需要先切換網絡，將資金從 A 轉移到 B，等待 L1 確認後，才能完成交易。
• 流動性問題：當流動性分散在多個 Rollup 之間時，交易對的深度和效率都會降低，導致更差的交易價格、借貸協議收益減少，以及次優的交易執行效果。
• 可組合性受限：在單鏈環境下，借貸協議可以在同一筆交易中調用 DEX 合約，實現即時清算。而在多 Rollup 生態中，這一過程變得異步化。例如，借貸協議可能需要先在一個 Rollup 上觸發清算，再等待消息在另一個 Rollup 的 DEX 進行結算。如果過程中出現任何問題，想要撤銷操作並不容易。此外，以太坊並未提供原生工具來支持跨 Rollup 的合約調用，也無法保證這些調用能夠快速執行。這種原子性（atomicity）的缺失，削弱了以太坊生態的可組合性優勢。

互操作性

互操作性的核心目標是讓一筆交易可以在一個 Rollup 上發起，並同步更新另一個 Rollup 的狀態，例如將代幣從 Rollup A 轉移到 Rollup B。理想情況下，該過程應該像 L1 交易一樣同步進行，即 A 餘額減少的同時，B 餘額即時增加。然而，在實際操作中，不同 Rollup 之間實現這種無縫的“全有或全無”（all-or-nothing）交互極具挑戰性。

理想情況下，不同 Rollup 之間的交互應當像以太坊 L1 那樣同步執行。在同步環境中，來自不同 Rollup 的多個合約調用可以被打包進單個交易，要麼全部成功，要麼全部失敗，從而實現即時且原子的執行結果。

相比之下，異步可組合性則涉及跨多個 Rollup、分階段完成的交互流程。它並非一個原子交易，而是可能先在某個 Rollup 上觸發一個事件，等待確認後，再在另一個 Rollup 上完成後續操作。異步可組合性需要處理回滾問題：某個 Rollup 可能會先行執行某個操作，但如果對應的 Rollup 未能完成其部分，則該操作可能需要回滾，以恢復狀態一致性。

同步和異步可組合性在許多方面面臨相似的挑戰，本文將圍繞這些問題展開討論。
此外，本文重點關注原生的 Rollup 互操作性方案，即需要在協議層進行集成的解決方案。我們不涵蓋依賴流動性提供者的外部跨鏈橋方案，因為這類方案通常僅支持同質化代幣的轉移。

互操作性的挑戰

實現真正的 Rollup 互操作性，不僅僅是傳遞消息，更關鍵的是確保交易能安全、快速地最終確認。僅依賴以太坊 L1 進行跨 Rollup 結算，意味著高延遲和高成本。例如，當 Alice 想用 Rollup A 上的資金購買 Rollup B 上的代幣時，通常有兩種方案：

• Rollup B 僅接受通過以太坊 L1 橋接的資金。在這種情況下，Alice 需要先將資金從 Rollup A 提取到 L1，然後再存入 Rollup B，最後才能進行交易。這一過程不僅耗時，還涉及高額 Gas 費用。
• Rollup B 允許 Alice 直接在 Rollup 之間轉賬，而無需經過 L1 結算。這雖然更快、更便宜，但也帶來了新的風險。例如，如果 Rollup A 發生雙重提交，未能最終結算，或提交了無效的狀態轉換，那麼 Rollup B 就可能受到影響，面臨重組等安全風險。

當兩個 L2 以比以太坊更快的延遲進行交互（即在它們提交或結算狀態轉換到 L1 之前），rollup 需要應對三個核心問題：雙重提交、無效性和未結算。

• 雙重提交：一個 rollup 向不同的鏈廣播衝突狀態，等於多次提交相同的資產。
• 無效性：某個狀態轉換可能在 L1 上永遠無法被證明為有效。
• 未結算：證明生成或結算過程可能會無限期卡住。

需要強調的是，所有這些問題都可以通過等待 L1 的最終確定性來輕鬆解決——即狀態轉換完全在以太坊上結算。然而，我們關注的是如何在比以太坊更快的延遲下實現安全的跨 rollup 交互。因此，我們需要探索在 L1 最終確定性之前的時間窗口內，既能保證安全性，又能提升交互效率的解決方案。

假設 Alice 在 Scroll 主網擁有 10 ETH，並希望將其轉移至 Arbitrum。理想情況下，Alice 應該能夠以比以太坊更快的延遲，在這兩條鏈之間無縫轉移流動性。假設存在某種方案，使得 Arbitrum 可以在 Scroll 向 L1 提交任何數據之前，就先行為 Alice 記賬 10 ETH，那麼這對 Arbitrum 來說會有哪些潛在風險？

• 雙重提交：Scroll 在 L1 提交了一個不同的狀態轉換，其中並未包含 Alice 的轉賬交易，這樣一來，相當於 Scroll “偷走”了 Arbitrum 先行發放的 10 ETH（Arbitrum 只能通過重組來修正自身狀態）。
• 無效性：Scroll 並未進行雙重提交，但包含 Alice 交易的狀態轉換本身是無效的，因此無法在 L1 結算（即無法在 L1 證明其有效性），也就無法將資金交給 Arbitrum。Arbitrum 仍然需要重組以應對這種情況。
• 未結算：Scroll 既未雙重提交，且狀態轉換也是有效的，但負責生成證明的節點下線，導致該狀態永遠無法在 L1 結算。Arbitrum 再次面臨需要重組的問題。

當 Arbitrum 在 Scroll 向 L1 提交之前（在雙重提交場景中），或在 Scroll 結算之前（在無效性和未結算場景中）就接受了 Alice 的 10 ETH，意味著它的安全性依賴於 Scroll 的正確性和可用性，從而承擔了一定的鏈間風險。

決定 Rollup 互操作性的一個重要方面是它如何處理雙重提交問題。不同的架構對雙重提交採取了不同的應對策略。例如，在 OP Superchain 這樣的系統中，所有 rollup 被設計為一同進行重組——如果一個 rollup 發生雙重提交，所有連接的 rollup 也必須重組其狀態，以保持系統的一致性。這種機制被稱為跨鏈聯動區塊。而其他架構則專注於完全防止雙重提交，並採用不同的機制來實現，我們將在下文探討。

對於未結算和無效性，一旦零知識證明（zk proof） 能夠實時生成（即實時證明變得可行），這些問題都可以輕鬆解決。然而，雙重提交則是一個本質上不同的問題。zk 證明可以證明 Alice 在 Arbitrum 上發送了 10 ETH 給 Bob，但 zk 證明 無法保證 Scroll 會在 L1 提交該狀態轉換。因此，zk 證明本身無法解決雙重提交問題，也永遠無法解決這一問題。當然，等待 L1 結算可以徹底消除雙重提交的風險，但這又犧牲了 rollup 的速度優勢。因此，我們的關注點是預結算階段的雙重提交——即在最終提交至以太坊之前，如何提供防雙重提交的安全保證。不同的方法涉及不同的權衡，尤其是在信任假設方面，接下來我們將對此展開討論。

互操作架構

我們探討了兩種不同的互操作性架構，旨在實現比以太坊更快的交互延遲，我們將其稱為網狀（mesh）和樞紐（hub）模型。

簡而言之，網狀模型是指 Rollup 之間直接互連，形成一個相互信任的網絡，以確保預結算的最終性，同時不發生雙重提交。

樞紐模型則引入了一個共享層，所有 Rollup 依賴該層來防止跨鏈交互中的雙重提交，並實現比以太坊更快的交互延遲。接下來，我們探討這兩種模式在實際應用中的區別。

網狀模型（Mesh）

網狀架構的工作方式符合直覺：各個 Rollup 直接通信，同時仍然負責自身向以太坊 L1 結算。

然而，隨著越來越多的 Rollup 相互連接，信任和依賴關係的傳遞性將成為可擴展性問題。例如，如果 Arbitrum 信任 Scroll，但不信任 zkSync，那麼 Scroll 在保持 Arbitrum 信任的同時，也無法信任 zkSync。因此，在網狀架構下，只有獨立的“信任群體”（即 Rollup 組成的團體）才能相互交互。當 Rollup 數量增加，互操作場景變得更加複雜時，整個系統的安全性最終受制於最薄弱的 Rollup。

儘管網狀系統依賴信任來保障預結算安全性，但它們仍然可以在最終結算時檢測到雙重提交，並觸發所有相關 Rollup 的重組。因此，這種互操作模式適用於以下情況：主要參與者是經過驗證、安全性較高的 Rollup；這些 Rollup 願意在系統內部建立信任依賴關係。然而，如果目標是擴展到更多 Rollup、其他 L2，甚至是 L3 和應用鏈，那麼網狀模型的擴展性問題將變得不可忽視。

樞紐模型（Hub）

樞紐模型通過引入共享層來彌補網狀模型的不足。每個 Rollup 需要信任該層，它作為跨鏈交互的唯一可信來源，從而使得新增 Rollup 變得更加簡單。理所當然，這一共享層必須儘可能安全，以在提供比以太坊更快的交互延遲的同時，確保最大程度的防雙重提交能力。

這種方案的優勢在於：新增 Rollup 不會帶來額外的信任依賴問題，因為互操作層在 Rollup 之間充當“防護盾”。無論是 L2、L3 還是應用 Rollup，只需集成到樞紐，即可享受互操作帶來的好處。

然而，該方案的主要權衡點在於：所有 Rollup 共同依賴同一個樞紐層，這使得該層在系統中的權力大幅提升。

特別是在預結算階段的防雙重提交問題上，我們必須確保樞紐不會與惡意 Rollup 串通作惡。因此，與網狀模型需要 Rollup 之間的相互信任不同，樞紐模型將這種信任集中到一個共享層，要求其保持獨立性，不得與其他 Rollup 共謀進行雙重提交。

因此，構建 Hub 時必須以安全性和去中心化為核心考慮因素。關於 Hub 的實現，有幾種不同的方案：

• 使用現有的 Rollup：這是最簡單的方案，直接基於一個已有、經過實戰考驗的 Rollup 進行擴展，僅需在其上部署智能合約即可。
• 創建專門的樞紐組件：而非讓 Rollup 依賴某個現有 Rollup 的完整安全體系，可以開發一個專門用於互操作的輕量級組件作為樞紐。這種方式的優勢在於，組件可以針對跨鏈需求進行優化，最小化漏洞和攻擊面，甚至可以進行形式化驗證以提高安全性。
• 直接使用以太坊 L1：該方案直接在 L1 上使用基於 L1 的預確認，利用極致的去中心化和安全性，同時提供近乎即時的交易確認、最小化提款時間等優勢。

如果使用 zk 證明，上述三種方式都可以利用證明聚合來降低成本。L1 只需驗證一個聚合證明，該證明批量涵蓋多個 Rollup 的驗證數據，從而顯著提升系統效率。

現有系統

多個項目已提出不同的互操作性（interop）解決方案，主要可分為以下幾類：

網狀系統（Mesh Systems）：OP Superchain 和 Arbitrum 的 Chain-clusters 屬於網狀系統，其中鏈與鏈之間必須共同結算——如果其中一條鏈發生雙重提交，所有連接的鏈都必須進行重組。這些系統依賴鏈間信任來實現預結算確認。

然而，由於信任團體難以擴展到多個大型 Rollup，最終可能需要引入某種樞紐機制來實現更高效的預結算終局性。

樞紐系統（Hub Systems）：Espresso 和 zkSync 的 Elastic Chain 採用樞紐系統。Scroll 也在探索基於樞紐的設計，以實現更具可擴展性、去信任化的互操作方案。我們在 2024 年哥倫比亞加密經濟學研討會（Columbia CryptoEconomics Workshop 2024）上分享了該設計的初步概念，並將在後續文章中提供更多細節。

其它系統：L1 的 Rollup（Based Rollups）具備同步可組合性，不僅能與其他 Rollup 無縫交互，還能直接與以太坊 L1 交互，並利用 L1 進行雙重提交防護。

Polygon 的 AggLayer 也是一種樞紐系統，它提供一個共享層，使所有 Rollup 通過該層進行通信。然而，它的不同之處在於避免在共享層引入額外的信任假設。AggLayer 依賴最終結算來保障安全性，並採用悲觀證明來防止雙重提交，意味著其防護機制僅在結算時生效。該系統可以選擇性地使用預確認來提供更快的終局性保證。近期，AggLayer 宣佈與 Espresso Systems 達成合作，共同提供共享排序機制。

結語

在以太坊之上的跨鏈互操作設計，需要權衡安全性、去中心化與可信中立性，其中雙重提交防護是核心挑戰之一。但這並非唯一難點，其他關鍵問題仍待解決，包括：數據可用性、結算層設計（例如跨 Rollup 共享橋接）、Rollup 智能合約的實現、消息傳遞協議和經濟激勵機制，以確保系統的可持續運行。正如 Vitalik 在最近的推文中所說，我們比大多數人想象的更接近解決這些跨鏈問題。在互操作性的最終形態中，用戶將不再感覺自己是在使用各個獨立的 Rollup，而是“體驗到一個完整的以太坊”。

聲明：

1. 本文轉載自[Scroll Research]。所有版權歸原作者所有[Alejandro Ranchal-Pedrosa]。若對本次轉載有異議，請聯繫 Gate Learn 團隊，他們會及時處理。
2. 免責聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。
3. Gate Learn 團隊將文章翻譯成其他語言。除非另有說明，否則禁止複製、分發或抄襲翻譯文章。