bug: decrementing 0 should fail, but it's getting successful transaction

[marciob]

Bug Report

Kakarot version:

when decrementing 0 it normally should get a failed transaction, but actually it is getting a successful transaction.

Current behavior:

while testing that decrement function with a count state 0:

    // Function to decrement count by 1
    function dec() public {
        // This function will fail if count = 0
        count -= 1;
    }

when trying to decrementing from the 0 value, although the state value still remains 0, it is getting a successful transaction, it should fail.

Expected behavior:

when trying to decrementing from the 0 value, the txn should revert with an error like that:

transact to Counter.dec errored: VM error: revert.

revert
	The transaction has been reverted to the initial state.
Note: The called function should be payable if you send value and the value you send should be less than your current balance.
Debug the transaction to get more information.

Steps to reproduce:

I used that contract:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.17;

contract Counter {
    uint public count;

    // Function to get the current count
    function get() public view returns (uint) {
        return count;
    }

    // Function to increment count by 1
    function inc() public {
        count += 1;
    }

    // Function to decrement count by 1
    function dec() public {
        // This function will fail if count = 0
        count -= 1;
    }
}

at the initial state, with count at 0, I tried to call dec(), it got a successful transaction.

Other information:

EVM environment: Kakarot ZKEVM blockchain (Testnet)
Solidity version: 0.8.17
No balance was sent to the contract upon deployment.

[Eikix]

why does the note talk about value and payable?
did you try to reproduce on the normal remix evm?

[marciob]

@Eikix I am testing from the "Solidity-by-example" contracts examples, the comments in the contract are from there.

Yes, I tried to reproduce on normal remix, the "Expected behavior" mentioned is from the normal remix evm.

[marciob]

also, the "payable" note from remix I guess it's a default note in some errors, just in case.

[ClementWalter]

I remember that we once used safe_uint256 that was actually raising, but we found out that it was normally the solidity compiler that adds the safe checks and revert and not the SUB opcode.

Actually, running in the playground I do see that it's reverting, but after GT on the result of SUB, not sure exactly what happens for us though. We could add a test into test_counter

[ClementWalter]

just tried rn adding a test to test_counter.py and it doesn't REVERT.

See #767