V神原文详解：通过及时性检测器解决区块链的51%攻击问题

注：原文作者是以太坊联合创始人Vitalik Buterin，在这篇文章中，他提出了一种称为及时性检测器（TD）的构造，以试图解决51%攻击的问题。

（图：Vitalik Buterin）

摘要

我提出了一种基于Lamport 99% 容错共识的构造，并称之为及时性检测器（timeliness detectors）。及时性检测器（TD）允许在线客户端（即连接到其它延迟≤δ客户端的客户端，又称用户）在保证正确性和一致性的情况下，检测区块是否是“准时”发布的。

在发生51%攻击的情况下，这允许至少一部分在线客户端就（i）是否发生了“足够糟糕”的51%攻击达成一致，以及确定（ii）什么是“正确”的链，甚至有可能（iii）确定哪些验证者要对攻击负责。这降低了51%攻击造成混乱的能力，加快了从攻击中恢复的时间，同时也潜在地增加了成功攻击的成本。

及时性检测器（TD）

及时性检测器最基本的结构如下。对于客户端收到的每个数据块，客户端都会维护一个“是否是及时”的依据，它会说明客户端是否认为区块是“准时”收到的。其目的是在51%攻击中尝试区分攻击链和“正确”链：

我们的模型很简单：每个区块B都有一个自我声明的时间戳 t （在实际的协议中，时间戳通常是隐性的，例如以slot数显示）。然后有一个共同商定的同步约束δ。最简单的时间检测器是：如果你在时间t+δ之前接收到区块B，那么你认为该区块就是及时的，如果你在时间t+δ之后收到它，那你就不会认为它是及时的。但这并不能达成一致：

我们通过下面的方式解决这个问题。对于每个区块，我们随机选择N个“证明者”样本（v1...vn）。每个证明者都遵循以下规则：如果他们看到一个带有时间戳t的区块B在时间t+（2k+1)δ之前有来自k个证明者的签名，他们就用自己的签名进行重新广播。而客户端遵循的规则则是：如果它们在时间t+2kδ之前看到一个带有时间戳t的区块B，以及来自k个证明者的签名，那么它们会及时接受它。如果它们看到区块B，但它永远不满足这个条件，则客户端就认为区块B是不及时的。

让我们看看，当只有一个客户端认为某个区块B是及时的，但其它客户端最初可能因为延迟差异，而不认为它是及时时，会发生什么。我们首先假设有一个诚实的证明者。

这张图展示了所发生事情背后的基本原理。如果客户端在截止时间T之前看到一个区块，那么该区块将在证明者截止时间T+δ之前落入证明者的手中，并且证明者将添加他们的签名，并且他们将在时间T+δ之前重新广播它，保证其他节点在T+2δ前看到有签名的区块。关键的机制是一个附加签名以延迟截止时间的能力。

现在，让我们考虑n−1个非诚实证明者以及1个诚实证明者的情况。如果客户端看到一个带有k个签名的及时区块，则有两种可能：

而在情况（2）中，我们知道诚实的证明者将在时间T+（2k+1）δ之前看到该bundle，因此它们将用自己的签名重新广播该它，并且所有其它客户端将在k+1签名截止时间T+（2k+2）δ之前看到该扩展bundle。

因此，现在我们有了一个“及时性检测器”，客户端可以使用它来跟踪哪些区块是“准时”的，哪些区块是“不准时”的，以及在什么时候，所有延迟小于δ的客户端都会同意哪些区块是准时的。

最简单的区块链架构

为了决定谁可以提出提议，谁可以在任何slot证明区块的目标。我们可以这样定义一个“99%容错区块链”：要确定当前状态，只需按照它们自己声明的时间戳顺序处理所有及时的区块。

这实际上是可行的（并且提供了对最终性逆转和审查51%攻击的抵抗），并且在它自己的假设下给出了一个相当简单的区块链架构！唯一的问题是：一切都建立在假设所有客户端都将在线，并且网络永远不会被中断的基础上。因此，要使其安全地工作，可能需要一周或更长的区块时间，而这实际上是一个“辅助链”的合理架构，它可以跟踪验证者的存款、提款以及罚没情况，例如，（通过审查新加入的验证者等）来防止长期的51%攻击。但我们不希望把这种架构应用到主链。

