流动的信任:从 Kiln 事件看以太坊共识层质押的进入与退出|GCC Research
2025-10-0713:33
GCC Research
2025-10-07 13:33
GCC Research
2025-10-07 13:33
收藏文章
订阅专栏

撰文:shew

概述

GCC 基金会在过去曾将一部分 ETH 质押给了 Kiln 服务商。但不久前,Kiln API 出现漏洞,导致 SwissBorg 的 193,000 SOL 被盗。出现该事件后,Kiln 为了保护用户资产安全,对使用 Klin 服务质押的 ETH 进行了清退。Kiln 为用户脱管的大量 ETH 进入退出队列。这导致提款队列在过去一段时间激增。



本文将介绍以太坊质押的基本原理和 Kiln 服务的实现原理,读者可以通过本文了解到以太坊质押和退出的工作原理和等待时间等机制。


存款

以太坊 PoS 升级中,早期最重要的步骤就是部署存款合约。存款合约是部署在执行层上的承载质押 ETH 的合约,该合约地址是 0x00000000219ab540356cBB839Cbe05303d7705Fa。该合约也许是除了 WETH 合约外,以太坊内持有最多 ETH 的合约。

存款合约内包含 deposit 函数,任何用户都可以调用该函数为验证者进行充值。该函数接受的最核心参数是以下两个:


  1. pubkey 验证者的公钥。众所周知,PoS 需要验证者对区块进行签名投票,所以不同的公钥可以区分不同的验证者,我们可以通过指定公钥的形式来确定需要为哪一个验证者充值
  2. withdrawal_credentials 提款凭证。验证者在参与投票或者出块时可以获得 ETH 排放奖励,这些 ETH 需要发送给谁是通过提款凭证确定的。当然,假如验证者需要退出共识层,本金也会被发送给提款凭证。目前常见的提款凭证有 Type 1 和 Type 2 类型提款凭证,这些提款凭证本质上是以太坊执行层地址。简单来说,用户可以通过提款凭证指定一个以太坊地址用来接收可能的奖励和退出质押时的本金


在此处,我们可以可以更加详细的介绍提款凭证的有关内容。在最初,共识层使用的 Type 0 类型的提款凭证,这类的提款凭证是一个 BLS 公钥,但需要注意的该公钥与用户签名投票的公钥并不是同一类,读者阅读早期以太坊资料时往往可以看到以下这种示意图:



其中 withdrawing keys 就是指 Type 0 提款凭证对应的 BLS 私钥。但是读者需要注意的是,Type 0 提款凭证基本属于被废弃状态,目前我们一般不使用该类型提款凭证,假如用户使用了该类型提款凭证,也需要切换为 Type 1 提款凭证,否则无法进行提款操作。

Type 1 提款凭证是简单的,本质上就是以太坊地址,下图展示了一个使用 Type 1 提款凭证的节点:



使用 Type 1 提款凭证时,系统每间隔一段时间就会将用户大于 32 ETH 的资产清扫到用户的提款地址内部。比如上图中 0x71f62786AeD65a78c46a6f69c3bA0d5Ae9B9cdeA 接受的资产都来自共识层。该过程是自动的,用户并不需要任何操作就可以不断收到来自共识层的奖励。



在 Pectra 升级后,以太坊共识层引入新的提款凭证,该提款凭证被称为 Type 2 提款凭证,该提款凭证允许用户持有大于 32 ETH 的余额,并且持有的余额越多,出块的概率越大。但是 Type 2 提款凭证在验证者余额小于 2048 ETH 之前并不会自动收集奖励。

值得注意的是,共识层会直接将 ETH 奖励发送给用户的提款地址,这意味着我们可以选择一个合约地址作为提款地址,这样就可以实现非托管质押。Klin 就是用了该方案,假如企业使用 Klin 服务进行 32 ETH 质押,质押时会使用一个带有手续费提取逻辑的合约地址作为提款地址。此时企业发起提款后,资金会被退回到提款合约,此时除了企业自己外,没有其他用户可以使用该合约内的 ETH 资产。企业可以调用合约内的提款函数将 ETH 提取到自己的钱包中。当然,提款函数中也包含手续费计算逻辑,会提取一定数量的手续费发送给运行验证者的运营商。

实际上,Lido 等流动性质押平台以及 EigenCloud 等 restake 平台都使用类似的原理,即验证者会将提款地址设置为某一个特殊的地址。对于 Lido 而言,虽然资金被用于验证者节点质押,但资金的并不会完全被验证者控制,而是仍被自己的合约控制。对于验证者而言,其唯一可以控制资金的方法是违反共识协议,使被托管的资金 slash。但是该行为对验证者而言也没有任何好处。

当验证者或者其他资金提供者将 ETH 存入存款合约后,存款合约会抛出存款事件。下图展示了一个来自存款合约的事件:



共识层在出块时,出块的验证者会通过 API 从执行层节点处抓取存款事件,并将其打包到共识层区块 (Beacon Block) 内部,所有的共识层节点都可以通过共识层区块或者自己抓取存款事件获得当前验证者集。需要注意的,每一个区块可以容纳 16 笔存款交易,假如单一区块容纳的存款交易超过 16 笔交易,那么该起会被视为无效区块。

当用户的 Deposit 成功后,用户无法立即成为验证者,而是会进入另一个等待激活的队列。等待激活队列会在每一个 Epoch ( 一个 Epoch 包含 32 个区块 ) 结束时进行处理,当以下任一条件被满足后,我们就会 完成 本次激活队列处理,队列内剩余的用户会在下一次 Epoch 时再次处理:


  1. 处理 16 笔存款
  2. 达到每一个 Epoch 内的最大存款上限 ( 大约为 256 ETH)


