Coin Spotlight

Radix DLT

 

Radix DLT is something else. It is a project I am extremely excited about as it represents an entirely unique approach to distributed ledgers. As incredible as the protocols we have today are, very few come close to the foresight, simplicity of engineering and architecture of this project.

Part 1

Distributed ledger technology (DLT)

Bitcoin uses a technology we refer to as a blockchain which is fairly intuitive and linear data structure for ordering transactions and timestamping events. The term “blockchain” is often used as a misnomer for the entire crypto industry however only represents one form of a broader set of distributed ledger technology (DLT). A blockchain is similar to a “vertically” scalable database where more computing power improves performance and speed of the network is limited only by the fastest nodes (think of it as a circuit in series in electrical terminology).

Figure 1 – Linear data structure of a blockchain which timestamps order of events via a unique hash (Source)

We have seen new data structures emerge like Directed Acyclic Graphs (DAG) in Nano and IOTA and implementations of sidechains and child-chains in sharding architectures. These new data structures are usually attempting to solve the scalability problem faced by linear blockchains where the full overhead of the ledger must be run through the entire network. In other words, in a blockchain, every transaction is passed through every node. DAGs are said to be horizontally scalable by running multiple database streams in parallel where more streams = more capacity (parallel circuits).

 

The biggest challenge with horizontal scaling is that security on the data streams is reduced as not all nodes can watch all shards and there is a reduction in overall validation power on individual shards. Bitcoin is so secure because every single node knows about every single transaction and thus there are many copies. Furthermore, sharding of DAG structures become complex in ensuring enough nodes are across enough shards to prevent a double spend. this problem is further complicated by transactions created offline and then forwarded to the network. As a result, most DAGs only confirm transactions when the sender and receiver are online and are able to interact with the transaction (i.e. you cannot receive a payment until you are online).

 

With sharding, the data is split into multiple blockchains with cross chain communication so the network can scale with the number of shards. With both of these approaches however, the overall consensus of global state is a challenge – how do you ensure absolute security and finality (immutability) by communicating the state of each parallel channel cross the network without overloading the “mainchain” or compromising security.

Radix DLT

This is where Radix  DLT has set out to create something unique. What fascinates me about Radix is that the lead architect Dan Hughes has worked on the project for a number of years and has actually stepped through the process of creating all the aforementioned data structures. Starting with a blockchain, moving to a sharded blockchain and exploring the use of DAG architecture. Through this process he was able to fully appreciate the limitations and challenges associated with each and eventually turn to a unique solution of a “floating” data structure with a maximum of 264 shards. That is          18,446,744,073,709,600,000 shards and is enough to store the entirety of Google in 2kB pieces!

 

Where as most DLTs focus on distributing shards or child chains between fixed nodes – Radix has flipped the model and allows nodes to be flexible across as many or as few shards as they want. A super computer may sit across the entire network where as a raspberry pi can sit across a handful of shards as allowed by its limited computing power. Nodes dynamically adjust according to their computational capacity and communicate/gossip only changes in their state rather than the complete set of information in their ledger.

 

Similar to Nano, each account is effectively an individual shard. When a transaction occurs this links two shard together (which may or may not have previously interacted). The nodes on the sender and receiver shards now reshuffle to they can validate the transaction and create temporal proof which signs that these two shards have interacted in the past (temporal proof discussed later)

 

The system reduces network overhead by two simple concepts:

• Assumption that a transaction only has interaction with the sending and receiving shards and thus the rest of the network does not need to know about it immediately (i.e. two events can happen in the Universe which have no impact on each other and thus need not be communicated)
• Assumption that the vast majority of transactions are valid until proven otherwise. Rather than a blockchain where every transaction is screened by the whole network, Radix assumes transactions are ok until a double spend is identified. This reduces network overhead, data requirements and leads to a more efficient network. Since most nodes will sit across the same group of shards, they will be able to determine if a double spend has occurred by communicating with their immediate network.

 

The tempo ledger

The tempo ledger draws upon the concepts of space-time (hectic right!) to maintain a record of transactions and the history of atoms.

 

