密钥生命周期与签名流程

从 Cosigner 的视角了解密钥生成、签名和重新分片。

密钥生成

在配置了 Cosigner 的工作区中创建钱包时，会在 MPCium 节点和你的 Cosigner 之间执行分布式密钥生成。

1. Orchestrator 发送已签名的 session_start，其中包含 KEYGEN、key_id、协议和门限。
2. Cosigner 验证签名并询问你的回调。
3. 各参与方运行 tss-lib 密钥生成。结束时每方都持有自己的分片和共享公钥。
4. Cosigner 加密其分片，以 shares:<protocol>:<key_id> 存储，并记录委员会信息。
5. 只有公钥和结果哈希会离开 Cosigner。
6. Orchestrator 检查所有公钥是否一致，然后将其返回给 Apex。

同时需要 ECDSA 和 EdDSA 的钱包会运行两个相互关联的会话。任意一个失败，两个都会中止。

签名

1. 准入

通过工作区策略的请求会从 Apex 发送到 Orchestrator，并使用 Apex 发起方密钥签名。Orchestrator 根据密钥生成记录核对委员会，确认所有成员在线，然后发送已签名的 session_start。

session_start 包含 key_id、原始 signing_input、可选的 signing_context（交易详情，最大 64 KiB）、HD derivation、门限和参与方。

2. 本地检查

除非以下检查按顺序全部通过，否则 Cosigner 会拒绝该会话：

1. 消息小于 128 KiB。
2. Orchestrator 签名有效（密钥在配对时锁定）。
3. 每分钟少于 20 次启动和 10 次中止。
4. 并发会话少于 5 个。
5. session_start 已写入审计日志。
6. 你的回调返回 approve。否则会话以 CALLBACK_REJECTED 失败。

如果 Orchestrator 在回调等待期间中止，Cosigner 会停止等待。

3. 密钥交换

• 会话必须与锁定的委员会一致：门限、参与方密钥、身份密钥、审批者标志。
• Cosigner 向每个对等方发送 peer_joined、peer_ready 和已签名的 X25519 密钥。
• 每对对等方会获得按方向区分的 ChaCha20-Poly1305 密钥（基于 X25519 的 HKDF，并与会话绑定）。

4. 门限签名

Orchestrator 发送 mpc_begin。如果钱包设有审批者（例如 Fystack 移动端审批者），mpc_begin 必须包含该审批者对这一确切签名输入的签名批准。缺少该批准时，Cosigner 会以 APPROVAL_REQUIRED 使会话失败。

随后各参与方运行 tss-lib 轮次。每条消息都经过签名并带有序列号，因此重放消息会被丢弃。

5. 结果

每个参与方报告其签名的哈希。Orchestrator 要求所有哈希一致，然后将签名结果（signature、r、s、恢复 id）返回给 Apex。Cosigner 记录 session_end 并删除其检查点。

重新分片

替换分片，并可选择更换委员会或门限。公钥和地址不会改变。

1. 旧委员会和门限来自密钥生成记录，而不是来自调用方。
2. 至少需要 threshold + 1 个旧成员在线。
3. 新旧成员运行 tss-lib 重新分片。新分片先暂存，旧分片保持有效。
4. 所有参与方报告相同的结果，且公钥保持不变。
5. Orchestrator 持久化该决定，然后发送已签名的 reshare_commit。每个参与方换上新分片。

提交前中止会保留旧分片。提交后只会向前推进：提交会不断重试，直到每个参与方都确认为止，即使发生崩溃也是如此。

失败代码