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


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

.



Source link