To simply describe the Tempo ledger:

• An instance of Tempo is called a Universe (smaller Universes can be deployed for private application)
• Each universe contains a pre-determined number of shards which is fixed once the universe is deployed
• An action or transaction is called an Atom of which there are two types
  1. Payload atom = a simple signed communication and data transfer
  2. Transfer atom = exchange of value and ownership
• Atoms can exist inside atoms creating more complex transactions (think smart contracts where different atoms are executed after conditions are met)
• Atoms require an origin and a destination shard to be defined and can have multiple depending on complexity of the transaction and signatures required (i.e. multi-send and milti-sig)
• Consumables are ownable assets (tokens) which have an auditable trail of atoms describing who owned the consumable and when
• Since atoms are present in any shards they interact with (origin and destination), the more shards it interacts with, the more nodes know about it and thus the greater the data redundancy
• Each node has a logical clock (like a nonce in Ethereum) which increases by one every time a new event is observed by that node. A send, receive or observation of another atom will increase the logical clock by one.
• Atoms are assigned to nodes which sign with what is called a Temporal Proof which gives the atom coordinates in the Universe at the time of its validation

Temporal proofs

Since nodes are not required to store the entire ledger, a system is required to validate an atom’s validity to prevent a double spend. Before an event is broadcast to the entire network, a sub-set of nodes perform a validation which results in a Temporal Proof being created and assigned to that Atom.

 

The first node to see the atom (Node O) will be located on the atoms origin shard. Node O will then locate a random node (Node N) which sits across either the sender or receiver’s shard and assign it the job of creating a Temporal Proof. This Temporal Proof defines the time (logical clock / nonce) and space (Node ID) at which the atom was observed and processed.

 

The creator of the atom can specify the length of the temporal proof – that is the number of times this Hash(L,E,O,N) need to be completed which is akin to number of confirmations. The more nodes which append their proof, the more secure the atom.

 

A temporal proof is a space-time coordinate containing four parts:

1. L = Logical clock of the node (N) who first observed the event (this proof increases it by one)
2. E = Hash of the Atom (the Atoms ID)
3. O = ID of the observer node (N) (This will be the same for all confirmations)
4. N = ID of the node creating the temporal Proof (P) (this will change for each node who confirms)

 

The atom now has a string of space-time coordinates which can be used to verify it’s existence as well as provides the network with a traceable path to follow in the event of a future conflict.

Vector clocks

When a discrepancy such as a double spend is detected, the coordinates (L,E,O,N) can be used to construct what is known as a Vector Clock – an order of operations using the node Logical clocks from directly and indirectly associated atoms. This allows nodes to communicate and find some combination of atoms, nodes and other vector clocks within the many shards on the network that eventually confirm the order of events.

 

This seems like a complex process to the human mind and takes a few rounds to digest how it works however can be computed by the network extremely fast. In as simple terms as possible, nodes use space-time coordinates (L,E,O,N) to find:

• A node who was involved in the Temporal Proof
• A node who is on the same shard as one who performed the Temporal Proof
• A node who is on the same shard as the one who is on the same shard as one who performed the Temporal proof
• A node as above who has been involved in an atom which has anything to do with the above
• Until eventually, enough order of operations can be found to correctly sequence the events

 

Its like a ‘who dun’ it’ murder mystery where evidence is collected from around the network until a confident deduction can be made as to the order and sequence of events.

 

There is some serious mathematics at play here but really, it is a simple principle. Find as many coordinates as possible which are even loosely associated with the conflicting atom (anything containing same node, same shard) and use them to deduce the actual order of events to determine if the conflicting atom is valid or not. It is a massive power of deduction problem which in reality can be performed very quickly given the low overhead as this process is only undertaken when a conflict is identified.

 

To aide this process, nodes regularly “gossip” where they send random packets of information regarding their global state of the shards they are currently monitoring to other nodes. Since nodes know which shards other nodes are across, it becomes trivial to broadcast a message to find a node to resolve a discrepancy.

 

Check back in for Part 2 of the Radix Project covering the Node incentives, economic model and how token issuance builds the value of the XRD currency.