大多数关于帐户抽象的文章都很糟糕
如果你正在阅读本文，你很可能已经阅读了一些便于理解帐户抽象的文章。你可能会同意99%关于帐户抽象的帖子都非常烂。?
你发现几乎所有的人都从描述EOA和智能合约之间的区别开始，并含糊得提及用户体验的改进。他们未能解释账户抽象本质上是什么，而是专注于账户抽象的副产品。
本指南涵盖了账户抽象思想的每一步，从账户抽象是什么，到为什么每个人都称它为下一个大事件。
什么是账户抽象？
我发现从帐户抽象不是什么开始更容易，账户抽象不是：
支付用户的Gas费??原生多签签名??web3auth类型的“社交登录”作为帐户抽象实现的结果，你可以执行这些操作。?
如果我将帐户抽象重新命名会更直观，它会被称为“可编程的交易有效性(programmabletransactionvalidity)“。
通俗来说，账户抽象是可以以编程方式设定交易的有效性条件。
我们稍后将更深入地介绍由Vitalik等人撰写的EIP-4337(https://eips.ethereum.org/EIPS/eip-4337)，它提到，“实现账户抽象的关键目标：允许用户使用包含任意验证逻辑的智能合约钱包，而不是EOA，作为他们的主要账户。”
目前，在以太坊上，当且仅当满足以下条件时，交易才有效：
1.有足够的余额支付gas。??
2.nonce是正确的。??
3.具有有效的数字签名。?
但是，如果开发人员可以定义一组不同的交易有效性条件呢？?
Argent推出利用账户抽象的自托管智能钱包Web Wallet:8月4日消息，智能合约钱包Argent宣布推出利用账户抽象的自托管智能钱包Web Wallet，允许用户使用电子邮件地址创建网络钱包，无需下载，也无需助记词。[2023/8/4 16:18:40]
当我在做研究时和James(@_prestwich)聊过，回过头来看，他将帐户抽象的问题表述为，“如果你可以通过密钥以外的任何方式进行身份验证怎么办？你可以做些哪些很酷的事情？”
无法自动执行交易
无状态(stateless)vs有状态(Stateful)的帐户抽象
在我们继续之前，重要的是要知道存在两种类型的帐户抽象：无状态的和有状态的。????
许多人将账户抽象描述为“一旦满足某些条件就自动执行交易”的方案。如果你正在实现无状态的帐户抽象，那么只有上述表述中的一些子集情况是可能的！
Stateless=不依赖于外部状态，没有副作用。?Stateful=可以依赖于外部状态，可以访问链的状态。在有状态账户抽象实现中，定义有效性条件的智能合约可以访问链的状态。这样做的问题是，在一个实例中为真的条件在另一个实例中可能不为真。实际上，这看起来像是一个节点发送一笔当前有效但之后变得无效的交易。例如，假设你想在区块高度为1000000时自动执行一笔交易。在区块高度为1000000时，你可以将用户操作提交到内存池中，这在当时是有效的。当区块打包者试图将它放入下一个块时，它可能是无效的，因为区块号增加了。
接收的节点必须花费资源来验证永远不会上链的东西，并且不能将交易发送方列入黑名单，因为它在发送时是有效的。?
欧易Web3钱包已支持AA账户抽象:金色财经报道，欧易发布公告宣布已于2023年08月02日支持账户抽象，可以一键创建智能合约账户。未来，欧易Web3钱包还将持续基于EIP-4337，持续为账户抽象技术添砖加瓦，陆续将推出社交恢复以及其他特色功能。[2023/8/2 16:13:53]
我们稍后会详细介绍ERC4337，其中研究人员花了很多时间来弄清楚如何避免这种情况。出于上述的原因，规范中禁止使用特定的操作码，如“blockNumber”。??
使用无状态帐户抽象，您永远不会有更改有效性条件的风险——它是单调的。
Fuel：无状态的账户抽象?
我们稍后会讨论其他生态系统如何实现帐户抽象。从Fuel开始，你将看到如何从头开始构建一个新系统和模块化理论，以及为现有系统构建之间的对比。
Fuel使用谓词(Predicate)实现无状态的账户抽象。谓词是你可以花费UTXO的条件。其是主函数返回布尔值的脚本。函数逻辑控制如果求值为真，则该谓词下的资产被解锁，可以由调用者使用。谓词拥有或控制UTXO。
注：UTXO代表未花费的交易输出。对UTXO核心的基本理解是，对于每笔交易，都会花费全部余额，或者说代币数量。你发送给目标收款人的金额会全部转给他们，其余的会被销毁，然后再次铸造，从而产生新的未花费输出。?Fuel谓词的关键是你可以内省或检查谓词的输入和输出，这将允许你构建订单簿Dex，或在多方之间进行原子化的Swap。
在交易层面，UTXO交易描述了交易影响的一个子集。这部分效果可以在无状态帐户抽象中进行调节。Fuel通过UTXO模型的设计实现了这一点。这使系统能够了解交易的输入和输出。在以太坊上，你只知道输入。使用Fuel，你可以使用输出来编写逻辑，如果你提供X，则提供Y。
Arbitrum已激活One和Nova上的账户抽象端点支持:8月2日消息，Offchain Labs已正式在Arbitrum One与Arbitrum Nova上激活对账户抽象端点的支持。
此前报道，7月17日，Arbitrum提案AIP-2已获得投票通过，将在 One 和 Nova 主网上激活对账户抽象端点的支持。该提案旨在解决ERC-4337打包交易的问题，新RPC端点eth_sendRawTransactionConditional 将允许用户在提交交易时指定有效的区块高度和时间戳范围，从而解决了在验证和执行阶段之间可能发生的智能合约账户存储变化的问题。[2023/8/2 16:13:47]
实际操作层面来说
你可以将代币锁定在一个具有可编程的有效性的谓词中，该谓词表示，“有一些可以花费的代币，满足一些条件时，X数量的Y资产发送到某个地址。同样，你可能有一些逻辑说明此交易仅在X以特定价格Swap时才有效。这里的误区在于不是你要*发送*任何东西。它已经被发送了。你看到的是交易的最终效果，在这个例子中，代币已被发送。??
谓词有效性
在作用域执行期间不检查谓词。而是在交易有效时间内进行检查。谓词可以检查交易的输入是否具有特定属性，但它不关心这些输入是否有效。当然交易输入必须是有效的，交易才是有效的，但不是谓词在强制执行该有效性。?
未来
目前，Fuel谓词受到字节数的限制，以此作为计量它们的一种方式。将来，Fuel团队将使用Gas来约束谓词，从而允许使用循环。这使得像自定义哈希和签名验证这样的密码学成为可能，因为它们通常需要使用循环。
Vitalik Buterin：账户抽象可简化用户体验，同时增强以太坊的灵活性和适用性:7月18日消息，以太坊创始人Vitalik Buterin在以太坊巴黎EthCC会议上，详细阐述了账户抽象的历史及最新进展。Vitalik强调了账户抽象的重要性，这一特性可为智能合约账户和普通账户提供统一的交互界面，从而简化用户体验，同时增强以太坊的灵活性和适用性。[2023/7/18 11:02:52]
Fuel实现方案的好处
注：如果您想继续阅读使用账户抽象可以做什么，可以跳过此部分UTXO内省
在比特币和以太坊，以及使用类似实现的协议上，你无法内省交易。这意味着你无法内省花费它的交易，也无法用编程方式，根据输出来设定要执行的操作。
Fuel账户抽象实现的核心是为开发者和用户提供更大的灵活性，因为这些不是在协议级别编码的东西。Fuel的帐户抽象允许开发人员在应用程序级别自定义验证方案。?
FuelLabs团队有一个以太坊私钥的ECRecover示例。如果你想要实现不同曲线的ECRecover，开发者完全可以在应用层编写一个！查看Hashcloack用Sway编写的BLS12-381和Edwards25519的实现(https://github.com/hashcloak/fuel-crypto)。?
ECRECOVER：当向以太坊网络发送交易时，你必须使用你的私钥来签署该交易。ECRecover正在将这种验证签名的功能转移到智能合约中，而不是只有以太坊节点才能做。有了这，你可以验证的将不仅仅是交易签名本身。没有状态膨胀
无状态账户抽象不会使状态膨胀，因为即使它被花费了，它也永远不会进入到区块链状态，只会进入历史。?
Alchemy：以太坊账户抽象提案EIP-4337已在主网上部署:金色财经报道，Web3开发平台Alchemy在社交媒体上宣布，以太坊账户抽象提案EIP-4337已在主网上部署，未来将为我们带来实现的工具。1.无缝的用户入职、2.更多的账户安全、3.无Gas费交易。
一个全新的web3体验就在眼前。[2023/3/9 12:50:22]
有了谓词，就没有合约、状态或存储。谓词最初没有状态，如果随后有人代表谓词进行花费，你只会得到一条只针对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费签名验证方案的自由检查多签查看如下利用了Fuel帐户抽象功能的项目：
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%的资金放入多重签名并直接从其发起交易
解锁新应用
“没有人知道，但这极具启发性。它让人们行动起来！”
事实上：我们还不完全知晓可以解锁哪些创新型的应用程序，但我们可以开始大幅提升现有应用程序的用户体验，这是一个很好的开始。?
最后
几年前，区块链在用户层面的问题是世界上大多数人在经济上无法负担其使用成本。随着Layer2的持续发展和衍生，我们遇到了一个新的问题：UX。
突然间，我们可以将费用降到足够低以使区块链可用，但应用程序的用户体验需要更加舒适和稳健。在下一个周期中，我预计会有更多团队关注支持在帐户抽象上提升用户体验和改进流程。这将为web3带来类似web2的托管体验。??
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。