編者註:本文首發於公眾號“因雨成歌”,EthFans 經授權轉載。

概述

賬戶抽象[[Account Abstraction]] 是以太坊上的一種待實現的技術方案,按現階段設計,在實現賬戶抽象之後,一個智能合約賬戶也可以主動發起交易,而無需依賴“元交易” 的機制。

背景

以太坊的賬戶有兩種類型,一種是外部賬戶,另一種是合約賬戶。外部地址是由用戶的公鑰經過哈希運算後取的後20 個字節,形為0x76D836358E7A2BB0F26c32Ce61Dc8DD540b02F7D 。目前的以太坊的事務類型只有一種,必須由外部地址發起,合約地址無法主動發起事務。因此,任何合約自身狀態的改變,必須依賴於一個外部地址發起的事務,無論是一個多重簽名賬戶,還是混幣器,或是任何智能合約的配置變更,都需要由至少一個外部賬戶觸發。這樣的設計讓以下兩件事情無法完成。

1. 無需以太的主動事務

由於事務必須由外部賬戶發送並支付費用,而該費用是用以太(ETH)為單位結算的,因此該外部地址必須持有以太。當然,這種說法並不嚴謹,當gasprice 為0 時,事務無需支付手續費。可這種情況非常極端(見[1]) ,對於普通用戶來說,這樣的事務可能永遠無法入塊。

2. 非secp256k1的原生驗證方式

由於事務必須由外部賬戶發起,因此每筆事務的合法性檢查就是在驗證事務是否提供了該賬戶對應的合法的secp256k1 簽名。而如果要在驗證中引入複雜邏輯(例如多重簽名或社交恢復)或是採用不同的驗證算法(例如Eddsa、BLS、secp256r1 簽名算法,使用這些簽名算法是因為它們有特別的特性,或是對零知識證明友好,或是方便簽名聚合減少帶寬開銷,或是與現有的硬件驗證器兼容),則必須在智能合約層面實現。這也同時意味著,這種驗證仍要由至少一個外部賬戶發起,並通過以太坊的secp256k1 簽名驗證。

上述兩條約束讓普通用戶很難使用以太坊。首先,無論使用以太坊上的什麼應用,用戶都必須持有以太(並承擔以太價格波動的風險)。其次,用戶需要處理複雜的費用邏輯,gas price、gas limit、事務阻塞,這些概念對用戶來說過於復雜。許多區塊鏈錢包或應用試圖通過產品優化提高用戶體驗,但效果甚微。

如何解決上述兩個問題呢?

核心思路在於將“驗證所有權” 的操作由共識層下放到合約層,即不去檢查事務的發送者是否與資產所有人一致,而是檢查其是否提供了合法的憑據。具體的做法為:用戶對事務內容進行簽名,並將簽名交由一個第三方操作上鍊,這個第三方我們在接下來的文章中用“運營商(operator)” 來指代。這種事務被稱為“元交易”。根據設計理念的不同,元交易方案大致分為兩類:

1. 以賬戶為中心——智能錢包

以賬戶為中心的方案的目標是為用戶創建一個基於智能合約管理的賬戶,用戶可以使用該賬戶與區塊鏈上的任意合約交互。智能錢包的理念由來已久,但在近一年來有了長足的進展。根據「智能錢包趨勢」的統計(注:作者為本人,特此聲明),目前「智能錢包」的運營商超過10 家,總用戶數超過14 萬。其中大部分智能錢包採用了為用戶代付鏈上手續費的運營策略,再通過其它方式向用戶收取費用。

以賬戶為中心的方案本質上是一套區塊鏈賬戶系統,通用性強,且可以提供包括賬戶恢復、大額審批、轉賬白名單等附加特性。智能錢包的運營者協助用戶創建、管理區塊鏈上的可編程身份,並提供事務上鍊服務。一般來說,智能錢包會為用戶支付鏈上的gas 費,同時通過中心化計費系統向用戶收取費用。這套模式和傳統世界裡的賬戶服務很像,例如運營商支付基站、光纖等費用,而用戶只要充值話費就可以使用通信服務,而無需關心底層複雜的邏輯。

智能錢包也有其掣肘。一是安全問題,二是費用問題。

