We don't use all of the Stack functionality for it, so drop useless methods
and avoid some interface conversions. It increases single-node TPS by about
0.9%, so nothing really important there, but not a bad change either. Maybe it
can be reworked again with generics though.
Do not block subscribers until the unsubscription request to RPC server
is completed. Otherwise, another notification may be received from the
RPC server which will block the unsubscription process.
At the same time, fix event-based waiter. We must not block the receiver
channel during unsubscription because there's a chance that subsequent
event will be sent by the server. We need to read this event in order not
to block the WSClient's readloop.
Bad contract -> no contract. Unfortunately we've got a broken
6f1837723768f27a6f6a14452977e3e0e264f2cc contract on the mainnet which can't
be decoded (even though it had been saved successfully), so this is a
temporary fix for #2801 to be able to start mainnet node after shutdown.
There is a security issue found in github.com/btcsuite/btcd that we don't care
about (we're only using 256k1 implementation), but GitHub complains about
it. We could update to github.com/btcsuite/btcd/btcec/v2, but it's now just a
thin wrapper over github.com/decred/dcrd/dcrec/secp256k1/v4, so we better use
it directly.
When block is being spread through the network we can get a lot of invs with
the same hash. Some more stale nodes may also announce previous or some
earlier block. We can avoid full DB lookup for them and minimize inv handling
time (timeouts in inv handler had happened in #2744).
It doesn't affect tests, just makes node a little less likely to spend some
considerable amount of time in the inv handler.
Blockchain's notificationDispatcher sends events to channels and these
channels must be read from. Unfortunately, regular service shutdown procedure
does unsubscription first (outside of the read loop) and only then drains the
channel. While it waits for unsubscription request to be accepted
notificationDispatcher can try pushing more data into the same channel which
will lead to a deadlock. Reading in the same method solves this, any number of
events can be pushed until unsub channel accepts the data.
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...
Which allows to enable/disable the service, change nodes, keys and other
settings. Unfortunately, atomic.Value doesn't allow Store(nil), so we have to
store a pointer there that can point to nil interface.
It can change the committee even if noone voted. Fixes state diff at block
390726 of T5 testnet where there are no transactions, but committee changes
because there were some registrations in previous 21 blocks.
It's not an ideal solution, but at least it solves the problem for
now. Caveats:
* consensus only needs one method, so it's mirrored to Blockchain
* rpcsrv uses core.* definition of the StateRoot (so technically it might as
well not have an internal Ledger), but it uses core already unfortunately
1. It's not good for pkg/core to import anything from pkg/neorpc.
2. The type is closely tied to the state package, even though it's not stored
in the DB
It makes a copy of the resulting set, so the lock can be released
earlier. This helps a lot with iterators that keep Seek() unfinished for a
long time,
Specifying a certain stateroot R as `invoke*historic` RPC-call
parameter, we're willing to perform historic call based on the storage
state of root R. Thus, next block should be of the height h(R)+1. This
allows to use historic functionality for the current blockchain height.
They test both module and service which is a bit wrong, but separating these
tests will lead to some duplication, so it's OK for now to have them in the
higher-order package (service imports module).
It also brings ToStackItem to Block and Transaction, previously this was
avoided to separate block and transaction packages from VM. But turns out
`transaction` depends on `stackitem` already, so this makes little sense (but
can be shuffled in another way if needed).
Context.Container is still a hash.Hashable because we have a number of
occasions (header or MPT root verification) where there is no ToStackItem
implementation possible. Maybe they can go with `nil` Container, but I don't
want to have this risk for now.
This allows to reuse it across different packages.
testchain can't be used because of circular dependencies.
Init() is not changed except for filepath.Join() use instead of direct string
appends which is a better approach anyway. rootpath is required because
current directory will change from package to package.