This is a heavily discussed topic in our community. Over time some complex theories were evolved. However, none of those theories is correct.
What exactly has happened when a client desyncs is a heavily discussed topic in our community. Over time some complex theories evolved. Some gamers argue, that it happens when transactions are sent too fast successively. However, none of those theories are correct. In fact, one gamer can’t cause it on their own. It originates from the node network and how forks are handled.
The clients interpret every block and compute the current game state. If a fork appears it depends on the connected nodes which of these blocks are accepted. Consequently, the player base could split and play with different game states. Such a split would repeat at every fork. From this moment, players would not be able to interact with each other anymore.
Of course, this is something that should never ever happen, so we implemented a bulletproof method to prevent it. Our clients have an inbuilt fork detection which allows them to revert up to six blocks on their own. This means all the game operations which had taken place in those blocks have to be computed again starting from the block from which the chain has split.
Even exchanges and banking services regard blocks older than 6 blocks as safe and forks of that length as extremely unlikely to happen. However, the testnet proved that this can indeed happen if the mining difficulty becomes extremely easy or the used mining power of a single miner surpasses the current combined computing power excessively. In such cases, we even experienced forks of more than 40 blocks.
So we implemented a service which enables us to handle forks of any dimension. To achieve that, it does nearly the same as what the clients do: detect forks. The trick is that both, the client and the service communicate with each other and compare the hash of the current game state. If the hashes match, there is no need to worry. If they are not the same, this is a clear indication that there is currently an active fork and your client and the service operate with different blocks.
You might be wondering why you can’t proceed to play during the syncing. That is easy to explain and you will agree that it is the right thing to do. We are protecting you against actions you do not want to carry out.
Worst case scenario
Let’s play through the worst case scenario and ignore the integrity service: You have sent a character on a quest during a prior block and you are currently dismantling equipment you do not need. Now a fork appears and your client and the integrity service are connected to nodes which operate with different blocks.
Because the reward of the quests is based on the position of the transaction within the block and the hash of a block, the service and your client will compute different rewards for the character who is on a mission. While the service thinks you received a legendary piece of equipment, your client computes that you received equipment without any relevance. Without the integrity service and a forced resync, you might dismantle the equipment without realizing that you would get a legendary piece if the other chain became the main chain.
Let’s introduce some more chaos. This time it is the other way round. You received a legendary holy ring while the integrity service computes a basic nature ring. You might equip and upgrade it and send your hero on a quest with bosses using physical damage which you can only clear because of the ring.
If now the other chain becomes the mainchain and your client detects that it is in a fork the game operations would do a rollback. Consequently, the legendary holy ring would become a basic nature ring. The elemental bonus for the mission would become a disadvantage and you would fail the quest. However, the upgrading would still have taken place so you would end up with useless equipment in which you invested a lot of resources.
You see, even if a desync is rather annoying it is still better than the situations you might get into if we did not have such strict standards about handling forks.