Backwards Compatibility; Secure Metering Isolation

[wanderer]

Overview

There are three ways to achieve backwards compatibility with EVM1's gas prices in EVM2 in a secure manner. Currently in the prototype we are just leaving EVM1 gasPrices unmodified but this is not secure under the assumption that some severe mismatch in the gas price of an EVM1 opcode is found in the future that doesn't affect EVM2.

1. Meter all the EVM1 contracts in with the EVM2 gasprices which target 0.5 second processing time. This is perhaps the cleanest way but it has the disadvantage to this is that some EVM1 opcodes and precompiles will cost more than they currently do which could break some contracts (it will also force all contract to run wasm VMs, there will be no way to fallback to EVM1 implementation when running an EVM1 contract).
2. Lower all the EVM2 gasprices to the point that all the EVM1 opcodes and precompiles cost less or equivalent to what they cost now. This would might have the effect of lowering the overall gasLimit for EVM1 contracts and may make some EVM1 contracts unusable
3. Have separate gasPrices for EVM1 and EVM2 contracts. This is the most pluralistic option but is more complex than 1 and 2.

This issue is to explore option 3.

Rational

As the recent DOS attacks have shown metering in EVM1 can be inaccurate therefore EVM1 contracts need to have isolation from EVM2 contracts if they are metered differently. Having different Metering Types for EVM1 and EVM2 would allow nodes to change gas limits and accept different gas prices for each type. In case of a DOS attack on EVM1 the gaslimit could be lowered just for EVM1 without affecting operation of EVM2 contracts.

Metering Types

name	binary encoding
EVM1	0x00
EVM1 (after EIP 150)	0x01
EVM2	0x02

BlockHeader structure

Change the gasLimit and gasUsed fields to an array containing [meterType, gasLimit, gasUsed]. If one of the metering types is omitted then this block doesn't contain any computation of that required that type. Gas Limit is calculated independently for each gas type using the canonical gas limit calculation as defined in the Yellow Paper.

Tx structure

In the tx replace the gasLimit and gasPrice fields with an array the contains the elements [[meterType, gasPrice, gasLimit] ... ] where each type must be a unique metering type. If one of the metering types is omitted then this tx will not fund any computation of that required that type.

[gcolvin]

Is "accurate" metering even possible? Stock systems vary a lot, even the same system can vary under load, and systems and clients can be customized to make expensive operations faster. Also, a little context on how inaccurate gas prices affect security would help me - this might be a problem not only for e-wasm, but for improvements in EVM 1.x.

[vbuterin]

