-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Add Musicoin and MCIP-3 UBI hardfork. #6621
Conversation
Tested MCIP-3 transition against GMC 2.0.0 |
ethcore/src/ethereum/ethash.rs
Outdated
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 { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
ethcore/src/ethereum/ethash.rs
Outdated
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(); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
@@ -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) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
LGTM except for tracing nit |
Reused |
What:
--chain musicoin
logic for core and walletRationale: