# 技术调研：多平台账户凭据管理与签名服务

## 调研概述

本文档分析多平台账户凭据管理系统的技术选型、签名算法最佳实践、配置管理方案和安全实现策略。

## 关键技术决策

### 1. 签名算法选型

#### Pacifica (Solana 基础)
**决策**: 使用 Ed25519 签名算法
**理由**:
- Pacifica 基于 Solana 区块链，原生支持 Ed25519
- `tweetnacl` 库提供高性能 Ed25519 实现
- `bs58` 库处理 base58 私钥编码
- 与现有 Pacifica 集成完全兼容

**备选方案**:
- 直接使用 @solana/web3.js (过重，仅需签名功能)
- libsodium (C binding，增加部署复杂度)

#### Aster (以太坊基础)
**决策**: 使用 EIP-191 签名方案
**理由**:
- Aster 基于以太坊，支持标准 EIP-191 个人签名
- `ethers` 库提供完整的以太坊签名实现
- 支持 keccak256 哈希和 secp256k1 椭圆曲线
- 与现有 Aster 集成保持一致

**备选方案**:
- EIP-712 结构化签名 (复杂度过高，Aster 不需要)
- 原始 secp256k1 签名 (缺乏标准化，兼容性差)

#### Binance (CEX)
**决策**: 使用 HMAC-SHA256 签名
**理由**:
- Binance 官方 API 要求 HMAC-SHA256
- Node.js 内置 crypto 模块支持
- 高性能，无需外部依赖
- 标准化实现，维护成本低

**备选方案**:
- RSA 签名 (Binance 不支持)
- HMAC-SHA1 (安全性不足，已弃用)

#### OKX
**决策**: 使用 HMAC-SHA256 + Base64 编码
**理由**:
- OKX 特有的三元组认证 (API Key + Secret + Passphrase)
- 需要特定的请求头格式和时间戳处理
- 使用标准 HMAC-SHA256 确保兼容性

### 2. 配置文件格式选型

#### JSON vs YAML vs TOML
**决策**: 使用 JSON 格式
**理由**:
- Node.js 原生解析支持，无需额外依赖
- 严格的数据类型定义，减少配置错误
- 广泛的工具支持和调试能力
- 与现有项目配置风格一致

**备选方案评估**:
```typescript
// YAML: 人类友好但解析开销大
yaml: require('yaml') // +50KB dependency

// TOML: 新兴格式，生态不成熟
toml: require('@iarna/toml') // +30KB dependency

// JSON: 原生支持，零依赖
json: JSON.parse() // Native
```

### 3. 热重载实现方案

#### 文件系统监控技术
**决策**: 使用 Node.js fs.watch API
**理由**:
- 原生支持，无需第三方依赖
- 跨平台兼容 (Linux inotify, macOS fsevents, Windows NTFS)
- 低延迟 (<100ms) 检测文件变化
- 内存占用小，适合生产环境

**实现策略**:
```typescript
// 智能防抖动：避免频繁重载
const debounceTime = 1000; // 1秒防抖
let reloadTimer: NodeJS.Timeout;

fs.watch(configPath, (eventType, filename) => {
  clearTimeout(reloadTimer);
  reloadTimer = setTimeout(() => {
    this.reloadCredentials();
  }, debounceTime);
});
```

**备选方案**:
- `chokidar` 库 (功能强大但增加依赖)
- 定时轮询 (延迟高，资源消耗大)

### 4. 凭据加密存储方案

#### 加密算法选择
**决策**: 使用 AES-256-GCM
**理由**:
- AEAD (认证加密) 提供完整性保护
- GCM 模式支持并行计算，性能优异
- NIST 推荐标准，安全性经过验证
- Node.js crypto 模块原生支持

**实现细节**:
```typescript
// 密钥派生：PBKDF2 + 随机盐
const salt = crypto.randomBytes(32);
const key = crypto.pbkdf2Sync(password, salt, 100000, 32, 'sha256');

// 加密：AES-256-GCM + 随机IV
const iv = crypto.randomBytes(16);
const cipher = crypto.createCipher('aes-256-gcm', key);
```

