Ξ

    Search by
    ETH  $
    Loading...
    Loading...
     Gas: 
    Loading...
             Epoch / Slot :
    Loading...
           活跃验证者 :
    Loading...

    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+1n+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进行授权。