主题
Fabric-X 性能基准与数据溯源
本文收录 组合性设计 · 08 扩容指南 中性能 / 吞吐 / 硬件分析所用的全部来源，按可信度分层、逐条溯源。分层与标注约定见 参考资料 · 简介。
摘要：代码常量 / 配置默认值最可信；仓库内上游官方文档次之；外部论文为一手实测来源但须按发表语境理解；
cbdc-chain/docs/（含ARCHITECTURE.md等）已与代码脱节，不作事实依据。
20 万 TPS 账本面参考配置单
本表是 IBM 在 Fabric-X 论文（eprint 2023/1717）中实测达成 >200K TPS（端到端）的真实部署——排序面实测 430K tps、committer 面实测 474K/280K TPS，均为论文实测（✅），非外推。硬件统一为 IBM Cloud 三地域裸金属。使用处见 08 扩容指南。
配置单（应用部署数量 = 论文实测）：
| 平面 | 应用 | 实例数 | 每节点规格 | 实测能力 / 角色 | 依据 |
|---|---|---|---|---|---|
| 排序 | Batcher | 16（4 shard × 4 party） | 96 核 / 64 GB / 1 TB SSD(RAID0) / 10 GbE | 排序峰值 430K tps（4p×4s, 300 B, ~0.6 s） | ✅ §6.2 Fig 7a |
| 排序 | Router | 4（每 party 1） | 同上 | 逐笔处理，CPU 最重（34%） | ✅ §6.2 / Table 3 |
| 排序 | Consenter | 4（每 party 1，BFT f=1） | 同上 | 最轻（CPU 2%） | ✅ §6.2 / Table 3 |
| 排序 | Assembler | 4（每 party 1） | 同上 | 存储最重（持久化全部交易） | ✅ §6.2 / Table 3 |
| 验证 | Signature Verifier | 3 | 96 核 / 64 GB | CPU 最重（55%）；线性可扩 | ✅ §6.3 / Table 4 |
| 验证 | VC（与 DB 同机） | 9 | 96 核 / 64 GB / NVMe | 内存 32 GB、磁盘 29% | ✅ §6.3 / Table 4 |
| 验证 | YugabyteDB | 9（与 VC 同机，分布式） | 同上 | committer 峰值 474K(1/1) / 280K(4/4) | ✅ §6.3 |
| 验证 | Coordinator | 1（单实例，首要瓶颈） | 96 核 / 64 GB | 网络密集(发 2.4 Gbps)、依赖图串行访问 = 限速点 | ✅ §6.3 / Table 4 |
| 验证 | Sidecar | 1（单实例） | 96 核 / 64 GB / NVMe | 从排序服务取块、转发 coordinator | ✅ §6.3 |
| 全局 | 硬件 | — | 双 48 核 Intel Xeon 8260（共 96 核）/ 64 GB / 1 TB SSD RAID0 / 10 Gbps / Ubuntu 20.04；IBM Cloud 3 区（伦敦/巴黎/米兰） | — | ✅ §6 |
节点合计：排序面 28 节点（4 party ×（4 batcher + 1 router + 1 consenter + 1 assembler））+ 验证面 14 节点（9 VC/DB 同机 + 3 verifier + 1 coordinator + 1 sidecar）= 账本面 ~42 节点。论文 §6.4 另以「每组织 21 台服务器」表述（对比 vanilla Fabric 2 台/组织），实测 >400K TPS（组件级）/ >200K TPS（端到端）。
对比：Arma 独立论文（eprint 2024/808，160 B 交易，另一套实验）：
| 环境 | 硬件（论文原值） | 2 shard | 4 shard | 8 shard | 延迟 |
|---|---|---|---|---|---|
| LAN | 14 台裸金属，各 40 核 / 64 GB，<1ms | 225K | 230K | 240K TPS | 700/800/1000 ms |
| WAN（英+意） | 44 台 VM，各 32 核 / 64 GB | 150K | 190K | 220K TPS | ~1000 ms |
三条必读边界
- Coordinator 与 Sidecar 是单实例、不可横向扩（论文 §6.3 +
deployment-guide.md §3.5）；论文实测确认 coordinator 依赖图的串行访问是首要瓶颈，挂 coordinator/sidecar 立即全停（挂 2 个 VC 降到 160K、挂 3 个全停）。 - 本配置达成的是 IBM UTXO CBDC 样例负载（300 B、读写集 1/1–4/4、门限 BLS 签名），非本仓库 cbdc-biz 的 BN254 ZK token transfer（KB 级带范围证明）；换到本部署负载须重新实测。
- 本配置单是账本面。本系统 cbdc-biz 业务面（institution / endorser / auditor / bizhub）另算，端到端被单 auditor 卡在万级（见 08 扩容指南 · 这套系统实际能到多少 TPS）——要给账本面喂满 200k，发起侧还需海量 institution 做 ZK 证明生成（~41ms/笔 ⇒ 约数千核），且须先解除 auditor 单点。当前代码下，"整套 cbdc 系统 20w" 不成立；可成立的是"账本面 20w"。
Fabric-X 论文实测全记录（eprint 2023/1717 = SIGMOD '26）
来源：Fabric-X: Scaling Hyperledger Fabric for Asset Exchange，Elli Androulaki et al.，SIGMOD Companion '26（Bengaluru，2026-05-31）DOI
10.1145/3788853.3803092；IACR eprint2023/1717。2026-06-01 用浏览器 UA 经curl（带 Referer）取得 PDF（13 页）全文——WebFetch 直取返回 403，curl -A <browser-UA> -e <abstract-url>可下载。以下逐条记录论文实测事实。
测了什么（被测系统与负载）
- 系统：Fabric-X —— 解耦微服务化 peer（背书 / 验证 / 提交）+ Arma 分片 BFT 排序服务。实现栈：Fabric Smart Client + Token SDK（钱包 / 背书）；扩展 HLF 排序服务接 Arma；committer 为 Go 分布式服务、gRPC 通信、YugabyteDB 持久化。
- 应用：UTXO-based CBDC，含 ZKP（保密性 + 不可链接性）与门限 BLS 签名（IBM TSS 库）。
- 三阶段分别评测：§6.1 执行（execute / 背书）、§6.2 排序（order / Arma）、§6.3 验证（validate / committer）。
被测交易长什么样（UTXO 结算交易）
- 交易类型：UTXO CBDC 结算交易（settlement transaction）（
§5Tokenized UTXO Approach）。用户钱包构造交易请求 = 待花费 inputs + 新 outputs（收款方 + 找零）+ 付款方签名；token validator 验签/校验格式后生成结算交易——read-set = 输入 key（校验未花费），write-set = 新 output token + 标记输入 token 待删除；经 Arma 排序入块；committer 做双花检查（read-set 输入是否仍未花费），通过则应用 write-set（加新 token、删已花费），否则拒绝。 - 隐私 / 密码学：测了两种模式——完整 ZKP（保密 + 不可链接） 与 仅匿名（更轻，延迟降到几 ms，
§6.1）；背书用非交互门限 BLS 签名（TSS 库）聚合成单个紧凑签名（替代 vanilla Fabric 的多份 X.509），测了 t=3/5/10。 - 基准用的交易规格：
- 排序（§6.2）：主用 300 B 交易；Fig 7b 另变化交易大小（越大吞吐越低，受网络带宽限）。（Arma 独立论文用 160 B。）
- 验证（§6.3）：变化每笔 输入(read-set) × 输出(write-set)，从 1/1 到 4/4（4/4 时吞吐降 41%）；另注入 0–30% 无效签名 与 0–30% 双花交易测其影响。
- 注意：这是 IBM 自带 UTXO CBDC 样例的合成负载，单笔仅 100–300 B / 小 KV；远小于本仓库 cbdc-biz 的 BN254 ZK token transfer（KB 级、带范围证明），故不能据此推断 cbdc-biz 端到端吞吐。
怎么测的（硬件与方法）
- 方法：自研 workload generator 压测；指标经 Prometheus 采集（吞吐 + 99 分位延迟）；每点为 ≥5 分钟、1 秒采样的平均。
- 主部署（结算引擎）：IBM Cloud 三地域（伦敦 / 巴黎 / 米兰）裸金属，双路 48 核 Intel Xeon 8260 @2.40GHz（共 96 核）/ 64 GB RAM / 1 TB SSD（RAID 0）/ 10 Gbps / Ubuntu 20.04。
- 排序跨 DC 实验（§6.2 Fig 7c）：4 个 AWS 站点（Ohio / N. Virginia / N. California / Oregon），每 VM 32 vCPU / 64 GiB / RHEL 10 / EBS gp SSD（3000 IOPS）。
达到什么效果（实测结果，分阶段）
§6.1 执行（token endorser）
- token 生成延迟 100 ms、有效性检查 274 ms（论文原值）。
- 门限 BLS（TSS 库）Table 2：签名 0.147 s（±4%）（t=3/5/10 同）；签名份额聚合 0.124 / 0.241 / 0.624 s（t=3/5/10）。
- 执行阶段（含 ZKP）≤ 20 ms；仅保证匿名时降到几 ms。执行无状态、可水平扩，门限签名对其总延迟影响可忽略。
§6.2 排序（Arma） —— 300 B 交易、延迟 ~0.6 s：
- 峰值 430,000 tps（4 parties + 4 shards）（Fig 7a）。
- party 越多吞吐越低：13 parties + 4 shards = 308,000 tps。
- 交易越大吞吐越低（带宽，Fig 7b）；跨多 DC 延迟 ~0.8 s（Fig 7c）。
- 资源占用 Table 3（负载 100K Tx/s、300 B、4 parties 2 shards）：Router CPU 34%（逐笔处理最重）、主 batcher 发送带宽最高、assembler 存储最重、consenter 最轻。
- 故障（Fig 8，80K Tx/s）：停共识 leader（P1）→ 吞吐归零至选出新 leader；停 shard 主（P2/P3）→ 该 shard 暂时掉量；停非主 follower（P4）→ 无影响。
§6.3 验证（committer） —— 默认配置 = 3 签名 verifier + 9 VC（与 9 个分布式 DB 节点同机）+ 1 coordinator + 1 sidecar，控延迟 < 1 s：
- 交易大小（Fig 9a）：输入/输出 1/1 → 4/4，吞吐降 41%（474,000 → 280,000 TPS），p99 延迟仅 83 → 101 ms。瓶颈 = coordinator 依赖图（单同步原语串行化访问）；瓶颈分析确认 coordinator 为首要限制（签名验证线性扩、VC 吞吐高于系统吞吐）。
- 无效签名（Fig 9b）：无效占比 0% → 30%，吞吐反升 419,000 → 459,000 tps（~10%）（早拒减少 VC 工作），p99 75–83 ms。
- 双花（Fig 9c）：10% 双花 → 吞吐 −33%（419,000 → 280,000）、p99 85 ms → >1,100 ms；30% → −38% 至 260,000 tps（convoy 效应 + 回滚重试）。
- 资源占用 Table 4：签名 verifier CPU 最高 55%；VC+DB 单元内存最重 32 GB、磁盘 29%；coordinator 网络密集（发送 2.4 Gbps）、CPU 仅 17%。
- 故障（Fig 10）：挂 1 个 VC 无影响；挂 2 个 → 降到 160,000 TPS、延迟 3 s；挂 3 个 → 完全停。coordinator / sidecar 挂 → 立即全停。
§6.4 成本对比：Fabric-X >400,000 TPS（= Fabric 2,000 TPS 基线的 200 倍），代价 每组织 21 台服务器（Fabric 为 2 台）。
口径说明：论文自身的「峰值 TPS」随语境不同
同一篇论文给出多个数字，须按语境区分、不可混用：
| 出处 | 数字 | 语境 |
|---|---|---|
| 摘要 / §2 | >100,000 TPS | 端到端整体声明（保守表述） |
| 结论 | >200,000 TPS | 端到端峰值 |
| §6.4 成本分析 | >400,000 TPS | 对比 Fabric 基线 |
| §6.2 排序 | 430,000 tps | 仅排序服务，4p+4s，300 B，~0.6 s |
| §6.3 验证 | 474,000 TPS | 仅 committer，1in/1out（4/4 时 280,000） |
即：单看排序或committer 验证组件可达 ~43–47 万 tps，但端到端论文落在 >20 万（结论）/ >10 万（摘要）；仓库
fabric-x/README.md:11取的是 >200,000 TPS。本配置单的「20 万」对应论文端到端结论量级。仍须注意：这些是 IBM 的 UTXO CBDC 样例 + 300 B / 小 KV 负载，非本仓库 cbdc-biz 的 BN254 ZK 负载，cbdc-biz 端到端另受单 auditor 限制（见 08 扩容指南）。
Arma 论文实测全记录（eprint 2024/808）
来源：Arma: Byzantine Fault Tolerant Consensus with Horizontal Scalability，Yacov Manevich / Hagar Meir / Kaoutar Elkhiyaoui / Yoav Tock / May Buzaglo，IBM Research（Zurich / Haifa）；IACR eprint
2024/808（同arXiv:2405.16575）。2026-06-01 用浏览器 UA 经curl取得 PDF（26 页）。Arma 是 fabric-x-orderer 的排序协议（fabric-x-orderer/README.md:36引用）。
测了什么
- Arma BFT 排序协议：把交易的分发 + 验证与共识解耦——共识只对「批的元数据」做全序；分片（shard）各管一部分交易，每分片每 party 一个 batcher。带抗审查（最大包含时限）与去重。
- 评测两套原型：① Arma 嵌入 Fabric 排序节点（OSN）；② 全分布式独立 Arma（LAN / WAN）。
- 摘要结论：独立系统 >200,000 tps；嵌入 Fabric 使其共识提速一个数量级。
怎么测的（硬件与方法）
- 嵌入 Fabric（§6.1）：客户端在英国，交易 300 B 与 3.5 KB（后者 = 标准 Fabric 交易大小）；OSN 跨 英 / 意 / 法 三 DC（延迟 英-法 10ms、英-意 20ms、意-法 17ms）；硬件 裸金属 Ubuntu 22.04，96 核 Intel Xeon 8260 @2.40GHz（48 核 ×2 线程）+ 64 GB + Broadcom 9460-16i RAID0 双 SSD；OSN 数 4 → 16。
- 全分布式（§6.2）：4 party = 4 router + 4 consensus + 4 assembler + 4×（分片数）batcher；客户端发 160 B 交易到所有 router；批上限 10000 / 500ms。方法：阶梯加压，端到端延迟 >5s 即停，取「延迟 <5s 的最高速率」。
- LAN（§6.2.1）：14 台裸金属，各 40 核 + 64 GB，同 DC <1ms。router+consenter 同机（4 台），其余 batcher+assembler 摊在另 10 台（2/4/8 分片 = 8/16/32 batcher）。
- WAN（§6.2.2）：44 台 VM，各 32 核 + 64 GB，跨英 + 意 3 DC，每进程独占一 VM。
实测部署清单（硬件 × 应用数量，论文原值）：
| 实验 | 单节点硬件 | 应用部署数量 | 机器数 |
|---|---|---|---|
| 嵌入 Fabric（§6.1.1） | 裸金属 Ubuntu 22.04，96 核 Xeon 8260（48×2 线程）/ 64 GB / Broadcom 9460-16i RAID0 双 SSD；英/意/法 3 DC | 每个 Fabric OSN 进程 = 1 router + （每分片 1 batcher）+ 1 consensus + 1 assembler（全部同进程） | 4 → 16（OSN 数） |
| 分布式 LAN（§6.2.1） | 40 核 / 64 GB 裸金属，同 DC <1ms | 4 party = 4 router + 4 consensus + 4 assembler + 4×分片数 batcher（2/4/8 分片 → 8/16/32 batcher，8 分片共 44 进程） | 14：4 台跑 router+consenter（同机），余 10 台均摊 4 assembler + 8/16/32 batcher |
| 分布式 WAN（§6.2.2） | 32 核 / 64 GB VM，英+意 3 DC | 同上（8 分片 = 44 进程），每进程独占 1 VM | 44 |
注：Arma 论文给出了硬件与应用部署数量（上表），但未给每组件的 CPU/磁盘/网络资源占用表——那类逐组件占用表只在 Fabric-X 论文（Table 3 排序面 / Table 4 committer，见 Fabric-X 实测全记录）。
达到什么效果
- 嵌入 Fabric（§6.1，Fig 6）：节点越多吞吐越低；3.5 KB 交易比 300 B 大 11.6×，但吞吐仅低 ~6×。对 Fabric 是约一个数量级提速：~2K → ~20K TX/sec。
- 分布式 LAN（§6.2.3，Fig 7）：2/4/8 分片 = 225K / 230K / 240K TX/sec，延迟 700 / 800 / 1000 ms。增幅有限——更多 batcher 仍挤在同 10 台机。
- 分布式 WAN（Fig 8）：2/4/8 分片 = 150K / 190K / 220K TX/sec（增幅更明显，因每加分片也加机器）。低负载（100K）时各分片数延迟相近（LAN 700ms / WAN 1000ms），仅饱和后才显出加分片收益。
- 容错（§7）：
F < N/3；可容忍 F 个 router、每 shard F 个 batcher、F 个 consensus 节点故障。α-validity：Arma 允许一部分交易不经验证即被全序，靠下游（如 Fabric 的验证层）丢弃无效交易。
与 Fabric-X 论文（2023/1717）的关系：两篇是不同实验。本篇（Arma）聚焦排序协议本身（160 B 独立分布式达 240K(LAN)/220K(WAN)；300 B/3.5 KB 嵌入 Fabric）；Fabric-X 论文用 300 B 端到端达排序 430K、committer 474K。配置单的排序面以 Fabric-X 论文的 4p×4s 为准，本篇提供 160 B 的「分片→吞吐」对照。
外部一手来源（论文）
| 文献 | 标识 / URL | 提供的数据（详见上方实测全记录） | 访问状态（2026-06-01） | 仓库引用处 |
|---|---|---|---|---|
| Arma: BFT Consensus with Horizontal Scalability（IBM Research，Manevich et al.） | eprint 2024/808 · arXiv:2405.16575 | 排序协议实测：独立分布式 240K(LAN)/220K(WAN) @160B、嵌入 Fabric ~20K @300B/3.5KB —— 见 Arma 实测全记录 | ✅ 已抓取（curl 浏览器 UA + PyMuPDF；WebFetch 直取 403） | fabric-x-orderer/README.md:36、fabric-x/README.md:44、docs/fabric-x/02-architecture.md |
| Fabric-X: Scaling Hyperledger Fabric for Asset Exchange（SIGMOD '26，Androulaki et al.） | eprint 2023/1717 · DOI 10.1145/3788853.3803092 | 端到端 UTXO CBDC 三阶段实测：排序 430K、committer 474K、端到端 >100K/>200K TPS；IBM Cloud 96 核裸金属 —— 见 Fabric-X 实测全记录 | ✅ 已抓取（curl 浏览器 UA + PyMuPDF；WebFetch 直取 403） | fabric-x/README.md:11,117、fabric-x/docs/index.md:495 |
两篇均为排序 / 验证组件级或端到端吞吐，不含本仓库 cbdc-biz 的 BN254 ZK 负载，cbdc-biz 端到端另受单 auditor 限制（见 08 扩容指南）。
仓库内上游官方文档（IBM/Hyperledger，随 submodule 签出）
| 文档 | 关键数据 / 用途 |
|---|---|
fabric-x/README.md:11,117 | 200k TPS 声明 + 指向 Fabric-X 白皮书 |
fabric-x-committer/docs/deployment-guide.md §1–4 | 「sized for 50,000 TPS」硬件规格（Sidecar/Coordinator ×1、Verifier ×3、VC ×6、YugabyteDB ×9 RF=3、Query ×2+，多为 32 核，DB/Sidecar NVMe，10 Gbps）；扩容指引（§3）；Sidecar/Coordinator 单实例仅纵向（§3.5）；启动顺序（§4） |
fabric-x-committer/docs/performance-tuning.md | 吞吐参数与默认值：verifier parallel-executor.parallelism=40（假设 32+ 核，:133-137）、coordinator local-dep-constructors=1（>2-4 收益递减，:107-109）、VC 三级 worker（:173-189）、in-flight 上限默认 2000 万（:65） |
fabric-x-committer/docs/architecture.md:166 / index.md:37 | YugabyteDB 商用硬件 >100,000 TPS |
fabric-x-committer/docs/loadgen-artifacts.md | committer 压测负载生成工具 |
fabric-x/docs/concepts/endorser.md:103,436,442 | 背书模型吞吐：FSC ~50K、阈值签名 ~40K、自定义 ~10K TPS（各带 10–30ms 延迟） |
fabric-x/docs/intro/usecases.md:10,32,40 | 分片实现 >100K TPS、线性随分片扩展、无单点 |
fabric-x/docs/architecture/transaction-flow.md:126,557 | 背书延迟 P50 25ms/P99 100ms（双 endorser）、ECDSA 签名 2ms；「4–8 分片起步、按负载扩」 |
fabric-x/docs/architecture/index.md:23 | 免责声明：实际吞吐取决于硬件/分片/DB/网络，须自行 benchmark |
fabric-x-orderer/config/defaults.go:56-68、node/batcher/batcher_role.go:319-379 | 批参数代码常量：MaxMessageCount=10000、AbsoluteMaxBytes=10MiB、BatchCreationTimeout=500ms |
本部署（cbdc-chain）吞吐上界与瓶颈的代码/基准依据
| 主题 | 数据 | 出处 |
|---|---|---|
| HSM 签名上界 | Luna S790 标称 22,000 tps（ECC P-256）、SoftHSM ~11,000；session pool 默认 5 / 最大 30 | sign-kms/README.md:128-129、sign-kms/pkg/pkcs11/session_pool.go:18-19 |
| 一把 key 绑一台 HSM | 每 namespace 经 ns.ProviderID 解析唯一 provider，无单 key 跨多机负载均衡 | sign-kms/internal/biz/kms_biz.go:58-87、internal/conf/conf.proto:51-52 |
| 每笔 auditor HSM 签名 = 1 | 整笔一条 MarshallToAudit 消息签一次，与 input/output 数无关 | fabric-token-sdk token/services/ttx/auditor.go:386-392 |
| 每笔 transfer 的 KMS 签名总数 = 4 | auditor 1 + endorser 1 + institution 节点 2（proposal + envelope，同 key 两次独立 Sign）；owner 外部注入不占 KMS | fabric-token-sdk token/services/network/fabric/endorsement/fsc/initiator.go:77,106、responder.go:332-354 |
| SoftHSM2 签名串行、并发不扩 | pool=1/并发 1 ≈ 10,200 tps；pool=10/并发 50 ≈ 11,400（并发 ×50 仅 +12%）⇒ 单实例 ≈ 1/签名延迟；同实例多 token 共享天花板；多 provider 指同一 .so 无增益 | sign-kms/README.md:119-128（M4 Pro 实测）、sign-kms/conf/core.yaml:27-38 |
| 上游 FSC 业务层（节点级）无实测 TPS | token-sdk 仅提供四层压测 harness（Local/API/gRPC/两机），仓库未公布任何节点级结果；文档示例行「30,000,000 ns/op = 33,333 TPS」自相矛盾（30ms/op 对应 ~33 ops/s），不可引用；Fabric-X 论文 §6.1 对执行/背书层只给延迟（执行 ≤20ms、token 生成 100ms、有效性检查 274ms、BLS 0.147s）不给 TPS；fabric-x/docs/concepts/endorser.md 的「FSC ~50K」为无条件标称 | fabric-token-sdk/docs/drivers/benchmark/token_validation_service_benchmark.md:232-242、fabric-token-sdk/cmd/token_validation_service/ |
| ZK 证明生成实测 | BN254 2in2out / 10 worker = ~241 ops/s，P50 ~41ms/笔 | fabric-token-sdk/docs/drivers/benchmark/core/dlognogh/dlognogh.md:192-257 |
| 本部署 ZK 曲线 = BN254 | tokengen 默认 BN254 且 gen_crypto.sh 未传 --aries | cbdc-biz/scripts/gen_crypto.sh:85-89、fabric-token-sdk/cmd/tokengen/cobra/pp/zkatdlognoghv1/gen.go:131-134 |
| committer Coordinator 单活跃流 | streamActive 单 mutex、单 goroutine 全局依赖图、local-dep-constructors 默认 1 | fabric-x-committer service/coordinator/coordinator.go:52-58、dependencygraph/global_dependency_manager.go:44,124-188 |
| auditor 单进程 / 单写 | 单签名身份、audit_worker_pool ≤ 32×GOMAXPROCS、auditdb 进程内锁、协议 1-of-N 视所有 auditor 公钥为一逻辑实体 | cbdc-biz/conf/auditor/core.yaml:189-205、pkg/workerpool/pool.go:49、fabric-token-sdk token/services/storage/auditdb/store.go:278-298、token/core/common/validator_auditing.go:22-77 |
| owner 签名外部注入 | 银行自托管 X.509 预签名，不占中心 HSM | cbdc-biz/pkg/views/transfer.go:662,694 |
| 压测工具 | cbdc-stress：-c/-d/-mode ring，输出 P50/P90/P99 | cbdc-stress/main.go:26-35 |
访问与方法说明
- 两篇论文于 2026-06-01 抓取：
eprint 2024/808（Arma，26 页）与eprint 2023/1717（Fabric-X，13 页）此前 WebFetch 直取均 HTTP 403，改用curl带浏览器 UA + Referer 下载 PDF、用 PyMuPDF 提取全文后逐条记录。两篇的硬件、拓扑与三阶段/分片实测均已补全（见上方两份实测全记录）。 - 08 扩容指南中「实测/标称」数字均注明来源层级；凡标 【规划假设】 的为推导示例（如每节点吞吐→副本数），须以 cbdc-stress 实测替换。
- 不引用
cbdc-chain/docs/（如ARCHITECTURE.md:68的「4 方跨地域 200k+ TPS / ~0.8s」）作为依据——该目录已与代码脱节，仅可视为对上述论文的转述线索。
相关阅读
- 组合性设计 · 08 扩容指南 —— 本文数据的使用处（5 万 / 20 万 TPS 模型）
- fabric-x · 架构、fabric-x-committer · 架构、fabric-x-orderer · 架构