Back in 2008, I have a strange idea to reduce server side computation needs for a web game. I came out with a concept to let the client compute all the validation in order to minimize the servers load. However the validation result can be easily manipulated if it was only done on client side.
At that time my thought was: in order to "secure" the validation, it must be done on server. Yet it eliminated the purpose of introducing the concept in the first place. Validation that done on client side can only have one advantage, it provide blazing fast respond as all the validations are done locally. The front end can react to the user action as soon as possible before even the actions are submitted to the server. If the actions are invalidated by the server, the server can simply respond with a roll-back request. This technique was seen on many MMORPG built with native code even at that time to give an illusion to the players the game is running smoothly by responding to the user action as soon as possible. Although dissatisfy with the dumb idea, i am happy with the accidental outcome.
Further thought, I came out with a variation of the concept, which is letting another client that is not participation in the same game session to validate a player action. However the idea bring me another question which is, "what if a client decided to screw with the system by purposely sending the wrong validation results?: It would be result in total chaos! Still, back to the basic, I told myself 'the user cannot be trusted!' This lead me to a dead end and I had stopped thinking about (not exactly stopped, i just don't spend much time into solving the problem).
Recently, I had a sudden interest to develop a web based sandbox game which sparkled the old problem I tried to solve. After scratching my head for quite awhile, I came out with a way that i think suited my needs. I asked myself, "What if the validations are computed by more than one client?" "This could be the solution to the problem!".
So I started to think with this direction, server will assign clients (assume 2 clients) that ain't involved in the game session to do the validation by providing them the necessary data like game state, actions, etc. As long as more than two clients did the validations and send the result back in hash form, server side can easily check the validity of the validation by comparing the hashed results. If the results wasn't matched, the server can then fall back to use its own computation power do the validation by itself. With this idea, the server can eliminate almost all of the needs to validate the actions done by the player. Even better if the back end will assign each validation to be done by different clients every cycle of the game. By randomizing this, there is almost no way that a player can cheat. If a client doesn't send the result in timely manner, the back end can simply flag it as 'timeout' and start comparing with whatever results it had gathered. Worst case scenario, the server will just do the computation by itself.
Of cause, the concept isn't without its cons. The most obvious disadvantage I can think of is the latency issue. Yet it is easily tolerable by using the 'action first check later' technique that I had mentioned earlier in the article given that your game or application have certain level of fault tolerant where roll-back is possible.