The Sovrin TestNet has been a vital part of the Sovrin ecosystem for over five years. It is a platform where developers can test their applications, deploy non-production proofs of concept, and where the Sovrin Foundation tests Hyperledger Indy upgrades prior to deploying them on the Sovrin MainNet. The potential for resetting TestNet has always been known in the community — it has just not yet happened. However, with our recent announcement that a reset is likely to be “coming soon”, there have been concerns raised by some of the Sovrin Stewards. In this blog post, we will explore why the resetting of TestNet is sometimes necessary, the resulting concerns raised by some Sovrin Stewards, and a clarification (and a request) from the Sovrin Foundation about those concerns.
Resetting TestNet is sometimes necessary for technical reasons, most notably for aligning with Sovrin MainNet ahead of an upgrade to the MainNet nodes. In fact, there is an upcoming technical need for just such a reset. We will soon need to reset TestNet to match the current Sovrin MainNet configuration ahead of an upgrade to MainNet that will eliminate the token from the network. The use of a token on the Sovrin networks has not proven to be viable, and the existence of code and data on Sovrin networks has become a maintenance burden. The path to eliminating that overhead necessitates a reset of first BuilderNet and thenTestNet to provide the greatest amount of protection for the Sovrin MainNet.
Apart from resetting TestNet for technical reasons, there are other arguments for resetting TestNet that have been long discussed in the community. There needs to be a differentiator between TestNet and MainNet to prevent TestNet from being just “a second MainNet.” In fact, there have been cases where some have misused TestNet, running what amounts to production use cases on the non-production network. Such actions can impact clients, the proper use of the network, and the reputation and stability of Sovrin itself. As such, it’s important to have measures in place to prevent misuse. Periodic resetting is one way to achieve this differentiation. It’s not ideal, as it may cause significant disruption for legitimate TestNet users. However, right now, it is the only tool we have for establishing such a differentiation. We are aware of another approach that has been proposed, a “rolling window”, where transactions of more than a given age become “unresolvable”. Such an approach would be less disruptive than reset but does require some Hyperledger Indy investment and development. We welcome funding and invite collaborators to work with us on this alternative approach.
Our goal either way is to make Sovrin a self-sustaining subscription service with the resources necessary to maintain the utility in the long run. A service with the resources necessary to invest in evolving the network, such as a “rolling window” update, or for evolving the current AnonCreds revocation capabilities.
As previously announced, TestNet is subject to periodic reset. For 2023, there is not yet a defined plan for when that reset will occur. When the plan is finalized, the timing will be announced and Sovrin TestNet users will have time to prepare. As noted, the first reset will be required for preparing for an upgrade of MainNet. The frequency of resets thereafter will depend on the capabilities of Hyperledger Indy, the governance of the network, and what is best for the stability of the Sovrin Foundation.
Our goal either way is to make Sovrin a self-sustaining subscription service with the resources necessary to maintain the utility in the long run. A service with the resources necessary to invest in evolving the network, such as a “rolling window” update or for evolving the current AnonCreds revocation capabilities.
As previously announced, TestNet is subject to periodic reset. For 2023, there is not yet a defined plan for when that reset will occur. When the plan is finalized, the timing will be announced, and Sovrin TestNet users will have time to prepare. As noted, the first reset will be required for preparing for an upgrade of MainNet. The frequency of resets thereafter will depend on the capabilities of Hyperledger Indy, the governance of the network, and what is best for the stability of the Sovrin Foundation.