作者 | Rajeev Gopalakrishna
以太坊有兩種類型的賬戶。外部自有賬戶（EOA）和合約賬戶（CA）。EOAs由私鑰控制，而CA由其中包含的智能合約代碼控制。EOAs一直比CA更有特權，因為只有EOAs可以通過支付gas開始交易執行，賬戶抽象(AA)是一個提案，它允許合約像EOA一樣成為一個 “頂層 “賬戶，其可以支付費用并開始交易執行，
賬戶抽象的動機是顯著改善用戶在錢包、DApps和DeFi等各種場景下與以太坊進行交互時的用戶體驗。賬戶抽象在以太坊中提供了一個基礎層的功能，來決定什么時候可以支付gas，以及對誰支付gas等問題，
Status Messenger應用集成了一個以隱私為中心的資訊系統，以及一個以太坊錢包和一個Web3 DApp瀏覽器，Status wallet目前是一個EOA錢包，它限制了我們提供只有智能合約錢包才能提供的豐富的用戶體驗，如多重簽名安全、社交恢復、利率限制、允許/拒絕地址列表和無gas的元交易，目前智能合約錢包的用戶體驗到了gas 費波動的影響，并且第三方中繼器無法有效解決這個問題，而賬戶抽象旨在解決這個問題，
在本文中，我們提出了智能合約錢包背景下對賬戶抽象的需求，然后，我們通過描述協議變化和對節點的影響深入探討賬戶抽象的關鍵方面，最后，我們討論了一些擴展的提議，并通過合理化與以太坊接口的Status項目的計劃路線圖來結束，這些項目可能都會受到賬戶抽象的影響。
歷史&動機
賬戶抽象最初是在2017年以EIP-86的形式提出的，目的是實現 “交易來源和簽名的摘要”，但這一想法的起源可以追溯到更早的2016年。當時有人建議：”與其有一個協議內機制，將ECDSA和默認的nonce方案作為唯一的 「標準 」方式來保證賬戶的安全，不如采取初步措施，建立一個模型，從長遠來看，所有的賬戶都是合約，并且合約可以支付gas，用戶可以自由定義自己的安全模型。”
最初的建議被認為是具有挑戰性的，因為需要改變許多協議并且需要保證安全性。最近，Vitalik等人提出了EIP-2938的草案，該草案概述了一個更容易實現的方法：通過將協議/共識的變化最小化，并通過節點mempool規則強制執行所需的安全保證，由Sam Wilson和Ansgar Dietrichs(另外兩位EIP作者)撰寫的Vitalik的以太坊 Engineering Group Meetup presentation和ETH Online presentation(以及相關文章1和2)為這個主題提供了更詳細的介紹。本文重點介紹了所有這些來源的關鍵內容。
動機：賬戶抽象背后的動機原理非常簡單，但卻是根本性的：今天的以太坊交易具有可編程的效果（通過調用智能合約實現），但它們只具有固定的有效性，即只有當它們具有有效的ECDSA簽名與有效的nonce，并且具有足夠的賬戶余額時，交易才是有效的，賬戶抽象通過引入一種新的賬戶抽象交易類型，將交易從固定有效性升級為可編程有效性。這種賬戶抽象交易類型總是來自一個特殊的地址并且協議不需要對其進行簽名、Nonce或余額檢查。這種賬戶抽象交易的有效性由目標智能合約決定，目標智能合約可以執行自己的有效性規則，之后它可以決定為這類交易付款，
那么，為什么這個很有用呢？我們以以太坊錢包為例來強調賬戶抽象的好處，
智能合約錢包：如今大多數以太坊錢包都是EOA錢包，它由種子短語生成的私鑰保護，(BIP-39種子短語是一個由12-24個單詞組成的有序列表，這些單詞是從2048個單詞中隨機選擇的，這提供了獲得二進制種子所需的熵，該種子使用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簽名，
所有這些先進的錢包功能都需要使用完善的智能合約，錢包用戶要么需要與EOA進行交互，要么依賴錢包提供商通過提供商的中繼器或第三方中繼器網路（如 Gas Station Network）來支持元交易。前者依賴于在KYC后的中心化交易所購買ETH，而后者旨在通過將用戶的負擔轉移到中繼器上，以減少這種上鏈用戶體驗摩擦，其成本由錢包提供商鏈上/鏈下和/或用戶鏈下補償，
然而，基于中繼器的架構有三個主要缺點：(1)它們可能會被認為是中心化的中介機構，有可能會對交易進行審查(2)由于中繼者的交易需要額外的21000基礎gas fee，而且它們的業務需要在gas fee之外獲得利潤，因此在技術/經濟上效率低下(3)使用中繼者專用協議迫使應用依賴非基底層的以太坊基礎設施，其用戶群較小，可用性保證不確定，
賬戶抽象將使智能合約錢包能夠接受用戶的無gas交易，并在不依賴中繼層網路的情況下為其支付gas 費，因此，這種基層能力將極大地改善這類錢包的入駐用戶體驗，而不會犧牲以太坊的去中心化保障，
Tornado Cash：一個相關的動機應用是混幣器，如tornado.cash，其中Tornado通過使用智能合約打破地址之間的鏈上聯系來改善交易隱私，該合約接受ETH存款，隨后可由不同的地址提取。用戶在存款時需要提供秘密的哈希值，之后在提現時提供zkSnark證明，以顯示對秘密的了解，而不泄露秘密或之前的存款本身。這樣就把提現和存款脫鉤了。
但提現存在一個問題，要從新生成的地址中執行提現交易，用戶需要在里面有一些ETH來支付gas。這個ETH的來源（一般是交易所）會破壞Tornado的隱私。首選的替代方案是再次使用中繼器網路，但是它有前面概述的缺點。
賬戶抽象將解決這個問題，允許Tornado合約接受用戶的提現賬戶抽象交易，然后驗證zkSnark并扣除一些gas費（從之前的存款金額中扣除），然后將剩余的存款金額轉到提現地址，
賬戶抽象
EIP-2938號文件提出的賬戶抽象，允許合約成為支付費用和開始執行交易的最高級賬戶。這是通過引入協議變化實現的，新的賬戶抽象交易類型需要兩個新的操作碼：NONCE和PAYGAS，對mempool的規則進行改變以及支持高級用法的擴展，賬戶類型仍然有兩種類型（EOA和合約賬戶），所有擬議的變化都與當前的交易、智能合約和協議向后兼容。
賬戶抽象的應用分為兩個方面考慮：1）單租戶應用，如智能合約錢包，為每個用戶創建一個新的合約 2）多租戶應用，如tornado.cash或Uniswap，多個用戶與同一套智能合約交互，
賬戶抽象對多租戶應用的支持需要更多的研究，建議作為未來的工作，所以我們將在本文中重點討論單租戶賬戶抽象的支持，
協議變化
引入了一種新的交易類型，以及兩個支持NONCE和PAYGAS的操作碼，這些是唯一的協議變化，
賬戶抽象交易：引入了一種新的賬戶抽象交易類型AA_TX_TYPE。它的有效類型被解釋為RLP([nonce, target, data])，而不是現有的交易類型，后者的有效類型是RLP([nonce, gas_price, gas_limit, to, value, data, v, r, s])。
賬戶抽象交易中省略的gas_price和gas_limit在執行過程中由目標賬戶抽象合約指定。賬戶抽象交易中省略的 ECDSA 簽名 v、r、s 由特定合約對數據進行驗證檢查代替。to 地址由目標合約地址代替，之所以省略該值，是因為所有賬戶抽象交易的始發地址是一個特殊的ENTRY_POINT地址(0xFFFF…FFF)，而不是與之相關聯的EOA值，
如果檢查失敗，則交易被認為是無效的，否則，tx.target.nonce將被遞增，交易繼續進行，
賬戶抽象交易的基本gas成本建議為15000，而不是目前的21000（以反映缺乏內在ECDSA簽名所節省的成本），此外，賬戶抽象交易沒有內在gas限額，在開始執行時，gas限值只需設定為該組的剩余gas。
NONCE操作碼：NONCE操作碼(0x48)將被調用者的NONCE(即賬戶抽象目標契約)壓入EVM堆棧。因此，Nonce暴露給EVM，以允許對所有交易字段（包括nonce）進行簽名驗證，作為賬戶抽象合約中驗證的一部分，
PAYGAS操作碼：PAYGAS操作碼(0x49)從堆棧中取出兩個參數: (頂部)version_number, (頂部第二個)memory_start. version_number允許未來的實現改變opcode的語義，目前，該操作碼的語義如下。
檢查 version_number == 0 (否則拋出異常)
提取 gas_price = bytes_to_int(vm.memory[memory_start: memory_start + 32])
提取 gas_limit = bytes_to_int(vm.memory[memory_start + 32: memory_start + 64])
檢查contract.balance >= gas_price * gas_limit (否則拋出異常)
檢查 globals.transaction_fee_paid == False (否則拋出異常)
檢查AA執行框架==頂層框架，即如果當前EVM執行退出或還原，則整個事務的EVM執行終止（否則拋出異常）。
設置contract.balance -= gas_price * gas_limit(限制)。
設置 globals.transaction_fee_paid = True
設置 globals.gas_price = gas_price 和 globals.gas_limit = gas_limit。
設置當前執行上下文的剩余gas=gas_limit-已經消耗的gas。
在賬戶抽象交易執行結束時，（globals.gas_limit – remaining_gas）*globals.gas_price轉移給礦工，賬戶抽象合約退還 remaining_gas * globals.gas_price。
PAYGAS作為EVM執行檢查點。在此點之后的任何還原都只會還原到這里，然后合約不接受退款，globals.gas_limit * globals.gas_price轉移到礦機。
新的交易類型和兩個新的操作碼構成了協議/共識層面的變化，它們的語義是比較容易理解。
Mempool規則
“Mempool “指的是以太坊節點內部的一組內存數據結構，它在挖礦前存儲候選交易，Geth稱其為 “交易池”；Parity稱其為 “交易隊列”。無論名稱如何，它都是一個坐在內存中等待被納入區塊的交易池，把它看成是一個 “等待區”，等待交易被接受到一個區塊中。”
目前，通過固定的交易有效性規則，礦工和其他節點只需要最小的努力就可以驗證其mempool中的交易，從而避免DoS攻擊，例如，如果一個礦工擁有有效的ECDSA簽名、有效的nonce，并且有足夠的賬戶余額，就可以確定某筆交易將真正支付費用，該礦工的mempool中的其他交易只有在來自同一地址，并且，增加nonce或充分減少賬戶余額的情況下，才可能使這個待處理的交易無效，這些條件在計算上是最小的，以使礦工和節點對其mempools有足夠的信心，分別進行區塊等待或重播。
賬戶抽象交易以其可編程的有效性引入了更多的復雜性。賬戶抽象交易不支付任何前期gas，并依靠其目標賬戶抽象合約來支付gas（通過PAYGAS），從概念上講，賬戶抽象交易處理分為兩個階段：較短的驗證階段（PAYGAS之前）和較長的執行階段（PAYGAS之后）。如果驗證階段失敗（或拋出異常），交易無效（就像今天無效簽名的非賬戶抽象交易一樣），不會被包含在一個區塊中，礦工也得不到任何費用，
因此，礦工和節點需要一個可預測的機制來避免一個待處理的賬戶抽象交易的有效性對mempool中其他待處理交易的依賴性。否則，一個交易的執行可能會使mempool中的許多/所有賬戶抽象交易無效，導致DoS攻擊，為了避免這種情況，有兩個建議的規則要在mempools中的賬戶抽象交易上執行（由礦工和節點執行，但不是在協議本身）。
Opcode Restriction
為了防止賬戶抽象交易的有效性取決于賬戶抽象合約本身以外的任何因素，以下操作碼在核查階段(即在PAYGAS之前)被視為無效：PAYGAS之前）：環境操作碼（BLOCKHASH、COINBASE、TIMESTAMP、NUMBER、DIFFICULTY、GASLIMIT）、BALANCE（任何賬戶，包括目標本身）、對目標以外的任何事物的外部調用/創建或預編譯（CALL, CALLCODE、STATICCALL、CREATE、CREATE2）和讀取代碼的外部狀態訪問（EXTCODESIZE、EXTCODEHASH、EXTCODECOPY、DELEGATECALL），除非地址是目標，
節點要放棄mempool中以賬戶抽象合約為目標的賬戶抽象事務，打破這個操作碼限制規則。這確保了只要賬戶抽象合約狀態不發生變化，mempool中的有效賬戶抽象事務將保持有效。
字節碼前綴限制
如果非賬戶抽象事務可以影響賬戶抽象合約的狀態，那么就會影響mempool中賬戶抽象事務的有效性。為了防止這種情況的發生，賬戶抽象事務應該只允許針對那些在其字節碼開頭有AA_PREFIX的合約，其中AA_PREFIX實現了對msg.sender是賬戶抽象事務的特殊ENTRY_POINT地址的檢查。這有效地防止了非賬戶抽象交易與賬戶抽象合約的交互，
節點要把賬戶抽象事務丟給在其字節碼入口點沒有這個AA_PREFIX的賬戶抽象合約。
對賬戶抽象合約實施的這兩個限制共同確保了：(1)賬戶抽象交易的有效性邏輯所能訪問的唯一狀態是賬戶抽象合約內部的狀態，(2)這個狀態只能被其他針對這個特定賬戶抽象合約的賬戶抽象交易修改，
因此，只有在另一宗針對同一份賬戶抽象合約的等待交易中，未完成的賬戶抽象交易才會失效。然而，鑒于這些不是協議/共識的改變，礦工可以自由地在區塊中包含打破這些規則的交易。
擴展
上述協議變更和mempool規則允許基本的賬戶抽象合約充分而安全地實現單租戶應用，如智能合約錢包，其他需要放寬上述規則或需要實現多租戶應用的高級用法，則需要賬戶抽象以擴展的形式提供更多的支持，比如。
SET_INDESTRUCTIBLE opcode，禁用SELFESTRUCT，允許賬戶抽象合約在驗證階段安全地調用DELEGATECALL的庫，
IS_STATIC opcode，如果當前上下文是靜態的，則返回true，允許非賬戶抽象事務調用者覆蓋之前的字節碼前綴限制，安全地從賬戶抽象合約中讀出值。
RESERVE_GAS opcode，當從一個非賬戶抽象事務調用時，它建立了一個賬戶抽象合約消耗的gas下限，該下限是尋求寫入合約狀態的，這樣做的作用是迫使攻擊者不消耗最低數量的gas，以抑制試圖使mempool中任何賬戶抽象事務無效的行為，
還有其他的如多個待處理的交易、驗證的緩存結果、驗證的動態gas限制和贊助交易，這些都是支持多租戶應用和zk證明所需要的，如Tornado Cash。關于它們的詳細內容不在本文的討論范圍內，
下一步工作
賬戶抽象EIP-2938目前處于草案模式，正在以太坊研究論壇中進行討論，EIP的下一步是被考慮納入即將到來的硬分叉之一，EIP作者的目標顯然是Berlin之后的硬分叉（Berlin暫定于2021年初的某個時間），其時間表目前還不是很明確。所以對于EIP-2938來說，現在還為時過早。
此外，也不清楚是否有必要在以太坊基礎第1層（L1）加入EIP-2938。鑒于第2層（L2）解決方案的相對靈活性（如我們之前的文章所述），賬戶抽象可以在特定的L2上實現，而不需要升級整個L1。然而，即使一些L2實現了自己的賬戶抽象版本，在L1上統一支持賬戶抽象也有好處，因此，賬戶抽象在哪里實現，如何實現，還有待觀察，
“賬戶抽象不太重要是因為不管L1是否支持，都可以在L2上實現，”— Vitalik在他關于以匯總為中心的以太坊路線圖的文章中談到了在基礎層將繼續起作用的事情），
Status：Status錢包目前是一個EOA錢包，它的區別在于捆綁了一個以隱私為中心的短信系統，并實現了哈拉中的支付或Keycard的增強安全性等集成，正在考慮智能合約錢包的功能，如多簽和社交恢復，賬戶抽象 EIP-2938的支持將有助于消除對集中式和低效的基于relayer的架構的依賴，如前所述。
Status也在評估L2解決方案，既要支持其錢包中的多鏈，又要為各種用例提供所需的擴展，如我們在前面的文章中所述。例如，Keycard正在探索一個支付網路，其信用卡級別的可擴展性和近乎即時的終局性的設計要求是目前以太坊網路無法滿足的。此外，還有許多其他的計劃，如推薦計劃、Tribute-to-Talk和ENS名稱，所有這些計劃都將受益于L2擴展性，以實現可行的部署和合理的用戶體驗，如果一個可行的L2解決方案實現了賬戶抽象，那么建立在該L2基礎上的項目將能夠利用賬戶抽象的優勢，而不必依賴L1，
總結
以太坊協議的一個基本方面是，只有外部自有賬戶(EOAs)可以支付gas費并開始執行交易，合約賬戶（CA）不能這樣做。賬戶抽象（AA）是一個提案，旨在改變這種區別，允許專門構建的CA以編程方式檢查新型賬戶抽象交易的有效性，決定代為支付gas費，從而有效地啟動其執行，而不需要EOA，
賬戶抽象對于顯著改善錢包、混幣器、DApps和DeFi等各種場景下的用戶體驗具有意義，而無需依賴中心化和低效的基于relayer的架構，基本的單租戶場景，如智能合約錢包，通過引入一種新的交易類型、兩種新的操作碼和兩種mempool規則，賬戶抽象可以安全地支持。高級多租戶應用，如Tornado Cash，需要對這些協議變化和節點規則進行擴展，
在這篇文章中，我們提到了智能合約錢包背景下對賬戶抽象的需求，我們通過描述協議變化和對節點的影響來強調賬戶抽象的關鍵方面。我們觸及了一些針對高級用途的擬議擴展，最后，我們在以太坊當前的路線圖和Status的優先事項中對賬戶抽象進行了定位。
在Web3中減少摩擦和改善用戶體驗是這個生態系統中所有項目的首要任務。賬戶抽象，以某種形式，可能肯定會在未來的努力中發揮重要作用。
