We just published the proposal from the Ewasm working group, one of the three main Eth 1.x working groups (the other two are state rent and data collection). This is a “pre-EIP” document and lays out the background, motivations, and high-level goals of the initiative. The document is public and commenting is turned on (or we can discuss here, of course).
Hugo kudos and thanks to @AlexeyAkhunov @axic @cdetrio and many others who did the heavy lifting here.
Thanks a lot for this publication! Looking forward to more details, specifically on deterministic interpreters/compilers, and interface between EVM and eWASM.
I just wanted to comment, that linear cross-contract storage proposed in the Storage Rent proposal would integrate nicely with eWASM, because it is linear. You could imagine memory-mapping part of linear storage (in R/O or R/W mode) before calling eWASM routing.
turbo-ewasm has an upcoming proposal for memory-mapping, we are going to study the cross-contract storage proposal and update it. Thanks for pointing this out.
(Hello Magicians. Porting this over from twitter…thanks Lane)
Regarding security…does the existence of two parallel VM’s introduce systemic risk? The increased complexity of having separate VM’s, executing separate instruction sets, seems to increase the attack surface. In other words, the security benefits gained from eliminating dependance on precompiles might be countered by the resulting complexity stemming from the above proposal. Or can those risks be managed? And loosely speaking, how would you go about testing this setup? Could you throw fuzzers at it, similar to how Geth/Parity is tested?
On another note, it seems like this would make life a bit easier for end-user DApp developers. If so, that’s a nice win : )
First of all, what is systemic risk in this context? 
I only heard this term used in relation to bank collapsing causing collapse of the financial system and economy going into recession.
Sure, it is risky to have two VMs. It might not be super elegant, and in the hindsight, EVM could have been done better. But waiting for pure eWASM chain is basically waiting for Eth2.0.
Whether this risk is worth it? I think it is. Introducing it sooner rather than later would solve chicken and egg problem - to give motivation for creation specialised WASM interpreters and compilers for adversarial environments - with guarantees on compilation times and runtimes of opcode (currently this motivation is lacking). And if those new compilers and interpreters are creators, I am sure they will be ingested back into the Web world, where WebAssembly came from - to improve security of Web browsers.
Way to manage this risk? I think it is already in the proposal - first using eWASM for precompiles, before making it available for all contract developers.
On testing and fuzzing - I suspect eWASM team have some fuzzing experts onboard