Carbonado

为真正偏执狂设计的抗末日数据存储格式。

Carbonado 是一种加密、持久、压缩、可证明复制的共识关键数据的归档格式，无需区块链或强大的硬件。解码和编码可以通过 WebAssembly 在浏览器中完成，嵌入到 P2P 网络上的远程节点，保存在兼容 S3 的云存储中，或作为单个高度可移植的平面文件容器格式在本地磁盘上。

特性

Carbonado 归档格式具有以下特性，使其具有抗性

• 驱动器故障和数据丢失
  • 使用 bao 编码，因此可以上传到远程节点，并且可以定期检查该数据的随机 1KB 切片与本地哈希值进行比较，以验证数据复制和完整性。这样，副本可以地理分布；在太阳耀斑或日冕物质抛射的情况下，最多只有地球的一半将受到影响。
• 监控
  • 默认情况下，文件使用来自 secp256k1 密钥的 ecies 认证加密 进行静态加密，这些密钥可以是提供的或从助记词中派生。
• 盗窃
  • 解码由客户端使用自己的密钥完成，因此即使存储数据的设备被带走或丢失，即使存储介质未加密，也不会有任何影响。
• 数字淘汰
  • 所有项目代码、依赖项和程序都将打包到 tarball 中，并随每个版本以 Carbonado 格式提供。
• 比特衰减和宇宙射线
  • 作为最后的编码步骤，使用 zfec 添加前向错误纠正码，以增强一些文件系统和存储介质中已经使用的那些。

然而，无需区块链，但它们可用于定期将数据检查到持久的地方。

文档

有关格式和操作的更详细信息，请参阅 carbonado crate 文档，托管在 docs.rs。

还将有一个称为 CHIPs 的规范列表。

生态系统

Carbonado 是一种新型归档格式，围绕该格式构建了工具以更好地利用它。将支持以下几种存储提供者前端

• HTTP
• Storm
• Hypercore
• IPFS
• 比特追踪（BitTorrent）
• 远程同步（rsync）
• 安全文件传输协议（SFTP）
• 与S3兼容的对象存储

如果您对上述任何特定用例感兴趣，请告诉我们！

碳化硅节点（carbonado-node）（https://github.com/diba-io/carbonado-node）是这些实现所在之处。还计划在carbonado-clients中进行工作。

检查点

碳化硅存储客户端支持使用可选的与比特币兼容的HD钱包，该钱包具有特定的派生路径，可用于通过链上OP_RETURN来安全地使用带时间戳的碳化硅检查点。

检查点是结构化的人可读YAML文件，可用于引用其他碳化硅编码文件。它们还可以包括文件存储的所有位置索引，因此除了其他所需元数据以检索、解码和在存储提供商前端提供服务外，还可以检查互联网上的多个位置以检查该哈希值的碳化硅编码数据的出现。

应用

合同

RGB合同寄售必须以一致性关键且耐数据丢失的方式编码，否则它们无法导入或消费。

内容

包括用于MIME类型和预览内容的元数据，非常适合NFT和UDAs，特别是对于完全占有和自托管数据，或者支付对方远程保管数据。

代码

代码、依赖项和程序可以在需要的地方进行维护。这有助于确保即使在没有互联网访问或包管理器离线的情况下，数据仍然可以访问。

比较

以太坊

在以太坊上，所有合同代码在所有时间点对所有地址都是复制的。这导致可扩展性问题，对于大量数据来说成本过高，并且暴露了所有合同用户的全部数据，还有可能在不涉及所有用户的情况下随时更改所有数据。

碳化硅是为了编码任意长度的数字资产而设计的，这些资产将离线存储、加密并安全存储。

IPFS

IPFS将数据存储到称为BadgerDS的数据库中，以IPLD格式编码，这并不等同于简单的、可移植的平面文件格式，该格式可以在任何服务器、服务或节点之外进行传输和存储。如果更换存储后端，IPFS是跨对等网络传输数据的完美方式。碳化硅将支持IPFS前端。

Filecoin

碳化硅使用基于性能良好的BLAKE3散列算法的Bao流验证，以建立统计复制证明（可以在一段时间内反复证明）。Filecoin则使用zk-SNARKs，这通常计算成本极高，通常推荐使用GPU加速。此外，Filecoin需要区块链，而碳化硅则不需要。碳化硅是Filecoin的直接替代品，因此不需要兼容性。

Storm

Storm是一个很好的工具，但它有一个16MB的文件大小限制，并且尽管可以将文件分成块，但它们是直接存储在嵌入的数据库中，而不是平面文件中。碳化硅将支持Storm前端。

错误纠正

在处理错误纠正方面做出了一些决策。使用了一种称为Zfec的块前向错误纠正算法，该算法在Tahoe-LAFS中应用。类似于RAID 5和6如何将奇偶校验位条带化存储数组，Zfec以这种方式编码位，只需要m个总块中的k个有效块来重建原始数据。由于Zfec没有内置完整性检查，这变得更加复杂。使用Bao来验证解码输入的完整性；如果完整性检查失败，我们无法确定哪个块失败。因此，有两种处理方法；要么为每个块创建一个哈希并在非绑定安全位置持久化，要么尝试每种块的组合，直到找到一个有效的组合。这里使用后者，因为希望擦除的需求相对罕见，尤其是在使用可靠的存储媒体、设置CoW文件系统进行擦除以防止位错或有一个完整的副本是良好的情况下。然而，如果您只剩下一个副本，并且所有您拥有的只是哈希（文件名）和一些有效的块，那么这个crate中的擦除方法应该有所帮助，即使它可能计算密集。

在没有任何错误的输入上运行擦除实际上返回一个错误；这是为了防止写入不需要擦除的字节。这在仅追加数据存储和计费云存储场景中非常有用。

为Zfec的k/m参数选择了4/8的值，这意味着只需要4个有效块，但提供了8个块。一半的块可能无法解码。这使数据大小加倍，加上加密和完整性检查，但这是过度谨慎的代价。此外，需要一个非素数的k来使块大小与Bao切片大小对齐。

Bao只支持1KB的固定块大小，因此Carbonado文件的最小大小是8KB。这也很好地与4KB硬盘扇区对齐，以减少浪费的空间。

只要配置了carbonadod以在8个不同的存储卷上存储归档块，存储提供商就不需要使用RAID来保护存储卷。如果卷失败，擦除将恢复丢失的数据。当数据提供服务时，只需要4个块。这导致了一种用户级的“应用RAID”，这与Carbonado的设计原则相符，即它是一个灵活的格式，具有用户友好的配置选项。它旨在对“Jim叔叔”爱好者友好，就像对专业挖掘数据中心的FIL或XCH一样。

术语

文件被分成最大1MB输入长度的段。这是因为它很好地与IPFS IPLD、Storm和BitTorrent前端对齐。这些段通过目录文件分别跟踪和组合，目录文件还可能存储有关文件的其他元数据，这些元数据对于特定的存储前端是必需的。块用于错误纠正，并且可以存储在单独的卷上。切片与流验证相关，硬编码为1KB大小，也是对Rust字节切片（对未知的8位整数数组的引用）的引用。

总之：n MB的文件 -> n MB / 1MB目录段 -> 8x Zfec块 -> >=1MB / 8x / 1024字节切片

只有块单独存储在磁盘上。切片在内存中引用，段如何流式传输由前端特定。分段还有助于计算并行化，减少节点内存需求，并有助于在存储卷之间分配IO负载。