加密框架交易

作者：Thomas Thiery

感謝 Julian Ma、Anders Elowsson、Benedikt Wagner 和 Gottfried Herold 的反饋與審閱。

內容提要 (TL;DR)

加密框架交易（Encrypted frame transactions）會隱藏對 MEV 提取至關重要的執行參數，直到區塊內容和排序固定後才揭露。

建構者（Builder）在任何解密密鑰揭露之前，先承諾完整的交易排序集。密鑰揭露後，建構者在同一個時隙（Slot）內執行該已承諾的排序。這使得「同槽位加密執行」（same-slot encrypted execution）成為可能，而無需將區塊拆分為特殊的加密部分和明文剩餘部分。

此設計複用了 LUCID 的加密方案：用戶可以自行發布密鑰，或委託給門檻委員會（threshold committee）或任何其他實體。它建立在框架交易（Frame Transaction，EIP-8141）之上，該提案將硬編碼的授權替換為可編程的 VERIFY 邏輯（為兼容後量子密碼學方案開闢了道路），並通過基於框架的交易結構實現了欄位級別的選擇性披露。

高層次理念

實現同槽位加密執行的關鍵理念之一是排序與執行分離（order-execute separation）：建構者在任何解密密鑰揭露之前承諾完整的交易排序集，然後在密鑰揭露後的同一個時隙內執行該已承諾的排序。

在 ePBS (EIP-7732) 區塊拍賣中，建構者的出價承諾的是預先計算的執行結果。這在這裡行不通，因為最終的有效載荷（payload）取決於哪些加密交易被揭露以及它們解密後的內容。對於同槽位加密執行，出價必須先承諾交易內容和排序，而與執行相關的輸出（如最終有效載荷和區塊級訪問列表 BAL，EIP-7928）僅在揭露後才綁定。

這是與 LUCID 等「下一槽位加密設計」的關鍵區別。在 LUCID 中，加密交易在時隙 N 承諾，密鑰在時隙 N 期間發布，而執行則發生在時隙 N+1 的專用區塊頂部通道（top-of-block lane）中。當時隙 N+1 的建構者構建區塊的明文部分時，它已經知道了解密後的交易。

該設計還基於框架交易（EIP-8141），這使其在兩個方面具備未來兼容性。VERIFY 框架將硬編碼的授權替換為可編程的公共驗證，為後量子兼容方案鋪平了道路。基於框架的交易結構避免了硬編碼單一且永久的「公開/隱藏」欄位劃分：隨著新框架類型的定義，發送者可以選擇哪些執行參數公開承諾，哪些隱藏，而無需引入新的交易類型。

時隙 N 流程

每個加密框架交易都有一個公開的 VERIFY 框架和一個隱藏的加密執行階段。交易封裝（envelope）承諾 exec_params_binding = H(exec_params)，將密文與發送者預期的明文綁定。

時隙 N 的流程如下：

• 提議者（Proposer） 廣播包含獲勝建構者出價的信標區塊。該出價在任何密鑰揭露前承諾完整的交易排序列表。

• 密鑰發布者（Key-releasers） 觀察信標區塊並發布 k_dem（每筆交易的對稱密鑰），並綁定到 (slot, beacon_block_root, tx_reveal_id)。

• 證明者（Attesters） 緩存收到的揭露信息直到 T_rev_a，然後凍結其本地視圖。

• 建構者（Builder） 在 T_rev_b 凍結其揭露視圖，執行已承諾的排序，並廣播簽名後的揭露後有效載荷封裝（post-reveal payload envelope）。

• PTC（Payload Timeliness Committee） 在 T_PTC 截止時間對該封裝進行投票。

• 時隙 N+1 的證明者 驗證時隙 N 的有效載荷，包括根據其緩存視圖驗證 BAL 和 reveal_root，然後對區塊進行投票。

上圖未顯示與包含者（Includer）和 Blob 相關的職責，以避免圖表過於擁擠。

備註：

