作者：Yuxing, SevenX Ventures
本文僅供學習交流，不構成任何投資參考。
隨著以太坊應用場景的不斷拓展和延伸，傳統以太坊錢包的外部賬戶（Externally Owned Accounts, EOA）方案的劣勢逐步顯露，其功能簡單而且性能一般，不支持並發交易，且存在密鑰管理的難題。智能合約錢包使用合約賬戶（Contract Accounts, CA）作為錢包地址，是一種相對來說新型的以太坊錢包解決方案，它能解決EOA 錢包的短板並且帶來更強大的功能。未來，你將可以選擇不去小心翼翼保護好自己的私鑰，也能夠享受幾乎同等級別的安全性；你還可以在去中心化的交易所裡享受到目前中心化交易所才有的便捷，但同時資金又是始終掌握在自己的手中，不用擔心交易所暴雷的可能……
前段時間發布的新版以太坊路線圖中，賬戶抽象智能合約規範ERC-4337 作為EOA 錢包轉向智能合約錢包的關鍵要素被寫入The Splurge 當中。那麼，智能合約錢包到底是什麼，而賬戶抽象與智能合約錢包又是什麼關係，它們是怎麼實現的，其未來的發展形態是什麼樣的，又存在著什麼機遇和挑戰呢？
以太坊的賬戶類型
以太坊有兩種類型的賬戶：外部賬戶（Externally Owned Accounts, EOA）和合約賬戶（Contract Accounts, CA）。外部賬戶是以太坊原生記錄用戶餘額的錢包賬戶地址，合約賬戶一開始的設計目的並不是用來記錄用戶錢包地址餘額的。
外部賬戶
EOA 是以太坊以及其他EVM 兼容鏈（或類EVM 鏈）才有的概念，嚴格來說包括BTC 在內的主流非EVM 鏈都沒有這個設定。 Metamask 錢包使用的就是外部賬戶，這一類的錢包也被稱為“EOA 錢包”，由用戶私鑰控制，其生成規則是：
私鑰→ 公鑰→ Keccak256 哈希→ 最後20 Bytes → 十六進製字符串（EOA 地址）
這個生成規則完全由數學變換而來，該地址未對應任何一段智能合約。使用該類型地址進行交易的時候，其節點驗證規則是：
交易簽名→ ec_recover → 公鑰→ （用上面的規則生成）地址→ 對比要操作的地址
如果驗證通過，則繼續後面的流程，不通過則拒絕交易。 EOA 在以太坊中的核心設定是作為交易的發起方並支付gas，即交易的觸發器，一筆交易無論後面有多少合約調用，一開始都必須由一個EOA 發起並且支付足夠的gas 才可以進行。一個EOA 地址的交易流程如下圖所示。
簡化的EOA 交易機制來源：Nethermind
外部賬戶的問題
目前EOA 賬戶是用戶使用錢包類型的絕對主流的錢包形態。以太坊社區對EOA 表達了一些擔憂，包括：
• 密鑰管理： 獲取資金的唯一方法是知道私鑰，最大的問題是在於單點故障，對於用戶來說，私鑰即資產。對於用戶來說，一旦私鑰丟失或者被盜，那麼就意味著資產損失。
• 依賴ECDSA 簽名： 更簡單且抗量子的數字簽名是對當前ECDSA 的明顯改進。
• 事務與操作是一對一的：一次不能執行多個操作會產生不必要的成本和糟糕的用戶體驗。
隨著區塊鏈應用場景的不斷擴大，用戶在區塊鏈上管理的不僅僅是自己的鏈上資產，可以還會有鏈上身份、社交關係甚至鏈上信用等等。而目前這些內容大多數都簡單地通過錢包映射到假匿名的個人，不僅是用戶掙扎在以助記詞為主的EOA 錢包私鑰管理方案中，而且應用也因EOA 錢包的簡單性在很多應用場景上受到限制。
有很多錢包方案嘗試解決這些問題：
• 圍繞著單點故障，MPC 錢包通過使用閾值簽名方案(TSS) 提供了一個更好的私鑰管理方案，而智能合約錢包則可以通過社交恢復、多重簽名等方案解決這個問題。
• 諸如批量交易、自定義驗證邏輯等而更好的用戶體驗、更強大的功能和可擴展性，則主要由智能合約錢包帶來。
MPC 錢包和智能合約錢包並不是完全獨立的方案，智能合約錢包也可以使用MPC+TSS 技術實現智能合約錢包的管理，Unipass 是一個很好的例子。
注：MPC 錢包指的是使用多方安全計算技術的錢包，它相當於為你的資產金庫僱傭了M 個管家，每個管家都不能夠獨立打開金庫，而使用閾值簽名方案(TSS) 相當於給你的金庫設置了一把需要N 把鑰匙才能打開的鎖，那麼MPC + TSS 錢包方案相當於提供了一個多角色金庫管理方案，M 個管家中需要有N 個管家同時提供他們所管理的鑰匙才能夠打開金庫。
合約賬戶
CA 是具備內部邏輯的以太坊賬戶，裡面既可以是業務邏輯（Token 合約用來記賬，質押合約用來放貸和清算），也可以是賬戶邏輯（比如gnosis safe 的多簽邏輯），而後者就是智能合約錢包（Smart Contract Wallet/Account, SCW）。 Argent 錢包使用的就是智能合約錢包，其開創了社會恢復這種模式，合約由內部邏輯代碼控制，其生成規則有CREATE 和CREATE2 兩種方式，這裡不展開。
與EOA 不同的是，CA 和公鑰沒有必然對應關係。比如gnosis safe 創建的CA 裡可以設定任意多把公鑰來解鎖它的地址對應的資產；當然CA 也可以不設定任何密鑰，而是由其他CA 的邏輯決定是否可以解鎖，比如DeFi 的借貸合約，只要還了錢就能取回質押的資產。
以太坊上除ETH 之外的所有資產都是由CA 承載，DeFi 等業務邏輯就更是全都由CA 來實現。然而CA 無法主動進行操作和支付gas 的設定也限制了它的能力，早在2016 年就有提案希望能讓CA 自己支付gas。 
智能合約錢包交易來源：Nethermind
由於交易只能從EOA 開始，為了改善用戶體驗，通常智能合約錢包會提供中繼（Relayer）服務，從用戶那裡獲取簽名消息並從服務提供商的EOA 提交到鏈上，其自定義費用機制可以將ETH 退回給用戶的EOA 錢包實現免Gas 費用。
目前來說，智能合約錢包沒有運行標準（EIP-4337 有希望成為標準），所以每個項目都必須使用像以太坊加氣站網絡（Gas Station Network, GSN ）這樣的元交易解決方案，或者努力創建和管理自己的中繼服務，以及管理費用機制和審計他們複雜的智能合同。
智能合約錢包
顧名思義，智能合約錢包（Smart Contract Wallet/Account, SCW）就是用CA 作為地址的錢包方案，特點是具備內部邏輯，智能合約錢包可以實現很多EOA 無法實現的功能，比如gas 代付、批量交易、多重簽名、權限管理、離線授權和社交恢復等等。
合約賬戶是與簽名者（授權者）分離的智能合約，它可以有自己的簽名和恢復邏輯。這意味著，如果您失去對Signer 的訪問權限，並不一定意味著您失去了對帳戶的訪問權限。同樣，這就是Account Abstraction 這個名字的由來。賬戶是從簽名者那裡抽像出來的。
賬戶抽象
目前以太坊的現狀是絕大多數人都在使用EOA 錢包，因為目前以太坊中的所有交易都必須從EOA 開始，EOA 必須有一些ETH 來支付gas，這使得新用戶無法快速進入。我們需要一種方案，來允許用戶使用包含任意驗證邏輯的智能合約錢包，這種方案稱為賬戶抽象（Account Abstract, AA）。
簡單的來說，賬戶抽象的結果是：
• 過去你將錢存在以太坊EOA 錢包地址上，受到各種EOA 地址限制的同時享受擁有私鑰就擁有資產的簡單便捷；
• 現在你將錢存在以太坊智能合約地址上，你可以通過不管理私鑰的方式控制你的錢包資產，簽名者和賬戶本身的分離使得你可以在一個更低安全級別進行交易的操作，而將賬戶本身放置於更高的安全級別。
“賬戶抽象”的目標是將賬戶類型的數量從2 種（EOA 和合約）減少到1 種（只有合約），並將簽名驗證、gas 支付和重放攻擊保護等功能從核心協議中移到EVM 。一直以來，實現賬戶抽像都是許多以太坊開發者的努力方向，這一點從EIP 的歷史可以看出。
EIP 歷史
賬戶抽象的概念從2016 年開始最早由Vitalik 提出，2017 年他本人發起了第一個提案。這麼多年來，賬戶抽象相關的提案有非常多，其中最主要的解決方案是EIP-3074 和EIP-4337。 EIP-3074 的提出比EIP-4337 要早一年，但EIP-4337 卻被納入了以太坊的新版路線圖，其主要原因是EIP-4337 的實現要更為輕量，無需修改以太坊的核心協議，同時也沒有EIP-3074 那樣的安全隱患。而EIP-4337 存在的用戶遷移問題、Gas 過高問題以及潛在智能合約安全問題是智能合約錢包的共通問題，Vitalik 認為賬戶抽象最佳現實途徑是在短期內開始大力支持ERC-4337，然後隨著時間的推移添加EIP 來彌補其弱點。 
賬戶抽象EIP 歷史
EIP-86 ： 2017 年，Vitalik 提出了EIP-86，試圖引入可以被視為“轉發合約”的智能合約錢包。這些轉發合約將只接受來自“入口點”地址的交易，只要交易遵循特定格式，任何人都可以從該地址發送交易。
EIP-1014 ： 這些轉發合約將根據它們的代碼被部署到一個特定的地址，引入了後來演變成EIP-1014 的想法，提出了CREATE2 操作碼。由於EIP-86 需要對協議進行重大更改，最終沒有被合併，而EIP-1014 於2018 年合併。
EIP-2938 ： 2020 年9 月，Vitalik Buterin、Ansgar Dietrichs 和Matt Garnett 提出了EIP-2938，該協議要求被識別為智能合約錢包的特殊智能合約將只接受賬戶抽象交易，這一新型交易由EIP- 2718 引入。他們將以編程方式設置交易的最大gas 並實施任意驗證方法。 EIP-2938 需要在EVM 中添加兩個新的操作碼才能使交易可行。這些操作碼顯著改變了核心協議，包含此類更改的過程可能會拖很長時間。
EIP-3074 ： 2020 年10 月，Ansgar Dietrichs 和Matt Garnett 等人提出了EIP-3074，引入了兩個新的操作碼：AUTH 和AUTHCALL。當一起使用時，它們允許智能合約代表EOA 發送交易，這使得例如多重簽名、批量和讚助交易、密鑰恢復以及更易於訪問的CeFi 交易所存款變得可能。但該EIP 存在一些安全風險，受到了一些批評，新的操作碼還會修改核心協議，研究人員開始思考一個更好的解決方案，最終被提議為EIP-4337。 
EIP-3074 交易流程來源：Nethermind
Layer2： 隨後，由於L2 沒有以太坊L1 的技術債務，可以開箱即用地引入帳戶抽象，Optimism 和Starknet 都有自己的賬戶抽象實現，ArgentX 是Argent 在Starknet 上的錢包版本，使用受EIP-4337 啟發的自定義帳戶抽象實現。最近的例子是Visa Crypto Auto Payments on StarkNet ，Visa 的以太坊自動支付解決方案是利用賬戶抽象概念並創建一種新型賬戶合約——可委託賬戶，其主要想法是擴展交易的可編程有效性規則以包括預先批准的允許列表。簡單來說，賬戶抽象可以將用戶賬戶發起的自動支付操作委託給預先批准的自動支付智能合約。 StarkNet的賬戶模型就是Visa目前所說的賬戶抽象，其實現受ERC-4337 的啟發，抽象賬戶則會檢查交易是否來自給定地址。 
Visa 在StarkNet 上實施賬戶抽象
EIP-4337 ： 2021 年9 月，Vitalik Buterin 與來自OpenGSN 和Nethermind 的以太坊研究人員吸取了以往努力的經驗教訓， 提出了EIP-4337 。 EIP-4337 添加了新的UserOperation 內存池希望完全取代當前的交易內存池，從而實現賬戶抽象。用戶將UserOperation 對象發送到以太坊節點，而不是交易，他們將一組這些對像打包成一個包含在以太坊鏈中的交易。這種打包交易稱為“ 入口點”智能合約，它處理UserOperation 對象並為其部署智能合約錢包。 
ERC-4337 交易流程來源：Nethermind
EIP-5003 ： 2022 年3 月， Dan Finlay , Sam Wilson 提出了EIP-5003，希望通過部署代碼代替外部帳戶，允許從ECDSA 遷移。這個EIP 引入了一個新的操作碼，它在EIP-3074 授權地址AUTHUSURP部署代碼。對於外部擁有的賬戶（EOA），連同EIP-3607 ，這有效地撤銷了原始簽名密鑰的權限。這是對EIP-3074 的補充，EIP-3074 只能授予額外的參與者權限，但不能撤銷。
EIP-5792 ： 2022 年10 月， Moody Salem 提出了EIP-5792，該EIP 添加JSON-RPC 方法，用於從用戶錢包發送多個函數調用，並檢查其狀態。新方法在底層交易方面比現有交易發送API 更抽象，以允許錢包實現之間存在差異，例如使用EIP-4337 的智能合約錢包或支持通過EIP-3074 捆綁交易的EOA 錢包。 Dapps 可以使用這個更抽象的接口來支持不同類型的錢包而無需額外的工作量，並提供更好的用戶體驗來發送函數調用包（例如EIP-20 #approve後跟一個合約調用）。
EIP-4337 詳解
在EIP-4337 中，一共有6 個組件：入口點合約（EntryPoint contract）、出納合約（Paymaster contract）、用戶操作（UserOperation）、打包器（Bundler）、發送人合約（Sender Contract）和聚合器（ Aggregator）。
• EntryPoint: 入口點合約處理傳遞給它的交易操作的執行和驗證。全局入口點合約接收來自各個Bundler 的打包交易，並通過每個UserOperations 來運行驗證和執行循環。
• Paymaster: 這是可選合約，可以代表用戶為交易支付gas。用戶可以不依賴他們的錢包，而是獲得由出納員贊助的交易費用。
• UserOperations: 這些是為代表用戶執行交易而創建的交易對象。執行發生在Sender Contract 確認之後。這些操作由Dapp 生成。
• Bundlers: Bundler 從內存池中獲取UserOperations，並將它們打包在一起以將它們發送到EntryPoint contract 以供執行。
• Sender Contract: 這些是智能合約形式的用戶錢包賬戶。
• Aggregator: 聚合器是錢包信任的輔助合約，用於驗證聚合簽名。
整個ERC-4337 標準的運行邏輯包括兩個循環：驗證循環的執行循環，它們組合在一起完成了賬戶抽象的邏輯。
驗證循環：入口點合約通過每個UserOperation 並調用Sender Contract 中的“檢查功能”。 Sender Contract 運行此功能以檢查UserOperation 的簽名並補償打包這些交易的Bunder。
執行循環：將每個UserOperation 中的調用數據發送到Sender Contract 。錢包運行執行操作以執行操作中指定的交易。然後Sender Contract 將在操作執行後退還剩餘的氣體。 
驗證循環和執行循環來源：EIP-4337
引入的出納員角色允許應用程序開發人員為其用戶補貼費用。當paymaster 不等於零地址時，入口點執行不同的流程： 
引入出納員的驗證循環和執行循環來源：EIP-4337
在驗證循環中，入口點合約除了調用“檢查功能”以外，還必須檢查paymaster 是否被質押，並且還有足夠的ETH 存入入口點合約以支付操作費用，然後調用paymaster 上的“檢查功能”以檢查paymaster 是否願意支付。
在執行循環中，入口點合約必須在主執行調用後調用paymaster 上的Post-op。它必須通過在內部調用環境中進行主要執行來保證Post-op 的執行，並且如果內部調用環境回撤，則嘗試在外部調用環境中再次調用Post-op（即使用戶操作回撤，也應當支付gas費用）。
Vitalik 總結認為，ERC-4337 作為一個純自願的ERC 可以做很多事情。然而，在一些關鍵領域，它比真正的協議內解決方案更弱：
1. 用戶遷移問題，現有用戶如果不將其所有資產和活動移動到新帳戶，則無法升級；
2. 額外的gas 開銷（基本UserOperation 用戶操作約42 k，而基本交易約為21 k）；
3. 智能合約安全問題，它較少受益於協議內抗審查技術（例如crLists），該技術以交易為目標而會忽略用戶操作（user operation）
而實現最佳效果的一條現實途徑，是在短期內開始大力支持ERC-4337，然後隨著時間的推移添加EIP 來彌補其弱點。這並不一定需要大家專門承諾遵守ERC-4337。相反，可以將協議內支持設計為更通用，並支持ERC-4337 及其替代方案和改進。目前ERC-4337 的實現方案有Biconomy、Soul Wallet 和eth-infinitism，他們都編寫了自己的入口點合約實現方案，而入口點合約是該標準下智能合約安全的核心所在。
Vitalik 提出了賬戶抽象的可能路線圖。
短期
1. 將ERC-4337 全面投入生產。理想情況下，可以使用簽名聚合功能對其進行擴展，以實現rollup 友好性。
2. 應該有接入ERC-4337 的易於使用的瀏覽器錢包。
3. 考慮實現簽名聚合和壓縮，以使ERC-4337 對L2 更加友好；
4. 在L2 協議中引導ERC-4337 生態，其中gas 成本問題會較少；
中期
1. 實施Verkle 樹，添加EIP 以降低gas 成本；
2. 添加可選的EOA-to-ERC-4337 轉換；
3. 在提議者/建設者分離（Proposer/Builder Separation, PBS） 推出的同時或不久之後添加crList 邏輯；
長期<br/>考慮強制轉換，執行不規則的狀態轉換，將字節碼部署到每個可能是EOA 的帳戶中，但這種方法的缺點是需要修改核心協議以及對於礦工/驗證者來說成本很高。
項目掃描
SevenX Ventures對市場上的智能合約錢包進行了簡單掃描，收集整理了一些市場上比較主流的智能合約錢包項目，其綜合情況如下： 
實現案例
我們選取了兩個項目進行案例介紹，對他們的功能和相應的實現原理進行了解析。其中Unipass 是傳統智能合約錢包的典型代表，而Candide Wallet 是使用ERC-4337 標準錢包的典型代表，他們擁有豐富的公開文檔，對他們的產品功能實現進行了詳細地解釋。
Unipass
UniPass Wallet 是一個支持郵件社交恢復的智能合約錢包解決方案。通過UniPass Wallet，開發者可以在產品內提供流暢的免私鑰、免gas 的用戶體驗，從而快速地吸引海量的Web2 用戶。其特點是：免私鑰、抗審查、免gas、郵件恢復、隱私保護、多平台和支持多鏈。
免私鑰、抗審查、郵件恢復和隱私保護的特性主要是由Unipass 的秘鑰管理方案帶來的。 UniPass Wallet 的合約賬戶中支持用戶設置多種類型的密鑰。已經支持的密鑰類型包括：
1. 我們經常使用的外部地址，支持EIP-1271 協議（一個合約的標準簽名驗證方法）的合約賬戶。
2. UniPass 的用戶還可以使用郵箱來作為密鑰。我們在鏈上部署的智能合約，可以通過DKIM （ 域名密鑰識別郵件）來以密碼學的手段驗證用戶對於一個互聯網郵箱的所有權。在驗證過程中，UniPass 採用了零知識證明技術，確保用戶郵件信息的隱私安全。
3. 在未來， UniPass Wallet 還將考慮支持相比於secp256k1 更高效更簡潔的簽名算法（比如：Schnorr，BLS），後量子安全簽名算法（比如：Lamport，Winternitz）等等。
秘鑰主要有三種角色：
1. Owner 是賬戶的所有者。 Owner 控制賬戶的部署、升級、銷毀等核心功能，是賬戶的最高權限控制者。
2. Operator 是賬戶資產的執行者。 Operator 負責賬戶的資產轉賬、合約調用、授權許可等功能，是用戶日常使用的密鑰。
3. Guardian 是賬戶的守護者。當賬戶內的密鑰損毀或丟失，用戶失去賬戶控制時，可以通過guardian 來恢復賬戶。 UniPass 提供的一大特色功能就是：鏈上郵件社交恢復。
在UniPass Wallet 的智能合約中，用戶是通過一系列具有角色權重的密鑰來管理賬戶的。除了以安全多方計算（MPC）方案實現的Master key 外，用戶還可以設置多種其他類型的密鑰。每一個密鑰都有一個對應的角色及權重。用戶只有在集齊了總角色權重門限超過要求的密鑰後，才可以獲得該角色的授權。
一個密鑰允許被賦予單個或多種角色。密鑰在被賦予某個角色的時候，會同時被設定對應的權重。而用戶要開始執行某身份的相關操作時，需要用該角色總權重達到100 及以上的單把或多把密鑰進行簽名。例如在初始註冊賬戶時，用戶可以跳過守護者設置。相關參數可以設置如下：
免gas 的特性是通過一個第三方relayer 實現的，用戶發起交易時需要relayer 幫助用戶發起交易。在這個過程中，relayer 可以支持用戶使用任意代幣支付gas，甚至可以完全幫助用戶代付gas，實現免gas 的體驗。 Relayer 是個開源的服務端程序，UniPass 會運行默認的relayer，合作方或者任意第三方也都可以運行relayer。
Candide
CANDIDE 是一群貢獻者，他們公開合作構建的公共產品，沒有單一的實體或公司控制其發展。 Candide Wallet Beta 是一款自託管移動智能合同錢包。它目前部署在Goerli 測試網上。它現在可以在Android Test 和IOS Testflight 上使用。
Candide Beta 其技術基礎是Stackup 分叉的ERC-4337 實現和Gnosis Safe 的開源框架，其特性包括無助記詞、社會恢復、批量交易、免Gas 費等。
其中，無助記詞、批量交易、免Gas 費等特性其實現邏輯與ERC-4337 的邏輯相同，採用eth-infinitism 開發的入口點合約完成。 Candide 運行自己的打包器，將UserOperation 打包為自己錢包的服務。該方案中，大部分的安全取決於入口點合約，而非錢包本身的構建。
此外，社會恢復的特性來源於Candide 將Safe 用於其基礎錢包合約。這讓Candide 可以利用最受信任的DAO 合約來管理數字代幣。 Candide 將使用Gnosis Safe 模塊化設計來交付其核心功能，包括社交恢復，以及未來的功能，如時間鎖定和取款限制。該社交恢復模塊與Unipass 的邏輯相同，不同的是Unipass 主要是郵件恢復，但Candide 的守護人可以是任何具有公共地址的簽名者，如家人朋友、機構和硬件錢包。
關於合約錢包的思考
早期的智能合約錢包都是根據非常具體的問題進行合約開發，如Gnosis Safe 的多簽以及Argent 的社會恢復功能。早期的這些產品設計複雜，很多時候也不公開透明，且沒有形成統一的標準，很難作為中間件插入到其他的應用當中。對於這一類型的產品，其判斷標準更多需要從使用場景出發，有沒有抓住用戶的核心需求，如Safe 的多簽功能就抓住了用戶的核心需求之一。
隨著ERC-4337 的誕生，快速構建一個擁有無助記詞、批量交易、免Gas 費的錢包變得非常方便，統一的標準也讓基於該標準構建的開發套件具有可組合性，能夠作為中間件插入不同的應用，並且保持互操作性。
因此，在考量早期的智能錢包方案的時候，能夠ERC-4337 兼容是非常重要的一點。而對於基於ERC-4337 的解決方案，由於技術大多是開源的，其考量方案建議圍繞以下幾點：
1. 技術：入口點合約、打包器和聚合器（如果有）的構建方案，以及除了ERC-4337 帶來的功能以外的功能構建方案，如社會恢復功能
2. 運營：如何構建社區、推向市場和贏得用戶
3. 體驗：錢包使用用戶體驗是否足夠好，如流暢、穩定等
4. 以及一些其他to C 產品的主要考察邏輯
未來錢包的模式更有可能是類似B2B2C 的模式。錢包作為一個C 端產品存在的同時，更重要的是提供一套成熟的SDK 方案用於其他應用集成為應用內錢包，再面向C 端用戶。其中，打包器和聚合器在早期主要是中心化的構建方式，後面有可能形成模塊化的網絡，但由於這一塊是價值捕獲的核心，錢包採用他人構建的打包器網絡需要經過經濟收益的博弈。
APP 
