在即将到来的以太坊 Glamsterdam 升级中，一处埋在共识层存款记账规则里的瑕疵被提前揪了出来。研究员 avsetsin 在升级草案处于公开审查阶段时指出：如果运营者先用某一公钥注册为区块构建者，而质押服务随后用同一公钥为新验证者存入 ETH，原有规则可能会把这两笔存款都记到构建者账户名下，导致用于启动新验证者的质押资金被“记错账”，在极端情形下甚至被运营者提取。多家中文媒体转引 CoinDesk 报道，这一漏洞并未在主网上被利用，而是被审查机制提前锁定，并在讨论后形成修复方案；核心调整是重新梳理验证者存款的处理规则，阻断质押服务存入的新验证者资金被错误划入构建者账户。据报道，该修复已于 10 月 26 日合并进以太坊共识规范，为后续 Glamsterdam 升级上线前的质押记账安全性加上了一道更明确的防线。
看似无害的公钥复用，如何踩中记账陷阱
把时间线拉回到漏洞被推演出来的那一刻：先登场的是运营者，他用一串公钥在系统里注册为区块构建者，这笔注册在共识层的存款记账表里留下了第一条记录。随后登场的是质押服务，它在为新验证者存入 ETH 时，出于公钥管理上的复用，恰好再次使用了同一串公钥。问题就在这里出现了——在原 Glamsterdam 草案的规则下，这两笔原本属于不同角色的存款，在系统眼中却指向了同一个“构建者账户”。因为存款记账逻辑在判断归属时，只依据这串公钥是否已作为构建者出现，而没有把“新验证者存款”当成一个需要单独隔离的角色来源，于是第二笔本应启动新验证者的资金，被错误叠加到了构建者名下。
从设计角度看，这种“先构建者、后验证者、还恰好复用公钥”的组合，被低估成几乎不会发生的边缘场景；但在现实运营中，运营者与质押服务分工明确、各自维护公钥的模式本身，就为这种无心复用留下了空间。一旦这样的组合在链上真正出现，系统就会按照草案里写死的逻辑，把两笔存款合并记入构建者账户，为运营者打开提取原本属于新验证者质押资金的机会，这种潜在错配风险显然不能留到升级落地后再由生产环境来检验。
错记一笔账，质押服务可能失去哪笔ETH
在这种记账错位下，真正被推到悬崖边上的，并不是运营者自己的保证金，而是质押服务代用户打入、用于启动新验证者的那笔存款。链上规则一旦把这笔钱也算入构建者账户，提取权自然跟着落在运营者手里，哪怕用户从未同意、也未曾意识到公钥被复用，协议层却已经把“这是谁的钱”写成了另一种答案。对托管型质押服务来说，这意味着一种极难向委托人解释的场景：表面上，用户看到的是“你的ETH已经用于开通新验证者”；但在底层共识账本里，这笔资金在技术上已经变成运营者可以单方面动用的余额。
这种错配直接冲击的是用户与运营者之间本就脆弱的信任边界。质押服务的商业模式建立在“协议保证规则、运营者负责执行”的分工之上，委托人默认相信，即便运营者掌控密钥，本金和收益的分配也受链上机制约束。然而在这次漏洞暴露出的情形里，激励设计和安全边界出现了重叠：同一组公钥既参与构建者角色的激励，又承载新验证者的存款，只要记账规则稍有偏向，就会在不改变任何表面流程的前提下，把本应锁定给新验证者的ETH，悄然转换成运营者可以提走的资产，这种隐形的权限漂移本身，就是共识层不能容忍的系统性风险。
升级前揪出隐患：以太坊开发者如何堵住漏洞
在公开审查还在进行的时候，研究员 avsetsin 率先把问题抛回给开发者：如果运营者先用某个公钥注册为区块构建者，而质押服务随后用同一公钥为新验证者存入 ETH，那么现有草案下两笔存款会一并落入构建者账户。随着披露细节被反复推演，共识规范维护方很快意识到，这不是单一实现瑕疵，而是存款记账规则本身在「同一公钥、不同角色」场景下缺乏边界约束，于是围绕如何在不破坏现有流程的前提下重写这部分规则展开讨论。
最终拍板的修复方案，并没有去额外收紧构建者的注册流程，而是直接对验证者存款的处理逻辑动刀：在共识层重新定义这类存款的归属路径，防止质押服务存入的新验证者存款被错误划入构建者账户，从规则层切断运营者将这笔 ETH 视作自有资产的空间。据多家中文媒体转引 CoinDesk 报道，这一修复已于 10 月 26 日正式合并进以太坊共识规范，属于在 Glamsterdam 升级上线前完成的预防性修补，也为后续升级在链上落地提供了更安全的质押记账基础。
从一次记账漏洞，看质押服务的公钥与职责边界
这一记账漏洞之所以成立，前提是同一公钥被运营者先用来注册区块构建者，再被质押服务用来为新验证者存入 ETH。按设计，以太坊共识层为构建者和验证者分别设定了存款与权限规则，但 Glamsterdam 草案中这一段逻辑留下了模糊地带：当公钥跨角色复用时，两笔本应分属不同账户的存款被混写进构建者账户，运营者于是获得了提取本应用于新验证者的质押资金的机会。此次修复通过调整验证者存款的处理方式，尽量削弱同一公钥跨角色复用带来的记账错位，但材料也点明，这种风险从一开始就与质押服务的运营实践紧密相连。
从角色设计上看，构建者负责打包区块，验证者承担共识投票，两者在权限和激励上本应保持清晰的职责分离。规则层修补的是边界条件，却无法代替质押服务自身的公钥管理纪律：是否禁止同一公钥在内部被标记为不同角色、是否在流程上阻断“先当构建者、再当验证者”的复用路径，决定了这类场景在现实运营中出现的概率。这次事件对以太坊质押生态的启示在于，不能把安全完全外包给协议升级，参与者需要先在内部流程里消灭这类公钥复用风险，再把共识规则视作最后一道防线。
Glamsterdam之后，需要盯紧哪些安全信号
从结果上看，这次公钥复用漏洞被锁定在Glamsterdam升级草案阶段，未演变为主网事故，且据多家中文媒体转引 CoinDesk 报道，修复已在10月26日合并进以太坊共识规范，对质押存款安全感知的边际影响更多体现在“信心修复”而非“恐慌加剧”：一方面，它暴露了质押记账在设计层面确实存在未被充分建模的极端场景，提醒运营方和开发者不要把现有流程视为理所当然；另一方面，漏洞在上线前被外部研究员 avsetsin 抓出、并迅速进入规范修复，也强化了社区对以太坊升级审查机制的信任。接下来值得盯紧的信号主要有两类：其一，围绕Glamsterdam推进过程，是否还会出现针对质押与存款规则的进一步审查与微调——材料并未给出正式上线时间表，任何新增的规则调整都需要通过官方公告确认；其二，修复合并之后，社区对这类“共识层记账细节”的讨论是否升温，是否推动更多外部研究者持续参与审查。整体来看，这次事件释放的是一个偏正向的长线信号：只要公开审查持续进行、外部研究员与核心开发者保持协作，类似的设计层风险更有机会在规格文档阶段被识别和消除，而不是等到主网资金付出代价时才被市场发现。
加入我们的社区，一起来讨论，一起变得更强吧！
AiCoin专属Hyperliquid福利：https://app.hyperliquid.xyz/join/AICOIN88
AiCoin专属Aster福利：https://www.asterdex.com/zh-CN/referral/9C50e2
链上电报（Telegram）社群：https://t.me/AiCoinWhaleData
链上社区：https://www.aicoin.com/link/chat?cid=N6OVMor5g
AiCoin链上推特：https://x.com/aicoinwhaledata
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到[email protected]，本平台相关工作人员将会进行核查。
