GAS:賬戶抽象化（EIP-2938）：智能合約錢包為什么有這項需求？_Mercurity.finance

原文標題：引介|賬戶抽象化：為什么&做了什么

以太坊有兩種類型的賬戶：外部賬戶和合約賬戶。前者由用戶私鑰控制，而后者由存儲在智能合約賬戶內的合約代碼控制。外部賬戶的權限要大于合約賬戶，因為只有外部賬戶可以通過支付gas啟動交易的執行過程。賬戶抽象化則是一個可以讓合約賬戶成為和外部賬戶一樣的“頂層”賬戶的提案，實現了賬戶抽象化之后，合約賬戶也可以支付交易費和執行交易。

之所以提出賬戶抽象化，是想要在錢包、交易混淆器、DApp和DeFi等各種應用場景下，顯著改善用戶與以太坊鏈的交互體驗。賬戶抽象化方案要為以太坊提供一個基礎功能層，來確定何時支付，誰來支付以及怎樣支付gas。

以StatusMessenger應用為例，其將隱私信使服務與以太坊錢包和Web3瀏覽器集成在一起。目前，Status錢包仍然是外部賬戶錢包，因此其不能像智能合約錢包那樣支持豐富的用戶體驗，比如多簽安全、基于社交的錢包恢復、支付限額、地址黑/白名單以及無需gas費用的元交易。智能合約錢包的用戶體驗受累于gas價格波動，即使通過第三方的中繼者也無法有效解決這個問題。賬戶抽象化旨在解決這個問題。

在本文中，我們先探討智能合約錢包對賬戶抽象化的需求。然后描述協議的變更及其對節點的影響，借此深入到賬戶抽象化的關鍵部分。最后，我們討論一些關于擴展功能的提案，并以闡釋Status項目的計劃路線圖作為本文的總結，因為該項目要與以太坊配合因而勢必受到賬戶抽象化的影響。

歷史與動機

賬戶抽象化這個概念是在撰寫于2017年的EIP-86里首次提出的，其目的是實現“交易來源和簽名的抽象”。不過其動機和想法可以追溯到2016年年初vitalik提交的一個issue，文中建議“與其將ECDSA簽名算法和默認的nonce機制寫死在協議內作為‘標準’的賬戶安全機制，不如初步建立一個賬戶模型，在未來把所有的賬戶都變成合約，讓合約可以支付gas，讓用戶可以自由定義自己的安全模型。”

要實現最初的提議非常有挑戰，因為不僅要大幅修改協議，還要滿足系統的安全保證。最近，Vitalik等人提出了EIP-2938草案，該草案概述了一個更簡單的實現。這個實現對協議/共識的改動最小，并且通過設置節點的內存池規則來滿足所需的安全保證。Vitalik的以太坊工程組Meetup演講和SamWilson與AnsgarDietrichs的ETH線上演講都對這個主題做了非常棒的介紹。本文會著重介紹這些資料的關鍵內容。

基于賬戶抽象的智能合約錢包Clave已正式推出:8月26日消息，智能合約錢包Clave發推稱，正式推出由賬戶抽象提供支持的智能錢包平臺 Clave，支持使用手機、平板電腦或筆記本等安全元件與生物識別身份驗證技術實現無密鑰或助記詞登陸。Clave 將通過“意圖”、會話密鑰模塊與安全模塊等交易模擬器等改變用戶與區塊鏈交互方式，支持社交恢復。Clave 將首先支持 zkSync，現已開放白名單。[2023/8/26 10:03:34]

動機：賬戶抽象化背后的動機很簡單，但會帶來根本性的改變：當前，以太坊交易具備?功能可編程性，但是?交易的驗證方式?卻是固定的。只有持有有效的ECDSA簽名、有效的nonce值以及足夠的賬戶余額，一筆交易才算有效。賬戶抽象化引入了一種新的交易類型——抽象賬戶交易。這種交易總是由一個特殊地址產生，協議不會檢查其簽名，nonce和余額。通過引入這種交易，賬戶抽象化實現了從固定驗證方式到可編程驗證方式的轉變。抽象賬戶交易的有效性由其target字段指定的智能合約驗證，通過驗證之后，合約可以自行為該交易支付手續費。

那么，為什么賬戶抽象化這么有用呢？我們將用以太坊錢包為例，闡述它會帶來哪些好處。

