Handle nomination expiration properly by sgkim126 · Pull Request #1598 · CodeChain-io/codechain

sgkim126 · 2019-06-03T10:44:34Z

Please see the last commit only.
It depends on #1597, #1594 and #1595

foriequal0 · 2019-06-03T11:49:12Z

core/src/consensus/solo/mod.rs

        self.machine.increase_term_id(block, last_term_finished_block_num)?;
+
+        let current_term = block.state().metadata()?.unwrap().current_term_id();
+        stake::on_term_close(block.state_mut(), current_term)?;


I assumed that on_term_close should be called after transactions being applied with the same current_term number. I think you can find its evidences in the tests pointing the off-by-one error. But I'm not sure this would be okay too.

The last block changes the term. It means that the term has been changed after executing the last block of the term, not before the first block of the next term. So you should call on_term_close with the changed term id.
Please fix the test cases.

What about

let current_term = block.state().metadata()?.unwrap().current_term_id(); self.machine.increase_term_id(block, last_term_finished_block_num)?; stake::on_term_close(block.state_mut(), current_term)?;

?
I think this wouldn't have an issue if it doesn't introduce problems

let current_term = block.state().metadata()?.unwrap().current_term_id(); stake::on_term_close(block.state_mut(), current_term)?; self.machine.increase_term_id(block, last_term_finished_block_num)?;

because it looks like

let mut current_term = 0; while(true) { for tx in transactions { tx.apply(); } stake::on_term_close(current_term); current_term += 1; }

which is a effectively for current_term in 0.. { ... }

Looks good, but it seems that on_term_close doesn't use the last_term_finished_block_num, so the order is not important.
I made it increase the term id after on_term_close and there is no need to pass the term id because on_term_close takes the state.

foriequal0 · 2019-06-03T11:49:22Z

core/src/consensus/tendermint/engine.rs

        stake::move_current_to_previous_intermediate_rewards(&mut block.state_mut())?;
+
+        let current_term = block.state().metadata()?.unwrap().current_term_id();
+        stake::on_term_close(block.state_mut(), current_term)?;


sgkim126 · 2019-06-04T03:13:12Z

I stopped Travis. I'll run it after merging #1594 and #1595

foriequal0 · 2019-06-05T08:50:43Z

core/src/consensus/solo/mod.rs

        self.machine.increase_term_id(block, last_term_finished_block_num)?;
+
+        let current_term = block.state().metadata()?.unwrap().current_term_id();
+        stake::on_term_close(block.state_mut(), current_term)?;


What about

let current_term = block.state().metadata()?.unwrap().current_term_id(); self.machine.increase_term_id(block, last_term_finished_block_num)?; stake::on_term_close(block.state_mut(), current_term)?;

?
I think this wouldn't have an issue if it doesn't introduce problems

let current_term = block.state().metadata()?.unwrap().current_term_id(); stake::on_term_close(block.state_mut(), current_term)?; self.machine.increase_term_id(block, last_term_finished_block_num)?;

because it looks like

let mut current_term = 0; while(true) { for tx in transactions { tx.apply(); } stake::on_term_close(current_term); current_term += 1; }

which is a effectively for current_term in 0.. { ... }

sgkim126 · 2019-06-07T01:33:21Z

I resolved the conflicts.

foriequal0 · 2019-06-10T09:31:28Z

core/src/consensus/stake/mod.rs

        let delegator = public_to_address(&address_pubkey);

        let mut state = helpers::get_temp_state();
+        assert_eq!(Ok(()), state.update_params(0, CommonParams::default_for_test()));


Why don't we add this state.update_params(0, CommonParams::default_for_test()); to helpers::get_temp_state();? or let calling update_params() create metadata automatically?
And state.update_params() is not a subject for this tests. I think it can just .unwrap() rather than assert_eq!()

There is a test whether the initial state is a root of the empty trie.

How about making a local test helper?

I think it doesn't have worth to make a helper function.
And please prefer to use assert_eq if the argument derives Debug and PartialEq.
You should read the backtrace if you use unwrap, because the test fails in Option.

