Monad 质押机制解析

Monad 上的 Staking 如何运作

Monad 是一条 proof-of-stake 区块链。Validators 质押 MON 以参与共识并获得区块奖励。未运行 validator 的 Token 持有者可以将他们的 MON 委托给某个 validator，从而按照其质押比例获得该 validator 奖励的一部分。

本文从委托者的角度解释 Staking 的机制：操作何时生效、奖励如何运作，以及取消委托和提取时会发生什么。

原生 delegation

Monad 在协议中内置了原生 delegation。任何 Token 持有者都可以直接将 MON 委托给某个 validator，而无需运行节点或使用第三方协议。

这与 Ethereum 有一个重要区别：Ethereum 协议本身没有 delegation 机制。要在 Ethereum 上进行 Staking，用户必须自己运行 validator 节点（这需要至少 32 ETH 以及持续的基础设施支持），或者使用像 stETH 或 rETH 这样的 liquid staking token（LST）。LST 是一种 smart contract，会汇集用户存款，并将其分配给运行 validators 的节点运营者。LST 会发行一个代表已质押头寸的衍生 token。

在 Monad 上，delegation 只需向 staking precompile 发起一笔交易即可。委托者保留其质押的直接所有权，获得来自协议的奖励，并且可以在不依赖任何中介的情况下取消委托和提取。

LST 有优点也有缺点——它们可在 DeFi 中组合使用，并且可以通过在 DEX 上交易来提供即时流动性，但另一方面，也会带来额外的 smart contract 风险，而且某些运营决策（比如参数管理和节点运营者选择）是在链下进行的，超出了存款人的控制范围。在 Monad 上，用户可以根据自己的偏好选择直接委托或 LST。

Validators 和 delegation

Validators 是负责提议和投票区块的节点。每个 validator 都有一个佣金率——即在把剩余奖励分配给 delegators 之前，它保留的区块奖励比例。Validators 在注册时设置该费率，并且可以随时更改。

共识 validator 集 目前由按总质押量（自质押 + 委托质押）排名前 200 的 validators 组成，其中每个活跃 validator 的总质押至少需要 10,000,000 MON，且自委托至少需要 100,000 MON。MIP-9 将把活跃集合增加到 300 个 validators。活跃集合之外（或低于质押阈值）的 validators 虽然已注册，但不参与共识，也不获得奖励。

要进行委托，用户在 staking contract 上调用 delegate(validator_id)（这是一个位于 0x1000 的预编译合约），并附带 MON。委托是按（validator，delegator address）这一组合进行追踪的。像 Backpack 这样的钱包，以及像 gmonads 和 MonadVision 这样的 staking 仪表盘，都将本文描述的各项操作（delegate、compound、claimRewards、undelegate、withdraw）以按钮形式展示在 UI 中，因此委托者无需直接调用 staking contract 就能执行这些操作。

Epoch 和激活时机

validator 集不会持续变化。它在一个 epoch 的持续时间内固定不变——50,000 个区块，或者在 400ms 出块时间下约 5.5 小时。在每个 epoch 边界，staking contract 会对当前质押进行快照，并为下一个 epoch 选出前 200 个 validators。在一个 epoch 内，共识集合是冻结的：无论委托或取消委托多少，都不会改变谁参与共识，直到下一个边界到来。

这种 epoch 结构意味着委托不会立即生效。当用户在正常运行期间进行委托时，新质押会在下一个 epoch 边界激活。在此之前，token 会被锁定（它们会离开委托者的可流动余额），但尚未开始获得奖励。

关于 epoch 边界，还有一个额外的细节。在边界区块之后，会有一个持续 5,000 轮（约 33 分钟）的 epoch delay period，之后新的 validator 集才会生效。在此窗口期间，区块仍会继续产生——共识不会暂停——但前一个 epoch 的 validator 集仍处于活跃状态。在此窗口期间进行的委托会进一步延后：它们会在再下一个 epoch 边界才激活，而不是当前正在处理的那个边界。这样做是为了确保 delegation 的变化不会影响已经在进行中的 validator 集切换。

在一个 epoch 早期进行的委托，会在下一个边界开始获得奖励（约 5.5 小时或更短）。在边界区块之后（即在 epoch delay 期间）进行的委托，则要等到再下一个边界——最坏情况下可达约 11 小时。

奖励如何累积

每当 validators 的某个区块被加入链上时，他们会获得 25 MON 的区块奖励。每个区块的奖励分配如下：

