EIP-7002：合并后对质押用户体验的改进

公共公告：这正式是《EIPs for Nerds》系列的第一篇文章——或者说是第二篇，如果你把关于ERC-7512：链上智能合约审计的表示的文章算上。你可以阅读EIPs For Nerds：让以太坊的研发变得可及以了解关于该命名和EIP系列的理由的背景。

以太坊从工作量证明（Proof of Work，PoW）转向权益证明（Proof of Stake，PoS），即“合并”（The Merge），是网络历史上的一个关键时刻。除了通过减少碳足迹为以太坊的重塑形象提供了亟需的支持外，权益证明对于一个重要的长期目标至关重要：降低参与以太坊共识的门槛。合并将计算资源（挖矿能力）替换为金融资本，作为以太坊经济安全的基础——为任何人通过在信标链上质押32 ETH来盈利和轻松运行验证者节点开辟了机会。

虽然权益证明带来了好处，但仍有许多改进的地方。包括但不限于：

• 减少质押集中和验证者卡特尔化
• 最小化验证者的操作开支并激励单独质押
• 改善质押经济学和用户体验（UX）
• 提升委托和多方质押操作的简单性、安全性和去中心化

EIP-7002：执行层可触发的提款是一个新的以太坊改进提案（EIP），它解决了一些上述问题。该EIP引入了一个机制，使质押者可以使用提款凭证从信标链中提取验证者，而不依赖于验证者的签名密钥来触发提款操作——有效地将验证者的签名密钥与提款密钥解耦。

这种验证者签名密钥与提款密钥之间的“关注分离”具有一个关键的好处：通过使提款凭证能够保留对质押ETH的控制，在委托质押中减少信任假设。我将在本篇文章中探讨为何这个特性是必要的，并讨论EIP-7002的其他好处，尤其是对单独质押和DVT（分布式验证者技术）质押的好处。文章还将考虑在以太坊实施EIP-7002的一些潜在缺点。

让我们深入探讨吧！

设定场景：一个关于密钥、白手套和攻击的故事

如果你今天想质押ETH并验证信标链，你有两个主要选择：单独质押和委托质押；还有其他质押ETH的途径，但这些基本上是在上述选项之间的某种提款。单独质押是直接的：

• 将32 ETH存入信标链存款合约以激活一个新的验证者
• 生成执行验证者职责（验证交易、验证区块、聚合证明和提议区块）的密钥
• 设置验证者节点并同步执行层（EL）和共识层（CL）客户端
• 保持你的验证者在线并正常运作，以避免罚款

还有更多步骤（质押启动平台的验证者常见问题对潜在的验证者有很好的概述），但这大致是启动验证者最重要的方面。重要的是，单独质押不需要中介或对方，并允许你保留从信标链验证中收到的100%的奖励（对区块进行证明和提议区块）。但这并不是一顿免费的午餐：你有责任管理你的验证者，并需要一定的技术专长来运行单独的质押操作。

如果管理验证者的想法听起来很困难，你可以选择委托质押的路径。你仍然负责提供32 ETH来注册一个新验证者——只不过现在，你将运营验证者的责任委托给第三方。验证者节点操作员提供了某种人们会称之为“白手套服务”的服务，并需要对此服务进行补偿。例如，你可能需要与节点操作员分担部分验证者奖励，作为初步协议的一部分。

“白手套”的部分意味着操作员负责保持你的验证者在操作和安全——这意味着你可以像在周五晚上看Netflix一样（或无论你在空闲时间做什么），而不必担心因为错过验证职责而被罚款或担心验证者密钥的安全。

不过有一个警告：委托质押需要信任节点操作员，以避免通过犯下可罚行为（例如，签署两个冲突的区块）或直截了当地窃取你的资金，将你的32 ETH置于风险中。这要求很高——绝对不是对信任有问题的人适合的安排——但当节点操作员诚实时，这种安排大多数时候运作良好。

但以太坊并不是建立在web2的“信任我，兄弟”这种理念上，这就是你在 crypto-Twitter 和 Reddit 对话中经常看到“无信任”和“无信任性”出现的原因。委托质押的最纯形式与这种理念相冲突，但在激活新验证者的过程中的密钥对生成方式提供了一种解决办法。

每个验证者都有两个密钥：提款密钥和验证者密钥。提款密钥是一个公钥-私钥对，用于根据你想要“提取”（只提取奖励）还是“退出”（提取32 ETH余额+奖励）的不同情况，部分或完全提取信标链验证者的余额。请注意，提款密钥必须从默认的BLS (0x00) 凭证更新为指向以太坊地址的 0x01 凭证，以便启用对验证者余额的部分或全部提款。

提款密钥是在存款时通过像质押启动平台这样的接口生成并哈希，以创建提款ID，并包含在验证者的存款数据中——这为信标链提供了关于谁存入32 ETH的信息。下图来自保护提款密钥的Attestant提供了提款密钥如何集成到验证者存款请求过程的很好概述：

提款密钥在验证者存款请求过程中的使用。（来源）

验证者密钥是执行每个以太坊验证者所期望的职责所需的公钥-私钥对——主要是在其他人进行投票和提议区块。验证者的公钥作为其在以太坊共识协议中的唯一加密身份，而私钥则应保持隐藏并用于签署区块数据（出于这个原因，验证者密钥也被描述为签名密钥）。

现在，验证者（签名）密钥和提款密钥之间的主要区别是：

验证者的签名密钥使用很频繁——每6.5分钟或者在每个选定进行证明或提议区块的时间段——最好保持在一个可以在线轻松访问的地方，比如热钱包。然而，提款密钥的使用频率较低，可以保存在安全的、离线的位置，比如冷钱包，直到质押者希望从与特定验证者相关的提款地址提取资金。

