Technical - Frequently Asked Questions


#1

What are logical clocks?
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.

Do logical clocks increment for only consumables or all events?
Logical clocks are incremented for all events, which is either protocol events (atoms) or protocol messages (fault detection)

What are vector clocks?
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

What are merkle trees?
Radix uses logical clocks to provide a simple and reliable method for nodes to record and recall events in the order they have witnessed them. While these logical clocks are simple and reliable, they do not provide any security against nodes tampering with the logical clock values that it has assigned to events.

To ensure the assigned logical clock values are tamper-proof, nodes produce “Commitments” which are an ordered, cryptographically secure, compact representations of the events witnessed by a node.

What are 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.

How often does a node present commitments to the network?
Commitments are produced either when a node takes part in Temporal Provisioning for an event, or at will over an arbitrary interval. Any transaction a node sees will be part of its commitment in the temporal proof it signs. If a node is not eligible to sign the temporal proof, it will include all transactions it has seen since. It’s last commitment in the next temporal it is eligible to sign. Unless the network is very large, most nodes will sign all temporal proofs for all transactions they see.

What if the node is requested to send the commitment for a transaction that is not included in a commitment yet? Will that never happen or will it force the node to create a commitment on the fly?

Nodes don’t get asked for specific transactions. They get asked to prove prior commitments. If a node hasn’t seen a transaction it won’t be in it’s commitment, but that’s doesn’t prevent it proving it’s honest.

What are temporal proofs?

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

What is Byzantine Fault Tolerance?
Byzantine fault tolerance ( BFT ) is the dependability of a fault-tolerant computer system, particularly distributed computing systems, where components may fail and there is imperfect information on whether a component has failed. In a “Byzantine failure”, a component such as a server can inconsistently appear both failed and functioning to failure-detection systems, presenting different symptoms to different observers.

What is Byzantine Fault Detection?
Distributed systems are subject to a variety of faults and attacks. A faulty/malicious node may exhibit arbitrary behavior. In particular, a faulty node may corrupt its local state and send arbitrary messages, including specific messages aimed at subverting the system. Many security attacks, such as censorship, freeloading, misrouting, and data corruption, can be modeled as Byzantine faults. Systems can be protected with Byzantine fault tolerance (BFT) techniques, which mask a bounded number of Byzantine faults, e.g. using state machine replication. BFT is a very powerful technique, but it has its costs. In a practical system that needs to tolerate up to f concurrent Byzantine faults, BFT cannot be implemented with less than 3f+1 replicas. Moreover, BFT scales poorly to large replica groups; as more servers are added, the throughput of the system may actually decrease. Byzantine Fault Detection is an alternative approach that aims at detecting rather than masking faulty behavior. With this approach, the system does not make any attempt to hide the symptoms of Byzantine faults. Rather, each node is equipped with a detector that monitors other nodes for signs of faulty behavior. If the detector determines that some node has become faulty, it notifies the application software, which can then take appropriate action. For example, nodes can cease to communicate with the faulty node; once all correct nodes have followed suit, the faulty node is isolated and the fault is contained. Lies (or faults) in Radix can be detected using merkle trees of commitments.

Read more about the case for Byzantine Fault Detection in this whitepaper.

Radix uses both BFT to defend against network splits/attacks and BFD to defend against malicious behavior like double spends, transaction suppressing, etc.

What is mass?
We label events within the network (such as messages or transactions) as ‘atoms’. These atoms carry mass if they are transferring value, for example transactions or payloads with fees. This mass is calculated in a very simple manner, simply being the quantity (e.g. the amount of Radix being transferred) multiplied by the amount of time it has been static for. For example, if I transferred 10 Radix to Bob which I had held for 10 days then the mass of the atom being sent would be 100. If I had 5 Radix but had held for 20 days then the mass would similarly be 100.

The first node in the temporal proof for a valid transaction receives this mass. Nodes then build up mass across the multiple transactions they validate. The record of this mass is stored by nodes serving the same shards as said recipient node, as they store temporal proofs from completed transactions (known as finality). It is important to remember that transactions don’t just have a single gossip path through the network but rather have multiple routes due to the nature of our gossip protocol, which sees nodes ‘talk’ to all of their neighbouring nodes. This means that transactions are seen by a large majority of nodes.

This mass allows us to resolve conflicts which cannot be solved by simple resolution by letting us use mass as the determining factor. We add up the mass of all nodes involved in the temporal proof for the conflicting transactions and the atom with the most total mass associated with it is accepted. The losing transaction is meanwhile discarded.

Expanding upon this logically, in the event of a network split whichever network has the greatest mass is the mainnet. The mainnet then absorbs all non-conflicting transactions (i.e. anything that doesn’t constitute a double spend) into it. Conflicting transactions are, again, discarded. This works because although both transactions will have reached finality on their respective networks, the transaction on the mainnet will possess the mass of this large majority of nodes involved in validating it, meaning it will sum greater than the subnet.

Why do we need mass?
As discussed above, we use mass to defend against complex network attacks. You can read more about it in this blog post.

