Bata 测试版 TP 全面说明：从加密资产到智能支付监控

以下为 Bata 测试版 TP（Test Prototype）的全面说明，面向参与测试与评估的团队/开发者/风控人员。文中涉及的字段、流程与参数可根据实际测试网配置进行微调。

一、加密资产（Assets）

1）支持的资产类型

- 账户型资产：以“余额/账本行”形式管理，适用于链上或链下托管。

- 代币型资产：基于合约/映射账本（如 ERC-20 类），以合约地址与精度为准。

- 稳定币与包装资产：通常配套“价格/锚定”评估模块，用于降低清算波动风险。

2）资产识别与最小单位

- 每种资产需定义：资产ID（或合约地址）、精度 decimals、链网络标识 chainId、最小划转单位 minUnit。

- 所有金额在系统内部以“最小单位整数”计算，展示层再按 decimals 还原为可读数。

3）额度与风控约束

- 测试阶段可启用额度上限：单笔限额、日累计限额、地址/账户分组限额。

- 风控策略可基于地址标签（高风险/白名单）、历史行为与异常频率触发。

二、区块高度（Block Height）

1）区块高度的作用

- 用于确定：交易确认状态、回执有效窗口、清算结算时点、重放保护边界。

- TP 将区块高度作为“时间度量”的主要依据之一，避免仅依赖本地时间造成偏差。

2）确认与最终性

- 定义确认阈值 confDepth：当区块高度满足 currentHeight - txIncludedHeight >= confDepth 时，交易被标记为“可清算”。

- 对于具备更高最终性的链，可降低 confDepth 或改为基于最终性信号。

3）高度追踪与数据快照

- 系统维护：lastProcessedHeight（最后处理高度）与 targetHeight（待处理高度）。

- 每轮处理基于区块区间 [lastProcessedHeight+1, targetHeight] 进行扫描与落库。

- 清算相关表建议引入快照字段 snapshotHeight，确保审计可追溯。

三、清算机制（Clearing）

1）清算目标

- 将“已完成支付/已确认订单”转换为“可结算的余额变动”。

- 支持多资产、多链路的记账与对账。

2）清算触发时机

- 触发条件：

a) 支付交易确认达到阈值（基于区块高度）；

b) 订单状态达到完成（如已签收/已完成商户回调）；

c) 风险评估通过或进入“待复核”队列。

- TP 推荐分两阶段：

- 阶段A：可清算（status=clearing_ready）

- 阶段B：完成清算（status=cleared）

3）清算方式

- 实时清算：在满足确认条件后立即结算，适合高吞吐支付。

- 延迟清算：以批次方式按高度区间结算，适合对账和审计可控性要求更高的场景。

4）清算一致性与幂等

- 幂等键：建议使用 paymentId / txHash + index（若存在多笔拆分）。

- 处理流程需具备：重复回调不导致重复入账。

- 建议采用“状态机 + 事务锁/唯一约束”保证一致性。

四、费用计算（Fee Calculation）

1）费用构成

- 网络费用：由链上 gas、或链路转账成本构成。

- 服务费（Protocol Fee）：TP 平台服务抽成，可能按固定值或按比例。

- 风控/审计成本（可选）https://www.cdschl.cn ,：用于覆盖额外校验或保险金机制。

2）费用计算原则

- 金额计算统一使用最小单位整数。

- 比例费率需明确：feeRate（如 0.3%）、计费基数 feeBase（通常为订单金额或成交金额）。

- 舍入规则：建议固定采用“向下取整”或“银行家舍入”，并在文档中写明。

3）示例（说明用）

- 若订单金额为 A（最小单位），服务费率为 r（例如 r=30bps），则：

fee = floor(A * r / 10000)

- 若存在免手续费门槛，可定义：如果 A >= threshold 则 fee=0。

4）费用归属

- 费用支付方：用户/商户/由系统垫付后在清算中扣回。

- 归集账户：费用可单独入账为 feeLedger，便于财务对账与审计。