这个区别对减少委托质押设置中的信任假设至关重要：由于提款密钥不需要执行验证职责，质押者可以通过与节点操作员共享验证者密钥并保留提款密钥来控制质押ETH。这样，恶意操作员就无法在质押者未同意的情况下提取验证者的余额，从而逃之夭夭。

由质押者持有提款密钥的委托质押安排通常被描述为“非保管”，以反映代表质押者操作验证者节点的实体最终不会控制质押ETH。这与“托管”质押解决方案形成对比，其中质押服务控制签名和提款密钥；“强化的白手套服务”是一个不错的思维模型，用于理解托管质押：质押者简单地提供32 ETH来资助验证者，并将所有其他事情的职责，包括发起验证者存款请求和存储提款密钥，委托给质押服务。

将验证者签名密钥与提款密钥分离理论上解决了委托质押协议中的信任问题。在实践中，非保管质押设置中节点操作员与质押者之间的关系仍然有一 элемент信任，因为用于提取验证者并触发全额或部分提取验证者余额到提款地址的当前机制。

要从信标链中提取验证者，必须提交用验证者密钥签署的“自愿退出消息”（Voluntary Exit Message，VEM）以进行处理。一旦包含在区块中（每个区块最多可以包含16个提取请求操作），提款消息会被添加到提款请求队列——最终提款的延迟受到诸如排队提款的数量或验证者淘汰率等因素的影响。

以太坊上的验证者提款请求的高级概述。（来源）

我强调了需要用验证者的签名密钥签署自愿提款请求的要求，以突出现有“非保管”质押解决方案中的一个问题：质押者必须依赖节点操作员（控制签署VEM所需的验证者密钥者）来处理提款请求。这有效地重新引入了信任在节点操作员与质押服务之间的关系中；更糟的是，它使质押者面临被恶意节点操作员“攻击”的风险。

在攻击中，攻击者的目标是为其他方造成损失——并不一定直接受益。为说明此情境，考虑Alice委托Bob代表她运营一个验证者的情况，但后来决定提取她的32 ETH。Bob可以尊重Alice的请求并通过签署自愿退出消息（VEM）来触发提款请求……或者拒绝签署提款请求消息，使Alice的提款操作延误。Bob并不会因为拒绝Alice的请求而直接受益——他能做的只是只通过拒绝帮助Alice提取她的验证者，将Alice的ETH“绑架”。

好吧，这并不是100%准确；在这种情况下，Bob可以做很多坏事来造成更多的“麻烦”给Alice：

1. 通过故意犯下可罚行为或产生罚款来减少Alice的验证者余额。未执行验证职责（例如，缺少证明）或犯下可罚行为（例如，在同一时间段名称中签署两个冲突的区块）的个人处罚通常较低，但会随着在同一时期内发生类似违规行为的验证者数量的增加而增加。例如，缺少一两个证明会以微小的比例减少验证者的余额，但如果出现无效漏损——多个验证者在离线状态下——那么这种减少的提升将是指数级的。

在当前机制下，恶意的Bob可以通过蓄意减少故障和惩罚，使Alice的32 ETH验证者余额减少最多50%。如果我们使用1 ETH = $2,000的算法，Bob的攻击会使Alice损失至少$32,000（16 ETH）的正常情况下（没有相关的处罚）和$64,000（32 ETH）在最坏的情况下（即由于相关处罚可能被削减的全部余额）。

能摧毁事物的人，会控制事物。 — 保罗·阿特雷德（Dune）

2. 向Alice勒索赎金以交换不犯可罚行为。这与之前的攻击定义并不完全对齐，但考虑到如果Alice决定强硬对待，Bob唯一的补救措施就是燃烧ETH。所以，该情况与目标是以最小的损失盈利的更常见攻击类型有所不同。

注意：在这种情况下，Bob（节点操作员）实际上可能是诚实的，但对手可能会破坏验证者密钥并拘留Alice的ETH。这解释了“对方风险”的概念，质押作为一种服务（SaaS）平台的用户必须承受的另一原因是，单独质押——其“信任自己，不信任他人”的原则——被认测速为以太坊质押者的金标准。

这是否意味着每个非保管质押服务实际上并非真正的非保管？并不完全是。一个简单的变通方法是，质押服务提前签署自愿提款请求消息——最好是在验证者在信标链上激活后——质押者可以独立地向以太坊共识节点提交无论何时希望撤回的请求。

通过提前签署自愿提款请求为质押者准备，质押者与节点操作员之间的安排回归到原始的非保管状态。不过，预签乱码的信息因多种原因并不具有可持续性：

非保管质押的预签名提款请求问题

复杂性

预签名提款请求工作流程要求质押服务操作员与质押委托者之间进行更多的沟通：你必须提交请求以获取提款请求消息，并等待质押服务发送签名的提款请求。而使用和交换预签名的提款请求时，安全问题也是一方面：

• 质押服务必须采取额外措施——例如，加密提款请求消息并通过安全（链外）通信渠道共享——以防提款请求消息落入错误之手。
• 质押者必须采取额外的预防措施，将提款请求消息存储在安全位置，因此丢失提款请求消息相当于可能失去独立提取验证者余额的能力。

此外，当前预签名提款请求的有效期为两个以太坊分叉或~12个月——如果你预计每六个月就会发生一次分叉。这意味着质押者一年中可能需要多次向质押服务操作员重新提交自愿提款请求。如果在EIP-7044实施后，签名的验证者提款请求将无限期有效，则情况将不再如此。

EIP-7044解决了退出消息过期的问题，但引入了一系列新的问题——尤其是对于大型质押池。了解背景，目前在去中心化质押池中的做法要求新的验证者节点操作员在从池中获得资金之前提交预签名的提款请求。在这里，签名的提款请求提供加密经济安全，因为它减少了一个（不受信任的）操作员对验证者资金的影响；当一个不合作的验证者节点操作者时，质押池可以通过在链上提交预签名的提款请求来触发提款请求。

