Standard binary serialization/deserialization is mostly used in VM to put/get
elements into/from storage, so they never should exceed MaxSize (otherwise one
won't be able to deserialize these items).
This patch leaves EncodeBinaryStackItem unprotected, but that's a streaming
interface, so it's up to the user of it to ensure its appropriate use (and our
uses are mostly for native contract's data, so they're fine).
We can have very deep reference types and attempt to JSONize them can easily
lead to OOM (even though there are no recursive references inside). Therefore
we have to limit them. While regular ToJSON() is buffer size limited to
MaxSize, ToJSONWithTypes is not and limiting it to MaxSize output will require
substantial rewriting effort while not really providing fair result, MaxSize
is more about stack item size while its JSON representation can be much bigger
because of various overheads.
Initial thought was to limit it by element count based on
MaxIteratorResultItems, but the problem here is that we don't always have this
limit in contexts using ToJSONWithTypes (like notification event
marshaling). Thus we need some generic limit which would be fine for all
users.
We at the same time have maxJSONDepth used when deserializing from JSON, so
it can be used for marshaling as well, it's not often that we have deeper
structures in real results.
Inspired by neo-project/neo#2521.
If we're done with element it no longer can lead to recursion error, so fix
cases like `[arr, arr]` where we have two copies of `arr` trigger this error
for no good reason (there is no recursion there).
Sometimes on-chain invocations need a bit more GAS than expected after test
invocations, so let the user compensate for that. 2.x has similar option since
483fefbb62.
`storage.Seek()` is rather expensive and we need only last updated value
of gas per block in `PostPersist()`.
Signed-off-by: Evgeniy Stratonikov <evgeniy@nspcc.ru>
Problem: with StateRootInHeader setting on only one header of height N+1
can be added to the chain of height N, because we need local stateroot
to verify headers (which is calculated for the last stored block N).
Thus, adding chunk of headers starting from the current chain's heigh
is impossible and (*Blockchain).AddHeaders doesn't have much sense.
Solution: verify header.PrevStateRoot only for header N+1. Rest of the
headers should be added without PrevStateRoot verification.
For `nft-nd-nns` example only `namestate.go` file was compiled which is
certainly not what we want.
Signed-off-by: Evgeniy Stratonikov <evgeniy@nspcc.ru>
If a method is known at compile time we can still check
if it is present in the list of methods of at least one contract.
Signed-off-by: Evgeniy Stratonikov <evgeniy@nspcc.ru>
On many occassions we can determine at compile-time if contract config lacks
some properties it needs. This includes all native contract invocations
through stdlib, as both hashes and methods are known at compile-time
there.
Signed-off-by: Evgeniy Stratonikov <evgeniy@nspcc.ru>
(*NEO).GetCandidates along with getCandidatesCall use candidates sorted
by serialized ECPoint bytes.
(*NEO).computeCommitteeMembers use candidates sorted by votes, and then
by deserialized ECPoint, i.e. using default ECPoint comparator.
Problem:
```
executor_test.go:151:
Error Trace: executor_test.go:151
executor_test.go:147
nep11_test.go:232
Error: Expect "{"name":"HASHY 3HNCEX8D9J0p\u002BLxmr3uPhOhSW90="}" to match "{"name":"HASHY 3HNCEX8D9J0p+Lxmr3uPhOhSW90="}"
Test: TestNEP11_OwnerOf_BalanceOf_Transfer
```
Solution:
Same as preesnted in #2006.