**备选方案**:
- AES-256-CBC (需要额外的HMAC完整性验证)
- ChaCha20-Poly1305 (性能好但兼容性差)

### 5. 权限控制架构

#### RBAC vs ABAC
**决策**: 实现简化的平台级 RBAC
**理由**:
- 需求明确：模块对平台的访问控制
- RBAC 实现简单，维护成本低
- 满足当前<100 QPS的性能要求
- 便于审计和调试

**权限模型设计**:
```typescript
interface PermissionPolicy {
  moduleId: string;           // 模块标识
  allowedPlatforms: string[]; // 允许访问的平台
  permissions: {
    sign: boolean;            // 签名权限
    query: boolean;           // 查询权限
  };
}
```

**备选方案**:
- ABAC (基于属性) - 过于复杂，当前需求不需要
- ACL (访问控制列表) - 扩展性差，不适合多平台

### 6. 错误处理和重试策略

#### 签名失败处理
**决策**: 指数退避 + 熔断器模式
**理由**:
- 指数退避避免雪崩效应
- 熔断器保护底层服务
- 最大重试次数控制资源消耗

**实现方案**:
```typescript
class SignatureService {
  private async retryWithBackoff<T>(
    operation: () => Promise<T>,
    maxRetries = 3
  ): Promise<T> {
    for (let attempt = 0; attempt <= maxRetries; attempt++) {
      try {
        return await operation();
      } catch (error) {
        if (attempt === maxRetries) throw error;

        const backoffMs = Math.min(1000 * Math.pow(2, attempt), 10000);
        await new Promise(resolve => setTimeout(resolve, backoffMs));
      }
    }
  }
}
```

## 性能优化策略

### 1. 签名缓存机制
- 相同参数的签名结果缓存 5 分钟
- LRU 策略，最大缓存 1000 条记录
- 缓存命中率目标 >80%

### 2. 并发控制
- 使用 Promise 池控制并发签名请求
- 最大并发数：50 (基于 100 QPS 需求)
- 队列长度限制：200

### 3. 内存管理
- 敏感数据及时清理 (setTimeout 0)
- 使用 WeakMap 自动回收凭据引用
- 定期触发 V8 垃圾回收

## 安全加固措施

### 1. 输入验证
- 所有签名请求参数严格类型检查
- 平台类型白名单验证
- 请求大小限制 (最大 1MB)

### 2. 日志脱敏
- 私钥信息完全屏蔽
- API Key 仅记录前4位和后4位
- 签名结果记录哈希摘要而非原文

### 3. 内存保护
- 使用 Buffer.allocUnsafe() 避免内存泄露
- 敏感 Buffer 使用后立即 fill(0)
- 避免字符串拼接造成的内存残留

## 测试策略

### 1. 单元测试
- 每个签名适配器独立测试套件
- Mock 外部依赖，隔离测试环境
- 覆盖率要求 >90%

### 2. 集成测试
- 使用测试网络验证签名正确性
- 配置热重载端到端测试
- 权限控制场景覆盖

### 3. 性能测试
- 签名吞吐量基准测试 (目标 100 QPS)
- 内存泄露检测 (长时间运行)
- 并发压力测试

## 部署和运维

### 1. 监控指标
- 签名请求 QPS 和延迟分位数
- 错误率和重试率统计
- 内存使用和GC频率

### 2. 告警策略
- 签名失败率 >5% 立即告警
- 响应时间 p99 >200ms 告警
- 配置重载失败告警

### 3. 灾备方案
- 配置文件多副本备份
- 服务无状态设计，支持水平扩展
- 降级策略：临时禁用非关键平台

## 技术债务和风险

### 1. 已知限制
- 单进程设计，无法利用多核优势
- 内存存储凭据，重启会丢失缓存
- 配置文件格式变更需要重启

### 2. 风险缓解
- 定期安全审计和依赖更新
- 监控和告警覆盖关键路径
- 详细的操作手册和应急预案

### 3. 后续优化
- 考虑 Worker Threads 提升并发性能
- Redis 集成支持分布式缓存
- 配置中心集成实现动态配置

---

**调研完成时间**: 2025-09-28
**技术栈确认**: TypeScript + Node.js + 原生加密库
**下一步**: 进入 Phase 1 设计阶段