Community Clarification: Equivocation

Dear Smeshers,

The Spacemesh protocol is essentially a collection of voting mechanisms that produce a canonical ledger, where smeshers become eligible to vote by allocating storage space to the protocol. The biggest threat to a voting system is double voting (otherwise known as equivocation) and that’s why the protocol takes a very hard stance when duplicate votes are detected. The cost of double voting on Spacemesh is permanent disqualification of the offending smesher identity. (Compare this to proof of stake networks like Ethereum, where the penalty for equivocation is slashing of a substantial portion, or in some cases 100%, of a validator’s stake.)

We’ve recently detected multiple disqualified identities on the Spacemesh mainnet due to attempted double voting or double activation (a precursor to double voting). We’ve investigated these cases and the purpose of this document  is to share our conclusions with the community.

We currently have no reason to believe that any of the smeshers that got disqualified tried intentionally to do anything malicious. Unfortunately, however, the network is unable to differentiate between intentionally malicious behavior and honest mistakes that lead to double voting. What’s more, all the cases we’re aware of involve some “off-label” use of our software. The official Spacemesh node implementation was designed to prevent disqualifying one’s own identity if used as intended.

The cases we’re aware of all involved running two instances of the node software with the same smesher identity (i.e., the same key.bin file). So we want to make it very clear that doing so, even accidentally, will permanently disqualify your identity, resulting in lost rewards and a need to regenerate your PoST data with a new smesher identity.

Examples of how users got disqualified include using SMApp and then simultaneously firing up an instance of go-spacemesh directly, pointing it to the same PoST data and key file; and copying the PoST data directory to a second machine and pointing SMApp to it without shutting down the previous instance. Other variations are possible, but note that all involve “off label” use of Spacemesh software: in the first case, running two nodes simultaneously on the same system requires disabling multiple existing safeguards such as lock files and P2P ports, and in the latter case, transferring PoST data and identities across devices is an advanced, unsupported use case. Users are of course free to use Spacemesh software as they like but we strongly encourage users who aren’t familiar with operating blockchain infrastructure to stick to supported usage patterns only (e.g., running Smapp on a single device), and to read all documentation and be extraordinarily careful when deviating from officially supported usage patterns.

To reiterate: never, under any circumstances, run two instances of Spacemesh (whether using Smapp or go-spacemesh, on the same system or multiple systems) using the same smesher identity at the same time. If you do so, your identity will be disqualified. When in doubt, ask for help!

Our first priority is the health and security of the Spacemesh network, which unfortunately means that we must continue to take double voting seriously, even if done unintentionally. However, there are some additional safeguards that we can put in place to make it even harder to accidentally double vote. Before seeing these cases, it seemed unlikely that users with benign intentions would accidentally or naïvely run two node instances concurrently. Now that we’ve seen this happen in the wild, we’ve decided to take additional measures to prevent users from accidentally shooting themselves in the foot:

1. When PoST data is initialized a fingerprint of the running system (operating system, hardware, network configuration, etc.) will be taken and stored alongside the PoST files (go-spacemesh#4856). When the files are accessed this fingerprint will be checked and if it doesn’t match the current system the node will refuse to start and will display a message to the user that they must verify that the systemthat generated the data isn’t running a node anymore before updating the fingerprint.
2. When receiving data from the network, if messages (ATXs, Hare messages, etc.) signed by the node’s own identity are received the node will shut down with a similar error message (go-spacemesh#4857). If the user intended to do this (e.g., they need to resync a node, or migrate data to a new computer) they can explicitly indicate the last layer they expect to see messages from the previous node and this check will be skipped for those layers.

We hope that with these measures in place no additional smeshers will accidentally get disqualified.

Another issue is that there’s currently no clear indication in the SMApp UI when your own identity gets disqualified. If you suspect that your identity may have been affected (e.g., you should be receiving rewards but you’re not), you can compare your Smesher ID (available on the Smeshing screen in SMApp, or in your logs) with the list of disqualified identities that’s available on Discord. We’re working on showing this information on the explorer Smesher page, which will be ready in the next couple of days. In addition, we’re working on notifying affected users directly in SMApp, which will be part of the next update.

If you have any further questions about this issue feel free to ask on the network discussion channel on Discord.