Many people describe account abstraction as a means to “automatically execute transactions once some condition is met.” Only a subset of those situations is possible if you’re implementing stateless account abstraction—which you should!
许多人将账户抽象描述为一种“在满足某些条件后自动执行交易”的手段。如果您正在实施无状态帐户抽象，那么只有部分情况才是可能的——当然您应当如此！
什么是账户抽象？(What is account abstraction?)
Account abstraction, in general, is the ability to set the validity conditions of a transaction programmatically.
一般来说，账户抽象是用编程方式设置交易有效条件的能力。
What account abstraction is not:
账户抽象不是什么：
- paying users’ gas fees
支付用户的gas - native multi-sig
原生(支持)多签 - web3auth type “social login”
web3auth 类型 “社交登录”
You can do these things as a result of an account abstraction implementation.
作为实现帐户抽象的结果，您可以执行这些操作
EIP-4337, which we cover more in-depth later, written by Vitalik et al., says, “Achieve the key goal of account abstraction: allow users to use smart contract wallets containing arbitrary verification logic instead of EOAs as their primary account.”
EIP-4337，容我们稍后会更深入介绍，但它由 Vitalik 等人撰写，说，“实现账户抽象的关键目标：允许用户使用包含任意验证逻辑的智能合约钱包，而非 EOA 作为他们的主账户。”
Currently, on Ethereum, a transaction is valid if and only if:
目前，在以太坊上，当且仅当满足以下条件时，交易才有效：
- There's sufficient balance to pay gas.
有足够的余额支付gas。 - The nonce is correct.
随机数是正确的 - It has a valid digital signature.
具有有效的数字签名。
But what if developers could define a different set of conditions in which transactions are valid?
但如果开发人员在有效交易中可以定义一组不同的交易条件呢？
无状态与有状态帐户抽象 (Stateless vs. stateful account abstraction)
Before we move on, it's important to note that two types of account abstraction exist: stateless and stateful.
在我们继续之前，重要的是要注意存在两种类型的帐户抽象：无状态和有状态。
Many people describe account abstraction as a means to “automatically execute transactions once some condition is met.” Only a subset of those situations is possible if you’re implementing stateless account abstraction—which you should!
许多人将账户抽象描述为一种“在满足某些条件后自动执行交易”的手段。如果您正在实施无状态帐户抽象，那么只有这些情况的一个子集是可能的——当然您应当如此！
Stateless = doesn't depend on the external state, doesn’t have side effects.
无状态 = 不依赖于外部状态，没有副作用。
Stateful = can depend on external state, has access to chain’s state.
有状态 = 可以依赖于外部状态，可以访问链的状态。
In a stateful account abstraction implementation, the smart contract that defines validity conditions has access to the chain’s state. The problem with this is that a condition that is true at one instance may not be true at another. Practically speaking, this would look like a node sending a transaction that is currently valid and becomes invalid later. For example, say you wanted to execute a transaction at block 1000000 automatically. At block 1000000, you could submit a user operation into the mempool, which would be valid at the time. When the bundler tries to put it into the next block, it could be that it’s not valid because the block number increased.
在有状态的账户抽象实现中，定义有效条件的智能合约可以访问链的状态。但这样做的问题是，在一个实例中为真的条件在另一个实例中可能不为真。实际上，这看起来像是一个节点发送一个当前有效但稍后无效的交易。例如，假设您想在区块 1000000 自动执行一笔交易。在区块 1000000，您可以将用户操作提交到内存池中，这在当时是有效的。当 打包者(bundler)试图将它放入下一个块时，它可能是无效的，因为区块号增加了。
The receiving node has to spend resources validating something that will never be on-chain and can’t blacklist what sent the transaction because it was valid at the time of sending.
接收节点必须花费资源来验证永远不会在链上的东西，并且不能将发送的交易内容列入黑名单，因为它在发送时是有效的。
In ERC4337, which we go into more detail about later, researchers spent a lot of time figuring out how to avoid this. The specification bans using specific opcodes like blockNumber for this reason.
在我们稍后会详细介绍的 ERC4337 中，研究人员花了很多时间来弄清楚如何避免。出于这个原因，规范禁止去使用特定的操作码，如blockNumber。
With stateless account abstraction, you never run the risk of changing validity– it’s monotonic.
使用无状态帐户抽象，您永远不会冒更改有效性的风险——它是单片/单核的。
Fuel 无状态 AA的实现 (Fuel’s Implementation of stateless AA)
We’ll talk about how other ecosystems implement account abstraction in a bit. By starting with Fuel, you’ll see the contrast between building a new system from the ground up and the modular thesis, compared to building for an existing system.
我们稍后会讨论其他生态系统如何实现帐户抽象。从 Fuel 开始，您将看到从头开始构建新系统和模块化论文与构建现有系统之间的对比。
Fuel implements stateless AA with predicates. A predicate is just a condition under which you can spend a UTXO. Predicates are scripts where the main function returns a boolean. A pure function where assets under that predicate are unlocked and can be spent by the caller if evaluated to true. A predicate owns or controls UTXOs.
Fuel 使用谓词实现无状态 AA。谓词只是您可以花费 UTXO 的条件。谓词是主函数返回布尔值的脚本。一个纯函数，其谓词下的资产被解锁，若评估结果为真，则可以由调用者使用。谓词拥有或控制 UTXO。
Note: UTXO stands for unspent transaction output. The core fundamental understanding of UTXOs is that for each transaction, the entirety of the balance, or amount of coins, gets spent. The amount you send to your intended recipient goes to them, and the rest gets burned, then minted again, resulting in new unspent output.
注意：UTXO代表未花费的交易输出。对 UTXO 的核心基本理解是，对于每笔交易，都会花费全部余额或代币数量。你发送给目标收件人的金额会转给他们，其余的会被销毁，然后再重新铸造，从而产生新的未花费输出。
The key thing about Fuel predicates is that you can introspect, or examine, the inputs and outputs of predicates which allows you to have agreements that allow you to build an order book exchange or do atomic swap between multiple parties.
Fuel 谓词的关键是您可以内省，或检查谓词的输入和输出，这使得您可以达成允许建立订单簿交易所或在多方之间进行原子交换的协议。
At the transaction level, UTXO transactions describe a subset of the exact effects of a transaction. This subset of effects can be conditioned on in stateless account abstraction. Fuel achieves this through the design decision of a UTXO model. This is what enables the system the possibility to know about the inputs and outputs of a transaction. On Ethereum, you only know about the inputs. With Fuel, you could use the outputs to write logic that says if you provide X then Y.
在交易层面，UTXO 交易描述了交易确切影响的一个子集。这部分效果可以在无状态帐户抽象中进行调节。 Fuel 通过 UTXO 模型的设计决策实现了这一点。这使系统能够了解交易的输入和输出。而在以太坊上，你只知道输入。使用 Fuel，您可以使用输出来编写逻辑，比如您提供X，那么就会有 Y。
实际来说 (Practically speaking)
You could lock coins in a predicate with programmable validity that says, “these are spendable if, in return, X amount of Y asset was sent to a certain address. Similarly, you could have some logic that says this transaction is only valid if X is swapped at a certain price. The gotcha here is not that you’re sending anything. It’s already been sent. You’re seeing the final effects of the transaction, in this case, where coins have been sent.
你可以将代币锁定在一个具有编程有效性的谓词中，该谓词说，“X 数量的 Y 资产被发送到某个地址，那(作为回应)这些代币就是可以花费的。同样，您可能有一些逻辑表明此交易仅在 X 以特定价格交换时才有效。这里要注意的是，不是你要 发送 任何东西，而是已经发送了。您将看到交易的最终效果，在这种情况下，代币实际已被发送。
谓词的有效性 (Predicate validity)
Predicates aren’t checked during scoped execution. They’re checked at transaction validity time. A predicate can check that the transaction's inputs have specific properties, but it doesn't care if those are valid (existing, signed) inputs. They have to be valid inputs for the transaction to be valid, but it's not the predicate that enforces that validity.
在作用域执行期间不检查谓词。他们在交易有效时间进行检查。谓词可以检查交易的输入是否具有特定属性，但它不关心这些输入是否有效（现有的、已签名的）。要使得交易有效，那它们必须是有效输入，但它不是强制执行有效性的谓词。
很快 (Soon™)
Right now, Fuel predicates are constrained by the number of bytes as a way to meter them. In the future, the team is going to constrain predicates with gas, allowing for the use of loops. This makes it possible to do cryptography like custom hashing and signature verification, which usually require loops.
现在，Fuel 谓词受到字节数的限制，以此作为"限制"的一种方式。将来，团队将使用gas来约束谓词，进而允许使用循环。这使得像自定义哈希和签名验证这样通常需要循环的密码学成为可能。
实施Fuel的好处 (Benefits of Fuel’s Implementation)
Note: Skip this section if you want to move on to what you can do with AA
注意：如果您想继续了解可以使用 AA 做什么，请跳过此部分
UTXO 内省 (UTXO Introspection)
On both Bitcoin and Ethereum, and the protocols that use similar implementations, you can’t introspect transactions. This means you can’t introspect the transaction spending it, and you can’t programmatically set what to do based on outputs.
在比特币和以太坊以及使用类似实现的协议上，你无法内省交易。这意味着您无法内省花费它的交易，也无法根据输出用编程方式设置要执行的操作。
At its core, Fuel’s implementation of AA offers developers and, in turn, users more flexibility because these are not things encoded at the protocol level. Fuel’s account abstraction allows developers to define custom verification schemes at the application level.
核心来说，Fuel AA的实施为开发人员和用户提供更大的灵活性，因为这些不是在协议级别编码的东西。 Fuel 的帐户抽象允许开发人员在应用级别自定义验证方案。
The Fuel Labs team has an EC Recover example for an Ethereum private key. If you wanted an EC Recover for different curves, a developer could write one at the application layer! Check out this implementation of BLS12-381 and Edwards25519 by Hashcloack, written in Sway.
Fuel Labs 团队有一个以太坊私钥的 EC Recover 示例。如果您想要针对不同曲线的 EC Recover，开发人员可以在应用层编写一个！请查看用 Sway 编写的 Hashcloack 对 BLS12-381 和 Edwards25519 的实现。
EC RECOVER: When sending a transaction to the Ethereum network, you have to sign this transaction with your private key. EC Recover is moving this functionality of verifying a signature into a smart contract instead of it being something only an Ethereum node can do. With this, you can verify much more than just the transaction signature itself.
EC RECOVER：当向以太坊网络发送交易时，您必须使用您的私钥签署该交易。 EC Recover 正在将这种验证签名的功能转移到智能合约中，而不是只有以太坊节点才能做的事情。有了这个，您可以验证的不仅仅是交易签名本身。
没有状态膨胀 (No state bloat)
Stateless account abstraction doesn't bloat the state (as much) because even when it gets spent, it never enters the blockchain state, only the history.
无状态账户抽象不会使状态膨胀（那么多），因为即使它被花费了，它也永远不会进入区块链状态，只会进入历史。
With predicates, there’s no contracts, state, or storage. Predicates don’t have state initially, and then if someone spends on behalf of the predicate, you only get one database entry, just for the UTXO instead of a state tree.
有了谓词，就没有合约、状态或存储。谓词最初没有状态，然后如果有人代表谓词花费，你只会得到一个数据库条目，这只针对 UTXO 而不是状态树。
其他团队如何进行帐户抽象 (How Other Teams are doing Account Abstraction)
Like most things in computer science, account abstraction can be implemented in myriad ways. No one implementation is standard across the industry.
与计算机科学中的大多数事物一样，帐户抽象可以通过多种方式实现。没有一种实施是整个行业的标准。
Ethereum
EIP-2938 was an initial EIP to allow a contract to be the top-level account that pays fees and starts transaction executions. The implementation was around introducing a new EVM opcode to signal validity to extend the conditions of transactions with the execution of arbitrary EVM bytecode. This proposal didn’t make it into the protocol because devs were busy with other changes like the merge and couldn’t risk a protocol change of that magnitude.
EIP-2938 是一个初始 EIP，允许合约成为支付费用的顶级账户并开始交易执行。实施是围绕引入一个新的 EVM 操作码，来发出有效信号，以通过执行任意 EVM 字节码来扩展交易条件。该提案没有纳入协议，因为开发人员正忙于合并等其他更改，无法冒险进行如此大的协议更改。
ERC-4337 is the first account abstraction proposal/standard that brings on Ethereum account abstraction without requiring core protocol changes. It does this by moving the validation of transactions out of the protocol itself and moving it over to a higher level—the smart contract level with this special entry point.
ERC-4337 是第一个账户抽象提案/标准，无需更改核心协议即可实现以太坊帐户抽象。它通过将交易验证移出协议本身并将其移至更高级别（具有此特殊“入口点 entry point ”的智能合约级别）来实现这一点。
On Ethereum, EOAs are accounts on Ethereum whose functionality is hardcoded into the protocol. Defining how they pay gas, how they sign transactions, how they use a nonce, etc. This standard moves away from the hard-coded nature of accounts that EOAs give us.
在以太坊上，EOA 是以太坊上的账户，其功能被硬编码到协议中。它定义如何支付 gas，如何签署交易，如何使用随机数等。这个标准摆脱了 EOA 给我们的帐户的硬编码性质。
Starknet
Starknet is a zk-rollup on Ethereum. Starkware implements a modified version of the model of EIP-4337 for Ethereum. Read more about it here.
Starknet 是以太坊上的 zk-rollup。 Starkware 为以太坊实现了 EIP-4337 模型的修改版本。在 此处 阅读更多相关信息。
zkSync
zkSync is a zk-rollup on Ethereum. zkSync implements a modified version of EIP-4337. Read more on their implementation here.
zkSync 是以太坊上的 zk-rollup。 zkSync 实现了 EIP-4337 的修改版本。在 此处 阅读有关其实施的更多信息。
Biconomy AA
Biconomy is a developer tooling platform focused on infrastructure and tooling for the Ethereum ecosystem. Biconomy implements a modified version of EIP-4337 and offers features like paying for users’ gas fees as part of an SDK. Read more about their implementation here.
Biconomy 是一个开发者工具平台，专注于以太坊生态系统的基础设施和工具。 Biconomy 实现了 EIP-4337 的修改版本，并提供了诸如作为 SDK 的一部分来支付用户 gas 费用的功能。在 此处 阅读更多关于它们实施的信息。
模块化设计 (Modular Design)
The ethos of modular is not designing a system that is tightly coupled with another system, allowing for greater flexibility. Fuel’s implementation of account abstraction is a manifestation of that. Fuel’s implementation of account abstraction allows higher flexibility and a highly customizable environment where developers can, at the application level, define validity conditions without depending on the Fuel protocol to support it.
模块化的精神 并不是设计系统间互相紧密耦合的(新)系统，来实现更大的灵活性。 Fuel 对账户抽象的实现就是一个体现。 Fuel 的帐户抽象实现允许更高的灵活性和高度可定制的环境，开发人员可以在应用程别定义有效性条件，而无需依赖 Fuel 协议来支持。
Because Fuel wasn’t built exclusively for Ethereum or any other system, Fuel’s implementation isn’t burdened by the baggage of another system and has room to innovate.
因为 Fuel 不是专门为以太坊或任何其他系统构建的，所以 Fuel 的实施不会被另一个系统的包袱所累，并且依然创新的空间。
While zkSync, Starkware, and Biconomy all implement a modified version of EIP-4337, Fuel implemented a more unique and highly performant account abstraction. Because Fuel will be deployed as a rollup on Ethereum, by some accounts, Ethereum already has account abstraction.
虽然 zkSync、Starkware 和 Biconomy 都实现了 EIP-4337 的修改版本，但 Fuel 实现了更独特和高性能的帐户抽象。因为 Fuel 将作为以太坊上的汇总而部署，所以从一些账户来看，以太坊已经有了账户抽象。
您可以使用帐户抽象做什么 (What you can do with Account Abstraction)
The new experiences you see being built are features made possible by account abstraction but not by account abstraction itself. Things like sponsoring gas fees for users and things like Web3Auth are application-layer things built on top of account abstraction. These things are inherently possible through account abstraction's core mechanism: the ability to set the validity conditions of a tx programmatically.
您看到正在构建的新体验，是由帐户抽象而变得可行的功能，但并不是由帐户抽象本身来实现。诸如为用户赞助 gas 费用和 Web3Auth 之类的东西，是建立在帐户抽象之上的应用层。通过帐户抽象的核心机制，这些事情本质上是可能的：以编程方式设置交易有效性条件的能力。
Examples of things built on top of account abstraction:
建立在账户抽象之上事情的例子：
-
Web3auth
Web3授权 -
Paying gas fees for other users
为其他用户支付gas -
Freedom of signature verification scheme
自由的签名验证方案 -
Check multiple signatures (native multi-sig)
检查多签(原生多重签名)
Check out these projects who have leveraged Fuel’s account abstraction:
查看这些利用 Fuel 帐户抽象的项目：
-
Authsome - Walletless login system. This wallet is then used as the basis for a pluggable authentication infrastructure, similar to Web3Auth.
Authsome - 无钱包登录系统。这个钱包随后被用作可插入身份验证基础设施的基础，类似于 Web3Auth。 -
Thunder - An NFT marketplace on Fuel that can bulk execute transactions with one click.
Thunder - Fuel 上的 NFT 市场，可以一键批量执行交易。 -
Poolshark - a protocol for directional liquidity. Poolshark matches conditional orders using Fuel's account abstraction with pooled liquidity to improve accessibility and reduce fees for advanced traders.
Poolshark - 定向流动性协议。 Poolshark 使用 Fuel 的账户抽象与汇集的流动性来匹配条件订单，进而提升专业交易者的可访问性并降低费用。
UX改进 (UX Improvements)
-
Social recovery of wallets
钱包的社交性恢复 -
Batching transactions
批量交易 -
Applications can pay for the gas of their users’ transactions
应用可以支付用户交易的费用 -
Use wallets from different ecosystems (or same, that use different signature schemes)
使用来自不同生态系统（或相同，使用不同签名方案）的钱包 -
Walletless web3 login
无钱包 web3 登录 -
Users don’t need ETH in their “regular” wallet to initiate transactions
用户不需要在他们的“常规”钱包中使用 ETH 来启动交易 -
Ability to put 100% of funds in a multisig and initiate transactions from there directly
能够将 100% 的资金放入多重签名并直接发起交易
新应用解锁 (New Applications Unlocked)
“No one knows, but it's provocative. It gets the people going!”
“没有人知道，但它真的让人血脉贲张。它让人们真的行动起来！”
Here’s the truth: we don’t fully know what new types of applications can be unlocked (yet), but we can begin to make massive improvements to the UX of existing applications, and that’s a great start.
事实是这样的：我们还不完全知道可以解锁哪些新型应用，但我们可以开始对现有应用的用户体验进行大规模改进，这是一个很好的开始。
让所有人都能使用区块链 (Making blockchains available to everyone)
A couple of years ago, the UX problem with blockchains was that they were entirely financially inaccessible to most of the world. With the continued progress and proliferation of layer 2s, we arrive at a new frontier: UX.
几年前，区块链的用户体验问题是世界上大多数人在经济上完全无法获得它们。随着layer2的持续进步和扩散，我们到达了一个新的前沿：用户体验。
Suddenly, we can get fees down low enough to make blockchains usable, but the applications' UX needs to be more pleasant and robust. Over the next cycle, we foresee more teams will focus on account abstraction-enabled UX improvements and flows. This will be another tool needed to bring a web2-like experience with the custodial properties of web3.
突然之间，我们可以将费用降到足够低来让区块链变得可用，但应用的用户体验需要更加愉快和稳健。在下一个周期，我们预计会有更多团队关注支持帐户抽象的用户体验改进和流程。这应是利用web3 的托管特性，带来类似 web2 的体验所需的另一个工具。
致谢 (Acknowledgments)
John Adler, Kristof Gazso, Yuan Han Li, James Prestwich, Ryan Sproule.
敬请关注 (Follow Us)
关于我们 (About Us)
Fuel is the fastest execution layer for the modular blockchain stack. Powerful and sleek, the technology enables parallel transaction execution, empowering developers with the highest flexible throughput and maximum security required to scale. Developers choose the FuelVM for its superior developer experience and the ability to go beyond the limitations of the EVM.
Fuel 是模块化区块链技术栈的最快执行层。该技术功能强大且时尚，支持并行交易执行，为开发人员提供了扩展所需的最高灵活吞吐量和最大安全性。开发人员选择 FuelVM 是因为它卓越的开发人员体验和运行能力 ，突破了 EVM 的限制**。
