信息来源自substack，略有修改，作者cami

你很可能已经阅读了一些用于理解帐户抽象的文章，并同意99%关于帐户抽象的帖子都是垃圾。

你发现几乎所有的人都从描述EOA和智能合约之间的区别开始，并含糊地提到了用户体验的改进。他们未能解释账户抽象实际上是什么，而是专注于账户抽象的副产品。

本指南涵盖了整个思路，从账户抽象是什么，到为什么每个人都称它为下一个大事件。

什么是帐户抽象？

我发现从帐户抽象不是什么开始解释比较容易：

-支付用户gas费

-原生多签名

– web3auth类型的“社交登录”

作为帐户抽象实现的结果，你可以执行这些操作。

如果我可以把账户抽象重新命名得更直观一些，那么它将被称为“可编程交易有效性”。

一般来说，帐户抽象是一种以编程方式设置交易有效性条件的能力。

由Vitalik等人撰写的EIP-4337表示：“实现帐户抽象的关键目标是，允许用户使用包含任意验证逻辑的智能合约钱包，而不是EOA作为他们的主要账户。”

目前，在以太坊上，当且仅当满足以下条件时，交易才有效：

1.有足够的余额支付gas。

2. nonce是正确的。

3.它具有有效的数字签名。

但是，如果开发人员可以定义一组不同的交易有效条件呢？

你不能自动执行交易

无状态和有状态的帐户抽象

在我们继续之前，有必要注意存在两种类型的帐户抽象：无状态和有状态。

无状态=不依赖于外部状态，没有副作用。

有状态=可以依赖于外部状态，可以访问链的状态。

在有状态的账户抽象实现中，定义有效性条件的智能合约可以访问链的状态。这样做的问题是，一个条件在一个实例中是真的，在另一个实例中可能不是真的。实际上，这看起来就像一个节点发送了一个当前有效但之后就会失效的交易。例如，假设你想在区块1000000处自动执行一笔交易。在区块1000000处，你可以向mempool提交一个在当时有效的用户操作。当bundler试图将它放入下一个区块时，它可能会因为区块编号增加而无效。

接收节点不得不花费资源来验证一些永远不会出现在链上的东西，而且不能把发送交易的东西列入黑名单，因为它在发送的时候是有效的。

在ERC4337中，研究人员花了很多时间来研究如何避免这种情况。为此，该规范禁止使用特定的操作码，如’ blockNumber ‘。

通过无状态帐户抽象，你永远不会冒更改有效性的风险——它是单调的。

Fuel的无状态AA的实现

我们稍后将讨论其他生态系统如何实现帐户抽象。从Fuel开始，你将看到与为现有系统构建相比，从头开始构建新系统与模块化论述之间的对比。

Fuel使用谓词实现了无状态AA。谓词只是一个可以使用UTXO的条件，是主函数返回布尔值的脚本。是该谓词下的资产被解锁，如果求值为true，则可以由调用者使用的纯函数。谓词拥有或控制UTXO。

注意：UTXO代表未花费的交易输出。对UTXO的核心基本理解是，对于每笔交易，都会花费全部余额或代币数量。你发送给你的目标收件人的金额会转给他们，其余的会被销毁，然后再次铸造，从而产生新的未花费输出。

关于Fuel谓词的关键在于，你可以内省或检查谓词的输入和输出，这允许你达成协议，从而允许你建立订单簿交易或在多方之间进行原子交换。

在交易层面，UTXO交易描述了交易的确切效果的子集。这部分效果可以在无状态帐户抽象中被设定为条件。Fuel通过UTXO模型的设计决策实现了这一点。这使得系统能够了解交易的输入和输出。在以太坊上，你只知道输入的情况。有了Fuel，你可以用输出来编写逻辑，说明如果你提供X则Y。

你可以将代币锁定在具有可编程有效性的谓词中，该谓词表示：“如果将X数量的Y资产发送到某个特定地址，则这些代币是可消费的。类似地，你可以有一些逻辑，说这个交易只有在X以一定的价格交换时才有效。这里的问题不在于你在“发送”什么。它已经被发送了。你看到的是交易的最终效果，在这种情况下，代币已经被发送。

谓词有效性

在作用域执行期间不会检查谓词。他们会在交易有效性时间被检查。谓词可以检查交易的输入是否具有特定的属性，但它并不关心这些输入是否是有效的。要使交易有效，它们必须是有效的输入，但执行这种有效性的不是谓词。

现在，作为衡量它们的一种方式，Fuel谓词受到字节数的限制。在未来，该团队将使用gas来约束谓词。这使得通常需要循环的自定义哈希和签名验证等密码学成为可能。

