Not from DAO's items with storage.STNEP17Balances prefix, because
changes are reflected there only after notifications processing. And
this happens only after the transaction script is executed, but there
might be cases when we need to get the balance that was updated
earlier during the same transaction processing.
Affects storage dumps.
The result is the same HALT state, but the exception message is the real
one got from user. Changes ported from C#:
1. Throw exception: 59b8ac73d2/src/neo-vm/ExecutionEngine.cs (L1448)
2. Prettify message: https://github.com/neo-project/neo-vm/blob/master/src/neo-vm/VMUnhandledException.cs#L28
The result is that instead of
```
2021-03-31T17:02:54.508+0300 WARN contract invocation failed {"tx": "2aefeb705f3a609df8767d9b45e036b9dd1eb77407e5732375981915668889b8", "block": 30640, "error": "error encountered at instruction 970 (THROW): runtime error: invalid memory address or nil pointer dereference"}
```
we'll get
```
2021-03-31T17:33:56.299+0300 WARN contract invocation failed {"tx": "2aefeb705f3a609df8767d9b45e036b9dd1eb77407e5732375981915668889b8", "block": 30640, "error": "error encountered at instruction 970 (THROW): unhandled exception: No authorization."}
```
in the node logs.
After getting account from the storage there are a lot of checks which
may fail. But C# node uses Snapshot.GetAndChange, so the account state
should be put in the storage even in case of vote failure. Affects
dumps.
C# node returns an error if the candidate is not registered. We have this
check inside the ModifyAccountVotes, but (*NEO).vote doesn't panics and
just return bool on stack, so we should match exactly the C#'s
algorithm.
Prevent
2021-03-27T00:05:23.382+0300 WARN blockQueue: failed adding block into the blockchain {"error": "error while trying to apply MPT changes: key not found", "blockHeight": 12757, "nextIndex": 12758}
after node restart (node reads "local" root hash that it doesn't have).
It was completely ruined by bf20db09e0. MPT was
updating bc.dao directly which shouldn't ever happen, it must write into the
same cache and then Persist these KVs as usual.
It's only used to sign/verify it and is not a part of the structure. It's
still neded in consensus.Payload though because that's the way dbft library
is.
It's not network-tied any more, network is only needed to
sign/verify. Unfortunately we still have to keep network in consensus data
structures because of dbft library interface.
