Filecoin检索，土星Saturn奖励模拟（连载3）

奖励分配设计

在讨论在节点运营商之间分配奖励的选项之前，我们努力满足一些原则：

简单胜过复杂 → 我们只会在复杂性达到目的时才增加复杂性，因此，我们会尝试构建实现目标的最简单流程。

有限奖励 → 由于我们仍处于测试阶段，我们应该限制每日奖励以避免在 DDoS 攻击和其他异常行为的情况下超支。

激励可靠且高效的服务→这是我们在设计激励措施时关心的两个主要属性。首先，我们希望运营商能够以快速的下载时间提供大量检索服务。检索量以每天服务的总 TB 量来衡量，而下载时间以首字节时间 (TTFB) 来衡量。其次，我们希望操作员可靠且优雅地失败（这对于 L1 比 L2 更重要）。

激励诚实 → 应激励操作员报告自己的错误并如实记录自己的日志

对自由市场的偏好 → 我们尝试利用自由市场机制和供求关系来避免为内容交付设定价格。因为我们不知道 Saturn 节点在运行 Saturn 时会产生的实际成本，所以我们需要允许一些价格发现。新服务的定价是一个难题，当我们存在价格不确定性时，让市场决定市场是一个很好的设计。

奖励池

奖励池是一组预留给节点运营商的 Filecoin。这个想法是，在每一天，我们将使用这个奖励池的一部分，并将其分配给当天提交给网络的资源。

拥有奖励池可以让我们实现两件事：

我们保证有有限的奖励有有限的奖励，因为我们不能花费比池中已有的更多的钱。

我们允许卖方进行价格发现。特别是，我们每天都会给出一定的预算，我们要求节点运营商决定他们愿意为该预算贡献多少资源。当网络达到平衡时，我们将能够计算节点运营商以什么价格评估他们的资源以及我们需要向未来客户收取多少费用。

定义奖励池时首先要考虑的是它应该是预定义的还是可变的。在预定义池中，在给定时间间隔内要支付的全部奖励金额在开始时就已定义，并且不会改变，与网络状态无关。一个常见的例子是比特币的铸造模型，其中要支付的奖励总额在协议中定义并且是完全可预测的。

另一方面，在未预先定义（即可变）的池中，要分配的奖励总量可能会因网络增长或/和客户加入而发生变化。土星的一个例子是这样一种情况，内容发布者正在加入并预先支付使用该服务的费用。在这种情况下，他们将为不断增长的奖励池提供资金，新客户的加入会导致总奖励池的增加。变量池似乎很适合 Saturn，主要有两个原因：

由于 Saturn 有望成为一个内容交付市场，让客户为网络提供资金是建立可持续奖励流的最直接方式。

由于奖励将取决于引入网络的资金，所有参与者都被激励“出售”Saturn 并为其使用做出贡献。

然而，可变池的缺点是不可预测，这可能会阻止节点运营商进行大量的前期投资。另一种选择是拥有一个混合池，其中包含一个预先确定的基本组件和一个可变组件。基础部分将由固定的初始 Filecoin 池提供资金，而可变部分将由加入网络的新客户提供资金。这样，基础池提供了更多的可预测性，而可变池则鼓励增长和采用。这是为土星选择的设计。我们有协议实验室投资的初始数量的 FIL，旨在启动网络并在开始时提供稳定数量的奖励。然后，客户进来，他们的 FIL 将被添加到池中，从而继续为操作提供资金。

与此考虑相关的是池支付分配的定义. 对于给定的新资金流入奖励池，我们需要定义每天如何分配总资金以支付奖励。比特币等区块链使用指数衰减模型，其中挖矿奖励随时间呈指数级减少。这种模式有利于早期采用者，使网络在一开始就实现更快的增长。另一种选择是在整个客户协议期间平均分配总资金，这是最简单的方法。另一种方法是将奖励分配与网络的增长联系起来（例如，网络提供的总带宽）。这种设计的优势在于可以使激励与增长保持一致，因为运营商希望共同发展网络以获取更大的回报。它还减少了较大奖励对早期采用者的影响，并使奖励随着时间的推移或多或少保持不变。这个问题进一步已在模拟部分讨论，并且是模拟期间测试的设计选项之一。

