This repository was archived by the owner on Nov 6, 2020. It is now read-only.
Generalize engine trait#6591
Merged
Merged
Conversation
Including metropolis updates
arkpar
reviewed
Sep 25, 2017
| "authorityRound": { | ||
| "params": { | ||
| "stepDuration": "4", | ||
| "blockReward": "0x4563918244F40000", |
arkpar
reviewed
Sep 25, 2017
| fn hash(&self) -> H256; | ||
|
|
||
| /// Get a reference to the seal fields. | ||
| fn seal(&self) -> &[Vec<u8>]; |
Collaborator
There was a problem hiding this comment.
Spaces are used instead of tabs on a few lines in this file
arkpar
reviewed
Sep 26, 2017
| fn builtins(&self) -> &BTreeMap<Address, Builtin> { | ||
| &self.builtins | ||
| } | ||
| fn on_close_block(&self, block: &mut M::LiveBlock) -> Result<(), M::Error> { |
Collaborator
There was a problem hiding this comment.
why not use ::engines::common::bestow_block_reward here?
Contributor
Author
There was a problem hiding this comment.
since it handles uncle reward as well and there is a test that depends on that behavior
Collaborator
|
Looks good in general, mostly just code moved around. |
Collaborator
|
Could use a doc describing migration of existing spec files though. From 1.6 and 1.7 |
Contributor
|
@rphmeier ^^^ |
Contributor
Collaborator
|
Are there any docs yet? |
Contributor
|
No but I can help drafting something if anyone asks. |
Contributor
Author
|
Move |
This was referenced Oct 29, 2017
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This introduces the parity-machine crate, which defines traits for blockchain headers and live blocks.
Consensus engines are intended to be generic over different kinds of state machines which fit the requirements they need. For example, ethash could potentially be run over any block chain type with a difficulty and balances (for block and uncle reward).
Verification and block population logic which was fragmented among engines has now been unified in two places:
ethcore/machine.rsandethcore/verification/verification.rs. This eliminates a common source of bugs stemming from protocol upgrades being implemented for some engines but not others.state,executive, andexternalitiesare now fully decoupled from consensus logic.ValidatorSetbased engines haven't been generalized yet, and currently are implemented only for theEthereumMachine. In a future PR, theValidatorSetframework will be generalized to anything which supports a generalized notion of smart contracts and "signals" (implemented via ethabi and log events in Ethereum).The snapshot module can is also a prime candidate for refactor. Currently there are two kinds of chunks: "block chunks" and "corroboration chunks". Corroboration chunks vary from engine to engine, and now we can make "block chunks" vary from machine to machine. This will give us secure warp sync with minimal effort for any new blockchains we create.