智能合約錢包：如今大多數以太坊錢包都是外部賬戶錢包，它們的安全性由助記詞生成的私鑰保護。為了以后能在其他錢包里恢復密鑰，用戶應當安全妥善地保管助記詞。然而，這種錢包很容易因為私鑰被盜或者助記詞丟失導致用戶的資產遭受損失。

智能合約錢包是通過智能合約在鏈上實現的。這種錢包能夠提供可編程的風險遷移和友好的用戶體驗，比如多簽安全、基于社交或時間的錢包恢復、轉賬金額限制、地址黑白名單、無需gas費用的元交易和批量交易。

雖然智能合約面臨因代碼質量差而帶來的安全風險，但是這種風險可以通過錢包提供方的安全審計來減輕。而外部賬戶錢包的風險完全由用戶自己承擔，用戶無法獲得智能合約那樣的可編程的安全保障，用戶必須自己保管好助記詞。

當前可用的智能合約錢包有Argent、Authereum、Dapper、Dharma、GnosisSafe、Monolith和MYKEY。從下圖可以看到，這類錢包的使用率看起來在增加。

Argent通過守護者的概念實現了無需種子的基于社交的錢包恢復。守護者是用戶信任的人或設備，可以幫助用戶恢復錢包。Argent還要實現類似銀行的安全性與類似Venmo的可用性取代地址，支持元交易）。

以太坊基金會啟動賬戶抽象相關項目資助活動，截止日期為3月31日:2月28日消息，以太坊基金會宣布在2023年2月27日至3月31日啟動新一輪資助，以鼓勵圍繞賬戶抽象和支持它的必要基礎設施進行開發、研究和教育，包括webauthn交易驗證、賬戶抽象區塊瀏覽器、捆綁器、p2p消息傳遞、定序器RPC等。

據悉，本輪贈款的目的是促進和啟動多個與賬戶抽象相關的新項目。單個提案的預算上限為50,000美元，項目可以申請標準贈款計劃以獲得額外資金。[2023/2/28 12:33:27]

GnosisSafe是一款多簽智能合約錢包，專注于團隊資金管理，任何一筆交易都要得到團隊中最低人數的批準才能發生。它還可以通過元交易實現無需gas的簽名。

所有這些高級錢包功能都要用到靈活的智能合約。錢包用戶要么通過外部賬戶發送交易，支付gas費以調用錢包合約，要么依賴錢包提供方支持元交易功能，借由錢包提供方的中繼器或者第三方中繼網絡如GasStationNetwork來使用錢包。前者通常是通過了KYC認證的用戶依靠中心化交易所購買ETH；后者將用戶的負擔轉移到中繼器上，由錢包提供方或用戶在鏈上或鏈下補償中繼器，從而提高用戶體驗。

然而，基于中繼器的架構有三個主要缺點：他們可能會面臨中心化的詬病，引起交易審查的擔憂；由于中繼器發出的交易需要支付額外21000單位的基礎gas費，為了獲得利潤其必須收取更高的費用以覆蓋這部分成本，這就導致了技術和經濟上的低效；對中繼專用協議的使用，迫使應用不得不依賴非以太坊的基礎設施，而較小的用戶群無法支撐這些設施提供穩定可靠的服務。

賬戶抽象化將使智能合約能夠接受用戶的無需gas的元交易，并且無需依賴中繼網絡就能為其支付gas費。因此，這種底層能力在不犧牲去中心化的情況下，能夠極大改善這些智能合約錢包的用戶體驗。

TornodoCash：另一個相關應用是交易混淆器，例如tornado.cash。Tornado使用智能合約切斷地址之間的鏈上關聯以提升交易的隱私性，該合約允許用戶存入ETH后通過另一個地址提款。用戶在存款時提供一個秘密值的哈希，隨后在提款時提供zkSnark證明。該證明可以在不泄露秘密值和存款信息的情況下，證明其知道這個秘密值。這樣就把存款和提款脫鉤了。

但是在提款時有一個雞生蛋蛋生雞的問題。為了在新生成的地址上執行提款交易，用戶需要給該地址存入一些ETH以支付gas費。但這些ETH的來源本身又會破壞使用Tornado所帶來的隱私性。首選的替代方案是再次使用中繼網絡，而這樣做有上述的那些缺點。

Harmony將在第二季度實現賬戶抽象功能:2月19日消息，Harmony宣布將在2023年第二季度實現賬戶抽象，為用戶和開發者提供更大的靈活性和功能。帳戶抽象是一種允許創建多種類型帳戶的功能，每種帳戶都具有獨特的功能和特性。[2023/2/19 12:15:35]

