介绍

以太坊的路线图包含了一种名为“数据可用性采样 (DAS) 。DAS 引入新的 @djrtwo/das-requirements">需求4 ，需要实现 专用网络协议 7。其中一位重要的@dankrad/S-Kademlia-DAS">协议提案 4 使用基于分布式哈希表（DHT）Kademlia2 来存储和检索数据样本。

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

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

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

在本节中，我们进一步激励验证者的证明协议，描述了针对数据可用性采样的女巫 (Sybil) 攻击。

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

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

有关此类 Sybil 攻击的更多信息，请参阅此最近的研究论文2 关于 DHT Eclipse 攻击。此外，@dankrad/S-Kademlia-DAS#SKademlia-modifications">Dankrad 的 DAS 网络协议提案 8 描述了 S/Kademlia DHT 协议如何遭受此类攻击，并表明需要一种验证者的证明协议。

验证者证明（Proof of Validator）

上述攻击激发了对验证者的证明协议：如果只有验证者可以加入DHT，那么想要发起Sybil攻击的攻击者也必须质押大量的ETH。

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

此外，为了验证者 DoS 弹性，我们还致力于在网络层隐藏验证者的身份。也就是说，我们不希望攻击者能够知道哪个 DHT 节点对应于哪个验证器。

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

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

这样一个验证者的证明 Bob 在 DHT 层中建立连接期间将使用协议，以便 Alice 知道她正在与验证者进行通信。

验证者协议证明 (Proof of Validator protocol)

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

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

协议概述

该协议采用了会员证明子协议，其中 Alice 通过使用零知识证明证明来证明她是验证者，证明她知道一个秘密哈希前像。然后，Alice 根据该秘密前像构建了一个唯一的密钥对。

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

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

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

方法#1：默克尔树 (Merkle Tree)

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

• 优点：不需要可信设置
• 优点：简单易懂
• 缺点：依赖于 SNARK 友好的哈希函数，如 Poseidon
• 负面：证明创建速度较慢

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

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

在协议结束时，Alice 可以使用 D 在 DHT 中对消息进行签名并派生出她唯一的 DHT 节点身份。

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

方法#2：查找 (Lookups)

这是使用 Lookup 2 （如Caulk 2）的权衡空间：

• 正面：极其高效的证明创建（使用预处理阶段）
• 正面：协议可以调整为使用常规哈希函数而不是 Poseidon
• 负面：需要大尺寸的可信设置（理想情况下等于验证器的大小）

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

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

就像 Merkle 方法一样，每个验证器我 注册一个新值p我 在区块链上：

效率

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

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

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

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

讨论

轮换身份

这独特性 的财产验证者的证明 协议确保每个网络参与者拥有不同的派生密钥对。然而，对于某些网络协议，允许验证者具有轮换身份可能是有利的，其中它们的派生密钥定期（也许每天）更改。

在这种情况下，如果 Eve 在某一天行为不端，Alice 可以将她当天列入黑名单。但是，第二天，Eve 可以生成一个新的派生密钥，该密钥未列入黑名单。如果我们希望能够根据轮换身份将验证器永久列入黑名单，我们将需要更先进的匿名凭证方案，例如SNARKBlock 1。

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

另一种方法（也许更简单）是从所有验证者身份 BLS12-381 密钥中构建承诺，并对该承诺进行成员资格证明。

然而，这种方法需要验证者将其身份私钥插入到零知识证明系统中，以创建有效的成员身份证明并计算唯一的派生密钥。

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

未来的研究方向

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

致谢

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

声明：

1. 本文转载自[ethresear]，著作权归属原作者[George Kadianakis , Mary Maller, Andrija Novakovic, Suphanat Chunhapanya]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. 文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.io的情况下不得复制、传播或抄袭经翻译文章。