以太坊有兩種類型的帳戶：外部擁有帳戶（EOA）和合約帳戶（CA）。 EOA 由私鑰控制，而 CA 由其中包含的智能合約代碼控制。EOA 一直比 CA 擁有更高的特權，因爲只有 EOA 才能通過支付 Gas 來啓動交易執行。帳戶抽象（AA）是一個允許合約成爲“頂級”帳戶的提案，就像 EOA 一樣，可以支付費用並開始交易執行。

AA的動機在於顯著改善用戶與以太坊區塊鏈的互動體驗，涵蓋了各種場景，如錢包、混幣服務、去中心化應用（ÐApps）和 DeFi。AA爲以太坊提供了一個基礎層功能，用於決定何時可以支付 gas 費用，這也對誰支付 gas 以及如何支付 gas 產生了影響。

Status Messenger 應用捆綁了一個以隱私爲中心的即時通訊應用，以太坊錢包和 Web3 ÐApp 瀏覽器。Status 錢包目前是一個外部擁有帳戶（EOA）錢包，這限制了我們提供的富有用戶體驗，只有智能合約錢包才能提供，如多重籤名安全、社交恢復、速率限制、地址允許/拒絕列表和無 gas 的元交易。然而，智能合約錢包的用戶體驗今天受到波動的 gas 價格嚴重影響，這個問題並沒有被第三方中繼有效解決。AA旨在解決這個問題。

在本文中，我們闡述了在智能合約錢包背景下需要帳戶抽象的原因。然後，我們深入探討了AA的主要方面，描述了協議的更改以及對節點的影響。最後，我們討論了一些提議的擴展，並對與以太坊進行接口的 Status 項目的計劃路線進行了合理化。因此，這些項目可能會受到AA的影響。

歷史與動機

抽象帳戶最初是在2017年作爲EIP-86提出的，旨在實現“交易發起方和籤名的抽象化”，但這一激發思想的起源可以追溯到更早的2016年，當時有人建議：“與其在協議中設立一個機制，將ECDSA和默認nonce方案確立爲唯一的“標準”保護帳戶的方式，不如採取初步步驟朝着一個模型邁進，在長期內所有帳戶都是合約，合約可以支付 gas，用戶可以自由定義自己的安全模型。” 最初的提案被認爲難以實現，因爲需要進行許多協議更改，並滿足安全保證。 最近，Vitalik等人提出了EIP-2938的草案，概述了一種更簡單的實現方式，通過盡量保持協議/共識更改的最小化，並通過節點內存池規則強制執行所需的安全保證。Vitalik的以太坊工程團隊見面會演示和ETHOnline演示（與其他EIP作者之一的Sam Wilson和Ansgar Dietrichs（附帶的文章1和2一起）一起）爲主題提供了很好的介紹。 本文從所有這些來源中着重介紹了最關鍵方面。

動機：AA背後的激發原理非常簡單但是基本的：以太坊交易今天具有可編程效果（通過調用智能合約實現），但它們具有固定的有效性，即僅當交易具有有效的ECDSA籤名、有效的nonce和足夠的帳戶餘額時才有效。AA通過引入一種新的AA交易類型，將交易從固定的有效性升級爲可編程的有效性，該類型始終源自一個特殊地址，協議不需要對其進行籤名、nonce或餘額檢查。 這種AA交易的有效性由目標智能合約確定，在此之後，它可以決定支付此類交易，並施加自己的有效性規則。

那麼，爲什麼這有用呢？我們以以太坊錢包爲例來着重介紹 AA 的好處。

智能合約錢包： 如今大多數以太坊錢包都是 EOA 錢包，它們受到種子短語生成的私鑰的保護。（BIP-39 種子短語或助記詞是從2048個單詞的列表中隨機選擇的12-24個單詞的有序列表。這提供了獲得使用 PBKDF2 函數生成的二進制種子所需的熵。然後使用二進制種子生成BIP-32錢包的非對稱密鑰對。）用戶應將助記詞寫在安全的地方，因爲稍後可能需要它來恢復另一個錢包上的密鑰。然而，此類錢包很容易受到私鑰盜竊或種子短語丟失的影響，從而導致用戶資金損失。

