账户抽象不会到来

账户抽象 不 会到来

Safe

它已经通过 Safe 实现了

本文旨在揭开账户抽象的真正含义、其相关优势，以及 Safe 如何实施它来创建安全且可用的 Web3 体验。这不是一个关于实施账户抽象的技术指南，我们将在底部包含相关链接。

当前状态

账户抽象这个话题并不新鲜，自 2015 年 以来，它一直是长期讨论的话题。然而，随着 EIP 标准（如 1271 和 4337）的显着进展，以及 Safe、Argent 和 Ambire 等杀手级智能合约钱包的普及，该话题终于出现在 Web3 讨论的前沿，并且 2023 年将是其在实施中走向主流的一年。

不幸的是，这种新出现的炒作往往会产生更多的不准确和空洞的噪音。在 2023 年，围绕该话题存在许多定义和误解。让我们来揭开它们的神秘面纱。

那么，账户抽象到底是什么？

让我们首先从一个加密术语表开始。

     💳 区块链上的一个 账户 是一个具有原生代币余额（例如 ETH、GNO）的实体，它可以是链上交易的入口点。账户可以由用户控制或部署为智能合约（见图 1）

     📃 智能合约账户 是由代码管理的账户，而不是更常见的 外部所有账户 (EOA) 实现，后者是由私钥管理的账户（见图 2）

     🔎 在计算机科学中，抽象 意味着隐藏信息，以增加对更重要领域的关注。

以太坊 EVM 中的账户，来自 Ethereum.org

EOA 与智能合约账户

有了术语表... 让我们来定义 AA。

账户抽象是指将账户类型从 2 种（EOA 和智能合约）减少到 1 种（仅智能合约）的想法，目的是提高 Web3 的可用性和灵活性。

这通过将交易的有效性条件（签名验证、gas 支付、重放保护）从核心协议层（共识层）转移到 EVM 智能合约层（执行层）来实现。

换句话说，我们不仅在谈论仅使用智能合约账户代替 EOA 作为默认账户。我们还在谈论区块链如何与智能合约交互，以及我们如何验证来自智能合约的数据。通过 AA，以下是我们想要抽象出来的账户的具体组成部分：

• 签名抽象 - 允许不同的账户合约使用不同的签名验证方案。

• Gas 抽象 - 允许不同的交易费用支付模型。例如，由另一方/合约支付。

• Nonce 抽象 - 允许除了账户的单个线性 nonce 之外的不同重放保护方案。例如，不同类型的交易使用多个 nonce。

• 网络抽象 - 智能合约账户可以通过任意消息桥由不同网络上的账户控制。

酷，但是为什么要这样做？

账户抽象有点改变了模型。它要求我们以不同于现在的方式思考账户，所有这些都是为了改善用户体验并将下一个 10 亿用户引入 Web3 的核心目标。

目前，默认情况下，链将账户视为私钥和公钥对（即 ECDSA secp256k1 密钥对）。并通过使用此 ECDSA 公钥/私钥对的签名来验证你在区块链上所做的事情。这意味着我们作为用户，需要私钥 (EOA) 才能与链交互。而私钥在存储、管理和恢复方面对用户并不友好。

另一方面，智能合约账户 由于其 可编程性（它们只是代码），因此更加 灵活和可定制。AA 的核心目标是将智能合约账户作为一等公民和 默认账户 来巩固。它通过从核心协议层删除账户规范，并提供一个入口点（或默认账户）来实现这一点，该入口点实现了这些规范。此入口点可以作为合约来实现，例如 EIP4337，或者以原生方式在协议本身中实现，例如 Starknet。

AA 的一个简单的类比是，我们将系统从 iOS 过渡到 Android。它将在灵活性和可定制性方面提供更多，但与任何根本性的系统更改一样，我们需要小心安全方面的权衡。需要通过 AA 实现一个中间立场，我们在 Safe 将确保我们的形式验证合约和开发者工具为开发者创建一个基线，以便在这个智能合约账户时代构建新的和安全的 dapps/钱包。

AA 的好处

账户抽象的价值不仅仅是通过在合约或协议层面实施账户抽象来产生的。而是关于构建在其之上的功能。让我们按 AA 抽象掉的关键组件来区分这些好处。

📝通过从协议中抽象出签名验证逻辑，并允许不同的账户合约使用不同的签名验证方案，你可以在应用层启用以下功能：

• 原生多重签名

• 无种子登录

• 社交恢复

• 批量交易（默认的智能合约功能）

• 轻松的钱包迁移和密钥处理

• 混合托管设置

💱通过在协议层面创建一个单独的执行方案，你可以启用不同的支付模型：

• 支付其用户交易的 gas 费用

• 用户不需要在其钱包中持有 eth

• 用于 gas 的新货币，不强制使用特定的代币（原生代币或合约定义的代币）来支付交易费用。

总而言之 - 这些功能将使我们能够为 dapps 和钱包创建一个对新手友好的体验，这种体验不涉及管理私钥/种子短语以及持有/支付 gas 费用。

那么现在已经有哪些可用了？

鉴于 Safe 是以太坊/EVM 上采用最广泛的智能合约账户，并拥有一套成熟的开发者工具，因此上述好处已经可以通过 SAFE 获得。我们默认在合约层面启用了多重签名、批量交易、中继和恢复机制。但是一旦原生的账户抽象出现，这意味着我们可以在不需要 EOA 或合约定制的核心需求的情况下启用所有这些 SC 功能。这是用户体验方面的一个重大升级，并且很快，使用以太坊账户将与使用银行相同。

Safe 未来在 AA 方面有什么计划？

由于 Safe 是当今以太坊/EVM 上采用最广泛的智能合约账户。我们知道我们在将 AA 变为现实方面发挥着重要作用。找到实施这些新技术的人似乎是账户抽象的最大瓶颈，但我们有很大的计划要通过即将发布的 EthDenver 公告来解决这个问题 👀

最终，我们的目标是帮助在每个链的协议层面推动原生 AA，但也计划支持像 EIP4337 这样的合约标准，他们正在朝这个方向努力，并认为它最终将被推送到验证层和原生代码中。以下是我们未来计划的快速摘要：

EIP4337 支持

• 我们当前的合约 (v1.3) 不允许你将多重签名与 EIP4337 bundler 一起使用。但是，核心合约的 v1.4 使用 Safe 模块解决了这个问题，并将允许我们在 EIP4337 在主网上实施时收集反馈。

原生账户抽象支持

• Safe 合约 v2.0 将支持原生账户抽象。

• 我们将整合从基于模块的 EIP-4337 支持中收集的反馈，以简化对不同链上原生账户抽象的支持。

2023 年将是账户抽象的一年，我们将确保开发者通过 Safe 为其 AA 努力获得充足的资金，无论是通过我们的 资助 还是黑客马拉松。对于下一个通过 AA 加入 Web3 的 10 亿用户，我们说 gm。

• 原文链接： safe.mirror.xyz/9KmZjEbF...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～