智能賬戶加密內存池

由Marc Harvey-Hill @ Nethermind撰寫。特別感謝Ahmad Bitar 、 Aikaterini-Panagiota Stouka 、 Stefano De Angelis 、 Conor McMenamin 、 Lin Oshitani和Julie Bettens的反饋。反饋不一定代表認可。

這篇文章探討了使用智能賬戶來驗證是否遵守加密內存池規則的概念。這可以加強搶先交易保護和審查阻力的保障，以防區塊提議者試圖違反加密內存池規則。

在加密的內存池中，用戶發送加密交易，這些交易在公共約束中發佈在鏈上。這是對下一個提議者的限制，要求他們按預定義的順序（例如按優先費用排序）包含這些交易。在下一個時隙之前，解密密鑰會被顯示出來，以便提議者可以Decrypt幷包含來自公共約束的交易。他們應該按照預定的順序將約束中的所有有效交易包含在他們的區塊頂部，不要事先插入任何可能搶先解密交易的交易。我們關心的是強制提議者遵守這些規則。

智能賬戶可用於防止惡意提議者搶先交易。用戶可以加密ERC-4337智能賬戶交易 (UserOps)，而不是加密普通交易，這些交易會檢查它們是否以正確的順序包含在The Block內的正確索引中（即頂部）。如果檢查失敗，則 UserOp 的主體（例如交換）將不會運行，因此它們不可能被搶先交易。

如果提議者不是惡意的，但離線，它們也可以提供保護。在這些情況下，解密密鑰仍將被洩露，因此現在每個人都可以看到解密的交易。這意味著下一個提議者可以包含這些解密的交易並預先插入他們自己的搶先交易。智能賬戶同樣可以提供保護；作為在 UserOp 開始時執行的檢查的一部分，我們可以驗證 UserOp 是否在其預期的時隙中執行。如果檢查失敗，則 UserOp 的主體將不會運行，因此攻擊不再可能。

為了實現其關鍵屬性，即防止搶先交易和抵制審查，加密內存池應分別執行兩個規則：排序和包含。如前所述，智能賬戶可用於強制執行排序，這意味著交易必須在正確的位置、以正確的順序、在The Block內的正確索引（塊頂部）執行。我們還將探討如何通過防欺詐遊戲來強制執行包含，這意味著如果提議者不包含公共約束中的交易，他們將失去獎勵，並可能被削減。

智能賬戶加密內存池有幾個好處：

• 無條件的搶先交易保護：提議者在任何情況下都不能搶先交易。即使他們離線並且解密的交易被洩露，未來的提議者也不能將其包括在內並搶先交易，因為交易主體不會在未來的時隙中執行。
• 重組安全性：如果發生重組，仍然不可能進行搶先交易。
• 激勵一致性：如果提議者審查任何加密的內存池交易，他們就會錯過所有提示。

背景

作為背景介紹，我推薦我作的這個 5 分鐘演講，其中概述了加密內存池的設計空間。

總結一下：

• 用戶對他們的交易進行加密。
• 加密交易在公開約束下發布在鏈上。下一個時隙的提議者應將所有這些交易按預定義的順序包含在其區塊的頂部。
• 在下一個時段開始之前，“密鑰員”會透露解密密鑰。
• 如果提議者在線，他們就會構建自己的區塊。智能賬戶和防欺詐遊戲可用於強制提議者遵守規則，尊重公共約束。

本設計重點關注第 4 點：如何強制約束中的所有交易都以正確的順序包含在內。我們將探索一種智能賬戶方法，通過強制執行排序和包含規則來緩解惡意和離線提議者的問題。

設計中還有其他重要方面，例如加密機制、密鑰人的性質、公共約束的具體發佈位置等；我不會在這篇文章中介紹這些內容。

加密內存池分類

我們可以根據加密內存池設計對提議者執行排序和包含規則的強度對其進行分類。

第 0 階段 - 受信任

