Comment on page
Core Concepts
How does Tashi work?
Tashi fundamentally changes how we think about multiplayer games. Traditionally multiplayer games come in three flavors:
- 1.Server-Client: A dedicated server is hosted by the publisher or a player. All other players connect to the Server, which acts as the authority for the game state.
- 2.Host-Client: One of the players is selected as the "server". This players is both a client and a server and is the authority for the game state. Certain kinds of cheating depend on this type of configuration.
- 3.Peer-to-Peer: Also known as P2P. In this model, all players are clients and pass each other their "moves", then each client updates their game state locally. In this scenario the clients (peers) trust each other's moves. Certain kinds of cheating exploits this "trust" between clients.
TCE takes this model to a new level. In Tashi:
- All clients are also servers. You can think of this as a "Mesh Multiplayer" configuration.
- The servers all calculate consensus between each other. A high-level explanation of how this works might look like this:
- 1.All clients report to their local server their proposed "moves" (inputs)
- 2.All players' servers in the game session gossip with each other, broadcasting their local inputs and any inputs they've received from other players
- 3.Each player's server validates the sender of the input message and that the message is structurally valid.
- 4.Using the Tashi consensus protocol, all servers calculate consensus when they can confirm that more than 2/3 of the players in the session are aware of the same input message.
- 5.Each server then processes the inputs in the same order, validating the inputs against the local simulation, then applying any state changes to the local state.
- In this way, players can play a game without any leaders (host or dedicated server) and be guaranteed that all players remain in sync with the presence and order of inputs from all players at all times.
Tashi's consensus protocol is loosely inspired by the hashgraph algorithm. There are still two main phases of calculating consensus which we'll briefly explore in this document: Gossip & Virtual Voting.
The gossip protocol for Tashi can be described as a "gossip about gossip" protocol. This term was originally included in the hashgraph white paper and refers to the concept of not only sharing your inputs, but also sharing the inputs you've received from other players and from who you received them. You can think of this as wrapping all of your inputs into a message, applying a timestamp to the message, including a reference to the last messages you received, signing the message cryptographically, then sending your message to others in your session. As players receive these messages from others in the session, they can build a Directed Acyclic Graph (DAG) of how everyone learned of all inputs in the game session.
The most direct method of calculating consensus is to just take a simple vote. You can ask all participants in the session to cast their vote about when they saw a message and what the timestamp of that message is. Voting algorithms have been around longer than computers and are the surest way to reach consensus.
The problem with simple voting in a distributed network is that it is expensive. Players must first be aware of the inputs, then they must broadcast their vote, then someone has to gather the votes, tally the results, and broadcast back to everyone else. If you want to avoid a leader, you can have all participants message each other with their votes, which is even more inefficient.
This is where Virtual Voting comes in. Instead of passing around votes, each participant just gossips what they receive and what they create, and by doing so develop a DAG. Each participant can independently evaluate the DAG using a virtual voting algorithm to calculate how every other participant would have voted. The key insight here is that a participant's vote is thought of as being attached to a message, and which votes are attached to a message is decided by a deterministic function whose sole input is that message's ancestry. Because all participants see the message's ancestry, they can each run that deterministic function locally to determine what votes would be attached to that message, and so the votes do not actually need to be sent. In other words, the voting data is passively included in the gossip data, and we use mathematics and cryptography to determine: a) that greater than 2/3 of the players in the session have seen the inputs, b) the timestamps of all broadcasted inputs, and as a result, c) the order of all inputs.
This result provides a deterministic order of inputs, guaranteed to be identical between players, which allows each player's computer to pass this stream of inputs into their local simulation, and, provided that the simulation code is deterministic, end up with identical results; all without ever using a central authority (dedicated server or host).
We implemented TCE using everyone's favorite low-level language, Rust. This allowed us to take advantage of Rust's memory safety and general performance efficiencies. It also allows us to build for any major architecture and deploy to any game platform.
Depending on the network configuration, two modes are available. When integrating with services like Unity's Relay, you must use UDP (though we still use QUIC, just tunneled through UDP). Other services, like Tashi's Relay or peer-to-peer configurations, can take advantage of the reliability, congestion control, and multiplexed streaming capabilities of QUIC directly.
QUIC is the preferred configuration.
TLS 1.3 is the latest version of the TLS protocol used for network encryption. The latest version includes performance and security improvements over previous versions of the protocol.
Hashing is used in TCE to calculate and confirm the synchronization of state across players in a Tashi game session and to facilitate the DAG generation used calculate consensus.
Cryptographic signing is the core mechanism by which consensus is calculated and trust is generated. Each player's computer is signing their input messages before they send to other players in the session and validating the signatures on the received messages from other players. This is how the player's computer knows that they are interacting with the true players in their Tashi game session.
The Tashi Network Transport is an SDK that wraps TCE and makes it available within a game engine. Most game engines provide a Network Manager component with pluggable transports.
The goal of TNT is allow game developers to simply select TNT as the network transport, configure the TNT component within minutes, and build a multiplayer game using all of the existing multiplayer game development paradigms that already exist. Theoretically an existing multiplayer game could import TNT, make some minor configurations, and the game would continue to work as expected. This is obviously contingent on the complexity of the netcode in the rest of the game.
TNT is currently available for Unity, but plans for providing libraries for Unreal Engine, Cryengine, Godot, and Bevy are in the works.
Last modified 3mo ago