更合理的选择

然而，在这篇文章中，我们将重点关注满足一组较弱安全性假设的系统架构。即如果以下两个假设中的任何一个是真的，那么它们就是好的：（i）网络延迟很低，包括验证者和客户端之间的网络延迟，以及（ii）大多数验证者是诚实的。首先，让我们回到一个模型，在这个模型中，我们有带有一些分叉选择规则的区块链，而不仅仅是离散的区块。我们将通过我们最喜欢的两个终局性分叉选择规则例子，（i）FFG和 (ii) LMD GHOST。

对于FFG，我们将该分叉选择规则扩展如下。从创始区块开始，每当你看到两个子链都已完成的区块时，请选择lower-epoch及时完成区块的链。然后从那开始继续按以前的方式前进。一般来说，在两种情况下，只会有两个冲突的最终链：（i）33%的攻击，以及（ii）许多节点离线（或审查）导致长期运行的inactivity leak。

情况（i）：

情况（ii），option1 （少数离线）：

情况（ii），option2 （离线多数，稍后以最终确定的链重新出现）：

因此，在所有情况下，至少过了某个时间点（T+2kδ，在该时间点之后，如果客户端没有及时接受一个区块，那么我们知道它永远不会及时接受它）后，我们都可以防止51%攻击破坏最终性。还要注意，上面的图有点误导性。我们关心的不是完成区块的时间线，而是区块的及时性，其中包括证明该区块已最终确定的证据。

对于有时会离线的客户端而言，只要没有51%攻击，这不会改变任何事情：如果链没有受到攻击，那么规范链中的区块将是及时的，因此最终确定的区块将始终是及时的。

而可能导致风险增加的主要情况是，客户端具有高延迟，却没有意识到它们具有高延迟。它们可能会把及时区块视为非及时区块，或者把非及时区块视为及时区块。该机制的目标是，如果非及时性依赖分叉选择和及时性依赖分叉选择是不一致的，就应该通知用户，以便他们能够验证正在发生的事情。不应指示他们盲目接受依赖及时性分叉选择作为规范。

在处理审查问题时，我们还可以使用及时性检测器来自动检测和阻止审查。这很简单：如果具有自声明时间t的区块B是及时的，那么在时间t+(2k+2)δ之前不包含该区块的任何链（无论是作为祖先区块还是作为叔块）都会自动被判定为非规范链。这确保审查区块超过（2k+2）δ的链将被客户端自动拒绝。

在这里使用及时性检测器（TD）的主要好处是，它可以在审查“过多”的情况下形成共识，避免“边缘攻击”的风险，这些“边缘攻击”被故意设计成对某些用户（而非其他用户）而言是足够糟糕的，从而导致社区浪费时间和精力来争论是否分叉审查链（相反，大多数用户在任何情况下都会同意正确的行动方案）。

注意，这需要一个叔块包含机制，而当前以太坊2.0是没有的。此外，它还需要一种机制来执行叔块内部的交易，这样审查阻力就能扩展到交易，而不仅仅是区块的原始体。这需要和无状态客户端很好地协作。

另一个问题是，需要小心处理许多区块被发布并获得及时性状态的可能性。这可能是由于发布延迟，或者是由于一个提议者恶意地在同一slot中发布多个区块造成的。前者可以通过修改的规则处理，其中区块必须包括所有时间早于（2k＋2）δ的及时区块或最大允许数（例如4）叔块。

而后者可以通过这样一个规则处理：如果包括来自特定slot的一个区块，则可以有效地忽略来自该slot的所有其他区块。

请注意，在Casper-CBC框架中，对包含非及时性或审查性区块的链进行审查预防和取消优先级操作，足以提供与上述FFG框架相同的终局性保证。

面临的挑战及任务