五、安全支付保护（Security Payment Protection）

1）威胁模型（常见风险）

- 重放攻击：同一签名/交易在不同上下文被重复提交。

- 中间人/回调篡改：商户回调内容被替换或延迟到错误状态。

- 地址冒充与钓鱼：欺诈地址接收资产。

- 余额被透支：并发下重复扣减导致超额。

2）核心保护机制

- 交易唯一性：用 txHash、nonce 或 paymentId 做强幂等校验。

- 签名校验：对关键字段进行签名验证（订单号、金额、链ID、有效期）。

- 有效窗口：引入 expiresAt / validityHeight，超时拒绝或进入人工复核。

- 回调验签：商户回调必须携带签名，TP 校验签名与回调主题字段一致。

3）安全支付流程建议

- 建议支付建立“预订单预授权”状态：

- 先生成 paymentIntent（包含金额、资产、目的地址/路由信息）

- 确认交易回执达到阈值后，再写入“已清算/已完成”。

4）异常处置

- 风险触发：进入 quarantine（隔离队列）或 manualReview（人工复核）。

- 失败/回滚策略：对未达确认阈值的支付，避免做最终入账；对超时订单执行退款或释放占用额度。

六、数据评估（Data Evaluation）

1）数据评估的目的

- 验证链上事实与系统账本一致。

- 衡量风控有效性与清算准确度。

- 形成可审计的数据底稿。

2）关键评估指标

- 命中率：清算触发的订单中成功清算比例。

- 对账差异：系统账本余额与链上实际余额差（可按资产/地址维度）。

- 延迟分布：支付确认到清算完成的耗时分位数（P50/P95/P99）。

- 错误率：失败回调、验签失败、幂等冲突、状态机异常的计数。

3）数据一致性校验

- 前置校验：字段完备性、金额单位一致性、链ID正确性。

- 后置对账：

- 清算流水与链上交易列表比对；

- 每笔入账对应唯一事件来源（来源事件 eventRef）。

4）数据质量分层

- 原始数据（Raw）：来自链上/回调。

- 解析数据（Parsed）：校验并标准化后的字段。

- 结算数据（Settled）：最终写入账本的结果。

- 建议对每层保留校验码或 hash，确保可追溯。

七、智能支付监控（Intelligent Payment Monitoring）

1）监控目标

- 实时发现异常交易、异常费用、异常清算延迟。

- 通过规则 + 模型（可选）自动分级告警。

2）监控维度

- 交易维度：成功率、失败码分布、重试次数。

- 金额维度：异常大额、异常拆分频率、手续费偏离。

- 高度维度：区块延迟导致的确认积压。

- 账户维度：单地址高频、黑名单命中、资金流向异常。

3）告警策略（示例）

- 硬阈值告警：

- confDepth 达到但仍未进入 clearing_ready

- fee 超出预期上限（如超过订单金额的某比例）

- 软阈值告警：

- P95 清算延迟超过基线

- 某资产对账差异持续放大

- 黑白名单：命中直接触发人工复核。

4）智能化建议

- 自动归因：告警聚合到根因（链上拥堵、验签失败、状态机卡住、数据库写入失败）。

- 自愈策略：

- 对可重放的缺失数据执行补偿扫描；

- 对幂等冲突仅记录不写入；

- 对隔离队列定时重新评估（基于最新风险策略）。

结语：测试版 TP 的落地要点

- 明确资产与最小单位，保证费用与清算计算的一致性。

- 以区块高度为准绳实现确认阈值与清算时点控制。

- 用状态机 + 幂等键 + 唯一约束实现清算一致性。

- 通过签名验签、有效窗口与幂等校验形成安全支付保护。

- 用数据评估体系持续度量对账差异与延迟表现。

- 通过智能监控将异常快速分级定位并推动自动补偿。

注：以上为测试版说明框架，实际字段名、API 与参数需以 Bata 测试网部署配置为准。