然而，不会感到舒适的是验证者节点操作员，如果预签名的提款请求被存储在一个随机服务器上，因为这会导致有人意外/故意触发虚假的提款请求，获取到签名的退出消息。在最坏的情况下，强制退出可能会导致验证者节点操作员遭受损失（例如，如果你根据未来的信标链奖励进行贷款）。这意味着质押池必须采取更多安全预防措施，确保存放提款请求消息的安全，尤其是在实施EIP 7044后，签名提款请求拥有无限到期日期的情况下。

一种潜在的解决方案是，用通过DKG（分布式密钥生成）协议生成的共享公钥加密签名提款请求，并要求关键份额的法定人数在提款请求可以被解密之前重新构造私钥。这减少了由一个方存储提款请求带来的信任假设，前提是没有一人能够控制足够的关键份额，在未征得其他参与者同意的情况下单方面解密预签名提款请求。但是如果一个或多个私钥份额丢失、失踪或被窃取，就会出现边缘情况——这使得在需要触发验证者提款时，解密签名提款请求变得困难，甚至完全不可能。

监管合规

质押服务受到了各种监管机构的密切关注，最引人注目的是由加里·根斯勒（Gary Gensler）领导的美国证券交易委员会（SEC）。例如，Kraken在今年早些时候关闭了其托管的质押作为服务的业务，并因“通过其加密质押平台提供未注册的证券”而支付了3000万美元的罚款。

理论上，非托管质押服务不太可能因为与质押者之间的非托管关系而落入SEC的陷阱：

1. 激活验证者的32 ETH（或32 ETH的倍数）存款来自由质押者控制的提款地址——协议将提款地址识别为32 ETH存款的拥有者。这意味着非托管质押服务不能提取验证者余额并与“客户资金”混合，如同SEC指控Kraken的那样。

在像Kraken这样的交易所，用户的资金余额是“虚拟”的，因为客户的所有资金都保存在由交易所控制的一个或多个钱包中。因此，如果你通过由交易所经营的托管质押服务质押32 ETH，你实际上获得的是交易所承诺在你希望提款时返还32 ETH（外加一定比例的验证者奖励）的债券。

2. 质押者可以通过提交预签名的退出请求独立提取资金，而不必担心恶意质押服务阻止提款。相较之下，托管质押服务——尤其是像Kraken这样的交易所——控制质押者的资产，并可能会因任意原因阻止提款。

这两个事实消除了“投资者保护”的需求；我不是政策专家，所以请原谅我在这个推理线条中的任何错误。不过，如果你今天经营一家机构非托管质押服务，可能仍然会有一些小的曲折：

• 在激活验证者和将预签署的自愿退出请求发送给质押者之间的短暂（或可能长）时间段内，质押服务控制着32 ETH——这使其在监管的眼中是“托管的”。进一步加剧问题的是，预签名退出请求的短到期日期（在EIP 7044之前）：从新退出消息签署到发送给质押者的过程中，验证者节点操作员对质押的ETH拥有某种控制。

• 虽然常规的退出消息将在链上广播并可公开验证，预签名的退出请求需要加密并通过私下的（链外）方式在节点操作员与质押者之间共享。这使得第三方如监管者更难以验证质押服务究竟是在初始的验证者存款协议中的确签署了退出意向——或者在原始退出消息过期后交换方是否再次出现（即，EIP 7004之前）。

总而言之：预签名的退出请求缓解了委托质押的一些问题，但还不足以使以太坊的质押成为无信任、安全和去中心化的。为了让“非托管”的概念重新回归非托管质押，我们需要一个更好的解决方案——而这得益于EIP-7002。在接下来的部分中，将详细介绍EIP-7002，并探讨该EIP的各种优势以及实施过程中可能出现的潜在问题。

EIP-7002的概述：执行层可触发的提款

EIP-7002解决了委托质押中的主要代理问题——质押者必须信任验证者节点操作员提前签署提款请求或处理未来提款请求——通过引入一种新自愿提款操作，可使用验证器的提款凭证触发。这使得质押者能够在不依赖持有验证者签名密钥的实体（即在委托质押设置中的质押服务）来处理提款的情况下，提取质押的ETH。

EIP-7002的关键特性是引入了一种状态化的验证者提款请求合约，该合约维护来自执行层的验证者提款请求的队列。在时间间隔内，若干提款请求将从队列中移除并添加到信标链区块的执行请求中。这允许来自执行层的提款请求“注入”到共识层并作为信标链操作的一部分进行处理——这类似于来自存款合约的存款如何从执行层传递到共识层进行处理。

提款请求是常规的以太坊交易，其验证者合约地址作为目标，表明提取验证者的意图（通过其公钥识别）。如果（a）它由与验证者执行层（0x01）提款凭证中引用的以太坊地址签名（b）要提取的验证者在信标链上处于活动状态，那么验证者提款消息是有效的。这些检查由共识层在提款请求到达信标链后执行；验证者提款请求合约只确认在质押者调用提款请求合约时，提款请求交易支付了足够的gas。

所有执行层的提款请求处理方式均与从共识层触发的常规自愿提款请求操作相同，这保持了对活跃验证者提款的最大允许提款请求数量的不变。EIP-7002在协议内部的机制，允许在执行层和共识层之间转移提款请求，也消除在触发提款请求时需要连接到共识节点的需求（这一点是提取预签名提款请求验证者所必需的）。验证者现在可以在同一执行层地址中得到资金并提取。

在观察了EIP-7002的总体工作原理后，我们现在可以深入探讨该EIP的更细节部分。接下来的部分将涉及EIP-7002的当前规范并讨论验证者提款请求机制的重要方面。如果你宁愿跳过技术讨论并探索实施EIP-7002的优点，你可以跳到下一部分——其中强调EIP-7002如何改善质押用户体验（UX）。

验证者提款请求操作