安全:如果賬戶合約存在漏洞,那麼所有用戶的資產都會遭受風險。專業的代碼編寫、安全審計和形式化驗證,都只能減少風險發生的可能,而不能保證它不會發生—— Argent 已經發生過。費用:智能錢包的賬戶創建需要費用,而轉賬和任何調用任何合約都會比外部地址花費更多費用。這導致智能錢包的用戶需要支付更高的事務費用,這影響了他們的使用體驗

2. 以資產為中心—— 無氣通證

無氣通證也存在其問題。從目前的使用情況來看,極少有人使用這種特性(需要數據支持)。在「智能錢包,不止元交易」一文中,我分析了可能的原因,其中之一在於沒有辦法建立有效的計費系統。

以資產為中心的方案提高了資產的可用性。不同於智能錢包需要創建智能合約賬戶,無氣通證可以支持外部賬戶在不使用以太的情況下進行轉賬,反而是智能合約賬戶需要兼容更多規範(例如EIP-2126,讓合約可以識別不同類型的簽名格式),否則無法讓無氣通證的合約驗證所有權

以資產為中心的方案的目標是創建允許由第三方支付費用的資產,實現“無需gas 的通證”。例如,DAI、USDC 都可以允許任意外部地址使用元交易的方式發送資產。這些通證協議都使用EIP-712 協議驗證擁有者的合法性。

賬戶抽象的發展史

根據Matt Garnett 整理的賬戶抽象發展歷史[2],從以太坊2015 年上線起,賬戶抽象的討論沒有停止。本文將按照時間順序,對賬戶抽象相關的EIP進行簡要介紹。需要說明的是,該歷史漏掉了EIP-208,我做了相應補充。

EIP-101:貨幣與密碼學抽象

[[November 15th, 2015]]

在這個EIP [3] 中,Vitalik 討論了對Serenity 中的賬戶體系的設計。這個方案的主要思想是,每個賬戶都擁有自己的“代碼”,也即邏輯部分。由於該方案改動過大,與當前事務的兼容性不好,會造成許多安全隱患,該方案被擱置到分片之後。

EIP-86:事務來源和簽名抽象

[[February 10th, 2017]]

經過漫長的討論,Vitalik 提出了EIP-86。 EIP-86 是為賬戶抽像做技術準備,它定義了一種新的賬戶類型,允許用戶創建基於智能合約的賬戶,該賬戶是一個代理合約(forwarding contract),存儲Ether,在入口點檢查事務的簽名,並將驗證合法的事務轉發到指定的地址,並支付相應的費用。這種機制對多簽錢包、環簽名混幣、自定義的密碼算法(例如ed25519)等場景的實現有更多幫助。

對EIP-86 的討論展開了很久,值得說明的是,Vitalik 豐富了協議細節,提出了EIP-208。 EIP-86/208 計劃於Metropolis 階段升級,但在第19 次核心開發者會議[4] 上,開發者提出了很多問題,並決定在Metropolis 中暫緩引入,主要理由如下。

賬戶抽象帶來新類型的事務,與傳統事務必須有一個EOA 作為發送者相比,這些事務沒有發送者。這種事務破壞了事務哈希的唯一性,儘管這不會對EVM 的執行造成影響,但是所有基於“唯一性” 假設的外部操作都會收到影響。例如,所有通過事務哈希來定位事務的RPC 接口。此外,賬戶抽象的“無氣支付” 是一個優化,但是必要性不足。因為其功能可以通過“代理合約” 實現,唯一的問題是其開銷會比原生實現要大一些。礦工的挖礦策略會受到極大影響,在被廣泛接納前,這些新類型的事務可能無法被很快廣播。這種新類型的事務仍然保留了nonce、gasprice、value 字段,且被設為0。這非常不優雅,希望未來用新的事務類型解決,而不是引入技術債。

EIP-859:主網上的賬戶抽象

[[January 30th, 2018]]

與前兩個EIP 不同,EIP-859 並沒有形成確定性的草案,而是始終在討論過程中,沒有定稿。該提案希望賬戶合約有一個相對規範的實現,即(1)檢查簽名(2)支付手續費(3)調用目的賬戶。

