把口号改成带轮次与负载模块的可运行配置
Hyperledger Caliper 0.7.1的Benchmark Configuration页指出：基准配置文件是运行Caliper基准所需配置之一，它主要约束工作负载执行与结果收集；理论上可独立于被测系统（SUT），但也可能受工作负载模块实现限制。设置集中在根属性test下，其中关键的是rounds数组。
每个round可写label（通常对应提交交易类型的短名）、txNumber（本轮应提交的交易数）或txDuration（按秒持续提交）、rateControl以及workload.module路径。示例用5个worker，先跑label为init、txNumber为500、固定25 TPS的一轮，再跑label为query、txDuration为60秒、固定5 TPS的一轮。这样，“区块链研究方向”里一句“我们要测写入性能”就被改写成：假设某链码在给定workers与速率控制器下，能在标明的txNumber或txDuration内完成提交。
事先声明失败长什么样：迭代掉队也是证据
Grafana k6文档Dropped iterations页说明：有时场景无法跑到预期迭代数，k6用计数指标dropped_iterations跟踪未发出的迭代；该数字对调试执行器与分析结果有价值。掉迭代常见两类原因：执行器配置不足，或SUT无法承受配置的VU到达率。
对shared-iterations与per-vu-iterations，若在全部迭代完成前触达maxDuration就会掉迭代；对constant-arrival-rate与ramping-arrival-rate，没有空闲VU时会掉迭代——测试初期多半是VU配额不够，后期则可能是SUT变慢导致迭代耗时变长。把这条写进研究问题，就是预先给出失败标准：若dropped_iterations持续上升，或Caliper某round无法按txNumber/txDuration完成，则原假设被证伪，而不是事后改口成“环境问题再说”。
一份可证伪提纲：假设、控制量、反例
综合两份文档，可以把一次账本写入/查询方向整理成三行：假设——在声明的workers、rateControl与workload.module下，目标轮次能完成既定txNumber或撑满txDuration；控制变量——锁定Caliper配置中除待测因素外的rounds字段与监控项；失败标准——出现无法完成的轮次，或在对比负载工具中观察到由配置不足或SUT过载导致的dropped_iterations。
写作边界：本文只示范如何把研究方向写成可复现、可证伪的问题陈述，不提供具体链码审计结论，不把Caliper示例中的marbles样例宣传为生产基准，也不替代完整实验伦理与数据发布规范。