作为OKX Web3技术团队推出的「以太坊Pectra升级」系列文章的第02期，本期内容我们将继续聚焦升级背后的核心技术变更，结合实际应用场景展开分享与讨论，欢迎技术同仁一同参与学习交流。以太坊Pectra升级是继坎昆升级之后的重要里程碑，聚焦账户抽象、数据可用性、预编译合约优化等多个技术方向。这不仅关乎以太坊性能和开发体验的进一步提升，也将深刻影响未来去中心化应用的设计范式。
本文的核心议题是「智能账户标准化的必要性」，我们关注到账户抽象（Account Abstraction，AA）的生态系统在不断发展过程中，已逐渐显现出碎片化的趋势。虽然目前已经拥有 ERC-4337、ERC-6900、ERC-7579 等接口标准来定义账户抽象的功能，但不同实现方案之间在用户体验、接口规范和行为预期上存在明显差异。不同的钱包实现方案都聚焦于相似的应用场景和有限的核心功能，但各自采用了不兼容的设计假设和实现逻辑。这种“各自为政”的做法虽为开发者在特定场景下提供了一定的定制空间，却同时大大增加了交互成本，使得终端用户、dApp 开发者和钱包提供方在互操作性、工具支持和使用门槛上均面临阻力。
智能账户要实现规模化采用、提升互操作性、消除生态碎片化，一个关键前提是标准化的钱包实现。现阶段，虽然在账号层面的高度定制化看似具有吸引力，但其实并未带来实质性价值提升，反而成为生态协作的障碍。多种实现方式虽然为开发者在特定场景下提供了灵活性，但也使整个生态变得零散不一，既影响用户的统一使用体验，也增加了应用开发和生态工具建设的复杂性及成本。
随着 EIP-7702 推出，智能账户之间差异可能会进一步放大，这使得统一标准的重要性和紧迫性愈加突出。从长期生态发展的角度来看，只有通过标准化实现，才能有效降低摩擦，实现规模化部署，并提升整体协作效率。相比之下，仅注重灵活和定制化的实现路径，由于缺乏广泛的实际应用场景，其长期价值亟待重新审视。
1、为什么要标准化实现？
ERC (Ethereum Request for Comments) 标准是智能合约开发者最常接触的规范之一，它们为合约中的特定功能定义了明确的行为准则和交互接口。这些标准的实现逻辑和采用方式通常较为开放，允许开发者根据具体需求自由调整。这种开放性对于普通功能而言是适合的，但对于智能钱包中涉及资产安全和去中心化应用（Dapp）兼容性的核心功能来说，却可能产生严重的安全风险和兼容性问题 (例如将在下文中提及的 ERC-20 恶意函数篡改）。
核心功能的复杂性与权限控制的疏漏，易导致钱包行为的不确定性和安全漏洞，增加用户资产被盗或遭受攻击的风险。同时，不统一的行为模式也给Dapp的开发带来较大的兼容性挑战，增加了生态整合的复杂度和成本。因此，对于涉及安全性和兼容性的关键功能，明确的标准定义及统一且可验证的标准化实现必不可少。
下文将进一步讨论，在 EIP-7702 激活后，智能钱包应采用“标准化实现”来完成的两项关键功能。
1.1 合约关键状态的管理
在实现用户交易意图的过程中，所有智能账户都需要对自身的状态数据进行有效管理。随着 EIP-7702 的推出，一个 EOA 账户下的存储空间变得可以被合约使用，并且该存储空间并非由单一合约独占，而是可能被多个智能账户提供方共同使用。
当用户发起“切换代理合约（re-delegation）”操作时，原有的账户合约会被新的合约替换。然而，旧合约写入的状态数据不会随之被清除，仍然保留在存储中。这意味着新的代理合约可以访问甚至修改旧合约写入的存储数据，也就引入了“存储污染”的风险，可能干扰甚至破坏当前合约的执行逻辑。
以合约中的 nonce 状态为例：nonce 是防止交易重放攻击的重要机制。账户在签署每笔交易时都会使用一个新的 nonce，以确保每个签名都是唯一的。当用户频繁切换代理合约时，由于新旧合约之间共享账户的存储空间，nonce的管理可能变得不清晰。例如，当用户从合约 A 切换到合约 B，再回到合约 A 时，会出现以下问题：
钱包提供方(A)如何确保nonce的准确性与连续性 (即没有被合约B恶意修改）？
用户是否必须为不同的合约分别维护不同的nonce？
为了解决这些问题，社区中已经出现了多种方案，例如通过 namespace 对存储进行隔离（ERC-7201），以减少存储混乱带来的影响。但无论采用何种方案，目前生态中仍缺乏强制性的统一规范，来确保 nonce 的唯一性与安全性。
凡是涉及交易验证的关键状态，尤其是像 nonce 这类防重放字段，必须由单一的“可信来源”（Single Source of Truth）进行统一管理与读取。这不仅应是一种“规范”，更应成为具备统一标准化实现的“原则” —— 不论账户是否为 ERC-4337 生态下的智能账户，皆应如此。
1.2 合约上的签名验证
另一项应当采用标准化实现的关键功能是合约账户的签名验证流程。
ERC-1271 是专门针对智能合约设计的一套标准接口，规定了合约如何验证签名，从而允许合约账户与应用进行安全的互动。在 EIP-7702 推出之前，应用通常根据地址类型（是否包含代码）选择合适的签名验证方式：
如果是普通用户地址，则使用传统的签名算法进行验证；
如果是智能合约地址，则调用合约提供的 ERC-1271 接口进行验证。
然而，EIP-7702 的推出模糊了这一区分，因为它允许普通账户地址也带有合约代码。这意味着原本针对普通账户设计的签名验证流程可能会发生意料之外的故障，例如导致某些授权签名失效，从而影响用户资产的安全性与应用的稳定性。
一个更具体的例子是：用户进行 “设置代理合约(delegate)” 操作后，可能会导致 DApp 对 Permit 授权的鉴权失败（如 USDC 的鉴权）
为了避免安全隐患和应用兼容性问题，建议所有基于 EIP-7702 的智能账户都采用统一的签名验证方式，在实现 ERC-1271 接口的同时，也要兼容传统的签名验证逻辑。这种统一且标准化的实现方式，能够有效减少生态中的混乱，保障用户资产的安全，并提高应用之间的兼容性与互操作性。
以下为一种示例实现方式：
2、灵活定制的问题
尽管当前的AA标准，给实现带来了灵活性与扩展性，但随之而来的，是更高的实现复杂度以及更大的集成成本。与 EOA 不同，智能账户的运行更多的依赖于链下与链上的协同机制，尤其是在交易构造和签名验证两个关键环节中。这些环节如果缺乏标准化和统一性，将直接带来实现层面上的碎片化，影响钱包、dApp 乃至整个智能钱包生态的定性。
本节将聚焦两个尤为突出的痛点，说明为何这些环节迫切需要以标准化实现来降低系统性摩擦和潜在风险：
2.1 链下集成的痛点
智能账户在带来全新能力的同时，也引入了额外的实现复杂度。与 EOA 不同，智能账户在与 DApp 交互过程中，更加依赖链下工具对交易进行编码与构造，以适配各自的接口与逻辑。这种差异显著增加了生态中各参与方的集成成本与开发负担：
钱包提供方：每一种智能账户实现往往拥有独特的接口、参数设计与行为假设，钱包必须为其单独适配定制逻辑。这不仅显著增加了开发与维护成本，还降低了智能账户的可移植性 —— 相比之下，传统 EOA 用户只需导入助记词即可轻松在不同提供方之间完成钱包迁移。
DApp 开发者：不同的智能账户实现支持的核心功能高度相似，但接口参数与调用逻辑却千差万别。DApp 必须先识别用户所使用的账户类型，再对交互流程做出适配。以合约钱包中最常见的批量调用（batch executions）接口为例，由于各钱包的具体实现方式不同，导致函数签名与结果处理上出现大量不兼容的情况:
Safe、Biconomy 和 ZeroDev 都分别实现了各自版本的批量调用功能，但三者的函数命名、接口参数和结果处理方式均不相同。其中，ZeroDev 考虑了批量调用失败的情况，而 Safe 和 Biconomy 并未处理此类场景。
简而言之，智能账户在“实现层面”（而不是接口定义层）缺乏标准化，已导致生态趋于碎片化。这种碎片化严重阻碍了整个链下集成生态的发展：智能账户难以在不同供应商间迁移，DApp 需要处理大量特殊逻辑，用户则被迫面对不一致、甚至令人困惑的使用体验。
2.2 链上验证的安全考量
ERC-4337 标准已经相对成熟，并为赞助交易定义了一整套安全处理机制。然而，其框架中包含的 EntryPoint 调用、多次合约交互及模拟验证、Paymaster Gas 计算、Bundler 补偿转账等多个步骤，往往会带来较高的 Gas 开销，对 Gas 成本敏感的用户来说并不友好。
因此，在本节中，我们将探讨一种脱离 ERC-4337 框架的、面向 EIP-7702 智能账户的“赞助-补偿”交易流程，以期在保证基本安全性的同时，简化路径、降低 Gas 消耗。
假设一个极简化的“赞助-补偿”流程，用于 EIP-7702 下的智能账户：赞助方（Sponsor）调用账户合约，执行用户指定的交易意图（Intent）。由于智能账户本身是模块化的，其验证器（Validator）的选取也具备高度灵活性。以下流程基于几个关键假设：
赞助方仅在链下模拟（simulation）确认可以通过特定代币获得补偿后（30行），才会上链提交交易。例如，用户使用 USDC 对赞助方进行补偿；
赞助方信任该智能账户实现，认为其逻辑诚实可靠；
用户可自行选择或配置已安装/白名单内的验证器模块来验证其交易意图。
为了防止赞助方遭受攻击，必须尽量减少“红丸攻击”（Red Pill Attack）的风险 —— 即链下模拟结果与链上实际执行结果出现显著差异，导致赞助方预期补偿失败。特别是涉及外部合约调用时，此类风险尤为显著，恶意被调用方可能通过链上故意失败影响整个交易流程。
根据我们所构建的伪代码示意交易流程，涉及三类关键的外部调用操作，分别是：
验证（Validation）：调用验证器合约确认用户请求的合法性。这是风险最高的阶段：验证发生在补偿之前，链下可能模拟成功，但链上可能故意失败，造成赞助方损失。
补偿（Reimbursement）：调用代币合约向赞助方支付补偿。一般使用如 USDC 等可信稳定币。补偿操作位于用户意图执行之前，若验证通过，补偿即执行，不受后续执行影响。
批量调用（Batch Call）：执行用户意图，调用多个合约。为保护赞助方利益，批量调用不应导致整个交易回滚，即使其中部调用分失败，也不影响补偿的完成。可设置 Gas 限制，防止 OOG（Out of Gas）导致交易整体失败。
在这三类调用中，验证阶段的外部合约调用最为敏感，因为它位于交易初期、且直接决定后续流程是否继续。然而，当前赞助方在验证失败时缺乏保护机制，极易遭遇模拟与真实环境不一致的攻击。
为降低风险，建议对验证环节进行严格约束。一种有效策略是采用“白名单机制”，仅允许预先审核过的可信验证器合约参与验证流程。白名单的维护方可以是赞助方自身，也可以是账户提供方，以提供更大的灵活性。
进一步分析验证流程，可以发现其实际应用场景相对集中，主要包括：
用户的自定义签名验证（如使用 Passkey、多签方案）；
针对特定场景的受限访问授权（如 SessionKey 授权）等。
鉴于验证逻辑在本质上高度相似，建议采用统一的、具备一定倾向性的标准化实现作为生态基础组件。在未来，行业可通过对这一基础实现进行升级或扩展，以逐步引入新的验证逻辑
3、客制化是伪需求？
回过头来看，智能账户真正带来的价值提升其实是明确且高度聚焦的。大多数实际应用场景并不依赖无限制的定制能力，而是围绕少数几个关键功能点展开。正如 EIP-7702 动机中所强调的，这些核心能力包括：
批量处理（Batching）：允许用户在单笔原子交易中执行多个操作。例如，当前在去中心化交易所（DEX）中，用户需分别发起 ERC-20 授权和实际代币转账操作，造成用户体验断裂。而更高级的批处理场景还可能涉及操作之间的依赖关系，例如第一个操作的输出作为第二个操作的输入。
交易赞助（Sponsorship）：允许账户 X 为账户 Y 发起交易并承担相关 Gas 费用。账户 X 可从账户 Y 处获取 ERC-20 代币补偿，或由其自身运营方承担费用，实现类似“免 Gas 体验”。
权限降级（Privilege de-escalation）：用户可签发权限受限的子账户，只允许其执行部分操作，如仅能消费 ERC-20 代币但禁止使用 ETH，或设置每日花费上限，甚至仅能与特定 DApp 交互。这一能力为更安全、细粒度的账户控制提供了可能。
基于上述目标，对智能账户进行高度定制化的做法不仅缺乏必要性，甚至可能适得其反。当前生态中，大量账户实现的功能实质上大同小异，但在接口与代码逻辑上却千差万别，造成以下严重问题：
字节码冗余（Bytecode bloat）：大量仅有微小差异的账户合约部署上链，导致链上存储膨胀，增加节点同步与维护成本。
标准化假象（Illusion of standardization）：类似于 ERC-20 所面临的问题，虽然接口表面一致，但实现行为却五花八门。有研究指出，部分 ERC-20 实现可能通过“巧妙”地修改函数行为，破坏集成方对其预期逻辑的合理假设，甚至构成恶意行为。对于智能账户来说，这个问题更加严重，可能带来更加广泛的不兼容甚至安全风险。
鉴于此，在追求智能账户能力扩展的同时，控制实现多样性、推动功能核心化与实现标准化，将是下一阶段智能账户生态走向稳定与规模化的关键路径。
4、标准化实现是实现项目间去信任协作的关键
去信任性（Trustlessness） 是区块链系统所追求的核心特性之一，尤其是在跨项目协作、模块化组合日益普遍的今天。然而，在实践中，真正的去信任往往难以实现：即使合约通过了审计，仍可能存在未知漏洞；而为了支持灵活迭代而引入的可升级性机制，也常常意味着某个外部账户或控制器握有“最终权限”，从而重新引入了中心化的信任点。
相较之下，不可升级的（immutable）合约似乎提供了更强的去信任保障，但如果这些合约并非基于经过社区审查、长期验证的共享实现，它们的不可变性反而会成为风险源。一旦发现漏洞，项目可能被锁死在一个无法修复的错误逻辑中，反而违背了去信任性应有的安全保障。
因此，标准化、共享且可审计的合约实现，是实现项目间真正去信任协作的关键。它们作为“生态共识”的一部分，为多个项目提供统一的、可信赖的逻辑单元，让合作各方无需相互建立信任即可安全集成和交互。
当每个项目都从零开始自行实现时，模块化与可组合性带来的不再是自由，而是复杂性、重复性和互操作性问题。而通过依赖标准化实现，项目间可以在不引入额外信任假设的前提下协作，真正推动去中心化生态的可持续发展。
总结：标准化实现，是智能账户走向规模化、实现互操作的关键
为了真正释放智能账户的潜力，并为用户、DApp 与钱包提供方带来切实的价值提升，基于 EIP-7702 的标准化最小实现，可能是智能账户未来发展的关键方向。
通过对关键状态管理、签名验证等核心功能进行标准化，智能账户生态可以显著降低实现复杂度、提升跨项目的互操作性，并为用户提供更加一致、可预测且安全的使用体验。
EIP-7702 的推出，不仅是一项技术创新，更是建立智能账户通用基础设施的契机。它为我们提供了一个“重构共识”的窗口期，推动整个 Web3 钱包生态从功能多样走向结构统一，实现真正的可持续发展。
术语解释
Terminology | Description | |
|---|---|---|
1 | ERC 标准 | ERC 标准是为以太坊区块链上合约应用设计的一系列标准规范。一项 ERC 标准，通常会定义和规范合约的接口和功能。例如 ERC-20 代币标准，为代币合约的转账、铸造、销毁、等设定了共同接口使得代币可以在区块链网络上进行交易和传输。然而，ERC 标准的实现并不具有强制性，开发者可以根据自己的需求 “自由裁量” 一个 ERC 标准的的实现逻辑。 |
2 | 账户抽象 （Account Abstraction）/ ERC-4337 | 账户抽象是指把传统外部账户（EOA）的签名验证和支付等功能，转移到智能合约（智能钱包）中，从而让用户的账户具有灵活可编程能力，既能实现多签、社交恢复、批量交易、Gas 代付等高级功能，也摆脱了仅靠私钥控制的单点风险。ERC-4337 是一种不修改底层协议、基于账户抽象思路的 ERC 标准。该标准通过引入 UserOperation、Bundler、EntryPoint、Paymaster 等新模块，构建起了一套智能合约钱包生态。 |
3 | EIP-7702 | 是以太坊 “布拉格升级” 的一部分，该提案定义了一种全新的交易类型，即 “Set Code 交易”。通过该交易，用户可以将任意智能合约的执行逻辑 “映射” 到外部账户（EOA）上。这意味着，用户只需通过签署一个 Set Code 交易，便能使现有的 EOA 账户不仅具备智能合约的执行逻辑，同时也保留原有的 EOA 特性（例如通过私钥签名交易）。 |
4 | ERC-1271 | 是一个让“合约账户”也能验证签名的 REC 标准接口。原本只有外部账户（EOA）的签名能（在节点上）得到验证，现在通过这个接口，合约（在EVM内）也能“理解”和确认签名是否合法。 |
5 | 切换代理合约（Re-delegation） | 指的在是在EIP-7702升级后，用户将映射到 EOA 账户上的智能合约 A 切换到另一个合约 B。可以理解为用户换了一个“控制账户行为的操作系统”（即执行逻辑），但原系统遗留下来的账户数据还存在“磁盘”（Account Storage）上，可能被新系统访问或修改。 |
6 | 重放攻击 | 指的是黑客“复制并重播”用户之前发出的链上交易，造成重复执行，这种攻击一般是利用合约漏洞完成的。比如用户转了一次账，黑客让这笔交易被重新执行多次。就像有人偷偷录下你转账的操作并偷偷反复播放。为了防止重放攻击，智能合约的设计需要包含一些机制来确保交易的不可重复性。 |
7 | 赞助方（Sponsor） | 是指为用户发起交易、支付 Gas 费用的第三方。赞助方可能希望从用户方获得 ERC20 代币作为 Gas 补偿（Token Pay），也可能只是为了提升用户体验而免费帮用户发交易（Free Gas)。具体的补偿模式由赞助方和用户双方共同决定。 |
8 | 用户意图（Intent） | 用户希望账户完成的某种链上操作，比如“转账”、“授权代币”等。可以理解为用户签署一个“指令”，由账户执行这个“任务”。体操作由合约账户在链上帮用户完成。 |
9 | 验证器（Validator） | 在模块化的智能账户设计中，用来验证交易是否合法的模块或合约。比如检查签名对不对、是否满足权限条件等。就像一个门卫，只有通过验证的交易指令才能在该账户下执行。 |
往期内容回顾
© 2025 OKX。本文可以全文复制或分发，也可以使用本文 100 字或更少的摘录，前提是此类使用是非商业性的。整篇文章的任何复制或分发亦必须突出说明：“本文版权所有 © 2025 OKX，经许可使用。”允许的摘录必须引用文章名称并包含出处，例如“文章名称，[作者姓名 (如适用)]，© 2025 OKX”。不允许对本文进行衍生作品或其他用途。