Contract Hash Endian Mismatch between GetAppLog and GetContractState

[devhawk]

I deployed a contract to test net. In the getapplicationlog response, the result.executions.notifications contains:

[
    {
        "contract": "0xfffdc93764dbaddd97c48f252a53ea4643faa3fd",
        "eventname": "Deploy",
        "state": {
            "type": "Array",
            "value": [
                {
                    "type": "ByteString",
                    "value": "tMUieFpmq0OGiYWowGJANoOfFxY="
                }
            ]
        }
    }
]

tMUieFpmq0OGiYWowGJANoOfFxY= is 0xB4C522785A66AB43868985A8C0624036839F1716 in hex. However, if I pass that hex value to GetContractState, I get a "contract not found" error.

Via dora I was able to determine that the correct contract hash is 0x16179f83364062c0a885898643ab665a7822c5b4. the value returned from getapplicationlog needs to be byte swapped before passing it to getcontractstate.

is it possible to make these more consistent? It's bad enough that getapplicationlog uses base64 encoding while getcontractstate expects hex encoding. Do we have to force users to swap bytes too?

[roman-khimov]

I don't think it's possible to fix this, at least not without actually fixing neo-project/neo#938. Notifications are [name, stack item] pairs in their essence (tied to contract of course) and stack items can contain whatever data can be on VM stack in exactly the way it's represented there. Contract hash is not much different from any other ByteString in VM, so it gets translated to base64 as regular ByteString and changing it doesn't seem to be correct, because in VM world that's how the hash is represented, this it what you pass to Contract.Call for example. Changing getcontractstate doesn't seem to be correct either as all other JSON communication implies reversed hash where we expect a hash to be passed (like contract field in this log).

[devhawk]

Thanks for the link @roman-khimov. I knew that I had seen this issue somewhere before