In Ethereum Casper 101 [1], Jon Choi gave a great clear overview of Casper and why explicit finality can be beneficial to scalability. The aim of this article is to give an overview of Ethereum sharding design and explain how explicit finality helps for blockchain sharding.
To fully understand the specification of Ethereum sharding mechanism proposal, I highly recommend digging in sharding doc [2] by Vitalik.
Blockchain Scalability Issues
- Growth of transactions. We love unicorns and kittens.
- Limitation of scalability with current block creation process. Block gas limit restricts the computational capacity of the block. Increasing block gas limit or decreasing block time too much would lead to high stale rate and weaken the ability of the network against attacks.
- Lack of parallelizability. First, current EVM operates transactions in sequence. Second, every full node executes each transaction and store the whole (or pruned) state trie for security and decentralization.
Further reading: EIP 648 — Easy parallelizability for executing transactions in parallel.
To solve scalability problems, sharding is a solution that introduces to on-chain state partition and gains higher throughput.
Terminology
At first, let’s take a look at terms for differentiating the objects on main chain (you can take as the current Mainnet chain) or shard chain in different levels:
You can simply imagine that the transactions would be wrapped in a “collation”; similar to block, a collation also points to its parent collation in chains — that’s the shard chains we’re going to talk about. Being a “collator” means having the eligibility to propose a new collation on the proof-of-stake shard chain.
Basic Quadratic Sharding
The Consensus of Shard Chain Depends on Main Chain
Similar to side chain technology, only the small pieces of proof of collations have to be recorded on main chain — that’s the basic idea of how we scale out the blockchain: (i) the shard chains have their own galaxy with their own transactions, shard validators only have to verify the shard they are watching for; (ii) shard chains also stick on main chain universe for reaching higher level of consensus via proof-of-stake mechanism.
Validator Manager Contract (VMC)
For joining shard chains on main chain, there’s going to be a special contract on main chain called Validator Manager Contract (VMC). VMC is the core of this sharding mechanism; the purpose of VMC can be outlined as follows:
- Proof-of-stake system. The validators’ stake may be slashed if they misbehaved.
- Pseudorandomness sampling. By applying recent block hash as the seed to sample the eligible collator. Basically, the validators deposit their stake in VMC, and then their validation code address would be recorded in a global validators pool list inside VMC. One shard chain validator would be sampled from validators pool list, and become the collator of the specific shards in specific “period” (as it will be explained below). The idea is making validators unable to forecast when they would be the collator and in which shard many days ago.
- Collation header validation. VMC contains an
addHeader(bytes collationHeader)function to verify the collation header and writing a record of valid collation header hash. This function provides on-chainverification immediately. - Cross-shard communication. By utilizing UTXO model, the user can deposit ether on a specific shard via transaction call and create a receipt (with a receipt ID) on main chain. The shard chain user can create a receipt-consuming transaction with the given receipt ID to spend this receipt.
- On-chain governance. With VMC as the parliament, it enables validators to vote on-chain.
How to Propose a Collation in Shard?
In phase 1, VMC would maintain 100 shards (SHARD_COUNT = 100). Each shard operates in parallel and the clients of shard i only have to verify the transactions on shard i.
“period” is defined as a window of block times, e.g., PERIOD_LENGTH = 5 means 5 blocks per period. This indicated in each period, there’s only lesser than or equal to one valid collation for each shard.
Once the validator gets sampled to be eligible collator to propose a new collation, the collator has to validate the recent collations and send a transaction to call addHeader function. Note that if the collator is sampled to propose a new collation on period 10, that means the addHeader transaction has to be included in period 10, i.e., block number10 * PERIOD_LENGTH to block number (10 + 1) * PERIOD_LENGTH — 1.
The collation header hash must be recorded on VMC to prove its header is valid in global. Also, the other validators of the shard have to watch VMC all the time for getting latest status and then verify if the transactions are valid too.
Fork Choice Rule of Shard Chain
In basic sharding, the fork choice rule depends on the longest main chain. The valid head collation of the given shard is not simply the head collation of “longest valid shard chain” but the “the longest valid shard chain within the longest valid main chain”.
An example is described in Figure 3: in Figure 3(a), there are two forks of main chain and the second chain is the longest valid main chain in the following figure. Since block B3 is the head block, it’s easy to see that collation C3 is the head collation.
And then block B3' arrives in Figure 3 (b). Assume that the score of block B3 is higher than the score of block B3', so the upper chain is still the longest main chain:
Lastly, block 4 arrives in Figure 3 (c). Note that for this shard, collation C3has a higher score than collation C2, but the below chain is the longest valid main chain, so collation C2 is the head collation now:
Further reading: another design — Vlad Zamfir’s sharded fork choice rule.