Okay then. I'll comment like // Arrange, // Action, // Assert to separate sections to convey the intention of a test in that situation.

core/src/consensus/solo/mod.rs

core/src/consensus/stake/mod.rs


-        let result = on_term_close(&mut state, 29);
+        let result = on_term_close(&mut state);
+        increase_term_id_until(&mut state, 30);


foriequal0 · 2019-06-10T09:40:23Z

core/src/consensus/stake/mod.rs

        assert!(result.is_err(), "Cannot self-nominate without a sufficient balance");
    }

+    fn increase_term_id_until(state: &mut TopLevelState, term_id: u64) {


If on_term_close handles increasing term id, this will be term_close_until(...)

No. It doesn't close terms. It just increases term id on the metadata

Is there a meaning to differentiate closing the term from increasing the term id?

Yes. It is hard to create test cases if we close terms to set the states.

core/src/consensus/stake/mod.rs


        for current_term in 0..=released_at {
-            on_term_close(&mut state, current_term).unwrap();
+            on_term_close(&mut state).unwrap();


foriequal0 · 2019-06-11T00:46:22Z

core/src/consensus/stake/mod.rs

        self_nominate(&mut state, &address, &address_pubkey, 200, 0, 30, b"".to_vec()).unwrap();

-        let result = on_term_close(&mut state, 29);
+        let result = on_term_close(&mut state, pseudo_term_to_block_num_calculator(29));


pseudo_term_to_block_num_calculator is somewhat misleading. Actual bulk term increasing thing is done with increase_term_id_until, on_term_close is increasing it just one step. I think turn increase_term_id_until into term_close_until or something

It doesn't increase the term bulky.
The second parameter of on_term_close is the block number of closing block.
And you cannot rename increase_term_id_until to term_close_until, because it doesn't close term, it merely increases term id.

I understand it now that pseudo_term_to_block_num_calculator is not actually related term id. It was confusing for a while.
I think increasing term id by closing the term is more realistic than calling increase_term_id directly.

It is the purpose of this function to set the states for testing not calling on_term_close.

foriequal0 · 2019-06-11T00:47:17Z

core/src/consensus/stake/mod.rs

        let delegator = public_to_address(&address_pubkey);

        let mut state = helpers::get_temp_state();
+        assert_eq!(Ok(()), state.update_params(0, CommonParams::default_for_test()));


How about making a local test helper?

sgkim126 added the consensus label Jun 3, 2019

sgkim126 requested a review from foriequal0 June 3, 2019 10:44

foriequal0 requested changes Jun 3, 2019

View reviewed changes

sgkim126 added the do-not-merge Do not merge (for mergify.io) label Jun 4, 2019

sgkim126 removed the do-not-merge Do not merge (for mergify.io) label Jun 4, 2019

foriequal0 requested changes Jun 5, 2019

View reviewed changes

sgkim126 mentioned this pull request Jun 7, 2019

Implement dynamic validator set #1574

Merged

foriequal0 requested changes Jun 10, 2019

View reviewed changes

Handle nomination expiration properly

0ef4700

sgkim126 requested a review from foriequal0 June 10, 2019 10:43

foriequal0 requested changes Jun 11, 2019

View reviewed changes

foriequal0 approved these changes Jun 11, 2019

View reviewed changes

mergify bot merged commit dc9a0cf into CodeChain-io:master Jun 11, 2019

sgkim126 deleted the nominate branch June 12, 2019 02:27

Conversation

sgkim126 commented Jun 3, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sgkim126 Jun 4, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

foriequal0 Jun 5, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sgkim126 commented Jun 4, 2019

Uh oh!

foriequal0 Jun 5, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sgkim126 commented Jun 7, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

This comment was marked as outdated.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment was marked as outdated.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

sgkim126 Jun 4, 2019 •

edited

Loading

foriequal0 Jun 5, 2019 •

edited

Loading

foriequal0 Jun 5, 2019 •

edited

Loading