如果EIP-859 實現,可以抽象(1)簽名算法(2)更複雜的邏輯,並且不會破壞“事務哈希唯一” 的特性,但仍然不能允許使用ERC-20 支付費用。

這個提案在第34 次和第40 次核心開發者會議的筆記中被提及。根據會議筆記,第33 次核心開發者會議上決定擱置該提案,而是聚焦於Casper。而Vitalik 在第34 次會議[5] 上承認該提案仍不成熟,但“不管怎樣在分片時會實現”。 Hudson 指出,君士坦丁堡升級包含的內容太多了,因此不再考慮該提案。第40 次核心開發者會議上,大家決定永久擱置該提案,無人反對。

EIP-2938:賬戶抽象

[[September 4th, 2020]]

時間又過了兩年,ETH 2.0 的Phase 0 已經啟動,而賬戶抽像也被重新提上議程。出乎意料的是,該提案建議在ETH 1.x 上首先實現。

簡單來說,賬戶抽象的目標是讓智能合約成為頂級的賬戶類型,而非受限制的必須由外部賬戶調用的賬戶,這樣智能合約賬戶就可以主動發起事務並支付手續費。這個目標與EIP-86 已經有了很大區別,當時的提案希望徹底消滅外部賬戶,或者說將所有的外部賬戶都變成合約賬戶,而此提案仍然保留了外部賬戶的存在。

以太坊當前的事務合法性只通過三個參數判斷:ECDSA 簽名、自增nonce 和賬戶餘額,因此節點非常容易判斷一筆事務的合法性。然而,這勢必造成了很多限制。 EIP-2938 實現後,以下場景可以主動實現:

(1) 智能錢包使用ECDSA 之外的算法驗證簽名;(2) 智能錢包的其它特性,包括多重簽名和社交恢復;(3) 保護隱私的系統,例如Tornado.cash;(4) 提高DeFi 協議gas效率;(5) 用戶使用其它token,而不是ETH 支付手續費。

目前,以上用戶場景也可以通過間接的方式實現。該提案認為這種方式在技術和經濟上都不高效。

EIP-2938 分為單租戶和多租戶兩個階段,顧名思義,其區別在於賬戶的擁有者是單個用戶還是多個(不特定的)用戶。在單租戶階段能滿足(1)、(2) 和(5) 場景的需求,而只有在多租戶階段(3) 和(4) 才能實現。多租戶階段的技術方案仍未成型。有關EIP-2938 的更多內容,可以參考Status 發表,以太坊愛好者翻譯的文章[6]。

代價是什麼? —— 硬幣的兩面

毫無疑問,假設賬戶抽象成功部署,可以帶來新的功能特性,但也一定有取捨,不可能得到美好的東西,但不付出什麼代價。過去五年的討論給了我們足夠的經驗,其負面影響甚至由於其複雜性而難以分析。儘管如此,本文將試圖系統討論其潛在收穫和代價,以便讀者公允地判斷。 「賬戶抽象的收穫」參考了核心開發者Peep an EIP 文檔[7]。

1. 賬戶抽象的收穫

(1)主動發送事務的智能合約賬戶。

智能合約賬戶可以無需EOA 觸發而主動發送事務,減少了對運營商的依賴,且gas 消耗更少。

(2)提高混幣器的隱私性。

現階段,用戶從類似Tornado.cash 的混幣器中提款仍需要依賴一個EOA 賬戶發送事務,這個EOA 賬戶是暴露隱私的脆弱環節。實現多租戶的賬戶抽像後,任何人提取代幣時,均無需額外支付費用,而直接從提款金額中扣除。

(3)使用其它代幣支付手續費。

現階段,用戶必須使用ETH 支付網絡的手續費,在賬戶抽象實現之後,用戶可以使用其它token 支付手續費。但這不意味著在協議層礦工會接受非ETH 作為手續費,而是通過和DEX 交互換取ETH 支付手續費。

(4)減少鏈上無效套利交易,提高可擴展性。

