Lido 以太坊验证者退出政策

zHYFZr4eRGm3Ju9_vkcSgQ? 发布于 2026-07-25 阅读 22

文章介绍了以太坊验证者的两种退出机制(自愿退出和强制退出),并提及了未来可能的可触发退出方式。随后详细阐述了Lido以太坊协议的验证者退出政策V1.0:包括退出目标(满足提款、重新分配质押、轮换密钥)、适用范围、校验者退出顺序的确定性规则、节点运营商的责任(通过Key API、Validator Ejector等工具及时处理退出请求),以及监控和惩罚措施(延迟和违规状态、奖励减半、停止分配新质押等)。此外,还规定了异常退出和业务连续性的处理方式。整体为Lido的staking机制提供了明确的退出流程和责任划分,确保用户提款需求能及时得到满足。

3年前更改3年前更改

Lido on Ethereum 验证者退出政策

STATUS: V1.0

A. 背景

以太坊验证者退出机制

目前,以太坊验证者有两条退出路径。第一种是主动退出(voluntary exit),验证者可以提交一笔主动退出交易到信标链,从而选择主动停止履行职责(提议区块和对区块进行证明)。第二种是协议强制驱逐——可能由罚没(slashing)或有效余额不足(当前阈值为 16 ETH)触发。此外,以太坊社区正在讨论引入第三种退出验证者的方式,即基于提款凭证触发验证者退出的机制。

主动退出(Voluntary Exit)

验证者可以发起主动退出,前提是当前处于活跃状态、未被罚没,并且已活跃至少 256 个 epoch(约 27 小时)。具体做法是使用验证者密钥签署一条“主动退出消息”(VEM),并将其广播给共识层客户端(或直接通过 API 等方式)进行处理。一旦验证者的退出消息被处理,该验证者将进入退出队列。发起主动退出后,验证者应继续履行职责,直到成功退出,以避免产生任何处罚。当验证者到达退出 epoch 后,它将停止履行职责,不再获得奖励或受到惩罚(进入“可提款”状态)。进入可提款状态后,验证者需要等待其索引被提款扫描操作解析,才能将余额提取到指定的执行层 0x01 提款凭证(请注意,使用 0x00 提款凭证的验证者需要轮换为 0x01 才能处理提款,否则将被跳过)。

强制退出(Forced Exit)

强制退出与本政策文件的目的无关,但可能因验证者被罚没或有效余额低于 EJECTION_BALANCE 阈值(当前为 16 ETH)而发生。

可触发的退出(Triggerable Exit)

以太坊社区已经提出了一些功能建议,允许(来自执行层的)提款凭证发出信号并启动相关验证者的退出。此类功能将为质押解决方案提供更强的保障,确保验证者能够及时有序地退出,同时也可作为针对恶意或表现不佳的节点运营商的潜在反制措施。然而,其缺点是,可触发的退出需要承担链上 Gas 成本,而这类成本在共识层侧并不存在——这使得它在一般验证者退出场景中不如共识层发起的退出方式合适(而且它也不是万能药,因为验证者在退出队列中仍可能行为不当)。一旦/如果可触发退出在以太坊上可用,本政策将需要更新,以详细说明协议如何以及可以在哪些情况下使用它们。

B. 政策

B.1 目标

验证者退出可被包括 Lido 在内的功能完备的质押协议用于以下目的:

  • 满足用户的提款赎回请求(例如,当提款请求大于仅通过部分提款/扫款可释放用于赎回的质押金额时)。
  • 出于多种原因(例如表现不达标、节点运营商集合策略中的指导原则),在运营商集合中重新分配质押(将质押从一个运营商转移到另一个运营商)。
  • 在不改变质押分配的情况下轮换某些验证者的签名密钥。

拟议中的 Lido on Ethereum 协议 V2 升级将引入一系列基于链上信号的机制,用于在需要处理验证者退出时通知参与协议的节点运营商。

B.2 范围

本政策适用于 Lido on Ethereum 协议、参与“精选节点运营商注册表”(“节点运营商”)的节点运营商,以及他们作为协议一部分所运营的验证者。精选注册表之外的验证者目前不属于本政策范围,但可能会在后续修订中被纳入。

