native contract extensions versus using an efficient VM

MarioFortierMarioFortier Boston, MAMember Posts: 30
This post relates to https://blog.ethereum.org/2014/08/27/state-ethereum-august-edition

The proposed solution for native code extensions running outside of the gas-realm is a deviation from the simpler idea of tracking cost of small execution steps. I think the proposed fix is too complex and does not resolve the root cause: the EVM design is not speed efficient.

Performance issues might be related to the instruction set being too small, being interpreted, being stack-base or lack of optimization phase in the tool chain... anyway, we probably all agree here that it is not "fast" enough.

I believe the safest path to end-up with an efficient EVM is to re-use what has been developed for years: either Mono/CLR or JVM.

Optimized intermediate language and JIT compilation is key to resolve the root cause.

How can this work?
============
Roughly, I estimate 4 months one engineer and the following will very likely work:
- Select an existing VM, say Mono/CLR for example.

- Do a contract to C# translation tool. Consider first using only a subset of C# to simplify the gas consumption logic (done in next step).

- Modify the C# compiler to inject CIL (intermediate code) for keeping track of gas for each CIL instruction from the contract code... that is the hard part. An alternative to explore would be to move some gas tracking at a higher level, say the C# generation phase.

- EVM code (now CIL with gaz tracking) are still the contract code in the block-chain. Making a contract to be load as a package or assembly allows inter-contract call. All the hard work is done, just have to use it.

- Will need some development time for security and sandboxing (e.g. to prevent dependency on assembly that are not gaz metered), but such isolation has been done before by many others.

Some good info for tracking cost at CIL instruction granularity: http://msdn.microsoft.com/en-us/library/ms973852.aspx

In Short
=====
If you use an existing intermediate language over an existing VM supporting JIT, in the end the "EVM" will:

- run a couple order of magnitudes faster than the current design.

- might run about half the speed of native code (after JIT and with consideration of doubling the number of native instructions for gaz consumption tracking).

Beside resolving the root cause, you get a new marketing bullet that contracts are sandbox and run over a well-known VM.

\Mario Fortier

Comments

  • MarioFortierMarioFortier Boston, MAMember Posts: 30
    edited September 2014
    Thinking of it, code injection for gaz metering would be better done at the full node, after the CIL contract code is downloaded and before loading into the VM.

    Advantages:
    - the C# compiler does not need to be modified.
    - the contract code in the block chain is smaller.
    - the miner can be 100% sure the proper metering is applied to all contracts running.

    In other word, code flow for adding a contract would be:
    Serpent/Mutan/LLL -> C# -> CIL (stored in Block Chain)

    The code flow for calling into a contract would be:
    CIL (from Block Chain) -> CIL+metering code injection -> VM Dynamic Binding -> JIT -> Native execution

    Most of the complexity is handled by Mono/CLR and, again, the same could be done in the JVM world.

    \Mario Fortier
  • CfBCfB Member Posts: 29

    I believe the safest path to end-up with an efficient EVM is to re-use what has been developed for years: either Mono/CLR or JVM.

    It's safe as long as Ethereum community has people that know internals of Mono/JVM well enough to instantly fix a flaw/bug if one is suddenly found. Otherwise a single 0-day vulnerability will bring the whole network to knees.
  • MarioFortierMarioFortier Boston, MAMember Posts: 30
    edited September 2014
    CfB said:

    I believe the safest path to end-up with an efficient EVM is to re-use what has been developed for years: either Mono/CLR or JVM.

    It's safe as long as Ethereum community has people that know internals of Mono/JVM well enough to instantly fix a flaw/bug if one is suddenly found. Otherwise a single 0-day vulnerability will bring the whole network to knees.
    (By 'safest path' I meant reducing risk to reach the goal, but I am fine to switch the discussion to VM security issues).

    The Ethereum community will be left to themselves to fix a 0-day vulnerability specific to the VM only if they try to build their own.

    ===

    I assume we are talking here of attacks that can prevent a large number of miner to operate. The attack surface is way larger than the VM executing the contract... but lets keep focusing on your concern specific to Mono/JVM.

    Our best hope to keep the network humming is diversity.

    Diversity among running instances of Mono/JVM is already done. They differ by their implementation, version installed, host OS and platform.

    Ethereum is making the additional noble effort to diversify with independent implementation in different language, but it is yet to be seen how this will turn out in practice. Miners have a tendency to choose the most profitable implementation, and one will be dominant (likely C++).

    \Mario Fortier
    Post edited by MarioFortier on
  • MarioFortierMarioFortier Boston, MAMember Posts: 30
    edited September 2014
    If the advantages of replacing the current EVM implementation are too hard to swallow, then I suggest to use the mature VM+gaz metering solution for at least sandboxing the execution of the "native extensions".
  • TechnologovTechnologov Member Posts: 102 ✭✭
    Also what happens if some miners have installed "native contract extensions" and others don't ?
  • StephanTualStephanTual London, EnglandMember, Moderator Posts: 1,282 mod
    @Technologov‌: code extensions are not designed for mission specific purposes. Instead, they represent generic, desirable yet potentially gas costly functions. For examples, data structures such as heaps or things like ecrecover.

    They will be distributed with the core clients.
  • wireswires Member Posts: 7
    I'm also not a big fan of the proposed fix...

    What about having a non-linear gas cost function, think a discount for big-gas contracts?
  • eaglgenes101eaglgenes101 Member Posts: 43
    Then you could reduce costs by clobbering together several small contracts into one big one, which would encourage centralization. Ouch.
  • eaglgenes101eaglgenes101 Member Posts: 43
    And also: There are at least 4 open source javascript engines under active development, and each has its own strengths and quirks. Similarly, we might end up with multiple kinds of ethereum jits, some aiming to be general purpose, others focused on contracts with certain properties (like a quick interpreter aimed at contracts with few loops and/or subroutines)
  • TechnologovTechnologov Member Posts: 102 ✭✭
    Tual says:
    "They will be distributed with the core clients."
    So... it looks like a standard library ?
    Or more like a custom library that everyone can write for his own needs?
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    Our best hope to keep the network humming is diversity.
    No actually that is what helps make sure the protocol is well-understood, and a last line of defense if there is a blockchain split. If it happens a lot of people need to reinstall. Better to prevent it allthogether.

    IMO the evm execution has a lot better shot of not having a hole in there due to its simplicity. Talking just libevm/VM.h in cpp-ethereum and ethvm/vm.go in eth-go here, the rest all will still have to be present if C# were to be used.

    Of course, that is comparing the VM with C# or whatever bytecode, not comparing the VM with native extensions. As i understand it, with native extensions the idea is to basically artificially lower the gas cost of some contracts. So you could keep using the VM, though computationally prohibitive. The problem is to ensure that for anything with an artificially lower gas cast, people have time to get the native code implemented, and confident of the security of the native code, before the computation becomes prohibitive.(Vitalik seems to have a slightly different approach)
  • eaglgenes101eaglgenes101 Member Posts: 43
    edited September 2014
    People are probably going to make jits for ethereum to speed up mining, whether we like it or not. Probably better to just cut out the middleman and put a jit in the vm while we're still under development. Even the native code generated can be sandboxed, as NaCl has demonstrated.
Sign In or Register to comment.