ERC-7524: 钱包中的 PLUME 签名
一种新的以太坊密钥对签名方案，允许使用“无效值”来实现独特的匿名性和 ZK 投票。
| Authors | Yush G (@Divide-By-0) <aayushg@mit.edu>, Kobi Gurkan (@kobigurk), Richard Liu (@rrrliu), Vivek Bhupatiraju (@vb7401), Barry Whitehat (@barryWhiteHat) |
|---|---|
| Created | 2023-09-24 |
| Discussion Link | https://ethereum-magicians.org/t/erc-7524-plume-signature-in-wallets/15902 |
Table of Contents
摘要
ZK-SNARKs 已经促成了基于匿名所有权证明的新身份应用程序的构想。将现有应用程序转变为需要匿名唯一性的系统的主要技术之一是可验证的确定性签名的开发。由于以太坊基于 ECDSA，因此目前无法验证签名是否以确定性方式生成，即使使用“确定性” ECDSA 签名也是如此：ZK-SNARK 证明需要某人的私钥才能实现，并且某些硬件钱包甚至不允许查看私钥。总的来说，我们不希望将私钥导出/复制粘贴到 SNARK 中成为预期的用户行为，并且大多数硬件钱包将无法在安全 enclave 中为现有方案运行 SNARK 算术化（而且我们也不希望现在标准化钱包中的整个证明系统，因为它们几乎每年都在涌现和发展）。因此，我们只能选择一种新的算法，该算法为我们提供可在 enclave 外部进行 SNARK 化的可验证的确定性无效值。
这种签名如何导致独特的假名的具体示例是，我们在 ZK-SNARK 中证明它是正确生成的，该 ZK-SNARK 仅公开 reveal the hash(signature)，并且 SNARK 另外证明了公钥具有的某些属性（即，在某个匿名集中，已在链上执行了某些操作集等）。此证明是其他人看到的唯一内容，因此 hash(signature) 可以用作“无效值”：对特定匿名帐户的公共承诺，以禁止诸如双重支出之类的行为，或允许匿名操作之间保持一致的身份。我们的目标是标准化一种新的可验证的确定性签名算法，该算法既能唯一标识密钥对，又能保护帐户身份的秘密，并且验证不需要密钥。我们找到的特定签名函数（将在本文的其余部分进行讨论）是 $hash(message, public\ key) ^ {secret\ key}$。
动机
- 现有的 ZK 应用程序的优势在于，对证明者没有唯一性约束：也就是说，允许同一钱包多次证明自己是成员是有意为之的。但是，许多应用程序需要每个用户最多执行一次操作，尤其是那些希望实现 Sybil 抵抗的协议。如果没有将每个地址映射到选择加入映射（该映射还将用户的私钥映射到新系统），以太坊目前无法原生实现此类协议，这增加了复杂性，丧失了原子性，并且无法从以太坊帐户丰富的链上历史记录中受益。
- 需要此技术的特定应用程序包括：
- zk 投票，其中某个集合中的每个帐户都有一票
- 以假名方式申领空投，如 Stealthdrop
- 审核假名论坛，人们可以在论坛的其他地方证明他们是同一个身份
- zk 偿付能力证明——如果您希望两个交易所证明他们知道一组持有某些余额的私钥，则需要一种方法来确保两个交易所不会同时申领同一个地址，同时保持私密性
因此，基于以太坊帐户的 ECDSA 密钥对的确定性值是确保每个用户执行一次操作的必要组成部分，并且可以在以太坊上启用所有这些应用程序。
规范
我们提出了一种新的签名标准，该标准提供以下属性，以便在钱包中为标准 ECDSA 密钥实施：
- 它生成的签名包含确定性组件和非确定性组件。确定性组件可以用作无效值。
- 签名者可以使用现有的 secpk256k1 密钥对，例如那些在支持以太坊帐户的硬件钱包中的密钥对。因此，如果 enclave 中存在生成器点乘法 API（例如 Ledger 就有），则密钥可以保留在安全 enclave 中。
参数
此方案使用 高效密码学标准 2 (SEC 2) v2 第 9 页中定义的 secp256k1 曲线。
我们使用以下符号来引用此曲线的参数：
- $g$：曲线的基点（也称为生成器）。
- $p$：曲线的阶数。
- $F_p$：阶数为 $p$ 的有限域。
请注意，我们使用指数符号来表示椭圆曲线标量乘法。
公钥编码函数
SEC1
此方案使用 高效密码学标准 1 (SEC 1) v2 中定义的 SEC1 椭圆曲线点编码方案。使用点压缩。我们使用符号 $\mathsf{sec1}(pk)$ 来表示 secp256k1 曲线点 $pk$ 的压缩编码，作为长度为 33 的字节串。
哈希函数
SHA256
此方案使用 IETF RFC 4634 中定义的 SHA256 哈希函数。
在本文档中，我们使用符号 $\mathsf{sha256}(a_1,.. a_n)$ 来表示 $n$ 个值 $a_1, …, a_n$ 的串联的 sha256 摘要。然后应将摘要解释为 secp256k1 标量域中的大端值。
哈希到曲线
我们使用符号 $\mathsf{htc}([a_1, …, a_n])$ 来表示椭圆曲线点，它是 IETF RFC 9380 附录 J.8.1 中的 secp256k1_XMD:SHA-256_SSWU_RO_ 的结果。此哈希到曲线算法对 $n$ 个值 $a_1, …, a_n$ 的串联进行运算。
密钥生成
密钥对包括 $(sk, pk)$，定义如下：
- $sk$：用户的密钥，它是 $F_p$ 域中的加密安全随机标量。
- $pk$：用户的公钥，定义为 $g^{sk}$，它是 secp256k1 曲线上的一个点。
签名生成
此方案基于 Chaum-Pedersen 签名方案 1。给定一个 32 字节的消息 $m$ 和一个密钥对 $(sk, pk)$，用户可以按如下方式生成签名：
- 从 $F_p$ 中选择一个随机 $r$。
- 计算 $h = \mathsf{htc}([m, \mathsf{sec1}(pk)])$。
- 计算 $z = h ^ r$。
- 计算无效值 $\mathsf{nul} = h^{sk}$。
- 计算 $c = \mathsf{sha256}([g, pk, h, \mathsf{nul}, g^r, z]])$。
- 计算 $s = r + sk \cdot c$。
签名是 $(z, s, g^r, c, \mathsf{nul})$。
$\mathsf{htc}$ 的输入长度始终为 65 个字节。
请注意，在此方案中，我们将 $h$ 计算为消息和 $pk$ 的哈希，而不是消息和 $r$ 的哈希。这是为了使我们的方案具有确定性。
签名验证（非 ZK）
📝 注意：此部分不具有规范性。
非 ZK 签名验证不是此提案的一部分，但与直观地理解 ZK 签名验证相关。
在验证者知道 $g$、$m$、签名者的公钥 $pk$ 和签名 $(z, s, g^r, c, \mathsf{nul})$ 的情况下，他们可以执行以下检查以确定签名是否有效：
- 计算 $h = \mathsf{htc}([m, \mathsf{sec1}(pk)])$。
- 计算 $c’ = \mathsf{sha256}([g, pk, h, \mathsf{nul}, g^r, z])$。
- 如果以下任何一项为假，则拒绝： a. $g^{s} \cdot pk^{-c} \stackrel{?}{=} g^r$ b. $h^s \cdot \mathsf{nul}^{-c} \stackrel{?}{=} z$ c. $c \stackrel{?}{=} c’$
- 如果以上所有项都为真，则接受。
现在我们转到 ZK 签名验证规范。
版本 1：验证器优化
在存在必须不能知道签名者的 $pk$ 的验证者的情况下，但签名者必须证明他们在给定 $m$ 的签名的情况下知道对应于的 $sk$，则需要零知识证明。
以下验证函数可以通过电路描述为非交互式零知识证明系统（例如 Groth16）的一部分。要创建证明，证明者提供以下输入：
公开： $\mathsf{nul}$，$c$ 私有： $pk$、$r$、$s$、$z$、$g^r$、$hash[m, g^sk]$（包含用于保存约束）
电路执行以下计算：
- 计算 $h = \mathsf{htc}([m, \mathsf{sec1}(pk)])$。
- 计算 $pk = g^{sk}$。
- 计算 $c’ = \mathsf{sha256}([g, pk, h, \mathsf{nul}, g^r, z]])$。
- 计算 $g^{s} \cdot pk^{-c}$。
- 计算 $g^r$。
- 计算 $h^s \cdot \mathsf{nul}^{-c}$。
它还建立以下约束：
- $g^{s} \cdot pk^{-c} = g^r$
- $h^s \cdot \mathsf{nul}^{-c} = z$
- $c = c’$
版本 2：证明者优化
目前，SHA-256 哈希运算在浏览器中的 zk 证明中尤其昂贵。在 PLUME 的上下文中，$c$ 的计算是有效证明时间的瓶颈，因此 Poseidon 团队建议的一种修改是将此哈希计算移出电路，转移到验证器中。
为此，我们将 $z$ 和 $g^r$ 作为电路中的公共信号，并将 $c$ 的定义更新为 $c = \text{sha256}([\text{nul}, g^r, z])$。更新后的协议如下。
公开： $\mathsf{nul}$，$c$，$g^r$，$z$ 私有： $pk$，$r$，$s$，$hash[m, g^sk]$
电路执行以下计算：
- 计算 $h = \mathsf{htc}([m, \mathsf{sec1}(pk)])$。
- 计算 $pk = g^{sk}$。
- 计算 $g^{s} \cdot pk^{-c}$。
- 计算 $g^r$。
- 计算 $h^s \cdot \mathsf{nul}^{-c}$。
该电路建立以下约束：
- $g^{s} \cdot pk^{-c} = g^r$
- $h^s \cdot \mathsf{nul}^{-c} = z$
除了验证 zk-SNARK 之外，PLUME 验证器还执行以下检查。
$c == \text{hash}(\text{nul}, g^r, h^r)$
由于 SHA-256 是以太坊上的原生预编译，因此此操作对于智能合约验证器仍然有效。
版本 3：
将来可能会有更高效的 V3，可能通过从 hash_to_curve 中删除不可区分性来实现。
理由
我们将定义我们在候选算法中寻找的一些特定属性，然后定义一些其他的直观算法，并解释为什么它们实际上不起作用。
- 非交互性
- 非交互性在 ZK ID 系统中的重要性在于，它可以从一开始就实现较大的匿名集，使其能够抵抗 sybil 攻击和垃圾邮件，如果存在交互阶段，则可能会发生这些攻击和垃圾邮件。这使得可以实现新的用例，例如 ZK 空投。
- 非交互性使得所有符合条件的用户都可以成为匿名集的一部分，而无需任何交互。如果 zk 证明可以验证 Merkle 树中的集合成员资格、通过签名验证消息以及验证唯一的无效值，则可以实现这一点。交互式无效值（例如 tornado.cash 的无效值）需要使用每个新用户更新匿名集 Merkle 树，
- 唯一性
- 如果我们要禁止诸如双重支出或双重申领之类的行为，我们需要确保每个帐户的这些行为在可验证的意义上是唯一的。
- 例如：由于 ECDSA 签名是非确定性的，因此签名不足以满足要求；我们需要一个新的确定性函数，该函数只能使用公钥进行验证。我们希望无效值是非交互式的，以唯一标识密钥对，同时保持帐户身份的秘密。
- 关键的见解在于，此类无效值可以用作对特定匿名帐户的公开承诺，从而为我们提供唯一性保证。
- 确定性
- 我们希望每个帐户只生成一个此类签名，并在未来随着时间的推移完全以相同的方式生成该签名。
- 无需密钥即可验证
- 在签名是非确定性签名（如 ECDSA）的情况下，仅凭签名不足以进行验证。
- 我们需要一个只能使用公钥验证的新的确定性函数
- 我们不希望用户在任何地方复制粘贴密钥，并且我们需要选择一个函数，以使 enclave 计算对于硬件钱包来说足够简单。
- 由于无效值是非交互式的，因此我们能够在不泄露帐户身份的情况下唯一标识密钥对。
我们最终的设计尽可能简单，并且基于 BLS 签名、Chaum-Pederson EQDL 和 Goh-Jarecki 的 EDL 论文，但适用于 secp256k1。
安全注意事项
PLUME 论文 2 中有对此特定算法的密码学的正式证明。该理论已经发布，并且实现已经进行了一轮内部审计，但它们尚未端到端地进行正式验证或审计，尽管从经验上证明它们正确地符合所提出的规范。
交互性-量子保密性权衡
请注意，在遥远的未来，一旦量子计算机可以破坏 ECDSA 密钥对的安全性，大多数以太坊密钥对将被破坏，但提前迁移到抗量子密钥对将确保主动资金的安全。具体来说，人们可以仅通过对消息进行签名来提交到新的抗量子密钥对（或类似算法上的更高位密钥对），并且规范链可以分叉以使此类密钥对有效。ZK-SNARK 变得可伪造，但 ZK 证明仍然具有前向保密性。在最佳情况下，链应该能够顺利地继续下去。
但是，如果人们依赖于任何类型的确定性无效值（如我们的构造），则他们的匿名性会立即被破坏：有人可以仅推导出整个匿名集的密钥，计算所有无效值，并查看哪些无效值匹配。ECDSA 上的任何确定性无效值算法都会存在此问题，因为泄露密钥会泄露“随机性”的唯一来源，而“随机性”可保证确定性协议中的匿名性。
| 如果人们希望保持数据的后量子保密性，则他们必须放弃我们的至少一种属性：最简单的一种属性可能是非交互性。例如，对于零知识空投，匿名集中的每个帐户都会公开地签署对新 semaphore id 承诺的承诺（实际上，地址 pk 发布 $hash[randomness\ | \ external\ nullifier\ | \ pk]$）。然后，为了索取，他们会泄露其外部无效值，并且 ZK 证明它来自匿名集中的某个 semaphore id。这会将匿名集大大缩小到在该帐户进行索取之前已选择加入 semaphore 承诺的每个人。因此，可能需要一个单独的注册阶段，人们可以在其中提交无效值以播种匿名集。这种交互性要求使得诸如 zk 空投或更好的 tornado cash 构造（在使用案例部分中）之类的应用程序变得更加困难。但是，由于（就我们目前所知）哈希对于量子计算机来说仍然很难，因此人们不太可能能够使您匿名。 |
最近对通过量子退火解决离散对数所需的 $2n^2$ 量子位的近似值表明，在大于 $n$ = 6 位素数的情况下无法工作，这表明我们可能要花费数十年才能实现这一目标，并且解决 RSA 所需的 $n^2$ 量子位的预测为 10-40 年，这表明解决离散对数可能需要更长的时间。
我们希望人们能够为其应用程序选择适当的算法，以在其选择的交互性-量子保密性权衡点上做出选择，并希望包含此信息可以帮助人们做出正确的选择。优先考虑短期保密性的人员（例如 DAO 投票或年轻人的供词，这些人可能在年老时不再关心）可能会优先考虑本文档的无效值构造，但举报人或记者可能需要考虑使用 semaphore 构造。
版权
通过 CC0 放弃版权及相关权利。
-
{ "DOI": "10.1007/3-540-48071-4_7", "URL": "https://link.springer.com/content/pdf/10.1007/3-540-48071-4_7.pdf", "publisher-place": "Berlin, Heidelberg", "author": [ { "given": "David", "family": "Chaum" }, { "given": "Torben Pryds", "family": "Pedersen" } ], "container-title": "Advances in Cryptology — CRYPTO' 92", "editor": [ { "given": "Ernest F.", "family": "Brickell" } ], "type": "paper-conference", "id": "10.1007/3-540-48071-4_7", "citation-label": "10.1007/3-540-48071-4_7", "ISBN": "978-3-540-48071-6", "issued": { "date-parts": [ [ 1993 ] ] }, "page": "89-105", "publisher": "Springer Berlin Heidelberg", "title": "Wallet Databases with Observers" } -
{ "DOI": "1721.1/147434", "author": [ { "given": "Aayush", "family": "Gupta" }, { "given": "Kobi", "family": "Gurkan" } ], "type": "book", "id": "Gupta_Gurkan_2022_PLUME", "citation-label": "Gupta_Gurkan_2022_PLUME", "issued": { "date-parts": [ [ 2022, 9 ] ] }, "keyword": "zero knowledge,zk proof,nullifier,ddh-vrf,vrf,pseudonymity,ethereum,bitcoin,ecdsa,secp256k1,plume,signature", "note": "Cryptology ePrint Archive, Paper 2022/1255", "title": "PLUME: An ECDSA Nullifier Scheme for Unique Pseudonymity within Zero Knowledge Proofs", "URL": "https://eprint.iacr.org/2022/1255" }
Citation
Please cite this document as:
Yush G (@Divide-By-0) <aayushg@mit.edu>, Kobi Gurkan (@kobigurk), Richard Liu (@rrrliu), Vivek Bhupatiraju (@vb7401), Barry Whitehat (@barryWhiteHat), "ERC-7524: 钱包中的 PLUME 签名 [DRAFT]," Ethereum Improvement Proposals, no. 7524, September 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7524.