扇区构建器

扇区构建器提供了一个扇区数据库，以 Rust 作为 crate 实现，并导出 C API 以供（例如）go-filecoin 使用。它将最终管理对扇区（密封和非密封）的配置和实现访问以及执行 filecoin-proofs 和 storage-proofs 操作所需的磁盘缓存。

这些方法将包括至少

• 向扇区增量写入块
• 预处理原始扇区以添加位级填充
• 实际上，上述两项已合并：我们边写边预处理。
• 管理缓存和生成扇区的多个表示，以满足需求
• Merkle 树缓存/再生

扇区基础的责任可能还包括

• 跨异构存储类型和格式对扇区和它们的节点进行随机访问
• 扇区元数据管理
• 扇区打包
• 构建扇区
• 构建聚合 Merkle 树（将多个扇区合并以生成单个根）

甚至可能是

• 按字段元素索引的扇区随机访问（进一步减少填充）

关于 '填充' 的一些话

在数据可以复制之前，对原始数据进行两种类型的填充。为了简单起见，我们将这些称为字节填充和位填充。字节填充是指在原始数据的末尾添加（零个或多个）零字节，以将其总大小增加到预期的扇区大小。

位填充也称为 '预处理'，是指在每 254 位原始数据后添加两个零 位。填充是必要的（在当前实现中），以确保连续的逻辑域元素（Fr）将是对齐的。因为域的模是一个 255 位的素数，有一些 255 位的数不是我们的域的元素。因此，为了确保我们永远不会溢出域，我们可以从每 256 位（32 字节）的字节对齐存储中最多取 254 位实际数据。

设计说明

将扇区基础作为 Rust 模块的动力。为什么不是 go-filecoin 的一部分？

我们需要在难以通过 go-filecoin 和跨越 FFI 边界实现的程度上暴露一些对磁盘/文件存储的控制。

• 示例：矿工可能希望将磁盘视为没有文件系统的原始块设备。

例如：Go 代码可以将 Go 指针传递到 C，前提是它指向的 Go 内存不包含任何 Go 指针。我们之前尝试用 Go 编写此磁盘/存储管理器时，涉及到将定义在 Go 中的函数指针传递给 Rust，该函数在应用某个键时从 Go 映射中返回一个值（这模拟了 FPS 从磁盘/文件管理器获取文件路径）。除了这个指针，我们还传递了键。这在运行时引发了消息 "cgo argument has Go pointer to Go pointer" 的恐慌，这是有道理的，因为 cgo 文档 中提到了。如果我们让 Rust 管理磁盘/存储管理器状态，这就不会是问题。

此外，这个具体问题体现了 FFI 边界带来的摩擦。事实上，FPS（filecoin-proofs 和 storage-proofs）的扇区基础与证明组件之间的通信需要精心协调，以确保效率和正确性。问题不在于 Go 有问题，而在于 FFI 边界会干扰最佳功能。尽管如此，Rust 的类型系统将有助于实现所需的性能泛型。尽管这自然存在于该 API 边界的 Rust 一侧，但控制这些函数的关注点包括与证明本身只有间接关系的点。

存储配置和调整将取决于与 Filecoin 协议和区块链交互时产生的考虑，这些交互可能根本与存储证明无关。这种逻辑不应包含在证明模块中。这两个考虑因素划定了扇区基础 不是（go-filecoin 自身的一部分，或 storage-proofs 必须消费它的一部分）。这也解释了为什么 sector-base 目前作为一个独立的 crate 存在于 Filecoin Proving Subsystem (FPS) 之下，其源代码位于 rust-fil-proofs 存储库中。

API 参考

扇区基础 API。Rust 源代码是定义 扇区基础 API 的真相来源，并将成为生成文档的最终来源。

基于磁盘的扇区存储 API

许可证

MIT 或 Apache 2.0