账戶抽象的動機、歷史和分析

概述

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

背景

以太坊的账戶有兩種類型，一種是外部账戶，另一種是合約账戶。外部地址是由用戶的公鑰經過哈希運算後取的後20個字節，形為

0x76D836358E7A2BB0F26c32Ce61Dc8DD540b02F7D 。

目前的以太坊的事務類型只有一種，必須由外部地址發起，合約地址無法主動發起事務。因此，任何合約自身狀態的改變，必須依賴於一個外部地址發起的事務，無論是一個多重籤名账戶，還是混幣器，或是任何智能合約的配置變更，都需要由至少一個外部账戶觸發。這樣的設計讓以下兩件事情無法完成。

無需以太的主動事務

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

非secp256k1的原生驗證方式

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

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

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

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

以账戶為中心——智能錢包

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

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

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

安全：如果账戶合約存在漏洞，那么所有用戶的資產都會遭受風險。專業的代碼編寫、安全審計和形式化驗證，都只能減少風險發生的可能，而不能保證它不會發生——Argent已經發生過。

費用：智能錢包的账戶創建需要費用，而轉账和任何調用任何合約都會比外部地址花費更多費用。這導致智能錢包的用戶需要支付更高的事務費用，這影響了他們的使用體驗

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

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

以資產為中心的方案提高了資產的可用性。不同於智能錢包需要創建智能合約账戶，無氣通證可以支持外部账戶在不使用以太的情況下進行轉账，反而是智能合約账戶需要兼容更多規範（例如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）主動發送事務的智能合約账戶。

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

• （2）提高混幣器的隱私性。

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

• （3）使用其它代幣支付手續費。

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

• （4）減少鏈上無效套利交易，提高可擴展性。

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

账戶抽象的代價

（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

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。