参考架构
示意数字资产基础设施
数字资产产品背后的链下基础设施：区块链节点、钱包服务、安全的密钥管理、索引、交易监控和 API 网关。
问题
设想一家企业，需要代表用户或为自身资金在一条或多条公有区块链上持有、发送和接收数字资产。它必须生成充值地址、识别转入的资金、为转出的交易签名，并通过自己的应用呈现准确的余额和历史记录。
区块链是一种不同寻常的依赖。交易不可逆，在达到最终性之前确认只是概率性的，区块可能被重组，手续费会波动，而私钥一旦泄露，事后轮换也无法挽回损失。链本身不提供的安全性、可审计性和运营控制，必须由围绕链的基础设施来补足。
设计必须满足的需求
- 私钥绝不能以明文形式出现在应用内存、日志、备份或运维人员的机器上。
- 每一笔转出交易都必须通过策略检查，大额转账必须获得不止一人的审批。
- 余额必须由已最终确认的链上数据推导得出，并在发生链重组后自动修正。
- 失去任何单个节点或 RPC 服务商，都不得导致充值无法识别或提现无法广播。
- 交易必须经过筛查和监控，并完整留存每一笔由谁申请、谁审批、谁签名的审计轨迹。
- 新增对另一条 EVM 兼容链的支持，应当只是配置和测试工作，而不是重写。
设计
组件
应用与 API
- 客户端应用
- API 网关
- 合作方 API
- 运营控制台
钱包与交易
- 地址管理
- 交易构建器
- Nonce 与手续费控制
- 策略引擎
密钥管理
密钥绝不离开签名边界
- HSM
- MPC 签名
- 多人审批门限
- 密钥轮换
节点 / RPC 层
- 全节点
- RPC 服务商
- 故障切换路由
- Mempool 访问
索引与分析
链上数据在最终确认前都是暂定的
- 区块摄取
- 事件解码
- 重组处理
- 查询 API
监控与合规
- 交易监控
- 地址筛查
- 审计轨迹
- 告警
API 网关
一个经过认证的统一入口，服务于内部应用和合作方集成。凡是涉及价值转移的请求，它都强制执行限流、请求签名和幂等键。提现接口与只读接口相互分离，以便施加更严格的控制和独立的配额。
钱包服务
钱包服务从分层确定性密钥派生充值地址，将其映射到账户，并跟踪平台所控制的地址。它把服务日常提现的热钱包，与存放储备的温钱包和冷钱包层级区分开来。各层级之间的归集和再平衡是受策略约束的显式操作。
交易服务与策略引擎
该服务负责构建交易、管理 nonce、估算手续费，并在交易卡住时处理替换。在任何内容被签名之前，策略引擎会评估限额、频率规则、目标地址白名单和审批要求。该服务以显式状态机的形式，跟踪每笔交易经历提交、上链和最终确认的全过程。
安全的密钥管理
签名在硬件安全模块内部完成，或通过多方计算完成：密钥分片由不同的参与方分别持有，完整密钥从不被拼合。签名边界只接受带有有效策略决定和所需审批的请求。密钥仪式、备份和恢复都是成文并经过演练的流程。
区块链节点与 RPC 层
平台通过一个由自营全节点和外部 RPC 服务商组成的资源池读取链上数据并广播交易。路由层检查节点健康状况和区块高度，自动进行故障切换，并对关键读取在多个来源之间比对结果。通过多条路径广播，可以降低交易被悄悄丢弃的概率。
索引器
索引器摄取区块，解码转账和合约事件，并以区块号和区块哈希为键写入关系型存储。在区块达到配置的最终性深度之前，数据都被标记为暂定；遇到重组时，则回滚并重放受影响的区块。应用从这个存储读取余额和历史记录，而不是实时调用 RPC。
交易监控与筛查
转入和转出的资金都会对照地址风险数据进行筛查，并按行为规则检查，例如拆分交易或异常的交易频率。告警会生成待审核的案件，被标记的提现在签名之前就被扣留，而不是事后再调查。该组件的设计目的是支持组织履行合规义务，它并不能替代这些义务。
可观测性与审计
仪表盘对照阈值跟踪节点滞后、索引器滞后、待处理交易的滞留时长、手续费支出和热钱包余额。每一次请求、策略决定、审批和签名都写入只追加的审计日志。一个周期性任务会把内部账本与链上余额进行对账，并上报任何差异。
取舍
设计决策
| 决策 | 理由 |
|---|---|
| 采用 MPC 或 HSM 签名，而不是由应用持有密钥 | 把密钥放在应用配置里简单又快，却会让任何一次服务器被攻破都变成全部损失。硬件签名或多方签名会增加延迟、成本和操作流程，而这正是消除“密钥可以在某一个点被窃取”所应付出的代价。 |
| 分层钱包结构，只保留少量热钱包余额 | 把全部资金放在热钱包里，提现可以即时完成，风险敞口也最大。只让日常周转所需的流动性保持在热钱包中，可以限制攻击者或软件故障所能触及的范围，代价是需要执行再平衡操作，并且在热钱包余额不足时偶尔会出现提现延迟。 |
| 自营节点与外部 RPC 服务商结合使用 | 只依赖一家服务商成本低，却形成了一个可能限流、滞后或下线的依赖。运行节点是实实在在的运维负担，因此设计上两者并用：自有节点用于保持独立性和进行验证，服务商用于提供突发容量和地域覆盖。 |
| 使用专门的索引器，而不是按需查询链 | 实时 RPC 查询无法高效回答诸如账户完整历史这类问题，还会让用户看到尚未最终确认的数据。索引器是又一个需要构建并保持同步的系统，但正是它让余额查询快速、一致，并在重组之后依然正确。 |
| 只在达到配置的最终性深度后才为充值入账 | 在首次确认时就入账感觉更快，却可能为一笔之后被重组掉的转账入账。等待最终性会让资金可用时间推迟一段因链而异的时长，这一过程会以“待确认”状态告知用户。 |