账户抽象（Account Abstraction）

foshouguacai

已于 2024-06-25 06:48:37 修改

阅读量2k

点赞数 51

文章标签：区块链

于 2024-06-24 21:56:50 首次发布

本文链接：https://blog.csdn.net/foshouguacai/article/details/139939710

版权

前言

在传统的以太坊生态系统中，有两种类型的账户：外部拥有账户（EOA）和合约账户（CA）。EOA 是用户直接控制的，通常与私钥相关联，而合约账户则由代码控制。账户抽象的目标是将这两种账户类型融合，使任何账户都可以由代码控制，从而增加操作的灵活性以及更多可能得扩展。

EIP-4337提案到ERC-4337协议是以太坊账户抽象从提议到落地的关键，该提案避免了修改以太坊的共识层。以太坊基金会在 3 月 1 日的 WalletCon 活动上宣布称，以太坊智能合约 ERC-4337 已经部署、测试，将正式开启智能账户的新时代。

传统账户

比较容易理解的且我们常见的账户就是EOA账户，区别于智能合约账户，该账户可以直接发送和接受以太币，同时它也可以作为触发其他合约的发起者。

传统账户有以下几个问题：

需要用户记录私钥，如果忘记了私钥对应账户的以太币就没了
签署交易算法采用的是固定以太坊签名算法，无法定制。且以太坊签名算法（ECSDA）目前是非抗量子的，之后可能需要做升级。
只能作为交易的发起者，无法做其他事情。例如：支持多签、私钥可找回等等。

智能合约钱包

智能合约钱包使用智能合约来管理用户的资产。试想该场景，开发者开发了一个智能合约，而这个智能合约的作用就是用来管理你的资产。

我们知道智能合约有可编程的特点，那么通过智能合约就可以将你的资产使用衍生出很多不同于EOA账户的功能。

例如：我每次花费资产的时候，总会给我发个短信通知下具体金额；设置一个定投的逻辑，在指定价格的时候就使用我的智能合约账户调用某个dex定投某个币种；也可以在合约中开发一个接口，只有多个人签名才时才能花费我的智能合约钱包中的某些资产；

可以发现因为开发者可以自定义智能合约的逻辑，所以智能合约钱包多了很多操作的想象空间。这些想象空间通过开发者实现智能合约具体逻辑代码来实现。

这里看智能合约钱包好像已经满足了所有用户的功能，想要的逻辑功能通过代码实现就可以。那为什么还要搞一个抽象账户出来？

我的理解是：抽象账户其实就是特殊的智能合约钱包，但是之前智能合约钱包的实现有很多定制性、随意性，每个开发者都可以实现自己想要的逻辑，接口名称也随便叫。并不利于web3 app的接入、智能合约之间的相互调用。那么以太坊官方就自己搞出来一套标准，不仅在应用层面实现了抽象账户的功能并设置标准，同时也避免了共识层的修改。

抽象账户

抽象账户是一套标准（ ERC-4337），其定义了一系列的接口和需要实现的功能组件，这些接口及功能组件可以理解为“智能合约钱包”中需要开发者实现的一些自定义逻辑。

下面通过用户使用角度陈述下抽象账户的具体实现：

用户发起交易时会产生一个UserOperations（UO），UO不会立即被处理，而是放入一个mem pool当中。另一个组件bundler会对这些UO进行打包上链。而UO中需要的gas fee是通过另一个组件payMaster来提供。签名与UO具体要触发的逻辑操作、签名的校验是通过另一个Entey Point的合约处理。对于逻辑操作Entey Point只触发但并不具体执行，具体执行UO逻辑的是另一个合约，被称为wallet contract（可以理解为可自定义逻辑的智能合约钱包）。除此之外类似于开户，如果你之前没有账户就会给你重新创建一个账户，抽象账号这里也类似，如果用户没有对应的wallet contract，那么还有一个wallet contract factory来为用户创建，普通账户是创建公私钥，抽象账户就是为用户创建一个对应的智能合约。

大致如下图：

ERC-4337的交易逻辑：

这里一点一点去捋可能不太容易理解，这些复杂的交互会绕的人脑壳发晕。

可以通过下面这个方法简单去理解，计算机科学中有一个耳熟能详的名言“没有什么问题是不能通过加一个中间层去实现的”。这里ERC-4337的设计思想也是一样的，如果哪个具体逻辑需要用户自定义，那么我就加一个中间层，抽象账户将这个中间层具体的协议定好就可以了，而中间层后面具体逻辑的实现则交给开发者。

抽象账户的中间层处理如下表所示：

需定制的逻辑	中间层	具体实现
签名的逻辑应该是可定制的	加一个签名、校验的中间层	Entry Point contract
gas fee的付给应该是可定制的	加一个付gas fee的中间层	Pay Master
不仅要支持转账还要有智能合约的功能	加一个智能合约执行的中间层	Entry Point contract + Wallet contract
避免使用私钥直接交互	加一个专门处理交易打包的中间层	Bundler

为什么要加这些中间层呢？前面说了，一个是为了规范这些接口的标准。另一个是通过添加这些标准将逻辑的实现权力交给用户，因为这里的逻辑实现是可自定义的，那可想象的空间就变非常大。例如：gas fee的支付可以自定义逻辑，那么就不仅可以通过eth支付gas，也可以通过usdt支付，甚至可以通过信用卡/银行卡支付。再比如：签名与校验的逻辑可以自定义，那么就可以支持任意可能的签名方式，只要签名代码与校验代码实现了对应逻辑就可以（这里再扩展下就可以使用户不需要私钥也可以进行交易，因为权限的校验是可定制的）。当然还有一些其他的智能合约钱包可实现的场景，它也是可以实现的。

一些其他的场景：