首頁

Partnered With:

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

Vitalik Buterin

閱讀本文需 16 分鐘

實現最佳效果的一條現實途徑，是在短期內開始大力支持ERC-4337，然後隨著時間的推移添加EIP來彌補其弱點。

原文標題：《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 可以做很多事情。然而，在一些關鍵領域，它比真正的協議內解決方案更弱：

-現有使用者如果不將其所有資產和活動移至新帳戶，則無法升級；

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

- 較少受益於協議內抗審查技術（例如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 交易都會將其轉換。也可以一次通過整個狀態來完成。

問題

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

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

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 可以幫助我們簡化。例如：

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

「code address」欄位可以讓代理更輕鬆，消耗的 gas 更少。

「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 設計的大致輪廓如下：

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

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

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

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