Multiplayer netcode where all units, including server, are untrusted - possible, feasible, etc.?

Question

Most professional video games use either a peer-to-peer architecture or a client-server architecture. In the former, clients often trust each other, and instead employ anti-cheat techniques to ensure that all clients are using the same version of the game. In a client-server architecture, the company-owned server manages the game, and each client only needs to trust the server without trusting any other client.

My question is: how might I write a game network architecture such that the server is not necessarily trusted either (e.g. it is another client, or is buggy, or has been compromised), and do so in a way that does not take too much processing power away from the game?

I know that the blockchain algorithm (as infamously used by Bitcoin and other cryptocurrencies) does provide this as long as at least half of the computing power is owned by trusted machines. While this may work for long-term actions (such as match verdicts), it doesn't work as well for the frame-by-frame actions of action games and can also be too slow for turn-based games, to say nothing of the computing power it requires of the clients or of any dedicated servers.

Answer 1

The client is in the hands of the enemy

I forgot where i read this, but it's really useful while coding client-server architectures. Basically it means you can't trust the input from the clients and have to check if it's possible. In your case you also have to check the input you get from the server.

For Example:

• Strategy: keep also track of enemys resources and units. Is it possible to build them? How fast are they?
• Shooter: How much ammunation does the enemy have? How much did he use? Is his movement valid?

These checks should not take too much time in your gameloop and can at least verify if the actions are allowed.

The Problem with this solution is, that your client has to know everything. So it's easier for hackers to see where the enemy is, how much resurces he has, and so on.

In an standard client-server architecture the server decides which input is valid and which one is not. In your architecture each client decides this for himself. So maybe display a warning that the recieved data is inconsistent. The Players then can decide if they want to keep playing, or end the game. (Only show this once a match!)