• 完全信任的提議者。
• 排序和包含不強制執行，因此能夠搶先和審查而不承擔任何後果。

第一階段-質押

• 提議者擁有可以被削減的權益。他們可以發佈提議者承諾。
• 如果提議者重新排序或審查，他們的股份可能會被削減。要求提交提議者違反規則的證據。
• 訂單僅可追溯執行，因此仍有可能搶先交易。如果收益超過賭注，則可能發生這種情況。
• 除了削減質押金額外，還可以使用質押來補償用戶。
• 問題：必須削減允許解密交易洩露的離線提議者，即使他們沒有及時收到密鑰。
• 本白皮書探討了第一階段的內存池。它使用了削減和提議者承諾。

第 2 階段 - 智能賬戶

• 由智能賬戶強制執行的排序。
• 提議者在執行之前證明鏈上排序正確。
• 無法搶先執行，如果順序不正確，UserOp 主體將不會執行。
• 如果未滿足納入條件，提議者將失去所有加密的內存池獎勵。也可能像第一階段一樣被削減。

第 3 階段 — 供奉

• 由區塊有效性條件強制執行。
• 如果排序和包含不滿足，提議者就無法構建有效的區塊；這意味著他們將錯過區塊獎勵。
• 必須通過硬分叉將其納入協議中。
• 將需要更長的時間來協調適合供奉的設計。

第 2 階段比第 1 階段的優勢在於無條件的搶先交易保護。第 1 階段搶先交易仍然可能發生，因為它只會在事後受到懲罰；如果獲得的價值超過了削減造成的損失，就會發生搶先交易。如果提議者只是離線，並且他們時隙中的解密交易被洩露，也可能發生搶先交易。在第 1 階段，提議者可能會因此受到削減（如果他們沒有及時收到解密密鑰，這可能是不公平的），而在第 2 階段，這不是問題，因為洩露的交易無法在其預期時隙之外執行。

最終，第三階段將在長期內提供最強大的安全保障，但實際上需要很長時間才能就適合納入協議的設計達成共識。從短期到中期來看，第二階段應該可以提供足夠的保護。

下表總結了加密內存池不同階段的各種執行機制：

請注意，加密內存池的階段並不是其安全性的唯一因素，這還取決於其他方面，例如密鑰機制。

設計

我將介紹一種使用智能賬戶和防欺詐遊戲對提議者強制執行排序和包含規則的設計。在探索細節之前，我們將首先從高層概述其工作原理開始：

• 用戶創建並加密 UserOps。這些 UserOps 指定它們應在哪個 slot 中執行（即下一個 slot）。
• 加密的 UserOps 被包含在公共約束的鏈上。
• 在下一個 slot 開始時，解密密鑰將被廣播，提議者將解密其 slot 的 UserOps。他們開始構建自己的區塊（他們可以使用 MEV-boost，這將在PBS 部分中討論）。
• 提議者創建“排序聲明”。此聲明是提議者聲明哪些交易處於公共約束中以及應如何根據內存池規則對其進行排序。他們還可以聲明某些解密的 UserOps 無效，因此不包括它們。
• 提議者將所有（有效）解密的 UserOps 捆綁到單個 ERC-4337 交易中。排序聲明應作為調用數據傳遞到此交易中。
• 提議者應該將此捆綁交易包含在其區塊的頂部。
• 驗證檢查是作為此捆綁交易的一部分在鏈上進行的。可以驗證排序聲明是否滿足公共約束，然後可以驗證每個 UserOp 是否遵循排序聲明。
• 如果檢查通過，UserOp 主體將被執行，否則檢查完成後它們將停止，並且主體將不會執行。
• 提議者可能錯誤地聲稱某些有效交易無效；這就是使用欺詐證明遊戲的地方。交易提示被鎖定一段時間，在此期間任何人都可以提供證據證明提議者就某筆交易無效撒謊。提議者將無法收取獎勵，並可能被削減。

