The problem Servo solves

While Web3 has seen rapid growth in recent years, it has been primarily geared towards single-player or non-time-sensitive applications. Traditionally Web3 gaming takes on two categories: complex and immersive single-player games or slower-paced multiplayer games (like blackjack or poker). Fast-paced multiplayer games have been delegated to the Web2 realm. More focus must be placed on creating immersive multiplayer games on the blockchain and we contend that doing so will greatly improve the Web3 experience since much of the appeal of the Internet lies in our ability to interact with our friends. Just as importantly, and perhaps counter to conventional opinion, we contend that this decentralization of gaming will actually reduce latency and imporve performance because players are not forced to route their traffic through a server.
We built a protocol that people can use to play two player competitive games without having to trust the player that they are playing against. We wrote a whitepaper explaining this protocol. We also built a game that people can play to test the performance of the protocol. The protocol utilizes smart contracts to solve disputes between the players, so we wrote these contracts for EVM chains and for Solana. Our protocol does not require the user to sign a bunch of transactions interrupting their gameplay. The only time the blockchain is involved is when ther is a dispute between players, which will never happen if both players are honest. The protocol is insecure if the rulesets agreed upon by the players favor one player over another. However, this will only happen if one player deliberately accepts a ruleset unfavorable to them. At the beginning of the gameplay, when rules are being exchanged, either player can back out with no penalty. Also, the protocol penalizes players for leaving the game, automatically declaring the other player the winner. We encourage you to read the whitepaper where we fully explain the protocol in depth.

Challenges we ran into

The biggest challenge we faced was designing an algorithm that protected both players but kept latency low. We ended up having to design our own protocol from scratch because everything else we tried (zk, only blockchain based) was simply too slow. We solved it by persevering and opting to use program-managed temporary accounts to sign ordered blocks sent between the players instead of having all user data sent through the chain or by having computationally intensive zk proofs created. We only involved the chain if a dispute was raised and the chain had to arbitrate. At that point, the game is paused until the dispute is solved. We also had to build the game engine in pure typescript, which was much harder than using existing game libraries. We needed to do this because we needed the low level control to record user operations so that the other user could validate them when the block is sent over. We chose to build the protocol specifically for two players because we thought that it was more interesting and we didn't see anything else remotely similar in the space. That ended up being more difficult route because we had to invent everything from scratch. Existing technology simply cannot find consensus if there are only two players in the network. In the end, it was worth it, because we created something new. It was also a challenge writing the whitepaper because we had to think of ways that people could try to cheat the protocol.