数字资产钱包长期把完整私钥或助记词放在单一设备上，设备丢失、备份泄露或遭遇钓鱼时，资产往往无法挽回。用户还要同时使用以太坊等 secp256k1 账户和 Solana 等 Ed25519 账户，两套密钥割裂、备份成本高。传统 GG20 门限方案依赖 Paillier 大整数和离线、在线两阶段签名，服务端集成重，也很难做成可上架的手机钱包。本项目面向个人与产品团队的协同托管场景：手机持有一份密钥分片，服务端持有另一份，任何单方都无法独立签名；创建一次即同时就绪双曲线账户，用门限多方计算替代助记词单点，降低私钥泄露和换机丢失带来的资产风险。
项目分为协议栈、业务控制面和移动钱包三层。协议层实现门限 ECDSA 的分布式密钥生成、门限签名和密钥刷新，以及Ed25519 的密钥生成与签名；消息中继按消息标识转发各轮协议数据，服务端固定作为参与方一并持久化密钥分片。控制面提供邮箱验证码登录、会话与设备绑定、短时签名票据、钱包元数据和网络目录，并记录 Google 备份的文件标识与校验信息，不保存明文分片。移动端包含引导与生物识别解锁、一键创建受保护钱包、资产与收款、按链族分开的转账页（以太坊原生币和 ERC-20、Solana 原生币和 SPL）、发送前链上模拟、审阅确认后多方签名并广播、活动记录、网络管理、深色与浅色主题，以及口令加密的手动恢复和 Google 云端密文备份。协议调试入口与正式账户隔离，正式路径不暴露参与方编号和中继地址。
我负责从门限协议服务到移动端钱包的整体设计与实现。技术栈为 Rust（消息中继、协议编排、参与方服务、客户端 SDK 与 Flutter FFI）、MPC、gRPC 加 SSE、Flutter 与 Riverpod，以及 Go（Gin、Gorm）、PostgreSQL 和 Redis。协议轮次不经过业务 API：手机通过 FFI 作为一方，与持有另一分片的服务端经中继完成计算，Go 只负责身份校验并签发短时票据，服务端验票后才参与签名。实现上的难点是三套编号不能混用（接口从 1 起计，参与方从 0 起计，标识与接口对齐），同一账户要并发完成双曲线密钥生成，中继按消息标识点对点拉取而不是房间广播，以及分片只能在客户端加密后再备份、模拟通过后才允许进入签名。
评论