Add new RPC method to retrieve block notifications organized by trigger type.
Signed-off-by: Ricardo Prado <ricardo.prado@simpli.com.br>
Signed-off-by: Roman Khimov <roman@nspcc.ru>
We're trying to delete less than 1% of data in the default configuration for
mainnet, so it looks like this:
2025-01-14T15:51:39.449+0300 INFO finished MPT garbage collection {"removed": 221115, "kept": 71236766, "time": "5m40.323822085s"}
Spending this much time for this low gain every 10K blocks is far from being
optimal.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
Solves two problems:
* inability to estimate GAS needed for registerCandidate in a regular way
because of its very high fee (more than what normal RPC servers allow)
* inability to have MaxBlockSystemFee lower than the registration price
which is very high on its own (more than practically possible to execute)
See https://github.com/neo-project/neo/issues/3552.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
It's impossible to maintain a 4K line. I'm not even sure new table works good
enough, but at least it's per-hardfork.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
Differentiate released and stable ones from test-only not-yet-ready and such.
Enabled only stable ones by default to avoid surprises in private networks
when some beta hardfork is made available with some node release.
Fixes#3719.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
Previously, the `blockQueuer` routine, which enqueues blocks into
`bQueue`, could be blocked on enqueing newer blocks if older blocks
downloading is delayed by NeoFS.
The `blocksCh` channel, acting as a queue ordered by download speed,
conflicted with the BQueue requirement for strict sequential enqueuing
(expecting an exact range of blocks), resulting in a deadlock that
stalled the process.
Before with default config settings:
```
2024-11-27T17:12:19.348+0300 INFO persisted to disk {"blocks":
0, "keys": 116, "headerHeight": 0, "blockHeight": 0, "took": "15
.509083ms"}
2024-11-27T17:19:39.574+0300 INFO persisted to disk {"blocks":
16, "keys": 11107, "headerHeight": 216768, "blockHeight": 216768,
"took": "62.762041ms"}
```
Average block persistence speed: 492.40 block/s
Average blocks number for each persist log: 584.28
After:
```
2024-11-27T17:29:03.362+0300 INFO persisted to disk {"blocks":
0, "keys": 116, "headerHeight": 0, "blockHeight": 0, "took": "19
.485084ms"}
2024-11-27T17:34:58.527+0300 INFO persisted to disk {"blocks":
16, "keys": 11109, "headerHeight": 216770, "blockHeight": 216769,
"took": "52.43925ms"}
```
Average block persistence speed: 610.33 block/s
Average blocks number for each persist log: 752.61
Close#3699
Signed-off-by: Ekaterina Pavlova <ekt@morphbits.io>
`Any` type with nil/null value is treated as a parameter filter that allows
any notification value. Not more than 16 filter parameters are allowed.
Closes#3624.
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
It's dangerous to change `Max*` ProtocolConfiguration settings:
* Changes in MaxBlockSize, MaxBlockSystemFee and MaxTransactionsPerBlock
may lead to the fact that accepted block or transaction becomes invalid.
I agree that these settings are not written in the DB, but at the same
time it's not correct to compare databases that have these settings
mismatched.
* Changes in MaxTraceableBlocks may lead to the fact that some
transaction will be processed differently, it's a possible contract
state mismatch.
* Changes in MaxValidUntilBlockIncrement may lead to the fact that
`setMaxNotValidBeforeDelta` method of native Notary contract may be
processed in a different way which is also a possible contract state
mismatch.
Ref. 5d29a3fdab.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
