On the size check in the NUMEQUAL instruction about neo-vm

[lightszero]

@erikzhang
I had checked that.

In IL,when a 'object' == 'another object', it is a ceq opcode.except that object type had a overload equal method.

But the type" byte[]" do not overload equal method.
so byte[]== byte[] is a object==object, got a IL ceq opcode

and int== int got a IL ceq opcode too.
so can't tell is object==object or int==int or byte[]==byte[] just from IL code in current address.

[erikzhang]

I don't think it's the problem. The equality comparison of ByteArray uses EQUAL instead of NUMEUQAL.

[hal0x2328]

I can confirm - I stumbled on the issue independently while testing my debugger (I noticed several missing contracts on TestNet after upgrading to 2.10.1) and traced it to this issue - the NEL contracts all use this code in their upgrade operation before they continue to the Contract.Migrate call:

if (script == new_script)
    return false;

I debugged a past upgrade operation they did on-chain on TestNet and found that it is indeed using NUMEQUAL for the comparison as @wowoyinwei said.

[shargon]

Thanks for your feedback, the fix was made on #124

[vikkkko]

When I debugged, I found the returned false in the NUMEQUAL instruction that caused the failed execution. Then I removed the size verification in NUMEQUAL and there would be no problem.
Because only the comparison of the contracts is likely to exceed the size limit, it is considered to be the reason.
I will look into it again.

[vncoelho]

@hal0x2328 also found some interesting insights about it. Maybe it has some inconsistency in recent versions. Let's investigate further.

[igormcoelho]

reverting this change wont cause any problem, as theres no issue in.comparing.bignum. This limitation only.applies to keeping them.in memory, over 32bytes. So if reverting resolves, I vote for revert.

[vikkkko]

Since I suspect that it is a problem caused by the comparison of scripts, I did a test and first I wrote the following contract:

    Public class Test : SmartContract
    {
        Public static object Main(string method, object[] args)
        {
            String magicStr = "20190411";
            Byte[] script = Blockchain.GetContract(ExecutionEngine.ExecutingScriptHash).Script;
            Return script == new byte[] { };
        }
    }

The contract hash is 0xa4c86aff3437cd7ed76d415f0e5701eb06cac325 deployed on the TestNet

First, I sent an invoke request to the node http://seed2.ngd.network:20332 (version2.10.0). The body of the request is as follows:

{
  "jsonrpc": "2.0",
  "method": "invokefunction",
  "params": [
    "0xa4c86aff3437cd7ed76d415f0e5701eb06cac325",
    "",
    [
    ]
  ],
  "id": 3
}

What was returned was as follows:

{
    "jsonrpc": "2.0",
    "id": 3,
    "result": {
        "script": "00c1006725c3ca06eb01570e5f416dd77ecd3734ff6ac8a4",
        "state": "HALT, BREAK",
        "gas_consumed": "0.143",
        "stack": [
            {
                "type": "Boolean",
                "value": false
            }
        ]
    }
}

Then I sent the same request to the node http://seed5.ngd.network:20332 (version2.10.1), and what was returned was not the same:

{
    "jsonrpc": "2.0",
    "id": 3,
    "result": {
        "script": "00c1006725c3ca06eb01570e5f416dd77ecd3734ff6ac8a4",
        "state": "FAULT",
        "gas_consumed": "0.134",
        "stack": []
    }
}

I also enabled two nodes locally. The only difference between the two nodes was that one node removed the size verification in the NUMEQUAL instruction. The local node that removed the size verification returned as seed2 did, and the node that retained the size verification returned as seed5 did.
@shargon @erikzhang

[erikzhang]

if (script == new_script)
    return false;

Why does ByteArray comparison use NUMEQUAL instead of EQUAL? This is definitely a compiler error.

[erikzhang]

https://github.com/neo-project/neo-compiler/blob/0f296ce71e13c64624a003ba2bb31aed44f6e274/neon/MSIL/Conv_Multi.cs#L584-L598

I don't understand. The compiler uses the correct instruction (EQUAL). Which compiler version are you using? @wowoyinwei

[vikkkko]

The compiled version of the NNC should be 2.3.0.9
The compiled version I tested yesterday is the latest 2.4.1.0
@erikzhang

[erikzhang]

@lightszero Can you find out why the compiler uses NUMEQUAL instead of EQUAL?

[igormcoelho]

This is really strange @wowoyinwei, I can confirm the strange opcode on 2.3.0.9.

#125 bytes
52 PUSH2  # The number 2 is pushed onto the stack.
c5 NEWARRAY  #
6b TOALTSTACK  # Puts the input onto the top of the alt stack. Removes it from the main stack.
6c FROMALTSTACK  # Puts the input onto the top of the main stack. Removes it from the alt stack.
76 DUP  # Duplicates the top stack item.
6b TOALTSTACK  # Puts the input onto the top of the alt stack. Removes it from the main stack.
00 PUSH0  #An empty array of bytes is pushed onto the stack
52 PUSH2  # The number 2 is pushed onto the stack.
7a ROLL  # The item n back in the stack is moved to the top.
c4 SETITEM  #
6c FROMALTSTACK  # Puts the input onto the top of the main stack. Removes it from the alt stack.
76 DUP  # Duplicates the top stack item.
6b TOALTSTACK  # Puts the input onto the top of the alt stack. Removes it from the main stack.
51 PUSH1  # The number 1 is pushed onto the stack.
52 PUSH2  # The number 2 is pushed onto the stack.
7a ROLL  # The item n back in the stack is moved to the top.
c4 SETITEM  #
61 NOP  # Does nothing.
68 SYSCALL 2d53797374656d2e457865637574696f6e456e67696e652e476574457865637574696e6753637269707448617368 # System.ExecutionEngine.GetExecutingScriptHash
61 NOP  # Does nothing.
68 SYSCALL 1a4e656f2e426c6f636b636861696e2e476574436f6e7472616374 # Neo.Blockchain.GetContract
61 NOP  # Does nothing.
68 SYSCALL 164e656f2e436f6e74726163742e476574536372697074 # Neo.Contract.GetScript
00 PUSH0  #An empty array of bytes is pushed onto the stack
9c NUMEQUAL  # <------------------------------ shouldn't be there
61 NOP  # Does nothing.
6c FROMALTSTACK  # Puts the input onto the top of the main stack. Removes it from the alt stack.
75 DROP  # Removes the top stack item.
66 RET  #

Somehow, this new byte[] { }; is possibly being considered as a number... but it's very strange and unlikely. I'll try to look into it, it shouldn't be there.

[lightszero]

let me see see，byte[] in avm is a number,that is fine. i will check why is numequal