該流程如下圖所示：

概述3366×1560 267 KB

現在我們將通過一個示例逐步瞭解該設計在實踐中的運作情況，然後更詳細地探討該過程的不同部分。

例子

三個用戶有他們想要通過加密內存池執行的 UserOps。這些 UserOps 的哈希值為 0xa、0xb、0xc。用戶加密他們的 UserOps 並將其發送到加密內存池。

約束690×960 23.5 KB

加密的 UserOps 包含在鏈上以 blob 或 calldata 形式發佈的公共約束中。除了密文之外，還會顯示底層 UserOps 的哈希值，以及這些哈希值屬於明文 UserOps 的證明。

在下一個時段開始之前，密鑰生成者會透露 UserOps 的解密密鑰；提議者現在必須構建一個排序聲明。

聲明780×957 26 KB

在此示例中，加密的內存池按優先級費用進行排序。提議者為每個 UserOp 提供優先級費用證明並對其進行相應排序。提議者還聲明哈希值為 0xa 的 UserOp 對預設狀態無效。提議者現在必須構建其區塊。

塊966×1407 26.1 KB

提議者將有效的 UserOps 捆綁到單個交易中，並將其包含在The Block頂部。在此交易中，首先驗證排序聲明。接下來，以正確的順序執行有效的 UserOps 0xb 和 0xc。對於每個用戶，在執行主體之前，首先進行驗證檢查。

由於提議者聲明哈希值為 0xa 的 UserOp 無效，因此他們沒有將其包括在內。但是，現在任何人都可以提交證明 0xa 確實有效並索取提議者對此時隙的小費。

訂購聲明

一旦 UserOps 被解密，提議者必須首先在 calldata 中發佈“排序聲明”。這是提議者聲明為正確排序的 UserOp 哈希列表。一旦根據公共約束證明此列表正確，每個 UserOp 就可以使用它來檢查它是否已包含在正確的順序中。

訂貨聲明應當：

（1）尊重內存池的排序規則，例如按優先費用或FCFS排序。
（2）不包含原始約束中不存在的任何 UserOps。
（3）聲明約束中的哪些 UserOps 對預狀態無效。

我們可以通過將聲明與在 blob 或 calldata 中發佈的公共約束進行比較來立即驗證 (2)；提議者可以根據 blob KZG 承諾證明約束的內容。公共約束應公開 UserOps 的哈希值（用戶可以在提交時證明哈希值）；然後可以將這些哈希值與排序聲明進行比較，以確保不存在原始約束中未包含的哈希值。

我們還可以通過將排序聲明與公共約束中的哈希列表進行比較來立即驗證 (1)。在 FCFS 的情況下，列表應該相同。對於優先費用排序，提議者必須為每個 UserOp 提供優先費用的額外證明。

聲明 (3) 允許提議者聲稱某些 UserOps 無效，因此不需要包含在內。提前證明這一點的成本非常高，因此可以在防欺詐遊戲中事後驗證。我們將在包含部分進一步闡述這一點。

一旦 (1) 和 (2) 在鏈上得到證明，排序聲明現在就可以在 UserOp 排序檢查中使用。

訂購

在執行 UserOp 主體之前，必須進行檢查以驗證：

• UserOp 正在正確的位置執行，與排序聲明相匹配。
• 當前插槽與 UserOp 中包含的插槽匹配。可以使用 SLOT 預編譯來檢查。
• 捆綁交易在區塊頂部執行。可以使用 TXINDEX 預編譯進行檢查。
• 先前的 UserOp 均未通過驗證檢查。

只有在驗證了這些內容後，UserOp 的主體才會被執行。如果任何檢查失敗，則 UserOp 主體以及後續 UserOp 的主體都無法執行；提議者將無法領取任何獎勵，並且可能會被削減。

包容性

