x
知道了流失限制和在利润验证器之前要退出的验证器的数量，就可以计算出来退出队列的总持续时间（以天为单位）：在验证器被退出之后，在它被完全提款之前，还有两个步骤： 已退出的验证器在其状态从已退出更新为可提款之前，还要经历 256 个历时（27.3 小时）的延迟，称为最小验证器可撤回性延迟。最后，可提款的验证器也要接受处理部分提款的自动「扫荡」，随后其余额被提取。 完整的提款率限制 如上所述，所有退出的验证器必须等待 256 个历时（27.3 小时或 1.1 天），直到他们变成可提款的。一旦验证器可以提款，处理全额提款的速度被限制在每档 16 个提款，由处理部分提款的同一自动「扫荡」程序进行。 因此，下面的表达式给出了任何退出的验证器在它的余额被完全提取之前应该等待的最大时间（以天为单位）： *Max. Time from Exit to Withdraw (days) (((withdrawals_eligible_validator_count/16)12)/60/60/24) + 1.1 days 其中「withdrawals_eligible_validator_count」是...
x
知道了流失限制和在利润验证器之前要退出的验证器的数量，就可以计算出来退出队列的总持续时间（以天为单位）：在验证器被退出之后，在它被完全提款之前，还有两个步骤： 已退出的验证器在其状态从已退出更新为可提款之前，还要经历 256 个历时（27.3 小时）的延迟，称为最小验证器可撤回性延迟。最后，可提款的验证器也要接受处理部分提款的自动「扫荡」，随后其余额被提取。 完整的提款率限制 如上所述，所有退出的验证器必须等待 256 个历时（27.3 小时或 1.1 天），直到他们变成可提款的。一旦验证器可以提款，处理全额提款的速度被限制在每档 16 个提款，由处理部分提款的同一自动「扫荡」程序进行。 因此，下面的表达式给出了任何退出的验证器在它的余额被完全提取之前应该等待的最大时间（以天为单位）： *Max. Time from Exit to Withdraw (days) (((withdrawals_eligible_validator_count/16)12)/60/60/24) + 1.1 days 其中「withdrawals_eligible_validator_count」是...
每个周期（每 6.4 分钟）可以退
图 3 描述了退出一个活动验证器所需的高级步骤。让我们简单地来谈谈每一个步骤。 一个活跃的验证器，具有 0x01-类型提款凭证，按照预期提出并验证块。验证者的私钥被用来签署自愿退出（VE）操作，而已签署的 VE（通过 CL 客户端）提交给以太坊的 CL. 每个时段最多处理 16 个 VE（每 12 秒）。一旦 VE 操作被处理，并且经过至少 5 个历时（32 分钟）的延迟，验证器的状态就会从激活状态更新为退出状态。在这一点上，退出的验证器被分配了一个退出历时（即验证器将被退出的历时），并正式进入退出队列。虽然验证器现在已经发出了退出的信号，但它仍然必须执行所有验证器的职责（即区块提案和证明），直到它通过退出队列被处理。退出队列的长度取决于活跃的以太坊验证器的总数和已经在队列中的验证器的数量。在验证器通过退出队列处理后，其状态从正在退出更新为已退出，并停止验证区块。 验证器退出率的限制 由于一些原因，重要的是 PoS 协议的验证器集别变化得太快。因此，验证器的退出受到退出队列的速率限制。退出队列的持续时间是协议的流失限制的函数，以及在感兴趣的验证器之前要退出的验证器数量。 Chur...
每个周期（每 6.4 分钟）可以退
图 3 描述了退出一个活动验证器所需的高级步骤。让我们简单地来谈谈每一个步骤。 一个活跃的验证器，具有 0x01-类型提款凭证，按照预期提出并验证块。验证者的私钥被用来签署自愿退出（VE）操作，而已签署的 VE（通过 CL 客户端）提交给以太坊的 CL. 每个时段最多处理 16 个 VE（每 12 秒）。一旦 VE 操作被处理，并且经过至少 5 个历时（32 分钟）的延迟，验证器的状态就会从激活状态更新为退出状态。在这一点上，退出的验证器被分配了一个退出历时（即验证器将被退出的历时），并正式进入退出队列。虽然验证器现在已经发出了退出的信号，但它仍然必须执行所有验证器的职责（即区块提案和证明），直到它通过退出队列被处理。退出队列的长度取决于活跃的以太坊验证器的总数和已经在队列中的验证器的数量。在验证器通过退出队列处理后，其状态从正在退出更新为已退出，并停止验证区块。 验证器退出率的限制 由于一些原因，重要的是 PoS 协议的验证器集别变化得太快。因此，验证器的退出受到退出队列的速率限制。退出队列的持续时间是协议的流失限制的函数，以及在感兴趣的验证器之前要退出的验证器数量。 Chur...
