原文标题：《Understanding Withdrawals》by Jim McDonald
原文翻译：John, ECN
提款 (withdrawals）是验证者生命周期（validator lifecycle）中缺失的一部分，从 2020 年 12 月以太坊共识链一开始启动以来就在开发当中，现在将随上海升级而来。由于上海升级将在今年上半年启动，所以值得注意和理解什么是提款，其工作机制，以及这个新特性的使用方法。
历史
当共识链第一次在 2020 年 12 月启动时，你无法从共识链上发送任何信息到执行链上去。也就是说，尽管余额能在共识链上累积，你也无法通过执行链去提现，因为技术上在当时提款是不可能的。经年累月过后以太坊的结构已经被改变得可以容纳新的研究成果，转变为当前以 layer 2 为中心的扩容模型，并且很大程度上保持了执行链的原貌。在 2022 年的 9 月，执行链与共识链合并了，执行区块变成了共识区块里数据的一个子集。这时信息从共识链上转移到执行链上就是可行的了，其中一个例子就是验证者奖励。
你可以在”理解合并后的奖励“（”Understanding post-merge rewards”）一文中找到共识链和执行链互动以及合并的区块如何构建的详细细节。关键点在于只有在合并之后提款才变成可能。
验证者在做些什么？
自从 2020 年 12 月的共识链创世以来，验证者一直在产生区块并维护链的安全。具体来说，他们一直在提议新的区块，并参与对它们自己和其他验证者提议的区块的投票（注解 2 ）。当被正确执行时，这些行为会为验证者带来奖励。共识链启动时只有 2 万多名验证者，但在笔者撰文时已经约有 52 万名活跃的验证者在确保其安全性。从 2020 年 12 月 到 2022 年 9 月，共识链只维护了其自身的安全，但是这为合并的到来铺平了道路（注解 3 ），从 2022 年 9 月之后执行链就已经仅由验证者们保证其安全性。
为了回报他们维护区块链安全性的行动，这些验证者被许诺以根据以太坊协议直接产生的奖励，这些奖励被记录在共识链上。
验证者的奖励怎么样了？
因为共识链本身没有执行能力，所以积累在上面的 ETH 无法从一个账号被转移到另一个。确实共识链甚至没有账户的概念，链上唯一有余额的实体是验证者本身。这意味着这些验证者的奖励虽然在过去两年稳定增长，但是却没有提取它们的方法。
在所有验证者中，共识链已经产生了超过 1 百万的 ETH 作为累计的奖励。 就个人的验证者而言，他们的奖励取决于一系列的因素，但最明显的莫过于他们作为活跃验证者的时间。有很多验证者已经积累了一笔数量巨大的奖励：
大多数验证者获得了只有少于 2 个 ETH 的奖励， 有些高达 5 个 ETH，尽管这些奖励被登记在在共识链上，但是它们无法在执行链上被实例化，直到提款的功能就位。
注意，自从合并之后，除了上述的奖励，提议区块的验证者会获得一部分交易费。这些费用会直接在执行链上被支付，因此下文不会再论述它们。
上海升级改变了什么
上海升级（注解 4 ）提供了一个从共识链上转移奖励到执行链上的机制，每一个执行区块都会包括大约 16 次把 ETH 转移到执行链账号上的提款（注解 5 ）的数据。提款有以下数据结构：
图表 3 ：一笔提款
一笔提款的单个组成部分分别为：
提款索引（Withdrawal index） 提款的唯一标识符，便于引用。
验证者索引（Validator index） 共识链上一笔提款来源的验证者的索引
地址（Address） 提款将会被汇集到的地址
数目（Amount） 将会被添加到账户的 ETH 数目，单位是 Gwei（注解 6 ）
当区块被导入到执行链中时，提款将会根据给定的数量进行处理，相应地址的余额会增加。注意提款不是交易，它们不消耗 gas，它们也不会在提现地址触发任何智能合约的操作。一旦区块被处理完毕，相应的余额将会增加，但不会再有其他的事情发生。
被提款的 ETH 是从哪里来的？
上述的信息描述了什么是提款，但是提款发生时的 ETH 是从哪来的呢？
尽管一个验证者的信息被创建时，需要向以太坊存款合约存入 32 个 ETH，但是不能以提款为目的访问这些 ETH，因为合约里没有任何允许代币转移的机制。这些账目总和的使用也最终会导致合约出现负的余额，因为现在验证者的在共识链上的余额总和超过了一开始存款的总和。
提款是用根据以太坊协议产生的资金（即新增发的 ETH）来支付的，而不是从已有的账户上转移。这保证了提款可以一直被支付，即使从共识链上提出的总数目高于存入的总数目。
提款时钟
在内部，共识层的软件持有一个存有验证者信息的简单列表：
每一个验证者实体的独立组成部分分别为：
索引（Index） 对应这个验证者及其列表内位置的唯一索引
状态（State） 目前这个验证者的状态，比如“活跃中”或“退出中”（注解 7 ）
余额（Balance） 目前该名验证者的余额，单位为 Gwei
提款凭证（Withdrawal credentials） 该名验证者的提款凭证
上述这些概念大多数都是不言自明的，然而提款凭证却需要一些解释。每一个验证者都有一组提款凭证。这些凭证控制了共识层资金的流向，包括初始的存款和接下来的奖励。
目前有两种提款凭证：
从 BLS 公钥产生的，被称为“type 0 ”提款凭证
从执行地址产生的，被称为“type 1 ”提款凭证。
我们待会再来详细地探索这些概念，但是，目前的重大区别在于，type 1 的提款凭证允许共识资金被提款到执行链上去，而 type 0 提款凭证不行。
共识链按顺序处理提款，从索引 0 开始一直处理到某一集合中最后那个索引，然后再从头开始。你可以用一个单指针的模拟时钟作为类比提款进程的一种思考方式。 每一个钟上的刻度代表一个验证者，从验证者索引 0 开始到最后那个（目前大概是 52 万个）。
图表 4 提款时钟
一旦上海升级上线，区块就会包含提款信息。为了选择哪些验证人可以提款，时钟指针围绕验证人转动，每当它指向一个有资格提款的验证者时，该名验证者的部分或全部余额将根据以下规则被提出：
如果验证者拥有 type 1 凭证，并处于 ”活跃“ 状态（注解 8 ），并有超过 32 个 ETH 的余额，那么超过 32 个 ETH 的部分会被提出。
如果验证者拥有 type 1 凭证，并处于 “可提款” 状态，余额不为 0 ，那么剩余的所有余额都会被提出。
如果上述其中一条规则适用，就会有一笔提款产生并被添加到区块里；如果上述两条都不适用，那么验证者就会被认为不符合条件，指针会继续往下走。指针会继续跳动直到它找够 16 个符合条件的验证者（注解 9 ），这时单个区块所需的提款笔数足够了，提款信息就会被包含进区块中。
时钟指针走完一轮的时间取决于符合资格的验证者数量。
在笔者撰文时有大约 520, 000 名验证者处于活跃状态。若每个区块有 16 笔提款，每天 7, 200 个区块，则每处理一轮符合资格的验证者集将需要大概 4.5 天。但正如上图所示，这个时间将随着符合资格的验证者数量改变而改变。
修改提款凭证的过程
正如上文所述，要成为符合资格的验证者必须拥有 type 1 的提款凭证。笔者撰文时有大概 40% 的验证者拥有 type 1 的凭证，其余的则拥有 type 0 凭证。上海升级会带来从 type 0 升级到 type 1 提款凭证的能力，如此验证者便能接收奖励。修改提款凭证需要创建一个在共识链上广播的签名操作。这个操作的结构如下图：
图表 6 ：修改提款凭证的操作
操作的组成部分分别为：
验证者索引（Validator index） 该操作所适用的验证者的索引
提款的 BLS 公钥（Withdrawal BLS public key） 目前 BLS 提款凭证的 BLS 公钥
执行地址（Execution address） 用于新提款凭证的执行地址
签名（Signature） 由当前 BLS 提款凭证的私钥在操作的其他字段上所作的签名。
信标链上的操作过程如下：
“就每一个被验证者索引所定义的验证者而言，检查给定的 BLS 公钥是否可以转换为匹配当前验证者的 type 0 提款凭证。若可以，则把给定执行地址转换成 type 1 的提款凭证并为验证者更新。”
因此，修改凭证的操作只能发生一次。 一旦修改凭证的操作被处理完毕，链上验证者的定义就会包含 type 1 提款凭证，所以就据上文所述就没有 type 0 提款凭证可供匹配了。也就是说，type 1 凭证一旦被设定就将在其生命周期内保持不变。（注解 11 ）
选择执行地址
修改提款凭证的第一步就是选择用来接收提款的以太坊执行地址。正如上文所描述的，你只能作一次改变，所以你必须保证你在做设置之前已经确保了地址私钥的控制权。若你有多个验证者身份那么你需要考虑是否要为每一个验证者身份提供一个不同的提款地址，或者为所有的验证者身份使用相同的地址：
设置相同的地址方便了你，奖励会更快地累积到这个地址去，因此消耗的 gas 会更少。
设置不同的地址，保持它们互不关联则增加了你的验证者身份的安全性，若这些验证者身份本身就是互不关联的（不同的储蓄地址，不同的或者本来就没有的区块提议涂鸦等）
创建操作
一旦执行地址被选定，则需要为每一个验证者创建并签署一个操作。由于暴露与提款凭证相关的私人信息的敏感性（可能是私钥或者助记词），我们推荐离线创建。操作方法超出了这篇文章论述的范围，但你可以参考使用 ethdo 工具这么做的详细指南，或者使用未来其他可用的工具和向导。
广播操作
在创建操作之后，你需要把它们广播在共识链上。若操作是在上海升级之后才被提供给共识节点的，那么它会在下一次机会被广播到网络中以打包进区块。若操作是在上海升级之前被提供给共识节点的，那么它会被储存起来并在升级完成后被广播到网络。注意这需要你连接到一个可以识别上海升级的共识节点上；就目前来看这些共识节点预计将在 2 月的某个时候可用，为主网升级提供了良好的时机。
在线/离线 进程
正如上文所述，创建凭证修改操作应该在离线状态下进行。这避免了提款的私钥被暴露给不安全的电脑从而导致私钥被窃取的情况。然而，访问一台在线的电脑需要从信标节点上获取信息，并最终广播凭证修改操作。因此，我们推荐用一个在线/离线的进程来创建并广播修改操作。
图表 7 ：在线和离线的配置中创建和广播修改提款凭证操作
有不少的工具都遵循这个过程，比如 ethdo 就有他们自己的文档交代如何进行这个过程，下文是每一步的概览，讲述其作用和意义。
1.获取链上信息
要创建有效的已签名的凭证修改操作，你需要从链上获取不同的信息，这些信息应该从链本身获取以保证是正确的信息。我们同样推荐获取一份包含目前所有验证者信息的列表。因为这样可以更容易地创建操作，同时验证创建的操作是否适合验证者。
这些信息来自一个活跃中的共识节点，因此需要从一台联网的电脑上获取这些资料。大多数运行验证者程序的实体应该都有访问共识节点的权限，但是如果它们将质押过程委托给一个服务商，那它们应该设法从服务商获取必要信息。
这将产生一份包含链上信息的文件。文件本身不会带有私钥或其他敏感信息。
2.转移链上信息
一旦链的信息被收集完成，那就需要把它从一台在线的电脑转移到一台离线的电脑。目前的普遍做法是通过 USB 存储，USB 存储允许两台电脑不需要直连就能完成信息的转移。这意味着离线的电脑可以完全与互联网断开连接，极大地增加了私钥或者助记词的安全性。
3.创建凭证修改操作（Credentials Operations）
一旦离线的电脑上有了链的信息，那就可以进行凭证修改操作的创建了。这要求对创建了目前提款凭证的助记词和私钥的访问权，所以在离线的电脑上运行这个进程更加安全。
私钥和助记词有可能创建了多个验证者的凭证，因此创建进程可能会产生多个修改操作。
这会产生一个包含了修改凭证操作的文件，文件自身不会包含私钥或者其他敏感信息。
4.转移凭证修改操作
一旦凭证修改操作的文件被创建完成，就需要把它从离线的电脑上转移到在线的电脑上。再说一次，USB 存储或类似的方式是普遍的最优做法。
5.广播凭证修改操作
一旦在线的电脑上有了凭证修改操作的文件，就可以通过将这些操作发送到某个共识节点来向以太坊网络广播。最有可能是发送到下载链信息回来的那个节点上。
一旦操作被提交到共识节点上，节点就会把它们在全网范围内广播，一旦共识区块打包了这些操作那么修改就会随之生效。每一个区块都有容纳 16 个修改操作的空间， 所以有可能需要 4 天才能让一个操作被添加到一个区块里去，但是更有可能的是 1 到 2 个小时就可以添加。
总结
提款功能将随着上海升级推出，自从共识链启动以来第一次使用户的共识奖励变得可用。一旦设置好之后，它们就会自动地为任何验证者所用，而升级也带来了一个机制来配置那些尚未准备好提款的验证者。
验证者生命周期完成之后，共识链就履行了对质押者们从 2020 年 12 月以来许下的承诺，并准许验证者离开这个他们此前觉得可能离开不了的系统。额外的验证者将为以太坊带来更强的安全性以及一条更强大的链。
1.以太坊有多条链，通常被称为共识链（或称信标链）和执行链，欲了解更多信息请参考文章”理解合并后的奖励“。
2.他们同样参与到同步委员会中，但这些都是见证的另一种形式。
3.就是用俗话解释以太坊从工作量证明共识机制到权益证明共识机制的迁移。
4.与共识链上的 Capella 升级同时进行。
5.严格意义上最高可以达到 16 笔提款，除极端情况外，所有 slot 都应该是满的。
6.共识链上的所有数值都是以 Gwei 为单位的，因此从共识链到执行链的任何代币转移都是一个以 Gwei 为单位的整数。
7.状态实际上来自验证者信息中的其他字段，所以它不会呈现在验证者的定义里，但是由于它在文章其他地方被引用了，所以把它展示在这。
8.“活跃中”和”可提款“的状态定义可参考文章“理解验证者生命周期”
9.在 16384 名验证者之后提款时钟的指针就会停止跳动，即使找不够 16 名符合资格的验证者，尽管这种情况不太可能在测试网以外发生。
10.笔者撰文时这个数字实际上大约是 7160 ，因为一些区块没被提议或者在提议后变成了孤块。
11.这可能随着新的操作的引入而在未来改变，但在笔者撰文时尚无这样的计划。
12.预计在升级后的头几天会有一波验证者修改他们凭证的初始高峰期，在这之后排队的人将会很少，因为大多数符合资格修改凭证的验证者都已经修改完。
点击“阅读原文”获取文章内部链接！
原文链接：https://www.attestant.io/posts/understanding-withdrawals/
