The current phase 2 proposal takes this model and generalises it. There can now be several, even many, types of EVM (called execution environments, EEs). An EE is code written in eWASM that runs as an (almost) pure function. This means that an EE does not store any state itself: anything it needs to know has to be provided to it along with the transaction. So, for example, if I want to transfer a token to you, then along with the transaction I need to provide a proof (such as a Merkle branch) of my balance of that token; the EE has no independent idea what my balance is since it does not store anything. Actually, this is not quite true: each EE will store a single 32 byte value that is some sort of digest or accumulator of its current world state (maybe a Merkle root, but this is not prescribed, it could be anything sufficiently secure).

Abstracting out the execution layer in this way allows for the ultimate in flexibility. There could be EEs for zk-Rollups, or ERC20-like tokens, or enterprise-friendly environments, or Plasma, or smart contracts written in Haskell if you like all that lazy functional goodness, or that mimic Libra's Move VM2, or even an EE that runs the EVM, allowing for a near seamless transfer from Eth1 to Eth2. Each EE could have its own replay-protection, or signing scheme, or permissioning requirements: abstraction is power.

The idea is that, for a reasonably large fee (~100s of Eth?), anyone could deploy their own EE to support their own specialised blockchain environment. The Ethereum 2.0 shard chains just focus on the fundamentals: transaction ordering and