对于所有人的账户抽象化

June 29th, 2023

许多人将账户抽象描述为“一旦满足某些条件就自动执行交易”的一种手段。如果您正在实施无状态帐户抽象，则只有其中一部分情况是可能的 - 您应该这样做！

免责声明：本文由一名Fuel社区的成员翻译。为了提供准确的翻译，我们进行了仔细的检查，但仍然不排除会有错误或遗漏。Fuellabs不对翻译信息的准确性、可靠性或及时性负责。

原文：Account Abstraction For Everyone Else

什么是账户抽象？

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

这些不是账户抽象：

支付用户的 Gas 费用
原生多重签名
基于“社交登录”的 web3auth

您可以通过帐户抽象实现来执行这些操作。

我们稍后将更深入地讨论由Vitalik等人撰写的EIP-4337，它说：“实现账户抽象的关键目标：允许用户使用包含任意验证逻辑的智能合约钱包，而不是EOA作为他们的主要账户。”

目前，在Ethereum上，交易在以下情况下有效：

有足够的余额来支付Gas。
Nonce 是正确的。
拥有有效的数字签名。

但是，如果开发人员可以定义一组不同的条件，在这些条件下事务是有效的呢？

无状态VS有状态帐户抽象

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

许多人将帐户抽象描述为“在满足某个条件后自动执行事务”的一种方法。如果您正在实现无状态帐户抽象，则只有这些情况的一个子集是可能的—您应该这样做！

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

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

在一个有状态帐户抽象实现中，定义有效性条件的智能合约可以访问链的状态。问题是，在某个实例中为真的条件在另一个实例中可能不为真。实际上，这看起来像是一个节点发送一个当前有效但过后会无效的交易。例如，假设您希望在区块1000000处自动执行交易。在区块 1000000时，您可以将用户操作提交到内存池中，该操作在当时是有效的。当绑定器尝试将其放入下一个块时，可能是因为块数增加而变得无效。

接收节点必须花费资源验证一些永远不会在链上的东西，并且不能将发送交易的内容列入黑名单，因为它在发送时是有效的。

在ERC4337中，研究人员花了大量时间研究如何避免这种情况，我们稍后将对此进行更详细的介绍。由于这个原因，这个规范禁止使用特定的操作码，比如“blockNumber”。

使用无状态帐户抽象，您永远不会冒着更改有效性的风险——这是单调的。

Fuel中无状态AA的实施

稍后我们将讨论其他生态系统是如何实现帐户抽象的。从Fuel开始，您将看到从头开始建立一个新的系统和模块化论文与现有系统上构建两者之间的对比。

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

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

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

在交易层面，UTXO交易描述了交易确切影响的子集。这种效应子集可以以无状态帐户抽象为条件。Fuel通过UTXO模型的设计决策实现了这一点。这使系统能够了解交易的输入和输出。在Ethereum上，你只知道输入。有了Fuel，你可以用输出来写逻辑，如果你提供X，那么它提供Y。

从实际情况来说

你可以将代币锁定在一个具有可编程有效性的谓词中，该谓词说：“如果作为回报，X数量的Y资产被发送到某个地址，这些都是可以消费的。同样，你可以有一些逻辑，说只有当X以某个价格交换时，这笔交易才有效。这里的问题不是你要”发送”任何东西。它已经被发送了。你看到的是交易的最终效果，在这种情况下，代币已经被发送。

谓词有效性

在有效范围执行期间不检查谓词。它们在交易有效期进行检查。谓词可以检查交易的输入是否具有特定的属性，但它不在乎这些是否是有效的（现有的、已签名的）输入。它们必须是有效的输入，交易才会有效，但执行这种有效性的不是谓词。

Soon™

现在，Fuel 谓词受到字节数的约束，以此来衡量它们。未来，团队将使用Gas约束谓词，从而允许使用循环。这使得像自定义哈希和签名验证这样通常需要循环的密码学成为可能。

实施 Fuel 的优势

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

UTXO 反省

