* 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
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).
* move common forks and parameters to common params
* port specs over to new format
* fix RPC tests
* parity-machine skeleton
* remove block type
* extract out ethereum-specific methods into EthereumMachine
* beginning to integrate Machine into engines. dealing with stale transitions in Ethash
* initial porting to machine
* move block reward back into engine
* abstract block reward logic
* move last hash and DAO HF logic into machine
* begin making engine function parameters generic
* abstract epoch verifier and ethash block reward logic
* instantiate special ethereummachine for ethash in spec
* optional full verification in verify_block_family
* re-instate tx_filter in a way that works for all engines
* fix warnings
* fix most tests, further generalize engine trait
* uncomment nullengine, get ethcore tests compiling
* fix warnings
* update a bunch of specs
* re-enable engine signer, validator set, and transition handler
* migrate basic_authority engine
* move last hashes into executedblock
* port tendermint
* make all ethcore tests pass
* json-tests compilation
* fix RPC tests: change in gas limit for new block changed PoW hash
* fix minor grumbles
* validate chainspecs
* fix broken import
* fix transaction verification for pre-homestead
* final engine changes
* migration to v13
* adding and removing pending transitions
* epoch_transition_for
* port snapshot to new engine methods
* final validator set interface
* fix compiler errors
* revert v13/epoch_depth transition
* make call on new epoch
* rolling finality checker
* tests for finality checker
* constructing finality proof upon pending transition
* fix warnings and finality proof checking
* fix compiler warnings in tests
* test fixes
* don't include genesis in finality checking
* change snapshot test chain building logic
* minor refactorings
* fetch epoch transition based on parent, fix divide-by-zero in SimpleList
* fix formatting
* fix ABIs and finality checking in snapshot restoration
* encode signal number in proof
* create more blocks at the end of tests
* update gist to accurate contract code
* test for epoch_transition_for
* fix tests with immediateTransitions parameter
* disable force flag after forcing
* rename ValidatorsChanged to InitiateChange and finalizeSignal to finalizeChange
* a few more validator set tests
* Ethereum Classic Monetary Policy
Create a new parameter `ecip1017EraRounds`. When the block number
passes one era rounds, the reward is reduced by 20%.
See https://github.com/ethereumproject/ECIPs/blob/master/ECIPs/ECIP-1017.md
* Update rewards for uncle miners for ECIP1017
In the monetary policy, the rewards are changed from "up to 7/8 of the
reward" to "1/32 of the reward".
* Fix an off-by-one error in ECIP1017 era calculation
According to
https://github.com/ethereumproject/ECIPs/blob/master/ECIPs/ECIP-1017.md,
when in block number 5,000,000, it should still be in Era 1 (which in
our code `era == 0`). So we need to check whether the `rem` equals to
zero and act accordingly when calculating the era.
* `ecip1017_era_rounds` missing from EthashParams when run in build bot
* strip out ecip1017_eras_block_reward function and add unit test
