詳解近期熱議的「帳戶抽象」：Devcon後的新風口？

剛剛結束的 Devcon 上，帳戶抽象算是最熱的幾個話題之一，最近可以經常看到 AA / EOA / SCW / 4337 等縮寫和代號在各種 talk、panel 和資訊流里出現。再加上敘事開始往「Onboarding next billion users」的方向發展，一些新的形容詞也開始出現在產品之前，比如 seedless / gasless / social recovery / non-custodial。相信看完這兩句的你已經開始腦殼疼了，那麼接下來就讓我儘自己所能來幫大家梳理一下這些名詞概念到底代表什麼。

閱前提示：本文不是嚴肅的技術文檔，可能會用不精確但容易理解的語言進行闡述或比喻，歡迎大家以此為起點深入探索這些技術的細節。

EOA - Externally Owned Accounts

EOA 中文叫做外部帳戶，我們最熟悉的 MetaMask 生成的地址就是 EOA。它的特點是原理簡單，比如生成規則是：

私鑰 - 公鑰 - Keccak256 哈希 - 最後 20 Bytes - 十六進制字符串（EOA 地址）

可以看出這個規則非常直接，全是由數學變換計算出來的，生成的地址內部沒有任何結構和邏輯。節點驗證一筆交易是否被地址 owner 授權的時候也是固定的規則：

交易簽名 - ec_recover - 公鑰 -（用上面的規則生成）地址 - 對比要操作的地址

對比結果一致那麼驗簽通過，進行後續流程；不通過則直接打回，不會進一步廣播交易。

EOA 的另一個設定是作為交易的發起方並支付 gas，相對應的 CA（合約帳戶）只能被其他 CA 或者 EOA 調用。也就是說，EOA 是交易的觸發器，一筆交易無論後面有多少合約調用，一開始都必須由一個 EOA 發起並且支付足夠的 gas 才可以進行。

需要指出的是，EOA 是以太坊以及其他 EVM 兼容鏈（或類 EVM 鏈）才有的概念，嚴格來說包括 BTC 在內的主流非 EVM 鏈都沒有這個設定。

CA - Contract Accounts

CA 中文叫做合約帳戶（也曾被稱為內部帳戶），我們常見的 ERC-20 Token 合約、DeFi 業務合約等都有一個跟 EOA 長得很像的地址，這就是 CA。

在設定上，CA 是以太坊世界的原住民，EOA 和 ETH 是為 CA 的業務邏輯準備的觸發器和燃料；實際使用下來，以太坊上除 ETH 之外的所有資產都是由 CA 承載，DeFi 等業務邏輯就更是全都由 CA 來實現。然而 CA 無法主動進行操作和支付 gas 的設定也限制了它的能力，早在 2016 年就有提案希望能讓 CA 自己支付 gas。

簡單來說，CA 是具備內部邏輯的以太坊帳戶，裡面既可以是業務邏輯（Token 合約用來記賬，質押合約用來放貸和清算），也可以是帳戶邏輯（比如 gnosis safe 的多簽邏輯），而後者就是我們即將提到的「SCW - 智能合約錢包」概念。

CA 的地址規則是通過計算生成的，有 CREATE 和 CREATE2 兩種方式，這裡不再展開。大家只需要記住 CA 和公鑰沒有必然對應關係即可，比如 gnosis safe 創建的 CA 里可以設定任意多把公鑰來解鎖它的地址對應的資產；當然 CA 也可以不設定任何密鑰，而是由其他 CA 的邏輯決定是否可以解鎖，比如 DeFi 的借貸合約，只要還了錢就能取回質押的資產。

SCW/A - Smart Contract Wallet/Account

智能合約錢包應該是字面意思最好理解的了，也就是用 CA 作為地址的錢包方案，而我們常用的 EOA 錢包方案是用前述的公鑰變換結果作為地址。由於具備內部邏輯，智能合約錢包可以實現很多 EOA 無法實現的功能，比如 gas 代付，批量交易，權限管理，離線授權，社交恢復等等。

這裡舉幾個例子來展示一下智能合約錢包的擴展潛力：