• 揭露的及時性通過類似於 FOCIL (EIP-7805) 的證明者視圖合併機制來強制執行。另一種變體可能要求揭露信息在相應解密密鑰被包含之前，必須獲得 PTC 的法定人數支持，從而進一步限制建構者在揭露包含方面的自由裁量權。無論哪種情況，該機制都依賴於證明者或 PTC 成員及時獲得底層交易字節，以便根據 exec_params_binding 驗證揭露信息。

• 該設計還假設對於給定的 (slot, beacon_block_root)，最多只有一個規範的、獲得法定人數支持的揭露後有效載荷封裝。同一時隙內競爭的有效封裝應被視為雙重簽名（equivocation）情況。

角色

發送者 (Senders)

在提交之前，發送者運行密鑰發布者的鏈外 KEM（密鑰封裝機制）以生成 (k_dem, kem_ciphertext)，使用 k_dem 加密 exec_params 生成 dem_ciphertext，設置 exec_params_binding = H(exec_params)，對封裝進行簽名，並將交易提交到內存池（mempool）。

對於自我解密，發送者直接生成一個新的 k_dem 並將 kem_ciphertext 設置為空。

包含者 (Includers)

在時隙 N-1 期間，包含者構建並廣播包含列表（inclusion lists）。對於加密交易，他們驗證交易封裝和 VERIFY 框架，同時將加密執行字節視為受大小限制的不透明字節。

如果一個加密交易被跳過（即 k_dem 未揭露），在狹義上仍被視為滿足 IL（包含列表），因為封裝已被包含，儘管隱藏的執行部分並未運行。

提議者 (Proposer)

在時隙 N，t = 0s 時，提議者廣播包含建構者出價的信標區塊。提議者根據出價價值以及出價的 IL 位圖（bitlist）是否覆蓋了提議者 IL 凍結截止日期前觀察到的所有 IL 來選擇出價。

出價承諾：

• tx_ordering_root：完整交易內容排序列表的 Merkle 根。
• IL 位圖。
• 建構者身份和出價價值。

交易集和排序在出價時即鎖定，此時尚未揭露任何密鑰。建構者承諾所有內容，但尚未承諾最終執行結果。與執行相關的輸出（如 state_root、receipts_root、block_hash 和 BAL）在 T_rev_b 之後才確定，因為它們取決於加密交易解密後的內容。由於 BAL 是由執行衍生的，延遲執行綁定也會延遲 BAL 綁定。

需要區分兩種承諾。排序承諾必須綁定精確的交易字節（包括 VERIFY 框架數據），以便在出價時固定區塊內容。然而，揭露匹配應使用穩定的標識符 tx_reveal_id 而非精確的字節承諾，因為 EIP-8141 故意將 VERIFY.frame.data 排除在規範簽名哈希之外。

密鑰發布者 (Key-releasers)

該角色被稱為「密鑰發布者」而非「解密者」，因為其在協議內的任務是發布 k_dem，而不是執行解密。根據所使用的鏈外 KEM，密鑰發布者可能需要在內部解密 kem_ciphertext，但該步驟對協議是不可見的。

密鑰發布者發布鏈外指令，描述發送者如何封裝 k_dem、KEM 結構以及相關的密鑰派生參數。

協議本身不對 KEM 結構施加限制，但 k_dem 必須與特定交易和揭露域進行上下文綁定，以便發布一筆交易的密鑰不會洩露其他交易的信息。在實踐中，這意味著至少要將其綁定到 tx_reveal_id、exec_params_binding 以及揭露時使用的分叉上下文。

協議在解密後驗證 H(exec_params) == exec_params_binding，但無法驗證 KEM 是否實現了密鑰獨立性。因此，用戶必須信任其選擇的密鑰發布者，相信其構造正確且不會在預定的揭露點之前洩露明文或密鑰。

在觀察到時隙 N 的信標區塊後，密鑰發布者廣播 k_dem 以及 (slot, beacon_block_root, tx_reveal_id)，並由 key_releaser_address 簽名。

