賬戶抽象允許我們使用智能合約邏輯來指定交易的效果，以及費用支付和驗證邏輯。這帶來了許多重要的安全好處，例如多重簽名和智能恢復錢包，能夠在不更換錢包的情況下更換密鑰以及量子安全性。

許多帳戶抽象的方法已在不同程度上被提出並得到了實施，參見：EIP-86、EIP-2938‌，以及兩年前的這篇文章‌。今天，由於開發者們希望專註於合並與分片，這些 EIP 的開發陷入了僵局，而 ERC-4337‌ 這種不需要任何共識更改的替代方案已經取得了很大進展。

ERC-4337 嘗試通過額外的協議手段實現和 EIP-2938 相同的事情。用戶需要發送稱為用戶操作（user operations）的鏈外消息，這些消息由區塊提議者（proposer）或為區塊提議者生成 bundles 的構建者（builder）批量收集並打包成單筆交易。提議者或構建者負責過濾操作以確保他們只接受支付費用的操作。用戶操作有一個單獨的 mempool 存儲池，連接到這個存儲池的節點會進行 ERC-4337 特定的驗證，以確保用戶操作在轉發之前能夠支付費用。

ERC-4337 作為一個純自願的 ERC 可以做很多事情。然而，在一些關鍵領域，它比真正的協議內解決方案更弱：

1、現有用戶如果不將其所有資產和活動移動到新帳戶，則無法升級；

2、額外的 gas 開銷（基本 UserOperation 用戶操作約 42 k，而基本交易約為 21 k）；

3、較少受益於協議內抗審查技術（例如 crLists），它以交易為目標並會錯過用戶操作（user operation）；

而實現最佳效果的一條現實途徑，是在短期內開始大力支持 ERC-4337，然後隨著時間的推移添加 EIP 來彌補其弱點。這並不一定需要大家專門承諾遵守 ERC-4337。相反，可以將協議內支持設計為更通用，並支持 ERC-4337 及其替代方案和改進。

在這裏，我將列出其中的一些 EIP，並說明它們可以按什麽順序實施。

將 EOA 錢包轉換為智能合約錢包

為了讓現有的 EOA 錢包升級到 ERC-4337 錢包，我們可以製作一個 EIP，允許 EOA 執行設置其合約代碼的操作。一旦 EOA 做到了這一點，這種轉變就不可逆轉。從那時起，該帳戶將僅用作智能合約錢包。幸運的是，由於 ERC-4337 帳戶是 DELEGATECALL 代理，因此如果需要，以後可以將錢包轉換為與其他 ERC 兼容的智能合約。

關於如何實施此升級過程有一些提案：

1、「replace code」 交易類型

這還沒有作為正式的 EIP 引入，但方法很簡單：添加一個新的 EIP-2718‌ 交易類型，只需將帳戶碼替換為 calldata。

2、AUTH_USURP (EIP-5003)

EIP-5003‌ 是 EIP-3074‌（AUTH 和 AUTHCALL）的擴展提案，它引入了新的 AUTHUSURP 操作碼。如果使用 EIP-3074 機製，EOA 地址 A 已授權另一個地址 B 代表它行事，則 AUTHUSURP 允許 B 設置 A 的代碼。

這種方法比「replace code」路線更復雜，只有當我們打算采用 EIP-3074 時，這才有意義。

強製轉換

在更長遠的未來，我們可能希望進行強製轉換，以簡化協議，並使合約成為唯一的帳戶類型，從協議中取消 ECDSA。一種可能的方法是添加一個覆蓋規則，從某個區塊開始，沒有 code 的賬戶被視為具有特定標準化「ERC-4337 EOA 錢包」 code 的賬戶。

這可以通過「poking」過程來完成，其中任何源自 EOA 的交易都將其轉換，並且任何觸及具有非零 nonce 的 EOA 交易都會將其轉換。也可以一次性通過整個狀態來完成。

問題

1、合約內 ECRECOVER 驗證：一些智能合約依賴於這樣的假設，即如果你向特定賬戶提供 ECRECOVER 的簽名，你就擁有該賬戶。如果 EOA 轉換為合約，然後更改其驗證密鑰，則原始密鑰仍然能夠在這些特定上下文中「代表」帳戶。這可通過開始鼓勵所有此類項目更改為使用 EIP-1271 驗證，而不是在帳戶有 code 的情況下使用 ECRECOVER。

2、尚未檢測到的賬戶：強製轉換面臨的一個挑戰是擁有資產（如 ERC20 s、ERC721 s，但不是 ETH）但尚未發送或接收任何交易的賬戶，因此協議無法可靠檢測到這些賬戶。協議必須保留將此類賬戶永久轉換為默認錢包的功能，或者需要有一個截止期（例如部署後 4 年），在此之後尚未轉換的帳戶將被燒毀。

3、EOA 只檢查不可轉讓性：一些應用程序實施合約內檢查以僅允許 EOA 與其交互。這通常是為了強製執行不可轉讓性。從根本上來說，這是一個壞主意，並且與轉向智能合約以提高安全性的目標不相容。因此，不應鼓勵這種做法，而應鼓勵應用依賴原所有者恢復程序來使轉移無法執行。

降低 Gas 成本

ERC-4337 錢包面臨更高的 gas 成本（基本 ERC-4337 操作約 42000 gas，而基本常規交易需要 21000 gas），原因如下：

1、需要支付大量的單個存儲讀/寫成本，在 EOA 的情況下，這些成本會捆綁到一筆 21000 gas 的付款中：