T he principles of mass is very simple, but in practice there are many things to consider…for example, in a large network, how do you collect enough information to determine all votes, without all nodes having to ask all other nodes (which gets SUPER exponential very quickly).

Dan assumed there would be a clever solution out there somewhere he could use, and so he read endless amounts of prior work and they all go exponent after a particular network size…so it was something else he had to invent.

The algorithm he came up with costs on average 1.05 messages per node and 12kb of data to determine the vote of a 10k node network to a suitable accuracy that we require.

Furthermore it’s consensus friendly so that all nodes will output the same result (with some margin for error) based on the same input

To put that in perspective, that’s like 10k people voting on something and you have to ask just one person what they know of how a handful of other people voted and you can arrive at an accurate and agreeable prediction for all 10k people.

It scales well too, for a 100k node network it’s still around 1.05 messages per node average and the data cost per node is about 27kb

How is Mass calculated?
Mass = XRD * (consumable (output) universe planck - consumer (input) universe planck). A universe planck period being an hour on mainnet because seconds are too granular to use and as our ledger wall clock time is only approximate, we need to have an adequate buffer to absorb drift, etc.

Will other user generated tokens have mass?
Probably yes. More details will follow in the upcoming security whitepaper

Will Radix be interopable with other blockchains?
No. Radix has a unique data architecture and consensus algorithm that is currently not interroperable with other blockchains. Radix will could likely become the secondary layer for scaling blockchains.

Will Radix have smart contracts?
Yes, Radix is developing a unique smart contracting language that even nondevelopers can learn. More details will follow as we progress through our Roadmap milestones.

Is Radix Quantum Computer Resistant?
Like most systems the Radix ledger is not Quantum Computer resistant. Currently we are looking at quantum resistance to determine either;

  • What cryptographic technology we can implement now
  • How can we migrate to quantum resistant cryptographic algorithms safely in the future

Ideally we like option 1, but a lot of the algorithms available are stateful, or produce VERY large signatures which is not ideal. Unless we can get a quick win developing a version that is stateless, we’ll probably end up with option b for now as rolling our own crypto which is not time tested is dangerous. This helps us focus on key features.

What are some benefits of Temporal Proofs?
Temporal proofs help with Mass delivery, propagation information (gossip verification), logical clock information, commitment information (for fault detection), RTP (time sync) information. They do do all of that in 100 bytes per vertex.

Is data encrypted where the node hosting the copies of data won’t be able to tell what’s in it?

It’s my understanding that transactions are signed with the private key of the entity owning the radix, just as in bitcoin. I have no idea about the message type atom. When it comes to data/messages/payload, the sender decides what to encrypt and what keys to use for the encryption. For a Twitter-like dapp the data would be in clear text since it’s supposed to be public. For a private message, the data would typically be duplicated and encrypted with the sender’s and the receiver’s public keys, so that both sender and receiver can decrypt it later. For private data storage, the data would be encrypted only using the sender’s public key since no one else is supposed to read it. A node can only read the data that is sent in clear text.

Which hashing algorithm is used in Tempo?
We use SHA126 to hash the history of work performed b the node. It’s a chained merkle tree also called as commitments.

Sharding & Scaling

How many transactions per second can Radix scale up to?
Our current alpha network has scaled up to 25,000 tx/s with only 16 to 20 nodes and without sharding . Our team recently tested speeds up to 80,000 tx/s on the same alpha network. We are focusing on optimizing the node first, before proving our theory of unbounded scalability with sharding. Keep an eye on our twitter and telegram for milestone announcements. Check our roadmap here.

When the network is not being stress tested, we do a sustained transaction throughout of about 2,500 tx/s. Check our explorer here.

What is linear scalability?
Linearly scalability is the ability of Radix to process more transactions per second as more nodes join the network. This property helps the network scale 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.

How does Radix achieve linear scaling?
Radix is massively sharded to scale linearly. Read more about our design philosophy here.

What is sharding and how does it help Radix scale?
Sharding is way to distribute network load by cutting up the distributed database into multiple manageable parts. We wrote a ELI5 blog post on what is sharding and an introduction to sharding in Radix. Read about our protocol design philosophy and how sharding will help us scale to millions of devices.

Can nodes maintain parts of the ledger?
Yes. The Radix ledger is divided into 18.4 quintillion shards. Depending on your node capacity (based on CPU and bandwidth), the node can scale down to serve only some shards/parts of the ledger. 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.Thus every 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.This allows any device to be a useful participant of the network creating the trust layer for the internet of things.

How do you ensure high availability for each shard?
Incentives in the Radix network are designed such that under served shards become an opportunity for node operators. Less nodes on a shard increases the possibility of earning more rewards for validating transactions. This allows the market to naturally gravitate towards supporting as many shards as possible, especially those which are under served. Radix is designed to provide a high degree of redundancy due to its massive shard space of 18.4 quintillion shards (2^64). At the start, all nodes will hold all shards, and pretty much every node will store all the transactions provided enough time has passed for gossip.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.

As discussed before 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