加密交易的有效性取決於 valid_block_height，因此在發生重組（reorg）後，它們不能在不同的高度重新插入。揭露信息綁定到 (slot, beacon_block_root)，因此一個分叉的揭露信息在另一個分叉上無效。請注意，這並不能防止在相同高度的競爭分叉上重新包含，因此用戶仍應將重組的時隙視為隱私洩露，並避免重新提交相同的 exec_params。

建構者 (Builder)

建構者決定所有交易（加密和明文）的排序，並受 IL 限制。該排序在任何密鑰揭露前通過 tx_ordering_root 在出價中承諾。

在 T_rev_b，建構者凍結其揭露視圖。對於每個已揭露的條目，它使用 k_dem 解密 dem_ciphertext 以恢復 exec_params。未揭露的條目將被跳過。然後，它按承諾的順序執行整個區塊，並廣播包含有效載荷、BAL、reveal_root 和 k_dem 列表的簽名 ExecutionPayloadEnvelope。

PTC (Payload Timeliness Committee)

在時隙 N 的 T_PTC，PTC 對綁定到 (slot, beacon_block_root) 的 payload_envelope_root = hash_tree_root(ExecutionPayloadEnvelope) 進行投票。PTC 成員根據交易封裝中相應的 k_dem_commitment 驗證每個揭露的 k_dem。這讓 PTC 可以在不嘗試解密 dem_ciphertext 或重新派生 exec_params 的情況下，對揭露信息的可用性進行投票。PTC 成員對每個 (slot, beacon_block_root) 最多簽署一個 payload_envelope_root，即他們觀察到的第一個有效封裝。

一個更嚴格的變體也會讓 PTC 成員證明揭露信息的可用性。在該變體下，只有當相應的揭露信息獲得 PTC 的法定人數支持時，才允許包含解密密鑰。

證明者 (Attesters)

在時隙 N 的證明截止日期之前，證明者驗證時隙 N-1 的執行有效載荷和 BAL，作為確定鏈頭的一部分。在證明截止日期和 T_rev_a 之間，他們緩存傳入的密鑰揭露，並在 T_rev_a 凍結其本地視圖。

在時隙 N+1 的 t = 3s 時，證明者使用封裝中的 k_dem 解密每個已揭露的條目以恢復 exec_params，重新執行時隙 N 的區塊，驗證下述區塊有效性規則，驗證時隙 N 的 BAL，確認 Blob 數據可用性，並對時隙 N 有效載荷中承諾的交易封裝強制執行 IL 滿足情況。

預期的本地規則是：如果在 T_rev_a 之前觀察到條目 i 的有效 k_dem，證明者將不會對 reveal_root 將條目 i 標記為未揭露的有效載荷進行證明。

PTC 法定人數用於收斂到單一有效載荷，而證明者視圖合併作為一種 CR（審查抗性）機制，確保建構者在不丟失證明的情況下無法排除揭露信息。

交易格式

交易佈局概念上為：
[VERIFY 框架, 明文] [加密階段, 密文]

該設計的具體版本將需要在 FrameTx 之上增加一個加密執行階段或額外的框架模式，因為目前的 EIP-8141 本身並未定義加密框架。

一個加密框架交易恰好包含一個加密執行階段。交易按承諾順序執行。對於每個加密交易，先運行 VERIFY 框架，如果已揭露，則隨後運行加密執行階段。否則，跳過加密階段。

由於這基於 EIP-8141，VERIFY 框架繼承了其語義。它的執行類似於 STATICCALL，不能修改狀態，且必須成功調用 APPROVE。如果未能做到，則交易被視為無效。VERIFY 框架數據也從規範簽名哈希中剔除，並且無法通過 TXPARAM* 被其他框架內省。

這意味著加密框架交易的編寫必須確保所有揭露前的有效性檢查僅憑公開數據即可判定。特別是，VERIFY 框架的批准結果不得依賴於同一區塊中較早加密交易的隱藏執行效果，否則建構者可能會承諾一個僅在揭露後才變為無效的排序。

封裝特定的欄位包括：