賬戶抽象化就可以解決這個問題，Tornado合約可以接受用戶的提款抽象賬戶交易，驗證zkSnark，扣除gas費，然后把剩余的資金轉給提款地址。

賬戶抽象化

在EIP-2938中提出的賬戶抽象化，接納合約作為頂層賬戶，使之可以支付交易費以及啟動交易的執行過程。實現賬戶抽象化需要變更協議以增加新的抽象賬戶交易類型、修改內存池規則以及引入擴展功能以支持高級用法。抽象賬戶交易需要增加兩個新的操作碼：NONCE?和?PAYGAS。賬戶類型仍然保持現有的兩種，所有的變更都向后兼容以支持當前的交易、智能合約和協議。

賬戶抽象化應用可以分成兩類：1)單租戶應用，如智能合約錢包，其會為每個用戶創建一個新合約；2)多租戶應用，例如tornado.cash或Uniswap，多個用戶與同一組智能合約交互。

目前還不能支持多租戶應用，這需要更多的研究工作，以期未來早日實現。所以本文將重點介紹單租戶的賬戶抽象化。

協議變更

對協議唯一的變更就是引入了一種新的交易類型，以及相關的兩個操作碼?NONCE?和?PAYGAS。

抽象賬戶交易：協議引入了一種新的交易類型：AA_TX_TYPE。它的二進制數據(payload)會被解析為?RLP()?，而不是現有交易的?

RLP()?。

Nonce檢查和現有交易類似，需滿足

?tx.nonce==tx.target.nonce。

如果檢查失敗，則交易無效，如果通過檢查，則?tx.target.nonce?將會遞增，交易繼續進行。

抽象賬戶交易的基礎gas消耗量將從21000降到15000。此外，抽象賬戶交易沒有內置的gas限額。當交易執行時，gas限額只需設定為當前block還剩余的gas限額即可。

NONCEopcode：NONCE?操作碼(0x48)推送被調用者——即抽象賬戶交易的target字段所指定的合約——的nonce值到EVM的棧上。借此，nonce值被暴露給了EVM，因而抽象賬戶合約可以將交易的任何字段作為驗簽邏輯的一部分。

以太坊賬戶抽象提案EIP-4337新增簽名聚合，可為rollups降低數據成本:10月3日消息，據以太坊創始人V神（Vitalik Buterin）近日發布的推文，其于2021年9月聯合發起的以太坊賬戶抽象提案EIP-4337近期發布了新版本，添加了包括BLS簽名算法的簽名聚合。簽名聚合功能能夠讓構建者和批次提交者也能聚合簽名（例如BLS、SNARKs），大大減少了鏈上的數據。

V神表示，ERC-4337為賬戶抽象提供了真正有價值和必要的東西，可為使用智能合約錢包的用戶操作提供“去中心化費用市場”。我們正在慢慢精準實現賬戶抽象的實際路徑，本次發布新增的簽名聚合功能可以為rollups降低數據成本，這也將成為采納ERC-4337的動力之一。

據悉，賬戶抽象（Account Abstraction）是通過省略以太坊賬戶體系中不必要細節，來減少復雜性并提高有效性有效地（消除了對EOA的需求和對智能合約錢包的特殊處理）。[2022/10/3 18:38:21]

PAYGASopcode：PAYGAS?操作碼(0x49)從棧上彈出2個參數：version_number，memory_start。

Version_number?允許未來通過新的實現變更操作碼的語義。目前，操作碼的語義如下：

檢查?version_number==0

讀取?gas_price=bytes_to_int(vm.memory)

讀取?gas_limit=bytes_to_int(vm.memory)

檢查?contract.balance>=gas_price*gas_limit

檢查?globals.transaction_fee_paid==False

檢查?AAexecutionframe==top-levelframe，也就是若當前EVM執行退出或回退，整個交易的EVM執行就暫停了

設置?contract.balance-=gas_price*gas_limit

設置?globals.transaction_fee_paid=True

設置?globals.gas_price=gas_price，globals.gas_limit=gas_limit

VitalikButerin等人發布Ethereum“賬戶抽象”提案ERC4337:9月29日，Ethereum創始人Vitalik Buterin聯合KristofGazso、yoav.eth、DrorTirosh、NamraPatel、TomaszK.Stanczak等人發布賬戶抽象提案ERC4337，可在不改變以太坊共識層協議的情況下實現驗證邏輯，該提案的開發者內測版本將于近期上線。