Is the number of shards constant per universe?
Yes. Radix will start with a shard space of 2^64 or 18.4 quintillion shards, which will be able to support every device in the world, and then some more.

How does Radix avoids the CAP theorem limit?
Tempo relies heavily on eventual consistency to achieve a total ordering of events. Radix avoids the CAP Theorem limit that DAGs and Blockchains suffer from by allowing transactions to be both asynchronous and concurrent. This allows it to scale out limitlessly. The Radix shard space is key to this scalability - 18.4 quintillion shards that nodes can maintain concurrently, while the Tempo consensus makes sure double spends don’t occur across these shards without being detected and rejected.

How scalable will Radix DEX be?
We have yet to see how decentralized exchanges will behave with high traffic and whether they may be able to function as expected or even outperform centralized exchanges. A key part of product development is to ship the MVP, iterate and improve as we get live feedback from the users. So the DEX is projected to improve and scale as we understand how it behaves in a live environment.

Transactions

Why does Radix use a UTXO model instead of a balance model?

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.

What are logical clocks?
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.

How long does it take for transaction settlement?
Transactions on the Radix Network confirm and finalize in 5 seconds or less. Current test networks may experience some delays, as we test and break things.

What is the transaction fee?
$0.01 to start with - this is set arbitrarily high to prevent spam attacks. Fees will gradually decrease as paid operations on the network increases.

Are fees fixed?
Yes.

Are transactions private and/or anonymous?
Radix is as private as private as bitcoin. It does not support complete anonymous transactions, but will support pseudo-anonymous transactions in the medium term. The ledger is design as such that in the future it will be very easy to create an anonymity layer on top of it. The team will not focus on it until the basic features are stable.

Are all Tokens first class citizens on the Radix platform?
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 the Radix token, have liquidity as a traded pair on the DEX.

Once these two facts are live; it is then possible for anyone who pays the transaction fee with their own token as the tx fee will be converted to Radix tokens on the DEX; allowing the node to confirm any token transaction and receive XRD instead, without the sender requiring to hold XRD 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.

How do I receive test radix tokens?

Download, install and take the alphanet wallets for a test drive on your desktop or android phone. Download here.

How do smart-contarcts work which might need to make use of information stored across many shards? Or, alternately, if all transactions directed to a smart contract are stored on one shard (the shard matching the address of the contract), how can they against this one smart contract scale beyond the expected computational power of any given computer on that shard range?

Yes, your upper bound for a smart contract is indeed the fastest nodes that serve the shard within which it lives but that is the same for transactions too, a shard cannot process more transactions than the fastest machines which serve it (which right now is about 3000 tps for a commodity machine). If a particular smart contract is very popular, then it is generating a lot of fee revenue for the nodes that serve it…so I expect to see those nodes contract their serving shard group around that particular shard as much as possible allowing them to free up CPU from serving other shards, and allowing them to process more in the smart contract shard.

What’s the cost of running smart contracts on radix? Will there be a gas system?

Kind of, but its called “Joules” and works a little differently than how Eth manages it…also the stable and scalable aspect of Radix will make it a much more predictable unit cost**

Transactions on the Radix Network confirm and finalize in 5 seconds or less. Current test networks may experience some delays, as we test and break things.

What is the transaction fee?

$0.01 to start with - this is set arbitrarily high to prevent spam attacks. Fees will gradually decrease as paid operations on the network increases.

Are fees fixed?
Yes.

Are transactions private and/or anonymous?
Radix is as private as private as bitcoin. It does not support complete anonymous transactions, but will support pseudo-anonymous transactions in the medium term. The ledger is design as such that in the future it will be very easy to create an anonymity layer on top of it. The team will not focus on it until the basic features are stable.

Are all Tokens first class citizens on the Radix platform?
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 the Radix token, have liquidity as a traded pair on the DEX.

Once these two facts are live; it is then possible for anyone who pays the transaction fee with their own token as the tx fee will be converted to Radix tokens on the DEX; allowing the node to confirm any token transaction and receive XRD instead, without the sender requiring to hold XRD 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.

How do I receive test radix tokens?
Download, install and take the alphanet wallets for a test drive on your desktop or android phone. Download here.

How do smart-contarcts work which might need to make use of information stored across many shards? Or, alternately, if all transactions directed to a smart contract are stored on one shard (the shard matching the address of the contract), how can they against this one smart contract scale beyond the expected computational power of any given computer on that shard range?
Yes, your upper bound for a smart contract is indeed the fastest nodes that serve the shard within which it lives but that is the same for transactions too, a shard cannot process more transactions than the fastest machines which serve it (which right now is about 3000 tps for a commodity machine). If a particular smart contract is very popular, then it is generating a lot of fee revenue for the nodes that serve it…so I expect to see those nodes contract their serving shard group around that particular shard as much as possible allowing them to free up CPU from serving other shards, and allowing them to process more in the smart contract shard.

What’s the cost of running smart contracts on radix? Will there be a gas system?
Kind of, but its called “Joules” and works a little differently than how Eth manages it…also the stable and scalable aspect of Radix will make it a much more predictable unit cost