Fuel实施的好处

注意：如果你想继续了解AA可以做什么，请跳过本节

UTXO自省

在比特币和以太坊以及使用类似实现的协议上，你不能自省交易。这意味着你不能自省交易的支出，也不能基于输出以编程方式设置要执行的操作。

在其核心，Fuel的AA实现为开发人员和用户提供了更多的灵活性，因为这些不是在协议级别上编码的东西。Fuel的帐户抽象允许开发人员在应用层面定义自定义验证方案。

Fuel Labs团队有一个以太坊私钥的EC恢复示例。如果你想要针对不同曲线的EC Recover，开发人员可以在应用层编写一个！

EC RECOVER：当向以太坊网络发送交易时，你必须使用你的私钥签署此交易。EC Recover正将验证签名的功能转移到智能合约中，而不是只有以太坊节点才能做到这一点。有了它，你可以验证更多的东西，而不仅仅是交易签名本身。

无状态膨胀

无状态帐户抽象不会使状态膨胀(那么多)，因为即使它被花费了，它也永远不会进入区块链状态，只会进入历史记录。

对于谓词，没有合约、状态或存储。谓词最初没有状态，如果有人代表谓词消费，则只能获得一个数据库条目，仅用于UTXO而不是状态树。

其他生态系统是如何进行帐户抽象的

像计算机科学中的大多数事情一样，帐户抽象可以以无数种方式实现。没有一种实现是整个行业的标准。

以太坊

EIP-2938是一个初始EIP，允许合约成为支付费用和启动交易执行的最高级别账户。其实施围绕着引入一个新的EVM操作码来发出有效性信号，以通过执行任意EVM字节码来扩展交易条件。该提案没有纳入协议，因为开发人员正忙于合并等其他变更，不能冒险进行如此大规模的协议变更。

ERC-4337是第一个不需要改变核心协议就能实现以太坊账户抽象的账户抽象提议/标准。它通过将交易验证移出协议本身，并将其移到更高的级别—具有特殊“入口点”的智能合约级别来实现这一点。

在以太坊上，EOA是以太坊上的帐户，其功能被硬编码到协议中。它定义了他们如何支付gas，如何签署交易，如何使用nonce等等。这个标准摆脱了EOA给我们带来的账户硬编码性质。

Starknet

Starknet是以太坊上的zk-rollup。Starkware为以太坊实现了EIP-4337模型的修改版本。

zkSync

zkSync是以太坊上的zk-rollup。zkSync实现了EIP-4337的修改版本。

Biconomy AA

Biconomy是一个开发人员工具平台，专注于以太坊生态系统的基础设施和工具。Biconomy实现了EIP-4337的修改版本，并提供了一些功能，比如作为SDK的一部分为用户支付gas费。

模块化设计

模块化的理念不是设计一个与另一个系统紧密耦合的系统，以允许更大的灵活性。Fuel对账户抽象的实现就是这种精神的一种体现。Fuel的帐户抽象实现提供了更高的灵活性和高度可定制的环境，开发人员可以在应用层面上定义有效性条件，而不需要依赖Fuel协议的支持。

因为Fuel不是专门为以太坊或任何其他系统构建的，所以Fuel的实现不受其他系统的拖累，有创新的空间。

zkSync、Starkware和Biconomy都实现了EIP-4337的修改版本，而Fuel实现了更独特和高性能的帐户抽象。由于Fuel将作为一个rollup部署在以太坊上，因此从某些方面来说，以太坊已经有了账户抽象。

你可以用帐户抽象做什么

你所看到的正在构建的新体验是通过帐户抽象而不是帐户抽象本身实现的功能。像为用户提供gas费赞助和Web3Auth之类的东西都是建立在帐户抽象之上的应用层事物。通过帐户抽象的核心机制：以编程方式设置tx的有效性条件的能力，这些事情本质上是可以实现的。

建立在帐户抽象之上的例子：

利用了Fuel账户抽象的项目：

用户体验改进

解锁新应用

事实是我们还不完全知道哪些新类型的应用程序可以被解锁(目前)，但我们可以开始对现有应用程序的用户体验进行大规模改进，这是一个很好的开始。

几年前，区块链的用户体验问题是，世界上大多数人在财务上完全无法接触到它们。随着第2层的不断发展和扩散，我们到达了一个新的领域：用户体验。

突然之间，我们可以将费用降低到足够低，使区块链可用，但应用程序的UX需要更加令人愉快和强大。在下一个周期中，我预计更多的团队将专注于支持帐户抽象的UX改进和流程。这将是为web3的托管属性带来类似web2的体验所需的另一个工具。