以太坊开发者解锁EIP-8141帧的新用途

核心提要：以太坊开发者提出EIP-8141：通过可编程合约调用表达交易特性9月7日，以太坊开发者Derek Chiang表示，EIP-8141的作者们找到了一种新方法，将多种交易特性转化为可编程的合约调用（称为“Frames”），而非在以太坊的交易信封中单独添加这些字段。核心摘要以太坊开发团队指出，EIP-8141能够通过被称为

以太坊开发者提出EIP-8141：通过可编程合约调用表达交易特性

9月7日，以太坊开发者Derek Chiang表示，EIP-8141的作者们找到了一种新方法，将多种交易特性转化为可编程的合约调用（称为“Frames”），而非在以太坊的交易信封中单独添加这些字段。

核心摘要

以太坊开发团队指出，EIP-8141能够通过被称为“可编程框架”（Programmable Frames）的合约调用来表达交易特性。这种机制可以在不增加新信封字段的情况下，支持交易过期、签名聚合、隐私证明以及交易后断言等功能。

目前，EIP-8141已列入Hegotá升级计划的日程中，但其规范仍处于草案阶段，激活日期尚未确定。开发人员正协调EIP-8141与EIP-8130的关系，以保持结构的一致性并改善基础设施对交易的可读性。Vitalik Buterin认为，将交易动作与其依赖项分离，有望实现并行验证并降低交易成本。

设计突破：从信封扩展转向合约调用

作为EIP-8141的共同作者及Ethlabs的贡献者，Chiang在最近的一次讨论中将这一进展描述为“设计上的突破”。该方案的核心思路是将交易过期、聚合签名、隐私池Merkle根以及交易后断言等概念，统一视为一种名为“Frames”的调用操作。

根据官方草案规范，“Frame Transaction”被定义为一连串的合约调用序列。不同的Frame可以执行不同的功能：有的用于验证交易，有的用于批准Gas支付，还有的用于执行用户操作。提案目前提供了三种模式：DEFAULT（默认）、VERIFY（验证）和SENDER（发送者）。

VERIFY Frame：检查是否满足所需的条件。SENDER Frame：由被标识为交易发送者的账户执行特定操作。原子批次：Frames还可以被组合成原子批次，这意味着批次中的每一个操作要么全部成功，要么整个组回滚。

Chiang指出，这并非巧合——@lightclients 和 @VitalikButerin 几乎在同一时间发布了关于Frames（EIP-8141）的内容。作者们最近实现了设计上的突破，意识到过去认为必须放入交易信封中的内容，现在可以通过其他方式处理。

稳定的信封接口与降低协调成本

尽管引入了Frames的概念，提案仍然定义了一个基础的交易信封，其中包含链ID、Nonce、发送者、费用、签名以及Frame列表等字段。Chiang强调的重点在于：开发人员可能能够通过新的Frame目标和调用模式引入更多功能，而不必为每个新功能创建一个新的信封格式。

修改以太坊的交易信封不仅影响执行客户端，还波及钱包、Layer 2网络、区块浏览器、签名设备、软件库以及基础设施提供商。由于以太坊的升级大约每九个月进行一次，频繁更改信封格式会导致缓慢且繁重的协调工作。足够通用的Frame格式可以作为稳定的接口，而具体的验证方法则由合约或指定的协议组件提供。

当然，这并不意味着未来的功能完全不需要网络升级。EIP-8141本身会改变以太坊的共识规则，需要客户端进行实施。新的操作码、预编译合约或Gas规则也可能需要硬分叉。提出的主要好处是，开发人员不必每次都需要重新设计交易容器。

原生账户抽象与安全性权衡

EIP-8141规范将其主要目标之一列为支持原生账户抽象。它有望支持密钥轮换、替代签名系统、赞助Gas支付以及交易批处理。同时，它也旨在减少以太坊账户对传统外部拥有账户所使用的secp256k1签名系统的依赖。

正如之前的报道所指出的，可编程验证最终有助于以太坊在不替换固定签名方案的前提下，采用新的认证系统。

然而，Chiang也承认存在权衡之处。高度抽象的交易可能会使钱包、排序器和其他基础设施在执行前难以分析。例如，Layer 2排序器可能希望只接受特定的签名方法，因为其计算成本是可预测的。

因此，开发人员正在探索Frames如何与另一个草案账户抽象提案EIP-8130协同工作。EIP-8130创建了一个链上密钥库，账户在其中注册参与者和身份验证合约，交易明确标识其认证方法。这种结构允许节点在运行任意钱包代码之前，确定交易所需的验证过程。在EIP-8130提议的Layer 2配置文件中，链可以将交易路径限制为一组固定的低成本认证器，同时通过普通的EVM执行为其他认证方法留出空间。

Chiang表示，EIP-8130可以为EIP-8141的Frames施加定义好的结构。这种协作可以在保留Frames灵活性的同时，为钱包和高吞吐量链提供更易读的交易格式。目前的联合设计尚未定稿，两项规范仍可根据修订进行调整。早期的竞争关系正在转变为寻找兼容元素。

Vitalik Buterin：关联并行验证

Vitalik Buterin在一篇独立文章中进一步阐述了技术方向，区分了交易的“动作”（Actions）和“依赖项”（Dependencies）。动作是指改变以太坊状态的操作，如转移ETH；依赖项则是必须满足的条件，如签名、Merkle证明或零知识证明。

Buterin认为，独立的依赖项可以进行并行检查。不访问以太坊状态的条件理论上可以由内存池（Mempool）一次性处理，而不是在执行过程中重复处理。多次检查最终可能通过递归STARK证明来表示，但这仍属于研究方向而非已批准的功能。

这种区分还有助于客户端将可预测的交易与需要以太坊完整动态执行环境的操作分开。Buterin表示，更具静态分析特性的活动可以获得更低的Gas成本并实现更好的扩展性。目前尚无此类费率表获得批准。Frame模型为此方法提供了潜在的接口，因为验证和执行表现为可识别的调用。以太坊在保留灵活合约执行能力的同时，允许更简单的交易声明更多关于其需求的信息。

Hegotá升级计划与未来展望

官方的Hegotá Meta EIP文件现已将Frame Transactions和FOCIL列为纳入以太坊Hegotá升级的计划项目。这比早期的考虑阶段具有更强的地位，但并未冻结EIP-8141当前的技术设计。

EIP-8141仍被标记为草案核心提案。随着实施工作的推进，作者们可以修订Frame模式、签名处理、Gas会计以及与EIP-8130的关系。Hegotá文档中的Sepolia、Hoodi和主网激活字段也留空。

接下来的可衡量步骤包括更新规范、执行客户端实施、测试网络以及与钱包和Layer 2系统的互操作性测试。开发人员还必须审查内存池拒绝服务风险，因为可编程验证可能会使拒绝无效交易变得更加耗费计算资源。

测试将决定所提出的灵活Frames与结构化认证器的组合是否能满足以太坊基础层及更快EVM链的需求。在激活参数公布之前，EIP-8141仍是Hegotá计划中但未完成的一部分。