Pectra的瑰宝：EIP-7702，SetCode交易

我起初对写这篇文章有些犹豫。

我一直希望我的文章既要 有趣，实用，最重要的是要容易 理解。但是，有这么多优秀的文章，我无法确定这篇文章是否会具备这些特点。然而，我的一位优秀同事建议我直接去写。所以我想， 那为什么不呢？

本文涵盖的概念应该是易于理解的，无需深入了解 Ethereum Virtual Machine（EVM）或 Solidity 开发。然而，尽管我努力保持尽量简单，某些基本的 Ethereum 术语和 功能将会出现，因此对 生态系统和 EIPs 的熟悉可能会有所帮助。

本文将尝试介绍以太坊 Pectra 更新中最受期待的特性之一：EIP-7702，也被称为 Set Code Transaction。

为了做到这一点，我觉得有必要提供一点关于以太坊当前状态的 背景。

关于以太坊更新的简短故事

维塔利克·布特林在2020年10月正式提出 rollup-centric roadmap，声明以太坊不再专注于作为L1处理任何事情，而是专注于成为 rollups 的最佳链，同时保持L1链尽可能安全和稳健，同时允许L2处理网络的 可伸缩性 scalability。

请记住，rollups 会将交易打包（或“压缩”）成批次，在链外执行，基本上保持链上记录每个交易的发生，而无需单独发送。

这减少了需要发布到区块链的数据量，从而增加了可伸缩性。

这种观点的转变在很大程度上影响了对以太坊生态系统进行的更新和升级的方向（以及L2、库和工具的运营方式）。

除了 rollup-centric 的路线图，以太坊的更新也受到其存在以来最大升级的重大影响：合并（The Merge）（2022年9月15日）。

合并实现了从分布式 工作量证明（Proof-of-Work）系统（最初由比特币白皮书提出）到引入了两个单独层的 权益证明（Proof-of-Stake）系统的完全转变：

• 一个负责交易的 执行 及 状态变化，我们可以称之为“执行客户端”（如Geth、Reth、Besu等），
• 另一个实现权益证明 共识算法 的，可以称之为“共识客户端”（如Lighthouse、Lodestar、Prysm等）。

以太坊文档中的客户端图示

每个新以太坊更新通过一系列 EIPs（ 以太坊改进提案）进行描述，这些提案详细描述了 建议的更改、其 理由以及如何在新链版本和客户端中实施这些更改。例如，在一个EIP中引入新的 opcode 到EVM，而在另一个中修改现有的 数据结构。

这一切都相关吗？ 当然是相关的！ 但是，除了其在以太坊底层操作中的固有重要性外，这种分离成两个层也决定了一般更新的命名。

它们包含对 EL 和 CL 的更改，每个层都有其自己的名称：

• EL 更新以 举办Devcon 会议的城市命名，
• CL 更新则以 按字母顺序排列的星星 命名（没错，星星🌟）。

为了表示整个硬分叉，两个名称会 合并。

我们今天要讨论的EIP是 Pectra 更新 的一部分，此名称源自 布拉格 Devcon 会议和 Electra 星。

如果你想了解更多关于以太坊更新命名的工作原理，我建议你查看以下文章：以太坊如何命名更新及其原因。

现在我们对我们的立场有了更清晰的认识，我们应该意识到驱动EIP存在的概念：账户抽象。

当我们谈论账户抽象时，我们主要是指 隐藏 用户使用 Externally Owned Account（EOA）与区块链交互的需求。

目前，进行任何“操作”的唯一方式是通过EOA，这可能导致 Web2 用户在转换到 Web3 时感到 沮丧，因为他们 不知道 或 不关心 如何处理钱包和私钥，从而导致非标准化的解决方案往往过于复杂。

然而，如果我们能实现良好的账户抽象解决方案，我们将能够：

• 赞助 交易（例如允许 Web2 用户上手而无需支付交易费用），
• 批量交易（这是一个非常实用的功能，Solana 在其 SVM 设计中原生实现了它），
• 处理 特权降级（在需要时允许其他用户访问账户的资源），

并且可以解锁更多有趣的功能！

