“以太网创始人God V在推特上介绍了以太网信标链第一个硬叉(暂定名为“HF1”)的升级方案。”以太网创始人God V在推特上介绍了以太网信标链第一个硬叉(暂定名为“HF1”)的升级方案。按照V神的说法，HF1增加了轻客户端支持，简化了规范，提高了效率，引入了惩罚力度较小的不活跃惩罚机制。根据文件，硬叉将使开发者能够对最近发布的信标链进行一些关键升级，这也将是对未来进行更深入更改的一个有用的测试。其中，轻量级客户端支持需要资源最少、可以在移动设备上运行的节点。这将允许“最小化信任钱包”验证区块链本身，而不是依赖外部服务提供商。“HF1是Ethereum信标链第一次硬叉升级的暂定代号(这个硬叉的长期命名思路见此处)。HF1的主要目标是：

添加轻量级客户端支持

修正信标链中的一些弱点。这些漏洞发现得太晚，在创建信标链时无法修复。

在小改动升级环境下测试信标链的硬叉升级机制，以便以后做更大的改动。

HF1中提议的一致变更包括：

同步委员会

我们向信标链添加了随机选择的“同步委员会”。这样做的目的是允许轻型客户端使用非常少的开销(每天至少大约20千字节，并且只有大约500字节来验证单个块)来确定链头。这将使轻量级客户端能够在移动设备和内置浏览器等用例中实际使用信标链，从而为信任最小化的钱包生态系统铺平道路。

在每个时间段(大约27小时)，随机选择1024个验证者作为同步委员会的成员。同步委员会中的验证者节点将向当前负责人发出签名证明。这些签名将作为LightClientUpdate对象的一部分进行广播，这可以帮助LightClientUpdate找到这个头，并将被包含在信标链中以获得奖励。

更多内容：https://github.com/ethereum/eth2.0-specs/pull/2130

记账改革（第一级）

我们替换了奖状奖励的计算方法。我们选择添加一个位字段来存储每个验证者的状态，这样我们就可以实时积累关于谁参与的数据，而不是存储挂起的测试站对象并最终处理它们。这些字段按照“重组顺序”进行排序，以确保同一委员会中验证者的记录一起显示。此更改的目的是简化客户端实现，并使更新Merkle树更便宜。

具体参考：https://github.com/ethereum/eth2.0-specs/pull/2176

记账改革（第二级）

，我们改变了验证器集，惩罚计算每64个周期只发生一次，而不是每一个周期。这样做的目的是大大降低处理“空白期过渡”的复杂度。比如有一个参与度很低的链，其中两个连续的块相隔一千个槽，它们之间只有一个空白期。为了应对这样的链条，客户端需要每周期重新计算一次每个验证者的余额，以惩罚验证者的不作为；在新的提案中，他们只需要每64个周期执行一次。

此外，我们对不作为惩罚的工作方法做了两个改变：

对于每个验证者，不活动惩罚将变成二次的。也就是说，如果有不活动的惩罚，在此期间完全离线的验证者将损失大约10%的余额，而在此期间90%时间在线的验证者现在将仅损失大约0.1%的余额(相对于1%)。这试图将惩罚集中在真正行为不端的节点上，并减少由于网络连接问题而离线的诚实节点。

更多的讨论可以在这里找到：https://github.com/ethereum/eth2.0-specs/issues/2098

验证者的不活动惩罚在确定后逐渐减缓，而不是停止。这保证了一旦达到最终状态，离线节点会持续失去平衡一段时间，从而保证验证者的在线时间百分比显著高于2/3，而不是仅仅略高于阈值。

具体参考：https://github.com/ethereum/eth2.0-specs/pull/2192

https://github.com/ethereum/eth2.0-specs/pull/2194

值得庆祝的一件事是，通过削弱验证者的罚款，我们可能会稍微走出困境(尽管不是完全)。我们将改变常数：

不活动_惩罚_配额ENT:从2**26 (=67，108，864)减少到3 * 2**24 (=50，331，648)

比例_斜线_乘数：从1增加到2

ENT:从2**7 (=128)降到2**6 (=64)

与HF1（接近）同时部署的分叉选择更改

(槽)对的分叉选择

目前，如果在最新的槽中没有块被发布，则它将被认为是证明者支持的链中的最新块，用于槽期间的LMD GHOST证明。例如，在下图中，BLANK上的校样被视为a上的校样：

然而，这为34%的攻击打开了大门。假设每个槽分配m个校验器，恶意攻击者控制0.34 * m，攻击者也有权利为槽n ^ 1发布块b。攻击过程如下：攻击者不发布B，也不发布它的任何证明。所有诚实的证人都会投票支持他们在第n个槽中看到A块而在第n个槽中什么也没看到的说法。目前这个计数被认为是对a的投票，在第n个槽中，一个诚实的提议者会在a上构建一个C块，此时恶意的提议者会向槽n ^ 1和n ^ 2宣布B及其证明。上叉有0.68 * m的验证器支持，上叉只有0.66 * m的支持，下叉胜出。

这篇文章的第3.1章更详细地描述了这次攻击：https://econcs.pku.edu.cn/wine2020/wine2020/workshop/gtib20 _纸_ paper。

提出的解决方案是改变分叉选择的工作模式，使其在(槽)对树而不是块树上运行。所以在上图中，槽n ^ 1中的诚实票会被计为(BLANK，n ^ 1)的票，所以会被正确地计为支持上述分叉，所以上述分叉得到1.32 * m的支持，从而战胜了攻击。

更多内容：https://github.com/ethereum/eth2.0-specs/pull/2197

修复分叉选择余额攻击

，分叉选择有“平衡攻击”。2%验证者的攻击者会在一个槽结束前的正确时间发出少量的证明，让网络中超过49%的人相信某个块A赢了，而超过49%的网络认为块B赢了。如果他们正确地安排了广播时间，每组验证者将准时看到他们的消息，但是在这个时隙结束之前没有时间向另一组验证者广播消息。如果网络环境对攻击者来说是最好的，那么可以无限重复。

提出的解决方案是通过授权下一个槽的支持者对分叉选择产生暂时但显著的影响来“打破对称性”，从而决定性地将所有验证者的支持方向转移到一边或另一边。

更多内容：https://notes.ethereum.org/@vbuterin/lmd_ghost_mitigation