在Bitcoin和Ethereum以及使用类似实现的协议上，你都无法内省交易。这意味着您不能内省花费它的交易，也不能基于输出以编程方式设置要执行的操作。

从本质上讲，Fuel对AA的实现为开发人员和用户提供了更多的灵活性，因为这些都不是在协议级别编码的东西。Fuel的帐户抽象允许开发人员在应用程序级别定义自定义验证方案。

Fuel Labs团队有一个Ethereum私钥的EC Recover示例。如果您想要针对不同曲线的EC Recover，开发人员可以在应用层编写一个！看看Hashcloack用Sway编写的BLS12-381和Edwards25519的实现。

EC RECOVER*：当向Ethereum网络发送交易时，您必须用您的私钥签署此交易。 EC Recover正在将验证签名的功能转移到智能合约中，而不是只有Ethereum节点才能做的事情。有了这一功能，您可以验证的不仅仅是交易签名本身。*

没有状态膨胀

无状态账户抽象不会让状态膨胀（那么多），因为即使花掉了，它也永远不会进入区块链状态，只有历史记录。

有了谓词，就没有契约、状态或存储。谓词最初没有状态，然后如果有人代表谓词进行支出，则只能获得一个数据库条目，仅用于UTXO而不是状态树。

其他团队如何进行账户抽象

像计算机科学中的大多数东西一样，帐户抽象可以通过多种方式实现。没有哪种实施方案是整个行业的标准。

Ethereum

EIP-2938是最初的EIP，允许合约作为支付费用和开始交易执行的顶级账户。它的实现围绕着引入一个新的EVM操作码来表示有效性，以通过执行任意EVM字节码来扩展交易的条件。这个提议没有被纳入协议，因为开发人员正忙于合并或者其他更改，不能冒险进行如此大规模的协议更改。

ERC-4337是第一个在不需要更改核心协议的情况下实现Ethereum账户抽象的账户抽象提案/标准。它通过将交易的验证从协议本身中移出，并将其转移到更高的级别，即具有此特殊“入口点”的智能合约级别来实现这一点。

在Ethereum上，EOA是Ethereum上的账户，其功能被硬编码到协议中。定义他们如何支付Gas、如何签署交易、如何使用随机数等。这一标准摆脱了EOA给我们的账户的硬编码性质。

Starknet

Starknet是Ethereum上的zk-rollup。Starkware为Ethereum实现了EIP-4337模型的修改版本。点击此处了解更多信息。

zkSync

zkSync是Ethereum上的zk-rollup。zkSync实现了EIP-4337的修改版本。点击此处了解更多信息。

Biconomy AA

Biconomy是一个专注于Ethereum生态系统基础设施和工具的开发工具平台。Biconomy完成了EIP-4337的修改版本，并作为SDK的一部分提供了支付用户Gas等功能。请在此处阅读有关其如何实施的更多信息。

模块化设计

模块化的精神不是设计一个系统与另一个系统紧密结合，而是提供更多的灵活性。Fuel对账户抽象的实施就是一种表现。Fuel对账户抽象的实施提供了更高的灵活性和高度可定制的环境，开发人员可以在应用程序级别定义有效性条件，而无需依赖Fuel协议来支持它。

由于Fuel不是专门为Ethereum或任何其他系统构建的，因此Fuel的实施不会受到另其他系统的负担，并且有创新的空间。

虽然zkSync、Starkware和Biconomy都对EIP-4337版本实现了修改，但Fuel实现了更独特、更高性能的帐户抽象。由于Fuel将作为rollup部署在Ethereum上，因此从一些账户来看，Ethereum已经有了账户抽象。

你可以使用账户抽象来做什么

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

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

Web3身份
为其他用户支付Gas
自由签名验证方案
检查多重签名（本机多签）

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

Authsome - 无钱包登录系统。这个钱包被用作可插拔身份验证基础设施的基础，类似于Web3Auth。
Thunder - Fuel上的NFT市场，可以一键批量执行交易。
Poolshark - 定向流动性协议。Poolshark使用Fuel的账户抽象将有条件订单与汇集的流动性相匹配，以提高可访问性并降低高级交易员的费用。