验证优先的智能合约钱包 - 魔法师 / 原始汤

最近有人对 EIP-3074 及其与未来消除协议中 EOA 的目标是否兼容提出了一些担忧。我花了一些时间思考这个问题，我认为 EIP-3074 实际上提供了一个有趣的替代升级路径。

如果要替换 EOA，我们应该仔细考虑什么来替换它们。

协议智能合约钱包

今天的智能合约钱包通常是自上而下实现的。在简单的情况下，钱包充当保镖（bouncer）。它验证对其的调用，然后将消息转发到目标合约。在更复杂的情况下，它是以不同方式使用以创建复杂访问策略的函数集合。

一个简单的保镖合约是 EOA 的自然替代品。但尽管它具有与现有 EOA 的功能对等性，但它没有 Vitalik 概述的智能合约钱包的任何好处。

有一些替代方案，但它们未能提供协议钱包所需的两个属性：

1. 与今天的工具无关。Solidity 和当前的 ABI 不应泄漏到协议中。
2. 可扩展而无需链上初始化。

为了满足这些要求，我们需要重新思考智能合约钱包的设计方式。

以验证为中心的钱包

智能合约钱包的核心只是强制执行其部署地址的访问策略。实际上在智能合约钱包中实例化 CALL 或执行重放保护只是一个实现细节。

如果我们专注于此属性，我们可以构建一个公正且可扩展的智能合约钱包。

在这种模式下，从 EOA 迁移到协议智能合约将如下所示：

• 部署 EIP-3074，基本保持原样
• 部署 EIP-3540 (EOF)
• 添加一个新的 EOF 部分 validate
• 将所有 EOA 转换为也实现 validate 部分的保镖智能合约，该部分检查 ecrecover(msg, sig) == address()
• 如果还没有 AA，则在客户端中进行特殊分配，允许 code_hash 等于 EOA 合约的帐户发起交易
• 修改 AUTH 的行为以调用恢复地址上的 validate 部分，只有当帐户的 validate 返回 true 时才设置 authorized
• 添加 AUTH2，它接受一个 target 参数，其 validate 部分在调用时立即被调用，并且只有当 target 返回 true 时才设置 authorized（或者，我们可以立即在 EIP-3074 中发布 AUTH2，并要求 target == recovered address，直到添加 EOF 部分 validate。）

这将为我们提供 Vitalik 概述的所有好处，同时 i) 不将 Solidity / 某种 ABI 编码纳入核心协议，以及 ii) 允许任何人在没有首先在链上交互的情况下享受这些好处（和新好处）。

这也为我们带来了 EIP-3074 的一些新的好处。用户可以修改他们自己的 validate 函数来阻止某些调用者，而不是“永远签署一张空白支票”。这比在调用者本身中这样做要好得多，因为只有希望阻止调用者的用户才必须支付存储成本来检查调用者是否被阻止。

我很想知道其他人对此的看法。

• 我们应该超越 EOA，而不是进一步巩固它们（与 EIP 3074 相关）
• EIP-721 vs. EIP-3074 / 智能合约钱包：会发生什么？
• EIP-3074: AUTH 和 AUTHCALL 操作码
• 一个更简单的 EIP 3074 替代方案的案例
• 上海候选：EIP-3074

• 原文链接： ethereum-magicians.org/t...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～