StarkNet正在为以太坊主网上的重置做准备。这篇文章介绍了他们目前对这种情况的看法，以及为什么要这样做，和这么做会有什么影响。以下是全文内容。
我们热衷于分享有关状态重置的信息。我们的目标是确保它不会给用户带来更多的不便，也不会造成重大的动荡。
生态系统快速发展的关键就是在一切都还没有完善之前就发布了StarkNet Alpha，以及着重利用反馈来解决问题和改进工作。状态重置让我们从StarkNet操作系统和协议中去除所有多余的代码和流程。它使我们能够确保尚在生产中的StarkNet系统尽可能精简和安全。
这个过程不是要我们去慢慢适应，而是一次性的，这就是为什么我们称它为FSR——最终状态重置。我们的目标是让这次状态重置成为StarkNet退出Alpha并投入生产之前的最后一次状态重置。我们还不确定目标是否会在FSR之后立即实现，但这是实现它的先决条件。
我们通过每月发布新版本与开发者社区分享，这构建StarkNet的过程也很快。追求立竿见影的完美是没有意义的，我们要做的显然是根据快速反馈进行改进。这符合去中心化和社区治理的平台精神。
这就是为什么我们一年前选择在公共测试网上发布StarkNet Alpha，并继续开发功能，通过频繁升级使这些功能具体化。有时，我们会选择一种设计，试一试大小，然后在确定它能产生更好的效果后选择另一种设计。
我们当时不确定这是否是正确的做法，但现在的实际情况证明这种做法是对的。一个卓越、活跃、充满激情的开发者社区在计划初期就已经参与到这个过程中，并深度参与了网络的塑造。
因此，我们今天才有这个StarkNet，它经过精心塑造和重塑成为一个非常精简的平台。
但它仍然被代码和一些废弃的功能所拖累，这些功能在最初的建设阶段是有着这样或那样的功用，现在却只是负担。因此，虽然所有我们需要的功能都采用非常精简的形式，但它们也承载着那些弃用功能的重量。
重置的目的是丢掉这些额外的重量——就像一座新建筑卸下数吨脚手架的那一刻。
通过尽可能推迟FSR，我们增加更多积极影响。这是因为我们想利用这个机会，减轻由已经计划或正在准备中的功能所产生的额外重量。然而我们知道，延迟FSR要么导致应用程序延迟投入生产，要么需要其应用端做更多工作，以确保无缝迁移。基于上述原因，我们仍在权衡一些因素，以确定最佳状态重置的日期，但预计会在2022年的第四季度。我们会在以后的帖子中发布更多详细信息，讨论还会需要的确切功能。
现有的StarkNet Alpha运行时间会尽可能的长。同时，我们将部署一个更精简的StarkNet Alpha新版本，它会以一个全新的状态重新开始。这意味着在新用例中，所有合约和账户都需要重新部署，资产需要从旧的StarkNet Alpha迁移到新的StarkNet Alpha。
这种影响不应太大，我们正在努力将其降至最低。尽管如此，还是有必要采取一些行动：
? 对于ERC-20类型的资产，我们将提供互操作性解决方案，从用户的角度使流程无缝衔接。
? 对于更复杂的资产，例如NFT等，我们的目标是提供构建区块，应用程序可以为其用户提供无缝迁移。例如，我们会提供一种工具，允许在新StarkNet上证明在发生在旧StarkNet上的事件。这可以在旧StarkNet中销毁带有元数据的NFT，从而可以将它们铸造到新StarkNet中的特定地址。
当我们说状态重置是最终的，也就是说我们——StarkWare——不会再执行一次重置。显然，我们为正在进行的去中心化过程感到自豪，其本质是我们无法对掌握在社区手中的网络做出长期承诺。
社区是否可以在完全去中心化后授权再进行一次重置？从理论上讲，这是可以的，但是随着StarkNet的采用和使用的增长，未来这种举措的破坏性需要与其带来的额外好处相权衡。我们希望不需要再有这种二次重置。
随着未来需求的出现，需要对协议做出有必要的更改，但这不应该是开发者或用户对StarkNet保持领先地位产生任何怀疑的原因。建筑会经历了无数次的翻修和改变，但清除从地基挖出的泥土是一次性的事情。
StarkNet也是如此。就像一个混乱的建筑工地，到处都是多余的代码，它已取得了卓越的成就。现在是时候进行它一生中最重要的整理工作了，为网络的进一步发展做好准备。
原文：《Regenesis: StarkNet’s No-Sweat State Reset》
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。