背景
閱讀我關於共享定序器的文章。
許多共享定序器已經允許原子包含事務。然而，這需要對所有組件彙總進行協議更改。這些協議的改變是未經指定的，而且這些想法是毛茸茸的和奇怪的。
我懷疑共享定序器的人們只是將其過於複雜化，使其看起來很神秘。所以我決定坐下來設計一個基本的交叉彙總捆綁方案。
幸運的是，我們擁有關於任意捆綁方案的現有技術，因此我們知道要避免什麼，以及通常如何構建它們。事實證明，修改每個Rollup的過濾功能很容易。
目標
它應該允許來自多個 EOA 的多個交易。
應該不可能破壞捆綁（包括組件交易而不包括同一序列中的所有其他交易）。
不需要共享 TX 格式。
簽名應該很便宜（在最壞的情況下，交易數量為
O(n)，參見 二次嘆息問題）
修改組件RollupTX 格式
在所有情況下均省略簽名。
在 tx 中包含鏈 ID 或其他域綁定。
沒有其他修改
捆綁
對於每個組件Rollup，都有一個數據結構，將 EOA 地址映射到該地址的交易列表。事務應該被序列化並表示為不透明字節。簽名者無需理解內容。
struct Bundle {arbitrum: Map<Address, Vec<OpaqueBytes>>,optimism: Map<Address, Vec<OpaqueBytes>>,}簽約
我們迭代所有交易，為Rollup和發送者插入分隔符。這確保了 txn 綁定到特定的Rollup和特定的 EOA，並且不會被誤解。它還確保將Rollup和 EOA 信息公開給所有觀察者，而不要求觀察者瞭解 tx 結構。
以這種方式簽名還可以確保所有簽名都提交給所有交易。這使得捆綁包不可修改。它既不能擴展也不能分拆。
fn signing_hash(&self) -> [u8;32] {let mut hasher = Keccak::new();hasher.update(b"arb");for (from, txns) in self.arbitrum.iter() {hasher.update(&from);txns.for_each(|tx| hasher.update(tx.hash()));}hasher.update(b"opt");for (from, txns) in self.optimism.iter() {hasher.update(&from);txns.for_each(|tx| hasher.update(tx.hash()));}hasher.finalize()}fn sign(&self, key: &SigningKey) -> Signature {key.sign_raw(self.signing_hash())}如果需要，也可以使用一些額外的域綁定，idc。
正在驗證
驗證可以在不瞭解交易內容的情況下完成。
我們通過以下方式驗證：
計算捆綁包的簽名哈希值
檢查該捆綁包的每個聲明的 EOA 是否在簽名哈希上都有簽名
struct SignedBundle {bundle: Bundle,signatures: Vec<Signature>,}fn verify(bundle: &SignedBundle) -> Result<()> {let signing_hash = bundle.bundle.signing_hash();// Collect the signers whose signatures are includedlet addresses = bundle.signatures.map(|sig| sig.recover_raw(signing_hash)).collect::<Result<HashSet<_>>>();// collect the stated EOA senderslet eoas = bundle.arb.keys().chain(bundle.opt.keys()).collect::<HashSet<_>>>();// Check that those sets are equalif eoas != addresses {return Err("missing sig or extra sig or whatever")}Ok(())}通過這種方式，我們確保所有簽名覆蓋所有交易（並且如果添加、刪除或替換交易將無效），並且簽名不會覆蓋任何交易。進行額外檢查也不是很昂貴。
序列化
誰在乎這都是小事。就做事吧。
過濾
組件彙總必須過濾驗證失敗的包。請注意，過濾不需要了解交易的內容，只需檢查交易的簽名即可。
這意味著簽名不正確或不足的包將包含在主機歷史記錄中，但會從Rollup歷史記錄中過濾掉。它們對Rollup鏈沒有任何影響。今天，ofc 在主網的彙總中對排序器輸出中的無效交易做了同樣的事情。
結論
這實現了多方捆綁包的原子包含。多個 EOA 可以包含事務。捆綁包無法拆分，因為所有簽名都提交給所有交易。簽名交易次數為O(n) 。驗證的時間複雜度為O(n + s)其中s是簽名者的數量。如果需要，您可以使用可聚合的簽名方案來稍微調整這種權衡。
繁榮。目標已實現。
那麼這對我們沒有什麼好處呢？閱讀過我過去的博客文章和惱火的推文線程的精明讀者可能會意識到，這種捆綁方式無法讓您獲得原子執行。是的。因此，如果沒有進一步的機制/協議更改來處理執行部分，您實際上無法使用它來構建任何互操作性方案。 MEV 提取塊構建器通過位於塊頂部來獲得執行。但你，最終用戶，不提取東西。你被提取了。
所以，是的，構建一個捆綁方案是微不足道的，但這只是因為我們將問題縮小到幾乎無用的程度。
總而言之，原子包含是令人討厭的，而且很容易，除了 MEV 提取之外，對任何事情都沒有什麼好處。別小題大做了。
