扇区基础

扇区基础提供扇区数据库，以 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参数包含Go指针到Go指针”的恐慌，这在cgo文档中是有意义的。如果我们让Rust管理磁盘/存储管理器状态，这就不会有问题。

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

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

存储配置和调整将取决于从与Filecoin协议和区块链交互中得出的考虑，这些交互可能与存储证明无关。这种逻辑不应包含在证明模块中。这两个考虑因素界定了扇区基础不是（go-filecoin本身的一部分，或作为storage-proofs的一部分，它必须消耗它）。这也解释了为什么sector-base目前作为一个独立的crate存在，作为Filecoin证明子系统（FPS）的一部分，源代码在rust-fil-proofs存储库中。

API参考

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

磁盘后置扇区存储API

许可证

MIT或Apache 2.0