While our server no longer uses these codes (-100, -400) they still can come
from C# servers and while we consider them deprecated we better at least have
some definition of them until C# implements our proposal:
https://github.com/neo-project/proposals/pull/156
Also adding description of deprecated RPC error codes in ROADMAP.md.
Signed-off-by: Tatiana Nesterenko <tatiana@nspcc.io>
RPC binding config may be malformed or the source .go contract may contain
structures like this:
```
type Str struct {
Field int
field int
}
```
We need to recognise these cases and return error. otherwise the resulting
binding can't be compiled.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
It helps us to keep the index clean and ordered. When some new RPC binding
test should be added, we don't need to search for a suitable place for it.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Perform private -> public transformation at the last step of RPC binding
generation so that it works not only with NeoGo contracts, but with any
other contracts.
Close#3083.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
And simplify atomic service value stored by RPC server. Oracle service can
either be an untyped nil or be the proper non-nil *oracle.Oracle.
Otherwise `submitoracleresponse` RPC handler doesn't work properly.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
52-bit precision is not enough for our 256-bit VM, but this value
matches the reference implementation, see the
https://github.com/neo-project/neo/issues/2879.
MaxIntegerPrec will be increased (or even removed) as soon as the
ref. issue is resolved.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Ensure that Scopes can be properly parsed not only from the string
representation, but also from a single byte. transaction.Signer
is not affected (checked against the C# implementation), only
RPC-related signer scopes are allowed to be unmarshalled from byte.
Close#3059.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
This prevents the possible attack on notary request sender when
malicious partie is allowed to send notary request with main transaction
being someone else's fallback.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
If the contract was deployed then cache must be initialized after
in-memory data reset. If the contract isn't active yet, then no
cache will be initialized on deploy (i.e. on call to Initialize()
method by native Management).
Close#2984.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Make the contracts cache initialization unified. The order of cache
iniitialization is not important and Nottary contract is added to the
bc.contracts.Contracts wrt P2PSigExtensions setting, thus no functional
changes, just refactoring for future applications.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
