做MPC钱包的人第一句想对同行说的往往是钱包不是钱包是把私钥拆了。真正动手实现之后你还会发现另一件事——把协议讲清楚的人很多把工程竖起来的人很少。这篇实战文章就是用 Rust 做密码学核心、用 Java 做业务协调层从零搭一个真正能完成“分片生成 → 两方签名 → 验签”闭环的最小可用 MPC 钱包。适合有 Java 基础、对密码学好奇、又还没下定决心直接啃生产级协议库的读者也适合被 KPI 逼着做技术预研、需要尽快跑通 Demo 的团队。我会把思路拆开讲清楚包括为什么这样分片、为什么用 Schnorr 而不是 ECDSA、Rust 和 Java 的边界到底画在哪以及我踩过的几个真坑。代码会给出关键函数照着敲就能跑不需要一上来就背上 GG20、FROST 那些沉重的协议包袱。1. 最小可用 MPC 钱包的需求拆解与架构选择1.1 功能边界到底什么才算“最小可用”MPC 钱包这个词被用得有点泛滥一说出来就容易让人联想到机构级托管、HSM 集群、合规审计那一大堆东西。但作为实战项目的第一步应该先把边界收窄。我理解的“最小可用”至少包含三块能力第一能把一份私钥拆成多份且任何单份都无法直接签名第二多份分片可以通过交互协同完成一次签名私钥从始至终不以完整形态出现在内存里第三能验证签名结果也就是对外证明这个钱包真的可用。至于多链支持、助记词导入、交易广播、手续费估算这些都不是本篇的重点。你可以把它们理解为一个钱包的“业务壳”而我们要做的是那个最核心的“加密内核”。这个内核一旦稳定下来上面的壳想怎么套都行。还有一个容易忽略的点最小可用不等于简单到可以牺牲安全。至少在功能演示层面签名成功了还必须验签成功而且要把“私钥不落地”这个属性真正做出来而不是在内存里拼出完整私钥再签名那就失去了 MPC 的意义。1.2 为什么用 Rust Java 这对组合选择 Rust 做底层理由其实被说烂了但确实是真的内存安全、无 GC、性能接近 C密码学社区里有大量高质量实现很多生产级 MPC 库本身就是 Rust 写的。更关键的是Rust 对错误处理比较较真写密码学逻辑时不容易出现“逻辑看起来对实际边界没处理”的侥幸代码。Java 这边则是企业里最常见的语言之一业务系统、后端服务、钱包中间件基本都是 Java。让前端业务团队直接用 Java 读写分片、组装交易、对接链上 API比要求他们精通 Rust 现实得多。所以我的分工原则很明确所有涉及密钥材料、标量运算、签名算法的代码一律放在 Rust 里Java 只做编排、存储、HTTP 调用和业务组装。这个边界必须画得干净。我见过一些项目为了省事把分片后的私钥明文传给 Java 层处理这就等于把 MPC 的安全属性又还回去了。Rust 和 Java 之间只传输公钥、nonce 点、部分签名这类公开信息私钥分片永远待在 Rust 进程里。1.3 进程模型两台签名机加一个协调者实战场上和单进程 Demo 最大的区别是MPC 天然就是分布式的。哪怕你只是想在自己电脑上跑通流程也应该把架构按“两方”来搭否则后面迁移到真实的双机部署时会很痛苦。我这里采用的模型是两个独立的 Rust 签名机进程分别持有分片一和分片二一个 Java 协调者进程负责发号施令。Java 向签名机 A 要一个 nonce 点向签名机 B 也要一个 nonce 点然后统计算出挑战值 e再让两个签名机分别做部分签名最后 Java 把两份部分签名组合成完整签名。整个过程两个 Rust 进程不直接通信消息都经过 Java 中转。这个模型有一个教学上的优势你可以清楚看到每一方到底持有什么、计算了什么、暴露了什么。后面如果要把 Java 中转升级成签名机之间的加密通道也只是消息流的变化核心密码学逻辑完全不用动。2. 核心原理加法分片与 Schnorr 签名为什么适合做 MPC2.1 从 Shamir 秘密共享到加法分片很多人一听到秘密共享就想起 Shamir 多项式这是对的但 2-2 阈值这个特例其实退化成了一件非常简单的事把私钥 x 随机拆成两份x1 和 x2满足 x x1 x2 mod n其中 n 是 secp256k1 曲线的阶。分片一存 x1分片二存 x2两个合在一起能恢复出 x但任意单独一片只包含随机数不泄露任何关于 x 的信息。Shamir 的一般形式是在有限域上随机取一个 t-1 次多项式然后取多项式上的点作为分片。当 t 2 时多项式是 f(y) a0 a1 * y取 y 1 和 y 2 两个点其中 a0 就是秘密。你把它展开就会发现分片本质上就是 x1 a0 a1、x2 a0 2 * a1 这样的线性组合。所以“加法分片”不是离经叛道而是最朴素的 2-2 特例。工程上我反而推荐先实现特例。一来代码只有三五行二来不容易犯多项式求值、Lagrange 插值这些实现错误。当你真正需要 2-3、3-5 阈值时再在同一个工程里引入完整的 Shamir 模块算法骨架是现成的。这里有一个安全细节必须提醒分片生成完原始私钥要立刻从内存中清除。我习惯用 zeroize 这类工具把临时变量清零而不是依赖 drop。你永远不知道编译器优化后是否会保留中间值。2.2 Schnorr 签名的线性特性MPC 签名之所以比普通签名难核心在于签名算法本身是否“线性”。ECDSA 是个典型的不合作者签名公式里既有 k 的逆元又有 r * x 这种交叉项两个分片想要在不暴露各自私钥的情况下联合算出一个合法签名需要 Paillier 同态加密、零知识证明这些重武器协议复杂度和实现难度都直线上升。Schnorr 签名则完全是另一回事。它的签名过程是选随机 nonce k计算 R k * G然后算挑战 e Hash(R || X || m)最后得到 s k e * x。你会注意到这里没有逆元、没有交叉项全是标量加法和乘法。这意味着如果 x x1 x2k k1 k2那么s s1 s2 (k1 e * x1) (k2 e * x2) k e * x完美线性。两个签名方各自用自己的分片算出一份部分签名任意顺序相加就能得到完整签名。这个过程不需要同态加密不需要繁琐的零知识证明通信轮次也很少。这也是为什么 FROST 这类门限签名协议会优先考虑 Schnorr 系算法。我做得最小可用版本直接采用 secp256k1 上的 Schnorr 签名好处是曲线是比特币同款后面想切换成 BIP340 标准也顺理成章。如果你是要做以太坊这类 ECDSA 系钱包那架构可以保留把 Rust 内核里的签名算法替换成两方 ECDSA 实现即可无非是协议复杂一点。2.3 两方签名的完整通信流程把上面的数学原理落成消息序列一共就四步。第一步Java 协调者向签名机 A 请求 nonceA 本地生成随机 k1返回 R1 k1 * G同时向签名机 B 做同样操作得到 R2 k2 * G。第二步Java 把 R1 和 R2 相加得到联合 nonce 点 R再结合聚合公钥 X 和消息 m 算出挑战值 e。第三步Java 把 e 分发给 A 和 B双方各自计算部分签名 s1 k1 e * x1、s2 k2 e * x2。第四步Java 把 s1 和 s2 相加得到完整签名 (R, s)可以直接用公钥 X 验签。这个流程里有一个很关键的点前面提到的 k1 和 x1、k2 和 x2 必须分别来自两台互不信任的机器否则就退化成单点。真实环境里A 和 B 之间还需要互相认证通信通道防止中间人篡改 nonce 点或挑战值。演示阶段用 Java 中转没问题但文章末尾我会列出一份教学版与生产版的差距清单。nonce 重用是这个流程里最致命的错误。Schnorr 签名里如果同一个 k 对不同消息签了两次两个方程相减就能把私钥 x 解出来。所以每次签名必须重新生成 k并且签完立刻丢弃。我在 Rust 签名机的状态设计里专门留了这一点生成 k 后暂存在内存收到 partial-sign 请求后取出来用然后立即清除绝不复用。3. Rust 签名机实现把密码学内核锁在进程里3.1 工程结构与依赖选择Rust 这边我拆成两个 binary一个是mpc-dealer负责生成钱包和分片一个是mpc-signer负责以 HTTP 服务形式对外提供签名能力。分两个进程的好处是职责单一Dealer 跑完即走Signer 常驻内存但只持有分片。依赖选型上以精为主。椭圆曲线运算我用 k256它是 RustCrypto 社区维护的 secp256k1 实现支持 Scalar、ProjectivePoint 这些底层原语写教学版 Schnorr 足够。HTTP 服务用 axum虽然依赖多一点但 handler 写起来很干净错误处理也直观。序列化用 serde serde_json命令行参数解析用 clap密钥清零用 zeroize。[dependencies] k256 { version 0.13, features [arithmetic, sha256] } sha2 0.10 serde { version 1, features [derive] } serde_json 1 zeroize { version 1, features [derive] } axum 0.7 tokio { version 1, features [full] } clap { version 4, features [derive] } hex 0.4版本号只代表我写这篇文章时的状态你实际使用时以 crates.io 上的最新版本为准。k256 的 API 在不同版本之间有过调整如果遇到random方法找不到或者from_repr签名变了去对应版本的 docs 页确认一下就行。3.2 密钥分片模块Dealer 的职责是先随机生成一个私钥 x然后拆成两份分片。这里我直接使用加法分片因为 2-2 阈值下这就是 Shamir 的最简形式。use k256::Scalar; use rand_core::OsRng; fn split_secret(secret: Scalar) - (Scalar, Scalar) { let part1 Scalar::generate_biased(mut OsRng); let part2 *secret - part1; (part1, part2) }生成之后Dealer 要做两件事一是把两份分片分别写进shard1.json和shard2.json文件里除了分片值还要带上分片 ID 和聚合公钥二是把聚合公钥写进wallet.json供 Java 层读取。聚合公钥不需要两个分片凑在一起才能算它有公开性let pk ProjectivePoint::GENERATOR * secret;写完文件后内存里的 secret 变量要清零。我建议在自定义结构体上实现 Drop 或直接用零化容器单纯依赖析构并不能保证内存被抹掉。分片文件的权限也要注意。我踩过一次生成了 shard 文件之后忘了 chmod另一个账号的进程都能读这在真实托管场景里是不可接受的。最次也要chmod 600最好是落盘前用操作系统级别的文件加密。3.3 两方签名模块与 HTTP 服务封装签名机内部维护一个状态结构体持有分片值和本次会话的 nonce。收到/nonce请求时生成随机 k 和对应点 R把 k 暂存起来回传 R 的序列化字节收到/partial-sign时从状态里取出 k配合请求带过来的挑战值 e 计算部分签名然后立即把 k 清零。#[derive(Clone)] struct SignerState { shard: Shard, current_nonce: Option(Scalar, ProjectivePoint), } fn do_partial_sign(x_i: Scalar, k_i: Scalar, e: Scalar) - Scalar { k_i e * x_i }这里 Rust 的所有权模型帮了大忙。状态结构体放在ArcMutex...里每次操作都是独占锁不会出现两个并发请求意外共用一个 nonce 的情况。你如果用 Java 写同样的逻辑得靠synchronized或者显式加锁粗心一点就漏了。HTTP 接口我定义了三个GET /pubkey返回分片 ID 和聚合公钥POST /nonce生成并返回 R 点POST /partial-sign接收{ e: 十六进制字符串, msg: 十六进制字符串 }返回{ id: 1, s: 十六进制字符串 }。客户端传 msg 进来主要是为了做日志审计签名机本身并不需要自己重新哈希因为挑战值 e 已经由协调者算好。这样做在功能上没问题但你必须理解它的信任假设签名机是在“诚实但好奇”的前提下工作的它不主动作恶但如果收到的 e 是恶意构造的签名结果也不会被验签接受。生产级实现需要双方先对 e 做承诺或者要求签名机之间直接协商避免中间人调包。axum 的 handler 写起来不长关键是把状态锁住async fn partial_sign( State(state): StateArcMutexSignerState, Json(req): JsonPartialSignReq, ) - ResultJsonPartialSignResp, StatusCode { let mut st state.lock().await; let (k_i, _) st.current_nonce.take().ok_or(StatusCode::BAD_REQUEST)?; let e decode_scalar(req.e).map_err(|_| StatusCode::BAD_REQUEST)?; let s_i do_partial_sign(st.shard.x_i, k_i, e); st.current_nonce None; Ok(Json(PartialSignResp { id: st.shard.id, s: hex::encode(s_i.to_bytes()) })) }注意take()之后立刻把 Option 设为 None就是为了保证一个 nonce 只能用一次。哪怕客户端重复提交同样请求也会因为 nonce 不存在而被拒绝。4. Java 业务层实现编排者不碰密钥4.1 Java 工程结构与依赖Java 这边就是一个普通的 Maven 工程核心包分三层model 放签名记录和分片元数据crypto 放椭圆曲线点运算和验签逻辑service 放签名编排与 HTTP 调用。外部依赖尽量少我最终只用了两个BouncyCastle 做 secp256k1 的点运算Jackson 做 JSON 解析。dependency groupIdorg.bouncycastle/groupId artifactIdbcprov-jdk18on/artifactId version1.77/version /dependency dependency groupIdcom.fasterxml.jackson.core/groupId artifactIdjackson-databind/artifactId version2.16.0/version /dependency为什么 Java 层还需要点运算因为协调者要计算联合 nonce 点 R以及最终验签时比较s * G和R e * X。这些运算用的是公开数据不涉及任何密钥材料放在 Java 层不会破坏安全模型。如果你连这点运算都不想在 Java 里做也可以让 Rust 签名机提供聚合接口但那样 Java 就只剩下调度了对理解整个流程反而没帮助。用 BouncyCastle 拿 secp256k1 曲线参数非常方便X9ECParameters x9 CustomNamedCurves.getByName(secp256k1); ECDomainParameters domain new ECDomainParameters(x9.getCurve(), x9.getG(), x9.getN(), x9.getH()); ECCurve curve x9.getCurve();4.2 钱包业务层地址生成与交易构造钱包的核心对象叫MpcWallet构造时只需要传入一个公钥配置这个配置来自 Dealer 生成的wallet.json。聚合公钥的字节可以直接作为账户标识如果要演示地址我一般取公钥的 x 坐标前缀转成十六进制作为演示用地址。交易构造可以做得非常朴素一条 JSON 记录包含 from、to、amount、nonce 四个字段然后按固定格式做序列化再取 SHA-256 作为待签名消息。真实链上的交易构造远比这个复杂但最小可用钱包不需要关心这些关键是整个流程能跑通。public byte[] buildMessage(String from, String to, BigInteger amount, long nonce) throws Exception { String json String.format({\from\:\%s\,\to\:\%s\,\amount\:\%s\,\nonce\:%d}, from, to, amount.toString(), nonce); MessageDigest digest MessageDigest.getInstance(SHA-256); return digest.digest(json.getBytes(StandardCharsets.UTF_8)); }4.3 与 Rust 签名机的 HTTP 交互与签名组合Java 发起签名时先并行调用两个签名机的/nonce接口拿到 R1 和 R2用 BouncyCastle 做点加得到 R然后计算挑战值 e。计算 e 的哈希规则必须和 Rust 端全局统一我在两边都加了自定义标签字节my-mpc-wallet/schnorr/v1防止以后重写哈希函数导致验签失败。byte[] challenge sha256(tag, rX, xX, msg); BigInteger e new BigInteger(1, challenge).mod(n);拿到 e 之后再次并行调用两个签名机的/partial-sign得到 s1 和 s2然后相加并取模BigInteger s s1.add(s2).mod(n);组合签名需要小心一点s 是标量必须落在 [0, n-1] 区间内。两个分片相加可能会越过 n取模之后才能作为合法值。我在第一次实现时忘了这一步验签偶尔会失败后来才发现是模运算没做。5. 端到端实操从零跑通一个最小 MPC 钱包5.1 编译与启动步骤整个流程我用脚本串起来体验上跟跑一个普通 Demo 差不多。先生成分片再启动两个签名机最后跑 Java 完成签名和验签。第一步编译 Rust 工程并生成钱包分片cargo build --release ./target/release/mpc-dealer \ --shards 2 --threshold 2 \ --out-shard ./data/shard1.json \ --out-shard ./data/shard2.json \ --out-wallet ./data/wallet.json chmod 600 ./data/shard1.json ./data/shard2.json第二步分别在两个终端启动签名机./target/release/mpc-signer --shard ./data/shard1.json --listen 127.0.0.1:9001 ./target/release/mpc-signer --shard ./data/shard2.json --listen 127.0.0.1:9002第三步编译并运行 Java 演示程序mvn -q compile exec:java -Dexec.mainClasscom.example.MpcWalletDemo5.2 签名流程演示输出Java 演示程序的日志我保留下来了它把每一步都打印清楚方便你看懂整个时序[*] Wallet pubkey (x-coordinate): 2f5c17a10c74... [*] Build message: {from:alice,to:bob,amount:100,nonce:1} [*] Fetch nonce from signer1 - R1: 03a1f... [*] Fetch nonce from signer2 - R2: 02c8e... [*] Combined R: 03660d... [*] Challenge e: 7b34fa... [*] Signer1 partial-s: 3d91ab... [*] Signer2 partial-s: 9f22cd... [*] Combined s: 8e07ff... [*] Signature (R, s): (03660d..., 8e07ff...) [*] Verification: passed看到Verification: passed这一行说明从分片生成到两方签名再到验签的完整闭环已经通了。如果把wallet.json里的公钥换成 Base58 或 Bech32 编码再封装一层地址逻辑这就是一个只要两把“碎片”同时在场才能动钱的演示钱包。5.3 安全属性验证私钥确实不落地演示跑完你还可以做一个小实验来验证 MPC 的属性。把两个签名机进程停掉用文本编辑器打开shard1.json和shard2.json你会发现里面只有两个随机数任何一个都无法单独推导出聚合私钥。然后在网络抓包里确认Rust 和 Java 之间传的全是公钥、nonce 点、部分签名这类公开数据整个签名过程中没有任何一方见过完整私钥。我管这个叫“行为验证”除了看代码还要看运行时的表现。曾经有个同学在我的指导下实现了一遍代码看起来完全没问题但跑起来才发现他把完整私钥放在 Java 内存里拼了一次只是为了算个签名。这种错误编译期抓不出来只有通过抓包或者日志审计才能发现。这也是为什么我坚持在架构图里把 Java 层放在“不碰密钥材料”的位置上。6. 踩坑记录与生产化改造清单6.1 常见问题速查表我把自己在开发过程中遇到的高频问题整理成了表格方便你边做边排查。现象根本原因解决办法验签偶尔失败组合 s 时没对 n 取模s1.add(s2).mod(n)不要再直接相加nonce 接口重复调用报错签名机状态里 nonce 被取走了确认每次签名前先请求新 nonce且不能并发复用两边算出的 e 不一致哈希规则不统一检查 tag、字段顺序、字节序准则是一条字符串拼到底启动签名机提示 shard 文件不可读文件权限过严或路径错误chmod 600 之后确认是运行账号拥有R 点的字节序混乱secp256k1 坐标是大端序统一用十六进制字符串传输解析时严格按大端处理分片文件被其他进程读到迁移分片时忘了纠正权限落盘后立刻 chmod必要时用加密文件系统6.2 教学版与生产版的差距清单这篇文章实现的代码定位是教学演示和预研验证距离生产级 MPC 钱包还有明确的差距我列在这里你可以对着做差距评估。第一协议强度。我们用朴素 Schnorr 并假设双方诚实真实场景需要处理恶意方。如果签名方可以任意构造挑战值 e或者中途掉线重放都会有安全隐患。生产级至少要用 FROST 或者两方 ECDSA 的审计实现比如 ZenGo 的 multi-party-ecdsa、frost-core 这类库而不是自己从零写。第二通信安全。Java 中转的模式只适合功能验证真实部署中签名机之间要有 TLS 双向认证和时间戳防重放。更严格的方案是让签名机之间直接建立加密通道Java 只下发“开始签名”的指令不接触任何中间协议消息。第三密钥存储。分片以明文 JSON 落盘只是权宜之计生产环境要接 TEE、HSM 或基于密码的本地加密并且要有完整的密钥版本管理和轮换策略。第四签名算法兼容性。如果你要对接以太坊得把 Rust 内核的 Schnorr 模块替换成两方 ECDSA架构可以保留但协议复杂度会上升一到两个量级。6.3 后续扩展方向分片数量从 2 扩到 3 或 5只需要把加法分片换成真正的 Shamir 多项式分片签名流程里把部分签名的收集规则改成门限组合。技术上没有本质障碍前提是你先把 2-2 链路跑透。另一个值得做的扩展是把签名机部署到两台物理机上让两个分片分散到不同的安全域这样就算一台机器被攻破攻击者也拿不到完整私钥。再往上走可以给签名机之间加上基于签名的身份认证把协议从“乐观信任”提升到“恶意安全”。我个人实际操作中的体会是MPC 项目最难的部分往往不是密码学本身而是工程边界和状态管理。你只要把“谁持有秘密、谁传输公开信息、什么时候该清内存”这三件事想清楚架构基本不会跑偏剩下的算法细节完全可以站在成熟库的肩膀上逐步替换。这篇最小可用的实现就是一个你可以放心改的起点。