B.3 政策声明

B.3.1 验证者退出顺序

Lido on Ethereum 验证者(即已提交到 Lido 节点运营商注册表并完成存款的验证者)的退出顺序应当是确定性的,以便在需要时能够独立且无需信任地计算得出。目前提出的退出顺序方案是相关主题 “提款:关于验证者退出顺序” 中讨论的“组合方法”。

B.3.2 随时间推移的性能预期

由于这是一项涉及以太坊协议新功能的新政策,本政策第一版中提出的强制执行机制、服务水平预期及相关时间窗口都较为宽松,以便在不施加不合理处罚的情况下解决初期问题。一旦验证者退出自动化相关的流程和机制成熟,本政策应进行修订。特别是,应进一步收紧服务水平预期的时间窗口,并提高对未达标行为的处罚力度。

B.3.3 节点运营商的职责

参与 Lido on Ethereum 协议的节点运营商有义务按照协议(由 DAO 设定)的要求和规则,及时且正确地退出验证者。如果协议出于 “B1-目标” 部分所述的任何原因,并根据 DAO 批准的验证者退出顺序,通过预言机或退出守护进程基础设施发出信号,请求其退出验证者,则节点运营商应执行相应操作。

为了确定节点运营商是否妥善执行了所需操作,本政策旨在明确节点运营商的执行时限,以及不符合要求时应受到的处罚。

一般而言,节点运营商应在合理的时间范围内退出被指示的验证者。验证者退出的具体机制由节点运营商自行决定,同时将提供开源工具,帮助节点运营商识别已发出信号的验证者退出请求以及处理这些请求。

该工具集应包含以下三个组件,节点运营商可使用这些组件以半自动或全自动方式处理验证者退出请求。节点运营商也可以选择使用以下任一模块的自定义实现(例如,采用即时(JIT)方式生成 VEM,而非预先生成一定比例的 VEM)。

  • Keys API(KAPI)服务 - 由节点运营商托管的一项服务,加载运营商的公共验证者密钥,计算下一个需要退出的密钥,并可接入其他工具(例如 eth-do、用于 web3 signer 的自定义脚本等),以自动生成和签署待存储的 VEM(作为预签名消息),供 Validator Ejector 使用。
  • Validator Ejector - 一个守护进程,监听 Exit Bus Oracle 报告,为待退出的验证者定位预签名(或获取 JIT 签名)的退出消息,并处理验证者退出请求(即向 CL 提交 VEM 以供广播)。
  • Exit Bus Oracle 报告 - Lido Oracle 的一个子模块,每天多次在链上结算一份报告;该报告指示各节点运营商应退出哪些验证者,并构成验证者退出请求的信号。

验证者退出请求每天多次通过链上 Exit Bus Oracle 报告向所有节点运营商发出信号。节点运营商有义务建立基础设施,以捕获已发出信号的验证者退出请求,并尽快处理相关(即涉及其验证者的)请求。

为清晰起见:

  • 一旦验证者退出请求可以从链上 Exit Bus Oracle 报告中检索到(该报告每天多次在链上最终确定),该请求即被视为“已发出信号”。
  • 一旦验证者退出请求被广播到 CL,并被包含进信标链的一个被提议区块中,该请求即被视为“已处理”。
  • 一旦验证者已完全退出并完成提款,该请求即被视为“已完成”。
B.3.4 监控与处罚

此外,还将提供另一个名为“Monitor Daemon”的工具,用于将已发出信号的验证者退出请求与信标链上已处理的退出进行核对,以确定验证者是否及时退出。监控结果将公开发布,以便 DAO 能够获得所需数据,了解验证者退出的速度、流程和有效性。

尽管该过程在很大程度上可以实现自动化,但考虑到基础设施、工作时间和机制时序的差异,以下是节点运营商必须遵守的验证者退出服务水平要求。

