先破一个名字上的误会：EIP-8130 标题里的 Keystore，不是你把私钥加密成一份 JSON 文件的那种 keystore——那是密钥的离线备份容器；这里说的 Keystore 是一份链上合约，登记的是”这个账户认谁、按什么规则认”。EIP-8130 在 2025 年 10 月提出，属于核心类目草案，试图把账户抽象的授权层做成协议级基础设施。下面按四个问题展开：解决谁的痛点、三个角色各干什么、节点行为怎么变、你现在需要做什么。
痛点：节点不想为每笔交易做模拟
此前的账户抽象路线常把”这笔交易合不合法”交给账户合约自己判断，节点就得在内存池边界执行一段来源不明的 EVM 代码才知道答案——这要求全状态访问、跟踪设施和一整套信誉机制来限制滥用成本。EIP-8130 的思路是把认证与账户逻辑拆开：每笔交易显式声明用哪个验证器（authenticator）认证签名，节点看声明就能决定接不接收，不必为任意代码做模拟。
Actor、Authenticator、Keystore 三个角色
规范定义了一组简单关系。Keystore 是账户的配置合约，把账户映射到它的授权条目集合；每一个有权限的主体叫 actor；每个 actor 绑定一个 authenticator——实现 IAuthenticator.authenticate(hash, data) 的合约，输入摘要与签名数据，返回认证出的 actorId。认证之后还有第二道门：actor 能做什么由 keystore 里的作用范围（scope）与授权上下文决定，认证与授权正式分家。这个结构对用户的直观意义是：权限审计从”猜这个钱包签名的含义”变成”读一份链上花名册”。
新交易类型与节点怎么过滤
规范引入一种新的 EIP-2718 交易类型：交易体里点名的验证器若属于规范钦定的规范集合（canonical set），认证走协议内置路径，成本是常数，不执行 EVM；若集合之外的自定义验证器被用于交易路径，链可以有两种采纳姿态——宽松模式下按普通 EVM 执行计费并受认证 gas 上限约束，保守模式干脆拒绝。合约可无许可部署并登记为 actor 的验证器，登记后至少在 EVM 内可用（比如实现钱包自定义的恢复流程），能不能上交易路径则取决于各链策略。
存量账户怎么进来，不支持的链怎么办
普通外部账户不需要任何改造：无代码账户在协议里自动委托到默认账户实现，用现有 secp256k1 密钥照常发这类交易，也可以用 EIP-7702 式的委托或规范自己的账户变更条目覆盖默认。增删权限、恢复换人，都以账户变更的形式记账。在不支持该交易类型的链上，同一套账户靠 ERC-4337 之类的通道转运，逻辑不变——规范把跨链一致性当作卖点：花名册与验证器合约被设计成多链共享的公共底座。
与 EIP-4337 路线的分工
同为账户抽象，ERC-4337 把验证逻辑留在账户合约内部，靠 EntryPoint 与打包器在协议之外补课；EIP-8130 则把”用哪套规则验证”提炼成交易里的显式字段，让过滤规则回到协议边界。两者不是替代关系：规范明确，在不含该交易类型的链上，8130 账户照样借 4337 通道进块。对用户的体感差别在于审计入口——4337 时代你要读账户合约源码，8130 时代你先读那份链上花名册，再看它引用的验证器合约。两条路线的账户在可见的将来会长期共存。
现在需要做什么
EIP-8130 是草案，依赖链包括 EIP-7702 等已在部分网络生效的提案，但它本身不是任何已上线的升级。用户层面的预演很简单：如果你已经在用智能账户，可以现在就把”这个账户谁有权操作、验证规则是什么”当成可审计的清单去要求；如果你用的是普通地址，等未来钱包端出现对应设置时，记住三查——验证器是否来自规范集合、花名册里有几个你认识的条目、每条形不形式上像样而作用域含糊。它想解决的问题清单，与把账户逻辑挂到地址上的EIP-7702 是什么？地址临时借用合约逻辑会发生什么一脉相承；给账户的密钥做链上登记的思路，也可以和把密钥换抗量子算法的给普通地址永久换上抗量子钥匙：EIP-8164 原生密钥委托对照着读。加密私钥文件那种 keystore 的用法与边界，在keystore 文件是什么：加密私钥备份怎么看、怎么用，两回事别混。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。