剛剛結束的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 代幣合約、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 代付，批量交易，權限管理，離線授權，社交恢復等等。
這裡舉幾個例子來展示一下智能合約錢包的擴展潛力：
-
Gnosis safe 利用智能合約錢包架構實現多簽邏輯；
-
用戶可以在一筆上鍊交易中同時給多個地址發送不同的token，也可以在用uniswap 時讓approve 和swap 在一筆交易裡完成，從而做到需要多少授權多少，避免因為過度授權造成安全隱患。
-
用戶可以給不同資產設定不同的操作權限，比如給PFP 設定比普通ERC-20 token 更高的操作門檻（例如需要一把由硬件錢包管理的admin key 才能轉移），這樣即便日常使用的環境發生密鑰洩露，黑客也無法將高價值資產轉走，在安全和便利中間取得平衡。
-
用戶可以簽署一個離線授權「誰能給我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 概念，更不用提前購買各種原生代幣來支付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 → 託管；滿足1 不滿足2 → 半託管；1、2 都滿足→ 非託管。
那麼知道了是哪種託管程度有什麼用嗎，用戶可能並不care 背後的原理，只要好用就行了唄！沒錯，其實我也部分認同這種觀點，至少在現在的階段，行業還沒有發展到發生用戶認知範式轉移的程度。其實我認為三種類型的方案分別適用於不同的場景：
-
託管方案 – 適用於交易所、大機構金服、強合規等場景，比如coinbase / fireblocks 提供的一些服務。特點是用戶量少，不需要應對高頻交互，而且客單價高，能支撐服務商花費大成本來維護一系列高防系統。
-
半託管方案 – 適用於相對高端的個人用戶群體。他們明白服務方可以審查自己的交易，並且有能力提前準備備份方案（比如導出私鑰），在服務方主動或被動拒絕服務時可以不影響自己的資產安全。這樣日常使用時可以享受安全和便利，極端情況下可以保全資產。注意這種方案對服務商的運維能力要求也非常高，畢竟個人用戶量大，日常跟各種應用的交互需求也更高，再就是對數據可用性要求高，畢竟一旦丟失服務端保存的數據有可能導致所有沒備份的用戶永遠無法訪問賬戶。
-
非託管方案 – 適用於面向mass adoption 的場景。初聽上去可能是反直覺的，但是從成本上講，非託管方案是唯一能夠在低客單價的場景裡保證足夠的安全性和可用性的方案。如果一個面向大規模用戶場景的應用方打算選擇上面兩種方案，就一定要考慮對方能否為自己的用戶群提供足夠安全可用的服務，否則一旦內部人員作惡、黑客入侵或不可抗力導致服務停擺，自己的所有用戶都會受到牽連，自己的業務也可能因此一蹶不振。歷史上的無數次案例都在講述一個故事，安全無小事，為用戶負責就是為自己負責。
-
MPC – Multi-Party Computation
多方安全計算 跟零知識證明（ZKP）可以並稱當下Web3 兩大「魔法」，一旦跟它們沾邊，似乎原來做不到的事情somehow 就能做了。實際上有些情況是這樣的，尤其是ZKP，可以利用概率換可行性；MPC 則是通過分散控制權來達成風控或者災備能力。
MPC 其實是一種範式，包含很多技術方案，在目前Web3 的語境下大都指的是tss。
-
TSS – Threshold Signature Scheme
門限簽名 是一種分佈式多方簽名協議，包含分佈式密鑰生成、簽名，以及在不改變公鑰的情況下更換私鑰碎片的re-sharing 等算法。
一個mn 的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。