如果节点运营商在信号可用时立即处理已发出信号的验证者退出请求,那么验证者退出请求从“已发出信号”到“已处理”的最短时间将在几分钟到一小时的范围内。就验证者退出表现而言,每个节点运营商都可能被认定为以下三种状态之一。

  • 状态良好 - 验证者退出请求得到完整、正确且及时的处理。
  • 延迟 - 验证者退出请求处理不完整、不正确,或未在期望的时间范围内完成处理。
  • 违约 - 验证者退出请求处理不完整、不正确,或未在最大可接受的时间范围内完成处理。
事件 不被视为“延迟”的要求 不被视为“违约”的要求
处理已发出信号的验证者退出请求 所有已发出信号的请求均尽快处理(不超过 1 天) 部分已发出信号的请求需要超过 1 天但少于 4 天才能处理完
上报无法执行已发出信号的验证者退出请求并说明原因 尽快,但不超过 1 天 尽快,但不超过 4 天

如果节点运营商未能及时处理验证者退出请求,则应采取以下措施:

  • 如果节点运营商状态为“延迟”,NOM 工作组将向该节点运营商提出问题,并要求其采取补救行动。
  • 如果节点运营商状态为“违约”,NOM 工作组将在 Lido 研究论坛上正式向该节点运营商提出问题。当节点运营商处于“违约”状态期间:
    • 将不再向该节点运营商分配新的质押(这将自动发生);
    • 发送给该节点运营商的每日奖励将减半(剩余一半将用于当天的 rebase)(这将自动发生)。削减后的奖励将在冷却期内持续,该冷却期的时长足以确定该节点运营商恢复服务后,随后收到的验证者退出请求能否得到及时处理。
  • 如果节点运营商状态为“延迟”或“违约”,Exit Bus Oracle 将假定该节点运营商无响应,并把新传入的验证者退出请求重新路由到未被认定为“违约”或“延迟”的运营商。由于验证者退出请求会被重新路由,DAO 应考虑(通过临时投票)覆盖相关节点运营商的活跃验证者总数限制,以便该节点运营商在恢复“状态良好”时,不会以牺牲接管了被重新路由退出请求处理工作的其他节点运营商的利益为代价而受益。
  • 一旦违约节点运营商处理完所有已发出信号的验证者退出请求(因而其在下一份 Accounting Oracle 报告中的违约验证者数量更新为 0),它将重新开始接收验证者退出请求。其状态将在 5 天后恢复为“状态良好”(前提是任何新收到的验证者退出请求都得到及时处理)。在这 5 天的“冷却期”内,它仍将不会获得新的质押,并继续获得减半的奖励。
  • 在最严重的情况下(例如持续数周的违约),DAO 可考虑通过链上投票来“停止”该节点运营商,其效果是将该运营商获得的费用设为零(DAO 可随时考虑此类投票)。如果该节点运营商对 DAO 的请求无响应,则其将被视为实际上已从“精选节点运营商注册表”中“退出”,DAO 应采取进一步步骤,正式确定该节点运营商的退出。

如果节点运营商因任何原因无法退出某个验证者(例如丢失了与该验证者相关的私钥),则其应通过提供该验证者的最大不可追回余额(即 32 ETH,因为超出该数额的部分可通过部分奖励获得)来补偿质押者。这样做会使该验证者被视为“不可恢复且已补偿”,并且,在评估该节点运营商的验证者退出请求状态时,这不会被视为违规。

B.3.5 乱序退出与节点运营商的业务连续性
乱序退出

乱序退出(Out of Order exits)是指节点运营商在 Lido 协议未对某个(组)验证者发出退出请求的情况下所执行的退出。在处理此类退出时,节点运营商必须通过 Lido 论坛(https://research.lido.fi)通知 DAO:此类退出已被处理,涉及多少验证者、哪些验证者已被退出,以及退出的原因。

业务连续性及其他考虑

如果节点运营商在任何时候无法继续参与 Lido on Ethereum 协议(例如已资不抵债),则其必须通过 Lido 论坛(https://research.lido.fi)将情况通知 DAO,并表明其打算退出其作为协议一部分运营的所有验证者。如果 DAO 未在 8 天内通过经批准的投票另行指示该节点运营商,则其必须着手触发所有验证者的退出。

  • 原文链接: hackmd.io/zHYFZr4eRGm3Ju...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~

相关文章

0 条评论