通過實時證明實現 Rollup 之間的同步可組合性
1. 基於彙總和實時驗證
基於基礎的Rollup是一種任何人都可以提議新區塊的Rollup ，沒有特權排序者。任何參與者都可以獲取Rollup的當前狀態，應用一組交易，並生成一個新區塊。
當我們要求數據可用性有效載荷和有效性證明作為一個整體提交時，一個關鍵的設計優勢便顯現出來。在傳統的Rollup設計中，數據先發布，證明隨後提交，這造成了一個斷層，使激勵機制的設計變得複雜：誰來生成證明？何時生成？如何確保他們得到公平及時的補償？
通過同時發佈數據和證明，我們徹底消除了這一差距。The Block提議者負責執行和證明。如果證明無效或缺失，則The Block根本不存在。這極大地簡化了激勵機制：The Block提議者即為證明者，其獎勵來自同一來源（例如交易費），無需單獨的證明市場或挑戰期。
這是通過實時證明實現的，它能夠快速生成有效性證明，使其可以與代碼塊的構建同時進行，而不是作為異步的後續考慮。
實時證明正迅速成為現實。目前，證明一個完整的以太坊區塊大約需要 12 個 GPU，平均證明時間約為 7 秒。儘管通過硬件改進和證明系統優化仍有很大的提升空間，可以進一步降低延遲，但很難準確預測其極限在哪裡。證明者中心化是一個值得關注的問題：硬件要求並不低，而且並非所有區塊創建者都能訪問相同的證明基礎設施。然而，證明本身具有並行化和商品化的特性，而且發展趨勢顯然是朝著使用更便宜的硬件實現更快證明的方向發展。
2. 什麼是同步可組合性？
同步可組合性意味著在單個交易中，一條鏈（L1 或Rollup）上的智能合約可以調用另一條鏈（L1 或另一個Rollup）上的智能合約，並在相同的執行上下文中接收結果，就像兩個合約都存在於同一條鏈上一樣。
如今，跨鏈交互是異步的：你在鏈 A 上發送消息，等待它轉發到鏈 B，然後單獨處理結果。這破壞了以太坊 DeFi 生態系統賴以強大的可組合性模型。協議無法跨越Rollup邊界進行原子性組合。
同步組合性恢復了這一點。從開發者的角度來看，調用另一個Rollup上的合約與調用同一條鏈上的合約在外觀和行為上完全相同。交易要麼在所有相關鏈上原子性地成功，要麼完全回滾。
3. 簡單情況：L2 到 L2 可組合性
在解決 L1↔L2 交互這個更難的問題之前，值得注意的是，僅 L2 捲包之間的可組合性相對簡單。
如果只處理 L2 級別，我們可以將所有受影響的彙總狀態的數據可用性打包到一個單獨的 blob 中。The Block構建器會構建一個涉及多個Rollup狀態的組合執行，將它們全部一起驗證，並將結果作為單個原子數據可用性提交。由於所有受影響的狀態轉換都已一起驗證和提交，因此自然而然地具備了可組合性：轉換要麼全部發生，要麼全部不發生。
這一觀察是基礎。更難的問題在於，當L1智能合約參與交互時，如何才能使其有效運作。
4. 代理智能合約
實現跨鏈調用的核心機制是代理智能合約。代理智能合約部署在一條鏈上，代表另一條鏈上的智能合約。
當L1鏈上的合約想要調用Rollup R上的合約時，它並不會直接在R上執行代碼。相反，它會調用位於L1鏈上的R合約的代理合約。該代理合約封裝了跨鏈調用：它知道目標合約是什麼，處理調用，在Rollup上應用相應的狀態更改，並返回結果，所有這些操作都在同一筆交易執行中完成。
從調用者的角度來看，與代理交互與與真實合約交互並無區別。代理是遠程合約的本地接口。
5. L1 ↔ L2 交互模型
當一筆交易同時涉及 L1 和 L2 智能合約時，其執行遵循一個結構化的流程：
第一步：確保代理合約存在
在執行之前，所有將與 L1 交互的 L2 合約的代理智能合約都必須部署完畢。如果要從 L1 調用Rollup R 上的某個合約，則該合約的代理必須已存在於 L1 上。
步驟 2：構建並提交執行表
執行表被構建並臨時存儲在 L1 狀態中。該表是一系列條目，其中每個條目描述一個操作及其後果。每個條目包含：
- 行動：主要
CALL或RESULT。 - 一組 L2 狀態轉換：哪些彙總會受到影響，以及它們的狀態根從什麼狀態轉換到什麼狀態。
- nextAction ：接下來會發生什麼，要麼是返回結果（帶有返回數據），要麼是另一個調用（調用不同的 L1 智能合約）。
該表記錄了跨鏈交互的完整軌跡。例如，考慮一個嵌套調用場景：
A ( on L1) calls B ( on Rollup 2 )→ B ( on Rollup 2 ) calls C ( on L1 )→ C ( on L1 ) returns→ B ( on Rollup 2 ) returns A ( on L1 ) continues execution在這種情況下，執行表將包含兩條記錄：
| # | Action | L2 State Transitions | nextAction | | ---|-----------------------|-------------------------------|---------------------| | 1 | CALL B ( on Rollup 2 ) - | Rup2: stateRoot₀ → stateRoot₁ | CALL C ( on L1) | | 2 | RETURN from C ( on L1) | Rup2: stateRoot₁ → stateRoot₂ | RETURN to A ( on L1) |第一條記錄寫道：“當 A 在Rollup 2 上調用 B 時， Rollup從 stateRoot₀ 轉換到 stateRoot₁，接下來需要做的是調用 L1 上的 C。” 第二條記錄寫道：“C 返回後， Rollup 2 從 stateRoot₁ 轉換到 stateRoot₂，最終結果返回給 A。”
執行表編碼了整個調用/返回序列，以及每一步發生的所有Rollup狀態轉換。至關重要的是，該表附帶一個有效性證明，保證表中每個執行步驟的正確性。該證明在提交表時驗證一次。
步驟 3：使用代理解析執行 L1 任務
現在 L1 交易正常執行。當執行到 L1 合約調用代理合約時，代理合約執行以下操作：
- 在執行表中查找相應的
CALL操作。 - 驗證並應用受影響彙總的狀態根更改。
- 如果序列中有嵌套的 L1 調用，則執行它們。
- 從執行表中刪除已消耗的條目（以避免浪費 L1 存儲空間）。
- 將
RESULT返回給調用 L1 合約。
從L1執行環境的角度來看，調用正常發生並返回了結果。跨鏈交互的複雜性完全由代理和執行表抽象化了。
步驟 4：L2 發起的交易
從 L2 發起並與 L1 交互的交易遵循相同的模型，但執行表中的第一個操作是L2TX而不是CALL交易啟動執行，任何對 L1 合約的調用都會成為表中的嵌套條目，並以相同的方式解析。
步驟 5：處理回滾
兩個特殊操作： REVERT和REVERT_CONTINUE以類似於單個鏈內還原操作的方式處理跨鏈邊界的還原操作。
當 L2 執行過程中發生回滾時，會向 L1 發送REVERT操作。L1 隨後處理回滾，撤銷回滾執行路徑中所有嵌套的 L1 調用，並相應地更新受影響的Rollup狀態根。L1 完成回滾調用的撤銷後，會向 L2 發送REVERT_CONTINUE操作，允許執行恢復。最終結果是，回滾在單個鏈中的工作方式與當前相同。
6. 補充說明
賬戶抽象與激勵機制協調
確保代理合約的部署以及用戶與The Block創建者之間的激勵機制正確匹配，可以使用現有的以太坊標準來實現——特別是EIP-7702 （設置 EOA 賬戶代碼）和EIP-4337 （賬戶抽象）。這些標準提供了協調設置階段所需的靈活性，而無需更改核心協議。
彙總不僅限於電子投票機
參與此係統的 Rollup 無需是 EVM 原生 Rollup。任何能夠接受和生成對其他 Rollup 的 `CALL` 調用的Rollup均可參與。每個Rollup通過zkVerification 密鑰定義自己的狀態轉換函數。Rollup 甚至可以擁有一個對其狀態根具有完全控制權的擁有者。
主系統施加的唯一限制是以太幣問責制：系統必須跟蹤每個Rollup持有的以太幣數量，並且不得允許Rollup發起“CALL”請求，其請求值高於其以太幣總餘額。
原生代幣和價值轉移
Rollup 可以定義自己的原生令牌。唯一的限制是，如果Rollup使用不同的原生令牌，則狀態轉換函數不應接受或發起來自或向外部Rollup發送的非零以太幣值的CALL請求。這可以防止 Rollup 內部令牌與 L1 系統跟蹤的以太幣之間出現記賬不匹配的情況。
無需 L1 叉車
整個機制無需對 L1 進行分叉即可實現。所有操作均通過部署在現有以太坊網絡上的智能合約完成。
與預確認正交
該方案與預確認機制完全正交。它既不依賴於預確認，也不與之衝突。事實上，一旦L1預確認機制可用，該方案還能從中受益，因為更快的L1最終確認速度將降低跨鏈相互作用的延遲。
參考實現
這些智能合約的工作原理初稿可在以下網址獲取： https://github.com/jbaylina/sync-rollups
