BTC
ETH
HTX
SOL
BNB
查看行情
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt

Vitalik提出的EIP-2938將給以太坊帶來哪些改變?

拔丝地瓜
特邀专栏作者
本文約7995字,閱讀全文需要約12分鐘
該草案概述了一個更容易實現的方法:通過將協議/共識的變化最小化,並通過節點mempool規則強制執行所需的安全保證。
AI總結
展開
該草案概述了一個更容易實現的方法:通過將協議/共識的變化最小化,並通過節點mempool規則強制執行所需的安全保證。

編者按:本文來自加密谷Live(ID:cryptovalley)編者按:本文來自

加密谷Live(ID:cryptovalley)"加密谷Live(ID:cryptovalley)"編者按:本文來自

加密谷Live(ID:cryptovalley)

加密谷Live(ID:cryptovalley)

加密谷Live(ID:cryptovalley)

加密谷Live(ID:cryptovalley)

以太坊有兩種類型的賬戶。外部自有賬戶(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交易和批量交易等功能,提供可編程的功能緩解風險以及用戶友好體驗。

智能合約錢包的例子有Argent、Authereum、Dapper、Dharma、Gnosis Safe、Monolith和MYKEY。如下圖所示,這類錢包的採用率似乎在增加。

Argent通過他們的Guardians概念實現了無密鑰社交恢復功能,其中Guardians是用戶信任的人或設備,可以幫助找回用戶的錢包。 Argent還旨在實現類似銀行的安全性(通過每日交易限額、賬戶鎖定和可信聯繫人等功能)以及類似Venmo的可用性(通過使用ENS名稱而非地址和支持元交易)相結合。

所有這些先進的錢包功能都需要使用完善的智能合約。錢包用戶要么需要與EOA進行交互,要么依賴錢包提供商通過提供商的中繼器或第三方中繼器網絡(如Gas Station Network)來支持元交易。前者依賴於在KYC後的中心化交易所購買ETH,而後者旨在通過將用戶的負擔轉移到中繼器上,以減少這種上鍊用戶體驗摩擦,其成本由錢包提供商鏈上/鏈下和/或用戶鏈下補償。

二級標題

Tornado Cash:一個相關的動機應用是混幣器,如tornado.cash,其中Tornado通過使用智能合約打破地址之間的鏈上聯繫來改善交易隱私,該合約接受ETH存款,隨後可由不同的地址提取。用戶在存款時需要提供秘密的哈希值,之後在提現時提供zkSnark證明,以顯示對秘密的了解,而不洩露秘密或之前的存款本身。這樣就把提現和存款脫鉤了。

二級標題

賬戶抽象將解決這個問題,允許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])

檢查globals.transaction_fee_paid == False (否則拋出異常)

檢查AA執行框架==頂層框架,即如果當前EVM執行退出或還原,則整個事務的EVM執行終止(否則拋出異常)。

"Mempool "設置globals.transaction_fee_paid = True"二級標題"設置globals.gas_price = gas_price 和globals.gas_limit = gas_limit。"二級標題"交易池"PAYGAS作為EVM執行檢查點。在此點之後的任何還原都只會還原到這裡,然後合約不接受退款,globals.gas_limit * globals.gas_price轉移到礦機。"新的交易類型和兩個新的操作碼構成了協議/共識層面的變化,它們的語義是比較容易理解。"

二級標題

Mempool規則

交易池

Opcode Restriction

。無論名稱如何,它都是一個坐在內存中等待被納入區塊的交易池。把它看成是一個

二級標題

等待區

二級標題

二級標題

賬戶抽象交易以其可編程的有效性引入了更多的複雜性。賬戶抽象交易不支付任何前期gas,並依靠其目標賬戶抽象合約來支付gas(通過PAYGAS)。從概念上講,賬戶抽象交易處理分為兩個階段:較短的驗證階段(PAYGAS之前)和較長的執行階段(PAYGAS之後)。如果驗證階段失敗(或拋出異常),交易無效(就像今天無效簽名的非賬戶抽象交易一樣),不會被包含在一個區塊中,礦工也得不到任何費用。

二級標題

為了防止賬戶抽象交易的有效性取決於賬戶抽象合約本身以外的任何因素,以下操作碼在核查階段(即在PAYGAS之前)被視為無效:PAYGAS之前):環境操作碼(BLOCKHASH、COINBASE、TIMESTAMP、 NUMBER、DIFFICULTY、GASLIMIT)、BALANCE(任何賬戶,包括目標本身)、對目標以外的任何事物的外部調用/創建或預編譯(CALL, CALLCODE、STATICCALL、CREATE、CREATE2)和讀取代碼的外部狀態訪問(EXTCODESIZE、EXTCODEHASH、EXTCODECOPY、DELEGATECALL),除非地址是目標。

二級標題

二級標題

字節碼前綴限制

節點要把賬戶抽象事務丟給在其字節碼入口點沒有這個AA_PREFIX的賬戶抽象合約。

對賬戶抽象合約實施的這兩個限制共同確保了:(1)賬戶抽象交易的有效性邏輯所能訪問的唯一狀態是賬戶抽象合約內部的狀態,(2)這個狀態只能被其他針對這個特定賬戶抽象合約的賬戶抽象交易修改。

因此,只有在另一宗針對同一份賬戶抽象合約的等待交易中,未完成的賬戶抽象交易才會失效。然而,鑑於這些不是協議/共識的改變,礦工可以自由地在區塊中包含打破這些規則的交易。

上述協議變更和mempool規則允許基本的賬戶抽象合約充分而安全地實現單租戶應用,如智能合約錢包。其他需要放寬上述規則或需要實現多租戶應用的高級用法,則需要賬戶抽像以擴展的形式提供更多的支持,比如。

二級標題

下一步工作

IS_STATIC opcode,如果當前上下文是靜態的,則返回true,允許非賬戶抽象事務調用者覆蓋之前的字節碼前綴限制,安全地從賬戶抽象合約中讀出值。

還有其他的如多個待處理的交易、驗證的緩存結果、驗證的動態gas限制和讚助交易,這些都是支持多租戶應用和zk證明所需要的,如Tornado Cash。關於它們的詳細內容不在本文的討論範圍內。

總結

賬戶抽象EIP-2938目前處於草案模式,正在以太坊研究論壇中進行討論。 EIP的下一步是被考慮納入即將到來的硬分叉之一。 EIP作者的目標顯然是Berlin之後的硬分叉(Berlin暫定於2021年初的某個時間),其時間表目前還不是很明確。所以對於EIP-2938來說,現在還為時過早。

二級標題

總結

Status:Status錢包目前是一個EOA錢包,它的區別在於捆綁了一個以隱私為中心的短信系統,並實現了聊天中的支付或Keycard的增強安全性等集成。正在考慮智能合約錢包的功能,如多籤和社交恢復,賬戶抽象EIP-2938的支持將有助於消除對集中式和低效的基於relayer的架構的依賴,如前所述。

ETH
Vitalik
投资
歡迎加入Odaily官方社群