1. validator 先取走其佣金（commission rate 乘以区块奖励）。
2. 剩余部分按比例分配给该 validator 的所有 delegators，比例取决于他们的活跃质押。

奖励不会在每个区块后直接发放给 delegators。那样会要求在每个区块都更新每个 delegator 的状态，无法扩展。相反，staking contract 使用一个 accumulator：一个按 token 计算、会随着每个区块持续增长的累计奖励值。当 delegator 执行任何操作（delegate、undelegate、compound 或 claim）时，contract 会通过比较当前 accumulator 与该 delegator 上次操作时记录的值，计算自上次操作以来应得的全部奖励。

这意味着奖励会在后台静默累积。delegator 的奖励余额会随着其 validator 产生的每个区块而增长，但在 delegator 决定如何处理这些奖励之前，不需要发起任何交易。

奖励复投与领取

delegator 对其已累积奖励有两个选择：

Compound

调用 compound(validator_id) 会将已累积奖励再投资为对同一 validator 的额外质押。奖励会被加入 delegator 的活跃质押中，从而提高未来奖励计算的基数。不会有 MON 转入 delegator 的钱包；所有 MON 都留在 staking contract 中，作为委托质押存在。

复投的激活时机与新委托相同：复投后的奖励会遵循 epoch 激活规则。在它们激活之前，这些奖励已经被提交，但尚未开始获得进一步奖励。

Claim

调用 claimRewards(validator_id) 会将已累积奖励提取到 delegator 的地址。MON 会从 staking contract 转入 delegator 的钱包，并立即变为可流动资产。delegator 的质押余额不会改变。

在这两种情况下，已累积奖励都会在调用时刻通过 accumulator 计算。调用之后新累积的任何奖励，会开始计入下一次 compound 或 claim。

取消委托与提取

移除质押是一个包含延迟的两步过程。

第 1 步：Undelegate

delegator 调用 undelegate(validator_id, amount) 开始解除质押。请求的金额会从 delegator 的活跃质押中移除，并保留用于后续提取。此时会计算并记入该取消委托金额对应的所有已累积奖励。

取消委托的 token 会进入 1 个 epoch（约 5.5 小时）的 cooldown period。在此窗口期间，这些 token 不再产生奖励，但也还不能提取。设置 cooldown 是为了确保参与过共识的质押不能被立即移除——这对已最终确认区块的安全性很重要，因为否则 validators 可能在签署恶意内容后立即解除质押。

只有活跃质押才能被取消委托。Pending delegations（尚未在 epoch 边界激活的质押）在变为活跃之前不能被取消委托。

每个 delegator-validator 对最多支持 256 个并发 withdrawal requests，由 withdrawal index（0-255）标识。如果取消委托后会留下少量 dust（低于 1 gwei）的剩余质押，contract 会强制取消委托整个剩余余额，以防止小额残余头寸不断累积。

第 2 步：Withdraw

在 1 个 epoch 的 cooldown 结束后，delegator 调用 withdraw(validator_id, withdrawal_id) 来取回 token。MON 会从 staking contract 转回 delegator 的钱包，并变为完全可流通资产。

这个两步过程意味着，从决定解除质押到 token 可用之间，总会有大约 5.5 小时的间隔。如果 delegator 需要在特定时间获得流动性，应当提前规划这一延迟。

时间总结

staking contract

staking 系统实现为位于 0x1000 的预编译合约。它不是 Solidity contract——其逻辑作为执行引擎的一部分由 C++ 实现。这使它能够为奖励铸造 token（增加总供应量），而这在用户空间的 Solidity 中是不可能实现的。

staking contract 的状态变更由共识层注入区块的系统交易触发：每个区块后的奖励分配、epoch 边界处的 epoch 快照，以及 epoch 开始时的 epoch transition。这些系统交易是确定性的，并可被所有节点验证，确保 staking 状态与链上其他所有活动一起构成同一条执行轨迹。

面向开发者

staking precompile 可以像其他任何 contract 一样从 Solidity 中调用。Solidity interface 和 ABI JSON 可在参考文档中获取。Monad Foundry 是 Foundry 的一个分支，内置了对 Monad precompiles 的支持，允许开发者在本地测试 staking 交互——包括 delegate、undelegate、claim rewards 和 epoch transitions——而无需部署到 live network。

• 原文链接： x.com/keonehd/status/204...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～