Radix is a little different from other DLT technology. This documentation should help clarify points. If you have any further questions - please join our Telegram group: https://t.me/radixDLT
Below you’ll find the FAQ, a discussion of attack vectors, and a glossary to help you learn about Radix.
Thank you for your interest.
Radix is a high-throughput platform to build and distribute decentralized applications.
In research and development since 2011, Radix DLT is the first, infinitely scalable, Distributed Ledger Protocol for trustless systems. It is an eventually consistent distributed database, with absolute ordering of related events and n-1 fault detection. It is specifically designed for ease of use and to run on resource restricted devices, helping drive both mass adoption and for use in the Internet of Things (IoT).
The Radix platform will enable developers to create, distribute and manage highly scalable, efficient and secure distributed applications for both public and private networks.
The Radix Public Network is a modular, general-purpose, global computer for decentralised applications that enables inexpensive and scalable transactions at incredible speeds with near-instant finality.
Radix offers a novel distributed ledger architecture for decentralized applications, that is sharded to scale in an efficient, unbounded linear fashion combined with a secure consensus algorithm called ‘Tempo’.
Radix scales linearly(and thus infinitely) as new nodes join the network using the theory of sharding, without compromising security. It enables resource-restricted devices to run a full Radix node on as little as 16MB of memory and a 100 Mhz processor. This enables inexpensive, scalable transactions at incredible speeds with near-instant finality.
Furthermore, Radix is also actively developing modules for:
To achieve speed, scalability, security, and efficiency, Radix has created a combined distributed database architecture and consensus algorithm called Tempo. It is the core module of the Radix platform. It uses vector clocks for generating a partial ordering of events in a distributed system to detect and prevent causality violations.
This system is both “asynchronous”, meaning there is no block time, and byzantine fault detective, meaning that it can detect and stop false transactions and double spends within a system that anyone can join.
Tempo does this by preserving the total order of events, allowing for the trustless transfer of value, timestamping and other functionality. It is a semi-structured, shardable architecture that limits state transfer information to only those members of the network that need it. This reduces overhead and increases performance.
It does not require large amounts of computing power (PoW) or large amounts of capital (PoS) to secure it. It is suitable for both public and private deployments, without modification, and requires no special hardware or equipment.Combined with a huge, overlapping shard space, the scalability of Radix is only constrained by the number of Nodes operating within the network.
Radix is built on a combined architecture and consensus algorithm called Tempo, which is fully outlined in the Tempo white paper that can be found here: http://bit.ly/2ADK8LA
The aim of Tempo is to create a trustless, decentralized consensus algorithm that can work reliably as a public network. To do this it must be:
To achieve this, Tempo relies on a two simple ideas, and one logical leap:
A logical clock is a counter that is incremented by 1 every time something new happens. On Radix, “something new” is when one Node speaks to another in the Radix network. This gives every Node their own relative time, based on network activity, and one they can use to create a simple order of events.
Gossip protocols are well established in computer science and are one of the fastest ways in which information can be reliably shared across a network. It works simply by a Node choosing a couple of other Nodes to tell something new to, and they, in turn, tell two other Nodes, and so on and so on. This causes information to spread at an exponential rate.
On Tempo, we add the Node logical clocks, signed by the Nodes in question, to the gossip they are spreading around the network. This allows everyone to see both new information, and at what logical clock time that information was seen by other members of the network.
To allow high scalability a Tempo ledger is split into a very large shard space, allowing a huge degree of concurrency. To avoid a double spend across any of the shards, the shard a wallet lives on is determined by its public key. This makes sure that any spend from a wallet will always start on the same shard.
When combined with the logical clocks and gossip, this Tempo to always find the total ordering of related events, allowing double spends to be quickly detected and ignored.
Daniel Hughes, chief technical officer of Radix DLT invented the Radix platform and ‘Tempo’ - it’s underlying engine.
In 2011 Dan Hughes, the founder of Radix, discovered Bitcoin and was instantly hooked by the underlying elegance of its distributed protocol. Having tested the limits of distributed ledgers based on blockchains, block-trees, and directed acyclic graphs(DAG), he found they all had a fundamental inability to scale. He dedicated his time developing a highly scalable distributed ledger technology platform. Five years in R&D and after many iterations he eventually invented ‘Tempo’ - a novel distributed ledger architecture for trustless systems, that is sharded to scale in an efficient, unbounded linear fashion.
Please see our team page here: https://www.radixdlt.com/#team
Mass adoption of cryptocurrencies is impossible without a means of achieving both transactional scalability and price stability - Radix is designed to solve these issues.
Cryptocurrencies such as Bitcoin and Ethereum are beginning to attract the attention of mainstream media thanks largely to their massive rise in value over the past year. The world is starting to realize the potential of blockchains. It has become increasingly evident that decentralized networks, running on distributed ledgers and token economics, will radically change industries over the coming decades.
In particular, it will disrupt three key areas;
Despite these innovations, the low scalability of the current breed of technology, and the high volatility of their value have delayed adoption, either for mainstream applications or as a useful currency.
We discuss how the Radix platform is designed to address these critical issues below:
Present blockchain based distributed ledgers do not scale well under load. This is because they are vertical architectures where all nodes participating in the network are required to have the complete global state of the system. The global state requires that all events are delivered and replicated on all nodes - this global requirement to always stay in sync gives an upper limit to the total throughput possible - often referred to as the CAP Theorem limit - of around 500 transactions per second, assuming no other limits.
Proposals to address these issues include: sharding blockchains; creating side chains; or using alternative architectures such as Directed Acyclic Graphs (DAG). Here is a short summary of the drawbacks of each of these methods:
Blockchain Sharding - you still need a coordination layer across all shards to stop double spends. This coordination layer has the same CAP Theorem limit that the sub shards do - you do gain throughput, but still, have an upper scalability limit and it comes at the cost of much greater complexity.
Side Chains - such as the lightning network (Bitcoin) or Plasma (Ethereum) are interesting developments for situations where two (or more) parties need do a stream of payments or actions between each other and aims to take some types of transactions off the chain. It is fast, efficient and trustless. It does not, however, address the core problem of blockchain scalability, and is merely a hack around the central issue, especially where innovations such as Crypto Kittys are happening, and causing problems, directly on a chain.
Directed Acyclic Graphs (also called a Tangle or Block-lattice) - an architecture with a much better base level of scalability than Blockchain, expected to reach in excess of 2,500 transactions per second per DAG instance (depending on consensus system used).
Unfortunately, once this limit is reached, sharding a DAG to increase throughput is very difficult without causing a massive degree of centralisation.
This is because; to prevent a double spend between several DAGs, a node would need to maintain all the DAGs simultaneously. At scale, these super nodes would be very large and very costly to maintain.
Radix provides a solution for reaching consensus, across a distributed ledger, that can scale limitlessly in an efficient, unbounded, linear fashion, without consuming a huge amount of computer resources or capital to secure it. It has a semi-structured, shareable architecture that limits state transfer information to only members of the network that need it, reducing overhead and increasing performance.
For a trustless, public network, security is a core issue. Central to this security is the consensus method used, as well as the way in which the platform rewards the nodes that do useful work for the network.
We discuss how the Radix platform is designed to improve upon and prevent these security issues below:
Every ten minutes, bitcoin miners compete with each other to mine the next block of transactions. The first miner to do so wins and gets all of the block rewards. Work done by every other miner is wasted. In a winner takes all (block reward + transaction fees) race each period, there is only one way to improve your chances of being successful: increase your hash power. This competitive nature of the Hashcash Proof of Work(PoW) algorithm leads to three results:
This eventually leads to the re-centralization of the network, where only very large miners have any chance of earning mining rewards. At the extreme end, this leaves the possibility of collusion, abuse, and censorship.
While success in Proof of Work is determined by who has the most hashing power, Proof of Stake is determined by whoever holds the most coins.
This essentially means that the network is available to be purchased by the highest bidder. With a very small group already holding a majority of coins on many Proof of Stake networks, this puts the control of the network immediately into the hands of a small, rich elite. Not massively dissimilar to banking.
The alternative would be for smaller stakeholders to pool together and move all of their wallets to a central service to share running costs reducing the per unit cost of the operation.This introduces significant security risk not only to hacking but to outside jurisdictional forces such as censorship, regulation, and taxation.
One way or the other, PoS will lead to centralization the same way PoW does due to economies of scale where the rich get richer, faster. Although PoS reduces the energy cost to run the network to a fraction of what PoW requires, it does not solve the centralization problem.
Some cryptocurrency architectures introduce the requirement for trust in a trustless network by using coordinator nodes.
A coordinator node has three principle problems:
This addition of trusted parties can give a significant performance boost, but at the cost of making the network far more vulnerable than it would otherwise be.
Proof of Work is an incredibly expensive and inefficient way of reaching consensus and creating security in a trustless network. This is because hashing to find the largest number of leading zeros before anyone else (“mining”) ends up consuming an ever-increasing amount of electrical power as more and more computers compete to mine the next block.
This process already consumes more electricity than the entire power consumption of Ireland. It is wasteful, and at a time when we are looking for ways to save energy and decrease the environmental impact we have on the world, it is a definite step in the wrong direction.
Smart Contract Execution on an un-sharded DLT (such as the current Ethereum network) becomes more expensive as the network gets bigger. This is because each Node on the network is required to execute every line of code in every Smart Contract submitted with sufficient gas.
As more Nodes join the network the lower the chances any given Node has to be rewarded with the gas fee for executing a Smart Contract. This means that each Node must anticipate needing to run a larger and larger number of Smart Contract before successfully earning a reward. As a result, it is likely that as the network grows, the higher the gas fee is likely to become once the mining rewards are taken into account.
For an object to become a currency, it has to fulfill three roles: a medium of exchange; a unit of account; a store of value. Although DLT technology has enabled trustless transactions over the internet, volatility has delayed their adoption as a medium of exchange and a unit of account. For cryptocurrencies to be adopted widely, they must equal or better the certainty of future purchasing power that fiat currently offers. A low-volatility coin is an asset designed to be price stable over time. This makes it suitable for short-term and medium-term use as a unit of account, a medium of exchange and, a store of value.
The Radix Stable Token is a proposed relatively price stable cryptocurrency currently in R&D. It will sit as a module on top of the Radix Tempo protocol and will be controlled by an algorithmic monetary policy of expanding and contracting coin supply. Full details will follow in a future white paper.
Radix is a modular DLT platform with the consensus architecture as its core module. Network participants can support more modules to earn tokens proportional to work done for supporting them.
Radix scales in an unbounded, linear fashion, where every new Node increases the overall throughput of the network. Limitless scalability means that each additional node added to the network increases the overall throughput capacity of the network. Increasing the amount of nodes have little to no detrimental effects on pre-existing Nodes and thus the scalability is deemed linear and unbounded.
Transactions on the Radix Network confirm in 0.2 seconds and finalize in 5 seconds or less.
Transaction fees on the Radix Public Network are projected to cost the equivalent of 1¢ or less.
The Radix Stable Token will be a low volatility cryptocurrency controlled by an algorithmic monetary supply policy of expanding and contracting coin supply. It is stabilized in a decentralized manner autonomously by the network itself.
You can run a full Radix Client on as little as 16MB of memory and a 100 Mhz processor. Critically, this enables performance-constrained IoT devices to participate as first-class citizens in the distributed network.
The Radix ledger is built specifically for integrating with existing merchant Point-of-Sale (POS) solutions. Even better, anyone can create their own debit cards using $25 off-the-shelf hardware. Debit cards make it easy for consumers to spend cryptocurrencies and create cold-wallets.
The Radix Public Network will allow trustless trading of digital assets to prevent counterparty risk and the security + reliability concerns suffered by centralized exchanges.
As part of its initial release, Radix will feature highly secure instant messaging client. This will provide a gateway to onboard early adopters of decentralized applications creating additional utility for the tokens.
The Radix Public Network will feature an app store similar to Google Play to distribute decentralized applications.
Radix relies on trustless collaboration. It distributes work between participating nodes according to their available resources. This promotes device inclusivity and allows Internet-of-Things (IoT) to also participate as first class citizens in the network.
The Radix Public Network is set for launch in Q1 of 2019. We will be launching various developer betas ahead of this for testing.
Radix enables merchants to accept cryptocurrencies without worrying about wild price swings. It helps developers to build applications that demand transaction rates beyond today’s blockchains. And last but not the least, it allows everyone to participate in ‘mining’ without special hardware and complex software setups.
Radix enables close to zero fees with a fast settlement and no chargebacks. It will provide merchants the ability to accept payments globally without friction. The Radix token is a stable cryptocurrency specifically designed to help protect merchants from wild price swings and incentivize them to accept and use Radix in their everyday business.
The Radix platform will enable developers to create, distribute and manage highly scalable distributed applications for both public and private networks.
Nodes get rewarded for maintaining the public network. The more of it they help to run, the larger the rewards they receive.
Radix is ideal for decentralized applications that demand blazing fast transactions with near-instant finality. Decentralized payment networks, communication networks and marketplaces are some examples to name a few.
Radix has come into being due to the hard work and dedication of Dan and a hard core of community supporters and investors.
Some of these early contributors to the project will receive a small number of tokens at launch, and Radix will also receive a minority % allocation.
However, most tokens will be available to anyone to buy from the integrated Radix Decentralised Exchange, and we have no wish to be the majority holder of our tokens either now or in the future.
No, Radix is not open-source yet. It will be open-sourced to support further development of the Radix Public Network in the future. Private deployments will be licensed. Additionally, we are actively working with individuals and institutions to audit and peer-review the code.
Once live, the public Radix network will be distributed. No single entity, organization or group will own the Radix network much like nobody owns the internet. But unlike the Internet, Radix is collectively maintained by its network participants who are incentivized to maintain it.
Additionally, it’s unique consensus algorithm prevents miner centralization as it does not require large amounts of computing power(PoW) or large amounts of capital(PoS) to secure it, thus mitigating major centralization attack vectors found in current PoW/PoS based blockchains.
The Radix platform has been designed from the start with IOT (Internet of Things) in mind and has thus been designed to enable high throughput from each shard, that constitutes the ledger. As such, Radix can scale beyond existing major payment networks such as VISA and Alipay.
Yes, the Radix Public Network will have the native low-volatile token which we see as key to mass adoption of cryptocurrencies in general. More details on the price-stable cryptocurrency will be released in our upcoming economics white paper.
We currently do not plan to do a public token offering ahead of the launch of a public network. The Radix technology platform is already in an advanced stage of development, so a large raise to build the foundational technology is not necessary.
There is no pre-sale for the Radix tokens.
Radix is capable of supporting various types of crypto economic token supply models. These include fixed, linear, pegged and inflationary. Radix Stable Value tokens follow a dynamic inflationary supply, so there is no hard cap.
Supply follows the Quantitative Theory of Money, with the objective of value stability over time. This means that instead of supply being fixed and value being variable, value is stabilized by fluctuating supply.
These supply fluctuations are controlled by a algorithmic monetary policy, which mimics the action a central bank takes in an economy, but with two important differences:
Radix tokens will have an initial short pegged period ($1 = 1 RDX) after which the token will be allowed to float free. As demand for the currency increases, the total circulation of Radix low-volatile coin will also be increased.
If demand reduces, the system has a few mechanisms in place to burn tokens in circulation as well. If these systems fail, the currency will decrease in value, in real terms, against other currencies (such as the dollar), until demand regains.
The full details of this system will be outlined in the upcoming economics white paper.
Initially, the Radix stable token will be valued at $1. Value is not pegged to the dollar and will free float according to demand.
There will be opportunities to either purchase or earn tokens for use on the live network after launch of the main network.
Radix tokens will mainly be traded on the integrated decentralized exchange. When the Radix Public Network goes live, you will be able to buy/trade the Radix Stable Tokens through this integrated decentralized exchange. Centralized exchanges will also offer the Radix Stable Token if they decide to support it. Further details will be released closer to the launch of the platform; right now the team is focused on developing and testing the platform.
Once launched, you can earn Radix Tokens by running Radix Nodes on the public network. Participating Nodes receive a share of both fees paid by users of the network as well as a portion of new supply.
The network incentivizes participating Nodes by rewarding tokens in proportion to the amount of work done. In simple terms, the more transactions you process on the network, the more you are able to earn.
For the Radix Stable Value token, balance holders also share in new supply. Currently planned split is 50% to balance holders, 50% to network operators, but this split is not yet finalized.Note: When the demand is less than supply, the network burns tokens to stabilize the token price. It does not burn tokens from customer wallets. Instead other methods are used to burn and achieve price stability. Further details will be revealed in the economics white paper which is expected to be released soon.
You will earn as much as you work for validating transactions, storing shards and supporting additional network services.
Initially Radix will provide a simple, open source wallet for storing your Radix tokens. This will also be available as a development platform for 3rd party developers to build their own versions.
A testnet has been deployed and is being used for continuous testing of the platform. The following link will show occasional tests with increasing ambitions to showcase the proven scalability of Radix. -> http://explorer.radix.globalYou may also want to join the Radix Telegram Channel here -> https://t.me/radixdlt
To assist with total order determination of events, nodes declare to the network a periodic commitment of all events they have seen.
This commitment is produced either when a node takes part in Temporal Provisioning for an event, or at will over an arbitrary interval. A commitment is a Merkle Hash constructed from the events a node has witnessed since submitting a previous commitment, with the first leaf being the last commitment a node submitted, producing a linked sequence of commitments over time.
For more information, see: https://papers.radixdlt.com/tempo/#commitments
Every modern payment card follows the EMV standard. This allows any EMV compliant card to securely sign a transaction hash with a private key held in the secure card element and send the signature back to the reader device. The transaction is then broadcast to the Radix Public Network (or your bank if making a normal fiat payment). The Radix network then verifies the transaction and signature in the usual manner and if it validates, you've made your payment.
Video demonstration: https://youtu.be/pMw7hQ6x2f0
IP addresses are not limited to the number of nodes they can host. Using port routing and forwarding you can have as many nodes as you can support.
We believe that one of the keys to unlocking mass market use cases for cryptocurrencies and crypto assets is making them as accessible as possible to everyday users.
To help with this we have created some extra features on our network to make that path to use even easier.
One of these is the Radix decentralized debit card. The Radix decentralized debit card turns any EMV card into a cryptocurrency wallet that will work with any point of sale terminal device, without using the Visa/MasterCard/Amex payment rails.
This allows customers to pay, and merchants to accept, digital currencies directly - keeping the familiar hardware (POS device + physical card) enabling a new world of potential applications.
We have already created a proof of concept that demonstrates a digital currency payment being made, over the Radix network, using an EMV card and a standard PoS device.
If you are interested in using the card in for an application you already have some ideas for, we would love to hear from you.
Linearly scalability is the ability(of Radix) to process more transactions per second as more nodes join the network with no upper limit. Radix scales in an unbounded, linear fashion, where every new node increases the overall throughput of the network. Increasing the amount of nodes have little to no detrimental effects on pre-existing Nodes and thus the scalability is deemed linear and unbounded.
Radix achieves limitless scaling using a distributed database that can be broken up into relatively small constituents termed shards. Since the number of shards is indefinite and has no detrimental effect on pre-existing shards, scaling is practically infinite and thus linear.
Our previous tests have scaled up to 500 transactions per second per partition. Combined with a huge, overlapping shard space, the scalability of Radix is only constrained by the number of Nodes operating within the network
Radix has a single shard performance in excess of 500 transactions per second, which coupled with virtually limitless amounts of shards supported by the platform means a theoretical throughput of hundreds of thousands of transactions per second.
The concept of sharding in a distributed system has existed for a long time. In the simplest sense, sharding your database involves breaking up your big database into many, much smaller databases spread across multiple nodes. The goal of sharding is to move away from requiring 'full' nodes – those which store the full state of the network and every transaction that occurs.
Instead, each node stores a subset of this data and only verifies those transactions. If a node needs to know about transactions or blocks that it doesn’t store, then it finds another node with the information it needs. Radix supports a 64-bit shard space which equates to about 18.4 quintillion shards. With 2,000 tps per shard, the scalability of Radix is only constrained by the number of Nodes operating within the network.
We first started working on sharding in 2014 after realising "Block Trees" and "Side Chains" were not up to task for global adoption of our platform. Several methods were explored and tested. In 2016 the blueprint for what is now called Tempo was developed.
Each node maintains as many shards as it is able to; if a shard becomes too heavy for the node, it will automatically drop that shard. The more shards a node services, the more likely it is to get fees.
The system innately pulls nodes into underserved shards thus maintaining high availability for each shard.
Yes. Radix supports a 64-bit shard space which equates to about 18.4 quintillion shards. This is sufficient to make even the entire of Google's data holding consume around only 2MB per shard (assuming an even distribution of data.)
Short answer - because if you store balances you cannot do state sharding without making the transactions non-atomic. A UTXO type system of consumables allow you to state shard with zero destination overhead, whereas a balance model ends up having a significant destination overhead, making sharding inefficient and only secure through a form of centralised orchestration.
Long answer - to answer this question we need to first establish that sharding is necessary - generally speaking there are two constraints with a DLT:
1. Transaction throughput
2. Storage throughput
With a DAG your transaction throughput is higher than on a blockchain as the transport can be optimized - you are dealing with transactions individually rather than as a block. However, those transactions still need to be validated, and at around 2,000 transactions per second on a single shard (assuming standard servers) you will see the performance of the full nodes on a network start to drop significantly. Pruning the ledger does nothing to reduce this load as this is a throughput constraint, not a storage constraint.
To scale beyond the 2,000 transactions per second mark you will therefore need to start splitting the throughput load; this requires sharding the network, splitting the work amongst the nodes, rather than requiring all the nodes to do all the same work.
Now that you are splitting up the ledger into parts, you need a method of dealing with transactions between shards.
Using balances, rather than UTXO can certainly reduce the storage requirements of the ledger on a given shard as you can prune the transaction history; however, one shards output is no longer another shards input without overhead. Since no TX history is being stored, just balances, the transactions between shards are not atomic, and this starts creating serious complexity. As a worked example:
There are four shards - A, B, C, D and I start with a balance of 50 on shard A and send 10 to wallet X on Shard B.
My balance is now recorded as 40, and at some unknown time in the future wallet X will have a balance of 10 (lets disregard the mechanics of how wallet X becomes aware of the spend in shard A).
However, I also send the same 10 to wallet Y on Shard C, and wallet Z on Shard D.
If I am only recording balances, and not UTXO; and only one of those transactions is valid, how do I void the updated balances of the wallet on the other two shards once the triple spend in Shard A is resolved?
The overhead I tried to avoid by making transactions non-atomic has simply moved to the double spend resolution process, as I now have substantial inter-shard communications to perform to correct the double spend as the output of one shard is not the input of another; we have no transaction history to construct a balance, just the balances themselves.
Now there is a co-ordinator requirement again - some sort of central authority with a guaranteed, up to date view of all shards, to make sure that any given spend only updates 1 of the balances on any shard.
Without that, without transaction history, and without atomicity, double spending between shards becomes trivial.
Security in the Radix network is based on both fault-detection and fault-tolerance. In our case, we use byzantine fault-tolerance to resist sybil attacks and prevent isolation of nodes, clients, and shard attacks. We make use of proof of work algorithm to make it resource intensive for an attacker to create multiple identities fast.
Radix uses logical clocks for generating a causal ordering of events to detect and prevent double spends.
Essentially the first event to gain a temporal proof will become the valid event, the second event will be automatically discarded by the nodes as soon as the earlier temporal proof is presented. In the event that two temporal proofs happen exactly simultaneously (regardless of whether you submitted them simultaneously) both transactions will be dropped. As this will happen within the time it takes for both transactions to be gossiped to all Nodes in a shard, certainty of a transaction can be generally reached within 5 seconds or less.
To assist with total order determination of events, nodes declare to the network a periodic commitment of all events they have seen. The commitment is tamper-proof as they are signed by the producing nodes. A node may be requested to provide information to enable verification of any commitments it has produced at any time. They should deliver all the relevant Atom hashes to the requesting node, allowing it to reconstruct the commitment hash and verify. Requesting nodes can then take appropriate action in the event of a fraudulent commitment being detected.
This uncertainty of when a commitment verification may be requested prevents nodes from tampering with their logical clock values, as all commitments have a logical clock value associated with them and so tampering is easily detectable.
The more nodes that have been in a shard, the more secure a shard history is due to the number of redundant copies of the shard information being maintained.
It is also possible for nodes to leave a shard, come back later and re-affirm history. This makes any attack vector not just all the nodes in a shard now, but all the nodes that have ever witnessed the event you are trying to change.
There is also a high degree of incentive for nodes to maintain under-served shards as the more shards low node count shards they maintain (serve) the higher the probability of getting fees.
For shard selection incentives, see: https://papers.radixdlt.com/incentives/#shards
With some difficulty - as the Radix universe is split into 18.4 quintillion shards, and your shard address is deterministic on your wallet address, you would need to continually cycle PGP key generation to get matching shard address keys. In addition to this there are several other sybil and spam attack prevention mechanisms to prevent even high numbers of malicious actors on a shard being able to reliably control or isolate honest nodes in a shard.
These mechanisms will be covered in more detail in the forthcoming v2 Tempo White Paper.
The cost of sending transactions across the Radix network is currently set at $0.01, while the cost of validating a transaction is almost negligible in terms of computer resources.
This makes the attack highly asymmetric in favour of Nodes, meaning that an attacker would have to spend a very high amount in fees to create any kind of stress on the network. If an attacker spams the network, nodes are immediately incentivized to validate them and collect fees for work done, in extreme cases, attracting more nodes to the shard being attacked due to the strong, positive economic incentives.
Nodes in the Radix network periodically commit the Merkle hash of all previously observed events. Suppressed transactions are easy to detect with the help of these periodic commitments. For example: If a Node(A) sends a message to Node(B) at logical clock 10 asking for Atoms that B might have that A does not and B responds that it has nothing then both nodes include the hash of the messages in their commitments.
If B was withholding an Atom to present later to try and double spend, and presents it, and Node(A) sees it at logical clock 20 for example, Node(A) will have in one of its commitments that it asked Node(B) for Atoms it doesn't have at logical clock 10 and B said it had nothing. Node(B) is therefore exposed, with proof that it lied which can be broadcasted to the network.
Transactions on the Radix Network confirm in 0.2 seconds and finalize in 5 seconds or less.
Around $0.01 to start off with - this is set arbitrarily high to prevent spam attacks. Later on this will be allowed to be voted on by node operators/validators.
Yes, transactions will complete even if the receiving device is not online.
Radix currently does not support completely anonymous transactions, but will support private/anonymous transactions in the medium term.
Yes - essentially this means you can pay the transaction fee with the token you are sending, e.g. “Coffee Token” rather than Rads.
This is to make sure that anyone who creates tokens on our system is not forced to also make sure their customers and coin holders must also use Rads if they want to use the system. This was specifically designed into the Radix protocol to make sure all tokens are first class citizens.
This does, however, rely on:
1. The Radix DEX (decentralized exchange) being live (white paper pending) - part of the Radix protocol.
2. That the token you want to pay the fee with, and Rads, have liquidity as a traded pair on the DEX.
Once those two facts are live; it is then possible for anyone pays the transaction fee with their own token as the tx fee will be converted to Rads on the DEX; allowing the node to confirm any token transaction and receive Rads, but the sender not requiring Rads to send their tokens.
However, if your Coffee Token is not popular enough to have a trading pair on the DEX, then you will still need to pay the TX fee in Rads.
The Economics White Paper will be published before the launch of the main Radix network but after we release the public beta test network and allow people to try the underlying technology layer.
No, not quite. Radix has several token types that are possible to create on the Radix platform. One of these tokens is the Radix low volatility coin, which aims to create a token with a more predictable, less volatile value to make it more useful as a currency. This Radix token will have an elastic supply based on ‘Quantity Theory of Money’.
The Radix low volatility token is based on 'Quantity Theory of Money' which is a elastic token supply model. When new supply is generated due to increased token demand, 50% of new Radix tokens will be distributed to balance holders, and 50% to Node operators.
The Radix algorithmic monetary supply rules will dictate creation or destruction of the Radix native tokens via its integrated decentralized exchange.
Full details of the Radix Low Volatility Token will be released with the coming Economics White Paper.
There are several different token types that can be issued on the Radix network.
One of the most hotly anticipated is the Radix low volatility coin, which, when launched will have a starting value set to 1 USD/token. The coin value will be 'relatively' stable, not pegged (ie. it is NOT fixed at $1 forever).
Over the longer term, the price will increase in a controlled manner if there is a sustained imbalance between the supply side and the demand side. The higher the sustained imbalance to the demand side, the higher the price and the more tokens will be in circulation. The price discovery process will allow it to float up/down, but the economics will attempt to smooth out the peaks and troughs to reduce volatility.
This is still an experimental coin type and the full details will be released in a coming Economics White Paper.
Simply, the more services - which includes number of shards - that a node provides for the Radix network, the larger the potential earning base. Each node earns fees from any Temporal Proof's they create. The distribution of which nodes provide the temporal proofs is probabilistic, not resource intensive. In other words, you don't have to ‘mine a block’ to get TX fees, just confirm a transaction!
A machine will automatically maintain as many shards as are possible, given its resources; very small machines will run only a few shards, large machines many more. A full node can be run on as little as 16MB of Memory and a 100 Mhz processor. At the moment we run the test net with a 64 bit shard space, so finding light shards is trivial, even for a very heavy network.
For more information, see: https://papers.radixdlt.com/incentives/
Every atom submitted to a public network is submitted with a transaction fee. This transaction fee is shared equally by the nodes that provide the temporal proof. Nodes which provide the temporal proof are selected randomly, with a bias towards those that are maintaining both shards of a transaction span (almost all transactions are inter-shard due to the huge shard space and the way that a shard address is generated). Only a valid temporal proof receives a fee.
For more information, see: https://papers.radixdlt.com/incentives/#incentives
A shard with a lower number of nodes has the same statistical probability of a transaction crossing into or out of it. The lower the number of nodes in a shard, the higher the probability of being selected to create a temporal proof for a crossing transaction. This higher probability gives you an incentive to service this shard as creating a temporal proof is the way you get rewarded for work on the network.
For more information, see: https://papers.radixdlt.com/incentives/#shards
In the Tempo Ledger each transaction is officially verified by a 'temporal proof path' which consists of a chain of nodes.
The nodes which are taking part in the temporal proof, that have verifiably done work for the network and as such are rewarded with income through transaction fees and node earnings at the end of the earnings cycle.Which nodes take part in the temporal proof is random. Therefore, each node is expected to gain income roughly proportional to the activity in the network and the fraction of the network that they are supporting.
For more information on Temporal Proofs, see: https://papers.radixdlt.com/tempo/#temporal-proof-provisioning
For more information on Incentives, see: https://papers.radixdlt.com/incentives/#incentives
The underlying rewards algorithm is more "fair" than the Bitcoin/Ethereum one, but in time, if the network grows sufficiently large it may still make sense to coordinate and share maintaining different parts of the whole network to get a more even reward distribution.
For more information on rewards, see: https://papers.radixdlt.com/incentives/#incentives
Radix plans to open-source itself in the future. Right now the team is focused on testing and developing the platform.
Radix has filed a patent for its technology to defend itself from copycats until our market penetration goals are achieved. It will go fully open source once that happens.
The patents are to restrict and license certain types of private implementation of the Radix code. For the public network, Radix will always be an open platform.
The distributed ledger (also called a shared ledger, or referred to as distributed ledger technology) is a consensus of replicated, shared, and synchronized digital data geographically spread across multiple sites, countries, or institutions. There is no central administrator or centralised data storage.
Decentralized applications (dApps) are applications that run on a P2P network of computers rather than a single computer. dApps, have existed since the advent of P2P networks. They are a type of software program designed to exist on the Internet in a way that is not controlled by any single entity.
Transactional finality refers to the instant that a transaction is deemed immutable, irrevocable and thus completed.
On Radix, transaction finality is the time it takes for a new transaction to be gossiped to the furtherest side of the relevant Shard from the starting Node, and then back again. As long as no conflicts are found, this transaction is then deemed to have reached finality.
An instance of the Radix Tempo ledger is called a Universe.
A public Radix network (Universe) is segmented into a very large shard space (currently 18.4 quintillion shards). The start and end point for any Atom in the Radix Universe is an address, which is formed of a public key and a Universe checksum. The shard number of an address is deterministically calculated by taking a modulo of a public key over the total shard space to derive the shard index. This makes it trivial to for anyone to correctly calculate the shard a public key lives on.
For more information, see: https://papers.radixdlt.com/incentives/#shards
Any event within the Radix universe, such as a message or transaction, is represented by an object called an Atom.
For more information, see: https://papers.radixdlt.com/tempo/#radix-tempo
Payload Atom are transactional messages, sent to one or more parties, like an email or an instant message.
For more information, see: https://papers.radixdlt.com/tempo/#radix-tempo
Transfer Atoms are used to transfer the ownership of an item, such as currency, to another party.
For more information see: https://papers.radixdlt.com/tempo/#radix-tempo
A temporal proof is a cryptographically secure record of ordered events.
Before an event can be presented to the entire network for global acceptance, an initial validation of the event is performed by a subset of nodes which, if successful, results in: A Temporal Proof being constructed and associated with the Atom, and a network-wide broadcast of the Atom and its Temporal Proof.
For more information, see: https://papers.radixdlt.com/tempo/#radix-tempo
Within Tempo, all Nodes have a local logical clock; an ever-increasing integer value representing the number of events witnessed by that node. Nodes increment their local logical clock when witnessing an event which has not been seen previously. Upon storing an event the Node also stores its current logical clock value with it. This record can then be used to help validate the temporal order of past events if required.
Within Tempo, all nodes have a local logical clock (see Logical Clocks)
These Logical Clocks can then be made into Vector Clocks, where the Logical Clock of many Nodes are collected in relation to the same event, and then used to create a comparison of order between Nodes in order to determine which event proceeded which.
Note: on their own, Vector Clocks only create a partial ordering - Node Commitments are also necessary to complete the ordering of events.
See the Tempo White Paper for more details: https://papers.radixdlt.com/tempo/#commitments
To assist with total order determination of events, nodes declare to the network a periodic commitment of all events they have seen. A commitment is a merkle hash.
A gossip protocol is a highly effective, well established way of getting information to be quickly spread through a network. In essence any Node that receives a new piece of information, tells two (or more) neighbouring nodes about it. They then tell two or more each (2*2) and so on. This follows an exponential pattern until all Nodes in the network have been told.
This is how Radix ensures any new transactions are quickly shared with all relevant nodes in a highly reliable, fast and fault tolerant way.