以太坊1.0重置是否能减轻负担

这个提议在以太坊社区里从2020年6月就开始讨论了。其实主要相关于以太坊1.0链的状态，未来以太坊2.0的进程里，有一个进程需要进行以太坊1.0和2.0的合并，以及未来以太坊将面临的升级任务。

以太坊社区研究这件事的开始是由以太坊ledgerwatch的开发者AlexeyAkhunov提出的，他以COSMOS的问题和方案为基础提出了重置以太坊的推论，通过这篇文章内容可以初步理解重置以太坊的概念。

CosmosHub的经验教训 如果您观察到CosmosHub如何执行从版本1到版本2，然后从版本2到版本3的升级，您将知道这实际上是通过重新启动区块链来完成的。升级后，节点运营商必须关闭其节点，然后生成CosmosHub状态的快照，然后有效地使用该快照任何想要加入Cosmos的人，需要获取CosmosHub-3的起源，下载CosmosHub-3的所有块（而不是CosmosHub-1或CosmosHub-2），然后重播它们。

我们可以“重新启动”以太坊1吗？ 让我们看一下这种方法在以太坊中的应用假设，我们有一个非常大的区块链（150-160Gb）以及相当大的状态（40-100Gb，取决于您的存储方式）。这种“重新启动”的明显好处是，新的连接器节点将需要从40Gb的创世纪状态开始，而不是从价值150Gb的块开始。但是下载40GbGenesis仍然不是一个很好的体验。以太坊中的状态是隐式的，只有其merkle根哈希是显式的。

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

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

是无状态的以太坊吗？ 如果您完全遵循无状态以太坊，那么您可能会意识到这正是我们正在尝试做的事情-保留块编写器有权访问隐式状态的假设，而删除所有验证节点具有相同访问权的假设。我们建议通过让区块打包者有义务在区块中添加额外的证明来做到这一点，我们称这些证明为“区块见证”。

区块中的证明与交易中的证明？ 当人们第一次了解这一点时，他们就认为这些额外的证明确实是由交易发送者提供的，并成为交易有效载荷的一部分，但是我们必须向他们解释，这不是区块打包者的工作。但是后来我们发现交易将不得不包含一些额外的证据。也就是说，他们将需要证明发送地址有足够的ETH来购买该交易的gas，以及该账户中所有其他交易的随机数，但随机数较低。他们可能还需要证明发送帐户的随机数，以便该节点可以找出是否存在随机数缺口，从而通过一系列不可行的交易来发现潜在的DDOS攻击，并可以进行更严格的检查。

ReGenesis以提供缓解 关于DSA的担忧无法轻松地完全解决，但可以充分缓解，以至于用户很少会看到不便，也永远不会永远陷入“无法实现所需状态转换”的境地。缓解措施依赖于额外的规则，即随交易提供的任何证明（根据状态根进行检查（但不一定足以使交易成功））都成为隐含状态的一部分。因此，用户反复执行事务的尝试将保持隐式状态的增长，并最终将成功。任何试图“诱捕”用户的攻击者，都必须想出更复杂的方法来将事务的状态访问重定向到隐式状态之外，最终，攻击者将失败。

随着隐式状态从无到有（仅在“重新启动”之后）增长到包含越来越多的活动访问状态，事务需要提供的证据将减少。一段时间之后，大多数交易甚至都不需要附加任何证据，只需接触状态中一些非常老旧且“尘土飞扬”的部分。

我们可以继续做下去？ 我称此为“重新启动”再生，可以定期进行以减轻非采矿节点的负担。它也代表了无状态以太坊的戏剧性版本。

重复执行ReGenesis将简化以太坊客户端实现的体系结构。它几乎可以消除对更高级的快照同步算法的需求。如果我们每1m块（大约6个月）执行一次ReGenesis，则可以在BitTorrent，Swarm，IPFS上使用状态快照以及区块链文件。我们现在不能这样做，因为状态每15秒钟而不是每6个月更改一次。如果客户端实现可以应对重播6个月的数据块，那么我们就不需要非常复杂的快照算法。因此，

热点：以太 以太坊 太坊