LUCID 的同 Slot 解密方案：可選的 N Slot 執行與 N+1 退回機制
本提案透過預先 ABB 的經濟承諾機制打破加密內存池的循環依賴，允許在同一個 Slot 內釋放解密金鑰以降低延遲，並在條件不滿足時退回到標準的 N+1 模式。
摘要
加密內存池（Encrypted mempools）消除了有害的 MEV，但引入了時序問題。LUCID 在 Slot N+1（提交後整整一個 Slot）才解密密封交易（Sealed Transactions, STs），因為建構者（Builder）的承諾（ABB）存在於信標區塊內，在 Slot 敲定前無法被觀察到。這創造了一個循環依賴：建構者必須在看到明文前做出承諾，但解密者需要看到承諾後才釋放密鑰。Slot 邊界解決了這個問題，代價是約 12 秒的延遲和一個區塊價值的狀態變化。
我們觀察到這種依賴關係可以更早被打破。如果建構者在構造 ABB 之前，透過可罰沒的抵押品和向 Keyper 委員會支付費用來做出經濟承諾，Keyper 可以在同一個 Slot 內釋放解密密鑰。建構者進行解密，將其插入區塊頂部（Top-of-Block），並針對完整的負載構造 ABB。從共識層的角度來看：這就是一個正常的 LUCID 區塊。
這僅需要一個極小的規格變動（decrypted_transactions 可攜帶同 Slot 的 STs），無需新欄位，也不會改變 LUCID 的加密、包含或 MEV 保護保證。新的信任假設是 Keyper 的活躍度（Liveness）和罰沒執行。用戶透過 decryptor_address 選擇加入，並在條件未滿足時回退到 N+1。
同 Slot 執行減少了延遲，加強了針對過時狀態的執行保證，並在保留 LUCID 核心特性的同時對齊了建構者的激勵。
1. 透過 Slot N 選項優化 LUCID 下的執行
LUCID 的 N+1 設計是由循環依賴驅動的：
建構者必須在看到明文之前承諾包含 STs（透過可審計建構者出價，ABB），否則建構者可能會根據內容選擇性地排除或重新排序。
解密者應僅在該承諾之後釋放密鑰，否則建構者可能會看到明文並進行雙重承諾（Equivocation）。
ABB 存在於信標區塊中。當 ABB 在網路上可被觀察到時，Slot N 的負載已經敲定。
N 與 N+1 之間的 Slot 邊界乾淨地解決了這個問題。我們的提案則以不同方式解決：將承諾信號移動到比 ABB 更早的時間點。
ABB 前的經濟承諾
建構者已經擁有了 ST 密文（FOCIL 包含列表在 Slot N-1 期間傳播它們）以及正在構造中的區塊模板。建構者缺乏的是解密密鑰。
如果建構者簽署一份由可罰沒抵押品支持的經濟承諾，並向 Keyper 委員會合約支付費用，確認包含特定的 STs，Keyper 可以將此視為有效的承諾信號，並在 ABB 構造之前釋放密鑰。建構者為早期密鑰訪問付費，因為回跑（Back-running）價值和區塊組合優勢超過了成本（見第 5 節）。
流程
Slot N-1： 用戶將交易加密為 ST，廣播至 LUCID 內存池。
FOCIL 委員會在包含列表中傳播 ST。
建構者透過 ILs 接收密文，使用常規交易構建區塊模板。
Slot N： 建構者識別其 decryptor_address 為同 Slot Keyper 委員會的 STs。
建構者在協議外網絡上提交承諾並向 Keyper 委員會合約支付費用：
「我將在區塊頂部包含 STs [x, y, z]」
Keyper 驗證承諾 + 支付，向建構者釋放解密密鑰並公開廣播。
建構者解密 STs，插入現有模板的區塊頂部，重新計算狀態根。
建構者構造涵蓋完整負載的 ABB。
提議者（Proposer）選擇 ABB，發布信標區塊。
從共識層的角度來看：一個正常的 LUCID 區塊。
回退機制： 如果建構者未承諾，或密鑰遲到，
適用標準 LUCID N+1 解密。性能無退化。
同 Slot 解密是對已構建區塊模板的增量更新；解密、插入區塊頂部、重新計算狀態根：耗時約 1-2 秒。
防雙重承諾與經濟安全
在 N+1 中，Slot 邊界防止了雙重承諾。在同 Slot 中，經濟罰沒承擔了這一角色。罰沒條件是確定性的：如果建構者簽署了承諾包含 STs [x, y, z] 但獲勝區塊遺漏了其中任何一個，則該建構者將被罰沒。承諾是自證明的（建構者的簽名），且包含情況可透過 decrypted_transactions 欄位在鏈上驗證，無需主觀判斷或委員會投票。
FOCIL 提供了協議底線：無論如何都強制包含 ST。收到密鑰但遺漏 ST 的建構者將面臨經濟罰沒（承諾網絡）和協議懲罰（FOCIL）。經濟承諾強化了協議原有的要求。
抵押品必須超過從看到明文並違約中可獲得的最大可提取價值（MEV）。由於解密後的交易以協議確定的順序放置在區塊頂部，雙重承諾不會產生重新排序的價值。執行是在鏈上的：欺詐證明合約根據敲定區塊中的 decrypted_transactions 欄位驗證建構者簽署的承諾；沒有委員會或主觀爭議解決。如果 Keyper 離線，同 Slot 會退化為 N+1。我們得到的是延遲回歸，而非安全失效。
為什麼是建構者
在 ePBS 中，提議者是消極的出價選擇者。建構者構造執行負載，並且是唯一擁有同 Slot 執行基礎設施的實體：持久的 Keyper 連接、優化的解密程序和預先準備的區塊模板。隨著 Slot 時間壓縮，這種複雜性變得更加重要。
3. 密鑰分發與證明
證明者（Attesters）的執行層（EL）客戶端必須獨立驗證 decrypted_transactions 欄位，這需要解密密鑰。主要的工程疑慮在於密鑰傳播是否足夠快以進行證明。
密鑰傳播可行性
公開密鑰釋放是安全的：LUCID 的區塊頂部放置是確定性的（按 tob_fee 排序），因此沒有參與者能從早期明文訪問中獲得可利用的排序優勢。Keyper 在向建構者交付的同時公開廣播密鑰。
在證明窗口內傳播有多現實？我們將解密密鑰大小與網絡已處理的負載進行比較。
解密密鑰大小。 Shutter 使用 BLS12-381 門檻加密。組裝後的解密密鑰是一個 G1 點：壓縮後為 48 位元組。對於一個現實的 Keyper 委員會（Shutter 的 Gnosis 部署使用 7 個），聚合前的完整份額數據為 336 位元組至 1 KB。即使有 100 個 Keyper：總計 4.8 KB。
網絡已處理的負載：
| 負載類型 | 大小 | 傳播時間 (p95) |
|---|---|---|
| 以太坊區塊 (典型) | ~110 KB (壓縮) | 1-3s, 98% 低於 4s |
| 以太坊區塊 (含 Blobs) | ~400 KB (平均) | 97% 低於 4s (來自中繼) |
| 單個 Blob (EIP-4844) | 128 KB | 大多低於 2.5s |
| 每區塊最大 Blobs (Pectra, 9×128KB) | ~1,152 KB | 97.1% 低於 4s (家庭節點) |
| 組裝後的解密密鑰 | 48 位元組 | — |
| 完整 Keyper 份額集 (100 個 Keyper) | 4.8 KB | — |
解密密鑰比典型區塊小 ~2,300 倍。在以太坊的 gossipsub（D=8, ~6 跳）上，小消息在 ~200-500ms 內傳播——這主要受每跳延遲影響（~70ms × 6 跳 ≈ 最小 420ms），而非頻寬。即使在最壞情況下（100 個獨立密鑰份額，總計 4.8 KB），數據量也僅相當於少數幾個證明消息——對於 Gossip 層來說微不足道。
時序分析 (12 秒 Slot)
證明截止時間約為 Slot 開始後的 4 秒。使用實測傳播數據的時間線：
t=0s: Slot 開始。建構者擁有來自前一 Slot 的密文 + 區塊模板。
識別選擇同 Slot 的 STs（透過 decryptor_address）。
簽署經濟承諾。
t=0.5-1s: Keyper 向建構者釋放密鑰 + 開始公開廣播。
（48 位元組組裝密鑰，~1KB 份額。Gossip：~200-500ms。）
t=1-2s: 建構者在本地解密（~50-200ms），插入區塊頂部，
重新計算狀態根（~500-800ms）。
t=2-2.5s: 區塊發布（~110KB）。密鑰已傳播約 1.5-2s ——
可能在區塊到達之前就已到達大多數節點。
t=2.5-3.5s: 區塊傳播（典型為 1-3s，根據 ethPandaOps）。
密鑰已於 2s 前到達。
t=3.5-4s: EL 客戶端使用已收到的密鑰驗證 decrypted_transactions
（~200-500ms）。
t=4s: 證明截止時間。
密鑰在區塊之前到達。 在 48 位元組的大小下，密鑰 Gossip（~200-500ms）比區塊傳播（~1-3s）更快完成。到證明時間時，密鑰已在本地。這反映了 Blob 的行為；在 Dencun 之後，35.5% 的 Blob（每個 128KB）在 Slot 開始前就已到達。解密密鑰比這小 ~2,700 倍。
多建構者密鑰分發
在 ePBS 中，每個 Slot 有多個建構者競爭。如果建構者 A 承諾並收到密鑰但建構者 B 獲勝，建構者 A 持有的是已經在鏈上確認並排序的交易明文。排序已敲定且狀態已更新，建構者 A 無法追溯性地重新排序或搶跑。在下一個 Slot 中，這些 STs 已經執行；明文不具備殘餘的排序優勢。（無論如何，建構者 A 始終可以透過 FOCIL ILs 訪問密文。）
密鑰可以安全地釋放給所有已承諾的建構者，提供冗餘：如果獲勝的建構者掉線，另一個已承諾的建構者可以介入。
4. 6 秒及更短的 Slot
隨著以太坊轉向更短的 Slot 時間，證明窗口會被壓縮。在 6 秒 Slot（證明在 ~t=2s）中，區塊傳播 + 驗證餘裕縮減至 ~0.5-1s。密鑰傳播（48 位元組，~200-500ms）仍然適用，但區塊驗證時序成為限制因素。
樂觀驗證
對於更短的 Slot，最自然的方法是：證明者接受 decrypted_transactions 而不進行獨立的實時驗證。正確性透過異步方式強制執行，任何一方都可以在挑戰窗口內證明解密錯誤，從而觸發建構者罰沒。
這將密鑰驗證完全從關鍵的證明路徑中移除。建構者的經濟承諾已經保證了包含；樂觀驗證將相同的經濟安全模型擴展到解密正確性。這種模式與樂觀 Rollup 類似：先接受，後證明欺詐。
值得注意的是，這種壓力並非同 Slot 獨有。6 秒 Slot 下的 N+1 解密面臨同樣的限制；驗證前一 Slot 的 STs 仍然需要在壓縮的窗口內使用密鑰和計算。隨著 Slot 時間減少，樂觀驗證可能成為 LUCID 的通用優化，無論是否採用同 Slot。
其他方法
隨機抽樣（受 PeerDAS 啟發）：每個 Slot 由一組輪換的證明者子集進行完整驗證；其他人信任該子集簽署的確認。解密密鑰（48 位元組）和密文遠小於 Blob 單元（~2 KB），因此每個證明者的成本微不足道。
專用委員會：一個較小的質押委員會，與 Keyper 直接連接進行預驗證，類似於同步委員會（Sync Committee）。輪換並受罰沒約束。
這些方法並非同 Slot 專有——它們透過在 Slot 時間減少時減輕證明負載，同樣使 N+1 受益。
5. 建構者博弈論
區塊頂部（ToB）是區塊中最具價值的房地產（CEX-DEX 套利）。為什麼建構者會自願將解密後的 STs 放在那裡？
在 LUCID 的穩定狀態下，每個建構者都會從前一個 Slot 繼承解密後的 STs 並放在區塊頂部——這是透過 FOCIL 強制的，無法避免。區塊頂部在每個 Slot 中都已經被佔用了。問題不在於是否發生佔用，而在於建構者是否為此獲得補償。
| 比較項 | N+1 模式 | 同 Slot 模式 |
|---|---|---|
| 區塊頂部被解密 STs 佔用？ | 是 —— 來自前一 Slot | 是 —— 來自當前 Slot |
| 建構者從佔用中獲益？ | 否 | 是 —— 來自完整明文可見性的回跑價值 |
| 建構者對區塊頂部內容的可見性？ | 部分 —— 密鑰在 Slot 之間到達 | 完整 —— 密鑰在區塊構造前到達 |
| 繼承自前一建構者的 Slot？ | 總是 | 減少 —— 在完全採用的均衡下消除* |
佔優策略。 同 Slot 解密的區塊頂部佔用成本與 N+1 相同（相同的 STs 佔據相同的位置）。建構者向 Keyper 委員會支付早期密鑰訪問費用，但在區塊構造時獲得了完整的明文可見性——從而實現最優的回跑放置和更緊湊的區塊組合。來自完整信息的回跑價值超過了密鑰訪問成本。同樣的佔用，更好的區塊。
協調均衡。 如果所有建構者都採用同 Slot，則沒有人會繼承前一 Slot 累積的解密交易。每個建構者僅在區塊頂部處理自己 Slot 的 STs——這比 N+1 的可變繼承更乾淨、更可預測。
價格發現與防作弊
建構者是否可以支付過低費用並捕獲所有回跑價值？不——價格發現是透過 ePBS 區塊拍賣競爭實現的，而非密鑰支付。擁有解密明文的建構者能構建更有價值的區塊（最優回跑、更精確的 Gas 估算、完整的狀態知識）。這個區塊會以更高的出價更頻繁地贏得提議者的拍賣。跳過密鑰支付的建構者是在盲目構建，產出的區塊競爭力較低。
Keyper 委員會設定最低支付門檻——這是服務費，而非投機性拍賣。實際的價值提取流入 ePBS 出價，而非密鑰支付。ePBS 競爭確保沒有建構者能在不被同樣擁有密鑰且出價更激進的建構者擊敗的情況下，私吞全部盈餘。FOCIL 強化了這一點：選擇不是「包含或排除」，而是「帶領完整信息構建或盲目構建」。
6. 權衡
同 Slot 解密並非在所有方面都優於 N+1。它引入了權衡。
收益
減少約 12 秒延遲，適用於對時間敏感的交易——DeFi 交易、清算、條件執行。
更強的執行保證。 同 Slot 執行意味著交易針對當前 Slot 的狀態進行結算，而非漂移了 12 秒的狀態。這減少了交易失敗、意外回滾和過時價格執行——特別是對於清算和限價單，N 和 N+1 之間的狀態變化可能會使交易完全失效。
用戶選擇。 在創建交易時透過 decryptor_address 選擇速度，抽象為錢包開關。支付小額 decryptor_fee；建構者支付時間溢價。
激勵對齊。 在 N+1 中，建構者在無補償的情況下承擔區塊頂部佔用。同 Slot 補償所有參與者：建構者獲得完整明文可見性（回跑價值、更精確的 Gas 估算、最優組合）；Keyper 賺取基礎費 + 建構者溢價；用戶獲得更快的執行。
成本
壓縮證明窗口。 密鑰傳播從約 12 秒 (N+1) 壓縮到約 3 秒。在實踐中，密鑰（48 位元組，~200-500ms Gossip）在區塊（~1-3s）之前到達——但在更短的 Slot 時間下，餘裕會收緊。
經濟與協議強制執行。 N+1 使用 Slot 邊界（協議保證）。同 Slot 使用經濟罰沒。無論如何，FOCIL 都提供了協議底線。
信任假設轉移。 同 Slot 依賴於 Keyper 的活躍度、罰沒的正確性和抵押品的充足性。任何組件失效 → 延遲退化至 N+1，而非安全失效。
僅限選擇加入
這些權衡僅由選擇它們的參與者承擔。設定標準 decryptor_address 的用戶獲得的正是 LUCID 的 N+1 體驗。不承諾的建構者照常構建 N+1 區塊。在沒有明確選擇加入的情況下，任何參與者的安全屬性都不會改變。
7. LUCID 兼容性
同 Slot 解密可直接映射到 LUCID 現有的規格，僅需一個極小的規格變動。
現有規格掛鉤
LUCID 的 ST 票據（Ticket）已包含 decryptor_address（負責解密的實體）和 decryptor_fee（執行時支付給該實體）。LUCID 對解密者是不可知的：ST 標頭是不透明的，可能包含任何特定於解密者的元數據。
同 Slot Keyper 委員會發布與其 decryptor_address 關聯的 Eon 密鑰（來自 DKG）。想要快速執行的錢包使用這些參數進行加密。委員會透過 decryptor_address 識別其 STs。
經濟學。 兩層結構，使用 LUCID 現有欄位加上協議外支付：
decryptor_fee（L1，用戶支付）：覆蓋 Keyper 運營成本的小額基礎費——DKG、在線時間、N+1 回退。確保無論建構者是否採用，Keyper 都能獲得補償。
建構者密鑰訪問支付：建構者向 Keyper 委員會支付早期密鑰釋放費用。建構者付費是因為完整明文可見性具有競爭價值（第 5 節）。
錢包將此抽象為速度選擇：標準 (N+1) 或快速 (同 Slot)。用戶的 decryptor_fee 在兩種情況下都很小；建構者的支付是主要的收入信號。
唯一的規格變動。 decrypted_transactions 目前引用前一個 Slot。極小的變動：當建構者在構造 ABB 前證明密鑰可用時，允許其同時攜帶同 Slot 的 STs。
MEV 分類對齊
同 Slot 保留了 LUCID 的 MEV 保證。有害 MEV（搶跑、三明治攻擊）仍然被完全防止，因為建構者在承諾前無法看到明文，這與 N+1 相同。回跑得到保留並有所改進：LUCID 明確允許回跑（透過條件 STs 進行 CEX-DEX 套利），而同 Slot 在構建時為建構者提供明文，以便更準確地放置回跑交易。OFA 兼容性和概率性 MEV 燃燒保持不變，因為同 Slot 僅影響建構者何時看到明文，而不影響適用哪些保護措施。
當前狀態
一個類似的概念驗證（PoC）已部署在 Hoodi 測試網上，使用 Shutter 的門檻加密（5 分之 3 Keyper）和質押建構者承諾。它展示了基於承諾條件的密鑰釋放；由事件觸發而非時間觸發，驗證了上述核心機制。這不是 LUCID 或本提案的 1:1 實現，而是一個相鄰的加密內存池 PoC。
下一步：擴展到兼容 LUCID 的 ST 票據格式、ABB 前的承諾觸發器，以及直接驗證時序分析的「承諾到密鑰釋放」延遲基準測試。
代碼庫： github.com/shutter-network/primev-sequencer
總結
N+1 是一個穩健的默認設置。同 Slot 提供了一個可選的替代方案，透過 ABB 前的經濟承諾解決了同樣的循環依賴，以壓縮證明窗口為代價換取更低的延遲、更強的執行保證和建構者補償。兩者是互補的：當條件未滿足時，同 Slot 會回退到 N+1，且在沒有明確選擇加入的情況下，任何參與者的安全屬性都不會改變。
核心技術問題：約 3 秒的密鑰傳播（在 12 秒 Slot 下）是否提供了足夠的證明餘裕？在 48 位元組（比區塊小 2,300 倍，比 Blob 小 2,700 倍）的大小下，傳播數據表明密鑰會在區塊之前到達證明者節點。
待討論的開放問題
LUCID 規格兼容性。 decrypted_transactions 是否嚴格引用前一個 Slot，還是可以攜帶同 Slot 解密的 STs？允許在建構者證明密鑰可用時進行可選同 Slot 執行的最小規格變動是什麼？
更短 Slot 的驗證。 在 6 秒 Slot 下，樂觀驗證似乎最自然——但這應該是同 Slot 特有的，還是能同時使 N 和 N+1 路徑受益的通用 LUCID 優化？
1 則貼文 - 1 位參與者
[閱讀完整主題](https://ethresear.ch/t/same-slot-decryption-for-lucid-optional-n-execution-with-n-1-fallback/24576)