We want to cut the tail more aggressively, what matters is state, but not
old blocks and transactions that contracts don't use in any way. #3493
suggests that it's safe to limit the tail to one day, but let's be a bit
more conservative for now.
As a sidenote, EVM only allows to fetch things from the recent 256 blocks.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
According to https://golangci-lint.run/usage/linters/#govet,
`check-shadowing` no longer exists. Now it should be
```yaml
govet:
disable: [shadow]
```
but `shadow` is disabled by default. Thus, whole `govet` section is not
needed anymore.
```
$ golangci-lint --version
golangci-lint has version 1.59.1 built with go1.22.3 from 1a55854a on 2024-06-09T18:08:33Z
```
Signed-off-by: Leonard Lyubich <leonard@morphbits.io>
This fixes
```
$ golangci-lint --version
golangci-lint has version 1.59.1 built with go1.22.3 from 1a55854a on 2024-06-09T18:08:33Z
$ golangci-lint run ./...
WARN [config_reader] The configuration option `output.format` is deprecated, please use `output.formats`
```
The configuration file is updated according to
https://golangci-lint.run/usage/configuration/.
Signed-off-by: Leonard Lyubich <leonard@morphbits.io>
It's needed to give user a hint about what's wrong with the witness
during `calculatenetworkfee` RPC request processing.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
This code was accidentally removed by
https://github.com/nspcc-dev/neo-go/pull/3477, it's important to have
these fields set by default.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
This commit adds a single test that covers the
previously uncovered branch in the mptdata
decoding algorithm.
Signed-off-by: Furetur <furetur@gmail.com>
It should be sufficient to retrieve next block validators once per
updateExtensibleWhitelist call and then reuse this value. `nextVals`
copy intentionally omitted since the only change that
smartcontract.CreateDefaultMultiSigRedeemScript performs over the
`nextVals` list is sorting.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Refs #3415
This commit introduces a small new change
that implements the Hooks API and more
specifically the OnExecHook. This feature
can be used to implement test coverage
collection, tracing, breakpoints, and etc.
To be more specific, this commit:
1. adds a new `hooks` field to the `VM`
(this field contains the OnExecHook
function)
2. sets the default value of this hook
to be a NOP function
3. adds the `VM.SetOnExecHook` method
Signed-off-by: Furetur <furetur@gmail.com>
If `config-path` is not passed, default configs are used according to
the set network. In VM CLI the default privnet config with InMemory db
is used.
Close#3450Close#3459
Signed-off-by: Ekaterina Pavlova <ekt@morphbits.io>
Signers are very important for notary checks and keeping/passing an additional
copy of them is very inconvenient. Exposing them from invoker makes them
available in actors too.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
Most of the time people are interested in successful executions. Unfortunately,
unwrap package can't help here because of a different result structure (some
interface abstract can help, but it's still mostly stack-oriented and sessions
can be a problem), so this additional interface is needed.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
Add a note about System.Runtime.GetNotifications refcounting to Domovoi
hardfork. Ref. https://github.com/neo-project/neo/pull/3301 and
https://github.com/nspcc-dev/neo-go/pull/3485.
Although NeoGo doesn't have anything to be updated, there's a
behaviour difference between C# and Go nodes before Domovoi hardfork, it
deserves a comment.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
It's not correct to use an updated contract state got from Management to
check for the allowed method call. We need to use manifest from the
currently executing context for that. It may be critical for cases when
executing contract is being updated firstly, and after that calls
another contract. So we need an old (executing) contract manifest for
this check.
This change likely does not affect the mainnet's state since it's hard
to meet the trigger criteria, but I'd put it under the hardfork anyway.
Ref. https://github.com/neo-project/neo/pull/3290.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
This test ensures that NeoGo node doesn't have the DeepCopy problem
described in https://github.com/neo-project/neo/issues/3300 and fixed in
https://github.com/neo-project/neo/pull/3301. This problem leads to the
fact that Notifications items are not being properly refcounted by C#
node which leads to possibility to build an enormously large object on
stack. Go node doesn't have this problem.
The reason (at least, as I understand it) is in the fact that C# node
performs objects refcounting inside the DeepCopy even if the object
itself is not yet on stack. I.e. System.Runtime.Notify handler
immediately adds references to the notification argumetns inside
DeepCopy:
b1d27f0189/src/Neo.VM/Types/Array.cs (L108)b1d27f0189/src/Neo.VM/Types/Array.cs (L75)
Whereas Go node just performs the honest DeepCopy without references counting:
b66cea5ccc/pkg/vm/stackitem/item.go (L1223)
Going further, C# node clears refs for notification arguments (for array
and underlying array items). System.Runtime.GetNotifications pushes the
notificaiton args array back on stack and increments counter only for
the external array, not for its arguments. Which results in negative
refcounter once notificaiton is removed from the stack. The fix itself
(f471c0542d/src/Neo/SmartContract/NotifyEventArgs.cs (L84))
doesn't need to be ported to NeoGo because Go node adds object to the
refcounter only at the moment when it's being pushed to stack by
System.Runtime.GetNotifications handler. This object is treated as new
object since it was deepcopied earlier by System.Runtime.Notify handler:
b66cea5ccc/pkg/vm/stack.go (L178).
Thus, no functoinal changes from the NeoGo side. And we won't
intentionally break our node to follow C# pre-Domovoi invalid behaviour.
Close#3484, close#3482.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
