小文件可不简单：Walrus在Quilt上的一小步，dStorage的一大步

上图是一张来自Walrus制作的文件分布图，可以非常清晰的看到，1KB-100KB的文件占据了Walrus储存的半壁江山。如果按照1MB以及以下为口径进行计算，几乎覆盖了Walrus储存的近八成内容。

其实到这里我们就知道，小文件可不小，其庞大的数量让dStorage项目不得不去正视小文件的有机储存问题。

而Walrus新推出的Quilt结构，则提供了一种可能的思路。

核心原理是将多个小文件捆绑成一个大的存储单元（Quilt），在不丢失文件独立性的前提下统一编码和存储。具体而言，每个 Quilt 最多可包含约 660 个文件。

当开发者调用 Quilt 上传时，客户端会将待存文件按序组合，将它们的原始数据及自定义元数据打包成一个大的数据流，并提交给 Walrus 发布者。

在逻辑上，每个文件在 Quilt 中依旧保留文件边界信息。系统会为每个打包的文件分配一个 QuiltPatchId 作为唯一标识。与普通的 BlobId 不同，QuiltPatchId 的计算依赖于整个 Quilt 的内容，因此将同一文件放入不同 Quilt 会产生不同 ID。

举一个生活化的例子你可能就一目了然Walrus的Quilt在做什么。如果你平时喜欢去超市享受购物的乐趣，你也许会有在散装区装袋上秤的这样的经历。而你是否思考过，这些散装区的货物是从哪里来的呢？

Quilt 做的事就是把一堆小文件一次性装进同一个大的运输托盘，但每个小文件都会贴上自己的独立标签和编号，随时都能单独拿出来用，不需要把整包倒出来。这就像把超市里散装的小零食装进一个托盘发往销售区，但每袋零食都有条码，收银时依然能单件扫码结账。

对实际开发最直接的好处就是省钱省时更稳。以前你有六百个小文件就要做六百次上传与确认，每一步都有固定开销和失败概率。Quilt 把它们变成一次提交，费用和尾部延迟一下子被摊薄了，重试与断点续传也只围绕这一次进行。读取时也不用解压整包，按编号就能把其中一张图片、一段文本精准取回，用户点开就能看，速度体验和单文件几乎一样。

使用 Quilt 后，Walrus 在存储性能和成本上有显著提升。首先是在存储空间利用率方面：Walrus 的 RedStuff 编码会将 Blob 数据扩大约 4.5～5 倍。如果 600 个小文件各自独立上传，这些膨胀开销会叠加到每个文件上；而采用 Quilt 后，这个 4.5 倍的膨胀仅作用于整个打包好的 Blob，一次性分摊到所有文件上，从而大幅提高空间利用率。

其次是存储成本和 Gas 费用。Walrus文档给出测试数据：将 600 个 10KB 文件作为一个 Quilt 存储时，所需的 WAL 存储费约为 0.005，而单独存储则需要约 2.088 WAL，降低了约 409 倍。相应地，Sui 交易费也从600笔聚合到1笔，节省了约 238 倍。简单地说，Quilt 让每次存储操作能够批量做功，极大地降低了总体的费用和网络负载。

再举个加密玩家最熟悉且具像化的例子：NFT，小文件存储的经典代表。一个 NFT 项目常常包含上百张图片和对应的 JSON 元数据。利用 Quilt，这些图片和描述可以一次性批量上传到 Walrus，只花费一笔存储费，却还能通过文件标签快速找到任意一张图片或元文件，无需下载整个集合。

对于项目方而言，长期运维上也更省心，写入时你可以给每个小文件顺手打上标签，后面按标签检索就能立刻定位。一批相关数据作为一个大包裹天然具备原子性，回滚、审计和复现场景更加干净。