All posts in " Radix DLT "

The Radix Saga: Part 1

By Shawn Dexter / December 1, 2020

The Promise Of Possibility

A Necessary Perfection

Over the past year, the DeFi ecosystem has taken the crypto world by storm. With repackaged branding and bandage-fixes, most projects have only now hopped onto the DeFi bandwagon. Hidden with this charade, however, exists a team that has spent nearly a decade engineering an elegant future-ready platform to put all-others to shame...

Back in 2013, visionary Dan Hughes foresaw the inefficiencies that would eventually come to plague the DeFi space. Of course, “DeFi” wasn’t even a well-known term back then. But Dan was thinking far ahead of his peers. Inspired by Satoshi Nakamoto himself, Dan envisioned a truly globally-scalable platform that would revolutionize the world as we know it. 

Led by this coding genius, the Radix team has discarded iteration after iteration of consensus-models. Each of these iterations were cutting-edge innovations. But to Radix — none of them were good enough.  They were stubborn in their pursuit of a truly world-breaking innovation.  Some would say their approach to innovation was “perfectionist”, but Radix would argue that their approach was “necessary.” After all, Radix is embarking on a herculean mission that demands nothing less than perfection itself.

A Trillion Dollar Ambition

Scalability is often touted as the next big step for the DeFi Ecosystem. But that begs the question — what does scaling even entail? How “much” do we need to scale? And scale for “whom” exactly?  The Radix team have been obsessing over these questions over the past decade, and they have found the crypto-space severely wanting.

The global financial services industry (lending, borrowing, payments etc) is estimated to be worth $25 Trillion dollars. Crypto DeFi is only a tiny fraction in comparison and still wasn’t able to meet the throughput requirements. The rebuttal to this is often “Ethereum 2.0 will solve the scalability and throughput problem”. And perhaps it may — but not without a host of other problems that lead to bottlenecks on the road to global adoption.

Dan Hughes was able to foresee these crippling hurdles all the way back in 2013. Even four years later, while everyone was touting “scalability” as the new buzz word, Dan and his team were working tirelessly away at problems that hadn’t even been discovered yet. Radix sought to engineer a solution that would be battle-ready for the demands of the trillion dollar industry that not only needed scalability — but security and ease-of-use as well.

A Four-Pronged Attack

Although extremely ambitious, Radix’s mission statement could be summed up in a single simple sentence: 
A decentralized protocol to serve as the backbone of global finance.

A simple sentence indeed — but an almost impossible task. In fact, achieving this would entail battling one of the hardest problems in Computer Science. The Blockchain Trilemma states that a system cannot have all three: Security, Scalability & Decentralization without compromising on at least one of them.

Radix, however, didn’t just want their platform to fulfil all three of these criteria — but they insisted on the fourth: “Ease Of Use”.  Again, while this may sound simple on paper, it would require the genius of Dan Hughes and his team to see it fulfilled. 

Even the team at Ethereum struggle to provide ease-of-use to their community. While Ethereum 2.0 may eventually deliver on its promise of scalability, it will do so by adding increased complexity to an already unsavoury development experience. This makes future development efforts prone-to-error, laborious, and expensive — all of which are likely to hinder adoption.

In fact, this is a problem that plagues every major project in the DeFi space. As soon as a team attempts to tackle one problem, they inevitably sacrifice a value offering on another problem. For example, the solution provided by Ethereum 2.0 brings to doubt its core-value proposition in the DeFi Space. For while Ethereum’s solution may provide scalability, it also hampers the seamless “cross-chain composability” that made DeFi effective in the first place.

Radix realized that the only way to escape this “trap of compromise” was to approach the problem differently. Instead of trying to solve “one problem at a time”, they opted for a four-pronged attack. Tackling all four problems holistically would allow Radix to craft an innovation where each one of the solutions “complimented” each other, instead of “compromising” on each other:

  • Scalability with Composability
  • Security
  • Decentralization
  • Ease of Use

But achieving this feat would be no small matter. In fact, it would be a gargantuan task — the likes of which would raise the eyebrows of the smartest minds in the space. Dan Hughes, however, would settle for nothing less.

A Composable Solution

After years of sweat and blood, the persistence finally paid off. Radix’s stubborn determination bore fruit to what could potentially be a world-changing innovation: Cerberus — the heart of the Radix protocol.  

Cerberus, aptly named after a mythological multi-headed guardian, was Radix’s statement indicating that they have finally arrived for the grand stage. It promises to encapsulate every feature the team envisioned in their dream protocol — a protocol that would serve as the backbone of the global financial system.  

“We spent years building, so you don’t have to”
Dan Hughes

By incorporating a unique shard-first  approach, Radix was able to elegantly solve each of the aforementioned problems. Not only does Cerberus provide a novel answer to the Blockchain Trilemma, but it does so while still maintaining ease-of use &  composability — a core feature to ensure the success of the DeFi ecosystem.

Put simply, Cerberus’ pre-sharded architecture allows Radix to leverage the benefits of sharding while still maintaining seamless communication between the shards. This means that apps living on different shards can interact with each other easily (aka cross-shard interoperability) This is far more crucial and ground-breaking than it may seem.  In future articles, we will provide simple explainers to all of these concepts and how Radix tackles them.

Like pieces of a jigsaw puzzle finally coming together, Cerberus is a picturesque piece of engineering where every component compliments the other.  But will Radix achieve its eventual goal of global adoption? There’s definitely still a long road ahead. And at Mango; we’re excited to explore the technology further.

Continue reading >
Share

Radix DLT: Tempo’s Logical Clocks Explained Simply

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:

  1. The intensive resource/electricity required by the PoW Hash Puzzle
  2. 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 🙂

Read Next:   Radix: Sharding Explained   or   RadixDLT: The Future Of Crypto?


Did this post help you?

Help Us Keep Doing What We Do Best!

Tip Jar 🙂

BTC: 3LrzDr7ZYQ5xWAKnweM1XuUAvU5YEkF7Zb

ETH: 0x87ba0C08910Dbd3b93D74A2A3b61d78A3C2dbDab

Did you enjoy this post?

Help Us Keep Doing What We Do Best!

Tip Jar 🙂​​

BTC: 3LrzDr7ZYQ5xWAKnweM1XuUAvU5YEkF7Zb

ETH: 0x87ba0C08910Dbd3b93D74A2A3b61d78A3C2dbDab

Get my upcoming eBook for Free!

"The Mango Guide TO Understanding Blockchain"

Offer Valid For FIRST 500 registrations only

No menu items have been found.
No menu items have been found.
Continue reading >
Share
>