本帖用於討論以太坊增強型提案 (EIP) ，該提案旨在為以太坊添加一個與加密方案無關的加密內存池（提案編號待定）。以下是提案全文：
抽象的
該EIP提議將加密內存池（mempool）集成到協議中。它允許用戶在交易被打包到區塊之前對其進行加密，從而保護交易免受搶先交易和夾層攻擊，並增強抗審查能力。該設計與加密技術無關，支持任意解密密鑰提供者，例如基於Threshold加密、多方計算委員會（MPC）、閾值加密（TEE）、延遲加密或全同態加密（FHE）方案。即使解密密鑰提供者失效，傳統的明文交易仍然得到支持，鏈的傳輸也能得到保證。
動機
此增強型集成方案 (EIP) 的目標是防止用戶遭受惡意交易重排序攻擊，並提高協議的實時（“弱”）抗審查能力。它還旨在通過暫時隱藏區塊構建者和其他協議參與者的信息來降低他們的監管風險。此方案的目標並非提高用戶隱私（例如交易保密性），因為交易最終都會公開。
該提案基於先前的工作，例如Shutterized Beacon Chain和已部署在Gnosis Chain上的加密內存池的實時、非協議實現。它解決了長期存在的搶先交易問題，並有可能緩解 MEV 帶來的有害次生影響，例如構建者中心化。該設計也與既定的提案者-構建者分離機制 (ePBS) 自然契合，使其成為以太坊路線圖的合理延伸。
規格
在執行層，部署了一個名為密鑰提供者註冊表的合約。它允許任何賬戶註冊密鑰提供者，併為其分配一個唯一的 ID。註冊需要指定一個包含解密函數和密鑰驗證函數的合約，這兩個函數都接受以字節字符串形式存在的密鑰 ID 和密鑰消息。此外，密鑰提供者可以將其他提供者指定為直接受信任，從而形成一個有向信任圖。我們定義密鑰提供者 A 信任另一個密鑰提供者 B 當且僅當該圖中存在從 A 到 B 的有向路徑。信標鏈在其狀態中複製密鑰提供者註冊表，類似於處理信標鏈存款的機制。
加密交易作為一種新的交易類型被添加進來。它們由信封和加密有效載荷組成。信封包含信封隨機數、gas 值、gas 價格參數、密鑰提供商 ID、密鑰 ID 和信封簽名。加密有效載荷包含有效載荷隨機數、值、調用數據和有效載荷簽名。
在一個有效的區塊中，任何使用密鑰提供者 A 的密鑰加密的交易只能位於以下交易之前：
明文交易
使用密鑰提供程序 A 提供的密鑰加密的交易
使用A信任的密鑰提供商提供的密鑰加密的交易。
在每個時隙中，當密鑰提供者觀察到構建者發佈的執行有效載荷時，他們會收集所有以其密鑰提供者 ID 尋址的加密交易信封中引用的密鑰 ID。對於每個密鑰 ID，他們必須發佈相應的解密密鑰或密鑰保留通知。相應的消息引用信標區塊哈希值，以防止在未來的時隙中發生重放攻擊。他們可以在觀察到執行有效載荷後立即發佈，也可以延遲到時隙的稍後時間發佈。
有效載荷及時性委員會 (PTC) 的成員必須監聽所有加密交易中引用的解密密鑰，這些密鑰由密鑰提供者 ID 和密鑰 ID 字段標識。他們必須使用註冊表合約中指定的驗證函數來驗證這些密鑰，並對每個密鑰設置一個硬編碼的較小 gas 限制。最後，他們必須在有效載荷證明消息中證明每個加密交易是否存在有效密鑰，為此，有效載荷證明消息擴展了一個專用的位域。
在執行有效載荷處理過程中，所有明文交易處理完畢後，加密交易的信封將作為批次執行。此操作會更新信封簽名者的隨機數，並從信封賬戶支付費用。該費用涵蓋信封、解密有效載荷和解密密鑰所佔用的區塊空間成本，以及解密和密鑰驗證過程中使用的計算成本。隨後，使用密鑰提供者註冊表中的解密函數，根據密鑰提供者 ID 和信封上的密鑰 ID 指定的密鑰對加密有效載荷進行解密。如果解密成功，則根據信封上指定的 gas 限制以及The Blockgas 限制執行生成的有效載荷交易。如果解密或執行失敗（包括 PTC 確認解密密鑰缺失的情況），則跳過該交易，而不回滾信封。
理由
密鑰提供商註冊
註冊過程與加密技術無關，以確保協議的中立性，最大限度地降低新密鑰提供者的准入門檻，並使用戶能夠根據自身需求選擇最佳方案。執行層合約被選為指定任意執行邏輯的規範方式。完全基於執行層合約的註冊也是一種合理的替代方案。
許多加密方案在EVM中表達效率低下，因此需要專門的預編譯程序。然而，添加這些預編譯程序超出了本EIP的範圍。
密鑰提供商信任圖
發送加密交易的用戶不僅必須信任自己的密鑰提供者，還必須信任區塊中先前交易所使用的任何密鑰提供者（參見“安全注意事項”）。雖然協議應該尊重用戶的信任偏好，但如果每個用戶只信任自己的密鑰提供者，那麼構建者就只能在每個區塊中包含使用單個密鑰提供者的密鑰加密的交易。這是不可取的，因為它會使市場份額較小的密鑰提供者難以競爭，並有可能形成密鑰提供者壟斷。
另一方面，要求用戶明確聲明他們信任哪些第三方密鑰提供商會增加交易規模開銷，並且由於可能需要滿足大量相互衝突的用戶偏好，也會使區塊構建更加困難。作為一種折衷方案，本提案要求密鑰提供商做出選擇。用戶通過使用密鑰提供商的密鑰，即表示默認同意此方案。
有了這種解決方案，即使出現由單一主導密鑰提供商組成的準壟斷，並且該密鑰提供商沒有指定任何其他密鑰提供商為可信的，構建者仍然可以包含使用其他小型密鑰提供商的交易，而不會產生機會成本，只要小型密鑰提供商信任主要的密鑰提供商（並且可能彼此信任）。
交易指令
該方案有效地將區塊分為明文交易部分和加密交易部分。明文交易放在前面，使構建者能夠完全模擬該部分的執行過程，並應用現有的區塊構建技術和MEV提取策略。因此，構建者可以將加密交易附加到The Block末尾而無需付出機會成本。如果順序顛倒，加密交易的費用必須大幅提高，才能使包含加密交易的區塊在PBS拍賣中與僅包含明文交易的區塊相比具有競爭力。
交易執行
協議和構建者必須避免包含最終無法支付 gas 費用的加密交易。為了確保無論區塊中任何加密有效載荷的內容如何，費用支付都包含在明文信封中，並且區塊中的所有信封都會在任何加密有效載荷之前執行。為了保證構建者和協議在區塊構建時收到的費用金額，不會支付 gas 退款。
為簡便起見，加密後的有效載荷包含簽名。另一種更高效但私密性稍差的方法是將信封簽名者視為發件人。
解密密鑰扣留
該協議明確允許解密密鑰提供者在自行選擇的條件下扣留解密密鑰。這使得他們能夠安全地實施規則，限制哪些用戶可以使用哪些密鑰，例如基於先前的付款情況，並防止密鑰 ID 搶先攻擊（參見“安全注意事項”）。另一方面，被無正當理由扣留的密鑰可用於自定義懲罰機制和可靠性指標（請注意，該協議會記錄哪些密鑰存在、哪些密鑰曾經存在以及哪些密鑰不存在）。
缺乏協議內密鑰提供者激勵機制
該提案並未規定密鑰提供者的收費機制，也未規定對不當行為的懲罰措施。這使得鏈下可以實施多種激勵模式。例如，密鑰提供者可以與構建者達成協議，按交易量向用戶付費，或者作為公共物品運營。他們也可以接受因無正當理由扣留密鑰以提升服務吸引力而受到的懲罰。
執行有效載荷加密
未來的 EIP 可能會提議允許構建者使用密鑰提供者的密鑰來加密執行有效載荷。這樣一來，構建者就可以在構建完成後立即發佈執行有效載荷，而無需等到 50% 的區塊進度才發佈。這將提高點對點效率，並防止構建者因系統崩潰而錯過區塊進度。此外，如果構建者附加一個關於區塊中使用了哪些密鑰的零知識證明，則密鑰披露時間窗口可以更早開始，從而延長。為了儘量降低複雜性，本 EIP 未包含此功能。
向後兼容性
該提案對協議的執行層和共識層進行了不向後兼容的更改。
安全考量
可信密鑰提供商
用戶必須信任他們用來加密交易的密鑰提供商。
不要提前發佈解密密鑰，否則會遭到搶先攻擊和夾擊攻擊。
不要過早發佈解密密鑰，以免在支付信封費用之前阻止交易執行。
關鍵提供商可以通過加密機制（例如，Threshold加密、硬件加密）、經濟機制（例如，對不當行為進行懲罰）、治理機制（例如，投票選擇具有社會聲譽的實體）或這些機制的組合來贏得這種信任。
在較小程度上，用戶需要信任區塊中所有在其交易之前使用的加密交易的密鑰提供者。這是因為密鑰提供者可以選擇發佈或隱藏解密密鑰，並在觀察到後續交易的解密密鑰後獲取這些密鑰。這種選擇賦予了他們對後續交易的初始狀態一定的影響力。惡意選擇的“解密”方案可能會使這種攻擊更加強大，因為它允許使用精心構造的解密密鑰直接修改解密結果的特定部分，或者直接設置解密結果。這實際上實現了搶先交易。
用戶無需信任其交易之後任何交易所使用的密鑰提供者，因為用戶交易有效載荷的初始狀態不受後續交易有效載荷的影響（僅受其信封影響，但信封是在任何解密密鑰發佈之前選擇的）。同樣，明文交易的用戶也無需信任任何密鑰提供者（但他們仍然需要信任密鑰構建器）。
重組
解密密鑰會在相應的加密交易最終完成之前發佈。因此，在鏈重組的情況下，即使交易未必包含在鏈中，它也可能被公開。然而，由於解密密鑰消息包含The Block哈希值，因此可以通過密鑰驗證功能使其失效。這不會阻止信封交易被包含，但會阻止其執行，從而防止有效載荷的搶先執行。
關鍵ID領先運行
當用戶使用特定密鑰 ID 加密交易時，其他用戶可以在交易進行過程中觀察該交易，並創建另一個指定相同密鑰提供者和密鑰 ID 的加密交易。如果第二個交易包含在比原始交易更早的區塊中，即使原始交易尚未被包含在區塊中，不知情的密鑰提供者也會洩露密鑰，從而洩露原始交易。
密鑰提供商可以保護用戶免受此類攻擊。一種可行的策略是“命名空間化”密鑰 ID：提供商僅發佈以信封簽名者地址為前綴的密鑰 ID 的密鑰，並保留所有其他密鑰 ID。由於我們可以合理地假設攻擊者無法訪問信封簽名者的帳戶，因此攻擊者將無法生成具有正確命名空間密鑰 ID 的交易。
關鍵提供者-兒童建造者勾結
為了構建一個新區塊，構建者需要知道前一個區塊的後續狀態，因此也需要知道區塊中使用的所有解密密鑰以及哪些密鑰被隱藏。一旦 PTC 驗證，這些信息就會公開。然而，惡意密鑰提供者可以與區塊構建者串通，提前告知他們這些信息。這將使構建者獲得競爭優勢，因為他們可以更早地啟動The Block構建過程。
由於有效載荷證明發布到區塊槽結束之間的時間仍然足夠長，足以完成區塊構建，因此該攻擊的影響被認為較低。此外，The Block構建週期的開始遠不如結束階段重要（因為只有在結束階段才能得知所有可包含的交易），而結束階段不受此次攻擊的影響。同時，延遲發佈解密密鑰會帶來密鑰未被 PTC 驗證的風險，從而抵消攻擊者的競爭優勢。最後，如果使用惡意密鑰提供者的加密交易數量較少，它們對狀態樹的影響也可能很小。這意味著，不依賴於狀態樹全部信息的樂觀區塊構建策略可能是可行的，從而可以抵禦此次攻擊。
