Gloas 熔断器

节点维护了一份白名单构建者列表和一份黑名单构建者列表，二者服务于不同的目的。黑名单中的构建者提交的出价将被拒绝；如果这些构建者是已知的，则不会通过直接连接与其联系。另一方面，白名单构建者即使在全局断路器触发时也会获得优先对待。

在 gloas 中有三种类型的构建者：通过 P2P 连接的构建者，它们在很大程度上是匿名的；以及通过直接连接联系到的构建者，它们可能是可信的或不可信的。目前尚不清楚市场上是否会出现不可信的直接连接构建者，但我们应该按照它们存在的假设来准备断路器。不可信的构建者可以部署多个密钥、轮换密钥、尝试攻击 payload 市场等。可信的构建者也可以这样做，但它们是成熟机构，有可能会失去市场份额。因此，在某些断路器场景中，实际上回退到可信构建者比立即回退到自行构建更合适。很少有场景下回退到 P2P 出价更可取。

预期断路器场景

有三种情况最有可能成为触发断路器的原因。

大型构建者 bug

这一直是主网上 payload/区块缺失的主要原因。大型构建者赢得了拍卖，但未能交付 payload。在这种情况下，我们可以非常积极地将这类构建者列入黑名单。理由如下。首先，我们可以立即将相应的构建者索引列入黑名单。如果该构建者索引对应的是 P2P 出价者，那么无论如何它都不太可能是大型构建者。在这种类型的场景中，我们希望将单个构建者或单个中继列入黑名单。

客户端 bug

主网上曾发生过 CL 客户端未能产生足够的区块而触发断路器的情况。在 Gloas 上，这很可能不再是问题，实际上，客户端应该是在 payload 缺失（而不是共识区块（以及整个 slot）缺失）时触发断路器。在这种类型的场景中，我们不需要做任何事情。

构建者对网络的攻击

最可能发生这种情况的是不可信构建者，它们要么用不交付 payload 的获胜出价淹没 P2P 堆栈，要么制造类似的活性问题。在这种场景下，我们希望首先回退到可信构建者网络，如果这个回退失败，才会回退到自行构建。

运营者配置

运营者可以在 beacon 节点级别指定白名单和黑名单构建者索引列表。该功能的文档需要详尽，因为构建者索引会被复用，并且该列表可能会逐渐失效。运营者应保守行事，确保列表要么及时更新，要么只添加被高度信任的构建者。

或者，如果大型构建者愿意提供帮助，beacon 节点可以维护一个与每个直接连接 URL 关联的可能的构建者索引列表，以便能够按 URL 而不是按构建者索引进行白名单/黑名单操作。

Beacon 节点跟踪

失败的构建者

beacon 节点将维护一个带有失败记录的构建者列表

type FailedBuilder struct {
    index           BuilderIndex
    failed          uint8
    whitelistEpoch  Epoch
    backOffEpoch    Epoch

}

failed 字段跟踪该构建者连续未交付 payload 的次数。当该构建者索引被列入黑名单时，whitelistEpoch 会被设置为非零值，此时该字段指示该构建者应在何时被重新列入白名单。backOffEpoch 字段也具有类似的含义，它指示 failed 计数器应在哪个 epoch 被再次清零。这样可以持续跟踪白名单构建者的失败情况，以便如果它们继续失败，可以立即被重新列入黑名单，且持续时间更长。

中继

beacon 节点将跟踪通过直接连接联系的端点返回的出价。这些是类似下面的对象

type RelayBuilder struct {
    identifier      string
    indices         []BuilderIndex
}

identifier 字符串可以是所联系的 URL 或代理数据字段。它必须与验证者客户端传递给 beacon 以建立直接连接的数据相同。indices 是从该端点返回的出价中看到的构建者索引。运营者可以通过在命令行中为给定中继标识符传入预期的索引来修改这些列表。这些列表可以由社区维护。对于很少提议区块的居家质押者来说，这个列表基本无用，但对质押池运营者来说则很有意义。

这个列表的要点在于，每当某个构建者索引未能交付 payload 时，FailedBuilder 列表中会添加/更新一条记录，同时还会为由同一中继服务的任何其他构建者创建另一条记录，以便将该中继像单个构建者一样封禁。

额外常量

容错

运营者可以指定一个常量 AllowedFailures，用于规定给定构建者在被列入黑名单之前允许的失败次数。这可以按构建者、中继、构建者组等分别指定。但我会把它当作一个全局常量来写（我认为其默认值应为 0）。

