InterValue项目的双周报一直是我们团队和社区之间最重要的一份沟通文件。20200406-20200419这段时间，刚好赶上主网压力测试的收尾和下一阶段功能开发的启动，内容比前几期厚实不少。这篇双周报适合三类人读：第一类是关心项目技术走向的开发者，第二类是正在跑节点的运维同学，第三类是希望通过定期报告判断项目活跃度的观察者。我会把这两周里真正有变化的部分，按版本基线、协议层改动、测试网数据、社区协作、风险登记和后续规划六个板块拆开讲，尽量把每个决定背后的理由也说清楚。

老读者应该知道，我们这份双周报不是流水账。每一条进展都对应具体的提交、可复现的数据，或者一个明确的验收标准。如果你只看结论不看过程，很容易被表面的"优化""修复"误导。所以在展开细节之前，我先说一下这两周的版本基线和工作方式。

1. 版本基线：为什么双周报必须先说清"在哪个Commit上工作"

1.1 分支管理与基线快照

这两周的代码仓库主线保持在20200406-20200419这个基线分支上，主干分支一直开放接收小范围修复。为了保证社区成员复现问题时不在环境上浪费太多时间，我们约定每次双周报必须给出明确的基线哈希。当前公布的基线是4f8d2a1c，它以 consensus、storage、docs 三个子模块的合并状态为基准。

之所以这样要求，是因为社区成员分布在不同时区、不同网络环境，如果没有统一基线，A同学报出的错误在B同学那里可能根本复现不了。基线的作用相当于给全项目拍了一张快照，所有人讨论问题都基于同一张照片。这两周我们吃过一次亏：有成员在旧分支上发现了一个区块同步卡死的问题，排查了两个小时才发现他用的还是前两周的代码，而这个问题在新基线中已经被修复。从那以后，双周报的第一条必须写基线，没有任何例外。

1.2 双周报的信息消费方式

这份报告不是一个人拍脑袋写出来的。技术进展部分由核心协议组按提交记录梳理，社区动态部分由运营组根据论坛和线上讨论记录整理，风险登记部分来自每周四的例行问题清单。三个来源交叉核对之后，才汇成你们现在看到的版本。

如果你只是想快速了解项目是否健康，建议重点看第三部分的测试网数据和第五部分的风险登记表；如果你是开发者，第二部分和第六部分的优先级排序会更重要。但无论如何，第一部分不要跳过去，因为后面的所有讨论都依赖这个版本基线。如果未来两周你发现某个表现和这份报告对不上，请先检查你的代码是否切到了4f8d2a1c。

2. 协议层改动：确定性出块与状态同步的取舍

2.1 出块广播策略调整

共识模块这两周做了两处比较关键的调整。第一处是出块广播策略：原来新块产生之后，节点会按 peer 列表依次推送，一个 peer 推送成功再推下一个，逻辑简单但慢。现在改为随机选取 N 个 peer 并发推送，N 取 3。这个改动的目的很直接，就是想把区块在网络里的传播延迟压下来。我们在测试网上观察到的广播延迟中位数从 850ms 降到了 520ms，代价是同期节点带宽占用上升了大约 14%，对于当前的测试网规模来说完全可接受。

第二处调整是对收到的广播块先做基础格式校验，再放进验证队列。以前的做法是广播块直接进入缓存，等出块节点的完整验证结果回来之后再决定是否进入主链。这在节点数量少的时候问题不大，但节点一多，大量无效广播块会挤占验证线程，造成后续合法区块也要排队。现在先把区块头和签名做一遍快速校验，不合格的直接丢弃，验证线程的压力明显降下来了。用快递分拣来类比的话，以前是把所有包裹都先堆到分拣口再逐个处理，现在是在入口处就量一下尺寸，明显超规的包裹直接退回去，不必送进分拣线。

2.2 状态同步：增量快照与全量校验的时间差

