最小可用MPC钱包实战：Rust内核与Java编排实现两方签名闭环

做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 签名为什么适合做 MPC

2.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 + x2，k = 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 请求 nonce，A 本地生成随机 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 的所有权模型帮了大忙。状态结构体放在Arc<Mutex<...>>里，每次操作都是独占锁，不会出现两个并发请求意外共用一个 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): State<Arc<Mutex<SignerState>>>, Json(req): Json<PartialSignReq>, ) -> Result<Json<PartialSignResp>, 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> <groupId>org.bouncycastle</groupId> <artifactId>bcprov-jdk18on</artifactId> <version>1.77</version> </dependency> <dependency> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-databind</artifactId> <version>2.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.mainClass=com.example.MpcWalletDemo

5.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 常见问题速查表

我把自己在开发过程中遇到的高频问题整理成了表格，方便你边做边排查。

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 项目最难的部分往往不是密码学本身，而是工程边界和状态管理。你只要把“谁持有秘密、谁传输公开信息、什么时候该清内存”这三件事想清楚，架构基本不会跑偏；剩下的算法细节，完全可以站在成熟库的肩膀上逐步替换。这篇最小可用的实现，就是一个你可以放心改的起点。