另一个常量是 CriticalFailures，它表示：即使构建者之前被列入白名单，也应当被列入黑名单。这个常量的用法将在下面解释。

退避期

常量 BackOffPeriod 表示在给定构建者没有出价的情况下经过多少个 epoch 后，failed 计数器将被重置为 0。常量 WhitelistPeriod 表示在首次超过 AllowedFailures 的违规情况下，该构建者将被列入黑名单多少个 epoch。

系统性故障

我们设定了 CriticalFailedBuilders 和 CriticalFailedUntrustedBuilders 的阈值，超过之后我们会回退到可信构建者或自行构建。

操作

单个构建者封禁

每当 payload 缺失并且相应的 beacon 区块已被链上超过 60% 的验证者证明时，就会在 FailedBuilder 中为相应的构建者创建或更新一条记录。

如果该构建者已经存在记录，那么我们就递增 failed 计数器。如果该构建者的失败次数超过 AllowedFailures，则将其 whitelistEpoch 设置为当前 epoch 加上 WhitelistPeriod，并将其 backOffEpoch 设置为当前 epoch 加上 BackOffPeriod。如果失败次数达到 CriticalFailures，则我们可以将 whitelistEpoch 或 backOffEpoch 设置得更高，设为一个高得多的常量，或者干脆一直持续到运营者重启节点（除非该构建者广播了有效的 payload，使 failed 计数器重置为零）。

一个典型的配置可以是 AllowedFailures = 0、CriticalFailures=2、WhitelistPeriod=1 和 BackOffPeriod=5，这样在单次失败时，我们只将该构建者列入黑名单一个 epoch；但如果在 5 个 epoch 内连续两次失败，该构建者将被永久封禁，直到重启。

如果失败的构建者是所跟踪的某个 RelayBuilder 对象中索引的一部分，则相同的流程将应用于该列表中的所有构建者。例如，如果节点将某个中继跟踪为 indices = [1,2] 的 RelayBuilder，而构建者 1 未能广播 payload。节点将像上面那样跟踪一个索引为 1、failed=1 的 FailedBuilder，以及另一个索引为 2、failed=0 的记录，但两者都可能被列入黑名单，即使 failed=0。

单个构建者列入白名单

如果收到了来自失败列表中某个构建者的 payload，我们会立即将其列入白名单并将其从列表中移除（除非它是一个中继的一部分）。这可以进一步设计为设置一个隔离期，观察它是否再次失败并以特殊方式跟踪，但在我看来这有些过度设计。

如果该构建者是一个中继的一部分，我们只需设置 failed=0，当同一个中继的所有成员都是 failed=0 时，我们将它们全部列入白名单。

系统性故障

当节点跟踪到 CriticalFaildeUntrustedBuilders 个或更多 whitelistEpoch 高于当前 epoch（即当前处于黑名单状态）的构建者时，节点将不再接受 P2P 出价，而只回退到向可信构建者请求出价（可以是直接连接，也可以是运营者在启动时指定的白名单索引）。

当被列入黑名单的构建者数量达到 CriticalFailedBuilders 个或更多时，节点将回退到自行构建。

请注意，这里不再跟踪一个 epoch 内错过的 slot 或连续错过的 slot；通过简单地跟踪被封禁的构建者数量并对其保持足够保守，这两个指标应当已经得到了覆盖。

这些指标的合理默认值是 CriticalFailedBuilders = 7 和 CriticalFaildeUntrustedBuilders = 3。

结论

通过上述设计和前面提到的最常见场景，我们将得到以下结果。

在单个大型构建者 bug 的情况下，该构建者将被立即封禁一个 epoch，将损害限制在该 epoch 内的一个区块。如果该构建者在下一个 epoch 仍然存在 bug，则将被永久列入黑名单。除此之外不会对网络造成损害。

如果存在阻止区块产生的客户端 bug，则不会触发断路器的任何变更。

如果存在来自不可信构建者的攻击，那么在 3 次出价失败后，节点就会回退到可信构建者。

当然，如果每个人都使用类似的设计，这套方案按现状就能正常工作。如果节点使用完全独立的设计，默认值仍然足够合理，因此 Prysm 节点将首先回退到可信构建者，并且只在关键情况下才回退到自行构建。同时，退避机制允许节点在某个构建者失败后的一段时间内没有赢得出价时，合理地重新尝试该构建者。

• 原文链接： potuz.net/posts/gloas-ci...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～