通过帧交易实现原生临时密钥轮换 - 密码学

通过 Frame Transactions 实现原生临时密钥轮换

感谢 @mvicari 的贡献以及 @asanso 的反馈

摘要

这是我们之前发布的文章 通过临时密钥对和账户抽象实现量子安全 的后续。

我们建议将临时密钥轮换直接集成到 frame transaction 格式 (EIP-8141) 中，而无需单独的 Account Abstraction 层。通过添加一个单例注册表合约，可以在协议层将签名权限与链上身份解耦，并且 Frame Transactions 的原生打包能力使我们能够为每笔交易添加一个用于轮换签名者的 frame，从而以最小的开销和最大程度的统一性实现一次性 ECDSA 密钥，使密钥轮换对所有发送者统一可用。

动机

EIP-8141 引入了 frame transactions，它将验证逻辑与交易发送者解耦，为任意签名方案打开了大门。独立地，在我们之前的作品中，我们展示了在每笔交易后进行密钥轮换（在 AA 层实现）可以通过使每个暴露的密钥立即失效，从而有效中和 ECDSA 面临的量子威胁。

Frame transactions 已经为这种轮换逻辑提供了一个天然的归宿：与其在每个智能合约钱包中独立实现密钥轮换，我们可以将其植入交易格式本身，使其对所有发送者统一可用。

设计

该提案需要两个组件才能运作：

1. 签名者注册表合约

部署在知名地址的单例合约，维护从账户地址到其当前授权签名者的映射：

mapping(address account => address signer) public signerOf;

我们在我们的 git repo 构建了该注册表合约的一个示例实现。

在未来，我们计划升级此合约，使其也包含处理使用 ECDSA 签名的 frame transactions 的整个 VERIFY 过程所需的代码。

2. Frame Transaction 中的额外 Frame

为了实现轮换，有必要添加一个指向单例合约的 frame，将授权签名者更改为下一个签名者。打包功能在 frame transactions 中是原生的，因此该 frame 可以添加到任何交易中而无需协议更改。

验证流程

在 VERIFY frame 中，会在注册表中查找 tx.sender 的当前签名者。交易签名将针对该签名者进行验证（而不是直接针对 tx.sender）。

• 如果 signerOf[sender] == address(0)，用户签名将直接针对 tx.sender 进行验证，默认保留类似 EOA 的行为。
• 如果验证通过，tx.sender 的注册表条目将更新为 nextSigner，完成轮换：

signerOf[tx.sender] = nextSigner;

这最后一步是在一个额外的 frame 中完成的，因为验证 frame 不能进行状态更改。

这种轮换必须发生，即使其他执行 frame 被回滚，这镜像了在基于 AA 的方法中确定的相同不变性：失败的交易绝不能在不轮换的情况下让当前签名者暴露。

FrameTxScheme.png1360×1120 77.1 KB

轮换开关

如果交易中没有包含轮换 frame，则不会发生签名者轮换，使密钥轮换功能完全可选。用户可以简单地通过在交易中添加适当的 frame，在任何以太坊账户上决定开启或关闭它。

属性

• 将签名与链上身份解耦：账户地址永远不会改变；只有授权签名者会轮换。
• 量子缓解：每个私钥恰好使用一次；即使以后被量子计算机破解，它也无法授权未来的交易。
• 默认选择加入：从未向注册表写入（或永久设置 nextSigner = 0）的账户会经历标准的行为，且没有额外开销。
• 无需每个钱包的逻辑：发送者-签名者解耦在交易验证层处理，而不是在每个合约内部，从而消除了对自定义智能钱包实现的需求。
• BIP44 兼容性：nextSigner 地址可以从 BIP44 路径派生，使该方案与现有的 HD 钱包基础设施兼容。

与基于 AA 的轮换的比较

我们上一篇文章中基于 AA 的方法在智能合约钱包的 validateUserOp 内部实现了同样的轮换，表明这种方法在今天也是可行的，并展示了 ERC20 转账约为 13.6万 Gas。这种 frame transaction 方法的不同之处在于：

• 轮换是协议的一等公民功能，而不是每个钱包的约定。
• 所有 frame-transaction 发送者都能受益，而无需部署或升级智能钱包。

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