Blockchain Explicit Finality for Sharding

Implicit Finality v.s. Explicit Finality

At first, I have to clarify that the sharding mechanism should be able to apply in both proof-of-work chain and proof-of-stake chain; even so, explicit finality gadget like Casper can make sharding stronger.

In general proof-of-work chains, finality is probabilistic and implicit [1] [5]; in simpler words, it’s always possible to rewrite the chain even the block has gotten thousands of confirmations. In contrast, applying proof-of-stake with Casper the Friendly Finality Gadget (“FFG”) cryptoeconomic mechanism explicitly enforces finality of we-can-check-if-its-finalized-for-us in-protocol.

[Notes from Vlad] There’s an economic risk of in-protocol explicit finality threshold: it creates the ideal cartel sizes at 2/3 + 1 and 1/3 + 1 . Accordingly, the marginal contribution to finality of any node which is not in 2/3 + 1 coalition becomes 0. 🥒

Dependency on Main Chain Finality

In basic sharding, the shard chains are pegging on main chain.

To the shard validators, we expect with sharding, the blockchain capacity became 100x higher in phase 1, thus all the validators of these 100 shards will need to watch VMC status to get the correct valid head collation. It’s important for validators to be certain of know they are the collator or not as soon as possible; to the normal users, if we apply cross-shard transactions in phase 2, the normal users will also need to retrieve their deposit information (receipt ID) on VMC.

Explicit finality would help for mitigating the uncertainty of syncing between main chain and massive shard chains.

Explicit Finality Helps for Stateless Client

The basic idea of stateless clients is that the stateless clients don’t store the whole state trie, instead, they only store the state trie root. The archival clients store the full state trie and provide the Merkle branches that the given collation needs. With these Merkle branches, the stateless clients are capable of building the partial state trie and verifying the collation [6].

The syncing process would be triggered once the validator gets sampled and starts reshuffling (i.e., changing the shards which the validators watch for and syncing the shard chains). With stateless client mechanism, the cost of reshuffling drops to (near) zero because they only have to validate the recent collations (i.e., collations with high score) to sync with the shard.

Figure 6. Stateless client model. (Icons made by DinosoftLabs from www.flaticon.com is licensed by CC 3.0 BY)

Since the syncing process could be much faster, stateless client model makes it possible to reshuffle between each collation. It not only reduces the storage burden and overhead but also makes the system more secure because frequent sampling gains adaptive attack resistance.

Although the syncing cost becomes much lower, the stateless validators still have to verify as more collations as they can within a certain period of time to confirm that they get the best valid collation with the highest score.

Casper FFG will provide explicit finality threshold after about 2.5 “epoch times”, i.e., 125 block times [1] [7]. If validators can verify more than 125 / PERIOD_LENGHT = 25 collations during reshuffling, the shard system can benefit from explicit finality and be more confident of the 25 ahead collations from now are all finalized.