欄位	類型	描述
exec_params_binding	bytes32	H(exec_params)
k_dem_commitment	bytes32	k_dem 的隱藏承諾
key_releaser_address	address	密鑰發布者身份
dem_id	uint16	AEAD 套件加哈希標識符
dem_ciphertext_len	uint32	聲明的密文長度限制
valid_block_height	uint64	僅在此區塊高度有效

k_dem_commitment 欄位在揭露前將封裝與特定的對稱密鑰綁定。在揭露時，發布的 k_dem 會根據此承諾進行檢查。這有兩個目的：它讓 PTC 成員僅通過檢查承諾即可對揭露可用性進行投票，並區分了密鑰發布者的錯誤行為（發布錯誤密鑰）與解密失敗（密鑰正確但無法解密密文）。

加密執行階段包含：

欄位	類型	描述
kem_ciphertext	bytes	KEM 封裝和元數據
dem_ciphertext	bytes	exec_params 的 AEAD 加密

客戶端會拒絕任何加密字節超過聲明或協議規定大小限制的交易。全局 MAX_TOTAL_ENCRYPTED_BYTES_PER_BLOCK 限制了每個區塊的總密文大小。這意味著該設計雖然只有一個執行費用市場，但有兩個受限的區塊資源：Gas 和加密字節容量。

排序與有效性

建構者決定所有加密和明文交易的完整排序，並受 IL 限制。該排序在任何密鑰揭露前通過 tx_ordering_root 在出價中承諾。

tx_ordering_root = MerkleRoot(L_order)，其中每個 L_order[i] 承諾精確的編碼交易內容。

另外，reveal_root = MerkleRoot(L_reveal)，其中 L_reveal 僅涵蓋加密條目：

• 如果在 T_rev_b 前揭露，則為 (tx_reveal_id_i, k_dem_i)
• 否則為 (tx_reveal_id_i, empty)

驗證者強制執行三項義務：

• 排序義務： 交易內容和排序與 tx_ordering_root 匹配。
• 公開有效性義務： 所有揭露前的有效性條件僅憑公開數據即可滿足。
• 加密義務： 每個標記為已揭露的條目都能正確解密並滿足 H(exec_params) == exec_params_binding。

驗證者按順序從 L_order 中的每個加密交易派生 tx_reveal_id，並檢查 L_reveal 是否準確涵蓋了這些加密條目。

每個加密條目的揭露結果受三種情況支配：

• 未揭露： 在 T_rev_b 前未收到揭露。該條目在 L_reveal 中被標記為未揭露，加密執行階段被跳過。VERIFY 框架仍會運行，且仍會收取公開部分的 Gas 費用。
• 承諾不匹配： 發布的 k_dem 與 k_dem_commitment 不符。PTC 將該揭露視為無效。該條目被視為未揭露。這種情況表明密鑰發布者行為不當：發布的密鑰與發送者承諾的不符。
• 解密失敗： 發布的 k_dem 與 k_dem_commitment 匹配，但未能產生滿足 H(exec_params) == exec_params_binding 的有效明文。建構者可以通過展示承諾密鑰與密文的對比來證明不可解密性。該條目將被跳過，而不是使整個有效載荷無效，因為建構者忠實地應用了發送者綁定的密鑰。

除了這些跳過路徑外，如果條目在 L_reveal 中被標記為已揭露，但提供的 k_dem 未能產生滿足綁定條件的 exec_params，且不符合上述任何跳過條件，則有效載荷封裝無效。

在更嚴格的 PTC 認證揭露變體下，揭露包含還需滿足一個條件：只有當相應揭露獲得 PTC 法定人數支持時，才可包含解密密鑰。

建構者約束

建構者仍然可以包含條件策略和狀態敏感交易。改變的是時機：它必須在看不到加密交易隱藏執行參數的情況下選擇排序。

這也意味著建構者承擔了執行風險。如果較早的加密交易改變了狀態，導致較晚承諾的明文交易回滾（revert），該較晚的交易仍會消耗 Gas。發送者支付 Gas，而建構者則損失了浪費區塊空間的機會價值。

