Ethereum Shard Chains Explained
One of the main objectives of the Ethereum 2.0 specification is improving Ethereum’s scalability. Blockchains traditionally scale poorly. The main reason for this is that all full nodes have to process all transactions and store the full state of the blockchain. This significantly limits transaction throughput in Ethereum 1.0. The intuitive solution to this problem is dividing the blockchain up into manageable chunks, which are then processed by a subset of nodes. Ethereum shard chains represent the implementation of the sharding scaling technique that is intended to bring about a more scalable Ethereum platform.
Sharding
Sharding, a technique borrowed from database management systems (DBMS), is at the core of Ethereum’s scaling strategy. DBMS sharding splits databases horizontally, usually across rows of tables, and divides the responsibility for storing data between several nodes, reducing the processing and storage space requirements of individual nodes.
Sharding for blockchains works similarly. The idea is to divide the blockchain’s state and transaction processing into shards, each of which is processed by a separate set of nodes. This means that individual nodes now only have to store the state of their own shard and process only a subset of the transactions, improving overall transaction throughput. This core scaling strategy will be inherent in the implementation of the Ethereum shard chains.
The Difficulty of Blockchain Sharding
Blockchain sharding may sound intuitively simple, but it is actually much more complex than DBMS sharding. There are a number of reasons for this complexity:
- Security: The reason that all nodes process all transactions in a blockchain system is security. It is very difficult to take over a blockchain with a 51% attack because of the sheer number of nodes that would have to be compromised. In theory, a single shard could be compromised more easily, as fewer validators are securing a shard than a whole non-sharded blockchain. Therefore, a sweet spot between sufficient security and optimal performance needs to be found, keeping validator sets sufficiently large to guarantee security.
- Cross-Shard Transactions: Transactions between accounts that are maintained in a different shard rely on some mechanism to communicate between shards. It is therefore a requirement to have a set of validators that can route transactions between shards. Cross-shard communication is non-trivial and requires carefully designed security measures.
- Finality: Related to cross-shard communication is the question of how to deal with transaction finality. Blockchains that use a variant of Nakamoto consensus, such as Ethereum, provide probabilistic finality. In the case of occasional forks in the chain, the longest (or heaviest) chain will eventually dominate, leading to the fact that transactions in a stale chain may be undone. The probability of this happening decreases with every block confirmation. However, in the case of cross-shard transactions, probabilistic transaction finality is problematic, as transactions that are undone in one shard may already have been communicated to other shards. Therefore, a finality mechanism needs to be used on top of the consensus protocol in order to provide stronger guarantees on finality.
Ethereum Beacon Chain
Sharding in Ethereum 2.0 is made possible by the Ethereum beacon chain, a proof-of-stake chain that connects all shards. Individuals who wish to participate in the consensus process (in other words become network validators) must stake 32 ether by making a one-way transaction to a deposit contract on the current Ethereum 1.0 proof of work chain.
Once in the validator set, a node may be selected to act as a validator in a shard chain. Assignments are randomized using Verifiable Delay Functions (VDF). This randomness ensures that the composition of validator sets (called committees) is not predictable, which improves security.
Ethereum Shard Chains
Shard chains in Ethereum 2.0 store state and process transactions. One randomly selected validator is responsible for forming and proposing blocks of transactions that will be voted on by a randomly selected sharding committee. If a proposed block receives enough votes, a ‘crosslink' between the shard block and the beacon chain will be created, which confirms that the shard block will be added to the beacon chain. It is also important to note that transactions are only executed and validated within a shard, and that state is only stored at the shard level.
According to the official beacon chain specification, Ethereum 2.0 will support 1024 Ethereum shard chains, each of which will be secured by a committee size of 128 validators.
Finality
As explained above, Nakamoto consensus and its variants, as used in Ethereum 1.0, provide relatively weak finality guarantees in the form of a probabilistic approximation. For this reason, Ethereum shard chains add a finality overlay protocol in order to provide stronger guarantees. In this protocol, validators are encouraged to attest to the validity of each block by signing it using BLS signature aggregation. These signatures, when added up, constitute a vote for the validity of a block. Once a two-thirds majority is reached, finality can be considered essentially stable.
Conclusion
As with the rest of Ethereum 2.0, sharding is expected to be phased in gradually. The current roadmap foresees the beacon chain to be deployed first, before sharding will be enabled. EVM state transition functions, light client support, and cross-shard communication will follow in subsequent phases.
