Filecoin检索，土星Saturn服务Treasury的规格（连载2）

Treasury 是 Saturn 的服务，负责处理节点运营商（以及未来的客户）提交的传输日志，并相应地分配奖励。

当用户从 Saturn 的网络请求一段内容时，Saturn 不会从用户那里收集数据。相反，Saturn 直接从为请求提供服务的节点运营商处获取检索日志。

由于节点运营商为他们提供的检索付费，因此存在一个明确的攻击向量，运营商可以在其中更改这些日志以利用网络并收集更大份额的分配奖励。

因此，财政部需要确保节点运营商获得正确的激励，并且我们有能力检测欺诈日志并惩罚行为不端的运营商。

下图说明了 Treasure 服务的结构：

Treasury 从日志服务接收数据，并开始在日志检测模块中处理它。日志检测模块负责标记看起来可疑的日志和操作员，并将这些标记的实体发送到奖励分配模块。

日志检测模块的方法将从简单的检测技术开始（例如启发式和简单的异常检测）。然后，随着我们从 Saturn 收集更多数据并从真实用户那里获得经验，我们将迭代和改进检测模型。

接下来，奖励计算器是负责处理转账日志和其他指标，并计算每个节点运营者将获得多少 FIL 的部分。这是财政部的一部分，它将定义节点运营商的主要激励措施，并保证运营商与 Saturn 的长期愿景和目标保持一致。

最后，在所有组件的基础上，我们有监控模块。因为 Saturn 将在敏捷/迭代设置中运行，我们需要能够监控整个支付过程，以改进日志检测模块和奖励计算器。我们需要存储标记的实体和对运营商的支付。

在接下来的部分中，我们将更详细地描述我们想要激励/惩罚的行为以及每个模块如何为实现这一目标做出贡献。

行为和激励

良好的行为

在高层次上，我们希望激励以下行为：

高带宽服务

表现

可靠性

地域覆盖

坚持土星的设计。示例包括 L1 缓存丢失到 L2 和 L2 缓存丢失到 SP。

目前，衡量地理覆盖范围和对土星设计的遵守情况将很棘手，因此，它不在 10 月份财政部发布的范围之内。我们注意到这里的行为是为了将来的迭代。

因此，前三个行为用于设计在 Saturn 节点之间分配奖励的公式。接下来，我们将更详细地讨论这 3 种行为中的每一种行为以及可以使用哪些指标来衡量它们。

高带宽服务

我们想要激励的最重要的行为是具有高带宽的服务。那么 CDN 的主要目标是为用户提供内容，因此，土星在给定时间间隔内交付的数据总量（以字节为单位）应该尽可能高。

此外，高带宽的维护成本很高，这意味着它需要得到适当的激励。因此，我们的目标是使带宽成为对奖励影响最大的指标。

我们可以从传输日志中收集每个请求的总数据服务，我们可以按节点聚合它以获得给定时间间隔内节点服务的总带宽。

表现

我们想要激励的第二个最重要的行为是绩效。我们的意思是节点应该以能够为客户带来良好体验的方式满足请求。考虑到这一点，两个最重要的指标是：

Time to first byte (TTFB) - 第一个请求的字节到达客户端的速度。TTFB 测量节点响应请求的速度。该指标最初将由 Saturn 使用生成的流量进行估算。然后，一旦我们开始集成客户端，我们就可以使用客户端的日志来估计 TTFB。

下载速度——客户端下载所有请求的速度。下载速度衡量节点完成请求所需的时间，因此，用户必须等待多长时间才能收到完整内容。可以使用列从传输日志中获取指标request_duration_sec。

请注意，下载速度通常在客户端受到限制。换句话说，一个节点可能通常能够以 100Mbps 的速度向客户端上传内容，但该节点可能处于蜂窝连接上并且只能以 20Mbps 的速度下载内容。

我们还可以使用其他指标来衡量性能，例如缓存命中率。然而，这里我们关注的是对最终用户真正重要的东西，即 TTFB 和总下载速度。在缓存命中率示例中，缓存命中率越高，TTFB 就越低，这是已经得到奖励的指标。

可靠性

离开网络的节点会降低网络性能和用户体验。例如，当一个节点出现故障时，可能需要长达 60 秒的时间才能检测到该节点出现故障并从网络中移除。Saturn 的 service worker 可以优雅地恢复，尽管性能有所下降。没有 ARC 服务工作者的愚蠢客户端不能，他们的请求可能会失败。

因此，我们想引入一种机制，让节点优雅地告诉网络他们将要下线。如果某个节点不正常下线，我们需要对该节点进行惩罚。如果它正常下线，我们仍然要惩罚它，尽管比不正常下线要少。

我们目前可以从编排器中提取每个节点的正常运行时间数据。这是可信数据，因为服务是集中操作的，数据不是由节点报告的。

