评估系统时，应把它服务谁、完成什么任务、承受什么故障写清，再选择指标。同一个吞吐量、节点数或能耗数字，在负载、控制结构和统计范围不同的情况下，可能代表完全不同的结果。
判断归属：AI 候选方法。 下面是由架构、共识与隐私边界形成的评估框架，不是已经验证的通用评分标准。
性能必须与任务及负载一起报告#
吞吐量应说明统计的是提交、接受还是成功完成的操作；响应时间应说明起止点，并同时考虑分位数。可用率需要明确服务边界、观测窗口和成功标准。可靠性则涉及故障后能否正确服务、恢复和保存数据，不能由“正常运行时很快”替代。
测试应控制请求大小、到达速率、热点变化、网络、资源和参与者数量。平均值可能掩盖少量长尾失败；只报告高峰值也无法说明持续负载。不存在无需说明应用需求就适用于所有 Web3 服务的统一 TPS 门槛，也不能由采用 IPFS 推出固定可用率。
去中心化先问资源由谁控制#
节点数量并不等于独立控制实体数量。同一组织可以运行许多节点；不同实体也可能共同依赖一个服务入口。应分别追踪共识权、持币或投票权、基础设施、数据来源和升级权限。
基尼系数一类分布指标需要说明测量的是哪项资源；“中本聪系数”式门槛也要说明什么控制足以破坏什么目标。若不先定义控制能力与故障阈值，跨协议比较一个整数容易失真。
安全、能耗与治理都有范围#
安全实验必须先给出攻击者能力与成功条件。一次恶意节点被识别的模拟，只支持该设置中的观察，不能单独证明激励相容、抗所有串谋或完整协议安全。用户账户保护、合约执行和共识容错也应分层评价。
能耗比较要说明时间、设备、系统边界与分摊方法。网络年能耗、每次操作的分摊能耗、边际能耗与全生命周期影响不能混为一谈。尤其不能把不同年代、共识方式和测量范围的数字直接排成优劣表。本轮未重建 CBECI 数据或生命周期模型。
治理与政策还涉及规则制定权、恢复/撤销机制和现实约束。本轮未核查各地法规，不保留具体法律条款断言；标准的存在也不意味着不同应用已实现兼容。需要额外证据的问题保留为开放检验。