RE: Proposal for upgrading the Ethereum VM with wasm

Dear all,

I think you can see it both ways but basically:

Wasm seems to not suit your needs entirely and the question is: how could it or have you missed something that would make it fit.

Hence it makes sense to be in the design repo as an issue to state your needs and whether Wasm will be able to handle it either MVP, post MVP, or really later down the road.

Thanks,
Jc

From: Martin Becze [mailto:mjbecze@gmail.com]
Sent: Tuesday, December 22, 2015 3:46 PM
To: JF Bastien
Cc: public-webassembly@w3.org
Subject: Re: Proposal for upgrading the Ethereum VM with wasm

Sure I'll do that! I just wasn't forsure if it would be want there, since this has more to do with Ethereum than wasm.

On Tue, Dec 22, 2015 at 11:43 PM, JF Bastien <jfb@google.com<mailto:jfb@google.com>> wrote:
Hi Martin,

Could you please move the discussion to WebAssembly's design repo<https://github.com/WebAssembly/design/>? We usually file issues for these discussions, it ends up being easier to follow along, search, and find later.

Thanks,

JF

On Tue, Dec 22, 2015 at 3:36 PM, Martin Becze <mjbecze@gmail.com<mailto:mjbecze@gmail.com>> wrote:
Hello,
I wrote a proposal today for upgrading the Ethereum VM with wasm. You can see it here https://github.com/ethereum/EIPs/issues/48


One of the harder parts of fitting wasm to Ethereum is the current Ethereum opcodes CALL and CALLCODE.  CALL makes a call to another Ethereum contract (module) and the result is placed in memory at a specified location.  CALLCODE is kinda like dlopen. It injects code from a given contract into the current running code. Currently I don't know of anyway to support this kind of behavior with wasm semantics. So if we adopt the proposal we will have to modify the wasm VM some.

Please let me know if you have comments or suggests!

Thanks,
-Martin Becze