将惩罚机制引入Solana

21 分钟阅读

2025 年 8 月 12 日

非常感谢 0xIchigo 和 Ashwin Sekar 审阅本文的早期版本。

介绍

Slashing（罚没）是一种通过惩罚恶意或疏忽的验证者行为来加强网络安全的机制。一旦不当行为得到验证，与违规验证者相关的部分委托权益将被烧毁。

这是 Solana 等权益证明 (PoS) 网络的一个独特特征，在工作量证明 (PoW) 中没有等效项，因为它依赖于协议通过销毁质押资产来直接执行经济处罚的能力。在 PoW 中，没有类似的机制，因为区块链无法没收或销毁不诚实行为者的物理挖矿硬件。

Slashing 提供了几个关键好处：

• 它可以直接经济抑制恶意活动
• 它可以激励 Staker 将其权益分配给信誉良好的验证者，从而改善去中心化
• 它可以激励更大的运营商构建异构基础设施，从而降低共享故障的风险（例如，在 Firedancer 和 Agave 客户端之间分配其权益）。
• 它为验证者提供了另一个指标来区分自己，并通过避免 Slashing 违规和检测其他参与者的恶意活动来累积声誉。

我的观点是，Slashing 是一种棍棒，通货膨胀是一种胡萝卜，两者都应该激励去中心化。

Anatoly Yakovenko

Solana 联合创始人

纵观 Solana 的历史，它一直依赖于一种手动的、社区驱动的共识方法，称为社会化 Slashing。在这种模式下，如果验证者的行为是恶意的，例如通过损害网络活性或安全性，诚实的参与者可以离线协调发起硬分叉，重启网络并 Slashing 违规者的权益。虽然这种方法能够进行灵活的、个案判断，但它带来了巨大的协调开销，并且本质上是被动的。

迄今为止，Solana 上还没有验证者被 Slashing。Solana 最接近 Slashing 类的事件是在 2020 年 5 月，即主网启动两个月后，当时 Solana 基金会自愿烧毁了 1136 万个 SOL ，以回应社区对未公开的代币借贷给做市商的担忧。这使得代币总供应量减少了 2.3%，从 5 亿个 SOL 减少到 4.8864 亿个 SOL。虽然不是正式的 Slashing 事件，但这次销毁起到了一种自我施加的惩罚作用，旨在恢复信任并解决早期社区提出的透明度问题。

几年来，一直有人呼吁 Solana 采用更正式的 Slashing 机制，通常称为程序化 Slashing，通过一个固化的程序直接在链上执行。在这种系统中，如果验证者违反了特定的协议规则，则可以生成违规行为的加密证明并提交给专门的程序，然后该程序会自动触发 Slashing。这种模式减少了对人工协调的依赖，并能够在不中断网络运营的情况下执行较小的违规行为，为可扩展的、去中心化的问责制铺平了道路。

即将推出的 SIMD-0204：可 Slashing 事件验证 的功能门激活，标志着 Solana 在主网上实施正式程序化 Slashing 的第一个重大且有意义的步骤。正如我们将在本报告后面探讨的那样，区块链网络上的程序化 Slashing 事件幸运地很少发生，并且惩罚通常很小。然而，即使验证者的权益可能被协议自动销毁的可能性，也会引入所有利益相关者必须仔细权衡的新风险。关于 Solana 执行程序化 Slashing 的最佳方法，仍有许多悬而未决的问题。像所有经济变化一样，与 Slashing 相关的参数和惩罚将需要广泛的社区讨论，并且最终必须通过正式的治理投票来批准。

与 Slashing 相关的 SIMD

有几个 SIMD 与 Solana 上程序化 Slashing 的推出有关，最初的两个 SIMD-180 和 SIMD-204 计划在未来几个月内在主网上线。

首先，是先决条件 SIMD-0180：使用投票账户地址作为 Key Leader Schedule。此 SIMD 将 leader schedule 中使用的 Key 从验证者的身份地址更改为它的投票账户地址。此更改对于准确的 Slashing 归因至关重要，因为它在验证者的区块生产职责和他们委托的权益之间建立了直接、明确的联系。

SIMD-0204：可 Slashing 事件验证 概述了一个新的 Slashing 程序。它引入了一种链上机制，允许任何人提交和记录可 Slashing 行为的证据，从而创建一个可验证、不可变的验证者不当行为记录。

最后，SIMD-0212：Slashing 概述了在 Solana 协议中实施 Slashing。它建立在 SIMD-0204 奠定的基础上，以对已验证的违规行为施加惩罚。该提案仍然开放，并且仍在积极讨论中。

故障检测和归因

Slashing 程序被设计为一个纯粹的观察层。它不修改权益或奖励；其唯一功能是验证和记录违规行为。一个早期的原型已经 在测试网上线，其中包含示例提交（例如， DuplicateBlockProof 交易）展示了如何记录违规行为。

重复区块生产

在其初始推广中，该程序将专注于一种恶意行为：检测重复区块生产的实例。这是指 leader 为同一 slot 提交同一区块的两个或多个不同版本，这是一种明确且客观的共识违规行为。

此前，在 2022 年 9 月，一个验证者错误地在同一区块高度生成重复区块，从而引发了网络中断。发生这种情况的原因是验证者的主节点和备用备用节点同时处于活动状态，使用相同的节点身份但提出不同的区块。

此问题此后已得到修补，如今，即使在运行热备用的情况下，如果检测到多个实例，验证者客户端也包括关闭的安全措施。因此，如果没有故意恶意修改验证者软件，则极不可能生成重复区块。

重复区块生产是一个协议违规的例子，这种违规行为很难实时检测，但事后很容易验证。尝试协调同步响应（即网络暂停以确认对重复项的集体观察）会带来很大的复杂性。相反，追溯处理检测和 Slashing 更为可行。

提交的重复区块证明包括同一 slot 的两个冲突的 Shred，均由同一验证者签名。Slashing 程序通过确保 Shred 形成有效的重复区块证明、确认它们属于同一 slot 且由违规验证者正确签名来验证该证明。此逻辑类似于 Solana 的 Gossip 协议中用于处理分叉选择过程中重复区块证明的方法。

struct DuplicateBlockProofData {
  shred1_length: u32      // 未对齐的四字节小端无符号整数，
  shred1: &[u8]           // `shred1_length` 字节表示一个 Shred，
  shred2_length: u32      // 未对齐的四字节小端无符号整数，
  shred2: &[u8]           // `shred2_length` 字节表示一个 Shred，
}

报告者构造一个证明并将其存储在链上缓冲区账户中，然后向地址为 `S1ashing11111111111111111111111111111111111` 的 Slashing 程序提交一个交易，引用他们的缓冲区账户。一旦证明成功验证，结果将存储在由 Slashing 程序拥有的 `report_account` 程序派生地址 (PDA) 中，以供将来参考。这使得通过简单地在 Slashing 程序上运行 getProgramAccounts 调用来构建浮出 Slashing 相关数据的仪表板变得容易。验证者可以使用这些来检查他们是否已被报告违规行为，并根据需要采取纠正措施。

预计 Anza 将发布工具，以实现对这些事件的观察、创建证明以及在链上提交证明。可能会有多个实现，包括一个嵌入在验证者软件中的版本。每个 epoch 中只需一个诚实的参与者报告违规行为，因为每个唯一的违规者和 slot 组合只能报告一次。该程序会验证是否已存在针对同一 slot 和违规者的报告。如果找到匹配的报告，则新提交将被拒绝。可以基于发生违规行为的 slot（即最多 432,000 个 slot 之后，由 `Clock` sysvar 跟踪）在违规行为发生后的一个 epoch 内提交报告。

举报人奖励

在 Slashing 设计中，一个常见的问题是是否应该奖励那些报告违规行为的人（即告密者）。虽然奖励告密者似乎是一种简单的激励机制，但它带来了显著的挑战。

在 Solana 上，领导者控制交易包含，告密者奖励会产生抢先交易风险。假设某个验证者向当前区块领导者提交了有效的 Slashing 证明。在这种情况下，领导者可以简单地复制该证明，自己提交并审查原始交易，从而在不做任何工作的情况下获得奖励。这破坏了激励模型，并为滥用打开了大门。

以太坊提供了一个小的告密者奖励：被 Slashing 的验证者的有效余额的 1/512。对于拥有完整 32 ETH 的验证者，这等于 0.0625 ETH。该奖励被铸造为新的 ETH，但会被从被 Slashing 的验证者的权益中烧毁的更大金额所抵消。该值较低是有意为之，因为它旨在提升诚信和诚实参与，而不是由利润驱动的投机行为。

投票违规

预计 Slashing 程序的未来版本将扩展对各种类型的投票违规行为的支持，例如锁定违规和切换证据违规。

当验证者在两个单独的分叉上投票，而没有等待其塔锁定期到期时，就会发生锁定违规。根据 Solana 当前的共识算法 TowerBFT，一旦验证者在给定的 slot 对特定分叉进行投票，它就会被“锁定”，无法在一定时间内对竞争分叉进行投票。如果该验证者稍后在锁定期间到期之前对不同的分叉进行投票，则会违反锁定规则。

由 Solana 联合创始人 Michael Vines 开发的 Votalizer 机器人 当前在 Solana Tech Discord 中运行，跟踪整个网络中发生的锁定违规行为。在实践中，验证者很少会无意中犯下此类违规行为，因为要这样做通常需要故意修改验证者客户端。内置的安全措施可确保客户端检索其最新的链上投票，并防止可能导致锁定违规的操作。

虽然锁定违规已在 Slashing SIMD 和 早期文档 中明确提到，作为 Slashing 程序可能解决的投票违规示例， 但计划的 Alpenglow 共识更新 将删除 Tower BFT，从而消除锁定的概念。因此，预计投票违规行为只有在 Alpenglow 启动后才会引入。

Slashing 程序可能旨在检测的较新的 Alpenglow 投票违规行为可能包括提交同一 slot 的冲突投票，例如，既投 `NotarVote` 又投 `SkipVote`。

未来的违规类型

程序化 Slashing 必须与可验证且明确的不当行为实例相关联。不幸的是，这使得对更具主观性或系统性问题的执行（例如故意缓慢地生产区块或有害形式的 MEV 提取）变得更加具有挑战性。

在对等区块链网络中，通常导致 Slashing 的行为类型因协议而异。常见示例包括：

• 双重签名：在同一高度或 slot 生成两个冲突区块。
• 停机：离线且未能参与共识。
• 包围投票：进行与先前投票相冲突的投票，试图操纵或破坏网络的稳定。

Helius 自己的 0xIchigo 去年提出了一个 新的 Slashing 提案，建议惩罚未能参与正式治理投票的超多数验证者，旨在鼓励更多参与。虽然这种方法满足了客观可验证的要求，但一些评论者提出了担忧。一些人指出，法律约束可能阻止某些验证者投票。另一些人则认为，Slashing 应该严格限制在直接威胁网络安全或完整性的行为。

处罚执行

一旦 Solana 拥有了可靠的链上机制来报告和验证可 Slashing 的违规行为，下一个优先事项就是 Slashing 的经济执行，即定义不同类型违规行为的精确参数和惩罚公式。

指南仍在积极讨论中，本节中介绍的内容反映了当前的提案，旨在为社区反馈提供信息、鼓励对话并根据社区反馈进行演变。由于这些决定直接影响着 Solana 验证者的运营经济，因此任何更改都将经过公开的社区辩论，并且必须通过正式的治理流程批准。

在确定 Slashing 处罚时，一个关键原则是避免过于严厉地惩罚罕见的、一次性的运营商错误。理想情况下，惩罚系统应该有一个容忍轻微事件的缓冲，这些事件不会影响与适当安全措施的共识，而不是对诚实的错误执行严厉的惩罚。

目前对此缓冲的考虑是中本聪系数 (NC) 线，该线设置在超少数中最小的验证者的权益级别（即大约 1% 的权益）。

在提议的函数下，该函数确定每个投票账户被 Slashing 的委托金额，如果提交违规的总权益小于 NC 线，则不会 Slashing 任何权益。相反，如果共识面临风险，这意味着超过总权益的三分之一参与了违规行为，则协议应通过 Slashing 100% 的违规权益来果断响应。

对于介于这些极端情况之间的案例，目前的提案引入了具有缓慢增长率的二次惩罚函数。用于计算每个投票帐户要 Slashing 的权益比例的公式如下：

slash⁡(v)=(3max⁡(0,TSS−NCline)TS)2\operatorname{slash}(v) = \left(\dfrac{3\max(0, TSS - NC_{line})}{TS}\right)^2slash(v)=(TS3max(0,TSS−NCline​)​)2

v = 可 Slashing 的投票帐户

TSS = 可 Slashing 的总权益

TS = 总权益

NC 线 = 中本聪系数线

根据此公式，可以计算出违规验证者要 Slashing 的权益百分比，如下所示：

• 如果 4.66% 的权益违规，则为 1.2%（即 (3 * (0.0466 - 0.01) / 1)²)
• 如果 10% 的权益违规，则为 7.3%（即 (3 * (0.1 - 0.01) / 1)²)

下图说明了提议的曲线以及两种替代方案（激进型和线性型）。

可 Slashing 的总权益 (TSS) 是使用基于违规类型的权重计算的。投票违规的权重为 1，因为它们不太严重。重复区块违规的权重为 10，因为它们被认为更严重。

二次相关的 Slashing 惩罚（例如当前提议的）的一个关键优势是，它们激励那些运行多个验证者（例如交易所或 Staking 即服务提供商）的人员维护高质量的独立基础设施，以最大程度地降低广泛的、相关的故障风险。

传统 Slashing 的替代方案

Slashing 委托权益引发了有关公平性和问责制的重要问题。在当前的 Staking 模型中，大多数（如果不是全部）非私有验证者的权益都是委托的。这意味着，当发生 Slashing 时，通常是委托人（而不是犯下违规行为的验证者运营商）承担着惩罚的重担。即使是选择信誉良好的验证者的勤奋 Staker，如果验证者的行为是恶意的或错误地配置了他们的节点，也可能会在他们没有过错的情况下被 Slashing。

为了解决这种不平衡，已经提出了几种替代的 Slashing 设计。一种此类方法是要求所有验证者保持最低水平的自权益。这可以确保运营商在游戏中拥有皮肤，并且不能将 Slashing 的全部成本转嫁给他们的委托人。此方法的一个更严格的版本是仅 Slashing 自权益，同时自动取消与被 Slashing 的验证者相关联的所有委托人的权益。委托人将失去奖励，但保留其本金，从而使他们可以以最小的长期影响将其权益重新分配给另一个验证者。

另一种方法是在定义的期间内冻结帐户，在此期间他们无法获得奖励、更改所有权或提取资金。冻结的持续时间将随着违规行为的严重程度而增加。或者，协议可以 Slashing 未来的奖励，从而在设定的期限内减少验证者及其委托人的收益，而无需触及本金权益。

有些人建议将 Slashing 的权益重新分配给诚实的验证者，作为一种积极的强化形式，而不是烧毁它。但是，烧毁 SOL 实际上实现了类似的结果，因为它减少了总供应量，从而增加了每个持有者在网络所有权中的相对份额。

考虑事项

在 Solana 上引入 Slashing 具有几个重要的意义。在本节中，我们探讨两个关键领域：冷静期以及由此给生态系统参与者带来的风险、保险和运营负担。

冷静期

当前 Staking 模型中的一个关键漏洞是，当验证者犯下可 Slashing 的罪行，但在观察和报告该违规行为之前取消 Staking 时出现。如果没有延迟提款的机制，恶意行为者可能会利用这种时机差来逃避惩罚。

即使在停用后，权益仍有资格进行 Slashing 的冷静期可以缓解这种情况。此冷静期必须超过验证者或外部观察者检测和协调 Slashing 响应所需的最坏情况时间，尤其是在对抗性条件下，例如网络级 DDoS 攻击或恶意验证者之间的勾结。实际上，这意味着冷静期应持续数天。

Solana 对预先计算的权益快照的依赖加剧了这个问题。几个关键的协议组件（包括 leader 计划和分叉选择规则）都依赖于提前计算的权益值。因此，停用甚至完全提取的权益仍然会影响共识。

例如，leader 计划是从提前一个 epoch 的 epoch 边界处获取的权益快照派生的。这创建了一个窗口，验证者可能会犯下可 Slashing 的罪行，同时已经在上一个 epoch 中停用了他们的权益，并在当前 epoch 开始时提取了它。到发现违规行为时，已经没有剩余的活动权益可以惩罚。

一个解决方案是引入一个额外的冷静期，在此期间，权益仍然可以进行 Slashing，但不再计入协议的权益权重。在 epoch N 中停用其权益的 Staker 将只能在 epoch N+3 开始时提取权益。虽然这提高了安全性，但这种延迟通过迫使 Staker 在完全提取其权益之前额外等待约 2-4 天，从而带来了较差的用户体验。解决此问题的一种方法是缩短 epoch，以保持与当前标准类似的实时取消 Staking 延迟。但是，缩短 epoch 持续时间可能会对协议产生不可预见的影响，因此需要仔细评估。

风险、保险和运营负担

在 Solana 上引入 Slashing 对广泛的生态系统参与者产生了影响，尤其是那些托管、管理或在 Staking 的 SOL 上构建金融产品的参与者。即使进行 Slashing 的可能性也会带来财务风险、运营复杂性和声誉问题，特别是对于在信托或监管约束下运营的机构。这些风险可以通过保险或债券等保障措施来解决。

可能受影响的利益相关者包括：

• 流动性 Staking 协议
• 权益池
• 托管 Staking 提供商
• Restaking 协议
• DeFi 协议
• Staking ETF

对于其中一些实体，Slashing 事件可能会产生连锁反应。例如，流动性 Staking 代币 (LST) 的支持前提是基础验证者安全地执行。如果验证者被 Slashing，可能会触发 LST 的急剧重新定价，或者在极端情况下，如果对基础 SOL 的 Staking 验证者失去信心，则可能导致脱锚。如果 LST 被用作贷款协议中的抵押品，这可能会导致清算。

在其他生态系统中，Staking 提供商通常会提供 Slashing 保险，以减轻这些风险。例如，在以太坊上，许多提供商都提供负担得起的保险，以防止 Slashing 损失，保护级别因承保计划而异。

Slashing 风险还在整个 Staking 价值链中引入了新的运营责任。受影响的人员包括：

• Staking 服务运营商，他们现在必须监控验证者行为并主动减轻风险
• 托管平台和加密货币交易所，它们依赖第三方运营商，可能需要审查其验证者集并使其多样化
• 机构资产管理公司，他们可能寻求自有损失承保，以防止因外部运营商造成的与 Slashing 相关的损失

与对等网络的比较

本节将考察 Slashing 如何在以太坊和 Cosmos 等对等权益证明网络上实施。这些网络已经强制执行程序化 Slashing 多年，从而提供了关于 Slashing 事件的频率及其对网络安全和验证者行为的影响的有价值的真实数据。

以太坊

以太坊的权益证明协议（于 2020 年 12 月随着信标链的推出而引入）从一开始就将 Slashing 作为一项核心的强制执行机制。以太坊定义了四种具体的可 Slashing 罪行，所有这些罪行都围绕着模棱两可：

• 为同一 slot 提议多个区块
• 为同一目标检查点提交冲突的证明
• 证明具有相同来源和目标检查点的不同头部区块
• 创建两个证明，其中一个在来源和目标投票方面“包围”另一个

每种罪行都具有相同的处罚结构。当验证者被 Slashing 时，会立即处以其有效余额的 1/32 的处罚，上限为 1 ETH，原因是最大有效余额为 32 ETH。然后，验证者会被强制退出活动集，并放入大约 36 天的退出队列中。

在此期间，验证者处于非活动状态，并且无法提取资金。它继续损失如果处于活动状态本可以获得的奖励，实际上会经历稳定的机会成本。18 天后，将应用额外的相关性惩罚，该惩罚旨在与 36 天窗口内被 Slashing 的验证者数量成比例地升级。如果只有少数验证者被 Slashing，则惩罚很小。但是，在大规模 Slashing 事件中（无论是通过协调的不当行为还是共享的基础设施故障），惩罚会急剧增加，并且在最坏的情况下，可能会导致验证者损失几乎全部 Staking 余额。