注：“賬戶抽象”是以太坊社區中討論的改進提案之一，以實現交易不需要從私鑰控制的EOA賬戶發起，而是可以直接從智能合約發起，具體的用例包括智能合約錢包、Tornado.Cash這類隱私保護工具等。[2021/9/29 17:15:22]

設置當前的執行上下文的?remaining_gas=gas_limit-已經消耗的gas

在執行抽象賬戶交易的最后，(globals.limit-remaining_gas)*globals.gas_price?的費用將轉給礦工，remaining_gas*globals.gas_price?的金額則退還給抽象賬戶合約。

PAYGAS?操作碼充當EVM執行過程中的檢查點。任何回退都只退回到上一個檢查點，此時合約收不到退款，globals.gas_limit*globals.gas_price?的金額全都轉給礦工。

這個新的交易類型和這兩種新的操作碼構成了協議/共識級別的全部變更，它們的語義相對直觀，易于理解。

內存池規則

“內存池是指以太坊節點內部的，存儲在內存里的數據結構，其中存儲了用于挖礦的候選交易。Geth稱之為‘交易池’；Parity稱之為‘交易隊列’。不管叫什么，它都是一個存儲將被區塊包含的交易的數據池。我們可以把它看做是待打包區塊的“候車廳”。

抽象賬戶交易的可編程驗證方式引入了更多的復雜性。抽象賬戶交易并不預付gas費，而是依靠?target?字段指定的抽象賬戶合約來支付gas費。理論上，抽象賬戶交易的處理分兩個階段：較短的驗證階段和較長的執行階段。如果驗證階段失敗，會導致交易無效，該交易便不會被區塊包含，因而礦工也就拿不到交易費了

因此，礦工和節點需要一個可預測的機制，以避免待處理的抽象賬戶交易的有效性依賴內存池中的其他待處理交易。否則，一筆交易執行失敗可能會導致許多甚至全部的抽象賬戶交易無效，以此可以構造出拒絕服務攻擊。為了避免這種情況發生，我們建議內存池對抽象賬戶交易執行兩條規則。

操作碼限制

為了防止抽象賬戶交易的有效性取決于抽象賬戶合約以外的任何狀態，在驗證階段以下操作碼被視為無效：執行環境操作碼

、

BALANCE、除了對?target?合約或預編譯合約之外的任何外部調用/創建操作碼

、

對除了?target?合約之外的任何外部狀態的讀取操作碼

。

如果有抽象賬戶交易的target字段所指向的抽象賬戶合約違反了這個操作碼限制規則，節點就要丟棄這個交易。如此，只要抽象合約的狀態不發生變化，內存池中有效的抽象賬戶交易就將繼續有效。

字節碼前綴限制

如果非抽象賬戶交易可以影響抽象賬戶合約的狀態，那么其就可以影響內存池中的抽象賬戶交易的有效性。為了防止這種情況發生，抽象賬戶交易應當只接受字節碼前綴為?AA_PREFIX?的target合約。AA_PREFIX?實現了對?msg.sender?的檢查，確保其是特殊的?ENTRY_POINT?地址。這有效地防止了非抽象賬戶交易與抽象賬戶交易發生交互。

節點如果檢查到抽象賬戶交易指定的合約沒有這個?AA_PREFIX?作為字節碼前綴，就應該刪除這筆交易。

這兩條對抽象賬戶合約的限制確保了：只有抽象賬戶合約的內部狀態可以影響抽象賬戶交易的驗證邏輯；只有以同一個抽象賬戶合約為target的抽象賬戶交易可以修改該合約的狀態。

因此，只有區塊包含了以同一個抽象賬戶合約為target的另一筆抽象賬戶交易，才有可能使一個待處理的抽象賬戶交易無效。不過，鑒于這不是協議/共識層的變更，礦工在打包交易時可以隨意違反這些規則。

擴展

上述協議變更和內存池規則足以安全地實現諸如智能合約錢包這樣的單租戶應用。其他高級用法則需要放寬上述規則或者需要實現多租戶應用，這就要賬戶抽象化支持以下形式的擴展：

SET_INDESTRUCTIBLE?操作碼，它會禁用?SELFDESTRUCT，并允許抽象賬戶合約在驗證階段通過?DELEGATECALL?安全地調用庫函數。

S_STATIC?操作碼，如果當前的上下文是靜態的則返回true，并允許非抽象賬戶交易的調用者繞過之前的字節碼前綴限制，安全地從抽象賬戶合約里讀取數據。

