Why Tashi

TLDR;

  • Tashi has developed its own consensus engine, applying the principles learned from the most efficient and performant projects in the Web3 space

  • Tashi is developing a platform and architecture on which 3rd party developers can build projects using our Mesh Application (MeshApp) pattern

  • MeshApps are micro-networks leveraging Tashi's consensus Engine (TCE) to enable pure peer-to-peer activities without the need for leaders or servers.

What's consensus?

Simply put, consensus is the ability for independent parties to come to an agreement of some facts. In computer systems, it's the mechanism by which the computers agree to the state of the system. The most direct way to reach consensus is to take a vote:

  1. All peers observe activity on the system

  2. Each peer casts a vote on the state of the system

  3. Someone tallies the votes from all peers

  4. That someone notifies all peers of the result of the vote

This may require multiple rounds to agree on a specific state because, in each round, the result of the votes may not be definitive. With this simple voting algorithm we observe that a single activity will require at least a proposal, a vote from each peer, a calculation of the result of the votes, and a broadcast from the vote-counter to the peers of the result.

The problems with this simple approach are:

  • One activity results in many messages. The chattiness of a protocol like this is not practical.

  • A leader is required to tally or count votes. This leader has the power to delay or omit votes in such a way that could affect the order or inclusion of messages.

  • The goal of a protocol like this is to obfuscate leader selection so as to protect the next leader from attack.

There is another way

At Tashi, we've learned from the best. Inspired by Lamport timestamps, Leemon Baird's Hashgraph, and AlephBFT, we developed a leaderless voting algorithm that results in a guaranteed ordering of messages between peers with low latency finality and high throughput, and our goals were ambitious. We understood that in order to make Web3 technology viable for the existing Web2 space, we had to build something that didn't add any friction to the incumbent systems while still adding value. We chose to test our assumptions using multiplayer gaming as a forcing function for performance while ensuring fairness and security.

We built this consensus engine using the Rust programming language. The decision to use Rust was driven by the desire for a low-level language that embodied safe memory guarantees and a mature ecosystem of system-level libraries. Rust allowed us to write performant, low resource, and reliable code.

In 2022, we built our first proof of concept to prove that a consensus engine could be fast enough to support multiplayer gaming. We knew that the use case of multiplayer gaming required very low latency and moderate throughput. Games can operate at a finality latency of <100ms, but most multiplayer games require latencies <50ms. We were able to reach latencies as low as 28ms for peer-to-peer gaming. In 2023 we presented at Devcom in Germany and demonstrated Unity's Boss Room demo running as a multiplayer game with no peers and no hosts, strictly peer-to-peer.

Once we showed how to use Web3 technology in a very demanding Web2 use case, we knew that we could apply the same technology to other use cases. We decoupled the platform into three layers:

  1. Tashi Consensus Engine (TCE): This layer is responsible for the functions of handling messages, cryptography, and calculating consensus.

  2. Mesh Network (Mesh Net): This layer coordinates the network over which TCE operates. This includes functions like peer discovery, peer-to-peer network connections, NAT hole-punching, and relay where direct peer-to-peer fails.

  3. Mesh Application (Mesh App): This layer is the application running on a mesh net. Provided that all peers are running compatible versions of a mesh app, the state of their application is guaranteed to remain in sync.

Last updated