验证者证明：一种用于以太坊 DHT 的简单匿名凭证方案 - 密码学

验证者证明：以太坊 DHT 的简单匿名凭证方案

作者：George Kadianakis, Mary Maller, Andrija Novakovic, Suphanat Chunhapanya

简介

以太坊的路线图包含一种名为数据可用性采样 (DAS)的扩展技术。DAS 为以太坊的网络栈引入了新的需求，需要实现专门的网络协议。一个突出的 协议提案 使用基于 Kademlia 的分布式哈希表（DHT）来存储和检索数据样本。

然而，DHT 容易受到女巫攻击：控制大量 DHT 节点的攻击者可能使 DAS 样本不可用。为了应对这种威胁，可以建立一个高信任度的网络层，仅由信标链验证者组成。这种安全措施显着提高了攻击者的门槛，因为他们现在必须质押自己的 ETH 才能攻击 DHT。

在这篇文章中，我们介绍了一种验证者证明协议，该协议使 DHT 参与者能够零知识地证明他们是以太坊验证者。

动机：DAS 上的 “样本隐藏” 攻击

在本节中，我们将通过描述针对数据可用性采样的女巫攻击，进一步论证验证者证明协议的必要性。

DAS 协议围绕区块构建者展开，以确保区块数据可用，以便客户端可以获取它们。目前的方法涉及将数据划分为样本，网络参与者仅获取与其兴趣相关的样本。

考虑这样一种情况：女巫攻击者想要阻止网络参与者从负责提供样本的受害者节点获取样本。如上图所示，攻击者生成许多接近受害者节点 ID 的节点 ID。通过用他们自己的节点包围受害者节点，攻击者会阻止客户端发现受害者节点，因为恶意节点会故意隐瞒有关受害者存在的信息。

有关此类女巫攻击的更多信息，请参阅这篇关于 DHT Eclipse 攻击的 最新研究论文。此外，Dankrad 的 DAS 网络协议提案 描述了 S/Kademlia DHT 协议如何受到此类攻击的影响，并展示了对验证者证明协议的需求。

验证者证明

上述攻击促使需要一种验证者证明协议：如果只有验证者可以加入 DHT，那么想要发起女巫攻击的攻击者还必须质押大量 ETH。

使用我们的验证者证明协议，我们确保只有信标链验证者可以加入 DHT，并且每个验证者都获得唯一的 DHT 身份。

此外，为了提高验证者的 DoS 弹性，我们的目标还在于隐藏网络层上验证者的身份。也就是说，我们不希望攻击者能够分辨出哪个 DHT 节点对应于哪个验证者。

为了实现这些目标，验证者证明协议必须满足以下要求：

• 唯一性：每个信标链验证者必须能够派生一个唯一的密钥对。此属性不仅限制了女巫攻击者可以生成的节点数量，而且还使网络参与者能够通过将行为不端的节点的派生密钥对列入黑名单来在本地惩罚它们
• 隐私性：对手必须无法了解哪个验证者对应于特定的派生公钥
• 验证时间：协议的验证过程必须高效，每个节点耗时少于 200 毫秒，从而使每个节点每秒至少学习五个新节点

Bob 在 DHT 层建立连接期间会使用这种验证者证明协议，以便 Alice 知道她正在与验证者对话。

验证者证明协议

我们的验证者证明协议实际上是一个简单的匿名凭证方案。其目标是使 Alice 能够生成一个唯一的派生密钥，表示为 DD，当且仅当她是验证者。随后，Alice 在网络层中使用此派生密钥 DD。

在设计此协议时，我们的目标是创建一个易于实施和分析的解决方案，确保其以有效的方式满足概述的要求。

协议概述

该协议采用成员资格证明子协议，其中 Alice 通过使用 ZK 证明来证明她知道一个秘密哈希原像，从而证明她是验证者。然后，Alice 构造一个从该秘密哈希原像派生的唯一密钥对。

成员资格证明子协议可以通过不同的方法实例化。在这篇文章中，我们展示了一个使用 Merkle 树的协议和第二个使用 查找 的协议。

虽然这两种方法都表现出可接受的效率，但它们具有不同的权衡。Merkle 树依赖于 SNARK 友好的哈希函数，如 Poseidon（可能被认为是实验性的）。另一方面，有效的查找协议依赖于大小等于验证者集大小（目前为 70 万验证者，但仍在增长）的 powers-of-tau 可信设置。

现在让我们深入研究这些协议：

方法 #1：Merkle 树

Merkle 树已广泛用于成员资格证明（例如，请参阅 Semaphore）。以下是设计使用 Merkle 树的成员资格证明时的权衡空间：

• 优点：无需可信设置
• 优点：易于理解
• 缺点：依赖于 SNARK 友好的哈希函数，如 Poseidon
• 缺点：较慢的证明创建

下面我们描述了基于 Merkle 树的验证者证明协议：

使用 Merkle 树的验证者证明协议

每个验证者 ii 在区块链上注册一个值 p_ipi，使得 p_i = Hash(s_i)pi=Hash(si)。因此，区块链包含一个列表 \{p_i\}{pi}，使得：

p_1 = Hash(s_1), \ldots, p_n = Hash(s_n)

p1=Hash(s1),…,pn=Hash(sn)

其中 p_ipi 是公开的，而 s_isi 是秘密的。区块链为公开的 p_ipi 值列表创建并维护一个公共 Merkle 根 RR。

假设 Alice 是一个验证者。以下是她如何在她拿到她的秘密值 s_isi 的前提下计算并显示她的派生密钥 DD：

1. 设置派生密钥 DD 等于 D = s_i GD=siG

