Vitalik Buterin：以太坊PoS算法的动态验证节点问题

在传统的共识算法中，不论他们是同步，还是部分异步或是完全异步的网络模型，又或者他们是通过简单容错，拜占庭容错或者责任容错的方式来设计，通常来说在一个协议中的模型包含固定的参与者，至少有些部分是严格按照协议施行的。

但是在权益证明中，验证节点可以存在和消失，甚至验证节点的绝对数量也会随着时间而增加或者缩小。这一次设定的80%验证节点也许会比另一次设定的20%验证节点要少，那么什么是固定模型就显得很模棱两可，那么在动态模型中，也许不应该有这种情况发生。那么我们应该怎么办呢？

第一个需要解决的问题是同步的权益证明，也就是说，传统的链状权益并且不包含最终结果。使用这类算法的包括点点币，NXT类型的算法，DPOS，在Manuve白皮书中提到的首个算法，还有目前在运行的其他项目。这里的问题很简单，因为不可能达到或者维持“经济计算结果”；反而，目标很简单，就是创建正反馈的机制，可以激励验证节点可以在有分叉的情况下，确定主要的区块，并且随着时间加强这条主链上区块的权威。

如果是固定的验证节点设置，分叉的规律很简单：最长的链胜出。但是，如果验证节点的设置是动态呢？那么，我们需要避免的攻击如下。

假设一条链将1000万ETH作为权益，但是其中有450,000（4.5%）被攻击者控制。现在，假设攻击者开始从某个区块开始维护他们自己的私有链。他们不允许新的验证节点进入他们的链，虽然他们确实包含了转账撤回的选项。随着时间推移，最后这条链上唯一的权益抵押就只有攻击者，也许会有一些例外。尽管这条链有少了很多的ETH权益抵押，但是看起来却高质量很多，因为区块生产者会在90%的时间出现，但是在主链上的区块生产者很显然是用户，并且会更加经常离线。因此，简单的最长链模型也会进入这类攻击。

为了解决这个问题，我们使用在工作量证明中同样的方法：我们不只是寻找最长的链，而是最长的，困难权重最大的链，在这种情况下，困难度等于在某个时刻权益抵押的ETH数量。

验证节点设置现在可以随意进出，甚至在随着每个区块进行完全地改变。不论这些节点设置发生了什么，经济环境仍然是同样运行，为最有可能获胜的结果创造激励，拥有越多ETH的链会比拥有更少ETH的胜出。

为什么上述案例是相对简单的原因是权益证明的结构会独立地对每个信息进行评估，并且惩罚错误，因此即使参与者的身份每毫秒交换一次，经济模式也不会改变，因为不论他们的历史情况如何，每个人都有相同的激励。以太坊最近的Casper设计，在另一方面，会惩罚这种含糊其辞的情况，也就是说验证节点发送两条互相冲突的信息。

在这个模型中，验证节点设置改变的情况很难处理，因为安全认证是在你假设验证节点设置是不变的，但是实际情况是变化的。

一种可能性是简单粗暴地让节点设置每次只能改变少于1%，因此来保证你可以维持一些程度的安全，只要每33个周期中有1个新的区块可以完成。这实际上是可以的。但是这个方案却不是让人很满意，并且我们可以在更完整分析这个问题后得出更好的结论。

也许有人会本能地想起另一个想法“为了维持可持续性，我们可以等验证节点A来确认验证节点B，然后让验证节点B从那儿开始。”为了想明白这些是怎么运作的，想想以下的算法：

每个区块必须要包含下个区块验证节点的哈希值。

对于将要有效的区块，它必须指出一个有效的母区块，并且证明（例如，有足够多的相同序列号的COMMIT）母区块已经完成。也就是说，每个区块都必须要完成。

这里要注意区块之间发生的共识，也就是说，会有“产生区块1，完成区块1，产生区块2，完成区块2。。。”这样的顺序，不想我们其他的算法，甚至在之前区块共识完成之前新的区块也会在生成。在这种情况下为了出现分叉，就需要在某个区块高度，区块发生分散，所以我们可以使用我们的安全认证方法来展示在这个区块高度的1/3验证节点可以削减。

但是，如果我们尝试将这个应用到“交织共识”模型中，产生新区块和完成旧区块可以同时完成，这也是Casper最新版中的案例，但是有一个挑战。因为并不是100%确定共识会在每一个周期都达成，我们不能简单地让在第N轮的区块成为第N+1轮的验证节点；如果第N轮没有最终完成，那么N轮就会有2个竞争的候选人，你会遇到通过两个不相连的验证节点完成2个有冲突的链。

那么如果我们通过使用第N*50轮来确定地（N+1）*50轮的验证节点，来解决这个问题，并且希望每50轮你总是完成至少一次。但是，这也会有问题：

所以如果我们想要交织共识，我们还需要做什么？首先，需要注意状态转移功能其实是有关于是否给定区块有无完成的部分信息：如果一个区块已经完成，那么证据就可以及时上传到链上，或许也不会，但是如果一个区块没有完成，那么这个证据就绝对不会被上传。我们可以将这个“是或者可能”的预言是完成。

让我们来利用这个特性。如果预言机说可能，我们就不改变验证节点设置；如果它说是的，那么我们就进行改变。

不幸地是，事情没有这么简单。

这里的问题在于我们不能立刻对是否有共识这件事情达成共识，所以某人可以通过两组不同的验证节点设置来生成母子区块。

所以从这我们就可以得到我们的解决方案。我们会保留以上的结构，但是我们将增加条款，每个区块都必须同时被之前的和新的认证节点完成。也就是说，在任何情况下，我们之前会需要从2/3活跃的验证节点中获得某种类型的信息，现在，我们需要从旧的验证器集合的大约2/3和新的验证程序集的2/3中得到这个消息。

现在，让我们看看如果对于给定区块是否完成有争议的情况。

证明这个可行很容易。给定任何母区块，子区块只可以拥有两种可能的验证节点：由母区块本身的验证节点，还有母区块加入的为那个区块服务的验证节点。如果有2个子区块，并且都完成了，那么母区块中的1/3验证节点都会被削减。如果其中有子区块没有完成，那么任何子区块中的验证节点都不会改变，因此证明逻辑就转移到任何确实完成验证的衍生链。

我们如何才能将这个和其他共识机制结合呢，包括之前说过的各种共识和分叉选择机制？以上所说的机制在任何链上有检验的模型中都可以运行，不论检验是否互相直接跟从，或者之间是否有区块。所以的问题在于，给定一个检查点，如果这个检查点完成了检验，那么它可以创造子检查点，反映出已经完成或者没有完成。

对于分叉选择原则，我们不通过计算单个验证节点，而是选择之前验证节点的最少commit以及更新验证节点的commit。这就是我们需要的所有资源。