刚刚完毕的 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 代付，批量买卖，权限管理，离线受权，社交恢复等等。

这里举几个例子来展现一下智能合约钱包的扩展潜力：

1. Gnosis safe 应用智能合约钱包架构完成多签逻辑；

2. 用户能够在一笔上链买卖中同时给多个地址发送不同的 token，也能够在用 uniswap 时让 approve 和 swap 在一笔买卖里完成，从而做到需求几受权几，防止由于过度受权形成平安隐患。

3. 用户能够给不同资产设定不同的操作权限，比方给 PFP 设定比普通 ERC-20 token 更高的操作门槛（例如需求一把由硬件钱包管理的 admin key 才干转移），这样即使日常运用的环境发作密钥泄露，黑客也无法将高价值资产转走，在平安和便利中间获得均衡。

4. 用户能够签署一个离线受权「谁能给我 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. 钱包开发商无法擅自操作用户的账户

2. 钱包开发商无法阻止用户操作本人的账户

假如你也认同这两点，那么判别一个钱包是托管、半托管还是非托管就能够直接拿这两个规则去检验了：

不满足 1 → 托管；满足 1 不满足 2 → 半托管；1、2 都满足 → 非托管。

那么晓得了是哪种托管水平有什么用吗，用户可能并不 care 背后的原理，只需好用就行了呗！没错，其实我也局部认同这种观念，至少在如今的阶段，行业还没有开展到发作用户认知范式转移的水平。其实我以为三品种型的计划分别适用于不同的场景：

1. 托管计划 - 适用于买卖所、大机构金服、强合规等场景，比方 coinbase / fireblocks 提供的一些效劳。特性是用户量少，不需求应对高频交互，而且客单价高，能支撑效劳商破费大本钱来维护一系列高防系统。

2. 半托管计划 - 适用于相对高端的个人用户群体。他们明白效劳方能够检查本人的买卖，并且有才能提早准备备份计划（比方导出私钥），在效劳方主动或被动回绝效劳时能够不影响本人的资产平安。这样日常运用时能够享用平安和便利，极端状况下能够保全资产。留意这种计划对效劳商的运维才能请求也十分高，毕竟个人用户量大，日常跟各种应用的交互需求也更高，再就是对数据可用性请求高，毕竟一旦丧失效劳端保管的数据有可能招致一切没备份的用户永远无法访问账户。

3. 非托管计划 - 适用于面向 mass adoption 的场景。初听上去可能是反直觉的，但是从本钱上讲，非托管计划是独一可以在低客单价的场景里保证足够的平安性和可用性的计划。假如一个面向大范围用户场景的应用方打算选择上面两种计划，就一定要思索对方能否为本人的用户群提供足够平安可用的效劳，否则一旦内部人员作恶、黑客入侵或不可抗力招致效劳停摆，本人的一切用户都会遭到牵连，本人的业务也可能因而一蹶不振。历史上的无数次案例都在讲述一个故事，平安无小事，为用户担任就是为本人担任。

---

• MPC - Multi-Party Computation

多方平安计算 跟 零学问证明（ZKP）能够并称当下 Web3 两大「魔法」，一旦跟它们沾边，似乎原来做不到的事情 somehow 就能做了。实践上有些状况是这样的，特别是 ZKP，能够应用概率换可行性；MPC 则是经过分散控制权来达成风控或者灾备才能。

MPC 其实是一种范式，包含很多技术计划，在目前 Web3 的语境下大都指的是 tss。

---

• TSS - Threshold Signature Scheme

门限签名 是一种散布式多方签名协议，包含散布式密钥生成、签名，以及在不改动公钥的状况下改换私钥碎片的 re-sharing 等算法。

一个 m-n 的 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。