跑分首先要说明测量对象
区块链跑分数据有哪些常见问题，首先取决于“跑分”测的是什么。本文讨论交易处理与区块处理性能。以太坊区块文档说明，交易被组织进区块，并由其他节点重新执行、验证状态变化；比特币开发指南则说明，全节点独立验证区块，网络还可能出现临时分叉。这些机制意味着，提交请求、收录交易和确认交易属于不同的测量环节。
问题一：把提交速度当作处理速度
每秒提交多少笔请求，只能描述测试端施加的负载。若指标声称反映链上吞吐量，就需要交代统计的是已收录交易、执行成功交易，还是满足特定确认条件的交易。缺少这一口径，较高的请求量无法直接证明网络完成了同等数量的有效处理。
问题二：交易数量相同，工作量不同
以太坊使用 gas 衡量执行资源消耗，区块受到 gas 上限约束；比特币一笔交易可以包含多个输出。因此，一笔交易并不对应固定计算量或固定数量的支付动作。比较每秒交易数时，应说明交易类型、复杂度及统计单位，否则简单交易与复杂业务的成绩容易被误读为同等负载下的差异。
问题三：用出块节奏代替用户等待时间
出块间隔描述相邻区块之间的时间，无法单独说明某笔交易从提交到收录需要多久。以太坊的时隙可能没有区块，比特币出块时间也具有随机性。因此，用单个区块的交易数除以理想出块间隔，只能得到特定假设下的估算；实测应明确观察窗口，并计入窗口内的实际等待。
问题四：忽略分叉与确认口径
比特币开发指南指出，同一高度可能出现不同区块，节点最终依据累计工作量选择有效链。统计若包含后来退出主链的区块，可能高估最终保留的交易量。确认耗时也需要注明起止条件：首次收录、后续确认与最终性并非可以任意替换的概念，不同机制之间应先明确比较目标。
问题五：缺少适用条件，却扩大结论
区块容量受到资源约束，节点还要承担传播、验证和存储工作。跑分报告应交代软件版本、节点配置、网络条件、负载组成、测试时长与失败处理方式，让读者判断结果适用于什么环境。短时峰值不足以独立证明持续处理能力；单项吞吐指标也不足以证明整个系统在安全性、去中心化程度或用户体验上更优。