智能合約錢包是通過智能合約在鏈上實現的（顧名思義）。此類錢包通過實施多重籤名安全、社交或基於時間的恢復、交易或金額的速率限制、地址允許/拒絕列表、無gas元交易、批量交易等功能，提供可編程的風險緩解和用戶友好的體驗。

雖然智能合約錢包面臨來自有漏洞的智能合約的安全風險，但通過錢包提供者進行的安全測試和審查可能會減輕這種風險。EOA錢包的風險完全取決於錢包用戶，他們需要保管種子短語的安全，而沒有任何智能合約可能提供的可編程保障。

Argent、Authereum、Dapper、Dharma、Gnosis Safe、Monolith 和 MYKEY都是智能合錢包的案例。從下圖可以看出，這類錢包的採用似乎正在增加。

Argent通過其Guardians的概念實現了無種子的社交恢復功能，Guardians是用戶信任的人或設備，可以幫助用戶恢復錢包。Argent還旨在實現銀行般的安全性（通過特性如每日交易限額、帳戶鎖定和信任聯系人）與Venmo般的易用性（通過使用ENS名稱而不是地址以及支持元交易）相結合。

Gnosis Safe是一個多重籤名智能合約錢包，專注於團隊資金管理，需要團隊成員的最少數量（m-of-n）批準交易才能進行。它還通過元交易實現了無Gas籤名。

所有這些先進的錢包功能都需要使用非平凡的智能合約。錢包用戶要麼需要具備Gas的EOA與其進行交互，要麼依賴於錢包提供者通過提供商的中繼器或第三方中繼器網路（如Gas Station Network）支持元交易。前者通常依賴於經過KYC後在中心化交易所購買的ETH，而後者旨在通過將用戶的負擔轉移到中繼器上，以由提供商在鏈上/鏈下補償或用戶鏈下支付的成本來減少這種入門UX摩擦。

然而，基於中繼器的架構存在三個主要缺點：（1）它們可能被視爲具有潛在審查交易能力的中心化中介；（2）它們在技術上/經濟上效率低下，因爲中繼器交易需要額外的基本Gas費用並且他們需要在Gas費用之上獲取利潤；（3）使用中繼器特定協議迫使應用程序依賴於具有較小用戶基礎和不確定可用性保證的非基礎層以太坊基礎設施。

帳戶抽象將使智能合約錢包能夠接受用戶的無gas元交易並爲其支付Gas費，而無需依賴中繼器網路。因此，這種基礎層功能將顯著改善此類錢包的入門用戶體驗，而不會犧牲以太坊的去中心化保證。

Tornado Cash：一個相關的激勵應用是tornado.cash等混幣服務，@tornado.cash/introducing-private-transactions-on-ethereum-now-42ee915babe0">Tornado通過接受ETH存款並允許稍後由不同地址提取來改善交易隱私，從而打破了地址之間的鏈上關聯。用戶在存款時需要提供一個祕密的哈希，並在提取時提供zkSnark證明以顯示對祕密的了解，而不會透露祕密或早期存款本身。這樣就從提取中斷開了存款。

但是提取存在一個雞生蛋的問題。要從新生成的地址執行提現交易，用戶需要在其中存放一些ETH以支付Gas費。這些ETH的來源（通常是交易所）可能會破壞Tornado的隱私。首選的替代方案是再次使用中繼器網路，但這具有前面提到的缺點。

帳戶抽象將通過允許Tornado合約接受用戶的提取AA交易、驗證zkSnark、從早期存款金額中扣除一些gas費用，然後將剩餘的存款金額轉移到提取地址來解決此問題。

帳戶抽象

EIP-2938 中提出的帳戶抽象允許合約成爲支付費用並開始交易執行的頂級帳戶。這是通過引入協議更改以及新的 AA 事務類型來實現的，該事務類型需要兩個新的操作碼：nonce和PAYGA、內存池規則和擴展的更改以支持高級用法。帳戶類型仍然是兩種（EOA 和合約帳戶），所有提議的更改都向後兼容當前交易、智能合約和協議。

AA 的應用程序分爲兩類：1) 單租戶應用程序，例如智能合約錢包，它爲每個用戶創建一個新合約；2) 多租戶應用程序，例如tornado.cash 或 Uniswap，其中多個用戶與 AA 進行交互同一套智能合約。

