√Radix. (English version)

This article was translated by myself. There might be unintentional errors or mistakes. For the original German article, please click here.

Today I would like to present to you a project that the ones of you, who have been around for a long time in the crypto space, might already know. It is a infrastructure project which has been in development for more than five years. The head behind this project began doing R&D on the blockchain protocol, overruled his concept, looked into DAG based solutions, lost 900 BTC of a founding round in a hack (all investors were completely paid out by Dan Hughes – no money was lost for them), started over again with a new concept and did all that to solve the well known problem of scalability. Now Dan Hughes is back, as CTO of the former company eMunie: Radix.

The following post shall give a overview of the project itself and dives into the all-new consensus algorithm called „Tempo“. It is in my opinion crucial to understand this algorithm, especially with so many new projects arising which claim on a daily basis to have solved the scalability issue all and for once.

The project

Since the development began in 2012, eMunie constantly increased the transactions per second throughput in their technology. In the beginning of 2015, only 200 and at the end of 2015 1000 transactions per second were possible. Today, these numbers look like rookie numbers and Radix really pumped them up (yes, I tried to make a Wolf of Wallstreet reference there). After the rebranding and the implementation of the new consensus algorithm, Tempo, suddenly 14000 tx/s became possible. Some months ago they ran tests in which 1 billion transactions were made in one week! According to their road map, the Radix team wants to reach one million tx/s at the end of this year. All tests so far were conducted in a test net and can be  monitored through an explorer specifically built for this. Making a transaction completely for free – like with IOTA- is not possible with Radix: the project aims at a transaction fee equal to one cent or lower, while micro transactions are free.

In addition to these high transactions per second numbers, the Radix team is working on some very interesting features that shall be released in the coming months:

• Smart Contracts are one of the most important features when it comes to new infrastructure projects – and they are possible with Radix. Smart Contracts on Radix will be written in a new, Java Script based, language named Scrypto. This language will be implemented on the testate by the end of this year, will be slowly rolled out on the main net in Q2 2019 and will finally be available in a Turing complete state in Q2 2019.
• As seen with Ethereum, Radix plans to implement a Naming System, allowing the connection between Radix addresses and Text. This would make it possible to send Radix Token like it is possible in the Ethereum network with Ether: Instead of copy pasting a long address, a user could simply send Ether to the connected text string, e.g „altcoinspekulant.eth“.
• Furthermore, and this might be one of the most interesting features to come, Radix will release a developer kit with which anyone can build his own Radix based debit card. This video shows a working prototype. Given the fact that it is planned to develop the Radix Token into a stable Token in the future, this might be the crucial technology to a lot of real world adoption.
• At last, Radix will be fully operational without Proof of Work, Proof of Stake, master nodes or any centralised authority like the IOTA Coordinator. It will be possible to run a Radix node on a Raspberry Pi, too.

At the moment, the London based Radix team, which consists of 14 team members (9 developers), is working at full capacity towards the Alpha Launch, which is scheduled to take place on June 19th. But all these goals would not be reachable without Tempo, the consensus algorithm which lays the foundation for the technology. The algorithm will be explained in the following paragraphs.

Tempo – the brand new consensus algorithm

Tempo is a developed-from-scratch consensus algorithm which profits from using sharing and a gossip protocol. Sharding describes a way of database partitioning (in this case dividing a database in several parts) while a gossip protocol is a way of communication in a P2P network. When using a gossip protocol, sharing information works in a way similar to a spreading disease or a gossip at a workplace (for details information read this wikipedia entry). Before diving deeper, it is essential to understand the following fundamentals:

• A radix network in its entirety is called a Universe
• Each event in this universe, transactions or messages, are represented through an object that is called Atom. Each Atom contains at least one address as their end point (destination), which is generated through the identity (e.g private key) of the receiving party.
• An Atom can either be a payload Atom (e.g a message to one or several persons) or a transaction Atom that transfers property. Atoms may contain other Atoms if they were designed for that purpose

The Tempo Ledger, which underlies the the network, is a distributed database which stores all Atoms of a Universe. Any node can choose weather to store the database as an entirety or only parts of it. The parts, into which the database is divided are called Shards. The amount of Shards that exist are defined with the creation of a universe and can not be changed afterwards. The radix main network will consist of more than 18 quintillion Shards and each nodes may choose which one of them it locally stores.

