以太坊2.0测试网分为4个分支

目前，在以太坊2.0测试网（如图）中出现了四到五个主要分支之后，出现了导致Prysm节点和整个网络瘫痪的错误。

“我们需要让所有客户就目前的问题达成共识。 这也导致与加入的同伴声称对链的不同观点产生同步破坏。 “我们将在本周内部署thorughout来解决所有这些问题。”

“它到处跳来跳去……好像无法决定，”运行prysm客户的人与prysm开发人员Nishant Das说，“是的，有很多重组。”

“现在发生了许多不同的派生，并且某些节点被卡在很远的后面，因此您可以得到所有这些父块请求来尝试解决它，但是主要的请求当前显示在eth2stats上，这在灯塔和prysm之间达成了共识，”另一个prysm开发人员Raul Jordan说。

由于所有这些分叉，今天伦敦时间午夜左右，对内存的需求猛增，达到70或80 GB。

“最有效的数据库压缩技术是在确定性之后发生的，” Lighthouse的Paul Hauner说。 “我们还看到了数据库中的一些问题，这些问题阻止了修剪，但我不确定这在这里是否起作用。”

从大约12个小时前开始，情况似乎已经有了明显改善，更多的人到达了连锁店的顶端。

要求节点运行程序仅在允许的情况下运行它，而不要重新启动，因为那样会丢失到该点为止的所有同步。 也：

“我正在使用–block-batch-limit = 512和–p2p-max-peers = 200似乎很麻烦，”节点运行器说。

max peer参数不是开发人员推荐的一部分，但块批处理限制是，Das指出：

“因此，当您遇到困难时，它会循环遍历您的同伴以尝试解除粘滞，使用较大的批次将更快地在这些同行中循环。”

许多人说他们在请求父块方面遇到一些错误。 他们被要求忽略它，因为节点正在遍历所有分支，而Preston Van Loon发布了网络树。

显然，您可以通过转到localhost：8080 / tree来获得此树，这种树可以让您查看链的运行方式。

正如您可能期望的那样，这最初显示一个链条运行良好，然后我们有两个，并且它们都有自己的链条，所有这些链条最终又随着一个链条再次运行而下降。

以太坊2.0测试网常规链，2020年8月

新节点显然只需要进行同步，它们需要了解这些分叉，然后将新分叉与该节点放下，然后跳转到有效的尖端。

显然，这需要达到66％的参与率，而那些下降的参与者将被削减到那时：

以太坊2.0测试网节点运行程序被削减。

这个以太坊人很好地赚了很多钱，方法是在打开节点设置后什么也不做。

而且，即使在大刀阔斧之后，他仍然可以获利，但是您可以看到上升的速度比下降的速度慢很多。 他白天赚钱，现在每小时亏损。

这意味着当他和其他人越早达到连锁秘诀时，他就有很大的动机重新回到同步状态，他越快回到赚钱而不是亏损的状态。

开发人员正在竭尽全力在途中帮助他，尝试各种技巧和修复，同时还为任何需要帮助的人提供帮助。

一些人自豪地宣布他们到达了尖端，随着下降的节点越多，可以同步到其上的节点就越多，而现在下降的通道可能产生多米诺骨牌效应。

卢恩（Loon）说：“梅德拉（Medalla）远未死，可以修复。”而且必须修复，因为这也有可能实时发生。

例如，在升级过程中的一些错误导致矿工使用不同的版本后，比特币在主网上的链分裂叉两次或更多次。

然而，在此期间，比特币网络一直在运行，导致社交媒体公告告诉人们等待100次或更多次确认。

如果这里有34％的问题被取消，则网络将停止运行，直到它们恢复正常为止。

这是一个发展中的故事，因此，由于链条当前尚未最终确定，因此尚未找到新的插槽/块，因此尚不清楚它们如何正确运行。

尽管认真学习了很多经验教训，例如拥有某种可以快速将密钥导出到其他客户端的方法，但所有这些都使我们对漏洞在发生时可能发生的实时事件进行了演练。 一个prysm开发人员说：

“拥有多个客户的全部目的是，如果主客户无法正常工作，您可以切换到其他客户。

昨天我们遇到了困难时期的问题时，最好是改用另一位客户以避免生命损失。”

粗糙时间是一种声称的去中心化时间同步方式，由于六个不同的时间源，由于某种原因，它使得去中心化节点向前跳了四个小时，从而导致错误并因此导致网络崩溃，因此并不是很分散。 达斯说：

“进入的到达块还具有一个插槽号，通过它我们可以确定其是否有效。 基本上是genesis_time + slot_Num * slot_time。

如果某个节点认为它距离未来4小时，则拒绝该块，因为它似乎来自过去。

这也使prysm的验证程序阻止提案感到混乱，因为现在根据验证程序的本地时钟提前了4个小时。”

解决这个问题的方法很简单，就是不默认使用粗糙时间，因此导致了测试网络上有趣的发展，这与虚假的eth有关，因此没有丢失任何东西，并且获得了很多收益。

此外，如果网络确实通过启用的编码机制恢复了活力，那么这不应延迟实时启动，因为一切都会发生，因为它的发生本身就是错误，因为错误本身很小，假定没有与代码相关的复杂性以及启动机制。

注释

—-

原文链接：https://www.trustnodes.com/2020/08/16/ethereum-2-0-testnet-breaks-into-4-forks

原文作者：Trustnodes

编译者/作者：wanbizu AI

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。