I don't think any of us are under the illusion that a strict 1:1 mapping
between gas and microseconds is feasible. All I personally care about is
gas counting being (i) totally deterministic, and (ii) there being some
bound on how much the gas/microsecond ratio can change between different
opcodes; I think something under 4x would be ideal, current EVM seems to be
~20x not including the worst-case IO attacks (the worst offender seemingly
being DIV, though there hasn't been a complete survey done).

On Thu, Sep 29, 2016 at 4:09 PM, Greg Colvin [email protected]
wrote:

Is "accurate" metering even possible? Stock systems vary a lot, even the
same system can vary under load, and systems and clients can be customized
to make expensive operations faster. Also, a little context on how
inaccurate gas prices affect security would help me - this might be a
problem not only for e-wasm, but for improvements in EVM 1.x.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#50 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACIKbh2kDTrvhpMjtL2d6glIGRj4dGTaks5qvBrhgaJpZM4KJzwX
.

[wanderer]

Is "accurate" metering even possible?

@gcolvin no not exactly but the more we can move into the VM the better it should become. Then we only need to focus our attention on the metering of the base Instruction Set. Webassembly instructions were selected because correspond to instruction found on common hardware. Therefore we can get finer grain resolution on the average computational time. But this is definitely not 100% accurate.

The point here is to assume hypothetically some severe mismatch in the gas price of an EVM1 opcode is found in the future that doesn't affect EVM2. How could we isolate this fail to EVM1 contracts without affecting the entire ethereum computer? In the DOS attack, miners lowered the gasLimit. It would be nice if in the future validators could do the same for either EVM1 or EVM2 without taking down the gasLimit on both of them.

@vbuterin I would like to add to the care list is (iii) not to break any EVM1 contracts if possible. 😸 Option 1. Would be the easiest but it might break some EVM1 contract. Option 3 is my favorite currently b/c it is extensible. so for example it would be easier to add another metering type for something like storage.

anyone have any more options to add? or thoughs on the current options?

[gcolvin]

@vbuterin Yeah, even on hardware DIV is very much slower than the other operations, and in software it gets worse, probably much worse than 20x. It might be the only one so far off as to matter. Is it too late to fix this mistake?

It does strike me that the larger the number of independent clients and varieties of hardware on the network the less likely it is that a worst-case attack on one will be so on another.

@wanderer For interpreters operations can be typically be consistently timed - but can vary a lot between interpreters. And native code such as emitted by a JIT or wasm engine will vary in quality, and effects besides cycle typically dominate. Plus the other source of variation I mentioned. So it's still not clear to me that different implementations of the same client will vary that much more than implementations of different clients, in which case option 3 doesn't help much.

But I confess I don't really understand options 1 and 2. Have they been detailed elsewhere?

Another approach might be to look at optimal wasm implementations of EVM1 opcodes and scale the EVM2 opcode gas costs to align the cost of the EVM1 opcodes and their implementations.

[wanderer]

@gcolvin right, i agree that we can't get accurate metering, only 'better'. And option 3 attempt to make metering more accurate. Its only trying to provide isolation. Its assuming

1. EVM1 contract and EVM2 contract are metered differently
2. There could be a DOS susceptible flaw in either EVM1 or EVM2 metering scheme

Allowing miner/validators to adjust the gasLimit for the different metering types gives miners a way to migrate the DOS attack without having affecting the other metering types gas limit.

Another approach might be to look at optimal wasm implementations of EVM1 opcodes and scale the EVM2 opcode gas costs to align the cost of the EVM1 opcodes and their implementations.

I think that is 2.

options 1) is just using the output of evm2wasm then injecting the result with evm2 metering I think @axic has some more stats on the EVM1 precompiles metered in ewasm metering

[gcolvin]

I'm guessing that DoS-susceptible flaws can also appear across other categories (e.g. the Go wasm VM has susceptibility that the Parity VM doesn't) so allowing out this one case might not help.

So if I've stumbled back on option 2 I'm not seeing how the problem you describe arises. But I'm assuming the scaling step only provides for rough alignment, with injected metering providing exact reproducibility.

[wanderer]

I'm guessing that DoS-susceptible flaws can also appear across other categories (e.g. the Go wasm VM has susceptibility that the Parity VM doesn't) so allowing out this one case might not help.

yep, this is only to regards to metering that might be off in the protocol. If the attack is on something else then of course it wouldn't apply.

So if I've stumbled back on option 2 I'm not seeing how the problem you describe arises. But I'm assuming the scaling step only provides for rough alignment, with injected metering providing exact reproducibility.

yeah for example EXP implemented would cost around x10 more if gas metering in the current ewams metering schedule. Now if we just shift the EVM2 cost down untill it it is equal or less than the current EVM1 cost, then EVM2 operations would be super cheap compared to EVM1 operations which might be actually be ok.

I'm actually leaning towards 2 now. The only nice thing about 3. is that could offer some nice extensibility in the future.

[gcolvin]

Not sure what you mean by "cost around x10 more if gas metering in the current ewams metering schedule." Ten times more than what? And no time to read the code, but are using an O(exp) or O(log E) algorithm? Gotta run...

[gcolvin]

In general for the 256-bit opcodes there can be a lot of variation between clients depending on the choice of algorithms and quality of implementation. Much more than 4X, and not a constant factor but differences in time and space complexity. E.g. clients that use the O(E) modular exponentiation algorithm for EXP can be brought to their knees by large exponents that the O(log E) algorithm will handle just fine. This is true for EVM2 clients as well. So I do think that merely distinguishing EVM1 from EMV2 is not adequate. Can a system of registering each client be devised so that if particular clients are being successfully attacked they can be dealt with? But again, the more independent clients the more resistance to systemic attack.

[wanderer]

Ten times more than what?

if we meter transcompiled evm1 code with evm2 gasprices, under option 2