RESERVE_GAS?操作碼，當一筆非抽象賬戶交易試圖對一個抽象賬戶合約寫入狀態時，設置一個gas消耗的下限。這樣做是為了強制攻擊者在試圖讓內存池的抽象賬戶交易無效時至少要消耗一定的gas，以此抑制其攻擊動機。

還有一些其他的擴展，例如存儲多筆待處理交易、緩存驗證結果、驗證過程的動態gas限制和擔保交易等，這些都是為了支持多租戶應用和零知識證明。這些內容不在本文的討論范圍內。

下一步

目前，關于賬戶抽象化的EIP-2938還只是一個草案，正在以太坊研究論壇中討論。下一步是考慮將這個EIP納入即將到來的硬分叉中。EIP的作者顯然瞄著Berlin之后的硬分叉，具體的時間表還不確定。所以，對于EIP-2938來說，現在還處于早期階段。

此外，也不清楚是否有必要在以太坊的Layer1(L1)加入EIP-2938。鑒于Layer2(L2)方案的靈活性，我們也可以在特定的L2上實現賬戶抽象化，這樣就不需要升級整個L1了。不過，在L1上統一支持賬戶抽象化要比在不同的L2上各自實現賬戶抽象化好。因此，在哪里實現，怎樣實現賬戶抽象化還有待觀察。

“賬戶抽象化在某種程度上不那么重要，因為無論L1是否支持，它都可以在L2上實現。”——Vitalik在談及基礎層的升級需求時表達了這個觀點。

Status：Status錢包目前是一個外部賬戶錢包，它的獨門絕技是將聊天支付和Keycard集成到一個隱私信使服務中。目前其正在考慮加入一些智能合約錢包的特性，如多簽和基于社交的錢包恢復。如前所述，支持EIP-2938有助于消除對中心化和低效的中繼架構的依賴。

Status也在評估L2解決方案，正如我們之前的文章里說的，這樣做既可以在錢包里支持多鏈，也可以為多種用例提供所需要的擴展。例如，Keycard正在探索一種支付網絡，其所需的信用卡級別的可擴展性和近乎即時的終局性是目前以太坊網絡無法滿足的。此外，還有許多其他計劃，如推薦計劃、SNTreaction、Tribute-to-Talk和ENS域名。所有這些計劃都適合在L2上實現，因為這在部署上可行，而且能夠提供還不錯的用戶體驗。如果一個可行的L2方案實現了賬戶抽象化，那么在該L2上的項目都能享受賬戶抽象化的好處，而不必依賴L1。

總結

以太坊協議的一個根本問題是，只有外部賬戶（EOS（可以支付gas費和啟動交易執行過程，而合約賬戶（CA（做不到。賬戶抽象化（AA（是一個旨在改變這種區別的提案，允許具有特定構造的合約賬戶可以檢查新增的一類交易——抽象賬戶交易的有效性，并代為支付gas費，從而在不需要外部賬戶的前提下有效地啟動交易的執行過程。

賬戶抽象化能夠在不依賴中心化和低效的中繼架構的情況下，顯著改善錢包、交易混淆器、DApps和DeFi的用戶體驗。通過引入一種新的交易類型，兩種操作碼以及兩條內存池規則，賬戶抽象化能夠安全地支持基本的單租戶場景，如智能合約錢包。如果要支持更高級的多租戶應用，如TornodoCash，則需要對協議和節點規則做更多的擴展。

本文闡述了智能合約錢包對賬戶抽象化的需求。通過描述協議的變更和對節點的影響來強調賬戶抽象化的關鍵部分。我們還談到了一些針對高級用法的擴展提案，最后通過介紹Status項目在以太坊上的路線圖和優先級讓讀者對賬戶抽象化有一個比較清楚的定位。

減少Web3的摩擦及改善用戶體驗是這個生態里所有項目的首要任務。賬戶抽象化，最終一定會以某種形式在未來發揮重要的作用。

感謝HesterBruikman審閱本文草稿并提供有益的反饋。感謝AlexHowell提供貼心的插圖。

原文鏈接:

https://our.status.im/account-abstraction-eip-2938/

作者:?RajeevGopalakrishna

翻譯&校對:?戡亂&阿劍

Tags：GAS以太坊NCEARGMegaShiboX Inu以太坊幣怎么挖礦賺錢Mercurity.financeMarginless

屎幣