eth/vm/logic/arithmetic: handle exp(X,0) == 1.

[veox]

What was wrong?

0^X calc was short-circuited. Y^0 == 1, but this wasn't tested for.

Caught by exp8.json test (not yet tracked in tests fixture on master).

Semi-accidentally caught in PR #1181, which updated the JSON test fixtures to a newer version, which does contain the exp8.json test. The failure got lost among others.

Can be seen in py3{5,6}-vm CI tests: for the EVM bytecode 0x600060000a600055, which is:

000000: PUSH1 0x00
000002: PUSH1 0x00
000004: EXP
000005: PUSH1 0x00
000007: SSTORE

... there was a 15000 gas use delta (to that of expected): as if the storage was (re-)set to 0, not 1. Mentioned CI runs:

• py35-vm
• py36-vm

How was it fixed?

• An additional short-circuit check for exponent == 0 was added.
• A regular test (as compared to ethereum/tests common tests) was added.

Cute Animal Picture

Source: not sure; via @ano at peepeth

[voith]

I have an unrelated question to this PR:
I was trying to understand this line:

py-evm/eth/vm/logic/arithmetic.py

Line 155 in 08674f6

result = pow(base, exponent, constants.UINT_256_CEILING)

In my understanding mod=constants.UINT_256_CEILING is used to prevent an overflow.
I was trying to see what would happen when base would be negative.

In [0]: pow(-1, 3)
Out[0]: -1

In [1]: pow(-1, 3, 2**256)
Out[1]: 115792089237316195423570985008687907853269984665640564039457584007913129639935

is this intended behaviour?

[pipermerriam]

Can you add a test for this here:

https://github.com/ethereum/py-evm/blob/master/tests/core/opcodes/test_opcodes.py

[veox]

@voith I think so?..

The yellowpaper is a bit terse on this, but it does specify some signed arithmetic operations (e.g. SDIV in addition to DIV (division, /), or SGT in addition to GT (greater than, >); but not SEXP in addition to EXP).

It could be assumed that the stack values are to be interpreted as unsigned integers, but I haven't found this stated explicitly anywhere. (EDIT: Didn't look extra-thoroughly.)

There is a section on precompile 5 ("arbitrary-precision exponentiation under modulo"), for which one could assume the logic follows that of EXP. For this precompile, inputs are non-negative integers.

[pipermerriam]

@voith I am pretty sure @veox is correct that arguments are treated as unsigned integers.

[veox]

@pipermerriam Should be able to...

[voith]

For this precompile, inputs are non-negative integers.

Yeah, just tested some solidity code. solidity doesn't allow exponentiation when the base is negative!

[veox]

@pipermerriam See commit e7b0af9: tests 0^0==1, 0^1==0. Is this enough? Too much?..

---

EDIT: If OK, should be fine to squash-and-merge on your end. ;)

[carver]

Side note: looks like it would be valuable to have a parametrized fixture in conftest that returns all mainnet VMs. Then this would reduce to two cases, and we wouldn't have to remember to update the test on every new fork, like:

@pytest.mark.parametrize(
    'base, exponent, expected',
    (
        (0, 1, 0,),
        (0, 0, 1,),
    )
)
def test_exp(mainnet_vm, base, exponent, expected):
    computation = prepare_computation(mainnet_vm)
    computation.stack_push(exponent)
    computation.stack_push(base)
    computation.opcodes[opcode_values.EXP](computation)
    result = computation.stack_pop(type_hint=constants.UINT256)
    assert result == expected

[pipermerriam]

Lets wait for the chain-builder to land as it will make this a lot easier to do

[pipermerriam]

chain builder has landed so this should be pretty easy now