DKLS 协议：移动端 MPC 性能之选
在移动端场景下，如果 GG20 / CGGMP 这类协议 DKG 动辄数分钟、签名也要数秒，DKLS（DKLs）系列协议是值得重点考虑的替代方向。
它不只是"更快"，而是用 OT（不经意传输） 替代 Paillier 同态加密，在通信轮数、带宽和计算量上都更适合手机端。下面从性能对比、核心原理、安全性到落地生态，系统梳理一遍。
为什么是 DKLS？移动端的性能之选
GG20 这类协议在移动端表现不佳，主要是因为它们依赖 Paillier 同态加密 和大量 零知识证明（ZKP），计算和通信开销都很大。
相比之下，DKLS（DKLs）系列协议 专为高效率设计，核心优势在于：
- 极低的延迟：签名时间可低至 < 1.2 秒，特定网络条件下甚至有 80 毫秒 的案例。
- 更少的通信轮数：最新的 DKLs23 仅需 3 轮 通信，远少于 GG20 的 6 轮以上。
- 更低的带宽消耗：DKLs23 通信量约 60KB，优于 DKLs19 的 90KB。
- 更低的计算需求：整体计算负担远小于 GG 系列协议。
这些特性使 DKLS 非常适合在计算和网络资源受限的移动设备上运行。
主流 MPC 协议移动端对比
| 协议系列 | 代表协议 | 移动端适用性 | 签名速度参考 | 主要特点 |
|---|---|---|---|---|
| DKLS (DKLs) | DKLs19, DKLs23 | 高（推荐） | < 1.2 秒 | 为性能优化，通信轮数少，带宽消耗低，计算量小。 |
| GG 系列 | GG18, GG20 | 低 | 5 - 10 秒 | 依赖 Paillier 加密，计算和通信开销大，不推荐移动端。 |
| CMP 系列 | CMP, CGGMP | 中等 事实移动端性能超级差 | ~15ms（在线阶段） | 安全性高，支持恶意多数模型；在线快，但预签名阶段复杂。 |
请注意：上表中 CMP 的 "~15ms" 仅指 在线签名阶段，完整流程还包含耗时较长的预计算（Presigning）阶段。
核心原理：OT 如何取代 Paillier
与 GG 系列依赖复杂 Paillier 同态加密不同，DKLs23 的核心创新是使用 不经意传输（Oblivious Transfer, OT） 作为密码学原语。可以把 OT 理解成一个"安全的消息传递员"：
- 发送方 有两条消息（
m₀和m₁）。 - 接收方 提供一个选择比特
c（0 或 1）。 - 协议结束后，接收方 只能 收到
m_c，而发送方 不知道 接收方选择了哪条消息。
DKLs23 利用 OT 的这个特性，让多方在"互不知晓对方秘密"的情况下，协同完成椭圆曲线上的标量乘法等核心运算。实现中通常采用 OT 扩展（OT Extension） 技术，用少量基础 OT 高效生成大量 OT 实例。
安全现状与潜在风险
DKLs23 在性能上是飞跃，但 OT 乘法和安全性确实需要仔细审视。总的来说，协议核心是 安全的，安全性建立在扎实的密码学基础上；但并非完美无缺，极度依赖正确实现，且在理论安全性上有一个已被识别的"小瑕疵"。
理论安全性：从"统计安全"到"计算安全"
- 原声明：DKLs23 原始论文声称达到 统计安全性（Statistical Security）——即使攻击者拥有无限计算能力也无法攻破。
- 最新发现：2026 年 5 月的一篇学术论文对此提出修正，证明 DKLs23 并未达到 统计安全性。
- 现实情况：它仍然是 计算安全性（Computational Security） 的，与 RSA、ECC 等日常密码系统处于同一安全级别。论文也提出了轻量级改进方案，可使其恢复统计安全性。
实现安全性：细节决定成败
DKLs23 规范给予实现者较大自由度来选择底层子协议（基础 OT、OT 扩展等），这是实践中更需警惕的风险：
- 审计发现：Trail of Bits 在审计早期 DKLs23 生产级库 Silent Shard 时，发现了可能被利用来 破坏密钥的严重漏洞。
- 好消息：漏洞被发现后已及时修复，该库也通过了后续全面安全审计。说明选择 经过严格安全审计的实现 至关重要。
协议层安全性：对恶意行为有防护
协议本身考虑了恶意攻击者，例如：
- OT 扩展协议带有一致性检查，能以极高概率（如
1 - 2⁻⁸⁰）检测并拒绝恶意接收方的欺骗行为。 - 乘法协议通过"乘后检查"（Mul-then-check）等机制保证输出正确性。
潜在风险与挑战
- 实现复杂度：子协议选择或具体编码时很容易引入漏洞。
- 侧信道攻击风险：部分实现（如
tss-lib）的 OT 基础运算中，标量乘法并非恒定时间（Constant-Time）实现，存在通过执行时间推断密钥的风险。 - OT 乘法的正确性：协议设计本身经过论证；主要风险在于 实现不当 时，攻击者可能通过滥发错误信息干扰协议，导致生成错误签名。
落地生态：SDK 与钱包
DKLs23 作为较新技术，应用案例不如成熟方案广泛，但已有多款 SDK 和钱包产品在实际落地，主要集中在 加密货币钱包和 MPC 基础设施 领域。
SDK 与库
| 项目/产品 | 简介 | 关键特点 |
|---|---|---|
| Silent Shard | Silence Laboratories 开发的 DKLs23 协议库 | 生产级实现，曾由 Trail of Bits 审计；被 MetaMask 等钱包采用。 |
| ceres_mpc | 基于 Flutter 的 MPC SDK | 专为 移动端（Flutter） 设计，Rust 核心；支持两方密钥生成、恢复和签名。 |
| @vultisig/sdk | Vultisig 协议 TypeScript SDK | 跨平台（Node.js、浏览器、React Native），支持 37+ 条区块链；提供"快速金库"和"安全金库"。 |
| @bitshard.io/bitshard-sdk | BitShard TypeScript SDK | 支持灵活 n-of-m 阈值配置，提供 密钥轮换 和 恢复。 |
| dkls23-wasm | DKLs23 的 WebAssembly 封装 | 支持 Web 浏览器和 Node.js，实现 DKG 和 DSG。 |
| dklstss（Go） | Go 语言 DKLs23 实现 | secp256k1 阈值 ECDSA 签名，支持密钥刷新、委员会重共享等。 |
钱包与应用
| 项目/产品 | 简介 | 关键特点 |
|---|---|---|
| MetaMask | 最流行的以太坊钱包之一 | 底层使用基于 DKLs23 的 Silent Shard，是主流产品中的 重要落地案例。 |
| Blockdaemon | 区块链基础设施平台 | MPC 节点服务支持 DKLs23，提供水平扩展配置。 |
| Vultisig | 自托管 MPC 钱包 | 通过 @vultisig/sdk 提供跨平台服务，支持二维码在移动应用间配对。 |
| BitShard | MPC 钱包基础设施 | 通过 SDK 提供分布式密钥生成和阈值签名服务。 |
React Native 实践
在 React Native 中集成 DKLS，可以考虑以下途径：
- 原生桥接库：封装高性能 C++/Rust MPC 库的 RN 桥接，例如
@toruslabs/react-native-tss-lib-bridge。 - 第三方 MPC 服务 SDK：
- Web3Auth：基于 DKLs19，签名时间 < 1.2s。
- PortalHQ：跨平台（含 React Native）MPC 操作 SDK。
- Vultisig：
@vultisig/sdk，TypeScript 实现，支持 React Native。
- 移动端优先选型：如果自研集成，可重点关注
@vultisig/sdk或ceres_mpc——前者跨平台覆盖 RN，后者专为移动端 Flutter 设计。
如果对签名速度有极致要求，且签名方可以是一台服务器，也可以考虑 BLS 签名方案：吞吐量极高（> 100 sig/s），且无需多方同步。
总结
- 性能：DKLS（尤其 DKLs23）在移动端显著优于 GG 系列，是 GG20 / CGGMP 慢体验的直接替代方向。
- 原理：用 OT 替代 Paillier，是性能提升的根本来源。
- 安全：协议具备 计算安全性，OT 乘法机制在密码学上可靠；但理论上的统计安全声明已被修正，且 极度依赖审计过的实现。
- 落地：Silent Shard（MetaMask）、Vultisig、BitShard 等已有生产案例；RN 场景优先选成熟 SDK，不要自行实现。
生产环境（尤其是 React Native 应用）的核心建议：务必选择经过独立安全公司（如 Trail of Bits）严格审计的成熟开源库或商业 SDK。