多租戶應用程序的AA支持需要更多的研究，並將在未來進行。因此，在本文中，我們將專注於單租戶AA支持。

協議變更

引入了一種新的交易類型，以及兩個支持的操作碼：NONCE 和 PAYGAS。這些是唯一的協議更改。

AA 交易：引入了一種新的 AA 交易類型 AA_TX_TYPE。其有效載荷被解釋爲 RLP([nonce, target, data])，而不是現有交易類型的有效載荷 RLP([nonce, gas_price, gas_limit, to, value, data, v, r, s])。

AA 交易中省略的 gas_price 和 gas_limit 由目標 AA 合約在執行過程中指定。AA 交易中省略的 ECDSA 籤名 v、r、s 被替換爲對數據的特定合約驗證檢查。to 地址被目標合約地址替換。由於所有 AA 交易的發起地址都是一個特殊的 ENTRY_POINT 地址（0xFFFF…FFFF），而不是具有與之關聯的值的 EOA，因此省略了值。

與現有交易類似，通過檢查 tx.nonce == tx.target.nonce 來處理非重復 nonce 的 AA 交易。如果此檢查失敗，則將視交易爲無效，否則會增加 tx.target.nonce 並繼續執行交易。

建議將 AA 交易的基本 gas 成本設定爲 15000，而不是當前的 21000（以反映缺乏內在 ECDSA 籤名的成本節約）。此外，AA 交易沒有固定的 gas 限制。在開始執行時，gas 限制被簡單地設置爲區塊中剩餘的 gas。

NONCE 操作碼：NONCE 操作碼（0x48）將調用方（即 AA 目標合約）的 nonce 推送到 EVM 棧上。因此，nonce 通過 EVM 暴露給了 EVM，以允許對所有交易字段（包括 nonce）進行籤名驗證，作爲 AA 合約中驗證的一部分。

PAYGAS 操作碼：PAYGAS 操作碼（0x49）從棧中取出兩個參數：（頂部）version_number、（次頂部）memory_start。version_number 允許將來的實現更改操作碼的語義。當前，操作碼具有以下語義：

1. 檢查 version_number == 0（否則拋出異常）
2. 讀取 gas_price = bytes_to_int(vm.memory[memory_start: memory_start + 32])
3. 讀取 gas_limit = bytes_to_int(vm.memory[memory_start + 32: memory_start + 64])
4. 檢查 contract.balance >= gas_price * gas_limit（否則拋出異常）
5. 檢查 globals.transaction_fee_paid == False（否則拋出異常）
6. 檢查 AA 執行幀 == 頂級幀，即如果當前的 EVM 執行退出或回滾，則整個交易的 EVM 執行終止（否則拋出異常）
7. 設置 contract.balance -= gas_price * gas_limit
8. 設置 globals.transaction_fee_paid = True
9. 設置 globals.gas_price = gas_price 和 globals.gas_limit = gas_limit
10. 設置當前執行上下文的 remaining_gas = gas_limit - 已經消耗的 gas

在 AA 交易執行結束時，將 (globals.gas_limit - remaining_gas) globals.gas_price 轉移給礦工，而 AA 合約將被退還 remaining_gas globals.gas_price。

PAYGAS 充當 EVM 執行檢查點。在此點之後的任何回滾都只會回滾到此處，然後合約將不會收到退款，而 globals.gas_limit * globals.gas_price 將轉移到礦工處。

新的交易類型和兩個新的操作碼構成了協議/共識級別的更改，它們的語義相對簡單，易於理解。

內存池規則

“內存池是指以太坊節點內部的一組內存數據結構，它在交易被挖掘之前存儲候選交易。Geth 稱之爲“交易池”; Parity 稱之爲“交易隊列”。不管名稱如何，它都是一個存儲在內存中等待被包含在區塊中的交易的池子。可以將其想象成交易等待被接受到區塊中的“等待區”。

