TOP Network Technical Spotlight | Sharding Part 3 | Cross-Shard Transactions
In part 2, we learned how TOP Network uses many forms of randomness to defend against single-shard-takeover attacks, and methods such as shard reshuffling to help prevent adaptive adversaries from gaining control of any shard. Another challenge in sharded blockchains is dealing with cross-shard transactions. Not only do cross-shard transactions present possibilities for double-spends, but they also require more network bandwidth than a transaction that is not cross-shard. Without an efficient network architecture and routing algorithm, cross-shard transactions can become a bottleneck.
What Are Cross-Shard Transactions?
Each shard is responsible for a certain set of the entire space of accounts. When an account wants to send funds to another account within the same shard, the process is similar to that of a non-sharded blockchain. This could be called an intra-shard transaction. When an account in one shard is sending funds to an account that resides in another shard, there must be some additional processes to facilitate these cross-shard transactions.
In most implementations, including TOP Network’s, cross-shard transactions are carried out asynchronously. This means the sending account is debited, and then the receiving account is credited at a slightly later time.
Here is the process of sending 25 TOP from Account X in Shard A to account Account Y in Shard B.
Step 1:
Step 2:
Step 3:
Step 4:
In some other implementations, the cross-shard transaction depends upon the speed of the root-chain, which can become a bottleneck. The root-chain still plays an important role in TOP Network, but cross-shard transactions do not need to wait on cross-linked root blocks to carry out both ends of the cross-shard transaction. Throughout the whole process, audits carried out by Advanced nodes, in addition to pBFT consensus from the shards are checking for double-spends.
Importantly, only the sending and receiving clusters need to participate in the routing of cross-shard transactions. This is the Network Sharding described in earlier parts. This means that even as the network grows and there are an increasing number of cross-shard transactions, clusters won’t get bogged down with the routing involved with cross-shard transactions, as they only need to deal with incoming and outgoing transactions to their own shards.
