原文标题：《名词解释：Web3账户相关概念大梳理》
原文作者：zhixian.eth
刚刚结束的Devcon上，账户抽象算是是最热的几个话题之一，最近可以经常看到AA/EOA/SCW/4337等缩写和代号在各种talk、panel和信息流里出现。再加上叙事开始往「Onboardingnextbillionusers」的方向发展，一些新的形容词也开始出现在产品之前，比如seedless/gasless/socialrecovery/non-custodial。相信看完这两句的你已经开始脑壳疼了，那么接下来就让我尽自己所能来帮大家梳理一下这些名词概念到底代表什么。
阅前提示：本文不是严肃的技术文档，可能会用不精确但容易理解的语言进行阐述或比喻，欢迎大家以此为起点深入探索这些技术的细节。
EOA?-ExternallyOwnedAccounts
EOA中文叫做外部账户，我们最熟悉的MetaMask生成的地址就是EOA。它的特点是原理简单，比如生成规则是：
私钥-公钥-Keccak256哈希-最后20Bytes-十六进制字符串
可以看出这个规则非常直接，全是由数学变换计算出来的，生成的地址内部没有任何结构和逻辑。节点验证一笔交易是否被地址owner授权的时候也是固定的规则：
交易签名-ec_recover-公钥-地址-对比要操作的地址
对比结果一致那么验签通过，进行后续流程；不通过则直接打回，不会进一步广播交易。
EOA的另一个设定是作为交易的发起方并支付gas，相对应的CA只能被其他CA或者EOA调用。也就是说，EOA是交易的触发器，一笔交易无论后面有多少合约调用，一开始都必须由一个EOA发起并且支付足够的gas才可以进行。
需要指出的是，EOA是以太坊以及其他EVM兼容链才有的概念，严格来说包括BTC在内的主流非EVM链都没有这个设定。
CA?-ContractAccounts
CA中文叫做合约账户，我们常见的ERC-20Token合约、DeFi业务合约等都有一个跟EOA长得很像的地址，这就是CA。
在设定上，CA是以太坊世界的原住民，EOA和ETH是为CA的业务逻辑准备的触发器和燃料；实际使用下来，以太坊上除ETH之外的所有资产都是由CA承载，DeFi等业务逻辑就更是全都由CA来实现。然而CA无法主动进行操作和支付gas的设定也限制了它的能力，早在?2016年就有提案希望能让CA自己支付gas。
简单来说，CA是具备内部逻辑的以太坊账户，里面既可以是业务逻辑，也可以是账户逻辑，而后者就是我们即将提到的「SCW-智能合约钱包」概念。
CA的地址规则是通过计算生成的，有CREATE和CREATE2两种方式，这里不再展开。大家只需要记住CA和公钥没有必然对应关系即可，比如gnosissafe创建的CA里可以设定任意多把公钥来解锁它的地址对应的资产；当然CA也可以不设定任何密钥，而是由其他CA的逻辑决定是否可以解锁，比如DeFi的借贷合约，只要还了钱就能取回质押的资产。
SCW/A?-SmartContractWallet/Account
智能合约钱包?应该是字面意思最好理解的了，也就是用CA作为地址的钱包方案，而我们常用的EOA钱包方案是用前述的公钥变换结果作为地址。由于具备内部逻辑，智能合约钱包可以实现很多EOA无法实现的功能，比如gas代付，批量交易，权限管理，离线授权，社交恢复等等。
这里举几个例子来展示一下智能合约钱包的扩展潜力：
1.Gnosissafe利用智能合约钱包架构实现多签逻辑；
2.用户可以在一笔上链交易中同时给多个地址发送不同的token，也可以在用uniswap时让approve和swap在一笔交易里完成，从而做到需要多少授权多少，避免因为过度授权造成安全隐患。
3.用户可以给不同资产设定不同的操作权限，比如给PFP设定比普通ERC-20token更高的操作门槛，这样即便日常使用的环境发生密钥泄露，黑客也无法将高价值资产转走，在安全和便利中间取得平衡。
4.用户可以签署一个离线授权「谁能给我100ETH，就可以转走我的某个BAYC」，这样不需要授权给第三方合约，用户就可以跟其他人P2P地完成原子交易。
AA?-AccountAbstraction
账户抽象其实不是一个新概念了，最早可以追溯到2015年的一些讨论，当时Vitalik认为至少要让以太坊用来验证交易的密码学算法做到可替换，比如换成性能更优的ed25519，可以说7年来Vitalik和EF都没有停止对账户抽象方案的讨论和探索，这里有个整理好的?linktree?可以帮大家回顾一下历史。
那么账户抽象怎么理解呢？这里我引用一下?ERC-4337?里对其目标的描述：
Achievethekeygoalofaccountabstraction:allowuserstousesmartcontractwalletscontainingarbitraryverificationlogicinsteadofEOAsastheirprimaryaccount.CompletelyremoveanyneedatallforuserstoalsohaveEOAs(asstatusquoSCwalletsand?EIP-3074?bothrequire)
可以看出以太坊对于账户抽象的期望是改变目前大多数人都在使用EOA的现状，希望用户转向SCW，并且把生态对EOA的依赖完全去除。除了里面提到的EIP-3074之外，还有一个更为激进和远期的?EIP-5003，这里同样引述几段原文：
EOAs…arelimitedbytheprotocolinavarietyofcriticalways.Theseaccountsdonotsupportrotatingkeysforsecurity,batchingtosavegas,orsponsoredtransactionstoreducetheneedtoholdetheryourself.Therearecountlessotherbenefitsthatcomefromhavingacontractaccountoraccountabstraction,likechoosingone'sownauthenticationalgorithm,settingspendinglimits,enablingsocialrecovery,allowingkeyrotation,arbitrarilyandtransitivelydelegatingcapabilities,andjustaboutanythingelsewecanimagine.
…ThisEIPprovidesapathnottoenshrineEOAs,buttoprovideamigrationpathoffofthem,onceandforall.
不难看出，EIP-5003的目标是一次性将EOA转换为CA，让所有用户用上SCW，彻底解决向前兼容的问题。
到这里大家对AA的来龙去脉和未来目标应该有所了解了。但需要指出的是，AA这个概念不是以太坊和EVM专属的，很多链原生已经具备了不同程度的AA特性。比如EOS/Polkadot/Near/Solona/Flow/Aptos…甚至BTC，这些链在设计时就已经将账户做成了有内部结构甚至具备权限管理能力的状态，还有StarkNet/CKB等具备更完善的账户抽象能力。说到这里大家不难发现，以太坊的AA是在解决EOA意外地流行带来的历史遗留问题，从而在账户层面上变得更加先进和灵活。
4337?-?ERC4337
从上面对AA的讨论里不难看出，ERC-4337只是这个方向众多提案中的一个，但是为什么大家一提到AA或者SCW就会说到它呢？我们来看这个文档的副标题：
Anaccountabstractionproposalwhichcompletely?avoidsconsensus-layerprotocolchanges,insteadrelyingonhigher-layerinfrastructure.
也就是说，ERC-4337是AA的路线第一次从「暴力革命」转向「和平演变」，不再追求利用共识层的改变实现AA，而是转而使用SCW这种用户层的方案。并且为了实现更好的互操作性，ERC-4337定义了一些SCW应该实现的接口，以及元交易打包、gas代付等基础设施的框架。它的出现让目前差异极大的各种SCW方案能够拥有统一的用户交互界面以及共用一些生态层面搭建的开放基础设施，有助于各种场景快速实现自己需要的SCW方案。另一方面，ERC-4337的推动有助于促进生态其他参与方提升对SCW的兼容性，比如验签需要的?EIP-1271?和有些DeFi协议里定义的禁止CA交互的一些规则。
Seedless
这里的seed指的是seedphrase，就是我们创建钱包的时候经常被要求备份的助记词。那么seedless的意思就是「无助记词的」，或者也可以说成「无私钥的」。注意这个「无」并不是实际意义上的没有密钥，而是指不需要用户备份助记词/私钥或者感知到它们的存在。
一个常见的问题是，如果用户不备份助记词，用户是不是就没有账户的控制权了？一旦用户切换新设备环境，账户不就无法访问了吗？没错，只是把用户备份助记词的功能砍掉的话只能算是产品设计失误，而seedless追求的是用户「不需要」知道助记词的存在，同时依然拥有账户的完全控制权。也就是说，用户拥有在新设备自主恢复账户控制的能力，只是不再依赖助记词这种UX很差、过于geek的方式，比如下面要讲到的社交恢复就是非常好的一种。
Gasless
这里的gas指的是gasfee，所以gasless的意思是「免gasfee的」。同样的，gasless也不是真的不需要支付gasfee，而是指用户不需要被迫去了解gas概念，更不用提前购买各种原生Token来支付gas。
那么gas谁来付？分两种情况：
一种是用户账户里已经有cryptoasset的时候，比如playtoearn得到token，或者领到的空投，亦或是别人的转账，只要这些token有一定的价值和流动性，就会有relayer愿意接受它们并帮用户支付gas，以此赚取收益。
另一种是用户账户里没有有价token，比如刚刚创建的账户。如果此时需要链上交互，应用方可以选择资助用户一些「定向」用途的gas来帮他们bootstrap，从而降低用户流失，这时即便算上gas补贴的消耗，整体的用户获取成本反而可能会更低；或者可以通过让用户观看广告等方式来换取一些gas。这两种策略在gas成本较低的L2上都非常有效。
SocialRecovery
社交恢复是指利用社交关系帮助用户在丢失密钥的情况下重新获得账户访问权的机制。如果你用微信登录过新设备，应该有过「让你的两个朋友发送xxx给你的账号以登录」的体验——这就是社交恢复想达到的效果，只不过验证方从微信变成了智能合约。
一种常见的误区是把利用社交账号来创建/登录钱包的方案称为社交恢复，这是错把「社交关系」与「社交平台账号」划了等号。老牌智能合约钱包Argent就内置了社交恢复能力，它要求你的guardian提供一个以太坊地址，从而在你需要登陆新设备时提供签名来进行授权，然而这一方案的潜在设定就是：你的guardian一定比你在管理以太坊账户上更专业，否则当你需要他们签名的时候，如果他们自己的账户已经无法访问，你的账户也会连带遭殃。所以一种更加可行的办法是利用email的密码学证明或者电子护照等生活中常见的密码学工具来增强社交恢复方案的实用性。
Non-custodial
非托管可以说是crypto行业最正确、也是被滥用最多的概念之一了，因为很多时候各家都会有自己的定义。这里我也分享一下我们对非托管的定义，主要有两方面：
1.钱包开发商无法擅自操作用户的账户
2.钱包开发商无法阻止用户操作自己的账户
如果你也认同这两点，那么判断一个钱包是托管、半托管还是非托管就可以直接拿这两个规则去检验了：
不满足1-托管；满足1-不满足2-半托管；1、2都满足-非托管。
那么知道了是哪种托管程度有什么用吗，用户可能并不care背后的原理，只要好用就行了呗！没错，其实我也部分认同这种观点，至少在现在的阶段，行业还没有发展到发生用户认知范式转移的程度。其实我认为三种类型的方案分别适用于不同的场景：
1.?托管方案?-适用于交易平台、大机构金服、强合规等场景，比如coinbase提供的一些服务。特点是用户量少，不需要应对高频交互，而且客单价高，能支撑服务商花费大成本来维护一系列高防系统。
2.?半托管方案?-适用于相对高端的个人用户群体。他们明白服务方可以审查自己的交易，并且有能力提前准备备份方案，在服务方主动或被动拒绝服务时可以不影响自己的资产安全。这样日常使用时可以享受安全和便利，极端情况下可以保全资产。注意这种方案对服务商的运维能力要求也非常高，毕竟个人用户量大，日常跟各种应用的交互需求也更高，再就是对数据可用性要求高，毕竟一旦丢失服务端保存的数据有可能导致所有没备份的用户永远无法访问账户。
3.?非托管方案?-适用于面向massadoption的场景。初听上去可能是反直觉的，但是从成本上讲，非托管方案是唯一能够在低客单价的场景里保证足够的安全性和可用性的方案。如果一个面向大规模用户场景的应用方打算选择上面两种方案，就一定要考虑对方能否为自己的用户群提供足够安全可用的服务，否则一旦内部人员作恶、黑客入侵或不可抗力导致服务停摆，自己的所有用户都会受到牵连，自己的业务也可能因此一蹶不振。历史上的无数次案例都在讲述一个故事，安全无小事，为用户负责就是为自己负责。
MPC?-Multi-PartyComputation
多方安全计算跟零知识证明可以并称当下Web3两大「魔法」，一旦跟它们沾边，似乎原来做不到的事情somehow就能做了。实际上有些情况是这样的，尤其是ZKP，可以利用概率换可行性；MPC则是通过分散控制权来达成风控或者灾备能力。
MPC其实是一种范式，包含很多技术方案，在目前Web3的语境下大都指的是tss。
TSS?-ThresholdSignatureScheme
门限签名是一种分布式多方签名协议，包含分布式密钥生成、签名，以及在不改变公钥的情况下更换私钥碎片的re-sharing等算法。
一个m-n的tss指的是一个公钥对应了n个私钥碎片，其中m个碎片的联合签名可以被公钥验签成功。不难发现这个逻辑类似于多签，他们的区别主要在公钥的数量上。
举例来说，2-2的多签是一个门上挂了2把锁，必须用两个钥匙把它们都打开才能开门；2-2的tss是一个门上挂了1把锁，但是钥匙有两片，合起来用才能打开门。这里为了好理解，描述并不严谨，两把钥匙合成一把其实更符合ShamirSecretSharing算法的情况；tss算法下的密钥碎片是不会相遇的，而是它们分别签名之后，通过特定算法可以用对应的公钥验签通过。
那么tss是不是一定是托管或者非托管的？其实没有必然联系，主要看最终的方案如何设计和取舍。非托管方案要求用户拥有独立操作账户的能力，所以用户必须掌握不少于门限数量的密钥碎片，例如2-3的话用户需要掌握2片，而2-2的方案无法达成非托管，最多可以做到半托管；但是如果用户管理最多的私钥碎片，那么势必会提高对用户能力的要求，很难做到massadoption。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。