現階段,在鏈上發現套利機會時,可能存在多個套利者同時發起套利交易,而首筆成功的套利事務會讓其餘事務的套利行為失效,但這些事務仍然會被打包在以太坊中(如果gasprice 足夠,且沒有使用相同nonce 替換該事務),這導致以太坊上存在大量的“垃圾” 事務。而實現賬戶抽象之後,由於可以在賬戶權限驗證階段進行價格判斷,那麼套利者無需為失敗的套利行為付費,鏈上也不會包含失敗的套利事務,可以有效提高鏈的可擴展性。

2. 賬戶抽象的代價

(1)加大內存池驗證事務有效性的開銷

在現階段,節點收到一筆事務時,很容易判斷其有效性,並將其載入內存池。節點只需要判斷三件事:簽名的有效性、nonce 的合理性(賬戶當前nonce 加1 或合理的數值)、賬戶的餘額,如果其中任意一條不滿足,節點可以選擇丟棄該事務。非法事務並不會支付手續費,節點是免費“驗證”,由於驗證ECDSA 的簽名非常簡單,開銷極低,目前網絡的安全性不會受到挑戰。當引入賬戶抽像後,判斷一筆事務的有效性的難度大了很多,節點需要為無效事務的驗證花費更多計算資源,而不能從中收取任何費用。有關DOS 攻擊,參見[8]

(2)加大內存池確保事務有效性的開銷

現階段,一旦節點驗證某筆事務的有效性,除非該賬戶使用相同nonce 發送新的事務並被打包,否則這筆載入內存池的事務將永遠有效,直到被打包進某個區塊(也可能因為gasprice 太低而一直沒有打包)。而賬戶抽象之後,判斷事務的有效性的難度提高了,內存池中的多筆事務在被打包前可以同時有效,但由於其有效性可能依賴全局狀態,存在其中某一筆事務執行後剩餘事務全部失效的可能性。因此,需要建立新的內存池規則,以避免這種情況的出現。

(3)引入新的事務類型、計費方式、挖礦和廣播策略

首先,引入了新的事務類型。在EIP-86/208 的討論過程中,一度有一種傾向是“消滅” EOA 賬戶,或者說把EOA 賬戶包裹在一個智能合約賬戶內,這樣鏈上的基本賬戶類型和事務類型都只有一種。而在本提案中,EOA 賬戶得以保留,即存在兩種類型的賬戶——EOA 和AA,也有兩種事務類型。同時,AA 事務調用其它合約時必須加上前綴,以防止EOA 賬戶發起對AA 賬戶狀態的修改,影響事務有效性的判斷,這可能會帶來兼容性的問題。其次,計費方式發生了變化。現階段,礦工無需關心事務的內容,只需要確認事務的發起方的ETH餘額大於gaslimit*gasprice,就可以保證收到手續費。而在賬戶抽象之後,如何保證礦工可以收到手續費呢?本提案將一筆事務分拆成兩個部分——驗證階段和執行階段,用一個新的操作符PAYGAS 間隔。在驗證階段,完成對賬戶權限的驗證,在此階段不允許調用外部數據或操作賬戶餘額。與現階段的方法一致,驗證通過則支付手續費並開始執行事務,即使事務在執行階段回滾,也仍然會被包含在區塊中且支付費用,但驗證不通過則丟棄該非法事務。再者,挖礦和廣播策略變得更加複雜。為了保護內存池和礦工的安全,推薦的挖礦策略更加保守。每個賬戶的待處理事務只保留一個,不再保留更高nonce 的事務;對驗證階段設置gas 的容量上限;在AA 賬戶發起的事務被打包進入區塊之後,需要丟棄掉內存池所有對此賬戶進行操作的事務。為了避免前2 條代價造成的潛在影響,以太坊協議層需要做相應的技術改動。

重新評估「收穫」?

要評估賬戶抽象的必要性,首先不妨來回顧其“收穫”。 “收穫” 無非分為兩種類型——原來不能做的,現在可以做了;比原來做得更好了。

(1)主動發送事務的智能合約賬戶。

智能錢包可以做到這件事情,此收穫屬於一種改進。由於事務的有效性依賴於合格的簽名(或其它憑證),而非發送事務的EOA 賬戶,因此任何EOA 賬戶都可以提交事務,不存在信任或可靠性風險。由於無需轉發事務,更少的gas 消耗是一個合理的“收穫”,但能達到整體的最優嗎?換句話說,在引入瞭如此復雜的技術改動之後,針對相同的事務內容,計算機在相同時間內可以處理更多的AA 事務還是EOA 事務?