欺詐證明遊戲用於驗證提議者未審查任何有效的公共約束交易。提議者小費累積在智能合約中，並保留一段時間。在此期間，任何人都可以提交 zk 證明，證明提議者聲明無效的 UserOp 確實對預設狀態有效。提交此證明的任何人都可以從該位置索取提議者小費，提議者也可能被削減。可以燒掉一定比例的獎勵，以阻止提議者自己提交欺詐證明（如果沒有削減）。如果在挑戰期內未提交任何挑戰，則提議者可以索取所有小費。

另一種設計可以強制提議者提前提供無效交易的證明。由於生成這些證明的成本很高，這可能會導致對提議者的惡意攻擊，因此我建議使用欺詐證明遊戲。

注意事項

依賴項

此提案依賴於EIP-7793 ，即 TXINDEX 預編譯；無需進行其他共識級別更改。需要有交易索引才能檢查捆綁交易是否在區塊頂部執行。

EIP-7843 ，即 SLOT 預編譯，是一種軟依賴。通過此預編譯，我們可以驗證當前 slot 是否與 UserOp 中指定的 slot 匹配。它不是嚴格依賴，因為 UserOp 可以包含一個與 TIMESTAMP 操作碼進行檢查的時間戳。這種方法有效，但不太具有前瞻性，因為如果 slot 長度發生變化，就需要更新它。

ERC-6900模塊化智能賬戶可能比標準 ERC-4337 賬戶更可取。這些賬戶支持預執行鉤子的實現，可用於在執行主要 UserOp 主體之前運行檢查。

重組安全

為了重組安全，解密的 UserOps 必須在發佈公共約束的時隙之後立即執行。要理解這一點，請考慮如果我們在時隙 x 中在鏈上發佈約束，並在時隙 x+2 中包含解密的 UserOps，會發生什麼情況。攻擊者可以等到 UserOps 在時隙 x+2 中解密，然後重組鏈以在時隙 x+1 中包含包含搶先交易的區塊。

一旦實現單槽最終性，這一要求就會被取消。

洩露意圖

假設用戶正在通過加密的內存池將代幣 X 大額兌換為代幣 Y。該時隙的提議者處於離線狀態，因此解密的 UserOp 會向所有人公開。正如所討論的那樣，該兌換不能包含在未來的時隙中，因為 UserOp 的主體不會在未來的時隙中執行，因此無法進行搶先交易。但是，用戶進行兌換的意圖已被洩露，因此其他人可能會在用戶重新提交兌換之前買下代幣 Y，從而有效地搶先交易用戶。

目前尚不清楚這種攻擊是否可靠。例如，交易可能是故意洩露的，目的是操縱市場並提高代幣 Y 的價格。

在某些情況下，這可能是一個更大的問題，例如，如果使用加密的內存池提交交易以註冊ENS名稱。儘管從技術上講，交易不能被搶先執行，但洩露註冊名稱的意圖可能是一個不可接受的風險。

哈希或承諾

為簡單起見，我建議公共約束應顯示純文本 UserOps 的哈希值，以便可以在鏈上將它們與排序聲明進行比較。這種方法會破壞加密機制的安全性，因為哈希值是確定性的，這會使加密方案不安全，無法抵禦選擇純文本攻擊。

我們可以使用不會洩露明文信息的承諾來代替哈希。我們可以使用Lee et al., 2019和Campanelli et al., 2019中的技術，將加密方案與承諾相結合。

EOA 支持

利用EIP-7702，可以通過將ERC-6900代碼部署到 EOA 地址來為 EOA 帶來相同的功能。

提議者建造者分離

到目前為止，我們假設提議者將在本地構建The Block，但設計仍然可以與MEV-boost或ePBS配合使用。提議者可以照常構建捆綁交易，並通過約束 API請求構建者將其包含在The Block頂部。

結論

我已經概述了一種加密內存池最大程度免信任執行機制的設計，該機制需要的共識級別更改最少。這為防止搶先交易和審查提供了強有力的保障。未來的文章將更詳細地探討設計的其他部分，例如公共約束。