Spacemesh Status Update (22/08/23)

The Spacemesh mainnet launched just over a month ago, on July 14. Since then there have been 15 releases of go-spacemesh and 17 releases of Smapp (which bundle the go-spacemesh releases). Our first priority remains maintaining network health and stability, and the security of user keys and funds, and most of these releases have been fixes to various high severity issues that have arisen since genesis. We’ll continue to fix these issues as they arise and as we become aware of them, and we’ll continue to encourage users to upgrade to the latest releases, since it’s the best way to ensure that your node is stable and that you don’t miss any rewards (and it’s also in the best interest of overall network health to have as many upgraded nodes as possible).

We’d like to address a couple of issues that have arisen, especially related to updates.

Auto-Updates

As you’ve probably noticed by now, Smapp checks periodically for new releases, alerts the user when a new release is available, and, in the case of critical updates, automatically downloads and installs the update, then restarts. 

We recognize that this update process is centralized and that it subverts an essential aspect of blockchain governance: namely, that all miners and node operators should have the choice about where they get their updates from and whether and when to update their nodes. We debated this feature a great deal before releasing it and we’d like to explain our reasoning.

Spacemesh is attempting to make mining accessible to millions of casual, everyday Internet users who have never operated blockchain infrastructure before. But this novel approach introduces a novel challenge: getting vital updates to a very large number of less tech-savvy users. Since the network and software are still considered “alpha” for now, it’s essential that we be able to update a critical mass of nodes in case of severe bugs and issues. We don’t like the auto-update feature either, and are committed to disabling it as soon as it’s feasible to do so.

For those users who aren’t comfortable with auto-updates, go-spacemesh has no such features, nor will we add them. Go-spacemesh users are assumed to be technically sophisticated and it’s incumbent upon them to pay attention to releases and update manually when a new release becomes available (or risk losing rewards if their node falls behind). 

If you want to disable auto-updates but continue using Smapp—despite the risks—it’s possible to block auto-updates in Smapp as well and instructions have been shared on Discord.

Improving the Release Process

We recognize that a few of our Smapp releases have gone awry and caused issues for those who upgraded, including the Smapp v1.1.0 release that went out yesterday. We use industry standard CI (continuous integration) practices and have a thorough test suite for both go-spacemesh and Smapp, which tests all changes across all supported platforms. Nevertheless, bugs do occasionally creep in and make it past our tests, all of which passed for yesterday’s releases. The v1.1.0 release had vital fixes we were eager to ship out, and this led to sloppiness on our part.

There’s more we can do to improve the release process. We’re discussing our current protocol internally and we’ll share more details regarding improvements with the community as soon as possible. We will be setting up a testnet very soon as well, with details on how to participate forthcoming. Some community members have suggested opening a testing channel for mainnet releases, but we think this could easily become problematic if, for example, there was a bug which impacted smesher identity. So, in the short leadup to testnet, we will make our internal testing as rigorous as possible. 

Spacemesh is a work in progress and we’re glad that you’re along for the ride, but things will be bumpy for a while as we work out all of the network’s kinks and improve stability. As mentioned above, Spacemesh should be considered “alpha” software. Please don’t invest more resources in Spacemesh than you can afford to lose.

PoET

One more quick note on PoET servers. 

In the previous epoch we became aware of an issue where nodes were registering with multiple PoET servers, as designed, but weren’t selecting the PoET proof with the highest tick count. This resulted in 737 of ~2400 or around 30% of ATXs targeting epoch 2 ending up with a lower tick count from a slower PoET, which resulted in temporarily reduced rewards for affected smeshers. The issue was fixed in go-spacemesh v1.0.11 and all smeshers who subsequently updated should be fine, i.e., they should not experience reduced rewards due to a PoET proof with fewer ticks.

In the most recent PoET round that kicked off a few days ago, we noticed that a small number of ATXs (representing only 2% of smesher coinbases) again ended up selecting PoET proofs with a lower tick count. We strongly suspect that these smeshers haven’t updated their software since before v1.0.11 and are running versions of go-spacemesh that are extremely out of date. If you are running up-to-date node software and you’re receiving fewer rewards in epoch 3 than expected, or if you’ve checked that your ATXs have a lower than expected tick count, please let us know so we can investigate further.