在基礎設計中，建構者對截止時間附近收到的揭露仍有一定的自由裁量權。它可以等待觀察哪些密鑰傳播開來，並以此為條件決定是否包含。PTC 章節中描述的更嚴格變體（需要 PTC 證明）減少了建構者的裁量權，但壓縮了時間預算。

加密

構造採用標準的 KEM-DEM 分離模式。

• KEM 完全存在於 kem_ciphertext 中，可以在不更改共識的情況下更改。
• DEM 是共識關鍵的。在揭露時，每個節點使用 k_dem 在本地解密 dem_ciphertext，重構 exec_params，並對照 exec_params_binding 進行檢查。

該設計的具體版本還必須固定 H(exec_params) 中使用的哈希以及每個 dem_id 的 Nonce 或 IV 派生方式。本文將這些細節抽象化，但在共識實現中不能留空。

AEAD 的 aad（附加驗證數據）為 (chain_id, tx_reveal_id, sender, tx_nonce, exec_params_binding, dem_id)，這將密文與預期交易綁定並防止移植攻擊（transplant attacks）。

加密有效載荷

exec_params 為 RLP(blinding_nonce, target, calldata, priority_fee?, padding?)

可選的尾部欄位必須按該順序規範編碼，且不得有間隔。

blinding_nonce 確保相同的目標和調用數據仍會產生不相關的承諾。目標合約（target）位於 exec_params 內部，因此在揭露前保持隱藏。尾部的 padding 欄位（如果存在）包含 padding_length 個零字節，在 EVM 執行前會被剝離。Gas 計費會退還填充字節的調用數據成本，因此協議部分補貼了長度隱藏。這對於像 ChaCha20 這樣的流加密（stream ciphers）是定義明確的，因為一個明文字節映射到一個密文字節；具有自身填充語義的分組加密模式（block cipher modes）則需要在不同的 dem_id 下單獨處理。

發送者選擇哪些欄位保持公開，哪些隱藏在 exec_params 內部。

隱藏優先費

公開封裝攜帶 max_fee_per_gas，且 APPROVE 授權 gas_limit * max_fee_per_gas，這與適配 FrameTx 的 EIP-1559 費用模型一致。發送者可以將實際的 priority_fee 放在 exec_params 內部，而不是在封裝中發布 max_priority_fee_per_gas。在揭露前，建構者能看到費用上限，但看不到精確的小費（tip）。

揭露後，協議檢查 priority_fee <= max_fee_per_gas - base_fee 並收取 gas_used * (base_fee + priority_fee)。

建構者獲得實現的優先費。任何未使用的授權金額將被退還。如果加密框架因密鑰未能在 T_rev_b 前到達而被跳過，則永遠不會收取隱藏的 priority_fee，因為 exec_params 從未被解密。偏好更具預測性包含的發送者仍可以在公開封裝中發布可見的優先費。

請注意，這種費用處理是加密交易設計的一部分，並非當前 FrameTx 語義自動提供的功能。

費用、跳過與免費期權

如果 k_dem 未能在 T_rev_b 之前到達，交易將被跳過。VERIFY 框架仍會運行，Nonce 仍會消耗，發送者仍需支付固有成本、調用數據成本和 VERIFY Gas。隱藏執行階段不運行。

由於 APPROVE 預先授權了全部 Gas 預算並在事後退還未使用部分，跳過行為很乾淨：發送者為實際運行的公開部分付費，加密執行的 Gas 被退還。跳過時不收取隱藏優先費，因為它僅在成功解密後才有定義。

「免費期權」問題依然存在。自我解密的發送者可以觀察已承諾的排序，並選擇是否揭露。如果排序有利，則揭露並執行；如果排序不利，則扣留密鑰並獲得跳過。

候選緩解措施包括對加密交易徵收額外費用（固定或動態，如 LUCID 中的 ToB 費用），或對重複跳過行為進行懲罰。

隱私屬性

加密框架交易僅提供「交易前隱私」（pre-trade privacy）。

