PolyXOR128：带 Lean 证明的高速 128 位通用哈希
PolyXOR128 是用 Rust 实现的 128 位通用哈希（universal hash），面向文件/数据流完整性校验，并强调密码学强度下的低碰撞概率。作者 orlp（此前有 polymur-hash、foldhash 等）发布仓库 orlp/polyxor：在密钥与输入独立且随机的前提下，长度至多 n 字节的两条消息碰撞概率上界为 (n/4096 + 3) / 2^128，证明用 Lean 完整形式化。
吞吐上，作者在中大型输入上对比 crates.io 常见实现：除 CRC64 外快于所测主流哈希；在带 AVX-512 的机器上 bulk 吞吐可接近 foldhash 的约两倍。单线程示例数据包括 Ryzen 9950X 最高约 130 GB/s、Apple M2 Pro 约 60 GB/s，并给出 Xeon 等图示。实现依赖硬件加速的无进位乘法（carryless multiply），对 AArch64 / x86-64 做动态分发；便携参考实现极慢，嵌入式可能受限。密钥展开实例约 5 KB 内存；小串（如 ≤256 字节）目前零填充到 128 字节倍数，尚未专项优化。
通用哈希要求密钥对数据保密且不公开；跨不安全信道应使用 finalize_mac（用 AES 封装哈希）再传输。它不能替代无法保密密钥时的抗碰撞哈希（例如公开包校验和）。设计上对 128 字节块混入密钥、奇偶扩展后做类似 CLHASH 的 NH 变体，SIMD 累加后再进入多项式归约；另有 design.md。作者说明正文与最终代码主要为人工撰写，Lean 形式化由 AI 生成但结论经其核验且可被 Lean 检查。相关帖曾被误判为非人工后已由版主恢复。
原文链接：https://github.com/orlp/polyxor
Casita：面向源码与构建产物的内容寻址存储层
Casita 是 Cachix 团队在用 Rust 重写 Nix、并按层拆分现代化时交出的第一层独立组件：内容寻址对象存储，覆盖共享存储、校验、同步与垃圾回收，以 Rust 库和 CLI 预发布，目标平台 Linux / macOS / Windows。背景是 agent 开发会更快堆出多版源码与 target/ 产物，全留占盘、全丢又要重编。
存储模型类似广义的 Git 对象库：不可变 blob 与不可变对象记录；blob 用完整字节的 BLAKE3，并可附带 Bao outboard 做区间校验。目录/文件等记录在 blob 之上形成图；改文件会换新 ID 并向上传播，未改文件共享原 blob。应用通过 root 命名保留可达图；可重建数据（如 Cargo target/）可用 evictable root。导入支持文件系统、tar、NAR 与 Git；Casitar 可打包完整图；另有实验性 Gix ODB 适配、CasitaFS 只读挂载（Linux FUSE / macOS FSKit），以及本地与可选 SSH 同步。共享 S3 后端仍实验性。
团队还在 Cargo 上加了 ArtifactStorage 接口与 Casita backend（实验分支），用于 registry/Git 依赖与 workspace 构建产物的导入恢复，目前性能尚未追上文件系统后端。0.1 前仍需压测、拓宽基准与真实工作流验证。仓库：cachix/casita。
原文链接：https://casita.rs/blog/introducing-casita-a-content-addressed-store-for-source-code-and-build-artifacts/
mbrotli 进入上游 lzbench：安全 Rust 实现的 Brotli 可对照官方基准
mbrotli 是用安全 Rust 编写的 Brotli 编解码器。此前多数对比数据主要来自项目自有仓库；现在 mbrotli 0.5.2 已进入上游 inikep/lzbench（PR #333），可与 Google Brotli 等编解码器在同一 harness 下跑分。
作者在 WSL2、默认 lzbench 构建、window 22、单线程、Silesia 语料上对比捆绑的 Google Brotli 1.2.0：解压在各 quality 上 mbrotli 更快（约 1.09–1.16×）；q0–q1 压缩基本持平或略快；q2–q9 压缩目前约慢 1–9%；q10 / q11 压缩显示约 1.18× / 1.35× 更快。q0–q9 压缩体积一致；q10/q11 的微小体积差来自 lzbench 对 C Brotli 使用了 -ffast-math，会改变最高 quality 下的浮点代价计算，按常规方式构建 C Brotli 后输出可再次对齐。作者强调不必过度解读 q10/q11 对比，但进入上游 lzbench 后可以用公共基准继续看优势与短板。
原文链接：https://github.com/inikep/lzbench
Taipei：与 Tower 集成的服务过载治理，附交互式说明
Taipei 是与 Tokio Tower 集成的库，目标是让服务在压力下仍表现稳定，并减少手调。功能以 Tower layer 形式提供，可包在已有 Service 外；文档站点用 WASM 跑真实 crate，配合交互仿真讲解过载相关原则，即使不直接用该 crate 也可作参考。
示例路径包括：用 InstrumentedTokioRuntime 观测 CPU；CpuBackpressureLayer 在 CPU 高于阈值时托住请求；QueueLayer 做排队与超时，并把队列错误映射为 HTTP 503 等。文档从手写并发上限讲起，说明为何需要队列、背压与运行时观测，再对比“拍脑袋 limit”的局限。仓库：nhawkes/taipei；说明入口：https://taipei-book.pages.dev/intro 。作者注明文案自写，代码有 AI 辅助。
原文链接：https://taipei-book.pages.dev/intro
From Rust中文社区 Mike
社区学习交流平台订阅：
评论区
写评论还没有评论