译者：洒脱喜
注：原文作者是以太坊联合创始人Vitalik Buterin，在这篇文章中，他提出了一种称为及时性检测器（TD）的构造，以试图解决区块链51%攻击的问题。
摘要
我提出了一种基于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个签名的及时区块，则有两种可能：
这k个签名当中，有一个是诚实的；
这k个签名当中，没有一个是诚实的；
在情况（1）中，我们知道该证明者是诚实的，因此证明者在时间T+(2j−1)δ之前广播了带有 j ≤k 个签名的区块B，这意味着（通过同步假设）每个客户端在时间T+2jδ之前都看到了该bundle，所以每个客户端都接受区块B作为当前区块。
而在情况（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），option 1 （少数离线）：
情况（ii），option 2 （离线多数，稍后以最终确定的链重新出现）：
因此，在所有情况下，至少过了某个时间点（T+2kδ，在该时间点之后，如果客户端没有及时接受一个区块，那么我们知道它永远不会及时接受它）后，我们都可以防止51%攻击破坏最终性。还要注意，上面的图有点误导性。我们关心的不是完成区块的时间线，而是区块的及时性，其中包括证明该区块已最终确定的证据。
对于有时会离线的客户端而言，只要没有51%攻击，这不会改变任何事情：如果链没有受到攻击，那么规范链中的区块将是及时的，因此最终确定的区块将始终是及时的。
而可能导致风险增加的主要情况是，客户端具有高延迟，却没有意识到它们具有高延迟。它们可能会把及时区块视为非及时区块，或者把非及时区块视为及时区块。该机制的目标是，如果非及时性依赖分叉选择和及时性依赖分叉选择是不一致的，就应该通知用户，以便他们能够验证正在发生的事情。不应指示他们盲目接受依赖及时性分叉选择作为规范。
在处理审查问题时，我们还可以使用及时性检测器来自动检测和阻止审查。这很简单：如果具有自声明时间t的区块B是及时的，那么在时间t+(2k+2)δ之前不包含该区块的任何链（无论是作为祖先区块还是作为叔块）都会自动被判定为非规范链。这确保审查区块超过（2k+2）δ的链将被客户端自动拒绝。
在这里使用及时性检测器（TD）的主要好处是，它可以在审查“过多”的情况下形成共识，避免“边缘攻击”的风险，这些“边缘攻击”被故意设计成对某些用户（而非其他用户）而言是足够糟糕的，从而导致社区浪费时间和精力来争论是否分叉审查链（相反，大多数用户在任何情况下都会同意正确的行动方案）。
注意，这需要一个叔块包含机制，而当前以太坊2.0是没有的。此外，它还需要一种机制来执行叔块内部的交易，这样审查阻力就能扩展到交易，而不仅仅是区块的原始体。这需要和无状态客户端很好地协作。
另一个问题是，需要小心处理许多区块被发布并获得及时性状态的可能性。这可能是由于发布延迟，或者是由于一个提议者恶意地在同一slot中发布多个区块造成的。前者可以通过修改的规则处理，其中区块必须包括所有时间早于（2k＋2）δ的及时区块或最大允许数（例如4）叔块。
而后者可以通过这样一个规则处理：如果包括来自特定slot的一个区块，则可以有效地忽略来自该slot的所有其他区块。
请注意，在Casper-CBC框架中，对包含非及时性或审查性区块的链进行审查预防和取消优先级操作，足以提供与上述FFG框架相同的终局性保证。
面临的挑战及任务
想出最好的方式，用非技术的语言向用户解释，在及时性意识和非及时性意识分叉选择规则不一致的情况下发生了什么，以及他们应该如何应对这种情况；
分析系统在延迟有时高于δ，或延迟总是潜在高于δ情况下，且我们有假设（例如，某些固定部分的证明者是诚实的，或其他混合假设）下的行为。查看是否有方法修改规则以提高这些场景中的性能；
分析实现这些属性，同时不需要包括新证明的方法，相反，只需要重用现有证明（例如，验证者证明FFG中的每个epoch的证明）；
确定是否对基于“简单”最长链分叉选择规则进行了一些小的修改，使它们能够从及时性检测器中获益，从而获得某种终局性。
微信扫一扫 
