-图片来自 Blair Fraser-
一个星期以前（注：本文撰写于 2019 年 12 月 17 日），我们宣布使用 Lighthouse 客户端启动一个大型的公开测试网。测试网成功启动并且运行了一周，首次证明了使用生产环境配置的 Eth2 测试网也是可以跑起来的。
启动测试网时，我们曾说，“我们要尝试把这个测试网搞崩，而且我有自信我们能够成功”。测试网确实挂了，而且是两次。第一次是在周六上午，第二次是在周一早上（都是悉尼时间）。第一次挂掉（超过 100 个 epoch 没有敲定）之后，我们成功恢复了测试网运行；但第二次崩溃时，我们决定就此收手，不再恢复。
以太坊独立钱包地址数突破2亿:7月4日消息，据Etherscan数据显示，以太坊独立钱包地址数突破2亿。据悉，Etherscan的数据记录从2015年7月30日开始，最开始独立钱包地址为9205个。2020年6月6日，独立钱包地址突破1亿。[2022/7/4 1:48:50]
这里说的 “崩溃”、“挂掉”，都是指测试网无法敲定 epoch。而没法敲定 epoch 的原因是超过 1/3 的验证者都掉线了。在设计上，这个测试网遇到问题不会死撑，而是会快速且明确地表现出失败。
这个测试网的基石是 4 个 AWS t2.medium 实例（硬件配置是 2 vCPU，4gb RAM， 32gb SSD）；每个实例都作为公开的引导节点，负载 4096 个验证者。实际上，我们也很惊讶，它们居然能撑这么久；对于少数硬件配置一般的机器来说，这是巨大的负担；它们中只要有两个离线了，测试网就没法继续敲定了。
昨日以太坊销毁量8300ETH，环比上升42.3%:据欧科云链链上大师数据显示，当前以太坊销毁量为128.89万ETH，24小时Base Fee均值97 Gwei；昨日以太坊销毁量8300.41ETH，环比上升42.3%。近24小时销毁量前三的协议分别是OpenSea 1238.74 ETH、Uniswap V3 743.58 ETH以及Erc-20 USDT 411.58 ETH。[2021/12/29 8:10:55]
我们分析了这两次崩溃事件，也学到了很多（细节在后续章节中）。我们团队已经回到开发工作中，希望能在下周发布一个新的测试网（也有可能是后面几周，可能工作会受假期影响）。你可以在 v0.1.1 milestone 这个页面上了解我们的进展。
以太坊核心开发者eric.eth考虑创建EIP，以将区块奖励从2 ETH减少到1 ETH:以太坊核心开发者eric.eth表示，为了符合以太坊对最低必要发行量的承诺，已经开始分析我们为安全支付的费用（与对EIP-1234的分析一致）。eric.eth称正在考虑创建一个EIP，将区块奖励从2 ETH减少到1 ETH。
据悉eric.eth在EIP-1234中分析表示，区块奖励和向矿工支付的交易费用，是为了确保网络的安全。对比BTC和ETH网络，将区块奖励和交易费用都转换为美元，并跨时间进行比较。两者非常接近，有时ETH实际上向矿工支付的费用比BTC高。因此从不同区块链，很难比较网络安全和财务费用。因此使用市值作为衡量指标来分析网络是否向矿工支付了过高的价格。ETH市值金是BTC市值的34%，因此向矿工的支付是过度的（ETH和BTC矿工获得的奖励的美元价值接近，但ETH市值低），并证明减少区块奖励是合理的。
今日此前消息，矿工提出针对EIP-1559的提案EIP-3368，拟将当前区块奖励从2 ETH增加至3 ETH。[2021/3/13 18:42:09]
测试网第一次崩溃的直接原因是软件的联网部件中的一个循环，它会 “看到” 某个见证数据（attestation）不断地重复发布。该循环在我们部署的四个信标节点（primary node）中的两个节点上出现了，耗尽了它们的资源，使得它们无法生产区块和见证数据。这个问题是导致两次崩溃的直接原因。
以太坊微信指数日环比上升71.40%:金色财经报道，微信指数显示，7月30日，区块链微信指数为1995869，日环比上升12.33%；比特币微信指数为818592，日环比下降12.26%；以太坊微信指数为193086，日环比上升71.40%；IPFS微信指数为325422，日环比下降6.66%。[2020/7/31]
我们已经更新了我们的 gossipsub 实现，现在，每条内容都是根据其内容来寻址的，这就意味着，如果我们收到两条内容相同的消息，gossipsub 协议会忽略掉第二条消息。我们也在 Lighthouse 客户端的代码中加入了复制消息检查，以此防止收发复制消息。
数据量暴涨
两个信标节点挂掉以后，测试网就不可能敲定区块了（因为 50% 的验证者都离线了）。不过，剩下的两个节点仍在继续发出和接收区块，这也是我们希望看到的情形。但是，网络失去确定性（finality）之后，它们就无法修剪和压缩它们的数据库，这就导致它们的数据库以每小时几 GB 的速度增长。因为我们将测试网节点的硬盘限制在 32 GB（包括操作系统所占用的部分），最终，它们的磁盘被旧数据塞满、无法再接受新区块了。这就导致另外两个节点也离线了。
在这种情况下，要想恢复测试网运行也很简单，只需加大硬盘、重启节点即可。我们也对这种恢复方式很满意，因为这就意味着，一些配有大硬盘的节点在两次崩溃中都几乎不会受到什么影响。
在我写作本文之时，Michael 正在开发针对这个问题的解决方案，思路是让数据库的膨胀速度降低 32 倍。虽然我们很高兴看到在 100 epoch 不能敲定之后节点能够恢复，但目前的情况相当于，一个硬盘不足 64gb 的节点只有约 10 个小时的生存时间。恢复能力对 Lighthouse 客户端是非常重要的，而 Michael 的更新会将 10 小时延长到 13 天。
分叉选择
我们也观察到，网络的分叉选择时间延长到了 8 秒。在我们看来，这是不可接受的，必须要去解决它。我们意识到，这个问题是由于过度从磁盘中加载信标链状态（BeaconState）导致的，所以我们已经写了一个 PR 来解决这个问题。
很高兴看到人们参与到 Lighthouse 测试网中来并运行自己的验证者，有 400 多名参与者参与了我们的测试网！感谢他们的反馈！下面这些建议是他们一再提到的：
需要更快的同步时间：我们正在努力了，预计在 0.1.1 版本中，同步速度可以快上 1.5～2 倍。
更好的 docker 文档：Scott 正在优化这些文档，而且新的测试网会用 docker 来部署（即，我们会亲身尝试使用 docker）。
更稳定的 eth1 节点：我们提供了一个公开的 eth1 节点，方便用户的使用，但事实证明，这个节点还导致了某些验证者宕机。在下一个测试网发布的时候，我们会在不同的地区部署少量节点，并在这些节点间做负载均衡。
更多 API 端点：becaoncha.in 团队联系上了我们，并希望他们的区块浏览器能够得到更多的 API 端点。我们已经提交了一个 PR，估计会在 0.1.1 版本时合并。
（完）（文内提供了许多超链接，请点击阅读原文到 EthFans 网站上获取）原文链接:https://lighthouse.sigmaprime.io/update-20.html作者: Blair Fraser翻译: 阿剑你可能还喜欢：
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。