# 概念和基础设施

damocles 包含了一系列的抽象、功能组件、基础设施。了解这些内容有助于我们理解 damocles 的运转。

# 公共部分

# ActorID

ActorID 是在 damocles 组件中使用的、SP 的标识格式，为数字类型。其与 SP 的地址是一一对应的关系。

例如：

在测试网络中，t01234 这样一个 SP 地址与 1234 这样一个 ActorID 一一对应
在主网中，f02468 这样一个 SP 地址与 2468 这样一个 ActorID 一一对应

之所以统一使用 ActorID 这样的标识格式，是为了：

方便辨识和书写
避免地址中的网络标识 (t，f) 和类型标识 (t0 中的 0) 可能带来的混淆

# objstore

objstore 是基于对象存储模式的存储基础设施抽象。

我们知道，在 Filecoin 中，与数据交互的各个环节广泛使用了基于文件系统的存储设施抽象。但在实践过程中，我们发现，除了一些相对基础的数据访问模式外，文件系统提供的大量特性并未被使用。

经过分析，我们认为：

在许多场景下，基本的对象存储抽象已经能够满足 Filecoin 的需求
无论是搭建本地的大规模高可用分布式存储集群，还是使用已有的商业化存储方案，对象存储都有大量选项
存量的、基于文件系统的存储可以经由简单的代理层完成向对象存储接口的转换

当然，由于在算法层面，一些关键的环节还不支持基于对象存储的抽象（例如 MerkleStore），我们目前仅仅是将文件系统转换为对象存储的形式。希望在将来，通过社区推动Filecoin 算法层面对于对象存储的原生支持落地，令使用者能够按照自己的需求使用适合的存储方案，甚至混合方案。

# piece store

piece store 是在存储订单封装场景中使用的，用于访问订单 piece 数据的存储抽象。

这里的 piece 数据，是指用户发出的、未经过填充 (padding) 和 FR32 转换的原始数据内容。

由于 damocles-cluster 并不会涉及 piece 数据的写入，因此只提供了数据读取的接口。

# damocles-worker 部分

# sealing store

sealing store 是位于 damocles-worker 所在宿主机的存储设施，用于临时存放扇区封装过程中产生的数据文件。通常由高速本地存储设备（如 nvme）构成。

sealing store的使用遵循：

一个扇区唯一对应一个 sealing store
一个 sealing store 在同一时间只会存在一个扇区

每个 sealing store 中都会包含 meta 和 data 两个子目录，分别存放正在进行中的扇区的状态和封装数据。这样，在sealing store 之间，状态数据不会相互影响。即使部分sealing store的底层存储设备损坏，影响面也会局限在它所容纳的 sealing store 范围内。

通常来说，sealing store 会根据当前宿主机上存储资源数量来进行规划。

# remote store

remote store 是扇区数据的永久存储设施，通常是一个存储集群。

目前在 damocles-worker 中，remote store 实现为一套在文件系统之上的对象存储接口封装。

完成封装、等待上链的扇区数据会从 sealing store 移动到 remote store。

实际上， remote store 更多相对 sealing store 的本地而言。对于 damocles-manager 和 damocles-worker 来说，都需要能够访问这一存储设施。

# processor

processor 是扇区封装步骤的执行器。通常来说，每一个独立的步骤会对应一类 processor，如 pc1 processor, c2 processor 等。使用者可以针对每一类 processor 设置其并行数量。

通常来说，processor 会根据当前宿主机上的计算资源数量来进行规划。

# external processor

external processor 是一类特殊的 processor，它们以子进程的形式存在，通过确定的协议，与主进程完成任务上下文的交互，并具体执行某一特定的封装步骤。

external processor 这一设定的存在，使得damocles 可以依托操作系统提供的接口，针对子进程进行计算资源的配置和隔离，例如

通过 cgroup选项为 pc1 processor 指定 cpu sets，以避免 pc1 阶段的扇区相互抢占 cpu资源
通过 numa 选项为 pc1 processor 指定内存分配的倾向性，以降低 pc1 阶段内存的访问延迟，提高 multicore_sdr 模式下的缓存预取效率
通过英伟达默认的 GPU 相关环境变量，为多个 c2 prcessor 各自绑定唯一的可用 GPU，并将锁文件的位置分隔开

等极其灵活的搭配方式。

除了方便计算资源的配置和隔离之外，external processor 还使得 非通用或非公开的执行器实现 变得可能。任何满足上下文交互协议要求的可执行程序都可以作为 external processor的具体实现被集成进封装流程，这使得诸如：

高度定制化的 c2 processor
基于 GPU 外包的 pc2 processor 或 c2 processor

等选项变得易于集成。使用者可以任意选择多种定制化的 external processor 进行组合，且这种选择不会受限于具体的 external processor 的开发和维护者是谁。

# sealing store、processor 和 sector 的关系

在之前的段落中我们提到，sealing store 和 processor 分别根据存储资源和计算资源进行规划，那么是否意味着他们之间并不需要维持 1:1 的配比？

答案是肯定的，原因如下：

在任何一个特定阶段，一个 sector 所占用的资源是其所占用的计算资源（processor）和存储资源（sealing store）的组合。

在 damocles-worker 的封装流程中，sector 从一个阶段进入下一个阶段时，会释放之前占用的计算资源，并尝试申请下一阶段所需要的计算资源。被释放的计算资源完全可以被分配给其他等待中的sector。

举例来说：

通常，基于成本和硬件规格考虑，可规划的 sealing store 数量往往多于可规划的 p1 processor 数量。在 damocles-worker 的封装中，如果一个 sector 完成了 p1 阶段的计算，那么释放出来的 p1 processor 就可以被用于等待中的其他 sealing store 上的 sector。

这使得硬件资源的高密度利用变得可行。

# damocles-manager 部分

# 基础服务 API

这是 damocles 依托的服务及其接口定义。

这些服务和接口为 damocles 提供基础的、与链和其他参与者交互的能力。

# chain.API

这是一组定义在 venus/venus-shared 中的，链相关的接口定义。主要是向 damocles 提供基础的链服务接口。

# messager.API

这是一组定义在 venus/venus-shared 中的，消息相关的接口定义。主要是向 damocles 提供发送消息、确认上链和执行结果方面的基础能力。

# market.API

这是一组定义在 venus/venus-shared 中的，订单相关的接口定义。主要是向 damocles 提供订单分配、订单数据获取方面的基础能力。

# RandomnessAPI

这是对 chain.API 的一层简单封装，主要用于提供扇区封装、维持过程中所需的随机数信息。

这一层封装使得 damocles-worker 及其他模块仅需要根据用途获取相应的结果，而不必在意具体的请求对象（Drand or Filecoin）或请求格式。

# MinerInfoAPI

这是对 chain.API 的一层封装，主要提供 SP 粒度的信息。

# SectorManager

这是管理扇区分配的模块。主要负责根据 damocles-worker 提交的参进行扇区编号的分配。

可以为多个 SP 、不同的扇区大小提供支持。

# DealManager

这是管理订单的模块，主要负责为空白的扇区分配可容纳的订单 piece，以及对失败的扇区中的订单进行释放。

# CommitmentManager

这是管理扇区消息上链的模块。主要负责按照预先指定的策略对 PreCommit 和 ProveCommit 消息进行单条或聚合式的提交，并观察上链结果。

# SectorStateManager

这是管理进行中的扇区的状态的模块。主要负责接收来自 damocles-worker的状态和异常信息上报。

# SectorIndexer

这是管理已完成的扇区位置的模块。主要负责定位指定的扇区，常用在 PoSt 的计算过程中。

← 简述