状态同步部分这周改得比较纠结。项目的账号状态存储一直采用增量快照机制，新区块落地后写增量，每隔一段时间做一次快照压缩。但校验方式一直是"每次同步都做全量校验"，这在状态量小的时候没有问题，可测试网跑了几个月之后，全量校验的耗时开始指数上升，新节点加入网络时要花很长时间才能追到最新高度。

这周我们把策略调整为"增量校验+定期全量校验"的组合。具体来说，节点每次同步只校验最近一段时间的增量状态，同时每隔 10000 个区块强制做一次全量校验，防止增量校验长期运行后积累出看不见的偏差。这两周在全量校验耗时上，在接近 5 万个区块的历史数据上，从原来的 15 分钟降到了 2 分钟左右。这个取舍背后的逻辑是：状态账本不需要每次同步都从头算一遍，就像记账本不需要每次记一笔账就把整年的账重新数一遍，只需要确认自己上次记到哪一页，把那一页之后的数据核对完就行。定期全量校验则是防止"页码错乱"的兜底手段。

3. 测试网观察：从节点监控数据看网络真实表现

3.1 监控指标与采样方式

测试网目前有大约 30 个公开节点，分布在不同的数据中心和家庭网络环境。我们通过一个轻量监控程序每隔 10 秒采集一次节点状态，包括当前区块高度、出块间隔、事务池大小、在线离线状态等。监控程序本身也跑在测试网上，所以采集到的数据偶尔会有 1-2 秒的抖动，但这不影响整体判断。

需要说明的是，这 30 个节点并不全是核心团队运行的。大约三分之一由社区成员自主部署，配置差异很大，正好帮我们暴露出不少只在低配环境才会出现的问题。比如这周有节点因为磁盘 IO 过高导致同步落后超过 200 个区块，这个现象在监控数据里非常明显，单靠核心团队自己的高配节点很难发现。

3.2 实测数据回归与结论

下表是这两周的测试网核心指标，数据采样时间为 20200419 的 08:00 UTC。

整体来看，网络表现符合预期，共识模块的调整带来了可量化的收益。但节点在线率从 95.7% 降到 94.1%，这个信号不能忽视。离线的主要原因是存储目录持续膨胀，导致磁盘占满。这说明状态存储优化已经不只是"以后再做"的事，而是直接关系到测试网稳定性的现实问题。我们在风险登记表里把它列为了下一阶段的最高优先级。

4. 社区协作：文档本地化、开发者任务池与线上讨论

4.1 文档本地化与多语言同步

这两周文档仓库的变动也比较大。我们新增了中文、英文、韩文三个语言目录，英文版本由核心团队直接维护，中文和韩文版本由社区志愿者认领维护。本周完成了节点部署文档的英译中，同时修正了 11 处 API 文档与实际返回格式不一致的问题。

文档不一致是社区反馈里出现最多的问题。很多开发者在集成 API 时照着文档写，结果返回字段少了一个下划线，来回排查浪费了不少时间。这周我们专门做了一个小工具，把文档中的 JSON 示例和测试网的真实响应做自动比对，比对不一致的地方会生成一个 issue。目前这个工具还在内部试用，等稳定了会开放出来。

4.2 开发者任务池与Review流程

开发者任务池这两周新增了 12 个任务，其中 6 个是 bug 修复、4 个是测试用例完善、2 个是性能分析。任务统一挂在论坛的固定帖子上，每位成员认领后需要在 48 小时内给出初步方案，否则任务会自动释放回池子，让其他人继续认领。这样做的目的是尽量保证任务不被"占着不动"。

Review 流程方面，我们坚持至少两个维护者 approve 才能合并代码。这两周从提交 PR 到合并的中位时间是 28 小时，比上周的 34 小时有所缩短。主要原因不是 review 速度变快了，而是提交者学会了在 PR 描述里直接附上测试日志和复现步骤，维护者不需要再追问一遍。这也是双周报想强调的一个点：高质量的协作不靠催促，靠降低对方的沟通成本。目前任务池的整体完成率是 75%，4 个测试类任务还处于进行中状态，预计下个周期能全部关闭。