根据EIP-7002，验证者提款请求（在伪代码中定义为 add_withdrawal_request()）是对验证者提款请求合约地址的 CALL。调用验证者提款请求合约的交易字段有两个值：

• source_address：用于发起交易的提款地址的20字节值
• validator_pubkey：待提取验证者的48字节公钥值

在质押者用 validator_pubkey作为输入调用提款请求合约后，验证者提款请求合约将运行以下操作（我将在后面讨论此操作的关键部分）：

• 确认交易支付了足够的gas以涵盖 EXIT_FEE
• 为当前区块增加退出计数器（EXIT_COUNT）的值一
• 将退出消息插入队列
• 为当前区块增加未使用的提款数量（EXCESS_EXITS）的值一
• 退还调用者——如果他们支付了额外的gas——通过转交2300 gas（EXCESS_RETURN_GAS_STIPEND）

一个重要的细节：验证者提款请求合约不检查 source_address 是否是待提取的 validator_pubkey 的有效提款地址，也不检查 validator_pubkey。这就泄露了一个潜在的安全问题：如果攻击者用消息填满队列，而这些消息注定会失败；这主要是算是一种攻击，其目标是阻止合法提款请求的处理。EIP-7002通过对提款请求交易收取动态调整的费用来解决这个问题（提款费用机制将在后面讨论）。

每个区块的最大和目标提款

MAX_WITHDRAWAL_REQUESTS_PER_BLOCK

MAX_WITHDRAWAL_REQUESTS_PER_BLOCK 是可以包含在信标链块中的执行层提款请求的数量。此值当前设置为16，以反映信标链上的类似操作，如 VoluntaryExit（直接从共识层通过质押者的验证者密钥触发的退出操作）。

规范中还指出，将 MAX_WITHDRAWAL_REQUESTS_PER_BLOCK 设置为16限制了执行负载的大小，并由此限制了信标链区块的大小，减少了在共识层上处理退出操作的开销。这是有用的，因为我们预计一些质押者将继续使用当前的方法（即通过预签名退出或实时的自愿退出信息）来退出验证者。

TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK

EIP-7002理论上允许在区块中包含最多16个执行层退出操作，但目标是每个区块进行两个退出的更保守估计。根据规范， TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK 被设置为2，以限制验证者的更替率，并保持信标链get_validator_churn_limit()函数定义的每个周期最大的允许提款量的不变——即使在流通中的所有ETH被质押的情况下。

验证者提款请求队列

WITHDRAWAL_REQUEST_COUNT

WITHDRAWAL_REQUEST_COUNT是当前区块中包括的提款请求数量。在每次成功调用验证者提款请求合约后，保存在验证者合约存储中的 WITHDRAWAL_REQUEST_COUNT 变量的值增加1 (在伪代码中定义为 increment_count()).

在任何时候， WITHDRAWAL_REQUEST_COUNT 的值将位于 TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK（2）和 MAX_WITHDRAWAL_REQUESTS_PER_BLOCK（16）之间，具体取决于多少个提款请求操作被添加到区块的执行负载中。 WITHDRAWAL_REQUEST_COUNT 也是计算新提款请求操作需要支付的费用（MIN_WITHDRAWAL_REQUEST_FEE）的函数的输入。

EXCESS WITHDRAWAL REQUESTS

EXCESS_WITHDRAWAL_REQUESTS 是 MAX_WITHDRAWAL_REQUESTS_PER_BLOCK 和 TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK 之间的差值——当前区块未使用的提款请求数量。正如所提到的，每个区块最多可以包含16个提款请求，但在正常情况下，每个区块目标为两个提款请求，因此 EXCESS_WITHDRAWAL_REQUESTS 相当于“区块理论上能够消耗的提款请求数与实际使用的提款请求数之间的差额”。

提款请求合约的超额计数器根据上一个区块的使用情况更新，并且是确定调用验证者提款请求合约的交易需支付费用的因素之一。这保证提款费用根据当今的使用状况进行定价，类似于EIP-1559计算新区块的 base_fee 是基于目标gas限制与上一区块使用的gas之间的差异。

WITHDRAWAL_REQUEST_QUEUE

WITHDRAWAL_REQUEST_QUEUE 是当前存储在验证者合约中的所有待处理提款请求列表示（存储单元为 WITHDRAWAL_REQUEST_QUEUE_STORAGE_SLOT 作为 WITHDRAWAL_REQUEST_QUEUE_HEAD_STORAGE_SLOT 和 WITHDRAWAL_REQUEST_QUEUE_TAIL_STORAGE_SLOT）。排队的提款请求数量可以是无限的，但 MAX_WITHDRAWAL_REQUESTS_PER_BLOCK 变量限制了每个区块可以脱队的待处理提款请求数量。

提款请求队列维护“头”和“尾”索引——这两个索引仅仅指代在队列的开始和结束附近的请求组——在每个区块后更新，以考虑一个或几笔提款请求的处理。这是一个先进先出（FIFO）队列，因此请求按加入队列的时间顺序执行——这在安全性上有影响，尤其在诚实验证者的攻击方面。

验证者提款合约费用

MIN_WITHDRAWAL_REQUEST_FEE 是调用验证者提款请求合约以提取验证者所需支付的钱。在将提款请求插入队列之前，验证者提款请求合约会检查附加到交易上的gas费用是否等于或超过当前值的 MIN_WITHDRAWAL_REQUEST_FEE——如果交易成功执行后剩余gas，则发送地址将获得正好2300 gas的退款。

根据规范，这种设计遵循了Solidity中已弃用的功能，即在目标合约中调用 fallback() 函数或通过 transfer() 或 send() 发送ETH时，向接收者转发2300 gas的补助金。随着Berlin/Istanbul分叉后gas费用的变化，改变了此功能的效用（可以阅读现在停止使用Solidity的transfer()以了解背景信息），但是原先简单的gas会计系统的想法依然是有用的。在EIP-7002的上下文中，发送固定的2300 gas退款简化了验证者提款请求合约的费用机制。

