Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: fork collator-selection and use escrow for bonding #688

Merged
merged 3 commits into from Aug 22, 2022

Conversation

gregdhill
Copy link
Member

@gregdhill gregdhill commented Aug 1, 2022

Signed-off-by: Gregory Hill gregorydhill@outlook.com

Forks pallet-collator-selection and distinguishes StakingCurrency and RewardsCurrency so that we can use the illiquid Escrow balance for candidacy bonds.

The reason for the split is because the ReservableCurrency implementation on the Escrow pallet is incompatible with the calls made in note_author.

@sander2
Copy link
Member

sander2 commented Aug 17, 2022

Any chance you can split up your pr in at least 2 separate commits - one where you just add unchanged forked pallet, and one with the changes you made to it? The current pr with a single commit is quite hard to review

Signed-off-by: Gregory Hill <gregorydhill@outlook.com>
Signed-off-by: Gregory Hill <gregorydhill@outlook.com>
@gregdhill gregdhill force-pushed the feat/collator-escrow branch 2 times, most recently from 0d45135 to 500409b Compare August 18, 2022 10:33
Signed-off-by: Gregory Hill <gregorydhill@outlook.com>
@sander2 sander2 added the needs-democracy Needs a referendum to be enacted label Aug 18, 2022
Copy link
Member

@sander2 sander2 left a comment

Choose a reason for hiding this comment

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

The code LGTM, but I do have a concern regarding migrations. Can you check if we need any? At first I thought we'd be fine as long as you forked the exact version that we are currently using, but then I realized that it may actually be a bit more complicated to switch over. I don't know the details of this pallet to be honest, but as I understand it the existing collators have locked KINT/INTR. Wouldn't switching over without migration lead to their KINT/INTR being locked forever? And wouldn't it lead to problems when existing collators quit, as we would attempt to unlock vKINT but didn't lock?

I'd like the above to be addressed. I also think we should give this a test on testnet. I mean, we should test all changes that we make on testnet before deployment, but we should pay particular attention to this one :)

@@ -427,6 +430,7 @@ pub mod pallet {
/// Kicks out candidates that did not produce a block in the kick threshold
/// and refund their deposits.
pub fn kick_stale_candidates(candidates: Vec<CandidateInfo<T::AccountId, BalanceOf<T>>>) -> Vec<T::AccountId> {
// TODO: also kick candidates when escrow balance drops
Copy link
Member

Choose a reason for hiding this comment

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

I don't think there is consensus on whether or not we should, so fine with leaving this as-is for now

@gregdhill
Copy link
Member Author

Wouldn't switching over without migration lead to their KINT/INTR being locked forever? And wouldn't it lead to problems when existing collators quit, as we would attempt to unlock vKINT but didn't lock?

This is not a problem because we have not yet enabled registration.

@gregdhill gregdhill merged commit 51a5636 into interlay:master Aug 22, 2022
@gregdhill gregdhill deleted the feat/collator-escrow branch August 22, 2022 13:02
@sander2 sander2 added this to the Release 1.19 milestone Sep 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-democracy Needs a referendum to be enacted
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants