处罚
安全考虑
验证者集合是实际拥有质押的密钥集合，这些密钥会因双重签名或其他不当行为而被处罚。我们通常将链的安全性视为验证者集合的安全性。每条链的情况不同，但这是我们的黄金标准。即使是IBC，其安全性也仅限于参与的两个验证者集合中的最小值。
Eth桥中继是与main injective daemon 一起运行的二进制文件，由验证者集合管理。它纯粹作为代码组织的一部分，负责签署以太坊交易，并观察以太坊上的事件并将其引入 Injective 链状态。它使用以太坊密钥签署发送到以太坊的交易，并使用 Injective 链账户密钥签署来自以太坊的事件。我们可以对任何由验证者集合运行的Eth签名者签署的错误消息添加处罚条件，并能够提供与验证者集合相同的安全性，只是由不同的模块检测恶意证据并决定处罚的程度。如果我们能证明由验证者集合的任何Eth签名者签署的交易是非法或恶意的，那么我们可以在 Injective 链侧进行处罚，并可能提供验证者集合的100%安全性。请注意，这还可以访问3周的解锁期，即使他们立即解锁，也允许证据进行处罚。
以下是我们在Peggy中使用的各种削减条件。
PEGGYSLASH-01:签署虚假的验证者集合或交易批次证据
该惩罚条件旨在阻止验证者对从未存在于 Injective Chain 上的验证者集合（validator set）和随机数（nonce）进行签名。其通过一种证据机制实现，任何人都可以提交一条消息，其中包含验证者对伪造的验证者集合的签名。此机制旨在实现以下效果：如果一个验证者联盟意图提交伪造的验证者集合，其中一名叛变者可能导致整个联盟的验证者受到惩罚（slashed）。
实现注意事项：
该惩罚条件最复杂的部分在于确定某个验证者集合是否从未存在于 Injective 上。为了节省空间，我们需要清理旧的验证者集合。我们可以在键值存储（KV store）中维护一个验证者集合哈希到布尔值的映射，并利用该映射来检查某个验证者集合是否曾经存在。这种方法比存储整个验证者集合更高效，但其增长仍然是无界的。或许可以使用其他加密方法来减少该映射的大小。此外，可以考虑从该映射中删除非常旧的条目，但任何删除操作都会降低该惩罚条件的威慑力。
当前实现的版本存储了所有过去事件的哈希映射，这比存储完整的批次或验证者集合更小，并且不需要频繁访问。一个可能但尚未实现的效率优化是，在一定时间后从该列表中移除哈希值。但这需要为每个哈希存储更多的元数据。
目前，中继器（relayer）尚未实现自动证据提交功能。当签名在以太坊上可见时，再进行惩罚已经无法防止桥接劫持或资金盗窃。此外，由于执行此操作需要验证者集合中 66% 的多数同意，控制多数的一方可能会直接拒绝提交证据。该惩罚条件最常见的应用场景是破坏试图控制桥接的验证者联盟，通过增加他们之间的信任难度，使其难以协调实施此类盗窃行为。
盗窃行为将涉及交换可惩罚的以太坊签名，这为联盟中的任何叛变者手动提交此类消息提供了可能性。
目前，该功能在状态中实现为一个不断增长的哈希数组。
PEGGYSLASH-02: 未能签署交易批次
当验证者在交易批次（transaction batch）由 Peggy 模块创建后的 SignedBatchesWindow 时间窗口内未能对其进行签名时，将触发该惩罚条件。此机制旨在防止以下两种不良情况的发生：
验证者未运行正确的二进制文件 验证者可能未在其系统中运行正确的二进制文件，导致其无法履行签名职责。
验证者联盟拒绝签名 超过 1/3 的验证者可能解除绑定（unbond）并拒绝签署更新，从而导致任何交易批次都无法获得足够的签名以提交至 Peggy 以太坊合约。
PEGGYSLASH-03: 未能签署验证者集合更新
当验证者未能对由 Peggy 模块生成的验证者集合更新（validator set update）进行签名时，将触发该惩罚条件。此机制旨在防止以下两种不良情况的发生：
验证者未运行正确的二进制文件 验证者可能未在其系统中运行正确的二进制文件，导致其无法履行签名职责。
验证者联盟拒绝签名 超过 1/3 的验证者可能解除绑定（unbond）并拒绝签署更新，从而导致任何验证者集合更新都无法获得足够的签名以提交至 Peggy 以太坊合约。如果他们阻止验证者集合更新的时间超过 Injective Chain 的解绑周期（unbonding period），他们将不再因提交伪造的验证者集合更新和交易批次（PEGGYSLASH-01 和 PEGGYSLASH-03）而受到惩罚。
为了应对第二种情况，PEGGYSLASH-03 还需要惩罚那些已停止验证但仍处于解绑周期内的验证者，惩罚时间最长可达 UnbondSlashingValsetsWindow 区块。这意味着当验证者离开验证者集合时，他们需要至少保持其设备运行 UnbondSlashingValsetsWindow 个区块。这对于 Injective Chain 来说是不常见的，可能不会被验证者接受。
当前 UnbondSlashingValsetsWindow 的值为 25,000 个区块，大约为 12-14 小时。我们根据以下逻辑确定这是一个安全的值：只要每个离开验证者集合的验证者至少签署一个不包含他们的验证者集合更新，就能保证中继器（relayer）能够生成一系列验证者集合更新，将链上的当前状态转换为最新状态。
需要注意的是，如果能够在共识代码内部执行以太坊签名，PEGGYSLASH-02 和 PEGGYSLASH-03 都可以被取消而不会降低安全性。这是 Tendermint 的一个较为有限的功能增强，但将显著减少 Peggy 的惩罚风险。
PEGGYSLASH-04: 提交错误的以太坊预言机声明（当前已禁用）
以太坊预言机代码（目前主要集中在 attestation.go 文件中）是 Peggy 模块的关键组成部分。它使 Peggy 模块能够了解以太坊上发生的事件，例如存款（deposits）和已执行的交易批次（executed batches）。PEGGYSLASH-03 旨在惩罚那些提交了从未在以太坊上发生的事件的声明的验证者。
实现注意事项
我们判断一个事件是否在以太坊上发生的唯一方式是通过以太坊事件预言机本身。因此，为了实现此惩罚条件，我们会惩罚那些在与 >2/3 验证者观察到的事件具有相同随机数（nonce）的情况下提交了不同事件声明的验证者。
尽管初衷良好，但该惩罚条件可能不适用于大多数 Peggy 应用场景。这是因为它将安装 Peggy 的 Injective Chain 的正常运行与以太坊链的正常运行绑定在一起。如果以太坊链发生严重分叉，不同验证者可能会在同一事件随机数下看到不同的事件，并因此受到惩罚，尽管他们并无过错。大规模的不公平惩罚将对 Injective Chain 的社会结构造成严重破坏。
PEGGYSLASH-04 的必要性分析
该惩罚条件的实际效用在于，如果 >2/3 的验证者形成一个联盟，在某个随机数下提交虚假事件声明，联盟中的部分成员可能会叛变并在同一随机数下提交真实事件声明。如果有足够多的联盟成员叛变，使得真实事件被观察到，那么剩余的联盟成员将因此惩罚条件受到惩罚。然而，这通常需要超过一半的联盟成员叛变。
如果没有足够多的联盟成员叛变，则两个事件都不会被观察到，以太坊预言机将停止运行。这种情况比 PEGGYSLASH-04 实际被触发的场景更为可能。
此外，在联盟成功的情况下，PEGGYSLASH-04 可能会针对诚实验证者触发。这可能使正在形成的联盟更容易威胁那些不愿加入的验证者。
PEGGYSLASH-05: 未能提交以太坊预言机声明（当前已禁用）
PEGGYSLASH-05 与 PEGGYSLASH-04 类似，但其针对的是未提交已被观察到的预言机声明（oracle claim）的验证者。与 PEGGYSLASH-04 不同，PEGGYSLASH-05 旨在惩罚那些完全停止参与预言机机制的验证者。
实现注意事项
遗憾的是，PEGGYSLASH-05 与 PEGGYSLASH-04 存在相同的缺点，即它将 Injective Chain 的正确运行与以太坊链的运行绑定在一起。此外，它可能无法有效激励正确的行为。为了避免触发 PEGGYSLASH-05，验证者只需复制接近被观察到的声明即可。虽然可以通过提交-揭示机制（commit-reveal scheme）来防止这种复制行为，但“懒惰的验证者”仍然可以轻松使用公共的以太坊全节点或区块浏览器，这对安全性影响类似。因此，PEGGYSLASH-05 的实际效用可能非常有限。
PEGGYSLASH-05 还引入了显著的风险，主要围绕以太坊链的分叉问题。例如，最近 OpenEthereum 未能正确处理柏林硬分叉（Berlin hardfork），由此导致的节点“故障”对自动化工具完全不可检测。节点并未崩溃，因此无需重启，区块仍在生成，尽管速度极慢。如果这种情况发生在 Peggy 运行且 PEGGYSLASH-05 激活的情况下，将导致这些验证者被从集合中移除，可能会引发链的混乱时刻，因为数十个验证者因几乎无过错而被移除。
在没有 PEGGYSLASH-04 和 PEGGYSLASH-05 的情况下，以太坊事件预言机仅在 >2/3 的验证者自愿提交正确声明时继续运行。尽管反对 PEGGYSLASH-04 和 PEGGYSLASH-05 的论点很有说服力，但我们必须决定是否能够接受这一事实。或者，我们必须接受 Injective Chain 可能因以太坊生成的因素而完全停止的可能性。
Last updated