Radix Mainnet (Xi’an)

The Radix 'universe' of Xi’an, once deployed, will exist on a fixed space of 2^256 data shards, served by a distributed network of validators called Shard Groups. Shard coverage will be allocated according to processing power, storage and bandwidth. A fixed ledger space allows wallet addresses to be deterministically mapped to a shard and, hence, for the global state of the network to be a derived sum of shard states. With so many shards, the likelihood of two substates being mapped to the same hash (a hash collision) at 1m transactions per second (tps), has been estimated as one every 3.67^63 years.

A proto-implementation of Xi’an is currently being built in the Cassandra project.

Radix’s founder, Dan Hughes, has said that the first release of Xi’an might only have 8-16 shard groups, which will be increased as the network throughput grows.

In the context of database performance, state objects can be a bottleneck due to the way they are stored and accessed. State objects are typically represented by a hash, and before they can be read, their location on the disk must be determined by querying an index. However, indexes can be very large, and only a portion of it can be stored in memory at any given time. As a result, several disk reads may be required to locate a specific state object, making it a slow process.

To put this into perspective, consider the example of receiving 19 state objects over a 10Mbit connection. It takes approximately 0.0019 seconds to process and store them in memory. However, if these state objects were stored on an SSD capable of 100,000 random reads per second, it would take much longer to retrieve them due to the indexing process. For example, if the index requires six reads to locate a state object, and there are 20 state objects to provision, it would take 140 reads in total. This equates to a maximum of 714 transactions per second, given that the bandwidth of the connection is 10 Mbits (~1MB per second).

While an SSD may seem like a better option, there are other factors that impact database performance, such as maintenance and compaction of indexes and data, as well as the database itself producing latency through its operations. In reality, one would be lucky to see 500 transactions per second using an SSD.

Another consideration is the latency of the network, which can significantly impact the time it takes to execute a transaction. Even with a fast network, there is a consensus round that must be reached before execution, which can take several seconds. In a cross shard transaction with 20 state objects, finality can take anywhere from 10-15 seconds, depending on the transaction. However, the asynchronous nature of provisioning, execution, and certificate generation means that other transactions can be prepared and completed while the current transaction is being processed.

The Radix protocol assumes that 256 bits are enough to avoid "almost all" collisions in shard addresses. In the rare event of a collision, the corresponding transaction would fail and the user would simply retry, automatically resulting in different shard addresses.

Radix's consensus protocol is called Cerberus. It will allow an effectively unlimited number of shards to operate independently without losing atomic composability. The Cassandra testnet is used to stress test Cerebus.

An unsharded version of Cerebus has been operating on the Radix mainnet for over 1 year. Sybil protection is achieved by Delegated Proof of Stake (DPoS).

It remains unclear if every Xi'an wallet will be given the software to run a validator node. The consensus algorithm's operation is also uncertain when most nodes are powered down. Power drain and feasibility of running mobile validators are additional concerns.

The Xi'an protocol for the Radix network is a speculative concept, aimed at increasing the number of validator sets and shard groups for better transaction processing. The number of validator sets may be double the amount required to satisfy the demand for transactions per second (TPS). Each validator set may consist of up to 3000 validators, with a minimum of 100 validators for security purposes.

The Xi'an protocol allows the number of validators in each validator set to vary between 100 and 3000 while maintaining the same number of shard groups. Only when TPS demand increases to utilize the whole 3000 validators will it be necessary to add a shard or split existing shard groups.