截至 2026 年 1 月 15 日，Arweave 官方仓库在短短半个月内已经产生了约 95 个提交。贡献高度集中但方向非常清晰，包括数据同步、网络性能、稳定性、可观测性，以及开发与测试基础设施。这些更新并不喧哗，却直接决定了 Arweave 是否真的能承载「永久存储」这一长期承诺。
整体更新概览
截至 2026 年 1 月 15 日，Arweave 仓库在年初阶段已累计约 95 个提交，代码主要由 James Piechota 与 Lev Berman 贡献。更新节奏密集，但方向高度集中，整体呈现出以下特征：
- 明显偏向系统级优化，而非新增用户侧功能
- 大量提交围绕真实生产环境暴露的问题
- 多项改动涉及底层同步与网络模型，影响范围广
- 测试、监控与开发工具同步推进，强调可维护性
基于 Footprint 的索引与同步系统
Footprint 机制是本阶段最重要的结构性更新之一，相关改动虽然最早引入于 2025 年中，但在 2026 年初仍在持续打磨与完善。主要变化包括：
- 新增 API 接口
- GET /footprints/{partition}/{footprint}：查询指定分区下的足迹数据
- GET /footprint_buckets：获取足迹存储桶信息
- 同步机制调整
- 在传统区块同步与足迹同步之间交替执行
- 新增 sync_from_local_peers_only 配置项，允许节点限制同步来源
- 性能与并发控制
- 引入 LRU（最近最少使用）熵缓存
- 对并发熵生成过程加入互斥锁，避免重复计算
该更新共涉及 48 个文件修改、2400+ 行新增代码，标志着 Arweave 正在从「以区块为中心的同步」逐步演进为「以数据足迹为中心的同步模型」，为后续更复杂的存储与同步场景奠定基础。
网络连接与吞吐性能优化
在 2026 年 1 月的一次关键提交中，Arweave 对 HTTP 网络层的默认配置进行了显著调整。在真实生产环境中，运行完整区块链数据的节点通常会维持 4000–6000 个并发连接，而此前 Cowboy 的默认配置明显偏低，导致部分节点出现：
- 区块广播延迟
- 请求排队与超时
- 高负载下性能不稳定
具体调整后，最大连接数从 1024 到 5000，接收器数量从 10 升级到 500。该调整显著提升了节点在高并发场景下的网络处理能力，尤其改善了使用机械硬盘的节点在区块同步与广播过程中的表现。
关键稳定性与 Bug 修复
2026 年 1 月的大量提交集中在修复潜在的系统稳定性问题，以下为几项代表性修复。
1. Erlang Atom 表耗尽风险
- 问题：每个 ar_peer_worker 进程都会注册新的 atom，长期运行可能耗尽 Erlang atom 表
- 修复：重构 peer worker 的注册逻辑，避免为每个进程创建独立 atom
- 影响文件：ar_peer_worker.erl、ar_peer_worker_sup.erl
2. Footprint 同步限制的竞态条件
- 问题：异步 enqueue_task 与同步 process_queue 组合可能突破足迹限制
- 修复：将 enqueue_task 改为同步调用，彻底消除竞态
- 结果：在不引入性能回退的情况下提升稳定性
3. 多交易区块中的数据根验证
- 问题：在包含多个交易的区块中，数据根验证存在边界缺陷
- 修复内容：
- 修正跨区块边界的数据根处理逻辑
- 将验证逻辑迁移至 ar_data_root_sync.erl
- 重构并扩充相关测试（约 140 行）
4. 活跃足迹记录保持问题
- 问题：近期代码调整破坏了活跃足迹记录的保持机制
- 修复：恢复并修正足迹状态追踪逻辑，确保同步状态准确
5. Peer Worker 调用超时
- 问题：gen_server:call 在高负载下出现超时
- 修复：合理延长超时时间，避免误判失败
测试体系的持续增强
2026 年初，Arweave 对测试基础设施进行了多项补强。
- 新增 ar_test_runner 模块
- 支持运行单个测试用例
- 更便于定位与调试问题
- 大型存储模块端到端（E2E）测试
- 覆盖边界条件与性能场景
- 数据同步协调器测试修复
- 提升测试稳定性，减少偶发失败
这些改动显示，测试已不再只是验证功能正确性，而是开始承担 长期系统演进的安全网角色。
监控与可观测性改进
为更好地理解系统在生产环境中的行为，多个新的监控指标被引入或优化。
- 数据发现过程指标
- HTTP 状态码记录优化（使用原始数值而非字符串）
- 新增 sync_chunks_skipped，用于跟踪已同步但未写入的数据块
这些指标为定位同步瓶颈、网络异常与存储行为提供了更精细的数据基础。
数据同步与缓存机制优化
围绕数据同步与熵缓存，代码中出现了一系列连续优化：
- 将 ar_entropy_cache 从 gen_server 架构改为更轻量实现
- 新增熵缓存相关指标
- 使用 MiB 作为缓存配置单位，而非熵数量
- 限制同时进行的足迹同步数量，防止资源被过度占用
- 优化分区迭代策略，提升整体同步效率
这些改动共同指向一个目标：在数据规模持续增长的前提下，控制同步成本与资源消耗。
开发工具与工程化改进
在工程与开发体验层面，也出现了多项实用更新。
- 新增 scripts/system_info.sh
- 以 YAML 格式输出构建时使用的软件与库版本
- 已集成进 GitHub Actions 流程
- 引入 Cursor AI 项目规则
- 为 AI 辅助编码提供明确的项目约束
- 提升自动生成代码的可维护性
架构与内部结构调整
为提升代码可读性与长期维护性，Arweave 对部分内部结构进行了整理：
- 同步过程中的 peer 处理逻辑拆分至独立模块
- 数据同步任务状态统一命名规范
- 引入 idle peer worker 的自动清理机制，防止资源泄漏
从 2026 年 1 月的代码更新可以看到，Arweave 当前阶段的开发重点并不在「快速推出新功能」，而是在提升节点在真实生产环境中的运行能力、减少长期运行下的潜在稳定性风险、为更大规模的数据同步与存储做好工程准备，以及强化测试、监控与开发工具，支撑未来复杂度增长。这些更新整体呈现出一种 偏底层、偏工程、偏长期 的特征，也为后续网络规模与使用场景的扩展提供了更稳固的基础。