尽管 Slashing 在以太坊协议中占据中心地位，但在实践中却极为罕见。截至 2025 年 5 月，在 131 起事件中，只有 484 个验证者（不到验证者总数的 0.05%）被 Slashing。这些事件通常源于影响多个验证者的单个错误，通常是由于运营商错误或软件错误造成的，而不是恶意造成的。

最大的 Slashing 事件发生在 2023 年 11 月，当时 Bitcoin Suisse 有 100 个验证者因与非活动相关的罪行而被 Slashing ，每个验证者损失了 1 ETH。

迄今为止，以太坊上没有 Slashing 事件威胁到协议的整体完整性。这表明，虽然 Slashing 是一种必不可少的威慑力量，但其实际强制执行并不频繁，并且验证者生态系统已在很大程度上内化了避免这些惩罚所需的行为。

Cosmos

Cosmos 和基于 Cosmos SDK 的链（例如 Cosmos Hub）将 Slashing 实施为一种内置安全机制，主要针对两个故障：双重签名和延长停机时间。这些 Slashing 规则旨在强制执行协议的安全性和活跃性属性。

在同一高度签署两个不同区块的验证者将面临立即惩罚。任何参与者都可以提交链上证据证明其违规行为，一旦经过验证，验证者的 5% 的 Staking 代币将被自动 Slashing，并被置于墓碑状态，这意味着他们将被永久从活动验证者集中删除，并且无法重新进入。一旦进入墓碑状态，验证者及其委托人都必须等待取消绑定期才能重新委托其权益。虽然处于墓碑状态的验证者运营商可以使用新密钥重新启动，但他们必须从头开始重建其声誉和委托。

Cosmos 还通过自动 Slashing 来强制执行活跃性，以应对长时间的停机时间。如果验证者签署的过去 10,000 个区块中少于 5%，则会被视为非活动状态，并处以 0.01% 的权益 Slashing 罚款。虽然相比之下微不足道，但这种强制执行是严格且不可谈判的，从而确保验证者保持正常运行时间并可靠地参与共识。

有趣的是，一些验证者选择将这种较小的惩罚视为自愿停止运营的成本，认为损失微不足道。

虽然 Cosmos SDK 网络共享标准默认 Slashing 参数，但各个链可以修改或扩展这些规则，以反映其自身的安全假设和风险模型。这种灵活性允许每个网络根据其验证者集大小、去中心化目标或预期容错来校准其 Slashing 系统。57 个基于 Cosmos SDK 的主网上的 Slashing 活动 提供了对整个生态系统中强制执行的更广泛的看法：

• 12,143 次与停机相关的 Slashing
• 111 次双重签名 Slashing
• 326 次其他违规行为
• 12,580 次 Slashing 事件总数

这些数据表明，虽然双重签名很少见且受到严厉惩罚，但停机 Slashing 更为频繁，并且主要被视为一项常规运营成本。

结论

Slashing 仍然是区块链行业中争论最多且情绪最激烈的议题之一。每当出现新的验证者不当行为或激励错位形式时，对 Slashing 的呼吁就会迅速跟进。很容易理解为什么在表面上，Slashing 似乎是一种强大的威慑手段，提供了一种直接的链上机制来惩罚不良行为者并维护网络完整性。

然而，正如本文所说明的那样，程序化 Slashing 远非解决不当行为的灵丹妙药。其有效性取决于罪行是否明确且可证明，但在复杂的现实情况下，这些条件并不总是容易满足的。在证据不明确或可以解释的情况下进行 Slashing 会带来惩罚诚实行为者、破坏信任和可能造成比试图防止的违规行为更大的危害的风险。

可以说，自动化形式的 Slashing 给网络带来的最大价值是对利益相关者的心理影响。即使任何形式的违规行为（无论多么罕见）都可能造成经济损失，也足以促使规避风险的 Staker 将其委托分散到多个验证者，同时激励运营商投资于多样化、独立的基础设施。

更多资源

• Slashing：灵丹妙药还是潘多拉魔盒？ - Tim Roughgarden，Accelerate Conference
• 无许可共识的经济限制 - Eric Budish、Andrew Lewis-Pye、Tim Roughgarden
• 负责任的活跃性 - Andrew Lewis-Pye、Joachim Neu、Tim Roughgarden、Luca Zanolini

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