1. Gnosis safe 利用智能合約錢包架構實現多簽邏輯；

2. 用戶可以在一筆上鏈交易中同時給多個地址發送不同的 token，也可以在用 uniswap 時讓 approve 和 swap 在一筆交易里完成，從而做到需要多少授權多少，避免因為過度授權造成安全隱患。

3. 用戶可以給不同資產設定不同的操作權限，比如給 PFP 設定比普通 ERC-20 token 更高的操作門檻（例如需要一把由硬體錢包管理的 admin key 才能轉移），這樣即便日常使用的環境發生密鑰泄露，駭客也無法將高價值資產轉走，在安全和便利中間取得平衡。

4. 用戶可以簽署一個離線授權「誰能給我 100 ETH，就可以轉走我的某個 BAYC」，這樣不需要授權給第三方合約，用戶就可以跟其他人 P2P 地完成原子交易。

AA - Account Abstraction

帳戶抽象其實不是一個新概念了，最早可以追溯到 2015 年的一些討論，當時 Vitalik 認為至少要讓以太坊用來驗證交易的密碼學算法做到可替換，比如換成性能更優的 ed25519（詳見這裡），可以說 7 年來 Vitalik 和 EF 都沒有停止對帳戶抽象方案的討論和探索，這裡有個整理好的 link tree 可以幫大家回顧一下歷史。

那麼帳戶抽象怎麼理解呢？這裡我引用一下 ERC-4337 里對其目標的描述：

Achieve the key goal of account abstraction: allow users to use smart contract wallets containing arbitrary verification logic instead of EOAs as their primary account. Completely remove any need at all for users to also have EOAs (as status quo SC wallets and EIP-3074 both require)

可以看出以太坊對於帳戶抽象的期望是改變目前大多數人都在使用 EOA 的現狀，希望用戶轉向 SCW，並且把生態對 EOA 的依賴完全去除。除了裡面提到的 EIP-3074 之外，還有一個更為激進和遠期的 EIP-5003，這裡同樣引述幾段原文（有省略）：

EOAs … are limited by the protocol in a variety of critical ways. These accounts do not support rotating keys for security, batching to save gas, or sponsored transactions to reduce the need to hold ether yourself. There are countless other benefits that come from having a contract account or account abstraction, like choosing one"s own authentication algorithm, setting spending limits, enabling social recovery, allowing key rotation, arbitrarily and transitively delegating capabilities, and just about anything else we can imagine.

…This EIP provides a path not to enshrine EOAs, but to provide a migration path off of them, once and for all.

不難看出，EIP-5003 的目標是一次性將 EOA 轉換為 CA，讓所有用戶用上 SCW，徹底解決向前兼容的問題。（經過上面的名詞解釋，看這些縮寫是不是順暢了些？）

到這裡大家對 AA 的來龍去脈和未來目標應該有所了解了。但需要指出的是，AA 這個概念不是以太坊和 EVM 專屬的，很多鏈原生已經具備了不同程度的 AA 特性。比如 EOS / Polkadot / Near / Solona / Flow / Aptos … 甚至 BTC（單簽 / 多簽 / Taproot），這些鏈在設計時就已經將帳戶做成了有內部結構甚至具備權限管理能力的狀態，還有 StarkNet / CKB 等具備更完善的帳戶抽象能力。說到這裡大家不難發現，以太坊的 AA 是在解決 EOA 意外地流行帶來的歷史遺留問題，從而在帳戶層面上變得更加先進和靈活。

4337 - ERC 4337

從上面對 AA 的討論里不難看出，ERC-4337 只是這個方向眾多提案中的一個，但是為什麼大家一提到 AA 或者 SCW 就會說到它呢？我們來看這個文檔的副標題：

An account abstraction proposal which completely avoids consensus-layer protocol changes, instead relying on higher-layer infrastructure.

