Parity can accept older work packages #811
Conversation
…lock. Docuemnt SealingWork properly.
Fixes #756.
gavofyork
added
the
A3-inprogress ⏳
gavofyork
added
A0-pleasereview 🤓
| // TODO [todr] Should be moved to miner crate eventually. | ||
| fn prepare_sealing(&self, author: Address, gas_floor_target: U256, extra_data: Bytes, transactions: Vec<SignedTransaction>) | ||
| -> Option<(ClosedBlock, HashSet<H256>)> { | ||
| -> (Option<ClosedBlock>, HashSet<H256>) { |
There was a problem hiding this comment.
In the caller, we always want to know which transactions were invalid, even if there's no new block to mine.
| @@ -339,6 +339,18 @@ impl fmt::Debug for State { | |||
| } | |||
| } | |||
|
|
|||
| impl Clone for State { | |||
There was a problem hiding this comment.
Where is this used? I implemented state snapshot specifically to avoid state cloning, which is quite expensive.
There was a problem hiding this comment.
in block.rs, ClosedBlock and also in miner.rs. it's necessary so that we can reopen a ClosedBlock later, add a new transaction and possibly seal.
cloning should only be used in those two circumstances, both are only when mining. it's certainly necessary for allowing additional transactions in a block since a possibly arbitrary block-finalization state-change must be reverted. it may not strictly be necessary for the usage in miner.rs, but i don't particularly want to rewrite that code for some optimisation of as-yet unknown benefit.
arkpar
added
A5-grumble 🔥
…cannot). `ClosedBlock`s still keep the pre-finalised state (i.e. state after the last transaction). `LockedBlock`s do not. New mining algo needs to reopen these `ClosedBlock`s, however enactment system does not (and `ClosedBlock`s are slower & more hungry), hence the distinction.
gavofyork
added
A0-pleasereview 🤓
arkpar
added
A8-looksgood 🦄
gavofyork
added
the
A5-grumble 🔥
gavofyork
added
A0-pleasereview 🤓
arkpar
added
A8-looksgood 🦄
Utilise
UsingQueuein order to pushClosedBlocks into a queue for (if used) later retrieval from work.