不良行为

另一方面，我们要避免的行为主要围绕滥用和欺诈。例子包括：

篡改日志——创建未发生的检索日志或更改真实日志以改进某些变量，例如发送的字节数和请求持续时间。指标节点的一些示例可能是：

请求完成需要多长时间

他们的 TTFB 指标

正常运行时间和状态。例如，节点响应编排器的健康检查，而实际上处于离线状态或对真实用户而言性能下降的状态

他们服务的请求数量

他们为客户提供的字节数

虚假检索 - 运营商或其他参与者进行的检索与网络的真实合法客户不符。

检索返回错误的内容

与良好行为相反，不良行为将被用来惩罚节点。日志检测模块将负责检测行为。在标记特定日志或节点后，我们可以通过不同的方式来惩罚行为不良的节点：

去除欺诈日志，减少对相应节点的奖励

对节点的总奖励应用惩罚

通过限制它能够服务的请求来减少节点的未来奖励

日志检测模块

日志检测模块旨在检测节点运营商提交的任何篡改或虚假日志。由于必须在 Saturn 拥有真正的活跃用户之前设计 Treasury 服务的初始版本，我们从一个简单的基于启发式的检测系统开始，根据用户将如何使用 Saturn 进行操作的合理假设和我们已有的测试数据进行调整。

在 Saturn 发射并收集到更多数据后，我们计划通过改进启发式算法和试验更复杂的检测方法（例如异常检测模型、监督模型和主动学习模型）来迭代这个简单的系统。

独立于检测方法，当我们谈论欺诈行为时，我们可以在两个不同的级别检测它：

1、请求级别：我们查看单个日志的级别，对应于检测看起来不合法的特定请求。这里的一个例子是一个持续时间快得令人难以置信的请求。在此级别，我们筛选来自日志服务的所有个人请求，并标记任何看起来可疑的请求。输出是标记请求的列表及其标记的来源。

2、操作员级别：我们不查明看起来具有欺诈性的特定日志的级别，而是查看各个节点操作员的一般行为。这里的一个例子是一个节点操作员正在记录一个不可能的大量请求。在此级别，我们汇总了每个操作员的原始日志，并标记了任何看起来可疑的日志。输出是已标记运算符的列表及其标记的来源。

启发式

启发式被定义为对我们试图避免的特定行为进行编码的简单规则。在本模块中，我们将对前面描述的两个级别进行试探——请求和节点操作员。

大多数启发式算法都有一个需要设置或调整的阈值。这个阈值取决于我们正在比较的单个指标。例如，如果我们有一个快速请求启发式算法，旨在捕获报告不可能高的 TTFB 值的运营商，则指标将是 TTFB，我们需要为此指标设置一个阈值来编码“不可能高”的内容。

我们可以将此问题解释为搜索单变量异常或异常值。在快速请求启发式的情况下，我们感兴趣的是对于“正常”数据分布来说太小的数据点。在这里，阈值是我们认为数据点“异常”的点。

有两种方法可以设置这些阈值：

1、专家判断：这里我们使用我们对 Saturn 和真实请求如何工作的知识来设置阈值。这对于我们可以轻松定义什么是不可能的情况可能很有用。

2、统计异常值：这里我们使用土星的真实数据来模拟基础指标的统计分布。这假设我们拥有的数据是“正常的”并且将代表未来的请求。一旦我们有了度量的经验分布，我们就可以设置阈值，使得具有一定统计意义的所有落在外面的点都是从不同的分布中采样的。

最后，我们混合使用这两种策略。

奖励计算器

奖励计算器是负责计算支付给节点运营商的模块。我们用于设计模块的 5 个主要原则：

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

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

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

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

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

附件

土星建筑

ARC支出管道

节点将属性会话和 p2p 传输报告发送到日志摄取器。属性会话报告是节点在给定网站上的时长，p2p 传输报告是从一个节点发送到另一个节点的数据量。

记录摄取器完整性检查，但不对这些报告执行欺诈检测。完整性检查报告写入 google BigQuery。

每天一次，每天，簿记员都在运行。bookkeeper 是一个 python 脚本，它遍历 BigQuery 中的所有日志，并且：进行基本的欺诈检测。不规则报告被删除

欺诈检测后，计算收入+费用并将这些计算结果写入单独的 BigQuery 表

根据上述计算结果向客户发放款项并向客户收费。

簿记员将结果写入表：留下书面记录，以及

因此，如果事情因任何原因出现故障或失败，将来可以重新运行支出和收费

簿记员向 PayPal 提交付款，网站获得付款。如果簿记员已经支付给定站点一天的费用（基于非空数据库记录），则该站点将不会再次获得付款。这使我们能够随时重新运行簿记员以发出任何未付款或失败的付款。

簿记员向 stripe 提交费用，客户被收取费用。