結論:一種需要技術驗證的改進。

(2)提高混幣器的隱私性。

目前Tornado.cash 使用運營商的模式,替代用戶提交取款的收據。與智能錢包的運營商不同,隱私運營商可能不夠穩定和,任何人可以替代提交事務,但隱私場景下的運營商可靠性會低於通用場景,可能造成服務不可用。不過,這需要在多租戶階段才能實現,而目前多租戶模式的方案的可行性、安全性仍然需要驗證。

結論:一種提高服務可用性的改進。但不知道能否上線,何時可以上線。

(3)使用其它代幣支付手續費。

現在智能錢包在做類似的事情,例如Argent、MYKEY 都允許用戶使用DAI 支付手續費,但這一操作並非原子的。使用穩定幣等資產通過DEX 兌換ETH 支付手續費,乍看解決了原來不能解決的問題,但我想表達的是,真實需求並非是技術完備性,而是使用穩定的貨幣來對抗不穩定的手續費(ETH 價格波動、gasprice 價格波動、gas 消耗不確定)。使用鏈上事務直接置換手續費,有一種每次使用手機聯網前,先買充值卡充話費的感覺,似乎回到了投幣電話的時代。何況這筆事務還有巨大的失敗風險,因為鏈上狀態的改變可能影響價格。當然,這並不是說投幣電話沒有用處。

結論:一種可以實現原子化使用非ETH 資產支付手續費的改進。但不解決價格波動問題,真實需求存疑,且計費方式效率低下。

(4)減少鏈上無效套利交易,提高可擴展性。

在研究過程中,關於“減少鏈上無效事務可以提高鏈擴展性”的論述甚至讓我懷疑整個賬戶抽象的動機。在現有的模型下,套利者追求套利機會,但由於策略公開,可能導致不同的套利者競爭,抬高網絡費率並引入大量失敗的套利事務。然而,套利者更明白這個道理,因此也會評估套利失敗的後果,否則就要付出手續費的代價,恰恰是這個成本讓系統處在動態博弈中。如果競爭套利的行為不需要付出成本,那麼儘管不會出現無效的鏈上事務,但整個系統卻會容納更多的套利行為,讓節點承受更多的無法收費的計算任務,何談增加系統的可擴展性?

結論:不是改進,更像是為了鏈上“乾淨” 的一種固執。

綜上所述,這些聲稱的改進大多只是對現有實現的“優化”,且缺少足夠的驗證,部分“優化” 甚至經不起推敲。

總結

本文總結了以太坊“賬戶抽象” 的背景,“賬戶抽象” 主要為了解決兩個問題,一是無需Ether 發送事務,二是實現自定義的驗證邏輯和算法。為了解決這些問題,以太坊歷史上提出了多個提案,本文分析了這些提案的企圖和最終未採納的原因。本文的重點是針對EIP-2938 這個最新的關於賬戶抽象的分析,討論了其“收穫” 和“代價”。 “賬戶抽象” 可以將一些現階段需要引入“信任” 才能實現的功能變得更加可靠,例如為混幣器提供更好的隱私,或是使用例如穩定幣在內的資產支付手續費,但也不可避免地帶來技術架構的大改動,其安全性也需要更完備的驗證。引用阿劍的一段話“而如果某些技術,既沒有增加人們可選的東西,又犧牲了人們實際上選擇了的東西,那就沒有理由對這些技術懷有信心。”

參考文章

[1] https://etherscan.io/tx/0x4f719da4e138bd8ab929f4110e84d773b57376b37d1c635d26cd263d65da99cb

[2] https://hackmd.io/@matt/r1neQ_B38

[3] https://github.com/ethereum/EIPs/issues/28

[4] https://github.com/ethereum/EIPs/pull/208#issuecomment-313872489

[5] https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2034.md

[6] https://ethfans.org/posts/account-abstraction-eip-2938-why-and-what

[7] https://tinyurl.com/peep-an-eip-2938

[8] https://ethresear.ch/t/dos-vectors-in-account-abstraction-aa-or-validation-generalization-a-case-study-in-geth/7937