Now the question arises on how transactions are made, confirmed and saved. To understand this, one has to understand how property is defined in the Radix network , how it changes its owner and how transactions  (events) are ordered in a logical chronology. Why ownership does not play a role with payload Atoms, the ownership on a transfer Atom is defined over so-called Consumables. A Consumable is a piece of code which references the current owner with his private key. Ownership is defined through a chain of these Consumables. To send an object with the help of an Atom to a third party and transfer the ownership of it, the current owner, let’s call him Ernie, has to create a Consumer for this object. This Consumer includes a hash of the Consumable that references Ernie as the current owner of that object as well as a reference to all the consumables of previous owners. This construct now gets passed on via a transaction to the recipient, let’s call him Grover, who then creates a Consumable for this object and adds it to the Consumer. Explained in a simpler way: Ernie owns a chain letter in an envelope which he wants to send to Grover. The chain letter includes the written signatures of all previous owners in a chronological order. To show that he currently owns this letter, Ernie writes his signature on a post it which he sticks on the letter and writes a reference to this post-it below all signatures. With the transfer to Grover, this post it is removed and Ernies‘ actual signature is added to the rest of the signatures. Upon receipt, Grover proceeds like Ernie in the beginning. Of course one has to imagine this process cryptographically secured through public-/private keys and hashes.

Now we can take a closer look at the actual transaction. It is of the utmost importance to every dlt infrastructure that the transactions (events) can be ordered in a chronological way to determinate when a transaction took place. For this process the actual time a transaction was issued is negligible. It is more important, that the network can determine wether a transaction A happened prior to a transaction B (again, the actual time difference between these does not matter, only the result). Looking at Bitcoin, this issue is solved through the Blockchain, where a transaction A happened before a transaction B if it was included in a block prior to the latter one. However, creating a chronological order with Radix is a bit more complicated.

In a Radix universe, each node has a built in meter (like a electricity meter) whose value increases once each time the node processes a transaction (event) it did not know before. This meter is called Logical Clock and its value gets saved with every event that gets saved in the local database of the node. In a next step, we have to take a closer look at Shards. Let us assume again that Ernie wants to make a transaction to Grover. The Atom which he wants to send, is saved in the Shard with the index one, while Grover’s recipient address lies in Shard 3. At this point we have to remember that Sharding means a split database with nodes deciding which Shard(s) they save. This means that in the current example, the transaction is only of interest to nodes which possess a copy of Shard one, Shard 3, or both. Before this event is sent to all these nodes, it has to be checked and confirmed. This process includes a variable number of nodes (the more the less discrepancies will occur in a Universe) which obtain the according shards and is called Temporal Proof. To establish Temporal Proof, Ernies node takes a closer look at Shard one and determines wether the object he wishes to transfer was not already spent and that the transaction is correct (if there is a discrepancy the transaction is rejected). If everything is correct the node decides on the number of nodes that will be involved in the Temporal Proof process (and that are directly connected in the network – if no proper nodes are found the search radius is widened) and sends it to the next node (randomly chosen). With each check the nodes add the so called Space-Time Coordinate (l, e, o, n) to the transaction and send it on. This Coordinate contains the current value of the Logical Clock (l), the Hash of the transaction (e), the identity of the current node checking the transaction (o) and the identity of the next node checking it (n). After the transaction was checked by each node and no discrepancies were found, it is considered confirmed and gets sent on to the rest of the nodes which obtain Shard one, 3, or both (Finalisation). With the successful transaction from Shard one to 3 any changes in ownership of the sent Atom would only be of relevance to Shard 3 in the future (except it gets sent back to Shard one) and would not have to be saved by nodes with Shard one. The confirmation itself of a transaction should take less than 5 seconds.

Obviously there may arise conflicts in such a distributed database.  Even though most can be solved through nodes gathering additional data from their neighbours (through gossiping) and comparing logical clock values of a transaction, I do not want to dive deeper on this topic as it would increase the length of this post significantly. If a conflict or discrepancy can not be resolved, the involved transactions can not get confirmed. According to Radix it is impossible that a transaction gets confirmed without being correct. More about conflicts can be read in this section of the Radix Tempo whitepaper while potential attacks get discussed in the Radix blog.

Node incentives and investment opportunities

The incentive to run a node in the radix universe is the fact that one gets paid for useful work though a mix of transaction fees and inflation. For this I point, too, at the according Radix whitepaper. At the moment, the specifications of this inflation as well as investment opportunities have to be revealed by the Radix team in the much anticipated economics whitepaper (which should be released within Q3). All we know is that the Radix Token will be distributed through the decentralised Radix exchange in Q4 2018. It may be that there are more informations revealed in the telegram channel prior to the release of the paper

All together I believe that Radix has an enormous potential – maybe even IOTA like. This obviously would require the tech to work as outlined. One should definitely try to keep updated about this project and I will attend the Radix Alpha Launch in London on June 19th to write further about this project.

-Lukas Fiedler

Disclaimer: The author is invested in the crypto currencies named above or may be invested in the future.