Deprecate SMC, Replace With an Interface and Mocked Methods for a Beacon Chain in Client

[rauljordan]

Hi all,

One of our goals in building the beacon chain is to eventually deprecated the Sharding Manager Contract defined in the client folder in our repo. The purpose of the SMC in the minimal sharding spec and our implementation is to:

• Handle the submission of collation headers and proofs of custody across shard, period pairs
• Select committees (notaries) on shards for a certain period
• Reshuffle committees across shards

These pieces of functionality will be replaced by the Random Beacon Chain and its RANDAO mechanisms + cross-link handling. In order to tie in our previous work on the minimal sharding spec with our beacon chain work, we should create an interface for the BeaconChain that we can implement through a mock struct and use within the client folder until the beacon chain is completed. This way, we can eliminate the SMC and be back on track with tying together the beacon chain + sharding. This will make our repository very cohesive and allow future contributors to know exactly what the beacon chain does and what our client folder handles.

I suggest we prioritize this and move in parallel with beacon chain PRs as it will get us closer to a demo/first-release sooner.

[terencechain]

To add more color, here are all the mock functions we need to implement:

Caller related functions:

• GetNotaryInCommittee() -- Sample notary, returns true if notary is selected
• ShardCount() -- Return total shard count
• LastSubmittedCollation() -- Return last submitted collation struct from the mock back end
• NotaryRegistry() -- Return notary struct from the mock back end

Transactor related functions:

• RegisterNotary() -- Register notary to the mock back end
• AddHeader() -- Add header to the mock back end