这就是为什么账户抽象在过去几年中一直是一个 热门话题。想象一下，找到一种方法以保留以太坊的 安全性 和 稳健性 特性，同时轻松 onboard 新用户（并扩展EOAs的能力作为额外的好处）。

请记住，多年来提出了许多提案（如 EIP-3074、EIP-4337 等）试图解决这个问题，但目前没有任何一个 EIP 能够解决 所有 问题。

账户抽象EIPs的历史以及以太坊中的讨论非常有趣，可能是另一个文章的好话题，但现在让我们介绍最新的贡献（而且是一个很出色的贡献）！

EIP-7702，也被称为 SetCode Transaction 的 EIP，建议改变EOAs在 原生 级别的操作方式。

正如奥利凡德对哈利所说：“魔杖选择巫师，波特先生。对于我们这些研究魔杖法的人来说，早已不言而喻。”

好的，对于研究以太坊的我们来说，EOAs 和智能合约账户之间的区别一直是显而易见的：EOAs不能存储代码，但可以触发交易，而智能合约账户可以存储代码但无法独立触发交易。

SetCode Transaction 是来改变这一点的，允许EOAs存储代码。

好的，我说谎了 — 它们实际上不会 存储 代码，但在7702之后，它们将存储所谓的 delegation designator，你可以基本上把它想象成指向存储你想执行代码的智能合约的 指针。

这是一个巨大的变化，你基本上是通过发送一次交易来 转换 你的 EOA 成为智能账户！

用户必须遵循的流程相对简单，如下图所示（基于 @tinchoabbate 的图形，他展示得如此清晰，我发现很难不使用整个图）。

如图所示，普通用户想要 转换 他们的 EOA 为智能账户，必须 选择一个合约，来提供他们账户的逻辑（不用说，合约必须已经部署在链上），签署一个 类型-4 交易（遵循 EIP-2718 标准），他们可以自己发送，也可以让其他人发送。

之后就没多少事可做了，如果交易成功，那么他们应该已经成功将他们的 EOA 转变为可以执行其智能合约允许的复杂代码的智能账户。

难道这听起来不让人 惊叹 很 简单 吗？

但我们还没有那么快， 这只是对 EIP-7702 一旦 Pectra HardFork 生效后将允许的 高层次 介绍，但如果我们想在现实中使用它，还有许多内容需要了解……

如果你像我一样好奇，你可能还有一些悬而未决的问题：

• 任何人都可以发送这个交易将我的账户转换为智能账户吗？
• 新智能账户的 状态 位于何处？
• 我可以将 智能账户转换回EOA 吗？
• 如果我EOA指向的智能合约存在漏洞，我 可以更新它吗？
• 一旦我将账户转换为智能账户，我的 nonce 会发生什么变化？
• 我如何开始使用它？我可以在 Pectra 更新生效之前试用它吗？
• 这与其他所有账户抽象 EIPs（如 4337）有什么 不同？
• 关于在 多个链 中使用我的EOA 呢？
• 钱包提供商和应用程序最有可能会 决定 哪些智能合约对普通用户使用作为委托合约足够安全，因为大多数人无法自行判断。这是否违背了去中心化？这是否存在任何风险？
• 这是账户抽象的 上帝之手 吗？（ 剧透，不是）。

别担心，我打算在接下来的文章中详细讨论所有这些问题。

快速回顾！

在本文中，我们讨论了最新的以太坊升级之一 Pectra update（以布拉格 Devcon 事件和 Electra 星命名）将引入 setCode transaction，正如 EIP-7702 中规定的，以及其他一些特性。

这个新交易允许 EOA 利用 智能合约 来 扩展其功能，不仅仅是触发交易——使得像 交易赞助、批量处理 和 特权降级 等功能成为可能——有效地将其转变为我们所称的智能账户。这是对 账户抽象 概念的重要贡献，而这是以太坊生态系统中一个主要的讨论点。

尽管将 EOA 转换为智能账户似乎很简单，但我们仍需分析 setCode 交易如何在用户账户上下文中利用智能合约的代码，以理解其局限性和潜在风险。

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