以太坊开发者近期披露，EIP-8141 的设计出现新进展。该提案尝试把部分交易功能写成可编程合约调用，也就是“frames”，而不是每增加一种能力就修改一次以太坊交易封装格式。
交易功能改为可编程调用
这一思路覆盖的功能包括交易到期、聚合签名、隐私池相关的 Merkle 根，以及交易执行后的断言检查。开发者认为，如果这套接口足够通用，以太坊未来引入新验证方式时，钱包、浏览器、签名设备和 Layer 2 不必每次都适配新的交易外壳。
EIP-8141 草案把一笔 Frame Transaction 定义为一组合约调用序列。不同 frame 可以负责验证交易条件、批准 gas 支付，或执行用户操作。
目前草案列出三种模式：DEFAULT、VERIFY 和 SENDER。其中，VERIFY frame 用于检查某项条件是否满足，SENDER frame 则代表以交易发送者身份执行操作。多个 frame 还可以组成原子批处理，即要么全部成功，要么整体回滚。
减少钱包和基础设施协调成本
开发者 Derek Chiang 的核心观点是，未来新增功能未必都要再设计一套新的交易封装。只要通过新的 frame 目标和调用模式表达，就可能在保持基础结构稳定的前提下扩展能力。
以太坊每次修改交易封装，影响范围并不只在执行客户端。钱包、Layer 2、区块浏览器、签名硬件、软件库和各类基础设施服务商，都要理解并支持新格式。
Chiang 表示，以太坊升级大约每九个月推进一次，若频繁改动交易封装，协调成本会很高。相比之下，若 frame 格式能成为较稳定的接口，新验证方法就可以更多交给合约或指定协议组件处理。
不过，这并不意味着未来所有功能都能绕开网络升级。EIP-8141 本身仍会修改以太坊共识规则，需要客户端实现。若涉及新操作码、预编译合约或 gas 规则，仍可能需要硬分叉。
EIP-8130 与并行验证方向
开发者也承认，交易抽象程度提高后，钱包和排序器在执行前分析交易会更困难。为此，团队正研究 EIP-8141 与另一份账户抽象草案 EIP-8130 的配合方式。
EIP-8130 提出链上 keystore 结构，让账户预先登记参与者和认证合约，并在交易中明确标注认证方式。这样一来，节点在运行任意钱包代码前，就能先判断交易需要哪种验证流程。对 Layer 2 来说，这有助于限制为一组成本更可预测的认证方式。
Vitalik Buterin 也在另一篇帖子中解释了相关方向。他把交易拆分为“动作”和“依赖条件”两部分。前者负责改变以太坊状态，后者则包括签名、Merkle 证明或零知识证明等前置条件。若这些依赖彼此独立，未来就可能并行检查，从而降低部分交易的处理成本。
已列入 Hegotá，但激活时间未定
官方 Hegotá Meta EIP 已把 Frame Transactions 列为计划纳入的升级内容之一，这意味着其状态较此前更进一步。但 EIP-8141 目前仍是核心草案，技术细节尚未最终敲定。
接下来仍需推进的工作包括：更新规范、完成执行客户端实现、搭建开发网络，以及与钱包和 Layer 2 系统进行互操作测试。开发者还需要评估内存池拒绝服务风险，因为可编程验证可能提高筛除无效交易的计算成本。
目前，Hegotá 的 Sepolia、Hoodi 和主网激活时间仍为空白。EIP-8141 已进入升级计划，但距离最终落地还有一段实现和测试过程。