第三个考虑是我们应该有一个池还是应该拆分。拆分意味着我们会将特定数量的 Filecoin 分配给特定的节点组（L1 与 L2s）或特定的激励措施（例如，速度和可靠性）。

拥有多个池可以让我们在无需更改奖励分配公式的情况下调整激励措施。例如，如果我们希望激励网络降低平均 TTFB，我们可以增加分配给快速检索的池，因此，将为该特定行为分配更多奖励。多个池还允许客户根据他们希望获得的服务类型支付不同的费用。例如，客户可以将更多的钱投入“速度”池中以激励更快的交付。

多个池可以提供帮助的另一个领域是基于区域的定价。如果我们发现各地区的成本差异很大，并且我们希望激励特定地区的增长，那么每个地区都有奖励池是实现这一目标的一种干净方式。

牢记简单胜过复杂的原则，拥有一个池似乎是开始的最佳方法。这并不意味着不能在以后的版本中重新考虑这个想法。然而，对于第一个版本，潜在的收益并不能弥补增加的复杂性。

处罚

正如第一部分所讨论的，惩罚可以成为激励诚实的强大驱动力。然而，为了使激励有效，惩罚需要足够大，以使被发现的风险无利可图。换句话说，考虑到检测概率，提交虚假/篡改日志的预期奖励应低于诚实的预期奖励。这是我们在模拟中测试不同奖励机制时将建模的指标之一（下一节中有更多详细信息）。

独立于惩罚量和所需的调整，我们可以想到四种主要的惩罚机制，每种机制的惩罚范围都在增加：

从奖励计算中删除标记的日志。在这种机制中，我们只是忽略了标记的日志，因此，节点运营商的奖励会略有减少，因为我们忽略了虚假日志。

对标记节点的总奖励给予惩罚。此处对预期支付给节点运营商的总奖励应用一般惩罚。这是一种个体激励，直接针对节点的预期奖励。此外，此设置允许我们惩罚只能在节点级别检测到的行为（例如，服务的请求数量高得离谱）。

根据 swarm 中存在的标记实体数量对 L1 节点进行惩罚。该机制旨在阻止 L1 节点与其集群之间的串通。通过根据集群的行为方式惩罚 L1 节点，我们激励 L1 节点可靠地报告他们的集群的表现。

根据网络有多少标记的活动对整个网络进行惩罚。通过将诚实作为网络的集体目标，这是一种范围更广的机制。因此，它应该阻止节点之间的勾结，并为网络“作弊”建立问责制。它还将阻止节点攻击他们视为竞争对手的其他节点，以获得更大的奖励。

请注意，这些机制不是排他性的，我们可以同时使用不同的机制。例如，我们可以删除标记的日志，并在删除虚假日志后对操作员的总奖励给予额外的惩罚。

惩罚范围和每次惩罚的确切数额将是模拟中测试的重要组成部分。

关于惩罚的另一个重要考虑因素是它们是否应该只减少未来的收益，或者我们是否应该要求节点提供抵押品并对抵押品施加惩罚。拥有抵押品的优势在于需要节点运营商做出更高的承诺，同时利用他们的损失规避。另一方面，抵押品的缺点是增加了节点运营商的进入壁垒。

考虑到该系统的第一次迭代旨在启动网络并了解人们将如何使用（和滥用）Saturn，低准入门槛似乎更为重要。因此，我们建议一开始不要有任何抵押品，并重新评估其对未来迭代的需求。

服务评分函数

服务评分函数是一种将服务指标（例如带宽、节点类型或 TTFB）映射为实数定义了给予特定节点运营商的奖励比率。秒我秒我我我

