Categories
- 17.3K All Categories
- 9.5K Mining
- 574 Pool Discussion
- 378 Promotional
- 1.4K General Project Discussion (non-technical)
- 485 Education
- 811 Protocol and Client discussion
- 170 web3-js
- 29 Whisper
- 16 Swarm
- 3 RLP
- 303 IoT & Hardware
- 1.2K Smart Contracts and Dapps
- 28 Serpent
- 359 Solidity
- 664 Projects
- 1.2K Reference clients code and builds
- 249 Eth & AlethZero- Cpp Implementation
- 471 Geth - Go Implementation
- 242 Mist
- 15 Node.js Implementation
- 36 Python Implementation
- 49 Mix
- 36 Other Implementations
- 170 Meetups
- 40 Other Events
- 226 Jobs & Skills
- 281 Press and Articles
- 75 Audio/Video
- 296 Ether Sale
- 1.2K Other Languages
- 96 Chinese
- 255 German
- 33 Italian
- 111 French
- 3 Hebrew
- 42 Japanese
- 75 Portugese
- 46 Romanian
- 185 Russian
- 231 Spanish
- 47 Turkish
- 125 Watercooler
native contract extensions versus using an efficient VM
MarioFortier
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
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
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
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
They will be distributed with the core clients.
What about having a non-linear gas cost function, think a discount for big-gas contracts?
"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?
IMO the evm execution has a lot better shot of not having a hole in there due to its simplicity. Talking just
libevm/VM.hin cpp-ethereum andethvm/vm.goin 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)