Rollups 中的預先確認保證的分類及其削減條件
感謝 mteam 和 Justin Drake 對本文的反饋和評論。感謝 Ink L2 為我的研究提供資金支持。
Optimistic Rollup 中的預確認機制可以為用戶提供不同級別的保證，從基本的包含性到對排序和執行結果的強保證。然而，由於缺乏正式的分類法，導致討論中存在定義重疊，甚至有時是重複的現象。本文檔提出了一種結構化的預確認保證分類方法，旨在明確每種類型之間的界限。此外，文檔還定義了相關的罰沒條件以及執行這些條件所需的計算複雜度，從而使Rollup設計能夠對安全性、用戶體驗和實現方式進行嚴格的權衡。
預先確認有四個基本保證：
- 包容性
- 通過簽名消息強制包含需要預先確認的排序器將交易包含在指定的塊中。
- 訂購
- 通過簽名消息強制排序需要預先確認排序器將交易包含在指定塊中的指定序列號處。
- 執行成功
- 執行成功保證交易不會回滾，無論其確切的輸入狀態或 Gas 消耗如何。但是，除非還做出了狀態後承諾，否則它不能保證特定的狀態變化。
- 州後擔保
- 通過簽名消息強制執行後狀態保證需要預確認測序器包含交易並確保執行期間的預狀態參數和後狀態突變與預確認測序器的簽名響應相匹配。
類別 0
保證包含。不保證訂購或執行成功。
這是最弱的保證。交易者通過預確認響應獲得交易被包含的保證。然而，排序並不能保證，執行結果也不確定。
此類別的削減條件將是交易樹中交易不包含的證明。
然而，無序交易樹的非包含證明在 EVM 中計算起來很複雜，因為需要對交易樹中的所有交易進行排除證明。
例子：
DEX 內存池納入限價訂單
用戶向基於 Rollup 的 DEX 提交限價訂單。排序器提供簽名保證，保證該交易將被打包到下一個區塊中，但最終排序方式尚未確定。這使得 DEX 前端可以向用戶顯示他們的訂單將被處理，但不會承諾執行成功或結果（滑點、競爭條件或搶先交易可能會影響執行結果）。
第 1 類
保證包含和排序。不保證執行成功。
此類別的削減條件將是交易樹中交易不包含的證明。
對已簽名的序列器交易使用序列號可以降低計算複雜度，因為通過提供指定序列的交易和附帶的 Patricia Merkle Tree (PMT) 見證，可以將不包含證明轉化為矛盾證明。
例子：
優先插槽的 NFT 鑄造
在 NFT 投放期間，用戶可以付費購買優先鑄幣位。排序器會返回一個已簽名的預確認，承諾鑄幣交易將被添加到特定的序列位置。但是，如果用戶資金或 Gas 不足，交易仍可能被撤銷。這確保了排序的公平性，同時將執行風險轉移給了用戶。
第 2 類
保證成功納入並執行。不保證排序或後續狀態。
此類別保證交易執行無逆轉，且不保證交易執行時的狀態樹輸入或輸出。此保證使發出預確認的排序器能夠從預確認的交易中提取 MEV，同時為交易者提供執行成功的強有力保證。
此類別的削減條件與類別 0 相同。但是，非逆轉證明需要在 EVM 中重新執行The Block，直到交易執行完畢。
例子：
具有 MEV 靈活性的滑點約束 DEX 交易
用戶向去中心化交易所 (DEX) 提交一筆指定最大滑點的交易（例如，“以至少 0.98 ETH的價格賣出 1000 USDC ”）。只要交易後價格在用戶的滑點容忍度範圍內，序列器就會返回預確認，保證交易成功（即不會回滾）。只要最終執行價格在允許範圍內併成功，序列器就可以自由地相對於其他交易重新排序這筆交易，並提取 MEV（例如，通過“夾層”操作）。這讓用戶在無需特定排序或狀態根的情況下，仍能保持執行的信心。
第 3 類
保證包含、執行成功和後狀態。不保證順序。
這是最強的保障。此保障為交易者提供了交易被包含和交易後狀態變更的保證。雖然排序可以自然推斷，但並非嚴格執行，因為交易的前後狀態可以獨立驗證。只要交易的狀態上下文保持隔離，交易在The Block中的位置可以發生變化，而不會影響其執行結果。
削減條件與第 2 類相同，但增加了 EVM 後狀態證明，以驗證後狀態突變。
例子：
託管或有條件付款合同
在跨鏈橋接或支付通道中，用戶發送交易，期望其最終產生精確的後狀態突變（例如，balanceOf(user) += 1 ETH）。排序器會簽署一份預確認，該預確認不僅承諾交易的納入和成功執行，還承諾最終產生的特定後狀態根。這使得預確認可以作為橋接協議或條件承諾中的鏈下證明，如果違反，將受到嚴厲的懲罰。
= 保證 | 
= 不保證
| 類別 | 包容性 | 訂購 | 執行成功 | 州後擔保 | 削減計算 |
|---|---|---|---|---|---|
| 0 | | | | | 在） |
| 1 | | | | | O(1) |
| 2 | | | | | O(n) + O(m) |
| 3 | | | | | O(n) + O(m) |
* O(m) 意味著交易執行
關於削減條件複雜性的腳註：
雖然驗證 slashing 條件（例如，證明未包含或後狀態不正確）的簡單方法可能需要在 EVM 中進行 O(n) 或 O(m) 運算，但通過加密證明系統可以顯著降低這些成本。如果Rollup利用 SNARK（或類似的簡潔證明），則整個 slashing 驗證過程（無論是檢查包含、執行成功還是後狀態有效性）都可以在鏈上壓縮為常數時間驗證成本，從而有效地將計算複雜度降低到 O(1)。
為什麼要區分2類和3類？
第 2 類保證執行成功，但不保證執行後狀態。這意味著排序器可以在The Block內重新排序交易，從而可能改變其執行前和執行後狀態，只要它不被逆轉。這種靈活性使得 MEV 提取或批處理優化成為可能，同時又能保證交易“成功”。
相比之下，類別 3明確保證了後狀態，這意味著排序器必須確保交易導致特定的狀態轉換。只有當交易的預狀態是隔離的（即不受周圍交易的影響）時，才允許重新排序。如果預狀態不是隔離的，則排序將隱式固定，因為任何排序的更改都會使預期的後狀態無效。然而，排序本身並非罰沒條件——只有已提交的後狀態不匹配才可以被罰沒。
