作者：Alfred Lu，imToken Labs 实习生
本文受众：区块链初学者
抽象账户（Account Abstraction，简称 AA，也叫做账户抽象）的讨论最近在以太坊社群如火如荼地展开，但由于 AA 涉及的内容包含了合约账户（Contract Account）的特性、Native Protocol 的变更（将 Transaction 的执行与验证从共识层拉到合约层），以及各式各样的新式账户的提案（EIP-2938，EIP-3074，EIP-4337）层出不穷，导致 AA 非常难让人理解。
本文将以 imToken Labs 近期的研究观点，从以太坊最原始的账户开始，带到抽象账户介绍。最后引至探讨 AA 能带给我们什么不同的账户体验，和它与我们常见的 Contract Account 有什么差别，它到底为何重要。
目录
我期盼这次系列文章可以帮助一个初学者从完全不懂以太坊账户，到可以大概知道抽象账户的基本概念与设计缘由。
我把这篇文章拆解成几个重点问题，由浅入深依序介绍：
- 什么是账户
- 什么是抽象账户
- 抽象账户为何重要：与原生合约账户的差别
- 未来账户：使用和开发体验
而本篇文章将会着重在第一点：「什么是账户」。
什么是账户？
为什么这个章节提到的内容格外重要是因为许多人不懂 AA，或不知道为什么需要 AA。就是因为对以太坊的原生账户不够熟悉，导致无法理解许多 AA 的优点或想要解决的问题。
如果大家觉得自己已经熟悉以太坊原生账户的话，可以跳过本篇直接看下一篇。
以太坊的原生账户
以太坊最原生的两种账户为：外部账户与合约账户。
外部账户（Externally Owned Account，EOA）作为外界与区块链互动的切入点，我们持有一组公私钥对来控制这个 EOA，而公钥对应的地址会记录在链上，同时记录着这组地址的状态（例如 Balance、Nonce 等）。
合约账户（Contract Account，CA） 简单来说就是存了钱的智能合约，是另外一种储存我们资产的方式。我们能够利用智能合约的可编程性和签名的判断使（合约）账户更为灵活，以及实现众多特性。
例如：合约账户能做到多签钱包，可以让安全性大幅提升，也适合多人协同管理；抑或者是我们可以在合约中加入限制，让这个钱包只能汇款给某个指定角色，设置每日汇款上限等。
无论是哪种账户都能够储存以太币、收发以太币，也能够与智能合约互动。
EOA 与 Contract Account 最大的差别就在于，EOA 能够作为交易的发起者，而 Contract（不管是不是合约账户，只要是合约）都只能是交易的中继者。
也就是说当我们有一个 Contract Account 想要汇款给另外一个账户，就必须要有一个 EOA 作为交易发起者，将这笔交易送到 Contract Account 触发函数，再进而呼叫目标合约。其中合约去呼叫另外一个合约的行为就称作 Internal Call。
本图每列的最左角色为交易发起者，最右角色为收款者。可以发现 EOA 账户同时持有资产又可以做为发起者，但 CA 就不能作为发起者，需要一个 EOA 完成发起的动作。
所有权与签名权
了解两种账户是什么之后，我们准备要介绍这两种账户所要面对的问题，但在此之前我觉得有两个概念非常重要，这将很大程度的影响大家能不能理解合约账户，甚至之后的抽象账户。
这两个概念就是所有权和签名权。
- 有所有权的人我们称之为 Owner（所有者），拥有这个账户的人
- 有签名权的人我们称之为 Signer（签名者），能够决定这个账户发出的交易内容、决定资产动向的人
这样讲可能难以理解，先从现实生活中的银行体系来介绍好了。假设我在银行开了一个户头之后，我便是这个户头的所有者，这应该无庸置疑。同时柜员会用镜头拍下我们的脸，记录我们的印鉴，以及所有个人资讯包含电子信箱、手机号码、个人收支状况等。这些都是以便未来判断我们的身份。
同时我会得到一组户头帐号和密码，持有这些资讯的我也将是这个账户的签名者，只要带着这组密码，理论上我就能够领出这个户头的所有钱。
若是今天非常不幸，有一个小偷窃走了我的提款卡及密码，他也就有了这个账户的签名权对吧，因为他能够决定这个账户的资产走向。那他是否真的能够领出所有户头里面的钱呢？
答案是不行，因为银行会发现小偷并不是这个账户的所有者，也许是借由任何生物辨识或其他方法，反正银行绝对有办法知道眼前这位是不是当初来开户的人。
至此大家可能已经发现链下世界与链上世界的差别，那就是在区块链（至少以太坊）的世界中，账户的所有权和签名权理论上是同一个个体单位持有。也就是说持有私钥的人，就是拥有这个账户的人，同时他也能用这个账户发出任何他想要的交易，任意转移账户的所有资产。
我们没办法在链上仅通过一个签名，就判断出眼前这个送出交易的账户背后，到底是不是我们期待的那个人（账户的真正所有者）。因为私钥终究是一串乱码，而不是一个活生生的人。
退而求其次，我们只能认签名，也就是相信私钥没有外泄。只要签名通过验证：那我们就相信这个签名者真的是我们期盼的那个人。
接下来我们将会依序讲述一些现行账户设计的问题，这里先综述一下：
问题（１）－ 私钥保存
从上述内容，我们知道了 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 的话，他也是无法兑换的。
这个问题我认为有两个点：
- 使用者体验：当我们有一个新的账户想要跟合约互动时，就必须先将这个账户充值（如：从中心化交易所转 ETH 到这个账户地址）这可能会使使用者体验很差。
- 隐私有风险：无论是用中心化的交易所，还是从持有 ETH 的另一个账户，用哪个东西汇款给这个新账户，都能够在链上被串起关系。
问题（５）－ 合约账户无法作为交易发起者
有别于 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 一笔交易只能包含一个函数呼叫行为
背景信息：呼叫合约的函数来更改状态时，必须通过送出交易来与合约互动，每呼叫一次合约函数就需要送出一笔交易。
我们在 ERC20 Token 的操作上，常常需要先执行 approve 再执行 transferFrom，也就是呼叫两次 Token Contract 的函数，总共 EOA 就需要两次（笔）交易才能完成这个转移 Token 的行为。而 Contract Account 因为可以在合约内构建复杂的执行逻辑，所以可以直接在一笔交易就完成多个操作。
这样送出多笔交易的成本也会比送出一笔交易执行多个操作的成本来的高，这是因为每一笔交易都会被收一个固定的基本费用。
总结
相信大家看到这里已经有一定的概念了，除了 EOA 在某些应用场景没办法符合我们的需求；还有虽然合约账户能提供更丰富的功能，却因为种种原因导致使用上不如预期，例如需要依赖中心化的 Relayer 等等。
而以上提到的这些，其实都是抽象账户想要解决的问题！
所以未来的账户我们希望可以一笔交易完成多个操作，同时拥有有选择其他签名算法的弹性。
特别感谢 NIC Lin, Chang-Wu Chen和 imToken 同事们校对本文并提供改进建议。