2022 年末到 2023 年的現在是 Account Abstraction(AA)資訊大爆炸的一段時間,上到以太坊開發者大會,下至無數的新聞媒體都在說抽象帳戶,各種眼花撩亂的資訊讓人難以掌握,加上抽象帳戶本身的實作還存在許多可塑性,導致大家更難理解這是什麼東西,也無法理解為何我們會需要它。
所以這篇文主要是分享並整理一些這半年來我在學習 AA 時整理的資源,並且讓大家根據自己的需求以及想要了解的深度來決定要閱讀哪些資源。
Author: ChiHaoLu(chihaolu.eth) @ imToken Labs
Special thanks to NIC Lin for reviewing this post.
Table of Contents
Notes
- 以下所有條列式連結皆為排序過的,排序越前建議優先服用。
- 以下所有條列式連結,如果講述的是同樣內容我會盡量留下一個就好減少大家負擔,非必要不會重複提及
- 非必要但很值得看的內容我會留著但會加上 Optional Tag:🉑
以太坊的帳戶介紹
在了解以太坊的帳戶現況之前,最重要的是具備一定基礎內容的了解,但不用非常深入的知道底層原理,只要大概知道就好。包含:
- 何謂智能合約
- 何謂 EOA、Contract Account
- 何謂 Public Key、Private Key 與 Address
- 何謂 transaction,一個 transaction 會具備哪些元素
- 何謂 Signature
- High Level 的了解礦工如何處理交易,大概知道會驗證哪些內容
除了以上提到的點,如果還能具備 State(e.g. Balance, nonce)、EVM 等相關的基本概念也會很有效的幫助理解。
在這個階段的讀者適合(但不限於)以下學習資源:
以太坊的帳戶現況
這邊假設大家有一點知道什麼是以太坊中的原生帳戶,以及公私鑰、地址之間的關係,還有簽章跟交易代表的意涵是什麼了,但可能還不是非常熟悉,或者不知道了解這些事情可以幹嘛。
這裡先建議大家可以了解一下以下名詞,可以加速理解後面提到的內容:
- Multi-Sig Wallet:什麼是多重簽名錢包?
- Meta Transaction(以下任選一即可):
1. 沒程式碼:邁向完美區塊鏈使用體驗 — 元交易(Meta-Transaction)
2. 有程式碼:Meta Transactions 如何改變 DApp 付費生態 🉑
這個章節主要負責帶著大家更深入瞭解帳戶的設計,還有帶著大家思考當前帳戶可能會遇到的問題。主要內容基本上都整理在這篇文章裡:Account Abstraction 介紹(一):以太坊的帳戶現況。
當前的帳戶設計可能會遇到的問題如下,大家可以在閱讀完資源之後嘗試看看自己能不能理解:
- 原生 EOA 的私鑰保存困難(因為私鑰又臭又長,容易搞丟又不能點忘記密碼)
- 原生協議只能使用 ECDSA 這個簽章演算法(ECDSA 目前沒有不安全,但 web2 大部分都還是使用其他簽章演算法)
- 不想依賴中心化的 Relayer 的話,EOA 手續費只能透過 Ether 支付(我只想使用 USDT 還是必須持有 Ether 來付 Gas Fee,不太舒服)
- 合約帳戶(CA, Contract Account)無法作為交易發起者(我想要享受 CA 帶來的方便性卻不想依賴中心化的 Relayer 怎麼辦)
- EOA 一筆交易只能包含一個函式呼叫行為(每次都需要支付 Basic Fee,且每次都需要簽名導致體驗很差)
以太坊未來的帳戶體驗
有了以上所有的 background 大家應該已經知曉以太坊的原生帳戶是什麼形狀了,接下來就是介紹 AA 的目的以及他是如何運作的。但本章節提到的內容不會有程式碼還有複雜的系統設計,僅是 High Level 的幫助大家知道 AA 為什麼可以幫助我們增進以太坊上的帳戶體驗。
- Account Abstraction 介紹(二):以太坊未來的帳戶體驗
- 什麼是 ERC-4337 (或稱以太坊帳戶抽象,Account Abstraction for Ethereum)?
- Account abstraction 🉑
- Ethereum Account Abstraction — Everything you need to know 🉑
主要的重點在於:
- 何謂 UserOperation:就像我們過往的交易物件一樣
- 何謂 UserOperations memPool:就像過往的礦工交易暫存池一樣
- 何謂 Bundler:負責從 memPool 挑出交易打包
- 何謂 EntryPoint Contract:接收 Bundler 送來的 bundle transaction,並且呼叫 Wallet Contract
- 何謂 Wallet Contract:負責儲存用戶的資產、驗證交易、支付手續費、執行交易
- 何謂 Paymaster:Paymaster 可以替 Wallet Contract 處理手續費
- 如此設計可以怎麼樣解決我們之前提到過原生帳戶會有的問題
- 抽象帳戶有哪些 Features:擺脫 Native token、交易可以使用其他驗證方法、用未來會獲得的 ETH 支付當前的手續費
另外很推薦大家這篇文章:ERC-4337 — Misconceptions and Valid Concerns
深入了解 AA 設計
在這個階段的讀者可以更深入瞭解前面幾個章節提到名詞們的原理,因此可以藉由以下資源來完整地探索所有基本知識,也可以選擇跳過直接進到 AA Protocol 的部分:
這個章節的主要目的除了知道每一個角色在每一個步驟會做哪些事情,有哪些限制,還可以多思考這一步為何會這樣設計。
首先是 AA 的大補帖,由於 AA 是好幾年討論下來的成果,因此從這些大補帖可以綜觀許多資源,了解哪些內容是在何時被提出來討論的,最後再與當前的 EIP 進行比較才不會錯亂最新的設計到底是怎麼樣。同時大家也可以透過裡面的提到的內容進行更深入的相關細節探討:
- Awesome Account Abstraction
- Account Abstraction: Past, Present, Future 🉑
- Account Abstraction Link Tree 🉑
- The History and Future of Account Abstraction 🉑
關於 EIP-4337 最經典的莫過於 Vitalik 的文章、討論以及提案本身,是屬於一定要閱讀的內容:
- ERC-4337: Account Abstraction Using Alt Mempool
- ERC 4337: account abstraction without Ethereum protocol changes
- Implementing account abstraction as part of eth1.x 🉑
- The road to account abstraction 🉑
如果你已經了解了 4337 的設計,想要實際碰看看 AA 的開發可以參考以下資源:
- Awesome Account Abstraction — Code
- eth-infinitism/account-abstraction
- SDK — Stackup Docs
- SDK — ZeroDev Overview
- Discussion — ERC 4337: Account Abstraction via Entry Point Contract specification 🉑
另外由於社群也有討論其他實作 AA 的方向(其他提案),因此大家也可以嘗試(但不必要)閱讀以下內容:
- Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337
- EIP-3074: AUTH and AUTHCALL opcodes 🉑
- EIP-2938: Account Abstraction 🉑
或者可以直接閱讀我撰寫的兩篇有關於 AA 的 EIP 介紹文章,裡面有附上所有我參考過的資源,我覺得對自己的幫助很大:
Layer2 的原生 AA 設計
目前最有名的原生 Layer2 AA 就是 StarkNet 以及 zkSync,基本上他們都是追隨 EIP-4337 的設計來放進他們的 protocol 中,主要的差別在於原本 bundler 以及 EntryPoint Contract 要做的事情變成 Sequencer 來做。
原本 Bundler 送 bundle transaction 給 Entry Point 之後會去觸發 Wallet Contract 上的 validate function、收取手續費、execute function,而在 L2 的 Native AA 設計中呼叫 Wallet Contract 的人改為 Sequencer,其餘設計和處理交易的流程就沒有相差太多。
StarkNet
- StarkNet Account Abstraction Model — Part 1
- Starknet Account Abstraction Model — Part 2
- Awesome StarkNet AA Videos List 🉑
zkSync
- Matter Labs — Introducing Account Abstraction, L2 → L1 Messaging, and more.
- Account abstraction support
- zkSync2.0 x Account Abstraction 🉑
- Account abstraction multisig 🉑
Layer2 AA Discussions
- Julien Niset Why account abstraction on L2 is critical for mass adoption 🉑
- EIP-3074 and the role of the EVM in a L2 world — Ansgar Dietrichs aka @adietrichs at @ETHDubaiConf 🉑
- Demystifying Account Abstraction on Zk Rollups & Ethereum: Tech guy PoV 🉑
- Talking: Account Abstraction on ZK-rollup and Ethereum 🉑
這個部分如果已經了解 4337 的運作,那可能不會遇到太多問題,主要可以思考的問題是:在 Layer2 比在 Ethereum 本身實作 AA 有哪些好處。
AA 的安全與效能探討
最後一個章節其實是放一些我整理了很久但沒時間看的資源與主題,重點會放在 Security(Replay Protection、DoS Prevention)還有 Bottleneck 上,大部分內容我自己也不是很熟悉,大家斟酌使用:
EIP-2938
- Access List with EIP-2930: Account read/write lists
- Replay Protection, Transaction Hash Uniqueness and INDESTRUCTIBLE: EIP-2937: SET_INDESTRUCTIBLE opcode
- Protocol-enshrined Nonce
- DoS Vectors in Account Abstraction (AA) or Validation Generalization, a Case Study in Geth
- Re-validation & Peer denial-of-service
EIP-3074
- EIP-3074 Security Audit Report Ethereum Foundation
- Potential Threat: A case for a simpler alternative to EIP 3074
- Potential Threat: EIP-3074 Threat Models
- Gas Cost & dynamic_gas
dynamic_gas = 0
if addr not in accessed_addresses:
dynamic_gas += 2500 # cold_account_access - warm_storage_read
if value > 0:
dynamic_gas += 6700 # NB: Not 9000, like in `CALL`
if is_empty(addr):
dynamic_gas += 25000
remaining_gas = available_gas - dynamic_gas
all_but_one_64th = remaining_gas - (remaining_gas // 64)
if gas == 0:
subcall_gas = all_but_one_64th
elif all_but_one_64th < gas:
raise # Execution is invalid.
else:
subcall_gas = gas
EIP-4337 Alternative Mempool & DoS
Suffix
- I will give two talks respectively about StarkNet Account Abstraction(4/24 Conference) and EIP-4337 Overview(4/21 Workshop) in ETH Taipei.
- I will publish two articles respectively about StarkNet AA(2023 May) and zkSync AA(2023 Jun) in Medium.