重置以太坊1.0能减轻以太坊的负担吗？

基于以太坊这么多年的成功运营，重置以太坊这个词听起来骇人听闻。加密货币网络一旦启动就需要继续。重置是一个从技术到经济的过程。

自2020年6月以来，以太坊社区一直在讨论这一提议。实际上，这主要与以太坊1.0链的状态有关。在未来以太坊2.0的进程中，有一个过程需要以太坊1.0和2.0的融合，以及以太坊未来将面临的升级任务。

以太坊ledgerwatch的开发者Alexey akhunov提出了对以太坊社区的研究。基于宇宙的问题和解决方案，他提出了重置以太坊的推论。通过本文的内容，我们可以初步了解重置以太坊的概念。

宇宙中心的经验教训

如果你观察coos hub如何从版本1升级到版本2，然后从版本2升级到版本3，你就会知道这实际上是通过重启区块链来完成的。升级后，节点操作员必须关闭其节点，然后生成coos hub状态的快照，并有效地将该快照用作启动第一个块的新块链的原点。

现在，任何想加入coos的人都需要获得coos hub-3的来源，下载coos hub-3的所有块（而不是coos hub-1或coos hub-2），然后重放它们。

我们能“重启”以太坊1吗？

让我们看看这个方法在以太坊中的应用，假设我们有一个非常大的区块链（150-160gb）和一个相当大的状态（40-100gb，取决于您的存储模式）。这种“重启”的明显好处是，新的连接器节点将需要40Gb的Genesis，而不是150gb的块。但是下载40gb的genesis仍然不是一个好的体验。以太坊中的状态是隐式的，只有Merkle根哈希是显式的。

现在让我们假设我们可以使用这些40gb隐式存储的“链外”并且只使用根哈希作为源。让我们也从空状态开始。那么，如何使事务访问成为隐式状态的一部分呢？

请记住，即使现在40gb也是隐式的，获得它的确切方法在实现细节中。您可以运行所有1000万个块来计算它，您可以通过快速同步或扭曲同步下载它的快照，甚至可以从某人的外部磁盘**它并重新验证它。尽管状态是隐式的，但我们假设块生成器（通常是挖矿池）可以访问隐式状态并始终处理所有事务。我们要删除的假设是，所有其他验证节点都可以访问隐式状态来检查块中的事务是否有效，并且块头中显示的状态根哈希与块的执行结果匹配。

以太坊是无状态的吗？

如果您完全遵循无状态以太坊，您可能会意识到这正是我们正在尝试做的-保留块编写器可以访问隐式状态的假设，并删除所有验证节点具有相同访问权限的假设。为此，我们建议区块包装商必须向区块添加额外证据，我们称之为“区块见证人”。

区块证明和交易证明？

当人们第一次理解这一点时，他们认为这些额外的证明实际上是由事务发送者提供的，并且成为事务负载的一部分，但是我们必须向他们解释，这不是块打包器的工作。但后来我们发现，这笔交易必须包含一些额外的证据。换句话说，他们需要证明发送地址有足够的ETH来购买交易的gas，以及账户中所有其他交易的随机数，但随机数很低。他们可能还需要证明发送账号的随机数，这样节点就可以发现是否存在随机数缺口，从而通过一系列不可行的交易发现潜在的DDoS攻击，并可以进行更严格的检查。

再生提供救济

DSA的烦恼虽然不容易解决，但可以得到充分的缓解，使用户很少看到不便，永远不会陷入“无法实现所需状态转换”的境地。缓解依赖于额外的规则，即随事务提供的任何证明（对照状态根进行检查，但不一定足以使事务成功）成为隐含状态的一部分。因此，用户重复执行事务的尝试将隐式地不断增加，并最终会成功。任何试图“诱捕”用户的攻击者都必须想出一种更复杂的方法，将事务的状态访问重定向到隐式状态之外。最终，攻击者将失败。

当隐式状态从无到有（仅在“重启”之后）增长到包含越来越多的活动访问状态时，事务需要提供的证据量就会减少。过了一段时间，大多数交易甚至不需要添加任何证据，只需触及该州一些非常古老和“尘土飞扬”的地方。

我们能继续吗？

我称之为“重启”再生，它可以定期执行，以减轻非挖矿节点的负担。它还代表了无状态以太坊的戏剧性版本。

重复执行regenesis将简化以太坊客户端实现的体系结构。它几乎不需要更**的快照同步算法。如果我们每1m块（大约6个月）执行一次Regensis，我们可以在BitTorrent、swarm和IPFs上使用状态快照和区块链文件。我们现在不能这样做，因为状态每15秒改变一次，而不是每6个月改变一次。如果客户端实现能够处理6个月的数据块重放，那么我们就不需要非常复杂的快照算法。因此，以太坊实现的复杂性将降低。

缺点

我没怎么探索，但我看到了三个：

用户可能需要访问完全隐式的状态来创建事务，我实际上认为这是一种公平的折衷。

用户可能需要重复事务（由于动态状态访问），直到最终实现所需的状态转换。

如果网络在重新生成之前有效地“归档”所有块，则某些聚合技术（使用区块链数据确保数据可用性）可能会中断。