在揭露前，建構者可以看到公開封裝數據、VERIFY 框架、Gas 限制、費用上限、密鑰發布者選擇以及 dem_ciphertext_len。它看不到目標合約、調用數據、金額、路徑或交易對手。使用填充時，實際的 exec_params 長度在聲明的密文範圍內是模糊的，進一步減少了消息大小帶來的信息洩露。

這在網絡層不提供發送者匿名性，網絡級元數據仍可能洩露關於誰發送交易或交易來自哪個系統的信息。

揭露後，任何節點都可以從發布的 k_dem 值中恢復已揭露條目的 exec_params。此時交易已經執行，因此該信息不再能用於搶跑（frontrun）或三明治攻擊。但它並非永久隱藏。

隱私保證還取決於對密鑰發布者的信任。如果密鑰發布者在公開揭露前向建構者洩露明文或密鑰，則「密鑰盲排序」屬性將喪失。

失敗模式

• 不配合的密鑰發布者可能導致交易被跳過。
• 勾結的密鑰發布者可能在 T_rev_a 之後但 T_rev_b 之前私下向建構者揭露，導致執行發生，而證明者未能及時觀察到以通過視圖合併進行保護。
• 建構者可能在密鑰傳播後扣留揭露後的有效載荷封裝，導致丟失槽位，這同時也是隱私洩露。
• 建構者可能在 reveal_root 上雙重簽名，向不同的 PTC 成員發送不同的揭露集。雖然交易集和排序由 tx_ordering_root 固定，但揭露集仍會改變執行結果並可能導致視圖分裂。EIP-7732 已經指出有效載荷和 PTC 雙重簽名是 enshrined PBS 中視圖分裂風險面的一部分。

zkEVM 路徑

該設計自然地擴展到 zkEVM 環境。揭露機制保持不變；改變的是 DEM 解密變成了證明義務，而不是直接的執行層檢查。請注意，zkEVM 升級並不會自動使 exec_params 永久隱藏：證明系統必須是零知識的（而不僅僅是簡潔的），且 k_dem 必須保持為私有見證（witness）。它還壓縮了時間預算，因為每個區塊的加密交易數量將受到證明生成時間和 DEM 驗證的每筆交易電路成本的共同限制。

與 LUCID 的關係

加密框架交易與 LUCID 共享相同的基礎密鑰發布者模型和相同的 KEM-DEM 直覺。區別在於建構者的承諾發生在哪裡，以及這隱含了什麼樣的區塊結構。

LUCID 在時隙 N 承諾加密交易，在時隙 N 期間發布密鑰，並在時隙 N+1 的專用區塊頂部通道中執行。這使得下一槽位的建構者在放置區塊的明文剩餘部分之前就擁有了揭露後的知識，並為該通道引入了單獨的 ToB_fee_per_gas 排序規則。

加密框架交易在揭露前承諾交易內容和順序，在同一個時隙執行，將加密和明文流保持在一個交錯的排序中，並將加密執行置於與可編程驗證和欄位級隱藏相同的底層之上。

開放問題

揭露時機與證明者視圖合併。 揭露窗口需要仔細校準：既要足夠長以使密鑰廣泛傳播，又要足夠短以留出執行和有效載荷發布的時間。強制執行此規則的證明者視圖合併規則也需要完整的規範，涵蓋什麼算作有效的觀察揭露、證明者必須持有什麼數據，以及如何處理時鐘抖動和傳播不均。

ePBS 承諾變體。 該設計需要與 EIP-7732 不同的出價結構。建構者在執行前承諾交易內容和排序，而 EIP-7732 則是對預先承諾的 block_hash 進行出價。對出價對象、PTC 投票目標、分叉選擇規則以及揭露後封裝規範化的具體更改都需要單獨的規範。

免費期權問題。 自我解密的發送者可以觀察已承諾的排序並選擇是否揭露，這實際上持有了一個執行的免費期權。該設計需要一個原則性的緩解方案，且不會重新引入顯著的複雜性或第二個費用市場。