也就是說，ERC-4337 是 AA 的路線第一次從「暴力革命」轉向「和平演變」，不再追求利用共識層的改變實現 AA，而是轉而使用 SCW 這種用戶層的方案。並且為了實現更好的互操作性，ERC-4337 定義了一些 SCW 應該實現的接口，以及元交易打包、gas 代付等基礎設施的框架。它的出現讓目前差異極大的各種 SCW 方案能夠擁有統一的用戶交互界面以及共用一些生態層面搭建的開放基礎設施，有助於各種場景快速實現自己需要的 SCW 方案。另一方面，ERC-4337 的推動有助於促進生態其他參與方提升對 SCW 的兼容性，比如驗簽需要的 EIP-1271 和有些 DeFi 協議里定義的禁止 CA 交互的一些規則。

Seedless

這裡的 seed 指的是 seed phrase，就是我們創建錢包的時候經常被要求備份的助記詞。那麼 seedless 的意思就是「無助記詞的」，或者也可以說成「無私鑰的」。注意這個「無」並不是實際意義上的沒有密鑰，而是指不需要用戶備份助記詞 / 私鑰或者感知到它們的存在。

一個常見的問題是，如果用戶不備份助記詞，用戶是不是就沒有帳戶的控制權了？一旦用戶切換新設備環境，帳戶不就無法訪問了嗎？沒錯，只是把用戶備份助記詞的功能砍掉的話只能算是產品設計失誤，而 seedless 追求的是用戶「不需要」知道助記詞的存在，同時依然擁有帳戶的完全控制權。也就是說，用戶（且只有用戶自己）擁有在新設備自主恢復帳戶控制的能力，只是不再依賴助記詞這種 UX 很差、過於 geek 的方式，比如下面要講到的社交恢復就是非常好的一種。

Gasless

這裡的 gas 指的是 gas fee，所以 gasless 的意思是「免 gas fee 的」。同樣的，gasless 也不是真的不需要支付 gas fee，而是指用戶不需要被迫去了解 gas 概念，更不用提前購買各種原生 Token 來支付 gas。

那麼 gas 誰來付？分兩種情況：

一種是用戶帳戶里已經有 crypto asset 的時候，比如 play to earn 得到 token，或者領到的空投，亦或是別人的轉賬，只要這些 token 有一定的價值和流動性，就會有 relayer 願意接受它們並幫用戶支付 gas，以此賺取收益。

另一種是用戶帳戶里沒有有價 token，比如剛剛創建的帳戶。如果此時需要鏈上交互，應用方可以選擇資助用戶一些「定向」用途的 gas 來幫他們 bootstrap，從而降低用戶流失，這時即便算上 gas 補貼的消耗，整體的用戶獲取成本反而可能會更低；或者可以通過讓用戶觀看廣告等方式來換取一些 gas。這兩種策略在 gas 成本較低的 L2 上都非常有效。

Social Recovery

社交恢復是指利用社交關係幫助用戶在丟失密鑰的情況下重新獲得帳戶訪問權的機制。如果你用微信登錄過新設備，應該有過「讓你的兩個朋友發送 xxx 給你的賬號以登錄」的體驗——這就是社交恢復想達到的效果，只不過驗證方從微信變成了智能合約。

一種常見的誤區是把利用社交賬號來創建 / 登錄錢包的方案稱為社交恢復，這是錯把「社交關係」與「社交平台賬號」劃了等號。老牌智能合約錢包 Argent 就內置了社交恢復能力，它要求你的 guardian 提供一個以太坊地址，從而在你需要登陸新設備時提供簽名來進行授權，然而這一方案的潛在設定就是：你的 guardian 一定比你在管理以太坊帳戶上更專業，否則當你需要他們簽名的時候，如果他們自己的帳戶已經無法訪問，你的帳戶也會連帶遭殃。所以一種更加可行的辦法是利用 email 的密碼學證明（DKIM Signature）或者電子護照等生活中常見的密碼學工具來增強社交恢複方案的實用性。

Non-custodial

非託管可以說是 crypto 行業最政治正確、也是被濫用最多的概念之一了，因為很多時候各家都會有自己的定義。這裡我也分享一下我們對非託管的定義，主要有兩方面：

1. 錢包開發商無法擅自操作用戶的帳戶

2. 錢包開發商無法阻止用戶操作自己的帳戶