2. 通过通用 zkSNARK 以零知识证明存在一条从 p_ipi 到 Merkle 根 RR 的有效 Merkle 路径，以及以下声明：

p_i = Hash(s_i) \\\
D = s_iG \\\

pi=Hash(si) \\\
D=siG

在该协议结束时，Alice 可以在 DHT 中使用 DD 来签署消息并派生她唯一的 DHT 节点身份。

现在让我们看看一个稍微复杂但效率更高的使用查找的解决方案。

方法 #2：查找

以下是使用 lookup 协议（如 Caulk）的权衡空间：

• 优点：极高效的证明创建（使用预处理阶段）
• 优点：协议可以修改为使用常规哈希函数而不是 Poseidon
• 缺点：需要大的可信设置（理想情况下等于验证者的大小）

下面我们描述了一个具体的验证者证明协议：

使用查找的验证者证明协议

与 Merkle 方法完全一样，每个验证者 ii 在区块链上注册一个新值 p_ipi，使得：

p_1 = Hash(s_1), \ldots, p_n = Hash(s_n)

p1=Hash(s1),…,pn=Hash(sn)

其中 p_ipi 是公开的，而 s_isi 是秘密的。区块链为所有 p_ipi 值的向量创建并维护一个 KZG 承诺 RR。

假设 Alice 是一个验证者。以下是她如何在她拿到她的秘密值 s_isi 的前提下计算并显示她的派生密钥 DD：

1. 设置派生密钥 DD 等于 D = s_i GD=siG

2. 显示承诺 C = p_i G + s_i HC=piG+siH，其中 HH 是第二个群生成器。

你可以将 (D, C) = (s_i G, p_i G + s_i H)(D,C)=(siG,piG+siH) 视为 p_ipi 在随机数 s_isi 下的 El-Gamal 加密。假设 HashHash 是一个随机预言机，s_isi 不以任何方式显示，因此这是 s_isi 的有效加密。

3. 使用 Caulk+ 證明 来证明 CC 是对由承诺 RR 表示的集合 \{p_i\}{pi} 中值的承诺。

4. 使用 Sigma 协议证明 s_isi 在 DD 和 CC 之间是一致的。

5. 使用通用 zkSNARK 证明 p_i = Hash(s_i)pi=Hash(si) 且 C = p_iG + s_iHC=piG+siH。

At the end of the protocol, the validator uses DD as her derived key on the networking layer.

在该协议结束时，验证者将 DD 用作她在网络层上的派生密钥。

效率

我们根据证明创建和验证对我们的成员资格证明协议的运行时进行了基准测试（链接 到基准代码）。请注意，虽然成员资格证明只是我们的验证者证明协议的一部分，但我们预计它会主导总体运行时间。

下面我们提供了使用 Halo2 证明系统和 IPA 作为多项式承诺方案的 Merkle 树成员资格证明的基准测试结果。IPA 是一种比 KZG 慢的方案，但它不需要可信设置，从而最大限度地提高了 Merkle 树方法的优势。

我们观察到证明者和验证者时间都与我们的效率要求非常吻合。因此，我们决定不对基于 Caulk 的方法进行基准测试，因为预计其在所有类别（尤其是证明者时间和证明大小）中的性能都会显着提高。

基准测试是在运行在 Intel i7-8550U（五年前的 CPU）上的笔记本电脑上收集的。

讨论

旋转身份

验证者证明协议的唯一性属性可确保每个网络参与者都拥有不同的派生密钥对。但是，对于某些网络协议，允许验证者拥有轮换身份可能是有利的，其中它们的派生密钥会定期更改，例如每天更改。

为了实现这一点，我们可以调整协议以基于可变字符串（例如每日更改的值）生成轮换的派生密钥。例如，设 D = r_iGD=riG：为了证明此轮换密钥的有效性，我们可以利用 SNARK 证明 r_i = Hash( s_i || \mathsf{daily string})ri=Hash(si||dailystring)。此外，SNARK 必须证明 p_i = Hash(s_i)pi=Hash(si) 并对 p_ipi 进行成员资格证明。

在这种情况下，如果 Eve 在某一天行为不端，Alice 可以将她在该天列入黑名单。但是，在第二天，Eve 可以生成一个新的未被列入黑名单的派生密钥。如果我们想要能够基于其旋转身份永久地将验证者列入黑名单，我们将需要一种更高级的匿名凭证方案，例如 SNARKBlock。

为什么不使用身份 BLS12-381 公钥？

另一种（可能更简单的）方法是构建一个由所有验证者身份 BLS12-381 密钥组成的承诺，并对该承诺进行成员资格证明。

但是，此方法将要求验证者将其身份私钥插入到 ZK 证明系统中，以创建有效的成员资格证明并计算唯一的派生密钥。

我们决定不采用这种方法，因为将敏感身份密钥插入到复杂的加密协议中不是一个好习惯，而且还会使验证者更难以将其主身份密钥保持离线状态。

未来的研究方向

• 我们可以完全避免 SNARK 电路，并以纯粹代数的方式执行成员资格证明和密钥派生吗？
• 相关问题：我们能否在没有可信设置且不依赖 SNARK 友好的哈希函数的情况下，拥有一个有效的成员资格证明协议？

感谢

感谢 Enrico Bottazzi、Cedoor、Vivian Plasencia 和 Wanseob 在浏览成员资格证明代码库网络方面的帮助。

• zkFOCIL：使用可链接环签名实现包含列表隐私
• 允许验证者私下提供客户端信息——Nethermind Research 和 Nethermind Core 的一个项目

• 原文链接： ethresear.ch/t/proof-of-...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～