替代方法是设计一个特殊机制，使提款请求合约可以返回交易中剩余的最大gas量。这是有道理的，尤其是在提款地址是EOA的情况下——智能合约可以通过检查合约状态精确计算MIN_WITHDRAWAL_REQUEST_FEE的值，但EOA通常会对每次调用提款请求合约发送更多的gas。这一路径相比于使用简单的CALL以上述退款为固定量会增加EIP-7002设计的复杂性；不过EIP-7002的作者建议这个功能可能会包含在最终规范中，视利益相关者的反馈而定。

关于 MIN_WITHDRAWAL_REQUEST_FEE的计算，会涉及的事情越来越复杂。提款请求费用是动态的，旨在响应网络条件，类似于EIP-1559引入的基本费用，计算公式是三个变量的函数：

• 最低的（基准）提款费用： MIN_WITHDRAWAL_REQUEST_FEE
• 当前区块上未使用提款的数量： EXCESS_WITHDRAWAL_REQUESTS
• 提款请求费用更新公式： WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION

就像EIP-1559的 base_fee，验证者提款合约的退出费用也是一个限速机制：在平均情况下（每个区块两个请求），任何调用验证者提款请求合约的人都可以预计支付最低提款费用，但随着区块中包含的提款请求数量逐渐增加，操作的费用也逐渐上涨。这可以从EIP-7002关于更新提款请求费用的正式规范中得出：withdrawal_request_fee = MIN_WITHDRAWAL_REQUEST_FEE * e**(excess_withdrawal_requests / WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION)。

来自规范的提款请求费用机制的解释：

“逐区块的行为大致如下；如果区块N处理X个提款请求，则在区块N结束时， excess_withdrawal_requests 增加 X - TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK，因此区块N + 1的 withdrawal_request_fee 评估就因子增加。因此，它拥有类似于现有的EIP-1559的效果，但具有更“稳定”的性质，因为它以同样的方式响应相同的提款请求数量，无论它们在时间上的分布情况。”

通过根据验证者提款请求合约的使用情况逐渐提升提款请求费用，EIP-7002降低了恶意行为者故意填满提款请求队列从而阻止其他验证者提款的风险。记住队列中的提款请求是以先进先出（FIFO）的风格来脱队的，相较于例如后进先出（LIFO）或最高支付交易优先的方式。虽然我们可以假设gas价格会防止不必要的调用提款请求合约，恶意攻击者可能会愿意支付更多的gas来“填充”提款请求队列，并推动其他验证者的提款请求被延误。

此问题在合并后以太坊的区块构建中心化的问题变得更为严重。如果攻击者与一个或多个主导建设者在一起（背景提供：到目前为止，约80-90%的以太坊区块是由4-5个建设者生成的），并愿意为区块顶部的包含支付费用，他们可以有效地超前队列一个或多个质押者的提款请求，阻止检测到的时机等到信标链上的验证者获得及时提款。

那么，为什么有人需要经历这种压力？一个可能的动机是攻击者想手动生成难以提取验证者平衡的质押者。根据前面示例中的恶意节点操作员Bob和质押者Alice，Alice可以迅速提取她的验证者去阻止Bob的猖獗，通过使用提款验证者请求合约的提款凭证——但是Bob仍然可以通过对质押者进行欺诈性攻击，以对质押者的提款请求进行网络骚扰，并延迟Alice的提款请求。

区块结构与有效性

EIP-7002略微改变了信标块的结构和有效性，要求提款请求被置入块的实际主体中（排除执行构造的共识层）。请求必须嵌入执行的负载，确保即使共识层无法达成时，共识层依然拥有完全执行状态转换函数所需的数据。

EIP-7002还增加了区块的新有效条件。首先，提款请求列表（withdrawal_requests_list）不得超过MAX_WITHDRAWAL_REQUESTS_PER_BLOCK。其次，提款请求的列表必须对应移除的提款请求数量，这些请求存在于 WITHDRAWAL_REQUEST_QUEUE的先进先出（FIFO）顺序中。

EIP-7002提供了一个函数（expected_exit），用于确认块不包括的提款请求数量超过计算后结果的 NUM_WITHDRAWAL_REQUESTS_IN_QUEUE - MAX_WITHDRAWAL_REQUESTS_PER_BLOCK。此外，重新执行区块的共识节点将通过比较 request_type 和 request_data， 迭代验证请求的编码，其与提款请求列表的哈希承诺相比。

为什么是EIP-7002？执行层可触发提款的理由

减少委托质押的信任假设

在介绍中，我提到依赖于验证者的签名密钥来启动验证者退出引入了信任的问题；我没有包括信任的定义，但来自Vitalik的信任模型文章的定义很好地总结了这一点：“信任是你对其他人的行为所做的任何假设。”通过注册质押服务，知道恶意节点操作员可以冻结提款，质押者基本上信任该节点操作员诚实行事。EIP-7002 并没有完全消除委托质押中的信任因素——你仍然需要信任节点操作员不会执行恶意攻击——但使质押者能够使用取款凭证进行提款在一定程度上减少了信任负担。例如，用户不需要“有信心”节点操作员在他们请求后会签署自愿退出信息。

关于“无信任”的一个微妙点是，这并不一定意味着避免需要信任，而是不需要信任，因为 (a) 各方都有强烈的诚实行为动机 (b) 诚实方有一定程度的保护措施来抵御不诚实方的行为。使用取款凭证提取验证者的能力就是后者的一个例子：Bob可能会试图攻击Alice，但现在Alice有权利提取她的验证者，希望能够在Bob造成更多损害之前进行。

改进质押池的风险管理

