ReGenesis：我们可以“重启”以太坊吗？

来自 Cosmos Hub 的经验 

如果你观察过 Cosmos Hub 是如何从 1.0 版本升级到 2.0 版本，再升级到 3.0 版本的，你就会知道 Cosmos Hub 的升级本质上是通过用一个新的创世块重启区块链来实现的。要升级的时候，节点运营者需要关闭节点，然后生成 Cosmos Hub 状态的快照，然后将这一快照打包进新的创世块，创建一条新的区块链。

现在，凡是想要加入 Cosmos Hub 的人，都需要获取 CosmosHub-3 的创世块，下载 CosmosHub-3 的所有区块并进行重放（不再需要下载 CosmosHub-1 或 CosmosHub-2 的区块了）。

 我们可以 “重启” ETH 1.0 吗？ 

我们来设想一下同样的方法能不能应用到以太坊上。以太坊区块链非常庞大（150-160 Gb），状态也很大（40-100 Gb，具体取决于你存储状态的方式）。“重启” 以太坊区块链的一个明显优点是，新加入的节点需要下载 40Gb 的创世状态，而非一条 150 Gb 的区块链。然而，下载 40 Gb 的创世状态也不是很好的体验。

 将以太坊的状态存储在链下，只有默克尔根哈希是链上可见的

假定我们可以将这 40 Gb 存储在 “链下”，只将根哈希打包进创世块，这样我们就能从空状态开始了。但是，我们如何让交易访问这些隐式的状态？

请记住，尽管这 40 Gb 的状态是隐式的，而且如何获取这些状态属于实现细节，你可以运行所有 1000 万个区块来计算这些状态，或者通过快速同步、warp 同步来下载其快照，或者从其他人的外部磁盘复制过来再进行验证。虽然状态是隐式的，但是我们假设区块提议者（通常是矿池）可以访问这部分隐式数据，而且能够处理所有交易。只不过我们要放弃一个假设：所有其他验证节点都可以访问隐式状态，来验证区块中的交易是有效的，且区块头中的状态根哈希符合区块的执行结果（译者注：在当前的以太坊协议中，因为所有状态都是显式的，所以这个假设是合理的）。

 这不是无状态以太坊吗 

如果你了解无状态以太坊（Stateless Ethereum），你可能会意识到，这正是我们目前努力的方向 —— 保留 “区块提议者可以访问隐式状态” 的假设，去除 “所有验证节点都可以访问隐式状态” 的假设。我们建议的解决方案是，让区块提议者将额外的证明添加到区块中。我们将该证明称为 “区块见证（block witness）”。

 区块中的证明 vs 交易中的证明

第一次了解这个方案的人会认为额外的证明实际上是由交易发送者提供的，是交易有效负载的一部分，我们不得不出来解释说并非如此，证明是由区块提议者提供的。但是，我们后来发现，交易也必须包含额外的证明。换言之，交易发送方需要证明发送方地址有足够的 ETH 来支付 gas 费，以及其他所有由这个账户发起的 nonce 值较小的交易。此外，交易发送方还需证明发送方账户的 nonce 值，以便节点弄清楚 nonce 值之间是否存在缺口，以免有人借机发送一系列不可行的交易来进行 DDOS 攻击。我们还可以进行更加严格的检查，不过对于绝大多数抗 DDOS 攻击的方案来说， ETH 余额和发送方账户 nonce 值是必要信息（或许还不够充分）。

 交易中的证明存在的缺点

假设我们想让交易发送者将每一个相关状态的证明都添加进交易。这样做的好处在于，将简化我们为见证收取额外 gas 费所需的工作量。这样做的主要缺点在于，这通常需要通过动态状态访问（DSA，与静态状态访问（SSA）相对）实现。如果一个交易涉及的智能合约特别复杂，比方说，有大量对其他合约的嵌套调用，可能很难预先计算出交易将涉及的状态项。攻击者甚至可以利用 DSA 来给用户 “下套”，即，抢跑其交易（发送内容一样但 Gas 费更高的交易，以抢在前面被打包）让用户的交易因为证明不充分而失败。

ReGenesis 提供的缓解措施 

虽然 DSA 的隐患很难彻底解决，但是可以尽可能降低其风险，让用户不会感到不便，也不会永远限于无法实现预期状态转换的境地。该缓解措施需要引入额外的规则，即，任何随交易提供的证明（已经根据状态根进行过验证，但这并不足以保证交易能成功）都会成为隐式状态的一部分。因此，随着用户反复尝试执行交易，隐式状态会不断增长，最终交易成功。那些尝试给用户 “下套” 的攻击者必须找到更复杂的方法，把用户的状态访问重定向到已有的隐式状态之外，最终以失败告终。

随着隐式状态从无（刚重启时）到有不断增长，包含越来越多的主动访问状态，交易需要提供的证明将会减少。过了一段时间，大多数交易甚至不需要附带任何证明，除了那些涉及到很久之前的状态的交易。

 我们可以定期执行 ReGenesis 

我称之为 “重启” reGenesis ，可以定期执行，以便减轻非挖矿节点的负担。ReGenesis 也代表了一个不那么激进的无状态以太坊版本。

反复执行 ReGenesis 将简化以太坊客户端实现的架构，几乎可以免去对较高级快照同步算法的需求。如果我们每隔 100 万个区块（大约 6 个月）执行一次 ReGenesis，可以将状态快照和区块链文件放到 BitTorrent、Swarm 和 IPFS 上公开。目前我们无法做到这点（随产生随存），因为状态每隔 15 秒而非 6 个月转换一次。如果客户端实现可以重放 6 个月的区块，我们就不需要非常复杂的快照算法。因此，以太坊实现的复杂性会降低。

 ReGenesis 的缺点

我还没有对此进行深入探索，不过我已经看到的三个缺点有：

用户可能需要访问完整的隐式状态来创建交易。实际上，我认为这是公平的妥协。

（由于 DSA）用户可能需要反复执行交易，直到最后实现预期状态转换。

一些（利用区块链数据来实现数据可用性的）rollup 技术可能会受到影响