Regenesis: StarkNet’s No-Sweat State Reset
All you need to know about why and how this will happen
StarkNet is preparing for a regenesis on Ethereum Mainnet. This post presents our current thinking on what this will look like, as well as why it is necessary and what its impact will be.
We’re keen to share information about the state reset. We are aiming to ensure that it is no more than a minor inconvenience for users, and certainly not a major upheaval.
The key to the ecosystem’s fast development has been the release of StarkNet Alpha before everything was perfect, and strong use of feedback to iron out problems and improve things. The state reset lets us eliminate all superfluous code and flows from StarkNet OS and the protocol. It allows us to make sure that the StarkNet system that is in production is as lean and secure as possible.
It is not something we’ll make a habit of, but rather a one-off, which is why we’re calling it the FSR — the Final State Reset. Dramatic, we know. Our goal is for this state reset to be the last state reset before StarkNet goes out of Alpha and into production. We are still not sure if this will happen immediately after the FSR or not, but it is a prerequisite on the road there.
Time to Shed StarkNet’s Scaffolding
Building StarkNet has been a fast-moving journey that we’ve shared with the developer community by releasing new versions on a monthly cadence. It never made sense to aim for immediate perfection; the way to go was clearly to improve based on fast feedback. This fitted the spirit of a platform that is headed to decentralization and community governance.
This is why we chose to release StarkNet Alpha on a public testnet a year ago and continued to develop functionality that was externalized via frequent upgrades. On occasions, we chose one design, tried it for size, and then chose another after deciding it worked better.
We didn’t know for sure that this was the right approach, but we feel vindicated by the reality on the ground today. A remarkable, active, and passionate developer community has been brought into the process at the earliest possible moment, and which has been profoundly involved in shaping the network.
So today we have a StarkNet that has been lovingly shaped and reshaped into an exceedingly lean platform. Well, almost.
It is still weighed down by code and deprecated features that served one purpose or another during the initial construction phase but is now just a burden. So while all the functionality we need takes a very lean form, it’s carrying a lot of dead weight.
The purpose of regenesis is to drop this extra weight — akin to the moment a new building sheds tonnes of scaffolding.
The Tradeoff in Timing the FSR
By delaying the FSR to the extent possible, we increase its positive impact. This is because we want to use the opportunity to trim extra weight that will be generated by features that are already planned or in the pipeline. Yet we know that delaying the FSR either causes applications to delay going into production, or create more work on their end to ensure a seamless migration.
Based on the trade-off outlined above we are still weighing a few factors to decide the best possible date, but we expect it in Q4/2022. We’ll release more details in a future post that will discuss the exact features that are still required.
The existing StarkNet Alpha will run for as long as necessary. In parallel, we will deploy a new leaner version of StarkNet Alpha that will start afresh, with a new state. This means that in the new instance all the contracts and accounts will need to be redeployed and assets will need to be migrated from the old StarkNet Alpha to the new one.
The impact should not be dramatic, and we’re working to keep it minimal. Nevertheless, some action will be necessary:
- For ERC-20 type assets, we will offer interoperability solutions that make the process seamless from the user’s point of view.
- For more complicated assets such as NFTs and the like, we are aiming to offer building blocks that applications can use to provide seamless migration for their users. E.g., we will provide a tool that allows proving on the new StarkNet that an event was emitted in the old StarkNet. This will allow burning NFTs with metadata in the old StarkNet that can allow minting them to a specific address in the new StarkNet.
When we say that the state reset is final, we’re saying that we — as StarkWare — won’t carry out another one. Obviously, we’re proud that a process of decentralization is getting underway, the nature of which is that we can’t make long-term promises about the network, which will rightly be in the hands of the community.
Could the community mandate another reset after full decentralization? In theory, yes, but as StarkNet’s adoption and usage grow, the disruptiveness of such a move in the future would need to be weighed against its added benefit. It is our hope that no such further regenesis will be needed.
But that shouldn’t leave developers or users with any doubts about StarkNet staying on the cutting edge with meaningful changes to the protocol made as future needs unfold. Buildings go through numerous renovations and changes, but clearing away the earth dug up from the foundations is a one-time event.
The same goes for StarkNet. It’s achieved excellence as a messy building site with surplus code strewn around. It’s time for the tidying operation of a lifetime, to prepare the network for further development.
As always, we welcome your feedback, sincere thoughts, and quality memes.