Base58 does not preserve one-to-one byte correspondence with the
original data, so different combinations of the same number of bytes
might have different encoded string length. We use GAS transfer to mint
HASHY token, where the token hash is Base58Encode(Ripemd160(data + txHash)).
The problem is that `invokescript` RPC call is used to define transfer tx
sysfee, thus, txHash during testinvoke differs from the actual one, that's
why resulting token ID may have different length during testinvoke and
real invoke. As far as we use token ID as a key to store contract
values, the storage price may also differ. The result is failing
TestNEP11_OwnerOf_BalanceOf_Transfer test due to `gas limit exceeded`
error:
```
logger.go:130: 2021-06-10T21:09:08.984+0300 WARN contract invocation failed {"tx": "45a0220b19725eaa0a4d01fa7a6cdaac8498592e8f3b43bdde27aae7d9ecf635", "block": 5, "error": "error encountered at instruction 36 (SYSCALL): error during call from native: error encountered at instruction 22 (SYSCALL): failed to invoke syscall 1736177434: gas limit exceeded"}
executor_test.go:219:
Error Trace: executor_test.go:219
nep11_test.go:132
nep11_test.go:235
Error: Not equal:
expected: 0x2
actual : 0x4
Test: TestNEP11_OwnerOf_BalanceOf_Transfer
```
Fixed by using base64 instead of base58 (base64 preserves the resulting
encoded string length for the same input length).
VM types are used in debugger, while smartcontract ones are used in
manifest. We can't save only one of them, because conversion in either
side is lossy:
1. VM has `Array` and `Struct` but smartcontract only has `Array`.
2. Smartcontract has `Hash160` etc, which are all `ByteString` or
`Buffer` in VM.
And to spice things a bit more, return type in debugger can be `Void`,
which corresponds to no real stackitem type (as it must exist).
Closes#1379
We should check owner witness before adding more tokens to circulation.
Also we shouldn't allow to add to circulation more than TokenSupply
tokens.
CanTransfer function checks if "to" and "from" values are
correct script hashes. If one of these values is correct and one
incorrect, then function returns false positive result. It uses "and"
operator which requires both "to" and "from" script hashes to be
incorrect to fail transaction.
Instead transaction must fail if at least one argument is incorrect,
so it should be "or" operator.
