Spacemesh Decentralization

We would like to address an issue that some community members have raised concerns about - the H9 mining pool and its Spacemesh activities. We’re aware of what’s going on and the community’s concerns, but while we’ve never purposefully avoided it, we also never publicly laid out our perspective and approach on the topic.

Background

Leading up to our mainnet launch, the Spacemesh team had to concentrate our efforts. We decided to focus on making the experience for home smeshers as smooth as we could. This was not because we didn’t think industrial smeshers (data center rack or more) or semi-industrial smeshers (one or more serious home rigs) wouldn’t be interested in smeshing—we knew they would. But home smeshers wouldn’t have the capacity to build software for themselves (like industrial smeshers) or the expertise to understand and tinker with their configuration (like semi-industrial smeshers), so we decided to champion the little guy, while the larger smeshers would have to put in more effort.

Along Came H9…

Leading up to genesis, we learned that a mining pool, H9 (also known as HPool), which specialized in Chia farming, had taken notice of Spacemesh. They announced that they would launch a service for smeshers. This somewhat surprised us. After all, Spacemesh was deliberately designed to not incentivize pooling. Rewards are guaranteed every two-week epoch for all smeshers, and they scale linearly with smeshing weight (i.e. a smesher who has committed 4tb will earn double the rewards of somebody who has committed 2tb), so there’s no reward advantage in joining pools. But H9 found three main ways to provide value to their users:

1. They identified and implemented the most painfully missing features in the reference client for industrial and semi-industrial users, namely support for multiple GPUs and multiple hard drives (remember, we focused on people with home PCs and were more worried about people with no GPUs than people with several).
2. They identified a bottleneck for large smeshers and worked around it by splitting large space allocations into multiple small identities. See our previous post on reducing network load for more on this issue and how we’re addressing it.
3. The Spacemesh client was designed to run as a full node that also has access to the PoST data, so H9 built infrastructure to centrally operate smeshing nodes, such that users initialize and maintain their PoST data locally, then use it to generate a proof every epoch, and everything else is handled by the central nodes. This value proposition actually applies to smeshers of all sizes.

H9 advertised Spacemesh to their pool of Chia miners, and the response was overwhelmingly positive. So positive that Spacemesh was growing faster than anticipated, given the deliberately high cost of space initialization. Notably, despite these smeshers being mostly industrial and semi-industrial smeshers, none of them created the large ATXs that we anticipated seeing, since they were using the H9 optimizations, which made it easier to create many small identities as opposed to a few large ones. This has created more load on the network than it was designed to handle.

What’s Happening Now?

Because the network is overloaded, the Spacemesh team has avoided actively trying to onboard more smeshers. We’ve done almost zero PR since launching the network and instead focused on getting the network to scale in the short term and fixing the incentive issue that H9 is exploiting, which makes it more efficient to run small identities than to keep your identities unified.

This means that the only cohort of potential smeshers that has been advertised to and has therefore been meaningfully growing is H9 users. This is pretty bad for decentralization—a major long-term priority for Spacemesh and a trait that we believe our design is especially conducive to. It looks like a vast majority of the smeshing weight on Spacemesh today is controlled by the H9 pool.

Our estimates are that H9 has over 8,000 users that allocate space to smeshing. H9 is accountable to these individuals and has a reputation to protect. While we don’t dismiss the risks and issues associated with such centralization, we believe that in the short term H9 is highly incentivized to play fair and keep the network running smoothly.

Short Term Action

Since network load caused by the vast number of identities is destabilizing the network, one of the ideas we’re prepared to impose is a “new identity fee” that will be deducted from the first epoch reward of each identity that joins the network. This would be a temporary measure to slow the flood of new identities joining the network, and will no longer be necessary once the new version of PoST is rolled out (which inherently incentivizes large smeshers to consolidate their identities). We hope that the rate of new identities joining will slow down regardless, so we don’t even need this measure temporarily. But if it doesn’t—we’ll enact it.

What’s Next?

Once we’re able to stabilize the network and realign the incentives—our top development priorities at the moment—our focus will shift back to decentralization of smeshing. This starts with making the Spacemesh software work really well for any size smesher: better supporting some previously deprioritized workflows like initializing efficiently on multiple disks, using multiple GPUs concurrently, as well as efficiently deploying, monitoring, and maintaining PoST services on multiple machines.

We’re already making progress!

Our guides offer workarounds for technically savvy smeshers with multiple drives, a way to utilize multiple GPUs for initialization, and even running a single node instance for multiple identities spread across one or more machines. However, using these advanced features today requires technical ability and involves some risk (you might invalidate your identity if you make a mistake).

We intend to make these processes much simpler in the future!

We must achieve two important milestones, after which point we’ll make a concerted effort to attract miners: (1) the network can safely scale, and (2) individuals with any amount of storage can choose to smesh independently without sacrificing their reward or ease of smeshing.

We have plans to onboard storage ranging from data center-level actors to many home smeshers. We don’t believe the solution to Spacemesh centralization is “fighting” H9. We welcome the H9 smeshers, who contribute heavily to making Spacemesh secure, now and in the future. We’re all one big community. But we believe that a more diverse set of smeshers will help make Spacemesh more resilient in the future.

To the same end, we also intend to encourage competing pools. While the Spacemesh protocol is designed in such a way that, once the above improvements are in place, there should be no economic benefit to joining a pool, we nevertheless accept that some miners will always prefer to mine as part of a pool. We believe there’s room for competition, especially around the pool trust model: we’re particularly interested in supporting pools that don’t require miners to reveal their private keys to the pool operator! While pools aren’t ideal from a decentralization perspective, other things being equal, having many pools is better than having one large pool.

Spacemesh was designed to support a large number and variety of individuals contributing to the consensus protocol. While that’s not reflected in the composition of the smesher community today, we see the phase we’re in as a stepping stone toward our goal of being the most decentralized crypto network in the world.