Skip to content
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.

Add Musicoin and MCIP-3 UBI hardfork. #6621

Merged
merged 41 commits into from
Oct 8, 2017
Merged

Add Musicoin and MCIP-3 UBI hardfork. #6621

merged 41 commits into from
Oct 8, 2017

Conversation

5chdn
Copy link
Contributor

@5chdn 5chdn commented Oct 2, 2017

What:

  • --chain musicoin logic for core and wallet
  • ethash logic for MCIP-3 transition scheduled for block 1_200_001

Rationale:

  • eliminates the need for musicoin to distribute their own fork of parity

@5chdn 5chdn added A0-pleasereview 🤓 Pull request needs code review. M4-core ⛓ Core client code / Rust. M7-ui labels Oct 2, 2017
@5chdn
Copy link
Contributor Author

5chdn commented Oct 2, 2017

Tested MCIP-3 transition against GMC 2.0.0

let result_block_reward = reward + reward.shr(5) * U256::from(n_uncles);
let mut uncle_rewards = Vec::with_capacity(n_uncles);

self.machine.add_balance(block, &author, &result_block_reward)?;
if number >= self.ethash_params.mcip3_transition {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to write tests for that?

Copy link
Contributor Author

@5chdn 5chdn Oct 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, would be lucky to do that. Do I just add tests at the bottom of ethash.rs? Can I reuse the test_spec() or should I create a new test chain that includes the transition? Edit: Created tests for the block rewards.

let ubi_contract = self.ethash_params.mcip3_ubi_contract;
let ubi_reward = self.ethash_params.mcip3_ubi_reward.unwrap();
let dev_contract = self.ethash_params.mcip3_dev_contract;
let dev_reward = self.ethash_params.mcip3_dev_reward.unwrap();
Copy link
Contributor

@rphmeier rphmeier Oct 2, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we don't use unwrap(). favor expect() with a proof that it will never panic. That these fields are either all set or all not should be checked at spec parsing time. Grouping them into a struct mcip3 parsed optionally would make that logic a lot easier.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes sense. I have rewritten the logic, now a malformed mcip3 spec will just behave like a default block reward scheme.

@5chdn 5chdn added the A3-inprogress ⏳ Pull request is in progress. No review needed at this stage. label Oct 2, 2017
@5chdn 5chdn added A0-pleasereview 🤓 Pull request needs code review. and removed A3-inprogress ⏳ Pull request is in progress. No review needed at this stage. labels Oct 4, 2017
@5chdn 5chdn added this to the 1.8 milestone Oct 5, 2017
@arkpar arkpar added A8-looksgood 🦄 Pull request is reviewed well. and removed A0-pleasereview 🤓 Pull request needs code review. labels Oct 5, 2017
@@ -219,7 +252,7 @@ impl Engine<EthereumMachine> for Arc<Ethash> {
self.machine.add_balance(block, a, reward)?;
}

// note and trace.
// Note and trace.
self.machine.note_rewards(block, &[(author, result_block_reward)], &uncle_rewards)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

without altering this line, block rewards from this change won't be traced. I would recommend using a
Cow<&'a [(Address, U256)]> to store the main block reward initially to avoid an allocation on every block unless it's a musicoin chain.

Copy link
Contributor

@rphmeier rphmeier Oct 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or a separate call to machine.note_rewards within the musicoin conditional would serve the same purpose.

Copy link
Contributor Author

@5chdn 5chdn Oct 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I call machine.note_rewards for each block reward or only for the miner reward? Also, is the order of machine.add_balance important?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note_rewards takes two slices of &[(Address, U256)]. The first one is for block rewards and the second for uncle rewards. I don't think it matters if you make multiple calls to the function.

@grbIzl tracing does handle multiple block rewards correctly, right?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rphmeier it should. It's pretty straightforward.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good. @5chdn then you would say the correct implementation traces only the miner reward and not any of the others? LGTM if so.

@rphmeier rphmeier added A6-mustntgrumble 💦 Pull request has areas for improvement. The author need not address them before merging. and removed A8-looksgood 🦄 Pull request is reviewed well. labels Oct 5, 2017
@rphmeier
Copy link
Contributor

rphmeier commented Oct 5, 2017

LGTM except for tracing nit

@5chdn
Copy link
Contributor Author

5chdn commented Oct 6, 2017

Reused result_block_reward variable to make sure the correct reward is traced. Should be all now.

@rphmeier rphmeier added A8-looksgood 🦄 Pull request is reviewed well. and removed A6-mustntgrumble 💦 Pull request has areas for improvement. The author need not address them before merging. labels Oct 6, 2017
@gavofyork gavofyork merged commit 360ecd3 into master Oct 8, 2017
@gavofyork gavofyork deleted the a5-chains-musicoin branch October 8, 2017 16:18
@5chdn 5chdn added the B7-releasenotes 📜 Changes should be mentioned in the release notes of the next minor version release. label Oct 8, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A8-looksgood 🦄 Pull request is reviewed well. B7-releasenotes 📜 Changes should be mentioned in the release notes of the next minor version release. M4-core ⛓ Core client code / Rust.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants