以太坊信标链给每个验证者发一个序号，这个名字和余额都要跟着编号记账的名单，从创世那天起就只做一件事：追加。新的公钥存款进来，名单尾部加一行；旧的验证者退出、提款、消失，那一行也不删除。时间一长，谁都不难看出问题——进出场的验证者像潮水一样轮换，名册却像账房先生用不完的流水纸，只会越来越长。EIP-6914在2023年4月给出的解法简单直接：已经全额提款、并且安全等待期已过的验证者索引，回收给新存款复用。提案由Lion与Danny Ryan执笔，状态停在Stagnant，从未激活。
名册膨胀为什么是个真问题
共识层规范要求每个验证者的余额和状态按索引存放，签名聚合、委员会抽签、罚没记录都要在名单上寻址。名单只加不减意味着状态量随累计存款次数线性增长，哪怕同一时刻活跃的验证者数量不变。这就是典型的”账本比生意大”：活干的是那么多，账页翻得停不下来。提案把动机写得毫不含糊——消除验证者列表随人员轮换而无界增长的担忧。
回收要跨过的三道安全门
不是退干净就能马上把工号发给下一个人。规格要求两件事同时成立：旧主人已经完成完全提款，且处于可提款状态足够久——“足够久”的具体参数放在共识层规范里定，提案文本本身不锁数字。安全考量章节专门讨论过复用带来的攻击面：提款凭据、签名语境与旧索引的历史纠缠，必须等时间把这些尾巴全部晒死，新主人才能接手工号。设计上这是共识层的变化，执行层不需要任何改动，一笔存款怎么进、怎么排队的流程一概不变。
它为什么没有往前走
回收索引省的是状态空间，而验证者索引还被写进历史证明与各类客户端实现，动的每一处都要跨规范、跨客户端做兼容性排查。同期社区对状态膨胀的注意力也更多放在数据可用性和历史过期这些主干上，6914就随一批共识层小提案一起进入了停滞名单。它没有被正式否决，但也没有被排进任何升级——按EIP流程，半年没有活动自动转Stagnant。
快速问答
问：验证者索引现在还在无限增长吗？ 答：是。现行机制仍只追加，名册长度反映的是历史累计入场数，而不是当前活跃验证者数。 问：索引复用会不会影响”一个索引对应一笔质押”的直觉？ 答：会引入时间维度——同一编号在不同时代可能属于不同公钥，读历史数据时要按epoch而不是按编号认人。 问：它和Pectra的合并、最大有效余额有关吗？ 答：没有直接关系，那是余额上限与 Consolidation 规则；6914只管编号回收这一本账。
一笔对照账
给名册膨胀做个最简算术。假设某段时间里平均每天有一万名验证者完成完全提款离场，同时有一万名新人存款入场。在只追加的规则下，名册长度每天净增一万行，一年就是三百六十多万行——即使活跃集稳稳不动，账页依旧日日上新。在6914的规则下，只要新人赶上了旧编号的安全等待期，名册长度就围绕活跃集规模上下起伏，长期不再趋势性上涨。这中间的差额不是抽象数字：验证者列表要参与委员会抽签、要跟着轻同步协议传给资源受限的设备，每一行都对应签名聚合与状态读取的实打实成本。当然回收不是免费的午餐，等待期设多久、复用边界怎么划，正是这份提案从草稿到停滞始终没算完的那道题。
风险提示：本文讨论共识层提案，不构成投资建议；质押参与决策请以当前生效的协议规范为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。