Allow `VM` class to specify what `ChainDB` class it uses.

What is wrong?

In #350 the differences between shard collations and blocks required a bit of a hack to make the persist_block_to_db to work with both blocks and collations.

While we could try to sufficiently abstract the API, such as separating things into persist_block_to_db and persist_collation_to_db, I don’t believe this is the right solution. Eventually, we are bound to have either blocks, transactions, or something that require more such logic forks to handle.

Py-EVM has so far largely avoided these types of logic forks in it’s code by sufficiently abstracting the overall API so that underlying implementations can be swapped out within each VM.

How can it be fixed

I think that the Chain class should be modified so that it takes a backend DB type, and then delegates to the active VM for the appropriate block number to get the ChainDB. Each VM class can then define their own ChainDB class. Then the ShardVM class can expose it’s own ChainDB class with modified persist_block_to_db method.

[pipermerriam]

So far this is turning out interesting and I think promising. The VMState object’s usage is basically direct database access so it’s looking like I may be able to completely eliminate the snapshot/commit/revert API as well as moving the API for the account state database to be directly on the VMState object.

[pipermerriam]

So, maybe to tie this all together, though I’m not confident that I’ve got all the pieces right.

• Independent adapter implementations for VM give internal flexibility with regard to EVM semantics, enabling different logic for dealing with blocks, transactions, collations.
• Independent adapter implementations for the VMState currently have no direct need that I see, but the implementation looks pretty simple.
• Independent adapter implementations for the Chain as well as different implementations of the Chain class itself should enable the Fill/Light/Stateless use cases.