Technology
Well, I Was Wrong
The simplest way of doing this [defending against malicious synchronization] is by having each of the servers send each other the data that they receive from the others. This will allow each of the servers to compare the data, and figure out if it is manipulated. Only one check is needed because it is majority prof this way; as long as the majority of the servers are reporting the correct data, the individual servers can judge vote whether to kick a client or not.
One Twenty Eight, April 10th, 2017, 5 AM GMT, in this post
Quick Note
I use the words “server” and “player” interchangeably; this article is focused on the type of decentralized server that has one server per player.
Nope
Umm… No. That [quote] is not right. That is definitely not right.
In case you did not read that article, I went over the technicalities of a decentralized video game round. During this, I declared that as long as the majority of servers are reporting accurate data, the server is protected from malicious desynchronizing attacks.
Looking back at this, I realize that I was wrong. The majority is not able to protect against desynchronization attacks. A person carrying out the attack only attacks a few of the servers running the round, which is not a majority, and only a majority is able to kick players. The only reason why desynchronization attacks on a majority are majority-proofed is because a majority of the servers have prof that a client is trying to desynchronize them.
If only one server out of all of them was receiving incorrect data, the other servers could easily think that the server is lying to them about being lied to.
Somehow, there needs to be a way for the servers to be able to make it impossible, or lucrative to carry out desyncronization attacks.
Trust
Most of the time, clients will be playing with clients that they have never played with before; in order for a client to trust another client, the other client has to be trusted by someone that they trust.
Every client will have a trust level tied to their account. When the client joins into a round, it must give its public key to the other servers, and a signed document saying that they accept that the servers may rate them however they like.
But the client is still in control, if it sees a server that it does not like, it can choose to not connect, or consent.
The signed document contains the round number, and the public key of the server it is given to. The client fist connects to all of the servers currently running the round, and finds the round number. The client will then look through the record of the servers; the client will look to see if there are many low rated players (more on this later.) If the client likes what it sees, it will give consent (the signed document) to all of the servers. The servers will then send the client their signed document. The client will not be admitted until all of the servers in the round say that they have revived consent from the client.
The server can, once at any point in the round, rate the client on a scale (recommended 0–15). The client will the have the rating perminitally connected to their public key.
This will stop almost all attempts to desynchronize the game. If a server is accusing a client of trying to desynchronize the game; the other servers can look to the plaintiff’s and defendant’s rating, and judge weather or not the defendant is guilty or not. If the servers vote the defendant guilty, its rating will take a plunge; if the servers vote the defendant not guilty, the plaintiff’s rating will take a plunge.
But there is always room for error; and it is almost impossible to fix all of the errors, because there are hundreds of variables, and way more possibilities of what those variables could be.
Why the Rank Matters
People who have the intent of giving innocent players low ranks will have a very hard time. If servers see that there is a player giving low ranks to innocent players, they can do the same to them, and will lower their trust throughout.
Time must also be spent in order to receive high ranks; and people who just want to give innocent players low ranks are not going to waste their time doing that.
But the thought that anyone with a low rank must be someone with malicious intent will push new players away from the game. To fix this, players should need to have rank to give rank.
Whatever overall rank the player ranking someone has, the ranks that they give will be multiplied by their rank (as a percentage or a fraction.) Someone who has a rank of 1/255 will have a smaller impact of a players rank than someone who has a rank of 184/255.
There is also the possibility that two players could rank up to 1/255, and then constantly up vote each other. This could be stopped by requiring a very small fee for ranking, so that money has to be spent to rank each other up; or by limiting a player from ranking another a certain amount of times each block, but this is still not perfect.
If the video game itself is centralized, the single system that keeps track of the ranks will not have any issues when preforming the weighting. But a decentralized video game will need a Blockchain to run the rank. Each rating will be a “transaction.” For each bock, the rating of players will be calculated from the transactions of all the completely confirmed blocks before that. There will be no variable transaction speed so that certain transactions don’t get left behind for a long time.
Is it Even Possible?
No. A decentralized video game round is not possible by any means, there are way too many latency errors associated with decentralization, and players will always find a way to cheat, no matter what.
The ranking system is pretty cool though, it could be used in a decentralized video game with decentralized rounds.
