Skip to content

roadmap.md

Latest commit

 

History

History
277 lines (217 loc) · 8.66 KB

roadmap.md

File metadata and controls

277 lines (217 loc) · 8.66 KB
Raw

KMS 发展路线图

创建时间: 2025-09-27 17:58

🔓 待决策(2026-08-18):OpenAPI / HTTP API 契约支持范围

背景:SDK 反馈 KMS openapi spec 版本没跟 release 升(0.28.1 vs KMS_VERSION 0.29.0),检测不到变更(PR #212 已修版本+加机械门)。但这暴露一个更上层的产品决策:openapi 到底该投入多少?待 jason 拍板 A/B/C。

OpenAPI 是什么 / 现状

  • 一份机器可读的文件,描述 KMS 公网 HTTP API(/CreateKey、/Sign、WebAuthn…,即"AWS KMS 兼容 API")。工具用它:①渲染可交互文档 ②codegen 客户端 ③契约测试 ④版本 diff。
  • 本仓现状(已核代码):kms/docs/api/openapi.yaml 手写、不生成代码;KMS 运行时 serve kms.aastar.io/docs(Swagger UI 可试跑)+ /openapi.yaml。CLI 不碰它;SDK 手写、只 diff 它的 version。
  • 不覆盖:CLI(直连 TEE/DB,不走 HTTP)、loopback 内部端点(/pop、/kms/sign)。

谁受益

消费者 用不用 价值
本地 CLI ❌ 无关
AAStar SDK(手写) 弱(只 diff version) 低(可用 CHANGELOG/KMS_VERSION 替代)
人(浏览/试 API) ✅ Swagger UI 真价值
第三方/多语言/AWS-KMS-兼容客户端 ✅ 契约+codegen 取决于有没有这类人

决策 = 一句话:HTTP API 是不是"公开产品契约"?

  • 是(AWS-KMS-兼容定位、要第三方直连/多语言/审计)→ openapi 值得维护。
  • 不是(只有第一方 CLI+SDK)→ 只剩 /docs 人浏览价值,严格契约是过度投入。

三选项

  • A 认真支持 —— 但用生成式(utoipa 从 Rust handler 生成 openapi),让 spec 不可能与代码漂移(手写已漏过 /attestation、version)。适合 HTTP API 是公开产品。
  • B 最小支持 —— 保留 /docs 当尽力而为文档,不当严格契约;省版本门/逐端点同步仪式。适合"第三方以后可能"。
  • C 砍掉 —— 换 CHANGELOG + SDK 跟 KMS_VERSION;删 openapi + Swagger UI。适合确定不做公开 HTTP 契约。

与 PR #212 的关系

#212(版本对齐+机械门)在 A/B 下有用、合;在 C 下不必要、关掉。#212 合不合等本决策。

建议(中立)

倾向 A 但生成式(已有在线 Swagger UI + AWS-KMS 兼容定位 + 社区节点外部集成);若短期无真实第三方直连则 B 省心;不建议 C(已有在线 docs,砍是倒退)。

✅ 决定(2026-08-18,jason):A 认真支持(生成式)

KMS 的 HTTP API 作为公开产品契约维护(呼应 AWS-KMS-兼容定位 + 社区节点外部集成)。落地:

  1. utoipa 生成式迁移(排 task/issue,post-stability):从 Rust handler 加注解生成 openapi.yaml,让 spec 不可能与代码漂移(根治手写漏端点/漏版本那一类)。这是 A 的核心——手写 openapi 不划算,生成式才划算。
  2. PR #212 作为过渡合掉:在 utoipa 迁移前,先用"版本对齐 + 机械门(assert openapi version == KMS_VERSION)"保住版本这一维不漂移,给 SDK 一个能 diff 的信号。
  3. utoipa 迁移完成后,机械门可扩展成"生成的 spec 与入库 spec 一致"(或直接构建时生成),/docs Swagger UI 继续在线。

🎯 项目当前状态 (Phase 7 完成)

✅ 已完成的里程碑

  • Phase 1: 基础架构设计与eth_wallet集成
  • Phase 2: Mock-TEE环境验证与核心功能实现
  • Phase 3: AWS KMS兼容API服务开发
  • Phase 4: Docker OP-TEE环境验证
  • Phase 5: 公网部署与Cloudflare Tunnel
  • Phase 6: 代码库清理与项目优化
  • Phase 7: 企业级部署工具与测试系统

📊 当前系统指标

  • 在线版本: Mock-TEE v0.1.0
  • 运行状态: ✅ 健康，24/7在线
  • API响应: 平均 ~150ms
  • 功能覆盖: 100% AWS KMS兼容
  • 已创建密钥: 9个 (持续增长)
  • 测试覆盖: 完整curl测试套件

🚀 Phase 8: 安全性增强与真实TEE部署

8.1 真实OP-TEE环境迁移

目标: 从Mock-TEE升级到真实QEMU OP-TEE环境

任务清单:

  • 修复OP-TEE构建环境问题
  • 将eth_wallet代码适配到真实TEE
  • 验证TEE安全隔离功能
  • 性能基准测试对比
  • 一键Mock→TEE迁移脚本

预期收益:

  • 🔐 真实TEE安全保护
  • 🛡️ 硬件级密钥隔离
  • 📈 企业级安全认证
  • 🔧 生产部署就绪

8.2 安全审计与漏洞评估

目标: 全面安全评估和加固

任务清单:

  • 密码学实现安全审计
  • API安全性渗透测试
  • 侧信道攻击防护验证
  • 访问控制机制设计
  • 安全日志和监控

预期收益:

  • 📋 安全评估报告
  • 🔒 企业级安全标准
  • 🚨 实时威胁监控
  • 📊 合规性认证准备

8.3 高可用性架构设计

目标: 生产级高可用部署

任务清单:

  • 多节点集群架构
  • 负载均衡和故障转移
  • 数据持久化和备份
  • 灾难恢复机制
  • 监控告警系统

预期收益:

  • ⚡ 99.9%+ 可用性
  • 🔄 零停机部署
  • 💾 数据安全保障
  • 📊 实时运维监控

🎨 Phase 9: 功能扩展与生态集成

9.1 密钥管理高级功能

目标: 企业级密钥管理特性

任务清单:

  • 密钥轮换和版本管理
  • 多签名密钥支持
  • 密钥导入/导出功能
  • 密钥策略和权限控制
  • 审计日志和合规报告

预期收益:

  • 🔄 自动化密钥生命周期
  • 👥 多方授权控制
  • 📝 完整审计追踪
  • ⚖️ 合规性保障

9.2 多链支持扩展

目标: 支持多种区块链和密码学算法

任务清单:

  • Ed25519算法支持 (Solana, Cosmos)
  • BLS签名支持 (Ethereum 2.0)
  • RSA密钥支持 (传统系统)
  • 国密算法支持 (中国标准)
  • 跨链签名协议

预期收益:

  • 🌐 多区块链生态支持
  • 🔧 灵活算法选择
  • 🌍 国际化合规
  • 🔗 跨链互操作性

9.3 开发者生态建设

目标: 丰富的SDK和工具生态

任务清单:

  • JavaScript/TypeScript SDK优化
  • Python SDK开发
  • Go SDK开发
  • CLI工具增强
  • 开发者文档和教程

预期收益:

  • 👨‍💻 开发者友好
  • 📚 完整文档体系
  • 🛠️ 丰富工具链
  • 🤝 社区生态发展

🏭 Phase 10: 生产部署与商业化

10.1 硬件部署优化

目标: 真实硬件环境部署

任务清单:

  • Raspberry Pi 5 OP-TEE适配
  • ARM TrustZone优化
  • 硬件安全模块集成
  • 性能调优和基准测试
  • 部署自动化脚本

预期收益:

  • 🔧 生产级硬件部署
  • ⚡ 最优性能表现
  • 🛡️ 硬件级安全保护
  • 🚀 一键部署能力

10.2 企业级功能

目标: 企业客户需求支持

任务清单:

  • 多租户架构
  • RBAC权限系统
  • SSO集成支持
  • 企业级监控面板
  • SLA保障体系

预期收益:

  • 🏢 企业级服务能力
  • 👥 多客户隔离
  • 📊 运营管理平台
  • 📋 服务质量保证

10.3 标准化与认证

目标: 行业标准认证

任务清单:

  • FIPS 140-2认证准备
  • Common Criteria评估
  • SOC 2合规认证
  • ISO 27001体系建设
  • 第三方安全审计

预期收益:

  • 🏆 权威安全认证
  • 📜 合规资质证明
  • 🌟 行业标准地位
  • 💼 企业客户信任

📈 关键性能指标 (KPIs)

技术指标

  • 响应时间: < 100ms (目标优化)
  • 并发处理: > 1000 req/s
  • 可用性: 99.99%
  • 密钥生成: < 50ms
  • 签名操作: < 30ms

安全指标

  • 零安全漏洞: 持续安全审计
  • 密钥泄露: 零容忍
  • 访问控制: 100%合规
  • 审计完整性: 完整日志记录

业务指标

  • 开发者采用: 目标1000+ 开发者
  • 企业客户: 目标50+ 企业
  • API调用: 目标100万+ 次/月
  • 社区活跃: 持续贡献和反馈

🎯 里程碑计划

近期目标 (1-2个月)

  • ✅ Phase 8.1: 真实TEE环境部署
  • ✅ Phase 8.2: 安全审计完成
  • ✅ Phase 9.1: 高级密钥管理功能

中期目标 (3-6个月)

  • ✅ Phase 9.2: 多链支持实现
  • ✅ Phase 9.3: 开发者生态建设
  • ✅ Phase 10.1: 硬件部署优化

长期目标 (6-12个月)

  • ✅ Phase 10.2: 企业级功能完善
  • ✅ Phase 10.3: 标准化认证获得
  • ✅ 商业化运营启动

🤝 贡献机会

开发贡献

  • 🔧 核心功能开发
  • 🧪 测试用例编写
  • 📚 文档完善
  • 🐛 问题修复

生态贡献

  • 📦 SDK开发
  • 🎯 示例应用
  • 📖 教程制作
  • 🌐 社区建设

研究贡献

  • 🔬 安全研究
  • 📊 性能优化
  • 🆕 新特性设计
  • 🔍 标准制定

这个路线图将指导KMS从当前的原型系统发展成为企业级的生产服务，最终成为区块链和Web3生态中的关键基础设施。