cbdc-solution · 核心流程

1. 开发环境启动

应用启动顺序在 controller 中为：BizHub → Issuer → Auditor → Endorser → Wallet Node → Central → Facade。

2. WebSocket P2P 启动

四个 Token 节点启动时读取 fsc.p2p：

1. 以 node.crt / node.key 建立 WebSocket TLS listener；
2. serverRootCAs 与 clientRootCAs 都信任 Fabric CA 根链；
3. resolver 的 P2P 地址必须与对端证书 DNS SAN 匹配；
4. maxSubConns: 8192 提高每会话子连接承载量；
5. 节点注册同步器再从 BizHub 更新动态 resolver。

3. 银行请求鉴权

调用方机构身份来自签名缓存，不来自请求体中的 institution_code。

4. 钱包创建

普通 X.509 创建可恢复、可重试；Facade 不返回 Wallet Node 地址或 shard routing。私钥由银行生成并持有，平台只接收 CSR 或 Idemix member material。

5. 两步转账

策略钱包可返回多个 eligible_keys 和 required_signatures；key_id 绑定实际签名成员。Finality Worker 在提交成功后确认选币，失败或超时则解锁。

6. 动态节点注册

Auditor 和 Endorser 启动后以 NodeRegistrar 向 BizHub 注册自身外部可达地址；Wallet Node 与 Issuer 以 ResolverSync 周期拉取 Auditor / Endorser 快照并更新本地 FSC endpoint service。BizHub 校验证书角色和实例绑定，Central 通过 management API 管理注册元数据。

7. 结算与 RTGS

BizHub Runtime 承担结算状态机：

本地 cbdc-rtgs-mock 通过文件目录模拟 RTGS 对手方，无独立服务端口。

8. 数据迁移

BizHub 与 Central 分别拥有迁移链：

• bizhub migrate -conf ... 管理 cbdc_biz；
• central migrate -conf ... 管理 cbdc_central；
• Compose / K8s 用 one-shot job 或 initContainer 在服务启动前执行；
• Runtime / Management / Central 正常启动不做自动 DDL。