抽象帳戶（Account Abstraction、AA）的討論最近在以太坊社群如火如荼的展開，但由於 AA 涉及的內容包含了合約帳戶（Contract Account）的特性、Native Protocol 的變更（將 Transaction 的執行與驗證從共識層拉到合約層），以及各式各樣的新式帳戶的提案（EIP-2938 EIP-3074, EIP-4337）層出不窮，導致 AA 非常難讓人理解。
本文將以 imToken Labs 近期的研究觀點，從以太坊最原始的帳戶開始，帶到抽象帳戶介紹。最後引至探討 AA 能帶給我們什麼不同的帳戶體驗，和它與我們常見的 Contract Account 有什麼差別，它到底為何重要。
Quick Look the Core Questions
我期盼這次系列文可以讓一個初學者從完全不懂以太坊帳戶，到可以大概知道抽象帳戶的基本概念與設計原由。
我把這篇文章拆解成幾個重點問題，由淺入深依序介紹：
- 什麼是帳戶
- 什麼是抽象帳戶
- 抽象帳戶為何重要：與原生合約帳戶的差別
- 未來帳戶：使用和開發體驗
而本篇文章將會著重在第一點：「什麼是帳戶」。
什麼是帳戶？
為什麼這個章節提到的內容格外重要是因為許多人不懂 AA，或不知道為什麼需要 AA 就是因為對以太坊的原生帳戶不夠熟悉，導致無法理解許多 AA 的優點或想要解決的問題。
如果大家覺得自己已經熟悉以太坊原生帳戶的話，可以跳過本篇直接看下一篇：Account Abstraction 介紹（二）：以太坊未來的帳戶體驗。
以太坊的原生帳戶
以太坊最原生的兩種帳戶為：外部帳戶與合約帳戶。
外部帳戶（Externally Owned Account, EOA） 作為我們外界與區塊鏈互動的切入點，我們持有了一組公私鑰對來控制這個 EOA，而公鑰對應的地址會記錄在鏈上，同時記錄著這組地址的狀態（例如 Balance、Nonce 等）。
合約帳戶（Contract Account, CA） 簡單來說就是存了錢的智能合約，是另外一種儲存我們資產的方式。我們能夠利用智能合約的可編程性和簽章的判斷使（合約）帳戶更為彈性，以及完成眾多的 Features。
例如：合約帳戶能做到多簽錢包可以讓安全性大幅提升，也適合多人協同管理；抑或者是我們可以在合約中加入限制，讓這個錢包只能匯款給某個指定角色，每日匯款上限等。
無論是哪種帳戶都能夠儲存以太幣、收發以太幣，也能夠與智能合約互動。
EOA 與 Contract Account 最大的差別就在於，EOA 能夠作為交易的發起者，而 Contract（不管是不是合約帳戶，只要是合約）都只能是交易的中繼者。
也就是說當我們有一個 Contract Account 想要匯款給另外一個帳戶，就必須要有一個 EOA 作為交易發起者，將這筆交易送到 Contract Account 觸發函式，再進而呼叫目標合約。其中合約去呼叫另外一個合約的行為就稱作 Internal Call。
本圖每列的最左角色為交易發起者，最右角色為收款者。可以發現 EOA 帳戶同時持有資產又可以做為發起者，但 CA 就不能作為發起者，需要一個 EOA 完成發起的動作。
擁有權與簽核權
了解兩種帳戶是什麼之後，我們準備要介紹這兩種帳戶所要面對的問題，但在此之前我覺得有兩個概念非常重要，這將很大程度的影響大家能不能理解合約帳戶，甚至之後的抽象帳戶。
這兩個概念就是所有權和簽核權。
- 有擁有權的人我們稱之為 Owner（擁有者），擁有這個帳戶的人
- 有簽核權的人我們稱之為 Signer（簽核者），能夠決定這個帳戶發出的交易內容、決定資產動向的人
這樣講可能難以理解，先從現實生活中的銀行體系來介紹好了。假設我在銀行開了一個戶頭之後，我便是這個戶頭的擁有者，這應該無庸置疑。同時行員會用鏡頭拍下我們的臉，紀錄我們的印鑑，以及所有個人資訊包含電子信箱、手機號碼、個人收支狀況等。這些都是以便未來判斷我們的身分。
同時我會得到一組戶頭帳號和密碼，持有這些資訊的我也將是這個帳戶的簽核者，只要帶著這組密碼，理論上我就能夠領出這個戶頭的所有錢。
若是今天非常不幸，有一個小偷竊走了我的提款卡及密碼，他也就有了這個帳戶的簽核權對吧，因為他能夠決定這個帳戶的資產走向。那他是否真的能夠領出所有戶頭裡面的錢呢？
答案是不行，因為銀行會發現小偷並不是這個帳戶的擁有者，也許是藉由任何生物辨識或其他方法，反正銀行絕對有辦法知道眼前這位是不是當初來開戶的人。
至此大家可能已經發現鏈下世界與鏈上世界的差別，那就是在區塊鏈（至少以太坊）的世界中，帳戶的所有權和簽核權理論上是同一個個體單位持有。也就是說持有私鑰的人，就是擁有這個帳戶的人，同時他也能用這個帳戶發出任何他想要的交易，任意轉移帳戶的所有資產。
我們沒辦法在鏈上僅透過一個簽章，就判斷出眼前這個送出交易的帳戶背後，到底是不是我們期待的那個人（帳戶的真正擁有者）。因為私鑰終究是一串亂碼，而不是一個活生生的人。
退而求其次，我們只能認簽章，也就是相信私鑰沒有外洩。只要簽章通過驗證：那我們就相信這個簽核者真的是我們期盼的那個人。
接下來我們將會依序講述一些現行帳戶設計的問題，這裡先 Overview 一下：
問題（１）－ 私鑰保存
從上述內容，我們相信了 EOA 的簽核者就是擁有者。但現實真的是這樣嗎？竊走了我們私鑰的駭客就成為帳戶的擁有者、當我們失去私鑰之後就失去了一切。
這樣的設計恐怕平民老百姓是很難接受的，畢竟我們已經習慣了「忘記密碼」這個按鈕。這也是為何區塊鏈難以讓一家老小都迅速上手的其中一個原因：私鑰保存極度重要且危險。
而我們剛剛講的 EOA 簽核權和擁有權的問題，其實能夠在 Contract Account 得到緩解，那就是我們能夠將資產儲存在合約的同時，在合約中紀錄（且未來可以更新）代表著此帳戶的擁有者。
當這個 Contract Account 實作了 Social Recovery 等功能時，即便我們喪失了控制這個合約的擁有者私鑰，也不至於失去整個合約的控制，也不會失去這個合約上的資產。
大家對 Social Recovery 有興趣可閱讀：Social Recovery Wallet 社交恢復錢包
問題（２）－ 原生協議只能使用 ECDSA
以太坊的原生協議中，我們只能使用 ECDSA 這個簽章演算法來驗證用戶用送上來的交易簽章是否正確。
理論上有更安全的簽章演算法，但這也不代表 ECDSA 是不安全的。同時在某些應用場景中它不一定是那麼好用，如果能夠使用其他更有效率的簽章演算法會讓使用者體驗更好、效率更高。
因此我們不會希望所有的交易驗證都被綁在 ECDSA 上。
問題（３）－ EOA 手續費只能透過 Ether 支付
在以太坊上發送交易時使用的手續費必須使用 Ether 支付，這導致一個問題：當我們有一個新的、沒有 ETH 的帳戶想要收到別人贈與的 ERC20 代幣或是 NFT 等等資產時，就無法觸發提款交易。
舉例來說，如果用戶想要使用 Uniswap，帳戶裡面卻只有 DAI 而沒有 Ether 的話，他也是無法 Swap 的。
這個問題我認為有兩個點：
- 使用者體驗：當我們有一個新的帳戶想要跟合約互動時，就必須先將這個帳戶充值（e.g. 從中心化交易所轉 ETH 到這個帳戶地址）這可能會使使用者體驗很差。
- 隱私有風險：無論是用中心化的交易所，還是從持有 ETH 的另一個帳戶，用哪個東西匯款給這個新帳戶，都能夠在鏈上被串起關係。
關於 Relayer 與 Tornado Cash 的內容等下都會提到，屆時會有更多敘述。
問題（５）－ 合約帳戶無法作為交易發起者
有別於 imToken、MetaMask 是做 EOA 的錢包商，像是 Argent 這樣專門做 Contract Account 的錢包商必須依賴 Relayer 來讓用戶送出交易。
Relayer 是一個中心化的服務，它會代替我們發出交易，去執行我們的合約帳戶。此外它也可以解決必須要有 ETH 作為手續費的問題，或甚至隱私問題。
舉 Argent 為例，他有提供一個中心化的 Relayer。當我們使用錢包簽核完交易後就會直接送給 Relayer，Relayer 會以 EOA 的身份作為交易發起者，把我們已簽的交易物件送到 Contract Account。Relayer 會從 Contract Account 身上提走一定數量的 ERC20 代幣做為手續費（因為是 Relayer 支付 ETH 發起交易的）。
Argent Relayer 的一個缺點是它只會等待網路不壅塞、手續費比較低的時候才會送出交易，而且使用者也不能自己更新手續費來加速交易。
問題（６）－ EOA 一筆交易只能包含一個函式呼叫行為
Background：呼叫合約的函式來更改狀態時，必須透過送出交易來與合約互動，每呼叫一次合約函式就需要送出一筆交易。
我們在 ERC-20 Token 的操作上，常常需要先執行 approve 再執行 transferFrom，也就是呼叫兩次 Token Contract 的函式，總共 EOA 就需要兩次（筆）交易才能完成這個轉移 Token 的行為。而 CA 因為可以在合約內構建複雜的執行邏輯，所以可以直接在一筆交易就完成多個操作。
這樣送出多筆交易的成本也會比送出一筆交易執行多個操作的成本來的高，這是因為每一筆交易都會被收一個固定的基本費用。
Summary
相信大家看到這裡已經有一定的概念了，除了 EOA 在某些應用場景沒辦法符合我們的需求；還有合約帳戶能提供更豐富功能的 CA，卻因為種種原因導致使用上不如預期，例如需要仰賴中心化的 Relayer 等等的。
而以上提到的這些，其實都是抽象帳戶想要解決的問題！
所以未來的帳戶我們希望可以一筆交易完成多個操作，同時擁有有選擇其他簽章演算法的彈性。
Special thanks to NIC Lin, Chang-Wu Chen and imToken colleagues for reviewing this post.
