* Improve handling of RocksDB corruption (#7630)
* kvdb-rocksdb: update rust-rocksdb version
* kvdb-rocksdb: mark corruptions and attempt repair on db open
* kvdb-rocksdb: better corruption detection on open
* kvdb-rocksdb: add corruption_file_name const
* kvdb-rocksdb: rename mark_corruption to check_for_corruption
* Hardening of CSP (#7621)
* Fixed delegatecall's from/to (#7568)
* Fixed delegatecall's from/to, closes#7166
* added tests for delegatecall traces, #7167
* Light client RPCs (#7603)
* Implement registrar.
* Implement eth_getCode
* Don't wait for providers.
* Don't wait for providers.
* Fix linting and wasm tests.
* Problem: AttachedProtocols don't get registered (#7610)
I was investigating issues I am having with Whisper support. I've
enabled Whisper on a custom test network and inserted traces into
Whisper handler implementation (Network<T> and NetworkProtocolHandler
for Network<T>) and I noticed that the handler was never invoked.
After further research on this matter, I found out that
AttachedProtocol's register function does nothing:
https://github.com/paritytech/parity/blob/master/sync/src/api.rs#L172
but there was an implementation originally:
99075ad#diff-5212acb6bcea60e9804ba7b50f6fe6ec and it did the actual
expected logic of registering the protocol in the NetworkService.
However, as of 16d84f8#diff-5212acb6bcea60e9804ba7b50f6fe6ec ("finished
removing ipc") this implementation is gone and only the no-op function
is left.
Which leads me to a conclusion that in fact Whisper's handler never gets
registered in the service and therefore two nodes won't communicate
using it.
Solution: Resurrect original non-empty `AttachedProtocols.register`
implementation
Resolves#7566
* Fix Temporarily Invalid blocks handling (#7613)
* Handle temporarily invalid blocks in sync.
* Fix tests.
* kvdb-rocksdb: update to RocksDB 5.8.8
* kvdb-rocksdb: tune RocksDB options
* Switch to level-style compaction
* Increase default block size (16K), and use bigger blocks for HDDs (64K)
* Increase default file size base (64MB SSDs, 256MB HDDs)
* Create a single block cache shared across all column families
* Tune compaction settings using RocksDB helper functions, taking into account
memory budget spread across all columns
* Configure backgrounds jobs based on the number of CPUs
* Set some default recommended settings
* ethcore: remove unused config blockchain.db_cache_size
* parity: increase default value for db_cache_size
* kvdb-rocksdb: enable compression on all levels
* kvdb-rocksdb: set global db_write_bufer_size
* kvdb-rocksdb: reduce db_write_bufer_size to force earlier flushing
* kvdb-rocksdb: use master branch for rust-rocksdb dependency
* created the dir crate in util
* moved code from ethstore/src/dir/paths.rs to dir crate
* rename dir module in ethstore to accounts_dir to distinguish it
from the dir crate
* changes after @tomusdrw on #6952
* parity-version module split from util
removed unused util deps and features
trigger buildbot again
only kvdb links rocksdb
snappy linker issues
* rm snappy
* fixed old version imports
Firstly, `Step.duration_remaining` casts it to u32, unnecesarily
limiting it to 2^32. While theoretically this is "good enough" (at 3
seconds steps it provides room for a little over 400 years), it is
still a lossy way to calculate the remaining time until the next step.
Secondly, step duration might be zero, triggering division by zero
in `Step.calibrate`
Solution: rework the code around the fact that duration is
typically in single digits and never grows, hence, it can be represented
by a much narrower range (u16) and this highlights the fact that
multiplying u64 by u16 will only result in an overflow in even further
future, at which point we should panic informatively (if anybody's
still around)
Similarly, panic when it is detected that incrementing the step
counter wrapped around on the overflow of usize.
As for the division by zero, prevent it by making zero an invalid
value for step duration. This will make AuRa log the constraint
mismatch and panic (after all, what purpose would zero step duration
serve? it makes no sense within the definition of the protocol,
as finality can only be achieved as per the specification
if messages are received within the step duration, which would violate
the speed of light and other physical laws in this case).
