如果你正在阅读本文，你很可能已经阅读了一些便于理解帐户抽象的文章。你可能会同意 99% 关于帐户抽象的帖子都非常烂。
你发现几乎所有的人都从描述EOA和智能合约之间的区别开始，并含糊得提及用户体验的改进。他们未能解释账户抽象本质上是什么，而是专注于账户抽象的副产品。
本指南涵盖了账户抽象思想的每一步，从账户抽象是什么，到为什么每个人都称它为下一个大事件。
什么是账户抽象？
我发现从帐户抽象不是什么开始更容易，账户抽象不是：
- 支付用户的Gas费
- 原生多签签名
- web3auth类型的“社交登录”
如果我将帐户抽象重新命名会更直观，它会被称为“可编程的交易有效性(programmable transaction validity)“。
通俗来说，账户抽象是可以以编程方式设定交易的有效性条件。
我们稍后将更深入地介绍由 Vitalik 等人撰写的EIP-4337(https://eips.ethereum.org/EIPS/eip-4337) ，它提到，“实现账户抽象的关键目标：允许用户使用包含任意验证逻辑的智能合约钱包，而不是EOA，作为他们的主要账户。”
目前，在以太坊上，当且仅当满足以下条件时，交易才有效：
1. 有足够的余额支付gas。
2. nonce是正确的。
3. 具有有效的数字签名。
但是，如果开发人员可以定义一组不同的交易有效性条件呢？
当我在做研究时和James(@_prestwich)聊过，回过头来看，他将帐户抽象的问题表述为，“如果你可以通过密钥以外的任何方式进行身份验证怎么办？你可以做些哪些很酷的事情？”
无法自动执行交易
无状态(stateless) vs 有状态(Stateful)的帐户抽象
在我们继续之前，重要的是要知道存在两种类型的帐户抽象：无状态的和有状态的。
许多人将账户抽象描述为“一旦满足某些条件就自动执行交易”的方案。如果你正在实现无状态的帐户抽象，那么只有上述表述中的一些子集情况是可能的！
- Stateless = 不依赖于外部状态，没有副作用。
- Stateful = 可以依赖于外部状态，可以访问链的状态。
接收的节点必须花费资源来验证永远不会上链的东西，并且不能将交易发送方列入黑名单，因为它在发送时是有效的。
我们稍后会详细介绍ERC4337，其中研究人员花了很多时间来弄清楚如何避免这种情况。出于上述的原因，规范中禁止使用特定的操作码，如“blockNumber”。
使用无状态帐户抽象，您永远不会有更改有效性条件的风险——它是单调的。
Fuel：无状态的账户抽象
我们稍后会讨论其他生态系统如何实现帐户抽象。从 Fuel 开始，你将看到如何从头开始构建一个新系统和模块化理论，以及为现有系统构建之间的对比。
Fuel 使用谓词(Predicate)实现无状态的账户抽象。谓词是你可以花费UTXO的条件。其是主函数返回布尔值的脚本。函数逻辑控制如果求值为真，则该谓词下的资产被解锁，可以由调用者使用。谓词拥有或控制 UTXO。
注：UTXO 代表未花费的交易输出。对 UTXO 核心的基本理解是，对于每笔交易，都会花费全部余额，或者说代币数量。你发送给目标收款人的金额会全部转给他们，其余的会被销毁，然后再次铸造，从而产生新的未花费输出。Fuel 谓词的关键是你可以内省或检查谓词的输入和输出，这将允许你构建订单簿Dex，或在多方之间进行原子化的Swap。
在交易层面，UTXO 交易描述了交易影响的一个子集。这部分效果可以在无状态帐户抽象中进行调节。Fuel 通过 UTXO 模型的设计实现了这一点。这使系统能够了解交易的输入和输出。在以太坊上，你只知道输入。使用 Fuel，你可以使用输出来编写逻辑，如果你提供 X，则提供 Y。
实际操作层面来说
你可以将代币锁定在一个具有可编程的有效性的谓词中，该谓词表示，“有一些可以花费的代币，满足一些条件时，X 数量的 Y 资产发送到某个地址。同样，你可能有一些逻辑说明此交易仅在 X 以特定价格 Swap 时才有效。这里的误区在于不是你要*发送*任何东西。它已经被发送了。你看到的是交易的最终效果，在这个例子中，代币已被发送。
谓词有效性
在作用域执行期间不检查谓词。而是在交易有效时间内进行检查。谓词可以检查交易的输入是否具有特定属性，但它不关心这些输入是否有效（现有的、已签名的）。当然交易输入必须是有效的，交易才是有效的，但不是谓词在强制执行该有效性。
未来
目前，Fuel 谓词受到字节数的限制，以此作为计量它们的一种方式。将来，Fuel 团队将使用Gas来约束谓词，从而允许使用循环。这使得像自定义哈希和签名验证这样的密码学成为可能，因为它们通常需要使用循环。
Fuel 实现方案的好处
注：如果您想继续阅读使用账户抽象可以做什么，可以跳过此部分UTXO 内省
在比特币和以太坊，以及使用类似实现的协议上，你无法内省交易。这意味着你无法内省花费它的交易，也无法用编程方式，根据输出来设定要执行的操作。
Fuel 账户抽象实现的核心是为开发者和用户提供更大的灵活性，因为这些不是在协议级别编码的东西。Fuel 的帐户抽象允许开发人员在应用程序级别自定义验证方案。
Fuel Labs 团队有一个以太坊私钥的 EC Recover 示例。如果你想要实现不同曲线的 EC Recover，开发者完全可以在应用层编写一个！查看Hashcloack 用 Sway 编写的 BLS12-381 和 Edwards25519 的实现(https://github.com/hashcloak/fuel-crypto)。
EC RECOVER：当向以太坊网络发送交易时，你必须使用你的私钥来签署该交易。EC Recover 正在将这种验证签名的功能转移到智能合约中，而不是只有以太坊节点才能做。有了这，你可以验证的将不仅仅是交易签名本身。没有状态膨胀
无状态账户抽象不会使状态膨胀（那么多），因为即使它被花费了，它也永远不会进入到区块链状态，只会进入历史。
有了谓词，就没有合约、状态或存储。谓词最初没有状态，如果随后有人代表谓词进行花费，你只会得到一条只针对 UTXO 的数据库条目，而不是状态树。
其他生态系统如何实现账户抽象
与计算机科学中的大多数事情一样，帐户抽象可以通过多种方式实现。目前没有一种实现是整个行业的标准。
以太坊
EIP-2938(https://eips.ethereum.org/EIPS/eip-2938)是最早提出账户抽象的EIP，其允许合约成为支付费用和开始交易执行的顶级账户。实现是围绕引入一个新的 EVM 操作码来发出有效性信号，来通过执行任意的 EVM 字节码来扩展交易条件。该提案没有纳入协议，因为开发人员正忙于合并等其他更改，无法冒险进行如此大的协议更改。
ERC-4337(https://medium.com/infinitism/erc-4337-account-abstraction-without-ethereum-protocol-changes-d75c9d94dc4a)是第一个无需更改核心协议即可实现以太坊帐户抽象的提案/标准。它通过将交易验证移出协议本身并将其移至更高级别（具有该特殊“入口函数的智能合约级别）来实现这一点。
在以太坊上，EOA 是以太坊上的账户，其功能被硬编码到协议中。定义他们如何支付 gas，如何签署交易如何使用 nonce 等。这个标准摆脱了 EOA 带来的帐户硬编码性质。
Starknet
Starknet(https://starkware.co/starknet/)是以太坊上的 zk-rollup。Starkware 实现了以太坊 EIP-4337 模型的修改版本。更多相关信息可以阅读如下链接。
(https://community.starknet.io/t/starknet-account-abstraction-model-part-1/781)
zkSync
zkSync 是以太坊上的 zk-rollup。zkSync 实现了EIP-4337的修改版本。更多相关信息可以阅读如下链接。
(https://v2-docs.zksync.io/dev/developer-guides/aa.html#extending-eip4337)可以。
Biconomy
Biconomy 是一个开发者工具平台，专注于以太坊生态系统的基础设施和工具。Biconomy 实现了 EIP-4337 的修改版本，并提供SDK，其中一部分可以实现支付用户 gas 费用的功能。更多相关信息可以阅读如下链接。
(https://biconomy.gitbook.io/sdk/additional-content/account-abstraction)
模块化设计
模块化的精神(https://fuellabs.github.io/fuel-docs/master/modular-execution.html)不是设计一个与另一个系统紧密耦合的系统，从而提供更大的灵活性。Fuel 对账户抽象的实现就是一个体现。Fuel 的帐户抽象实现允许更高的灵活性，带来高度可定制的环境，开发人员可以在应用程序级别定义有效性条件，而无需依赖 Fuel 协议来支持它。
因为 Fuel 不是专门为以太坊或任何其他系统构建的，所以 Fuel 的实现不会被其他系统的包袱所拖累，从而有了更大创新的空间。
虽然 zkSync、Starkware 和 Biconomy 都实现了 EIP-4337 的修改版本，但 Fuel 实现了更独特和更高性能的帐户抽象。因为 Fuel 将作为以太坊上的Rollup进行部署，所以从一些账户来看，以太坊已经有了账户抽象。
帐户抽象可以做什么
你看到的正在构建的新的用户体验是由帐户抽象实现的功能，而不是帐户抽象本身。诸如用户支付 gas 费用和 Web3Auth 之类的，都是建立在帐户抽象之上的应用层。这些事情本质上成为可能是因为帐户抽象的核心原理：以编程方式设置交易有效性条件。
建立在账户抽象之上的例子：
- Web3auth
- 为其他用户支付gas费
- 签名验证方案的自由
- 检查多签（原生多签）
- Authsome(https://taikai.network/ethlisbon/hackathons/ethlisbon-2022/projects/cl9tv1epm14319401w1mf7ltuhm/idea) - 无钱包登录系统。这个钱包随后被用作可插拔的认证基础设施，类似于 Web3Auth。
- Thunder(https://twitter.com/ThunderbyFuel/status/1598338104573714433?s=20&t=MCV2iY9PdkvkpoWJAtouBQ) - Fuel 上的 NFT 市场，可以一键批量执行交易。
- Poolshark](https://twitter.com/poolsharks_labs) - 一种定向流动性协议。Poolshark 使用 Fuel 的账户抽象与汇集的流动性匹配条件订单，以提高高级交易者的可访问性并降低费用。
提升用户体验
- 钱包的社会恢复
- 批量交易
- 应用程序可以为其用户的交易支付 gas
- 使用来自不同生态系统（或相同，使用不同签名方案）的钱包
- 无钱包 web3 登录
- 用户不需要在他们的“常规”钱包中使用 ETH 来发起交易
- 能够将 100% 的资金放入多重签名并直接从其发起交易
解锁新应用
“没有人知道，但这极具启发性。它让人们行动起来！”
事实上：我们还不完全知晓可以解锁哪些创新型的应用程序，但我们可以开始大幅提升现有应用程序的用户体验，这是一个很好的开始。
最后
几年前，区块链在用户层面的问题是世界上大多数人在经济上无法负担其使用成本。随着Layer 2的持续发展和衍生，我们遇到了一个新的问题：UX。
突然间，我们可以将费用降到足够低以使区块链可用，但应用程序的用户体验需要更加舒适和稳健。在下一个周期中，我预计会有更多团队关注支持在帐户抽象上提升用户体验和改进流程。这将为web3 带来类似 web2 的托管体验。
