A Master Shard to Account for Ethereum 2.0 Global Scope

But … Ethereum 2.0 specs do not have a Master Shard!

Current Ethereum 2.0 proposals mention the Beacon Chain, which will host the Execution Environments code and (maybe) the last state root hash for each shard. We have Block Proposers and (maybe) a Network of Relayers, who can compute transaction results. We have Validators, part of shard committees, who validate proposed blocks and send the shard state root to the Beacon chain.

  • you can redeploy a contract on another shard that uses it frequently — ok for libraries, not great if you need the entire cross-shard storage

Global Scope for High-frequency Reads and Writes

We need sharding in Ethereum because it is decentralized and anyone can store whatever they want on-chain. And they don’t need to worry about the storage. Heck, they don’t even need to run a full node themselves.

A Master Shard to Account for Global Scope

We propose the existence and functionality of a special shard that we call Master Shard (MS). The main intent is for it to act as cache for frequently-used contracts and (frequently-used & rarely-modified) data from all the normal shards and bring them into the “global scope”, optimizing thus the inter-shard operations.

  • Update <shardId> <typeOfResource> <resourceId1> <resource2>
  • Get <shardId> <typeOfResource> <resourceId>, returns the cached <resource>

Writing to the Master Shard

Writing to the MS cannot be done through a normal, user-initiated transaction. This is a process controlled by the Beacon Chain’s EEs.

function reducer(shard_prev_state_root, block_data) {
// reduce, hash etc. return shard_next_state_root;
function reducer(shard_prev_state_root, ms_prev_state_root, block_data) {
// get MS state transitions from block_data and add them to the previous MS state
// reduce, hash etc.
return [shard_next_state_root, ms_next_state_root];

When Is a Resource moved To the MS?

I mentioned that the VM looks at how frequently a Shard1 resource is used and determines if it should move it to the Master Shard.

Updating Resources on the Master Shard

If a transaction is sent to a smart contract on Shard1, triggering a change of a resource that is cached on the MS, the EE will also update the cached resource, using the Update MS transaction.

Removing Resources from the Master Shard

The easiest solution would be resetting the MS after a number of blocks (i.e. equivalent of 1 year), removing the cached resources. There are other solutions, but more complex or computationally intensive, that we will propose.

Reading from the Master Shard

Each time a transaction sent to a shard requires to read data from another shard, it will first look in the global scope (MS), to see if the data is cached. If it is not, the transaction will continue normally. If it is, it will use the global scope. The MS enables data memoization.


  • avoids redeployment of libraries and contracts to multiple shards
  • cross-shard transactions will be faster if read data is cached
  • provides fast access to a galaxy of generally important data like dType and globally important collections like English language words, geographic points of interest, etc.
  • there are gas costs to caching data which should be clarified in more detail

Master Shard and Funding Ethereum Development

The MS caching could also be used to fund Ethereum development. Part of the gas costs saved by caching into the global scope can be directed to an account used for this purpose.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store