* Refactor updater to use ethabi-derive
* Grumble: do_call type alias
* Empty commit to trigger test re-run
* migration to ethabi-5.0
* migration to ethabi-5.0 in progress
* use ethabi_deriven to generate TransactAcl contract
* use ethabi_deriven to generate Registry contract
* hash-fetch uses ethabi_derive, removed retain cycle from updater, fixed#7720
* node-filter crate uses ethabi_derive to generate peer_set contract interface
* use LruCache in node-filter instead of HashMap
* validator_set engine uses ethabi_derive
* ethcore does not depend on native_contracts
* miner does no depend on native_contracts
* secret_store does not use native_contracts (in progress)
* removed native-contracts
* ethcore and updater does not depend on futures
* updated ethereum-types
* fixed all warnings caused by using new version of ethereum-types
* updated ethabi_derive && ethabi_contract to get rid of warnings
* removed another retain cycle in updater, fixed following minor version on update
* moved contracts out of native_contracts res
* updated ethabi_contract
* fixed failing test
* fixed failing test
* there is no need to create two contracts of the same kind any more
* simplify updater::ReleaseTrack conversion into u8 and add several tests for it
* applied review suggestions
* applied review suggestions
* updated ethereum-types and tiny-keccak
* Updated several deps
* Updated several more dependencies
* Modify dummy file to trigger ci
* fixed update of memmap to 0.6 in ethash crate
* Fixed fetch after update to latest reqwest
* Updated jsonrpc-core with fixes for serde
* add expects in util/version/build.rs
* Move miner away from ethcore.
* Fix ethcore to use miner/transaction.
* Fix tests and warnings.
* fixed incorrect merge of the test in the documentation
* 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).
