Radix DLT: Tempo’s Logical Clocks Explained Simply

By Shawn Dexter / May 27, 2018

In a previous post I discussed the various Consensus Methods - PoW, PoS, Tangle & Tempo. Since then I’ve covered a few topics on the most well known of the consensus methods (PoW and PoS). Today, I want to discuss, what I believe is, the most important of the Consensus Methods for us to grasp: Tempo.

Don’t get me wrong – I’m not claiming that Tempo is “better” than the rest. “Better” is subjective. However, I do believe Tempo is by far the most groundbreaking of the Consensus Methods.

Tempo tackles the current issues that plague the DLT/Blockchain world – namely scalability & mass adoption. And it does so effectively. As such, from an enthusiast perspective, Radix’s Tempo deserves our keen attention.

In this post, I want to start with the most important element of Tempo:
The Logical Clocks.

Don’t worry – it’s not as intimidating as it sounds. In fact, we’re going to keep this as simple as possible 🙂

Ordering Of Events – PoW, PoS and Tempo

Far too often people misunderstand the “goal” of a Consensus Method. Most people believe that consensus methods exist to “validate” transactions. But in truth, the focus of a Consensus Method is coming to an agreement on a set of events. And most importantly to:

Come to an agreement on the ordering of events!

In distributed systems, the ordering of events (like transactions) can be difficult. You cannot simply attach a timestamp to an event. Due issues like network latency, each system may witness an event at a different time.

So how are the systems to agree on the different timestamps? How are they to come to consensus on the ordering of events?

Bitcoin’s Proof Of Work uses The Cryptographic Puzzle as it’s core solution to determine the ordering of events.

Ethereum’s Proof Of Stake uses Random Sampling to determine the ordering of events.

And finally, Radix’s Tempo uses Logical Clocks to achieve ordering of events.

Logical Clocks – The Heart Of Tempo

Using normal timestamps for events doesn’t work too well in distributed systems. Why? Put simply – while one system may timestamp an event at 12:01 PM, another may timestamp the same event at 12:02 PM. This will cause inconsistencies – and a failure to agree on the data.

So instead of using a normal clock, we use a ‘logical’ clock. This allows us to place a timestamp that is relative to an occurence of the previous event. The clock cares more about “what happened before” an event than the exact “time” of the event.

Confusing? Let’s try an analogy....

Logical Clocks -A Restaurant Analogy

Let’s say you run a restaurant. Great food & a casual environment. No reservations are taken, you simply walk in and eat!

A typical scenario in your restaurant will consist of the following events in this order

A Patron will:

Walk into your restaurant
Order food
Eats Food
Pays Bill
Leaves restaurant

As a laid back restaurant owner, you don’t care about the exact time he conducts these events. However, you will care about in what order the events are conducted.

For example, if a patron “Leaves Restaurant” , you don’t care about what time he left. Instead, you care about what happened before he left the restaurant.

Specifically you will care if this event happened before:

Pays Bill

If he paid the bill, everything is A-okay. If he doesn’t, you now check what happened before this event. This time, you want to check if this event happened before:

Eats food

If he didn’t eat any food – everything is fine. However, if he did eat food and is trying to leave the restaurant without paying the bill…. Is he dining & dashing?

Uh..oh, possible malicious act detected! Stop him!

If you notice – you don’t care about the time your patron conducted an event. You’re more concerned about the order of the events. This is the “happened before” relationship:

"Patron drank a Peach milkshake" happened before “Patron Leaves Restaurant”

Similarly, Radix's Tempo does not care about the exact time a transaction occurred. All it cares about is the order in which the transactions occur. For a particular transaction, it cares about what "happened before" that transaction.

Let's say Piers and Dan are two nodes in the Radix universe. Piers conducts "Transaction A" at 12:01 pm, right before Dan sends him "Transaction B".

Tempo does not care that Transaction A happened at 12:01 PM. It will, instead, care about this:

“Transaction A happened before Transaction B”

(Essentially, in the Radix universe, each node records events without having to worry about the exact time of the event.)

This way, if Dan sees Transaction A at around.. 12:03 PM (remember, Piers conducted the Transaction at 12:01pm) -- it won’t matter as long as Dan sees that:

“Transaction A happened before Transaction B”

This allows for Piers and Dan to see Transaction A occur at different times, while still achieving consistency… eventually. Because the order of the transactions will be the same.

(Note: Dan and Piers are acting as two Nodes in our system)

ASIDE: Some of you may notice that there are similarities here to the Special Theory of Relativity. If so, you’re bang on… In the Radix Universe, every “node” has its own local clock. The universe assumes that each node will see events at different times, but that eventually everything can be ordered in a consistent manner.

The use of Logical Clocks allows Tempo to place timestamps that are “relative” to each other – instead of absolute timestamps. This allows for consistent ordering of events – regardless of whether they were witnessed at different times.

“So What?” & Final Thoughts

So what’s the big deal? Well, by using Logical Clocks to achieve ordering of events – Radix avoids:

The intensive resource/electricity required by the PoW Hash Puzzle
The capital requirement required for Random Sampling in Proof Of Stake

This allows Radix to achieve scalability while still maintaining the ability for mass-adoption – both of which are sorely needed today. Furthermore, the Logical Clocks also play a key role in the security – but we’ll leave that discussion for another day.

Radix’s Tempo is quite involved. We have a lot more to discuss, namely Sharding, Temporal Proofs and Commitments. We’ll go over these and more in future posts. The Logical Clocks, however, lie at the heart of the Tempo Consensus. And it’s important that we get an idea of what they are before moving further 🙂