# Account Abstraction

**Published by:** [Bella Research](https://paragraph.com/@bella495/)
**Published on:** 2022-11-21
**URL:** https://paragraph.com/@bella495/account-abstraction

## Content

Last edited time: November 21, 2022 2:25 PM 创建时间: July 31, 2022 10:37 PM 状态: 输出 类型: 专题研究 1 账户抽象是什么？ 现有账户类型 EOA：外部账户，由私钥控制 CA：合约账户，代码控制 现有事务类型： 只有EOA账户通过支付gas的方式调起CA，来执行代码逻辑 交易有效性验证： 持有有效的 ECDSA 签名 有效的 nonce 值 足够的账户余额 如果你发送 1 个 ETH 到由代码合约控制的账户，那就没有人可以再控制这个 ETH了。唯一可以转移这个 ETH 的是合约的执行，即代码本身。 账户抽象 它是一种新的账户类型，简单来说，账户抽象的目标是让智能合约成为顶级账户类型，而非受限于必须由外部账户调用，这样智能合约账户就可以主动发起事务并支付手续费。 账户抽象交易的有效性验证也发生了根本性改变，由原来固定的「签名+nounce+余额」变成了可编程的验证方式，其有效性由 target 字段指定的智能合约验证，通过验证之后，合约可以自行为该交易支付手续费。 核心思路是将“验证所有权”的操作由共识层下放到合约层，即不去检查事务的发送者是否与资产所有人一致，而是检查其是否提供了合法的凭据。 与原有账户类型相比的变化点： 引入了一种新的事物类型：账户抽象事物类型，AA_TX_TYPE。 它的二进制数据 (payload) 会被解析为 RLP([nonce, target, data]) ，而不是现有交易的 RLP([nonce, gas_price, gas_limit, to, value, data, v, r, s]) 新增了两种操作码 NONCE 操作码：添加一个 NONCE 操作码，推送事务的 nonce 字段。 PAYGAS 操作码：添加一个 PAYGAS 操作码，创建一个不可逆的检查点，确保 PAYGAS 之前的状态变更无法被逆转。 新增了两种内存池规则 操作码限制：在验证阶段（即在执行 PAYGAS 操作码之前）部分操作码被视为无效，以防止抽象账户交易的有效性取决于抽象账户合约以外的任何状态 字节码前缀限制：只接受字节码前缀为 AA_PREFIX 的 target 合约，以防止非抽象账户交易与抽象账户交易发生交互，若target指向的合约不是AA合约就放弃这笔交易 2 能解决什么问题？ 我们可以从以下几个方面出发，来看下AA有什么作用。 EOA账户可以实现逻辑和算法后（单租户 AA），能实现哪些功能 CA可以自主调起逻辑的话（单租户 AA），能实现哪些功能 AA功能举例 EOA账户可以实现逻辑和算法后，能实现哪些功能(单租户 AA) 目前EOA账户的任何链上操作都要ETH来付gas费，这对新钱包非常不友好 AA可以将任何其他货币swap成gas货币完成链上操作，也可以让”合约aa账户“为用户付gas费，这样，即使用户没有gas货币甚至钱包没钱也能实现（特定）交互 目前EOA账户完全由私钥控制，安全风险高 当一笔金额属于团队时，EOA账户会将权力和风险高度集中在一个人身上，AA可以通过多签来分散风险 同时，多签钱包还能实现卖账户的需求（游戏场景也许会有需求） 目前EOA账户面临很多安全风险，例如钓鱼网站、钓鱼合约 AA可以对交互合约、交互金额、时间段等进行限制，用户可设置合约黑/白名单、每日最高限额；还可实现社交恢复 目前EOA任何一个交互都需要签名，操作繁琐、贵 AA可以将一批需求打包起来，只有最后状态改变的时候才付钱 还可以在AA中加入Mobile key 和 session key，实现特定时间内特定合约交互时，都无需签名，对游戏友好 目前EOA账户都是自管钱包，用户为钱包负全责 第三方托管钱包，实现第三方帮你管理钱包，对小白友好，同时，用户可随时获得钱包的绝对掌控权 CA可以自主调起逻辑的话，能实现哪些功能(多租户 AA) 对于tornadocash这样的混币器来说，新的干净的收款地址要想交互合约是需要有资金在钱包里的，而打钱这个行为会让新地址和其他地址产生关联，并且大概率这个钱是来自于交易所，就有暴露的可能，目前的解决方案是第三方来帮你付gas unisawp套利者arbitrageurs来说，现在套利需要EOA与CA交互，很可能出现你的交易被别人抢先但是你的请求也上链的情况，这其实是种无用交易，占用区块空间，对你和区块来说都是无益的 如果Uniswap支持了AA交易+外部发起，就可以这样来操作： 用户提前将套利资金打进去，uniswap将验证余额状态和可调用余额的公钥，那么这个uniswap- AA账户就可以花这部分钱；当套利者发现机会时，uniswap- AA可直接发送交易，并且在验证有效性时可以强制验证价格限制逻辑，如果价格已经超出限制，便不会上链 AA的缺点/风险 L1贵，所以现在业内普遍认为只有L2才是aa的土壤 安全风险，代码质量差、代码漏洞 有效性验证变的可编程后，节点的验证过程会更复杂，会给节点增加很多无用的计算负担，且这部分验证计算是免费的，可能面临DOS攻击 target指向的条件如果是正在等待池中的交易的话，就会出现链上交易错误 3 截止目前，AA的发展进度是怎样的？ 钱包项目 Argent X，braavo 注意：argent、gnosis目前（20220806）的主网版本都是智能合约账户 钱包AA属于单租户AA，目前argent等实现的智能合约钱包实际上还是CA账户，能实现金额、时间、黑白名单等功能。 功能上其实已经和钱包AA差不多了，但唯一区别就是还不能实现自启动，所以目前argent需要用户EOA账户付gas费来创建智能合约钱包 AA+session key SN黑客松上的作品——收菜游戏 realms 计划将实现（目前20220811 还未实现） 2022/8/17 tarrence实现在手机生成密钥并存储在secure enclave中，完成多交互签名 transaction cart realms 已实现（在内测版本） 4 发展掣肘有哪些？ ETH上并没有任何关于AA的EIP正式执行落地，目前只有两个zkR是原生支持AA的 今年7月8日，zkSync发布V2版本，添加AA功能 Starknet网络也支持AA target指向的有效性验证条件还需要新的规定 5 session key 和 secure enclave secure enclave on IOS，TEE on Android session key定义 翻译为：对话键/会话密钥 特点：一次性（连线结束即失效）、对称式密钥，所有成员使用同一把钥匙来加解密 疑问 session key是存在缓存里吗？ 不是。Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据可以保存在集群、数据库、文件中；Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。 为了方便前后端对话，session id会存储在缓存中，但是敏感数据是存在服务器的 session key是否安全？ Session是存在服务器上的，理论上是可靠的 但是也有风险，如果客户端缓存中的session id被盗，就会被冒名顶替（劫持了sessionid并不能取得Session数据），所以用户需要保证浏览器的安全性 6 session key在移动端的应用 Secure Enclave定义 Secure Enclave 是 iOS 设备内部的安全执行环境，可以用来进行一些敏感信息的处理。 实现形式 Touch/Face ID 传感器和 Secure Enclave 会预置一个共享密钥，然后利用该共享密钥协商一个会话密钥，再用该会话密钥使用 AES-CCM 算法对传输的数据进行加密，这样可以确保应用处理器无法读取指纹数据，保证了整个指纹识别过程的安全。 session key与web3结合 临时生成的对话密钥可以灵活的在某段时间或某个环境中代替用户签名 但确实存在上述风险，目前有人正在做session key的合约实现 7 接下来关注 session key的合约实现进度 UX友好的游戏已有案例，跟进是否有项目将其应用在产品上 指纹识别/人脸识别已有实现案例，跟进是否有项目将其应用在产品上 更多资料请点此链接

## Publication Information

- [Bella Research](https://paragraph.com/@bella495/): Publication homepage
- [All Posts](https://paragraph.com/@bella495/): More posts from this publication
- [RSS Feed](https://api.paragraph.com/blogs/rss/@bella495): Subscribe to updates
- [Twitter](https://twitter.com/0x30cF): Follow on Twitter