（1）編輯包含 pubkey+nonce (~5000) 的存儲 slot；

（2）用戶操作調用數據成本（約 4500，通過壓縮可減少到約 2500）；

（3）ECRECOVER (~3000)；

（4）首次訪問錢包本身 (~2600)；

（5）首次訪問收款人賬戶 (~2600)；

（6）將 ETH 轉入收款人賬戶 (~9000)；

（7）編輯存儲以支付費用（~5000）；

（8）訪問包含代理 (~2100) 的存儲 slot，然後訪問代理本身 (~2600)；

2、除了上述存儲讀/寫成本之外，合約還需要執行 「業務邏輯」（解包 UserOperation、對其進行哈希、洗牌變量等）；

3、需要消耗 gas 來支付日誌費用（EOA 不發布日誌）；

4、一次性合約創建成本（約 32000 gas，加上代理中每個 code byte 200 gas，再加上設置代理地址的 20000 gas）；

其中很多問題將在 Verkle 樹 witness gas cost EIP‌ 以及 write gas cost reform EIP‌ 中自動解決，以更精簡的系統取代大量存儲成本。例如，pubkey 和 nonce 可以存儲在 slot 0…63 中，這將訪問它們的成本降低到 1000 以下。用戶在轉移 ETH 和支付費用時支付的費用會更少，因為目標賬戶和接收賬戶只需要被首次訪問一次。

還有更多的 EIP 可以幫助我們實現簡化。例如：

1、禁止智能合約邏輯使用 slot 0 的自願 ERC，將允許它用於存儲代理，從而使其受益於更便宜的 gas 成本。

2、「code address」字段可以使代理更輕松，消耗的 gas 更少。

3、「snappy compression」預編譯可以更輕松地使用 ABI 對象，而無需為所有零字節支付 calldata gas 成本。

這是一個需要更多研究的領域。

crLists

這是一個長期的問題，因為只有啟用了完全的協議提議者/構建者（proposer/builder）分離方案後，crLists 才真正適用。挑戰在於，我們希望提議者能夠識別「值得」包含的用戶操作（即他們支付足夠的費用），以便協議可以迫使它們被包含在下一個有空間的區塊中。

這要求在協議中明確「驗證」和「執行」的概念。對於用戶操作，必須有一種已定義的方法來驗證該操作，以及有一種已定義的方法來執行該操作，這樣如果某個操作被驗證，則執行該操作的嘗試將是保證支付費用的，除非被讀取的狀態在驗證期間被修改。這些操作可以通過嵌入 ABI 方法來實現，如果實現了 EOF EIP，也可以通過添加專用的 EOF 部分來實現。

幸運的是，這不需要我們把 ERC-4337 當作一個最終標準，而是納入 ERC-4337 所支持的一個較弱概念，其他在很大程度上不同的 ERC 也可以輕松支持它。

原因是，ERC-4337 和 EIP-2938 的復雜性很大程度上與解決更強的 DoS 抗性問題有關：不可能使一個操作取消數百個其他操作，因為這將允許廉價地對 mempool 進行垃圾交易攻擊。這需要對帳戶驗證可訪問的內容施加限製。在這裏，我們可以做一些更簡單的事情：只記錄在驗證過程中觸摸了哪些狀態對象，如果這些狀態對象中的任何一個被編輯，則不需要包含。

這使得個人賬戶可以在審查抵製和靈活性之間選擇自己的權衡。在極端情況下，如果賬戶願意，可以通過 Uniswap 在驗證期間支付費用，但由於任何人都可以發送影響 Uniswap 狀態的交易，因此此類賬戶實際上沒有抗審查保證。

crList 設計的大致輪廓如下：

1、提議可以包含一個 crList，它指定要包含的操作列表，以及每個操作讀取的狀態對象 (key, value）對的列表。接受 crList 的構建者（或其他任何人）必須檢查所有操作是否通過 validate 檢查。

2、執行 crList 中的每個操作都需要該區塊，除非該區塊沒有足夠的剩余 gas，或者執行時的當前狀態已經編輯了該操作讀取的狀態對象之一。

ERC-4337 的剩余復雜性將僅用於 mempool 安全。原則上，可以有多個相互競爭的 ERC 以不同的方式實現該目標，只要它們都遵循相同的驗證和執行標準。

這種方法的一個缺點是它與簽名聚合不完全兼容（正如 ERC-4337 試圖做的那樣）：因為協議不「理解」聚合方案，它不能強製聚合，惡意構建者可能納入未聚合的操作，並迫使發送者為其支付全部 gas。但這種不便可以說是適度的。

可能的路線圖

短期

1、將 ERC-4337 全面投入生產。理想情況下，可以使用簽名聚合功能對其進行擴展，以實現 rollup 友好性。

2、應該有接入 ERC-4337 的易於使用的瀏覽器錢包。

3、考慮實現簽名聚合和壓縮，以使 ERC-4337 對 L2 更加友好；

4、在 L2 協議中引導 ERC-4337 生態，其中 gas 成本問題會較少；

中期

1、實施 Verkle 樹，添加 EIP 以降低 gas 成本；

2、添加可選的 EOA-to-ERC-4337 轉換；

3、在 PBS 推出的同時或不久之後添加 crList 邏輯；

長期

1、考慮強製轉換；

可能的替代方案

1、考慮編寫一個在協議層包含 ERC-4337 等效帳戶和交易的 EIP，並推動其在 L2 中的采用；

2、使用一種通過 axuliary 區塊‌工作的抗審查解決方案，消除用戶操作對以太坊協議的可讀的需要；