# 面向客户程序的签名

> 举措 QL-03。每个客户程序都能以一次调用完成 ZK 友好签名与后量子签名的验证，让区块链原生应用中的授权只需一行代码。

QL-03 面向客户程序的签名 状态：积极开发中

几乎每个区块链原生应用都会在每次请求时问同一个问题：这是正确的密钥授权的吗？在 v1.0.0 中，客户程序（guest）用代码来回答。secp256k1 公钥恢复由 `k256` 在委托的 `MOD_MUL` 与 `EC_ADD` 电路之上完成，这让以太坊自身的签名变得负担得起；其他任何方案都只能用普通指令执行。QL-03 让签名验证成为客户程序的一等操作。

## 签名方案

一个签名方案证明起来便宜与否，几乎完全取决于它的*验证*算法：做什么运算、在哪个域上做、调用哪个哈希。签名者从不在证明内部运行。以下四种设计覆盖了整个设计空间：

| 方案 | 思路 | 对客户程序的意义 |
| --- | --- | --- |
| 原生曲线上的 Schnorr | 在一条基域恰为证明系统自身所用域的曲线上运行 Schnorr 协议，如 Grumpkin 之于 BN254 | 从构造上就最便宜：运算和哈希都是电路原生的 |
| ML-DSA（FIPS 204） | 把 Schnorr 搬到格上，借助拒绝采样使短响应保持均匀分布 | NIST 的首要后量子签名；成本主要来自其哈希，以及（除非密钥固定）其矩阵扩展 |
| FN-DSA（Falcon） | 基于格陷门的“哈希后签名”，陷门由高斯采样隐藏 | 三种后量子方案中运算最少、哈希也最少 |
| SLH-DSA（FIPS 205） | 仅由哈希函数构造的签名 | 完全没有代数运算，约两千次哈希调用；假设最为保守 |

四种验证算法都是“计算后比较”，不涉及秘密，也不依据秘密做分支，正因如此每一种都可以被证明。专题文章 [ZK-Friendly Signature Schemes](https://www.gweb3networks.com/expositories/zk-friendly-signature-schemes.html) 用玩具示例逐一推演，并比较了它们在电路中的成本。

## 成本由什么决定

有两个杠杆决定了每一个数字：

- **证明者所用的域。** 一个方案的运算就是电路的运算时，它才是原生的。因此哪个方案最便宜，取决于 [QL-02](https://apogee.gweb3networks.com/docs/quantum-leap/post-quantum#refield) 的换域，方案的选择也将与之一同做出。
- **哈希。** 后量子验证算法的成本主要来自其标准哈希，而不是代数运算。换成算术哈希就偏离了标准，这是面向零知识的构造所选择的变体；保留标准哈希，则是与现有密钥互操作的前提。两者各有用武之地，由客户程序决定。

## 面向开发者

目标是让客户程序验证授权，就像今天计算哈希一样：一次调用，委托给电路，应用自己的代码里没有任何密码学。这将打开区块链原生应用赖以构建的各种模式：所用密钥并非链上原生密钥的账户、状态转换函数内部的多方审批、会话密钥，以及在其诞生所依托的曲线被攻破之后依然有效的身份。

返回[任务简报](https://apogee.gweb3networks.com/docs/quantum-leap)。