权益证明验证者狙击研究
合并正在迅速临近。几个月后，以太坊链将从工作量证明（PoW）切换到权益证明（PoS）。这是一个令人兴奋的发展，但我们需要强调后合并链的一个重要隐私问题。HOPR 团队一直在与帝国理工学院的去中心化系统和安全小组合作，领导对功能相同的Gnosis 信标链(GBC) 的研究。我们已经确定了验证者对彼此进行狙击攻击以试图窃取他们的区块奖励的巨大不正当动机。
这是可能的，因为 PoS 验证方案要求每个人都提前知道信标链上的验证者公钥，因此每个人都知道验证者在一个时期内对插槽的排序。这种预知与有关验证者 IP 地址的信息相结合，可以进行特别令人讨厌的攻击，即有人可以故意关闭验证者的节点 — — 例如，通过拒绝服务 (DoS) 攻击 — — 并且下一个验证者可以窃取他们的奖励。
这种可能性已经有一段时间了 — — 事实上，它在 2020 年的几次以太坊安全审计中都提到了（这里有一个来自 Least Authority，另一个来自 Quantstamp）。但它通常被认为是低严重性。
然而，过去几个月在 HOPR 进行的研究，以及我们在伦敦帝国理工学院分散系统和安全小组的合作者的平行研究，使我们得出结论，风险要高得多，原因有以下三个：
- 进行这种攻击的动机比以前想象的要高得多
- 识别验证者 IP 比以前想象的要容易
- 攻击本身比以前想象的更容易进行，也更难缓解
让我们概述一下攻击的步骤，然后更详细地看看这三点。
验证者狙击 — — 基础
攻击的基本概要很简单：观察信标链网络足够长的时间以在验证者的公钥和他们的 IP 地址之间形成链接，然后当该验证者成为区块提议者时，通过 DoS 攻击使他们的机器离线。他们将无法完成他们的区块提议者职责，并且他们的位置将到期。该角色将传递给下一个验证者，后者将能够获得被狙击的验证者可以访问的所有 MEV 机会和交易费用。
但是您将如何获得进行攻击所需的公钥和 IP 地址信息呢？要理解，我们需要更深入地研究权益证明在 ETH2 和等效设置中的工作方式。
每个 epoch，随机选择一组验证器来提议块，每个验证器都可以验证 epoch 内的一个块。此验证过程在这些小组内进行，但每个步骤的确认（称为证明）在整个网络中广播。这一切都是公开发生的，运行验证器节点的唯一要求是您提供必要的质押。因此，任何人都可以付费访问所有这些数据。
当您运行验证器节点时，您将获得有关其他节点运行器的 IP 地址和公钥的信息。这个链接并不简单 — — 为了提高效率，证明通常捆绑在一起，节点不会连接到网络中的所有其他对等点，从而导致数据不完整和大量噪音。但我们将在下面展示如何以非常高的确定性将 IP 地址与公钥相关联。
一旦你建立了这个链接，剩下的就是等待一个合适的攻击机会。然后，您可以对目标验证器发起极具针对性的拒绝服务攻击 (DoS)。这与我们更熟悉的分布式拒绝服务 (DDoS) 攻击不同，它会导致主要服务中断数小时。它不需要那么激烈或长期存在：它只需要让目标机器停止运行足够长的时间，以至于它们无法履行其插槽职责。但是在这里可以获得什么，这些攻击机会多久发生一次？
正是在这里，以前的研究似乎误解了风险。
不匹配的激励措施
我们的评估是，当以前的研究人员和审计人员考虑这种攻击时，他们主要考虑的是造成混乱的动机：不分青红皂白地破坏链，或者通过阻止验证者履行验证职责来导致验证者被削减。
被忽略的是，MEV 的巨大增长为验证者相互攻击创造了直接的激励，无论是单独工作还是与专门的验证者狙击手合作，他们会寻找机会击落特定机器，就像 MEV 搜索者如何串联操作一样与矿工/验证者。
为了使攻击可行，必须同时发生三件事：
- 知道即将到来的区块提议者的 IP 地址
- 控制下一个插槽（因为您是该插槽中的验证者，或者您能够与他们合作）
- 内存池中有足够的 MEV 机会值得挖掘
我们的评估是，这不是千载难逢的情况。事实上，我们希望看到这种情况经常发生。这是因为：
- 找到具有高置信度的验证者 IP 地址被证明是相当微不足道的
- MEV 搜索者和矿工之间的合作频率表明，机会是巨大的，并且这些互动在 DeFi 领域几乎没有摩擦。尽管 DoS 促成的 MEV 攻击会比普通 MEV 更受欢迎，后者存在于道德灰色地带，但我们仍然希望类似的协作和服务能够迅速出现。
- 目前以太坊中的 MEV 机会非常频繁，没有理由认为切换到 ETH2 会显着改变这一点
将 IP 地址链接到公钥
人们早就知道，可以监视网络并在验证者的公钥和 IP 地址之间建立链接。但据我们所知，HOPR 是第一个真正尝试它的项目。接下来的部分将详细解释我们做了什么以及它是多么容易。
我们的设置
自 2022 年 4 月 21 日以来，全球 11 名 HOPR 团队成员一直在 Gnosis Beacon 链上运行验证器节点，使用我们在AVADO的优秀合作伙伴提供的硬件节点。他们自愿与我们的分析团队分享他们的 IP 地址和公钥，以便确认结果。请注意，除了验证结果外，分析过程中未使用 IP 地址。
另外，我们运行另一个节点，该节点经过轻微修改，以在所有连接的对等方广播证明时收集它们的 IP 地址，并使用Elastic Stack将其转储到 IP 和公钥的数据库中。节点修改相当简单，因为 Lighthouse 客户端促进了验证器监控作为标准。（当我们讨论改进这种数据收集的方法时，这个特性也很重要。）
这产生了很多数据。例如，在 6 月 1 日至 7 月 1 日期间，我们存储了 2,285,214,572 个 IP / 公钥对，它们可能与 1,253 个唯一 IP 地址相关联。
将公钥链接到 IP 地址
那么我们如何将这些海量数据转化为 IP 地址和公钥之间的可靠链接呢？请记住，仅仅因为我们的节点从特定 IP 地址接收到与公钥相关联的证明的信息，这并不意味着这是具有该公钥的验证节点的 IP 地址。这是因为一些节点聚合了证明，以便在整个网络中更快地传播。事实上，我们的节点甚至没有注册这些是聚合证明，而是以与单个证明相同的方式记录它们。
因此，我们的任务是克服所有这些噪音。
首先，我们选择一些公钥来尝试链接。对于这个实验，我们使用了我们已经从测试人员那里知道的公钥。了解此步骤是有效的至关重要，因为我们在任何时候都没有使用我们对 IP 地址的预知来建立链接。提前选择这些公钥的唯一原因是因为我们知道我们可以验证这些结果。我们同样可以选择随机公钥并一一处理，最终击中由 HOPR 团队控制的那些。
即使缩小到这 11 个公钥，它仍然是很多数据。从 4 月 21 日到 7 月 1 日，我们的节点收集了与 11 个 HOPR 公钥相关联的 431,639 对 IP 地址。在这段时间内，1613 个唯一 IP 地址与 11 个 HOPR 公钥相关联。但哪些是真实的？
首先要做的是将数据划分为离散的时间块。时间范围的选择是任意的，但我们选择了一天，因为这似乎会提供可管理的数据量。例如，如果您只查看过去 15 分钟的证明，我们可能无法连接到给定的 HOPR 节点。因此，您将没有任何信息可以将公钥与正确的 IP 地址相匹配。
下图显示了整个 6 月 HOPR Team GBC 节点的 IP 和 pub key 证明计数，证明按天分隔。
正如我们所看到的，我们的收获节点并没有平等地连接到所有 HOPR 节点。事实上，有些日子它几乎与他们中的任何一个人都没有联系。这是有道理的，因为一个节点无法始终连接到网络中的所有 1600 个节点，并且节点并不总是始终处于启动状态且可访问。
尽管如此，这足以提供强有力的联系。对于给定的日期和公钥，我们只是查看了哪个 IP 地址最常与来自该公钥的证明相关联。这确实是可能的最基本方法，但即便如此，我们发现在 62% 的情况下也产生了正确的配对。
但我们可以轻松地做得更好。这种方法无法解释这样一个事实，即我们的收获节点将不会直接连接到我们试图识别的节点。换句话说，它没有充分利用这样一个事实，即当给定的 HOPR 发布密钥与给定日期的正确 HOPR IP 相关联时，HOPR IP 在与该特定相关联的所有其他 IP 中产生最高的证明计数在 99% 的情况下，HOPR 发布密钥。
为了改进这一点，我们使用了一种重新加权的方法，我们重新加权第一种方法中给定 IP 的百分比份额，以及所有日子的相关证明总数。
本质上，加权降低给定 HOPR 节点未连接的天数，并将该权重转移到给定 HOPR 节点连接的天数。
这种方法将识别正确 IP 地址的概率从 62% 提高到 89%。它还将与每个节点关联的可能 IP 地址集减少到 1–3 个。
因此，建立从公钥到 IP 地址的可靠链接需要在相当长的时间内收集数据。但是多久？该图显示我们需要收集大约三周的原始证明来链接我们所有的 11 个节点。但这是因为我们已经有一组我们感兴趣的公钥来证明我们的概念证明。如果我们只是想找到任何公钥进行狙击，并且我们准备接受较低的确定性阈值，那么可能需要的时间会少很多。
还有各种其他技术可以大大减少这个时间，例如：
- 运行多个验证器节点
- 切断与已建立链接的节点的连接，以专注于未链接的节点
最后一个让我们回到上面提到的灯塔修改。您可以选择特定的验证器来连接或忽略，而不是不加选择地连接到节点。这通常用于诊断目的，以测试您控制的节点的健康状况，但这可以被破坏以促进攻击。
一个限制是数据集中有很多冗余。由于我们只对构建 IP 地址数据库感兴趣，而不是促进网络上的验证，因此从我们已经知道 IP / pubkey 链接的节点收集数据是没有意义的。因此，如果我们设置一个置信度阈值，超过该阈值我们很高兴链接已经建立，我们可以故意断开与这些验证器的连接，转而专注于当前未链接的节点。通过这种方式，我们可以更有效地构建整个网络的图像，更快地填充 IP 地址数据库。
攻击可行性
当然，一旦你有了 IP / pubkey 链接，你仍然需要进行攻击。这有多可行？这就是我们伦敦帝国理工学院 Arthur Gervaise 小组的研究合作伙伴目前正试图确定的。我们预计他们的研究将在未来几个月内发表，但我们已经可以进行一些评估。
首先，这不需要是大规模的攻击。目标机器只需要关闭一分钟左右，足以让插槽过期。
其次，客户端级别的解决方案在这里似乎没有多大帮助。从 2020 年开始，Teku 审计中提出了一些解决方案，但它们仅在攻击者试图超载节点而不是整台机器时才有效。
第三，近几个月来，我们已经看到更大规模的 DoS 攻击对加密货币产生了影响，但回报可能会更小。人们不借此机会进行更简单、不易察觉的攻击以获得更高回报，这似乎是不可想象的。
下一步
那么可以做些什么呢？
最明显的短期解决方案是手动保护您的 IP 地址。良好的 VPN 卫生当然很重要，但请注意，这可能不足以保护您。除了许多 VPN 商业模式让您面临其他隐私问题之外，VPN 根本无法提供足够的 IP 地址保护。举个例子，让我们回到之前的地理位置图：
我们不想doxx我们自己的团队成员，但我们只是说这张地图准确定位了节点的IP地址，而不是他们的物理位置……
因此，您需要相当快速地循环您的 IP 地址。有多快？这取决于建立 IP 链接的速度。我们的幼稚方法需要数周时间，但我们只是运行一个收获节点，几乎没有优化。合作者的估计表明，时间可以很容易地减少到 15 分钟，尤其是当您乐于接受对信心阈值的适度打击时。
显然，作为传输级隐私项目，我们将支持传输级隐私解决方案。通过像 HOPR 这样的混合网络发送的证明基本上每次都会显示不同的 IP 地址（中继链中倒数第二跳的 IP 地址）。证明也足够小，只需要一条 HOPR 消息，因此不应该有任何明显的延迟或数据包丢失。
该解决方案还将使验证成为家庭验证者的可行选择，我们认为这是去中心化未来的重要组成部分。我们很高兴看到我们在 Gnosis Chain 的朋友也有同感，他们经常拒绝复杂或资源密集型的解决方案，这会增加成为验证者的障碍。
但现实情况当然是应该在每一层采用各种解决方案。区块链是支撑我们在其上构建的一切的基本事实来源 — — 任何努力都不能保证其完整性和安全性。
负责任的披露
最后，关于负责任披露的说明。对我们最初的 Twitter 线程的最大批评之一是，我们应该通过用于严重错误和其他威胁的私人披露渠道不那么公开地发布这些信息。
虽然我们同意我们线程的初始基调不是最理想的，但我们不同意这是闭门造车的问题。这是众所周知的事情好几年了，没有迹象表明它被非常重视。目前没有资金处于风险之中，因此没有直接的危险信号会提升此信息。
这对每个人来说都是一个问题，尤其是验证者，我们认为每个人都参与到对话中至关重要。我们期待在未来几个月内与尽可能多的人在这个问题上进行合作。如果您想与我们联系，请使用以下链接之一。
作者：Sebastian Bürgel — HOPR 创始人
官网: https://www.hoprnet.org
推特: https://twitter.com/hoprnet
Telegram: https://t.me/HOPRChinese
Discord: https://discord.gg/dEAWC4G
领英: https://www.linkedin.com/company/hoprnet
论坛: https://forum.hoprnet.org
Github: https://github.org/hoprnet
扫码添加我们助手微信加入微信群👇