目前，质押池没有办法强制验证节点操作员进行提款——这使得池的贡献者处于信任节点操作员诚实行动的不舒服境地。一些去中心化质押池要求节点操作员提供保证金，但考虑到恶意操作员可能被格损到 0 ETH，因此在风险厌恶的质押者眼中，保证金的安全性可能是不够的。

实施 EIP-7002 后，质押池可以通过配合对节点操作员质押物质的格损威胁与通过执行层提款强制撤回表现不佳的操作员的程序，大大减少信任假设。取款凭证指向智能合约地址（而非外部拥有地址）的可能性也为质押池提供了新的事件响应设计——例如，如果一个操作员在时间窗口内受到高于平均水平的惩罚，智能合约可以自动提交提款请求。然而，这需要信任一个 oracle 来跟踪验证者的表现，并依赖一个 keeper network 来触发智能合约。

对于实施 EIP-7002 的质押池的另一个假设益处是消除了请求和存储预签署提款信息的需要，这伴随着我之前解释的风险（例如，未授权访问提款消息可能导致意外的验证者提款）。这也有助于实现设计无信任质押池的目标：与依赖于少数（可信）个人存储的预签署提款请求相反，指定为提款地址的智能合约可以由治理管理，使社区能够公开透明地决定撤回节点操作员。

改进 DVT 设定的风险管理

分布式验证者技术 (DVT) 被认为是以太坊质押基础设施的重要组成部分，原因有很多：

• DVT 降低了独立质押的障碍：多位独立质押者可以将资金汇集在一起，共同激活一个验证者，而无须信任其他每一个参与方。多方计算 (MPC) 方案可以容忍最多 ⅓ 的故障节点——因此如果一个假设的分布式验证者需要 3 个 5 共有密钥来重构验证者签名密钥，签名仍然可以发生，只要两个 DVT 节点处于离线状态。
• DVT 提升了机构/独立质押设置的容错性和韧性：如上所述，验证者的签名密钥可以被分割为多个其他密钥，当需要签名区块数据时再重构。这降低了黑客破解验证者签名密钥的风险，或者质押者因存储签名密钥的设备受损而失去资金的风险。

但是，DVT 设置仍然给质押者带来一些风险，因为 Beacon 链上提款和退出的工作方式。如果一些 DVT 节点丢失密钥或拒绝参与门限签名方案，退出验证者将变得不可能——尤其是在：

• DVT 设置中每个参与者的密钥在激活验证者时生成，且在初始 DKG 仪式后无法“刷新”（请注意，“参与者”可以简单地是同一质押者拥有的另一个外部拥有地址）；某些 DVT 协议确实允许生成新的密钥，尽管这可能要求其余密钥符合常规签名所需的法定签名数量。
• 一旦（分布式）验证者处于活动状态，法定阈值——共同生成有效签名所需的密钥数量——便无法更改。

如果没有 EIP-7002 提供使用取款密钥的选项来提取验证者，独立 DVT 设置或与其他验证者一起运行的好处将大大减少（例如，验证者余额可能会被锁定很久）。EIP-7002 为分布式验证者提供了一个回退安全选项：如果重构签名密钥不可行，则可以通过提交使用从密钥中重构的取款密钥签署的提款请求，从 Beacon 链中撤回验证者。

改进合规性：将“非托管”放入非托管质押中

EIP-7002 的作者们不太可能明确设定使运行受监管的机构质押服务公司更容易的目标。尽管如此，该EIP确实帮助解决了让监管机构相信机构对质押 ETH 不持有的难题。在这种情况下，质押运营者可以简单地出示由质押者的取款密钥签名的存款交易哈希——该密钥现在可以签署和提交自愿退出——作为证明，验证者中存入的资金在任何时刻都不会由其控制。

我强调“任何时刻”，因为在 EIP 7044 之前，节点操作员在预签名退出过期后会暂时控制验证者的余额。即使在 EIP-7044 的永久有效签字退出中，节点操作员仍然在验证者激活和质押者接收来自质押服务运营者的签字退出消息的短时间内，持有存入共享的 32 ETH。EIP-7002 消除了这些尴尬的情况，确保质押者在验证者生命周期内（从进入 Beacon 链到提取并将资金发送到质押者的提款地址）都有（可验证的）资金控制权。

改进所有人的质押用户体验 (UX)

将 EIP-7002 理解为“质押基础设施的账户抽象”是一个很好的心理模型。作为背景，验证者密钥（或签名密钥）始终是一个外部拥有地址，并带有影响当前以太坊外部拥有地址的相同私钥安全和使用方面的约束：

• 验证者（签名）密钥更容易被破解。与存储在冷（离线）存储中的取款密钥不同，验证者密钥存储在连接到互联网的热钱包中，使其容易受到钓鱼攻击。如果验证者的签名密钥被破解，质押者和委托质押提供者将易受前言中描述的攻击向量影响，无其他中当计划—超出“等待余额降到 16 ETH，然后通过协议强制撤回验证者”的内容。
• 验证者密钥的恢复方案选项有限（丢失一次=永远丢失）。通过分布式验证者技术 (DVT) 将验证者密钥拆分为多个密钥可以降低这一风险，但运行独立 DVT 质押设置并不简单；此外，正如我之前解释的，DVT 并不是万灵药，因为密钥可丢失，且可能使密钥刷新变得复杂。
• 验证者密钥不能支持更灵活的质押设计。由于将取款凭证指向智能合约的好处，不同的质押服务已经发展出自动化/灵活的验证者资金工作流。但是，撤回验证者仍然是一个手动过程，需要签署自愿提款请求消息——该过程可以通过存储预签署提款请求的智能合约自动化，但这伴随着某些信任假设和以前解释过的安全考量。