目前，由於固定的交易有效性規則，礦工和其他節點在驗證其內存池中的交易時需要的工作量很小，因此可以避免 DoS 攻擊。例如，如果一個交易具有有效的 ECDSA 籤名、有效的 nonce 並且具有足夠的帳戶餘額，礦工就可以確信該交易實際上會支付費用。該礦工內存池中的其他交易可能會使得待處理交易無效，只有當它們來自相同的地址時，並且要麼增加 nonce，要麼足夠減少帳戶餘額。這些條件在計算上是最小的，以便給礦工和節點足夠的信心來考慮區塊或重新廣播。

AA 交易引入了更多的復雜性，因爲它們具有可編程的有效性。AA 交易不支付預付費用，並依賴於它們的目標 AA 合約支付 gas（通過 PAYGAS）。從概念上講，AA 交易處理分爲兩個階段：較短的驗證階段（在 PAYGAS 之前）和較長的執行階段（在 PAYGAS 之後）。如果驗證階段失敗（或拋出異常），則交易無效（就像今天具有無效籤名的非-AA 交易一樣），不會被包含在區塊中，礦工也不會獲得任何費用。

因此，礦工和節點需要一個可預測的機制，以避免待處理的 AA 交易的有效性依賴於內存池中的其他待處理交易。如果沒有，一筆交易的執行可能會使得內存池中的許多/全部 AA 交易無效，從而導致 DoS 攻擊。爲了避免這種情況，有兩個建議在 AA 交易內存池中執行的規則（由礦工和節點執行，但不包括在協議本身中）：

操作碼限制

爲了防止 AA 交易的有效性依賴於 AA 合約本身之外的任何狀態，在驗證階段（即 PAYGAS 之前），以下操作碼被視爲無效：環境操作碼（BLOCKHASH、COINBASE、TIMESTAMP、NUMBER、DIFFICULTY、GASLIMIT）、BALANCE（包括目標本身在內的任何帳戶的餘額）、對除目標或預編譯之外的任何內容的外部調用/創建（CALL、CALLCODE、STATICCALL、CREATE、CREATE2）以及讀取代碼的外部狀態訪問（EXTCODESIZE、EXTCODEHASH、EXTCODECOPY、DELEGATECALL），除非地址是目標。

預計節點會丟棄針對違反此操作碼限制規則的 AA 合約的 AA 交易。這確保了內存池中的有效 AA 交易在 AA 合約狀態不發生變化的情況下將保持有效。

字節碼前綴限制

如果非-AA 交易可以影響 AA 合約的狀態，則會影響內存池中 AA 交易的有效性。爲了防止這種情況發生，AA 交易只能針對在其字節碼開頭具有 AA_PREFIX 的合約，其中 AA_PREFIX 實現了檢查 msg.sender 是否爲 AA 交易的特殊 ENTRY_POINT 地址的檢查。這有效地防止了非-AA 交易與 AA 合約進行交互。

預計節點會丟棄針對沒有在其字節碼入口點具有 AA_PREFIX 的 AA 合約的 AA 交易。

對 AA 合約強制執行的這兩個限制確保：（1）AA 交易的有效性邏輯所訪問的唯一狀態是 AA 合約內部的狀態，（2）此狀態只能由其他針對特定 AA 合約的 AA 交易修改。

因此，對 AA 合約的未執行 AA 交易可能僅通過包含針對同一 AA 合約的另一個 AA 交易的區塊而無效。然而，鑑於這些不是協議/共識更改，礦工可以自由地在區塊中包含違反這些規則的交易。

擴展

上述協議更改和內存池規則允許基本 AA 合約充分且安全地實現智能合約錢包等單租戶應用。其他需要放寬上述規則或需要實現多租戶應用程序的高級用法需要 AA 以擴展的形式提供更多支持，例如：

1. SET_INDESTRUCTIBLE 操作碼，它禁用了 SELFDESTRUCT，並允許 AA 合約在驗證階段安全地調用帶有 DELEGATECALL 的庫。
2. IS_STATIC 操作碼，如果當前上下文是靜態的，則返回 true，並允許非-AA 交易調用者覆蓋之前的字節碼前綴限制，並安全地從 AA 合約中讀取值。
3. RESERVE_GAS 操作碼，當從尋求寫入合約狀態的非-AA 交易中調用 AA 合約時，它爲 AA 合約消耗的 gas 設定了一個下限。這有助於迫使攻擊者消耗最少的 gas 以阻止嘗試使內存池中的任何 AA 交易失效。

