把本机 SQLite 事务每秒完成数与公链每秒提交数写在一张柱状图，不是同条件对比：前者可能只是单机持久化确认，后者可能只是在远端 RPC 接受待处理交易。区块链（36）：节点备份、RPC 与终局停滞不能混成“服务异常”的链头延迟和终局停滞，也不能压成一个平均请求耗时。

flowchart LR
  S[客户端发送] --> R[RPC 接收]
  R --> I[区块纳入]
  I --> E[执行成功]
  E --> F[按网络定义终局]
  F --> B[业务条件与资产对账完成]

固定硬件、节点数、软件 SHA、网络拓扑、负载分布、批次大小、资产类型和成功定义，分别报提交延迟、纳入延迟、执行失败比例、终局/业务延迟及尾部值。成本同时包含用户交易费、节点 CPU/内存/磁盘/带宽、证明生成与验证、运维备份和争议期资金占用；不能只用低平均 gas 宣称总体最便宜。安全模型也不同：许可网络牺牲开放性，rollup 可能依赖 L1 数据和有权退出的桥，传统数据库则依赖运营者。

先定义可复算的测量记录

对于订单 o，保留五个不同的 UTC 时间戳：t_submit（发起方发送）、t_accept（节点收到）、t_include（取得纳入位置）、t_final（根据选定网络规则满足终局策略）、t_business（链外履约和资产对账一致）。t_accept - t_submit 是接入开销；t_include - t_submit 才包括等待打包；t_business - t_submit 不能被平均块间隔取代。某些系统没有与公链同义的 t_final，不能用本地日志的“已提交”强制映射。统计时对每个订单保留成功/失败与原因、是否仍在观测窗口、发生重组时回退到哪个位置；未终局的订单属于未完成或删失样本，不得只从已完成订单取平均值。

对比实验应先发同样的合成订单分布，固定并发与重试策略，再公布处理率 满足业务谓词的订单数 / 测量秒数。报告中分别给 P50、P95、P99、超时比例与故障恢复时间；每次运行保存节点与客户端软件 SHA、数据库索引、工作负载种子、负载发生器日志、网络丢包、开始结束时间。把多机构许可网络的四节点测量与单进程 SQLite 放在同一图并非不可行，但图例必须指明各自的故障假设、持久化层级和可用资源；数据不能假装来自尚未运行的系统。

练习一：100 次 RPC 接收成功，其中 10 次执行 revert，能称 100 次成功业务交易吗？答案：不能；需明确分母和后续终局。练习二：将交易打包间隔缩短但数据仍延迟发布，用户真实可退出延迟必减吗？答案：不一定；数据取得与结算仍是单独瓶颈。没有冻结硬件与真实网络，所有吞吐/成本实测 NOT_RUN，不虚构 TPS、TVL 或用户规模。

可迁移原则：跨系统比较先统一输入负载和成功谓词。参考：Ethereum 节点运行、Bitcoin Core 文档（系统与版本参数待核）；导航：区块链（36）：节点备份、RPC 与终局停滞不能混成“服务异常” · 37 · 区块链（38）：从合成订单到最终对账需要哪些证据。