Vitalik ：以太坊的賬戶抽象之路

注：原文作者是以太坊聯合創始人Vitalik Buterin。

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

許多帳戶抽象的方法已在不同程度上被提出並得到了實施，參見：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 區塊‌工作的抗審查解決方案，消除用戶操作對以太坊協議的可讀的需要；