- Key Dates
- Development History
- Radix Iteration 1: Blockchain (700-1000 tps)
- Radix Iteration 2: Blocktree (200 tps)
- Radix Iteration 3: Directed Acyclic Graph (DAG) (1500 tps)
- Radix Iteration 4: Channeled Asynchronous State Tree (CAST) (2300 tps)
- Radix Iteration 5: Tempo (1.4m tps)
- Radix Iteration 6: Cerberus
Key Dates
DATE | EVENT |
1979-07 | Daniel Patrick Hughes was born in Stoke-on-Trent, England. |
1984 | Hughes’ father bought him a Spectrum Zx81 computer, which sparked his interest in coding. |
2008-02-25 | Hughes incorporated KDB Technology, a mobile technology company. |
2011 | Hughes heard about Bitcoin. |
2012 | Hughes read Satoshi Nakamoto’s Bitcoin whitepaper. |
2013 | Hughes forked the Bitcoin code to achieve a maximum of 1000 transactions per second (tps). |
2016-12-02 | Hughes and Piers Ridyard incorporated Surematics, decentralised deal-room software for insurance companies. |
2017-07-13 | RDX Works incorporated. |
2019-07-16 | Radix Foundation incorporated. |
2021-07-28 | Radix ‘Olympia’ Mainnet launched. |
2021-12-15 | Radix ‘Alexandria’ developer environment launched. |
Development History
From 2013, Dan began to experiment with various data structures and consensus mechanisms. Each iteration led to insights that have informed the current Radix architecture.
Radix Iteration 1: Blockchain (700-1000 tps)
In 2013, Dan forked the Bitcoin codebase and experimented with different permutations of block size, block times, and hardware. These experiments established that the practical limit of blockchain throughput is approximately 700-1000 tps. A simple comparison with Visa at 24,000 tps meant that blockchains would never work as a global payments rail.
Further Reading
Radix Iteration 2: Blocktree (200 tps)
The limits of monolithic blockchains led to Dan’s first experiments with sharding in the form of a ‘blocktree’: a data structure of multiple, branching blockchains. At this stage, every branch had its own trust boundary, necessitating a complex messaging system to communicate between them. This led to the insight of grouping related transactions together into the same branch. Unfortunately, at around 200tps, any disagreements between branches led to an exponential rise in message complexity as the states reorganized.
Radix Iteration 3: Directed Acyclic Graph (DAG) (1500 tps)
Following on from projects like IOTA, Dan started exploring Directed Acyclic Graphs (DAGs), which allow for parallel, asynchronous processing of transactions. This was also a move away from Proof-of-work (PoW) sybil protection. Ultimately, the lack of coordination between nodes made the DAG vulnerable to double-spend attacks.
Further Reading
Radix Iteration 4: Channeled Asynchronous State Tree (CAST) (2300 tps)
In an effort to contain the message complexity of blocktrees, a CAST separates ledger state from data availability by hosting the former on a blocktree and the latter in a DAG. The way that CAST uses lightweight merkle representations of node votes has been retained but, though an improvement on previous attempts, any network latency still led to an exponential rise in message complexity.
Radix Iteration 5: Tempo (1.4m tps)
Tempo was the fifth iteration of code since 2013 and led to Dan being accepted into Y Combinator in 2017. Around this time the project changed its name from eMunie to Radix.
Further Reading
Radix Iteration 6: Cerberus
Cerberus uses Tempo’s pre-defined shardspace concept but also builds on a number of well-proven cryptographic primitives, giving strong guarantees around safety, liveness and well-defined security bounds. This combines to create a unique BFT-style agreement process enabling scalability alongside security. Importantly for the Weak Atom problem, the security bounds of this can be well-proven and gives strong guarantees around safety and finality.