And determine the need for Null dynamically. For some reason the only dynamic
context is Contract.Call. CALLT is not dynamic and neither is a call from
native contract, go figure...
We use it a lot in (*Blockchain).IsTxStillRelevant().
name old time/op new time/op delta
IsSignatureContract-8 19.1ns ± 5% 1.2ns ± 4% -93.81% (p=0.000 n=10+10)
name old alloc/op new alloc/op delta
IsSignatureContract-8 0.00B 0.00B ~ (all equal)
name old allocs/op new allocs/op delta
IsSignatureContract-8 0.00 0.00 ~ (all equal)
Perform add/set/remove operations with VM type firstly, and with
refcounter after that. It is needed to be able to extend add/set/remove
operations with extra checks.
We can omit DAO wrapping for safe methods and for those methods that are not
wrapped into try-catch block. However, we still need to persist
notificationsCount changes for these methods to the parent context.
Reference implementation:
e167f03e25/src/neo-vm/ExecutionContext.cs (L77).
Turns out that exception-related code (try\finally handling) is the only
place where next instruction pointer bounds are not pre-checked before
assignment. This statement is true for both go and C# implementations.
However, C# code has duplicate check located inside the
InstructionPointer setter for all instructions except the
exception-related ones. Neo-go code doesn't perform this duplicate check.
Thus, C# VM FAULTs execution in case of invalid TRY/FINALLY offsets, and
neo-go VM does not.
This commit reverts a part of
https://github.com/nspcc-dev/neo-go/pull/2396. This bug is discovered
thanks to test added in https://github.com/neo-project/neo-vm/pull/453.
Which allows to create verification scripts without keys.PublicKey which is
convenient in some cases where we already have serialized key and don't want
to waste time decompressing it.
Currently the only known reason this can happen is processing
ENDFINALLY opcode before the corresponding ENDTRY.
Signed-off-by: Evgeniy Stratonikov <evgeniy@nspcc.ru>
As can be seen in https://dotnetfiddle.net/s7eg21 (int) conversions
result in an exception in C# code.
Signed-off-by: Evgeniy Stratonikov <evgeniy@nspcc.ru>
Also do not limit depth. It was introduced in e34fa2e915 as a simple
solution to OOM problem. In this commit we do exactly the refactoring
described there. Maximum size is the same as stack item size and
can be changed if needed withouth significat refactoring.
`1 MiB` seems sufficient, though.
Signed-off-by: Evgeniy Stratonikov <evgeniy@nspcc.ru>