5. 风险登记表：被反复提到的隐患与应对

5.1 性能瓶颈：状态存储膨胀与GC压力

风险登记表是本轮双周报新增篇幅较大的部分。当前登记的风险有三类，状态存储膨胀、GC 暂停时间、以及节点版本碎片化。状态存储膨胀是最突出的一个：测试网持续运行较长时间，存储目录缺少归档和清理机制，导致运行节点长期占用磁盘空间持续上升。低配置节点一旦磁盘写满，轻则同步落后，重则直接离线。

GC 暂停时间的问题主要出现在智能合约执行密集的场景。临时对象生命周期过长，导致 GC 暂停偶尔超过 200ms。200ms 对单笔交易影响不大，但吃满区块验证线程时，会让同一批次里的其他交易出现明显排队延迟。应对方案是优化对象池复用，减少临时对象创建，同时把 GC 触发频率的参数调整到一个更合理的区间。这部分预计在下一个双周周期内完成一轮实测。

5.2 安全审计与应急响应机制

安全方面，本周完成了一次依赖库升级，主要是升级一个序列化库到修复版本，解决低版本客户端在特定长度消息下可能触发的异常。同时发布了一个针对旧版本客户端的补丁，目前测试网上所有核心节点都已升级到补丁版本，社区节点中还有 4 个没有完成升级。

我们的应急响应机制按"发现-同步-修复-公告"四步走。这两周实际用了一次，处理的是节点握手超时的问题：新版本客户端在握手时多了一段签名信息，旧版本客户端解析不到这段信息就直接断开了。从问题发现到公告发出用了大概 5 个小时，速度可以接受，但复盘时我们发现"同步"这一步还可以更快，原因是运营人员手动整理节点列表花了不少时间。下一步会做一个自动收集在线节点版本的工具，避免下次还要人工核对。

6. 下个双周的工作排序与可验收目标

6.1 优先级排序的逻辑

下一阶段的工作排序是：状态存储优化、文档自动校验工具上线、测试网扩容、社区翻译激励、开发者工具完善。这个顺序的考虑只有一条：先止血，再活血。状态存储优化直接影响节点稳定，是当前最明显的"失血点"，必须先做。文档校验工具已经完成了内部原型，上线成本不高，收益却很直接，能减少社区开发者因为文档踩坑的频次，所以排第二。

测试网扩容计划新增 10 个社区节点，扩容的目的不仅是为了压力测试，更是为了提前暴露不同网络环境下的兼容性问题。社区翻译激励排在测试网扩容后面，是因为翻译工作需要先确定文档冻结版本，而文档冻结要等校验工具跑稳了才敢做。最后才是开发者工具完善，比如继续优化任务池的标签体系和 PR 模板。

6.2 可验收目标与协作分工

为了让下期双周报有据可查，我们为每项工作都定了明确的验收标准和责任小组。具体如下表：

这些目标都不算激进，但都把"完成"定义得非常具体。我们不愿意用"持续优化""不断改进"这类没法验收的词来写双周报，因为那对读者没有价值。下一期双周报发布时，可以直接对照这张表逐项打勾，没有打勾的也要说清楚为什么没完成。

整理这份双周报时，我最大的感受是"风险透明"这件事比想象中还要重要。很多项目喜欢把进展写得漂亮，把问题藏起来，结果社区只能在遇到故障时被动发现。我们选择把性能瓶颈和 GC 问题直接摆出来，短期看会显得项目不够完美，但长期看，社区和开发者的信任恰恰是这么一点点建立起来的。如果你也是社区项目的长期关注者，建议你多看看风险登记表这类内容，那才是判断一个项目真实健康程度的窗口。