還有其他一些，例如多個待處理的交易、緩存驗證結果、驗證的動態 Gas 限制和贊助交易，這些都是支持多租戶應用程序和 zk 證明（如Tornado Cash）所必需的。本文將不做討論。

下一步

帳戶抽象EIP-2938目前處於草案模式，並正在以太坊研究論壇中進行討論。該EIP的下一步是考慮將其納入即將到來的硬分叉之一。EIP的作者顯然正在瞄準柏林之後的硬分叉（柏林的時間表目前尚不清楚，初步計劃於2021年初）。因此，對於EIP-2938來說，該過程仍處於早期階段。

此外，目前還不清楚是否需要將EIP-2938包含在以太坊基礎層第1層（L1）中。鑑於第2層（L2）解決方案的相對靈活性（如我們早期文章中所述），帳戶抽象可以在特定的L2上實現，而無需對整個L1進行升級。然而，即使一些L2實現了自己的AA版本，統一的L1上的AA支持也有好處。因此，尚需觀察AA將在何處以及如何實現。

“帳戶抽象的重要性略有下降，因爲無論L1是否支持，都可以在L2上實現。” —— Vitalik 在他關於以太坊路線圖的文章中提到的關於基礎層仍然重要的事情。

狀態：Status錢包目前是一個EOA錢包，通過捆綁隱私中心的消息傳遞程序以及啓用集成，如在聊天中進行支付或使用Keycard提供增強安全性，它因此與衆不同。智能合約錢包功能，如多重籤名和社交恢復，正在考慮之中，EIP-2938支持將有助於通過消除對中心化和效率低下的基於中繼的架構的依賴，如前文所述。

Status還在評估L2解決方案，旨在支持其錢包中的多個鏈，並爲早期文章中描述的各種用例提供所需的擴展。例如，Keycard正在探索一個支付網絡，其設計要求包括信用卡級別的可擴展性和幾乎即時的終局性，這些要求目前以太坊網路無法滿足。此外，還有許多其他計劃，例如推薦計劃、SNT反應、Tribute-to-Talk和ENS名稱等，所有這些都將受益於L2可擴展性，以實現可行的部署和合理的用戶體驗。如果一個可行的L2解決方案實現了AA，那麼在該L2上構建的項目將能夠利用AA的好處，而無需依賴於L1。

結語

以太坊協議的一個基本方面是，只有外部擁有的帳戶（EOAs）可以支付Gas費用並開始交易執行。合約帳戶（CAs）不能做到這一點。帳戶抽象（AA）是一個提案，旨在改變這種區別，並允許特殊構建的CAs以編程方式檢查新類型的AA交易的有效性，決定代表它們支付Gas費用，從而在不需要EOA的情況下有效地開始它們的執行。

AA對於大大改善用戶體驗具有重要意義，涵蓋了各種情景，例如錢包、混合器、ÐApps和DeFi，而無需依賴於中心化和效率低下的基於中繼的架構。通過引入新的交易類型、兩個新的操作碼和兩個內存池規則，基本的單租戶場景，例如智能合約錢包，可以安全地得到AA的支持。對於高級的多租戶應用程序，例如Tornado Cash，需要對這些協議更改和節點規則進行擴展。

在本文中，我們從智能合約錢包的背景出發，激發了對AA的需求。我們通過描述協議更改和對節點的影響來突出AA的關鍵方面。我們提及了一些用於高級用途的擬議擴展，並最終通過將AA置於當前以太坊路線圖和Status的優先事項的背景中加以定位。

減少摩擦、改善Web3的用戶體驗是這個生態系統中所有項目的重中之重。在未來的工作中，帳戶抽象可能以某種形式會發揮重要作用。

聲明：

1. 本文轉載自【status】。原文標題爲“Account Abstraction (EIP-2938): Why & What”。所有版權歸原作者【Rajeev Gopalakrishna】所有。若對本次轉載有異議，請聯系【Gate Learn】團隊，他們會及時處理。
2. 免責聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。
3. Gate Learn 團隊將文章翻譯成其他語言。除非另有說明，否則禁止復制、分發或抄襲本譯文。