`Shard` class and `ShardVM` class

What is wrong?

Create a Shard class which mirrors the Chain class and a ShardVM which mirrors the VM class.

How can it be fixed

Fill this in if you know how to fix it.

[pipermerriam]

Approach looks sound. Make it so!

[hwwhww]

@pipermerriam

New BaseVM class with common/shared methods between VM and ShardVM.

I’m looking into this, it seems easy to drag out some functions that related to gas_limit and uncles to be VM-only. But on the other side, so many functions are using block as their prefix, suffix, or are related to block_class and I’m not sure which of them could be reused in ShardVM at this moment.

I suggest that we can start with a simple overriding at the beginning, and then implement the new logic with collation in Stage 2:

1. In base.py, rename VM to BaseVM.

2. Create vm.py, VM, simply inherit BaseVM:

   class VM(BaseVM):
       pass
   

3. Create shard_vm.py, also inherit BaseVM:

   class ShardVM(BaseVM):
       pass
   

4. Rewire the ShardingVM fork to inherit this new ShardVM:

   ShardingVM = ShardVM.configure(
       name='ShardingVM',
       # classes
       _block_class=ShardingBlock,
       _state_class=ShardingVMState,
       # implementations from other VM forks
       create_header_from_parent=staticmethod(create_frontier_header_from_parent),
       compute_difficulty=staticmethod(compute_frontier_difficulty),
       configure_header=configure_frontier_header,
       ....
   )
   

5. When we start to apply Collation as the container, we override the basic functions in ShardVM if we need.

6. Refactor and clean up the common/shared methods.

I guess it would be less pain of backporting by this way. Any advice and suggestions will be greatly appreciated.