Ξ

    Search by

    HF1 提案

    信标链首次硬分叉 HF1 的详细提案

    VB

    Vitalik Buterin       2021-02-19

    来源 | notes.ethereum.org/@vbuterin


    HF1 为信标链首次硬分叉的暂时代码名称 (点进链接参与协议升级永久命名的讨论)，这次升级的主要目标为：

    1. 增加轻客户端支持

    2. 修复一些信标链上的漏洞，这些漏洞发现时间比较晚，来不及在创世前修复

    3. 在需要进行较大的更新 (分片、合并) 之前，先在相对较小的更新中对硬分叉机制进行测试


    HF1提议的共识改变

    同步委员会

    我们在信标链上添加了随机取样的 “同步委员会”。这样做的目的是让轻客户端以较低的开销 (每天至少需要约20KB来保持，需要约500个字节来确定单个区块) 来确定信标链头。这将使得轻客户端实际上可用于移动设备、信标链 之类的浏览器内的应用案例 (以及合并后的整个以太坊)，从而为更加去信任的钱包生态打好基础。

    在每个时间段（约27小时）内，随机选择 1024 位验证者作为同步委员会的成员。同步委员会中的验证者将发布证明当前链头的签名。这些签名将作为 LightClientUpdate 对象的一部分被广播至区块链，这可以帮助轻客户端找到链头；并且签名会被打包进链，验证者会分得奖励。

    主要PR：

    核算改革 (第一层)

    给验证者的奖励不再通过计算得出。此前，我们的方法为存储 PendingAttestation 对象然后在最后对它们进行处理。而现在我们添加了一个位字段以存储每个验证者的状态，从而可以实时收集参与数据。位字段按照“混洗”的方法进行排序，以确保同一个委员会的验证者的记录同时显示。这一改变的目的是简化客户端实现，并使得更新默克尔树的成本更低。

    主要PR：

    核算改革 (第二层)

    我们每64个epochs更新一次验证者集并进行一次惩罚核算，而不再每个epoch都计算一次。这样做是为了极大地降低处理“空时段过渡 (empty epoch transitions)”的复杂性——比如，在一条参与率非常低的链中，两个相继的区块之间隔了一千个slot，其间仅有空块。目前为了处理这样的链，客户端们将需要每个epoch重新计算一次验证者的余额以对验证者执行怠工惩罚。而这项提案应用之后，客户端仅需要每隔64个epoch核算一次。

    此外，我们对怠工惩罚 (inactivity leaks) 增加了两项变动：

    每个验证者的怠工惩罚力度降低至1/4。也就是说，如果链上出现怠工惩罚，当一个完全离线的验证者损失其余额的大约10%的数额时，在此期间另一个90%都在线的验证者仅损失其余额的大约0.1% (而不是~1%)。这样做是为了加大对作恶节点的惩罚力度，对那些仅仅由于网络连接不佳而掉线的验证者则降低惩罚力度。点进链接查看更多的讨论。

    • 区块敲定后怠工惩罚会逐渐减少，而不会停止。即区块被敲定后，离线节点的余额将持续减少，这样确保了参与率显著高于2/3，而不是刚刚超过阈值。点进链接查看更多的讨论 (不过请注意与此处略有不同)。

    主要PRs：

    惩罚常数调整

    很庆幸，尽管我们还没有完全解决验证者惩罚的问题，但在某种程度上已经摆脱了困境。我们会改变以下常数：

    • INACTIVITY_PENALTY_QUOTIENT: 从 2**26 (= 67,108,864) 减少至 3 * 2**24 (= 50,331,648)

    • PROPORTIONAL_SLASHING_MULTIPLIER: 从 1 提高至 2

    • MIN_SLASHING_PENALTY_QUOTIENT: 从 2**7 (= 128) 减少至 2**6 (= 64)


    提议的分叉选择变更（大概）与HF1同步部署

    通过 (block, slot)对来做分叉选择

    目前，如果在最近的slot里没有区块发布，那么出于LMD GHOST证明的目的，该slot里面的证明会被算作支持证明者所支持的最近区块。例如，在下图，空白 (BLANK) 区块的证明也会算入 A 的证明里。

    p

    但是，这容易招致34%攻击。如果有m名验证者被分配到每个slot，那么一个恶意攻击者就可以控制每个slot的0.34 * m。攻击是这样进行的：攻击者不发布B，且不发布任何他们的证明。所有的诚实证明者对他们在slot n看到A、在slot n+1什么都没看到的声明进行投票，在slot n+2，诚实提议者会在区块 A上生成区块 C，而诚实的验证者们会支持C。此时，恶意提议者发布B并对slot n+1 和 n+2做证明。这样，底部分叉有0.68 * m的验证者支持它，而顶部分叉只有0.66 * m的验证者支持，由此底部分叉胜出。

    这样的攻击在此论文的 3.1部分有详细描述： https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf

    提议的修复方案是改变分叉选择的运作方式——让分叉选择在 (block, slot) 对的树上操作，而不是在区块树上。因此，在slot n+1的诚实投票会算作在上图对 (BLANK, n+1)的投票，也就是会被正确算作支持顶部分叉，那么顶部分叉的支持率会变成1.32 * m，由此能够打败攻击。

    主要PR:

    分叉选择对称攻击修复

    分叉选择还存在“对称攻击(balance attack)”，攻击是这样形成的：有2%的验证者在一个slot结束之前发布少量证明，让大于49%的网络的人认为区块A胜出，让大于49%的网络的人认为区块B胜出。如果他们对广播计时准确，针对每组人群的信息会及时到达，且在slot的边界时间结束前不够时间重新广播信息到其他组。如果网络环境对攻击者而言是最理想的话，这样的攻击他们可以无限重复。

    提议的修复方案是通过赋予下一个slot的提议者暂时但重要的分叉选择权来“打破对称” ，他们能决定所有验证者在分叉的哪一边。

    重要的文档:



    网页版声明：ECN的翻译工作旨在为中国以太坊社区传递优质资讯和学习资源，文章版权归原作者所有，转载须注明原文出处以及ethereum.cn，若需长期转载，请联系eth@ecn.co进行授权。
    Ethereum Community Network
    以太坊社区网络
    Ethereum Community Network
    以太坊社区网络