There are three primary approaches to sharding blockchains, with the key distinction being how cross-shard transactions are handled. These approaches are:

1. Parachains (E.g. polkadot, Eth 2)
2. Manual Cross-shard Transactions (E.g. Near Protocol’s Nightshade)
3. Automatic Cross-shard Transactions (E.g Tari, Radix, Chainspace)

Parachains

In the parachains model, each shard functions as its own blockchain. However, the addition of parachains typically involves a long process because every chain requires a secure set of validators.

This approach also comes with a trade-off: while the transactions per second (TPS) within a single chain increase, the seamless interaction with assets across different shards becomes challenging. For instance, if you wish to exchange Asset A on shard 1 for Asset B on shard 2, you must wait for the coordination of both shards with a beacon chain to complete the transaction.

In many cases, it is more efficient to execute a fully cross-chain atomic swap, similar to the process used in two distinct blockchains.

Interestingly, this was the original design of Tari’s second layer. However, recognizing that cross-shard transactions would be sluggish and the challenge of ensuring that all validator sets were honest, Tari made the decision to shift to a Cerberus approach.

Manual Cross-shard Transactions (Near Protocol’s Nightshade)

Another approach is the one taken by Near Protocol’s Nightshade. In this approach, data is segmented according to user accounts. To facilitate cross-shard transactions, the contract code must be meticulously crafted to enable the transaction to be divided into multiple distinct pieces that can be independently and asynchronously executed on each shard.

This places a significant burden on developers to write code correctly and results in a complex programming model.

Automatic Cross-shard Transactions (Cerberus, Chainspace)

In Cerberus (and also Chainspace), data is distributed randomly over the shards, and cross-shard transactions are expected frequently. All transactions are based on a UTXO (Unspent Transaction Output) model, which means data must be destroyed when it is modified and recreated in a new state. This prevents double spending across shards, as long as the committees pledge the data to only one transaction. The intricacies of how this works are quite detailed, so will be omitted here.

When a cross-shard transaction occurs, the involved shards collaborate in consensus rounds. This process is sometimes referred to as “Braiding,” although the specifics can vary. Cross-shard consensus rounds are conducted as part of the local consensus rounds, ensuring that the process is not stalled, as seen in other sharding strategies.

Sharding Disadvantages

All three sharding approaches are susceptible to an attack known as the Single Shard Takeover (SST) problem. Each chain has mechanisms to detect and recover from SST. Tari is actively exploring solutions to address this issue, including checkpointing to the base layer.

Example

Let’s consider an example of a transaction using all three approaches, involving a swap between Asset A and Asset B, with the required data residing on two different shards.

For parachains, one would typically have to wait for the data to be committed to a checkpoint in the beacon chain before the two shards can complete a transaction.

In Near’s Nightshade design, the contract must be meticulously coded, and the transaction would be split into two subtransactions. The first subtransaction deducts the funds in the first shard and then sends the second subtransaction to the second shard for processing and inclusion in the blockchain. These subtransactions must be cleverly crafted to allow processing between other data changes that might happen asynchronously.

In Cerberus, shard 1 and shard 2 initiate the transaction locally and lock the data. They communicate to perform a braided consensus round, providing data and proof of data locking for this transaction. Once both shards have completed consensus, the data is updated in their respective shard databases. If there is an error or if one shard cannot provide proof of data locking, both sides abort.