For some, the word “sharding” might evoke images of glass shards. In the crypto world however, the term is becoming better known as a way to improve Ethereum’s scalability. Like other blockchains, Ethereum users must contend with the limitations that excessive network congestion can sometimes present. The difference here is that Ethereum developers are actively seeking a solution to the problem. And sharding may be the best option out there.
Off-chain solutions are currently viewed as one possible way to improve blockchain scaling (think the Lightning Network). They typically involve handling transactions off chain with only the most minimal interaction with the original chain. A more radical approach calls for re-configuring the protocol’s design itself. While a more complete solution, such an approach would be a far more difficult endeavor to pull off.
If blockchain sharding evokes tiny slivers of glass shards, it’s not without reason. In blockchain lingo, sharding means breaking a network into tiny partitions (with each detailing its current account balances, Solidity code, and sum-check number until it’s altered by a new transaction). Fragmenting a network in this manner is a necessary first step toward vastly increasing network throughput. The latter can be achieved by simply ensuring that these partitions (or shards) are designated for processing by predetermined nodes on the network. At present, the Ethereum blockchain operates the same way a single shard would.
The Sharding Structure
Describing how the sharding structure operates in details is much more complex. For instance, information about any particular shard (or network partition) is stored in a collation. This particular structure is created by network nodes called collators (hence the name). Collations describe each shard’s transactions and current account data. They even have a metadata-type element contained within called a collation header.
What type of metadata is that? It is the shard the collation corresponds to as well as the shard’s state before and after all transactions are processed. The collation header also retains digital signatures from two out of three collators located on a shard for verification purposes.
In order for sharding to be effective, it must allow transactions to occur between shards. The process for achieving this is not unlike that found in a smart contract. That is, instigating a payment transaction will reduce an ETH sender’s balance. However, that transaction will not be finalized until the following steps are completed. First, that a receipt is then recorded for the transaction and stored within a Merkle Tree for verification purposes (a Merkle Tree is a data structure consisting of cryptographic hashes). Second, that the ETH receiver’s shard then receives the receipt and verifies that the sender’s balance remains unspent. And third, that the receiving shard processes the transaction and then adds the ETH to its balance. It must also creates a new receipt for the shard to be used in new transactions.
Ultimately, a Validator Manager Contract (VMC) will be constructed to manage the sharding system. The VMC’s management of shards also requires fully reconciling all current shard accounts and transactions.
While this type of undertaking appears daunting, the technology is within reach. Moreover, the rewards for achieving far greater scalability within Ethereum would solve a real obstacle to mainstream adoption of cryptocurrency.