业务集成流程
SMN 的部署模型中白色背景部分为开发者需要开发的部分，开发者需要在 Developer Mobile / Browser App 中和 Developer Backend Service 中实现自己的业务逻辑和业务功能。
SMN Relayer 支持横向集群模式的高可用和扩容架构，依赖 Redis 或者 Redis Cluster，用于中转 MPC Node 之间的消息。MPC Node 之间的消息实现了端到端的加密通信。
Embedded MPC Node 支持 iOS、Android 和 Browser 平台，SMN Service 支持服务端以 Docker 镜像方式部署。
使用流程
以两个 MPC 参与方为例，其中一方为开发者服务端持有和管理私钥分片，另一方为开发者开发的移动端或浏览器端应用，由用户在自己的设备中持有和管理私钥分片。SMN 套件的整体使用流程为：
- 开发者服务端部署 SMN Relayer
- 开发者服务端部署并授权 SMN CA
- 开发者服务端部署 SMN Service
- 开发者编写后端钱包业务逻辑服务，集成 SMN Service API
- 移动端集成 Embedded MPC Node SDK
分布式私钥生成 Keygen（对应创建钱包业务场景）流程如下：
- 移动端应用提交钱包创建动作，开发者后端服务和移动端应用协商 SessionId，推荐使用 UUIDv4
- 开发者后端服务和移动端应用分别向 SMN Service 和 Embedded MPC Node（libsmnSDK） 发送 Keygen 指令以及 SessionId
- SMN Service 和 Embedded MPC Node 组织 MPC 协议的执行，并且存储私钥分片
- SMN Service 和 Embedded MPC Node 分别向开发者后端服务和移动端应用返回相同的 KeyId 和扩展公钥 xPub
由于 MPC 计算是分布式计算，可能会出现服务端先完成计算或者客户端先完成计算的情况，因此建议开发者在进行下一步业务逻辑之前，通过开发者后端服务判断，是否所有参与计算的 Node 都完成计算并且取得相同的 KeyId 和 xPub，判断相同后再进行后续步骤。
举个可能出现的场景，手机端和服务端构建 MPC 钱包，服务端收到 KeyId 和 xPub 后判定私钥分片创建成功，进入后续创建钱包逻辑，此时客户端由于网络问题最后一轮计算失败，本地未得到私钥分片。如果此时钱包功能正常，用户使用钱包进行转入操作，转出时由于本地私钥分片不存在造成无法签名转账，从而造成用户资产损失。
其他 MPC 协议类似，需要根据实际的业务场景决定是否需要开发者服务端判断是否所有参与方都完成计算。
分布式签名 Sign 流程（对应交易签名场景）如下：
- 移动端应用提交交易签名动作，开发者后端服务和移动端应用协商 SessionId
- 开发者后端服务和移动端应用分别向 SMN Service 和 Embedded MPC Node 发送分布式私钥签名指令以及 SessionId
- SMN Service 和 Embedded MPC Node 组织 MPC 协议的执行，计算签名结果
- SMN Service 和 Embedded MPC Node 分别向开发者后端服务和移动端应用返回相同的签名结果
总结
其余 MPC 协议集成流程类似，可以总结为：
- 所有参与方协商 SessionId 和计算指令，为了保证安全，以服务端生成 UUIDv4 作为 SessionId
- 所有参与方向各自的 MPC Node 发送指令
- 所有参与方各自收到 MPC 协议结果