换言之,每一次对等待激活序列的处理都会抽取一批存款交易然后处理,假如处理了 16 笔存款交易,那么就不会处理队列内剩下的交易; 还有一种情况,假如已经处理的存款交易存入共识层的 ETH 数量超过某一个限度,那么我们也会停止处理队列内剩余交易。由此读者就可以理解 Pectrified 网站中的数据显示的计算方法:



退出

在上文中,我们其实已经对退出质押过程中最核心的提款凭证进行了简单介绍。在 Pectra 升级后,验证者退出其实包含以下三种问题:


  1. 自动质押奖励分发。每隔一段时间,使用 Type 1 提款凭证的用户可以自动在提款地址处收到区块奖励,当然,质押 2048 ETH 的 Type 2 提款凭证用户也可以自动获得奖励
  2. 手动奖励提取。使用 Type 2 提款凭证的验证者可以手动提取质押奖励
  3. 退出所有质押 ETH。比如使用 Type 1 提款凭证的验证者退出自己存入的 32 ETH


我们首先介绍最为简单的自动质押奖励分发机制。在共识层内,验证者都维护着一个包含所有验证者的队列,在每一个 Epoch 末尾,出块节点会在队列中扫描最多 16384 个验证者,并从中抽取最多 16 个符合条件的验证者进行提款。此处的条件对于使用 Type 1 提款凭证的验证者而言是持有 ETH 的余额大于 32 ETH,多余的 ETH 会被提款到提款凭证对应的执行层地址。对于使用 Type 2 提款凭证的验证者而言是持有 ETH 的余额大于 2048 ETH,大于的部分会被自动提款到提款凭证对应的执行层地址。这一过程是不需要 gas 的,且不需要用户进行任何操作。

手动奖励提取是 Pectra 升级后引入的最新的取款方式。Pectra 升级中,我们引入了 EIP-7002。该 EIP 在主网引入了 0x00000961Ef480Eb55e80D19ad83579A64c007002 合约 ( 在后文中,我们称之为提款请求合约 )。验证者可以使用自己的提款凭证对应的地址向该合约发起交易来请求提款。

首先,由于该提款过程需要调用提款请求合约,所以该过程需要用户手动进行且需要支付 gas 费用。其次,为了避免用户在短时间内从共识层进行大量提款操作。EIP-7002 引入了提款手续费机制。提款手续费的计算方法如下:



此处的 backlog 指目前提款请求的数量与目标提款请求数量的差值。目前,目标提取请求数量是每一个区块为 2。简单来说,假如当前区块提款请求数量为 3,那么 backlog 的数值就是 1。我们需要注意到提款请求费用的计算是指数计算,所以假如在短时间内出现大量提款请求,用户需要为提款请求支付高额手续费。



当然,发起提款请求的方法非常简单。用户需要使用自己的提款凭证地址向提款请求合约发起交易。交易的具体内容是验证者的 BLS 公钥和提款数量。在共识层出块时,共识层会通知执行层调用取款请求合约来抓取该区块内的提款请求情况,并在共识层内进行处理。此处出现了目前以太坊执行层内最有趣的机制,执行层需要使用 0xfffffffffffffffffffffffffffffffffffffffe 对提款请求合约发起交易来读取提款请求,该交易是不需要验证签名和支付 gas 的。这是以太坊内目前为数不多的几种不需要支付 gas 就可以发起的交易。

当共识层每到 Epoch 末尾时,就会集中处理当前 Epoch 内的部分提款请求。相比于上文介绍的自动提款,部分提款请求时具有一定优先级的。每一个 Epoch 会首先处理 8 笔部分提款请求,然后再处理自动提款请求。同时每一个 Epoch 最多只能进行 16 笔提款。所以理论上假如部分提款每一个 Epoch 都有 8 笔,那么自动提款就只能处理剩下的 8 笔。

最后,我们介绍全部提款,也是这次 Klin 事件内被使用的验证者退出方法。在 Pectra 升级后,存在以下三种情况:


  1. 使用提款请求合约发起提款数量为 0 的请求
  2. 使用共识层的 API 发起自愿退出的请求
  3. 出于各种原因,当验证者的在共识层内的余额小于 16 ETH 时,共识层会自动为节点启动全部提款


全部提款实际上与上文中的部分提款共用扫描流程,在进行验证者扫描时,假如发现验证者本身处于全额提款状态,那么就会直接将验证者所有的余额一次性进行提取。

由于引入了使用提款请求合约进行全额提款的方法,为了用户可以更加有信心将 ETH 托管给服务商获取质押奖励,在过去,用户还需要与质押服务商进行沟通以实现退出共识层的目的,但是现在用户只需要使用提款地址向提款请求合约发起交易即可。


总结

本文介绍了目前以太坊共识层的质押和提款的基本规则,核心介绍了以下内容:


  1. 用户在质押时需要使用存款合约,通过验证者的 BLS 公钥发起存款
  2. 存款会每一个 Epoch 进行处理,处理的数量为 16 笔存款或者 256 ETH 存款数量
  3. 自动提款每一个 Epoch 会处理最多 16 笔,对于 Type 1 提款凭证用户而言,大于 32 ETH 的部分会被自动提取
  4. 部分提款需要通过提款请求合约进行,每一个 Epoch 会处理 8 笔,且优先级高于自动提款
  5. 全额提款目前也可以通过提款请求合约进行

【免责声明】市场有风险,投资需谨慎。本文不构成投资建议,用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资,责任自负。

专栏文章
查看更多
数据请求中

推荐专栏

数据请求中

一起「遇见」未来

DOWNLOAD FORESIGHT NEWS APP

Download QR Code