更具体地说，如果我们有个节点 (，要分配的奖励数量和节点的服务指标由定义，服务评分函数是一个函数使得：n�我=1,2,...,n我=1,2,...,�R�我我米我∈米米我∈米小号:米→R小号:米→�

的奖励为我我r我=小号(米我)⋅R�我=小号(米我)⋅�

∑n我=1小号(米我)=1∑我=1�小号(米我)=1

在详述评分函数之前，我们需要定义服务指标。在土星，服务可以通过三个主要指标来衡量：

带宽 — 在给定时间间隔内从 Saturn 传输到其最终用户的字节数。这是我们想要评分的主要指标，因为它对网络的“使用”进行编码，并且是节点运营商成本的主要驱动因素。

首字节时间 (TTFB) 和总下载时间——我们希望在 Saturn 中看到的行为之一是快速内容交付，因此，内容交付速度是一个重要的激励向量。我们衡量它的一种方法是通过最终用户记录的 TTFB 和总下载时间。请注意，由于我们尚未从最终用户那里收集日志，因此我们需要使用编排器执行的请求样本来估计平均 TTFB 和下载速度。此外，加入的客户（即内容发布者）将能够收集这两个指标，因此我们还可以利用他们的日志来估计平均 TTFB 和下载速度。

正常运行时间——可靠性是我们希望在土星上看到的另一种行为。L1 节点应在线，并在发生故障时向网络发出警告并优雅地失败。这里的另一点是，在奖励正常运行时间的同时，我们也在某种程度上奖励可用的服务。前两个指标侧重于最终用户体验的实际服务，而正常运行时间则考虑节点为网络执行服务的可用性。

还有另一种行为我们这里不讨论——地域覆盖。通过提供更大的奖励来激励某些地区将更容易使用多个池来解决。一旦我们对用户和节点运营商的位置有了更清晰的认识，这将在以后的版本中解决。

带宽评分功能

在对带宽进行评分时，带宽越高，奖励的份额应该越大。因此，不仅评分函数需要满足上述定义的标准，而且还需要严格单调递增。我们可以使用带宽分数的正幂来实现这一点。更具体地说，如果我们有：

n�个节点运算符 ( i=1,2,...,n�=1,2,...,� )

bi�� ：节点运营商i�在当前时代提供的总带宽

在当前时期支付给节点运营商i�的奖励由以下评分函数定义：S

(bi):=bki∑nj=1bkj�(��):=���∑�=1����

其中是任何正实数。来奖励奖励分配的一些灵活性。下图绘制了给予单个节点运营商的奖励与他们贡献的带宽比率之间的比率。每条线代表一个不同的。k∈R+�∈�+k�k�

使用超线性评分函数 ( )，奖励增加的速度快于贡献的带宽份额。这激励运营商提高他们的服务，因为他们通过增加他们服务的带宽获得越来越多的回报。另一方面，对于次线性函数 (，奖励份额的增长速度慢于提供的带宽份额。这会刺激更高的奖励分配，因为通过提供更多带宽来获得更大份额的奖励变得越来越困难。k>1�>1k<1�<1

的最优值是多少。因此，这将是我们将在模拟分析期间调整的参数。k�

下载次数计分功能

对于 TTFB 和下载速度，我们不能直接使用我们用于带宽的函数。原因有两个：

下载时间越短越好，这意味着评分函数需要单调递减。

节点可能对网络的下载时间做出积极和消极的贡献。换句话说，如果很多节点以高次数加入网络，它们会降低整个网络的性能。另一方面，对于带宽，节点只能增加更多带宽，因此它们不会在该特定指标上对网络产生负面影响。

这里的另一个重要考虑因素是速度非常低的单个请求通常对网络来说不是很有价值。只能说当很大一部分节点运营商速度很快时，Saturn 提供了一种快速的服务。考虑到这一点，我们对激励单个节点无限减少下载时间不感兴趣，而是希望整个网络优于每个下载时间指标的特定阈值。

对这种激励进行编码的一种方法是使用给定节点运营商的请求百分比，其中 TTFB 和总下载时间都低于某些预定义的阈值。有了这个新指标，我们可以使用为带宽定义的完全相同的函数。同时，我们避免奖励节点运营商在少数请求上实现极快的速度，而是根据他们的请求中有多少比阈值更好来奖励。

为什么我们使用百分比而不是请求数？如果我们选择请求的数量，我们将间接考虑此激励中的网络使用情况。速度始终低于阈值的两个节点运营商将仅根据他们服务的请求数量获得不同的奖励。

正常运行时间评分功能

我们目前有一个名为的表health_check_failures，用于存储来自节点的“停机”事件的数据。每分钟，编排器都会向每个节点发送健康检查并存储结果。未通过健康检查的节点将记录到health_check_failures表中。

我们可以从这些信息中估计停机时间。该提议是计算每个给定时间内健康检查失败的百分比。让di��代表节点i�的健康检查失败百分比。我们将ui=1−di��=1−��定义为节点i�的正常运行时间估计。

举个例子，假设我们每小时进行一次付款。我们每小时进行 60 次健康检查（每分钟 1 次）。如果节点k�未能通过 20 次健康检查，则：

dk=2060=13⟹uk=1−dk=23��=2060=13⟹��=1−��=23

请务必注意，此方法仅提供正常运行时间的估计值。它对节点停机时间的惩罚方式也很激进，因为它假设如果一个节点未通过健康检查，那么它必须停机一整分钟。此外，它会错过健康检查之间发生的停机事件。

结合评分功能

既然我们已经描述了哪些函数可用于对每个服务进行评分，我们需要定义如何将服务组合到一个单一的评分函数中。

假设我们有两个我们希望合并的服务指标，它们各自的评分函数是和分别。在这种情况下，我们可以定义以下两种方式将两个单独的评分函数组合成一个新的评分函数：小号1(A我)=A米我∑nj=1A米j�1(��)=���∑�=1����小号2(b我)=bn我∑nj=1bnj�2(��)=���∑�=1����

线性组合：S(ai,bi)=q⋅S1(ai)+(1−q)⋅S2(bi)�(��,��)=�⋅�1(��)+(1−�)⋅�2(��) ，其中 \(q \ in [0,1]\)

直接乘法：S(ai,bi)=ami⋅bni∑nj=1amj⋅bnj�(��,��)=���⋅���∑�=1����⋅���

线性组合的优点是易于为每个服务指标分配相对值（通过更改q�参数）。它类似于有两个奖励池，因为服务指标a�接收固定数量的奖励qR��而服务指标b�接收剩余的。它也很容易解释，这是一个巨大的优势。

另一方面，直接乘法激励所有服务之间的性能更加平衡。因为分数是相乘的，如果其中一个分数非常小，它对总奖励的影响将比线性组合所经历的影响更大。

目前尚不清楚最佳方法，这是我们将通过模拟测试的另一个功能。然而，除非有强烈的论据支持直接乘法方法，否则线性组合方法的可解释性和灵活性使其成为更好的选择。

处罚后的调整

让我们从一个例子开始本小节。假设一个新的运营商加入土星并开始尝试通过向其自己的节点发出大量虚假请求来玩弄系统。前两天后，欺诈检测系统会标记该操作员并进行处罚。这意味着原本分配给这个欺诈节点运营者的奖励将不会得到支付。

现在，让我们考虑一下这个例子中剩下的运算符会发生什么。即使它是伪造的，他们也在为网络“贡献”带宽。在计算整个网络的奖励时，会考虑欺诈运营商记录的流量，因此，部分奖励被“分配”给该运营商。这意味着在欺诈性运营商添加日志期间，分配给其余运营商的总奖励将低于该运营商从未加入网络的情况。如果记录的虚假流量占网络总流量的很大一部分，则此问题可能会进一步恶化。

因此，我们达到了一个可能的攻击向量，其中欺诈节点能够通过简单地加入和添加具有虚假流量的日志来减少剩余运营商的奖励。该运营商不会为自己获得任何奖励，但能够减少给予其余运营商的价值，这令人担忧。因此，为避免这种情况，当节点运营商被标记并表现出奇怪的高带宽服务时，我们需要调整其余运营商的奖励，以避免显着降低他们自己的奖励。

我们几乎没有选择来实现这一目标。在计算给定时间段的奖励份额时，我们将获得所有节点运营商的汇总绩效指标。在运营商被标记后，我们可以对聚合数据做三件事来调整奖励：

完全排除标记运算符的行。

好处：适用于没有先前数据的运营商，并减少因处罚而未分配的奖励金额

缺点：当诚实节点被标记时，运营商会得到奖励。

用该操作员的历史平均值替换标记操作员的行。

好处：当诚实节点被标记时，减少对运营商的奖励。

缺点：对没有先前数据的操作员不起作用。

用该时间段的网络平均值替换标记运营商的行。

好处：适用于没有先前数据的操作员，并在标记诚实节点时减轻对操作员的奖励。

缺点：当小节点被标记时，运营商将获得较少的奖励。

第二个选项被自动排除，因为它不能用于没有良好服务历史的节点。这给我们留下了选项 1 或 3。选项 1 更适合资本分配，因为它将导致更高份额的奖励分配给未标记的运营商。另一方面，选项 3 避免了在标记诚实节点时网络获得奖励的不平衡激励。然而，由于运营商无法控制欺诈检测系统，我们认为选项 1 设计的简单性和导致更高资本分配的事实取代了标记诚实节点时可能出现的问题。

L2s 支出

在第一部分中，我们描述了 L1 和 L2 节点预期如何在土星内交互。在硬件要求和服务期望方面，运行 L1 节点比运行 L2 节点要求更高。他们是直接向最终用户提供请求并处理所有发送到 Saturn 的请求的人。另一方面，L2 节点围绕单个 L1 节点形成集群，并作为其缓存的扩展。它们是家用机器，硬件要求低，可以随心所欲地离线。

将 L2 群视为其 L1 节点的缓存扩展是设置支出的一个很好的类比。在某种程度上，L2 有助于 L1 节点的性能。群体越大、性能越好，L1 节点交付内容的能力就越好。因此，L1 与群体分享他们收到的一些奖励是有意义的。特别是，我们可以使用之前的评分函数在 L1 节点之间分配奖励。然后，根据每个 L2 对 L1 提供的服务的贡献程度，分配的一部分奖励将传递给蜂群。

考虑到这一点，要回答的问题是我们如何衡量 L2 节点对 L1 节点提供的服务的贡献？当向 L1 节点提交请求时，有两种可能性 - L1 节点缓存了内容，或者没有缓存。如果内容被缓存，那么集群对服务没有任何贡献。然而，如果内容没有被缓存，L1 节点将向它的 swarm 请求数据。缓存中有该内容的 L2 节点将开始将其发送到 L1 节点，因此，从该请求获得的部分奖励应与发送该内容的 L2 运营商共享。

因此，我们可以使用使用缓存的 L1 节点提供的带宽份额来分配 L2 和 L1 节点之间的奖励。如果R�是在给定时期分配的总奖励，而c�是使用缓存的 L1 的带宽比率，那么支付给 L2 节点的总奖励将是R∗=(1−c)⋅γ⋅R�∗=(1−�)⋅�⋅� ，对于γ∈[0,1]�∈[0,1] 。请注意，我们并未将 100% 的缓存未命中请求所产生的奖励给予 L2，因为即使在这些请求中，L1 也扮演着非常重要的角色。因此，L2s 仅接收参数γ�中编码的部分奖励。

一旦我们有了，我们就可以使用相同的评分函数在 L2 节点之间这里需要注意的是，L2 不需要正常运行时间，因此，我们可以降低其正常运行时间阈值或完全删除评分功能。