功能规范：多平台账户凭据管理与签名服务

功能分支：002-multi-platform-account-management 创建日期：2025-09-28 状态：草稿输入：用户描述："实现多平台多账户的私钥等凭据存储，并且能实现对应平台管理账户的权限功能（签名），智能方便统一的账户信息注入方式"

执行流程（main）

1. 解析 Input 中的用户描述
   → 若为空：报错 "No feature description provided"
2. 从描述中提取关键概念
   → 识别：参与角色、关键操作、数据、约束
3. 对每个不清晰点：
   → 使用 [NEEDS CLARIFICATION: 具体问题] 标记
4. 补全"用户场景与测试"章节
   → 若无法识别明确流程：报错 "Cannot determine user scenarios"
5. 生成功能需求
   → 每条需求必须可测试
   → 含糊需求需标记
6. 若涉及数据：识别关键实体
7. 执行"Review Checklist"
   → 若存在 [NEEDS CLARIFICATION]：警告 "Spec has uncertainties"
   → 若出现实现细节：报错 "Remove tech details"
8. 输出成功，说明规范可进入规划阶段

⚡ 编写指引

✅ 聚焦用户价值与业务目标
❌ 避免实现细节（语言、框架、API）
👥 面向业务干系人而非开发者

Clarifications

Session 2025-09-28

Q: 凭据存储的加密级别要求是什么？ → A: 不用存储这一部分是从外部注入（注入方式配置文件读取）方便其他组件使用的
Q: 配置文件的格式和结构要求是什么？ → A: 推迟到规划阶段决策
Q: 系统如何处理账户凭据的动态重载？ → A: 支持热重载，监控配置文件变化自动更新
Q: 权限控制的粒度级别是什么？ → A: 平台级别（模块可访问整个平台的所有账户）
Q: 系统支持的最大并发签名请求数量级别？ → A: 小规模（<100 QPS）

用户场景与测试（必填）

核心用户故事

交易系统开发者和运维人员需要一个统一的账户凭据管理服务，能够从外部配置文件读取并管理多个加密货币交易所（Pacifica、Aster、Binance等）的私钥和API凭据，提供标准化的签名服务和账户信息注入功能，使得上层交易应用能够无缝接入不同平台而无需关心底层凭据管理的复杂性。

验收场景

给定需要添加Pacifica账户凭据，当提供Ed25519私钥、账户ID和子账户信息时，则系统能够安全存储并支持Solana基础的签名操作。
给定需要添加Binance账户凭据，当提供API Key、Secret Key和权限配置时，则系统能够存储并支持REST API的HMAC-SHA256签名认证。
给定需要添加Aster账户凭据，当提供以太坊私钥、用户地址和签名者配置时，则系统能够存储并支持EIP-191签名方案。
给定需要添加OKX账户凭据，当提供API Key、Secret、Passphrase时，则系统能够存储并支持其特有的签名算法。
给定交易模块请求特定平台签名服务，当提供平台类型、账户标识和待签名数据时，则系统能够自动选择对应的签名算法和凭据进行处理。
给定应用需要获取账户配置，当指定平台和账户标识时，则系统能够返回该平台特定格式的完整账户信息（地址格式、API端点、权限范围等）。
给定系统需要支持新的交易所，当定义新的凭据类型和签名方案时，则系统能够通过插件化方式扩展支持。

边界与异常

私钥泄露或损坏时的紧急冻结和恢复机制
不同交易所签名算法差异的统一处理
高并发签名请求的性能保证和限流控制
账户凭据轮换时的平滑切换策略
网络隔离环境下的安全凭据分发

功能需求（必填）

功能性需求

FR-001：系统必须支持多平台差异化凭据存储，包括Pacifica的Ed25519私钥+子账户、Binance的API Key/Secret、Aster的以太坊私钥+签名者、OKX的三元组等。
FR-002：系统必须提供可扩展的签名服务框架，支持各平台特有签名算法（Solana Ed25519、以太坊EIP-191、CEX HMAC变种等）。
FR-003：系统必须支持平台特定的账户信息注入，能够根据不同平台的地址格式、API端点、权限模型提供差异化配置。
FR-004：系统必须支持从外部配置文件安全读取凭据信息，提供统一的凭据加载和管理接口。
FR-005：系统必须支持账户的分组管理，允许按策略、环境或用途对账户进行逻辑分组。
FR-006：系统必须提供平台级别的权限控制，确保不同模块只能访问其授权的交易所平台的所有账户进行签名操作。
FR-007：系统必须记录所有签名操作的审计日志，包括签名请求、账户使用、权限验证等。
FR-008：系统必须支持账户凭据的生命周期管理，包括添加、更新、禁用、删除和状态监控，并支持配置文件变化的热重载。
FR-009：系统必须提供账户健康检查功能，能够验证私钥有效性和账户在各平台的状态。
FR-010：系统必须支持多环境的凭据隔离，防止开发、测试、生产环境的账户混用。

非功能性需求

NFR-001：私钥存储必须采用AES-256加密或硬件安全模块保护。
NFR-002：签名服务响应时间必须在50毫秒以内。
NFR-003：系统必须支持每秒100次以内的签名请求并发处理能力。
NFR-004：系统必须具备99.95%的可用性，支持热备份和故障转移。
NFR-005：审计日志必须保留至少24个月，支持合规审查。

关键实体

平台凭据模板（PlatformCredentialSchema）：定义每个交易所平台的凭据字段结构、验证规则和签名算法，支持插件化扩展。
账户凭据（AccountCredential）：存储具体账户的敏感信息，根据平台模板存储差异化字段（私钥、API密钥、Passphrase等）。
签名适配器（SignatureAdapter）：为每个平台实现特定的签名逻辑，处理不同的数据格式和算法要求。
账户配置（AccountConfig）：平台特定的账户配置信息，包括地址格式、API端点、权限范围等非敏感信息。
凭据注入器（CredentialInjector）：智能选择和注入账户信息的服务，根据请求上下文提供差异化配置。
权限策略（PermissionPolicy）：定义模块对特定平台账户的访问权限，支持细粒度控制。

审核与验收清单

无实现层面的语言/框架/接口细节
关注用户价值与业务诉求
面向非技术干系人
必填章节完整

需求完备性

不存在 [NEEDS CLARIFICATION] 标记
需求具备可测试性与可度量性
验收标准清晰可界定
范围界定明确
依赖与假设已识别

执行状态

用户描述已解析
关键概念已提取
无模糊标记存在
用户场景已定义
功能需求已写就
关键实体已确定
审核清单全部通过

spec.md 7.2 KB History Raw