一旦取款密钥能够退出验证者，我们可以解决大多数——或者至少是一些——这些问题。为了使其工作，质押者（或质押池）将需要一次性将 0x0 取款凭证更改为 0x01 取款凭证——0x0 凭证默认是 BLS (EOA) 密钥，0x01 凭证可以指向任何以太坊地址，包括智能合约和外部拥有地址。将智能合约设为验证者的提款地址对改善质押的用户体验 (UX) 大有裨益：

1. 取款密钥可以具有灵活的恢复机制，例如社交恢复。质押者可以有一个或多个“保管人”，在原始密钥被盗或丢失的情况下，授权新的密钥来控制提款请求智能合约——保管人可以是朋友、亲戚、同质押者或专业的第三方服务。恢复机制的灵活性对独立质押者特别有益；例如，你可以设置一个 死亡开关，如果你的验证者在预定时间内停止证明（例如因为你已经“过去”到了另一个地方），自动激活 EL 退出，并将资金发送到指定地址。

斗争是真实的，各位。（来源）

2. 灵活的质押设计可以出现。例如，一个风险厌恶的质押者可能会更喜欢一个 2 比 2 的多签提款合约——质押者和节点操作员持有两个所需的钥匙之一来批准提款请求，而不是存储整个提款密钥。这仍然是非托管的（节点操作员无法在未经批准的情况下退出验证者），尽管这要求信任节点操作员不会通过拒绝签署质押者提出的提款请求来阻止验证者的退出。在质押池中，质押设计的灵活性可能意味着实现带有任意逻辑的提款合约，以更新或转移验证者的所有权。

没有 EIP-7002，质押池管理验证者所有权的唯一切实方法是处理预签署的提款请求，这伴有各种风险和边缘案例。

3. 验证者提款可以安全地自动化。与存储预签名的提款请求在智能合约中不同，提款请求合约可以有复杂的规则来管理验证者提款请求；一个“疯狂的科学”思想是一个“基于时间的质押池”，其中节点操作员可以在不信任的情况下轮换。或者考虑到如果像 Lido 这样的大型质押池想要去中心化：治理可以决定撤回一些由大型节点操作者控制的验证者，并将资金重新分配给较小的操作者（或独立质押者），以减轻来自一个操作者控制的大量验证者的瓶颈问题。

这些只是 EIP-7002 启示的一些早期可能性，但我非常确信会出现更多应用——就像以太坊上智能钱包的新功能和用例不断浮现。如果你阅读了这篇文章并对将 EIP-7002 应用于质押设计有更具体的想法，请随时在评论中表达你的观点！

实施 EIP-7002 有没有缺点？

对现有质押设计的潜在破坏性变化

在 EIP-7002 草案中，EIP 的作者承认使用取款凭证触发验证者提款的可能担忧，但接着表示，“我们不知道依赖此功能（即无法使用取款凭证进行提款）的任何质押设计。”这似乎是合理的——甚至我在推测任何依赖此功能的委托质押安排时就遇到了困难。但仅仅因为它看起来不明显，并不意味着它不存在。

“聆听那些微弱的、纠结的怀疑。如果你不知道，你就不知道你不知道什么，你不知道你有多少不知道，你也不知道你需要知道多少。” — Eliezer Yudkowsky

为了提供一些背景，我将附上关于 通过通用消息总线（GMB）实施取款凭证批准的退出的早期提案的对话截图。GMB 是一个系统级的智能合约，其事件被客户端（如当前的存款合约）读取和处理，并能够传递来自执行层的消息到共识层。虽然作者暗示了更通用的 EL 到 CL 消息类型，但 EL 到 CL 消息总线的主要提议用例是通过 0x01 取款凭证提供从执行层触发退出的方法。

从这次交流中，我们已经得到了一个质押者与节点操作员之间建立的关系例子，基于质押者无法退出和使用取款密钥提取验证者的假设。实施 EIP-7002 的另一个潜在边界案例来自于 Lido 的去中心化计划的对话，这段对话可以在 Lido 社区质押播客中 观看 YouTube 中找到。（在视频中，EIP-7002 仅简要提及（28:55 到 30:00））。

背景信息：Lido 被描述为“对以太坊的系统性威胁”，因为它控制着约 33.3% 的 Beacon 链验证者，这可能使以太坊的共识面临风险；例如，如果 Lido DAO 强迫节点操作者进行交易审查，或撤回先前已完成的区块（迈克·纽德的 Lido 攻击向量的规模和方向 中详细描述了这一威胁）。

然而，前面的会议中的发言人提出了一个令人信服的论点，即该攻击向量——DAO 强行迫使节点操作员共同对以太坊协议进行攻击——尚未存在，因为节点操作员拥有一定的自主权。DAO 可以在验证者退出后对其质押进行扣留，但不能依赖于强制退出的威胁来逼迫验证者攻击以太坊的共识。

随着 EIP-7002 的实施，权力动态显著改变：由 DAO 管理的提款合约可以违反其意愿地撤回一个操作者——赋予 DAO 对节点操作员的杠杆。这种类型的杠杆对于保护质押协议免受恶意操作者组的攻击非常有用，如我之前解释的。但也可以在以下场景中被滥用：

• 质押协议遭遇治理攻击，DAO 通过强迫性提案触发从提款合约撤回验证者
• 攻击者通过劫持提款请求合约的所有权获取一个或多个验证者的控制权，并执行成功的勒索策略

这是 EIP-7002 如何改变质押设计中既有假设的又一个例子——这次是为像 Lido 这样的质押池代表其验证的节点操作员。然而，这个攻击向量可以通过多种方法轻松缓解，比如使用安全、经过严格审计的，可能不可升级的提款请求合约，或遵循 安全 DAO 治理的最佳实践。

为了考虑节点操作员在拒绝攻击者要求违反协议规则后遭受强制撤回损失的边界情况，质押池可以借鉴房地产公司的启发来保护节点操作员：