如果你也認同這兩點，那麼判斷一個錢包是託管、半託管還是非託管就可以直接拿這兩個規則去檢驗了：

不滿足 1 - 託管；滿足 1 - 不滿足 2 - 半託管；1、2 都滿足 - 非託管。

那麼知道了是哪種託管程度有什麼用嗎，用戶可能並不 care 背後的原理，只要好用就行了唄！沒錯，其實我也部分認同這種觀點，至少在現在的階段，行業還沒有發展到發生用戶認知範式轉移的程度。其實我認為三種類型的方案分別適用於不同的場景：

1. 託管方案 - 適用於交易平台、大機構金服、強合規等場景，比如 coinbase 提供的一些服務。特點是用戶量少，不需要應對高頻交互，而且客單價高，能支撐服務商花費大成本來維護一系列高防系統。

2. 半託管方案 - 適用於相對高端的個人用戶群體。他們明白服務方可以審查自己的交易，並且有能力提前準備備份方案（比如導出私鑰），在服務方主動或被動拒絕服務時可以不影響自己的資產安全。這樣日常使用時可以享受安全和便利，極端情況下可以保全資產。注意這種方案對服務商的運維能力要求也非常高，畢竟個人用戶量大，日常跟各種應用的交互需求也更高，再就是對數據可用性要求高，畢竟一旦丟失服務端保存的數據有可能導致所有沒備份的用戶永遠無法訪問帳戶。

3. 非託管方案 - 適用於面向 mass adoption 的場景。初聽上去可能是反直覺的，但是從成本上講，非託管方案是唯一能夠在低客單價的場景里保證足夠的安全性和可用性的方案。如果一個面向大規模用戶場景的應用方打算選擇上面兩種方案，就一定要考慮對方能否為自己的用戶群提供足夠安全可用的服務，否則一旦內部人員作惡、駭客入侵或不可抗力導致服務停擺，自己的所有用戶都會受到牽連，自己的業務也可能因此一蹶不振。歷史上的無數次案例都在講述一個故事，安全無小事，為用戶負責就是為自己負責。

MPC - Multi-Party Computation

多方安全計算跟零知識證明（ZKP）可以並稱當下 Web3 兩大「魔法」，一旦跟它們沾邊，似乎原來做不到的事情 somehow 就能做了。實際上有些情況是這樣的，尤其是 ZKP，可以利用機率換可行性；MPC 則是通過分散控制權來達成風控或者災備能力。

MPC 其實是一種範式，包含很多技術方案，在目前 Web3 的語境下大都指的是 tss。

TSS - Threshold Signature Scheme

門限簽名是一種分布式多方簽名協議，包含分布式密鑰生成、簽名，以及在不改變公鑰的情況下更換私鑰碎片的 re-sharing 等算法。

一個 m-n 的 tss 指的是一個公鑰對應了 n 個私鑰碎片，其中 m 個碎片的聯合簽名可以被公鑰驗簽成功。不難發現這個邏輯類似於多簽（multi-sig），他們的區別主要在公鑰的數量上。

舉例來說，2-2 的多簽是一個門上掛了 2 把鎖，必須用兩個鑰匙把它們都打開才能開門；2-2 的 tss 是一個門上掛了 1 把鎖，但是鑰匙有兩片，合起來用才能打開門。這裡為了好理解，描述並不嚴謹，兩把鑰匙合成一把其實更符合 Shamir Secret Sharing 算法的情況；tss 算法下的密鑰碎片是不會相遇的，而是它們分別簽名之後，通過特定算法可以用對應的公鑰驗簽通過。

那麼 tss 是不是一定是託管或者非託管的？其實沒有必然聯繫，主要看最終的方案如何設計和取捨。非託管方案要求用戶擁有獨立操作帳戶的能力，所以用戶必須掌握不少於門限數量的密鑰碎片，例如 2-3 的話用戶需要掌握 2 片，而 2-2 的方案無法達成非託管，最多可以做到半託管（比如 ZenGo）；但是如果用戶管理最多的私鑰碎片，那麼勢必會提高對用戶能力的要求，很難做到 mass adoption。

原文連結