Tashi Consensus

The consensus layer is responsible for maintaining the peer address book, managing and applying cryptographic keys and functions, validating the stream of messages flowing through consensus, and the consensus function itself.

The algorithm

Tashi's consensus protocol is loosely inspired by Lamport timestamps, hashgraph, and AlephBFT. There are many similarities between Tashi consensus and the aforementioned protocols, but in order to meet the demands of our use cases, we've written the engine from scratch in Rust and made significant modifications. There are two main phases of calculating consensus which we'll briefly explore in this document: Gossip & Virtual Voting.

Gossip

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 peers and from whom 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.

A Tashi event

As peers 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 session.

Virtual Voting

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. Peers 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 peers in the session have seen the inputs, and b) the order of all inputs.

This result provides a deterministic order of inputs, guaranteed to be identical between peers, which allows each peer's computer to pass this stream of inputs into their local application, and, provided that the application code is deterministic, end up with identical results; all without ever using a central authority (dedicated server or host).

The technology

Language: Rust

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 and deploy to just about any architecture.

Hashing Protocol: SHA-256

Hashing is used in TCE to calculate and confirm the synchronization of state across peers in a Tashi session and to facilitate the DAG generation used to calculate consensus.

Signing Protocol: ECDSA (prime256v1)

Cryptographic signing is the core mechanism by which consensus is calculated and trust is generated. Each peer's computer is signing their input messages before they send to other peers in the session and validating the signatures on the received messages from other peers. This is how the peer's computer knows that they are interacting with the true peers in their Tashi session.