• 在签署租约之前，租户需要提供“安全押金”。押金存放在不受房地产公司控制的银行账户中。
• 如果租户搬离公寓，但留下重大损害，房地产公司有权使用押金来支付修复费用。
• 如果租赁退房时公寓状况良好，押金会全额退还给租户。

质押协议可以采取类似的方法来保护节点操作者，通过通过 Nexus Mutual、Tidal Finance 或任何其他加密本地保险平台采取“节点操作员保险基金”政策。如果操作员的验证者被合法撤回，保险金将返还给 DAO；如果情况反转（例如，验证者的撤回因恶意提案或提款合约漏洞而触发），保险政策将向节点操作者支付损害赔偿。请注意，这种方法可以推广到依赖当前有关验证者退出的规范的任何现有关系中。

缺乏对更复杂的 EL 到 CL 消息的支持

EIP-7002 的验证者提款请求合约提供了一个单一的功能：从以太坊的执行层发送提款请求到共识层以提取验证者。然而，一些人建议实施一个通用的消息框架（例如，SendMessageToConsensusLayer 预编译，或之前提到的通用消息总线（GMB）系统级合约）用于在执行层和共识层之间传递通用类型的消息。这可能带来一些好处，例如解锁激活 Beacon 链验证者的新方式，尤其是如果允许将 ETH 附加到 EL 到 CL 消息时。

然而，正如丹尼·瑞安（EIP-7002 的作者之一） 在一则评论中解释的，花费宝贵的工程时间来构建通用的消息 EL → CL 框架是一个“价值主张不明确的大工程”。例如，GMB（通用消息总线）提案的作者只识别出一个 EL 和 CL 之间消息总线的其他用例：将验证者的取款凭证从 0x0 转换为 0x01 凭证。

这意味着我们更有可能看到验证者提款请求合约首先上线，而在核心开发者谈论实现一个通用的 EL 到 CL 消息总线之前，如果这真的会发生的话。毕竟，保持事物简单永远是个好主意。

简单性是可靠性的前提。 — Edsger W. Dijkstra

现有质押者的新风险向量

我大部分时间都阐述了启用取款凭证触发提款的好处，但与该特性相关的一些边界情况也存在。这一想法如下（感谢 GitHub 上的这则评论）：

• 如果验证者的签名密钥被破解，黑客可以要求赎金，或者试图减少验证者的余额——但是在任何情况下都无法提款。将会进入一场等待游戏：攻击者会摧毁整个余额，还是质押者能够在验证者被强制撤回后提取部分质押？
• 但是，一旦 EIP-7002 得以实施，前述场景中的黑客可以退出验证者并提取余额（在 EIP-7002 实施之后），而不是满足于恶性或勒索攻击。

简而言之，独立质押者和质押服务在 EIP 7002 实施后对于取款凭证需要更多保护。这就是为什么在改善独立/委托质押运营的安全性方面，社交恢复、多因素（MFA）认证和密钥轮换的采纳被认为是关键的原因。

限制机制选择

验证者提款请求合约的 add_withdrawal_request() 功能除了检查附带的提款请求费用外不进行任何额外检查，可能导致攻击者用无效提款请求（例如，不存在的验证者或不活跃的验证者的退出消息将在共识层的有效性检查期间无效化）使消息队列阻塞。EIP-7002 使用动态定价提款费用来限制提款请求并使这样的攻击付出成本，这类似于 EIP-1559 如何通过根据网络活动调整gas 费用来阻止垃圾邮件攻击和区块填充。

另一种设计是将对验证者提款请求合约的调用限制为实际的验证者——例如，通过检查 validator_pubkey 是否与活跃 Beacon 链验证者的公钥相对应。这可以通过消除复杂的 EIP-1559 风格定价机制并降低提款请求费用来简化 EIP-7002 的设计，因为用假请求淹没队列的问题可能较小。

然而，这要求执行层能够信任地访问关于共识层的信息——检查 validator_pubkey 是否与 Beacon 链的验证者注册表相符——这一特性依赖于实施 EIP-4788。这为 EIP-7002 增加了更多复杂性，并引入了两个 EIP 之间的新依赖关系，这可能对未来的设计改进产生影响，如 EIP-7002 的论据部分所述的那样。

即使 EIP-4788 与 EIP-7002 相结合，我们仍然需要额外机制来防止涉及合法验证者的其他形式的垃圾邮件。例如，在非常短的时间内提交多个提款请求，以提取同一个验证者。这反过来又要求新增加（和执行）一项新规则，例如“每个验证者每 3-4 个月只能提交一次提款请求”，这可能需要对验证者提款请求合约进行更多更改。

相反，当前的限速机制是容易推理的，并且保证对与执行层提款相关的大多数安全问题有足够的保护。例如，提款请求费用可以自动上调，以防止恶意攻击（试图阻止诚实的验证者提款）和垃圾邮件及拒绝服务攻击（试图强制共识节点浪费资源过滤无效的提款操作）。

结论：EIP-7002 和以太坊质押的未来

委托质押在最近几个月遭受了显著的批评，但可以安全地假设质押作为服务行业将继续存在。如果是这样，降低个人将质押委托给——无论是质押池还是机构非托管质押服务——的风险是的重要的。EIP-7002 通过使 0x01 取款凭证能够退出验证者并提取质押，以及减少质押者需信任节点操作员诚实性的需求，达到了这一目标。

EIP-7002 还具有其他积极的溢出效应。特别是通过改善从验证者密钥或 DVT 密钥丢失恢复的可行性和安全性，以提高独立质押操作和分布式验证者的韧性——应降低独立质押的障碍，并减少以太坊的质押中心化。

照例，我将结束这篇文章，请你考虑将这篇文章分享给可能会发现其信息的人，更重要的是，订阅以太坊 2077 获取关于以太坊研发的更多深度探讨。你还可以 在 Twitter 上与我联系，分享对这篇文章的评论或反馈。

• 原文链接： research.2077.xyz/eip-70...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～