賬戶抽象對於顯著改善錢包、混幣器、DApps 和 DeFi 等各種場景下的用戶體驗具有意義。本文將以太坊當前的路線圖和 Status 的優先事項中對賬戶抽象進行了定位。

原文標題:《深度丨 Vitalik 提出的 EIP-2938 將給以太坊帶來哪些改變?》
撰文:Rajeev Gopalakrishna
翻譯:Olivia
編輯:李翰博

以太坊有兩種類型的賬戶。外部自有賬戶(EOA)和合約賬戶(CA)。EOAs 由私鑰控制,而 CA 由其中包含的智能合約代碼控制。EOAs 一直比 CA 更有特權,因爲只有 EOAs 可以通過支付 gas 開始交易執行。賬戶抽象 (AA) 是一個提案,它允許合約像 EOA 一樣成爲一個 " 頂層 " 賬戶,其可以支付費用並開始交易執行。

賬戶抽象的動機是顯著改善用戶在錢包、 DApps 和 DeFi 等各種場景下與以太坊進行交互時的用戶體驗。賬戶抽象在以太坊中提供了一個基礎層的功能,來決定什麼時候可以支付 gas,以及對誰支付 gas 等問題。

Status Messenger 應用集成了一個以隱私爲中心的信息系統,以及一個以太坊錢包和一個 Web3 DApp 瀏覽器。Status wallet 目前是一個 EOA 錢包,它限制了我們提供只有智能合約錢包才能提供的豐富的用戶體驗,如多重簽名安全、社交恢復、利率限制、允許 / 拒絕地址列表和無 gas 的元交易。目前智能合約錢包的用戶體驗到了 gas 費波動的影響,並且第三方中繼器無法有效解決這個問題。而賬戶抽象旨在解決這個問題。

在本文中,我們提出了智能合約錢包背景下對賬戶抽象的需求。然後,我們通過描述協議變化和對節點的影響深入探討賬戶抽象的關鍵方面。最後,我們討論了一些擴展的提議,並通過合理化與以太坊接口的 Status 項目的計劃路線圖來結束,這些項目可能都會受到賬戶抽象的影響。

深度解讀 EIP-2938 草案中賬戶抽象的動機及影響

歷史 & 動機

賬戶抽象最初是在 2017 年以 EIP-86 的形式提出的,目的是實現 「交易來源和簽名的摘要 」,但這一想法的起源可以追溯到更早的 2016 年。當時有人建議:「與其有一個協議內機制,將 ECDSA 和默認的 nonce 方案作爲唯一的 「標準 」方式來保證賬戶的安全,不如採取初步措施,建立一個模型,從長遠來看,所有的賬戶都是合約,並且合約可以支付 gas,用戶可以自由定義自己的安全模型。」

最初的建議被認爲是具有挑戰性的,因爲需要改變許多協議並且需要保證安全性。最近,Vitalik Buterin 等人提出了 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。如下圖所示,這類錢包的採用率似乎在增加。

深度解讀 EIP-2938 草案中賬戶抽象的動機及影響

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 中減少摩擦和改善用戶體驗是這個生態系統中所有項目的首要任務。以某種形式,賬戶抽象可能肯定會在未來的努力中發揮重要作用。